Re: RFC: Platform data for onboard USB assets

[Andy Green]

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


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