Re: [PATCH v1] arm64: dts: ti: k3-am62-verdin: Set MMC clock pins as OUTPUT

[Francesco Dolcini <francesco@dolcini.it>]

+Judith

On Thu, Aug 13, 2026 at 11:24:58AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Setting MMC clock pins to PIN_OUTPUT disables the receiver (RXACTIVE=0), which breaks the internal clock loopback required by the MMC controller for read operations.
> --
> 
> --- Patch [1]: [PATCH v1] arm64: dts: ti: k3-am62-verdin: Set MMC clock pins as OUTPUT ---
> commit b7e315f9edd8f485234748a2f8e267539b5b0f30
> Author: Francesco Dolcini <francesco.dolcini@toradex.com>
> 
> arm64: dts: ti: k3-am62-verdin: Set MMC clock pins as OUTPUT
> 
> This commit changes the MMC clock pins for the K3 AM62x Verdin module
> from PIN_INPUT to PIN_OUTPUT to match the TRM documentation, effectively
> disabling the receiver (RXACTIVE = 0).
> 
> Link: https://www.ti.com/lit/pdf/spruiv7 Rev. C: Table 12-246. MMCSDi I/O Signals [0]
> 
> > diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
> > index e97b2b047d104..895b1b7dcac71 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
> > +++ b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
> > @@ -573,7 +573,7 @@ AM62X_IOPAD(0x15c, PIN_INPUT, 0)  /* (AB22) MDIO0_MDIO */ /* ETH_1_MDIO, SODIMM
> >  	pinctrl_sdhci0: main-mmc0-default-pins {
> >  		pinctrl-single,pins = <
> >  			AM62X_IOPAD(0x220, PIN_INPUT,        0) /*  (Y3) MMC0_CMD  */
> > -			AM62X_IOPAD(0x218, PIN_INPUT,        0) /* (AB1) MMC0_CLK  */
> > +			AM62X_IOPAD(0x218, PIN_OUTPUT,       0) /* (AB1) MMC0_CLK  */
> 
> [Severity: High]
> Does configuring this pin as PIN_OUTPUT disable the receiver (RXACTIVE=0) and
> break the internal clock loopback?
> 
> TI MMC controllers generally rely on this internal clock loopback path to
> synchronize incoming data for read operations. While the TRM documents the
> logical direction of the signal to the external card, disabling the input
> receiver might lead to eMMC read failures and timeouts.

Judith: is sashiko right on this?

Thanks,
Francesco