summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-06-06dt-bindings: interrupt-controller: update brcm,l2-intc.yaml referenceMauro Carvalho Chehab
Changeset 539d25b21fe8 ("dt-bindings: interrupt-controller: Convert Broadcom STB L2 to YAML") renamed: Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt to: Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.yaml. Update its cross-reference accordingly. Fixes: 539d25b21fe8 ("dt-bindings: interrupt-controller: Convert Broadcom STB L2 to YAML") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/a40c02a7aaea91ea7b6ce24b6bc574ae5bcf4cf6.1654529011.git.mchehab@kernel.org
2022-06-06dt-bindings: mfd: bd9571mwv: update rohm,bd9571mwv.yaml referenceMauro Carvalho Chehab
Changeset 983b62975e90 ("dt-bindings: mfd: bd9571mwv: Convert to json-schema") renamed: Documentation/devicetree/bindings/mfd/bd9571mwv.txt to: Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml. Update its cross-reference accordingly. Fixes: 983b62975e90 ("dt-bindings: mfd: bd9571mwv: Convert to json-schema") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1906a4d935eab57c10ce09358eae02175ce4abb7.1654529011.git.mchehab@kernel.org
2022-06-06net: phy: dp83867: retrigger SGMII AN when link changeTan Tee Min
There is a limitation in TI DP83867 PHY device where SGMII AN is only triggered once after the device is booted up. Even after the PHY TPI is down and up again, SGMII AN is not triggered and hence no new in-band message from PHY to MAC side SGMII. This could cause an issue during power up, when PHY is up prior to MAC. At this condition, once MAC side SGMII is up, MAC side SGMII wouldn`t receive new in-band message from TI PHY with correct link status, speed and duplex info. As suggested by TI, implemented a SW solution here to retrigger SGMII Auto-Neg whenever there is a link change. v2: Add Fixes tag in commit message. Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy") Cc: <stable@vger.kernel.org> # 5.4.x Signed-off-by: Sit, Michael Wei Hong <michael.wei.hong.sit@intel.com> Reviewed-by: Voon Weifeng <weifeng.voon@intel.com> Signed-off-by: Tan Tee Min <tee.min.tan@linux.intel.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220526090347.128742-1-tee.min.tan@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-06ALSA: usb-audio: Set up (implicit) sync for Saffire 6Takashi Iwai
Focusrite Saffire 6 has fixed audioformat quirks with multiple endpoints assigned to a single altsetting. Unfortunately the generic parser couldn't detect the sync endpoint correctly as the implicit sync due to the missing EP attribute bits. In the former kernels, it used to work somehow casually, but it's been broken for a while after the large code change in 5.11. This patch cures the regression by the following: - Allow the static quirk table to provide the sync EP information; we just need to fill the fields and let the generic parser skipping parsing if sync_ep is already set. - Add the sync endpoint information to the entry for Saffire 6. Fixes: 7b0efea4baf0 ("ALSA: usb-audio: Add missing ep_idx in fixed EP quirks") Reported-and-tested-by: André Kapelrud <a.kapelrud@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220606160910.6926-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-06-06ALSA: usb-audio: Skip generic sync EP parse for secondary EPTakashi Iwai
When ep_idx is already non-zero, it means usually a capture stream that is set up explicity by a fixed-format quirk, and applying the check for generic (non-implicit-fb) sync EPs might hit incorrectly, resulting in a bogus sync endpoint for the capture stream. This patch adds a check for the ep_idx and skip if it's a secondary endpoint. It's a part of the fixes for regressions on Saffire 6. Fixes: 7b0efea4baf0 ("ALSA: usb-audio: Add missing ep_idx in fixed EP quirks") Reported-and-tested-by: André Kapelrud <a.kapelrud@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220606160910.6926-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-06-06pNFS: Avoid a live lock condition in pnfs_update_layout()Trond Myklebust
If we're about to send the first layoutget for an empty layout, we want to make sure that we drain out the existing pending layoutget calls first. The reason is that these layouts may have been already implicitly returned to the server by a recall to which the client gave a NFS4ERR_NOMATCHING_LAYOUT response. The problem is that wait_var_event_killable() could in principle see the plh_outstanding count go back to '1' when the first process to wake up starts sending a new layoutget. If it fails to get a layout, then this loop can continue ad infinitum... Fixes: 0b77f97a7e42 ("NFSv4/pnfs: Fix layoutget behaviour after invalidation") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2022-06-06pNFS: Don't keep retrying if the server replied NFS4ERR_LAYOUTUNAVAILABLETrond Myklebust
If the server tells us that a pNFS layout is not available for a specific file, then we should not keep pounding it with further layoutget requests. Fixes: 183d9e7b112a ("pnfs: rework LAYOUTGET retry handling") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2022-06-06netfilter: nf_tables: memleak flow rule from commit pathPablo Neira Ayuso
Abort path release flow rule object, however, commit path does not. Update code to destroy these objects before releasing the transaction. Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2022-06-06netfilter: nf_tables: release new hooks on unsupported flowtable flagsPablo Neira Ayuso
Release the list of new hooks that are pending to be registered in case that unsupported flowtable flags are provided. Fixes: 78d9f48f7f44 ("netfilter: nf_tables: add devices to existing flowtable") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2022-06-06firmware: arm_scmi: Remove all the unused local variablesCristian Marussi
While using SCMI iterators helpers a few local automatic variables are defined but then used only as input for sizeof operators. cppcheck is fooled to complain about this with: | drivers/firmware/arm_scmi/sensors.c:341:48: warning: Variable 'msg' is | not assigned a value. [unassignedVariable] | struct scmi_msg_sensor_list_update_intervals *msg; Even though this is an innocuos warning, since the uninitialized variable is at the end never used in the reported cases, fix these occurences all over SCMI stack to avoid keeping unneeded objects on the stack. Link: https://lore.kernel.org/r/20220530115237.277077-1-cristian.marussi@arm.com Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-06-06firmware: arm_scmi: Relax base protocol sanity checks on the protocol listCristian Marussi
Even though malformed replies from firmware must be treated carefully to avoid memory corruption in the kernel, some out-of-spec SCMI replies can be tolerated to avoid breaking existing deployed system, as long as they won't cause memory issues. Relax the sanity checks on the recieved protocol list in the base protocol to avoid breaking one of the deployed platform whose firmware is not easily upgradable currently. Link: https://lore.kernel.org/r/20220523171559.472112-1-cristian.marussi@arm.com Cc: Etienne Carriere <etienne.carriere@linaro.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Reported-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Tested-By: Frank Wunderlich <frank-w@public-files.de> Acked-by: Michael Riesch <michael.riesch@wolfvision.net> Acked-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-06-06btrfs: prevent remounting to v1 space cache for subpage mountQu Wenruo
Upstream commit 9f73f1aef98b ("btrfs: force v2 space cache usage for subpage mount") forces subpage mount to use v2 cache, to avoid deprecated v1 cache which doesn't support subpage properly. But there is a loophole that user can still remount to v1 cache. The existing check will only give users a warning, but does not really prevent to do the remount. Although remounting to v1 will not cause any problems since the v1 cache will always be marked invalid when mounted with a different page size, it's still better to prevent v1 cache at all for subpage mounts. Fixes: 9f73f1aef98b ("btrfs: force v2 space cache usage for subpage mount") CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2022-06-06btrfs: fix hang during unmount when block group reclaim task is runningFilipe Manana
When we start an unmount, at close_ctree(), if we have the reclaim task running and in the middle of a data block group relocation, we can trigger a deadlock when stopping an async reclaim task, producing a trace like the following: [629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000 [629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [629724.501267] Call Trace: [629724.501759] <TASK> [629724.502174] __schedule+0x3cb/0xed0 [629724.502842] schedule+0x4e/0xb0 [629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs] [629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0 [629724.505442] flush_space+0x423/0x630 [btrfs] [629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50 [629724.507259] ? lock_release+0x220/0x4a0 [629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs] [629724.508940] ? do_raw_spin_unlock+0x4b/0xa0 [629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs] [629724.510922] process_one_work+0x252/0x5a0 [629724.511694] ? process_one_work+0x5a0/0x5a0 [629724.512508] worker_thread+0x52/0x3b0 [629724.513220] ? process_one_work+0x5a0/0x5a0 [629724.514021] kthread+0xf2/0x120 [629724.514627] ? kthread_complete_and_exit+0x20/0x20 [629724.515526] ret_from_fork+0x22/0x30 [629724.516236] </TASK> [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000 [629724.518269] Call Trace: [629724.518746] <TASK> [629724.519160] __schedule+0x3cb/0xed0 [629724.519835] schedule+0x4e/0xb0 [629724.520467] schedule_timeout+0xed/0x130 [629724.521221] ? lock_release+0x220/0x4a0 [629724.521946] ? lock_acquired+0x19c/0x420 [629724.522662] ? trace_hardirqs_on+0x1b/0xe0 [629724.523411] __wait_for_common+0xaf/0x1f0 [629724.524189] ? usleep_range_state+0xb0/0xb0 [629724.524997] __flush_work+0x26d/0x530 [629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140 [629724.526580] ? lock_acquire+0x1a0/0x310 [629724.527324] __cancel_work_timer+0x137/0x1c0 [629724.528190] close_ctree+0xfd/0x531 [btrfs] [629724.529000] ? evict_inodes+0x166/0x1c0 [629724.529510] generic_shutdown_super+0x74/0x120 [629724.530103] kill_anon_super+0x14/0x30 [629724.530611] btrfs_kill_super+0x12/0x20 [btrfs] [629724.531246] deactivate_locked_super+0x31/0xa0 [629724.531817] cleanup_mnt+0x147/0x1c0 [629724.532319] task_work_run+0x5c/0xa0 [629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0 [629724.533598] syscall_exit_to_user_mode+0x16/0x40 [629724.534200] do_syscall_64+0x48/0x90 [629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae [629724.535318] RIP: 0033:0x7fa2b90437a7 [629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7 [629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0 [629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200 [629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000 [629724.541796] </TASK> This happens because: 1) Before entering close_ctree() we have the async block group reclaim task running and relocating a data block group; 2) There's an async metadata (or data) space reclaim task running; 3) We enter close_ctree() and park the cleaner kthread; 4) The async space reclaim task is at flush_space() and runs all the existing delayed iputs; 5) Before the async space reclaim task calls btrfs_wait_on_delayed_iputs(), the block group reclaim task which is doing the data block group relocation, creates a delayed iput at replace_file_extents() (called when COWing leaves that have file extent items pointing to relocated data extents, during the merging phase of relocation roots); 6) The async reclaim space reclaim task blocks at btrfs_wait_on_delayed_iputs(), since we have a new delayed iput; 7) The task at close_ctree() then calls cancel_work_sync() to stop the async space reclaim task, but it blocks since that task is waiting for the delayed iput to be run; 8) The delayed iput is never run because the cleaner kthread is parked, and no one else runs delayed iputs, resulting in a hang. So fix this by stopping the async block group reclaim task before we park the cleaner kthread. Fixes: 18bb8bbf13c183 ("btrfs: zoned: automatically reclaim zones") CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2022-06-06arm/xen: Assign xen-grant DMA ops for xen-grant DMA devicesOleksandr Tyshchenko
By assigning xen-grant DMA ops we will restrict memory access for passed device using Xen grant mappings. This is needed for using any virtualized device (e.g. virtio) in Xen guests in a safe manner. Please note, for the virtio devices the XEN_VIRTIO config should be enabled (it forces ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS). Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/1654197833-25362-9-git-send-email-olekstysh@gmail.com Signed-off-by: Juergen Gross <jgross@suse.com>
2022-06-06xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devicesOleksandr Tyshchenko
Use the presence of "iommus" property pointed to the IOMMU node with recently introduced "xen,grant-dma" compatible as a clear indicator of enabling Xen grant mappings scheme for that device and read the ID of Xen domain where the corresponding backend is running. The domid (domain ID) is used as an argument to the Xen grant mapping APIs. To avoid the deferred probe timeout which takes place after reusing generic IOMMU device tree bindings (because the IOMMU device never becomes available) enable recently introduced stub IOMMU driver by selecting XEN_GRANT_DMA_IOMMU. Also introduce xen_is_grant_dma_device() to check whether xen-grant DMA ops need to be set for a passed device. Remove the hardcoded domid 0 in xen_grant_setup_dma_ops(). Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/1654197833-25362-8-git-send-email-olekstysh@gmail.com Signed-off-by: Juergen Gross <jgross@suse.com>
2022-06-06xen/grant-dma-iommu: Introduce stub IOMMU driverOleksandr Tyshchenko
In order to reuse generic IOMMU device tree bindings by Xen grant DMA-mapping layer we need to add this stub driver from a fw_devlink perspective (grant-dma-ops cannot be converted into the proper IOMMU driver). Otherwise, just reusing IOMMU bindings (without having a corresponding driver) leads to the deferred probe timeout afterwards, because the IOMMU device never becomes available. This stub driver does nothing except registering empty iommu_ops, the upper layer "of_iommu" will treat this as NO_IOMMU condition and won't return -EPROBE_DEFER. As this driver is quite different from the most hardware IOMMU implementations and only needed in Xen guests, place it in drivers/xen directory. The subsequent commit will make use of it. Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/1654197833-25362-7-git-send-email-olekstysh@gmail.com Signed-off-by: Juergen Gross <jgross@suse.com>
2022-06-06dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA opsOleksandr Tyshchenko
The main purpose of this binding is to communicate Xen specific information using generic IOMMU device tree bindings (which is a good fit here) rather than introducing a custom property. Introduce Xen specific IOMMU for the virtualized device (e.g. virtio) to be used by Xen grant DMA-mapping layer in the subsequent commit. The reference to Xen specific IOMMU node using "iommus" property indicates that Xen grant mappings need to be enabled for the device, and it specifies the ID of the domain where the corresponding backend resides. The domid (domain ID) is used as an argument to the Xen grant mapping APIs. This is needed for the option to restrict memory access using Xen grant mappings to work which primary goal is to enable using virtio devices in Xen guests. Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1654197833-25362-6-git-send-email-olekstysh@gmail.com Signed-off-by: Juergen Gross <jgross@suse.com>
2022-06-06xen/virtio: Enable restricted memory access using Xen grant mappingsJuergen Gross
In order to support virtio in Xen guests add a config option XEN_VIRTIO enabling the user to specify whether in all Xen guests virtio should be able to access memory via Xen grant mappings only on the host side. Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/1654197833-25362-5-git-send-email-olekstysh@gmail.com Signed-off-by: Juergen Gross <jgross@suse.com>
2022-06-06dt-bindings: update Luca Ceresoli's e-mail addressLuca Ceresoli
My Bootlin address is preferred from now on. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220603155727.1232061-2-luca@lucaceresoli.net
2022-06-06dt-bindings: msm: update maintainers list with proper idKrishna Manikandan
Use quic id instead of codeaurora id in maintainers list for display devicetree bindings. Signed-off-by: Krishna Manikandan <quic_mkrishn@quicinc.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1654166998-14907-1-git-send-email-quic_mkrishn@quicinc.com
2022-06-06dt-bindings: vendor-prefixes: document deprecated AtherosKrzysztof Kozlowski
Two old boards use "atheros" prefix instead of already documented "qca". Document it as deprecated to fix warnings like: at91-gatwick.dtb: atheros@0: 'atheros,board-id' does not match any of the regexes Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220601135222.205035-1-krzysztof.kozlowski@linaro.org
2022-06-06dt-bindings: Update QCOM USB subsystem maintainer informationWesley Cheng
Update devicetree binding files with the proper maintainer, and updated contact email. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220603021432.13365-1-quic_wcheng@quicinc.com
2022-06-06spi: dt-bindings: Fix unevaluatedProperties warnings in examplesRob Herring
The 'unevaluatedProperties' schema checks is not fully working and doesn't catch some cases where there's a $ref to another schema. A fix is pending, but results in new warnings in examples. 'spi-max-frequency' is supposed to be a per SPI peripheral device property, not a SPI controller property, so drop it. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20220526014141.2872567-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06spi: spi-mem: Fix spi_mem_poll_status()Patrice Chotard
In spi_mem_exec_op(), in case cs_gpiod descriptor is set, exec_op() callback can't be used. The same must be applied in spi_mem_poll_status(), poll_status() callback can't be used, we must use the legacy path using read_poll_timeout(). Tested on STM32mp257c-ev1 specific evaluation board on which a spi-nand was mounted instead of a spi-nor. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> Link: https://lore.kernel.org/r/20220602091022.358127-1-patrice.chotard@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06spi: cadence: Detect transmit FIFO depthLars-Peter Clausen
The depth of the transmit FIFO for the Cadence SPI controller is currently hardcoded to 128. But the depth is a synthesis configuration parameter of the core and can vary between different SoCs. If the configured FIFO size is less than 128 the driver will busy loop in the cdns_spi_fill_tx_fifo() function waiting for FIFO space to become available. Depending on the length and speed of the transfer it can spin for a significant amount of time. The cdns_spi_fill_tx_fifo() function is called from the drivers interrupt handler, so it can leave interrupts disabled for a prolonged amount of time. In addition the read FIFO will also overflow and data will be discarded. To avoid this detect the actual size of the FIFO and use that rather than the hardcoded value. To detect the FIFO size the FIFO threshold register is used. The register is sized so that it can hold FIFO size - 1 as its maximum value. Bits that are not needed to hold the threshold value will always read 0. By writing 0xffff to the register and then reading back the value in the register we get the FIFO size. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20220527091143.3780378-1-lars@metafoo.de Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06spi: spi-cadence: Fix SPI CS gets toggling sporadicallySai Krishna Potthuri
As part of unprepare_transfer_hardware, SPI controller will be disabled which will indirectly deassert the CS line. This will create a problem in some of the devices where message will be transferred with cs_change flag set(CS should not be deasserted). As per SPI controller implementation, if SPI controller is disabled then all output enables are inactive and all pins are set to input mode which means CS will go to default state high(deassert). This leads to an issue when core explicitly ask not to deassert the CS (cs_change = 1). This patch fix the above issue by checking the Slave select status bits from configuration register before disabling the SPI. Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com> Link: https://lore.kernel.org/r/20220606062525.18447-1-amit.kumar-mahapatra@xilinx.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06ASoC: wm_adsp: Fix event generation for wm_adsp_fw_put()Mark Brown
Currently wm_adsp_fw_put() returns 0 rather than 1 when updating the value of the control, meaning that no event is generated to userspace. Fix this by setting the default return value to 1, the code already exits early with a return value of 0 if the value is unchanged. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220603115003.3865834-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06ASoC: es8328: Fix event generation for deemphasis controlMark Brown
Currently the put() method for the deemphasis control returns 0 when a new value is written to the control even if the value changed, meaning events are not generated. Fix this, skip the work of updating the value when it is unchanged and then return 1 after having done so. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220603123937.4013603-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06ASoC: wm8962: Fix suspend while playing musicAdam Ford
If the audio CODEC is playing sound when the system is suspended, it can be left in a state which throws the following error: wm8962 3-001a: ASoC: error at soc_component_read_no_lock on wm8962.3-001a: -16 Once this error has occurred, the audio will not work again until rebooted. Fix this by configuring SET_SYSTEM_SLEEP_PM_OPS. Signed-off-by: Adam Ford <aford173@gmail.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220526182129.538472-1-aford173@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06ASoC: SOF: ipc-msg-injector: Fix reversed if statementDan Carpenter
This if statement is reversed. In fact, the condition can just be deleted because writing zero bytes is a no-op. Fixes: 066c67624d8c ("ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/Yph+T3PpGCdPsEDj@kili Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06ASoC: SOF: ipc-msg-injector: Propagate write errors correctlyDan Carpenter
This code is supposed to propagate errors from simple_write_to_buffer() or return -EFAULT if "size != count". However "size" needs to be signed for the code to work correctly and the case where "size == 0" is not handled correctly. Fixes: 066c67624d8c ("ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages") Fixes: 2f0b1b013bbc ("ASoC: SOF: debug: Add support for IPC message injection") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/Yph+Cd+JrfOH0i7z@kili Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06ASoC: fsl_sai: Add support for i.MX8MNShengjiu Wang
The SAI module on i.MX8MN is almost same as i.MX8MP, So reuse same soc data as i.MX8MP. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1653966123-28217-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06ASoC: SOF: Fix potential NULL pointer dereferenceAmadeusz Sławiński
Cleanup path for sof_prepare_widgets_in_path() should check if unprepare callback exists before calling it, instead it checks if it does not exist. Fix the check. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220602135757.3335351-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06gpio: dln2: make irq_chip immutableAndy Shevchenko
Since recently, the kernel is nagging about mutable irq_chips: "not an immutable chip, please consider fixing it!" Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new helper functions and call the appropriate gpiolib functions. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-06-06gpio: sch: make irq_chip immutableAndy Shevchenko
Since recently, the kernel is nagging about mutable irq_chips: "not an immutable chip, please consider fixing it!" Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new helper functions and call the appropriate gpiolib functions. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-06-06gpio: merrifield: make irq_chip immutableAndy Shevchenko
Since recently, the kernel is nagging about mutable irq_chips: "not an immutable chip, please consider fixing it!" Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new helper functions and call the appropriate gpiolib functions. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-06-06gpio: wcove: make irq_chip immutableAndy Shevchenko
Since recently, the kernel is nagging about mutable irq_chips: "not an immutable chip, please consider fixing it!" Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new helper functions and call the appropriate gpiolib functions. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2022-06-06gpio: crystalcove: Join function declarations and long linesAndy Shevchenko
There is no more hard limit of 80 characters for long lines, so join a few of them for better readability. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-06-06gpio: crystalcove: Use specific type and API for IRQ numberAndy Shevchenko
Use specific type and API for IRQ number in the callbacks. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-06-06gpio: crystalcove: make irq_chip immutableAndy Shevchenko
Since recently, the kernel is nagging about mutable irq_chips: "not an immutable chip, please consider fixing it!" Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new helper functions and call the appropriate gpiolib functions. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-06-06memory: samsung: exynos5422-dmc: Fix refcount leak in of_get_dram_timingsMiaoqian Lin
of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function doesn't call of_node_put() in some error paths. To unify the structure, Add put_node label and goto it on errors. Fixes: 6e7674c3c6df ("memory: Add DMC driver for Exynos5422") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220602041721.64348-1-linmq006@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-06-06memory: mtk-smi: add missing put_device() call in mtk_smi_device_link_commonMiaoqian Lin
The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the error handling paths. Fixes: 47404757702e ("memory: mtk-smi: Add device link for smi-sub-common") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220601120118.60225-1-linmq006@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-06-06memory: omap-gpmc: OMAP_GPMC should depend on ARCH_OMAP2PLUS || ↵Geert Uytterhoeven
ARCH_KEYSTONE || ARCH_K3 The Texas Instruments OMAP General Purpose Memory Controller (GPMC) is only present on TI OMAP2/3/4/5, Keystone, AM33xx, AM43x, DRA7xx, TI81xx, and K3 SoCs. Hence add a dependency on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3, to prevent asking the user about this driver when configuring a kernel without OMAP2+, Keystone, or K3 SoC family support. Fixes: be34f45f0d4aa91c ("memory: omap-gpmc: Make OMAP_GPMC config visible and selectable") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/f6780f572f882ed6ab5934321942cf2b412bf8d1.1652174849.git.geert+renesas@glider.be Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-06-06ARM: exynos: Fix refcount leak in exynos_map_pmuMiaoqian Lin
of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer. Fixes: fce9e5bb2526 ("ARM: EXYNOS: Add support for mapping PMU base address via DT") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220523145513.12341-1-linmq006@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-06-06arm64: dts: exynos: Correct UART clocks on Exynos7885David Virag
The clocks in the serial UART nodes were swapped by mistake on Exynos7885. This only worked correctly because of a mistake in the clock driver which has been fixed. With the fixed clock driver in place, the baudrate of the UARTs get miscalculated. Fix this by correcting the clocks in the dtsi. Fixes: 06874015327b ("arm64: dts: exynos: Add initial device tree support for Exynos7885 SoC") Signed-off-by: David Virag <virag.david003@gmail.com> Link: https://lore.kernel.org/r/20220526055840.45209-3-virag.david003@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-06-06quota: Prevent memory allocation recursion while holding dq_lockMatthew Wilcox (Oracle)
As described in commit 02117b8ae9c0 ("f2fs: Set GF_NOFS in read_cache_page_gfp while doing f2fs_quota_read"), we must not enter filesystem reclaim while holding the dq_lock. Prevent this more generally by using memalloc_nofs_save() while holding the lock. Link: https://lore.kernel.org/r/20220605143815.2330891-2-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Jan Kara <jack@suse.cz>
2022-06-06ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo Yoga ↵Cameron Berkenpas
DuetITL 2021 Enables the ALC287_FIXUP_YOGA7_14ITL_SPEAKERS quirk for the Lenovo Yoga DuetITL 2021 laptop to fix speaker output. [ re-sorted in the SSID order by tiwai ] BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555 Signed-off-by: Cameron Berkenpas <cam@neo-zeon.de> Co-authored-by: Songine <donglingluoying@gmail.com> Cc: stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220606002329.215330-1-cam@neo-zeon.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-06-06writeback: Fix inode->i_io_list not be protected by inode->i_lock errorJchao Sun
Commit b35250c0816c ("writeback: Protect inode->i_io_list with inode->i_lock") made inode->i_io_list not only protected by wb->list_lock but also inode->i_lock, but inode_io_list_move_locked() was missed. Add lock there and also update comment describing things protected by inode->i_lock. This also fixes a race where __mark_inode_dirty() could move inode under flush worker's hands and thus sync(2) could miss writing some inodes. Fixes: b35250c0816c ("writeback: Protect inode->i_io_list with inode->i_lock") Link: https://lore.kernel.org/r/20220524150540.12552-1-sunjunchao2870@gmail.com CC: stable@vger.kernel.org Signed-off-by: Jchao Sun <sunjunchao2870@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz>
2022-06-06fs: Fix syntax errors in commentsXiang wangx
Delete the redundant word 'not'. Link: https://lore.kernel.org/r/20220605125509.14837-1-wangxiang@cdjrlc.com Signed-off-by: Xiang wangx <wangxiang@cdjrlc.com> Signed-off-by: Jan Kara <jack@suse.cz>
2022-06-06xen/grant-dma-ops: Add option to restrict memory access under XenJuergen Gross
Introduce Xen grant DMA-mapping layer which contains special DMA-mapping routines for providing grant references as DMA addresses to be used by frontends (e.g. virtio) in Xen guests. Add the needed functionality by providing a special set of DMA ops handling the needed grant operations for the I/O pages. The subsequent commit will introduce the use case for xen-grant DMA ops layer to enable using virtio devices in Xen guests in a safe manner. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/1654197833-25362-4-git-send-email-olekstysh@gmail.com Signed-off-by: Juergen Gross <jgross@suse.com>
generated by cgit (git 2.34.1) at 2025-09-15 10:44:43 +0000