Netdev Archive on
help / color / mirror / Atom feed
From: Jakub Kicinski <>
To: Vladimir Oltean <>
Cc: Leon Romanovsky <>,
	Vladimir Oltean <>,, Andrew Lunn <>,
	Vivien Didelot <>,
	Florian Fainelli <>
Subject: Re: [RFC PATCH net] net: dsa: tear down devlink port regions when tearing down the devlink port on error
Date: Tue, 7 Sep 2021 08:44:31 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210905110735.asgsyjygsrxti6jk@skbuf>

On Sun, 5 Sep 2021 14:07:35 +0300 Vladimir Oltean wrote:
> Again, fallback but not during devlink port register. The devlink port
> was registered just fine, but our plans changed midway. If you want to
> create a net device with an associated devlink port, first you need to
> create the devlink port and then the net device, then you need to link
> the two using devlink_port_type_eth_set, at least according to my
> understanding.
> So the failure is during the creation of the **net device**, we now have a
> devlink port which was originally intended to be of the Ethernet type
> and have a physical flavour, but it will not be backed by any net device,
> because the creation of that just failed. So the question is simply what
> to do with that devlink port.

Is the failure you're referring to discovered inside the
register_netdevice() call?

> The only thing I said about the devlink API in the commit description is
> that it would have been nice to just flip the type and flavour of a
> devlink port, post registration. That would avoid a lot of complications
> in DSA. But that is obviously not possible, and my patch does not even
> attempt to do it. What DSA does today, and will still do after the patch
> we are discussing on, is to unregister that initial devlink port, and
> create another one with the unused flavour, and register that one.
> The reason why we even bother to re-register a devlink port a second
> time for a port that failed to create and initialize its net_device is
> basically for consistency with the ports that are statically disabled in
> the device tree. Since devlink is a mechanism through which we gain
> insight into the hardware, and disabled ports are still physically
> present, just, you know, disabled and not used, their devlink ports
> still exist and can be used for things like dumping port regions.
> We treat ports that fail to find their PHY during probing as
> 'dynamically disabled', and the expectation is for them to behave just
> the same as ports that were statically disabled through the device tree.
> My change is entirely about how to properly structure the code such that
> we unregister the port regions that a devlink port might have, before
> unregistering the devlink port itself, and how to re-register those port
> regions then, after the new devlink port was registered.

  parent reply	other threads:[~2021-09-07 15:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 23:17 Vladimir Oltean
2021-09-05  7:07 ` Leon Romanovsky
2021-09-05  8:45   ` Vladimir Oltean
2021-09-05 10:25     ` Leon Romanovsky
2021-09-05 10:31       ` Vladimir Oltean
2021-09-05 10:47         ` Leon Romanovsky
2021-09-05 11:07           ` Vladimir Oltean
2021-09-05 13:01             ` Leon Romanovsky
2021-09-05 15:01               ` Vladimir Oltean
2021-09-07 15:44             ` Jakub Kicinski [this message]
2021-09-07 15:47               ` Florian Fainelli
2021-09-07 16:43                 ` Andrew Lunn
2021-09-07 16:49                   ` Florian Fainelli
2021-09-07 22:59                     ` Leon Romanovsky
2021-09-08 20:21                     ` Vladimir Oltean

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH net] net: dsa: tear down devlink port regions when tearing down the devlink port on error' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).