Re: RFC: Platform data for onboard USB assets

Andy Green
2011-03-23T10:42:08Z

On 03/23/2011 10:32 AM, Somebody in the thread at some point said:
> On Wednesday 23 March 2011, Andy Green wrote:
>> It's the case for even usbnet, which is using a broken heuristic to
>> decide what to call the interface not even based on vid / pid.
>
> I agree that the heuristics in usbnet is less than helpful here,
> which among other things leads people to mixing up the two problems
> of fixing the device naming and fixing the MAC address assignment.
>
> Even though I know Greg disagrees, I'd still prefer sanitising the
> rules for the default device name that usbnet assigns. Simply letting
> a device driver flag "this is always an external ethernet, not
> a point-to-point connection" would be enough to solve this problem,
> and take some of the heat out of the discussion for how to solve
> the MAC address assignment.

Completely agree, I have a happy feeling being able to say that too.
But I already see there's no path through Greg let alone Alan, so it'll
have to be dealt with a less good way.

>> Before this RFC there's no generic support for the concept, although
>> that hasn't stopped it being implemented in wl12xx already at individual
>> mainline driver level. And before this RFC, I don't believe there was
>> any concept of async tagging through bus path for soldered-on assets in
>> Device Tree either.
>
> For the device tree, the method has always been to assign the device_node
> pointer to the device when the parent bus gets probed, that has not changed.
> The new idea that came as a result of your RFC is to use the same mechanism
> that we use elsewhere for USB as well, with the existing USB binding.

Fair enough.

-Andy