All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	Sathya Prakash <Sathya.Prakash@broadcom.com>,
	linux-pci@vger.kernel.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Keith Busch <keith.busch@intel.com>
Subject: Re: [Patch v1 0/7] mpt3sas: Hot-Plug Surprise removal support on IOC.
Date: Wed, 5 Sep 2018 09:38:16 +0200	[thread overview]
Message-ID: <20180905073816.jcrct2xcpucb6bkn@wunner.de> (raw)
In-Reply-To: <CAK=zhgprkzcF-UZeeqg_qN0xFLR=BfzkRNRZKA=DJyf7aMPmeg@mail.gmail.com>

On Wed, Sep 05, 2018 at 11:45:45AM +0530, Sreekanth Reddy wrote:
> On Tue, Sep 4, 2018 at 3:12 PM, Lukas Wunner <lukas@wunner.de> wrote:
> > Many scsi drivers call pci_channel_offline() to detect inaccessibility
> > of the device due to a PCI error:
> > https://elixir.bootlin.com/linux/v4.19-rc2/ident/pci_channel_offline
> >
> > A patch is pending such that surprise removal can also be queried
> > with that same function:
> > https://www.spinics.net/lists/linux-pci/msg75722.html
> 
> Lukas, thanks for pointing to this pci_dev_is_disconnected() API. So
> we can use this API directly instead of reading the vendor Id and
> checking for all one's once this patch get accepted?

Yes, except pci_dev_is_disconnected() is private to the PCI core,
but dev->error_state and pci_channel_offline() is public.


> I have one more instance where still we need this poll kthread, i.e
> during the device probe time we have some commands which has more
> timeout value (e.g. 300 seconds), so if user has unplugged this device
> just after sending this more time-out valued command then driver has
> to wait until this time-out value expires. i.e. this device is still
> visible in lspci output until this 300 seconds timeout value expires
> even though device is unplugged. if we have a poll kthread (which will
> poll for every one second) then driver can early detect the unplugged
> state and can terminate the outstanding commands and hence probe
> operation can be completed quickly.

The only instances I can see in your driver where it waits for 300 s
is in _base_diag_reset(), which does an msleep(256) in a loop for up
to 300 s, and scsih_scan_finished(), which is called in a loop with an
msleep(10) by do_scsi_scan_host().

Any harm in simply checking for removal of the device in those loops
and bailing out if so?  Instead of the poll kthread to achieve the same?


> Also whether we need to wait for below patches get accepted? so that
> we can post the new set of patches accommodating according to your
> suggestions,
> https://www.spinics.net/lists/linux-pci/msg75722.html
> https://www.spinics.net/lists/linux-pci/msg75438.html

I can't tell you whether and when those patches get accepted, that's
for Bjorn Helgaas to decide.  Also, what does get accepted might differ.
E.g. the first patch uses the existing pci_channel_io_perm_failure
state for removal.  There was debate whether to introduce a new state
for removed devices to avoid overloading the existing state, which is
used for error recovery.

All I can recommend is to follow linux-pci, test the patches that have
already been brought forward to ascertain they fulfil your needs,
and generally participate in the debate so that your use cases are
covered.

Thanks,

Lukas

  reply	other threads:[~2018-09-05 12:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1535690081-16116-1-git-send-email-suganath-prabu.subramani@broadcom.com>
     [not found] ` <CAHp75VfC8GN3oEzSFJYfMr0iqBTYUJ=WPoLS9Oh5NgVcFmnBkw@mail.gmail.com>
2018-08-31  8:55   ` [Patch v1 0/7] mpt3sas: Hot-Plug Surprise removal support on IOC Lukas Wunner
2018-09-04  5:49     ` Sreekanth Reddy
2018-09-04  9:42       ` Lukas Wunner
2018-09-05  6:15         ` Sreekanth Reddy
2018-09-05  7:38           ` Lukas Wunner [this message]
2018-09-05 14:17             ` Keith Busch
2018-09-12 10:01             ` Sreekanth Reddy
2018-09-13 10:10               ` Lukas Wunner

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=20180905073816.jcrct2xcpucb6bkn@wunner.de \
    --to=lukas@wunner.de \
    --cc=Sathya.Prakash@broadcom.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=keith.busch@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sreekanth.reddy@broadcom.com \
    --cc=suganath-prabu.subramani@broadcom.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.