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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 28 Jun 2024 at 08:33, Simon Glass <sjg@xxxxxxxxxxxx> wrote:
>
> Hi Elliot,
>
> On Fri, 21 Jun 2024 at 23:40, Elliot Berman <quic_eberman@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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?

Here I am referring to the actual number of separate boards which
appear in the wild, not the multiplication of the number of axes which
produced them.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux