netdev - Re: [PATCH] stmmac: Don't exit mdio registration when mdio subnode is not found in the DTS

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: <568F0A19.7010208@electromag.com.au>
Date:	Fri, 8 Jan 2016 09:00:09 +0800
From:	Phil Reid <preid@...ctromag.com.au>
To:	Florian Fainelli <f.fainelli@...il.com>,
	Romain Perier <romain.perier@...il.com>
Cc:	peppe.cavallaro@...com, netdev <netdev@...r.kernel.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>
Subject: Re: [PATCH] stmmac: Don't exit mdio registration when mdio subnode is
 not found in the DTS

On 8/01/2016 3:45 AM, Florian Fainelli wrote:
> On 03/01/16 06:36, Romain Perier wrote:
>> Hi,
>>
>> 2016-01-02 18:52 GMT+01:00 Florian Fainelli <f.fainelli@...il.com>:
>>>
>>>>> This looks reasonable, does it work if we just assign mdio_node to the pdev->dev.of_node to be backwards compatible with DTSes which have not yet been updated?
>>>>>
>>>>
>>>> I don't understand what you mean. Instead of defining mdio_node with
>>>> NULL, you propose to assign it to pdev->dev.of_node as its default
>>>> value... then it would be reassigned with "child_nod" if a subnode
>>>> with the compatible string "snps,dwmac-mdio" is found, or kept with
>>>> its default value otherwise... and in this case we could call
>>>> of_mdiobus_register(new_bus, mdio_node) all the time ? (it removes the
>>>> conditonnal branch)
>>>
>>> Your understanding is correct, this is what I was suggesting, thanks
>>
>> So in this case, I already tested this yesterday, it does not work,
>> basically because the for loop just after of_mdiobus_register is never
>> executed, probably because new_bus->phy_map is not populated, which is
>> not the case by calling mdiobus_register for example.
>> of_mdiobus_register seems to populate this array of phys only for
>> subnodes found in the devicetree...
>
> Fair enough, then you initial patch with dropping IS_ENABLED() and
> adding a "Fixes" tag should be resubmitted.
>
Looks reasonable.



-- 
Regards
Phil Reid