Mark Brown <broonie@xxxxxxxxxx> writes:
> On Tue, Jan 05, 2016 at 09:50:54PM +0000, Måns Rullgård wrote:
>> Cyrille Pitchen <cyrille.pitchen@xxxxxxxxx> writes:
>
>> > + as->use_cs_gpios = true;
>> > + if (atmel_spi_is_v2(as) &&
>> > + !of_get_property(pdev->dev.of_node, "cs-gpios", NULL)) {
>> > + as->use_cs_gpios = false;
>> > + master->num_chipselect = 4;
>> > + }
>
>> This part breaks the AVR32 boards and probably anything else that
>> doesn't use devicetree but does use GPIOs for chip select.
>
> Shouldn't this just be setting defaults for the case where nothing is
> provided?
Traditionally the platform data included a GPIO number to use and that
was that. At some point DT support was added wherein the platform data
is overridden by cs_gpio from struct spi_device if this is valid (it is
set to a negative value by default). Thus far all was well. Then came
this patch. It assumes that everybody uses DT and treats a missing
cs-gpios property as indication that the controller's own pins should be
used. It also assumes that if any device uses GPIO for CS all of them
do, even though the SPI core driver might provide a partial list
(probably since many boards don't use all the available chip selects,
but it doesn't prevent someone abusing this).
To work correctly in call cases, this driver should use, for each
peripheral, the following priority:
- spi->cs_gpio (filled from DT or -ENOENT)
- GPIO from platform data
- controller chip select pin
The trouble is that there is no way to reliably tell a valid GPIO number
of zero in the platform data from an unset value. In practice, I
believe existing old boards using this driver all use a non-zero GPIO
(the AVR32 platform code requires this), so checking for a non-zero
number is probably sufficient. I'll cook up a patch for this unless
someone objects.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
