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: <564D6D0B.8010204@electromag.com.au>
Date:	Thu, 19 Nov 2015 14:32:43 +0800
From:	Phil Reid <preid@...ctromag.com.au>
To:	Andrew Lunn <andrew@...n.ch>
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

On 19/11/2015 10:25 AM, Andrew Lunn wrote:
 >> 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.
Hadn't dug into the gpiod stuff that far. Yes looks like there limited support for
extracting from sub nodes. There's devm_get_gpiod_from_child which looks like it
does something like that but I don't have any idea how to go from an of_node to
a fwnode_handle.

 > +		gpio = of_get_named_gpio_flags(child, "reset-gpios", 0,
 > +					       &flags);
 > +		if (gpio_is_valid(gpio)) {
 > +			ret = devm_gpio_request_one(dev, gpio, flags,
 > +						    "switch_reset");
 > +			if (ret)
 > +				goto out_free_chip;

The flags passed into devm_gpio_request_one are of type GPIOF_* which don't
match the device tree definitions for flags. As your handling the device flags
manually I think devm_gpio_request_one flags should be 0. Or you can translate
the device tree flags and get devm_gpio_request_one to configure the polarity etc.
Then I think you don't need to do your polarity inversions later on.

 >
 >> 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 :-)
Worked as expected on my hardware, can see the line toggle, chip is configured correctly.

Tested-by: Phil Reid <preid@...ctromag.com.au>


 >
 >> 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.
Seems a sound plan.




-- 
Regards
Phil Reid

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