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: <20200622135106.GK4560@sirena.org.uk>
Date:   Mon, 22 Jun 2020 14:51:06 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Yisen Zhuang <yisen.zhuang@...wei.com>,
        Salil Mehta <salil.mehta@...wei.com>,
        Jassi Brar <jaswinder.singh@...aro.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Iyappan Subramanian <iyappan@...amperecomputing.com>,
        Keyur Chudgar <keyur@...amperecomputing.com>,
        Quan Nguyen <quan@...amperecomputing.com>,
        Frank Rowand <frowand.list@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Liam Girdwood <lgirdwood@...il.com>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Fabien Parent <fparent@...libre.com>,
        Stephane Le Provost <stephane.leprovost@...iatek.com>,
        Pedro Tsai <pedro.tsai@...iatek.com>,
        Andrew Perepech <andrew.perepech@...iatek.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY
 registration

On Mon, Jun 22, 2020 at 03:39:40PM +0200, Andrew Lunn wrote:

> The PHY subsystem cannot be the first to run into this problem, that
> you need a device structure to make use of the regulator API, but you
> need the regulator API to probe the device. How do other subsystems
> work around this?

If the bus includes power management for the devices on the bus the
controller is generally responsible for that rather than the devices,
the devices access this via facilities provided by the bus if needed.
If the device is enumerated by firmware prior to being physically
enumerable then the bus will generally instantiate the device model
device and then arrange to wait for the physical device to appear and
get joined up with the device model device, typically in such situations
the physical device might appear and disappear dynamically at runtime
based on what the driver is doing anyway.

> Maybe it is time to add a lower level API to the regulator framework?

I don't see any need for that here, this is far from the only thing
that's keyed off a struct device and having the device appear and
disappear at runtime can make things like runtime PM look really messy
to userspace.

We could use a pre-probe stage in the device model for hotpluggable
buses in embedded contexts where you might need to bring things out of
reset or power them up before they'll appear on the bus for enumeration
but buses have mostly handled that at their level.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ