lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dfaa91d3-1169-4381-a2ef-83443ee3e4ce@rowland.harvard.edu>
Date:   Thu, 25 May 2023 20:50:53 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Roy Luo <royluo@...gle.com>
Cc:     raychi@...gle.com, badhri@...gle.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Michael Grzeschik <m.grzeschik@...gutronix.de>,
        Bastien Nocera <hadess@...ess.net>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Flavio Suligoi <f.suligoi@...m.it>,
        Douglas Anderson <dianders@...omium.org>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC PATCH v1] usb: core: add sysfs entry for usb device state

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@...land.harvard.edu> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ