Hi Garrett, Artem and all on driver-discuss and driver-usb,
if I may ask for your advice *again* regarding my Option HSO driver project:
Yesterday, I have started to draft the design for the three driver approach
Artem and Garrett were recommending:
* usbhso should become a nexus driver to discover the device's logical ports:
network ports, muxed serial ports or CDC-like serial ports.
usbhso should create for each logical port (or a set of logical ports of the
same type) a devi node. Each port node's devi_parent_data should contain the
information the port driver needs to do its job:
- port config (what kind of a port is this ?)
- which USB interface, alt config to use (and maybe endpoint indexes)
- pointer to the usba_device_t of the usba framework
- for mux ports, maybe a pointer to shared port config (I am also considering
to use one devi node for all the muxed ports of one USB interface, which
seems to be the cleaner solution. Then the shared port config could be
maintained by the port driver).
* usbshso (s for serial, according to Artem's usbser naming convention) will be
a client of usbser and handle muxed and ordinary serial ports. It
will resemble usbsacm to a certain extent.
* usbnhso (n for network) will be a GLDv3 driver and handle network I/O
At the moment, I am facing two design decisions on which I would appreciate
your
advice:
- My understanding so far is that only the nexus driver should register as a
USBA client, as only it would represent the whole device from a USB point of
view. Also, USBA needs devi_parent_data to hold the usba_device_t, so if the
port drivers were USBA clients, I'd need another way to pass down information
the device tree.
If this was the way to go, the port drivers would need to perform USBA
framework actions on the usba_device_t the nexus driver has registered on.
My first question is if only registering the nexus driver as a USBA client
sounds like the right decision and in particular if it is acceptable for a
port driver to use the nexus driver's usba_device_t.
- Secondly, if only the nexus driver is a USBA client, I suspect it will need
some way to have the port drivers execute some actions. Right now the only
example I've got on my list are the USB event callbacks, but I am pretty sure
there will be other cases.
Is it a good approach to include in devi_parent_data a list of callbacks into
the port drivers for the nexus driver to execute?
Also, one question on the side: Is it correct that for nexus drivers it is more
appropriate to use devi_driver_data (via ddi_(set|get)_driver_private) rather
than a soft state because each nexus driver instance gets its own dip anyway?
Nils
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
