Searched hist:6204 (Results 1 - 17 of 17) sorted by relevance
/linux-master/drivers/gpu/drm/etnaviv/ | ||
H A D | etnaviv_hwdb.c | diff 989c9dad Fri Mar 19 13:02:02 MDT 2021 Sascha Hauer <s.hauer@pengutronix.de> drm/etnaviv: add HWDB entry for GC7000 rev 6204 This is the 3D GPU found on the i.MX8MP SoC. The feature bits are taken from the NXP downstream kernel driver 6.4.3.p1.305572. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> |
/linux-master/mm/kmsan/ | ||
H A D | kmsan_test.c | diff 6204c9ab Sun Mar 05 16:13:22 MST 2023 Alexander Potapenko <glider@google.com> kmsan: add test_stackdepot_roundtrip Ensure that KMSAN does not report false positives in instrumented callers of stack_depot_save(), stack_depot_print(), and stack_depot_fetch(). Link: https://lkml.kernel.org/r/20230306111322.205724-2-glider@google.com Signed-off-by: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com> Cc: syzbot <syzkaller@googlegroups.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
/linux-master/drivers/s390/net/ | ||
H A D | qeth_l3_sys.c | diff 6204b47e Mon Apr 18 18:43:20 MDT 2011 Michał Mirosław <mirq-linux@rere.qmqm.pl> net: s390: convert to hw_features options.large_send was easy to get rid of. options.checksum_type has deeper roots so is left for later cleanup. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | qeth_core.h | diff 6204b47e Mon Apr 18 18:43:20 MDT 2011 Michał Mirosław <mirq-linux@rere.qmqm.pl> net: s390: convert to hw_features options.large_send was easy to get rid of. options.checksum_type has deeper roots so is left for later cleanup. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | qeth_l3_main.c | diff 6204b47e Mon Apr 18 18:43:20 MDT 2011 Michał Mirosław <mirq-linux@rere.qmqm.pl> net: s390: convert to hw_features options.large_send was easy to get rid of. options.checksum_type has deeper roots so is left for later cleanup. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/drivers/tty/serial/ | ||
H A D | bcm63xx_uart.c | diff d29e0d04 Thu Dec 05 19:26:07 MST 2013 Florian Fainelli <florian@openwrt.org> tty: serial: bcm63xx_uart: use linux/serial_bcm63xx.h Now that the UART block defines have been moved to a separate file, include that one and do not longer rely on the MIPS-specific bcm63xx_regs.h header file. Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6204/ |
/linux-master/tools/perf/util/ | ||
H A D | cache.h | diff 452e8401 Mon May 09 23:48:01 MDT 2016 Masami Hiramatsu <mhiramat@kernel.org> perf tools: Remove xrealloc and ALLOC_GROW Remove unused xrealloc() and ALLOC_GROW() from libperf. Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20160510054801.6158.6204.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
H A D | util.h | diff 452e8401 Mon May 09 23:48:01 MDT 2016 Masami Hiramatsu <mhiramat@kernel.org> perf tools: Remove xrealloc and ALLOC_GROW Remove unused xrealloc() and ALLOC_GROW() from libperf. Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20160510054801.6158.6204.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
H A D | Build | diff 452e8401 Mon May 09 23:48:01 MDT 2016 Masami Hiramatsu <mhiramat@kernel.org> perf tools: Remove xrealloc and ALLOC_GROW Remove unused xrealloc() and ALLOC_GROW() from libperf. Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20160510054801.6158.6204.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
/linux-master/fs/btrfs/ | ||
H A D | extent_map.h | diff 176840b3 Tue Feb 25 07:15:13 MST 2014 Filipe Manana <fdmanana@gmail.com> Btrfs: more efficient btrfs_drop_extent_cache While droping extent map structures from the extent cache that cover our target range, we would remove each extent map structure from the red black tree and then add either 1 or 2 new extent map structures if the former extent map covered sections outside our target range. This change simply attempts to replace the existing extent map structure with a new one that covers the subsection we're not interested in, instead of doing a red black remove operation followed by an insertion operation. The number of elements in an inode's extent map tree can get very high for large files under random writes. For example, while running the following test: sysbench --test=fileio --file-num=1 --file-total-size=10G \ --file-test-mode=rndrw --num-threads=32 --file-block-size=32768 \ --max-requests=500000 --file-rw-ratio=2 [prepare|run] I captured the following histogram capturing the number of extent_map items in the red black tree while that test was running: Count: 122462 Range: 1.000 - 172231.000; Mean: 96415.831; Median: 101855.000; Stddev: 49700.981 Percentiles: 90th: 160120.000; 95th: 166335.000; 99th: 171070.000 1.000 - 5.231: 452 | 5.231 - 187.392: 87 | 187.392 - 585.911: 206 | 585.911 - 1827.438: 623 | 1827.438 - 5695.245: 1962 # 5695.245 - 17744.861: 6204 #### 17744.861 - 55283.764: 21115 ############ 55283.764 - 172231.000: 91813 ##################################################### Benchmark: sysbench --test=fileio --file-num=1 --file-total-size=10G --file-test-mode=rndwr \ --num-threads=64 --file-block-size=32768 --max-requests=0 --max-time=60 \ --file-io-mode=sync --file-fsync-freq=0 [prepare|run] Before this change: 122.1Mb/sec After this change: 125.07Mb/sec (averages of 5 test runs) Test machine: quad core intel i5-3570K, 32Gb of ram, SSD Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com> Signed-off-by: Josef Bacik <jbacik@fb.com> |
H A D | extent_map.c | diff 176840b3 Tue Feb 25 07:15:13 MST 2014 Filipe Manana <fdmanana@gmail.com> Btrfs: more efficient btrfs_drop_extent_cache While droping extent map structures from the extent cache that cover our target range, we would remove each extent map structure from the red black tree and then add either 1 or 2 new extent map structures if the former extent map covered sections outside our target range. This change simply attempts to replace the existing extent map structure with a new one that covers the subsection we're not interested in, instead of doing a red black remove operation followed by an insertion operation. The number of elements in an inode's extent map tree can get very high for large files under random writes. For example, while running the following test: sysbench --test=fileio --file-num=1 --file-total-size=10G \ --file-test-mode=rndrw --num-threads=32 --file-block-size=32768 \ --max-requests=500000 --file-rw-ratio=2 [prepare|run] I captured the following histogram capturing the number of extent_map items in the red black tree while that test was running: Count: 122462 Range: 1.000 - 172231.000; Mean: 96415.831; Median: 101855.000; Stddev: 49700.981 Percentiles: 90th: 160120.000; 95th: 166335.000; 99th: 171070.000 1.000 - 5.231: 452 | 5.231 - 187.392: 87 | 187.392 - 585.911: 206 | 585.911 - 1827.438: 623 | 1827.438 - 5695.245: 1962 # 5695.245 - 17744.861: 6204 #### 17744.861 - 55283.764: 21115 ############ 55283.764 - 172231.000: 91813 ##################################################### Benchmark: sysbench --test=fileio --file-num=1 --file-total-size=10G --file-test-mode=rndwr \ --num-threads=64 --file-block-size=32768 --max-requests=0 --max-time=60 \ --file-io-mode=sync --file-fsync-freq=0 [prepare|run] Before this change: 122.1Mb/sec After this change: 125.07Mb/sec (averages of 5 test runs) Test machine: quad core intel i5-3570K, 32Gb of ram, SSD Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com> Signed-off-by: Josef Bacik <jbacik@fb.com> |
H A D | file.c | diff 176840b3 Tue Feb 25 07:15:13 MST 2014 Filipe Manana <fdmanana@gmail.com> Btrfs: more efficient btrfs_drop_extent_cache While droping extent map structures from the extent cache that cover our target range, we would remove each extent map structure from the red black tree and then add either 1 or 2 new extent map structures if the former extent map covered sections outside our target range. This change simply attempts to replace the existing extent map structure with a new one that covers the subsection we're not interested in, instead of doing a red black remove operation followed by an insertion operation. The number of elements in an inode's extent map tree can get very high for large files under random writes. For example, while running the following test: sysbench --test=fileio --file-num=1 --file-total-size=10G \ --file-test-mode=rndrw --num-threads=32 --file-block-size=32768 \ --max-requests=500000 --file-rw-ratio=2 [prepare|run] I captured the following histogram capturing the number of extent_map items in the red black tree while that test was running: Count: 122462 Range: 1.000 - 172231.000; Mean: 96415.831; Median: 101855.000; Stddev: 49700.981 Percentiles: 90th: 160120.000; 95th: 166335.000; 99th: 171070.000 1.000 - 5.231: 452 | 5.231 - 187.392: 87 | 187.392 - 585.911: 206 | 585.911 - 1827.438: 623 | 1827.438 - 5695.245: 1962 # 5695.245 - 17744.861: 6204 #### 17744.861 - 55283.764: 21115 ############ 55283.764 - 172231.000: 91813 ##################################################### Benchmark: sysbench --test=fileio --file-num=1 --file-total-size=10G --file-test-mode=rndwr \ --num-threads=64 --file-block-size=32768 --max-requests=0 --max-time=60 \ --file-io-mode=sync --file-fsync-freq=0 [prepare|run] Before this change: 122.1Mb/sec After this change: 125.07Mb/sec (averages of 5 test runs) Test machine: quad core intel i5-3570K, 32Gb of ram, SSD Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com> Signed-off-by: Josef Bacik <jbacik@fb.com> |
/linux-master/arch/arm64/boot/dts/freescale/ | ||
H A D | imx8mp.dtsi | diff 4bdb1192 Tue Mar 29 16:46:20 MDT 2022 Lucas Stach <l.stach@pengutronix.de> arm64: dts: imx8mp: add GPU nodes Add the DT nodes for both the 3D and 2D GPU cores found on the i.MX8MP. etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6204 etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341 [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Tested-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> |
/linux-master/scripts/dtc/include-prefixes/arm64/freescale/ | ||
H A D | imx8mp.dtsi | diff 4bdb1192 Tue Mar 29 16:46:20 MDT 2022 Lucas Stach <l.stach@pengutronix.de> arm64: dts: imx8mp: add GPU nodes Add the DT nodes for both the 3D and 2D GPU cores found on the i.MX8MP. etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6204 etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341 [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Tested-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> |
/linux-master/drivers/leds/ | ||
H A D | Kconfig | diff 6204f03d Thu Feb 01 13:26:34 MST 2018 Pavel Machek <pavel@ucw.cz> leds: Clarify supported chips by LM355x driver Clarify which controllers are supported by which driver. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> |
/linux-master/drivers/net/wireless/ath/ath11k/ | ||
H A D | mac.c | diff 7e8453e3 Sun Sep 06 15:26:25 MDT 2020 Tom Rix <trix@redhat.com> ath11k: fix a double free and a memory leak clang static analyzer reports this problem mac.c:6204:2: warning: Attempt to free released memory kfree(ar->mac.sbands[NL80211_BAND_2GHZ].channels); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The channels pointer is allocated in ath11k_mac_setup_channels_rates() When it fails midway, it cleans up the memory it has already allocated. So the error handling needs to skip freeing the memory. There is a second problem. ath11k_mac_setup_channels_rates(), allocates 3 channels. err_free misses releasing ar->mac.sbands[NL80211_BAND_6GHZ].channels Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200906212625.17059-1-trix@redhat.com |
/linux-master/drivers/platform/x86/ | ||
H A D | Kconfig | diff 06469a8d Tue Aug 29 07:37:48 MDT 2023 Vadim Pasternak <vadimp@nvidia.com> platform/x86: mlx-platform: Add dependency on PCI to Kconfig Add dependency on PCI to avoid 'mlx-platform' compilation error in case CONFIG_PCI is not set. Failed on i386: CONFIG_ACPI=y CONFIG_ISA=y Error In function 'mlxplat_pci_fpga_device_init': implicit declaration of function 'pci_request_region': 6204 | err = pci_request_region(pci_dev, 0, res_name); | ^~~~~~~~~~~~~~~~~~ | pci_request_regions Fixes: 1316e0af2dc0 ("platform: mellanox: mlx-platform: Introduce ACPI init flow") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Reported-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20230829133748.58208-2-vadimp@nvidia.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> |
Completed in 1227 milliseconds