RE: [PATCH v4 7/8] mmc: block: register RPMB partition with the RPMB subsystem
> 2; > > This looks like it does not support 8KB writes added in v5.1 spec. Can that > be > supported? You are right there is not support for 8K packet, but the change should be simple. I will update the patch. Thanks Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ipr: Clear interrupt on croc/crocodile when running with LSI
If we fall back to using LSI on the Croc or Crocodile chip we need
to clear the interrupt so we don't hang the system.
Cc: stable
Tested-by: Benjamin Herrenschmidt
Signed-off-by: Brian King
---
drivers/scsi/ipr.c |1 +
1 file changed, 1 insertion(+)
diff -puN drivers/scsi/ipr.c~ipr_clear_isr drivers/scsi/ipr.c
--- linux-2.6.git/drivers/scsi/ipr.c~ipr_clear_isr 2016-06-24
17:37:24.265197867 -0500
+++ linux-2.6.git-bjking1/drivers/scsi/ipr.c2016-06-24 17:38:39.640943642
-0500
@@ -10097,6 +10097,7 @@ static int ipr_probe_ioa(struct pci_dev
ioa_cfg->intr_flag = IPR_USE_MSI;
else {
ioa_cfg->intr_flag = IPR_USE_LSI;
+ ioa_cfg->clear_isr = 1;
ioa_cfg->nvectors = 1;
dev_info(&pdev->dev, "Cannot enable MSI.\n");
}
_
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] block: provide helpers for reading block count
On Thu, 23 Jun 2016, Arnd Bergmann wrote: Several drivers use an expensive do_div() to compute the number of logical or physical blocks in a blockdev, which can be done more efficiently using a shift, since the blocksize is always a power of two number. Let's introduce bdev_logical_block_count() and bdev_physical_block_count() helper functions mirroring the bdev_logical_block_size() and bdev_physical_block_size() interfaces for the block size. @@ -1226,6 +1226,13 @@ static inline unsigned short bdev_logical_block_size(struct block_device *bdev) return queue_logical_block_size(bdev_get_queue(bdev)); } +static inline sector_t bdev_logical_block_count(struct block_device *bdev) Curious, why not just return u64 instead for all these instead of sector_t (ie dealing with lba, it reads weird)? Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 1/2] smartpqi: initial commit of Microsemi smartpqi driver
> -Original Message-
> From: Johannes Thumshirn [mailto:jthumsh...@suse.de]
> Sent: Friday, June 17, 2016 4:57 AM
> To: Don Brace
> Cc: j...@linux.vnet.ibm.com; Viswas G; Mahesh Rajashekhara;
> h...@infradead.org; Scott Teel; Kevin Barnett; Justin Lindley; Scott Benesh;
> elli...@hpe.com; linux-scsi@vger.kernel.org
> Subject: Re: [PATCH V3 1/2] smartpqi: initial commit of Microsemi smartpqi
> driver
>
> EXTERNAL EMAIL
>
>
> Hi Don/Kevin,
>
> some comments inline (mostly stulistic nothing architectural)
>
> On Thu, Jun 16, 2016 at 05:48:16PM -0500, Don Brace wrote:
> > From: Kevin Barnett
> >
> > This initial commit contains WIP of Microsemi's smartpqi module.
> >
> > Reviewed-by: Scott Benesh
> > Reviewed-by: Kevin Barnett
>
> if this is From: Kevin it should have his S-o-b as well.
>
> > Signed-off-by: Don Brace
Done
> > ---
>
> [...]
>
> > + */
> > +
> > +#if !defined(_SMARTPQI_H)
> > +#define _SMARTPQI_H
> > +
> > +#pragma pack(1)
>
> I know GCC does understand #pragma pack() to be compatible with MSVC
> but please
> use the kernel's __packed convention on structs you want to have packed.
>
We prefer to leave this "as is" for these reasons:
We do not use __packed on other Microsemi Linux drivers.
There's not consistency in the usage of __packed. Just a quick survey of the
kernel source reveals at least four styles:
Syntax #1:
struct xxx {
.
} __packed;
Syntax #2:
struct __packed xxx {
.
};
Syntax #3:
struct xxx {
.
} __attribute__((__packed__));
Syntax #4:
struct __attribute__((__packed__)) xxx {
.
};
> > +
> > +#define PQI_DEVICE_SIGNATURE "PQI DREG"
>
> [...]
>
> > + pqi_index_t oq_ci_copy;
> > + struct task_struct *task;
> > + u16 int_msg_num;
> > +};
> > +
>
> Just for clarification (sorry haven't looked up the sepecs yet) is this a
> queue pair or more than two queues (looks like 3 to me)?
>
There are 3 queues
> > +struct pqi_queue_group {
> > + struct pqi_ctrl_info *ctrl_info;/* backpointer */
> > + u16 iq_id[2];
> > + u16 oq_id;
>
> [...]
>
> > +#define RAID_CTLR_LUNID "\0\0\0\0\0\0\0\0"
> > +
> > +struct pqi_scsi_dev_t {
>
> For sake of consistency with the other structs "struct pqi_scsi_dev"?
Done
>
> > + int devtype;/* as reported by INQUIRY commmand */
> > + u8 device_type;/* as reported by */
>
> [...]
>
> > +
> > +/* Define the PCI IDs for the controllers that we support. */
> > +static const struct pci_device_id pqi_pci_id_table[] = {
> > + {
> > + .vendor = PCI_VENDOR_ID_ADAPTEC2,
> > + .device = 0x028f,
> > + .subvendor = PCI_VENDOR_ID_ADAPTEC2,
> > + .subdevice = 0x0110,
> > + .class = 0,
> > + .class_mask = 0,
> > + .driver_data = 0
> > + },
> > + {
> > + .vendor = PCI_VENDOR_ID_ADAPTEC2,
> > + .device = 0x028f,
> > + .subvendor = PCI_VENDOR_ID_HP,
> > + .subdevice = 0x0600,
> > + .class = 0,
> > + .class_mask = 0,
> > + .driver_data = 0
> > + },
> > + {
> > + .vendor = PCI_VENDOR_ID_ADAPTEC2,
> > + .device = 0x028f,
> > + .subvendor = PCI_VENDOR_ID_HP,
> > + .subdevice = 0x0601,
> > + .class = 0,
> > + .class_mask = 0,
> > + .driver_data = 0
> > + },
> > + {
> > + .vendor = PCI_VENDOR_ID_ADAPTEC2,
> > + .device = 0x028f,
> > + .subvendor = PCI_VENDOR_ID_HP,
> > + .subdevice = 0x0602,
> > + .class = 0,
> > + .class_mask = 0,
> > + .driver_data = 0
> > + },
> > + {
> > + .vendor = PCI_VENDOR_ID_ADAPTEC2,
> > + .device = 0x028f,
> > + .subvendor = PCI_VENDOR_ID_HP,
> > + .subdevice = 0x0603,
> > + .class = 0,
> > + .class_mask = 0,
> > + .driver_data = 0
> > + },
> > + {
> > + .vendor = PCI_VENDOR_ID_ADAPTEC2,
> > + .device = 0x028f,
> > + .subvendor = PCI_VENDOR_ID_HP,
> > + .subdevice = 0x0650,
> > + .class = 0,
> > + .class_mask = 0,
> > + .driver_data = 0
> > + },
> > + {
> > + .vendor = PCI_VENDOR_ID_ADAPTEC2,
> > + .device = 0x028f,
> > + .subvendor = PCI_VENDOR_ID_HP,
> > + .subdevice = 0x0651,
> > + .class = 0,
> > + .class_mask = 0,
> > + .driver_data = 0
> > + },
> > + {
> > + .vendor = PCI_VENDOR_ID_ADAPTEC2,
> > + .device = 0x028f,
> > + .subvendor = PCI_VENDOR_ID_HP,
> > + .subdevice = 0x0652,
> > + .class = 0,
> > + .class_mask = 0,
> > + .driver_data = 0
> > + },
> > +
[PATCH V4 0/2] smartpqi: initial commit of Microsemi smartpqi driver
This driver is based on Linus's tree This initial commit contains WIP of Microsemi's smartpqi module. - add smartpqi to kernel.org - remove PCI IDs from aacraid driver - Depends on adoption of smartpqi driver Changes since V3 - removed 'devices' and 'PQI info' sysfs attributes according to Hannes's review. - changes suggested by Hannes and Johannes Thumshirn: - removed statistics - fixed issues raised by Johannes Thumshirn - answers to other Johannes Thumshirn's review posted in a separate reply. Changes since V2 - Corrected make ARCH=s390 kbuild test robot issue. - Answers to Hannes's Review posted in a separate reply Changes since V1 - Corrected make ARCH=i386 kbuild test robot issue. Changes since initial upload - Forgot to give correct ownership to the author. --- Don Brace (1): aacraid: remove wildcard for series 9 controllers Kevin Barnett (1): smartpqi: initial commit of Microsemi smartpqi driver MAINTAINERS| 11 drivers/scsi/Kconfig |1 drivers/scsi/Makefile |1 drivers/scsi/aacraid/linit.c |2 drivers/scsi/smartpqi/Kconfig | 50 drivers/scsi/smartpqi/Makefile |3 drivers/scsi/smartpqi/smartpqi.h | 1133 drivers/scsi/smartpqi/smartpqi_init.c | 6306 drivers/scsi/smartpqi/smartpqi_sas_transport.c | 350 + drivers/scsi/smartpqi/smartpqi_sis.c | 394 + drivers/scsi/smartpqi/smartpqi_sis.h | 32 11 files changed, 8281 insertions(+), 2 deletions(-) create mode 100644 drivers/scsi/smartpqi/Kconfig create mode 100644 drivers/scsi/smartpqi/Makefile create mode 100644 drivers/scsi/smartpqi/smartpqi.h create mode 100644 drivers/scsi/smartpqi/smartpqi_init.c create mode 100644 drivers/scsi/smartpqi/smartpqi_sas_transport.c create mode 100644 drivers/scsi/smartpqi/smartpqi_sis.c create mode 100644 drivers/scsi/smartpqi/smartpqi_sis.h -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 2/2] aacraid: remove wildcard for series 9 controllers
Depends on smartpqi driver adoption
Reviewed-by: Kevin Barnett
Reviewed-by: Scott Teel
Signed-off-by: Kevin Barnett
Signed-off-by: Don Brace
---
drivers/scsi/aacraid/linit.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 79871f3..d5b26fa 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -160,7 +160,6 @@ static const struct pci_device_id aac_pci_tbl[] = {
{ 0x9005, 0x028b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 62 }, /* Adaptec PMC
Series 6 (Tupelo) */
{ 0x9005, 0x028c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 63 }, /* Adaptec PMC
Series 7 (Denali) */
{ 0x9005, 0x028d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 64 }, /* Adaptec PMC
Series 8 */
- { 0x9005, 0x028f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 65 }, /* Adaptec PMC
Series 9 */
{ 0,}
};
MODULE_DEVICE_TABLE(pci, aac_pci_tbl);
@@ -239,7 +238,6 @@ static struct aac_driver_ident aac_drivers[] = {
{ aac_src_init, "aacraid", "ADAPTEC ", "RAID", 2,
AAC_QUIRK_SRC }, /* Adaptec PMC Series 6 (Tupelo) */
{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2,
AAC_QUIRK_SRC }, /* Adaptec PMC Series 7 (Denali) */
{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2,
AAC_QUIRK_SRC }, /* Adaptec PMC Series 8 */
- { aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2,
AAC_QUIRK_SRC } /* Adaptec PMC Series 9 */
};
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
