d0a7e57400
I recently tried to construct a totally generic transport class and found there were certain features missing from the current abstract transport class. Most notable is that you have to hang the data on the class_device but most of the API is framed in terms of the generic device, not the class_device. These changes are two fold - Provide the class_device to all of the setup and configure APIs - Provide and extra API to take the device and the attribute class and return the corresponding class_device Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> |
||
---|---|---|
.. | ||
acorn | ||
acpi | ||
atm | ||
base | ||
block | ||
bluetooth | ||
cdrom | ||
char | ||
cpufreq | ||
crypto | ||
dio | ||
eisa | ||
fc4 | ||
firmware | ||
hwmon | ||
i2c | ||
ide | ||
ieee1394 | ||
infiniband | ||
input | ||
isdn | ||
macintosh | ||
mca | ||
md | ||
media | ||
message | ||
misc | ||
mmc | ||
mtd | ||
net | ||
nubus | ||
oprofile | ||
parisc | ||
parport | ||
pci | ||
pcmcia | ||
pnp | ||
s390 | ||
sbus | ||
scsi | ||
serial | ||
sh | ||
sn | ||
tc | ||
telephony | ||
usb | ||
video | ||
w1 | ||
zorro | ||
Kconfig | ||
Makefile |