On Thu, Sep 24, 2015 at 11:49 PM, H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> wrote: > [Me] >> I understand the approach, but this is the wrong way to do it. >> Instead of indicating that a pin on the pin controller should be >> open drain, the *consumer* specifying its gpios = <....> should >> do this. > > On a second thought I am no longer sure if that is the right approach. > > A gpio is for input and output of “0” and “1” values. And a gpio consumer > can control if the output should be active or inactive and input. > > How the output is physically represented (totem-pole or single-ended, > high power, low power etc.) is not a property of the gpio itself and > there is IMHO no need for the consumer to be able to define (or change) > it. As it is today we already have support for open drain/collector in the GPIO subsystem, as open drain pins should not be actively driven to 1 and open source pins not actively driven to 0, instead set as input for each of these use cases. (See drivers/gpio/gpiolib.c, grep for OPEN_DRAIN) > On SoC with integrated gpio controllers it is very common to have > pinmux definitions completely separated from the gpio controller > properties. But the gpio consumer can connect to pinctrl settings > to describe that the pin should have certain physical properties. > > There, it is common to be able to enable/disable pull-up/downs as > well. So this is up to the driver to implement today, but last week Tony Lindgren and Grygorii Strashko approached me to add flags for this into the GPIO subsystem as well. We already have a few GPIO drivers cross-calling pinctrl_request_gpio() pinctrl_free_gpio() pinctrl_gpio_direction_input() pinctrl_gpio_direction_output() So we can very well add a pinctrl_gpio_set_config() to set up pulls, open drain/source, drive strength etc if it makes sense. > So turning a totem-pole output (as it is available in the tca6424) > into an open-drain output is sort of turning off the pull-up transistor. > I.e. comparable to a pinmux setting. > > So such controllers should get the option to define pinctrl. Yes and Tony/Grygorii want to do that from the GPIO consumer side. > Some chips might have special control registers for doing that > while others need the trick to switch between input and output > mode but that is driver implementation detail. > > But I am not sure if this has other implications. We will hash it out as we go along, but I see no immediate blocker for this. Yours, Linus Walleij -- 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