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]

Message-ID: <4D7A8F28.4080908@linaro.org>
Date:	Fri, 11 Mar 2011 21:07:52 +0000
From:	Andy Green <andy@...mcat.com>
To:	Greg KH <greg@...ah.com>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Arnd Bergmann <arnd@...db.de>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

On 03/11/2011 08:21 PM, Somebody in the thread at some point said:

>> Is a gadget driver a class driver?
>
> Some are, but you are now on the "other side" of the USB bus.

The goal of this is to allow board-specific data to define platform_data 
in any bus members.

>> Because I can set the MAC address for my g_ether from the kernel
>> commandline which is most definitely an "information source outside
>> the USB protocol".  That is exactly the kind of thing I am talking
>> about enabling also to be taken from usb_device->dev.platform_data.
>
> You don't have a usb_device for a gadget device.  USB Gadgets are a
> totally different world here, don't confuse them please.

Okay; but all that matters for this is that usb_gadget has a struct 
device composed in it, which in turn has a platform_data.  Gadget 
drivers can also benefit from the mapping scheme the same way.

I wrote up this RFC after a quick check struct device exists in the usb 
objects and grepping that nothing uses platform_data already.  If it 
isn't killed dead during this I will make workable patches for comment.

>> Using a .name defined to be the first member to match to specific
>> bus member devpath prepended with bus class:
>
> You can't rely on USB bus numbers to be the same EVER.  These are
> assigned by the host computer.

Alright: is there a better invariant nomenclature to talk about "the 
gadget / host that is running on a particular pair of pins"?  That's the 
ultimate definition of what's wired to what.

It's okay if the nomenclature differs for gadget or host because we can 
prepend a namepace token that is checked for before looking for a match 
in each case.

>> Well, it's an RFC so if you have a better plan I am all ears.
>
> I am totally confused, and as you are messing with bus id numbers, and
> confusing usb gadgets and drivers, I think you are as well.
>
> So, are you talking about USB gadgets, or USB drivers here?  They are
> different and have different requirements and responsibilities.

Both can make use of platform_data.  At the moment both gadget and host 
USB devices have NULL platform data members sitting there.  What this 
proposal is about is being able to teleport structs into those pointers 
from the board file, when gadget or host are instantiated that match. 
After that, drivers that are interested to take direction about anything 
can tell what they're willing to look at in their platform_data struct 
definition.

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