> >> Look at the device nodes. The kernel has mouse0 for example and udev
quoted text
> >> will translate this into /dev/input/mouse0. Nobody expects the kernel
> >> to use input/mouse0 and actually you even can't do that at all since
> >> the device model forbids "/" as bus id. Same applies for the firmware
> >> filenames.
> >
> > No, it doesn't.
>=20
> please enlighten me how you can use "/" within bus ids.

Please enlighten me why you need to use the firmware key in the bus ID.

quoted text
> So you actually do know how request_firmware() actually works right =20
> now? You need to change the firmware_class implementation and API to =20
> give it an extra parameter to allow any kind if simultaneous loading =20
> within one driver.=20

Yeah, the API change required is internal and rather trivial.

quoted text
> Having the FIRMWARE as environment variable is =20
> actually suboptimal.=20

Why? You still haven't given any reason for this.

quoted text
> You want to have the FIRMWARE environment =20
> variable as bus_id for the firmware struct device object.

Why?

The way I see it, there's nothing stopping you from creating firmware
"devices" using a simple increasing number as the bus_id, and having the
firmware key be presented in a 'FIRMWARE' property of those devices.
Then, the userspace loader realises such a device is created, looks at
the firmware property, takes the firmware, and stuffs it into the 'data'
property. It doesn't matter how many there are outstanding at the same
time because one userspace process is invoked per firmware device, hence
per ID.

johannes