On Thu, Apr 26, 2018 at 6:42 PM, Bartosz Golaszewski wrote:
> 2018-04-26 14:07 GMT+02:00 Linus Walleij :
>> On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote:
>>
>>> Board files constitute a significant part of the users of the legacy
>>> GPIO framework. In many cases they only export a
2018-04-26 14:07 GMT+02:00 Linus Walleij :
> On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote:
>
>> Board files constitute a significant part of the users of the legacy
>> GPIO framework. In many cases they only export a line and set its
>> desired value. We could use GPIO hogs for that
On Thu, Apr 12, 2018 at 10:00 PM, Christian Lamparter
wrote:
> The problem is that unlike native gpio-controllers, pinctrls need
> to have a "pin/gpio range" defined before any gpio-hogs can be added.
Indeed. But the primary use case (correct me if I am wrong Bartosz)
is to clean up old boardfil
On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote:
> Board files constitute a significant part of the users of the legacy
> GPIO framework. In many cases they only export a line and set its
> desired value. We could use GPIO hogs for that like we do for DT and
> ACPI but there's no supp
On Dienstag, 10. April 2018 22:30:28 CEST Bartosz Golaszewski wrote:
> Board files constitute a significant part of the users of the legacy
> GPIO framework. In many cases they only export a line and set its
> desired value. We could use GPIO hogs for that like we do for DT and
> ACPI but there's n
Board files constitute a significant part of the users of the legacy
GPIO framework. In many cases they only export a line and set its
desired value. We could use GPIO hogs for that like we do for DT and
ACPI but there's no support for that in machine code.
This patch proposes to extend the machin