In IBM Power servers, when hardware error occurs during probe
state, EEH subsystem will call driver's error_detected interface,
which will call pci_disable_device(). But driver's probe function also
call pci_disable_device() in this situation.
So pci_dev will be disabled twice:
Device lpfc disabl
From: Anish Bhatt
Date: Tue, 15 Jul 2014 19:55:52 -0700
> +#define pr_info_ipaddr(fmt_trail,\
> + addr1, addr2, args_trail...)\
Barf... use "%pIS" instead, which takes a pointer to a sockaddr of family
AF_INET or AF_INET
This patch removes the null test on lun_cg. lun_cg is initialized
at the beginning of the function to &lun->lun_group. Since lun_cg is
dereferenced prior to the null test, it must be a valid pointer.
The following Coccinelle script is used for detecting the change:
@r@
expression e,f;
identifier
> "James" == James Bottomley writes:
James> Well, your judgement: is this situation (support for UNMAP but
James> not for WRITE_SAME) in what is effectively a RAID driver (hv
James> drivers count as RAID) just a silly Microsoft one off?
I only recall seeing one or two devices that supported
On Wed, 2014-07-16 at 15:08 -0400, Martin K. Petersen wrote:
> > "James" == James Bottomley writes:
>
> James> It's the code we identified in sd.c:read_capacity_16():
>
> That's there to support devices that implement thin provisioning but
> which predate the LBP VPD page. And thus have no w
> "Rob" == Elliott, Robert (Server Storage) writes:
Rob> WRITE SAME with the UNMAP bit set to one (and a few other
Rob> conditions) guarantees that the data is zeroed out, while the UNMAP
Rob> command is just a hint. They're not fully interchangeable. Which
Rob> semantics are implied by REQ
> "James" == James Bottomley writes:
James> It's the code we identified in sd.c:read_capacity_16():
That's there to support devices that implement thin provisioning but
which predate the LBP VPD page. And thus have no way to tell us their
preferred command variant.
James> If the inquiry sho
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
Signed-off-by: Alexander Gordeev
Cc: Anil Gurumurthy
Cc: Vijaya Mohan Guvva
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Anil Gurumurthy
---
drivers/scsi/bfa/bfad.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Cc:
On Wed, 2014-07-16 at 14:45 -0400, Martin K. Petersen wrote:
> > "James" == James Bottomley writes:
>
> >> I don't have a problem with a BLIST_PREFER_UNMAP flag or something
> >> like that. But BLIST_TRY_VPD_PAGES seems more generally useful and it
> >> does fix the problem at hand. That's wh
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
Currently the driver falls back to INTx mode when MSI-X
initialization failed. This is a suboptimal behaviour
for chips that also support MSI. This update changes that
behaviour and falls back to MSI mode in case MSI-X mode
initialization failed.
Signed-off-by: Alexander Gordeev
Cc: "Stephen M. C
There is no need to call pci_disable_msix() in case
the previous call to pci_enable_msix() failed
Signed-off-by: Alexander Gordeev
Cc: Naresh Kumar Inna
Cc: Arvind Bhushan
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/csiostor/csio_isr.c |4 +---
1 files cha
> "James" == James Bottomley writes:
>> I don't have a problem with a BLIST_PREFER_UNMAP flag or something
>> like that. But BLIST_TRY_VPD_PAGES seems more generally useful and it
>> does fix the problem at hand. That's why I went that route.
James> Hang on ... unless we apply Christoph or m
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of James Bottomley
> Sent: Wednesday, 16 July, 2014 1:02 PM
> To: martin.peter...@oracle.com
> Cc: linux-ker...@vger.kernel.org; h...@infradead.org;
> de...@linuxdriverproj
Hi Alexander,
This looks fine to me.
Acked-by: Arvind Kumar
Thanks!
Arvind
From: Alexander Gordeev
Sent: Wednesday, July 16, 2014 11:05 AM
To: linux-ker...@vger.kernel.org
Cc: Alexander Gordeev; Arvind Kumar; pv-driv...@vmware.com;
linux-scsi@vger.kern
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
When a call to request_irq() failed pm8001_setup_msix()
still returns the success. This udate fixes the described
misbehaviour.
Signed-off-by: Alexander Gordeev
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Jack Wang
---
dr
Function pci_enable_msix() should not be called in case
it threw a negative errno from a previous call.
Signed-off-by: Alexander Gordeev
Cc: Anil Gurumurthy
Cc: Vijaya Mohan Guvva
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Anil Gurumurthy
---
drivers/scsi/bfa/bfad.
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
Hello,
This is a series of mostly trivial patches. Once accepted,
we could phase out pci_enable_msix() interface.
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_en
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
There is no need to call pci_disable_msix() in case
the previous call to pci_enable_msix() failed
Signed-off-by: Alexander Gordeev
Cc: James Smart
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: James Smart
---
drivers/scsi/lpfc/lpfc_init.c |9 ++---
1 files chan
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
Signed-off-by: Alexander Gordeev
Cc: Anil Ravindranath
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/pmcraid.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index be8ce54..c06af7f 100644
--
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Log
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Sign
On Wed, 2014-07-16 at 13:47 -0400, Martin K. Petersen wrote:
> > "Christoph" == hch@infradead org writes:
>
> Christoph> Oh, we actually have devices that support WRITE SAME with
> Christoph> unmap, but not without? That's defintively a little strange.
>
> Yep :(
>
> There were several SSD
On Wed, Jul 16, 2014 at 01:47:35PM -0400, Martin K. Petersen wrote:
> There were several SSDs that did not want to support wearing out flash
> by writing gobs of zeroes and only support the UNMAP case.
Given that SSDs usually aren't hard provisioned anyway that seems like
an odd decision. But SAS
> "Christoph" == hch@infradead org writes:
Christoph> Oh, we actually have devices that support WRITE SAME with
Christoph> unmap, but not without? That's defintively a little strange.
Yep :(
There were several SSDs that did not want to support wearing out flash
by writing gobs of zeroes an
On Wed, Jul 16, 2014 at 11:44:18AM -0400, Martin K. Petersen wrote:
> There are lots of devices out there that support WRITE SAME(10) or (16)
> without the UNMAP bit. And there are devices that support WRITE SAME w/
> UNMAP functionality but not "regular" WRITE SAME.
Oh, we actually have devices t
On Wed, Jul 16, 2014 at 04:31:29PM +0200, Hannes Reinecke wrote:
> The iBFT table only specifies a prefix length, so we need to
> check the given IP address to figure out whether the netmask
> should be printed in IPv4 or IPv6 style.
Ccing netdev - maybe someone over there might be able to think o
> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Wednesday, July 16, 2014 10:29 AM
> To: KY Srinivasan
> Cc: Hannes Reinecke; jasow...@redhat.com; a...@canonical.com; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com;
> jbott
On Wed, Jul 16, 2014 at 05:26:48PM +, KY Srinivasan wrote:
> Christoph,
>
> Is this patch-set ready to be checked in. Let me know if you want me to make
> any
> further corrections.
Hi Ky,
I've applied it locally, but I'm still waiting on reviews for two
important core fixes before pushing
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Monday, July 14, 2014 1:58 AM
> To: Christoph Hellwig
> Cc: KY Srinivasan; jasow...@redhat.com; a...@canonical.com; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@para
> "Christoph" == Christoph Hellwig writes:
Sreekanth,
I just sent out a patch for the direct I/O type cast issue. Please add
your SoB to that and use it to replace patch 6 when you send out the
final series.
Christoph> Btw, it would be good to resend the series with the various
Christoph> u
A type casting error caused the max volume LBA to be truncated from 64
to 32 bits. The virtual LBA would also get truncated to 32 bits in the
case of a 16-byte READ/WRITE command.
Rewrite entire function to get rid of code duplication and type casts.
Use get/put_unaligned wrappers to extract
> "hch" == hch@infradead org writes:
hch> read_capacity_16 calls sd_config_discard(sdkp, SD_LBP_WS16) if the
hch> LPBME bit is set. At least older SBC drafts left it wide open if a
hch> target supports WRITE SAME with UNMAP or UNMAP in this case.
Correct.
hch> So I think we'd still want a
On Wed, 2014-07-16 at 04:01 -0700, h...@infradead.org wrote:
> On Sun, Jul 13, 2014 at 08:58:34AM -0400, Martin K. Petersen wrote:
> > > "KY" == KY Srinivasan writes:
> >
> > KY> Windows hosts do support UNMAP and set the field in the
> > KY> EVPD. However, since the host advertises SPC-2 com
The iBFT table only specifies a prefix length, so we need to
check the given IP address to figure out whether the netmask
should be printed in IPv4 or IPv6 style.
Cc: Mike Christie
Cc: Peter Jones
Cc: Konrad Rzeszutek Wilk
Signed-off-by: Hannes Reinecke
---
drivers/firmware/iscsi_ibft.c | 35
On Wed, Jul 16, 2014 at 06:13:21AM -0500, Mike Christie wrote:
> I see the request timer is started before calling queue_rq, but I could
> not figure out what the cancel_delayed_work here is for exactly. It
> seems if the request were to time out and the eh started while queue_rq
> was running we c
On 06/25/2014 11:52 AM, Christoph Hellwig wrote:
> +static int scsi_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req)
> +{
> + struct request_queue *q = req->q;
> + struct scsi_device *sdev = q->queuedata;
> + struct Scsi_Host *shost = sdev->host;
> + struct scsi_cmnd *cmd =
On Sun, Jul 13, 2014 at 08:58:34AM -0400, Martin K. Petersen wrote:
> > "KY" == KY Srinivasan writes:
>
> KY> Windows hosts do support UNMAP and set the field in the
> KY> EVPD. However, since the host advertises SPC-2 compliance, Linux
> KY> does not even query the VPD page.
>
> >> If we w
On Wed, Jul 16, 2014 at 08:32:59AM +, Anish Bhatt wrote:
> We don't have any specific changes queued for 3.17, but the next update
> requires a similar change to cxgb4. I'm okay submitting that to net-next if it
> is okay with you.
That sounds fine to me.
--
To unsubscribe from this list: se
We don't have any specific changes queued for 3.17, but the next update
requires a similar change to cxgb4. I'm okay submitting that to net-next if it
is okay with you. Plus one of the patches requires cxgb4 dcb code that is
not yet in the scsi tree.
-Anish
Hi Anish,
the scsi side changes looks fine to me. Unless you have major updates
to the scsi driver for 3.17 that could cause conflicts I'm fine with
merging the whole series in through the networking tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a
On Wed, Jul 16, 2014 at 12:00:22PM +0530, Sreekanth Reddy wrote:
> Next time onwards I will follow as per your suggestions while posting the
> patches to upstream.
Btw, it would be good to resend the series with the various updates from
Martin once he's done with the review. That makes it a lot e
53 matches
Mail list logo
