All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Pylypiv <ipylypiv@google.com>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH v2] scsi: core: Disable CDL by default
Date: Fri, 7 Jun 2024 16:16:33 +0000	[thread overview]
Message-ID: <ZmMyYb8Up9-p1lUs@google.com> (raw)
In-Reply-To: <20240607012507.111488-1-dlemoal@kernel.org>

On Fri, Jun 07, 2024 at 10:25:07AM +0900, Damien Le Moal wrote:
> For scsi devices supporting the Command Duration Limits feature set, the
> user can enable/disable this feature use through the sysfs device
> attribute cdl_enable. This attribute modification triggers a call to
> scsi_cdl_enable() to enable and disable the feature for ATA devices and
> set the scsi device cdl_enable field to the user provided bool value.
> For SCSI devices supporting CDL, the feature set is always enabled and
> scsi_cdl_enable() is reduced to setting the cdl_enable field.
> 
> However, for ATA devices, a drive may spin-up with the CDL feature
> enabled by default. But the scsi device cdl_enable field is always
> initialized to false (CDL disabled), regardless of the actual device
> CDL feature state. For ATA devices managed by libata (or libsas),
> libata-core always disables the CDL feature set when the device is
> attached, thus syncing the state of the CDL feature on the device and of
> the scsi device cdl_enable field. However, for ATA devices connected to
> a SAS HBA, the CDL feature is not disabled on scan for ATA devices that
> have this feature enabled by default, leading to an inconsistent state
> of the feature on the device with the scsi device cdl_enable field.
> 
> Avoid this inconsistency by adding a call to scsi_cdl_enable() in
> scsi_cdl_check() to make sure that the device-side state of the CDL
> feature set always matches the scsi device cdl_enable field state.
> This implies that CDL will always be disabled for ATA devices connected
> to SAS HBAs, which is consistent with libata/libsas initialization of
> the device.
> 
> Reported-by: Scott McCoy <scott.mccoy@wdc.com>
> Fixes: 1b22cfb14142 ("scsi: core: Allow enabling and disabling command duration limits")
> Cc: stable@vger.kernel.org
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---

Reviewed-by: Igor Pylypiv <ipylypiv@google.com>

Thank you!

  parent reply	other threads:[~2024-06-07 16:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07  1:25 [PATCH v2] scsi: core: Disable CDL by default Damien Le Moal
2024-06-07  8:00 ` Niklas Cassel
2024-06-07 16:16 ` Igor Pylypiv [this message]
2024-06-11  6:27 ` Hannes Reinecke
2024-06-12  1:57 ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZmMyYb8Up9-p1lUs@google.com \
    --to=ipylypiv@google.com \
    --cc=dlemoal@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.