linux-kernel - Re: [PATCH 0/2] introduce devm_mdiobus_alloc/devm_mdiobus

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] [day] [month] [year] [list]

Message-ID: <5347CC75.8040300@ti.com>
Date:	Fri, 11 Apr 2014 14:05:25 +0300
From:	Grygorii Strashko <grygorii.strashko@...com>
To:	Florian Fainelli <f.fainelli@...il.com>
CC:	netdev <netdev@...r.kernel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Jonathan Cameron <jic23@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Prabhakar Lad <prabhakar.csengg@...il.com>,
	<santosh.shilimkar@...com>, Sekhar Nori <nsekhar@...com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	dlos <davinci-linux-open-source@...ux.davincidsp.com>
Subject: Re: [PATCH 0/2] introduce devm_mdiobus_alloc/devm_mdiobus_free

Hi Florian,
On 04/11/2014 07:55 AM, Florian Fainelli wrote:
> Hi Grygorii,
> 
> 2014-04-04 6:40 GMT-07:00 Grygorii Strashko <grygorii.strashko@...com>:
>> Introduce a resource managed devm_mdiobus_alloc()/devm_mdiobus_free()
>> to automatically clean up MDIO bus alocations made by MDIO drivers,
>> thus leading to simplified MDIO drivers code.
>>
>> Update Davinci MDIO driver ss example of new devm APIs usage.
> 
> This does look good at first glance. net-next is currently closed at
> the moment, so this will have to be merged later.

Thanks. It can wait for 3.16, so I'll update & resend after rc1.
I have few more patches for davinci_mdio.c, so
my intention here was to check if I can base them on top of new API or not :)

> 
> At some point, we might also want to handle the mdio_bus irq array, as
> that one is also usually dynamically allocated. Maybe we could just do
> a static irq[PHY_MAX_ADDR] allocation, 32 times the size of an integer
> might not be worth a potential leak.

It sounds good, but first of all irq field of mii_bus structure has to be made private. 
And drivers have to use getter/setters to access it - then its type can be changes 
simply and safely.

By the way, mdiobus_register() can be handled using DEVM approach too, but it 
will a bit more complex.

[...]
> 

Regards,
- grygorii

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/