Hi Russel,

Gesendet: Freitag, 4. Oktober 2024 um 16:35
Von: "Russell King (Oracle)" [off-list ref]
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/

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy