Am Dienstag, den 03.09.2019, 12:18 +0200 schrieb Oliver Neukum:
> This reverts commit f95aec18e46af9d7fb6f312020824d536dd720dd.
Please ignore this.
Regards
Oliver
I've got a report about a UAS drive enclosure reporting back
Sense: Logical unit access not authorized
if the drive it holds is password protected. While the drive
is obviously unusable in that state as a mass storage device,
it still exists as a sd device and when the system is asked
to perform a
This reverts commit f95aec18e46af9d7fb6f312020824d536dd720dd.
---
drivers/gnss/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gnss/core.c b/drivers/gnss/core.c
index 0d13bd2cefd5..e6f94501cb28 100644
--- a/drivers/gnss/core.c
+++ b/drivers/gnss/core.c
@@ -303,7
On Do, 2019-04-04 at 08:51 -0700, Bart Van Assche wrote:
> On Thu, 2019-04-04 at 16:47 +0200, Oliver Neukum wrote:
> > If a reset of a SCSI device requires no relocking of the door, the
> > flag must be reset anyway, lest it trigger unnecessary door action
> > later on.
&
If a reset of a SCSI device requires no relocking of the door, the
flag must be reset anyway, lest it trigger unnecessary door action
later on.
Signed-off-by: Oliver Neukum
---
drivers/scsi/scsi_error.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi
On Fr, 2019-03-08 at 09:13 +, kento.a.kobaya...@sony.com wrote:
> The usb_reset_and_verify_device included in usb_reset_device fails
> with -ENODEV after power off hub port, and the -ENODEV error will
> be reported to uas_eh_bus_reset_handler and upper layer, so it
> doesn't need to do rebind i
On Fr, 2019-02-08 at 13:25 -0800, Bart Van Assche wrote:
> This patch does not change any functionality.
>
> Cc: Oliver Neukum
> Signed-off-by: Bart Van Assche
Acked-by: Oliver Neukum
On Di, 2018-10-30 at 08:28 +, Zengtao (B) wrote:
> Hi
> For the issue itself, there is my observation:
> In the step 4, the Host will issue an PREVENT_ALLOW_MEDIUM_REMOVAL scsi
> command.
> and and timeout happens due to the device 's very slow fsg_lun_fsync_sub.
> I found there are two me
t to protect
dev->resetting.
I don't see why the scope of the lock would need to be enlarged.
Regards
Oliver
> To fix this data race, the write operations on line 634-635
> should be also protected by the lock.
>
> Signed-off-by: Jia-Ju Bai
Nacked-by: Oliver Neukum
Am Mittwoch, den 14.03.2018, 11:22 +0100 schrieb Kashyap Chamarthy:
> I see. So I ran `dmesg -w`, as I attached the disk & see the following:
UAS and no quirk for your device. It looks like it indeed just does
not support TRIM.
Sorry
Oliver
Am Dienstag, den 13.03.2018, 12:50 +0100 schrieb Kashyap Chamarthy:
> Earlier, I didn't know which list to email, so I wrote to Martin K.
> Petersen (who pointed me to the lists when I asked where I can post
> publicly), and he made this observation on the above quoted text:
>
> "Linux can run
this?
>From 4d1e26154bc5d09913bfba34d7adc39cce98d20a Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 10 Jan 2018 16:16:03 +0100
Subject: [PATCH] usb: uas: unconditionally bring back host after reset
Quoting Hans:
If we return 1 from our post_reset handler, then our disconnect handler
will be called immediately af
Am Dienstag, den 14.11.2017, 18:44 +0100 schrieb Hans de Goede:
>
> Greg, please do no merge the 2 recent uas seagate quirks I send
> then. I will submit a patch with the new approach right away.
Hi,
I am afraid in that case we will need a way to override a
quirk in the other direction, that is,
On Tue, 2016-12-27 at 21:19 -0500, Alan Stern wrote:
> On Tue, 27 Dec 2016, George Cherian wrote:
> > True. I am afraid that there necessarily is a window for resetting a
> > disconnected device. But the check you proposed is better.
> > however, I'd like to encapsulate that together with a test f
On Tue, 2016-12-27 at 10:20 -0500, Alan Stern wrote:
> On Tue, 27 Dec 2016, Oliver Neukum wrote:
>
> > On Thu, 2016-12-22 at 17:44 -0500, Alan Stern wrote:
> > > I don't see how this patch fixes anything. Unless I'm mistaken, it
> > > just avoids the probl
On Thu, 2016-12-22 at 17:44 -0500, Alan Stern wrote:
> I don't see how this patch fixes anything. Unless I'm mistaken, it
> just avoids the problem by preventing the system from issuing the
> command that provokes the error, rather than really fixing the
> underlying error.
Please clarify. If a r
On Thu, 2016-12-22 at 15:43 +0530, George Cherian wrote:
> dmesg with the patch applied
Hi,
did you apply both patches, yours and the one I posted?
And did you physically disconnect your device?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe
ed patch and do a SCSI log of the enumeration?
Regards
Oliver
From d4ddac88bbf9cb15e7d8638582f96d31e245f15b Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 21 Dec 2016 15:34:54 +0100
Subject: [PATCH] uas: device crashes on reset
We avoid resetting it.
Signed-of
On Wed, 2016-12-21 at 17:37 +0530, George Cherian wrote:
>
> On 12/21/2016 05:12 PM, Oliver Neukum wrote:
> > On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:
> >> Hi Oliver,
> >>
> >> I was working with this JMicron device and using the uas driver.
On Wed, 2016-12-21 at 12:54 +0100, Hans de Goede wrote:
> Hi,
>
> On 21-12-16 12:42, Oliver Neukum wrote:
> > On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:
> >> Hi Oliver,
> >>
> >> I was working with this JMicron device and using the uas drive
On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:
> Hi Oliver,
>
> I was working with this JMicron device and using the uas driver.
> I am seeing the following 2 issues.
>
> 1) On connect I see the following messages.
Thanks. Do you want to submit it to Greg?
The patch is fine.
> 2) On d
Some SATA to USB bridges fail to cooperate with some
drives resulting in no cache being present being reported
to the host. That causes the host to skip sending
a command to synchronize caches. That causes data loss
when the drive is powered down.
Signed-off-by: Oliver Neukum
Reviewed-by: Martin
On Thu, 2016-08-18 at 22:19 -0400, Martin K. Petersen wrote:
> >>>>> "Oliver" == Oliver Neukum writes:
>
> Oliver> Some SATA to USB bridges fail to cooperate with some drives
> Oliver> resulting in no cache being present being reported to the
> Oliv
Some SATA to USB bridges fail to cooperate with some
drives resulting in no cache being present being reported
to the host. That causes the host to skip sending
a command to synchronize caches. That causes data loss
when the drive is powered down.
Signed-off-by: Oliver Neukum
---
Documentation
On Tue, 2016-08-16 at 00:44 -0400, Martin K. Petersen wrote:
> >>>>> "Oliver" == Oliver Neukum writes:
>
> Oliver,
>
> Oliver> wce_default_on controls the default if the device provides no
> Oliver> indication. The problem here is that the
On Wed, 2016-08-10 at 22:40 -0400, Martin K. Petersen wrote:
> >>>>> "Oliver" == Oliver Neukum writes:
>
> Oliver> Some SATA to USB bridges fail to cooperate with some drives
> Oliver> resulting in no cache being present being reported to the
> Oliv
Some SATA to USB bridges fail to cooperate with some
drives resulting in no cache being present being reported
to the host. That causes the host to skip sending
a command to synchronize caches. That causes data loss
when the drive is powered down.
Signed-off-by: Oliver Neukum
Reviewed-by
Some SATA to USB bridges fail to cooperate with some
drives resulting in no cache being present being reported
to the host. That causes the host to skip sending
a command to synchronize caches. That causes data loss
when the drive is powered down.
Signed-off-by: Oliver Neukum
---
Documentation
On Thu, 2016-07-14 at 14:26 +0200, Hans de Goede wrote:
> Oliver Neukum is taking over uas maintainership from me and
> Gerd Hoffmann.
>
> Cc: Oliver Neukum
> Cc: Gerd Hoffmann
> Signed-off-by: Hans de Goede
Acked-by: Oliver Neukum
--
To unsubscribe from this list: send the
Some SATA to USB bridges fail to cooperate with some
drives resulting in no cache being present being reported
to the host. That causes the host to skip sending
a command to synchronize caches. That causes data loss
when the drive is powered down.
Signed-off-by: Oliver Neukum
---
Documentation
Some SATA to USB bridges fail to cooperate with some
drives resulting in no cache being present being reported
to the host. That causes the host to skip sending
a command to synchronize caches. That causes data loss
when the drive is powered down.
Signed-off-by: Oliver Neukum
---
drivers/scsi
On Tue, 2016-05-31 at 09:18 +0200, Hans de Goede wrote:
> Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level")
> removed the scsi_change_queue_depth() call from uas_slave_configure()
> assuming that the slave would inherit the host's queue_depth, which
> that commit sets to the sam
On Thu, 2016-02-04 at 19:22 +0800, Charles Chiou wrote:
> +static int stex_choice_sleep_mic(pm_message_t state)
> +{
> +switch (state.event) {
> +case PM_EVENT_SUSPEND:
> +return ST_S3;
> +case PM_EVENT_FREEZE:
Why do you react to PM_EVENT_FREEZE at all?
That is too early. You
On Tue, 2016-01-26 at 10:28 -0500, Alan Stern wrote:
> On Tue, 26 Jan 2016, Oliver Neukum wrote:
> > That is problematic. The ABORT_TMF does need IO for which we need
> > to wait. And if we just submit and pretend the abort worked, the tag
> > will be reused.
> >
On Thu, 2015-12-03 at 13:36 -0500, Alan Stern wrote:
> This is an old problem, but it was never resolved and it still affects
> people (Bugzilla #89511). In short, there are USB-(S)ATA bridges that
> claim to be write-back but don't support the SYNCHRONIZE CACHE
> command.
> This causes errors w
On Tue, 2014-12-16 at 14:14 +0800, Charles Chiou wrote:
> From f9d84df080c16097218092630db9b5df31d487b5 Mon Sep 17 00:00:00 2001
> From: Charles Chiou
> Date: Fri, 7 Nov 2014 10:15:18 +0800
> Subject: [PATCH 4/4] scsi:stex.c Add S3/S4 support
>
> Add S3/S4 support, add .suspend and .resume funct
On Mon, 2014-12-15 at 11:12 +0800, Charles Chiou wrote:
>
> On 12/10/2014 05:02 PM, Oliver Neukum wrote:
> > On Wed, 2014-12-10 at 09:38 +0800, Charles Chiou wrote:
> >> From 91868d4afe10533b8a4496075109e411100217bb Mon Sep 17 00:00:00 2001
> >> From: Charles Chi
On Wed, 2014-12-10 at 09:38 +0800, Charles Chiou wrote:
> From 91868d4afe10533b8a4496075109e411100217bb Mon Sep 17 00:00:00 2001
> From: Charles Chiou
> Date: Fri, 7 Nov 2014 10:15:18 +0800
> Subject: [PATCH 4/4] scsi:stex.c Add S3/S4 support
>
> Add S3/S4 support, add .suspend and .resume funct
On Sun, 2014-09-14 at 11:34 +0100, James Bottomley wrote:
> I'm agnostic on that. I was just combatting the impression that you had
> to be careful about side effects in known macro statements.
No you haven't. But it is very good practice to not have side effects
in warnings, as people, not comp
On Mon, 2014-09-15 at 08:42 +, David Laight wrote:
> From: Alan Stern
>
> > You must not add an aditional value for a module parameter without
> > documenting it in Documentation/kernel-parameters.txt.
>
> How can this work as a 'module parameter'?
It cannot. This parameter is an aid to deb
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> uas_log_cmd_state(cmnd, __func__);
> - /* all urbs are killed, clear inflight bits */
> - cmdinfo->state &= ~(COMMAND_INFLIGHT |
> - DATA_IN_URB_INFLIGHT |
> -
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> I've access to a number of different uas devices now, and none of them use
> old style sense urbs. The only case where these code-paths trigger is with
> the asm1051 and there they do the wrong thing, as the asm1051 sends 8 bytes
> status iu
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> Check for both type of cancellation codes for sense and data urbs.
Then you should also check for -ESHUTDOWN (unplug of HC)
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" i
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> - Make sure we always hold the lock when setting / checking resetting
> - Check resetting before checking urb->status
> - Add missing check for resetting to uas_data_cmplt
> - Add missing check for resetting to uas_do_work
Why is the checki
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> This commit removes the abort / lun-reset error handling paths, and also the
> taks-mgmt code since those are the only 2 task-mgmt users. Leaving only the
> (tested and testable) usb-device-reset error handling path in place.
>
> Note I re
On Wed, 2014-09-10 at 14:00 +0200, Hans de Goede wrote:
> Hi,
>
> On 09/10/2014 01:56 PM, Oliver Neukum wrote:
> > On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> Note this series is NOT intended for stable, but I accidentally
On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote:
> Hi,
>
> Note this series is NOT intended for stable, but I accidentally
> had "cc = sta...@vger.kernel.org" in my .git/config when sending
> this series, please ignore for stable.
>
> NACK for stable.
If this is not for stable, what do yo
On Tue, 2014-08-26 at 10:47 -0400, Alan Stern wrote:
> On Mon, 25 Aug 2014, Oliver Neukum wrote:
> > Just set US_FL_NEEDS_CAP16. If READ CAPACITY(16) fails in that case,
> > it is clear that something is wrong. It must be set or READ CAPACITY(10)
> > alone would be taken as
On Tue, 2014-08-26 at 09:58 +, David Laight wrote:
> > Part of the problem is that usb-storage has no way to know that
> > anything strange is going on. It's normal for READ CAPACITY(16) to
> > fail (this depend on the SCSI level), and it's normal for the READ
> > CAPACITY(10) to report a valu
On Mon, 2014-08-25 at 16:21 -0400, Alan Stern wrote:
> On Mon, 25 Aug 2014, Alfredo Dal Ava Junior wrote:
>
> > Well, it is causing problems anyway... from user perspective, it's a
> > Linux compatibility issue, as it works "fine" on Windows. I'm not an
> > expert, but I'm wondering that if usb-st
On Mon, 2014-08-25 at 10:58 +, Alfredo Dal Ava Junior wrote:
> - 1TB and 2TB: READ_CAPACITY_10 returns correct size value
> - 3TB and 4TB: READ_CAPACITY_10 returns size in a 2TB modulus
>
> If we fix capacity size by reporting (READ_CAPACITY_10 + MODULO_2TB), the
> result
> will be invalid
On Sun, 2014-05-18 at 21:50 +0200, Guennadi Liakhovetski wrote:
> On Sun, 18 May 2014, Rickard Strandqvist wrote:
>
> > There is otherwise a risk of a possible null pointer dereference.
> >
> > Was largely found by using a static code analysis program called cppcheck.
> >
> > Signed-off-by: Rick
On Thu, 2014-01-16 at 11:59 -0500, Alan Stern wrote:
> Since the START-STOP and TEST UNIT READY (or REQUEST SENSE or
> whatever)
> commands are likely to take a long time, they should all be carried
> out
> asynchronously with respect to the resume procedure. I don't know
> what
> the best way i
On Fri, 2013-11-15 at 17:53 -0200, Geyslan Gregório Bem wrote:
Hi,
> Hi guys,
>
> In the function msgin_qtag() [line 2632], this dereference was intentional?
>
> static struct ScsiReqBlk *msgin_qtag(struct AdapterCtlBlk *acb,
> struct DeviceCtlBlk *dcb, u8 tag)
> {
> struct ScsiReqB
On Thu, 2013-09-12 at 07:47 +0200, Hannes Reinecke wrote:
> On 09/11/2013 04:14 PM, Alan Stern wrote:
> > On Tue, 10 Sep 2013, Oliver Neukum wrote:
> >> I think we can be sure that no drive enclosure will crash
> >> with READ_CAPACITY_16.
> >
> > I wouldn
On Fri, 2013-09-13 at 06:37 -0700, Andy Lutomirski wrote:
> What's the status of this? Do I still need to test it?
>
> I won't have access to the Nook that triggered it the first time for a
> couple weeks, but I could try to find another device like that.
It works for me.
I'll push upstream in a
On Wed, 2013-09-11 at 10:14 -0400, Alan Stern wrote:
> There are three possibilities: nothing, your proposed patch, and a new
Nothing is feasible only if Windows uses READ_CAPACITY_10.
> quirk flag. The flag is safest, but also the hardest to maintain.
Again the same answer.
> > I think we ca
On Tue, 2013-09-10 at 13:25 -0400, Alan Stern wrote:
> On Tue, 10 Sep 2013, Oliver Neukum wrote:
>
> > Hi Hannes,
> >
> > you objected to this patch saying there's a possibilty that
> > HS devices may also need this feature, which would require
> >
Hi Hannes,
you objected to this patch saying there's a possibilty that
HS devices may also need this feature, which would require
a quirk. Does this mean that the patch is acceptable only
with an additional predefined quirk, or do you insist that all
devices be handled with quirks?
Regard
On Mon, 2013-09-02 at 13:25 +0200, Gerd Hoffmann wrote:
> +static void uas_zap_dead(struct uas_dev_info *devinfo)
> +{
> + struct uas_cmd_info *cmdinfo;
> + struct uas_cmd_info *temp;
> + struct list_head list;
> + unsigned long flags;
> +
> + spin_lock_irq(&uas_lists_
On Fri, 2013-08-23 at 14:43 -0700, Brandt, Todd E wrote:
> This is v3 of the non-blocking S3 resume patch. It's been broken into
> two pieces, this part is for the scsi subsystem. I've addressed Alan
> Stern's comments in particular by reformatting the call to conform
> to the proper style guideli
On Fri, 2013-08-09 at 01:09 +, Brandt, Todd E wrote:
> static struct ata_force_ent *ata_force_tbl;
> static int ata_force_tbl_size;
> +int ata_resume_status;
A single global variable for multiple ports?
> static char ata_force_param_buf[PAGE_SIZE] __initdata;
> /* param_buf is thrown aw
On Wed, 2013-08-07 at 15:58 +0900, Jingoo Han wrote:
> On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
> > On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
> >
> > > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType
> > &g
On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
> @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType *eeprom,
> unsigned long io_port)
>*/
> dprintkl(KERN_WARNING,
> "EEProm checksum error: using default values and
> options
On Fri, 2013-08-02 at 16:41 +, Brandt, Todd E wrote:
> Do you mean in terms of debug after a failure? I can resubmit the patch with
> the scsi_sense_hdr buffer still in place. I just wanted to keep the first
> draft simple to get the concept across.
How are errors reported?
Regards
On Fri, 2013-08-02 at 09:54 -0400, Alan Stern wrote:
> On Fri, 2 Aug 2013, Oliver Neukum wrote:
>
> > On Thu, 2013-08-01 at 11:53 -0400, Alan Stern wrote:
> > > On Thu, 1 Aug 2013, Oliver Neukum wrote:
> > >
> > > > On Wed, 2013-07-31 at 11:13 -0400,
On Thu, 2013-08-01 at 23:40 +, Brandt, Todd E wrote:
> This patch is a potential way to reduce the S3 resume time for SATA drives.
> Essentially this patch removes the hard disk resume time from the total
> system resume time, with the disks still taking as long to come back online
> but in
On Thu, 2013-08-01 at 11:53 -0400, Alan Stern wrote:
> On Thu, 1 Aug 2013, Oliver Neukum wrote:
>
> > On Wed, 2013-07-31 at 11:13 -0400, Alan Stern wrote:
> >
> > > More importantly, if we already know that the medium is not present or
> > > has been changed
liver
>From 8c90d860652aa99e6e60d9b32bc3aa8d4db9efa5 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Thu, 1 Aug 2013 10:08:20 +0200
Subject: [PATCH] sd: error handling during flushing caches
It makes no sense to flush the cache of a device without medium.
Errors during suspend must be handled a
On Mon, 2013-07-29 at 10:21 -0400, Alan Stern wrote:
> On Mon, 29 Jul 2013, Oliver Neukum wrote:
>
> > On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
> >
> > > In addition to my earlier comment, the patch below should be applied.
> > > It will fix you
On Tue, 2013-07-30 at 13:00 -0400, Alan Stern wrote:
> That's why I said the patch would fix the immediate problem but it
> wasn't the best solution. You do agree that the patch is correct, as
> far as it goes?
It will allow the system to sleep. But it seems to me that
a genuine error while flus
On Mon, 2013-07-29 at 10:21 -0400, Alan Stern wrote:
> On Mon, 29 Jul 2013, Oliver Neukum wrote:
>
> > On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
> >
> > > In addition to my earlier comment, the patch below should be applied.
> > > It will fix you
On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
> In addition to my earlier comment, the patch below should be applied.
> It will fix your immediate problem, although not in the best way.
Alan,
I think your diagnosis is correct, but not the fix.
This is run even in the runtime case. We mi
On Fri, 2013-07-26 at 09:54 -0700, Andy Lutomirski wrote:
> This is kernel 3.9.9-302.fc19.x86_64.
>
> I plugged in a BN Nook (a usb mass storage device), used it, and
> ejected it. This makes suspend fail:
>
> [50135.265514] PM: Entering freeze sleep
> [50135.265517] Suspending console(s) (use n
On Monday 11 February 2013 22:03:18 Dan Carpenter wrote:
> This bug was introduced back in bitkeeper days in 2003. We use
> "dcb->dev_mode" before it has been initialized.
>
> Signed-off-by: Dan Carpenter
Acked-by: Oliver Neukum
--
To unsubscribe from this list: s
On Tuesday 22 January 2013 11:05:35 James Bottomley wrote:
> > May 3 18:19:06 relampago3 kernel: [ 3948.472796] sd 7:0:0:0: [sdf]
> > 1565565872 512-byte logical blocks: (801 GB/746 GiB)
>
> This looks like a wrap around of your actual size. This appears to
> indicate the device isn't replying c
On Tuesday 22 January 2013 10:25:31 Aaron Lu wrote:
> On Mon, Jan 21, 2013 at 03:56:43PM +0100, Oliver Neukum wrote:
> > On Monday 21 January 2013 17:11:04 Aaron Lu wrote:
> > > It is not easy for the OS to tell if the drive is being used or not
> > > sometimes
> &
On Monday 21 January 2013 17:11:04 Aaron Lu wrote:
> It is not easy for the OS to tell if the drive is being used or not
> sometimes
>
> Alan has reminded me it is possible for an app to open the block device
> file(/dev/sr0), issue a command(play audio), then close the device file.
> From the OS
On Sunday 06 January 2013 16:41:37 Aaron Lu wrote:
> From: Lin Ming
>
> Uses block layer runtime pm helper functions in
> scsi_runtime_suspend/resume.
> Remove scsi_autopm_* from sd open/release path and check_events path.
> And remove the quiesce call in runtime suspend path, as we know there is
On Tuesday 25 September 2012 16:01:35 Aaron Lu wrote:
> On Mon, Sep 24, 2012 at 11:40:18PM +0200, Rafael J. Wysocki wrote:
> > On Monday, September 24, 2012, Aaron Lu wrote:
> > > On Mon, Sep 24, 2012 at 02:55:31PM +0200, Rafael J. Wysocki wrote:
> I just checked the spec again and tested, when th
On Tuesday 25 September 2012 22:46:06 Aaron Lu wrote:
> On 09/25/2012 10:23 PM, Oliver Neukum wrote:
> >> BTW, if sr_suspend should be generic, that would suggest I shouldn't
> >> write any ZPODD related code there, right? Any suggestion where these
> >> c
On Tuesday 25 September 2012 22:20:21 Aaron Lu wrote:
> On Tue, Sep 25, 2012 at 01:47:52PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, September 25, 2012, Aaron Lu wrote:
> > > I'm thinking of enabling this GPE in sr_suspend once we decided that it
> > > is ready to be powered off, so the time
On Friday 21 September 2012 23:18:27 Rafael J. Wysocki wrote:
> Now, James says he doesn't like the way ready_to_power_off is used. Sure
> enough, it is totally irrelevant to the majority of SCSI devices. It actually
> is totally irrelevant to everything in the SCSI subsystem except for the sr
>
On Wednesday 19 September 2012 13:27:47 James Bottomley wrote:
> On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
> > Hi James,
> >
> > May I know if this patchset will enter v3.7?
>
> Sigh, well, I was hoping to persuade the PM people to sort this out
> first.
>
> The first observation is tha
On Tuesday 18 September 2012 15:00:28 Aaron Lu wrote:
> When scsi device received stop command, it will take care of its
> internal cache before enters stopped power condition. This command is
> translated to standby immediate in libata-scsi, but standby doesn't
> imply flush cache for ATA device,
On Thursday 13 September 2012 12:24:46 Alan Stern wrote:
> On Thu, 13 Sep 2012, Oliver Neukum wrote:
> > Yes, but this confusion is necessary. The driver core is supposed to
> > be generic and knows strictly speaking only suspended and active.
> > It is a driver's job t
On Thursday 13 September 2012 11:51:07 James Bottomley wrote:
> On Thu, 2012-09-13 at 12:16 +0200, Oliver Neukum wrote:
> > On Thursday 13 September 2012 10:26:44 James Bottomley wrote:
> > > On Thu, 2012-09-13 at 17:07 +0800, Aaron Lu wrote:
> >
> > > > So I t
On Thursday 13 September 2012 10:26:44 James Bottomley wrote:
> On Thu, 2012-09-13 at 17:07 +0800, Aaron Lu wrote:
> > So I think this is basically 2 things, one is the runtime suspend of the
> > disk, another is when it is runtime suspended, how to remove its power.
> > I'm currently doing the la
On Tuesday 11 September 2012 20:31:17 Aaron Lu wrote:
> OK, I think I got your meaning.
>
> For a simpler scenario:
> 1 User application did an ioctl to lock the door of the ODD when there
> is no medium inside(but why? :-);
> 2 The ODD is runtime suspended;
> 3 The ODD is runtime powered off;
> 4
On Tuesday 11 September 2012 19:11:08 Aaron Lu wrote:
> On Tue, Sep 11, 2012 at 11:30:35AM +0200, Oliver Neukum wrote:
> > On Tuesday 11 September 2012 17:24:13 Aaron Lu wrote:
> > Yes, but because the whole system had been suspended.
> > In that case you can have a locked
On Tuesday 11 September 2012 17:24:13 Aaron Lu wrote:
> On Tue, Sep 11, 2012 at 10:55:44AM +0200, Oliver Neukum wrote:
> > On Tuesday 11 September 2012 14:44:30 Aaron Lu wrote:
> > > On Mon, Sep 10, 2012 at 12:45:51PM +0200, Oliver Neukum wrote:
> > > > On Monday 10
On Tuesday 11 September 2012 14:44:30 Aaron Lu wrote:
> On Mon, Sep 10, 2012 at 12:45:51PM +0200, Oliver Neukum wrote:
> > On Monday 10 September 2012 17:16:22 Aaron Lu wrote:
> >
> > > +static int sr_resume(struct device *dev)
> > > +{
> > > + struct
On Monday 10 September 2012 17:16:22 Aaron Lu wrote:
> +static int sr_resume(struct device *dev)
> +{
> + struct scsi_cd *cd;
> + struct scsi_sense_hdr sshdr;
> +
> + cd = dev_get_drvdata(dev);
> +
> + if (!cd->device->powered_off)
> + return 0;
> +
> + /* get the d
On Thursday 06 September 2012 13:08:18 Alan Stern wrote:
> On Thu, 6 Sep 2012, Oliver Neukum wrote:
>
> > On Thursday 06 September 2012 11:06:49 Alan Stern wrote:
> > > On Thu, 6 Sep 2012, Aaron Lu wrote:
> > >
> > > > > That's why we ha
On Thursday 06 September 2012 11:06:49 Alan Stern wrote:
> On Thu, 6 Sep 2012, Aaron Lu wrote:
>
> > > That's why we have an autosuspend delay. Although for some reason the
> > > SCSI subsystem doesn't use it currently... We need to add a call to
> > > pm_runtime_use_autosuspend() in scsi_sysf
On Wednesday 05 September 2012 23:22:55 Aaron Lu wrote:
> On Tue, Sep 04, 2012 at 08:47:15PM +0200, Oliver Neukum wrote:
> > On Tuesday 04 September 2012 13:59:38 Alan Stern wrote:
> > > What requirement are you talking about? The "no media and door closed"
> >
On Tuesday 04 September 2012 13:59:38 Alan Stern wrote:
> On Tue, 4 Sep 2012, Oliver Neukum wrote:
>
> > On Tuesday 04 September 2012 22:24:34 Aaron Lu wrote:
> > > From: Aaron Lu
> > >
> > > The ODD will be placed into suspend state when:
> > &g
On Tuesday 04 September 2012 22:24:38 Aaron Lu wrote:
> From: Aaron Lu
>
> Add a new flag may_power_off for scsi device, it gives the user a chance
> to control when the device is runtime suspended, can we remove its power
> if possible.
>
> And if the device can be powered off(reflected by can_
On Tuesday 04 September 2012 22:24:34 Aaron Lu wrote:
> From: Aaron Lu
>
> The ODD will be placed into suspend state when:
> 1 For tray type ODD, no media inside and door closed;
> 2 For slot type ODD, no media inside;
> And together with ACPI, when we suspend the ODD's parent(the port it
> attac
In scsi_test_unit_ready() a local sense may fail to allocate. In
this case the buffer must not be used even if an IO error happens.
Signed-off-by: Oliver Neukum
CC: sta...@kernel.org
---
drivers/scsi/scsi_lib.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
1 - 100 of 190 matches
Mail list logo
