linux-kernel - Re: [PATCH V2 7/7] USB: serial: f81232: Add gpiolib to GPIO device

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: <20200113152406.GD2301@localhost>
Date:   Mon, 13 Jan 2020 16:24:06 +0100
From:   Johan Hovold <johan@...nel.org>
To:     "Ji-Ze Hong (Peter Hong)" <hpeter@...il.com>
Cc:     Johan Hovold <johan@...nel.org>, gregkh@...uxfoundation.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        peter_hong@...tek.com.tw,
        "Ji-Ze Hong (Peter Hong)" <hpeter+linux_kernel@...il.com>
Subject: Re: [PATCH V2 7/7] USB: serial: f81232: Add gpiolib to GPIO device

On Thu, Jan 09, 2020 at 10:43:48AM +0800, Ji-Ze Hong (Peter Hong) wrote:

> Johan Hovold 於 2020/1/8 下午 10:46 寫道:

> > I understood from your other mail that the gpio device would not be able
> > to control the pins of an enabled port. In either case, I think you need
> > to refuse a request for a pin that's already in use by the corresponding
> > port.
> 
> OK, I'll change the code as previous mail as following:
> 
> I can read the UART enable state from GPIO Device, so I can do when the
> GPIO is associated with UART enabled, change it as output only otherwise
> can be set to input/output.
> 
> > Also is there a way to determine the number of available pins by
> > detecting the chip/package type? I'm assuming not all 36 pins are always
> > accessible?
> 
> Yes, we had register to get package type, I'll add UART enable & package
> type to determinate final GPIO pin out.

I suggest you start without any gpiochip, just add a simple control
driver which enables each UART (only the ones available in the package
and which have not been hardware disabled perhaps).

We don't want a user to be able to change the tranceiver mode behind the
serial driver's back so to speak.

Exposing GPIO pins (not MODE pins) in packages which have those enabled
should be fine, but you can add that later.

Johan