summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
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>
2024-07-03net: dsa: microchip: lan937x: disable in-band status support for RGMII ↵Lucas Stach
interfaces This driver do not support in-band mode and in case of CPU<->Switch link, this mode is not working any way. So, disable it otherwise ingress path of the switch MAC will stay disabled. Note: lan9372 manual do not document 0xN301 BIT(2) for the RGMII mode and recommend[1] to disable in-band link status update for the RGMII RX path by clearing 0xN302 BIT(0). But, 0xN301 BIT(2) seems to work too, so keep it unified with other KSZ switches. [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> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-03net: dsa: microchip: lan9371/2: add 100BaseTX PHY supportLucas Stach
On the LAN9371 and LAN9372, the 4th internal PHY is a 100BaseTX PHY instead of a 100BaseT1 PHY. The 100BaseTX PHYs have a different base register offset. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-03net: stmmac: enable HW-accelerated VLAN stripping for gmac4 onlyFurong Xu
Commit 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping") enables MAC level VLAN tag stripping for all MAC cores, but leaves set_hw_vlan_mode() and rx_hw_vlan() un-implemented for both gmac and xgmac. On gmac and xgmac, ethtool reports rx-vlan-offload is on, both MAC and driver do nothing about VLAN packets actually, although VLAN works well. Driver level stripping should be used on gmac and xgmac for now. Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping") Signed-off-by: Furong Xu <0x1207@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-03drm/managed: Simplify if conditionThorsten Blum
The if condition !A || A && B can be simplified to !A || B. Fixes the following Coccinelle/coccicheck warning reported by excluded_middle.cocci: WARNING !A || A && B is equivalent to !A || B Compile-tested only. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240701195607.228852-1-thorsten.blum@toblux.com
2024-07-03drm/fbdev-generic: Fix framebuffer on big endian devicesThomas Huth
Starting with kernel 6.7, the framebuffer text console is not working anymore with the virtio-gpu device on s390x hosts. Such big endian fb devices are usinga different pixel ordering than little endian devices, e.g. DRM_FORMAT_BGRX8888 instead of DRM_FORMAT_XRGB8888. This used to work fine as long as drm_client_buffer_addfb() was still calling drm_mode_addfb() which called drm_driver_legacy_fb_format() internally to get the right format. But drm_client_buffer_addfb() has recently been reworked to call drm_mode_addfb2() instead with the format value that has been passed to it as a parameter (see commit 6ae2ff23aa43 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()"). That format parameter is determined in drm_fbdev_generic_helper_fb_probe() via the drm_mode_legacy_fb_format() function - which only generates formats suitable for little endian devices. So to fix this issue switch to drm_driver_legacy_fb_format() here instead to take the device endianness into consideration. Fixes: 6ae2ff23aa43 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()") Closes: https://issues.redhat.com/browse/RHEL-45158 Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240627173530.460615-1-thuth@redhat.com
2024-07-03drm/panthor: Fix sync-only jobsBoris Brezillon
A sync-only job is meant to provide a synchronization point on a queue, so we can't return a NULL fence there, we have to add a signal operation to the command stream which executes after all other previously submitted jobs are done. v2: - Fixed a UAF bug - Added R-bs Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240703071640.231278-3-boris.brezillon@collabora.com
2024-07-03drm/panthor: Don't check the array stride on empty uobj arraysBoris Brezillon
The user is likely to leave all the drm_panthor_obj_array fields to zero when the array is empty, which will cause an EINVAL failure. v2: - Added R-bs Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240703071640.231278-2-boris.brezillon@collabora.com
2024-07-03drm/ast: Use drm_atomic_helper_commit_tail() helperThomas Zimmermann
Ast has no special requirements for runtime power management. So replace drm_atomic_helper_commit_tail_rpm() with the regular helper drm_atomic_helper_commit_tail(). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627153638.8765-9-tzimmermann@suse.de
2024-07-03drm/ast: Inline ast_crtc_dpms() into callersThomas Zimmermann
The function ast_crtc_dpms() is left over from when the ast driver did not implement atomic modesetting. But DPMS is not supported by atomic modesetting and the helper is only called to enable or disable the CRTC sync pulses. Inline the function into its callers. To disable the CRTC, ast sets (AST_DPMS_VSYNC_OFF | AST_DPMS_HSYNC_OFF) in VGACRB6. Replace the constants with the correct register constants for VGACRB6. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627153638.8765-8-tzimmermann@suse.de
2024-07-03drm/ast: Only set VGA SCREEN_DISABLE bit in CRTC codeThomas Zimmermann
The SCREEN_DISABLE bit controls scanout from display memory. The bit affects all planes, so set it only in the CRTC's atomic enable and disable functions. A number of bugs affect this fix. First of all, ast_set_std_regs() tries to set VGASR1 except for the SD bit. But the read bitmask is invert, so it preserves anything except the SD bit. Fix this by re-inverting the read mask. The second issue is that primary-plane and CRTC helpers modify the SD bit. The bit controls scanout for all planes, primary and HW cursor, so set it only in the CRTC code. Further add a constant to represent the SD bit in VGASR1. Keep the plane's atomic_disable around to make the DRM framework happy. v2: - fix typos in commit message Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627153638.8765-7-tzimmermann@suse.de