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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7692ec9b-52d2-4bae-a9af-a7a695b4e8f4@collabora.com>
Date: Mon, 11 Mar 2024 11:45:04 +0100
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Michael Walle <mwalle@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>
Cc: devicetree@...r.kernel.org, Sean Wang <sean.wang@...iatek.com>,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v3 2/2] arm64: dts: mediatek: add Kontron 3.5"-SBC-i1200

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@...nel.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@...labora.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