[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAC3K-4r1Of0H4YCX0+50ivEMx8C8u+rf_WxD+w6zrxjMwGwT1Q@mail.gmail.com>
Date: Wed, 29 Jun 2016 16:34:05 -0400
From: Jon Mason <jon.mason@...adcom.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Florian Fainelli <f.fainelli@...il.com>,
"Rafa?? Mi??ecki" <zajec5@...il.com>, davem@...emloft.net,
Hauke Mehrtens <hauke@...ke-m.de>,
BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 3/7] net: ethernet: bgmac: move BCMA MDIO Phy code into a
separate file
On Wed, Jun 29, 2016 at 4:15 PM, Andrew Lunn <andrew@...n.ch> wrote:
> On Wed, Jun 29, 2016 at 04:08:20PM -0400, Jon Mason wrote:
>> On Wed, Jun 29, 2016 at 2:46 PM, Andrew Lunn <andrew@...n.ch> wrote:
>> > On Wed, Jun 29, 2016 at 11:35:28AM -0700, Florian Fainelli wrote:
>> >> On 06/29/2016 07:13 AM, Andrew Lunn wrote:
>> >> > Hi Jon
>> >> >
>> >> > I know you are just refactoring code, but at some point it would be
>> >> > good to take a closer look at this MDIO bus driver.
>> >
>> >> And, to re-iterate all of your points are valid, but this is premature
>> >
>> > We agree then :-)
>> >
>> > Andrew
>>
>> I also agree with all of your points, but hope this is not something
>> that would prevent this patch series from being acceptable.
>
> No, it is acceptable as is.
>
> However, it would be nice the clean up the mess, especially if you are
> planning on using this code with new platforms, not just legacy stuff
> which is bit rotting.
I don't believe we'll be using the BCMA infrastructure going forward.
We'll be doing our own MDIO Phys, adding them to the device tree, and
referencing them through the DT/OF method. This is the current plan
for NSP, NS2, Cygnus, and other upcoming platforms. If someone can
find an elegant way of splitting off the Phy code from the BCMA core,
then this can be better than it is now. But, it will take someone
with docs, time, and hardware to give this code the audit and cleanup
it really needs. BTW, my last comment isn't intended as a slight
against the authors of this code. It is unfortunate that they were
put in a position of having to reverse engineer drivers for this HW.
Thanks,
Jon
>
> Andrew
Powered by blists - more mailing lists