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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181121124237.GC8059@sirena.org.uk>
Date:   Wed, 21 Nov 2018 12:42:37 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Anatolij Gustschin <agust@...x.de>
Cc:     linux-usb@...r.kernel.org, linux-spi@...r.kernel.org,
        linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org,
        gregkh@...uxfoundation.org, atull@...nel.org, mdf@...nel.org
Subject: Re: [PATCH v2 2/3] spi: add FTDI MPSSE SPI controller driver

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?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)