netdev - Re: [PATCH 2/3 v2] net: smsc911x: request and deassert optional RESET GPIO

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: <CACRpkdbd=qby2AymyNm7Mm7F2HMHGJ_rpbO6uHD8JVr+Up51iA@mail.gmail.com>
Date:   Wed, 7 Sep 2016 11:59:35 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Jeremy Linton <jeremy.linton@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Steve Glendinning <steve.glendinning@...c.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Kamlakant Patel <kamlakant.patel@...adcom.com>,
        Pavel Fedin <p.fedin@...sung.com>
Subject: Re: [PATCH 2/3 v2] net: smsc911x: request and deassert optional RESET GPIO

On Wed, Aug 31, 2016 at 5:08 PM, Jeremy Linton <jeremy.linton@....com> wrote:
> On 08/24/2016 07:59 AM, Linus Walleij wrote:
>>
>> On some systems (such as the Qualcomm APQ8060 Dragonboard) the
>> RESET signal of the SMSC911x is not pulled up by a resistor but
>> connected to a GPIO line, so that the operating system must
>> explicitly deassert RESET before use.
>>
>> Support this in the SMSC911x driver so this ethernet connector
>> can be used on such targets.
>
> Hmm, at least in our hardware case AFAIK (juno/lan9118) the hardware reset
> line on the lan9118 is active low, but the chip itself is documented as
> having internal pullups so that it may be left unconnected.

I guess this is only a comment about the contents of the commit message,
I'll check it up and augment.

This:

+       /* Request optional RESET GPIO */
+       pdata->reset_gpiod = devm_gpiod_get_optional(&pdev->dev,
+                                                    "reset",
+                                                    GPIOD_OUT_LOW);

Is Linux-internal way of saying "deassert the RESET" line, it does
*not* mean "drive it low".

GPIO lines are configured in the device tree for the platform in
question, and what you say about it being active low is true, and
that is why the device tree for the DragonBoard looks like so:

+ reset-gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;

Flagging it active low in the device tree make sure it is driven
high by the statement in the code.

> Beyond that, is it not possible for the firmware to get the reset pin in the
> correct configuration, so that linux doesn't have to mess with it?

That is always possible, and in that case you simply do not specify
the GPIO line for RESET. But this firmware for the APQ8060 DragonBoard
does not do it and Qualcomm is not going to update it, and I need
to deal with it.

Yours,
Linus Walleij