From: Andrew Lunn <andrew@lunn.ch>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@savoirfairelinux.com,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next 0/2] net: dsa: don't unmask port bitmaps
Date: Tue, 24 Oct 2017 11:22:34 +0200 [thread overview]
Message-ID: <20171024092234.GA2911@lunn.ch> (raw)
In-Reply-To: <be302ef8-7f12-aaf1-5f68-c4de89c7d83d@gmail.com>
> In case of probe deferral, you get the full probe function to exit with
> an error, and that usually involves freeing the recently allocated
> dsa_switch instance, and then allocating a new one when probe is
> re-entered, so that should not be a problem.
Hi Florian
That is the simple case. I remember having problems with more complex
cases, D in DSA. Switches 1 and 2 probe O.K, switch 3 fail with
EPROBE_DEFER. Switch 3, as you say, releases its dsa_switch instance,
so will get a freshly zero'ed new instance when it probes
again. However, switches 1 and 2 only experience the unwind at the DSA
level. The devices are not removed and later probed again. They have a
'dirty' dsa_switch structure the next time they are applied.
I just think there might be potential for regressions here. But i've
not yet looked at the details to really know if there actually is.
Andrew
next prev parent reply other threads:[~2017-10-24 9:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-23 18:17 [PATCH net-next 0/2] net: dsa: don't unmask port bitmaps Vivien Didelot
2017-10-23 18:17 ` [PATCH net-next 1/2] net: dsa: legacy: " Vivien Didelot
2017-10-23 18:17 ` [PATCH net-next 2/2] net: dsa: " Vivien Didelot
2017-10-23 21:11 ` [PATCH net-next 0/2] " Andrew Lunn
2017-10-23 21:26 ` Vivien Didelot
2017-10-24 0:54 ` Florian Fainelli
2017-10-24 9:22 ` Andrew Lunn [this message]
2017-10-26 8:06 ` David Miller
2017-10-26 8:43 ` Andrew Lunn
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=20171024092234.GA2911@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kernel@savoirfairelinux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@savoirfairelinux.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 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).