linux-kernel - Re: RFC: Platform data for onboard USB assets

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Mar 2011 10:39:32 +0000
From:	Andy Green <andy@...mcat.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Jaswinder Singh <jaswinder.singh@...aro.org>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	broonie@...nsource.wolfsonmicro.com, roger.quadros@...ia.com,
	greg@...ah.com, grant.likely@...retlab.ca
Subject: Re: RFC: Platform data for onboard USB assets

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/