From: Andrew Lunn <andrew@lunn.ch>
To: Josua Mayer <josua@solid-run.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH RFC] net: sfp: support assigning status LEDs to SFP connectors
Date: Tue, 10 May 2022 14:13:42 +0200 [thread overview]
Message-ID: <YnpW9nSZ2zMAmmq0@lunn.ch> (raw)
In-Reply-To: <1bc46272-f26b-14a5-0139-a987b47a5814@solid-run.com>
> > As far as i'm aware, the in kernel code always has a netdev for each
> > MAC. Are you talking about the vendor stack?
> The coprocessor can be configured both at boot-time and runtime.
> During runtime there is a vendor tool "restool" which can create and destroy
> network interfaces, which the dpaa2 driver knows to discover and bind to.
There should not be any need to use a vendor tool for mainline. In
fact, that is strongly discouraged, since it leads to fragmentation,
each device doing its own thing, the user needing to read each vendors
user manual, rather than it just being a standard Unix box with
interfaces.
What should happen is that all the front panel interfaces exist from
boot. If you want to add them to a bridge, for example, you do so in
the normal linux way, create a bridge and add an interface to the
bridge. The kernel driver can then talk to the coprocessor and magic
up a dpaa2 bridge object, and add the port to the bridge, but as far
as the user is concerned, it should all be the usual iproute2
commands, nothing more.
Andrew
next prev parent reply other threads:[~2022-05-10 12:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 12:29 [PATCH RFC] net: sfp: support assigning status LEDs to SFP connectors Josua Mayer
2022-05-09 12:49 ` Andrew Lunn
2022-05-10 8:56 ` Josua Mayer
2022-05-10 12:13 ` Andrew Lunn [this message]
2022-05-11 10:26 ` Russell King (Oracle)
2022-05-11 14:48 ` Ioana Ciornei
2022-05-11 10:12 ` Russell King (Oracle)
2022-05-11 15:48 ` Ioana Ciornei
2022-05-18 7:42 ` Josua Mayer
2022-05-09 15:54 ` Russell King (Oracle)
2022-05-10 9:44 ` Josua Mayer
2022-05-11 10:21 ` Russell King (Oracle)
2022-05-11 13:22 ` Ioana Ciornei
2022-05-11 13:39 ` Russell King (Oracle)
2022-06-01 10:18 ` Josua Mayer
2022-06-01 10:52 ` Russell King (Oracle)
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=YnpW9nSZ2zMAmmq0@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=josua@solid-run.com \
--cc=kuba@kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@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 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).