From: Andrew Lunn <andrew@lunn.ch>
To: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@savoirfairelinux.com,
"David S. Miller" <davem@davemloft.net>,
Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH net-next 0/2] net: dsa: don't unmask port bitmaps
Date: Mon, 23 Oct 2017 23:11:09 +0200 [thread overview]
Message-ID: <20171023211109.GA23689@lunn.ch> (raw)
In-Reply-To: <20171023181731.7977-1-vivien.didelot@savoirfairelinux.com>
On Mon, Oct 23, 2017 at 02:17:29PM -0400, Vivien Didelot wrote:
> DSA has several bitmaps to store the type of ports: cpu_port_mask,
> dsa_port_mask and enabled_port_mask. But the code is inconsistently
> unmasking them.
>
> The legacy code tries to unmask cpu_port_mask and dsa_port_mask but
> skips enabled_port_mask.
>
> The new bindings unmasks cpu_port_mask and enabled_port_mask but skips
> dsa_port_mask.
>
> In fact there is no need to unmask them because we are in the error
> path, and they won't be used after. Instead of fixing the unmasking,
> simply remove them.
Hi Vivien
I'm not looked at the code, travelling and don't have time.
What happens if the failure is -PROBE_DEFERRED, and it tried again
later. Will these masks be set back to 0? Or will they retain the old
values? I think there is supposed to be symmetry here, so that we undo
what we did, and so the next time we try again, we start from a good
state.
Andrew
next prev parent reply other threads:[~2017-10-23 21:11 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 ` Andrew Lunn [this message]
2017-10-23 21:26 ` [PATCH net-next 0/2] " Vivien Didelot
2017-10-24 0:54 ` Florian Fainelli
2017-10-24 9:22 ` Andrew Lunn
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=20171023211109.GA23689@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 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.