* Re: (subset) [PATCH v4 1/2] dt-bindings: mfd: st,stmpe: Add missing properties for PWM subnode
From: Lee Jones @ 2026-06-11 8:46 UTC (permalink / raw)
To: lee, ukleinek, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, linusw, Manish Baing
Cc: linux-pwm, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, Conor Dooley
In-Reply-To: <20260523173251.72540-2-manishbaing2789@gmail.com>
On Sat, 23 May 2026 17:32:50 +0000, Manish Baing wrote:
> The st,stmpe-pwm binding is already covered by the MFD schema in
> Documentation/devicetree/bindings/mfd/st,stmpe.yaml. However, the
> PWM subnode was missing a 'required' properties block. This allowed
> Device Tree nodes to pass validation even if the 'compatible'
> string was omitted. This omission could lead to probe failures
> at runtime.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: mfd: st,stmpe: Add missing properties for PWM subnode
commit: b07f7904e0523170856876e4412be852377d492a
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support
From: Vishnu Santhosh @ 2026-06-11 8:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, bjorn.andersson,
chris.lew, Vishnu Santhosh
Add required nodes to enable the upstream BAM-DMUX WWAN driver on
Qualcomm Shikra SoC.
The SMSM (Shared Memory State Machine) node provides the power
control signaling between the AP and modem for BAM-DMUX. The
BAM DMA controller node describes the A2 modem BAM hardware as a
standard DMA controller. The BAM-DMUX node references the DMA
channels and the pc/pc-ack interrupt lines from the modem SMSM
entry for power control signaling.
Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 51 ++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..3e59d5f6323c0d857f376316faa26c503e67f6bc 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -17,6 +17,23 @@ / {
#address-cells = <2>;
#size-cells = <2>;
+ bam_dmux: bam-dmux {
+ compatible = "qcom,bam-dmux";
+
+ interrupts-extended = <&modem_smsm 1 IRQ_TYPE_EDGE_BOTH>,
+ <&modem_smsm 11 IRQ_TYPE_EDGE_BOTH>;
+ interrupt-names = "pc",
+ "pc-ack";
+
+ qcom,smem-states = <&apps_smsm 1>,
+ <&apps_smsm 11>;
+ qcom,smem-state-names = "pc",
+ "pc-ack";
+
+ dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
+ dma-names = "tx", "rx";
+ };
+
clocks {
xo_board: xo-board {
compatible = "fixed-clock";
@@ -314,6 +331,28 @@ lmcu_dtb_mem: lmcu-dtb@b4702000 {
};
};
+ smsm {
+ compatible = "qcom,smsm";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mboxes = <0>, <&apcs_glb 13>;
+
+ apps_smsm: apps@0 {
+ reg = <0>;
+ #qcom,smem-state-cells = <1>;
+ };
+
+ modem_smsm: modem@1 {
+ reg = <1>;
+ interrupts = <GIC_SPI 69 IRQ_TYPE_EDGE_RISING 0>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
soc: soc@0 {
compatible = "simple-bus";
@@ -640,6 +679,18 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
};
};
+ bam_dmux_dma: dma-controller@6044000 {
+ compatible = "qcom,bam-v1.7.0";
+ reg = <0x0 0x06044000 0x0 0x19000>;
+ interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
+ #dma-cells = <1>;
+ qcom,ee = <0>;
+
+ num-channels = <6>;
+ qcom,num-ees = <1>;
+ qcom,powered-remotely;
+ };
+
sram@c11e000 {
compatible = "qcom,shikra-imem", "mmio-sram";
reg = <0x0 0x0c11e000 0x0 0x1000>;
---
base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
change-id: 20260603-qcom-shikra-dts-bam-dmux-7fdcbb6fb662
prerequisite-message-id: <20260527-shikra-dt-v4-0-b5ca1fa0b392@oss.qualcomm.com>
prerequisite-patch-id: 3a689e8dda5fd2755b689d94d095806b3f2e6eed
prerequisite-patch-id: 2acc300a68ed8c5364fb5f2f7d28fc0d56ab07bf
prerequisite-patch-id: 2357cac636e019eaf14d6a493a1c72bca56fe405
prerequisite-patch-id: 2885f299e711582da312ca9d13983d296a3dd5dc
prerequisite-patch-id: 91af5f3c01e766a53ce8de69aa21847a2d6bbbf8
Best regards,
--
Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
^ permalink raw reply related
* RE: [PATCH v32 0/5] Add ASPEED AST2600 I2C controller driver
From: Ryan Chen @ 2026-06-11 8:42 UTC (permalink / raw)
To: Ryan Chen, jk@codeconstruct.com.au,
andriy.shevchenko@linux.intel.com, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, william@wkennington.com,
wsa+renesas@sang-engineering.com
Cc: linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, Conor Dooley
In-Reply-To: <20260611-upstream_i2c-v32-0-b66eba921d01@aspeedtech.com>
Hello Andi, Wolfram,
Sorry to bother you, can this i2c patch series can be review?
Ryan
> Subject: [PATCH v32 0/5] Add ASPEED AST2600 I2C controller driver
>
> This series adds support for the AST2600 I2C controller “new register set”
> implementation.
>
> The AST2600 I2C controller introduces a revised register layout which
> separates controller and target functionality into distinct register blocks, and
> extends clock divider configuration and packet-based transfer support
> compared to the legacy mixed register layout used on earlier ASPEED SoCs.
>
> The current driver implementation for the AST2600 I2C peripheral is through
> the hardware's "compatibility mode", which exposes a register set that
> matches the previous generation hardware (AST2500 and earlier).
>
> Instead, add a driver that works in new-register-set mode, to allow the new
> features, and will provide support for future hardware that will not implement
> compatibility mode.
>
> In order to support the new mode, we need a DT binding change to reflect the
> reference to the global register set. Since the binding still represents the same
> (AST2600 SoC) physical hardware, we continue to use the existing compatible
> string of "aspeed,ast2600-i2c-bus".
>
> However: since we're changing semantics for an existing binding, we allow
> backwards compatibility by selecting on presence/absence of the newly-added
> properties, and fall back to the old driver (ie., in compatibility mode) when we
> detect a DT using the old binding spec.
>
> Specifically:
>
> - ast2600-i2c-bus nodes that provide the `aspeed,global-regs` property
> (present in the new binding and absent in the legacy binding) will be
> successfully probed by the new driver
>
> - ast2600-i2c-bus nodes without `aspeed,global-regs` continue to use the
> existing driver (in legacy register mode), ensuring that platforms
> with the current DTBs remain functional
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> Changes in v32:
> - 1/5: add MAINTAINERS entry for aspeed,ast2600-i2c.yaml in the same
> patch that creates the file.
> - 3/5: add if/then conditional schema: when aspeed,global-regs is
> present, require reg to have at least two items. The new driver
> unconditionally maps resource index 1 (the buffer SRAM region); a DT
> with one reg entry and aspeed,global-regs passes schema validation but
> fails probe. The constraint makes the schema consistent with driver
> behaviour.
> - 4/5: address follow-on code review issues:
> - add MAINTAINERS entry for drivers/i2c/busses/i2c-ast2600.c.
> - fix interrupt storm when msgs is NULL: clear PKT_DONE in the IRQ
> handler; per the datasheet this auto-clears all associated status
> bits.
> - fix out-of-bounds: guard msgs_index against msgs_count before
> indexing msgs array in ast2600_i2c_controller_packet_irq().
> - fix use-after-free: WRITE_ONCE() null msgs before complete() in
> all IRQ completion paths so trailing IRQs bail out immediately.
> - fix race in timeout path: null msgs before re-enabling IER so a
> late IRQ cannot access the caller's freed message buffer.
> - fix 0-length SMBus block read hanging the bus: issue STOP via
> CONTROLLER_TRIGGER_LAST_STOP, set stop_pending, poll for
> NORMAL_STOP.
> - initialise clk_div_reg to I2CCG_DIV_CTRL and global_ctrl to 0
> to avoid uninitialized values if regmap_read() fails.
> - guard against clock-frequency = <0> in DT; default to 100 kHz
> to prevent divide-by-zero in ast2600_i2c_ac_timing_config().
> - remove AST2600_I2CM_BUS_RECOVER_FAIL from IER writes; bit 15 is
> Reserved in I2CM10 (IER) and only exists as a status bit in I2CM14.
> - 5/5: address follow-on code review issues:
> - fix target RX data loss in master-abort path: remove BUFF_CTRL
> zeroing that discarded pending target RX data stored in bits [29:24].
> - fix use-after-free in master-abort path: null msgs and re-enable
> IER before complete(), not after, preventing stale IRQ from touching
> the newly-installed msgs of the next transfer.
> - fix shared-buffer corruption on coalesced STOP+SLAVE_MATCH IRQ:
> restore the SLAVE_PENDING guard on target_active = false.
> SLAVE_PENDING
> (bit 29) is set when a new address-match is queued before the previous
> DMA receive completes; clearing target_active in that case allows the
> controller to overwrite the shared Tx/Rx buffer.
> - use READ_ONCE() for all process-context reads of target_active;
> the IRQ path writes it with WRITE_ONCE() and plain loads allow the
> compiler to cache a stale value across the IER-disable window.
> - Link to v31:
> https://lore.kernel.org/r/20260603-upstream_i2c-v31-0-ba7a02714f22@aspee
> dtech.com
> Changes in v31:
> - 1/5: clarify in the commit message that the second reg region is
> optional (minItems: 1), matching the schema change from v30.
> - 2/5: zero-initialise struct i2c_timings so the bus-frequency fallback
> correctly triggers when clock-frequency is absent in the DT.
> - 4/5: fix zero-length RX: ast2600_i2c_setup_buff_rx() now returns
> -EINVAL for xfer_len <= 0, propagated through the controller packet
> IRQ handler to abort the transfer instead of hanging until SW timeout.
> - 4/5: address follow-on code review issues:
> - Guard controller_packet_irq() against NULL msgs (post-timeout UAF).
> - Clamp HW-reported xfer_len via ast2600_i2c_clamp_len() in TX_ACK
> and RX_DONE to prevent out-of-bounds writes on HW length glitches.
> - Use regmap_update_bits() for I2CG_CTRL to avoid clobbering shared
> global bits across parallel bus probes (TOCTOU fix).
> - Fix SMBus block read with recv_len == 0: set controller_xfer_cnt =
> msg->len to satisfy the "msg done" check without an extra 1-byte RX.
> - Mirror the controller timeout sequence in recover_bus() timeout path
> (disable IER, synchronize_irq(), W1C ISR, reset master, restore IER).
> - Remove unused #include <linux/of_device.h>.
> - Remove dead adap.algo_data assignment in probe().
> - 5/5: address follow-on target-mode code review issues:
> - Clear target_active on any STOP (not just STOP without SLAVE_PENDING),
> fixing a deadlock under coalesced IRQ events.
> - Enable target IER in reg_target() rather than unconditionally in
> probe(), matching the disable in unreg_target().
> - Re-arm HW in SLAVE_PENDING|RX_DONE|WAIT_TX_DMA|STOP ISR case
> (missing CMD_STS write left bus SCL-stretched until INACTIVE_TO).
> - Default target ISR case: write TARGET_TRIGGER_CMD instead of
> silently breaking, preventing bus hang on unhandled states.
> - W1C-clear ADDR1/2/3_NAK bits in HW in target_irq() to prevent
> stale NAK bits from bouncing controller transfers with -EBUSY.
> - unreg_target(): write 0 to ADDR_CTRL instead of masking with
> ADDR1_MASK, which left ADDR1_ENABLE (BIT(7)) set after unregister.
> - Link to v30:
> https://lore.kernel.org/r/20260528-upstream_i2c-v30-0-5d4f9adc3530@aspee
> dtech.com
>
> Changes in v30:
> - 1/5: aspeed,ast2600-i2c.yaml: keep backward compatibility for
> existing in-tree AST2600 device trees (Sashiko AI review).
> - reg: add minItems: 1 so legacy single-reg DTs still validate.
> - retain bus-frequency as a deprecated property so DTs that still
> use it are not rejected by unevaluatedProperties: false.
> - 2/5: new patch "i2c: aspeed: Read clock-frequency via
> i2c_parse_fw_timings()". The legacy i2c-aspeed driver now reads
> the standard clock-frequency property first and falls back to
> bus-frequency, avoiding a silent 100 kHz downgrade when a DT
> follows the updated binding but still binds to the legacy
> driver (Sashiko AI review).
> - 4/5: address Sashiko AI code review feedback:
> - Use manual i2c_add_adapter() / i2c_del_adapter() instead of
> devm_i2c_add_adapter() so the adapter is torn down before the
> hardware is disabled in remove(); otherwise client .remove()
> callbacks can fail or hang after FUN_CTRL/IER have been cleared.
> - synchronize_irq() and clear pending IRQ status on the controller
> timeout path to avoid the ISR racing with the next transfer and
> touching freed msgs.
> - Use clamp_t() for AC TIMING divisor / scl_low / scl_high so
> extreme clock-frequency values cannot underflow into the unsigned
> domain and corrupt the AC TIMING register.
> - Derive the RX buffer offset from buf_size instead of hardcoding
> 0x10, since the dual-pool split is configurable.
> - Clamp i2c-scl-clk-low-timeout-us to the TTIMEOUT field's 5-bit
> range (max 31 * 1024us) and emit a dev_warn() instead of letting
> AST2600_I2CC_TTIMEOUT()'s mask silently truncate larger values.
> - Return -EBUSY (not -ENOMEM) for every ast2600_i2c_do_start()
> failure path in the controller packet IRQ handler (NORMAL_STOP,
> TX_ACK, and RX_DONE branches).
> - Advertise I2C_AQ_NO_ZERO_LEN_READ via i2c_adapter_quirks so the
> i2c-core rejects zero-byte reads before they reach the driver.
> The AST2600 packet engine cannot encode a zero-length RX command
> and would otherwise stall waiting for an RX_DONE that never
> arrives.
> - 5/5: address Sashiko AI code review feedback:
> - Force-stop path (target IRQ aborting an in-flight controller
> transfer): disable the controller IER and W1C-clear pending ISR
> before calling complete(), then restore the IER after the
> wake-up. Without the disable/clear sequence the controller IRQ
> handler can race with the target abort path and double-complete
> or touch freed msgs.
> - unreg_target() teardown ordering: disable the target IER first,
> then disable SLAVE_EN / clear ADDR_CTRL, synchronize_irq(), W1C
> pending ISR, and only then NULL i2c_bus->target and clear
> target_active. The old order left IER enabled while target was
> being cleared, allowing an in-flight handler to dereference a
> target pointer the caller had already freed.
> - reg_target() bring-up ordering: assign i2c_bus->target before
> enabling SLAVE_EN. Otherwise an IRQ that fires after SLAVE_EN
> is set but before the pointer is stored finds target == NULL,
> exits without clearing the ISR, and the unmasked event re-fires
> as an IRQ storm.
> - Use writel() instead of writeb() when staging a TX byte into
> the target buffer. The AST2600 buffer SRAM only supports 32-bit
> accesses; byte writes are silently dropped (or, on some
> revisions, raise a bus fault), so a SLAVE_READ_REQUESTED reply
> never reaches the master.
> - reg_target() rejects 10-bit client addresses with
> -EAFNOSUPPORT. AST2600_I2CS_ADDR1 is only a 7-bit field;
> without the check, the high bits of a 10-bit address overflow
> into the adjacent ADDR2 field and silently corrupt a second
> target slot.
> - Initialise the local `u8 value` to 0 in the target packet IRQ
> handler. Its address is passed to i2c_slave_event() for events
> such as I2C_SLAVE_STOP / I2C_SLAVE_READ_REQUESTED; a slave
> backend that reads the byte before writing would otherwise leak
> uninitialised kernel stack.
> - Link to v29:
> https://lore.kernel.org/r/20260415-upstream_i2c-v29-0-317c1a905ae1@aspee
> dtech.com
>
> Changes in v29:
> - 2/4: remove aspeed,enable-dma properties.
> - 3/4: update commit message remove transfer mode selection.
> - 3/4: remove sysfs file.
> - 3/4: remove define I2C_TARGET_MSG_BUF_SIZE and
> AST2600_I2C_DMA_SIZE.
> - 3/4: remove buf_index in struct ast2600_i2c_bus.
> - 3/4, 4/4: remove dma/byte mode, use buffer mode only.
> - 4/4: fix race between unreg_target and IRQ handler.
> - 4/4: move i2cs ier enable from ast2600_i2c_init to probe after master ier
> enable.
> - Link to v28:
> https://lore.kernel.org/r/20260330-upstream_i2c-v28-0-17bdae39c5cb@aspee
> dtech.com
>
> Changes in v28:
> - 2/4: update commit message correspond with aspeed,enable-dma.
> - 2/4: remove aspeed,transfer-mode and add aspeed,enable-dma property
> and description.
> - 2/4: Fix aspeed,enable-dma description to reflect hardware capability
> rather than software behavior.
> - 3/4: Separate xfer_mode_store into distinct parse and availability-check
> steps by introducing ast2600_i2c_xfer_mode_check().
> - 3/4: fix tx dma memcpy source point address.
> - 3/4: Use a temporary variable for
> devm_platform_get_and_ioremap_resource()
> to avoid storing an ERR_PTR in i2c_bus->buf_base; drop the redundant
> NULL assignment in the error path since i2c_bus is kzalloc()ed.
> - 3/4: Add ABI documentation file
> Documentation/ABI/testing/sysfs-driver-ast2600-i2c.
> - 4/4: fix typo condication -> condition.
> - 4/4: fix compile error, when disable CONFIG_I2C_SLAVE.
> - Link to v27:
> https://lore.kernel.org/r/20260324-upstream_i2c-v27-0-f19b511c8c28@aspee
> dtech.com
>
> Changes in v27:
> - 1/4 use aspeed,enable-dma instead aspeed,transfer-mode.
> - 2/4 remove aspeed,transfer-mode selection instad aspeed,transfer-mode
> - 2/4 add sysfs for xfer mode.
> - Link to v26:
> https://lore.kernel.org/r/20260309-upstream_i2c-v26-0-5fedcff8ffe8@aspeedt
> ech.com
>
> Changes in v26:
> - 1/4: binding reworks based on review feedback
> - Link to v25:
> https://lore.kernel.org/r/20260225-upstream_i2c-v25-0-9f4bdd954f3f@aspeed
> tech.com
>
> Changes in v25:
> - Use b4 to send series.
> - Rebase on v7.0-rc1.
> - Clarify cover letter and commit logs based on review feedback.
> - Remove the i2c-aspeed-core multiplexer infrastructure and
> implement driver selection via conditional -ENODEV handling
> in individual probe() functions.
> - 3/4: incorporate review feedback and refactor new driver
> - Link to v24:
> https://lore.kernel.org/r/20251118014034.820988-1-ryan_chen@aspeedtech.c
> om
>
> Changes in v24:
> - aspeed,ast2600-i2c.yaml
> - fix make dt_binding_check blank warning.
> - Link to v23:
> https://lore.kernel.org/all/20251117025040.3622984-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v23:
> - update typo patch (1/4) commit message.
> - aspeed,ast2600-i2c.yaml
> - update reg and description.
> - i2c-ast2600.c controller
> - replace ast2600_select_i2c_clock to ast2600_i2c_ac_timing_config.
> - i2c-ast2600.c target
> - I2C_TARGET_MSG_BUF_SIZE 256 to 4096
> - remove blank line.
> - refine Master comment description to controller
> - Link to v22:
> https://lore.kernel.org/all/20251112085649.1903631-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v22:
> - update patch (1/4) commit message add dts example reason.
> - aspeed,ast2600-i2c.yaml @patch (1/4)
> - rename ast2600-i2c.yaml to aspeed,ast2600-i2c.yaml.
> - update reg, clock-frequency description.
> - aspeed,ast2600-i2c.yaml @patch (2/4)
> - aspeed,transfer-mode, aspeed,transfer-mode add for ast2600.
> - i2c-aspeed-core.c,h @patch (3/4)
> - add i2c-aspeed-core allow both old and new device trees using the
> same compatible string "aspeed,ast2600-i2c-bus".
> - Link to v21:
> https://lore.kernel.org/all/20251027061240.3427875-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v21:
> - update patch (1/4) commit message
> - i2c-ast2600.c
> - move rst to local variable in ast2600_i2c_probe().
> - Link to v20:
> https://lore.kernel.org/all/20251021013548.2375190-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v20:
> - ast2600-i2c.yaml
> - fix warning at make dt_binding_check.
> - Link to v19:
> https://lore.kernel.org/all/20251020013200.1858325-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v19:
> - Split AST2600 binding into its own YAML file
> - Removed `aspeed,ast2600-i2c-bus` from `aspeed,i2c.yaml`
> - Added `aspeed,global-regs` and `aspeed,transfer-mode` to AST2600 binding
> - Link to v18:
> https://lore.kernel.org/all/20250820051832.3605405-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v18:
> - refine patch (1/3) commit message (reason for commit not list.)
> - i2c-ast2600.c
> - remove redundant reset_control_deassert in driver probe.
> - remove reset_control_assert(i2c_bus->rst) in driver remove.
> - Link to v17:
> https://lore.kernel.org/all/20250814084156.1650432-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v17:
> - move i2c new mode register and feature into driver commit message.
> - aspeed,i2c.yaml
> - remove multi-master properties.
> - use aspeed,transfer-mode properties for aspeed,enable-byte/enable-dma.
> -i2c-ast2600.c
> - rename dma_safe_buf to controller_dma_safe_buf.
> - fix ast2600_i2c_recover_bus return overflow warnings.
> - add ast2600_i2c_target_packet_buff_irq unhandle case.
> - add parameter "cmd" in ast2600_i2c_setup_dma_rx,
> ast2600_i2c_setup_buff_rx, ast2600_i2c_setup_byte_rx
> - use reset_control_deassert replace
> devm_reset_control_get_shared_deasserted.
> - useaspeed,transfer-mode properties for transfer mode setting.
> - change compatible = "aspeed,ast2600-i2cv2" to "aspeed,ast2600-i2c-bus".
> - Link to v16:
> https://lore.kernel.org/all/20250224055936.1804279-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v16:
> - aspeed,i2c.yaml: add aspeed,enable-byte properties for force byte mode.
> - i2c-ast2600.c
> - change include asm/unaligned.h to linux/unaligned.h.
> - add reset timeout councter when slave active timeout.
> - modify issue i2c_recovery_bus before slave re-enable.
> - add aspeed,enable-byte properties.
> - Link to v15:
> https://lore.kernel.org/all/20241007035235.2254138-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v15:
> - i2c-ast2600.c
> - add include unaligned.h
> - rename all master -> controller, slave -> target.
> - keep multi-master to align property.
> - remove no used element in ast2600_i2c_bus.
> - Link to v14:
> https://lore.kernel.org/all/20241002070213.1165263-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v14:
> - aspeed,i2c.yaml
> - v13 change people reviewed-by tag, v14 fixed to original people tag,
> modify to Reviewed-by: Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org>
> - struct ast2600_i2c_bus layout optimal.
> - ast2600_select_i2c_clock refine.
> - ast2600_i2c_recover_bus overridden fix.
> - dma_mapping_error() returned error code shadowed modify.
> - buffer register in a 4-byte aligned simplified
> - remove smbus alert
> - Link to v13:
> https://lore.kernel.org/all/20240819092850.1590758-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v13:
> - separate i2c master and slave driver to be two patchs.
> - modify include header list, add bits.h include. remove of*.h
> - modify (((x) >> 24) & GENMASK(5, 0)) to (((x) & GENMASK(29, 24)) >> 24)
> - modify ast2600_select_i2c_clock function implement.
> - modify ast2600_i2c_recover_bus function u32 claim to
> u32 state = readl(i2c_bus->reg_base + AST2600_I2CC_STS_AND_BUFF);
> - Link to v12:
> https://lore.kernel.org/all/20230714074522.23827-1-ryan_chen@aspeedtech.c
> om/
>
> Changes in v12:
> - aspeed,i2c.yaml
> - add Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> - i2c-ast2600.c
> - update include by alphabetical order
> - make just a one TAB and put the last two lines on the single one
> - remove no used timing_table structre
> - remove enum explicit assinment
> - rewritten to avoid this and using loop in ast2600_select_i2c_clock
> - use GENMASK for most 0xffff
> - remove too many parentheses
> - use str_read_write replace read write string
> - remove redundant blank line after ast2600_i2c_bus_of_table
> - fix wrong multi-line style of the comment
> - use macro for i2c standard speeds
> - remove useless noise dev_info
> - Link to v11:
> https://lore.kernel.org/all/20230430041712.3247998-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v11:
> - aspeed,i2c.yaml
> - no change, the same with v10.
> - i2c-ast2600.c
> - modify alert_enable from int -> boolean.
> - modify dbg string recovery -> recover.
> - remove no need to init 0.
> - remove new line after break.
> - remove unneeded empty line.
> - modify dma_alloc_coherent to dmam_alloc_coherent
> - modify probe nomem return dev_err_probe
> - modify i2c_add_adapter to devm_i2c_adapter
> - modify checkpatch: Alignment should match open parenthesis
> - modify checkpatch: braces {} should be used on all arms of this statement
> - modify checkpatch: Unbalanced braces around else statement
> - Link to v10:
> https://lore.kernel.org/all/20230415012848.1777768-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v10:
> - aspeed,i2c.yaml
> - move unevaluatedProperties after allOf.
> - remove extra one blank line.
> - i2c-ast2600.c
> - no change, the same with v8.
> - Link to v9:
> https://lore.kernel.org/all/20230405022825.333246-1-ryan_chen@aspeedtech.
> com/
>
> Changes in v9:
> - aspeed,i2c.yaml
> - backoff to v7.
> - no fix typo in maintainer's name and email. this would be another patch.
> - no remove address-cells, size-cells, this would be another patch.
> - use aspeed,enable-dma property instead of aspeed,xfer-mode selection.
> - fix allOf and else false properties for aspeed,ast2600-i2cv2.
> - i2c-ast2600.c
> - no change, the same with v8
> - Link to v8:
> https://lore.kernel.org/all/20230330073259.485606-1-ryan_chen@aspeedtech.
> com/
>
> Changes in v8:
> - aspeed,i2c.yaml
> - modify commit message.
> - Fix typo in maintainer's name and email.
> - remove address-cells, size-cells.
> - i2c-ast2600.c
> - move "i2c timeout counter" comment description before property_read.
> - remove redundant code "return ret" in probe end.
> - Link to v7:
> https://lore.kernel.org/all/20230327092524.3916389-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v7:
> - aspeed,i2c.yaml
> - Update ASPEED I2C maintainers email.
> - use aspeed,enable-dma property instead of aspeed,xfer-mode selection.
> - fix allOf and else false properties for aspeed,ast2600-i2cv2.
> - i2c-ast2600.c
> - remove aspeed,xfer-mode instead of aspeed,enable-dma mode. buffer
> mode
> is default.
> - remove aspeed,timeout instead of i2c-scl-clk-low-timeout-us for
> timeout setting.
> - Link to v6:
> https://lore.kernel.org/all/20230226031321.3126756-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v6:
> - remove aspeed,i2cv2.yaml, merge to aspeed,i2c.yaml -add support for
> i2cv2 properites.
> - i2c-ast2600.c
> - fix ast2600_i2c_remove ordering.
> - remove ast2600_i2c_probe goto labels, and add dev_err_probe -remove
> redundant deb_dbg debug message.
> - rename gr_regmap -> global_regs
> - Link to v5:
> https://lore.kernel.org/all/20230220061745.1973981-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v5:
> - remove ast2600-i2c-global.yaml, i2c-ast2600-global.c.
> - i2c-ast2600.c
> - remove legacy clock divide, all go for new clock divide.
> - remove duplicated read isr.
> - remove no used driver match
> - fix probe return for each labels return.
> - global use mfd driver, driver use phandle to regmap read/write.
> - rename aspeed,i2c-ast2600.yaml to aspeed,i2cv2.yaml -remove
> bus-frequency.
> - add required aspeed,gr
> - add timeout, byte-mode, buff-mode properites.
> - Link to v4:
> https://lore.kernel.org/all/20230201103359.1742140-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v4:
> - fix i2c-ast2600.c driver buffer mode use single buffer conflit in
> master slave mode both enable.
> - fix kmemleak issue when use dma mode.
> - fix typo aspeed,i2c-ast2600.yaml compatible is "aspeed,ast2600-i2c"
> - fix typo aspeed,i2c-ast2600.ymal to aspeed,i2c-ast2600.yaml
> - Link to v3:
> https://lore.kernel.org/all/20220516064900.30517-1-ryan_chen@aspeedtech.c
> om/
>
> Changes in v3:
> - fix i2c global clock divide default value.
> - remove i2c slave no used dev_dbg info.
> - Link to v2:
> https://lore.kernel.org/all/20220413101735.27678-1-ryan_chen@aspeedtech.c
> om/
>
> Changes in v2:
> - add i2c global ymal file commit.
> - rename file name from new to ast2600.
> aspeed-i2c-new-global.c -> i2c-ast2600-global.c
> aspeed-i2c-new-global.h -> i2c-ast2600-global.h
> i2c-new-aspeed.c -> i2c-ast2600.c
> - rename all driver function name to ast2600.
> - Link to v1:
> https://lore.kernel.org/all/20220323004009.943298-1-ryan_chen@aspeedtech.
> com/
>
> ---
> Ryan Chen (5):
> dt-bindings: i2c: Split AST2600 binding into a new YAML
> i2c: aspeed: Read clock-frequency via i2c_parse_fw_timings()
> dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs properties
> i2c: ast2600: Add controller driver for AST2600 new register set
> i2c: ast2600: Add target mode support
>
> .../bindings/i2c/aspeed,ast2600-i2c.yaml | 88 ++
> .../devicetree/bindings/i2c/aspeed,i2c.yaml | 3 +-
> MAINTAINERS | 2 +
> drivers/i2c/busses/Makefile | 2 +-
> drivers/i2c/busses/i2c-aspeed.c | 24 +-
> drivers/i2c/busses/i2c-ast2600.c | 1290
> ++++++++++++++++++++
> 6 files changed, 1400 insertions(+), 9 deletions(-)
> ---
> base-commit: a293ec25d59dd96309058c70df5a4dd0f889a1e4
> change-id: 20260223-upstream_i2c-ebd07f89739c
>
> Best regards,
> --
> Ryan Chen <ryan_chen@aspeedtech.com>
^ permalink raw reply
* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Andy Shevchenko @ 2026-06-11 8:37 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Alan Stern, linux-acpi, driver-core,
linux-pm, linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam, Chen-Yu Tsai
In-Reply-To: <CAMRc=MdiwQM6yk8FXcc+RisVP2iqWKWzVsn2-Yy6dyJXt-1X=Q@mail.gmail.com>
On Thu, Jun 11, 2026 at 04:20:58AM -0400, Bartosz Golaszewski wrote:
> On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> said:
> > On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
> >> When a USB hub port is connected to a connector in a firmware node
> >> graph, the port itself has a node in the graph.
> >>
> >> Associate the port's firmware node with the USB port's device,
> >> usb_port::dev. This is used in later changes for the M.2 slot power
> >> sequencing provider to match against the requesting port.
> >
> > Okay, would this affect ACPI-based systems? if so, how?
> > Can you elaborate on that, please?
>
> Is it possible that there's an ACPI device node associated with the port like
> on some DT systems? I don't think so and there should be no impact IMO but I
> also don't know enough about ACPI.
The API is agnostic. There is a possibility to have software nodes associated
with the port. I think the best is to be sure that ACPI-aware people who are
experts in USB will check this (Heikki?).
Also note Sashiko complain on reference count leakage.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] tty: serial: Add Cortina-Access UART driver and platform support
From: Arnd Bergmann @ 2026-06-11 8:35 UTC (permalink / raw)
To: Jason Li, Jason Li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <JH0PR01MB5777B84BE8D9987329ABA54BA21B2@JH0PR01MB5777.apcprd01.prod.exchangelabs.com>
On Thu, Jun 11, 2026, at 07:27, Jason Li wrote:
> Hi Arnd,
>
> Your memory is truly amazing; you even remember a submission from a few
> years ago.
No, I just looked up your previous submissions when I saw the new one,
lore.kernel.org never forgets anything ;-)
> Yes, we expect actual end-user products based on these SoCs, and our
> intention is to provide complete upstream support over time. The UART
> driver and DTS support submitted in this series are the first step in
> that effort.
>
> Cortina-System and Cortina-Access are now totally different company.
> Current aarch64 chipset are totally different with legacy gemini
> processor.
> Realtek has many business unit, different BU may have upstream plan but
> they are individual.
> Although Cortina-Access is a wholly-owned subsidiary of Realtek, our
> product development is entirely independent.
Thanks for the information. Please make sure to add something along
these into the changeset text for the initial arm64 patch, along
with a brief description of what type of chip this is
Arnd
^ permalink raw reply
* [PATCH v10] PCI: mediatek: Add support for EcoNet EN7528 SoC
From: Caleb James DeLisle @ 2026-06-11 8:23 UTC (permalink / raw)
To: mani
Cc: linux-pci, linux-mips, naseefkm, ryder.lee, helgaas, lpieralisi,
kwilczynski, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, ansuelsmth, linux-mediatek, devicetree,
linux-kernel, Caleb James DeLisle
In-Reply-To: <qwjq6jt3akjk6m4qp4s7xpqf2kzc3tyhsrmcoqhc3canknauxh@leu5dbmv5ngl>
Add support for the PCIe present on the EcoNet EN7528 (and EN751221) SoCs.
These SoCs have a mix of Gen1 and Gen2 capable ports, but the Gen2 ports
require re-training after startup.
Co-developed-by: Ahmed Naseef <naseefkm@gmail.com>
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
---
This is dubbed v10 because it comes from a patchset which was
already mostly applied.
Link: https://lore.kernel.org/linux-mips/20260521171951.1495781-1-cjd@cjdns.fr/
---
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pcie-mediatek.c | 154 +++++++++++++++++++++++++
2 files changed, 155 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 2247709ef6d6..8a3a31b2bc12 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -209,7 +209,7 @@ config PCI_MVEBU
config PCIE_MEDIATEK
tristate "MediaTek PCIe controller"
- depends on ARCH_AIROHA || ARCH_MEDIATEK || COMPILE_TEST
+ depends on ARCH_AIROHA || ARCH_MEDIATEK || ECONET || COMPILE_TEST
depends on OF
depends on PCI_MSI
select IRQ_MSI_LIB
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 1bb8839c3cb0..95b651ddc355 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -10,11 +10,13 @@
#include <linux/bitfield.h>
#include <linux/clk.h>
#include <linux/delay.h>
+#include <linux/errno.h>
#include <linux/iopoll.h>
#include <linux/irq.h>
#include <linux/irqchip/chained_irq.h>
#include <linux/irqchip/irq-msi-lib.h>
#include <linux/irqdomain.h>
+#include <linux/kconfig.h>
#include <linux/kernel.h>
#include <linux/mfd/syscon.h>
#include <linux/msi.h>
@@ -78,6 +80,7 @@
#define PCIE_CONF_VEND_ID 0x100
#define PCIE_CONF_DEVICE_ID 0x102
+#define PCIE_CONF_REV_CLASS 0x104
#define PCIE_CONF_CLASS_ID 0x106
#define PCIE_INT_MASK 0x420
@@ -90,6 +93,11 @@
#define MSI_MASK BIT(23)
#define MTK_MSI_IRQS_NUM 32
+#define EN7528_HOST_MODE 0x00804201
+#define EN7528_LINKUP_REG 0x50
+#define EN7528_RC0_LINKUP BIT(1)
+#define EN7528_RC1_LINKUP BIT(2)
+
#define PCIE_AHB_TRANS_BASE0_L 0x438
#define PCIE_AHB_TRANS_BASE0_H 0x43c
#define AHB2PCIE_SIZE(x) ((x) & GENMASK(4, 0))
@@ -149,12 +157,15 @@ struct mtk_pcie_port;
* @MTK_PCIE_FIX_DEVICE_ID: host's device ID needed to be fixed
* @MTK_PCIE_NO_MSI: Bridge has no MSI support, and relies on an external block
* @MTK_PCIE_SKIP_RSTB: Skip calling RSTB bits on PCIe probe
+ * @MTK_PCIE_RETRAIN: Retrain link to bridge after startup because some
+ * Gen2-capable devices start as Gen1.
*/
enum mtk_pcie_quirks {
MTK_PCIE_FIX_CLASS_ID = BIT(0),
MTK_PCIE_FIX_DEVICE_ID = BIT(1),
MTK_PCIE_NO_MSI = BIT(2),
MTK_PCIE_SKIP_RSTB = BIT(3),
+ MTK_PCIE_RETRAIN = BIT(4),
};
/**
@@ -760,6 +771,134 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
return 0;
}
+static int mtk_pcie_startup_port_en7528(struct mtk_pcie_port *port)
+{
+ struct mtk_pcie *pcie = port->pcie;
+ struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+ struct resource *mem = NULL;
+ struct resource_entry *entry;
+ u32 val, link_mask;
+ int err;
+
+ entry = resource_list_first_type(&host->windows, IORESOURCE_MEM);
+ if (entry)
+ mem = entry->res;
+ if (!mem)
+ return -EINVAL;
+
+ if (!pcie->cfg) {
+ dev_err(pcie->dev, "EN7528: pciecfg syscon not available\n");
+ return -EINVAL;
+ }
+
+ /* Assert all reset signals */
+ writel(0, port->base + PCIE_RST_CTRL);
+
+ /*
+ * Enable PCIe link down reset, if link status changed from link up to
+ * link down, this will reset MAC control registers and configuration
+ * space.
+ */
+ writel(PCIE_LINKDOWN_RST_EN, port->base + PCIE_RST_CTRL);
+
+ msleep(PCIE_T_PVPERL_MS);
+
+ /* De-assert PHY, PE, PIPE, MAC and configuration reset */
+ val = readl(port->base + PCIE_RST_CTRL);
+ val |= PCIE_PHY_RSTB | PCIE_PERSTB | PCIE_PIPE_SRSTB |
+ PCIE_MAC_SRSTB | PCIE_CRSTB;
+ writel(val, port->base + PCIE_RST_CTRL);
+
+ writel(PCIE_CLASS_CODE | PCIE_REVISION_ID,
+ port->base + PCIE_CONF_REV_CLASS);
+ writel(EN7528_HOST_MODE, port->base);
+
+ link_mask = (port->slot == 0) ? EN7528_RC0_LINKUP : EN7528_RC1_LINKUP;
+
+ /* 100ms timeout value should be enough for Gen1/2 training */
+ err = regmap_read_poll_timeout(pcie->cfg, EN7528_LINKUP_REG, val,
+ !!(val & link_mask), 20,
+ PCI_PM_D3COLD_WAIT * USEC_PER_MSEC);
+ if (err) {
+ dev_err(pcie->dev, "EN7528: port%d link timeout\n", port->slot);
+ return -ETIMEDOUT;
+ }
+
+ /* Activate INTx interrupts */
+ val = readl(port->base + PCIE_INT_MASK);
+ val &= ~INTX_MASK;
+ writel(val, port->base + PCIE_INT_MASK);
+
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ mtk_pcie_enable_msi(port);
+
+ /* Set AHB to PCIe translation windows */
+ val = lower_32_bits(mem->start) |
+ AHB2PCIE_SIZE(fls(resource_size(mem)));
+ writel(val, port->base + PCIE_AHB_TRANS_BASE0_L);
+
+ val = upper_32_bits(mem->start);
+ writel(val, port->base + PCIE_AHB_TRANS_BASE0_H);
+
+ writel(WIN_ENABLE, port->base + PCIE_AXI_WINDOW0);
+
+ if (!IS_BUILTIN(CONFIG_PCIE_MEDIATEK))
+ dev_info(pcie->dev,
+ "module not built-in, Gen2 unavailable even if supported\n");
+
+ return 0;
+}
+
+/**
+ * mtk_pcie_retrain - retrain the root bridge link if needed
+ * @dev: The device, for use in logging
+ * @host: The host bridge which contains the link
+ *
+ * Due to what is likely a hardware bug, some devices (notably EcoNet) start up
+ * as Gen1, and must be retrained once after initial configuration in order to
+ * reach Gen2.
+ *
+ * These devices always self-identify as Gen2 capable, but sometimes the PHY is
+ * only capable of Gen1 operation, and sometimes the PCIe card (e.g. wifi) is
+ * only Gen1 capable. Therefore it is most convenient to retrain every port
+ * after startup.
+ */
+static int mtk_pcie_retrain(struct device *dev, struct pci_host_bridge *host)
+{
+ struct pci_dev *rp;
+ int ret = -ENOENT;
+ u16 lnksta = 0;
+ u32 speed;
+
+ /* Should already have been warned about during startup_port */
+ if (!IS_BUILTIN(CONFIG_PCIE_MEDIATEK))
+ return 0;
+
+ guard(rwsem_read)(&pci_bus_sem);
+
+ for_each_pci_bridge(rp, host->bus) {
+ if (pci_pcie_type(rp) != PCI_EXP_TYPE_ROOT_PORT)
+ continue;
+
+#if IS_BUILTIN(CONFIG_PCIE_MEDIATEK)
+ ret = pcie_retrain_link(rp, true);
+#endif
+
+ if (ret)
+ return dev_err_probe(&rp->dev, ret,
+ "failed to retrain port\n");
+
+ pcie_capability_read_word(rp, PCI_EXP_LNKSTA, &lnksta);
+ speed = lnksta & PCI_EXP_LNKSTA_CLS;
+
+ pci_info(rp, "link retrained, speed %s\n",
+ pci_speed_string(pcie_link_speed[speed]));
+
+ }
+
+ return 0;
+}
+
static void __iomem *mtk_pcie_map_bus(struct pci_bus *bus,
unsigned int devfn, int where)
{
@@ -1173,6 +1312,13 @@ static int mtk_pcie_probe(struct platform_device *pdev)
if (err)
goto put_resources;
+ /*
+ * Ignore error because pci_host_probe() was already called, and in any
+ * case it is possible that the port will still work as Gen1.
+ */
+ if (pcie->soc->quirks & MTK_PCIE_RETRAIN)
+ mtk_pcie_retrain(dev, host);
+
return 0;
put_resources:
@@ -1292,8 +1438,16 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
.quirks = MTK_PCIE_FIX_CLASS_ID | MTK_PCIE_FIX_DEVICE_ID,
};
+static const struct mtk_pcie_soc mtk_pcie_soc_en7528 = {
+ .ops = &mtk_pcie_ops_v2,
+ .startup = mtk_pcie_startup_port_en7528,
+ .setup_irq = mtk_pcie_setup_irq,
+ .quirks = MTK_PCIE_RETRAIN,
+};
+
static const struct of_device_id mtk_pcie_ids[] = {
{ .compatible = "airoha,an7583-pcie", .data = &mtk_pcie_soc_an7583 },
+ { .compatible = "econet,en7528-pcie", .data = &mtk_pcie_soc_en7528 },
{ .compatible = "mediatek,mt2701-pcie", .data = &mtk_pcie_soc_v1 },
{ .compatible = "mediatek,mt7623-pcie", .data = &mtk_pcie_soc_v1 },
{ .compatible = "mediatek,mt2712-pcie", .data = &mtk_pcie_soc_mt2712 },
base-commit: 843044971a5167087a9484f8f6eec81da30f2a71
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 11/12] dt-bindings: clock: qcom,gcc-mdm9607: Use proper address in example
From: Krzysztof Kozlowski @ 2026-06-11 8:31 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Georgi Djakov,
Shawn Guo, Bryan O'Donoghue, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, linux-arm-msm,
linux-clk, linux-kernel, devicetree
In-Reply-To: <20260609-qcom-clk-mdm9607-fixes-v1-11-5e9717faf842@linaro.org>
On Tue, Jun 09, 2026 at 04:14:47PM +0200, Stephan Gerhold wrote:
> Given that this is a dedicated schema for qcom,gcc-mdm9607, we might as
> well use the correct memory addresses in the example. This does not
> affect the validation itself, but will reduce confusion for readers.
>
> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> ---
> Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 10/12] dt-bindings: clock: qcom,gcc-mdm9607: Add missing "clocks" property
From: Krzysztof Kozlowski @ 2026-06-11 8:30 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Georgi Djakov,
Shawn Guo, Bryan O'Donoghue, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, linux-arm-msm,
linux-clk, linux-kernel, devicetree
In-Reply-To: <20260609-qcom-clk-mdm9607-fixes-v1-10-5e9717faf842@linaro.org>
On Tue, Jun 09, 2026 at 04:14:46PM +0200, Stephan Gerhold wrote:
> gcc-mdm9607.c uses "fw_name", so it requires specifying the "xo" and
"gcc-mdm9607.c driver ..."
> "sleep_clk" clock source in the device tree. For some reason, this was
> never documented in the dt-bindings. Nowadays, qcom,gcc-mdm9607 has a
> dedicated schema, so we can just add it to the properties without any
> additional conditionals.
>
> Fixes: 6faa7e4ddce6 ("dt-bindings: clock: Add MDM9607 GCC clock bindings")
> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> ---
> .../devicetree/bindings/clock/qcom,gcc-mdm9607.yaml | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 09/12] dt-bindings: clock: qcom: gcc-mdm9607: Drop incorrect clocks
From: Krzysztof Kozlowski @ 2026-06-11 8:30 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Georgi Djakov,
Shawn Guo, Bryan O'Donoghue, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, linux-arm-msm,
linux-clk, linux-kernel, devicetree
In-Reply-To: <20260609-qcom-clk-mdm9607-fixes-v1-9-5e9717faf842@linaro.org>
On Tue, Jun 09, 2026 at 04:14:45PM +0200, Stephan Gerhold wrote:
> From: Stephan Gerhold <stephan@gerhold.net>
>
> These clocks do not seem to exist, they have no consumers and
> reading/writing to the registers fails. Drop them from the bindings.
>
> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> ---
> include/dt-bindings/clock/qcom,gcc-mdm9607.h | 2 --
> 1 file changed, 2 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: PCI: qcom,pcie-ipq9574: Document the ipq5210 pcie controller
From: Krzysztof Kozlowski @ 2026-06-11 8:28 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, linux-arm-msm, linux-pci,
devicetree, linux-kernel, Varadarajan Narayanan
In-Reply-To: <20260610-ipq9650_pcie_binding-v2-2-69e27a1fbf1c@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 04:30:54PM +0530, Kathiravan Thirumoorthy wrote:
> From: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
>
> Document the ipq5210 PCIe controller using ipq9574 as fallback compatible.
>
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] usb: dwc3: Update nominal max votes for qcom usb
From: sashiko-bot @ 2026-06-11 8:28 UTC (permalink / raw)
To: Akash Kumar; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260611081831.2743464-1-akash.kumar@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] APPS_USB_AVG_BW is incorrectly defined without the MBps_to_icc() conversion macro, passing a severely undersized value to the interconnect framework.
Pre-existing issues:
- [High] If pm_runtime_resume_and_get() fails in dwc3_qcom_remove(), the driver returns early, skipping core unregistration and causing massive resource leaks and potential panics.
--
commit 68d35d27d1f598a1e07e782bd412e6f30d3c6fbf
Author: Akash Kumar <akash.kumar@oss.qualcomm.com>
usb: dwc3: Update nominal max votes for qcom usb
This commit increases nominal max bandwidth votes to improve DDR performance
and handle multiple USB audio use cases without glitches. It updates the
peak interconnect bandwidth from 2500 to 5500 and increases the apps USB
average and peak bandwidth allocations.
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index f43f73ac36ff1..aa43a03f3c7fc 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -46,9 +46,9 @@
> #define USB_MEMORY_AVG_HS_BW MBps_to_icc(240)
> #define USB_MEMORY_PEAK_HS_BW MBps_to_icc(700)
> #define USB_MEMORY_AVG_SS_BW MBps_to_icc(1000)
> -#define USB_MEMORY_PEAK_SS_BW MBps_to_icc(2500)
> -#define APPS_USB_AVG_BW 0
> -#define APPS_USB_PEAK_BW MBps_to_icc(40)
> +#define USB_MEMORY_PEAK_SS_BW MBps_to_icc(5500)
> +#define APPS_USB_AVG_BW 40
[Severity: High]
Should this value be wrapped in the MBps_to_icc macro like the other
bandwidth definitions?
Since icc_set_bw expects values in kBps, defining APPS_USB_AVG_BW as
just 40 without the conversion macro appears to vote for 40 kBps instead
of the intended 40 MBps. Does this unintentionally starve the apps-usb
path instead of improving performance?
> +#define APPS_USB_PEAK_BW MBps_to_icc(80)
>
> /* Qualcomm SoCs with multiport support has up to 4 ports */
> #define DWC3_QCOM_MAX_PORTS 4
This isn't a bug introduced by this patch, but looking at driver unbind
in dwc3_qcom_remove:
drivers/usb/dwc3/dwc3-qcom.c:dwc3_qcom_remove() {
...
if (pm_runtime_resume_and_get(qcom->dev) < 0)
return;
...
}
[Severity: High]
If pm_runtime_resume_and_get fails, does this early return skip
dwc3_core_remove and core unregistration entirely?
Since devres-managed memory for the qcom and dwc structs will still be
freed when the remove callback completes, will leaving debugfs files
active and workqueues (like vbus_draw_work) running result in a
use-after-free if they are accessed later?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: PCI: qcom,pcie-ipq9574: Add IPQ9650 compatible
From: Krzysztof Kozlowski @ 2026-06-11 8:28 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, linux-arm-msm, linux-pci,
devicetree, linux-kernel
In-Reply-To: <20260610-ipq9650_pcie_binding-v2-1-69e27a1fbf1c@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 04:30:53PM +0530, Kathiravan Thirumoorthy wrote:
> Add the IPQ9650 PCIe compatible to the IPQ9574 binding, as the IPQ9650
> controller is compatible with IPQ9574 and uses it as the fallback.
>
> While at it, make the global interrupt as required for IPQ9650.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> .../devicetree/bindings/pci/qcom,pcie-ipq9574.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 06/16] usb: hub: Pass |struct usb_port*| to usb_port_is_power_on()
From: Bartosz Golaszewski @ 2026-06-11 8:25 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-7-wenst@chromium.org>
On Wed, 10 Jun 2026 10:40:40 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
> usb_port_is_power_on() currently takes |struct usb_hub*|, but only needs
> it to tell if the hub/port is SuperSpeed or not.
>
> In a subsequent change, usb_port_is_power_on() needs access to a pwrseq
> state tracking field in |struct usb_port|. Either structure can be used
> to identify whether a port/hub is SuperSpeed or not, as the field in
> |struct usb_port| is inherited from the hub:
>
> port->is_superspeed = hub_is_superspeed(hub)
>
> Replace usb_port_is_power_on()'s |struct usb_hub*| parameter with
> |struct usb_port*| so a subsequent change can use it.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
Makes sense.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: thermal: tsens: add ipq5210 & ipq9650 compatible
From: Krzysztof Kozlowski @ 2026-06-11 8:24 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: amitk, thara.gopinath, rafael, daniel.lezcano, rui.zhang,
lukasz.luba, robh, krzk+dt, conor+dt, linux-pm, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260610081241.1468507-2-varadarajan.narayanan@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 01:42:40PM +0530, Varadarajan Narayanan wrote:
> Add the compatible for the thermal sensors on the ipq5210 and ipq9650. The
> ipq5210 uses ipq5332-tsens as a fallback, while ipq9650 is added as a
> standalone v2 TSENS compatible with combined interrupt.
>
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> ---
> v2: Fix fallback definition
> Include ipq9650 to all applicable constraints
You already sent v2 and received comments yesterday.
Please respond to feedback and version your patches correctly.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Krzysztof Kozlowski @ 2026-06-11 8:21 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260610-pcie-phy-v3-1-334011b378d6@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 04:46:08PM +0530, Varadarajan Narayanan wrote:
> Document the PCIe phys on the ipq5210 platform. The 2 lane phy uses the
> ipq9574 as fallback. The single lane phy is documented separately.
Drop
>
> The ipq5210 has one dual lane and one single lane PCIe phy.
>
> The dual lane phy is similar to the dual lane phy present in ipq9574. Hence
> qcom,ipq5210-qmp-gen3x2-pcie-phy is documented with ipq9574's dual lane phy
> as fallback compatible.
You are repeating the first paragraph.
>
> The single lane phy (qcom,ipq5210-qmp-gen3x1-pcie-phy) is documented as
> specific compatible.
Because? I asked last time - do not repeat the diff. You explain here
why it is not using fallback.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Bartosz Golaszewski @ 2026-06-11 8:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam, Chen-Yu Tsai
In-Reply-To: <ailxrP-_9_NL8qnN@ashevche-desk.local>
On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
>> When a USB hub port is connected to a connector in a firmware node
>> graph, the port itself has a node in the graph.
>>
>> Associate the port's firmware node with the USB port's device,
>> usb_port::dev. This is used in later changes for the M.2 slot power
>> sequencing provider to match against the requesting port.
>
> Okay, would this affect ACPI-based systems? if so, how?
> Can you elaborate on that, please?
>
Is it possible that there's an ACPI device node associated with the port like
on some DT systems? I don't think so and there should be no impact IMO but I
also don't know enough about ACPI.
Bart
^ permalink raw reply
* Re: [PATCH v5 2/2] mfd: arizona: Convert GPIO IRQ handling to descriptors
From: Lee Jones @ 2026-06-11 8:20 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Charles Keepax, patches, linux-kernel, linux-gpio,
devicetree, Bartosz Golaszewski
In-Reply-To: <20260527-mfd-arizona-irq-v5-2-ebeda2e925da@kernel.org>
Couple of Sashiko issues I'd like you to comment on please buddy.
On Wed, 27 May 2026, Linus Walleij wrote:
> Convert the arizona polling GPIO handling to use a GPIO descriptor
> instead of passing a global GPIO number as platform data.
>
> This mechanism is not used in the kernel, but let's preserve
> the mechanism to be nice.
>
> Users can define "irq-gpios" in the devicetree or software node
> for the Arizona chip to provide the GPIO line corresponding to
> the IRQ.
>
> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> ---
> drivers/mfd/arizona-irq.c | 50 +++++++++++++++++++++------------------
> include/linux/mfd/arizona/core.h | 2 ++
> include/linux/mfd/arizona/pdata.h | 5 ----
> 3 files changed, 29 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
> index 544016d420fe..cf8e42662585 100644
> --- a/drivers/mfd/arizona-irq.c
> +++ b/drivers/mfd/arizona-irq.c
> @@ -136,21 +136,19 @@ static irqreturn_t arizona_irq_thread(int irq, void *data)
> dev_err(arizona->dev,
> "Failed to read main IRQ status: %d\n", ret);
> }
> -#ifdef CONFIG_GPIOLIB_LEGACY
> /*
> * Poll the IRQ pin status to see if we're really done
> * if the interrupt controller can't do it for us.
> */
> - if (!arizona->pdata.irq_gpio) {
> + if (!arizona->irq_gpiod) {
> break;
> } else if (arizona->pdata.irq_flags & IRQF_TRIGGER_RISING &&
> - gpio_get_value_cansleep(arizona->pdata.irq_gpio)) {
> + gpiod_get_value_cansleep(arizona->irq_gpiod)) {
[Severity: High]
Does this incorrectly check the logical value of the GPIO instead of the raw
physical state?
The legacy gpio_get_value_cansleep() returned the raw physical state of the
pin. The new gpiod_get_value_cansleep() returns the logical state, which
incorporates the ACTIVE_LOW flag from the devicetree or software node.
Because the IRQ trigger flags describe physical voltage transitions, comparing
these physical flags against a logical value might be incorrect. For example,
if a user defines irq-gpios with GPIO_ACTIVE_LOW for a falling edge interrupt,
a physically low line becomes logically 1, causing the polling condition
!gpiod_get_value_cansleep() to evaluate to 0, which fails to poll when the
interrupt is active.
Conversely, when the line is idle, it evaluates to 1, causing the IRQ handler
to poll infinitely.
Should this use gpiod_get_raw_value_cansleep() to preserve the original
physical semantics?
[Severity: High]
This is a pre-existing issue, but can this loop forever if the GPIO read
returns a negative error code?
gpiod_get_value_cansleep() (and its legacy predecessor) can return a negative
error code (e.g., -EIO) if reading the GPIO state fails over the bus. Since
negative values are non-zero, this evaluates to true for IRQF_TRIGGER_RISING,
setting poll = true and causing an infinite loop in the IRQ handler thread if
the read continues to fail.
Conversely, for IRQF_TRIGGER_FALLING, !(-EIO) evaluates to false, which
immediately aborts the poll.
Could the return value be stored in an integer and explicitly checked for
negative errors before evaluating it as a boolean?
> poll = true;
> } else if (arizona->pdata.irq_flags & IRQF_TRIGGER_FALLING &&
> - !gpio_get_value_cansleep(arizona->pdata.irq_gpio)) {
> + !gpiod_get_value_cansleep(arizona->irq_gpiod)) {
> poll = true;
> }
> -#endif
> } while (poll);
>
> pm_runtime_put_autosuspend(arizona->dev);
> @@ -210,6 +208,7 @@ int arizona_irq_init(struct arizona *arizona)
> const struct regmap_irq_chip *aod, *irq;
> struct irq_data *irq_data;
> unsigned int virq;
> + int gpio_irq;
>
> arizona->ctrlif_error = true;
>
> @@ -350,27 +349,32 @@ int arizona_irq_init(struct arizona *arizona)
> goto err_map_main_irq;
> }
>
> -#ifdef CONFIG_GPIOLIB_LEGACY
> - /* Used to emulate edge trigger and to work around broken pinmux */
> - if (arizona->pdata.irq_gpio) {
> - if (gpio_to_irq(arizona->pdata.irq_gpio) != arizona->irq) {
> - dev_warn(arizona->dev, "IRQ %d is not GPIO %d (%d)\n",
> - arizona->irq, arizona->pdata.irq_gpio,
> - gpio_to_irq(arizona->pdata.irq_gpio));
> - arizona->irq = gpio_to_irq(arizona->pdata.irq_gpio);
> + /*
> + * Used to emulate edge trigger and to work around broken pinmux
> + * define "irq-gpios" in device tree or software node.
> + */
> + arizona->irq_gpiod = devm_gpiod_get_optional(arizona->dev, "irq",
> + GPIOD_IN);
> + if (IS_ERR(arizona->irq_gpiod)) {
> + ret = dev_err_probe(arizona->dev,
> + PTR_ERR(arizona->irq_gpiod),
> + "Error getting IRQ GPIO\n");
> + goto err_main_irq;
> + }
> + if (arizona->irq_gpiod) {
> + gpio_irq = gpiod_to_irq(arizona->irq_gpiod);
> + if (gpio_irq < 0) {
> + ret = dev_err_probe(arizona->dev, gpio_irq,
> + "GPIO IRQ line is invalid\n");
> + goto err_main_irq;
> }
> -
> - ret = devm_gpio_request_one(arizona->dev,
> - arizona->pdata.irq_gpio,
> - GPIOF_IN, "arizona IRQ");
> - if (ret != 0) {
> - dev_err(arizona->dev,
> - "Failed to request IRQ GPIO %d:: %d\n",
> - arizona->pdata.irq_gpio, ret);
> - arizona->pdata.irq_gpio = 0;
> + if (gpio_irq != arizona->irq) {
> + dev_warn(arizona->dev, "IRQ %d does not match GPIO's IRQ %d\n",
> + arizona->irq, gpio_irq);
> + arizona->irq = gpio_irq;
> }
> + gpiod_set_consumer_name(arizona->irq_gpiod, "arizona IRQ");
> }
> -#endif
>
> ret = request_threaded_irq(arizona->irq, NULL, arizona_irq_thread,
> flags, "arizona", arizona);
> diff --git a/include/linux/mfd/arizona/core.h b/include/linux/mfd/arizona/core.h
> index 6d6f96b2b29f..7129651c9af6 100644
> --- a/include/linux/mfd/arizona/core.h
> +++ b/include/linux/mfd/arizona/core.h
> @@ -11,6 +11,7 @@
> #define _WM_ARIZONA_CORE_H
>
> #include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/interrupt.h>
> #include <linux/notifier.h>
> #include <linux/regmap.h>
> @@ -136,6 +137,7 @@ struct arizona {
> struct irq_domain *virq;
> struct regmap_irq_chip_data *aod_irq_chip;
> struct regmap_irq_chip_data *irq_chip;
> + struct gpio_desc *irq_gpiod;
>
> bool hpdet_clamp;
> unsigned int hp_ena;
> diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h
> index d465dcd8c90a..2f980d51cdfa 100644
> --- a/include/linux/mfd/arizona/pdata.h
> +++ b/include/linux/mfd/arizona/pdata.h
> @@ -178,11 +178,6 @@ struct arizona_pdata {
> /** Haptic actuator type */
> unsigned int hap_act;
>
> -#ifdef CONFIG_GPIOLIB_LEGACY
> - /** GPIO for primary IRQ (used for edge triggered emulation) */
> - int irq_gpio;
> -#endif
> -
> /** General purpose switch control */
> unsigned int gpsw;
> };
>
> --
> 2.54.0
>
--
Lee Jones
^ permalink raw reply
* [PATCH] arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl
From: Philipp Zabel @ 2026-06-11 8:18 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Philipp Zabel
Configure HDMI DDC SCL/SDA pins to support reading EDID.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
arch/arm64/boot/dts/freescale/imx8mp-frdm.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
index 5fb9714215bf..f43330d1ff8b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
@@ -562,6 +562,8 @@ MX8MP_IOMUXC_SAI1_RXD0__GPIO4_IO02 0x10
pinctrl_hdmi: hdmigrp {
fsl,pins = <
+ MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c2
+ MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c2
MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x10
>;
};
---
base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
change-id: 20260609-imx8mp-frdm-hdmi-ddc-715a3cd5a9ff
Best regards,
--
Philipp Zabel <p.zabel@pengutronix.de>
^ permalink raw reply related
* [PATCH] usb: dwc3: Update nominal max votes for qcom usb
From: Akash Kumar @ 2026-06-11 8:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Dmitry Baryshkov, Krzysztof Kozlowski, Conor Dooley
Cc: linux-usb, linux-kernel, linux-arm-msm, devicetree
Increase nominal max votes to improve DDR performance and USB audio
use case handling.
Currently, Bandwidth vote for max nominal value is set to 2500,
requiring DDR to run at 1GHz under normal load.
DDR is allowed to run under nominal range at 1.5GHz, which is
consistent across all targets. However, with the current nominal
vote, glitches are observed during multiple audio use cases over USB.
Update the nominal vote to allow DDR to run more
efficiently, enabling simultaneous multiple USB audio use cases
without glitches.
With the existing vote, throughput is around 125MB/s. The updated nominal
value increases throughput to 145MB/s.
Benefits:
Enhanced performance and stability for multiple USB audio use cases.
Improved overall system efficiency with higher throughput. Slight
improvement in the audio KPI from 17.9ms to 16.6ms RTD-USBC.
By implementing this change, we expect to see significant improvements in
both performance and stability, particularly for USB audio use cases,
leading to a more efficient system overall.
Signed-off-by: Akash Kumar <akakum@qti.qualcomm.com>
---
drivers/usb/dwc3/dwc3-qcom.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index f43f73ac36ff..aa43a03f3c7f 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -46,9 +46,9 @@
#define USB_MEMORY_AVG_HS_BW MBps_to_icc(240)
#define USB_MEMORY_PEAK_HS_BW MBps_to_icc(700)
#define USB_MEMORY_AVG_SS_BW MBps_to_icc(1000)
-#define USB_MEMORY_PEAK_SS_BW MBps_to_icc(2500)
-#define APPS_USB_AVG_BW 0
-#define APPS_USB_PEAK_BW MBps_to_icc(40)
+#define USB_MEMORY_PEAK_SS_BW MBps_to_icc(5500)
+#define APPS_USB_AVG_BW 40
+#define APPS_USB_PEAK_BW MBps_to_icc(80)
/* Qualcomm SoCs with multiport support has up to 4 ports */
#define DWC3_QCOM_MAX_PORTS 4
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 04/16] usb: hub: Return actual error from hub_configure() in hub_probe()
From: Bartosz Golaszewski @ 2026-06-11 8:17 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Alan Stern, linux-acpi, driver-core, linux-pm, linux-usb,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam, Bartosz Golaszewski, Greg Kroah-Hartman,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
In-Reply-To: <20260610084053.2059858-5-wenst@chromium.org>
On Wed, 10 Jun 2026 10:40:38 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
> The addition of power sequencing descriptor handling in the USB hub code
> requires dealing with deferred probing from pwrseq_get(). The power
> sequencing provider may not yet be available when the USB hub probes.
>
> Return the actual error code from hub_configure() when it fails, so that
> the driver core can notice the deferred probe request.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: ipq9574: Add missing PCIe global IRQs
From: Konrad Dybcio @ 2026-06-11 8:16 UTC (permalink / raw)
To: Kathiravan Thirumoorthy, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260610-ipq9574_pcie_global_irq-v1-1-6d6333b95c43@oss.qualcomm.com>
On 6/10/26 6:58 PM, Kathiravan Thirumoorthy wrote:
> IPQ9574 also has the dedicated 'global' IRQ line for each PCIe controller.
> Add the same.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 01/16] device property: Add fwnode_graph_get_port_by_id()
From: Bartosz Golaszewski @ 2026-06-11 8:15 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Alan Stern, linux-acpi, driver-core, linux-pm, linux-usb,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam, Bartosz Golaszewski, Greg Kroah-Hartman,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
In-Reply-To: <20260610084053.2059858-2-wenst@chromium.org>
On Wed, 10 Jun 2026 10:40:35 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
> In some cases the driver needs a reference to the port firmware node.
> Once such case is the upcoming USB power sequencing integration. The
> USB hub port is tied to the corresponding port firmware node if it
> exists.
>
> Provide a helper for this.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 02/21] pinctrl: pinconf-generic: Add property 'input-debounce-ns'
From: Linus Walleij @ 2026-06-11 8:10 UTC (permalink / raw)
To: Conor Dooley
Cc: Changhuang Liang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Emil Renner Berthing, Paul Walmsley, Albert Ou, Palmer Dabbelt,
Alexandre Ghiti, Philipp Zabel, Bartosz Golaszewski, linux-gpio,
linux-kernel, devicetree, linux-riscv, Lianfeng Ouyang
In-Reply-To: <20260603-sinless-mooing-48a37d3d05ea@spud>
On Wed, Jun 3, 2026 at 5:18 PM Conor Dooley <conor@kernel.org> wrote:
> > PIN_CONFIG_INPUT_DEBOUNCE,
> > + PIN_CONFIG_INPUT_DEBOUNCE_NS,
> > PIN_CONFIG_INPUT_ENABLE,
> > PIN_CONFIG_INPUT_SCHMITT,
> > PIN_CONFIG_INPUT_SCHMITT_ENABLE,
>
> Should this grow a mutual exclusion check in parse_fw_cfg()?
> Part of me says yes for consistency, but also as this is a new property
> that's going to have had exclusion in the binding from the start part of
> me says that it is unnecessary to add that.
Given that it already has a mutual exclusivity where it matters
most (in the bindings) I feel it's unnecessary. The only beneficials
would be out-of-tree users and I actively don't care about these
people.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: interrupt-controller: ti,irq-crossbar: Convert to DT schema
From: sashiko-bot @ 2026-06-11 8:08 UTC (permalink / raw)
To: Bhargav Joshi; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260611-crossbar-v2-1-231d4f88298e@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Incorrect property name referenced in the description of `ti,irqs-skip`. The description refers to `ti,crossbar-irqs-reserved` instead of the actual property name `ti,irqs-reserved`.
--
commit 19def91a21d8fc01d4494e60735ef7f90bf2fedd
Author: Bhargav Joshi <j.bhargav.u@gmail.com>
dt-bindings: interrupt-controller: ti,irq-crossbar: Convert to DT schema
This commit converts the TI irq-crossbar binding from text format to DT schema.
It also adds the missing '#interrupt-cells' property and moves the binding into
the interrupt-controller directory.
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,irq-crossbar.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,irq-crossbar.yaml
> new file mode 100644
> index 0000000000000..ec9a33511aae3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,irq-crossbar.yaml
[ ... ]
> + ti,irqs-reserved:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + List of the reserved irq lines that are not muxed using crossbar. These
> + interrupt lines are reserved in the soc, so crossbar bar driver should not
> + consider them as free lines.
> +
> + ti,irqs-skip:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Similar to "ti,crossbar-irqs-reserved", but these are for SOC-specific
[Severity: Low]
This isn't a bug, but there is a typo in the property name referenced here. The
original text binding correctly referred to "ti,irqs-reserved", but it was
mistakenly changed to "ti,crossbar-irqs-reserved" during the conversion. Should
this reference the actual property name "ti,irqs-reserved"?
> + hard-wiring of those irqs which unexpectedly bypasses the crossbar. These
> + irqs have a crossbar register, but still cannot be used.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-crossbar-v2-1-231d4f88298e@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: sashiko-bot @ 2026-06-11 8:06 UTC (permalink / raw)
To: Xianwei Zhao via B4 Relay
Cc: robh, conor+dt, linux-amlogic, neil.armstrong, devicetree
In-Reply-To: <20260611-gpio-to-irq-v1-1-12201716f23f@amlogic.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The newly added `hw-irq` property is not marked as required for the GPIO banks, and the example is not updated.
- [Medium] The custom device tree property `hw-irq` lacks a vendor prefix.
- [Low] The newly added `hw-irq` property lacks a description field.
--
commit 779e29b8c4c1e37224d568880fcfcc77220c1d72
Author: Xianwei Zhao <xianwei.zhao@amlogic.com>
dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
Add the hw-irq property for each GPIO bank and enable interrupt-parent
for pinctrl so that gpiod_to_irq() can translate GPIO lines to IRQs.
> diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
> --- a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
[ ... ]
> @@ -65,6 +67,9 @@ patternProperties:
> gpio-ranges:
> maxItems: 1
>
> + hw-irq:
> + $ref: /schemas/types.yaml#/definitions/uint32
[Severity: Medium]
Should this custom property have a vendor prefix to prevent namespace
collisions, such as amlogic,hw-irq?
[Severity: Low]
Would it be helpful to include a description field here to document the
purpose and semantic usage of this new property?
> +
> required:
> - reg
> - reg-names
[Severity: Medium]
The commit message indicates this property is added for each GPIO bank.
Should hw-irq be included in this required list under the
patternProperties:^gpio@[0-9a-f]+$ node to ensure incomplete configurations
fail schema validation?
Additionally, the example at the bottom of the file doesn't seem to include
this new property:
examples:
...
gpio@4240 {
reg = <0 0x4240 0 0x40>, <0 0x4000 0 0x8>;
reg-names = "gpio", "mux";
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&periphs_pinctrl 0 8 10>;
};
Does the example section need to be updated to demonstrate the usage of the
newly added property?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-gpio-to-irq-v1-0-12201716f23f@amlogic.com?part=1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox