On Wed, 26 Feb 2014, Dan Williams wrote:
> When CPU2 takes the lock it will certainly be after hubA->disconnected
> has been set, but I don't see what prevents de-referencing the hubA
> pointer from crashing. Continuing the above example:
>
> CPU1CPU2
> mutex_lock(pee
On Wed, 2014-02-26 at 10:49 -0500, Alan Stern wrote:
> On Tue, 25 Feb 2014, Dan Williams wrote:
>
> > > Look, we guarantee that the peer relation is dropped when either of the
> > > devices is unregistered. Therefore there's no need to take a reference
> > > to the peer device.
> >
> > Ugh, ye
On Tue, 25 Feb 2014, Dan Williams wrote:
> > Look, we guarantee that the peer relation is dropped when either of the
> > devices is unregistered. Therefore there's no need to take a reference
> > to the peer device.
>
> Ugh, yes. Reference counts alone don't save us from this scenario:
>
> C
On Tue, 2014-02-25 at 13:19 -0500, Alan Stern wrote:
> On Mon, 24 Feb 2014, Dan Williams wrote:
>
> > On Mon, 2014-02-24 at 19:01 -0800, Dan Williams wrote:
> > > As mentioned in the comments on patch 2, while ->peer is being modified
> > > we don't want usb_port_runtime_{suspend|resume} to run.
On Mon, 24 Feb 2014, Dan Williams wrote:
> On Mon, 2014-02-24 at 19:01 -0800, Dan Williams wrote:
> > As mentioned in the comments on patch 2, while ->peer is being modified
> > we don't want usb_port_runtime_{suspend|resume} to run. Introduce
> > pre_modify_peers() and post_modify_peers() to clo
On Mon, 2014-02-24 at 19:01 -0800, Dan Williams wrote:
> As mentioned in the comments on patch 2, while ->peer is being modified
> we don't want usb_port_runtime_{suspend|resume} to run. Introduce
> pre_modify_peers() and post_modify_peers() to close that hole.
...thinking about it further, when
On Fri, 2014-02-21 at 16:09 -0800, Dan Williams wrote:
> ClearPortFeature(PORT_POWER) on a usb3 port places the port in either a
> DSPORT.Powered-off-detect / DSPORT.Powered-off-reset loop, or the
> DSPORT.Powered-off state. There is no way to ensure that RX
> terminations will persist in this sta
ClearPortFeature(PORT_POWER) on a usb3 port places the port in either a
DSPORT.Powered-off-detect / DSPORT.Powered-off-reset loop, or the
DSPORT.Powered-off state. There is no way to ensure that RX
terminations will persist in this state, so it is possible a device will
degrade to its usb2 connect
