aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2023-06-19mmc: mmci: Retry the busy start conditionLinus Walleij1-12/+27
This makes the ux500 ->busy_complete() callback re-read the status register 10 times while waiting for the busy signal to assert in the status register. If this does not happen, we bail out regarding the command completed already, i.e. before we managed to start to check the busy status. There is a comment in the code about this, let's just implement it to be certain that we can catch this glitch if it happens. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2023-06-19mmc: mmci: Make busy complete state machine explicitLinus Walleij2-18/+45
This refactors the ->busy_complete() callback currently only used by Ux500 and STM32 to handle busy detection on hardware where one and the same IRQ is fired whether we get a start or an end signal on busy detect. The code is currently using the cached status from the command IRQ in ->busy_status as a state to select what to do next: if this state is non-zero we are waiting for IRQs and if it is zero we treat the state as the starting point for a busy detect wait cycle. Make this explicit by creating a state machine where the ->busy_complete callback moves between three states. The Ux500 busy detect code currently assumes this order: we enable the busy detect IRQ, get a busy start IRQ, then a busy end IRQ, and then we clear and mask this IRQ and proceed. We insert debug prints for unexpected states. This works as before on most cards, however on a problematic card that is not working with busy detect, and which I have been debugging, the following happens a lot: [ 3.380554] mmci-pl18x 80005000.mmc: no busy signalling in time [ 3.387420] mmci-pl18x 80005000.mmc: no busy signalling in time [ 3.394561] mmci-pl18x 80005000.mmc: lost busy status when waiting for busy start IRQ This probably means that the busy detect start IRQ has already occurred when we start executing the ->busy_complete() callbacks, and the busy detect end IRQ is counted as the start IRQ, and this is what is causing the card to not be detected properly. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2023-06-19mmc: mmci: Break out error check in busy detectLinus Walleij1-1/+10
The busy detect callback for Ux500 checks for an error in the status in the first if() clause. The only practical reason is that if an error occurs, the if()-clause is not executed, and the code falls through to the last if()-clause if (host->busy_status) which will clear and disable the irq. Make this explicit instead: it is easier to read. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2023-06-19mmc: mmci: Stash status while waiting for busyLinus Walleij1-0/+1
Some interesting flags can arrive while we are waiting for the first busy detect IRQ so OR then onto the stashed flags so they are not missed. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2023-06-19mmc: mmci: Unwind big if() clauseLinus Walleij1-7/+26
This does two things: firsr replace the hard-to-read long if-expression: if (!host->busy_status && !(status & err_msk) && (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) { With the more readable: if (!host->busy_status && !(status & err_msk)) { status = readl(base + MMCISTATUS); if (status & host->variant->busy_detect_flag) { Second notice that the re-read MMCISTATUS register is now stored into the status variable, using logic OR because what if something else changed too? While we are at it, explain what the function is doing. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2023-06-19mmc: mmci: Clear busy_status when starting commandLinus Walleij1-0/+1
If we are starting a command which can generate a busy response, then clear the variable host->busy_status if the variant is using a ->busy_complete callback. We are lucky that the member is zero by default and hopefully always gets cleared in the ->busy_complete callback even on errors, but it's just fragile so make sure it is always initialized to zero. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2023-06-19EDAC/amd64: Cache and use GPU node mapYazen Ghannam2-0/+77
AMD systems have historically provided an "AMD Node ID" that is a unique identifier for each die in a multi-die package. This was associated with a unique instance of the AMD Northbridge on a legacy system. And now it is associated with a unique instance of the AMD Data Fabric on modern systems. Each instance is referred to as a "Node"; this is an AMD-specific term not to be confused with NUMA nodes. The data fabric provides a number of interfaces accessible through a set of functions in a single PCI device. There is one PCI device per Data Fabric (AMD Node), and multi-die systems will see multiple such PCI devices. The AMD Node ID matches a Node's position in the PCI hierarchy. For example, the Node 0 is accessed using the first PCI device, Node 1 is accessed using the second, and so on. A logical CPU can find its AMD Node ID using CPUID. Furthermore, the AMD Node ID is used within the hardware fabric, so it is not purely a logical value. Heterogeneous AMD systems, with a CPU Data Fabric connected to GPU data fabrics, follow a similar convention. Each CPU and GPU die has a unique AMD Node ID value, and each Node ID corresponds to PCI devices in sequential order. However, there are two caveats: 1) GPUs are not x86, and they don't have CPUID to read their AMD Node ID like on CPUs. This means the value is more implicit and based on PCI enumeration and hardware-specifics. 2) There is a gap in the hardware values for AMD Node IDs. Values 0-7 are for CPUs and values 8-15 are for GPUs. For example, a system with one CPU die and two GPUs dies will have the following values: CPU0 -> AMD Node 0 GPU0 -> AMD Node 8 GPU1 -> AMD Node 9 EDAC is the only subsystem where this has a practical effect. Memory errors on AMD systems are commonly reported through MCA to a CPU on the local AMD Node. The error information is passed along to EDAC where the AMD EDAC modules use the AMD Node ID of reporting logical CPU to access AMD Node information. However, memory errors from a GPU die will be reported to the CPU die. Therefore, the logical CPU's AMD Node ID can't be used since it won't match the AMD Node ID of the GPU die. The AMD Node ID of the GPU die is provided as part of the MCA information, and the value will match the hardware enumeration (e.g. 8-15). Handle this situation by discovering GPU dies the same way as CPU dies in the AMD NB code. But do a "node id" fixup in AMD64 EDAC where it's needed. The GPU data fabrics provide a register with the base AMD Node ID for their local "type", i.e. GPU data fabric. This value is the same for all fabrics of the same type in a system. Read and cache the base AMD Node ID from one of the GPU devices during module initialization. Use this to fixup the "node id" when reporting memory errors at runtime. [ bp: Squash a fix making gpu_node_map static as reported by Tom Rix <[email protected]>. Link: https://lore.kernel.org/r/[email protected] ] Signed-off-by: Yazen Ghannam <[email protected]> Co-developed-by: Muralidhara M K <[email protected]> Signed-off-by: Muralidhara M K <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-06-19wifi: cfg80211: make TDLS management link-awareMukesh Sisodiya1-4/+4
For multi-link operation(MLO) TDLS management frames need to be transmitted on a specific link. The TDLS setup request will add BSSID along with peer address and userspace will pass the link-id based on BSSID value to the driver(or mac80211). Signed-off-by: Mukesh Sisodiya <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230616094948.cb3d87c22812.Ia3d15ac4a9a182145bf2d418bcb3ddf4539cd0a7@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: bump FW API to 81 for AX devicesGregory Greenman1-2/+2
Start supporting API version 81 for AX devices. Signed-off-by: Gregory Greenman <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230615094410.e61fdc474d89.I3d9823231fa7fc47158b8aa3561b43822c8c86cd@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: Add support for SCAN API version 16Ilan Peer2-21/+48
Scan API version 16 use link ID for reporting the TSF of scan results (instead of MAC ID used in previous versions). Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230615094410.05bf3e612297.Ie3075f7068af38c335d26778ab7d0ec4b1c026c3@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: Don't access vif valid links directlyIlan Peer3-4/+4
And instead use the vif getter functions, as a preparation for supporting disabled/dormant links. Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230615094410.61ca688cbbf1.Ic1b4049cf156238ff16e6c57959004da911cb5c8@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: handle eSR transitionsMiri Korenblit5-33/+155
There several transitions to handle in eSR mode: * SMPS should be disabled when in eSR mode * indicate to the fw whether the new added link should use the listen lmac or the main lmac * RLC is offloaded when in eSR mode; adjust RLC command accordingly Signed-off-by: Miri Korenblit <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230615094410.fb6409f44aca.I502460dec15e0b76035ad3cd809afa4ac16e9fe1@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: fix max number of fw active linksMiri Korenblit3-22/+24
The max active links that are supported by the FW is hard coded. This is wrong since this value is HW-dependent. Fix this by determining according to the actual HW. Also remove a redundant check that the number of active links doesn't exceeds the maximum. Signed-off-by: Miri Korenblit <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230615094410.e78ad74c6715.I68b26911c0a312d72eaf25344b448d03b1c61f4e@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: add a few rate index validity checksAnjaneyulu2-7/+13
Validate index before access iwl_rate_mcs to keep rate->index inside the valid boundaries. Use MCS_0_INDEX if index is less than MCS_0_INDEX and MCS_9_INDEX if index is greater then MCS_9_INDEX. Signed-off-by: Anjaneyulu <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123447.79f16b3aef32.If1137f894775d6d07b78cbf3a6163ffce6399507@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: Validate slots_num before allocating memoryAnjaneyulu1-1/+4
Verify slots_num is valid in iwl_txq_alloc() Signed-off-by: Anjaneyulu <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123447.90be48017c1b.I880e451e137c5cd688d5f38b573b0dbf352762b3@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: Validate tid is in valid range before using itAnjaneyulu2-6/+13
Validate tid is less then MAX TID when it is used to access corresponding arrays. Signed-off-by: Anjaneyulu <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123447.cea75e1f57e7.I03bc0a81d2c1bdbf4784c12c4c62b8538892ccba@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: track u-APSD misbehaving AP by AP addressJohannes Berg3-17/+26
If the AP is an AP MLD, then we shouldn't track just the BSSID but the MLD address. Just generally use ap_addr since it has the BSSID in the non-MLD case. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123447.b6a4f7edd10c.Ie5a8029ed686b9441620ba06596d430432f65559@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: implement WPFC ACPI table loadingJohannes Berg6-51/+65
We skipped this in the past, but now we will need it for some platforms. Implement loading the PHY filter configuration IDs from the WPFC ACPI table. Note that the firmware must also be aware of the right filter configuration IDs (they're just the IDs of a filter configuration, not the actual configuration). Remove the useless hardcoded zeroes while at it. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123447.035026ea3169.I3a1fc1fe644fefa0d818ee1926c5fc331d68e8a3@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: pcie: fix NULL pointer dereference in ↵Anjaneyulu1-2/+3
iwl_pcie_irq_rx_msix_handler() rxq can be NULL only when trans_pcie->rxq is NULL and entry->entry is zero. For the case when entry->entry is not equal to 0, rxq won't be NULL even if trans_pcie->rxq is NULL. Modify checker to check for trans_pcie->rxq. Fixes: abc599efa67b ("iwlwifi: pcie: don't crash when rx queues aren't allocated in interrupt") Signed-off-by: Anjaneyulu <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.5a5eb3889a4a.I375a1d58f16b48cd2044e7b7caddae512d7c86fd@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: add some FW misbehaviour check infrastructureJohannes Berg4-9/+36
When the firmware misbehaves (according to the driver), we often either ignore that, or WARN_ON, which is very noisy but doesn't really help. Add a little helper macro IWL_FW_CHECK() that can be used in place of WARN_ON() in conditions, and make it take a message that's printed in this case. We can also add more behaviour to this in the future. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.2e12ac670cea.Ia0198036b7a626876d836bd41a4b2d2b1e65c5ca@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: always send spec link ID in link commandsJohannes Berg1-0/+2
The firmware technically only needs this when the link is newly added, but it's much easier for debugging if it's always available, so include it. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.daecd0e626f7.I0f8a16a6d80a283c9f947c9bb0fc50a7c6853948@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: use array as array argumentJohannes Berg2-2/+2
When calling iwl_mvm_set_fw_qos_params() we explicitly pass a pointer to the first array element, but the function will treat it as an array. Simplify and clarify the code and pass the array instead. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.6fb4a9743b1b.I801007d207f6539a9e0996366ec593e2038b1f90@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: store WMM params per linkJohannes Berg2-6/+15
We have the data structure set up to store the parameters per link, but weren't using them. Fix that and store them in the right link. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.332c4949a1be.Icae03975d578b0cc82279911a1ea7cbc313046d6@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: check link during TXJohannes Berg1-1/+3
Again, during some (botched) FW restart scenarios we can end up with a NULL link in the driver but mac80211 thinking all is still going OK. If we try to TX at the same time, we can crash there. Fix that by checking for a NULL link during TX. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.cee48479deec.I4eef58f7b67afafb7b3294adbeb6e0067b68419d@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: add a NULL pointer checkJohannes Berg2-2/+12
We've observed that in some botched firmware restart scenarios when the firmware crashes again while we're reconfiguring, we can hit NULL pointer crashes here. The underlying issue is the botched restart which we need to fix separately, but until we can do that, don't crash hard here. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.e47b0192c78f.I67fa9f07cd1c8b3bdc8db25f5e31c1c680c49745@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: fw: Add new FSEQ defines to fw dumpAriel Malamud2-2/+10
On fw error dump, dmesg prints FSEQ register data. Add 4 additional prints in order to match those being dumped by Windows driver. Allows fw infra to correctly detect version mismatch. Signed-off-by: Ariel Malamud <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.f40dc9c810a8.I26227900d0b7e9a71fefe5cbf57cf6b46ee44413@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: pcie: double-check ACK interrupt after timeoutJohannes Berg1-4/+9
There are evidently cases where the firmware completes the reset but the interrupt isn't received correctly, so check for the interrupt again after the timeout, and don't dump the firmware error log if the right bit is set. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.00cc2d9b88c3.I429bfe800f17c624e50c0b0c10dd2cd7d885f199@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: pull from TXQs with softirqs disabledJohannes Berg1-1/+4
In mac80211, it's required that we pull from TXQs by calling ieee80211_tx_dequeue() only with softirqs disabled. However, in iwl_mvm_queue_state_change() we're often called with them enabled, e.g. from flush if anything was flushed, triggering a mac80211 warning. Fix that by disabling the softirqs across the TX call. Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.0feef7fa81db.I4dd62542d955b40dd8f0af34fa4accb9d0d17c7e@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: use iwl_mvm_is_vendor_in_approved_list()Johannes Berg1-1/+1
We have this helper now instead of open-coding the check for the dmi_tas_approved_list, so use it even here. It was added for debugfs use, but it's better to be consistent. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.f3741f5cdef4.I5e0bf522189dc595ee38d05e93994211d32ec0f4@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: fw: make some ACPI functions staticJohannes Berg2-40/+19
iwl_acpi_get_wifi_pkg_range(), iwl_acpi_get_wifi_pkg() and iwl_acpi_get_object() need not be exported etc., they're used only within the same file. Make them static. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.e866032e4106.Ifede7f7c25b17a8215b154ce01da513b75384325@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: Correctly indicate support for VHT TX STBCIlan Peer1-2/+2
If HT STBC is not supported, do not indicate support for VHT TX STBC. Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.b24b5fba6fab.I116617875eb4a9d520df23a8c49a6594f9d8b2c6@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: correctly access HE/EHT sband capaJohannes Berg1-20/+26
We can't just dereference the sband->iftype_data pointer, that's an array so we need to access the right entry. Use the previously introduced helper functions to do that. There are also cases, e.g. when loading with disable_11ax=1, where the pointer might be NULL but we still attempt to use it, causing a crash. Fixes: 529281bdf0fc ("iwlwifi: mvm: limit TLC according to our HE capabilities") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614123446.a1f2b17ee39b.I8808120be744be8804815ce9e3e24ce6d2b424e3@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: Add NULL check before dereferencing the pointerMukesh Sisodiya1-6/+8
While vif pointers are protected by the corresponding "*active" fields, static checkers can get confused sometimes. Add an explicit check. Signed-off-by: Mukesh Sisodiya <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614154951.78749ae91fb5.Id3c05d13eeee6638f0930f750e93fb928d5c9dee@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-06-19wifi: iwlwifi: mvm: remove new checksum codeJohannes Berg4-84/+7
The hardware isn't going to get fixed, so this mode cannot work in the foreseeable future. Remove it. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230614145722.ddbc16c4affe.Ia6921e4b8a9624d4f57489ac775105ed0e400313@changeid [restore original subject] Signed-off-by: Johannes Berg <[email protected]>
2023-06-19Merge wireless into wireless-nextJohannes Berg1-6/+6
There are some locking changes that will later otherwise cause conflicts, so merge wireless into wireless-next to avoid those. Signed-off-by: Johannes Berg <[email protected]>
2023-06-19Merge tag 'mlx5-fixes-2023-06-16' of ↵David S. Miller15-36/+163
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-fixes-2023-06-16 This series provides bug fixes to mlx5 driver. Please pull and let me know if there is any problem. ==================== Signed-off-by: David S. Miller <[email protected]>
2023-06-19drivers: meson: secure-pwrc: always enable DMA domainAlexey Romanov1-1/+1
Starting from commit e45f243409db ("firmware: meson_sm: populate platform devices from sm device tree data") pwrc is probed successfully and disables unused pwr domains. By A1 SoC family design, any TEE requires DMA pwr domain always enabled. Fixes: b3dde5013e13 ("soc: amlogic: Add support for Secure power domains controller") Signed-off-by: Alexey Romanov <[email protected]> Acked-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] [narmstrong: added fixes tag] Signed-off-by: Neil Armstrong <[email protected]>
2023-06-19net: qca_spi: Avoid high load if QCA7000 is not availableStefan Wahren1-2/+1
In case the QCA7000 is not available via SPI (e.g. in reset), the driver will cause a high load. The reason for this is that the synchronization is never finished and schedule() is never called. Since the synchronization is not timing critical, it's safe to drop this from the scheduling condition. Signed-off-by: Stefan Wahren <[email protected]> Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000") Signed-off-by: David S. Miller <[email protected]>
2023-06-19ARM: 9298/1: Drop custom mdesc->handle_irq()Linus Walleij1-0/+1
ARM exclusively uses GENERIC_IRQ_MULTI_HANDLER, so at some point set_handle_irq() needs to be called to handle system-wide interrupts. For all DT-enabled boards, this call happens down in the drivers/irqchip subsystem, after locating the target irqchip driver from the device tree. We still have a few instances of the boardfiles with machine descriptors passing a machine-specific .handle_irq() to the ARM kernel core. Get rid of this by letting the few remaining machines consistently call set_handle_irq() from the end of the .init_irq() callback instead and diet down one member from the machine descriptor. Cc: Marc Zyngier <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
2023-06-19mtd: otp: clean up on error in mtd_otp_nvmem_add()Dan Carpenter1-3/+5
Smatch complains that these error paths are missing cleanup: drivers/mtd/mtdcore.c:983 mtd_otp_nvmem_add() warn: missing unwind goto? This needs to call nvmem_unregister(mtd->otp_user_nvmem) before returning. Fixes: 3b270fac8443 ("mtd: otp: Put factory OTP/NVRAM into the entropy pool") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2023-06-19mtd: maps: pismo: Switch back to use i2c_driver's .probe()Uwe Kleine-König1-1/+1
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2023-06-19mtd: rawnand: macronix: OTP access for MX30LFxG18ACArseniy Krasnov1-0/+167
Support for OTP area access on MX30LFxG18AC chip series. Signed-off-by: Arseniy Krasnov <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2023-06-19mtd: rawnand: meson: fix unaligned DMA buffers handlingArseniy Krasnov1-0/+4
Meson NAND controller requires 8 bytes alignment for DMA addresses, otherwise it "aligns" passed address by itself thus accessing invalid location in the provided buffer. This patch makes unaligned buffers to be reallocated to become valid. Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Cc: <[email protected]> Signed-off-by: Arseniy Krasnov <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2023-06-19mtd: rawnand: add support for the Sandisk SDTNQGAMA chipJohan Jonker1-0/+3
Sandisk SDTNQGAMA is a 8GB size, 3.3V 8 bit chip with 16KB page size, 1KB write size and 40 bit ecc support Co-developed-by: Paweł Jarosz <[email protected]> Signed-off-by: Paweł Jarosz <[email protected]> Signed-off-by: Johan Jonker <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2023-06-19mtd: rawnand: add basic sandisk manufacturer opsJohan Jonker4-1/+29
Add basic Sandisk manufacturer ops support to get SDTNQGAMA timing data with the nand_get_sdr_timings() function. Signed-off-by: Johan Jonker <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2023-06-19Merge branches 'iommu/fixes', 'arm/smmu', 'ppc/pamu', 'virtio', 'x86/vt-d', ↵Joerg Roedel15-609/+697
'core' and 'x86/amd' into next
2023-06-19fbdev: hitfb: Use NULL for pointersThomas Zimmermann1-2/+2
Replace integer constants with NULL. Resolves the following warnings: ../drivers/video/fbdev/hitfb.c:447:23: warning: Using plain integer as NULL pointer ../drivers/video/fbdev/hitfb.c:465:23: warning: Using plain integer as NULL pointer Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2023-06-19fbdev: hitfb: Fix integer-to-pointer castThomas Zimmermann1-1/+1
Fix the type casting from unsigned long to char __iomem *. Resolves the following warning: ../drivers/video/fbdev/hitfb.c:411:27: warning: incorrect type in assignment (different address spaces) ../drivers/video/fbdev/hitfb.c:411:27: expected char [noderef] __iomem *screen_base ../drivers/video/fbdev/hitfb.c:411:27: got void * Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2023-06-19fbdev/media: Use GPIO descriptors for VIA GPIOLinus Walleij4-46/+48
The VIA fbdev exposes a custom GPIO chip for its GPIOs, these are in turn looked up the camera driver using a custom API. Drop the custom API, provide a look-up table and convert to GPIO descriptors. Note proper polarity on the RESET line. Cc: Jonathan Corbet <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2023-06-19fbdev: broadsheetfb: Add MODULE_FIRMWARE macroJuerg Haefliger1-0/+2
The module loads firmware so add a MODULE_FIRMWARE macro to provide that information via modinfo. Signed-off-by: Juerg Haefliger <[email protected]> Signed-off-by: Helge Deller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.