netdev - Re: [PATCH net-next 2/2] dsa: mv88e6xxx.c: Hardware reset the chip if available

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: <20151119022514.GE25930@lunn.ch>
Date:	Thu, 19 Nov 2015 03:25:14 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	Phil Reid <preid@...ctromag.com.au>
Cc:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
	Neil Armstrong <narmstrong@...libre.com>
Subject: Re: [PATCH net-next 2/2] dsa: mv88e6xxx.c: Hardware reset the chip
 if available

> This is a general query about what is the preferred method of allocating gpios.
> The gpiod* family of functions provided similar functionality and automatically
> deal with active low / high outputs, direction, inital value  etc...
> I raise this more for knowledge on what method I should use for my patches.

I first tried using gpiod, but failed. The API requires that the gpios
be in the root of the device's subtree in the DT blob. But here the
gpios are associated to a switch, and the switch part of the subtree
is one level down. gpiod has no way to get them from there.

> Other than that the concept looks good and something I has been
> looking at adding.

Please feel free to test it on your hardware and send a Tested-by :-)

> Would it be worth considering placing the chip in reset on driver
> remove?  I have an battery powered hardware platform using one of
> this marvell devices and for certain configurations we don't need
> the switch active. So unloading the module to place the device in
> reset and would save power.  Reloading would reinitialise the port.

I think we first need to get module unload/load working reliably.
This is being worked on. But i'm not against this in principle.  Power
saving in general needs working on for Marvall devices. There is no
suspend/resume support for example. It would also be good to ensure
the PHYs are powered off when not needed, etc.

    Andrew

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html