linux-kernel - Re: [PATCH RFC v3 0/9] dt-bindings: hwinfo: Introduce board-id

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFLszThO1doxsXSYTrTTPy9QCW4hrBb07k0VdSNWip=4MKtTnA@mail.gmail.com>
Date: Fri, 28 Jun 2024 08:33:03 +0100
From: Simon Glass <sjg@...omium.org>
To: Elliot Berman <quic_eberman@...cinc.com>
Cc: Rob Herring <robh+dt@...nel.org>, Frank Rowand <frowand.list@...il.com>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konrad.dybcio@...aro.org>, 
	Amrit Anand <quic_amrianan@...cinc.com>, Peter Griffin <peter.griffin@...aro.org>, 
	Caleb Connolly <caleb.connolly@...aro.org>, Andy Gross <agross@...nel.org>, 
	Doug Anderson <dianders@...omium.org>, Chen-Yu Tsai <wenst@...omium.org>, 
	Julius Werner <jwerner@...omium.org>, "Humphreys, Jonathan" <j-humphreys@...com>, 
	Sumit Garg <sumit.garg@...aro.org>, Michal Simek <michal.simek@....com>, 
	boot-architecture@...ts.linaro.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH RFC v3 0/9] dt-bindings: hwinfo: Introduce board-id

Hi Elliot,

On Fri, 21 Jun 2024 at 23:40, Elliot Berman <quic_eberman@...cinc.com> wrote:
>
> Hi Simon,
>
> On Thu, Jun 06, 2024 at 10:00:54AM -0600, Simon Glass wrote:
> > On Wed, 5 Jun 2024 at 11:17, Elliot Berman <quic_eberman@...cinc.com> wrote:
> > > On Wed, Jun 05, 2024 at 07:17:35AM -0600, Simon Glass wrote:
> > > > Hi Elliot,
> > > >
> > > > I am just picking up the discussion here, which was started on another thread.
> > > >
> > > > I can't see why this new feature is needed. We should be able to use
> > > > compatible strings, as we do now. I added a 'usage' section to the FIT
> > > > spec [1] which might help. I also incorporated the board revision and
> > > > variant information and some notes on how to add to the available
> > > > suffixes.
> > > >
> > > > Does that handle your use case?
> > >
> > > -rev and -sku don't fit the versioning scheme for QTI devices, so this
> > > isn't a generic enough approach. Patch 5 in this series describes the
> > > versioning scheme for us.
> > >
> > > In the other thread, we had talked about using some regex based approach
> > > for matching the root node compatible. I haven't had chance to work on
> > > that proposal and will try to get to it in the next couple weeks.
> >
> > OK, I look forward to it. Please do check the FIT best match approach
> > and see how it might be extended to handle your requirements. So far I
> > have not seen a need for regexes, but it is certainly a possibility.
> >
>
> I spent some time collecting feedback from the team on using compatible
> strings + regex-style approach and we're not able to add a regex library
> into firmware, so this approach unfortunately won't work for us.
> Because we have more axes of board identification than chromebook, using
> FIT's compatible strings isn't a scalable solution for us. I don't think
> we have incompatible problems, we only have more than 2-3 axes of
> information.

I understand that. I assume that you have a lot of devices that use
the same SoC but different PMICs, displays, etc. Some of these can be
handled in the bootloader, e.g. by detecting hardware and applying an
overlay, or enabling/disabling a node in the DT. It can be useful to
have a hardware-readable ID to indicate things which cannot be probed,
e.g. with GPIOs or ADC + resistors.

Another option is to give names to your projects, so that machines
with the same SoC but major hardware differences end up with a
different name (see rk3399-xx.dts for examples).

I'm sure you are already doing some/all of these things. I still feel
(so far) that you don't need to invent something new here.

Re "FIT's compatible strings isn't a scalable solution for us", how is
what you are doing different from other vendors? Is it the sheer
number of variations, or something else?

Regards,
Simon