Nils Goroll wrote:
> 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?
Your thinking is correct. I'd probably skip having callback function
pointers though, and instead just hard code the dependency. I don't
*think* you need to support a generic bus framework. (So your child
driver will depend on, via the -dy -Ndrv/your_nexus_driver flags, the
nexus driver. It can just directly call functions from the nexus driver
then.)
>
> 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?
No, either approach is perfectly valid. The thing about
devi_driver_data is that you have to know the devinfo node. If you need
to get at data when you don't know that, the soft state routines can be
more useful (since then all you need is an instance number.) The soft
state routines can also store anything that requires a small index, not
just driver soft state.
-- Garrett
>
>
> Nils
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
