netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Adam Rudziński" <adam.rudzinski@arf.net.pl>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	netdev@vger.kernel.org, m.felsch@pengutronix.de,
	hkallweit1@gmail.com, richard.leitner@skidata.com,
	zhengdejin5@gmail.com, devicetree@vger.kernel.org,
	kernel@pengutronix.de, kuba@kernel.org, robh+dt@kernel.org
Subject: Re: [PATCH net-next 0/3] net: phy: Support enabling clocks prior to bus probe
Date: Fri, 4 Sep 2020 19:21:15 +0200	[thread overview]
Message-ID: <3f80e13f-fc62-37e7-3ee8-5626d26c32a9@arf.net.pl> (raw)
In-Reply-To: <20200904142347.GP3112546@lunn.ch>

W dniu 2020-09-04 o 16:23, Andrew Lunn pisze:
> On Fri, Sep 04, 2020 at 04:00:55PM +0200, Adam Rudziński wrote:
>> W dniu 2020-09-04 o 15:45, Andrew Lunn pisze:
>>>> Just a bunch of questions.
>>>>
>>>> Actually, why is it necessary to have a full MDIO bus scan already during
>>>> probing peripherals?
>>> That is the Linux bus model. It does not matter what sort of bus it
>>> is, PCI, USB, MDIO, etc. When the bus driver is loaded, the bus is
>>> enumerated and drivers probe for each device found on the bus.
>> OK. But is it always expected to find all the devices on the bus in the
>> first run?
> Yes. Cold plug expects to find all the device while scanning the bus.
>
>> Does the bus model ever allow to just add any more devices? Kind of,
>> "hotplug". :)
> Hotplug is triggered by hardware saying a new device has been
> added/removed after cold plug.
>
> This is not a hotplug case. The hardware has not suddenly appeared, it
> has always been there.
>
>     Andrew

There still is something that I would like to have clarified. Let me ask 
a bit more.

Even if the hardware is fixed, in general it doesn't mean that there is 
only one possible way of bringing it up in software (software in 
general, not necessarily Linux). Does the Linux driver/bus model define 
the allowed options more precisely?

Or:

There is "coldplug", there is "hotplug", and let's call the intermediate 
possibility "warmplug" - the hardware is fixed, but it is discovered not 
in the same scan. Some devices are found in scans triggered by something 
later. For example, by a driver which doesn't have its attached devices 
discovered yet. Let's assume for now that it makes sense, and this can 
result in a perfectly running system.
Does the Linux driver/bus model explicitly and strictly require 
"coldplug" approach in the case of fixed hardware? Is "warmplug" 
explicitly and strictly not allowed, or it just "doesn't feel right"?

Best regards,
Adam


  reply	other threads:[~2020-09-04 18:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-03  4:39 [PATCH net-next 0/3] net: phy: Support enabling clocks prior to bus probe Florian Fainelli
2020-09-03  4:39 ` [PATCH net-next 1/3] " Florian Fainelli
2020-09-03 20:39   ` Andrew Lunn
2020-09-03 21:25   ` Andrew Lunn
2020-09-03 21:28   ` Rob Herring
2020-09-03 21:42     ` Andrew Lunn
2020-09-03 21:50       ` Florian Fainelli
2020-09-03 21:43     ` Florian Fainelli
2020-09-03  4:39 ` [PATCH net-next 2/3] net: phy: mdio-bcm-unimac: Enable GPHY resources during bus reset Florian Fainelli
2020-09-03  4:39 ` [PATCH net-next 3/3] net: phy: bcm7xxx: request and manage GPHY clock Florian Fainelli
2020-09-04  6:15   ` Marco Felsch
2020-09-04 15:37     ` Florian Fainelli
2020-09-07  7:34       ` Marco Felsch
2020-09-07 19:07       ` Marco Felsch
2020-09-04  6:18   ` Marco Felsch
2020-09-04 15:38     ` Florian Fainelli
2020-09-07  7:37       ` Marco Felsch
2020-09-04  4:04 ` [PATCH net-next 0/3] net: phy: Support enabling clocks prior to bus probe Florian Fainelli
2020-09-04  6:19   ` Adam Rudziński
2020-09-04 13:45     ` Andrew Lunn
2020-09-04 14:00       ` Adam Rudziński
2020-09-04 14:23         ` Andrew Lunn
2020-09-04 17:21           ` Adam Rudziński [this message]
2020-09-04 13:58   ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3f80e13f-fc62-37e7-3ee8-5626d26c32a9@arf.net.pl \
    --to=adam.rudzinski@arf.net.pl \
    --cc=andrew@lunn.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=richard.leitner@skidata.com \
    --cc=robh+dt@kernel.org \
    --cc=zhengdejin5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).