Re: [PATCH] phy: nxp-c45: add driver for tja1103

From: Christian Herber
Date: Tue Apr 13 2021 - 09:44:11 EST




On 4/13/2021 3:30 PM, Andrew Lunn wrote:
On Tue, Apr 13, 2021 at 08:56:30AM +0200, Christian Herber wrote:
Hi Andrew,

On 4/12/2021 6:52 PM, Andrew Lunn wrote:

So what you are say is, you don't care if the IP is completely
different, it all goes in one driver. So lets put this driver into
nxp-tja11xx.c. And then we avoid all the naming issues.

Andrew


As this seems to be a key question, let me try and shed some more light on
this.
The original series of BASE-T1 PHYs includes TJA110, TJA1101, and TJA1102.
They are covered by the existing driver, which has the unfortunate naming
TJA11xx. Unfortunate, because the use of wildcards is a bit to generous.

Yes, that does happen.

Naming is difficult. But i really think nxp-c45.c is much worse. It
gives no idea at all what it supports. Or in the future, what it does
not support, and you actually need nxp-c45-ng.c.

Developers are going to look at a board, see a tja1XYZ chip, see the
nxp-tja11xx.c and enable it. Does the chip have a big C45 symbol on
it? Anything to give the idea it should use the nxp-c45 driver?

Maybe we should actually swing the complete opposite direction. Name
it npx-tja1103.c. There are lots of drivers which have a specific
name, but actually support a lot more devices. The developer sees they
have an tja1XYZ, there are two drivers which look about right, and
enable them both?

Andrew


Ok, we can agree that there will not be a perfect naming. Would it be a possibility to rename the existing TJA11xx driver to TJA1100-1-2 or is that unwanted?

I agree that it should be easy to find the right driver. Right now, there is another device called the SJA1110, which has a very similar IP integrated. It would be possible to use the driver for that device also, even if this is outside of the scope of this submission. Going for wildcards, we get to xJA11xx, which is really undesirable to me.

In the end my hope was that people will look up the correct driver through LKDDb or similar and will find the matching devices from there.

I am open to any suggestion that leads to users finding the right driver and that also work for future devices.

Using your example of an NG device: My assumption is that the things that change are covered by IEEE standardized registers, and thus should be implemented as part of generic helper functions. The things that are outside of the IEEE scope, e.g xMII interface configuration are generic and can be contained in a single driver if the registers are kept software compatible which we intend to do.

If nxp-c45.c is to generic (I take from your comments that' your conclusion), we could at least lean towards nxp-c45-bt1.c? Unfortunately, the product naming schemes are not sufficiently methodical to have a a good driver name based on product names.

Christian