Re: [PATCH 05/11] arm64: dts: mediatek: cherry: Add support for internal eMMC storage

["Nícolas F. R. A. Prado" <nfraprado@collabora.com>]

On Thu, Jun 30, 2022 at 05:33:10PM +0200, AngeloGioacchino Del Regno wrote:
> Add mtk-sd controller and pin configuration to enable the internal
> eMMC storage: now it is possible to mount a rootfs located at the
> internal storage.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  .../boot/dts/mediatek/mt8195-cherry.dtsi      | 87 +++++++++++++++++++
>  1 file changed, 87 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> index 091338f7d5ff..8c4b492f774f 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> @@ -9,6 +9,7 @@
>  
>  / {
>  	aliases {
> +		mmc0 = &mmc0;

There was this discussion about adding aliases on dtsi's or not [1]. The
case in favor of adding them in the dtsi seemed stronger, but it wasn't
conclusive... Anyway, I guess it's fine.

[1] https://lore.kernel.org/all/CAD=FV=Wi9xTnWTPbakSnf9rKkiT+4AT=3db-uwhww1bdLKjv9g@mail.gmail.com/

>  		serial0 = &uart0;
>  	};
[..]
> +&pio {
> +	mmc0_pins_default: mmc0-default-pins {
> +		pins-cmd-dat {
> +			pinmux = <PINMUX_GPIO126__FUNC_MSDC0_DAT0>,
> +				 <PINMUX_GPIO125__FUNC_MSDC0_DAT1>,
> +				 <PINMUX_GPIO124__FUNC_MSDC0_DAT2>,
> +				 <PINMUX_GPIO123__FUNC_MSDC0_DAT3>,
> +				 <PINMUX_GPIO119__FUNC_MSDC0_DAT4>,
> +				 <PINMUX_GPIO118__FUNC_MSDC0_DAT5>,
> +				 <PINMUX_GPIO117__FUNC_MSDC0_DAT6>,
> +				 <PINMUX_GPIO116__FUNC_MSDC0_DAT7>,
> +				 <PINMUX_GPIO121__FUNC_MSDC0_CMD>;
> +			input-enable;
> +			drive-strength = <MTK_DRIVE_6mA>;

These MTK_DRIVE_*mA macros map directly to the values, and the drive-strength
property is already standard and defined to take values in mA, so it's better to
use the value directly:

	drive-strength = <6>;

(Likewise below and in some other patches)

Otherwise,

Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Thanks,
Nícolas