[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210127190159.s6irvdej3fs4cdai@skbuf>
Date: Wed, 27 Jan 2021 21:01:59 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Lorenzo Carletti <lorenzo.carletti98@...il.com>
Cc: linus.walleij@...aro.org, andrew@...n.ch, vivien.didelot@...il.com,
f.fainelli@...il.com, davem@...emloft.net, kuba@...nel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 1/1] net: dsa: rtl8366rb: standardize init jam tables
On Wed, Jan 27, 2021 at 02:06:32AM +0100, Lorenzo Carletti wrote:
> In the rtl8366rb driver there are some jam tables which contain
> undocumented values.
> While trying to understand what these tables actually do,
> I noticed a discrepancy in how one of those was treated.
> Most of them were plain u16 arrays, while the ethernet one was
> an u16 matrix.
> By looking at the vendor's droplets of source code these tables came from,
> I found out that they were all originally u16 matrixes.
>
> This commit standardizes the jam tables, turning them all into
> jam_tbl_entry arrays. Each entry contains 2 u16 values.
> This change makes it easier to understand how the jam tables are used
> and also makes it possible for a single function to handle all of them,
> removing some duplicated code.
>
> Signed-off-by: Lorenzo Carletti <lorenzo.carletti98@...il.com>
> ---
Reviewed-by: Vladimir Oltean <olteanv@...il.com>
Some trivia to read for next time:
Documentation/process/submitting-patches.rst
Documentation/networking/netdev-FAQ.rst
I'm saying this because you should have used git-format-patch with a
--subject-prefix of "PATCH v2 net-next" so that the tree onto which this
patch is to be applied would be clear. As things stand, the Patchwork
tests added by Jakub have marked your patch as "Target tree name not
specified in the subject":
https://patchwork.kernel.org/project/netdevbpf/patch/20210127010632.23790-2-lorenzo.carletti98@gmail.com/
Also, generally, when people give you a Reviewed-by tag in v1 but you
need to resend v2, you should copy those tags yourself below your
Signed-off-by in the new patch submission. Otherwise, if the patch is
going to be applied, the maintainer will pick up the review tags on the
latest posted version only. When you make significant modifications to
the patch and you're concerned that the reviewers might no longer agree
with the updated version they haven't yet seen, it's ok to drop
Reviewed-by tags. In this case, you dropped Linus's review tag.
Powered by blists - more mailing lists