06 Apr, 2012

1 commit

  • Many users of debugfs copy the implementation of default_open() when
    they want to support a custom read/write function op. This leads to a
    proliferation of the default_open() implementation across the entire
    tree.

    Now that the common implementation has been consolidated into libfs we
    can replace all the users of this function with simple_open().

    This replacement was done with the following semantic patch:

    @ open @
    identifier open_f != simple_open;
    identifier i, f;
    @@
    -int open_f(struct inode *i, struct file *f)
    -{
    (
    -if (i->i_private)
    -f->private_data = i->i_private;
    |
    -f->private_data = i->i_private;
    )
    -return 0;
    -}

    @ has_open depends on open @
    identifier fops;
    identifier open.open_f;
    @@
    struct file_operations fops = {
    ...
    -.open = open_f,
    +.open = simple_open,
    ...
    };

    [akpm@linux-foundation.org: checkpatch fixes]
    Signed-off-by: Stephen Boyd
    Cc: Greg Kroah-Hartman
    Cc: Al Viro
    Cc: Julia Lawall
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Boyd
     

24 Feb, 2012

2 commits

  • Fix this:

    root@omap4430-panda:~# cat /debug/iommu/ducati/mem
    [ 62.725708] Unable to handle kernel NULL pointer dereference at virtual addre
    ss 0000001c
    [ 62.725708] pgd = e6240000
    [ 62.737091] [0000001c] *pgd=a7168831, *pte=00000000, *ppte=00000000
    [ 62.743682] Internal error: Oops: 17 [#1] SMP
    [ 62.743682] Modules linked in: omap_iommu_debug omap_iovmm virtio_rpmsg_bus o
    map_remoteproc remoteproc virtio_ring virtio mailbox_mach mailbox
    [ 62.743682] CPU: 0 Not tainted (3.3.0-rc1-00265-g382f84e-dirty #682)
    [ 62.743682] PC is at debug_read_mem+0x5c/0xac [omap_iommu_debug]
    [ 62.743682] LR is at 0x1004
    [ 62.777832] pc : [] lr : [] psr: 60000013
    [ 62.777832] sp : e72c7f40 ip : c0763c00 fp : 00000001
    [ 62.777832] r10: 00000000 r9 : 00000000 r8 : e72c7f80
    [ 62.777832] r7 : e6ffdc08 r6 : bed1ac78 r5 : 00001000 r4 : e7276000
    [ 62.777832] r3 : e60f3460 r2 : 00000000 r1 : e60f38c0 r0 : 00000000
    [ 62.777832] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
    [ 62.816375] Control: 10c53c7d Table: a624004a DAC: 00000015
    [ 62.816375] Process cat (pid: 1176, stack limit = 0xe72c62f8)
    [ 62.828369] Stack: (0xe72c7f40 to 0xe72c8000)
    ...
    [ 62.884185] [] (debug_read_mem+0x5c/0xac [omap_iommu_debug]) from [] (vfs_read+0xac/0x130)
    [ 62.884185] [] (vfs_read+0xac/0x130) from [] (sys_read+0x40/0x70)
    [ 62.884185] [] (sys_read+0x40/0x70) from [] (ret_fast_syscall+0x0/0x3c)

    Fix also its 'echo bla > /debug/iommu/ducati/mem' Oops sibling, too.

    Signed-off-by: Ohad Ben-Cohen
    Cc: Tony Lindgren
    Cc: Hiroshi Doyu
    Cc: Laurent Pinchart
    Cc: Russell King
    Cc: Joerg Roedel
    Cc: stable@vger.kernel.org
    Signed-off-by: Joerg Roedel

    Ohad Ben-Cohen
     
  • Adapt omap-iommu-debug to the latest omap-iommu API changes, which
    were introduced by commit fabdbca "iommu/omap: eliminate the public
    omap_find_iommu_device() method".

    In a nutshell, iommu users are not expected to provide the omap_iommu
    handle anymore - instead, iommus are attached using their user's device
    handle.

    omap-iommu-debug is a hybrid beast though: it invokes both public and
    private omap iommu API, so fix it as necessary (otherwise a crash
    is imminent).

    Note: omap-iommu-debug is a bit disturbing, as it fiddles with internal
    omap iommu data and requires exposing API which is otherwise not needed.
    It should better be more tightly coupled with omap-iommu, to prevent
    further bit rot and avoid exposing redundant API. Naturally that's out
    of scope for the -rc cycle, so for now just fix the obvious.

    Reported-by: Russell King
    Signed-off-by: Ohad Ben-Cohen
    Cc: Tony Lindgren
    Cc: Hiroshi Doyu
    Cc: Laurent Pinchart
    Cc: Joerg Roedel
    Signed-off-by: Joerg Roedel

    Ohad Ben-Cohen
     

09 Nov, 2011

1 commit


26 Aug, 2011

2 commits

  • Prepend 'omap_' to OMAP's 'struct iommu' and exposed API, to prevent
    namespace pollution and generally to improve readability of the code
    that still uses the driver directly.

    Update the users as needed as well.

    Signed-off-by: Ohad Ben-Cohen
    Acked-by: Laurent Pinchart
    Acked-by: Hiroshi DOYU
    Acked-by: Tony Lindgren
    Signed-off-by: Joerg Roedel

    Ohad Ben-Cohen
     
  • Move OMAP's iommu drivers to the dedicated iommu drivers folder.

    While OMAP's iovmm (virtual memory manager) driver does not strictly
    belong to the iommu drivers folder, move it there as well, because
    it's by no means OMAP-specific (in concept. technically it is still
    coupled with OMAP's iommu).

    Eventually, iovmm will be completely replaced with the generic,
    iommu-based, dma-mapping API.

    Signed-off-by: Ohad Ben-Cohen
    Acked-by: Laurent Pinchart
    Acked-by: Hiroshi DOYU
    Acked-by: Tony Lindgren
    Signed-off-by: Joerg Roedel

    Ohad Ben-Cohen