Re: [RFC] ACPI table HID/CID allocation

[Udit Kumar <udit.kumar@nxp.com>]

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Thursday, November 23, 2017 1:10 AM
> To: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Udit Kumar <udit.kumar@nxp.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun Sethi
> <V.Sethi@nxp.com>; Graeme Gregory <graeme.gregory@linaro.org>
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 
> 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.

Along with this line, say if a driver (what is available in kernel)
can work with PRP0001, and this driver is not exposing/need
any AML methods (i2c slave and flashes are good example here)
then no need to assign HID , right ?