From: Andrew Lunn <andrew@lunn.ch>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Michael Walle <michael@walle.cc>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org, kuba@kernel.org
Subject: Re: PHY firmware update method
Date: Thu, 29 Sep 2022 14:28:13 +0200 [thread overview]
Message-ID: <YzWPXcf8kXrd73PC@lunn.ch> (raw)
In-Reply-To: <YzVDZ4qrBnANEUpm@nanopsycho>
> >devlink has become the standard way for upgrading firmware on complex
> >network devices, like NICs and TOR switches. That is probably a good
> >solution here. The problem is, what devlink instance to use. Only a
> >few MAC drivers are using devlink, so it is unlikely the MAC driver
> >the PHY is attached to has a devlink instance. Do we create a devlink
> >instance for the PHY?
>
> Ccing Jakub. I don't think it is good idea to create a devlink instance
> per-PHY. However, on the other hand, we have a devlink instance per
> devlink linecard now. The devlink linecard however has devlink
> representation, which PHY does not have.
>
> Perhaps now is the time to dust-off my devlink components implementation
> and use it for PHYs? IDF. Jakub, WDYT.
If we want to make the PHY a component of an existing devlink for a
MAC, we somehow have to find that devlink instance. A PHY is probably
a property of a port, so we can call netdev_to_devlink_port(), which
gives us a way into devlink.
However, the majority of MAC drivers don't have a devlink
instance. What do we do then? Have phylib create the devlink instance
for the MAC driver? That seems very wrong.
Which is why i was thinking the PHY should have its own devlink
instance.
Or we do firmware upgrade some other way.
Andrew
next prev parent reply other threads:[~2022-09-29 12:28 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 [this message]
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
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=YzWPXcf8kXrd73PC@lunn.ch \
--to=andrew@lunn.ch \
--cc=hkallweit1@gmail.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.