linux-kernel - Re: [PATCH v4] USB: serial: ftdi_sio: implement GPIO support for FT-X devices

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: <20180918094515.GD3943@localhost>
Date:   Tue, 18 Sep 2018 11:45:15 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Karoly Pados <pados@...os.hu>
Cc:     Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        Loic Poulain <loic.poulain@...aro.org>
Subject: Re: [PATCH v4] USB: serial: ftdi_sio: implement GPIO support for
 FT-X devices

On Tue, Sep 18, 2018 at 09:35:35AM +0000, Karoly Pados wrote:
> >> + goto out_free;
> >> +
> >> + /* Chip-type guessing logic based on libftdi. */
> >> + priv->gc.ngpio = 4; /* FT230X, FT231X */
> >> + if (le16_to_cpu(serial->dev->descriptor.bcdDevice) != 0x1000)
> >> + priv->gc.ngpio = 1; /* FT234XD */
> > 
> > As I mentioned in my last mail: I've asked FTDI about this, but I fear
> > that FTX234XD has bcdDevice 0x1000 and we may need to just always
> > register all four pins after all.
> > 
> 
> To avoid missing 4.20, what is the latest time I should wait for FTDI's answer?
> Or should I just submit v5 as it is now and you'll incorporate FTDI's feedback
> when you receive it?

We'll get this into 4.20 either way, there's plenty of time. But I guess
we could play it safe and always register four pins, and if/when we get
more info about FT234XD we can implement registering just one pin in a
follow up patch.

Sounds good? If so I'll just merge your v5 (registering four pins) next
week.
 
> >> +static void ftdi_gpio_remove(struct usb_serial_port *port)
> >> +{
> >> + struct ftdi_private *priv = usb_get_serial_port_data(port);
> >> +
> >> + if (priv->gpio_used) {
> >> + /* Remark: Exiting CBUS-mode does not reset pin states too */
> >> + ftdi_exit_cbus_mode(port);
> >> + priv->gpio_used = false;
> >> + }
> > 
> > This should go after deregistration or we have a tiny race window here.
> 
> Can you elaborate on that to make sure I get it right? 
> By "deregistration" do you mean deregistering the GPIO chip below in the same method?

Yes.

> Does that mean something can call into our module while this method is running?
> If not, I'm clueless about the possible race here.

Correct, you can get gpio callbacks until the gpio chip has been
deregistered (anything coming in after that would be a gpiolib bug).

Thanks,
Johan