Re: Antwort: Re: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
On Wed, Apr 15, 2020 at 06:15:39PM +0300, Andy Shevchenko wrote: > On Wed, Apr 15, 2020 at 04:57:33PM +0200, Wolfgang Wallner wrote: > > > On Wed, Apr 15, 2020 at 5:00 PM Wolfgang Wallner > > > wrote: > > > > -"Andy Shevchenko" schrieb: ----- > > > > > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c > > > > > > > > > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko > > > > > wrote: > > > > > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner > > > > > > wrote: > > > > > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > > > > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > > > > > > > > wrote: > > > > > > > > > > >An: u-boot@lists.denx.de > > > > > > > > > > >Von: "Simon Glass" > > > > > > > > > > >Datum: 31.03.2020 01:14 > > > > > > > > > > >Kopie: "Andy Shevchenko" > > > > > > > > > > >, > > > > > > > > > > >"Wolfgang Wallner" , > > > > > > > > > > >"Leif > > > > > > > > > > >Lindholm" , "Simon Glass" > > > > > > > > > > > > > > > > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI > > > > > > > > > > >settings in > > > > > > > > > > >the device tree > > > > > > > > > > > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use > > > > > > > > > > Devicetree > > > > > > > > > > properties inside ACPI, especially it allows to re-use > > > > > > > > > > Devicetree's > > > > > > > > > > "compatible"-property. But this is for a different use case > > > > > > > > > > (using Devicetree > > > > > > > > > > properties inside ACPI, not add ACPI properties in > > > > > > > > > > Devicetree). > > > > > > > > > > > > > > > > Before we are going further with this here is a BIG CAVEAT. > > > > > > > > > > > > > > > > PRP0001 MUST NOT be used in production devices. > > > > > > > > > > > > > > > > This has been derived solely for debugging / pre-production > > > > > > > > testing / etc > > > > > > > > purposes. The real devices must have an official ACPI _HID. > > > > > > > > > > > > > > Thanks for pointing this out! I was not aware of this. > > > > > > > I have tried to understand how the PRP0001 is meant to be used, > > > > > > > but could not > > > > > > > find sufficient documentation. The best document I could find is > > > > > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux > > > > > > > kernel, and > > > > > > > as far as I can tell the constraint that you mention is also not > > > > > > > described > > > > > > > there. > > > > > > > > > > > > > > Do you know any other resources regarding PRP0001, e.g. some kind > > > > > > > of > > > > > > > speficiation? > > > > > > > > > > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP > > > > > > is > > > > > > a PNP ID for UEFI Forum. > > > > > > > > > > Basically last message in [3] from Rafael mentions his view on > > > > > PRP0001. I guess there is still no document, although as I noticed the > > > > > PRP prefix become official in a mean time. > > > > > > > > Thanks for the references. I have read them carefully, especially the > > > > thread > > > > in [3]. > > > > > > > > My understanding up to now was based on presentations by David > > > > Woodhouse, > > > > so it matches with his viewpoint in the thread at [3]. And as far as I > > > > can > > > > tell Raf
Re: Antwort: Re: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
On Wed, Apr 15, 2020 at 04:57:33PM +0200, Wolfgang Wallner wrote: > > On Wed, Apr 15, 2020 at 5:00 PM Wolfgang Wallner > > wrote: > > > -"Andy Shevchenko" schrieb: - > > > > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c > > > > > > > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko > > > > wrote: > > > > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner > > > > > wrote: > > > > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > > > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > > > > > > > wrote: > > > > > > > > > >An: u-boot@lists.denx.de > > > > > > > > > >Von: "Simon Glass" > > > > > > > > > >Datum: 31.03.2020 01:14 > > > > > > > > > >Kopie: "Andy Shevchenko" , > > > > > > > > > >"Wolfgang Wallner" , > > > > > > > > > >"Leif > > > > > > > > > >Lindholm" , "Simon Glass" > > > > > > > > > > > > > > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI > > > > > > > > > >settings in > > > > > > > > > >the device tree > > > > > > > > > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use > > > > > > > > > Devicetree > > > > > > > > > properties inside ACPI, especially it allows to re-use > > > > > > > > > Devicetree's > > > > > > > > > "compatible"-property. But this is for a different use case > > > > > > > > > (using Devicetree > > > > > > > > > properties inside ACPI, not add ACPI properties in > > > > > > > > > Devicetree). > > > > > > > > > > > > > > Before we are going further with this here is a BIG CAVEAT. > > > > > > > > > > > > > > PRP0001 MUST NOT be used in production devices. > > > > > > > > > > > > > > This has been derived solely for debugging / pre-production > > > > > > > testing / etc > > > > > > > purposes. The real devices must have an official ACPI _HID. > > > > > > > > > > > > Thanks for pointing this out! I was not aware of this. > > > > > > I have tried to understand how the PRP0001 is meant to be used, but > > > > > > could not > > > > > > find sufficient documentation. The best document I could find is > > > > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux > > > > > > kernel, and > > > > > > as far as I can tell the constraint that you mention is also not > > > > > > described > > > > > > there. > > > > > > > > > > > > Do you know any other resources regarding PRP0001, e.g. some kind of > > > > > > speficiation? > > > > > > > > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is > > > > > a PNP ID for UEFI Forum. > > > > > > > > Basically last message in [3] from Rafael mentions his view on > > > > PRP0001. I guess there is still no document, although as I noticed the > > > > PRP prefix become official in a mean time. > > > > > > Thanks for the references. I have read them carefully, especially the > > > thread > > > in [3]. > > > > > > My understanding up to now was based on presentations by David Woodhouse, > > > so it matches with his viewpoint in the thread at [3]. And as far as I can > > > tell Rafael Wysocki agrees with him in this thread. > > > > > > What I could not find in either of the references is that PRP0001 is only > > > for debugging, I only know about this constraint from your mail. Could you > > > point me to any source for this? > > > > From [3], Rafael said: > > "Let alone the fact that PRP0001 is actually quite useful at the > > prototyping stage when it is premature to allocate a new device ID just > > yet. Taking that to the extreme, if someone whittles a boa
Antwort: Re: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Hi Andy, -"Andy Shevchenko" schrieb: - > On Wed, Apr 15, 2020 at 5:00 PM Wolfgang Wallner > wrote: > > -"Andy Shevchenko" schrieb: ----- > > > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c > > > > > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko > > > wrote: > > > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner > > > > wrote: > > > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > > > > > > wrote: > > > > > > > > >An: u-boot@lists.denx.de > > > > > > > > >Von: "Simon Glass" > > > > > > > > >Datum: 31.03.2020 01:14 > > > > > > > > >Kopie: "Andy Shevchenko" , > > > > > > > > >"Wolfgang Wallner" , "Leif > > > > > > > > >Lindholm" , "Simon Glass" > > > > > > > > > > > > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI > > > > > > > > >settings in > > > > > > > > >the device tree > > > > > > > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use > > > > > > > > Devicetree > > > > > > > > properties inside ACPI, especially it allows to re-use > > > > > > > > Devicetree's > > > > > > > > "compatible"-property. But this is for a different use case > > > > > > > > (using Devicetree > > > > > > > > properties inside ACPI, not add ACPI properties in Devicetree). > > > > > > > > > > > > Before we are going further with this here is a BIG CAVEAT. > > > > > > > > > > > > PRP0001 MUST NOT be used in production devices. > > > > > > > > > > > > This has been derived solely for debugging / pre-production testing > > > > > > / etc > > > > > > purposes. The real devices must have an official ACPI _HID. > > > > > > > > > > Thanks for pointing this out! I was not aware of this. > > > > > I have tried to understand how the PRP0001 is meant to be used, but > > > > > could not > > > > > find sufficient documentation. The best document I could find is > > > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux > > > > > kernel, and > > > > > as far as I can tell the constraint that you mention is also not > > > > > described > > > > > there. > > > > > > > > > > Do you know any other resources regarding PRP0001, e.g. some kind of > > > > > speficiation? > > > > > > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is > > > > a PNP ID for UEFI Forum. > > > > > > Basically last message in [3] from Rafael mentions his view on > > > PRP0001. I guess there is still no document, although as I noticed the > > > PRP prefix become official in a mean time. > > > > Thanks for the references. I have read them carefully, especially the thread > > in [3]. > > > > My understanding up to now was based on presentations by David Woodhouse, > > so it matches with his viewpoint in the thread at [3]. And as far as I can > > tell Rafael Wysocki agrees with him in this thread. > > > > What I could not find in either of the references is that PRP0001 is only > > for debugging, I only know about this constraint from your mail. Could you > > point me to any source for this? > > From [3], Rafael said: > "Let alone the fact that PRP0001 is actually quite useful at the > prototyping stage when it is premature to allocate a new device ID just > yet. Taking that to the extreme, if someone whittles a board in his or > her garage and wants to use it to drive their homemade grass watering > system, having to invent a new device ID and put it into the existing > driver that otherwise doesn't require any modifications is ... you know > what I mean." > > It implies that the process should have included the allocation of an > official ACPI ID. I understand the quoted paragraph differently. In the paragraphs above Rafael argues that PRP0001 is useful, as with PRP0001 we can a
Re: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
On Wed, Apr 15, 2020 at 5:00 PM Wolfgang Wallner wrote: > -"Andy Shevchenko" schrieb: - > > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c > > > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko > > wrote: > > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner > > > wrote: > > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > > > > > wrote: > > > > > > > >An: u-boot@lists.denx.de > > > > > > > >Von: "Simon Glass" > > > > > > > >Datum: 31.03.2020 01:14 > > > > > > > >Kopie: "Andy Shevchenko" , > > > > > > > >"Wolfgang Wallner" , "Leif > > > > > > > >Lindholm" , "Simon Glass" > > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings > > > > > > > >in > > > > > > > >the device tree > > > > > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use > > > > > > > Devicetree > > > > > > > properties inside ACPI, especially it allows to re-use > > > > > > > Devicetree's > > > > > > > "compatible"-property. But this is for a different use case > > > > > > > (using Devicetree > > > > > > > properties inside ACPI, not add ACPI properties in Devicetree). > > > > > > > > > > Before we are going further with this here is a BIG CAVEAT. > > > > > > > > > > PRP0001 MUST NOT be used in production devices. > > > > > > > > > > This has been derived solely for debugging / pre-production testing / > > > > > etc > > > > > purposes. The real devices must have an official ACPI _HID. > > > > > > > > Thanks for pointing this out! I was not aware of this. > > > > I have tried to understand how the PRP0001 is meant to be used, but > > > > could not > > > > find sufficient documentation. The best document I could find is > > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, > > > > and > > > > as far as I can tell the constraint that you mention is also not > > > > described > > > > there. > > > > > > > > Do you know any other resources regarding PRP0001, e.g. some kind of > > > > speficiation? > > > > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is > > > a PNP ID for UEFI Forum. > > > > Basically last message in [3] from Rafael mentions his view on > > PRP0001. I guess there is still no document, although as I noticed the > > PRP prefix become official in a mean time. > > Thanks for the references. I have read them carefully, especially the thread > in [3]. > > My understanding up to now was based on presentations by David Woodhouse, > so it matches with his viewpoint in the thread at [3]. And as far as I can > tell Rafael Wysocki agrees with him in this thread. > > What I could not find in either of the references is that PRP0001 is only > for debugging, I only know about this constraint from your mail. Could you > point me to any source for this? >From [3], Rafael said: "Let alone the fact that PRP0001 is actually quite useful at the prototyping stage when it is premature to allocate a new device ID just yet. Taking that to the extreme, if someone whittles a board in his or her garage and wants to use it to drive their homemade grass watering system, having to invent a new device ID and put it into the existing driver that otherwise doesn't require any modifications is ... you know what I mean." It implies that the process should have included the allocation of an official ACPI ID. You always can ask ASWG for the clarification. Maybe I learn something new about PRP0001 :-) > > > > If PRP0001 is only for debugging, then I must also have misunderstood > > > > the > > > > Linux "device-property" API (define in include/linux/property.h). > > > > > > Not exactly. > > > > > > > There are some presentations available on the internet, e.g. [1], that I > > > > understand like PRP0001 + "device-property" API provide a way do access > > > > data > > > > from either Devicetree or ACPI, depending on what kind of platform you > > > > are on. > > > > > > No, these are not hard linked to each other (the relation is that > > > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI > > > _HID, by using compatible property [1]). The _DSD per se (i.o.w. > > > device properties implementation in ACPI) is a different story [2]. > > > > > > And I put [3] here, interesting to read. However, at that time I was > > > quite far from this topic. > > > > > > [1]: > > > https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id > > > [2]: > > > https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm. > > > [3]: https://patchwork.kernel.org/patch/7004241/ > > > > > > > [1] > > > > https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf -- With Best Regards, Andy Shevchenko
Antwort: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Hi Andy, -"Andy Shevchenko" schrieb: - > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko > wrote: > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner > > wrote: > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > > > > wrote: > > > > > > >An: u-boot@lists.denx.de > > > > > > >Von: "Simon Glass" > > > > > > >Datum: 31.03.2020 01:14 > > > > > > >Kopie: "Andy Shevchenko" , > > > > > > >"Wolfgang Wallner" , "Leif > > > > > > >Lindholm" , "Simon Glass" > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in > > > > > > >the device tree > > > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use > > > > > > Devicetree > > > > > > properties inside ACPI, especially it allows to re-use Devicetree's > > > > > > "compatible"-property. But this is for a different use case (using > > > > > > Devicetree > > > > > > properties inside ACPI, not add ACPI properties in Devicetree). > > > > > > > > Before we are going further with this here is a BIG CAVEAT. > > > > > > > > PRP0001 MUST NOT be used in production devices. > > > > > > > > This has been derived solely for debugging / pre-production testing / > > > > etc > > > > purposes. The real devices must have an official ACPI _HID. > > > > > > Thanks for pointing this out! I was not aware of this. > > > I have tried to understand how the PRP0001 is meant to be used, but could > > > not > > > find sufficient documentation. The best document I could find is > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and > > > as far as I can tell the constraint that you mention is also not described > > > there. > > > > > > Do you know any other resources regarding PRP0001, e.g. some kind of > > > speficiation? > > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is > > a PNP ID for UEFI Forum. > > Basically last message in [3] from Rafael mentions his view on > PRP0001. I guess there is still no document, although as I noticed the > PRP prefix become official in a mean time. Thanks for the references. I have read them carefully, especially the thread in [3]. My understanding up to now was based on presentations by David Woodhouse, so it matches with his viewpoint in the thread at [3]. And as far as I can tell Rafael Wysocki agrees with him in this thread. What I could not find in either of the references is that PRP0001 is only for debugging, I only know about this constraint from your mail. Could you point me to any source for this? > > > If PRP0001 is only for debugging, then I must also have misunderstood the > > > Linux "device-property" API (define in include/linux/property.h). > > > > Not exactly. > > > > > There are some presentations available on the internet, e.g. [1], that I > > > understand like PRP0001 + "device-property" API provide a way do access > > > data > > > from either Devicetree or ACPI, depending on what kind of platform you > > > are on. > > > > No, these are not hard linked to each other (the relation is that > > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI > > _HID, by using compatible property [1]). The _DSD per se (i.o.w. > > device properties implementation in ACPI) is a different story [2]. > > > > And I put [3] here, interesting to read. However, at that time I was > > quite far from this topic. > > > > [1]: > > https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id > > [2]: > > https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm. > > [3]: https://patchwork.kernel.org/patch/7004241/ > > > > > [1] > > > https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf > > > > -- > > With Best Regards, > > Andy Shevchenko regards, Wolfgang PS: I only realized now that I had mixed up the email-subject in my first reply and now the complete thread is under the wrong topic. Sorry for that.
Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko wrote: > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner > wrote: > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > > > wrote: > > > > > >An: u-boot@lists.denx.de > > > > > >Von: "Simon Glass" > > > > > >Datum: 31.03.2020 01:14 > > > > > >Kopie: "Andy Shevchenko" , > > > > > >"Wolfgang Wallner" , "Leif > > > > > >Lindholm" , "Simon Glass" > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in > > > > > >the device tree > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree > > > > > properties inside ACPI, especially it allows to re-use Devicetree's > > > > > "compatible"-property. But this is for a different use case (using > > > > > Devicetree > > > > > properties inside ACPI, not add ACPI properties in Devicetree). > > > > > > Before we are going further with this here is a BIG CAVEAT. > > > > > > PRP0001 MUST NOT be used in production devices. > > > > > > This has been derived solely for debugging / pre-production testing / etc > > > purposes. The real devices must have an official ACPI _HID. > > > > Thanks for pointing this out! I was not aware of this. > > I have tried to understand how the PRP0001 is meant to be used, but could > > not > > find sufficient documentation. The best document I could find is > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and > > as far as I can tell the constraint that you mention is also not described > > there. > > > > Do you know any other resources regarding PRP0001, e.g. some kind of > > speficiation? > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is > a PNP ID for UEFI Forum. Basically last message in [3] from Rafael mentions his view on PRP0001. I guess there is still no document, although as I noticed the PRP prefix become official in a mean time. > > If PRP0001 is only for debugging, then I must also have misunderstood the > > Linux "device-property" API (define in include/linux/property.h). > > Not exactly. > > > There are some presentations available on the internet, e.g. [1], that I > > understand like PRP0001 + "device-property" API provide a way do access data > > from either Devicetree or ACPI, depending on what kind of platform you are > > on. > > No, these are not hard linked to each other (the relation is that > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI > _HID, by using compatible property [1]). The _DSD per se (i.o.w. > device properties implementation in ACPI) is a different story [2]. > > And I put [3] here, interesting to read. However, at that time I was > quite far from this topic. > > [1]: > https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id > [2]: > https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm. > [3]: https://patchwork.kernel.org/patch/7004241/ > > > [1] > > https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf > > -- > With Best Regards, > Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner wrote: > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > > wrote: > > > > >An: u-boot@lists.denx.de > > > > >Von: "Simon Glass" > > > > >Datum: 31.03.2020 01:14 > > > > >Kopie: "Andy Shevchenko" , > > > > >"Wolfgang Wallner" , "Leif > > > > >Lindholm" , "Simon Glass" > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in > > > > >the device tree > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree > > > > properties inside ACPI, especially it allows to re-use Devicetree's > > > > "compatible"-property. But this is for a different use case (using > > > > Devicetree > > > > properties inside ACPI, not add ACPI properties in Devicetree). > > > > Before we are going further with this here is a BIG CAVEAT. > > > > PRP0001 MUST NOT be used in production devices. > > > > This has been derived solely for debugging / pre-production testing / etc > > purposes. The real devices must have an official ACPI _HID. > > Thanks for pointing this out! I was not aware of this. > I have tried to understand how the PRP0001 is meant to be used, but could not > find sufficient documentation. The best document I could find is > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and > as far as I can tell the constraint that you mention is also not described > there. > > Do you know any other resources regarding PRP0001, e.g. some kind of > speficiation? I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is a PNP ID for UEFI Forum. > If PRP0001 is only for debugging, then I must also have misunderstood the > Linux "device-property" API (define in include/linux/property.h). Not exactly. > There are some presentations available on the internet, e.g. [1], that I > understand like PRP0001 + "device-property" API provide a way do access data > from either Devicetree or ACPI, depending on what kind of platform you are on. No, these are not hard linked to each other (the relation is that PRP0001 is a way to enumerate devices, which don't have dedicated ACPI _HID, by using compatible property [1]). The _DSD per se (i.o.w. device properties implementation in ACPI) is a different story [2]. And I put [3] here, interesting to read. However, at that time I was quite far from this topic. [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id [2]: https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm. [3]: https://patchwork.kernel.org/patch/7004241/ > [1] > https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf -- With Best Regards, Andy Shevchenko
Antwort: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Hi Andy, -"Andy Shevchenko" schrieb: - > > Betreff: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > wrote: > > > >An: u-boot@lists.denx.de > > > >Von: "Simon Glass" > > > >Datum: 31.03.2020 01:14 > > > >Kopie: "Andy Shevchenko" , > > > >"Wolfgang Wallner" , "Leif > > > >Lindholm" , "Simon Glass" > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in > > > >the device tree > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree > > > properties inside ACPI, especially it allows to re-use Devicetree's > > > "compatible"-property. But this is for a different use case (using > > > Devicetree > > > properties inside ACPI, not add ACPI properties in Devicetree). > > Before we are going further with this here is a BIG CAVEAT. > > PRP0001 MUST NOT be used in production devices. > > This has been derived solely for debugging / pre-production testing / etc > purposes. The real devices must have an official ACPI _HID. Thanks for pointing this out! I was not aware of this. I have tried to understand how the PRP0001 is meant to be used, but could not find sufficient documentation. The best document I could find is Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and as far as I can tell the constraint that you mention is also not described there. Do you know any other resources regarding PRP0001, e.g. some kind of speficiation? If PRP0001 is only for debugging, then I must also have misunderstood the Linux "device-property" API (define in include/linux/property.h). There are some presentations available on the internet, e.g. [1], that I understand like PRP0001 + "device-property" API provide a way do access data from either Devicetree or ACPI, depending on what kind of platform you are on. regards, Wolfgang [1] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > wrote: > > >An: u-boot@lists.denx.de > > >Von: "Simon Glass" > > >Datum: 31.03.2020 01:14 > > >Kopie: "Andy Shevchenko" , > > >"Wolfgang Wallner" , "Leif > > >Lindholm" , "Simon Glass" > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in > > >the device tree > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree > > properties inside ACPI, especially it allows to re-use Devicetree's > > "compatible"-property. But this is for a different use case (using > > Devicetree > > properties inside ACPI, not add ACPI properties in Devicetree). Before we are going further with this here is a BIG CAVEAT. PRP0001 MUST NOT be used in production devices. This has been derived solely for debugging / pre-production testing / etc purposes. The real devices must have an official ACPI _HID. -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Hi Wolfgang,
On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
wrote:
>
> Hi Simon,
>
> -"Simon Glass" schrieb: -
>
> >An: u-boot@lists.denx.de
> >Von: "Simon Glass"
> >Datum: 31.03.2020 01:14
> >Kopie: "Andy Shevchenko" ,
> >"Wolfgang Wallner" , "Leif
> >Lindholm" , "Simon Glass"
> >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> >the device tree
> >
> > Devices need to report various identifiers in the ACPI tables. Rather than
> > hard-coding these in drivers it is typically better to put them in the
> > device tree.
> >
> > Add a binding file to describe this.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > Changes in v3:
> > - Add a pointer to information about acpi,compatible
> > - Change the example to ELAN
> > - Correct description of acpi,probed
> > - Drop hid-descr-addr
> > - Drop mention of PRIC
>
> I understand now where the term "PRIC" came from.
> The property "acpi,has-power-resource" triggers the function
> acpi_device_add_power_res(), which writes a PowerResource ('PowerResource'
> as specified in section 7.2 of ACPI 6.3). This function comes from Coreboot,
> and that implementation uses "PRIC" as the hardcoded device name. That's it,
> it is an arbitrary chosen device name (probably meaning "power IC" ... ?).
>
> Anyway, dropping the term "PRIC" makes the description easier to understand.
> The important information is that "acpi,has-power-resource" leads to the
> addition of a PowerResource entry.
>
> > - Just add the device.txt binding file in this patch
> > - Rename acpi,desc to acpi,ddn
> >
> > Changes in v2:
> > - Add the hid-over-i2c binding document
> > - Fix definition of HID
> > - Infer hid-over-i2c CID value
> >
> > doc/device-tree-bindings/device.txt | 37 +
> > 1 file changed, 37 insertions(+)
> > create mode 100644 doc/device-tree-bindings/device.txt
> >
> > diff --git a/doc/device-tree-bindings/device.txt
> > b/doc/device-tree-bindings/device.txt
> > new file mode 100644
> > index 000..06c2b84b6d5
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/device.txt
> > @@ -0,0 +1,37 @@
> > +Devices
> > +===
> > +
> > +Device bindings are described by their own individual binding files.
> > +
> > +U-Boot provides for some optional properties which are documented here. See
> > +also hid-over-i2c.txt which describes HID devices. See also
> > +Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel for
> > +the acpi,compatible property.
> > +
> > + - acpi,has-power-resource : (boolean) true if this device has a power
> > resource.
> > +This causes an ACPI PowerResource to be written containing the
> > properties
> > +provided by this binding, to describe how to handle powering the
> > device up
> > +and down using GPIOs
> > + - acpi,compatible : compatible string to report
>
> I still don't see a use case for a new "acpi,compatible" property.
> I will take a step back, and explain my understanding of the involved pieces
> and why I think adding "acpi,compatible" is of no benefit.
>
> Summary:
> As far as I understand the proposed "acpi, compatible" property, the following
> would happen:
> We have "acpi,compatible" in Devicetree, which results in a "compatible"-entry
> in ACPI's _DSD method, which is then again interpreted as the
> "compatible"-property of Devicetree. IMHO it would be strange for "compatible"
> and "acpi,compatible" to be different, so we could drop "acpi,compatible" and
> use the existing "compatible" instead.
But the compatible string is "hid-over-i2c". We don't want to have
lots of different compatible strings here, different drivers which do
the same thing. If we end up wanting a touchscreen drivers in U-Boot
that might change, but for now I think a generic driver is easier.
>
> The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> properties inside ACPI, especially it allows to re-use Devicetree's
> "compatible"-property. But this is for a different use case (using Devicetree
> properties inside ACPI, not add ACPI properties in Devicetree).
>
> Detailed explanation:
>
> 1) ACPI Constraint: Devices need to have either _HID or _ADR
>
>ACPI puts constraints on what properties a device ("device" here means a
>"Device()" entry in ASL code (DSDT or SSDT)) has to have. It has to have
>either an _HID or an _ADR property depending on whether it is on an
>enumerable bus:
>
> * if it is on an enumerable bus, it has to have an _ADR (address)
> property (e.g. a PCI device on a PCI bus)
> * if it is not on an enumerable bus, it has to have a _HID (hardware ID)
> property (e.g. the GPIO controllers on the Apollo Lake SoC). The legal
> values for _HID are specified and allow the type of the device to be
> identified (a similar concept as the "compatible" property in
> devicetree)
>
>These contraints are specified in section 6.1 of ACPI 6.3 [1].
>
> 2) ACPI's _DSD Method
>
>The Device Specific
Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Hi Wolfgang, On Wed, 1 Apr 2020 at 01:39, Wolfgang Wallner wrote: > > Hi Simon, > > -"U-Boot" schrieb: - > > [snip] > > >> + - acpi,ddn : Contains the string to use as the _DDN (DOS (Disk > >Operating > >> +System) Device Name) > >> + - acpi,hid : Contains the string to use as the HID (Hardware ID) > >> +identifier _HID > >> + - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI > >tables so that > >> +Linux will only load the driver if the device can be detected > >(e.g. on I2C > >> +bus) > > > >Will support for 'linux,probed' be mainlined? Otherwise the > >description > >should IMHO mention that it is an out-of-tree feature. > > I have thought some more about this property. > The Chromium discussions [1] mention that "linux,probed" is intended to be > a property in both Devicetree and ACPI, so a Linux kernel could handle the > device in the expected way whether it boots on a Devicetree platform or an > ACPI platform. The proposed "acpi,probed" property would only solve one such > use case (ACPI-based platforms): U-Boot boots, reads "acpi,probed" from > Devicetree, adds "linux,probed" to the ACPI description and hands that to the > Linux kernel. > > Why would we not keep the name "linux,probed" for this property? U-Boot could > still do the same Devicetree -> ACPI translation, but the same property could > then also be useful for Devicetree-based platforms. OK...oh dear. I will change it back to linux,probed Regards, Simon
Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Hi Simon, -"U-Boot" schrieb: - [snip] >> + - acpi,ddn : Contains the string to use as the _DDN (DOS (Disk >Operating >> +System) Device Name) >> + - acpi,hid : Contains the string to use as the HID (Hardware ID) >> +identifier _HID >> + - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI >tables so that >> +Linux will only load the driver if the device can be detected >(e.g. on I2C >> +bus) > >Will support for 'linux,probed' be mainlined? Otherwise the >description >should IMHO mention that it is an out-of-tree feature. I have thought some more about this property. The Chromium discussions [1] mention that "linux,probed" is intended to be a property in both Devicetree and ACPI, so a Linux kernel could handle the device in the expected way whether it boots on a Devicetree platform or an ACPI platform. The proposed "acpi,probed" property would only solve one such use case (ACPI-based platforms): U-Boot boots, reads "acpi,probed" from Devicetree, adds "linux,probed" to the ACPI description and hands that to the Linux kernel. Why would we not keep the name "linux,probed" for this property? U-Boot could still do the same Devicetree -> ACPI translation, but the same property could then also be useful for Devicetree-based platforms. [snip] regards, Wolfgang [1] https://groups.google.com/a/chromium.org/forum/#!msg/chromium-os-reviews/4HTHl78IGHw/oz82uImnBgAJ
Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Hi Simon,
-"Simon Glass" schrieb: -
>An: u-boot@lists.denx.de
>Von: "Simon Glass"
>Datum: 31.03.2020 01:14
>Kopie: "Andy Shevchenko" ,
>"Wolfgang Wallner" , "Leif
>Lindholm" , "Simon Glass"
>Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
>the device tree
>
> Devices need to report various identifiers in the ACPI tables. Rather than
> hard-coding these in drivers it is typically better to put them in the
> device tree.
>
> Add a binding file to describe this.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Add a pointer to information about acpi,compatible
> - Change the example to ELAN
> - Correct description of acpi,probed
> - Drop hid-descr-addr
> - Drop mention of PRIC
I understand now where the term "PRIC" came from.
The property "acpi,has-power-resource" triggers the function
acpi_device_add_power_res(), which writes a PowerResource ('PowerResource'
as specified in section 7.2 of ACPI 6.3). This function comes from Coreboot,
and that implementation uses "PRIC" as the hardcoded device name. That's it,
it is an arbitrary chosen device name (probably meaning "power IC" ... ?).
Anyway, dropping the term "PRIC" makes the description easier to understand.
The important information is that "acpi,has-power-resource" leads to the
addition of a PowerResource entry.
> - Just add the device.txt binding file in this patch
> - Rename acpi,desc to acpi,ddn
>
> Changes in v2:
> - Add the hid-over-i2c binding document
> - Fix definition of HID
> - Infer hid-over-i2c CID value
>
> doc/device-tree-bindings/device.txt | 37 +
> 1 file changed, 37 insertions(+)
> create mode 100644 doc/device-tree-bindings/device.txt
>
> diff --git a/doc/device-tree-bindings/device.txt
> b/doc/device-tree-bindings/device.txt
> new file mode 100644
> index 000..06c2b84b6d5
> --- /dev/null
> +++ b/doc/device-tree-bindings/device.txt
> @@ -0,0 +1,37 @@
> +Devices
> +===
> +
> +Device bindings are described by their own individual binding files.
> +
> +U-Boot provides for some optional properties which are documented here. See
> +also hid-over-i2c.txt which describes HID devices. See also
> +Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel for
> +the acpi,compatible property.
> +
> + - acpi,has-power-resource : (boolean) true if this device has a power
> resource.
> +This causes an ACPI PowerResource to be written containing the properties
> +provided by this binding, to describe how to handle powering the device
> up
> +and down using GPIOs
> + - acpi,compatible : compatible string to report
I still don't see a use case for a new "acpi,compatible" property.
I will take a step back, and explain my understanding of the involved pieces
and why I think adding "acpi,compatible" is of no benefit.
Summary:
As far as I understand the proposed "acpi, compatible" property, the following
would happen:
We have "acpi,compatible" in Devicetree, which results in a "compatible"-entry
in ACPI's _DSD method, which is then again interpreted as the
"compatible"-property of Devicetree. IMHO it would be strange for "compatible"
and "acpi,compatible" to be different, so we could drop "acpi,compatible" and
use the existing "compatible" instead.
The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
properties inside ACPI, especially it allows to re-use Devicetree's
"compatible"-property. But this is for a different use case (using Devicetree
properties inside ACPI, not add ACPI properties in Devicetree).
Detailed explanation:
1) ACPI Constraint: Devices need to have either _HID or _ADR
ACPI puts constraints on what properties a device ("device" here means a
"Device()" entry in ASL code (DSDT or SSDT)) has to have. It has to have
either an _HID or an _ADR property depending on whether it is on an
enumerable bus:
* if it is on an enumerable bus, it has to have an _ADR (address)
property (e.g. a PCI device on a PCI bus)
* if it is not on an enumerable bus, it has to have a _HID (hardware ID)
property (e.g. the GPIO controllers on the Apollo Lake SoC). The legal
values for _HID are specified and allow the type of the device to be
identified (a similar concept as the "compatible" property in devicetree)
These contraints are specified in section 6.1 of ACPI 6.3 [1].
2) ACPI's _DSD Method
The Device Specific Data (_DSD) method provides a way to provide additional
device properties to device drivers. It returns a package of "Device Data
Descriptors", each consisting of a UUID and a package in a format defined
by the provided UUID.
The details are specified in section 6.2.5 of ACPI 6.3 [1].
3) Special UUID value for _DSD: daffd814-...
The document "Device Properties UUID For _DSD" [2] specifies a special UUID
value:daffd814-6eba-4d8c-8a91-bc9bbf4aa301
When this UUID is used in the package returned by in a _DSD method,
it means the
[PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Add this binding from Linux v5.4.
Signed-off-by: Simon Glass
---
Changes in v3:
- Split out hid-over-i2c into its own patch
Changes in v2: None
.../input/hid-over-i2c.txt| 44 +++
1 file changed, 44 insertions(+)
create mode 100644 doc/device-tree-bindings/input/hid-over-i2c.txt
diff --git a/doc/device-tree-bindings/input/hid-over-i2c.txt
b/doc/device-tree-bindings/input/hid-over-i2c.txt
new file mode 100644
index 000..c76bafaf98d
--- /dev/null
+++ b/doc/device-tree-bindings/input/hid-over-i2c.txt
@@ -0,0 +1,44 @@
+* HID over I2C Device-Tree bindings
+
+HID over I2C provides support for various Human Interface Devices over the
+I2C bus. These devices can be for example touchpads, keyboards, touch screens
+or sensors.
+
+The specification has been written by Microsoft and is currently available
here:
+http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx
+
+If this binding is used, the kernel module i2c-hid will handle the
communication
+with the device and the generic hid core layer will handle the protocol.
+
+Required properties:
+- compatible: must be "hid-over-i2c"
+- reg: i2c slave address
+- hid-descr-addr: HID descriptor address
+- interrupts: interrupt line
+
+Additional optional properties:
+
+Some devices may support additional optional properties to help with, e.g.,
+power sequencing. The following properties can be supported by one or more
+device-specific compatible properties, which should be used in addition to the
+"hid-over-i2c" string.
+
+- compatible:
+ * "wacom,w9013" (Wacom W9013 digitizer). Supports:
+- vdd-supply (3.3V)
+- vddl-supply (1.8V)
+- post-power-on-delay-ms
+
+- vdd-supply: phandle of the regulator that provides the supply voltage.
+- post-power-on-delay-ms: time required by the device after enabling its
regulators
+ or powering it on, before it is ready for communication.
+
+Example:
+
+ i2c-hid-dev@2c {
+ compatible = "hid-over-i2c";
+ reg = <0x2c>;
+ hid-descr-addr = <0x0020>;
+ interrupt-parent = <>;
+ interrupts = <3 2>;
+ };
--
2.26.0.rc2.310.g2932bb562d-goog
