All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>
Subject: Re: [PATCH net] net: dsa: call teardown method on probe failure
Date: Thu, 4 Feb 2021 17:06:15 +0000	[thread overview]
Message-ID: <20210204170614.zutxxuufsx53lcgg@skbuf> (raw)
In-Reply-To: <YBwoKiRlOmi3my5G@lunn.ch>

On Thu, Feb 04, 2021 at 06:00:26PM +0100, Andrew Lunn wrote:
> On Thu, Feb 04, 2021 at 06:33:51PM +0200, Vladimir Oltean wrote:
> > Since teardown is supposed to undo the effects of the setup method, it
> > should be called in the error path for dsa_switch_setup, not just in
> > dsa_switch_teardown.
> 
> I disagree with this. If setup failed, it should of cleaned itself up.
> That is the generally accepted way of doing things. If a function is
> going to exit with an error, it should first undo whatever it did
> before exiting.
> 
> You are adding extra semantics to the teardown op. It can no longer
> assume setup was successful. So it needs to be very careful about what
> it tears down, it cannot assume everything has been setup. I doubt the
> existing implementations actually do that.

I'm sorry, I don't understand.
I write a driver, I implement .setup(). I allocate some memory, I expect
that I can deallocate it in .teardown().
Now dsa_switch_setup comes, calls my .setup() which succedes. But then
mdiobus_register(ds->slave_mii_bus) which comes right after .setup()
fails. Are you saying we shouldn't call the driver's .teardown()?
Why not?

  reply	other threads:[~2021-02-04 17:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04 16:33 [PATCH net] net: dsa: call teardown method on probe failure Vladimir Oltean
2021-02-04 17:00 ` Andrew Lunn
2021-02-04 17:06   ` Vladimir Oltean [this message]
2021-02-04 17:18     ` Andrew Lunn
2021-02-04 19:33 ` Florian Fainelli
2021-02-05  4:40 ` patchwork-bot+netdevbpf

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=20210204170614.zutxxuufsx53lcgg@skbuf \
    --to=vladimir.oltean@nxp.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.com \
    /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.