[PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada 388 clearfog boards

[Conor Dooley]

On Sun, Dec 24, 2023 at 03:58:14PM +0000, Josua Mayer wrote:
> Am 24.12.23 um 15:42 schrieb Conor Dooley:
> 
> On Sun, Dec 24, 2023 at 03:38:45PM +0100, Josua Mayer wrote:
> 
> 
> Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
> boards.
> 
> While they are just two variants, we have 3 device-tree:
> - armada-388-clearfog.dts
> - armada-388-clearfog-base.dts
> - armada-388-clearfog-pro.dts
> 
> While the first one is identical to the pro variant, the filename is
> not, and neither are the compatible strings.
> 
> The first is compatible to armada-380, 385, 388 and
> solidrun,clearfog-a1.
> The other two are compatible to the same, plus an additional string
> including the pro/base as suffix.
> 
> Add two bindings, one for the explicit pro and base variants using a
> total of 5 compatibles, and one for the generic name using just 4.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com><mailto:josua at solid-run.com>
> 
> 
> 
> There's nothing here that explains to me _why_ there are three sets of
> compatibles for only two boards. Why is this the case?
> 
> I have no idea how we ended up with these 3 combinations:
> clearfog-a1, armada388, ...
> clearfog-base-a1, clearfog-base-a1, armada388, ...
> clearfog-pro-a1, clearfog-base-a1, armada388, ...
> I can only assume it is because these boards are so similar they can boot
> from each others device-tree without large functional impact.

I think Krzysztof has dug more into this, but please just create two
combinations that make sense and have common elements (which they
already do to be fair). It doesn't really matter if some combination
that doesn't make sense is used out of tree.

Cheers,
Conor.

> 
> Note we did end up with 3 individual filenames because the Pro was supported first,
> without a suffix - and then both were supported with specific suffix.
> 
> 
> Also, binding patches need to be sent to the devicetree mailing list.
> get_maintainer.pl should have told you that, no?
> 
> I will fix it in v3, or do a resend.
> It did tell me, but I wrongly decided to pick only linux-arm-kernel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231226/ff840862/attachment.sig>