Re: Removal of qcom,board-id and qcom,msm-id

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

 



On 20/05/2022 03:39, Dmitry Baryshkov wrote:
>> I vaguely recall that the properties had to be extracted during the
>> boot.img creation process to create a table of contents header. But
>> after some time the bootloader started scanning the DTBs directly for
>> the vendor properties and thus the header was deprecated/removed. If the
>> bootloader is doing the scanning then I'm not sure what is preventing
>> the properties from being documented and allowed. I think the main
>> rejection was that the properties were added purely to be extracted
>> during post processing and placed into the table of contents header,
>> i.e. they weren't actually used by the kernel or the bootloader. If they
>> are now used by the bootloader it sounds OK to me if they're kept
>> around.
> 
> Yes, as far as I understand, they are used by the bootloader directly.

This solves only one part of concern form previous discussions - having
entries not used by anything. Kernel still don't use them but some
vendor bootloader (not U-boot) does.

The second problem with these is still not solved - these duplicate what
is already described by compatible. Basically, they do not add any new
hardware description, because board or SoC revision should be encoded
into the compatible. Imagine now adding such "vendor,device-id"
properties to every device node in DTS!

Best regards,
Krzysztof



[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