Re: More leaves on the device tree ?

I think we're getting a little off track of the TODO items
for the inclusion of the usb code.

I think the original post mentions that devinfo(?) works for
the time being, although perhaps some work later on presentation
could be done.

Let's stick with devinfo and hit up the next tasks on the
inclusion list.

I think the next thing is the SMP locking? Or do you have
anything you have in mind from the list you would like to
tackle next?

thank you,
-Alfred



* Hans Petter Selasky <hselasky@xxxxxxx> [071223 00:42] wrote:
On Sunday 23 December 2007, Poul-Henning Kamp wrote:
In message <20071222.234526.246317277.imp@xxxxxxxxxx>, "M. Warner Losh"
writes:
In message: <200712202005.33263.hselasky@xxxxxxx>

Hans Petter Selasky <hselasky@xxxxxxx> writes:
: "make_dev" takes an additional "device_t parent_device" argument and
: creates a child device with some magic flags set.

What do you do for all the devices in /dev/ for which there is no
device_t parent?

Hi,

If the parent is NULL, then no dev_t node is created.

Regarding cloned devices my opinion is that they should always create a
visible entry. What I have done for a while now is to create a dummy dev_t
node. It is so annoying with invisible devices. Then you never know what you
have got. For example "/dev/usbXXX".

What I do is simply to create "/dev/usb0 " with a space in the end. This file
is not openable. Really there sould be a flag for that. Then you
open "/dev/usb0" instead, but this device is never created. That's the clone
device. Then clones appear like "/dev/usb0.XX":

/dev/usb0 % /dev/usb1 % /dev/usb2 % /dev/usb3 %
/dev/usb0.00% /dev/usb1.00% /dev/usb2.00% /dev/usb3.00%


I second Warners comments here.

device_t is a handle for a hardware, dev_t is for a device in /dev,
they are very different thing and have no reasonable mapping between
them ([0..N]:[0..M])

I'm not saying that every make_dev() should take a device_t parent. If there
is no "device_t" parent then there will be no node created.

Another approach is to add something like:

void device_enlist_subdev(device_t parent, dev_t sub);
void device_delist_subdev(device_t parent, dev_t sub);

struct device {
...
LIST_HEAD(struct cdev) dv_cdev_children;
...
};

struct cdev {
LIST_ENTRY( .... ) dv_list;
};

For example if you have 8 USB serial port adapters, then you just get 8 TTY
devices like /dev/cuaUXXX . And finding out where the USB devices are
actually connected could be very simple if we could put some hints perhaps in
the device_t tree ?

--HPS

--
- Alfred Perlstein
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: klists and struct device semaphores
    ... both the interface and the parent device are locked. ... > the USB bus_type and clear for everything else. ... I think it is fine to lock parent unconditionally. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Selective Suspend for USB composite device
    ... each of the children's SS IRP and when all of the children are ready to ... the parent submits its own USB SS request down the stack. ... parent's USB SS callback is invoked, the parent calls each of the callbacks. ...
    (microsoft.public.development.device.drivers)
  • Re: About USB composite parent device driver - Usbccgp.sys
    ... yes, usbccgp supports USB SS. ... Please do not send e-mail directly to this alias. ... The driver uses usbccgp.sys as its parent driver. ... Now I got a question about the parent driver that does it support USB selective suspend feature? ...
    (microsoft.public.development.device.drivers)
  • Re: Selective Suspend for USB composite device
    ... you can do whatever you want to coordinate state between the child stacks? ... if you want to use usb SS, in your parent driver you need to pend each of the children's SS IRP and when all of the children are ready to suspend, the parent submits its own USB SS request down the stack. ...
    (microsoft.public.development.device.drivers)
  • Re: Selective Suspend for USB composite device
    ... are you using usbccgp for the parent driver which splits the functions into their own stacks? ... if yes, it implements USB SS for the parent, but each FDO that is loaded on its children need to also implement USB SS as well ... single configuration and 3 interfaces. ...
    (microsoft.public.development.device.drivers)