linux-kernel - Re: [PATCH v1 2/3] Documentation: gpio: Add a section on what to return in ->get() callback

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:   Mon, 5 Dec 2022 09:43:32 +0800
From:   Kent Gibson <warthog618@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Marc Zyngier <maz@...nel.org>, linux-gpio@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Jonathan Corbet <corbet@....net>,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH v1 2/3] Documentation: gpio: Add a section on what to
 return in ->get() callback

On Sat, Dec 03, 2022 at 10:38:45AM +0100, Linus Walleij wrote:
> On Wed, Nov 30, 2022 at 4:55 PM Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> wrote:
> 
> > +The below table gathered the most used cases.
> > +
> > +==========  ==========  ===============  =======================
> > +  Input       Output         State        What value to return?
> > +==========  ==========  ===============  =======================
> > + Disabled    Disabled    Hi-Z             input buffer
> > + Disabled    OS/OD/etc   Single ended     [cached] output buffer
> > +    x        Push-Pull   Out              [cached] output buffer
> > + Enabled     Disabled    In               input buffer
> > + Enabled     OS/OD/etc   Bidirectional    input buffer
> > +==========  ==========  ===============  =======================
> 
> This looks about right to me, but we need more input, Kent?
> 

Firstly, I'm all for tightening up the driver contract, and hope that
whatever is decided will also be updated in driver.h itself.

I can also understand Andy wanting to add support for Bidirectional
using the existing API.

But, and please correct me if I'm wrong, the user has no control over
whether an open drain output is single ended or bidirectional, and
no visibility as to which the driver supports or chooses.
So the contract is still vague.

My preference would be for the driver API to be extended with a new
callback for the output buffer, say get_output(), and have the existing
get() always return the input buffer.  Both would return an error if the
buffer is unavailable or disconnected, e.g. in the Hi-Z case.
As per Hans' suggestions, this would keep the drivers simple.

Then cdev could determine the approriate buffer to return, depending
on the mode.  Or, better yet, we extend that through the uAPI and
handball that decision to the user.

Cheers,
Kent.