From: Colin Foster <colin.foster@in-advantage.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Claudiu Manoil <claudiu.manoil@nxp.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 net] net: mscc: ocelot: remove buggy and useless write to ANA_PFC_PFC_CFG
Date: Thu, 16 Sep 2021 18:24:29 -0700 [thread overview]
Message-ID: <20210917012429.GA647191@euler> (raw)
In-Reply-To: <20210916114917.aielkefz5gg7flto@skbuf>
On Thu, Sep 16, 2021 at 11:49:18AM +0000, Vladimir Oltean wrote:
> This will conflict with the other patch.... why didn't you send both as
> part of a series? By not doing that, you are telling patchwork to
> build-test them in parallel, which of course does not work:
> https://patchwork.kernel.org/project/netdevbpf/patch/20210916012341.518512-1-colin.foster@in-advantage.com/
>
> Also, why didn't you bump the version counter of the patch, and we're
> still at v1 despite the earlier attempt?
I wasn't sure if changing the names of the patch and the intent is what
would constitute a new "patch series" so then restart the counter for
the counters or not. I had figured "two new patches, two new counters"
which I understand now was incorrect.
In this particular case, should I have stuck with my first submission
title:
[PATCH v2 net] bug fix when writing MAC speed
and submitted the two patches?
I assume it would only cause headaches if I incremented the counter and
changed the name to something like
[PATCH v2 net] remove unnecessary register writes
or something simliar? Although your example below suggests I should
maybe submit the next set as
[PATCH v3 net] ocelot phylink fixes
>
> git format-patch -2 --cover-letter --subject-prefix="PATCH v3 net" -o /opt/patches/linux/ocelot-phylink-fixes/v3/
> ./scripts/get_maintainer.pl /opt/patches/linux/ocelot-phylink-fixes/v3/*.patch
> ./scripts/checkpatch.pl --strict /opt/patches/linux/ocelot-phylink-fixes/v3/*.patch
> # Go through patches, write change log compared to v2 using vimdiff, meld, git range-diff, whatever
> # Write cover letter summarizing what changes and why. If fixing bugs explain the impact.
> git send-email \
> --to='netdev@vger.kernel.org' \
> --to='linux-kernel@vger.kernel.org' \
> --cc='Vladimir Oltean <vladimir.oltean@nxp.com>' \
> --cc='Claudiu Manoil <claudiu.manoil@nxp.com>' \
> --cc='Alexandre Belloni <alexandre.belloni@bootlin.com>' \
> --cc='UNGLinuxDriver@microchip.com' \
> --cc='"David S. Miller" <davem@davemloft.net>' \
> --cc='Jakub Kicinski <kuba@kernel.org>' \
> /opt/patches/linux/ocelot-phylink-fixes/v3/*.patch
I've been using --to-cmd and --cc-cmd with get_maintainer.pl. If this is
ill-advised, I'll stop. I noticed it seemed to determine the list on a
per-patch-file basis instead of generating one single list.
>
> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> Please keep this tag but resend a new version. You can download the patch with the review tags automatically using:
> git b4 20210916010938.517698-1-colin.foster@in-advantage.com
> git b4 20210916012341.518512-1-colin.foster@in-advantage.com
>
> where "git b4" is an alias configured like this in ~/.gitconfig:
>
> [b4]
> midmask = https://lore.kernel.org/r/%s
> [alias]
> b4 = "!f() { b4 am -t -o - $@ | git am -3; }; f"
Thank you for all this. I understand you have better things to do than
to hold my hand through this process, so I greatly appreciate your help.
next prev parent reply other threads:[~2021-09-17 1:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 1:09 [PATCH v1 net] net: mscc: ocelot: remove buggy and useless write to ANA_PFC_PFC_CFG Colin Foster
2021-09-16 11:49 ` Vladimir Oltean
2021-09-16 14:52 ` Jakub Kicinski
2021-09-16 14:56 ` Vladimir Oltean
2021-09-17 1:24 ` Colin Foster [this message]
2021-09-17 2:34 ` Joakim Zhang
2021-09-17 3:38 ` Colin Foster
2021-09-17 10:39 ` Joakim Zhang
2021-09-17 13:49 ` Konstantin Ryabitsev
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=20210917012429.GA647191@euler \
--to=colin.foster@in-advantage.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vladimir.oltean@nxp.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.