Hello!
On 7/31/20 1:18 PM, ashid...@fujitsu.com wrote:
> I understand that the commit log needs to be corrected.
The subject also could be more concise...
> (Shimoda-san's point is also correct)
>
> If there is anything else that needs to be corrected, please point it out.
OK, I'll try to post a proper patch review...
>> That seems a common pattern, inlluding the Renesas sh_eth
>> driver...
>
> Yes.
Not at all so common as I thought! Only 4 drivers use mdio-bitbang, 2 of
them are
for the Renesas SoCs...
> If I can get an R-Car Gen2 board, I will also fix sh_eth driver.
Do yuo have R-Car V3H at hand, by chance? It does have a GEther controler
used for
booting up...
>> No, the driver's remove() method calls ravb_mdio_release() and
>> that one calls
>> free_mdio_bitbang() that calls module_put(); the actual reason lies
>> somewehre deeper than this...
>
> No.
> Running rmmod calls delete_module() in kernel/module.c before
> ravb_mdio_release() is called.
> delete_module()
> -> try_stop_module()
> -> try_release_module_ref()
> In try_release_module_ref(), check refcnt and if it is counted up,
> ravb_mdio_release() is not
> called and rmmod is terminated.
Yes, after some rummaging in the module support code, I have to agree here.
I was
just surprised with you finding such a critical bug so late in the drivers'
life cycle.
Well, due to usually using NFS the EtherAVB (and Ether too) driver is probably
alwaysbuilt in-kernel...
> Thanks & Best Regards,
> Yuusuke Ashizuka <ashid...@fujitsu.com>
Trim your messages after your goodbye. That original message stuff typically
isn't
tolerated in the Linux mailing lists, nearly the same as top-posting...
[...]
MBR, Sergei
