On Tue, 8 Sep 2015, Ken Xue wrote:
> On Mon, 2015-09-07 at 10:48 -0400, Alan Stern wrote:
> > On Mon, 7 Sep 2015, Xue, Ken wrote:
> >
> > > Hi Alan and James,
> > > I found a bug about sr device runtime suspend & resume which is
> > > introduced by your patch about fixing NULL pointer dereferenc
On Mon, 2015-09-07 at 10:48 -0400, Alan Stern wrote:
> On Mon, 7 Sep 2015, Xue, Ken wrote:
>
> > Hi Alan and James,
> > I found a bug about sr device runtime suspend & resume which is introduced
> > by your patch about fixing NULL pointer dereference in runtime PM.
> > You know that sr device onl
On Mon, 7 Sep 2015, Xue, Ken wrote:
> Hi Alan and James,
> I found a bug about sr device runtime suspend & resume which is introduced by
> your patch about fixing NULL pointer dereference in runtime PM.
> You know that sr device only has runtime suspend routine but doesn't have
> resume routine.
On Mon, 17 Aug 2015, Alan Stern wrote:
> The routines in scsi_rpm.c assume that if a runtime-PM callback is
> invoked for a SCSI device, it can only mean that the device's driver
> has asked the block layer to handle the runtime power management (by
> calling blk_pm_runtime_init(), which among ot
Alan Stern writes:
> The routines in scsi_rpm.c assume that if a runtime-PM callback is
> invoked for a SCSI device, it can only mean that the device's driver
> has asked the block layer to handle the runtime power management (by
> calling blk_pm_runtime_init(), which among other things sets q->
The routines in scsi_rpm.c assume that if a runtime-PM callback is
invoked for a SCSI device, it can only mean that the device's driver
has asked the block layer to handle the runtime power management (by
calling blk_pm_runtime_init(), which among other things sets q->dev).
However, this assumpti
6 matches
Mail list logo
