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:   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
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ