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: <4D7A80A4.6040008@linaro.org>
Date:	Fri, 11 Mar 2011 20:05:56 +0000
From:	Andy Green <andy@...mcat.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Greg KH <greg@...ah.com>,
	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 07:12 PM, Somebody in the thread at some point said:

Hi -

>> I don't believe I referred to class devices anywhere.  It does not
>> matter if the main chip function is class device or not.
>
> It matters because the class specification for a USB device is never
> going to mention information sources that are outside the USB protocol,
> such as board definitions.  Consequently a class driver will never need
> to use such a thing.

Is a gadget driver a class driver?  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.

>>> Also, do you have a real example of a USB driver today that needs this?
>>
>> I think you find without devpath ->  platform_data mapping, the kind of
>> layout given above is made quite difficult to support in Linux.
>
> What would be needed to support such a mapping?  It seems to me that we
> probably have all the necessary ingredients in place already.

What I was imagining is getting the platform data structs from a header 
in include/linux/

#include <linux/onboard_device_1.h>
#include <linux/onboard_device_2.h>

Using a .name defined to be the first member to match to specific bus 
member devpath prepended with bus class:

struct onboard_device_1_platform_data device_1_platform_data {
	.name = "usb\1-0",
	.some_feature = 1,
};

struct onboard_device_2_platform_data device_2_platform_data {
	.name = "usb\1-1",
	.some_feature = 2,
};

Aggregating them into an array

void *devpath_to_platform_data_mapping[] = {
	device_1_platform_data,
	device_2_platform_data,
};

Registering the array in the machine file

register_platform_data_by_devpath(devpath_to_platform_data_mapping,
	ARRAY_SIZE(devpath_to_platform_data_mapping));

It needs to set two globals for pointer and member count

void
register_platform_data_by_devpath(void *map, int count)
{
	platform_data_mapping = map;
	platform_data_mapping_count = count;
}

Later, when a USB device is instantiated, if platform_data_mapping is 
not NULL, it checks to see if the devname it just synthesized matches 
any in the table that have static usb/ prefix, and if so, sets 
usb_device->dev.platform_data to the table entry.

Well, it's an RFC so if you have a better plan I am all ears.

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