Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 27 Jun 2023 01:42:42 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Horatiu Vultur <horatiu.vultur@microchip.com>
Cc:     Jerry Ray <jerry.ray@microchip.com>,
        Woojung Huh <woojung.huh@microchip.com>,
        UNGLinuxDriver@microchip.com, Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [PATCH] net: dsa: microchip: phy reg access 0x10-0x1f
Message-ID: <20230626224242.bqzqyfep5hvdkboh@skbuf>
References: <20230626182032.2079497-1-jerry.ray@microchip.com>
 <20230626192643.4zi2qyrjfllkxlmw@soft-dev3-1>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20230626192643.4zi2qyrjfllkxlmw@soft-dev3-1>
Precedence: bulk

Hi Horațiu,

On Mon, Jun 26, 2023 at 09:26:43PM +0200, Horatiu Vultur wrote:
> The 06/26/2023 11:20, Jerry Ray wrote:
> 
> Hi Jerry,
> 
> This seems like a patch for net-next which seems to be closed now.
> Please hold back this patch until the window opens again in like 2 weeks.
> 
> Also you need to add in the subject which tree are you targeting.
> In your case is net-next then it should be something like:
> [PATCH net-next] net: dsa: microchip: phy reg access 0x10-0x1f
> 
> > With the recent patch to promote phy register accesses to 32-bits for the
> > range >=0x10, it is also necessary to expand the allowed register address
> > table for the affected devices.  These three register sets use
> > ksz9477_dev_ops and are therefore affected by the change. The address
> > ranges 0xN120-0xN13f map to the phy register address 0x10-0x1f. There is
> > no reason to exclude any register accesses within this space.
> > 
> > on June 20, 2023
> > commit 5c844d57aa78    ("net: dsa: microchip: fix writes to phy registers >= 0x10")
> 
> This is just a small thing but as you need to send a new version, you can
> write something like this:
> ---
> With the recent patch [0] to promote ...
> 
> [0] 5c844d57aa78 ("net: dsa: microchip: fix writes to phy registers >= 0x10")
> ---
> 
> Or:
> 
> ---
> With the commit 5c844d57aa78 ("net: dsa: microchip: fix writes to phy
> registers >= 0x10") which promotes phy ...
> ---
> 
> Just to make it a little bit more clear that the commit that you posted
> at the end refers to the patch that you mention to at the beginning of
> the commit message.

I think these signs intend to denote a Fixes: tag. For that, we have a
fairly standard way of generating them:

$ cat ~/.gitconfig
...
[core]
        abbrev = 12
[pretty]
        fixes = Fixes: %h (\"%s\")

$ git show 5c844d57aa78 --pretty=fixes
Fixes: 5c844d57aa78 ("net: dsa: microchip: fix writes to phy registers >= 0x10")

That line should be pasted in the commit message next to (no empty lines
in between) the other tags like reviews and sign offs.

If Jerry can prove a problem with the existing code structure from
net-next (any PHY writes to registers >= 0x10), then the patch does not
need to wait until net-next reopens. It needs to wait until the net-next
pull request is sent to Linus, then this can be resent towards 'net.git'.
That problem needs to be described in the commit message.

If there's no problem that could potentially have a user-visible impact
in the existing code and PHY driver (those PHY writes are unreachable),
then I agree with you, the change can wait and should be resent when
net-next reopens.