netdev - Re: [PATCH net v3] net: phy: rename Asix Electronics PHY driver

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]

Message-ID: <8ace326e-b9fe-92d0-6617-5347c4389fcc@gmail.com>
Date:   Sat, 8 Jun 2019 13:54:05 +1200
From:   Michael Schmitz <schmitzmic@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH net v3] net: phy: rename Asix Electronics PHY driver

Am 08.06.2019 um 01:00 schrieb Andrew Lunn:
> On Fri, Jun 07, 2019 at 05:37:34PM +1200, Michael Schmitz wrote:
>> [Resent to net instead of net-next - may clash with Anders Roxell's patch
>> series addressing duplicate module names]
>>
>> Commit 31dd83b96641 ("net-next: phy: new Asix Electronics PHY driver")
>> introduced a new PHY driver drivers/net/phy/asix.c that causes a module
>> name conflict with a pre-existiting driver (drivers/net/usb/asix.c).
>>
>> The PHY driver is used by the X-Surf 100 ethernet card driver, and loaded
>> by that driver via its PHY ID. A rename of the driver looks unproblematic.
>>
>> Rename PHY driver to ax88796b.c in order to resolve name conflict.
>>
>> Signed-off-by: Michael Schmitz <schmitzmic@...il.com>
>> Tested-by: Michael Schmitz <schmitzmic@...il.com>
>> Fixes: 31dd83b96641 ("net-next: phy: new Asix Electronics PHY driver")
>
> Reviewed-by: Andrew Lunn <andrew@...n.ch>

Thanks for your review, Andrew.

Which reminds me - I had submitted two patches as cleanup for the 
xsurf100.c driver that would allow us to drop including lib8390.c there. 
The patches were reviewed by Geert but never picked up by Dave.

The card-specific block_output function provided by the xsurf100.c 
driver needs to execute reset_8380() when transfers get stuffed up. 
According to the comment at the head of lib8390.c, a reset must always 
be followed by a call to __NS8390_init(), so this function is also 
needed by our block_output. The current xsurf100.c includes lib8390.c 
just for the benefit of that single function.

My solution was to export ax_8390_init() through a public wrapper, but 
that didn't find favour, apparently. The only other solution I can see 
would be to add an init_8380 function pointer to the ei_device struct, 
but as init_8390 isn't really board specific, that would be abusing 
ei_device a little, no?

Any feedback welcome.

Cheers,

	Michael

>
>     Andrew
>