public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Asai Thambi S P <asamymuthupa@micron.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Jens Axboe <axboe@kernel.dk>, Sam Bradshaw <sbradshaw@micron.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] block: mtip32xx: remove HOTPLUG_PCI_PCIE dependancy
Date: Wed, 11 Apr 2012 15:22:56 -0700	[thread overview]
Message-ID: <4F860440.60808@micron.com> (raw)
In-Reply-To: <20120411204041.GA14375@kroah.com>

On 4/11/2012 1:40 PM, Greg KH wrote:

> On Wed, Apr 11, 2012 at 01:33:39PM -0700, Asai Thambi S P wrote:
>> On 4/11/2012 12:57 PM, Jens Axboe wrote:
>>
>>> On 2012-04-11 20:34, Greg KH wrote:
>>>> This removes the HOTPLUG_PCI_PCIE dependency on the driver and makes it
>>>> depend on PCI.
>>>
>>> I think it's an old dependency. I've built and run it here without as
>>> well, and no functional issues either.
>>>
>>> Sam/Asai?
>>>
>>
>>
>> Both driver and device will work fine without PCIe hotplug dependency. This
>> dependency is required for supporting surprise removal and surprise insertion
>> of the device on systems with PCIe hotplug controller.
> 
> But that's not a driver-specific thing at all.  All PCI drivers need to
> be able to handle this (I like how you constantly check the pci id,
> that's cute.)
> 
> So I think a basic dependancy on PCI should be fine here.

The P320 is different from existing PCIe devices supporting surprise removal
and surprise insertion (SRSI) capability (aka hotplug). We equate the hotplug
functionality enabled by PCIe hotplug controllers to that of any other storage
endpoint (SAS, SATA, FC, etc). For those devices, hotplug functionality is
enabled by the transport layer and propagated up to host storage stack for
handling.

There are two types of users for P320 device – 1) those with systems that have
PCIe hotplug controllers and intend to use hotplug and 2) those who do not
need or intend to use hotplug. The HOTPLUG_PCI_PCIE dependency enables users
in the first bucket to use the device’s capability without affecting those in
the second bucket.  While there aren’t many systems today that have PCIe
hotplug controllers, you will begin to see such systems very soon.

The mtip32xx driver depends on remove() being called for graceful handling of
surprise removal events.  Such cleanup is necessary to enable clean surprise
insertion of the same/different device in the same slot. We do check the PCI
id in non-fast path code to detect the surprise removal and fail any
outstanding I/Os with -ENODEV, but the driver still depends on the pci core
with help from the pcie hotplug module to call remove() for cleanup, hence the
HOTPLUG_PCI_PCIE dependency.

--
Regards,
Asai Thambi

  reply	other threads:[~2012-04-11 22:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11 18:34 [PATCH] block: mtip32xx: remove HOTPLUG_PCI_PCIE dependancy Greg KH
2012-04-11 19:57 ` Jens Axboe
2012-04-11 20:33   ` Asai Thambi S P
2012-04-11 20:38     ` Jens Axboe
2012-04-12  0:46       ` Asai Thambi S P
2012-04-12  7:38         ` Jens Axboe
2012-04-11 20:40     ` Greg KH
2012-04-11 22:22       ` Asai Thambi S P [this message]
2012-04-11 22:37         ` Greg KH
2012-04-12  0:32           ` Asai Thambi S P
2012-04-12  0:36             ` Greg KH

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=4F860440.60808@micron.com \
    --to=asamymuthupa@micron.com \
    --cc=axboe@kernel.dk \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sbradshaw@micron.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