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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 11 Jun 2017 22:43:31 +0300
From:   Andy Shevchenko <>
To:     Sakari Ailus <>
Cc:     "Mani, Rajmohan" <>,
        "" <>,
        "" <>,
        "" <>,
        Lee Jones <>,
        Linus Walleij <>,
        Alexandre Courbot <>,
        "Rafael J. Wysocki" <>,
        Len Brown <>
Subject: Re: [PATCH v1 2/3] gpio: Add support for TPS68470 GPIOs

On Sun, Jun 11, 2017 at 7:50 PM, Sakari Ailus <> wrote:
> On Sun, Jun 11, 2017 at 04:40:16PM +0300, Andy Shevchenko wrote:
>> On Sun, Jun 11, 2017 at 2:30 PM, Sakari Ailus <> wrote:

>> > Again, I'm not really worried about this driver, but the ACPI tables. How
>> > does the difference show there?
>> Same way. You will have common numbering over the chip [0, 9]. It will
>> be just an abstraction inside the driver.
> Oh, in that case that should be a non-issue.

>> Above states the opposite, so, it's clear to me that abstraction of 2
>> GPIO chips over 1 can be utilized here.
> Sounds fine to me, taken that this does not add complications to ACPI
> tables.

They just need to share the same ACPI_HANDLE (it might require to do
this in generic way in gpiolib) and have a continuous numbering (easy
to achieve with carefully chosen bases).

With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists