linux-kernel - Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY registration

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] [day] [month] [year] [list]

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

On 2020-06-24 17:50, Russell King - ARM Linux admin wrote:
> On Wed, Jun 24, 2020 at 09:06:28AM -0700, Florian Fainelli wrote:
>> On 6/24/2020 6:48 AM, Bartosz Golaszewski wrote:
>>> I didn't expect to open such a can of worms...
>>>
>>> This has evolved into several new concepts being proposed vs my
>>> use-case which is relatively simple. The former will probably take
>>> several months of development, reviews and discussions and it will
>>> block supporting the phy supply on pumpkin boards upstream. I would
>>> prefer not to redo what other MAC drivers do (phy-supply property on
>>> the MAC node, controlling it from the MAC driver itself) if we've
>>> already established it's wrong.
>>
>> You are not new to Linux development, so none of this should come as a
>> surprise to you. Your proposed solution has clearly short comings and is
>> a hack, especially around the PHY_ID_NONE business to get a phy_device
>> only then to have the real PHY device ID. You should also now that "I
>> need it now because my product deliverable depends on it" has never been
>> received as a valid argument to coerce people into accepting a solution
>> for which there are at review time known deficiencies to the proposed
>> approach.
> 
> It /is/ a generic issue.  The same problem exists for AMBA Primecell
> devices, and that code has an internal deferred device list that it
> manages.  See drivers/amba/bus.c, amba_deferred_retry_func(),
> amba_device_try_add(), and amba_device_add().
> 
> As we see more devices gain this property, it needs to be addressed
> in a generic way, rather than coming up with multiple bus specific
> implementations.
> 
> Maybe struct bus_type needs a method to do the preparation to add
> a device (such as reading IDs etc), which is called by device_add().
> If that method returns -EPROBE_DEFER, the device gets added to a
> deferred list, which gets retried when drivers are successfully
> probed.  Possible maybe?

FWIW that would be ideal for solving an ordering a problem we have in 
the IOMMU subsystem too (which we currently sort-of-handle by deferring 
driver probe from dma_configure(), but it really needs to be done 
earlier and not depend on drivers being present at all).

Robin.