Re: [PATCH v3 2/2] arm64: dts: mediatek: add Kontron 3.5"-SBC-i1200

[AngeloGioacchino Del Regno]

Il 11/03/24 09:44, Michael Walle ha scritto:
> Hi,
>
> On Wed Feb 21, 2024 at 4:59 PM CET, Michael Walle wrote:
> > Add basic support for the Kontron 3.5" single board computer featuring a
> > Mediatek i1200 SoC (MT8395/MT8195).
> >
> > Signed-off-by: Michael Walle <mwalle@xxxxxxxxxx>
>
> Any feedback on this? Should I repost after the merge window or is
> it fine as it is for now?

My feedback is

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx>

..and no there's no need to repost after the merge window, at least, I'm not picky
about that.

Though, if I ever forget about this one for *whatever reason*, please feel free to
ping me or Matthias about it and we will make sure to pick it up.

Cheers!
Angelo

> -michael
>
> > ---
> > v3:
> > - add vsys regulator
> > - correct the LDO input of the mt6360 regulator
> > - add missing interrupt-cells
> > - no underscores in node names
> > - dropped regulator-compatible everywhere and use the correc node name
> >    instead
> > - reordered mmc0 properties
> > - split mmc1 pinctrl properties, add no-mmc
> > - removed all MTK_DRIVE_8mA
> > - add i2c0 and i2c1
> > - add comments for spi and i2c busses
> > - add firmware-name property for scp (this should probably go into the
> >    base dtsi?!)
> > - add missing tpm compatible
> > - renamed thermal zones to something more meaningful
> > - add correct bias-pull-up to (some) i2c busses
> > - moved reset handling into the PHY node, also added a compatible string
> >    for the PHY.
> >
> > Mh, my memory is hazy, but IIRC I run into the same problem which was
> > discussed on netdev some time ago. That is, the PHY driver cannot be
> > probed unless it is taken out of reset. Which will only happen if you
> > probe it. And the workaround/advise was to use the compatible string in
> > that case, which is unfortunate.
> > Just wanted to point out, that it is *not* the same as snps,reset-*
> > because the latter will work just fine without the compatible. I'll
> > go with the compatible for now.
> >
> > I did *not* add the vbus to the USB ports, not even on the front port.
> > That is because of:
> >    dependencies:
> >      connector: [ usb-role-switch ]
> > and we just have a simple USB3.2 USB-A connector, no dual roles. IMHO
> > that is a bug in the driver, which should handle the vbus supply as
> > optional.
> >
> > v2:
> > - none