All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauri Sandberg <maukka@ext.kapsi.fi>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	maukka@ext.kapsi.fi
Subject: Re: [PATCH] net: mv643xx_eth: handle EPROBE_DEFER
Date: Tue, 22 Feb 2022 07:42:30 +0200	[thread overview]
Message-ID: <91729285-67f9-8fdb-4f97-f0e958cff8dd@ext.kapsi.fi> (raw)
In-Reply-To: <YhQO52cvzIo8prKi@lunn.ch>


On 22.2.2022 0.15, Andrew Lunn wrote:
>>> Please can you add code to remove the platform device when the probe
>>> fails.
>>
>> I am looking at the vector 'port_platdev' that holds pointers to already
>> initialised ports. There is this mv643xx_eth_shared_of_remove(), which
>> probably could be utilised to remove them. Should I remove the platform
>> devices only in case of probe defer or always if probe fails?
>   
> In general, a failing probe should always undo anything it has done so
> far. Sometimes you can call the release function, or its
> helpers. Other times you do a goto out: and then release stuff in the
> reverse order it was taken.
> 
> It looks like platform_device_del() can take a NULL pointer, so it is
> probably O.K. to call mv643xx_eth_shared_of_remove().

While I am on it, should I call of_node_put() to all port nodes as is
being done to the current child node if probe fails in function
mv643xx_eth_shared_of_probe() [1]?

[1] 
https://elixir.bootlin.com/linux/v5.16/source/drivers/net/ethernet/marvell/mv643xx_eth.c#L2800

-- Mauri

  reply	other threads:[~2022-02-22  5:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21  6:24 [PATCH] net: mv643xx_eth: handle EPROBE_DEFER Mauri Sandberg
2022-02-21 12:21 ` Andrew Lunn
2022-02-21 18:25   ` Mauri Sandberg
2022-02-21 22:15     ` Andrew Lunn
2022-02-22  5:42       ` Mauri Sandberg [this message]
2022-02-23 14:23 ` [PATCH v2] net: mv643xx_eth: process retval from of_get_mac_address Mauri Sandberg
2022-02-24 16:57   ` Jakub Kicinski
2022-02-24 17:43     ` Andrew Lunn
2022-02-24 18:20   ` 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=91729285-67f9-8fdb-4f97-f0e958cff8dd@ext.kapsi.fi \
    --to=maukka@ext.kapsi.fi \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sebastian.hesselbarth@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.