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

[Daniel Golle <daniel@makrotopia.org>]

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.