From: Johan Hovold <johan@kernel.org>
To: Karoly Pados <pados@pados.hu>
Cc: Johan Hovold <johan@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Loic Poulain <loic.poulain@linaro.org>,
andy.shevchenko@gmail.com, ajaykuee@gmail.com,
daniel.thompson@linaro.org
Subject: USB: serial: ftdi_sio: implement GPIO support for FT230X
Date: Wed, 5 Sep 2018 12:36:50 +0200 [thread overview]
Message-ID: <20180905103650.GA1089@localhost> (raw)
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)
Perhaps rename rename this using an ftdi_ prefix as well for consistency
with the current device-specific functions.
> > +{
> > + struct ftdi_private *priv = usb_get_serial_port_data(port);
> > + struct usb_serial *serial = port->serial;
> > + const u16 config_size = 0x24;
> > + u8 *config_buf;
> > + int result;
> > + u8 i;
> > +
[...]
> > + /*
> > + * All FT-X devices have at least 1 GPIO, some have more.
> > + * Chip-type guessing logic based on libftdi.
> > + */
> > + priv->gc.ngpio = 1;
> > + if (serial->dev->descriptor.bcdDevice == 0x1000) /* FT230X */
>
> Missing le16_to_cpu().
>
> > + 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.
>
> > +
> > + /* Determine which pins are configured for CBUS bitbanging */
> > + priv->gpio_altfunc = 0xff;
> > + for (i = 0; i < priv->gc.ngpio; ++i) {
> > + if (config_buf[0x1A + i] == FTDI_SIO_CBUS_MUX_GPIO)
>
> 0x1a warrants a define; but you shouldn't be reading 0x24 bytes from
> offset 0 above when the pinconfig is stored in just a couple of words.
>
> > + priv->gpio_altfunc &= ~BIT(i);
> > + }
> > +
> > + kfree(config_buf);
> > +
> > + return 0;
> > +}
How about returning the number of gpios instead of having every
device-specific function mess with priv->gc?
> > +
> > +static int ftdi_sio_gpio_init(struct usb_serial_port *port)
> > +{
> > + struct ftdi_private *priv = usb_get_serial_port_data(port);
> > + struct usb_serial *serial = port->serial;
> > + int result;
> > +
> > + /* Device-specific initializations */
> > + switch (priv->chip_type) {
> > + case FTX:
> > + result = ftx_gpioconf_init(port);
> > + break;
> > + default:
> > + return 0;
> > + }
> > +
> > + if (result < 0)
> > + return result;
> > +
> > + /* Register GPIO chip to kernel */
> > + priv->gc.label = "ftdi_sio";
>
> Maybe we shouldn't use the legacy sio suffix here; "ftdi" or "ftdi-cbus"
> should do.
>
> > + priv->gc.request = ftdi_sio_gpio_request;
> > + priv->gc.get_direction = ftdi_sio_gpio_direction_get;
> > + priv->gc.direction_input = ftdi_sio_gpio_direction_input;
> > + priv->gc.direction_output = ftdi_sio_gpio_direction_output;
> > + priv->gc.get = ftdi_sio_gpio_get;
> > + priv->gc.set = ftdi_sio_gpio_set;
> > + priv->gc.owner = THIS_MODULE;
> > + priv->gc.parent = &serial->interface->dev;
> > + priv->gc.base = -1;
> > + priv->gc.can_sleep = true;
> > +
> > + result = gpiochip_add_data(&priv->gc, port);
> > + if (!result)
> > + priv->gpio_registered = true;
> > +
> > + return result;
> > +}
> > +#define FTDI_SIO_CBUS_MUX_GPIO 8
And this one needs to have an FTX infix as it's FTX specific (e.g.
rename as FTDI_FTX_CBUS_MUX_IOMODE, which I believe better matches with
the various docs).
Johan
next reply other threads:[~2018-09-05 10:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 10:36 Johan Hovold [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-09-05 8:21 USB: serial: ftdi_sio: implement GPIO support for FT230X Johan Hovold
2018-09-05 8:19 Johan Hovold
2018-09-04 18:07 Karoly Pados
2018-09-04 17:53 Karoly Pados
2018-09-04 12:49 Johan Hovold
2018-08-28 0:44 kbuild test robot
2018-08-25 20:47 Karoly Pados
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180905103650.GA1089@localhost \
--to=johan@kernel.org \
--cc=ajaykuee@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=daniel.thompson@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=loic.poulain@linaro.org \
--cc=pados@pados.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).