Re: [RFC] ACPI table HID/CID allocation

[Daniel Thompson <daniel.thompson@linaro.org>]

On 22/11/17 19:39, Ard Biesheuvel wrote:
> On 22 November 2017 at 11:30, Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
>> On 21/11/17 18:10, Udit Kumar wrote:
>>>
>>> Thanks Ard,
>>> For internal SOC devices, this is perfectly ok to drop PRP0001 from CID.
>>>
>>>> This could be a valid reason to use PRP0001 + compatible, for things like
>>>> I2C
>>>> slaves that are external to the SoC
>>>
>>>
>>> For external devices (for which HID is not available), you suggest to go
>>> with PRP0001 + compatible or that device driver needs add ACPI HID
>>> support.
>>
>>
>> I don't think internal or external to the SoC would be any kind of deciding
>> factor in how to best to bind, simply because I don't understand why there
>> is no HID available.
>>
> 
> PRP0001 + compatible was invented to avoid the need to allocate a _HID
> for each and every component in existence that can already be
> identified by a DT compatible string (and little else except, e.g., a
> I2C slave address) and is not deeply engrained in the SoC in terms of
> clock tree, power states etc. So while internal/external may not be
> the most accurate distinction, it is still a useful one IMHO.

Hmnnn.... it sounds like jedec,spi-nor meets this test.

There is only one property in the DT bindings that describes the device 
itself (fast read support) rather than its "bus address" (chip select, 
frequency). Further, that single property is obsolete, at least for 
Linux; the kernel driver now contains a quirks tables to look up by 
device ID whether fast read is supported and will use that on non-DT 
systems (and also to censor broken DT systems ;-) ).


Daniel.