> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Thursday, November 23, 2017 1:10 AM > To: Daniel Thompson <daniel.thomp...@linaro.org> > Cc: Udit Kumar <udit.ku...@nxp.com>; Leif Lindholm > <leif.lindh...@linaro.org>; edk2-devel@lists.01.org; Varun Sethi > <v.se...@nxp.com>; Graeme Gregory <graeme.greg...@linaro.org> > Subject: Re: [RFC] ACPI table HID/CID allocation > > On 22 November 2017 at 11:30, Daniel Thompson > <daniel.thomp...@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 ? _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
