lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 13 Apr 2021 15:44:03 +0200
From:   Christian Herber <christian.herber@....nxp.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "Radu-nicolae Pirea (OSS)" <radu-nicolae.pirea@....nxp.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] phy: nxp-c45: add driver for tja1103



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ