netdev - Re: [PATCH v2 net-next] net: ethernet: ti: davinci

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: <ed3554bc-af62-78ce-a3eb-ff5f27ade6a2@ti.com>
Date:   Fri, 12 Aug 2022 10:06:05 +0530
From:   Ravi Gunasekaran <r-gunasekaran@...com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <linux-omap@...r.kernel.org>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <kishon@...com>,
        <vigneshr@...com>
Subject: Re: [PATCH v2 net-next] net: ethernet: ti: davinci_mdio: Add
 workaround for errata i2329

>> There is atleast one device sh_eth, which is not configured for autosuspend
>> but uses the bit bang core in sh_mdiobb_read() and invokes regular runtime
>> PM functions.
> 
> And that is the point of moving it into the core. It would of just
> worked for you.
> 
> If you don't feel comfortable with making this unconditional, please
> put runtime pm enabled version of mdiobb_read/mdiobb_write() in the
> core and swap sh_eth and any other drivers to using them.
> 

sh_eth is not configured for autosuspend and uses only pm_runtime_put().
davinci_mdio is configured for autosuspend and it must invoke 
pm_runtime_mark_last_busy() before calling pm_runtime_put_autosuspend().
So it looks like, there needs to be a runtime PM version of 
mdiobb_read/mdiobb_write() for each pm_runtime_put_*(). As of now, it's 
only sh_eth which is currently using runtime PM and davinci_mdio would 
be the next one. So at least in this case, two variants of 
mdiobb_read/mdiobb_write() could be added at the moment. By checking 
against the dev->power.use_autosuspend flag, it is possible to support 
both via a single version.

That being said, I'm quite inclined towards the existing implementation, 
where drivers can have wrappers written around 
mdiobb_read/mdiobb_write(). But I might be failing to see the broader 
picture. If having multiple runtime PM versions of 
mdiobb_read/mdiobb_write() benefits many other future drivers, then I 
will go ahead and add the variant(s) in the bitbang core.

Please provide your views on this. Your inputs on the next course of 
action would be helpful.

-- 
Regards,
Ravi