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: <71cc71a2-7872-419f-8413-dba3b7313894@collabora.com>
Date: Tue, 15 Apr 2025 12:57:16 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: frank-w@...lic-files.de, Daniel Golle <daniel@...rotopia.org>
Cc: Frank Wunderlich <linux@...web.de>,
 Matthias Brugger <matthias.bgg@...il.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH v2] arm64: dts: mediatek: mt7988a-bpi-r4: allow hw
 variants of bpi-r4

Il 15/04/25 12:30, Frank Wunderlich ha scritto:
> Am 15. April 2025 11:56:37 MESZ schrieb AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>:
>> Il 15/04/25 10:07, Frank Wunderlich ha scritto:
>>> Am 15. April 2025 09:36:43 MESZ schrieb AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>:
>>>> Il 14/04/25 14:32, Daniel Golle ha scritto:
>>>>> On Mon, Apr 14, 2025 at 11:27:23AM +0200, AngeloGioacchino Del Regno wrote:
>>>>>> Il 12/04/25 12:21, Frank Wunderlich ha scritto:
>>>>>>> From: Frank Wunderlich <frank-w@...lic-files.de>
>>>>>>>
>>>>>>> Sinovoip has released other variants of Bananapi-R4 board.
>>>>>>> The known changes affecting only the LAN SFP+ slot which is replaced
>>>>>>> by a 2.5G phy with optional PoE.
>>>>>>>
>>>>>>> Just move the common parts to a new dtsi and keep differences (only
>>>>>>> i2c for lan-sfp) in dts.
>>>
>>>>>> This should at least have some different compatible, if not probably also a
>>>>>> different model string - as it's a different device.
>>>>>>
>>>>>> 	compatible = "bananapi,bpi-r4-2g5", "bananapi,bpi-r4", "mediatek,mt7988a";
>>>>>
>>>>> Imho it doesn't make sense to declare compatibility with the
>>>>> "bananapi,bpi-r4" as the "bananapi,bpi-r4-2g5" is NOT compatible with the
>>>>> "bananapi,bpi-r4". It's a different board and using firmware meant for the
>>>>> "bananapi,bpi-r4-2g5" on the "bananapi,bpi-r4" (or vice versa) will result
>>>>> in a non-working Ethernet port.
>>>>>
>>>>
>>>> Is this device a BananaPi R4 variant, or is it a completely different device?
>>>
>>> The only difference is that sfp-lan is replaced by RJ45 socket with mt7988 internal phy.
>>>
>>
>> Perfect, then:
>> - The only difference is one routing
>>    - The base board is the same
>>    - Same hw project
>>      - The two machines are compatible with each other
>>        ...bar one difference
>>
>> ...then the compatibles shall be as I said before :-)
>>
>>>> If this is a completely different device, then it's not even a BananaPi R4,
>>>> otherwise this is compatible with BananaPi R4, with a small variation :-)
>>>
>>> Sinovoip now announces a R4Pro with some more changes (e.g. an external 2.5g switch),but we have no detailed shematic yet. It looks they also plan a R4lite which is based on different SoC (afair mt7987),but this is for sure different device (and so not using this bpi-r4.dtsi).
>>
>> In that case, R4Lite shall not be compatible with R4, as the name may be the
>> same, but in practice it's a different machine.
>>
>>>
>>> But basicly all are named BPi-R4. I guess R4Pro will also get own dts as too much changed.
>>
>> If R4pro is a redesign of the R4 board, that would not be compatible, as it
>> would not be the same base design; otherwise, I'm sure you have well understood
>> how it works for the compatibles, anyway :D
> 
> Yes, should i use 3 const in the binding (as i do not expect another hw variant of current R4) or still enum for the first compatible?

Use 3 consts please :-)

Besides, if a variant comes up later, we can always change the first const
to an enum, so no worries.

> 
>> Cheers!
>>
>>>
>>>> Cheers,
>>>> Angelo
>>>
>>>
>>> regards Frank
>>
>>
> 
> 
> regards Frank



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ