linux-kernel - Re: [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Dec 2016 18:41:00 +0100
From:   Peter Rosin <peda@...ntia.se>
To:     Sebastian Reichel <sre@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to
 share the ac-detect gpio

On 2016-12-14 18:01, Sebastian Reichel wrote:
> [of course I forgot to actually add gpio people, let's try again]
> 
> On Wed, Dec 14, 2016 at 05:59:21PM +0100, Sebastian Reichel wrote:
>> Hi,
>>
>> On Wed, Dec 14, 2016 at 12:56:45AM +0100, Peter Rosin wrote:
>>> If several parallel bq24735 chargers have their ac-detect gpios wired
>>> together (or if only one of the parallel bq24735 chargers have its
>>> ac-detect pin wired to a gpio, and the others are assumed to react the
>>> same), then all driver instances need to check the same gpio. But the
>>> gpio subsystem does not allow sharing gpios, so handle that locally.
>>
>> Adding GPIO subsystem people to see if they can come up with
>> something in the gpiod API for this usecase.

Right, I don't like how my new code steps away from gpio descriptors.

>>> However, only do this for the polling case, sharing is not supported if
>>> the ac detection is handled with interrupts.
>>
>> Why? I guess you only added the gpio polling stuff for the shared
>> gpio feature, so we can skip the gpio polling if we add shared irq
>> support instead?

Nope, the hw really can't do interrupts on the gpio, it's just not wired
up for that. The gpio is on an expander, and the irq line from the expander
top the cpu is not there (due to a desire to minimize the number of
connections between two parts of the system). So I need both polling and
sharing.

Cheers,
peda