Searched hist:6204 (Results 1 - 17 of 17) sorted by relevance

/linux-master/drivers/gpu/drm/etnaviv/
H A Detnaviv_hwdb.cdiff 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 Dkmsan_test.cdiff 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 Dqeth_l3_sys.cdiff 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 Dqeth_core.hdiff 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 Dqeth_l3_main.cdiff 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 Dbcm63xx_uart.cdiff 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 Dcache.hdiff 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 Dutil.hdiff 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 DBuilddiff 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 Dextent_map.hdiff 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 Dextent_map.cdiff 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 Dfile.cdiff 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 Dimx8mp.dtsidiff 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 Dimx8mp.dtsidiff 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 DKconfigdiff 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 Dmac.cdiff 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 DKconfigdiff 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