aboutsummaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2023-04-04asm-generic: avoid __generic_cmpxchg_local warningsArnd Bergmann3-11/+11
Code that passes a 32-bit constant into cmpxchg() produces a harmless sparse warning because of the truncation in the branch that is not taken: fs/erofs/zdata.c: note: in included file (through /home/arnd/arm-soc/arch/arm/include/asm/cmpxchg.h, /home/arnd/arm-soc/arch/arm/include/asm/atomic.h, /home/arnd/arm-soc/include/linux/atomic.h, ...): include/asm-generic/cmpxchg-local.h:29:33: warning: cast truncates bits from constant value (5f0ecafe becomes fe) include/asm-generic/cmpxchg-local.h:33:34: warning: cast truncates bits from constant value (5f0ecafe becomes cafe) include/asm-generic/cmpxchg-local.h:29:33: warning: cast truncates bits from constant value (5f0ecafe becomes fe) include/asm-generic/cmpxchg-local.h:30:42: warning: cast truncates bits from constant value (5f0edead becomes ad) include/asm-generic/cmpxchg-local.h:33:34: warning: cast truncates bits from constant value (5f0ecafe becomes cafe) include/asm-generic/cmpxchg-local.h:34:44: warning: cast truncates bits from constant value (5f0edead becomes dead) This was reported as a regression to Matt's recent __generic_cmpxchg_local patch, though this patch only added more warnings on top of the ones that were already there. Rewording the truncation to use an explicit bitmask instead of a cast to a smaller type avoids the warning but otherwise leaves the code unchanged. I had another look at why the cast is even needed for atomic_cmpxchg(), and as Matt describes the problem here is that atomic_t contains a signed 'int', but cmpxchg() takes an 'unsigned long' argument, and converting between the two leads to a 64-bit sign-extension of negative 32-bit atomics. I checked the other implementations of arch_cmpxchg() and did not find any others that run into the same problem as __generic_cmpxchg_local(), but it's easy to be on the safe side here and always convert the signed int into an unsigned int when calling arch_cmpxchg(), as this will work even when any of the arch_cmpxchg() implementations run into the same problem. Fixes: 624654152284 ("locking/atomic: cmpxchg: Make __generic_cmpxchg_local compare against zero-extended 'old' value") Reviewed-by: Matt Evans <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2023-04-04asm-generic/io.h: suppress endianness warnings for relaxed accessorsVladimir Oltean1-6/+6
Copy the forced type casts from the normal MMIO accessors to suppress the sparse warnings that point out __raw_readl() returns a native endian word (just like readl()). Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2023-04-04asm-generic/io.h: suppress endianness warnings for readq() and writeq()Vladimir Oltean1-2/+2
Commit c1d55d50139b ("asm-generic/io.h: Fix sparse warnings on big-endian architectures") missed fixing the 64-bit accessors. Arnd explains in the attached link why the casts are necessary, even if __raw_readq() and __raw_writeq() do not take endian-specific types. Link: https://lore.kernel.org/lkml/[email protected]/ Suggested-by: Arnd Bergmann <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2023-04-04PCI: Document pci_bus_for_each_resource()Andy Shevchenko1-0/+20
There might be confusion about why pci_bus_for_each_resource() uses Logical OR. Document the entire macro and explain how it works and why the conditional needs to be like that. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2023-04-04PCI: Introduce pci_dev_for_each_resource()Mika Westerberg1-0/+14
Instead of open-coding it everywhere introduce a tiny helper that can be used to iterate over each resource of a PCI device, and convert the most obvious users into it. While at it drop doubled empty line before pdev_sort_resources(). No functional changes intended. Suggested-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Krzysztof Wilczyński <[email protected]>
2023-04-04PCI: Introduce pci_resource_n()Andy Shevchenko1-8/+7
Introduce pci_resource_n() and replace open-coded implementations of it in pci.h. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
2023-04-04srcu: Move work-scheduling fields from srcu_struct to srcu_usagePaul E. McKenney1-4/+5
This commit moves the ->reschedule_jiffies, ->reschedule_count, and ->work fields from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. However, this means that the container_of() calls cannot get a pointer to the srcu_struct because they are no longer in the srcu_struct. This issue is addressed by adding a ->srcu_ssp field in the srcu_usage structure that references the corresponding srcu_struct structure. And given the presence of the sup pointer to the srcu_usage structure, replace some ssp->srcu_usage-> instances with sup->. [ paulmck Apply feedback from kernel test robot. ] Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Move srcu_barrier() fields from srcu_struct to srcu_usagePaul E. McKenney1-7/+7
This commit moves the ->srcu_barrier_seq, ->srcu_barrier_mutex, ->srcu_barrier_completion, and ->srcu_barrier_cpu_cnt fields from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Move ->sda_is_static from srcu_struct to srcu_usagePaul E. McKenney1-1/+1
This commit moves the ->sda_is_static field from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Move heuristics fields from srcu_struct to srcu_usagePaul E. McKenney1-3/+3
This commit moves the ->srcu_size_jiffies, ->srcu_n_lock_retries, and ->srcu_n_exp_nodelay fields from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Move grace-period fields from srcu_struct to srcu_usagePaul E. McKenney1-12/+13
This commit moves the ->srcu_gp_seq, ->srcu_gp_seq_needed, ->srcu_gp_seq_needed_exp, ->srcu_gp_start, and ->srcu_last_gp_end fields from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Move ->srcu_gp_mutex from srcu_struct to srcu_usagePaul E. McKenney1-1/+1
This commit moves the ->srcu_gp_mutex field from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Move ->lock from srcu_struct to srcu_usagePaul E. McKenney1-4/+7
This commit moves the ->lock field from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Move ->srcu_cb_mutex from srcu_struct to srcu_usagePaul E. McKenney1-1/+1
This commit moves the ->srcu_cb_mutex field from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Move ->srcu_size_state from srcu_struct to srcu_usagePaul E. McKenney1-1/+1
This commit moves the ->srcu_size_state field from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Move ->level from srcu_struct to srcu_usagePaul E. McKenney1-2/+2
This commit moves the ->level[] array from the srcu_struct structure to the srcu_usage structure to reduce the size of the former in order to improve cache locality. Suggested-by: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Begin offloading srcu_struct fields to srcu_updatePaul E. McKenney3-13/+25
The current srcu_struct structure is on the order of 200 bytes in size (depending on architecture and .config), which is much better than the old-style 26K bytes, but still all too inconvenient when one is trying to achieve good cache locality on a fastpath involving SRCU readers. However, only a few fields in srcu_struct are used by SRCU readers. The remaining fields could be offloaded to a new srcu_update structure, thus shrinking the srcu_struct structure down to a few tens of bytes. This commit begins this noble quest, a quest that is complicated by open-coded initialization of the srcu_struct within the srcu_notifier_head structure. This complication is addressed by updating the srcu_notifier_head structure's open coding, given that there does not appear to be a straightforward way of abstracting that initialization. This commit moves only the ->node pointer to srcu_update. Later commits will move additional fields. [ paulmck: Fold in [email protected]'s memory-leak fix. ] Link: https://lore.kernel.org/all/[email protected]/ Suggested-by: Christoph Hellwig <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: "Michał Mirosław" <[email protected]> Cc: Dmitry Osipenko <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Use static init for statically allocated in-module srcu_structPaul E. McKenney1-5/+14
Further shrinking the srcu_struct structure is eased by requiring that in-module srcu_struct structures rely more heavily on static initialization. In particular, this preserves the property that a module-load-time srcu_struct initialization can fail only due to memory-allocation failure of the per-CPU srcu_data structures. It might also slightly improve robustness by keeping the number of memory allocations that must succeed down percpu_alloc() call. This is in preparation for splitting an srcu_usage structure out of the srcu_struct structure. [ paulmck: Fold in [email protected] feedback. ] Cc: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04srcu: Add whitespace to __SRCU_STRUCT_INIT() & __DEFINE_SRCU()Paul E. McKenney1-14/+14
This is a whitespace-only commit with no change in functionality. Its purpose is to prepare for later commits that: (1) Cause statically allocated srcu_struct structures to rely on compile-time initialization and (2) Move fields from the srcu_struct structure to a new srcu_usage structure. Cc: Christoph Hellwig <[email protected]> Tested-by: Sachin Sant <[email protected]> Tested-by: "Zhang, Qiang1" <[email protected]> Tested-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2023-04-04io_uring/rsrc: add custom limit for node cachingPavel Begunkov1-0/+1
The number of entries in the rsrc node cache is limited to 512, which still seems unnecessarily large. Add per cache thresholds and set to to 32 for the rsrc node cache. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/d0cd538b944dac0bf878e276fc0199f21e6bccea.1680576071.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2023-04-04io_uring/rsrc: cache struct io_rsrc_nodePavel Begunkov1-0/+1
Add allocation cache for struct io_rsrc_node, it's always allocated and put under ->uring_lock, so it doesn't need any extra synchronisation around caches. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/252a9d9ef9654e6467af30fdc02f57c0118fb76e.1680576071.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2023-04-04io_uring/rsrc: don't offload node freePavel Begunkov1-3/+0
struct delayed_work rsrc_put_work was previously used to offload node freeing because io_rsrc_node_ref_zero() was previously called by RCU in the IRQ context. Now, as percpu refcounting is gone, we can do it eagerly at the spot without pushing it to a worker. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/13fb1aac1e8d068ad8fd4a0c6d0d157ab61b90c0.1680576071.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2023-04-04io_uring/rsrc: kill rsrc_ref_lockPavel Begunkov1-1/+1
We use ->rsrc_ref_lock spinlock to protect ->rsrc_ref_list in io_rsrc_node_ref_zero(). Now we removed pcpu refcounting, which means io_rsrc_node_ref_zero() is not executed from the irq context as an RCU callback anymore, and we also put it under ->uring_lock. io_rsrc_node_switch(), which queues up nodes into the list, is also protected by ->uring_lock, so we can safely get rid of ->rsrc_ref_lock. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/6b60af883c263551190b526a55ff2c9d5ae07141.1680576071.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2023-04-04io_uring/rsrc: keep cached refs per nodePavel Begunkov1-1/+0
We cache refs of the current node (i.e. ctx->rsrc_node) in ctx->rsrc_cached_refs. We'll be moving away from atomics, so move the cached refs in struct io_rsrc_node for now. It's a prep patch and shouldn't change anything in practise. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/9edc3669c1d71b06c2dca78b2b2b8bb9292738b9.1680576071.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2023-04-04virtio-blk: fix to match virtio specDmitry Fomichev1-9/+9
The merged patch series to support zoned block devices in virtio-blk is not the most up to date version. The merged patch can be found at https://lore.kernel.org/linux-block/[email protected]/ but the latest and reviewed version is https://lore.kernel.org/linux-block/[email protected]/ The reason is apparently that the correct mailing lists and maintainers were not copied. The differences between the two are mostly cleanups, but there is one change that is very important in terms of compatibility with the approved virtio-zbd specification. Before it was approved, the OASIS virtio spec had a change in VIRTIO_BLK_T_ZONE_APPEND request layout that is not reflected in the current virtio-blk driver code. In the running code, the status is the first byte of the in-header that is followed by some pad bytes and the u64 that carries the sector at which the data has been written to the zone back to the driver, aka the append sector. This layout turned out to be problematic for implementing in QEMU and the request status byte has been eventually made the last byte of the in-header. The current code doesn't expect that and this causes the append sector value always come as zero to the block layer. This needs to be fixed ASAP. Fixes: 95bfec41bd3d ("virtio-blk: add support for zoned block devices") Cc: [email protected] Signed-off-by: Dmitry Fomichev <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2023-04-04Merge branch 'iommufd/for-rc' into for-nextJason Gunthorpe48-73/+259
The following selftest patch requires both the bug fixes and the improvements of the selftest framework. * iommufd/for-rc: iommufd: Do not corrupt the pfn list when doing batch carry iommufd: Fix unpinning of pages when an access is present iommufd: Check for uptr overflow Linux 6.3-rc5 Signed-off-by: Jason Gunthorpe <[email protected]>
2023-04-04Merge tag 'renesas-drivers-for-v6.4-tag1' of ↵Arnd Bergmann1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers Renesas driver updates for v6.4 - Drop support for the obsolete R-Car H3 ES1.* (R8A77950) SoC, - Miscellaneous fixes and improvements. * tag 'renesas-drivers-for-v6.4-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: soc: renesas: Use "#ifdef" for single-symbol definition checks soc: renesas: pwc-rzv2m: drop of_match_ptr for ID table soc: renesas: mark OF related data as maybe unused soc: renesas: rmobile-sysc: Use of_fwnode_handle() helper soc: renesas: Remove r8a77950 arch soc: renesas: rcar-sysc: Remove R-Car H3 ES1.* handling Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2023-04-04gpu: host1x: Make host1x_client_unregister() return voidUwe Kleine-König1-1/+1
This function returned zero unconditionally. Make it return no value and simplify all callers accordingly. Signed-off-by: Uwe Kleine-König <[email protected]> Acked-by: Hans Verkuil <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2023-04-04ASoC: SOF: Add flag and state which will be used for DSP-less modePeter Ujfalusi1-0/+5
The DSPless mode of the ASoC/SOF driver can be used for hardware verification and debug on platforms with HDaudio codecs. The DSP mode is still needed on existing platforms for SSP, DMIC, SoundWire interfaces managed by the GP-DMA. This mode is also helpful to compare the legacy HDaudio driver with the ASoC/SOF driver wrt. codec management and handling. In theory we use the same code but differences are sometimes seen on jack detection and event handling. Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Rander Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-04-04mtd: spi-nor: Stop exporting spi_nor_restore()Tudor Ambarus1-6/+0
Some SPI NOR controllers that used this method were moved to drivers/spi/. We don't accept new support for the existing SPI NOR controllers drivers under drivers/mtd/spi-nor/controllers/ and we encourage their owners to move the drivers under drivers/spi/. Make spi_nor_restore() private as we're going to use it just in core.c. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tudor Ambarus <[email protected]>
2023-04-03tty: make tty_class a static const structureGreg Kroah-Hartman1-1/+1
Now that the driver core allows for struct class to be in read-only memory, move the tty_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: "Ilpo Järvinen" <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/2023040250-landowner-unfitted-11f4@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-04-03driver core: class: remove struct class_interface * from callbacksGreg Kroah-Hartman1-2/+2
The add_dev and remove_dev callbacks in struct class_interface currently pass in a pointer back to the class_interface structure that is calling them, but none of the callback implementations actually use this pointer as it is pointless (the structure is known, the driver passed it in in the first place if it is really needed again.) So clean this up and just remove the pointer from the callbacks and fix up all callback functions. Cc: Jean Delvare <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Kurt Schwemmer <[email protected]> Cc: Jon Mason <[email protected]> Cc: Dave Jiang <[email protected]> Cc: Allen Hubbe <[email protected]> Cc: Dominik Brodowski <[email protected]> Cc: Matt Porter <[email protected]> Cc: Alexandre Bounine <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: "Martin K. Petersen" <[email protected]> Cc: Doug Gilbert <[email protected]> Cc: John Stultz <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Wang Weiyang <[email protected]> Cc: Yang Yingliang <[email protected]> Cc: Jakob Koschel <[email protected]> Cc: Cai Xinchen <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Acked-by: Logan Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/2023040250-pushover-platter-509c@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-04-03driver core: class: mark the struct class in struct class_interface constantGreg Kroah-Hartman1-1/+1
The struct class pointer in struct class_interface is never modified, so mark it as const so that no one accidentally tries to modify it in the future. Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/2023040249-handball-gruffly-5da7@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-04-03driver core: class: make class_register() take a const *Greg Kroah-Hartman1-1/+1
Now that the class code is cleaned up to not modify the class pointer registered with it, change class_register() to take a const * to allow the structure to be placed into read-only memory. Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/2023040248-customary-release-4aec@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-04-03driver core: class: mark class_release() as taking a const *Greg Kroah-Hartman1-1/+1
The struct class callback, class_release(), is only called in 2 places, the pcmcia cardservices code, and in the class driver core code. Both places it is safe to mark the structure as a const *, to allow us to in the future mark all struct class usages as constant and move into read-only memory. Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/2023040248-outrage-obsolete-5a9a@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-04-03Merge tag 'thermal-v6.4-rc1-1' of ↵Rafael J. Wysocki2-287/+0
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux Pull thermal control material for 6.4-rc1 from Daniel Lezcano: "- Add more thermal zone device encapsulation: prevent setting structure field directly, access the sensor device instead the thermal zone's device for trace, relocate the traces in drivers/thermal (Daniel Lezcano) - Use the generic trip point for the i.MX and remove the get_trip_temp ops (Daniel Lezcano) - Use the devm_platform_ioremap_resource() in the Hisilicon driver (Yang Li) - Remove R-Car H3 ES1.* handling as public has only access to the ES2 version and the upstream support for the ES1 has been shutdown (Wolfram Sang) - Add a delay after initializing the bank in order to let the time to the hardware to initialze itself before reading the temperature (Amjad Ouled-Ameur) - Add MT8365 support (Amjad Ouled-Ameur)" * tag 'thermal-v6.4-rc1-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux: thermal/drivers/ti: Use fixed update interval thermal/drivers/stm: Don't set no_hwmon to false thermal/drivers/db8500: Use driver dev instead of tz->device thermal/core: Relocate the traces definition in thermal directory thermal/drivers/hisi: Use devm_platform_ioremap_resource() thermal/drivers/imx: Use the thermal framework for the trip point thermal/drivers/imx: Remove get_trip_temp ops thermal/drivers/rcar_gen3_thermal: Remove R-Car H3 ES1.* handling thermal/drivers/mediatek: Add delay after thermal banks initialization thermal/drivers/mediatek: Add support for MT8365 SoC thermal/drivers/mediatek: Control buffer enablement tweaks dt-bindings: thermal: mediatek: Add binding documentation for MT8365 SoC
2023-04-03mtd: spinand: add support for ESMT F50x1G41LBChuanhong Guo1-0/+1
This patch adds support for ESMT F50L1G41LB and F50D1G41LB. It seems that ESMT likes to use random JEDEC ID from other vendors. Their 1G chips uses 0xc8 from GigaDevice and 2G/4G chips uses 0x2c from Micron. For this reason, the ESMT entry is named esmt_c8 with explicit JEDEC ID in variable name. Datasheets: https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50L1G41LB(2M).pdf https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50D1G41LB(2M).pdf Signed-off-by: Chuanhong Guo <[email protected]> Signed-off-by: Martin Kurbanov <[email protected]> Signed-off-by: Dmitry Rokosov <[email protected]> Tested-by: Martin Kurbanov <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2023-04-03tracing: Error if a trace event has an array for a __field()Steven Rostedt (Google)1-4/+17
A __field() in the TRACE_EVENT() macro is used to set up the fields of the trace event data. It is for single storage units (word, char, int, pointer, etc) and not for complex structures or arrays. Unfortunately, there's nothing preventing the build from accepting: __field(int, arr[5]); from building. It will turn into a array value. This use to work fine, as the offset and size use to be determined by the macro using the field name, but things have changed and the offset and size are now determined by the type. So the above would only be size 4, and the next field will be located 4 bytes from it (instead of 20). The proper way to declare static arrays is to use the __array() macro. Instead of __field(int, arr[5]) it should be __array(int, arr, 5). Add some macro tricks to the building of a trace event from the TRACE_EVENT() macro such that __field(int, arr[5]) will fail to build. A comment by the failure will explain why the build failed. Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Reported-by: Douglas RAILLARD <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]>
2023-04-03ftrace: Mark get_lock_parent_ip() __always_inlineJohn Keeping1-1/+1
If the compiler decides not to inline this function then preemption tracing will always show an IP inside the preemption disabling path and never the function actually calling preempt_{enable,disable}. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: [email protected] Fixes: f904f58263e1d ("sched/debug: Fix preempt_disable_ip recording for preempt_disable()") Signed-off-by: John Keeping <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2023-04-03io_uring: rename trace_io_uring_submit_sqe() tracepointJens Axboe1-9/+6
It has nothing to do with the SQE at this point, it's a request submission. While in there, get rid of the 'force_nonblock' argument which is also dead, as we only pass in true. Signed-off-by: Jens Axboe <[email protected]>
2023-04-03io_uring: encapsulate task_work statePavel Begunkov1-1/+6
For task works we're passing around a bool pointer for whether the current ring is locked or not, let's wrap it in a structure, that will make it more opaque preventing abuse and will also help us to pass more info in the future if needed. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/1ecec9483d58696e248d1bfd52cf62b04442df1d.1679931367.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2023-04-03io_uring: kill unused notif declarationsPavel Begunkov1-13/+0
There are two leftover structures from the notification registration mechanism that has never been released, kill them. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/f05f65aebaf8b1b5bf28519a8fdb350e3e7c9ad0.1679924536.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2023-04-03io_uring: Add KASAN support for alloc_cachesBreno Leitao1-0/+1
Add support for KASAN in the alloc_caches (apoll and netmsg_cache). Thus, if something touches the unused caches, it will raise a KASAN warning/exception. It poisons the object when the object is put to the cache, and unpoisons it when the object is gotten or freed. Signed-off-by: Breno Leitao <[email protected]> Reviewed-by: Gabriel Krisman Bertazi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-04-03io_uring: Move from hlist to io_wq_work_nodeBreno Leitao1-1/+1
Having cache entries linked using the hlist format brings no benefit, and also requires an unnecessary extra pointer address per cache entry. Use the internal io_wq_work_node single-linked list for the internal alloc caches (async_msghdr and async_poll) This is required to be able to use KASAN on cache entries, since we do not need to touch unused (and poisoned) cache entries when adding more entries to the list. Suggested-by: Pavel Begunkov <[email protected]> Signed-off-by: Breno Leitao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-04-03io_uring: add support for user mapped provided buffer ringJens Axboe1-0/+17
The ring mapped provided buffer rings rely on the application allocating the memory for the ring, and then the kernel will map it. This generally works fine, but runs into issues on some architectures where we need to be able to ensure that the kernel and application virtual address for the ring play nicely together. This at least impacts architectures that set SHM_COLOUR, but potentially also anyone setting SHMLBA. To use this variant of ring provided buffers, the application need not allocate any memory for the ring. Instead the kernel will do so, and the allocation must subsequently call mmap(2) on the ring with the offset set to: IORING_OFF_PBUF_RING | (bgid << IORING_OFF_PBUF_SHIFT) to get a virtual address for the buffer ring. Normally the application would allocate a suitable piece of memory (and correctly aligned) and simply pass that in via io_uring_buf_reg.ring_addr and the kernel would map it. Outside of the setup differences, the kernel allocate + user mapped provided buffer ring works exactly the same. Acked-by: Helge Deller <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2023-04-03io_uring/kbuf: rename struct io_uring_buf_reg 'pad' to'flags'Jens Axboe1-1/+1
In preparation for allowing flags to be set for registration, rename the padding and use it for that. Acked-by: Helge Deller <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2023-04-03fs: add FMODE_DIO_PARALLEL_WRITE flagJens Axboe1-0/+3
Some filesystems support multiple threads writing to the same file with O_DIRECT without requiring exclusive access to it. io_uring can use this hint to avoid serializing dio writes to this inode, instead allowing them to run in parallel. XFS and ext4 both fall into this category, so set the flag for both of them. Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2023-04-03drm/vram-helper: turn on PRIME import/exportSimon Ser1-1/+3
We don't populate drm_driver.gem_prime_import_sg_table so only DMA-BUFs exported from our own device can be imported. We don't populate drm_gem_object_funcs.get_sg_table so DMA-BUFs cannot be imported into another device. Still, this is useful to user-space to share buffers between processes and between API boundaries (e.g. wlroots hard-requires PRIME import/export support). v2: expand commit message Signed-off-by: Simon Ser <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Tian Tao <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Hans de Goede <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-04-03regmap: Add maple tree based register cacheMark Brown1-0/+1
The current state of the art for sparse register maps is the rbtree cache. This works well for most applications but isn't always ideal for sparser register maps since the rbtree can get deep, requiring a lot of walking. Fortunately the kernel has a data structure intended to address this very problem, the maple tree. Provide an initial implementation of a register cache based on the maple tree to start taking advantage of it. The entries stored in the maple tree are arrays of register values, with the maple tree keys holding the register addresses. We store data in host native format rather than device native format as we do for rbtree, this will be a benefit for devices where we don't marshal data within regmap and simplifies the code but will result in additional CPU overhead when syncing the cache on devices where we do marshal data in regmap. This should work well for a lot of devices, though there's some additional areas that could be looked at such as caching the last accessed entry like we do for rbtree and trying to minimise the maple tree level locking. We should also use bulk writes rather than single register writes when resyncing the cache where possible, even if we don't store in device native format. Very small register maps may continue to to better with rbtree longer term. Signed-off-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-04-03USB: core: Add API to change the wireless_statusBastien Nocera1-0/+5
This adds the API that allows device specific drivers to tell user-space about whether the wireless device is connected to its receiver dongle. See "USB: core: Add wireless_status sysfs attribute" for a detailed explanation of what this attribute should be used for. Signed-off-by: Bastien Nocera <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>