Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Thu, 26 Oct 2023 12:40:30 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Oleksij Rempel <o.rempel@pengutronix.de>
Cc:     "David S. Miller" <davem@davemloft.net>,
        Andrew Lunn <andrew@lunn.ch>,
        Eric Dumazet <edumazet@google.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Woojung Huh <woojung.huh@microchip.com>,
        Arun Ramadoss <arun.ramadoss@microchip.com>,
        Conor Dooley <conor+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Rob Herring <robh+dt@kernel.org>, kernel@pengutronix.de,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        UNGLinuxDriver@microchip.com,
        "Russell King (Oracle)" <linux@armlinux.org.uk>,
        devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v8 0/5] net: dsa: microchip: provide Wake on LAN
 support (part 2)
Message-ID: <20231026094030.wyoz3rj2jiim7ptx@skbuf>
References: <20231026051051.2316937-1-o.rempel@pengutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231026051051.2316937-1-o.rempel@pengutronix.de>
Precedence: bulk

On Thu, Oct 26, 2023 at 07:10:46AM +0200, Oleksij Rempel wrote:
> This patch series introduces extensive Wake on LAN (WoL) support for the
> Microchip KSZ9477 family of switches, coupled with some code refactoring
> and error handling enhancements. The principal aim is to enable and
> manage Wake on Magic Packet and other PHY event triggers for waking up
> the system, whilst ensuring that the switch isn't reset during a
> shutdown if WoL is active.
> 
> The Wake on LAN functionality is optional and is particularly beneficial
> if the PME pins are connected to the SoC as a wake source or to a PMIC
> that can enable or wake the SoC.
> 
> changes v8:
> - rebase on top of net-next and s/slave/user/

I am stunned by what happened here. The timeline seems to be:

- On the 23rd of October, you sent a 9-patch series constituting v7.
- On the 25th of October, 4 of those patches were silently merged, as
  follows:

93aa731e6133 Merge branch 'dsa-microchip-WoL-support'
d264f24409b8 net: dsa: microchip: ksz9477: add Wake on LAN support
aed7425d6510 net: dsa: microchip: use wakeup-source DT property to enable PME output
4e1799ae84fc dt-bindings: net: dsa: microchip: add wakeup-source property
02e987f52cf0 net: dsa: microchip: Add missing MAC address register offset for ksz8863

 commit 93aa731e613399f5145166940b20224a8d116920
 Merge: e43e6d9582e0 d264f24409b8
 Author: David S. Miller <davem@davemloft.net>
 Date:   Wed Oct 25 08:47:33 2023 +0100

     Merge branch 'dsa-microchip-WoL-support'

with no further details as usual (cover letter becomes merge commit
message), no patchwork bot notification, nothing.

- Today you are sending the rest of 5 unmerged patches.
- In parallel, Colin Ian King has sent a fixup for a review comment on
  the first 4 patches from v7, which got silently applied without that
  comment being addressed.

So, given the circumstances, I see that you did the right thing. It's
just that I'm starting to understand less and less of what the rules are
supposed to be.