Searched hist:1892 (Results 1 - 25 of 58) sorted by path
/linux-master/drivers/nfc/st21nfca/ | ||
H A D | Makefile | diff 1892bf84 Tue May 20 14:21:59 MDT 2014 Christophe Ricard <christophe.ricard@gmail.com> NFC: st21nfca: Adding P2P support to st21nfca in Initiator & Target mode Support for Initiator and Target mode with ISO18092 commands support: - ATR_REQ/ATR_RES - PSL_REQ/PSL_RES - DEP_REQ/DEP_RES Work based on net/nfc/digital_dep.c. st21nfca is using: - Gate reader F for P2P in initiator mode. - Gate card F for P2P in target mode. Felica tag and p2p are differentiated with NFCID2. When starting with 01FE it is acting in p2p mode. On complete_target_discovered on ST21NFCA_RF_READER_F_GATE supported_protocols is set to NFC_PROTO_NFC_DEP_MASK for P2P. Tested against: Nexus S, Galaxy S2, Galaxy S3, Galaxy S3 Mini, Nexus 4 & Nexus 5. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> |
H A D | dep.c | diff 3decabdc Thu May 28 04:20:37 MDT 2020 Chuhong Yuan <hslester96@gmail.com> NFC: st21nfca: add missed kfree_skb() in an error path st21nfca_tm_send_atr_res() misses to call kfree_skb() in an error path. Add the missed function call to fix it. Fixes: 1892bf844ea0 ("NFC: st21nfca: Adding P2P support to st21nfca in Initiator & Target mode") Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/arch/arm/mach-bcm/ | ||
H A D | Kconfig | diff 1892bbcd Tue Apr 15 06:37:19 MDT 2014 Alex Elder <elder@linaro.org> ARM: bcm: clean up config and build targets Currently CONFIG_ARCH_BCM_MOBILE is used to select all (both) Broadcom mobile SoC families. Instead, use that only as a config menu switch, and define specific symbols like ARCH_BCM_281XX to select a particular SoC family. If ARCH_BCM_MOBILE is selected, all of the SoCs will be selected by default, but this way each can be disabled individually as well. Note that BCM281xx and BCM21664 both require the SMC and L2 cache control code, so that code will be built based on ARCH_BCM_MOBILE. Signed-off-by: Alex Elder <elder@linaro.org> [mporter: added ARM: to the description] Signed-off-by: Matt Porter <mporter@linaro.org> |
H A D | Makefile | diff 1892bbcd Tue Apr 15 06:37:19 MDT 2014 Alex Elder <elder@linaro.org> ARM: bcm: clean up config and build targets Currently CONFIG_ARCH_BCM_MOBILE is used to select all (both) Broadcom mobile SoC families. Instead, use that only as a config menu switch, and define specific symbols like ARCH_BCM_281XX to select a particular SoC family. If ARCH_BCM_MOBILE is selected, all of the SoCs will be selected by default, but this way each can be disabled individually as well. Note that BCM281xx and BCM21664 both require the SMC and L2 cache control code, so that code will be built based on ARCH_BCM_MOBILE. Signed-off-by: Alex Elder <elder@linaro.org> [mporter: added ARM: to the description] Signed-off-by: Matt Porter <mporter@linaro.org> |
/linux-master/arch/powerpc/boot/dts/ | ||
H A D | warp.dts | diff 1892e87a Tue Sep 27 00:03:25 MDT 2022 Dmitry Torokhov <dmitry.torokhov@gmail.com> powerpc/warp: switch to using gpiod API This switches PIKA Warp away from legacy gpio API and to newer gpiod API, so that we can eventually deprecate the former. Because LEDs are normally driven by leds-gpio driver, but the platform code also wants to access the LEDs during thermal shutdown, and gpiod API does not allow locating GPIO without requesting it, the platform code is now responsible for locating GPIOs through device tree and requesting them. It then constructs platform data for leds-gpio platform device and registers it. This allows platform code to retain access to LED GPIO descriptors and use them when needed. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/YzKSLcrYmV5kjyeX@google.com |
/linux-master/arch/powerpc/platforms/44x/ | ||
H A D | warp.c | diff 1892e87a Tue Sep 27 00:03:25 MDT 2022 Dmitry Torokhov <dmitry.torokhov@gmail.com> powerpc/warp: switch to using gpiod API This switches PIKA Warp away from legacy gpio API and to newer gpiod API, so that we can eventually deprecate the former. Because LEDs are normally driven by leds-gpio driver, but the platform code also wants to access the LEDs during thermal shutdown, and gpiod API does not allow locating GPIO without requesting it, the platform code is now responsible for locating GPIOs through device tree and requesting them. It then constructs platform data for leds-gpio platform device and registers it. This allows platform code to retain access to LED GPIO descriptors and use them when needed. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/YzKSLcrYmV5kjyeX@google.com |
/linux-master/drivers/ata/ | ||
H A D | libata-eh.c | diff fb1b8b11 Mon Jan 09 07:49:28 MST 2017 Geert Uytterhoeven <geert@linux-m68k.org> libata-eh: Use switch() instead of sparse array for protocol strings Replace the sparse 256-pointer array for looking up protocol strings by a switch() statement to reduce kernel size. According to bloat-o-meter, this saves 910 bytes on m68k (32-bit), and 1892 bytes on arm64 (64-bit). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Tejun Heo <tj@kernel.org> |
/linux-master/drivers/block/drbd/ | ||
H A D | drbd_main.c | diff 584164c8 Fri Mar 12 03:55:27 MST 2021 Lee Jones <lee.jones@linaro.org> block: drbd: drbd_main: Fix a bunch of function documentation discrepancies Fixes the following W=1 kernel build warning(s): drivers/block/drbd/drbd_main.c:278: warning: Function parameter or member 'connection' not described in 'tl_clear' drivers/block/drbd/drbd_main.c:278: warning: Excess function parameter 'device' description in 'tl_clear' drivers/block/drbd/drbd_main.c:489: warning: Function parameter or member 'cpu_mask' not described in 'drbd_calc_cpu_mask' drivers/block/drbd/drbd_main.c:528: warning: Excess function parameter 'device' description in 'drbd_thread_current_set_cpu' drivers/block/drbd/drbd_main.c:549: warning: Function parameter or member 'connection' not described in 'drbd_header_size' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'device' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'c' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1335: warning: Function parameter or member 'peer_device' not described in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1335: warning: Excess function parameter 'device' description in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Function parameter or member 'peer_device' not described in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Excess function parameter 'device' description in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'connection' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'sock' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'buffer' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'size' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'msg_flags' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:3525: warning: Function parameter or member 'flags' not described in 'drbd_queue_bitmap_io' drivers/block/drbd/drbd_main.c:3563: warning: Function parameter or member 'flags' not described in 'drbd_bitmap_io' Cc: Philipp Reisner <philipp.reisner@linbit.com> Cc: Lars Ellenberg <lars.ellenberg@linbit.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: drbd-dev@lists.linbit.com Cc: linux-block@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210312105530.2219008-9-lee.jones@linaro.org Signed-off-by: Jens Axboe <axboe@kernel.dk> diff 584164c8 Fri Mar 12 03:55:27 MST 2021 Lee Jones <lee.jones@linaro.org> block: drbd: drbd_main: Fix a bunch of function documentation discrepancies Fixes the following W=1 kernel build warning(s): drivers/block/drbd/drbd_main.c:278: warning: Function parameter or member 'connection' not described in 'tl_clear' drivers/block/drbd/drbd_main.c:278: warning: Excess function parameter 'device' description in 'tl_clear' drivers/block/drbd/drbd_main.c:489: warning: Function parameter or member 'cpu_mask' not described in 'drbd_calc_cpu_mask' drivers/block/drbd/drbd_main.c:528: warning: Excess function parameter 'device' description in 'drbd_thread_current_set_cpu' drivers/block/drbd/drbd_main.c:549: warning: Function parameter or member 'connection' not described in 'drbd_header_size' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'device' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'c' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1335: warning: Function parameter or member 'peer_device' not described in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1335: warning: Excess function parameter 'device' description in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Function parameter or member 'peer_device' not described in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Excess function parameter 'device' description in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'connection' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'sock' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'buffer' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'size' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'msg_flags' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:3525: warning: Function parameter or member 'flags' not described in 'drbd_queue_bitmap_io' drivers/block/drbd/drbd_main.c:3563: warning: Function parameter or member 'flags' not described in 'drbd_bitmap_io' Cc: Philipp Reisner <philipp.reisner@linbit.com> Cc: Lars Ellenberg <lars.ellenberg@linbit.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: drbd-dev@lists.linbit.com Cc: linux-block@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210312105530.2219008-9-lee.jones@linaro.org Signed-off-by: Jens Axboe <axboe@kernel.dk> diff 584164c8 Fri Mar 12 03:55:27 MST 2021 Lee Jones <lee.jones@linaro.org> block: drbd: drbd_main: Fix a bunch of function documentation discrepancies Fixes the following W=1 kernel build warning(s): drivers/block/drbd/drbd_main.c:278: warning: Function parameter or member 'connection' not described in 'tl_clear' drivers/block/drbd/drbd_main.c:278: warning: Excess function parameter 'device' description in 'tl_clear' drivers/block/drbd/drbd_main.c:489: warning: Function parameter or member 'cpu_mask' not described in 'drbd_calc_cpu_mask' drivers/block/drbd/drbd_main.c:528: warning: Excess function parameter 'device' description in 'drbd_thread_current_set_cpu' drivers/block/drbd/drbd_main.c:549: warning: Function parameter or member 'connection' not described in 'drbd_header_size' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'device' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'c' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1335: warning: Function parameter or member 'peer_device' not described in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1335: warning: Excess function parameter 'device' description in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Function parameter or member 'peer_device' not described in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Excess function parameter 'device' description in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'connection' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'sock' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'buffer' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'size' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'msg_flags' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:3525: warning: Function parameter or member 'flags' not described in 'drbd_queue_bitmap_io' drivers/block/drbd/drbd_main.c:3563: warning: Function parameter or member 'flags' not described in 'drbd_bitmap_io' Cc: Philipp Reisner <philipp.reisner@linbit.com> Cc: Lars Ellenberg <lars.ellenberg@linbit.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: drbd-dev@lists.linbit.com Cc: linux-block@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210312105530.2219008-9-lee.jones@linaro.org Signed-off-by: Jens Axboe <axboe@kernel.dk> diff 584164c8 Fri Mar 12 03:55:27 MST 2021 Lee Jones <lee.jones@linaro.org> block: drbd: drbd_main: Fix a bunch of function documentation discrepancies Fixes the following W=1 kernel build warning(s): drivers/block/drbd/drbd_main.c:278: warning: Function parameter or member 'connection' not described in 'tl_clear' drivers/block/drbd/drbd_main.c:278: warning: Excess function parameter 'device' description in 'tl_clear' drivers/block/drbd/drbd_main.c:489: warning: Function parameter or member 'cpu_mask' not described in 'drbd_calc_cpu_mask' drivers/block/drbd/drbd_main.c:528: warning: Excess function parameter 'device' description in 'drbd_thread_current_set_cpu' drivers/block/drbd/drbd_main.c:549: warning: Function parameter or member 'connection' not described in 'drbd_header_size' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'device' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'c' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1335: warning: Function parameter or member 'peer_device' not described in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1335: warning: Excess function parameter 'device' description in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Function parameter or member 'peer_device' not described in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Excess function parameter 'device' description in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'connection' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'sock' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'buffer' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'size' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'msg_flags' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:3525: warning: Function parameter or member 'flags' not described in 'drbd_queue_bitmap_io' drivers/block/drbd/drbd_main.c:3563: warning: Function parameter or member 'flags' not described in 'drbd_bitmap_io' Cc: Philipp Reisner <philipp.reisner@linbit.com> Cc: Lars Ellenberg <lars.ellenberg@linbit.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: drbd-dev@lists.linbit.com Cc: linux-block@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210312105530.2219008-9-lee.jones@linaro.org Signed-off-by: Jens Axboe <axboe@kernel.dk> diff 584164c8 Fri Mar 12 03:55:27 MST 2021 Lee Jones <lee.jones@linaro.org> block: drbd: drbd_main: Fix a bunch of function documentation discrepancies Fixes the following W=1 kernel build warning(s): drivers/block/drbd/drbd_main.c:278: warning: Function parameter or member 'connection' not described in 'tl_clear' drivers/block/drbd/drbd_main.c:278: warning: Excess function parameter 'device' description in 'tl_clear' drivers/block/drbd/drbd_main.c:489: warning: Function parameter or member 'cpu_mask' not described in 'drbd_calc_cpu_mask' drivers/block/drbd/drbd_main.c:528: warning: Excess function parameter 'device' description in 'drbd_thread_current_set_cpu' drivers/block/drbd/drbd_main.c:549: warning: Function parameter or member 'connection' not described in 'drbd_header_size' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'device' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1204: warning: Function parameter or member 'c' not described in 'send_bitmap_rle_or_plain' drivers/block/drbd/drbd_main.c:1335: warning: Function parameter or member 'peer_device' not described in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1335: warning: Excess function parameter 'device' description in '_drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Function parameter or member 'peer_device' not described in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1379: warning: Excess function parameter 'device' description in 'drbd_send_ack' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'connection' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'sock' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'buffer' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'size' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:1892: warning: Function parameter or member 'msg_flags' not described in 'drbd_send_all' drivers/block/drbd/drbd_main.c:3525: warning: Function parameter or member 'flags' not described in 'drbd_queue_bitmap_io' drivers/block/drbd/drbd_main.c:3563: warning: Function parameter or member 'flags' not described in 'drbd_bitmap_io' Cc: Philipp Reisner <philipp.reisner@linbit.com> Cc: Lars Ellenberg <lars.ellenberg@linbit.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: drbd-dev@lists.linbit.com Cc: linux-block@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210312105530.2219008-9-lee.jones@linaro.org Signed-off-by: Jens Axboe <axboe@kernel.dk> |
/linux-master/drivers/block/zram/ | ||
H A D | zcomp.c | diff 5ef3a8b1 Wed Nov 15 18:33:49 MST 2017 Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> zram: add zstd to the supported algorithms list Add ZSTD to the list of supported compression algorithms. ZRAM fio perf test: LZO DEFLATE ZSTD #jobs1 WRITE: (2180MB/s) (77.2MB/s) (1429MB/s) WRITE: (1617MB/s) (77.7MB/s) (1202MB/s) READ: (426MB/s) (595MB/s) (1181MB/s) READ: (422MB/s) (572MB/s) (1020MB/s) READ: (318MB/s) (67.8MB/s) (563MB/s) WRITE: (318MB/s) (67.9MB/s) (564MB/s) READ: (336MB/s) (68.3MB/s) (583MB/s) WRITE: (335MB/s) (68.2MB/s) (582MB/s) #jobs2 WRITE: (3441MB/s) (152MB/s) (2141MB/s) WRITE: (2507MB/s) (147MB/s) (1888MB/s) READ: (801MB/s) (1146MB/s) (1890MB/s) READ: (767MB/s) (1096MB/s) (2073MB/s) READ: (621MB/s) (126MB/s) (1009MB/s) WRITE: (621MB/s) (126MB/s) (1009MB/s) READ: (656MB/s) (125MB/s) (1075MB/s) WRITE: (657MB/s) (126MB/s) (1077MB/s) #jobs3 WRITE: (4772MB/s) (225MB/s) (3394MB/s) WRITE: (3905MB/s) (211MB/s) (2939MB/s) READ: (1216MB/s) (1608MB/s) (3218MB/s) READ: (1159MB/s) (1431MB/s) (2981MB/s) READ: (906MB/s) (156MB/s) (1457MB/s) WRITE: (907MB/s) (156MB/s) (1458MB/s) READ: (953MB/s) (158MB/s) (1595MB/s) WRITE: (952MB/s) (157MB/s) (1593MB/s) #jobs4 WRITE: (6036MB/s) (265MB/s) (4469MB/s) WRITE: (5059MB/s) (263MB/s) (3951MB/s) READ: (1618MB/s) (2066MB/s) (4276MB/s) READ: (1573MB/s) (1942MB/s) (3830MB/s) READ: (1202MB/s) (227MB/s) (1971MB/s) WRITE: (1200MB/s) (227MB/s) (1968MB/s) READ: (1265MB/s) (226MB/s) (2116MB/s) WRITE: (1264MB/s) (226MB/s) (2114MB/s) #jobs5 WRITE: (5339MB/s) (233MB/s) (3781MB/s) WRITE: (4298MB/s) (234MB/s) (3276MB/s) READ: (1626MB/s) (2048MB/s) (4081MB/s) READ: (1567MB/s) (1929MB/s) (3758MB/s) READ: (1174MB/s) (205MB/s) (1747MB/s) WRITE: (1173MB/s) (204MB/s) (1746MB/s) READ: (1214MB/s) (208MB/s) (1890MB/s) WRITE: (1215MB/s) (208MB/s) (1892MB/s) #jobs6 WRITE: (5666MB/s) (270MB/s) (4338MB/s) WRITE: (4828MB/s) (267MB/s) (3772MB/s) READ: (1803MB/s) (2058MB/s) (4946MB/s) READ: (1805MB/s) (2156MB/s) (4711MB/s) READ: (1334MB/s) (235MB/s) (2135MB/s) WRITE: (1335MB/s) (235MB/s) (2137MB/s) READ: (1364MB/s) (236MB/s) (2268MB/s) WRITE: (1365MB/s) (237MB/s) (2270MB/s) #jobs7 WRITE: (5474MB/s) (270MB/s) (4300MB/s) WRITE: (4666MB/s) (266MB/s) (3817MB/s) READ: (2022MB/s) (2319MB/s) (5472MB/s) READ: (1924MB/s) (2260MB/s) (5031MB/s) READ: (1369MB/s) (242MB/s) (2153MB/s) WRITE: (1370MB/s) (242MB/s) (2155MB/s) READ: (1499MB/s) (246MB/s) (2310MB/s) WRITE: (1497MB/s) (246MB/s) (2307MB/s) #jobs8 WRITE: (5558MB/s) (273MB/s) (4439MB/s) WRITE: (4763MB/s) (271MB/s) (3918MB/s) READ: (2201MB/s) (2599MB/s) (6062MB/s) READ: (2105MB/s) (2463MB/s) (5413MB/s) READ: (1490MB/s) (252MB/s) (2238MB/s) WRITE: (1488MB/s) (252MB/s) (2236MB/s) READ: (1566MB/s) (254MB/s) (2434MB/s) WRITE: (1568MB/s) (254MB/s) (2437MB/s) #jobs9 WRITE: (5120MB/s) (264MB/s) (4035MB/s) WRITE: (4531MB/s) (267MB/s) (3740MB/s) READ: (1940MB/s) (2258MB/s) (4986MB/s) READ: (2024MB/s) (2387MB/s) (4871MB/s) READ: (1343MB/s) (246MB/s) (2038MB/s) WRITE: (1342MB/s) (246MB/s) (2037MB/s) READ: (1553MB/s) (238MB/s) (2243MB/s) WRITE: (1552MB/s) (238MB/s) (2242MB/s) #jobs10 WRITE: (5345MB/s) (271MB/s) (3988MB/s) WRITE: (4750MB/s) (254MB/s) (3668MB/s) READ: (1876MB/s) (2363MB/s) (5150MB/s) READ: (1990MB/s) (2256MB/s) (5080MB/s) READ: (1355MB/s) (250MB/s) (2019MB/s) WRITE: (1356MB/s) (251MB/s) (2020MB/s) READ: (1490MB/s) (252MB/s) (2202MB/s) WRITE: (1488MB/s) (252MB/s) (2199MB/s) jobs1 perfstat instructions 52,065,555,710 ( 0.79) 855,731,114,587 ( 2.64) 54,280,709,944 ( 1.40) branches 14,020,427,116 ( 725.847) 101,733,449,582 (1074.521) 11,170,591,067 ( 992.869) branch-misses 22,626,174 ( 0.16%) 274,197,885 ( 0.27%) 25,915,805 ( 0.23%) jobs2 perfstat instructions 103,633,110,402 ( 0.75) 1,710,822,100,914 ( 2.59) 107,879,874,104 ( 1.28) branches 27,931,237,282 ( 679.203) 203,298,267,479 (1037.326) 22,185,350,842 ( 884.427) branch-misses 46,103,811 ( 0.17%) 533,747,204 ( 0.26%) 49,682,483 ( 0.22%) jobs3 perfstat instructions 154,857,283,657 ( 0.76) 2,565,748,974,197 ( 2.57) 161,515,435,813 ( 1.31) branches 41,759,490,355 ( 670.529) 304,905,605,277 ( 978.765) 33,215,805,907 ( 888.003) branch-misses 74,263,293 ( 0.18%) 759,746,240 ( 0.25%) 76,841,196 ( 0.23%) jobs4 perfstat instructions 206,215,849,076 ( 0.75) 3,420,169,460,897 ( 2.60) 215,003,061,664 ( 1.31) branches 55,632,141,739 ( 666.501) 406,394,977,433 ( 927.241) 44,214,322,251 ( 883.532) branch-misses 102,287,788 ( 0.18%) 1,098,617,314 ( 0.27%) 103,891,040 ( 0.23%) jobs5 perfstat instructions 258,711,315,588 ( 0.67) 4,275,657,533,244 ( 2.23) 269,332,235,685 ( 1.08) branches 69,802,821,166 ( 588.823) 507,996,211,252 ( 797.036) 55,450,846,129 ( 735.095) branch-misses 129,217,214 ( 0.19%) 1,243,284,991 ( 0.24%) 173,512,278 ( 0.31%) jobs6 perfstat instructions 312,796,166,008 ( 0.61) 5,133,896,344,660 ( 2.02) 323,658,769,588 ( 1.04) branches 84,372,488,583 ( 520.541) 610,310,494,402 ( 697.642) 66,683,292,992 ( 693.939) branch-misses 159,438,978 ( 0.19%) 1,396,368,563 ( 0.23%) 174,406,934 ( 0.26%) jobs7 perfstat instructions 363,211,372,930 ( 0.56) 5,988,205,600,879 ( 1.75) 377,824,674,156 ( 0.93) branches 98,057,013,765 ( 463.117) 711,841,255,974 ( 598.762) 77,879,009,954 ( 600.443) branch-misses 199,513,153 ( 0.20%) 1,507,651,077 ( 0.21%) 248,203,369 ( 0.32%) jobs8 perfstat instructions 413,960,354,615 ( 0.52) 6,842,918,558,378 ( 1.45) 431,938,486,581 ( 0.83) branches 111,812,574,884 ( 414.224) 813,299,084,518 ( 491.173) 89,062,699,827 ( 517.795) branch-misses 233,584,845 ( 0.21%) 1,531,593,921 ( 0.19%) 286,818,489 ( 0.32%) jobs9 perfstat instructions 465,976,220,300 ( 0.53) 7,698,467,237,372 ( 1.47) 486,352,600,321 ( 0.84) branches 125,931,456,162 ( 424.063) 915,207,005,715 ( 498.192) 100,370,404,090 ( 517.439) branch-misses 256,992,445 ( 0.20%) 1,782,809,816 ( 0.19%) 345,239,380 ( 0.34%) jobs10 perfstat instructions 517,406,372,715 ( 0.53) 8,553,527,312,900 ( 1.48) 540,732,653,094 ( 0.84) branches 139,839,780,676 ( 427.732) 1,016,737,699,389 ( 503.172) 111,696,557,638 ( 516.750) branch-misses 259,595,561 ( 0.19%) 1,952,570,279 ( 0.19%) 357,818,661 ( 0.32%) seconds elapsed 20.630411534 96.084546565 12.743373571 seconds elapsed 22.292627625 100.984155001 14.407413560 seconds elapsed 22.396016966 110.344880848 14.032201392 seconds elapsed 22.517330949 113.351459170 14.243074935 seconds elapsed 28.548305104 156.515193765 19.159286861 seconds elapsed 30.453538116 164.559937678 19.362492717 seconds elapsed 33.467108086 188.486827481 21.492612173 seconds elapsed 35.617727591 209.602677783 23.256422492 seconds elapsed 42.584239509 243.959902566 28.458540338 seconds elapsed 47.683632526 269.635248851 31.542404137 Over all, ZSTD has slower WRITE, but much faster READ (perhaps a static compression buffer used during the test helped ZSTD a lot), which results in faster test results. Memory consumption (zram mm_stat file): zram LZO mm_stat mm_stat (jobs1): 2147483648 23068672 33558528 0 33558528 0 0 mm_stat (jobs2): 2147483648 23068672 33558528 0 33558528 0 0 mm_stat (jobs3): 2147483648 23068672 33558528 0 33562624 0 0 mm_stat (jobs4): 2147483648 23068672 33558528 0 33558528 0 0 mm_stat (jobs5): 2147483648 23068672 33558528 0 33558528 0 0 mm_stat (jobs6): 2147483648 23068672 33558528 0 33562624 0 0 mm_stat (jobs7): 2147483648 23068672 33558528 0 33566720 0 0 mm_stat (jobs8): 2147483648 23068672 33558528 0 33558528 0 0 mm_stat (jobs9): 2147483648 23068672 33558528 0 33558528 0 0 mm_stat (jobs10): 2147483648 23068672 33558528 0 33562624 0 0 zram DEFLATE mm_stat mm_stat (jobs1): 2147483648 16252928 25178112 0 25178112 0 0 mm_stat (jobs2): 2147483648 16252928 25178112 0 25178112 0 0 mm_stat (jobs3): 2147483648 16252928 25178112 0 25178112 0 0 mm_stat (jobs4): 2147483648 16252928 25178112 0 25178112 0 0 mm_stat (jobs5): 2147483648 16252928 25178112 0 25178112 0 0 mm_stat (jobs6): 2147483648 16252928 25178112 0 25178112 0 0 mm_stat (jobs7): 2147483648 16252928 25178112 0 25190400 0 0 mm_stat (jobs8): 2147483648 16252928 25178112 0 25190400 0 0 mm_stat (jobs9): 2147483648 16252928 25178112 0 25178112 0 0 mm_stat (jobs10): 2147483648 16252928 25178112 0 25178112 0 0 zram ZSTD mm_stat mm_stat (jobs1): 2147483648 11010048 16781312 0 16781312 0 0 mm_stat (jobs2): 2147483648 11010048 16781312 0 16781312 0 0 mm_stat (jobs3): 2147483648 11010048 16781312 0 16785408 0 0 mm_stat (jobs4): 2147483648 11010048 16781312 0 16781312 0 0 mm_stat (jobs5): 2147483648 11010048 16781312 0 16781312 0 0 mm_stat (jobs6): 2147483648 11010048 16781312 0 16781312 0 0 mm_stat (jobs7): 2147483648 11010048 16781312 0 16781312 0 0 mm_stat (jobs8): 2147483648 11010048 16781312 0 16781312 0 0 mm_stat (jobs9): 2147483648 11010048 16781312 0 16785408 0 0 mm_stat (jobs10): 2147483648 11010048 16781312 0 16781312 0 0 ================================================================================== Official benchmarks [1]: Compressor name Ratio Compression Decompress. zstd 1.1.3 -1 2.877 430 MB/s 1110 MB/s zlib 1.2.8 -1 2.743 110 MB/s 400 MB/s brotli 0.5.2 -0 2.708 400 MB/s 430 MB/s quicklz 1.5.0 -1 2.238 550 MB/s 710 MB/s lzo1x 2.09 -1 2.108 650 MB/s 830 MB/s lz4 1.7.5 2.101 720 MB/s 3600 MB/s snappy 1.1.3 2.091 500 MB/s 1650 MB/s lzf 3.6 -1 2.077 400 MB/s 860 MB/s Minchan said: : I did test with my sample data and compared zstd with deflate. zstd's : compress ratio is lower a little bit but compression speed is much faster : 3 times more and decompress speed is too 2 times more. With different : data, it is different but overall, zstd would be better for speed at the : cost of a little lower compress ratio(about 5%) so I believe it's worth to : replace deflate. [1] https://github.com/facebook/zstd Link: http://lkml.kernel.org/r/20170912050005.3247-1-sergey.senozhatsky@gmail.com Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Acked-by: Minchan Kim <minchan@kernel.org> Tested-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
/linux-master/drivers/dma/ti/ | ||
H A D | omap-dma.c | diff d1134d66 Tue Jul 28 11:09:39 MDT 2020 Krzysztof Kozlowski <krzk@kernel.org> dmaengine: ti: omap-dma: Drop of_match_ptr to fix -Wunused-const-variable The of_device_id is included unconditionally by of.h header and used in the driver as well. Remove of_match_ptr to fix W=1 compile test warning with !CONFIG_OF: drivers/dma/ti/omap-dma.c:1892:34: warning: 'omap_dma_match' defined but not used [-Wunused-const-variable=] 1892 | static const struct of_device_id omap_dma_match[] = { Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20200728170939.28278-1-krzk@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org> diff d1134d66 Tue Jul 28 11:09:39 MDT 2020 Krzysztof Kozlowski <krzk@kernel.org> dmaengine: ti: omap-dma: Drop of_match_ptr to fix -Wunused-const-variable The of_device_id is included unconditionally by of.h header and used in the driver as well. Remove of_match_ptr to fix W=1 compile test warning with !CONFIG_OF: drivers/dma/ti/omap-dma.c:1892:34: warning: 'omap_dma_match' defined but not used [-Wunused-const-variable=] 1892 | static const struct of_device_id omap_dma_match[] = { Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20200728170939.28278-1-krzk@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org> |
/linux-master/drivers/gpu/drm/amd/display/dc/hwss/dcn10/ | ||
H A D | dcn10_hwseq.c | diff 9ccfe80d Thu Jan 25 08:46:04 MST 2024 Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()' The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875) Fixes: ddef02de0d71 ("drm/amd/display: add null checks before logging") Cc: Wyatt Wood <wyatt.wood@amd.com> Cc: Anthony Koo <Anthony.Koo@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
/linux-master/drivers/gpu/drm/i915/display/ | ||
H A D | intel_dp.c | diff 3680c2e9 Mon May 25 06:49:12 MDT 2020 Chris Wilson <chris@chris-wilson.co.uk> drm/i915/display: Only query DP state of a DDI encoder Avoid a NULL dereference for a mismatched encoder type, hit when probing state for all encoders. This is a band aid to prevent the OOPS as the right fix is "probably to swap the psr vs infoframes.enable checks, or outright disappear from this function" (Ville). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1892 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200525124912.16019-1-chris@chris-wilson.co.uk (cherry picked from commit 22da5d846d54dd13183b57874b9d5611d583d7c8) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> diff 22da5d84 Mon May 25 06:49:12 MDT 2020 Chris Wilson <chris@chris-wilson.co.uk> drm/i915/display: Only query DP state of a DDI encoder Avoid a NULL dereference for a mismatched encoder type, hit when probing state for all encoders. This is a band aid to prevent the OOPS as the right fix is "probably to swap the psr vs infoframes.enable checks, or outright disappear from this function" (Ville). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1892 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200525124912.16019-1-chris@chris-wilson.co.uk |
/linux-master/drivers/gpu/drm/i915/ | ||
H A D | i915_gem.c | diff 48ea1e32 Mon Jan 11 04:39:27 MST 2016 Michel Thierry <michel.thierry@intel.com> drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page Kernel and userspace are able to handle 4GB (1<<32) address space range, but "A32 Stateless Model" is not. According to documentation, A32 accesses are based on General State Base Address and bound checking is in place. Because size field (instruction State Base Address) limitation, it is not possible to address full 4GB memory region. A32 Stateless Model is used by some libraries and without this patch, the last page of 4GB address space is not accessible in 32bit processes. Reported-by: Artur Harasimiuk <artur.harasimiuk@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452512367-23614-1-git-send-email-michel.thierry@intel.com Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 1892faa9ec5d51b07d646cbd5597cd30e049aa51) Signed-off-by: Jani Nikula <jani.nikula@intel.com> diff 1892faa9 Mon Jan 11 04:39:27 MST 2016 Michel Thierry <michel.thierry@intel.com> drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page Kernel and userspace are able to handle 4GB (1<<32) address space range, but "A32 Stateless Model" is not. According to documentation, A32 accesses are based on General State Base Address and bound checking is in place. Because size field (instruction State Base Address) limitation, it is not possible to address full 4GB memory region. A32 Stateless Model is used by some libraries and without this patch, the last page of 4GB address space is not accessible in 32bit processes. Reported-by: Artur Harasimiuk <artur.harasimiuk@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452512367-23614-1-git-send-email-michel.thierry@intel.com Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> |
/linux-master/drivers/i2c/busses/ | ||
H A D | Kconfig | diff c62dac0a Thu Dec 03 15:32:50 MST 2020 Arnd Bergmann <arnd@arndb.de> i2c: mlxbf: select CONFIG_I2C_SLAVE If this is not enabled, the interfaces used in this driver do not work: drivers/i2c/busses/i2c-mlxbf.c:1888:3: error: implicit declaration of function 'i2c_slave_event' [-Werror,-Wimplicit-function-declaration] i2c_slave_event(slave, I2C_SLAVE_WRITE_REQUESTED, &value); ^ drivers/i2c/busses/i2c-mlxbf.c:1888:26: error: use of undeclared identifier 'I2C_SLAVE_WRITE_REQUESTED' i2c_slave_event(slave, I2C_SLAVE_WRITE_REQUESTED, &value); ^ drivers/i2c/busses/i2c-mlxbf.c:1890:32: error: use of undeclared identifier 'I2C_SLAVE_WRITE_RECEIVED' ret = i2c_slave_event(slave, I2C_SLAVE_WRITE_RECEIVED, ^ drivers/i2c/busses/i2c-mlxbf.c:1892:26: error: use of undeclared identifier 'I2C_SLAVE_STOP' i2c_slave_event(slave, I2C_SLAVE_STOP, &value); ^ Fixes: b5b5b32081cd ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Khalil Blaiech <kblaiech@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> |
/linux-master/drivers/media/i2c/ | ||
H A D | ov5640.c | diff dfbfb7aa Mon Dec 03 01:44:21 MST 2018 Maxime Ripard <mripard@kernel.org> media: ov5640: Compute the clock rate at runtime The clock rate, while hardcoded until now, is actually a function of the resolution, framerate and bytes per pixel. Now that we have an algorithm to adjust our clock rate, we can select it dynamically when we change the mode. This changes a bit the clock rate being used, with the following effect: +------+------+------+------+-----+-----------------+----------------+-----------+ | Hact | Vact | Htot | Vtot | FPS | Hardcoded clock | Computed clock | Deviation | +------+------+------+------+-----+-----------------+----------------+-----------+ | 640 | 480 | 1896 | 1080 | 15 | 56000000 | 61430400 | 8.84 % | | 640 | 480 | 1896 | 1080 | 30 | 112000000 | 122860800 | 8.84 % | | 1024 | 768 | 1896 | 1080 | 15 | 56000000 | 61430400 | 8.84 % | | 1024 | 768 | 1896 | 1080 | 30 | 112000000 | 122860800 | 8.84 % | | 320 | 240 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 320 | 240 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 176 | 144 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 176 | 144 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 720 | 480 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 720 | 480 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 720 | 576 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 720 | 576 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 1280 | 720 | 1892 | 740 | 15 | 42000000 | 42002400 | 0.01 % | | 1280 | 720 | 1892 | 740 | 30 | 84000000 | 84004800 | 0.01 % | | 1920 | 1080 | 2500 | 1120 | 15 | 84000000 | 84000000 | 0.00 % | | 1920 | 1080 | 2500 | 1120 | 30 | 168000000 | 168000000 | 0.00 % | | 2592 | 1944 | 2844 | 1944 | 15 | 84000000 | 165862080 | 49.36 % | +------+------+------+------+-----+-----------------+----------------+-----------+ Only the 640x480, 1024x768 and 2592x1944 modes are significantly affected by the new formula. In this case, 640x480 and 1024x768 are actually fixed by this change. Indeed, the sensor was sending data at, for example, 27.33fps instead of 30fps. This is -9%, which is roughly what we're seeing in the array. Testing these modes with the new clock setup actually fix that error, and data are now sent at around 30fps. 2592x1944, on the other hand, is probably due to the fact that this mode can only be used using MIPI-CSI2, in a two lane mode, and never really tested with a DVP bus. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Adam Ford <aford173@gmail.com> #imx6dq Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> diff dfbfb7aa Mon Dec 03 01:44:21 MST 2018 Maxime Ripard <mripard@kernel.org> media: ov5640: Compute the clock rate at runtime The clock rate, while hardcoded until now, is actually a function of the resolution, framerate and bytes per pixel. Now that we have an algorithm to adjust our clock rate, we can select it dynamically when we change the mode. This changes a bit the clock rate being used, with the following effect: +------+------+------+------+-----+-----------------+----------------+-----------+ | Hact | Vact | Htot | Vtot | FPS | Hardcoded clock | Computed clock | Deviation | +------+------+------+------+-----+-----------------+----------------+-----------+ | 640 | 480 | 1896 | 1080 | 15 | 56000000 | 61430400 | 8.84 % | | 640 | 480 | 1896 | 1080 | 30 | 112000000 | 122860800 | 8.84 % | | 1024 | 768 | 1896 | 1080 | 15 | 56000000 | 61430400 | 8.84 % | | 1024 | 768 | 1896 | 1080 | 30 | 112000000 | 122860800 | 8.84 % | | 320 | 240 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 320 | 240 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 176 | 144 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 176 | 144 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 720 | 480 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 720 | 480 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 720 | 576 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 720 | 576 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 1280 | 720 | 1892 | 740 | 15 | 42000000 | 42002400 | 0.01 % | | 1280 | 720 | 1892 | 740 | 30 | 84000000 | 84004800 | 0.01 % | | 1920 | 1080 | 2500 | 1120 | 15 | 84000000 | 84000000 | 0.00 % | | 1920 | 1080 | 2500 | 1120 | 30 | 168000000 | 168000000 | 0.00 % | | 2592 | 1944 | 2844 | 1944 | 15 | 84000000 | 165862080 | 49.36 % | +------+------+------+------+-----+-----------------+----------------+-----------+ Only the 640x480, 1024x768 and 2592x1944 modes are significantly affected by the new formula. In this case, 640x480 and 1024x768 are actually fixed by this change. Indeed, the sensor was sending data at, for example, 27.33fps instead of 30fps. This is -9%, which is roughly what we're seeing in the array. Testing these modes with the new clock setup actually fix that error, and data are now sent at around 30fps. 2592x1944, on the other hand, is probably due to the fact that this mode can only be used using MIPI-CSI2, in a two lane mode, and never really tested with a DVP bus. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Adam Ford <aford173@gmail.com> #imx6dq Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> |
/linux-master/drivers/misc/mei/ | ||
H A D | client.c | diff 1892fc2e Sun Sep 25 04:25:31 MDT 2016 Alexander Usyskin <alexander.usyskin@intel.com> mei: stop the stall timer worker if not needed The stall timer worker checks periodically if there is a stalled i/o transaction. The issue with the current implementation is that the timer is ticking also when there is no pending i/o transaction. This patch provides a simple change that prevents rescheduling of the delayed work when there is no pending i/o. Cc: Andy Lutomirski <luto@kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
H A D | hbm.c | diff 1892fc2e Sun Sep 25 04:25:31 MDT 2016 Alexander Usyskin <alexander.usyskin@intel.com> mei: stop the stall timer worker if not needed The stall timer worker checks periodically if there is a stalled i/o transaction. The issue with the current implementation is that the timer is ticking also when there is no pending i/o transaction. This patch provides a simple change that prevents rescheduling of the delayed work when there is no pending i/o. Cc: Andy Lutomirski <luto@kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
H A D | init.c | diff 1892fc2e Sun Sep 25 04:25:31 MDT 2016 Alexander Usyskin <alexander.usyskin@intel.com> mei: stop the stall timer worker if not needed The stall timer worker checks periodically if there is a stalled i/o transaction. The issue with the current implementation is that the timer is ticking also when there is no pending i/o transaction. This patch provides a simple change that prevents rescheduling of the delayed work when there is no pending i/o. Cc: Andy Lutomirski <luto@kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
H A D | interrupt.c | diff 1892fc2e Sun Sep 25 04:25:31 MDT 2016 Alexander Usyskin <alexander.usyskin@intel.com> mei: stop the stall timer worker if not needed The stall timer worker checks periodically if there is a stalled i/o transaction. The issue with the current implementation is that the timer is ticking also when there is no pending i/o transaction. This patch provides a simple change that prevents rescheduling of the delayed work when there is no pending i/o. Cc: Andy Lutomirski <luto@kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
H A D | mei_dev.h | diff 1892fc2e Sun Sep 25 04:25:31 MDT 2016 Alexander Usyskin <alexander.usyskin@intel.com> mei: stop the stall timer worker if not needed The stall timer worker checks periodically if there is a stalled i/o transaction. The issue with the current implementation is that the timer is ticking also when there is no pending i/o transaction. This patch provides a simple change that prevents rescheduling of the delayed work when there is no pending i/o. Cc: Andy Lutomirski <luto@kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
H A D | pci-me.c | diff 1892fc2e Sun Sep 25 04:25:31 MDT 2016 Alexander Usyskin <alexander.usyskin@intel.com> mei: stop the stall timer worker if not needed The stall timer worker checks periodically if there is a stalled i/o transaction. The issue with the current implementation is that the timer is ticking also when there is no pending i/o transaction. This patch provides a simple change that prevents rescheduling of the delayed work when there is no pending i/o. Cc: Andy Lutomirski <luto@kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
/linux-master/drivers/mmc/host/ | ||
H A D | renesas_sdhi_internal_dmac.c | diff 69e7d76a Wed Dec 16 03:29:32 MST 2020 Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> mmc: renesas_internal_dmac: add pre_req and post_req support Add pre_req and post_req support to improve performance. Inspired by a patch in the BSP by Masaharu Hayakawa. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/1608114572-1892-3-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> diff d7aefb28 Wed Dec 16 03:29:31 MST 2020 Takeshi Saito <takeshi.saito.xv@renesas.com> mmc: renesas_sdhi_internal_dmac: Fix DMA buffer alignment from 8 to 128-bytes According to the latest datasheet, the internal DMAC buffer alignment R-Car Gen3 SDHI HW should be 128-bytes. So, fix it. Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com> [shimoda: revise commit description, rebase] Fixes: 2a68ea7896e3 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/1608114572-1892-2-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> |
/linux-master/drivers/net/ | ||
H A D | veth.c | diff 5ce76fe1 Mon Mar 13 17:08:40 MDT 2023 Lorenzo Bianconi <lorenzo@kernel.org> veth: rely on rtnl_dereference() instead of on rcu_dereference() in veth_set_xdp_features() Fix the following kernel warning in veth_set_xdp_features routine relying on rtnl_dereference() instead of on rcu_dereference(): ============================= WARNING: suspicious RCU usage 6.3.0-rc1-00144-g064d70527aaa #149 Not tainted ----------------------------- drivers/net/veth.c:1265 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/135: (net/core/rtnetlink.c:6172) stack backtrace: CPU: 1 PID: 135 Comm: ip Not tainted 6.3.0-rc1-00144-g064d70527aaa #149 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:107) lockdep_rcu_suspicious (include/linux/context_tracking.h:152) veth_set_xdp_features (drivers/net/veth.c:1265 (discriminator 9)) veth_newlink (drivers/net/veth.c:1892) ? veth_set_features (drivers/net/veth.c:1774) ? kasan_save_stack (mm/kasan/common.c:47) ? kasan_save_stack (mm/kasan/common.c:46) ? kasan_set_track (mm/kasan/common.c:52) ? alloc_netdev_mqs (include/linux/slab.h:737) ? rcu_read_lock_sched_held (kernel/rcu/update.c:125) ? trace_kmalloc (include/trace/events/kmem.h:54) ? __xdp_rxq_info_reg (net/core/xdp.c:188) ? alloc_netdev_mqs (net/core/dev.c:10657) ? rtnl_create_link (net/core/rtnetlink.c:3312) rtnl_newlink_create (net/core/rtnetlink.c:3440) ? rtnl_link_get_net_capable.constprop.0 (net/core/rtnetlink.c:3391) __rtnl_newlink (net/core/rtnetlink.c:3657) ? lock_downgrade (kernel/locking/lockdep.c:5321) ? rtnl_link_unregister (net/core/rtnetlink.c:3487) rtnl_newlink (net/core/rtnetlink.c:3671) rtnetlink_rcv_msg (net/core/rtnetlink.c:6174) ? rtnl_link_fill (net/core/rtnetlink.c:6070) ? mark_usage (kernel/locking/lockdep.c:4914) ? mark_usage (kernel/locking/lockdep.c:4914) netlink_rcv_skb (net/netlink/af_netlink.c:2574) ? rtnl_link_fill (net/core/rtnetlink.c:6070) ? netlink_ack (net/netlink/af_netlink.c:2551) ? lock_acquire (kernel/locking/lockdep.c:467) ? net_generic (include/linux/rcupdate.h:805) ? netlink_deliver_tap (include/linux/rcupdate.h:805) netlink_unicast (net/netlink/af_netlink.c:1340) ? netlink_attachskb (net/netlink/af_netlink.c:1350) netlink_sendmsg (net/netlink/af_netlink.c:1942) ? netlink_unicast (net/netlink/af_netlink.c:1861) ? netlink_unicast (net/netlink/af_netlink.c:1861) sock_sendmsg (net/socket.c:727) ____sys_sendmsg (net/socket.c:2501) ? kernel_sendmsg (net/socket.c:2448) ? __copy_msghdr (net/socket.c:2428) ___sys_sendmsg (net/socket.c:2557) ? mark_usage (kernel/locking/lockdep.c:4914) ? do_recvmmsg (net/socket.c:2544) ? lock_acquire (kernel/locking/lockdep.c:467) ? find_held_lock (kernel/locking/lockdep.c:5159) ? __lock_release (kernel/locking/lockdep.c:5345) ? __might_fault (mm/memory.c:5625) ? lock_downgrade (kernel/locking/lockdep.c:5321) ? __fget_light (include/linux/atomic/atomic-arch-fallback.h:227) __sys_sendmsg (include/linux/file.h:31) ? __sys_sendmsg_sock (net/socket.c:2572) ? rseq_get_rseq_cs (kernel/rseq.c:275) ? lockdep_hardirqs_on_prepare.part.0 (kernel/locking/lockdep.c:4263) do_syscall_64 (arch/x86/entry/common.c:50) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) RIP: 0033:0x7f0d1aadeb17 Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 Fixes: fccca038f300 ("veth: take into account device reconfiguration for xdp_features flag") Suggested-by: Eric Dumazet <edumazet@google.com> Reported-by: Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/netdev/cover.1678364612.git.lorenzo@kernel.org/T/#me4c9d8e985ec7ebee981cfdb5bc5ec651ef4035d Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reported-by: syzbot+c3d0d9c42d59ff644ea6@syzkaller.appspotmail.com Reviewed-by: Eric Dumazet <edumazet@google.com> Tested-by: Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/r/dfd6a9a7d85e9113063165e1f47b466b90ad7b8a.1678748579.git.lorenzo@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
/linux-master/drivers/net/wireless/ath/ath5k/ | ||
H A D | base.c | diff 7dd6753f Sun Aug 12 19:18:33 MDT 2012 Bob Copeland <me@bobcopeland.com> ath5k: fix spin_lock_irqsave/spin_lock_bh nesting in mesh Lockdep found an inconsistent lock state when joining a mesh with ath5k. The problem is that ath5k takes the lock for its beacon state, ah->block, with spin_lock_irqsave(), while mesh internally takes the sync_offset_lock with spin_lock_bh() in mesh_sync_offset_adjust_tbtt(), which in turn is called under ah->block. This could deadlock if the beacon tasklet was run on the processor that held the beacon lock during the do_softirq() in spin_unlock_bh(). We probably shouldn't hold the lock around the callbacks, but the easiest fix is to switch to spin_lock_bh for ah->block: it doesn't need interrupts disabled anyway as the data in question is only accessed in softirq or process context. Fixes the following lockdep warning: [ 446.892304] WARNING: at kernel/softirq.c:159 _local_bh_enable_ip+0x38/0xa6() [ 446.892306] Hardware name: MacBook1,1 [ 446.892309] Modules linked in: tcp_lp fuse sunrpc cpufreq_ondemand acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 ip6table_filter nf_defrag_ipv4 xt_state nf_conntrack ip6_tables ext2 arc4 btusb bluetooth snd_hda_codec_idt snd_hda_intel carl9170 snd_hda_codec coretemp joydev ath5k snd_hwdep snd_seq isight_firmware ath snd_seq_device snd_pcm applesmc appletouch mac80211 input_polldev snd_timer microcode cfg80211 snd lpc_ich pcspkr i2c_i801 mfd_core soundcore rfkill snd_page_alloc sky2 tpm_infineon virtio_net kvm_intel kvm i915 drm_kms_helper drm i2c_algo_bit i2c_core video [ 446.892385] Pid: 1892, comm: iw Not tainted 3.6.0-rc1-wl+ #296 [ 446.892387] Call Trace: [ 446.892394] [<c0432958>] warn_slowpath_common+0x7c/0x91 [ 446.892398] [<c04399d7>] ? _local_bh_enable_ip+0x38/0xa6 [ 446.892403] [<c04399d7>] ? _local_bh_enable_ip+0x38/0xa6 [ 446.892459] [<f7f9ae3b>] ? mesh_sync_offset_adjust_tbtt+0x95/0x99 [mac80211] [ 446.892464] [<c043298f>] warn_slowpath_null+0x22/0x24 [ 446.892468] [<c04399d7>] _local_bh_enable_ip+0x38/0xa6 [ 446.892473] [<c0439a52>] local_bh_enable_ip+0xd/0xf [ 446.892479] [<c088004f>] _raw_spin_unlock_bh+0x34/0x37 [ 446.892527] [<f7f9ae3b>] mesh_sync_offset_adjust_tbtt+0x95/0x99 [mac80211] [ 446.892569] [<f7f7650f>] ieee80211_beacon_get_tim+0x28f/0x4e0 [mac80211] [ 446.892575] [<c047ceeb>] ? trace_hardirqs_on_caller+0x10e/0x13f [ 446.892591] [<f7fdc541>] ath5k_beacon_update+0x40/0x26b [ath5k] [ 446.892597] [<c047ad67>] ? lock_acquired+0x1f5/0x21e [ 446.892612] [<f7fdf9fb>] ? ath5k_bss_info_changed+0x167/0x1b2 [ath5k] [ 446.892617] [<c087f9ea>] ? _raw_spin_lock_irqsave+0x78/0x82 [ 446.892632] [<f7fdf9fb>] ? ath5k_bss_info_changed+0x167/0x1b2 [ath5k] [ 446.892647] [<f7fdfa09>] ath5k_bss_info_changed+0x175/0x1b2 [ath5k] [ 446.892651] [<c0479dd4>] ? lock_is_held+0x73/0x7b [ 446.892662] [<c0458fd5>] ? __might_sleep+0xa7/0x17a [ 446.892698] [<f7f5d8f7>] ieee80211_bss_info_change_notify+0x1ed/0x21a [mac80211] [ 446.892703] [<c0449875>] ? queue_work+0x24/0x32 [ 446.892718] [<f7fdf894>] ? ath5k_configure_filter+0x163/0x163 [ath5k] [ 446.892766] [<f7f95fa4>] ieee80211_start_mesh+0xb9/0xbd [mac80211] [ 446.892806] [<f7f6e610>] ieee80211_join_mesh+0x10c/0x116 [mac80211] [ 446.892834] [<f7a96b90>] __cfg80211_join_mesh+0x176/0x1b3 [cfg80211] [ 446.892855] [<f7a96c1c>] cfg80211_join_mesh+0x4f/0x6a [cfg80211] [ 446.892875] [<f7a89891>] nl80211_join_mesh+0x1de/0x1ed [cfg80211] [ 446.892908] [<f7a8db99>] ? nl80211_set_wiphy+0x4cf/0x4cf [cfg80211] [ 446.892919] [<c07cfa36>] genl_rcv_msg+0x1d5/0x1f3 [ 446.892940] [<c07cf861>] ? genl_rcv+0x25/0x25 [ 446.892946] [<c07cf009>] netlink_rcv_skb+0x37/0x78 [ 446.892950] [<c07cf85a>] genl_rcv+0x1e/0x25 [ 446.892955] [<c07cebf3>] netlink_unicast+0xc3/0x12d [ 446.892959] [<c07cee46>] netlink_sendmsg+0x1e9/0x213 [ 446.892966] [<c079f282>] sock_sendmsg+0x79/0x96 [ 446.892972] [<c04eb90d>] ? might_fault+0x9d/0xa3 [ 446.892978] [<c07a81d8>] ? copy_from_user+0x8/0xa [ 446.892983] [<c07a852c>] ? verify_iovec+0x43/0x77 [ 446.892987] [<c079f4d8>] __sys_sendmsg+0x180/0x215 [ 446.892993] [<c045f107>] ? sched_clock_cpu+0x134/0x144 [ 446.892997] [<c047992f>] ? trace_hardirqs_off+0xb/0xd [ 446.893002] [<c047bf88>] ? __lock_acquire+0x46b/0xb6e [ 446.893006] [<c047992f>] ? trace_hardirqs_off+0xb/0xd [ 446.893010] [<c045f149>] ? local_clock+0x32/0x49 [ 446.893015] [<c0479ec1>] ? lock_release_holdtime.part.9+0x4b/0x51 [ 446.893020] [<c0479dd4>] ? lock_is_held+0x73/0x7b [ 446.893025] [<c050d127>] ? fcheck_files+0x97/0xcd [ 446.893029] [<c050d4df>] ? fget_light+0x2d/0x81 [ 446.893034] [<c07a01f3>] sys_sendmsg+0x3b/0x52 [ 446.893038] [<c07a07b4>] sys_socketcall+0x238/0x2a2 [ 446.893044] [<c0885edf>] sysenter_do_call+0x12/0x38 [ 446.893047] ---[ end trace a9af5998f929270f ]--- [ 447.627222] [ 447.627232] ================================= [ 447.627237] [ INFO: inconsistent lock state ] [ 447.627244] 3.6.0-rc1-wl+ #296 Tainted: G W [ 447.627248] --------------------------------- [ 447.627253] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 447.627260] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 447.627264] (&(&ah->block)->rlock){+.?...}, at: [<f7fdd2d1>] ath5k_tasklet_beacon+0x91/0xa7 [ath5k] [ 447.627299] {SOFTIRQ-ON-W} state was registered at: [ 447.627304] [<c047cdbf>] mark_held_locks+0x59/0x77 [ 447.627316] [<c047ceeb>] trace_hardirqs_on_caller+0x10e/0x13f [ 447.627324] [<c047cf27>] trace_hardirqs_on+0xb/0xd [ 447.627332] [<c0439a3d>] _local_bh_enable_ip+0x9e/0xa6 [ 447.627342] [<c0439a52>] local_bh_enable_ip+0xd/0xf [ 447.627349] [<c088004f>] _raw_spin_unlock_bh+0x34/0x37 [ 447.627359] [<f7f9ae3b>] mesh_sync_offset_adjust_tbtt+0x95/0x99 [mac80211] [ 447.627451] [<f7f7650f>] ieee80211_beacon_get_tim+0x28f/0x4e0 [mac80211] [ 447.627526] [<f7fdc541>] ath5k_beacon_update+0x40/0x26b [ath5k] [ 447.627547] [<f7fdfa09>] ath5k_bss_info_changed+0x175/0x1b2 [ath5k] [ 447.627569] [<f7f5d8f7>] ieee80211_bss_info_change_notify+0x1ed/0x21a [mac80211] [ 447.627628] [<f7f95fa4>] ieee80211_start_mesh+0xb9/0xbd [mac80211] [ 447.627712] [<f7f6e610>] ieee80211_join_mesh+0x10c/0x116 [mac80211] [ 447.627782] [<f7a96b90>] __cfg80211_join_mesh+0x176/0x1b3 [cfg80211] [ 447.627816] [<f7a96c1c>] cfg80211_join_mesh+0x4f/0x6a [cfg80211] [ 447.627845] [<f7a89891>] nl80211_join_mesh+0x1de/0x1ed [cfg80211] [ 447.627872] [<c07cfa36>] genl_rcv_msg+0x1d5/0x1f3 [ 447.627881] [<c07cf009>] netlink_rcv_skb+0x37/0x78 [ 447.627891] [<c07cf85a>] genl_rcv+0x1e/0x25 [ 447.627898] [<c07cebf3>] netlink_unicast+0xc3/0x12d [ 447.627907] [<c07cee46>] netlink_sendmsg+0x1e9/0x213 [ 447.627915] [<c079f282>] sock_sendmsg+0x79/0x96 [ 447.627926] [<c079f4d8>] __sys_sendmsg+0x180/0x215 [ 447.627934] [<c07a01f3>] sys_sendmsg+0x3b/0x52 [ 447.627941] [<c07a07b4>] sys_socketcall+0x238/0x2a2 [ 447.627949] [<c0885edf>] sysenter_do_call+0x12/0x38 [ 447.627959] irq event stamp: 1929200 [ 447.627963] hardirqs last enabled at (1929200): [<c043a0e9>] tasklet_hi_action+0x3e/0xbf [ 447.627972] hardirqs last disabled at (1929199): [<c043a0c0>] tasklet_hi_action+0x15/0xbf [ 447.627981] softirqs last enabled at (1929196): [<c043999d>] _local_bh_enable+0x12/0x14 [ 447.627989] softirqs last disabled at (1929197): [<c040443b>] do_softirq+0x63/0xb8 [ 447.627999] [ 447.627999] other info that might help us debug this: [ 447.628004] Possible unsafe locking scenario: [ 447.628004] [ 447.628009] CPU0 [ 447.628012] ---- [ 447.628016] lock(&(&ah->block)->rlock); [ 447.628023] <Interrupt> [ 447.628027] lock(&(&ah->block)->rlock); [ 447.628034] [ 447.628034] *** DEADLOCK *** Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> |
H A D | mac80211-ops.c | diff 7dd6753f Sun Aug 12 19:18:33 MDT 2012 Bob Copeland <me@bobcopeland.com> ath5k: fix spin_lock_irqsave/spin_lock_bh nesting in mesh Lockdep found an inconsistent lock state when joining a mesh with ath5k. The problem is that ath5k takes the lock for its beacon state, ah->block, with spin_lock_irqsave(), while mesh internally takes the sync_offset_lock with spin_lock_bh() in mesh_sync_offset_adjust_tbtt(), which in turn is called under ah->block. This could deadlock if the beacon tasklet was run on the processor that held the beacon lock during the do_softirq() in spin_unlock_bh(). We probably shouldn't hold the lock around the callbacks, but the easiest fix is to switch to spin_lock_bh for ah->block: it doesn't need interrupts disabled anyway as the data in question is only accessed in softirq or process context. Fixes the following lockdep warning: [ 446.892304] WARNING: at kernel/softirq.c:159 _local_bh_enable_ip+0x38/0xa6() [ 446.892306] Hardware name: MacBook1,1 [ 446.892309] Modules linked in: tcp_lp fuse sunrpc cpufreq_ondemand acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 ip6table_filter nf_defrag_ipv4 xt_state nf_conntrack ip6_tables ext2 arc4 btusb bluetooth snd_hda_codec_idt snd_hda_intel carl9170 snd_hda_codec coretemp joydev ath5k snd_hwdep snd_seq isight_firmware ath snd_seq_device snd_pcm applesmc appletouch mac80211 input_polldev snd_timer microcode cfg80211 snd lpc_ich pcspkr i2c_i801 mfd_core soundcore rfkill snd_page_alloc sky2 tpm_infineon virtio_net kvm_intel kvm i915 drm_kms_helper drm i2c_algo_bit i2c_core video [ 446.892385] Pid: 1892, comm: iw Not tainted 3.6.0-rc1-wl+ #296 [ 446.892387] Call Trace: [ 446.892394] [<c0432958>] warn_slowpath_common+0x7c/0x91 [ 446.892398] [<c04399d7>] ? _local_bh_enable_ip+0x38/0xa6 [ 446.892403] [<c04399d7>] ? _local_bh_enable_ip+0x38/0xa6 [ 446.892459] [<f7f9ae3b>] ? mesh_sync_offset_adjust_tbtt+0x95/0x99 [mac80211] [ 446.892464] [<c043298f>] warn_slowpath_null+0x22/0x24 [ 446.892468] [<c04399d7>] _local_bh_enable_ip+0x38/0xa6 [ 446.892473] [<c0439a52>] local_bh_enable_ip+0xd/0xf [ 446.892479] [<c088004f>] _raw_spin_unlock_bh+0x34/0x37 [ 446.892527] [<f7f9ae3b>] mesh_sync_offset_adjust_tbtt+0x95/0x99 [mac80211] [ 446.892569] [<f7f7650f>] ieee80211_beacon_get_tim+0x28f/0x4e0 [mac80211] [ 446.892575] [<c047ceeb>] ? trace_hardirqs_on_caller+0x10e/0x13f [ 446.892591] [<f7fdc541>] ath5k_beacon_update+0x40/0x26b [ath5k] [ 446.892597] [<c047ad67>] ? lock_acquired+0x1f5/0x21e [ 446.892612] [<f7fdf9fb>] ? ath5k_bss_info_changed+0x167/0x1b2 [ath5k] [ 446.892617] [<c087f9ea>] ? _raw_spin_lock_irqsave+0x78/0x82 [ 446.892632] [<f7fdf9fb>] ? ath5k_bss_info_changed+0x167/0x1b2 [ath5k] [ 446.892647] [<f7fdfa09>] ath5k_bss_info_changed+0x175/0x1b2 [ath5k] [ 446.892651] [<c0479dd4>] ? lock_is_held+0x73/0x7b [ 446.892662] [<c0458fd5>] ? __might_sleep+0xa7/0x17a [ 446.892698] [<f7f5d8f7>] ieee80211_bss_info_change_notify+0x1ed/0x21a [mac80211] [ 446.892703] [<c0449875>] ? queue_work+0x24/0x32 [ 446.892718] [<f7fdf894>] ? ath5k_configure_filter+0x163/0x163 [ath5k] [ 446.892766] [<f7f95fa4>] ieee80211_start_mesh+0xb9/0xbd [mac80211] [ 446.892806] [<f7f6e610>] ieee80211_join_mesh+0x10c/0x116 [mac80211] [ 446.892834] [<f7a96b90>] __cfg80211_join_mesh+0x176/0x1b3 [cfg80211] [ 446.892855] [<f7a96c1c>] cfg80211_join_mesh+0x4f/0x6a [cfg80211] [ 446.892875] [<f7a89891>] nl80211_join_mesh+0x1de/0x1ed [cfg80211] [ 446.892908] [<f7a8db99>] ? nl80211_set_wiphy+0x4cf/0x4cf [cfg80211] [ 446.892919] [<c07cfa36>] genl_rcv_msg+0x1d5/0x1f3 [ 446.892940] [<c07cf861>] ? genl_rcv+0x25/0x25 [ 446.892946] [<c07cf009>] netlink_rcv_skb+0x37/0x78 [ 446.892950] [<c07cf85a>] genl_rcv+0x1e/0x25 [ 446.892955] [<c07cebf3>] netlink_unicast+0xc3/0x12d [ 446.892959] [<c07cee46>] netlink_sendmsg+0x1e9/0x213 [ 446.892966] [<c079f282>] sock_sendmsg+0x79/0x96 [ 446.892972] [<c04eb90d>] ? might_fault+0x9d/0xa3 [ 446.892978] [<c07a81d8>] ? copy_from_user+0x8/0xa [ 446.892983] [<c07a852c>] ? verify_iovec+0x43/0x77 [ 446.892987] [<c079f4d8>] __sys_sendmsg+0x180/0x215 [ 446.892993] [<c045f107>] ? sched_clock_cpu+0x134/0x144 [ 446.892997] [<c047992f>] ? trace_hardirqs_off+0xb/0xd [ 446.893002] [<c047bf88>] ? __lock_acquire+0x46b/0xb6e [ 446.893006] [<c047992f>] ? trace_hardirqs_off+0xb/0xd [ 446.893010] [<c045f149>] ? local_clock+0x32/0x49 [ 446.893015] [<c0479ec1>] ? lock_release_holdtime.part.9+0x4b/0x51 [ 446.893020] [<c0479dd4>] ? lock_is_held+0x73/0x7b [ 446.893025] [<c050d127>] ? fcheck_files+0x97/0xcd [ 446.893029] [<c050d4df>] ? fget_light+0x2d/0x81 [ 446.893034] [<c07a01f3>] sys_sendmsg+0x3b/0x52 [ 446.893038] [<c07a07b4>] sys_socketcall+0x238/0x2a2 [ 446.893044] [<c0885edf>] sysenter_do_call+0x12/0x38 [ 446.893047] ---[ end trace a9af5998f929270f ]--- [ 447.627222] [ 447.627232] ================================= [ 447.627237] [ INFO: inconsistent lock state ] [ 447.627244] 3.6.0-rc1-wl+ #296 Tainted: G W [ 447.627248] --------------------------------- [ 447.627253] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 447.627260] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 447.627264] (&(&ah->block)->rlock){+.?...}, at: [<f7fdd2d1>] ath5k_tasklet_beacon+0x91/0xa7 [ath5k] [ 447.627299] {SOFTIRQ-ON-W} state was registered at: [ 447.627304] [<c047cdbf>] mark_held_locks+0x59/0x77 [ 447.627316] [<c047ceeb>] trace_hardirqs_on_caller+0x10e/0x13f [ 447.627324] [<c047cf27>] trace_hardirqs_on+0xb/0xd [ 447.627332] [<c0439a3d>] _local_bh_enable_ip+0x9e/0xa6 [ 447.627342] [<c0439a52>] local_bh_enable_ip+0xd/0xf [ 447.627349] [<c088004f>] _raw_spin_unlock_bh+0x34/0x37 [ 447.627359] [<f7f9ae3b>] mesh_sync_offset_adjust_tbtt+0x95/0x99 [mac80211] [ 447.627451] [<f7f7650f>] ieee80211_beacon_get_tim+0x28f/0x4e0 [mac80211] [ 447.627526] [<f7fdc541>] ath5k_beacon_update+0x40/0x26b [ath5k] [ 447.627547] [<f7fdfa09>] ath5k_bss_info_changed+0x175/0x1b2 [ath5k] [ 447.627569] [<f7f5d8f7>] ieee80211_bss_info_change_notify+0x1ed/0x21a [mac80211] [ 447.627628] [<f7f95fa4>] ieee80211_start_mesh+0xb9/0xbd [mac80211] [ 447.627712] [<f7f6e610>] ieee80211_join_mesh+0x10c/0x116 [mac80211] [ 447.627782] [<f7a96b90>] __cfg80211_join_mesh+0x176/0x1b3 [cfg80211] [ 447.627816] [<f7a96c1c>] cfg80211_join_mesh+0x4f/0x6a [cfg80211] [ 447.627845] [<f7a89891>] nl80211_join_mesh+0x1de/0x1ed [cfg80211] [ 447.627872] [<c07cfa36>] genl_rcv_msg+0x1d5/0x1f3 [ 447.627881] [<c07cf009>] netlink_rcv_skb+0x37/0x78 [ 447.627891] [<c07cf85a>] genl_rcv+0x1e/0x25 [ 447.627898] [<c07cebf3>] netlink_unicast+0xc3/0x12d [ 447.627907] [<c07cee46>] netlink_sendmsg+0x1e9/0x213 [ 447.627915] [<c079f282>] sock_sendmsg+0x79/0x96 [ 447.627926] [<c079f4d8>] __sys_sendmsg+0x180/0x215 [ 447.627934] [<c07a01f3>] sys_sendmsg+0x3b/0x52 [ 447.627941] [<c07a07b4>] sys_socketcall+0x238/0x2a2 [ 447.627949] [<c0885edf>] sysenter_do_call+0x12/0x38 [ 447.627959] irq event stamp: 1929200 [ 447.627963] hardirqs last enabled at (1929200): [<c043a0e9>] tasklet_hi_action+0x3e/0xbf [ 447.627972] hardirqs last disabled at (1929199): [<c043a0c0>] tasklet_hi_action+0x15/0xbf [ 447.627981] softirqs last enabled at (1929196): [<c043999d>] _local_bh_enable+0x12/0x14 [ 447.627989] softirqs last disabled at (1929197): [<c040443b>] do_softirq+0x63/0xb8 [ 447.627999] [ 447.627999] other info that might help us debug this: [ 447.628004] Possible unsafe locking scenario: [ 447.628004] [ 447.628009] CPU0 [ 447.628012] ---- [ 447.628016] lock(&(&ah->block)->rlock); [ 447.628023] <Interrupt> [ 447.628027] lock(&(&ah->block)->rlock); [ 447.628034] [ 447.628034] *** DEADLOCK *** Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> |
Completed in 2135 milliseconds