From: Andrew Lunn <andrew@lunn.ch>
To: Michael Walle <michael@walle.cc>
Cc: Jiri Pirko <jiri@resnulli.us>, Jakub Kicinski <kuba@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org, Keller Jacob E <jacob.e.keller@intel.com>
Subject: Re: PHY firmware update method
Date: Tue, 24 Jan 2023 21:42:22 +0100 [thread overview]
Message-ID: <Y9BCrtlXXGO5WOKN@lunn.ch> (raw)
In-Reply-To: <ced75f7f596a146b58b87dd2d6bad210@walle.cc>
> So if you'd do this during the PHY probe, it might try to update the
> firmware on every boot and fail. Would that be acceptable?
Do you have a feeling how long that takes?
Also, is it possible to put the firmware into RAM and run it from
there, rather than put it into the EEPROM?
> How long could can a firmware update during probe run? Do we need
> to do it in the background with the PHY being offline. Sounds like
> not something we want.
One device being slow to probe will slow down the probe of that
bus. But probe of other busses should be unaffected. I _guess_ it
might have a global affect on EPROBE_DEFER, the next cycle could be
delayed? Probably a question for GregKH, or reading the code.
If it going to be really slow, then i would suggest making use of
devlink and it being a user initiated operation.
Andrew
next prev parent reply other threads:[~2023-01-24 20:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 11:27 PHY firmware update method Michael Walle
2022-09-28 12:28 ` Andrew Lunn
2022-09-29 7:04 ` Jiri Pirko
2022-09-29 12:28 ` Andrew Lunn
2022-09-29 14:12 ` Jakub Kicinski
2022-09-29 14:53 ` Andrew Lunn
2022-09-30 8:25 ` Jiri Pirko
2022-09-30 12:36 ` Andrew Lunn
2022-09-30 14:45 ` Jakub Kicinski
2022-09-30 16:49 ` Keller, Jacob E
2022-10-03 12:18 ` Russell King (Oracle)
2022-10-03 14:42 ` Jakub Kicinski
2022-10-03 17:53 ` Keller, Jacob E
2022-10-03 18:04 ` Jacob Keller
2023-01-24 17:13 ` Michael Walle
2023-01-24 17:11 ` Michael Walle
2023-01-24 20:42 ` Andrew Lunn [this message]
2023-01-31 16:10 ` Michael Walle
2023-01-31 16:29 ` Russell King (Oracle)
2023-01-31 17:48 ` Michael Walle
2023-01-31 18:36 ` Jacob Keller
2023-01-31 18:41 ` Jakub Kicinski
2023-01-31 19:56 ` Jacob Keller
2023-01-31 21:07 ` Jakub Kicinski
2023-01-24 22:28 ` Jacob Keller
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=Y9BCrtlXXGO5WOKN@lunn.ch \
--to=andrew@lunn.ch \
--cc=hkallweit1@gmail.com \
--cc=jacob.e.keller@intel.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux@armlinux.org.uk \
--cc=michael@walle.cc \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.