linux-kernel - Re: [PATCH 2/2] pinctrl: Add Pistachio SoC pin control driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdbt4MQYY7MqjFN-1Dp0am1PaOZ1YL+bKc8SJrtFDnSW_Q@mail.gmail.com>
Date:	Tue, 17 Mar 2015 13:16:52 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Andrew Bresticker <abrestic@...omium.org>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Linux MIPS <linux-mips@...ux-mips.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ezequiel Garcia <ezequiel.garcia@...tec.com>,
	James Hartley <james.hartley@...tec.com>,
	James Hogan <james.hogan@...tec.com>,
	Damien Horsley <Damien.Horsley@...tec.com>,
	Govindraj Raja <govindraj.raja@...tec.com>
Subject: Re: [PATCH 2/2] pinctrl: Add Pistachio SoC pin control driver

On Fri, Mar 6, 2015 at 7:51 PM, Andrew Bresticker <abrestic@...omium.org> wrote:
> On Fri, Mar 6, 2015 at 3:55 AM, Linus Walleij <linus.walleij@...aro.org> wrote:

>>> +static inline void gpio_writel(struct pistachio_gpio_bank *bank, u32 val,
>>> +                              u32 reg)
>>> +{
>>> +       writel(val, bank->base + reg);
>>> +}
>>
>> I don't see the point of these special readl/writel accessors. Just
>> use readl/writel
>> directly. Or consider readl/writel_relaxed() if MIPS has this.
>
> I actually find these useful for tracing MMIO accesses within a driver
> and it seems many other drivers do this too.  I can drop them though
> if you'd prefer.

OK does it turn up in ftrace etc? I was thinking these would be
inlined by the compiler (especially since you even state they shall
be inlined) and the symbols trashed?

>> (...)
>>> +static int pistachio_gpio_register(struct pistachio_pinctrl *pctl)
>>> +{
>>> +       struct device_node *child, *node = pctl->dev->of_node;
>>> +       struct pistachio_gpio_bank *bank;
>>> +       unsigned int i = 0;
>>> +       int irq, ret = 0;
>>> +
>>> +       for_each_child_of_node(node, child) {
>>> +               if (!of_find_property(child, "gpio-controller", NULL))
>>> +                       continue;
>>
>> So why not instead specify "simple-bus" as compatible on the parent node
>> and have each subnode be its own device (simple-bus will spawn platform
>> devices for all subnodes).
>>
>> Overall this composite-device pattern is discouraged if we can instead have
>> unique devices for each bank.
>
> I think there's an issue here though if some other device probes
> between the pinctrl driver and the gpiochip drivers.  Since all these
> pins are configured as GPIOs at POR, the pinctrl driver needs to clear
> the GPIO enable bit on a pin when enabling a pinmux function for that
> pin (see pistachio_pinmux_enable()).  If the gpiochip driver has yet
> to probe, attempting to map the pinctrl pin to a GPIO range/pin (via
> pinctrl_find_gpio_range_from_pin()) will fail and we won't be able to
> disable the GPIO function for that pin.

I was thinking the GPIO driver part should get a -EPROBE_DEFER when
trying to call gpiochip_add_pin_range() and continue later when the
pin controller is available?

And all drivers using GPIOs in turn get a -EPROBE_DEFER when
trying to get GPIOs on a not-yet registered GPIO chip.

Sorry if I don't really know how things work now... :(
It seems like a logical way to me.

>  Also it doesn't look like
> there's a good way to tell gpiolib to disable a GPIO form the pinctrl
> driver.

Define exactly what you mean by "disable". There is
pinctrl_free_gpio().

>  Any ideas?  I suppose I could keep the pin-to-GPIO mapping in
> the pinctrl driver in addition to expressing it in the DT with
> gpio-ranges, but that doesn't seem too nice.

The ranges shall definately be registered from the GPIO side of
the driver, that much I can tell you for sure...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/