summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-07-03usb: typec: ucsi: split read operationDmitry Baryshkov
The read operation is only used to read fixed data at fixed offsets (UCSI_VERSION, UCSI_CCI, UCSI_MESSAGE_IN). In some cases drivers apply offset-specific overrides. Split the read() operation into three operations, read_version(), read_cci(), read_message_in(). Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240627-ucsi-rework-interface-v4-3-289ddc6874c7@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-03usb: typec: ucsi: simplify command sending APIDmitry Baryshkov
The sync_write and async_write are used only for writing UCSI commands to the UCSI_CONTROL offsets. Rename sync_write and async_write operations to sync_control and async_control accordingly. Drop the offset and length fields and pass u64 command instead. Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240627-ucsi-rework-interface-v4-2-289ddc6874c7@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-03usb: typec: ucsi: move ucsi_acknowledge() from ucsi_read_error()Dmitry Baryshkov
As a preparation for reworking UCSI command handling, move ucsi_acknowledge() for the failed command from ucsi_read_error() to ucsi_exec_command(). Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240627-ucsi-rework-interface-v4-1-289ddc6874c7@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-03wifi: iwlwifi: properly set WIPHY_FLAG_SUPPORTS_EXT_KEK_KCKDaniel Gabay
The WIPHY_FLAG_SUPPORTS_EXT_KEK_KCK should be set based on the WOWLAN_KEK_KCK_MATERIAL command version. Currently, the command version in the firmware has advanced to 4, which prevents the flag from being set correctly, fix that. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240703064026.a0f162108575.If1a9785727d2a1b0197a396680965df1b53d4096@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-03usb: core: add missing of_node_put() in usb_of_has_devices_or_graphJavier Carrasco
The for_each_child_of_node() macro requires an explicit call to of_node_put() on early exits to decrement the child refcount and avoid a memory leak. The child node is not required outsie the loop, and the resource must be released before the function returns. Add the missing of_node_put(). Cc: stable@vger.kernel.org Fixes: 82e82130a78b ("usb: core: Set connect_type of ports based on DT node") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20240624-usb_core_of_memleak-v1-1-af6821c1a584@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-03USB: Add USB_QUIRK_NO_SET_INTF quirk for START BP-850kWangYuli
START BP-850K is a dot matrix printer that crashes when it receives a Set-Interface request and needs USB_QUIRK_NO_SET_INTF to work properly. Cc: stable <stable@kernel.org> Signed-off-by: jinxiaobo <jinxiaobo@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com> Link: https://lore.kernel.org/r/202E4B2BD0F0FEA4+20240702154408.631201-1-wangyuli@uniontech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-03USB: core: Fix duplicate endpoint bug by clearing reserved bits in the ↵Alan Stern
descriptor Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk). To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+8693a0bb9c10b554272a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/0000000000003d868e061bc0f554@google.com/ Fixes: 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses") CC: Oliver Neukum <oneukum@suse.com> CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/205a5edc-7fef-4159-b64a-80374b6b101a@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-03xhci: always resume roothubs if xHC was reset during resumeMathias Nyman
Usb device connect may not be detected after runtime resume if xHC is reset during resume. In runtime resume cases xhci_resume() will only resume roothubs if there are pending port events. If the xHC host is reset during runtime resume due to a Save/Restore Error (SRE) then these pending port events won't be detected as PORTSC change bits are not immediately set by host after reset. Unconditionally resume roothubs if xHC is reset during resume to ensure device connections are detected. Also return early with error code if starting xHC fails after reset. Issue was debugged and a similar solution suggested by Remi Pommarel. Using this instead as it simplifies future refactoring. Reported-by: Remi Pommarel <repk@triplefau.lt> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218987 Suggested-by: Remi Pommarel <repk@triplefau.lt> Tested-by: Remi Pommarel <repk@triplefau.lt> Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240627145523.1453155-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-03Merge tag 'ath-next-20240702' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath ath.git patches for v6.11 We have moved to a new group-managed repo, and this is the first pull request from that repo, and from me. Fingers crossed... We have some new features in ath12k along with some cleanups in ath11k and ath12k. Also notable are some device-tree changes to allow certain ath11k and ath12k devices to work with a new power sequencing subsystem. Major changes: ath12k * DebugFS support for datapath statistics * WCN7850: support for WoW (Wake on WLAN) * WCN7850: device-tree bindings ath11k * QCA6390: device-tree bindings
2024-07-03drm/dp_mst: Skip CSN if topology probing is not done yetWayne Lin
[Why] During resume, observe that we receive CSN event before we start topology probing. Handling CSN at this moment based on uncertain topology is unnecessary. [How] Add checking condition in drm_dp_mst_handle_up_req() to skip handling CSN if the topology is yet to be probed. Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626084825.878565-3-Wayne.Lin@amd.com
2024-07-03drm/dp_mst: Fix all mstb marked as not probed after suspend/resumeWayne Lin
[Why] After supend/resume, with topology unchanged, observe that link_address_sent of all mstb are marked as false even the topology probing is done without any error. It is caused by wrongly also include "ret == 0" case as a probing failure case. [How] Remove inappropriate checking conditions. Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Fixes: 37dfdc55ffeb ("drm/dp_mst: Cleanup drm_dp_send_link_address() a bit") Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626084825.878565-2-Wayne.Lin@amd.com
2024-07-03serial: imx: only set receiver level if it is zeroStefan Eichenberger
With commit a81dbd0463ec ("serial: imx: set receiver level before starting uart") we set the receiver level to its default value. This caused a regression when using SDMA, where the receiver level is 9 instead of 8 (default). This change will first check if the receiver level is zero and only then set it to the default. This still avoids the interrupt storm when the receiver level is zero. Fixes: a81dbd0463ec ("serial: imx: set receiver level before starting uart") Cc: stable <stable@kernel.org> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Link: https://lore.kernel.org/r/20240703112543.148304-1-eichest@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-03media: stm32: dcmipp: correct error handling in dcmipp_create_subdevsAlain Volmat
Correct error handling within the dcmipp_create_subdevs by properly decrementing the i counter when releasing the subdevs. Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver") Cc: stable@vger.kernel.org Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> [hverkuil: correct the indices: it's [i], not [i - 1].]
2024-07-03Merge tag 'coresight-next-v6.11' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/coresight/linux into char-misc-next Suzuki writes: coresight: Updates for v6.11 Coresight/hwtracing subsystem updates targeting v6.11 includes a few minor fixes and cleanups Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> * tag 'coresight-next-v6.11' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/coresight/linux: hwtracing: use for_each_endpoint_of_node() coresight: constify the struct device_type usage coresight: tmc: Remove duplicated include in coresight-tmc-core.c coresight: Fix ref leak when of_coresight_parse_endpoint() fails
2024-07-03wifi: wilc1000: fix ies_len type in connect pathJozef Hopko
Commit 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path") made sure that the IEs data was manipulated under the relevant RCU section. Unfortunately, while doing so, the commit brought a faulty implicit cast from int to u8 on the ies_len variable, making the parsing fail to be performed correctly if the IEs block is larger than 255 bytes. This failure can be observed with Access Points appending a lot of IEs TLVs in their beacon frames (reproduced with a Pixel phone acting as an Access Point, which brough 273 bytes of IE data in my testing environment). Fix IEs parsing by removing this undesired implicit cast. Fixes: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path") Signed-off-by: Jozef Hopko <jozef.hopko@altana.com> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Acked-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240701-wilc_fix_ies_data-v1-1-7486cbacf98a@bootlin.com
2024-07-03Merge tag 'counter-updates-for-6.11' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-next William writes: Counter updates for 6.11 Primarily consists of cleanups and updates for ti-eqep; ti-eqep now supports over/underflow events and can be build for K3 devices. In addition, ftm-quaddec is updated to add a missing MODULE_DESCRIPTION() macro. * tag 'counter-updates-for-6.11' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter: counter: ti-eqep: Allow eQEP driver to be built for K3 devices counter/ti-eqep: Add new ti-am62-eqep compatible dt-bindings: counter: Add new ti,am62-eqep compatible counter: ti-eqep: remove counter_priv() wrapper counter: ti-eqep: remove unused struct member counter: ti-eqep: implement over/underflow events counter: ftm-quaddec: add missing MODULE_DESCRIPTION() macro
2024-07-03Merge tag 'w1-drv-6.11' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/krzk/linux-w1 into char-misc-next Krzysztof writes: 1-Wire bus drivers for v6.11 Just two cleanups for W1 core code. * tag 'w1-drv-6.11' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/krzk/linux-w1: w1: Drop allocation error message w1: Add missing newline and fix typos in w1_bus_master comment
2024-07-03Merge tag 'fpga-for-6.11-rc1' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga into char-misc-next Xu writes: FPGA Manager changes for 6.11-rc1 FPGA unit test: - Macro's change re-enables FPGA KUnit test suites been configured as loadable module. Altera: - David's change removes unused structure definition. All patches have been reviewed on the mailing list, and have been in the last linux-next releases (as part of our for-next branch). Signed-off-by: Xu Yilun <yilun.xu@intel.com> * tag 'fpga-for-6.11-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga: fpga: altera-fpga2sdram: remove unused struct 'prop_map' Revert "fpga: disable KUnit test suites when module support is enabled"
2024-07-03Merge tag 'usb-serial-6.10-rc6' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial device ids for 6.10-rc6 Here are some new modem device ids. All have been in linux-next with no reported issues. * tag 'usb-serial-6.10-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Telit generic core-dump composition USB: serial: option: add Fibocom FM350-GL USB: serial: option: add Telit FN912 rmnet compositions
2024-07-03net: wwan: mhi: make default data link id configurableSlark Xiao
For SDX72 MBIM mode, it starts data mux id from 112 instead of 0. This would lead to device can't ping outside successfully. Also MBIM side would report "bad packet session (112)". In order to fix this issue, we decide to use the device name of MHI controller to do a match in wwan side. Then wwan driver could set a corresponding mux_id value according to the MHI product. Signed-off-by: Slark Xiao <slark_xiao@163.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20240701021216.17734-3-slark_xiao@163.com Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-03bus: mhi: host: Allow controller drivers to specify name for the MHI controllerSlark Xiao
MHI devices usually have a product/device name to identify each device uniquely. So let's specify that name in 'struct mhi_controller' so that the client drivers can use this name to uniquely identify the devices and apply any device specific quirks. Signed-off-by: Slark Xiao <slark_xiao@163.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20240701021216.17734-2-slark_xiao@163.com [mani: reworked subject and description] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-03bus: mhi: host: Add support for Foxconn SDX72 modemsSlark Xiao
Add support for Foxconn SDX72 based modems, T99W515 and DW5934E. Existing SDX55 channel/event configs are reused with the custom ready_timeout_ms value to workaround firmware issue. Signed-off-by: Slark Xiao <slark_xiao@163.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20240701021216.17734-1-slark_xiao@163.com [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-03gpio: mmio: do not calculate bgpio_bits via "ngpios"Shiji Yang
bgpio_bits must be aligned with the data bus width. For example, on a 32 bit big endian system and we only have 16 GPIOs. If we only assume bgpio_bits=16 we can never control the GPIO because the base address is the lowest address. low address high address ------------------------------------------------- | byte3 | byte2 | byte1 | byte0 | ------------------------------------------------- | NaN | NaN | gpio8-15 | gpio0-7 | ------------------------------------------------- Fixes: 55b2395e4e92 ("gpio: mmio: handle "ngpios" properly in bgpio_init()") Fixes: https://github.com/openwrt/openwrt/issues/15739 Reported-by: Mark Mentovai <mark@mentovai.com> Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Suggested-By: Mark Mentovai <mark@mentovai.com> Reviewed-by: Jonas Gorski <jonas.gorski@gmail.com> Tested-by: Lóránd Horváth <lorand.horvath82@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/TYCP286MB089577B47D70F0AB25ABA6F5BCD52@TYCP286MB0895.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-07-03drm/panfrost: Mark simple_ondemand governor as softdepDragan Simic
Panfrost DRM driver uses devfreq to perform DVFS, while using simple_ondemand devfreq governor by default. This causes driver initialization to fail on boot when simple_ondemand governor isn't built into the kernel statically, as a result of the missing module dependency and, consequently, the required governor module not being included in the initial ramdisk. Thus, let's mark simple_ondemand governor as a softdep for Panfrost, to have its kernel module included in the initial ramdisk. This is a rather longstanding issue that has forced distributions to build devfreq governors statically into their kernels, [1][2] or has forced users to introduce some unnecessary workarounds. [3] For future reference, not having support for the simple_ondemand governor in the initial ramdisk produces errors in the kernel log similar to these below, which were taken from a Pine64 RockPro64: panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq panfrost ff9a0000.gpu: Fatal error during GPU init panfrost: probe of ff9a0000.gpu failed with error -22 Having simple_ondemand marked as a softdep for Panfrost may not resolve this issue for all Linux distributions. In particular, it will remain unresolved for the distributions whose utilities for the initial ramdisk generation do not handle the available softdep information [4] properly yet. However, some Linux distributions already handle softdeps properly while generating their initial ramdisks, [5] and this is a prerequisite step in the right direction for the distributions that don't handle them properly yet. [1] https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/linux61/config?ref_type=heads#L8180 [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1066 [3] https://forum.pine64.org/showthread.php?tid=15458 [4] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d [5] https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad Cc: Diederik de Haas <didi.debian@cknow.org> Cc: Furkan Kardame <f.kardame@manjaro.org> Cc: stable@vger.kernel.org Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/4e1e00422a14db4e2a80870afb704405da16fd1b.1718655077.git.dsimic@manjaro.org
2024-07-03driver core: have match() callback in struct bus_type take a const *Greg Kroah-Hartman
In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Alex Elder <elder@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-03perf: arm_pmuv3: Include asm/arm_pmuv3.h from linux/perf/arm_pmuv3.hRob Herring (Arm)
The arm64 asm/arm_pmuv3.h depends on defines from linux/perf/arm_pmuv3.h. Rather than depend on include order, follow the usual pattern of "linux" headers including "asm" headers of the same name. With this change, the include of linux/kvm_host.h is problematic due to circular includes: In file included from ../arch/arm64/include/asm/arm_pmuv3.h:9, from ../include/linux/perf/arm_pmuv3.h:312, from ../include/kvm/arm_pmu.h:11, from ../arch/arm64/include/asm/kvm_host.h:38, from ../arch/arm64/mm/init.c:41: ../include/linux/kvm_host.h:383:30: error: field 'arch' has incomplete type Switching to asm/kvm_host.h solves the issue. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240626-arm-pmu-3-9-icntr-v2-5-c9784b4f4065@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2024-07-03perf: arm_v6/7_pmu: Drop non-DT probe supportRob Herring (Arm)
There are no non-DT based PMU users for v6 or v7, so drop the custom non-DT probe table. Unfortunately XScale still needs non-DT probing. Note that this drops support for arm1156 PMU, but there are no arm1156 based systems supported in the kernel. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240626-arm-pmu-3-9-icntr-v2-4-c9784b4f4065@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2024-07-03perf/arm: Move 32-bit PMU drivers to drivers/perf/Rob Herring (Arm)
It is preferred to put drivers under drivers/ rather than under arch/. The PMU drivers also depend on arm_pmu.c, so it's better to place them all together. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240626-arm-pmu-3-9-icntr-v2-3-c9784b4f4065@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2024-07-03perf: arm_pmuv3: Drop unnecessary IS_ENABLED(CONFIG_ARM64) checkRob Herring (Arm)
The IS_ENABLED(CONFIG_ARM64) check for threshold support is unnecessary. The purpose is to not enable thresholds on arm32, but if threshold is non-zero, the check against threshold_max() just above here will have errored out because threshold_max() is always 0 on arm32. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Mark rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20240626-arm-pmu-3-9-icntr-v2-2-c9784b4f4065@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2024-07-03perf: arm_pmuv3: Avoid assigning fixed cycle counter with thresholdRob Herring (Arm)
If the user has requested a counting threshold for the CPU cycles event, then the fixed cycle counter can't be assigned as it lacks threshold support. Currently, the thresholds will work or not randomly depending on which counter the event is assigned. While using thresholds for CPU cycles doesn't make much sense, it can be useful for testing purposes. Fixes: 816c26754447 ("arm64: perf: Add support for event counting threshold") Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20240626-arm-pmu-3-9-icntr-v2-1-c9784b4f4065@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2024-07-03pinctrl: freescale: Use scope based of_node_put() cleanupsPeng Fan
Use scope based of_node_put() cleanup to simplify code. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/20240627131721.678727-4-peng.fan@oss.nxp.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-07-03pinctrl: equilibrium: Use scope based of_node_put() cleanupsPeng Fan
Use scope based of_node_put() cleanup to simplify code. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/20240627131721.678727-3-peng.fan@oss.nxp.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-07-03pinctrl: ti: iodelay: Use scope based of_node_put() cleanupsPeng Fan
Use scope based of_node_put() cleanup to simplify code. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/20240627131721.678727-2-peng.fan@oss.nxp.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-07-03pinctrl: qcom: lpass-lpi: increase MAX_NR_GPIO to 32Alexey Klimov
Account for more than only 23 GPIOs in LPASS Low Power Island pinctrl generic driver. The previous value 23 was chosen to satisfy existing SoC-specific drivers. However SM4250 LPI pinctrl uses more than 23 GPIOs and its probe routine fails on: if (WARN_ON(data->npins > MAX_NR_GPIO)) return -EINVAL; with the following message: [ 10.709014] ------------[ cut here ]------------ [ 10.719085] WARNING: CPU: 1 PID: 56 at drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:446 lpi_pinctrl_probe+0x308/0x388 [pinctrl_lpass_lpi] [ 10.719108] Modules linked in: [...] [ 10.719238] CPU: 1 PID: 56 Comm: kworker/u33:0 Not tainted 6.10.0-rc2-00012-ge45ddb1f8d34-dirty #7 [ 10.719245] Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) [ 10.719250] Workqueue: events_unbound deferred_probe_work_func [ 10.719265] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 10.719271] pc : lpi_pinctrl_probe+0x308/0x388 [pinctrl_lpass_lpi] [ 10.719278] lr : lpi_pinctrl_probe+0x44/0x388 [pinctrl_lpass_lpi] ... [ 10.719357] Call trace: [ 10.719361] lpi_pinctrl_probe+0x308/0x388 [pinctrl_lpass_lpi] [ 10.719369] platform_probe+0x68/0xc4 [ 10.719378] really_probe+0xbc/0x29c [ 10.719384] __driver_probe_device+0x78/0x12c [ 10.719390] driver_probe_device+0xd8/0x15c [ 10.719395] __device_attach_driver+0xb8/0x134 [ 10.719401] bus_for_each_drv+0x88/0xe8 [ 10.719407] __device_attach+0xa0/0x190 [ 10.719412] device_initial_probe+0x14/0x20 [ 10.719418] bus_probe_device+0xac/0xb0 [ 10.719423] deferred_probe_work_func+0x88/0xc0 [ 10.719429] process_one_work+0x150/0x294 [ 10.719439] worker_thread+0x2f8/0x408 [ 10.719445] kthread+0x110/0x114 [ 10.719452] ret_from_fork+0x10/0x20 [ 10.719459] ---[ end trace 0000000000000000 ]--- [ 10.719589] qcom-sm4250-lpass-lpi-pinctrl a7c0000.pinctrl: probe with driver qcom-sm4250-lpass-lpi-pinctrl failed with error -22 Fixes: c2e5a25e8d88 ("pinctrl: qcom: Introduce SM4250 LPI pinctrl driver") Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/20240627003654.242870-1-alexey.klimov@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-07-03pinctrl: cy8c95x0: Update cache modificationPatrick Rudolph
In the previous review cycle the regmap cache update code was questioned since it seems and odd way of using regmap_update_bits(). Thus update the regmap cache modification code to better explain what it does and why it's done. This is no functional change, but it's improving code maintainability. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/20240626084525.787298-2-patrick.rudolph@9elements.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-07-03pinctrl: cy8c95x0: Use cleanup.hPatrick Rudolph
Use the guard mutex from cleanup.h to make the code more readable. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/20240626084525.787298-1-patrick.rudolph@9elements.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-07-03s390/vfio_ccw: Fix target addresses of TIC CCWsEric Farman
The processing of a Transfer-In-Channel (TIC) CCW requires locating the target of the CCW in the channel program, and updating the address to reflect what will actually be sent to hardware. An error exists where the 64-bit virtual address is truncated to 32-bits (variable "cda") when performing this math. Since s390 addresses of that size are 31-bits, this leaves that additional bit enabled such that the resulting I/O triggers a channel program check. This shows up occasionally when booting a KVM guest from a passthrough DASD device: ..snip... Interrupt Response Block Data: : 0x0000000000003990 Function Ctrl : [Start] Activity Ctrl : Status Ctrl : [Alert] [Primary] [Secondary] [Status-Pending] Device Status : Channel Status : [Program-Check] cpa=: 0x00000000008d0018 prev_ccw=: 0x0000000000000000 this_ccw=: 0x0000000000000000 ...snip... dasd-ipl: Failed to run IPL1 channel program The channel program address of "0x008d0018" in the IRB doesn't look wrong, but tracing the CCWs shows the offending bit enabled: ccw=0x0000012e808d0000 cda=00a0b030 ccw=0x0000012e808d0008 cda=00a0b038 ccw=0x0000012e808d0010 cda=808d0008 ccw=0x0000012e808d0018 cda=00a0b040 Fix the calculation of the TIC CCW's data address such that it points to a valid 31-bit address regardless of the input address. Fixes: bd36cfbbb9e1 ("s390/vfio_ccw_cp: use new address translation helpers") Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20240628163738.3643513-1-farman@linux.ibm.com Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-07-03eeprom: at24: Add support for Microchip 24AA025E48/24AA025E64 EEPROMsClaudiu Beznea
Add "microchip,24aa025e48", "microchip,24aa025e64" compatible for the usage w/ 24AA025E{48, 64} type of EEPROMs where "24aa025e48" stands for EUI-48 address and "24aa025e64" stands for EUI-64 address. [andrei.simion@microchip.com: Use AT24_DATA_CHIP with AT24_FLAG_READONLY for 24AA025E{48, 64} type of EEPROMs. Reword commit message.] Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20240703084704.197697-2-andrei.simion@microchip.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-07-03power: sequencing: simplify returning pointer without cleanupKrzysztof Kozlowski
Use 'return_ptr' helper for returning a pointer without cleanup for shorter code. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240703083038.95777-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-07-03phy: renesas: phy-rcar-gen3-usb2: Control VBUS for RZ/G2L SoCsBiju Das
Use regulator_hardware_enable() for controlling VBUS enable for RZ/G2L alike SoCs in interrupt context. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Acked-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20240702180032.207275-4-biju.das.jz@bp.renesas.com Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2024-07-03reset: renesas: Add USB VBUS regulator device as childBiju Das
As per RZ/G2L HW manual, VBUS enable can be controlled by the VBOUT bit of the VBUS Control Register(VBENCTL) register in the USBPHY Control. Expose this register as regmap and instantiate the USB VBUS regulator device, so that consumer can control the vbus using regulator API's Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20240702180032.207275-3-biju.das.jz@bp.renesas.com Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2024-07-03ata: libata-scsi: Check ATA_QCFLAG_RTF_FILLED before using result_tfIgor Pylypiv
qc->result_tf contents are only valid when the ATA_QCFLAG_RTF_FILLED flag is set. The ATA_QCFLAG_RTF_FILLED flag should be always set for commands that failed or for commands that have the ATA_QCFLAG_RESULT_TF flag set. Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Link: https://lore.kernel.org/r/20240702024735.1152293-8-ipylypiv@google.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-07-03ata: libata-core: Set ATA_QCFLAG_RTF_FILLED in fill_result_tf()Igor Pylypiv
ATA_QCFLAG_RTF_FILLED is not specific to ahci and can be used generally to check if qc->result_tf contains valid data. Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Link: https://lore.kernel.org/r/20240702024735.1152293-7-ipylypiv@google.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-07-03ata: libata-scsi: Do not pass ATA device id to ata_to_sense_error()Igor Pylypiv
ATA device id is not used in ata_to_sense_error(). Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Link: https://lore.kernel.org/r/20240702024735.1152293-6-ipylypiv@google.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-07-03ata: libata-scsi: Remove redundant sense_buffer memsetsIgor Pylypiv
SCSI layer clears sense_buffer in scsi_queue_rq() so there is no need for libata to clear it again. Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Link: https://lore.kernel.org/r/20240702024735.1152293-5-ipylypiv@google.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-07-03ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no errorIgor Pylypiv
SAT-5 revision 8 specification removed the text about the ANSI INCITS 431-2007 compliance which was requiring SCSI/ATA Translation (SAT) to return descriptor format sense data for the ATA PASS-THROUGH commands regardless of the setting of the D_SENSE bit. Let's honor the D_SENSE bit for ATA PASS-THROUGH commands while generating the "ATA PASS-THROUGH INFORMATION AVAILABLE" sense data. SAT-5 revision 7 ================ 12.2.2.8 Fixed format sense data Table 212 shows the fields returned in the fixed format sense data (see SPC-5) for ATA PASS-THROUGH commands. SATLs compliant with ANSI INCITS 431-2007, SCSI/ATA Translation (SAT) return descriptor format sense data for the ATA PASS-THROUGH commands regardless of the setting of the D_SENSE bit. SAT-5 revision 8 ================ 12.2.2.8 Fixed format sense data Table 211 shows the fields returned in the fixed format sense data (see SPC-5) for ATA PASS-THROUGH commands. Cc: stable@vger.kernel.org # 4.19+ Reported-by: Niklas Cassel <cassel@kernel.org> Closes: https://lore.kernel.org/linux-ide/Zn1WUhmLglM4iais@ryzen.lan Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20240702024735.1152293-4-ipylypiv@google.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-07-03ata: libata-scsi: Do not overwrite valid sense data when CK_COND=1Igor Pylypiv
Current ata_gen_passthru_sense() code performs two actions: 1. Generates sense data based on the ATA 'status' and ATA 'error' fields. 2. Populates "ATA Status Return sense data descriptor" / "Fixed format sense data" with ATA taskfile fields. The problem is that #1 generates sense data even when a valid sense data is already present (ATA_QCFLAG_SENSE_VALID is set). Factoring out #2 into a separate function allows us to generate sense data only when there is no valid sense data (ATA_QCFLAG_SENSE_VALID is not set). As a bonus, we can now delete a FIXME comment in atapi_qc_complete() which states that we don't want to translate taskfile registers into sense descriptors for ATAPI. Additionally, always set SAM_STAT_CHECK_CONDITION when CK_COND=1 because SAT specification mandates that SATL shall return CHECK CONDITION if the CK_COND bit is set. The ATA PASS-THROUGH handling logic in ata_scsi_qc_complete() is hard to read/understand. Improve the readability of the code by moving checks into self-explanatory boolean variables. Cc: stable@vger.kernel.org # 4.19+ Co-developed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Link: https://lore.kernel.org/r/20240702024735.1152293-3-ipylypiv@google.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-07-03ata: libata-scsi: Fix offsets for the fixed format sense dataIgor Pylypiv
Correct the ATA PASS-THROUGH fixed format sense data offsets to conform to SPC-6 and SAT-5 specifications. Additionally, set the VALID bit to indicate that the INFORMATION field contains valid information. INFORMATION =========== SAT-5 Table 212 — "Fixed format sense data INFORMATION field for the ATA PASS-THROUGH commands" defines the following format: +------+------------+ | Byte | Field | +------+------------+ | 0 | ERROR | | 1 | STATUS | | 2 | DEVICE | | 3 | COUNT(7:0) | +------+------------+ SPC-6 Table 48 - "Fixed format sense data" specifies that the INFORMATION field starts at byte 3 in sense buffer resulting in the following offsets for the ATA PASS-THROUGH commands: +------------+-------------------------+ | Field | Offset in sense buffer | +------------+-------------------------+ | ERROR | 3 | | STATUS | 4 | | DEVICE | 5 | | COUNT(7:0) | 6 | +------------+-------------------------+ COMMAND-SPECIFIC INFORMATION ============================ SAT-5 Table 213 - "Fixed format sense data COMMAND-SPECIFIC INFORMATION field for ATA PASS-THROUGH" defines the following format: +------+-------------------+ | Byte | Field | +------+-------------------+ | 0 | FLAGS | LOG INDEX | | 1 | LBA (7:0) | | 2 | LBA (15:8) | | 3 | LBA (23:16) | +------+-------------------+ SPC-6 Table 48 - "Fixed format sense data" specifies that the COMMAND-SPECIFIC-INFORMATION field starts at byte 8 in sense buffer resulting in the following offsets for the ATA PASS-THROUGH commands: Offsets of these fields in the fixed sense format are as follows: +-------------------+-------------------------+ | Field | Offset in sense buffer | +-------------------+-------------------------+ | FLAGS | LOG INDEX | 8 | | LBA (7:0) | 9 | | LBA (15:8) | 10 | | LBA (23:16) | 11 | +-------------------+-------------------------+ Reported-by: Akshat Jain <akshatzen@google.com> Fixes: 11093cb1ef56 ("libata-scsi: generate correct ATA pass-through sense") Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Link: https://lore.kernel.org/r/20240702024735.1152293-2-ipylypiv@google.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-07-03Merge tag 'regulator-hw-enable-helper' of ↵Philipp Zabel
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into reset/next regulator: Add helper to allow enable/disable in interrupt context Add a helper function that enables exclusive consumers to bypass locking and do an enable/disable from within interrupt context. Link: https://lore.kernel.org/r/988df019-00d4-4209-8716-39e82c565bf1@sirena.org.uk Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2024-07-03net: dsa: microchip: lan937x: disable VPHY supportLucas Stach
As described by the microchip article "LAN937X - The required configuration for the external MAC port to operate at RGMII-to-RGMII 1Gbps link speed." [1]: "When VPHY is enabled, the auto-negotiation process following IEEE 802.3 standard will be triggered and will result in RGMII-to-RGMII signal failure on the interface because VPHY will try to poll the PHY status that is not available in the scenario of RGMII-to-RGMII connection (normally the link partner is usually an external processor). Note that when VPHY fails on accessing PHY registers, it will fall back to 100Mbps speed, it indicates disabling VPHY is optional if you only need the port to link at 100Mbps speed. Again, VPHY must and can only be disabled by writing VPHY_DISABLE bit in the register below as there is no strapping pin for the control." This patch was tested on LAN9372, so far it seems to not to affect VPHY based clock crossing optimization for the ports with integrated PHYs. [1]: https://microchip.my.site.com/s/article/LAN937X-The-required-configuration-for-the-external-MAC-port-to-operate-at-RGMII-to-RGMII-1Gbps-link-speed Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>