On Tue, Sep 04, 2018 at 02:49:24PM +0200, Johan Hovold wrote:
> On Sat, Aug 25, 2018 at 10:47:44PM +0200, Karoly Pados wrote:
Here are some more comments on the setup functions, after having
prepared a patch adding support to FT232R.
> > +static int ftx_gpioconf_init(struct usb_serial_port *port)
On Tue, Sep 04, 2018 at 06:07:49PM +, Karoly Pados wrote:
> >>> + priv->gc.ngpio = 4;
> >>
> >> Shouldn't this be handled the other way round? IIRC there are two FTX
> >> device types with four pins, and one type where only one pin is
> >> accessible.
> >
> > There are 4 devices with 1 GPIO,
On Tue, Sep 04, 2018 at 05:53:14PM +, Karoly Pados wrote:
> > Actually, after thinking about this some more, it may be better to just
> > configure all pins during probe. The device is managed by the kernel,
> > and we can't really consider what user space may have done before, at
> > least if
>>> + priv->gc.ngpio = 4;
>>
>> Shouldn't this be handled the other way round? IIRC there are two FTX
>> device types with four pins, and one type where only one pin is
>> accessible.
>
> There are 4 devices with 1 GPIO, 1 device with 2 GPIOs, 2 devices with 4
> GPIOs,
> and 1 device with 6 GPIO
Thanks for the review, I am on the road most of this week, but I will submit
a new patch this weekend with all your feedback incorporated. Until then here
are my inputs / answers to some of your points.
> Actually, after thinking about this some more, it may be better to just
> configure all pins
On Sat, Aug 25, 2018 at 10:47:44PM +0200, Karoly Pados wrote:
> This patch uses the CBUS bitbang mode of the device, so there is
> no conflict between the GPIO and VCP functionality.
Please make the commit message self-contained (e.g. don't rely on the
summary, or mail Subject, even if you feel li
