Message-ID: <trinity-80459cab-e571-4699-b3f0-d73a00fe0858-1736076576826@trinity-msg-rest-gmx-gmx-live-548599f845-nqxpf>
Date: Sun, 5 Jan 2025 11:29:40 +0000
From: Frank Wunderlich <frank-w@...lic-files.de>
To: linux@...linux.org.uk
Cc: angelogioacchino.delregno@...labora.com, matthias.bgg@...il.com,
 davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
 conor+dt@...nel.org, chunfeng.yun@...iatek.com, vkoul@...nel.org,
 kishon@...nel.org, nbd@....name, john@...ozen.org, sean.wang@...iatek.com,
 Mark-MC.Lee@...iatek.com, lorenzo@...nel.org, andrew@...n.ch,
 hkallweit1@...il.com, lynxis@...0.eu, dqfext@...il.com,
 SkyLake.Huang@...iatek.com, p.zabel@...gutronix.de, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 linux-phy@...ts.infradead.org, daniel@...rotopia.org
Subject: Aw: Re: Aw: Re: [RFC PATCH net-next v3 3/8] net: pcs:
 pcs-mtk-lynxi: add platform driver for MT7988

Hi Russel,

> Gesendet: Freitag, 4. Oktober 2024 um 16:35
> Von: "Russell King (Oracle)" <linux@...linux.org.uk>
> Betreff: Re: Aw: Re: [RFC PATCH net-next v3 3/8] net: pcs: pcs-mtk-lynxi: add platform driver for MT7988
>
> Hi Frank,
>
> Sorry, but I've not been able to look at this, and I've completely lost
> all context now. I was diverted onto a high priority work issue for a
> while (was it from April to end of June) so didn't have much time
> available for mainline work. I then had a much needed holiday (three
> weeks) in July. I then had a clear week where I did look at mainline.
> Since then, I've had two cataract operations that have made being on the
> computer somewhat difficult, and it is only recently that I'm
> effectively "back" after what is approximately six months of not having
> a lot of bandwidth. I've seen the cataract consultant this morning, and
> just found out that my optometrist appointment for Tuesday is too soon
> after the cataract operation, and needs to be moved two weeks. The
> optometrist doesn't have availability then, so it's going to be another
> four weeks. FFS... I wish I'd known, then I could've made an
> arrangement with the optometrist months ago for the correct date.

How are you? I hope you're feeling better now....
I see you were more active on the Mailinglist in last time :)

> Now, XPCS has introduced a hack in a similar way to what you're trying
> to do, but I wasn't able to review it, so it went in. We're heading
> towards the situation where every PCS driver is going to have its own
> way to look up a PCS registered as a device. This is not going to scale.
>
> We need something better than this - and at the moment that's all I can
> say because I haven't given it any more thought beyond that so far.

Have you found some time (and were you able) to look a bit into this ([1])?

How would be the right way here? Daniel posted generic infrastructure for standalone
pcs drivers [2] similar to phy to have a generic base which all drivers can use and
which can be extended if needed.

There was some discussion about how pcs should handle if the underlaying device is removed...
unlikely on SoC, but possible on external bus devices like mdio or pcie. Imho this could be
a callback in common code handled by vendor driver (query information from mac driver or for
SoC simply return fixed value).

How should the subsystems talk with each other (callbacks, shared memory, ...)?

DT maintainers want to avoid syscon compatibles which are widely used for nodes representing only
a register range that is used from different subsystems. As we are currently upstreaming mt7988
(e.g. ethernet), there are some of these "devices" which currently have no own driver and only
handled by syscon driver to get the regmap. Should we really write different drivers with additional
compatibles (duplicate code!) only to handle exchange of the regmap between subsystems? For mt7988
which can have up to 7 syscon devices it is maybe better to have substructures like phy, pcs and so on
packed into an own driver to have a better overview in devicetree. But for some functional blocks
imho it makes not much sense (when really only a regmap has to be exchanged between different devices).

Daniel needs an answer to his questions in [1] (and [2]) on how to proceed. So please help to get the
pcs-part into the right shape.

regards Frank

[1] https://patchwork.kernel.org/project/netdevbpf/patch/8aa905080bdb6760875d62cb3b2b41258837f80e.1702352117.git.daniel@makrotopia.org/
[2] https://patchwork.kernel.org/project/netdevbpf/patch/ba4e359584a6b3bc4b3470822c42186d5b0856f9.1721910728.git.daniel@makrotopia.org/

Powered by blists - more mailing lists