Re: [PATCH v2 2/3] spi: add FTDI MPSSE SPI controller driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux