From: Jakub Kicinski <kuba@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Jiri Pirko <jiri@resnulli.us>, 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: Thu, 29 Sep 2022 07:12:09 -0700 [thread overview]
Message-ID: <20220929071209.77b9d6ce@kernel.org> (raw)
In-Reply-To: <YzWPXcf8kXrd73PC@lunn.ch>
On Thu, 29 Sep 2022 14:28:13 +0200 Andrew Lunn wrote:
> 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.
Tricky stuff, how would you expose the topology of the system to
the user? My initial direction would also be component. Although
it may be weird if MAC has a way to flash "all" components in one go,
and that did not flash the PHY :S
Either way I don't think we can avoid MACs having a devlink instance
because there needs to be some form of topology formed.
next prev parent reply other threads:[~2022-09-29 14:12 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 [this message]
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=20220929071209.77b9d6ce@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=hkallweit1@gmail.com \
--cc=jiri@resnulli.us \
--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.