lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 5 Apr 2016 08:56:12 +0000 From: Charles Garcia-Tobin <charles.garcia-tobin@....com> To: Mark Rutland <mark.rutland@....com>, Irina Tirdea <irina.tirdea@...el.com> CC: "Rafael J. Wysocki" <rjw@...ysocki.net>, Len Brown <lenb@...nel.org>, Mika Westerberg <mika.westerberg@...ux.intel.com>, Linus Walleij <linus.walleij@...aro.org>, "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>, "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>, "Heikki Krogerus" <heikki.krogerus@...ux.intel.com>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Octavian Purdila <octavian.purdila@...el.com>, Cristina Ciocan <cristina.ciocan@...el.com>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration On 04/04/2016 23:52, "Mark Rutland" <mark.rutland@....com> wrote: >Hi, > >On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote: >> This is a proposal for adding ACPI support for pin controller >> configuration. >> >> It has been developed to enable the MinnowBoard and IoT community >> by providing an easy way to specify pin multiplexing and >> pin configuration. >> >> This proposal is based on using _DSD properties to specify device >> states and configuration nodes and it follows closely the device >> tree model. Device states are defined using the Device Properties >> format and the configuration nodes are defined using the >> Hierarchical Properties Extension format. The generic properties >> for the configuration nodes are the same as the ones for device >> tree, while pincontroller drivers can also define custom ones. > >>From a look of the Documentation addition, and of the current uses of >pinctrl-names in device tree bindings, one reason for requiring multiple >pinctrl states is power management. Given that, I'm somewhat concerned by >this, >as it goes against the usual ACPI model of abstracting this sort of thing >behind power control methods. > >To the best of my knowledge, that goes against the ASWG's expectations on >how >_DSD will be used (per [1]). Charles, please correct me if that document >is no >longer representative. It is though latest version was posted by Rafael a bit later: https://lists.acpica.org/pipermail/dsd/2015-December/000027.html In addition the core rules requiring that existing ACPI paradigms are not subverted through DSD (basically the concern you express) are also documented in the main DSD documentation itself: http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UU ID.pdf (section 2.3) Cheers Charles > >Additionally, pinctrl has some cross-cutting concerns (e.g. mutually >exclusive >device usage due to a shared pin), and I can imagine that may interact >poorly >with any AML or firmware assumptions about the state of the world, as >there's >no mechanism present to notify those of changes to pins. > >I think that this is a class of problem which needs to be raised with the >ASWG, >and solved in an ACPI-native fashion, rather than simply copying >properties >from DT using _DSD. If nothing else, the restrictions on FW and AML would >need >to be specified. > >Thanks, >Mark. > >[1] https://lists.acpica.org/pipermail/dsd/2015-September/000019.html >
Powered by blists - more mailing lists