Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 6月, 2015 5 次提交
  3. 29 5月, 2015 2 次提交
    • U
      mtd: dc21285: use raw spinlock functions for nw_gpio_lock · e5babdf9
      由 Uwe Kleine-König 提交于 
      Since commit bd31b859 (which is in 3.2-rc1) nw_gpio_lock is a raw spinlock
that needs usage of the corresponding raw functions.

This fixes:

  drivers/mtd/maps/dc21285.c: In function 'nw_en_write':
  drivers/mtd/maps/dc21285.c:41:340: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type
    spin_lock_irqsave(&nw_gpio_lock, flags);

  In file included from include/linux/seqlock.h:35:0,
                   from include/linux/time.h:5,
                   from include/linux/stat.h:18,
                   from include/linux/module.h:10,
                   from drivers/mtd/maps/dc21285.c:8:
  include/linux/spinlock.h:299:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
   static inline raw_spinlock_t *spinlock_check(spinlock_t *lock)
                                                                                                        ^
  drivers/mtd/maps/dc21285.c:43:25: warning: passing argument 1 of 'spin_unlock_irqrestore' from incompatible pointer type
    spin_unlock_irqrestore(&nw_gpio_lock, flags);
                           ^
  In file included from include/linux/seqlock.h:35:0,
                   from include/linux/time.h:5,
                   from include/linux/stat.h:18,
                   from include/linux/module.h:10,
                   from drivers/mtd/maps/dc21285.c:8:
  include/linux/spinlock.h:370:91: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
   static inline void spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)

Fixes: bd31b859 ("locking, ARM: Annotate low level hw locks as raw")
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      e5babdf9
    • B
      mtd: chips: fixup dependencies, to prevent build error · bde90062
      由 Brian Norris 提交于 
      Commit 4612c715 ("mtd: cfi: deinline large functions") moved some
code into the cfi_util library without creating a new dependency. So we
can get build failures like the following, when CONFIG_MTD_JEDECPROBE=y
and CONFIG_MTD_CFI_UTIL=m.

   drivers/built-in.o: In function `jedec_read_id':
>> jedec_probe.c:(.text+0x187ed8): undefined reference to `cfi_build_cmd_addr'
   drivers/built-in.o: In function `jedec_read_mfr':
>> jedec_probe.c:(.text+0x187f4a): undefined reference to `cfi_build_cmd_addr'
   drivers/built-in.o: In function `jedec_reset':
>> jedec_probe.c:(.text+0x187fe0): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x188004): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x18802b): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x18804e): undefined reference to `cfi_send_gen_cmd'
   drivers/built-in.o: In function `jedec_probe_chip':
>> jedec_probe.c:(.text+0x188130): undefined reference to `cfi_build_cmd_addr'
>> jedec_probe.c:(.text+0x18814d): undefined reference to `cfi_build_cmd_addr'
>> jedec_probe.c:(.text+0x1881dc): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x188203): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x18822d): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x1884c0): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x1884e7): undefined reference to `cfi_send_gen_cmd'
   drivers/built-in.o:jedec_probe.c:(.text+0x188511): more undefined references to `cfi_send_gen_cmd' follow
   drivers/built-in.o: In function `jedec_probe_chip':
>> jedec_probe.c:(.text+0x188618): undefined reference to `cfi_build_cmd'

So let's express the dependency properly.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      bde90062
  5. 28 5月, 2015 4 次提交
  7. 23 5月, 2015 2 次提交
  9. 22 5月, 2015 2 次提交
  11. 21 5月, 2015 8 次提交
  13. 19 5月, 2015 2 次提交
  15. 16 5月, 2015 6 次提交
  17. 15 5月, 2015 1 次提交
  19. 13 5月, 2015 1 次提交
    • B
      mtd: fix: avoid race condition when accessing mtd->usecount · 073db4a5
      由 Brian Norris 提交于 
      On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to
mtd->usecount were done without taking mtd_table_mutex.
kernel: Call Trace:
kernel: [<ffffffff80401818>] __put_mtd_device+0x20/0x50
kernel: [<ffffffff804086f4>] blktrans_release+0x8c/0xd8
kernel: [<ffffffff802577e0>] __blkdev_put+0x1a8/0x200
kernel: [<ffffffff802579a4>] blkdev_close+0x1c/0x30
kernel: [<ffffffff8022006c>] __fput+0xac/0x250
kernel: [<ffffffff80171208>] task_work_run+0xd8/0x120
kernel: [<ffffffff8012c23c>] work_notifysig+0x10/0x18
kernel:
kernel:
        Code: 2442ffff  ac8202d8  000217fe <00020336> dc820128  10400003
               00000000  0040f809  00000000
kernel: ---[ end trace 080fbb4579b47a73 ]---

Fixed by taking the mutex in blktrans_open and blktrans_release.

Note that this locking is already suggested in
include/linux/mtd/blktrans.h:

struct mtd_blktrans_ops {
...
	/* Called with mtd_table_mutex held; no race with add/remove */
	int (*open)(struct mtd_blktrans_dev *dev);
	void (*release)(struct mtd_blktrans_dev *dev);
...
};

But we weren't following it.

Originally reported by (and patched by) Zhang and Giuseppe,
independently. Improved and rewritten.

Cc: stable@vger.kernel.org
Reported-by: NZhang Xingcai <zhangxingcai@huawei.com>
Reported-by: NGiuseppe Cantavenera <giuseppe.cantavenera.ext@nokia.com>
Tested-by: NGiuseppe Cantavenera <giuseppe.cantavenera.ext@nokia.com>
Acked-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      073db4a5
  21. 12 5月, 2015 1 次提交
    • B
      mtd: nand: add common DT init code · 5844feea
      由 Brian Norris 提交于 
      These are already-documented common bindings for NAND chips. Let's
handle them in nand_base.

If NAND controller drivers need to act on this data before bringing up
the NAND chip (e.g., fill out ECC callback functions, change HW modes,
etc.), then they can do so between calling nand_scan_ident() and
nand_scan_tail().
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      5844feea
  23. 07 5月, 2015 6 次提交