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

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

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@kernel.org>
> 
> 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@collabora.com>

...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