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
