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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 23 Mar 2011 11:32:02 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	andy.green@...aro.org
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 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.

> 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.

	Arnd
--
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/