netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Lukasz Majewski <lukma@denx.de>
Cc: Andrew Lunn <andrew@lunn.ch>, Vladimir Oltean <olteanv@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/7] dsa: marvell: Correct value of max_frame_size variable after validation
Date: Thu, 9 Mar 2023 15:31:10 +0000	[thread overview]
Message-ID: <ZAn7vkjj0bYdZnhz@shell.armlinux.org.uk> (raw)
In-Reply-To: <20230309154350.0bdc54c8@wsk>

On Thu, Mar 09, 2023 at 03:43:50PM +0100, Lukasz Majewski wrote:
> Hi Russell,
> 
> Please correct my understanding - I do see two approaches here:
> 
> A. In patch 1 I do set the max_frame_size values (deduced). Then I add
> validation function (patch 2). This function shows "BUG:...." only when
> we do have a mismatch. In patch 3 I do correct the max_frame_size
> values (according to validation function) and remove the validation
> function. This is how it is done in v5 and is going to be done in v6.

I don't see much point in adding the validation, then correcting the
values that were added in patch 1 that were identified by patch 2 in
patch 3 - because that means patch 1's deduction was incorrect in
some way.

If there is any correction to be done, then it should be:

patch 1 - add the max_frame_size values
patch 2 - add validation (which should not produce any errors)
patch 3 - convert to use max_frame_size, and remove validation, stating
  that the validation had no errors
patch 4 (if necessary) - corrections to max_frame_size values if they
  are actually incorrect (in other words, they were buggy before patch
  1.)
patch 5 onwards - the rest of the series.

> B. Having showed the v5 in public, the validation function is known.
> Then I do prepare v6 with only patch 1 having correct values (from the
> outset) and provide in the commit message the code for validation
> function. Then patch 2 and 3 (validation function and the corrected
> values of max_frame_size) can be omitted in v6.
> 
> For me it would be better to choose approach B.

I would suggest that is acceptable for the final round of patches, but
I'm wary about saying "yes" to it because... what if something changes
in that table between the time you've validated it, and when it
eventually gets accepted. Keeping the validation code means that during
the review of the series, and subsequent updates onto net-next (which
should of course include re-running the validation code) we can be
more certain that nothing has changed that would impact it.

What I worry about is if something changes, the patch adding the
values mis-patches (e.g. due to other changes - much of the context
for each hunk is quite similar) then we will have quite a problem to
sort it out.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2023-03-09 15:31 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09 12:54 [PATCH 0/7] dsa: marvell: Add support for mv88e6071 and 6020 switches Lukasz Majewski
2023-03-09 12:54 ` [PATCH 1/7] dsa: marvell: Provide per device information about max frame size Lukasz Majewski
2023-03-10 12:02   ` Vladimir Oltean
2023-03-10 12:25     ` Russell King (Oracle)
2023-03-10 13:04       ` Vladimir Oltean
2023-03-10 13:06         ` Vladimir Oltean
2023-03-10 13:17     ` Lukasz Majewski
2023-03-10 13:36       ` Vladimir Oltean
2023-03-10 14:10         ` Lukasz Majewski
2023-03-10 15:45       ` Vladimir Oltean
2023-03-10 16:12         ` Andrew Lunn
2023-03-12 15:55         ` Lukasz Majewski
2023-03-13 15:01           ` Vladimir Oltean
2023-03-10 14:04     ` Russell King (Oracle)
2023-03-09 12:54 ` [PATCH 2/7] net: dsa: mv88e6xxx: add support for MV88E6020 switch Lukasz Majewski
2023-03-10 14:23   ` Vladimir Oltean
2023-03-09 12:54 ` [PATCH 3/7] net: dsa: mv88e6xxx: add support for MV88E6071 switch Lukasz Majewski
2023-03-09 12:54 ` [PATCH 4/7] dsa: marvell: Define .set_max_frame_size() function for mv88e6250 SoC family Lukasz Majewski
2023-03-09 12:54 ` [PATCH 5/7] dsa: marvell: Add helper function to validate the max_frame_size variable Lukasz Majewski
2023-03-09 13:21   ` Russell King (Oracle)
2023-03-09 13:26     ` Russell King (Oracle)
2023-03-09 13:47       ` Lukasz Majewski
2023-03-09 13:52         ` Vladimir Oltean
2023-03-09 13:57           ` Lukasz Majewski
2023-03-09 12:54 ` [PATCH 6/7] dsa: marvell: Correct value of max_frame_size variable after validation Lukasz Majewski
2023-03-09 14:05   ` Russell King (Oracle)
2023-03-09 14:43     ` Lukasz Majewski
2023-03-09 15:31       ` Russell King (Oracle) [this message]
2023-03-10  9:47         ` Lukasz Majewski
2023-03-09 15:42       ` Andrew Lunn
2023-03-10 11:53         ` Lukasz Majewski
2023-03-10 12:06           ` Russell King (Oracle)
2023-03-10 13:19             ` Lukasz Majewski
2023-03-10 15:25             ` Vladimir Oltean
2023-03-09 12:54 ` [PATCH 7/7] dsa: marvell: Modify get max MTU callback to use per switch provided value Lukasz Majewski
2023-04-03 11:55 ` [PATCH 0/7] dsa: marvell: Add support for mv88e6071 and 6020 switches 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:
  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=ZAn7vkjj0bYdZnhz@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=alexander.duyck@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukma@denx.de \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.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).