linux-kernel - Re: [RFC PATCH 1/2] Regulator: Core: Add clock-enable to fixed-regulator

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: <20190731212335.GL4369@sirena.org.uk>
Date:   Wed, 31 Jul 2019 22:23:35 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Philippe Schenker <philippe.schenker@...adex.com>
Cc:     "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/2] Regulator: Core: Add clock-enable to
 fixed-regulator

On Tue, Jul 30, 2019 at 09:00:01PM +0000, Philippe Schenker wrote:
> On Tue, 2019-07-30 at 19:10 +0100, Mark Brown wrote:
> > On Tue, Jul 30, 2019 at 07:30:04PM +0200, Philippe Schenker wrote:

> > > This adds the possibility to enable a fixed-regulator with a clock.

> > Why?  What does the hardware which makes this make sense look like?

> Tomorrow I can provide some schematics if needed. But its just a simple
> switch that is switched by a clock (on when clock is on and off when
> clock is off). This clock is the RGMII 50MHz clock for the ethernet
> PHY.

So it's not switching with the clock, the circuit somehow keeps the
switch latched?

> Why is a regulator even needed?
> - On power up of the PHY there is a huge time I have to wait for
> voltage rail to settle. In the range of 100ms.
> - Because there is a switch in the circuit I abstract it with a
> regulator-fixed in devicetree to make use of the startup-delay.
> - This regulator/switch is enabled with a clock. So to be able to use
> the startup delay I need an enable-by-clock on regulator-fixed.

It does feel like it might be simpler to just handle this as a quirk in
the PHY or ethernet driver, this feels like an awful lot of work to
add a sleep on what's probably only going to ever be one system.

> Why do I think this should be in core?
> - Normally this task is done with gpio that is already in regulator-
> core.
> - Because that is already there I added the functionality for enabled-
> by-clock-functionality.
> - I thought of creating a new regulator-clock driver but that would
> hold a lot of code duplication from regulator-fixed.

Hopefully not a *lot* of duplication.  The GPIOs are handled in the core
because they're really common and used by many regulator devices, the
same will I hope not be true for clocks.

> Why is this a good Idea at all?
> - Well I'm here for the software part and should just support our
> hardware. If that is a good Idea at all I don't know, for sure it is
> not a solution that is from some school-book. But I tried it and
> measured it out and it seems to work pretty fine.
> - The reason behind all of that is limited GPIO availability from the
> iMX6ULL.

I guess my question here is what the trip through the regulator API buys
us - it's a bit of a sledgehammer to crack a nut thing.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)