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

Powered by blists - more mailing lists