[U-Boot] [PATCH 2/2] usb: eth: add Realtek RTL8152B/RTL8153 driver

[Stephen Warren <swarren@wwwdotorg.org>]

On 11/22/2015 08:09 PM, Simon Glass wrote:
> +Tom
>
> Hi Stephen,
>
> On 22 November 2015 at 10:09, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 11/21/2015 09:50 AM, Simon Glass wrote:
>>> Hi,
>>>
>>> On 21 November 2015 at 00:27, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 11/20/2015 10:38 AM, Marek Vasut wrote:
>>>>> On Friday, November 20, 2015 at 06:35:41 PM, Simon Glass wrote:
>>>>>> Hi,
>>>>>
>>>>> Hi,
>>>>>
>>>>>> On 19 November 2015 at 06:12, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On Thursday, November 19, 2015 at 01:49:16 PM, Anand Moon wrote:
>>>>>>>> Hi Marek,
>>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> Sorry for the mess: Please accept my apology, I will not in the future.
>>>>>>>
>>>>>>> Cool, thanks! :)
>>>>>>
>>>>>> This driver should use driver model, right?
>>>>>
>>>>> Of course.
>>>>
>>>> Hopefully it can support both DM and non-DM?
>>>
>>> Why support non-DM? Isn't that just going to slow us down?
>>
>> I don't think DM is activated everywhere for Ethernet yet is it?
>>
>> I can't see why it'd slow us down. The non-DM code should be quite
>> static, and only have any effect on DM conversion whenever we finally
>> pull the trigger to remove it. It shouldn't be any kind of maintenance
>> issue in the interim.
>
> The conversion to driver model is a large and complex undertaking. It
> cannot be done by a small group of people. If we add new features to
> the 'old world' then there is a temptation for boards to stay there,
> which slows the entire migration process.  Why convert your board to
> driver model if all the shiny new drivers you want work without it? We
> can only remove the old code for a subsystem when every board that
> uses it is either converted or moved.
>
> Adding a new driver that does not use driver model may add a board
> that uses it. That's one more conversion to do and one more hurdle to
> jump.
>
> We will be much more successful if we avoid adding new features to

Given the conversion is quite simple (just deleting an ifdef'd block of 
code in the Ethernet driver) I'm really not sure that I agree that 
adding a new Ethernet driver that supports the old (i.e. 
**currently-in-use**) model is any kind of issue at all. It's just one 
more file to apply a fairly mechanical conversion to.

Either way, Ted, you'll definitely need to supply /me/ a version of the 
driver that's cleaned up according to the review comments here and works 
without DM_ETH (for use by the Linux4Tegra U-Boot), even if that's a 
different patch than what gets applied upstream. It's probably simplest 
if you get a patch accepted upstream that matches only upstream 
requirements, then add back non-DM support once that's accepted and send 
the resulting patch to me.

Thanks.