于 2012/8/24 22:45, Alan Stern 写道: > On Fri, 24 Aug 2012, Lan Tianyu wrote: > >>>> But if other places got hub descriptor, they can't get DeviceRemovable >>>> value since we only set DeviceRemovable in the hub_configure().(e.g lsusb). > > Note: This isn't true. You now set desc->u.hs.DeviceRemovable in > ehci_hub_descriptor(). Oh. Sorry. I maybe confuse you or make you misunderstand due to my broken descriptor. Do you agree set desc->u.hs.DeviceRemovable in ehci_hub_descriptor()? > >>> I don't understand. lsusb will be able to see the DeviceRemovable >>> values in sysfs, won't it? >> lsusb will issue get hub descriptor request in the usr space and print >> DeviceRemovable. > > Sure, that's right. But that's not what I was complaining about -- I > was complaining about the fact the you want to call > get_hub_descriptor() twice. > >> So if we put setting DeviceRemovable in the hcd's hub descriptor request >> routine, usr space could also get acpi information via getting hub >> descriptor and we don't need to expose DeviceRemovable sysfs file. > > Userspace doesn't use get_hub_descriptor() (it calls usb_control_msg() > directly). Therefore you don't need to set any DeviceRemovable > information in that routine. Yeah. If we set desc->u.hs.DeviceRemovable in ehci_hub_descriptor(), this will be no problem. > >>>> Another problem is that some hcds will set DeviceRemovable themselves. >>>> There will be a conflict between hcd and acpi information. Different >>>> hcds may have different processes. >>> >>> There is always the possibility of a conflict. This remains true >>> whether you get the hub descriptor once or twice. >> Yeah. how to deal with conflict >> First time of getting the hub descriptor is to initialize hub and create >> port devices. The second time is to update DeviceRemovable after >> port devices create. > > Look, I can't tell exactly what's going on here because I can't see > your code. It isn't present in any trees that I have access to, and I > can't see what's going on by trying to read multiple patches spread > over several email threads. Yeah. That is the problem since my previous patchset still is not merged in the usb-next. But I also want to make this some progress. Do you have some suggestiones? I have thought of sending these patches with my previous patch. But it will make the whole patchset's version number increase quickly which may be nice. Since previous patches maybe relative stable. > Furthermore, I don't see why you need to update > hub->descriptor->u.hs.DeviceRemovable at all. The value returned by > hub_configure() the first time will be correct; there's no reason to > call get_hub_descriptor() a second time. At the first time, the hub->maxchild is not set and port's device was not created so usb port has not been bound with acpi. usb port's ACPI information is not accessible at that time. The usb_get_hub_port_connect_type will return type_unkown. The value returned by first time of call get_hub_descriptor() will not be correct. You can see follow link to find related code. http://marc.info/?l=linux-usb&m=134517695107183&w=2 @@ -181,7 +182,7 @@ static inline char *portspeed(struct usb_hub *hub, int portstatus) /* Note that hdev or one of its children must be locked! */ static struct usb_hub *hdev_to_hub(struct usb_device *hdev) { - if (!hdev || !hdev->actconfig) + if (!hdev || !hdev->actconfig || !hdev->maxchild) return NULL; return usb_get_intfdata(hdev->actconfig->interface[0]); } http://marc.info/?l=linux-usb&m=134553867601771&w=2 @@ -5254,6 +5258,9 @@ usb_get_hub_port_connect_type(struct usb_device *hdev, int port1) { struct usb_hub *hub = hdev_to_hub(hdev); + if (!hub) + return USB_PORT_CONNECT_TYPE_UNKNOWN; + return hub->ports[port1 - 1]->connect_type; } My original thought of calling get_hub_descriptor() a second time is that after the port's device created and hub->maxchild has been set, the usb_get_hub_port_connect_type() will work. So call again to set desc->u.hs.DeviceRemovable in ehci_hub_descriptor(). -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
