On 21/02/2018 03:24, Jan Kundrát wrote:
Hi,
I have two MCP23S17 at one SPI CS. That means that one SPI client node in my DT creates two gpiochip instances. I cannot assign names to the GPIO lines, though,
because each of these gpiochips actually uses just one common DT node:
gpio gpiochip3: names 32 do not match number of GPIOs 16
gpio gpiochip4: names 32 do not match number of GPIOs 16
I've already fixed a similar problem (several instances of a single subsystem struct within one SPI client) for regmap and pinctrl and gpiochip debugfs entries,
but I don't know how to proceed here. There's a very good reason for mcp23s08 to register two separate gpiochip instances, after all. About the only thing which
I can think of is walking the list of names once more from within mcp23s08_probe, or perhaps adding another DT property to also silence that warning. Or maybe
changing my userspace code so that it does not use GPIO names :).
Thoughts?
instead of:
gpiom1: gpio@0 {
compatible = "microchip,mcp23s17";
gpio-controller;
#gpio-cells = <2>;
spi-present-mask = <0x03>; // 2 devices address 0,1
reg = <0>; // chipselect 0
spi-max-frequency = <1000000>;
};
maybe something like:
gpiom1: gpio@0 {
compatible = "microchip,mcp23s17";
reg = <0>; // chip select line
spi-max-frequency = <1000000>;
gpios0: gpio@0 {
gpio-controller;
#gpio-cells = <2>;
spi-addr = <0x0>; // chipselect 0, device address 0
};
gpios1: gpio@1 {
gpio-controller;
#gpio-cells = <2>; // chipselect 0, device address 1
spi-addr = <0x1>;
};
};
Which would allow for different configuration of each chip.
Bit more work but each slave device would be a separate "device" then.
Which may also fix your previous naming problems.
I did something similar for an out of tree IIO driver.
Or the core spi code needs to allow two devices to share a CS.
--
Regards
Phil Reid
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
