On Tue, Nov 20, 2018 at 01:28:20AM +0100, Anatolij Gustschin wrote:

> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -113,6 +113,7 @@ obj-$(CONFIG_SPI_XILINX)          += spi-xilinx.o
>  obj-$(CONFIG_SPI_XLP)                        += spi-xlp.o
>  obj-$(CONFIG_SPI_XTENSA_XTFPGA)              += spi-xtensa-xtfpga.o
>  obj-$(CONFIG_SPI_ZYNQMP_GQSPI)               += spi-zynqmp-gqspi.o
> +obj-$(CONFIG_SPI_FTDI_MPSSE)         += spi-ftdi-mpsse.o
>  
>  # SPI slave protocol handlers
>  obj-$(CONFIG_SPI_SLAVE_TIME)         += spi-slave-time.o

Please keep the Makefile sorted.

> +++ b/drivers/spi/spi-ftdi-mpsse.c
> @@ -0,0 +1,673 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * FTDI FT232H MPSSE SPI controller driver

Please make the entire comment block here a C++ one so it looks more
consistent.

> +     struct gpiod_lookup_table *lookup[13];

This magic number for the size of the lookup table is not good.

> +static void ftdi_spi_chipselect(struct ftdi_spi *priv, struct spi_device 
> *spi,
> +                             bool value)
> +{
> +     int cs = spi->chip_select;
> +
> +     dev_dbg(&priv->master->dev, "%s: CS %d, cs mode %d, val %d\n",
> +             __func__, cs, (spi->mode & SPI_CS_HIGH), value);
> +
> +     gpiod_set_raw_value_cansleep(priv->cs_gpios[cs], value);
> +}

This is just a gpio chip select - can't it be handled by the core chip
select code?

> +     remaining = len;
> +     do {
> +             stride = min_t(size_t, remaining, SZ_64K - 3);

Rather than having a magic number for the buffer size it would be better
to either have a driver specific constant that's used consistently or
just use sizeof() when it's referenced in the code.  That way if the
buffer size is changed nothing will get missed.

> +             /* Last transfer with cs_change set, stop keeping CS */
> +             if (list_is_last(&t->transfer_list, &msg->transfers)) {
> +                     keep_cs = true;
> +                     break;
> +             }
> +             ftdi_spi_chipselect(priv, spi, !(spi->mode & SPI_CS_HIGH));
> +             usleep_range(10, 15);
> +             ftdi_spi_chipselect(priv, spi, spi->mode & SPI_CS_HIGH);

I'm not clear what this is intended to do?  It's overall not clear to me
that the driver needs to use transfer_one_message and not transfer_one,
the latter keeps more of the code in common code.

> +     /* Find max. slave chipselect number */
> +     num_cs = pd->spi_info_len;
> +     for (i = 0; i < num_cs; i++) {
> +             if (max_cs < pd->spi_info[i].chip_select)
> +                     max_cs = pd->spi_info[i].chip_select;
> +     }
> +
> +     if (max_cs > 12) {
> +             dev_err(dev, "Invalid max CS in platform data: %d\n", max_cs);
> +             return -EINVAL;
> +     }
> +     dev_dbg(dev, "CS count %d, max CS %d\n", num_cs, max_cs);
> +     max_cs += 1; /* including CS0 */

Why not just size the array based on the platform data?

Attachment: signature.asc
Description: PGP signature

Reply via email to