On Tue, Apr 25, 2017 at 4:44 PM, Richard Fitzgerald rf@opensource.wolfsonmicro.com wrote:
On Tue, 2017-04-25 at 16:13 +0200, Linus Walleij wrote:
On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald rf@opensource.wolfsonmicro.com wrote:
This adds support for the GPIOs on Cirrus Logic Madera class codecs. Any pins not used for special functions (see the pinctrl driver) can be used as general single-bit input or output lines. The number of available GPIOs varies between codecs.
Signed-off-by: Nariman Poushin nariman@opensource.wolfsonmicro.com Signed-off-by: Richard Fitzgerald rf@opensource.wolfsonmicro.com Signed-off-by: Charles Keepax ckeepax@opensource.wolfsonmicro.com
Changes from V1:
- dt bindings moved to a separate patch
- dependent on pinctrl driver instead of parent MFD
- added get_direction function
- added .request / .free / .set_config to work with pinctrl driver
- register range with pinctrl driver
Nice, but...
ret = gpiochip_add_pin_range(&madera_gpio->gpio_chip, "madera-pinctrl",
0, 0, madera_gpio->gpio_chip.ngpio);
if (ret) {
dev_warn(&pdev->dev, "Failed to add pin range (%d)\n", ret);
return ret;
}
This is all fine, but we have generic code for adding ranges from the device tree, see Documentation/devicetree/bindings/gpio/gpio.txt
The range of gpio pins is a fixed property of the chip, and so is the combination of gpio+pinctrl drivers.
Well so is the IRQ number, but we still put that in the device tree.
I think the general principle of the DT maintainers is that DT should be used for things that the drivers don't already know and can't figure out.
It's a grayzone. People use ranges in the device tree for example when there are several instances of the same GPIO block with different ranges into a single pin controller and then it makes sense.
But in this case you have your separate chip with one instance so it doesn't make sense, keep it like this.
Also it is necessary to proble from boardfiles as you explained in the pinctrl patch.
Good job, it's a nice driver. Also the pinctrl driver is very nice.
Yours, Linus Walleij