linux-kernel - Re: Device probing proceeds even when the default pinctrl state is invalid

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: <CACRpkdamPh3pLetWs_S6b_BFWKDgZwiyTaOTQCJsm3cC=ZzLAA@mail.gmail.com>
Date:	Thu, 18 Feb 2016 21:07:57 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Romain Izard <romain.izard.pro@...il.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>
Cc:	Linux GPIO List <linux-gpio@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: Device probing proceeds even when the default pinctrl state is invalid

On Thu, Feb 18, 2016 at 11:37 AM, Romain Izard
<romain.izard.pro@...il.com> 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