linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Stephen Douthit <stephend@silicom-usa.com>,
	Jens Axboe <axboe@kernel.dk>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ata: ahci: Lookup PCS register offset based on PCI device ID
Date: Tue, 13 Aug 2019 00:29:54 -0700	[thread overview]
Message-ID: <20190813072954.GA23417@infradead.org> (raw)
In-Reply-To: <CAA9_cme3saBAJEyob3B1tX=t8keTodWJZMUd1j_v7vPMRU+aXA@mail.gmail.com>

On Mon, Aug 12, 2019 at 12:31:35PM -0700, Dan Williams wrote:
> It seems platforms / controllers that fail to run the option-rom
> should be quirked by device-id, but the PCS register twiddling be
> removed for everyone else. "Card BIOS" to me implies devices with an
> Option-ROM BAR which I don't think modern devices have, so that might
> be a simple way to try to phase out this quirk going forward without
> regressing working setups that might be relying on this.
> 
> Then again the driver is already depending on the number of enabled
> ports to be reliable before PCS is written, and the current driver
> does not attempt to enable ports that were not enabled previously.
> That tells me that if the PCS quirk ever mattered it would have
> already regressed when the driver switched from blindly writing 0xf to
> only setting the bits that were already set in ->port_map.

But how do we find that out?

A compromise to me seems that we just do the PCS quirk for all Intel
devices explicitly listed in the PCI Ids based on new board_* values
as long as they have the old PCS location, and assume anything new
enough to have the new location won't need to quirk, given that it
never properly worked.  This might miss some intel devices that were
supported with the class based catchall, though.

  reply	other threads:[~2019-08-13  7:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-08 20:24 [PATCH] ata: ahci: Lookup PCS register offset based on PCI device ID Stephen Douthit
2019-08-09  3:46 ` Jens Axboe
2019-08-09 14:13   ` Stephen Douthit
2019-08-09 14:16     ` Jens Axboe
2019-08-10  7:43 ` Christoph Hellwig
2019-08-10 20:22   ` Dan Williams
2019-08-12 13:02   ` Stephen Douthit
2019-08-12 14:11     ` Jens Axboe
2019-08-12 16:29     ` Dan Williams
2019-08-12 17:49       ` Stephen Douthit
2019-08-12 18:06         ` Christoph Hellwig
2019-08-12 19:12           ` Stephen Douthit
2019-08-12 19:31           ` Dan Williams
2019-08-13  7:29             ` Christoph Hellwig [this message]
2019-08-13 22:07               ` Dan Williams
2019-08-14 14:34                 ` Stephen Douthit
2019-08-14 16:09                   ` Dan Williams
2019-08-14 16:54                     ` Stephen Douthit
2019-08-14 17:17                       ` Dan Williams
2019-08-19 16:30                         ` Stephen Douthit
2019-08-20  2:17                           ` Dan Williams
2019-08-20 13:59                             ` Stephen Douthit

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=20190813072954.GA23417@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=dan.j.williams@intel.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stephend@silicom-usa.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).