[PATCH net-next v2 00/14] net: dsa: add support for MT7988

[PATCH net-next v2 00/14] net: dsa: add support for MT7988

[Daniel Golle]

The MediaTek MT7988 SoC comes with a built-in switch very similar to
previous MT7530 and MT7531. However, the switch address space is mapped
into the SoCs memory space rather than being connected via MDIO.
Using MMIO simplifies register access and also removes the need for a bus
lock, and for that reason also makes interrupt handling more light-weight.

Note that this is different from previous SoCs like MT7621 and MT7623N
which also came with an integrated MT7530-like switch which yet had to be
accessed via MDIO.

Split-off the part of the driver registering an MDIO driver, then add
another module acting as MMIO/platform driver.

The whole series has been tested on various MediaTek boards:
 * MT7623A + MT7530 (BPi-R2)
 * MT7986A + MT7531 (BPi-R3)
 * MT7988A reference board

Changes since v1:
 * use 'internal' PHY mode where appropriate
 * use regmap_update_bits in mt7530_rmw
 * improve dt-bindings

Changes since RFC v3:
 * WARN_ON_ONCE if register read fails
 * move probing of the reset GPIO and reset controller link out of
   common  probe function, as they are not actually common

Changes since RFC v2:
 * split into many small commits to ease review
 * introduce helper functions to reduce code duplication
 * use helpers for locking to make lock-skipping easier and less ugly
   to implement.
 * add dt-bindings for mediatek,mt7988-switch

Changes since initial RFC:
 * use regmap for register access and move register access to bus-
   specific driver
 * move initialization of MT7531 SGMII PCS to MDIO driver

Daniel Golle (14):
  net: dsa: mt7530: make some noise if register read fails
  net: dsa: mt7530: refactor SGMII PCS creation
  net: dsa: mt7530: use unlocked regmap accessors
  net: dsa: mt7530: use regmap to access switch register space
  net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function
  net: dsa: mt7530: introduce mutex helpers
  net: dsa: mt7530: move p5_intf_modes() function to mt7530.c
  net: dsa: mt7530: introduce mt7530_probe_common helper function
  net: dsa: mt7530: introduce mt7530_remove_common helper function
  net: dsa: mt7530: split-off common parts from mt7531_setup
  net: dsa: mt7530: introduce separate MDIO driver
  net: dsa: mt7530: skip locking if MDIO bus isn't present
  net: dsa: mt7530: introduce driver for MT7988 built-in switch
  dt-bindings: net: dsa: mediatek,mt7530: add mediatek,mt7988-switch

 .../bindings/net/dsa/mediatek,mt7530.yaml     |  26 +-
 MAINTAINERS                                   |   3 +
 drivers/net/dsa/Kconfig                       |  27 +-
 drivers/net/dsa/Makefile                      |   2 +
 drivers/net/dsa/mt7530-mdio.c                 | 271 +++++++++
 drivers/net/dsa/mt7530-mmio.c                 | 101 ++++
 drivers/net/dsa/mt7530.c                      | 565 +++++++++---------
 drivers/net/dsa/mt7530.h                      |  38 +-
 8 files changed, 713 insertions(+), 320 deletions(-)
 create mode 100644 drivers/net/dsa/mt7530-mdio.c
 create mode 100644 drivers/net/dsa/mt7530-mmio.c


base-commit: 51aaa68222d6c34f0373cf95223ce2f230329e8f
-- 
2.40.0

[PATCH net-next v2 14/14] dt-bindings: net: dsa: mediatek,mt7530: add mediatek,mt7988-switch

[Daniel Golle]

Add documentation for the built-in switch which can be found in the
MediaTek MT7988 SoC.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
 .../bindings/net/dsa/mediatek,mt7530.yaml     | 26 +++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index 5ae9cd8f99a24..8d6dfed11d8d6 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -11,16 +11,23 @@ maintainers:
   - Landen Chao <Landen.Chao@mediatek.com>
   - DENG Qingfang <dqfext@gmail.com>
   - Sean Wang <sean.wang@mediatek.com>
+  - Daniel Golle <daniel@makrotopia.org>
 
 description: |
-  There are two versions of MT7530, standalone and in a multi-chip module.
+  There are three versions of MT7530, standalone, in a multi-chip module and
+  built-into a SoC.
 
   MT7530 is a part of the multi-chip module in MT7620AN, MT7620DA, MT7620DAN,
   MT7620NN, MT7621AT, MT7621DAT, MT7621ST and MT7623AI SoCs.
 
+  The MT7988 SoC comes with a built-in switch similar to MT7531 as well as four
+  Gigabit Ethernet PHYs. The switch registers are directly mapped into the SoC's
+  memory map rather than using MDIO. The switch got an internally connected 10G
+  CPU port and 4 user ports connected to the built-in Gigabit Ethernet PHYs.
+
   MT7530 in MT7620AN, MT7620DA, MT7620DAN and MT7620NN SoCs has got 10/100 PHYs
   and the switch registers are directly mapped into SoC's memory map rather than
-  using MDIO. The DSA driver currently doesn't support this.
+  using MDIO. The DSA driver currently doesn't support MT7620 variants.
 
   There is only the standalone version of MT7531.
 
@@ -81,6 +88,10 @@ properties:
           Multi-chip module MT7530 in MT7621AT, MT7621DAT and MT7621ST SoCs
         const: mediatek,mt7621
 
+      - description:
+          Built-in switch of the MT7988 SoC
+        const: mediatek,mt7988-switch
+
   reg:
     maxItems: 1
 
@@ -268,6 +279,17 @@ allOf:
       required:
         - mediatek,mcm
 
+  - if:
+      properties:
+        compatible:
+          const: mediatek,mt7988-switch
+    then:
+      $ref: "#/$defs/mt7530-dsa-port"
+      properties:
+        gpio-controller: false
+        mediatek,mcm: false
+        reset-names: false
+
 unevaluatedProperties: false
 
 examples:
-- 
2.40.0

Re: [PATCH net-next v2 00/14] net: dsa: add support for MT7988

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by David S. Miller <davem@davemloft.net>:

On Mon, 3 Apr 2023 02:16:40 +0100 you wrote:
> The MediaTek MT7988 SoC comes with a built-in switch very similar to
> previous MT7530 and MT7531. However, the switch address space is mapped
> into the SoCs memory space rather than being connected via MDIO.
> Using MMIO simplifies register access and also removes the need for a bus
> lock, and for that reason also makes interrupt handling more light-weight.
> 
> Note that this is different from previous SoCs like MT7621 and MT7623N
> which also came with an integrated MT7530-like switch which yet had to be
> accessed via MDIO.
> 
> [...]

Here is the summary with links:
  - [net-next,v2,01/14] net: dsa: mt7530: make some noise if register read fails
    https://git.kernel.org/netdev/net-next/c/b6f56cddb5f5
  - [net-next,v2,02/14] net: dsa: mt7530: refactor SGMII PCS creation
    https://git.kernel.org/netdev/net-next/c/9ecc00164dc2
  - [net-next,v2,03/14] net: dsa: mt7530: use unlocked regmap accessors
    https://git.kernel.org/netdev/net-next/c/1bd099c49f65
  - [net-next,v2,04/14] net: dsa: mt7530: use regmap to access switch register space
    https://git.kernel.org/netdev/net-next/c/a08c045580e0
  - [net-next,v2,05/14] net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function
    https://git.kernel.org/netdev/net-next/c/6de285229773
  - [net-next,v2,06/14] net: dsa: mt7530: introduce mutex helpers
    https://git.kernel.org/netdev/net-next/c/1557c679f71c
  - [net-next,v2,07/14] net: dsa: mt7530: move p5_intf_modes() function to mt7530.c
    https://git.kernel.org/netdev/net-next/c/25d15dee34a1
  - [net-next,v2,08/14] net: dsa: mt7530: introduce mt7530_probe_common helper function
    https://git.kernel.org/netdev/net-next/c/37c9c0d8d0b2
  - [net-next,v2,09/14] net: dsa: mt7530: introduce mt7530_remove_common helper function
    https://git.kernel.org/netdev/net-next/c/720d73635176
  - [net-next,v2,10/14] net: dsa: mt7530: split-off common parts from mt7531_setup
    https://git.kernel.org/netdev/net-next/c/7f54cc9772ce
  - [net-next,v2,11/14] net: dsa: mt7530: introduce separate MDIO driver
    https://git.kernel.org/netdev/net-next/c/cb675afcddbb
  - [net-next,v2,12/14] net: dsa: mt7530: skip locking if MDIO bus isn't present
    https://git.kernel.org/netdev/net-next/c/54d4147a121c
  - [net-next,v2,13/14] net: dsa: mt7530: introduce driver for MT7988 built-in switch
    https://git.kernel.org/netdev/net-next/c/110c18bfed41
  - [net-next,v2,14/14] dt-bindings: net: dsa: mediatek,mt7530: add mediatek,mt7988-switch
    https://git.kernel.org/netdev/net-next/c/386f5fc9061b

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net-next v2 00/14] net: dsa: add support for MT7988

[Arınç ÜNAL]

On 3.04.2023 04:16, Daniel Golle wrote:
> The MediaTek MT7988 SoC comes with a built-in switch very similar to
> previous MT7530 and MT7531. However, the switch address space is mapped
> into the SoCs memory space rather than being connected via MDIO.
> Using MMIO simplifies register access and also removes the need for a bus
> lock, and for that reason also makes interrupt handling more light-weight.
> 
> Note that this is different from previous SoCs like MT7621 and MT7623N
> which also came with an integrated MT7530-like switch which yet had to be
> accessed via MDIO.
> 
> Split-off the part of the driver registering an MDIO driver, then add
> another module acting as MMIO/platform driver.
> 
> The whole series has been tested on various MediaTek boards:
>   * MT7623A + MT7530 (BPi-R2)
>   * MT7986A + MT7531 (BPi-R3)
>   * MT7988A reference board

You did not address the incorrect information I pointed out here. Now 
that the patch series is applied, people reading this on the merge 
branch commit will be misled by the misinformation.

> 
> Changes since v1:
>   * use 'internal' PHY mode where appropriate
>   * use regmap_update_bits in mt7530_rmw
>   * improve dt-bindings

As a maintainer of the said dt-bindings, I pointed out almost 7 things 
for you to change. Of those 7 points, you only did one, a trivial 
grammar change. The patch series is applied now so one of us maintainers 
(you are one too now) need to fix it with additional patches.

Arınç

Re: [PATCH net-next v2 00/14] net: dsa: add support for MT7988

[Daniel Golle]

Hi Arınç,

On Mon, Apr 03, 2023 at 08:08:19PM +0300, Arınç ÜNAL wrote:
> On 3.04.2023 04:16, Daniel Golle wrote:
> > The MediaTek MT7988 SoC comes with a built-in switch very similar to
> > previous MT7530 and MT7531. However, the switch address space is mapped
> > into the SoCs memory space rather than being connected via MDIO.
> > Using MMIO simplifies register access and also removes the need for a bus
> > lock, and for that reason also makes interrupt handling more light-weight.
> > 
> > Note that this is different from previous SoCs like MT7621 and MT7623N
> > which also came with an integrated MT7530-like switch which yet had to be
> > accessed via MDIO.
> > 
> > Split-off the part of the driver registering an MDIO driver, then add
> > another module acting as MMIO/platform driver.
> > 
> > The whole series has been tested on various MediaTek boards:
> >   * MT7623A + MT7530 (BPi-R2)
> >   * MT7986A + MT7531 (BPi-R3)
> >   * MT7988A reference board
> 
> You did not address the incorrect information I pointed out here. Now that

I'm sorry, that was certainly not intentional and I may have missed
your comments. Actually it doesn't look like they have made it to the
netdev list archive or patchwork either.

> the patch series is applied, people reading this on the merge branch commit
> will be misled by the misinformation.

I've changed Kconfig stuff according to your recommendation and also
addressed possible misleading USXGMII and 10GBase-KR support by
introducing MT7988-specific functions and using 'internal' PHY mode.
So which of your comments have not been addressed?

> 
> > 
> > Changes since v1:
> >   * use 'internal' PHY mode where appropriate
> >   * use regmap_update_bits in mt7530_rmw
> >   * improve dt-bindings
> 
> As a maintainer of the said dt-bindings, I pointed out almost 7 things for
> you to change. Of those 7 points, you only did one, a trivial grammar
> change. The patch series is applied now so one of us maintainers (you are
> one too now) need to fix it with additional patches.

I was also surprised the series made it to net-next so quickly, but it
wasn't me applying it, I merly posted v2 with all comments I received
addressed.

Me and supposedly also netdevbpf maintainers use patchwork to track
patches and whether comments have been addressed. Can you point me to
emails with the comments which haven't been addressed there? Looking in
patchwork for the dt-bindings patch [1] I don't see any comments there.


Thank you for reviewing!


Daniel


[1]: See patchwork tracking for RFCv3, v1 and v2. Prior to RFCv3 the series
didn't have the dt-bindings addition, I introduced it with RFCv3 when splitting
the series into many small changes:
https://patchwork.kernel.org/project/netdevbpf/patch/9b504e3e88807bfb62022c0877451933d30abeb5.1680105013.git.daniel@makrotopia.org/
https://patchwork.kernel.org/project/netdevbpf/patch/fef2cb2fe3d2b70fa46e93107a0c862f53bb3bfa.1680180959.git.daniel@makrotopia.org/
https://patchwork.kernel.org/project/netdevbpf/patch/dffacdb59aea462c9f7d4242cf9563a04cf79807.1680483896.git.daniel@makrotopia.org/

Re: [PATCH net-next v2 00/14] net: dsa: add support for MT7988

[Arınç ÜNAL]

On 3.04.2023 20:42, Daniel Golle wrote:
> Hi Arınç,
> 
> On Mon, Apr 03, 2023 at 08:08:19PM +0300, Arınç ÜNAL wrote:
>> On 3.04.2023 04:16, Daniel Golle wrote:
>>> The MediaTek MT7988 SoC comes with a built-in switch very similar to
>>> previous MT7530 and MT7531. However, the switch address space is mapped
>>> into the SoCs memory space rather than being connected via MDIO.
>>> Using MMIO simplifies register access and also removes the need for a bus
>>> lock, and for that reason also makes interrupt handling more light-weight.
>>>
>>> Note that this is different from previous SoCs like MT7621 and MT7623N
>>> which also came with an integrated MT7530-like switch which yet had to be
>>> accessed via MDIO.
>>>
>>> Split-off the part of the driver registering an MDIO driver, then add
>>> another module acting as MMIO/platform driver.
>>>
>>> The whole series has been tested on various MediaTek boards:
>>>    * MT7623A + MT7530 (BPi-R2)
>>>    * MT7986A + MT7531 (BPi-R3)
>>>    * MT7988A reference board
>>
>> You did not address the incorrect information I pointed out here. Now that
> 
> I'm sorry, that was certainly not intentional and I may have missed
> your comments. Actually it doesn't look like they have made it to the
> netdev list archive or patchwork either.
> 
>> the patch series is applied, people reading this on the merge branch commit
>> will be misled by the misinformation.
> 
> I've changed Kconfig stuff according to your recommendation and also
> addressed possible misleading USXGMII and 10GBase-KR support by
> introducing MT7988-specific functions and using 'internal' PHY mode.
> So which of your comments have not been addressed?

https://lore.kernel.org/netdev/c11c86e4-5f8e-5b9b-1db5-e3861b2bade6@arinc9.com/

> 
>>
>>>
>>> Changes since v1:
>>>    * use 'internal' PHY mode where appropriate
>>>    * use regmap_update_bits in mt7530_rmw
>>>    * improve dt-bindings
>>
>> As a maintainer of the said dt-bindings, I pointed out almost 7 things for
>> you to change. Of those 7 points, you only did one, a trivial grammar
>> change. The patch series is applied now so one of us maintainers (you are
>> one too now) need to fix it with additional patches.
> 
> I was also surprised the series made it to net-next so quickly, but it
> wasn't me applying it, I merly posted v2 with all comments I received
> addressed.
> 
> Me and supposedly also netdevbpf maintainers use patchwork to track
> patches and whether comments have been addressed. Can you point me to
> emails with the comments which haven't been addressed there? Looking in
> patchwork for the dt-bindings patch [1] I don't see any comments there.

https://lore.kernel.org/netdev/a7ab2828-dc03-4847-c947-c7685841f884@arinc9.com/

> 
> 
> Thank you for reviewing!
> 
> 
> Daniel
> 
> 
> [1]: See patchwork tracking for RFCv3, v1 and v2. Prior to RFCv3 the series
> didn't have the dt-bindings addition, I introduced it with RFCv3 when splitting
> the series into many small changes:
> https://patchwork.kernel.org/project/netdevbpf/patch/9b504e3e88807bfb62022c0877451933d30abeb5.1680105013.git.daniel@makrotopia.org/
> https://patchwork.kernel.org/project/netdevbpf/patch/fef2cb2fe3d2b70fa46e93107a0c862f53bb3bfa.1680180959.git.daniel@makrotopia.org/
> https://patchwork.kernel.org/project/netdevbpf/patch/dffacdb59aea462c9f7d4242cf9563a04cf79807.1680483896.git.daniel@makrotopia.org/

Although I've been a maintainer for the dt-bindings schema for quite 
some time, I was somehow missed as a recipient on RFC v3.

Arınç

Re: [PATCH net-next v2 00/14] net: dsa: add support for MT7988

[Daniel Golle]

On Mon, Apr 03, 2023 at 08:50:11PM +0300, Arınç ÜNAL wrote:
> On 3.04.2023 20:42, Daniel Golle wrote:
> > Hi Arınç,
> > 
> > On Mon, Apr 03, 2023 at 08:08:19PM +0300, Arınç ÜNAL wrote:
> > > On 3.04.2023 04:16, Daniel Golle wrote:
> > > > The MediaTek MT7988 SoC comes with a built-in switch very similar to
> > > > previous MT7530 and MT7531. However, the switch address space is mapped
> > > > into the SoCs memory space rather than being connected via MDIO.
> > > > Using MMIO simplifies register access and also removes the need for a bus
> > > > lock, and for that reason also makes interrupt handling more light-weight.
> > > > 
> > > > Note that this is different from previous SoCs like MT7621 and MT7623N
> > > > which also came with an integrated MT7530-like switch which yet had to be
> > > > accessed via MDIO.
> > > > 
> > > > Split-off the part of the driver registering an MDIO driver, then add
> > > > another module acting as MMIO/platform driver.
> > > > 
> > > > The whole series has been tested on various MediaTek boards:
> > > >    * MT7623A + MT7530 (BPi-R2)
> > > >    * MT7986A + MT7531 (BPi-R3)
> > > >    * MT7988A reference board
> > > 
> > > You did not address the incorrect information I pointed out here. Now that
> > 
> > I'm sorry, that was certainly not intentional and I may have missed
> > your comments. Actually it doesn't look like they have made it to the
> > netdev list archive or patchwork either.
> > 
> > > the patch series is applied, people reading this on the merge branch commit
> > > will be misled by the misinformation.
> > 
> > I've changed Kconfig stuff according to your recommendation and also
> > addressed possible misleading USXGMII and 10GBase-KR support by
> > introducing MT7988-specific functions and using 'internal' PHY mode.
> > So which of your comments have not been addressed?
> 
> https://lore.kernel.org/netdev/c11c86e4-5f8e-5b9b-1db5-e3861b2bade6@arinc9.com/

Strange that both emails didn't make it into patchwork.

> 
> > 
> > > 
> > > > 
> > > > Changes since v1:
> > > >    * use 'internal' PHY mode where appropriate
> > > >    * use regmap_update_bits in mt7530_rmw
> > > >    * improve dt-bindings
> > > 
> > > As a maintainer of the said dt-bindings, I pointed out almost 7 things for
> > > you to change. Of those 7 points, you only did one, a trivial grammar
> > > change. The patch series is applied now so one of us maintainers (you are
> > > one too now) need to fix it with additional patches.
> > 
> > I was also surprised the series made it to net-next so quickly, but it
> > wasn't me applying it, I merly posted v2 with all comments I received
> > addressed.
> > 
> > Me and supposedly also netdevbpf maintainers use patchwork to track
> > patches and whether comments have been addressed. Can you point me to
> > emails with the comments which haven't been addressed there? Looking in
> > patchwork for the dt-bindings patch [1] I don't see any comments there.
> 
> https://lore.kernel.org/netdev/a7ab2828-dc03-4847-c947-c7685841f884@arinc9.com/
> 
> > 
> > 
> > Thank you for reviewing!
> > 
> > 
> > Daniel
> > 
> > 
> > [1]: See patchwork tracking for RFCv3, v1 and v2. Prior to RFCv3 the series
> > didn't have the dt-bindings addition, I introduced it with RFCv3 when splitting
> > the series into many small changes:
> > https://patchwork.kernel.org/project/netdevbpf/patch/9b504e3e88807bfb62022c0877451933d30abeb5.1680105013.git.daniel@makrotopia.org/
> > https://patchwork.kernel.org/project/netdevbpf/patch/fef2cb2fe3d2b70fa46e93107a0c862f53bb3bfa.1680180959.git.daniel@makrotopia.org/
> > https://patchwork.kernel.org/project/netdevbpf/patch/dffacdb59aea462c9f7d4242cf9563a04cf79807.1680483896.git.daniel@makrotopia.org/
> 
> Although I've been a maintainer for the dt-bindings schema for quite some
> time, I was somehow missed as a recipient on RFC v3.

Yeah, that was my mistake. get_maintainers.pl comes up with unreadable
unicode garbage, probably something is wrong in my local Perl setup.
So I always manually replace your name with readable UTF-8, but I missed
that for RFC v3.

Re: [PATCH net-next v2 00/14] net: dsa: add support for MT7988

[Arınç ÜNAL]

On 3.04.2023 21:13, Daniel Golle wrote:
> On Mon, Apr 03, 2023 at 08:50:11PM +0300, Arınç ÜNAL wrote:
>> On 3.04.2023 20:42, Daniel Golle wrote:
>>> Hi Arınç,
>>>
>>> On Mon, Apr 03, 2023 at 08:08:19PM +0300, Arınç ÜNAL wrote:
>>>> On 3.04.2023 04:16, Daniel Golle wrote:
>>>>> The MediaTek MT7988 SoC comes with a built-in switch very similar to
>>>>> previous MT7530 and MT7531. However, the switch address space is mapped
>>>>> into the SoCs memory space rather than being connected via MDIO.
>>>>> Using MMIO simplifies register access and also removes the need for a bus
>>>>> lock, and for that reason also makes interrupt handling more light-weight.
>>>>>
>>>>> Note that this is different from previous SoCs like MT7621 and MT7623N
>>>>> which also came with an integrated MT7530-like switch which yet had to be
>>>>> accessed via MDIO.
>>>>>
>>>>> Split-off the part of the driver registering an MDIO driver, then add
>>>>> another module acting as MMIO/platform driver.
>>>>>
>>>>> The whole series has been tested on various MediaTek boards:
>>>>>     * MT7623A + MT7530 (BPi-R2)
>>>>>     * MT7986A + MT7531 (BPi-R3)
>>>>>     * MT7988A reference board
>>>>
>>>> You did not address the incorrect information I pointed out here. Now that
>>>
>>> I'm sorry, that was certainly not intentional and I may have missed
>>> your comments. Actually it doesn't look like they have made it to the
>>> netdev list archive or patchwork either.
>>>
>>>> the patch series is applied, people reading this on the merge branch commit
>>>> will be misled by the misinformation.
>>>
>>> I've changed Kconfig stuff according to your recommendation and also
>>> addressed possible misleading USXGMII and 10GBase-KR support by
>>> introducing MT7988-specific functions and using 'internal' PHY mode.
>>> So which of your comments have not been addressed?
>>
>> https://lore.kernel.org/netdev/c11c86e4-5f8e-5b9b-1db5-e3861b2bade6@arinc9.com/
> 
> Strange that both emails didn't make it into patchwork.

I don't understand how how patchwork handles the conversation on the 
cover letter. I was never able to see them on patchwork but lore.kernel.org.

My review for patch 15 was received on patchworks as it should. It was 
missing "net-next" on the subject so perhaps that's why you missed it.

https://patchwork.kernel.org/project/netdevbpf/patch/80a853f182eac24735338f3c1f505e5f580053ca.1680180959.git.daniel@makrotopia.org/#25278482

Why don't you just check your inbox? We're emailing each other in the end.

> 
>>
>>>
>>>>
>>>>>
>>>>> Changes since v1:
>>>>>     * use 'internal' PHY mode where appropriate
>>>>>     * use regmap_update_bits in mt7530_rmw
>>>>>     * improve dt-bindings
>>>>
>>>> As a maintainer of the said dt-bindings, I pointed out almost 7 things for
>>>> you to change. Of those 7 points, you only did one, a trivial grammar
>>>> change. The patch series is applied now so one of us maintainers (you are
>>>> one too now) need to fix it with additional patches.
>>>
>>> I was also surprised the series made it to net-next so quickly, but it
>>> wasn't me applying it, I merly posted v2 with all comments I received
>>> addressed.
>>>
>>> Me and supposedly also netdevbpf maintainers use patchwork to track
>>> patches and whether comments have been addressed. Can you point me to
>>> emails with the comments which haven't been addressed there? Looking in
>>> patchwork for the dt-bindings patch [1] I don't see any comments there.
>>
>> https://lore.kernel.org/netdev/a7ab2828-dc03-4847-c947-c7685841f884@arinc9.com/
>>
>>>
>>>
>>> Thank you for reviewing!
>>>
>>>
>>> Daniel
>>>
>>>
>>> [1]: See patchwork tracking for RFCv3, v1 and v2. Prior to RFCv3 the series
>>> didn't have the dt-bindings addition, I introduced it with RFCv3 when splitting
>>> the series into many small changes:
>>> https://patchwork.kernel.org/project/netdevbpf/patch/9b504e3e88807bfb62022c0877451933d30abeb5.1680105013.git.daniel@makrotopia.org/
>>> https://patchwork.kernel.org/project/netdevbpf/patch/fef2cb2fe3d2b70fa46e93107a0c862f53bb3bfa.1680180959.git.daniel@makrotopia.org/
>>> https://patchwork.kernel.org/project/netdevbpf/patch/dffacdb59aea462c9f7d4242cf9563a04cf79807.1680483896.git.daniel@makrotopia.org/
>>
>> Although I've been a maintainer for the dt-bindings schema for quite some
>> time, I was somehow missed as a recipient on RFC v3.
> 
> Yeah, that was my mistake. get_maintainers.pl comes up with unreadable
> unicode garbage, probably something is wrong in my local Perl setup.
> So I always manually replace your name with readable UTF-8, but I missed
> that for RFC v3.

Did you try writing the output of get_maintainers.pl to a file, then 
feed the file directly to git send-email as recipients?

That may bypass that issue. It's also currently how I send my patches.

https://arinc9.notion.site/get_maintainers-and-git-send-email-e8edd99d962041eca874966021acefe6

Arınç