On Thu, May 25, 2023 at 01:31:17PM -0700, Roy Luo wrote: > On Thu, May 25, 2023 at 12:10 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, May 25, 2023 at 11:46:23AM -0700, Roy Luo wrote: > > > Alan, thanks for the quick response! > > > Yes, port_dev->state is indeed the same as port_dev->child->state. However, > > > I still add port_dev->state because port_dev->child won't be assigned until > > > the corresponding usb_device is in ADDRESS state. > > > I wish I can assign get port_dev->child assigned earlier, but I think > > > the current design - assign port_dev->child and device_add() after ADDRESS > > > state - also makes sense because there are many ways that the enumeration > > > could fail in the early stage. By adding port_dev->state, I can link > > > usb_device->state to usb_port as soon as the usb_device is created to get > > > around the limitation of port_dev->child. > > > I would be very happy to hear other ideas. > > > > Is there any real reason not to set port_dev->child as soon as the > > usb_device structure is created? If enumeration fails, the pointer can > > be cleared. > > > > Alan Stern > > Currently the usb core assumes the usb_device that port_dev->child points > to is enumerated and port_dev->child->dev is registered when > port_dev->child is present. Setting port_dev->child early would break this > fundamental assumption, hence I'm a bit reluctant to go this way. Well, you could remove that assumption by adding a "child_is_registered" flag and explicitly checking it. Alan Stern
