summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-05-06Revert "firewire: core: option to log bus reset initiation"Takashi Sakamoto
This reverts commit 6732491243045f5a7e1995b4be5f3c964b579ebd. The former commit adds some alternative tracepoints events to replace the reverted kernel log messages. Link: https://lore.kernel.org/r/20240501073238.72769-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: add tracepoints events for initiating bus resetTakashi Sakamoto
At a commit 673249124304 ("firewire: core: option to log bus reset initiation"), some kernel log messages were added to trace initiation of bus reset. The kernel log messages are really helpful, while nowadays it is not preferable just for debugging purpose. For the purpose, Linux kernel tracepoints is more preferable. This commit adds some alternative tracepoints events. Link: https://lore.kernel.org/r/20240501073238.72769-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: obsolete OHCI_PARAM_DEBUG_BUSRESETS from debug module parameterTakashi Sakamoto
The OHCI_PARAM_DEBUG_BUSRESETS bit of debug module parameter was added at a commit a007bb857e0b ("firewire: fw-ohci: conditionally log busReset interrupts"). At the former commit, the bit becomes less meaningful, just to skip logging. This commit obsoletes it. Link: https://lore.kernel.org/r/20240501073238.72769-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: add bus-reset event for initial set of handled irqTakashi Sakamoto
In the former commits, the spurious interrupt events are suppressed as possible, by unset bus-reset event from the set of handled irq. The change was written with the less-intrusive style, thus it firstly works at the second time to handle the event. But it is slightly inconvenient. This commit adds the event for the initial set of irq to handle. As a result, the event can be handled even if it is the first time. The change has a benefit that the OHCI_PARAM_DEBUG_BUSRESETS bit in debug module parameter is always effective. Tested-by: Adam Goldman <adamg@pobox.com> Link: https://lore.kernel.org/r/20240501073238.72769-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: add tracepoints event for asynchronous inbound phy packetTakashi Sakamoto
At the former commit, a pair of tracepoints events is added to trace asynchronous outbound phy packet. This commit adds a tracepoints event to trace inbound phy packet. It includes transaction status as well as the content of phy packet. This is an example for Remote Reply Packet as a response to Remote Access Packet sent by lsfirewirephy command in linux-firewire-utils: async_phy_inbound: \ packet=0xffff955fc02b4e10 generation=1 status=1 timestamp=0x0619 \ first_quadlet=0x001c8208 second_quadlet=0xffe37df7 Link: https://lore.kernel.org/r/20240430001404.734657-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core/cdev: add tracepoints events for asynchronous phy packetTakashi Sakamoto
In IEEE 1394 bus, the type of asynchronous packet without any offset to node address space is called as phy packet. The destination of packet is IEEE 1394 phy itself. This type of packet is used for several purposes, mainly for selfID at the state of bus reset, to force selection of root node, and to adjust gap count. This commit adds tracepoints events for the type of asynchronous outbound packet. Like asynchronous outbound transaction packets, a pair of events are added to trace initiation and completion of transmission. In the case that the phy packet is sent by kernel API, the match between the initiation and completion is not so easy, since the data of 'struct fw_packet' is allocated statically. In the case that it is sent by userspace applications via cdev, the match is easy, since the data is allocated per each. This example is for Remote Access Packet by lsfirewirephy command in linux-firewire-utils: async_phy_outbound_initiate: \ packet=0xffff89fb34e42e78 generation=1 first_quadlet=0x00148200 \ second_quadlet=0xffeb7dff async_phy_outbound_complete: \ packet=0xffff89fb34e42e78 generation=1 status=1 timestamp=0x0619 Link: https://lore.kernel.org/r/20240430001404.734657-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: add tracepoints events for asynchronous outbound responseTakashi Sakamoto
In a view of core transaction service, the asynchronous outbound response consists of two stages; initiation and completion. This commit adds a pair of events for the asynchronous outbound response. The following example is for asynchronous write quadlet request as IEC 61883-1 FCP response to node 0xffc1. async_response_outbound_initiate: \ transaction=0xffff89fa08cf16c0 generation=4 scode=2 dst_id=0xffc1 \ tlabel=25 tcode=2 src_id=0xffc0 rcode=0 \ header={0xffc16420,0xffc00000,0x0,0x0} data={} async_response_outbound_complete: \ transaction=0xffff89fa08cf16c0 generation=4 scode=2 status=1 \ timestamp=0x0000 Link: https://lore.kernel.org/r/20240429043218.609398-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: add tracepoint event for asynchronous inbound requestTakashi Sakamoto
This commit adds an event for asynchronous inbound request. The following example is for asynchronous block write request as IEC 61883-1 FCP request from node 0xffc1. async_request_inbound: \ transaction=0xffff89fa08cf16c0 generation=4 scode=2 status=2 \ timestamp=0x00b3 dst_id=0xffc0 tlabel=19 tcode=1 src_id=0xffc1 \ offset=0xfffff0000d00 header={0xffc04d10,0xffc1ffff,0xf0000d00,0x80000} \ data={0x19ff08,0xffff0090} Link: https://lore.kernel.org/r/20240429043218.609398-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: add tracepoints event for asynchronous inbound responseTakashi Sakamoto
In the transaction of IEEE 1394, the node to receive the asynchronous request transfers any response packet to the requester except for the unified transaction. This commit adds an event for the inbound packet. Note that the code to decode the packet header is moved, against the note about the sanity check. The following example is for asynchronous lock response with compare_and_swap code. async_response_inbound: \ transaction=0xffff955fc6a07a10 generation=5 scode=2 status=1 \ timestamp=0x0089 dst_id=0xffc1 tlabel=54 tcode=11 src_id=0xffc0 \ rcode=0 header={0xffc1d9b0,0xffc00000,0x0,0x40002} data={0x50800080} Link: https://lore.kernel.org/r/20240429043218.609398-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: add tracepoints events for asynchronous outbound requestTakashi Sakamoto
In a view of core transaction service, the asynchronous outbound request consists of two stages; initiation and completion. This commit adds a pair of event for them. The following example is for asynchronous lock request with compare_swap code to offset 0x'ffff'f000'0904 in node 0xffc0. async_request_outbound_initiate: \ transaction=0xffff955fc6a07a10 generation=5 scode=2 dst_id=0xffc0 \ tlabel=54 tcode=9 src_id=0xffc1 offset=0xfffff0000904 \ header={0xffc0d990,0xffc1ffff,0xf0000904,0x80002} data={0x80,0x940181} async_request_outbound_complete: \ transaction=0xffff955fc6a07a10 generation=5 scode=2 status=2 \ timestamp=0xd887 Link: https://lore.kernel.org/r/20240429043218.609398-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: add support for Linux kernel tracepointsTakashi Sakamoto
The Linux Kernel Tracepoints framework is enough useful to trace packet data inbound to and outbound from core. This commit adds firewire subsystem to use the framework. Link: https://lore.kernel.org/r/20240429043218.609398-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: replace local macros with common inline functions for ↵Takashi Sakamoto
isochronous packet header This commit replaces the local macros with the common inline functions to serialize the packer header for Asynchronous Streaming Packet. Link: https://lore.kernel.org/r/20240428071347.409202-9-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: add common macro to serialize/deserialize isochronous packet ↵Takashi Sakamoto
header The packet for Asynchronous Streaming Packet includes the same header fields as the isochronous packet has. It is helpful to have some helper functions to serialize/deserialize them. This commit adds such helper functions with their test. Link: https://lore.kernel.org/r/20240428071347.409202-8-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: obsolete tcode check macros with inline functionsTakashi Sakamoto
This commit declares the helper functions to check tcode to obsolete the functional macros. Link: https://lore.kernel.org/r/20240428071347.409202-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: replace hard-coded values with common macrosTakashi Sakamoto
In the helper function for logging in 1394 ohci driver includes the hard-coded variables for transaction code. They can be replaced with the enumerations in UAPI header. Link: https://lore.kernel.org/r/20240428071347.409202-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: replace hard-coded values with inline functions for ↵Takashi Sakamoto
asynchronous packet header This commit replaces the hard-coded values with the common inline functions to serialize and deserialize the header of asynchronous packet. Link: https://lore.kernel.org/r/20240428071347.409202-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: replace local macros with common inline functions for ↵Takashi Sakamoto
asynchronous packet header This commit uses the common inline functions to serialize and deserialize header of asynchronous packet. Link: https://lore.kernel.org/r/20240428071347.409202-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: replace local macros with common inline functions for ↵Takashi Sakamoto
asynchronous packet header This commit uses common inline functions to serialize and deserialize header of asynchronous packet. Link: https://lore.kernel.org/r/20240428071347.409202-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: add common inline functions to serialize/deserialize ↵Takashi Sakamoto
asynchronous packet header In both core and 1394 OHCI driver, some hard-coded values and macros are used to serialize/deserialize the header of asynchronous packets. It is inconvenient to reuse them. This commit adds some helper inline functions with their tests for the purpose. Link: https://lore.kernel.org/r/20240428071347.409202-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: use pci_irq_vector() to retrieve allocated interrupt lineTakashi Sakamoto
The pci_irq_vector() is available to retrieve the allocated interrupt line instead of the direct access to the member of device structure. Link: https://lore.kernel.org/r/20240331135037.191479-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: obsolete usage of deprecated API for MSITakashi Sakamoto
The usage of the pair of pci_enable_msi() and pci_disable_msi() is deprecated. This commit uses the preferred pair of API for the purpose. The call of pci_alloc_irq_vectors() can have a subeffect to change the return value of pci_dev_msi_enabled(). Link: https://lore.kernel.org/r/20240331135037.191479-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: replace request_irq() with request_threaded_irq()Takashi Sakamoto
Nowadays request_irq() is a wrapper of request_threaded_irq(). The IRQ handler of 1394 ohci driver has never been optimized yet, while it is a good preparation for the future work to replace the latter. This commit replaces the former. Link: https://lore.kernel.org/r/20240331135037.191479-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06Revert "firewire: ohci: use devres for requested IRQ"Takashi Sakamoto
This reverts commit 5a95f1ded28691e69f7d6718c5dcbc149613d431. As long as allocating any device interrupt vector for MSI, it is inconvenient to utilize managed device resources for IRQ requesting. Link: https://lore.kernel.org/r/20240331135037.191479-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: option to log bus reset initiationAdam Goldman
Add a debug parameter to firewire-core, analogous to the one in firewire-ohci. When this is set to 1, log when we schedule, delay, or initiate a bus reset. Since FireWire bus resets can originate from any node on the bus, specific logging of the resets we initiate provides additional insight. Signed-off-by: Adam Goldman <adamg@pobox.com> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06spi: pxa2xx: Drop linux/spi/pxa2xx_spi.hMark Brown
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>: As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of its content is being used solely internally to SPI subsystem (PXA2xx drivers). Hence this refactoring series with the additional win of getting rid of legacy documentation. Note, that we have the only user of a single plain integer field in the entire kernel for that. Switching to software nodes does not diminish any of type checking as we only pass an integer.
2024-05-06spi: dw: Auto-detect number of native CSMark Brown
Merge series from Serge Semin <fancer.lancer@gmail.com>: The main goal of the short series is to provide a procedure implementing the auto-detection of the number of native Chip-Select signals supported by the controller. The suggested algorithm is straightforward. It relies on the fact that the SER register writable flags reflects the actual number of available native chip-select signals. So the DW APB/AHB SSI driver now tests the SER register for having the writable bits, calculates the number of CS signals based on the number of set flags and then initializes the num_cs private data field based on that, which then will be passed to the SPI-core subsystem indicating the number of supported hardware chip-selects. The implemented procedure will be useful for the DW SSI device nodes not having the explicitly set "num-cs" property. In case if the property is specified it will be utilized instead of the auto-detection procedure. Besides of that a small cleanup patch is introduced in the head of the series. It converts the driver to using the BITS_TO_BYTES() macro instead of the hard-coded DIV_ROUND_UP()-based calculation of the number of bytes-per-transfer-word.
2024-05-06regulator: new API for voltage reference suppliesMark Brown
Merge series from David Lechner <dlechner@baylibre.com>: In the IIO subsystem, we noticed a pattern in many drivers where we need to get, enable and get the voltage of a supply that provides a reference voltage. In these cases, we only need the voltage and not a handle to the regulator. Another common pattern is for chips to have an internal reference voltage that is used when an external reference is not available. There are also a few drivers outside of IIO that do the same. So we would like to propose a new regulator consumer API to handle these specific cases to avoid repeating the same boilerplate code in multiple drivers. As an example of how these functions are used, I have included a few patches to consumer drivers. But to avoid a giant patch bomb, I have omitted the iio/adc and iio/dac patches I have prepared from this series. I will send those separately but these will add 36 more users of devm_regulator_get_enable_read_voltage() in addition to the 6 here. In total, this will eliminate nearly 1000 lines of similar code and will simplify writing and reviewing new drivers in the future.
2024-05-05mm: pass VMA instead of MM to follow_pte()David Hildenbrand
... and centralize the VM_IO/VM_PFNMAP sanity check in there. We'll now also perform these sanity checks for direct follow_pte() invocations. For generic_access_phys(), we might now check multiple times: nothing to worry about, really. Link: https://lkml.kernel.org/r/20240410155527.474777-3-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Acked-by: Sean Christopherson <seanjc@google.com> [KVM] Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Fei Li <fei1.li@intel.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Yonghua Huang <yonghua.huang@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-05drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()David Hildenbrand
Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes". Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks. Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VM_PAT that ends up using follow_pte(). This patch (of 3): We currently miss handling various cases, resulting in a dangerous follow_pte() (previously follow_pfn()) usage. (1) We're not checking PTE write permissions. Maybe we should simply always require pte_write() like we do for pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for ACRN_MEM_ACCESS_WRITE for now. (2) We're not rejecting refcounted pages. As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. Let's make sure to reject them. (3) We are only looking at the first PTE of a bigger range. We only lookup a single PTE, but memmap->len may span a larger area. Let's loop over all involved PTEs and make sure the PFN range is actually contiguous. Reject everything else: it couldn't have worked either way, and rather made use access PFNs we shouldn't be accessing. Link: https://lkml.kernel.org/r/20240410155527.474777-1-david@redhat.com Link: https://lkml.kernel.org/r/20240410155527.474777-2-david@redhat.com Fixes: 8a6e85f75a83 ("virt: acrn: obtain pa from VMA with PFNMAP flag") Signed-off-by: David Hildenbrand <david@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Fei Li <fei1.li@intel.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Yonghua Huang <yonghua.huang@intel.com> Cc: Sean Christopherson <seanjc@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-05memory tier: dax/kmem: introduce an abstract layer for finding, allocating, ↵Ho-Ren (Jack) Chuang
and putting memory types Patch series "Improved Memory Tier Creation for CPUless NUMA Nodes", v11. When a memory device, such as CXL1.1 type3 memory, is emulated as normal memory (E820_TYPE_RAM), the memory device is indistinguishable from normal DRAM in terms of memory tiering with the current implementation. The current memory tiering assigns all detected normal memory nodes to the same DRAM tier. This results in normal memory devices with different attributions being unable to be assigned to the correct memory tier, leading to the inability to migrate pages between different types of memory. https://lore.kernel.org/linux-mm/PH0PR08MB7955E9F08CCB64F23963B5C3A860A@PH0PR08MB7955.namprd08.prod.outlook.com/T/ This patchset automatically resolves the issues. It delays the initialization of memory tiers for CPUless NUMA nodes until they obtain HMAT information and after all devices are initialized at boot time, eliminating the need for user intervention. If no HMAT is specified, it falls back to using `default_dram_type`. Example usecase: We have CXL memory on the host, and we create VMs with a new system memory device backed by host CXL memory. We inject CXL memory performance attributes through QEMU, and the guest now sees memory nodes with performance attributes in HMAT. With this change, we enable the guest kernel to construct the correct memory tiering for the memory nodes. This patch (of 2): Since different memory devices require finding, allocating, and putting memory types, these common steps are abstracted in this patch, enhancing the scalability and conciseness of the code. Link: https://lkml.kernel.org/r/20240405000707.2670063-1-horenchuang@bytedance.com Link: https://lkml.kernel.org/r/20240405000707.2670063-2-horenchuang@bytedance.com Signed-off-by: Ho-Ren (Jack) Chuang <horenchuang@bytedance.com> Reviewed-by: "Huang, Ying" <ying.huang@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawie.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Gregory Price <gourry.memverge@gmail.com> Cc: Hao Xiang <hao.xiang@bytedance.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Ravi Jonnalagadda <ravis.opensrc@micron.com> Cc: SeongJae Park <sj@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-06i2c: designware: Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()Andy Shevchenko
As Krzysztof Kozlowski pointed out the better is to use MODULE_DEVICE_TABLE() as it will be consistent with the content of the real ID table of the platform devices. While at it, drop unneeded and unused module alias in PCI glue driver as PCI already has its own ID table and automatic loading should just work. Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20231120144641.1660574-9-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: pxa: use 'time_left' variable with wait_event_timeout()Wolfram Sang
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_event_timeout() causing patterns like: timeout = wait_event_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 <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: s3c2410: use 'time_left' variable with wait_event_timeout()Wolfram Sang
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_event_timeout() causing patterns like: timeout = wait_event_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Fix to the proper variable type 'long' while here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: rk3x: use 'time_left' variable with wait_event_timeout()Wolfram Sang
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_event_timeout() causing patterns like: timeout = wait_event_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Fix to the proper variable type 'long' while here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: qcom-geni: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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. Fix to the proper variable type 'unsigned long' while here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: jz4780: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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. Fix to the proper variable type 'unsigned long' while here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: synquacer: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: stm32f7: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: stm32f4: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: st: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: omap: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: imx-lpi2c: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: hix5hd2: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: exynos5: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: digicolor: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Acked-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: amd-mp2-plat: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang
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 <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: ali15x3: remove printout on handled timeoutsWolfram Sang
I2C and SMBus timeouts are not something the user needs to be informed about on controller level. The client driver may know if that really is a problem and give more detailed information to the user. The controller should just pass this information upwards. Remove the printout. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: ali1563: remove printout on handled timeoutsWolfram Sang
I2C and SMBus timeouts are not something the user needs to be informed about on controller level. The client driver may know if that really is a problem and give more detailed information to the user. The controller should just pass this information upwards. Remove the printout. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: ali1535: remove printout on handled timeoutsWolfram Sang
I2C and SMBus timeouts are not something the user needs to be informed about on controller level. The client driver may know if that really is a problem and give more detailed information to the user. The controller should just pass this information upwards. Remove the printout. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-05-06i2c: i801: remove printout on handled timeoutsWolfram Sang
I2C and SMBus timeouts are not something the user needs to be informed about on controller level. The client driver may know if that really is a problem and give more detailed information to the user. The controller should just pass this information upwards. Remove the printout and turn the SMBus-specific termination message to debug. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>