Device probing proceeds even when the default pinctrl state is invalid

[Romain Izard <romain.izard.pro@gmail.com>]

Hello Linus,

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 ?

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. 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.

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

For an existing example, in the device tree for Atmel's
SAMA5D2_Xplained board, 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.

I encountered this problem because I wanted to model in device tree a
system where the main SoC running Linux is connected to a secondary
chip, using two different protocols on the same pins. Using the
SAMA5D2's pin muxing, the secondary chip can be accessed either by a
serial port in normal use, or by bitbanging on the multiplexed GPIOs
when programming it. I created two devices with conflicting pinctrl
configurations, expecting only one of them to be successfully probed,
and to use the "bind" and "unbind" sysfs files to select the correct
driver. Choosing which device to probe first on startup is an other
issue in this case, that remains to be addressed.

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 ?

Best regards,
-- 
Romain Izard