On Thu, Feb 18, 2016 at 11:37 AM, Romain Izard
[off-list ref] wrote:

The current code for device probing tries to map the default pinctrl
state (in pinctrl_bind_pins), but is returning 0 or -EDEFER. If there
is an other error, it is not reported. This means that devices that do
not have any specified pinctrl state can be probed, which is a correct
behaviour that should be conserved, but it can also be an issue, as it
will fail to report any other issue with the specified pinctrl state.

Did I miss something that would explain why all other errors are ignored ?

Yeah we should probably respect a few errors and let some
pass. Please make a patch!

This also leads to a larger problem, as currently the device tree for
existing boards may specify invalid pinctrl configurations, but the
boards look like they work correctly, as long as nothing else tries to
use the same pins.

Well I guess if you look in the debugfs files it looks crazy does
it not? That is how I verify that the pins get bound right.
Especially in the file pinmux-pins

Correcting the issue may require a new
'strict-mapping' property in the pinctrl node in the device tree,
otherwise this correction would be an ABI regression.

Bah if the device tree is wrong it is wrong, we certainly do not
expect erroneous device trees that just "happen to work" to
keep working.

Is this pattern really a good one ? We're moving away from describing
hardware in here.

I don't understand.

For an existing example, in the device tree for Atmel's
SAMA5D2_Xplained board,

Where is this device tree, so I can look at it?

the mapping for the Ethernet transceiver's IRQ
line was missing it bias configuration, and thus the pins were not
reserved for the Ethernet use. I've just send a patch to correct it,
but breaking Ethernet on kernel upgrade for the boards using the
previous revisions would be an issue.

Hm, ask the Atmel DT maintainers what to do about this...
Nicolas: how real is this ABI issue?

We have patches bigger issues than this one before though.

In the current state of things, both devices are probed successfully
as conflicting pin sets are not recognized as an issue, which means
that my use case does not work.

Is the direction I'm taking something correct ?

I think so. The device trees should be correct, errors should be
handled.

Yours,
Linus Walleij