linux-kernel - Re: GPIO registration for external Ethernet PHY oscillator enable/disable

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: <CACRpkdYL-AQPDOZNrmeOeKbb+DvXBHB+hz37M+v_qKwzPzkApA@mail.gmail.com>
Date:	Tue, 7 Oct 2014 16:04:27 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Michael Welling <mwelling@...cinc.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Greg KH <gregkh@...uxfoundation.org>
Subject: Re: GPIO registration for external Ethernet PHY oscillator enable/disable

On Thu, Sep 25, 2014 at 9:17 PM, Michael Welling <mwelling@...cinc.com> wrote:

> How do I register a GPIO for use in the PHY suspend and resume code?
> Can it be handled outside of the PHY driver?

Nominally these days you should get a named GPIO using the
GPIO descriptor abstraction, putting a named GPIO reference in the
device tree node for the PHY, which should work fine
if you're using device tree for this system.
Documentation/gpio/consumer.txt

> If so how do ensure the appropriate suspend and resume sequencing?

AFAICT there is no good answer to this kind of questions. I guess
my best answer would be something like what has been said for
DRM drivers: handle all the sequence-sensitive hardware in one big
composite driver and handle sequencing in the driver.

> For reference, we are using a Micrel KSZ8081 PHY connected to a
> AT91SAMA5D35 processor.

I don't know how AT91 is progressing on the device tree side or if
it's strictly required to boot these days. If it is, you should be able
to proceed as indicated.

> Addendum:
> I ran into another situation where a GPIO enabled oscillator was used.
> The oscillator in this case drives the master clock for a audio codec.
> In the old days (before device tree), I could initialize the GPIO in the
> platform board file. Now with device tree I can setup the pin multipler
> but the initial state of the GPIO I am not sure how to set.

A driver needs to do this. Like a drivers/clk driver in this case I
guess?

> Is there a way to directly change the state of a GPIO pin from a
> devicetree entry?

I have suggested mechanisms like GPIO hogs to replace the need
for very basic drivers that would just take a GPIO during init,
set it and never do anything with it.

Like the gpiochip node should have some hog entries:

gpio-hog-high = <0>, <1>, <2>...;
gpio-hog-low = <...>;

Then they would be taken away from other consumers and not
possible to use for anything.

This has so far not been implemented though.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/