Hi Sergei,

I understand that the commit log needs to be corrected.
(Shimoda-san's point is also correct)

If there is anything else that needs to be corrected, please point it out.

   That seems a common pattern, inlluding the Renesas sh_eth
driver...

Yes.
If I can get an R-Car Gen2 board, I will also fix sh_eth driver.

   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.

Thanks & Best Regards,
Yuusuke Ashizuka [off-list ref]

-----Original Message-----
From: Sergei Shtylyov <redacted>
Sent: Friday, July 31, 2020 1:04 AM
To: Ashizuka, Yuusuke/芦塚 雄介 <redacted>
Cc: netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v2] ravb: Fixed the problem that rmmod can not
be done

Hello!

On 7/30/20 1:01 PM, Yuusuke Ashizuka wrote:

quoted

ravb is a module driver, but I cannot rmmod it after insmod it.

   Modular. And "insmod'ing it".

quoted

ravb does mdio_init() at the time of probe, and module->refcnt

is incremented

quoted

by alloc_mdio_bitbang() called after that.

   That seems a common pattern, inlluding the Renesas sh_eth
driver...

quoted

Therefore, even if ifup is not performed, the driver is in use

and rmmod cannot

quoted

be performed.

   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... Unfortunately I don't have the affected hardware
anymore... :-(

[...]

MBR, Sergei