summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
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
2024-07-03drm/ast: Remove gamma LUT updates from DPMS codeThomas Zimmermann
The DPMS code, called from the CRTC's atomic_enable, rewrites the gamma LUT. This is already done by the CRTC's atomic_flush. Remove the duplication. v2: - fix a typo 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-6-tzimmermann@suse.de
2024-07-03drm/ast: Handle primary-plane format setup in atomic_updateThomas Zimmermann
Several color registers are programmed in the DPMS code of the CRTC's atomic_enable helper and the primary plane's atomic_update. It requires the color format and the display mode. Both code paths handle different cases: the DPMS's code will not be executed if the color format changes without a full mode switch. The plane's code only runs if the color format changes, but ignores display-mode changes. The color format is a property of the primary plane, so consolidate all color-format code in the plane's atomic_update. Remove it from the DPMS helper. v2: - clarify commit message (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627153638.8765-5-tzimmermann@suse.de
2024-07-03drm/ast: Move mode-setting code into mode_set_nofb CRTC helperThomas Zimmermann
Do all mode setting in ast_crtc_helper_mode_set_nofb(), which always runs after disabling the CRTC and before programming the planes. Removes implicit synchronization between the CRTC's atomic disable, enable and the vertical retrace. Display-mode updates require HW cursors to be disabled. The HW cursor only picks up changes at vertical retrace periods. So the CRTC's atomic_disable helper waited for the retrace to delay any following mode-setting operations, which then happened in atomic_enable. See [1] for a description of the problem. With the CRTC helper callback mode_set_nofb, we can now synchronize and reprogram in the same place. As it always runs before the plane update, the plane code can be reordered with the CRTC's later atomic_enable et al. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/series/79914/ # 1 Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627153638.8765-4-tzimmermann@suse.de
2024-07-03drm/ast: Program mode for AST DP in atomic_mode_setThomas Zimmermann
The CRTC's atomic_flush function contains code to program the display mode to the AST DP chip. Move the code to the encoder's atomic_mode_set callback. The DRM atomic-modesetting code invoke this callback as part of the atomic commit. 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-3-tzimmermann@suse.de
2024-07-03drm/ast: Implement atomic enable/disable for encodersThomas Zimmermann
The CRTC helpers contain code to enable and disable DisplayPort connectors. Implement this functionality in the respective connector's atomic_enable/atomic_disable callbacks. DRM's atomic-modesetting helpers will call the functions as part of the atomic commit. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627153638.8765-2-tzimmermann@suse.de
2024-07-03power: supply: cros_charge-control: Avoid accessing attributes out of boundsNathan Chancellor
Clang warns (or errors with CONFIG_WERROR=y): drivers/power/supply/cros_charge-control.c:319:2: error: array index 3 is past the end of the array (that has type 'struct attribute *[3]') [-Werror,-Warray-bounds] 319 | priv->attributes[_CROS_CHCTL_ATTR_COUNT] = NULL; | ^ ~~~~~~~~~~~~~~~~~~~~~~ drivers/power/supply/cros_charge-control.c:49:2: note: array 'attributes' declared here 49 | struct attribute *attributes[_CROS_CHCTL_ATTR_COUNT]; | ^ 1 error generated. In earlier revisions of the driver, the attributes array in cros_chctl_priv had four elements with four distinct assignments but during review, the number of elements was changed to three through use of an enum and the assignments became a for loop, except for this one, which is now out of bounds. This assignment is no longer necessary because the size of the attributes array no longer accounts for it, so just remove it to clear up the warning. Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240702-cros_charge-control-fix-clang-array-bounds-warning-v1-1-ae04d995cd1d@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-07-03drm/exynos/vidi: convert to struct drm_edidJani Nikula
Prefer the struct drm_edid based functions for storing the EDID and updating the connector. It would be better if the vidi connection ioctl passed in the EDID size separately instead of relying on the extension count specified in the EDID, but that's what we have to rely on. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-07-03drm/exynos/vidi: simplify fake edid handlingJani Nikula
Avoid assigning fake_edid_info to ctx->raw_edid. Always keep ctx->raw_edid either an allocated pointer or NULL. Defer fake_edid_info handling to .get_modes(). This should be functionally equivalent but slightly easier to follow. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-07-03drm/exynos/vidi: use drm_edid_duplicate()Jani Nikula
Don't open code drm_edid_duplicate(). While at it, drop the error message on allocation failure. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-07-03Merge tag 'exynos-drm-fixes-for-v6.10-rc4' of ↵Inki Dae
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next Regression fix - Fix an regression issue by adding 640x480 fallback mode for Exynos HDMI driver. Bug fix - Fix a memory leak by ensuring the duplicated EDID is properly freed in the get_modes function. Code cleanup - Remove redundant driver owner initialization since platform_driver_register() sets it automatically.
2024-07-02net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from ↵Dave Jiang
__netif_rx() The following is emitted when using idxd (DSA) dmanegine as the data mover for ntb_transport that ntb_netdev uses. [74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526 [74412.556784] caller is netif_rx_internal+0x42/0x130 [74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5 [74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024 [74412.581699] Call Trace: [74412.584514] <TASK> [74412.586933] dump_stack_lvl+0x55/0x70 [74412.591129] check_preemption_disabled+0xc8/0xf0 [74412.596374] netif_rx_internal+0x42/0x130 [74412.600957] __netif_rx+0x20/0xd0 [74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev] [74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport] [74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport] [74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd] [74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd] [74412.634046] irq_thread_fn+0x21/0x60 [74412.638134] ? irq_thread+0xa8/0x290 [74412.642218] irq_thread+0x1a0/0x290 [74412.646212] ? __pfx_irq_thread_fn+0x10/0x10 [74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10 [74412.656117] ? __pfx_irq_thread+0x10/0x10 [74412.660686] kthread+0x100/0x130 [74412.664384] ? __pfx_kthread+0x10/0x10 [74412.668639] ret_from_fork+0x31/0x50 [74412.672716] ? __pfx_kthread+0x10/0x10 [74412.676978] ret_from_fork_asm+0x1a/0x30 [74412.681457] </TASK> The cause is due to the idxd driver interrupt completion handler uses threaded interrupt and the threaded handler is not hard or soft interrupt context. However __netif_rx() can only be called from interrupt context. Change the call to netif_rx() in order to allow completion via normal context for dmaengine drivers that utilize threaded irq handling. While the following commit changed from netif_rx() to __netif_rx(), baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."), the change should've been a noop instead. However, the code precedes this fix should've been using netif_rx_ni() or netif_rx_any_context(). Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Reported-by: Jerry Dai <jerry.dai@intel.com> Tested-by: Jerry Dai <jerry.dai@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20240701181538.3799546-1-dave.jiang@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-02net: phy: aquantia: add missing include guardsBartosz Golaszewski
The header is missing the include guards so add them. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Fixes: fb470f70fea7 ("net: phy: aquantia: add hwmon support") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://patch.msgid.link/20240701080322.9569-1-brgl@bgdev.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-02clk: vexpress-osc: add missing MODULE_DESCRIPTION() macroJeff Johnson
With ARCH=arm64, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/clk/versatile/clk-vexpress-osc.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240613-md-arm64-drivers-clk-versatile-v1-1-6b8a5e5e00ef@quicinc.com Acked-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-07-02clk: disable clk gate tests for s390Audra Mitchell
Currently clk-gate tests for s390 fail as the tests create a pretend clk-gate and use a "fake_reg" to emulate the expected behavior of the clk_gate->reg. I added some debug statements to the driver and noticed that the reg changes after initialization to -1, which is coming from an error coming from zpci_load(). This is likely because the test is using fake iomem and the s390 architecture likely isn't designed to handle that. Turn off the clk-gate tests for s390 for now as there is no clear work around for this problem as discussed in upstream conversation [1]. [1] https://lore.kernel.org/all/301cd41e6283c12ac67fb8c0f8d5c929.sboyd@kernel.org/T/#t Signed-off-by: Audra Mitchell <audra@redhat.com> Link: https://lore.kernel.org/r/20240702125539.524489-1-audra@redhat.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-07-02drm/amdgpu/atomfirmware: silence UBSAN warningAlex Deucher
This is a variable sized array. Link: https://lists.freedesktop.org/archives/amd-gfx/2024-June/110420.html Tested-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2024-07-02drm/amdgpu/atomfirmware: silence UBSAN warningAlex Deucher
This is a variable sized array. Link: https://lists.freedesktop.org/archives/amd-gfx/2024-June/110420.html Tested-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-02drm/amdgpu: fix out of bounds access in gfx11 during ip dumpSunil Khatri
During ip dump in gfx11 the index variable is reused but is not reinitialized to 0 and this causes the index calculation to be wrong and access out of bound access. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-02drm/amdgpu: add firmware for PSP IP v14.0.4Tim Huang
This patch is to add firmware for PSP 14.0.4. Signed-off-by: Tim Huang <Tim.Huang@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-02drm/amdgpu: enable mode2 reset for SMU IP v14.0.4Tim Huang
Set the default reset method to mode2 for SMU 14.0.4. Signed-off-by: Tim Huang <Tim.Huang@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-02drm/amdgpu: add SMU IP v14.0.4 discovery supportTim Huang
This patch is to add SMU 14.0.4 support Signed-off-by: Tim Huang <Tim.Huang@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-02drm/amd/pm: add SMU IP v14.0.4 supportTim Huang
This patch is to add SMU 14.0.4 support. Signed-off-by: Li Ma <li.ma@amd.com> Signed-off-by: Tim Huang <Tim.Huang@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-02drm/amd/pm: smu v14.0.4 reuse smu v14.0.0 dpmtableLi Ma
Replace IP VERSION with smu->is_apu in if condition. And the dpmtable of smu v14.0.4 is same as smu v14.0.0. Signed-off-by: Li Ma <li.ma@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>