All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Douthit <stephend@silicom-usa.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	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: Mon, 19 Aug 2019 16:30:41 +0000	[thread overview]
Message-ID: <f6399f3a-3899-2663-6667-e967eb43b156@silicom-usa.com> (raw)
In-Reply-To: <CAPcyv4ivzdEKbVepxcyJMmDmb5zG4Zvw+3f0rVJ8FOErK+c27g@mail.gmail.com>

On 8/14/19 1:17 PM, Dan Williams wrote:
>> Can you get someone from the controller design team to give us a clear
>> answer on a revision where this PCS change happened?
>>
>> It would be nice if we could just check PCI_REVISION_ID or something
>> similar.
> 
> I don't think such a reliable association with rev-id exists, the> intent was that the OS need never consider PCS.

Can you please ask to confirm?  It would be a much simpler check if it
is possible.

> The way Linux is using
> it is already broken with the assumption that it is performed after
> every HOST_CTL based reset which only resets mmio space. At most it
> should only be required at initial PCI discovery iff platform firmware
> failed to run.

This is a separate issue.

It's broken in the sense that the code is called more often that it
needs to be, but reset isn't a hot path, and there are no side effects
to doing this multiple times that I can see.  And as you point out, no
bug reports, so pretty benign all things considered.

We could move the PCS quirk code to ahci_init_one() to address this
concern once there's agreement on what the criteria is to run/not-run
this code.

> There are no bug reports with the current
> implementation that only attempts to enable bits based on PORTS_IMPL,
> so I think we are firmer ground trying to draw a line where the driver
> just stops worrying about PCS rather than try to detect the layout.

Someone at Intel is going to need to decide where/how to draw this line.

  reply	other threads:[~2019-08-19 16:30 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
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 [this message]
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=f6399f3a-3899-2663-6667-e967eb43b156@silicom-usa.com \
    --to=stephend@silicom-usa.com \
    --cc=axboe@kernel.dk \
    --cc=dan.j.williams@intel.com \
    --cc=hch@infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.