aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-07-03iommu/vt-d: Handle volatile descriptor status readJacob Pan1-1/+1
Queued invalidation wait descriptor status is volatile in that IOMMU hardware writes the data upon completion. Use READ_ONCE() to prevent compiler optimizations which ensures memory reads every time. As a side effect, READ_ONCE() also enforces strict types and may add an extra instruction. But it should not have negative performance impact since we use cpu_relax anyway and the extra time(by adding an instruction) may allow IOMMU HW request cacheline ownership easier. e.g. gcc 12.3 BEFORE: 81 38 ad de 00 00 cmpl $0x2,(%rax) AFTER (with READ_ONCE()) 772f: 8b 00 mov (%rax),%eax 7731: 3d ad de 00 00 cmp $0x2,%eax //status data is 32 bit Signed-off-by: Jacob Pan <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Yi Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-07-03MAINTAINERS: Mobileye: add OLB drivers and dt-bindingsThéo Lebrun1-0/+5
Register OLB-related files part of the "MOBILEYE MIPS SOCS" MAINTAINERS section. Those include: - drivers (clk-eyeq, reset-eyeq, pinctrl-eyeq5), - dt-bindings (mobileye,eyeq5-olb.yaml file), - bindings includes file <dt-bindings/clock/mobileye,eyeq5-clk.h>. Signed-off-by: Théo Lebrun <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-07-03MIPS: mobileye: eyeq5: add OLB system-controller nodeThéo Lebrun3-39/+162
The OLB ("Other Logic Block") is a system-controller region hosting clock, reset and pin controllers. It contains registers such as I2C speed mode that need to be accessible by other nodes. Remove fixed-clocks previously used; replace references. Add parent crystal clock, fixed at 30MHz. Add pin nodes for all functions. Add mobileye,eyeq5-olb compatible node, hosting clk, reset and pinctrl. Add reset and pinctrl references to UART nodes. Signed-off-by: Théo Lebrun <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-07-03dt-bindings: soc: mobileye: add EyeQ OLB system controllerThéo Lebrun1-0/+374
Add documentation to describe the "Other Logic Block" system-controller. It deals with three platforms: EyeQ5, EyeQ6L and EyeQ6H. First two have a single instance, whereas EyeQ6H has seven named instances. Features provided are: - Clocks, children to main crystal. Some PLLs and divider clocks. - Resets. Some instances DO NOT have reset. - Pinctrl. Only EyeQ5 has such feature. Those are NOT the only features exposed in OLB system-controllers! Many individual registers, related to IP block integration, can be found. Additional features will be exposed over time. We simplify devicetree phandles to OLB in two ways: - Compatibles exposing a single clock do not ask for a index argument. This means we use EyeQ6H OLB south (it has four clocks): clocks = <&olb_south EQ6HC_SOUTH_PLL_PER>; But use EyeQ6H OLB east (it has one clock): clocks = <&olb_east>; - Compatibles exposing a single reset domain do not ask for a domain index, only a reset index. This means we use EyeQ5 OLB (it has three domains): resets = <&olb 0 10>; But use EyeQ6H west reset (it has one domain): resets = <&olb_west 3>; About pinctrl subnodes: all pins have two functionality, either GPIO or something-else. The latter is pin dependent, we express constraints using many if-then. Reviewed-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Théo Lebrun <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-07-03MIPS: Alchemy: switch to use software nodes for GPIOsDmitry Torokhov1-38/+42
Switch to use software nodes/properties to describe GPIOs for the ADS7846 touchscreen and the SPI controller (away from using GPIO lookup tables). This allows removing use of ADS7846 platform data, which will be going away. Signed-off-by: Dmitry Torokhov <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-07-03um: Enable preemption in UMLAnton Ivanov3-2/+3
Since userspace state is saved in the MM process, kernel using FPU still doesn't really need to do anything, so this really is as simple as enabling preemption. The irq critical section in sigio_handler() needs preempt_disable()/preempt_enable(). Signed-off-by: Anton Ivanov <[email protected]> Link: https://patch.msgid.link/20240702102549.d2fcea450854.I12f5a53d80ec1e425e66ef272b1e95cb523b608e@changeid [rebase, remove FPU save/restore, fix x86/um Makefile, rewrite commit message] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: refactor TLB update handlingBenjamin Berg9-132/+110
Conceptually, we want the memory mappings to always be up to date and represent whatever is in the TLB. To ensure that, we need to sync them over in the userspace case and for the kernel we need to process the mappings. The kernel will call flush_tlb_* if page table entries that were valid before become invalid. Unfortunately, this is not the case if entries are added. As such, change both flush_tlb_* and set_ptes to track the memory range that has to be synchronized. For the kernel, we need to execute a flush_tlb_kern_* immediately but we can wait for the first page fault in case of set_ptes. For userspace in contrast we only store that a range of memory needs to be synced and do so whenever we switch to that process. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: simplify and consolidate TLB updatesBenjamin Berg3-317/+99
The HVC update was mostly used to compress consecutive calls into one. This is mostly relevant for userspace where it is already handled by the syscall stub code. Simplify the whole logic and consolidate it for both kernel and userspace. This does remove the sequential syscall compression for the kernel, however that shouldn't be the main factor in most runs. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: remove force_flush_all from fork_handlerBenjamin Berg3-33/+15
There should be no need for this. It may be that this used to work around another issue where after a clone the MM was in a bad state. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: Do not flush MM in flush_threadBenjamin Berg2-5/+24
There should be no need to flush the memory in flush_thread. Doing this likely worked around some issue where memory was still incorrectly mapped when creating or cloning an MM. With the removal of the special clone path, that isn't relevant anymore. However, add the flush into MM initialization so that any new userspace MM is guaranteed to be clean. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: Delay flushing syscalls until the thread is restartedBenjamin Berg7-42/+49
As running the syscalls is expensive due to context switches, we should do so as late as possible in case more syscalls need to be queued later on. This will also benefit a later move to a SECCOMP enabled userspace as in that case the need for extra context switches is removed entirely. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: remove copy_context_skas0Benjamin Berg9-229/+10
The kernel flushes the memory ranges anyway for CoW and does not assume that the userspace process has anything set up already. So, start with a fresh process for the new mm context. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: remove LDT supportBenjamin Berg9-477/+10
The current LDT code has a few issues that mean it should be redone in a different way once we always start with a fresh MM even when cloning. In a new and better world, the kernel would just ensure its own LDT is clear at startup. At that point, all that is needed is a simple function to populate the LDT from another MM in arch_dup_mmap combined with some tracking of the installed LDT entries for each MM. Note that the old implementation was even incorrect with regard to reading, as it copied out the LDT entries in the internal format rather than converting them to the userspace structure. Removal should be fine as the LDT is not used for thread-local storage anymore. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: compress memory related stub syscalls while adding themBenjamin Berg1-0/+39
To keep the number of syscalls that the stub has to do lower, compress two consecutive syscalls of the same type if the second is just a continuation of the first. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: Rework syscall handlingBenjamin Berg16-297/+274
Rework syscall handling to be platform independent. Also create a clean split between queueing of syscalls and flushing them out, removing the need to keep state in the code that triggers the syscalls. The code adds syscall_data_len to the global mm_id structure. This will be used later to allow surrounding code to track whether syscalls still need to run and if errors occurred. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: Add generic stub_syscall6 functionBenjamin Berg2-0/+38
This function will be used by the new syscall handling code. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: Create signal stack memory assignment in stub_dataBenjamin Berg5-8/+24
When we switch to use seccomp, we need both the signal stack and other data (i.e. syscall information) to co-exist in the stub data. To facilitate this, start by defining separate memory areas for the stack and syscall data. This moves the signal stack onto a new page as the memory area is not sufficient to hold both signal stack and syscall information. Only change the signal stack setup for now, as the syscall code will be reworked later. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: Remove stub-data.h include from common-offsets.hBenjamin Berg3-11/+8
Further commits will require values from common-offsets.h inside stub-data.h. Resolve the possible circular dependency and simply use offsetof() inside stub_32.h and stub_64.h. Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: time-travel: fix signal blocking race/hangJohannes Berg1-20/+98
When signals are hard-blocked in order to do time-travel socket processing, we set signals_blocked and then handle SIGIO signals by setting the SIGIO bit in signals_pending. When unblocking, we first set signals_blocked to 0, and then handle all pending signals. We have to set it first, so that we can again properly block/unblock inside the unblock, if the time-travel handlers need to be processed. Unfortunately, this is racy. We can get into this situation: // signals_pending = SIGIO_MASK unblock_signals_hard() signals_blocked = 0; if (signals_pending && signals_enabled) { block_signals(); unblock_signals() ... sig_handler_common(SIGIO, NULL, NULL); sigio_handler() ... sigio_reg_handler() irq_do_timetravel_handler() reg->timetravel_handler() == vu_req_interrupt_comm_handler() vu_req_read_message() vhost_user_recv_req() vhost_user_recv() vhost_user_recv_header() // reads 12 bytes header of // 20 bytes message <-- receive SIGIO here <-- sig_handler() int enabled = signals_enabled; // 1 if ((signals_blocked || !enabled) && (sig == SIGIO)) { if (!signals_blocked && time_travel_mode == TT_MODE_EXTERNAL) sigio_run_timetravel_handlers() _sigio_handler() sigio_reg_handler() ... as above ... vhost_user_recv_header() // reads 8 bytes that were message payload // as if it were header - but aborts since // it then gets -EAGAIN ... --> end signal handler --> // continue in vhost_user_recv() // full_read() for 8 bytes payload busy loops // entire process hangs here Conceptually, to fix this, we need to ensure that the signal handler cannot run while we hard-unblock signals. The thing that makes this more complex is that we can be doing hard-block/unblock while unblocking. Introduce a new signals_blocked_pending variable that we can keep at non-zero as long as pending signals are being processed, then we only need to ensure it's decremented safely and the signal handler will only increment it if it's already non-zero (or signals_blocked is set, of course.) Note also that only the outermost call to hard-unblock is allowed to decrement signals_blocked_pending, since it could otherwise reach zero in an inner call, and leave the same race happening if the timetravel_handler loops, but that's basically required of it. Fixes: d6b399a0e02a ("um: time-travel/signals: fix ndelay() in interrupt") Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-07-03um: time-travel: remove time_exit()Johannes Berg1-6/+0
This function is unused and unneeded, remove it. Link: https://patch.msgid.link/20240703130105.02b3a974acb7.I7264821f7cfa17ea713b7a3e4787aa41a3107d01@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-07-03drm/display/dsc: Add a helper to dump the DSC configurationImre Deak2-0/+94
Add a helper to dump the Display Stream Compression configuration, taken into use in the i915 driver by a later patch. v2: - Rebase on the s/DRM_X16/FXP_Q4 change. - s/DSC configration/DSC configuration in the function documentation. Acked-by: Jani Nikula <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-03drm: Add helpers for q4 fixed point valuesImre Deak2-2/+26
Add helpers to convert between q4 fixed point and integer/fraction values. Also add the format/argument macros required to printk q4 fixed point variables. The q4 notation is based on the short variant described by https://en.wikipedia.org/wiki/Q_(number_format) where only the number of fraction bits in the fixed point value are defined, while the full size is deducted from the container type, that is the size of int for these helpers. Using the fxp_ prefix, which makes moving these helpers outside of drm to a more generic place easier, if they prove to be useful. These are needed by later patches dumping the Display Stream Compression configuration in DRM core and in the i915 driver to replace the corresponding bpp_x16 helpers defined locally in the driver. v2: Use the more generic/descriptive fxp_q4 prefix instead of drm_x16. (Jani) Cc: Jani Nikula <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-03fuse: Convert to new uid/gid option parsing helpersEric Sandeen1-8/+4
Convert to new uid/gid option parsing helpers Signed-off-by: Eric Sandeen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Christian Brauner <[email protected]> Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
2024-07-03fuse: verify {g,u}id mount options correctlyEric Sandeen1-4/+20
As was done in 0200679fc795 ("tmpfs: verify {g,u}id mount options correctly") we need to validate that the requested uid and/or gid is representable in the filesystem's idmapping. Cribbing from the above commit log, The contract for {g,u}id mount options and {g,u}id values in general set from userspace has always been that they are translated according to the caller's idmapping. In so far, fuse has been doing the correct thing. But since fuse is mountable in unprivileged contexts it is also necessary to verify that the resulting {k,g}uid is representable in the namespace of the superblock. Fixes: c30da2e981a7 ("fuse: convert to use the new mount API") Cc: [email protected] # 5.4+ Signed-off-by: Eric Sandeen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Christian Brauner <[email protected]> Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
2024-07-03MIPS: sync-r4k: Rework based on x86 tsc_syncJiaxun Yang3-86/+202
The original sync-r4k did a good job on reducing jitter by determine the "next time value", but it has a limitation that when synchronization being performed too many times due to high core count or CPU hotplug, the timewrap on CPU0 will become unaccpetable. Rework the mechanism based on latest x86 tsc_sync. (It seems like the original implementation is based on tsc_sync at that time, so it's just a refresh.) To improve overall performance. Tesed on Loongson64, Boston, QEMU. Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-07-03MIPS: csrc-r4k: Don't register as sched_clock if unfitJiaxun Yang1-3/+14
When we have more than one CPU in system, counter synchronisation overhead can lead to a scenario that sched_clock goes backward when being read from different CPUs. This is accommodated by CONFIG_HAVE_UNSTABLE_SCHED_CLOCK, but it's unavailable on 32bit kernel. We don't want to risk sched_clock correctness, so if we have multiple CPU in system and CONFIG_HAVE_UNSTABLE_SCHED_CLOCK is not set, we just don't use counter as sched_clock source. Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-07-03MIPS: csrc-r4k: Select HAVE_UNSTABLE_SCHED_CLOCK if SMP && 64BITJiaxun Yang1-0/+1
csrc-r4k suffers from SMP synchronization overhead. Select HAVE_UNSTABLE_SCHED_CLOCK to workaround drift between the CPUs on the system. HAVE_UNSTABLE_SCHED_CLOCK requires cmpxchg64, so enable it for 64 bits only. Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-07-03iommu/arm-smmu-v3: Enable HTTU for stage1 with io-pgtable mappingKunkun Jiang4-1/+23
If io-pgtable quirk flag indicates support for hardware update of dirty state, enable HA/HD bits in the SMMU CD and also set the DBM bit in the page descriptor. Now report the dirty page tracking capability of SMMUv3 and select IOMMUFD_DRIVER for ARM_SMMU_V3 if IOMMUFD is enabled. Co-developed-by: Keqian Zhu <[email protected]> Signed-off-by: Keqian Zhu <[email protected]> Signed-off-by: Kunkun Jiang <[email protected]> Signed-off-by: Joao Martins <[email protected]> Reviewed-by: Ryan Roberts <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Signed-off-by: Shameer Kolothum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-07-03iommu/arm-smmu-v3: Add support for dirty tracking in domain allocJoao Martins3-23/+67
This provides all the infrastructure to enable dirty tracking if the hardware has the capability and domain alloc request for it. Also, add a device_iommu_capable() check in iommufd core for IOMMU_CAP_DIRTY_TRACKING before we request a user domain with dirty tracking support. Please note, we still report no support for IOMMU_CAP_DIRTY_TRACKING as it will finally be enabled in a subsequent patch. Signed-off-by: Joao Martins <[email protected]> Reviewed-by: Ryan Roberts <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Signed-off-by: Shameer Kolothum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-07-03iommu/io-pgtable-arm: Add read_and_clear_dirty() supportShameer Kolothum1-2/+112
.read_and_clear_dirty() IOMMU domain op takes care of reading the dirty bits (i.e. PTE has DBM set and AP[2] clear) and marshalling into a bitmap of a given page size. While reading the dirty bits we also set the PTE AP[2] bit to mark it as writeable-clean depending on read_and_clear_dirty() flags. PTE states with respect to DBM bit: DBM bit AP[2]("RDONLY" bit) 1. writable_clean 1 1 2. writable_dirty 1 0 3. read-only 0 1 Reviewed-by: Ryan Roberts <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Signed-off-by: Shameer Kolothum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-07-03iommu/arm-smmu-v3: Add feature detection for HTTUJean-Philippe Brucker2-0/+37
If the SMMU supports it and the kernel was built with HTTU support, Probe support for Hardware Translation Table Update (HTTU) which is essentially to enable hardware update of access and dirty flags. Probe and set the smmu::features for Hardware Dirty and Hardware Access bits. This is in preparation, to enable it on the context descriptors of stage 1 format. Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Joao Martins <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Ryan Roberts <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Signed-off-by: Shameer Kolothum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-07-03iommu/arm-smmu-v3: Add support for domain_alloc_user fnShameer Kolothum1-2/+31
This will be used by iommufd for allocating usr managed domains and is also required when we add support for iommufd based dirty tracking support. Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Signed-off-by: Shameer Kolothum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-07-03MIPS: csrc-r4k: Apply verification clocksource flagsJiaxun Yang1-1/+3
CP0 counter suffers from various problems like SMP sync, behaviour on wait. Set CLOCK_SOURCE_MUST_VERIFY and CLOCK_SOURCE_VERIFY_PERCPU, as what x86 did to TSC, to let kernel test it before use. Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-07-03MIPS: csrc-r4k: Refine rating computationJiaxun Yang1-1/+2
Increase frequency addend dividend to 10000000 (10MHz) to reasonably accommodate multi GHz level mips_hpt_frequency. Cap rating of csrc-r4k into 299 to ensure it doesn't go into "Desired" range, given all the drama we have with CP0 count registers (SMP sync, behaviour on wait etc). Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2024-07-03parport: Remove parport_driver.devmodelDr. David Alan Gilbert24-27/+0
'devmodel' hasn't actually been used since: 'commit 3275158fa52a ("parport: remove use of devmodel")' and everyone now has it set to true and has been fixed up; remove the flag. (There are still comments all over about it) Signed-off-by: Dr. David Alan Gilbert <[email protected]> Acked-by: Sudip Mukherjee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03parport: Remove attach function pointerDr. David Alan Gilbert1-1/+0
The attach function pointers haven't actually been called since: 'commit 3275158fa52a ("parport: remove use of devmodel")' topped adding entries to the drivers list. If you're converting a driver, look at the 'match_port' function pointer instead. (There are lots of comment references to 'attach' all over, but they probably need some deeper understanding to check the semantics to see if they can be replaced by match_port). Signed-off-by: Dr. David Alan Gilbert <[email protected]> Acked-by: Sudip Mukherjee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03parport: Remove 'drivers' listDr. David Alan Gilbert2-10/+0
The list has been empty since: 'commit 3275158fa52a ("parport: remove use of devmodel")' This also means we can remove the 'list_head' from struct parport_driver. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Acked-by: Sudip Mukherjee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03mcb: remove unused struct 'mcb_parse_priv'Dr. David Alan Gilbert1-5/+0
'mcb_parse_priv' has been unused since the initial commit 3764e82e5150 ("drivers: Introduce MEN Chameleon Bus"). Remove it. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Signed-off-by: Johannes Thumshirn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03misc: Drop explicit initialization of struct i2c_device_id::driver_data to 0Uwe Kleine-König9-10/+10
These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. While add it, also remove commas after the sentinel entries. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03bsr: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
With ARCH=powerpc, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/bsr.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03platform/goldfish: goldfish_pipe: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
With arch=x86, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/platform/goldfish/goldfish_pipe.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03dca: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
With ARCH=x86, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dca/dca.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03greybus: add missing MODULE_DESCRIPTION() macrosJeff Johnson2-0/+2
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/greybus/greybus.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/greybus/gb-es2.o Add all missing invocations of the MODULE_DESCRIPTION() macro. Acked-by: Alex Elder <[email protected]> Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03intel_th: msu-sink: add missing MODULE_DESCRIPTION()Jeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hwtracing/intel_th/intel_th_msu_sink.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03dsp56k: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
With ARCH=m68k, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/dsp56k.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/20240617-md-m68k-drivers-char-dsp56k-v1-1-56e435ffa664@quicinc.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03dtlk: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
With ARCH=m68k, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/dtlk.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03misc: ti-st: st_kim: use 'time_left' variable with ↵Wolfram Sang1-4/+4
wait_for_completion_interruptible_timeout() There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_interruptible_timeout() causing patterns like: timeout = wait_for_completion_interruptible_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03misc: tifm: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang1-3/+3
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03misc: bh1770glc: use 'time_left' variable with ↵Wolfram Sang1-5/+5
wait_event_interruptible_timeout() There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_event_interruptible_timeout() causing patterns like: timeout = wait_event_interruptible_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-03misc: apds990x: use 'time_left' variable with wait_event_interruptible_timeout()Wolfram Sang1-5/+5
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_event_interruptible_timeout() causing patterns like: timeout = wait_event_interruptible_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>