linux-kernel - Re: [PATCH v1 1/2] auxdisplay: Move panel.c to drivers/auxdisplay folder

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]

Message-ID: <20170327090153.GC28802@haproxy.com>
Date:   Mon, 27 Mar 2017 11:01:53 +0200
From:   Willy TARREAU <wtarreau@...roxy.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Miguel Ojeda Sandonis <miguel.ojeda.sandonis@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v1 1/2] auxdisplay: Move panel.c to drivers/auxdisplay folder

On Mon, Mar 27, 2017 at 10:26:07AM +0200, Geert Uytterhoeven wrote:
> On Mon, Mar 27, 2017 at 10:11 AM, Willy TARREAU <wtarreau@...roxy.com> wrote:
> > On Fri, Mar 24, 2017 at 04:19:43PM +0100, Geert Uytterhoeven wrote:
> >> On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko
> >> <andriy.shevchenko@...ux.intel.com> wrote:
> >> > On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote:
> >> >> On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
> >> >> <andriy.shevchenko@...ux.intel.com> wrote:
> >> >> > It looks like panel.c belongs to auxdisplay subsystem.
> >> >> >
> >> >> > Move it to drivers/auxdisplay folder.
> >> >> > No functional changes intended.
> >> >>
> >> >> I didn't move it to drivers/auxdisplay/ because it not only provides
> >> >> auxdisplay functionality, but also keypad functionality.
> >> >
> >> > Yes, I have noticed this. But keypad functionality is optional while
> >> > panel is main one. I think you would agree on this.
> >>
> >> I don't care that much, though. Willy?
> >
> > Well, as long as it continues to work, I don't really care either. The
> > only thing to keep in mind is that it can be difficult to split the
> > driver in two since in some cases it's possible to use the same lines
> > for keypad and lcd.
> 
> Ideally, it should be replaced by a glue driver using charlcd, matrix-keypad,
> and (still to be written?) gpio-parport ;-)

It would still not be enough because the same GPIO line may be used both for
LCD and keypad, so there's a need for being able to share the same line. The
typical use case is when you connect the buttons to the D0-D7 data lines of
the parport and feed them back to one entry like ACK, BUSY or PE. When data
are sent to the LCD, if a button is pressed, it will act on the input signal
but we don't care because the keypad driver is not watching. And conversely,
when the keypad driver scans the buttons, it will change the data lines state
but the LCD doesn't care because its E line remains low.

In fact here the output signals should be seen as a shared bus with multiple
chip select signals. Note that in some designs it's even possible that pressing
multiple buttons will cause crap to be sent to the LCD by short-circuiting
the lines (if no diodes are used) but it might be acceptable for many designs,
especially the DIY field where the principle is "don't do it".

Cheers,
Willy