Re: [RFC] ACPI table HID/CID allocation

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

> >> 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 ;-) ).
> >
> > You mean, this more on bus frame work, how to probe slave.
> > Example rtc-ds3232.c , when is spi mode just need name but for i2c
> > mode it needs of_match_table
> I mean nothing more or less than that PRP0001 + compatible:jedec,spi-nor is
> tolerable within the ACPI tables (rather than allocating a HID) because it has no
> properties[1] beyond the bus configuration that ACPI can already describe

Thanks.  So tables are tolerable with PRP0001 + compatible
 
> I'm afraid I don't understand how rtc-ds3232.c fits into this topic; there are no

Not directly , but just to mention that this is more on bus frame work (or say
controller driver) how they are probing their slaves. 

> documented device tree bindings for the SPI variant of this part and, in any case,
> an RTC should use the ACPI interfaces
> (rtc-cmos.c) so the choice HID is a moot point; it should not be in the ACPI tables
> at all.

Sure, RTC will not be exposed by acpi tables. 

> 
> Daniel.
> 
> 
> [1] Assuming one accepts the argument that the m25p,fast-read property
>      can be ignored.
>      ignored.