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