Re: Right amount of info in the DT

[Linus Walleij <linus.walleij@linaro.org>]

On Wed, May 31, 2017 at 6:36 PM, Yves Lefloch
<YvesMarie_Lefloch@sigmadesigns.com> wrote:

> I tried to carry on and add the other IPs' pins, and I've got a question
> regarding pin requesting.
> See, adding the smartcard's pins was easy because we don't have a driver for
> it yet, so the pins are just straightforward GPIOs, which the user-space can
> request using /sys/class/gpio/export.

Please do not use sysfs for userspace tests, familiarize yourself with
tools/gpio in the kernel and use these for testing using the ioctl()s.

> But that's not the case for the ethernet device, whose pins are already in
> use, although not requested explicitly by its driver
> (drivers/net/ethernet/aurora/nb8800.c). Which means user-space can also
> request/set them within the sysfs, and that is wrong.

It is common that a device allows simultaneous use of a pin for
GPIO and a certain device. (E.g. so that GPIO can "spy" on the pin
or similar.)

If on a certain system, this is not allowed, one shall set
.strict = true on the struct pinmux_ops, see
include/linux/pinctrl/pinmux.h

> - Is there a mechanism in the device tree to automatically request some pins
> for a driver once it gets loaded? I have looked at the `stateN_nodeM' thing
> in the documentation, but that doesn't seem to do the job without changes in
> the ethernet driver's code.

Yes those are called pin control hogs. Then the pins get associated with the
pin controller itself. Try first to associate the pins with the device actually
using them if possible.

> - Should the pins be declared at all if we know they are not going to be used
> for anything else than, for instance, ethernet? What about some removable
> device then, for instance UART as Thibaud pointed out previously?

I guess it depends on how much control of things you need in your system.

Also you might not need it now, but later on it turns out that in order to
properly deal with things like suspend/resume, you all of a sudden need
to switch pin control states when going to sleep and then it is nice if
the driver can handle these pins.

When in doubt, implement a driver for everything you have hardware
registers for, anything that is software controlled, I guess.

Yours,
Linus Walleij