Re: use_generic and usb probing
on 17/05/2011 10:19 Andriy Gapon said the following: So I am going to commit this. If it breaks anything for anyone and the problem would not be really trivial, the I'll just revert the change. r222051. Please take this commit in consideration if you run into any USB-related problems. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: use_generic and usb probing
on 06/04/2011 16:28 Hans Petter Selasky said the following: Run a kernel test compile including all modules. If that's OK it should be fine. So I am going to commit this. If it breaks anything for anyone and the problem would not be really trivial, the I'll just revert the change. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: use_generic and usb probing
On Tuesday 05 April 2011 18:45:51 Andriy Gapon wrote: on 05/04/2011 15:55 Hans Petter Selasky said the following: On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: I believe that newbus already supports ordering of children on a bus. BTW, does USB have to pass anything from probe to attach? Mostly only the driver info field. To avoid duplicate lookups. Duplicate lookup is of course not very nice, but duplicate probing pass is not nice either. This can all be avoided if the bus-drivers are sorted correctly before probing! Hi, Well, I think that that's what probe priorities actually for. I also think that typically ivars should be set by a bus driver. So maybe it's not such a good idea to pass data from probe to attach via ivars in child drivers. But I could be mistaken about that. The same device_t is used to do all the probes! Practically speaking, you most likely don't have to worry about that for drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And there is only a few generic drivers that can be handled on a case by case basis. There are more drivers that needs patching! Please scan all of the kernel files for usbdi.h and the use_generic flag. After looking at subr_usb.c I see your solution is fine as long as the PROBE() method that it attaches is the last one called before ATTACH(). If this is documented in how newbus should function, then please go ahead updating your patch to cover all USB drivers using use_generic. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: use_generic and usb probing
On Wednesday, April 06, 2011 3:33:47 am Hans Petter Selasky wrote:
On Tuesday 05 April 2011 18:45:51 Andriy Gapon wrote:
on 05/04/2011 15:55 Hans Petter Selasky said the following:
On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote:
I believe that newbus already supports ordering of children on a bus.
BTW, does USB have to pass anything from probe to attach?
Mostly only the driver info field. To avoid duplicate lookups.
Duplicate lookup is of course not very nice, but duplicate probing pass
is not nice either.
This can all be avoided if the bus-drivers are sorted correctly before
probing!
Hi,
Well, I think that that's what probe priorities actually for.
I also think that typically ivars should be set by a bus driver. So maybe
it's not such a good idea to pass data from probe to attach via ivars in
child drivers. But I could be mistaken about that.
The same device_t is used to do all the probes!
Practically speaking, you most likely don't have to worry about that for
drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And
there is only a few generic drivers that can be handled on a case by
case basis.
There are more drivers that needs patching! Please scan all of the kernel
files for usbdi.h and the use_generic flag.
After looking at subr_usb.c I see your solution is fine as long as the
PROBE()
method that it attaches is the last one called before ATTACH(). If this is
documented in how newbus should function, then please go ahead updating your
patch to cover all USB drivers using use_generic.
Yes. The device_probe() routine is called for the best matching driver
(based on the return values from device_probe()) before device_attach() is
called. Check device_probe_child() for the gory details including:
if (pri 0) {
/*
* A bit bogus. Call the probe method again to make
* sure that we have the right description.
*/
DEVICE_PROBE(child);
#if 0
child-flags |= DF_REBID;
#endif
} else
child-flags = ~DF_REBID;
child-state = DS_ALIVE;
--
John Baldwin
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: use_generic and usb probing
On Tuesday 05 April 2011 13:06:22 Andriy Gapon wrote: on 03/04/2011 13:46 Andriy Gapon said the following: Mostly out of curiosity (but not only because of that) I wonder why the use_generic flag and two probing passes are needed in USB driver probing code. That is, why the standard approach of using different probing return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't work here. I couldn't find any historic reason for this, so I am assuming that this is a kludge to work-around inconsistent return values in various USB newbus probe routines. Please see here my attempt at cleaning up the basics: http://people.freebsd.org/~avg/usb-use_generic.diff Reviews and testing are welcome. P.S. A side-effect of this patch is removal of a minor annoyance in a form of the following message: Unknown USB device: vendor product bus The message is produced by devd almost any time anything is connected via USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) use_generic=0 probing pass in USB. Hi, In the initial USB stack design drivers are supposed to either report match or non-match. The reason for this is that sometimes parameters are passed on from the probe to the attach via the USB attach args. See usbd_lookup_id_by_uaa(). When multiple drivers are probed and match, the information presented by the usb_attach_arg's can get messed up with regard to the attaching driver. It would be better if the newbus could support a probing priority argument! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: use_generic and usb probing
on 05/04/2011 14:21 Hans Petter Selasky said the following: On Tuesday 05 April 2011 13:06:22 Andriy Gapon wrote: on 03/04/2011 13:46 Andriy Gapon said the following: Mostly out of curiosity (but not only because of that) I wonder why the use_generic flag and two probing passes are needed in USB driver probing code. That is, why the standard approach of using different probing return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't work here. I couldn't find any historic reason for this, so I am assuming that this is a kludge to work-around inconsistent return values in various USB newbus probe routines. Please see here my attempt at cleaning up the basics: http://people.freebsd.org/~avg/usb-use_generic.diff Reviews and testing are welcome. P.S. A side-effect of this patch is removal of a minor annoyance in a form of the following message: Unknown USB device: vendor product bus The message is produced by devd almost any time anything is connected via USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) use_generic=0 probing pass in USB. Hi, In the initial USB stack design drivers are supposed to either report match or non-match. The reason for this is that sometimes parameters are passed on from the probe to the attach via the USB attach args. See usbd_lookup_id_by_uaa(). When multiple drivers are probed and match, the information presented by the usb_attach_arg's can get messed up with regard to the attaching driver. It would be better if the newbus could support a probing priority argument! I believe that newbus already supports ordering of children on a bus. BTW, does USB have to pass anything from probe to attach? Duplicate lookup is of course not very nice, but duplicate probing pass is not nice either. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: use_generic and usb probing
On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: I believe that newbus already supports ordering of children on a bus. BTW, does USB have to pass anything from probe to attach? Mostly only the driver info field. To avoid duplicate lookups. Duplicate lookup is of course not very nice, but duplicate probing pass is not nice either. This can all be avoided if the bus-drivers are sorted correctly before probing! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: use_generic and usb probing
on 05/04/2011 15:55 Hans Petter Selasky said the following: On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: I believe that newbus already supports ordering of children on a bus. BTW, does USB have to pass anything from probe to attach? Mostly only the driver info field. To avoid duplicate lookups. Duplicate lookup is of course not very nice, but duplicate probing pass is not nice either. This can all be avoided if the bus-drivers are sorted correctly before probing! Well, I think that that's what probe priorities actually for. I also think that typically ivars should be set by a bus driver. So maybe it's not such a good idea to pass data from probe to attach via ivars in child drivers. But I could be mistaken about that. Practically speaking, you most likely don't have to worry about that for drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And there is only a few generic drivers that can be handled on a case by case basis. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
