Hi Mark, On Fri, Feb 12, 2021 at 1:55 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > On Fri, Feb 12, 2021 at 01:48:21PM +0100, Nicolas Saenz Julienne wrote: > > On Fri, 2021-02-12 at 12:31 +0000, Mark Brown wrote: > > > On Thu, Feb 11, 2021 at 07:08:20PM +0100, Nicolas Saenz Julienne wrote: > > > > > - if (xfer->tx_buf || xfer->rx_buf) { > > > > + if ((xfer->tx_buf || xfer->rx_buf) && xfer->len) { > > > > I think the issue here is more that some users were passing in buffers > > > with zero length transfers, the above check was already intended to > > > catch this case but was working on the assumption that if there was > > > nothing to transfer then no buffer would be provided. > > > Fair enough, maybe it makes sense to move the check into __spi_validate() and > > propagate an error upwards? > > No, I think it's fine - there's probably some sensible use case with > drivers reusing a statically allocated transfer/buffer set for multiple > operations and just tweaking the length as needed which seems a bit > weird but I can't think of a reason not to allow it. Your patch is > currently queued, all being well it'll get tested & pushed out later > today. Aren't the zero-length transfers also used to do tricks with the CS signal, e.g. combined with cs_change? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds