public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn•ch>
To: Jiri Pirko <jiri@resnulli•us>
Cc: Jakub Kicinski <kuba@kernel•org>,
	Michael Walle <michael@walle•cc>,
	Heiner Kallweit <hkallweit1@gmail•com>,
	Russell King <linux@armlinux•org.uk>,
	netdev@vger•kernel.org
Subject: Re: PHY firmware update method
Date: Fri, 30 Sep 2022 14:36:47 +0200	[thread overview]
Message-ID: <Yzbi335GQGbGLL4k@lunn.ch> (raw)
In-Reply-To: <Yzan3ZgAw3ImHfeK@nanopsycho>

> Yeah, I tend to agree here. I believe that phylib should probably find a
> separate way to to the flash.
> 
> But perhaps it could be a non-user-facing flash. I mean, what if phylib
> has internal routine to:
> 1) do query phy fw version
> 2) load a fw bin related for this phy (easy phy driver may provide the
> 				       path/name of the file)
> 3) flash if there is a newer version available

That was my first suggestion. One problem is getting the version from
the binary blob firmware. But this seems like a generic problem for
linux-firmware, so maybe somebody has worked on a standardised header
which can be preppended with this meta data?

      Andrew

  reply	other threads:[~2022-09-30 12:37 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 [this message]
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
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=Yzbi335GQGbGLL4k@lunn.ch \
    --to=andrew@lunn$(echo .)ch \
    --cc=hkallweit1@gmail$(echo .)com \
    --cc=jiri@resnulli$(echo .)us \
    --cc=kuba@kernel$(echo .)org \
    --cc=linux@armlinux$(echo .)org.uk \
    --cc=michael@walle$(echo .)cc \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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