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: <ef753ab98cf19ce4482e76864d406c1e@pados.hu>
Date:   Tue, 18 Sep 2018 09:35:35 +0000
From:   "Karoly Pados" <pados@...os.hu>
To:     "Johan Hovold" <johan@...nel.org>
Cc:     "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

>> + 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?


>> +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?
Does that mean something can call into our module while this method is running?
If not, I'm clueless about the possible race here.