linux-kernel - pinctrl: kirkwood: gpio mode not being selected

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>] [day] [month] [year] [list]

Message-ID: <cd7367f5-d08f-44a4-33b8-3667e7ca735a@alliedtelesis.co.nz>
Date:   Tue, 28 Jul 2020 04:53:31 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: pinctrl: kirkwood: gpio mode not being selected

Hi,

I'm in the process updating our platforms from a v4.4.x based kernel to 
a v5.7 based one.

On one of our Marvell Kirkwood based boards I'm seeing a problem where a 
gpio isn't being driven (the gpio happens to be a reset to a PHY chip 
that our userspace switching code is attempting to talk to).

Our bootloader is inadvertently configuring MPP15 into uart0 RTS mode 
(probably a copy and paste from the reference board).

Under the v4.4 kernel by the time userspace gets started the MPP15 pin 
has been put into GPIO mode. With the latest v5.7 kernel the incorrect 
mode is retained.

I haven't gone bisecting but I'm guessing something somewhere has 
decided not to put the pin into GPIO mode (because that is the hardware 
default).

I probably need to define an explicit pinctrl node in my dts, but I 
wanted to make sure that this was an intentional change in behaviour.

Thanks,
Chris