Re: [PATCH 1/8] pm80xx: Updated link rate
On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote: > From: Viswas G > > > Updated 12G linkrate to libsas. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 2/8] pm80xx: Corrected device state changes in I_T_Nexus_Reset
On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote: > From: Viswas G > > In Nexus reset the device state set to DS_IN_RECOVERY before doing > phy reset and internal cleanup. Once internal cleanup finishes, > the device state will set to DS_OPERATIONAL. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan > --- Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 4/8] pm80xx: Fix for Incorrect DMA Unmapping of SG List
On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote: > From: Viswas G > > In pm8001_ccb_task_free(), the dma unmapping is done based on > ccb->n_elem value. This should be initialized to zero in the > task_abort(). Otherwise, pm8001_ccb_task_free() will try for > dma_unmap_sg() which is invalid for task abort and can lead to > kernel crash. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan > --- > drivers/scsi/pm8001/pm8001_sas.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/scsi/pm8001/pm8001_sas.c > b/drivers/scsi/pm8001/pm8001_sas.c > index 4e6955f..b1c5fb9 100644 > --- a/drivers/scsi/pm8001/pm8001_sas.c > +++ b/drivers/scsi/pm8001/pm8001_sas.c > @@ -790,6 +790,7 @@ pm8001_exec_internal_task_abort(struct pm8001_hba_info > *pm8001_ha, > ccb->device = pm8001_dev; > ccb->ccb_tag = ccb_tag; > ccb->task = task; > + ccb->n_elem = 0; > > res = PM8001_CHIP_DISP->task_abort(pm8001_ha, > pm8001_dev, flag, task_tag, ccb_tag); > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 3/8] pm80xx: Update For Thermal Page Code
On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote: > From: Viswas G > > Thermal page code has been changed to 7 for the 12G controllers. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan > --- Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 5/8] pm80xx: Remove unnecessary phy disconnect while link error
On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote:
> From: Viswas G
>
> If the link error happens, we don't need to disconnect the phy,
> which will remove the drive. Instead acknowledging the controller
> and logging the error will be enough.
>
> Signed-off-by: Viswas G
> Signed-off-by: Suresh Thiagarajan
> ---
> drivers/scsi/pm8001/pm80xx_hwi.c | 12
> 1 files changed, 0 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index dced9f7..3d8b4ae 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -3176,9 +3176,6 @@ static int mpi_hw_event(struct pm8001_hba_info
> *pm8001_ha, void *piomb)
> pm8001_printk("HW_EVENT_LINK_ERR_INVALID_DWORD\n"));
> pm80xx_hw_event_ack_req(pm8001_ha, 0,
> HW_EVENT_LINK_ERR_INVALID_DWORD, port_id, phy_id, 0, 0);
> - sas_phy_disconnected(sas_phy);
> - phy->phy_attached = 0;
> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
> break;
> case HW_EVENT_LINK_ERR_DISPARITY_ERROR:
> PM8001_MSG_DBG(pm8001_ha,
> @@ -3186,9 +3183,6 @@ static int mpi_hw_event(struct pm8001_hba_info
> *pm8001_ha, void *piomb)
> pm80xx_hw_event_ack_req(pm8001_ha, 0,
> HW_EVENT_LINK_ERR_DISPARITY_ERROR,
> port_id, phy_id, 0, 0);
> - sas_phy_disconnected(sas_phy);
> - phy->phy_attached = 0;
> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
> break;
> case HW_EVENT_LINK_ERR_CODE_VIOLATION:
> PM8001_MSG_DBG(pm8001_ha,
> @@ -3196,9 +3190,6 @@ static int mpi_hw_event(struct pm8001_hba_info
> *pm8001_ha, void *piomb)
> pm80xx_hw_event_ack_req(pm8001_ha, 0,
> HW_EVENT_LINK_ERR_CODE_VIOLATION,
> port_id, phy_id, 0, 0);
> - sas_phy_disconnected(sas_phy);
> - phy->phy_attached = 0;
> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
> break;
> case HW_EVENT_LINK_ERR_LOSS_OF_DWORD_SYNCH:
> PM8001_MSG_DBG(pm8001_ha, pm8001_printk(
> @@ -3206,9 +3197,6 @@ static int mpi_hw_event(struct pm8001_hba_info
> *pm8001_ha, void *piomb)
> pm80xx_hw_event_ack_req(pm8001_ha, 0,
> HW_EVENT_LINK_ERR_LOSS_OF_DWORD_SYNCH,
> port_id, phy_id, 0, 0);
> - sas_phy_disconnected(sas_phy);
> - phy->phy_attached = 0;
> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
> break;
> case HW_EVENT_MALFUNCTION:
> PM8001_MSG_DBG(pm8001_ha,
>
So what happens with the port, then?
Will you be getting another event when the port finally disconnects?
If not, how to you remove the port after a link failure?
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 6/8] pm80xx: Add PORT RECOVERY TIMEOUT support
On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote: > From: Viswas G > > PORT RECOVERY TIMEOUT is the maximum time between the controller's > detection of the PHY down until the receipt of the ID_Frame (from the > same remote SAS port). If the time expires before the ID_FRAME is > received, the port is considered INVALID and can be removed. The > IOP_EVENT_PORT_RECOVERY_TIMER_TMO event is reported following the > IOP_EVENT_ PHY_DOWN event when the PHY/port does not recover after > Port Recovery Time. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan > --- Ah. Here is the link down handling. Maybe you should indicate this in the previous patch. Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 7/8] pm80xx: Handling Invalid SSP Response frame
On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote: > From: Viswas G > > The request has to be retried incase if the length of the SSP > Response IU is invalid. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan > --- Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 8/8] pm80xx: Bump pm80xx driver version to 0.1.38
On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote: > From: Viswas G > > Bump pm80xx driver version to 0.1.38. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan > --- > drivers/scsi/pm8001/pm8001_sas.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/scsi/pm8001/pm8001_sas.h > b/drivers/scsi/pm8001/pm8001_sas.h > index 2788026..e2e97db 100644 > --- a/drivers/scsi/pm8001/pm8001_sas.h > +++ b/drivers/scsi/pm8001/pm8001_sas.h > @@ -58,7 +58,7 @@ > #include "pm8001_defs.h" > > #define DRV_NAME "pm80xx" > -#define DRV_VERSION "0.1.37" > +#define DRV_VERSION "0.1.38" > #define PM8001_FAIL_LOGGING 0x01 /* Error message logging */ > #define PM8001_INIT_LOGGING 0x02 /* driver init logging */ > #define PM8001_DISC_LOGGING 0x04 /* discovery layer logging */ > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 0/8] pm80xx: Driver updates
2015-07-29 8:27 GMT+02:00 : > From: Viswas G > > This patch set contains bug fixes for pm80xx driver. > Please consider these patches for next kernel release. > > Viswas G (8): > pm80xx: Updated link rate > pm80xx: Corrected device state changes in I_T_Nexus_Reset > pm80xx: Update For Thermal Page Code > pm80xx: Fix for Incorrect DMA Unmapping of SG List > pm80xx: Remove unnecessary phy disconnect while link error > pm80xx: Add PORT RECOVERY TIMEOUT support > pm80xx: Handling Invalid SSP Response frame > pm80xx: Bump pm80xx driver version to 0.1.38 > > drivers/scsi/pm8001/pm8001_defs.h |1 + > drivers/scsi/pm8001/pm8001_hwi.c |4 + > drivers/scsi/pm8001/pm8001_sas.c | 15 - > drivers/scsi/pm8001/pm8001_sas.h | 12 +++- > drivers/scsi/pm8001/pm80xx_hwi.c | 111 > +++-- > drivers/scsi/pm8001/pm80xx_hwi.h |5 +- > 6 files changed, 112 insertions(+), 36 deletions(-) > For the whole patchset: Reviewed-by: Jack Wang PS: company policy requests to use the email address of the company, please cc me to above address next time, I will send a patch to update my email in MAINTAINERS file. Thanks Jack -- 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 5/8] pm80xx: Remove unnecessary phy disconnect while link error
On 07/29/2015 11:20 AM, Viswas G wrote:
>
> On Wed, Jul 29, 2015 at 2:26 PM, Hannes Reinecke wrote:
>> On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote:
>>> From: Viswas G
>>>
>>> If the link error happens, we don't need to disconnect the phy,
>>> which will remove the drive. Instead acknowledging the controller
>>> and logging the error will be enough.
>>>
>>> Signed-off-by: Viswas G
>>> Signed-off-by: Suresh Thiagarajan
>>> ---
>>> drivers/scsi/pm8001/pm80xx_hwi.c | 12
>>> 1 files changed, 0 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
>>> b/drivers/scsi/pm8001/pm80xx_hwi.c
>>> index dced9f7..3d8b4ae 100644
>>> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
>>> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
>>> @@ -3176,9 +3176,6 @@ static int mpi_hw_event(struct pm8001_hba_info
>>> *pm8001_ha, void *piomb)
>>> pm8001_printk("HW_EVENT_LINK_ERR_INVALID_DWORD\n"));
>>> pm80xx_hw_event_ack_req(pm8001_ha, 0,
>>> HW_EVENT_LINK_ERR_INVALID_DWORD, port_id, phy_id, 0,
>>> 0);
>>> - sas_phy_disconnected(sas_phy);
>>> - phy->phy_attached = 0;
>>> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
>>> break;
>>> case HW_EVENT_LINK_ERR_DISPARITY_ERROR:
>>> PM8001_MSG_DBG(pm8001_ha,
>>> @@ -3186,9 +3183,6 @@ static int mpi_hw_event(struct pm8001_hba_info
>>> *pm8001_ha, void *piomb)
>>> pm80xx_hw_event_ack_req(pm8001_ha, 0,
>>> HW_EVENT_LINK_ERR_DISPARITY_ERROR,
>>> port_id, phy_id, 0, 0);
>>> - sas_phy_disconnected(sas_phy);
>>> - phy->phy_attached = 0;
>>> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
>>> break;
>>> case HW_EVENT_LINK_ERR_CODE_VIOLATION:
>>> PM8001_MSG_DBG(pm8001_ha,
>>> @@ -3196,9 +3190,6 @@ static int mpi_hw_event(struct pm8001_hba_info
>>> *pm8001_ha, void *piomb)
>>> pm80xx_hw_event_ack_req(pm8001_ha, 0,
>>> HW_EVENT_LINK_ERR_CODE_VIOLATION,
>>> port_id, phy_id, 0, 0);
>>> - sas_phy_disconnected(sas_phy);
>>> - phy->phy_attached = 0;
>>> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
>>> break;
>>> case HW_EVENT_LINK_ERR_LOSS_OF_DWORD_SYNCH:
>>> PM8001_MSG_DBG(pm8001_ha, pm8001_printk(
>>> @@ -3206,9 +3197,6 @@ static int mpi_hw_event(struct pm8001_hba_info
>>> *pm8001_ha, void *piomb)
>>> pm80xx_hw_event_ack_req(pm8001_ha, 0,
>>> HW_EVENT_LINK_ERR_LOSS_OF_DWORD_SYNCH,
>>> port_id, phy_id, 0, 0);
>>> - sas_phy_disconnected(sas_phy);
>>> - phy->phy_attached = 0;
>>> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
>>> break;
>>> case HW_EVENT_MALFUNCTION:
>>> PM8001_MSG_DBG(pm8001_ha,
>>>
>> So what happens with the port, then?
>> Will you be getting another event when the port finally disconnects?
>> If not, how to you remove the port after a link failure?
>>
>
> When the Phy disconnects, we will be getting the PHY DOWN events for
> the phys in that port and we will remove that port.
>
Okay, thanks.
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 5/8] pm80xx: Remove unnecessary phy disconnect while link error
On Wed, Jul 29, 2015 at 2:26 PM, Hannes Reinecke wrote:
> On 07/29/2015 08:27 AM, viswa...@pmcs.com wrote:
>> From: Viswas G
>>
>> If the link error happens, we don't need to disconnect the phy,
>> which will remove the drive. Instead acknowledging the controller
>> and logging the error will be enough.
>>
>> Signed-off-by: Viswas G
>> Signed-off-by: Suresh Thiagarajan
>> ---
>> drivers/scsi/pm8001/pm80xx_hwi.c | 12
>> 1 files changed, 0 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
>> b/drivers/scsi/pm8001/pm80xx_hwi.c
>> index dced9f7..3d8b4ae 100644
>> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
>> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
>> @@ -3176,9 +3176,6 @@ static int mpi_hw_event(struct pm8001_hba_info
>> *pm8001_ha, void *piomb)
>> pm8001_printk("HW_EVENT_LINK_ERR_INVALID_DWORD\n"));
>> pm80xx_hw_event_ack_req(pm8001_ha, 0,
>> HW_EVENT_LINK_ERR_INVALID_DWORD, port_id, phy_id, 0,
>> 0);
>> - sas_phy_disconnected(sas_phy);
>> - phy->phy_attached = 0;
>> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
>> break;
>> case HW_EVENT_LINK_ERR_DISPARITY_ERROR:
>> PM8001_MSG_DBG(pm8001_ha,
>> @@ -3186,9 +3183,6 @@ static int mpi_hw_event(struct pm8001_hba_info
>> *pm8001_ha, void *piomb)
>> pm80xx_hw_event_ack_req(pm8001_ha, 0,
>> HW_EVENT_LINK_ERR_DISPARITY_ERROR,
>> port_id, phy_id, 0, 0);
>> - sas_phy_disconnected(sas_phy);
>> - phy->phy_attached = 0;
>> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
>> break;
>> case HW_EVENT_LINK_ERR_CODE_VIOLATION:
>> PM8001_MSG_DBG(pm8001_ha,
>> @@ -3196,9 +3190,6 @@ static int mpi_hw_event(struct pm8001_hba_info
>> *pm8001_ha, void *piomb)
>> pm80xx_hw_event_ack_req(pm8001_ha, 0,
>> HW_EVENT_LINK_ERR_CODE_VIOLATION,
>> port_id, phy_id, 0, 0);
>> - sas_phy_disconnected(sas_phy);
>> - phy->phy_attached = 0;
>> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
>> break;
>> case HW_EVENT_LINK_ERR_LOSS_OF_DWORD_SYNCH:
>> PM8001_MSG_DBG(pm8001_ha, pm8001_printk(
>> @@ -3206,9 +3197,6 @@ static int mpi_hw_event(struct pm8001_hba_info
>> *pm8001_ha, void *piomb)
>> pm80xx_hw_event_ack_req(pm8001_ha, 0,
>> HW_EVENT_LINK_ERR_LOSS_OF_DWORD_SYNCH,
>> port_id, phy_id, 0, 0);
>> - sas_phy_disconnected(sas_phy);
>> - phy->phy_attached = 0;
>> - sas_ha->notify_port_event(sas_phy, PORTE_LINK_RESET_ERR);
>> break;
>> case HW_EVENT_MALFUNCTION:
>> PM8001_MSG_DBG(pm8001_ha,
>>
> So what happens with the port, then?
> Will you be getting another event when the port finally disconnects?
> If not, how to you remove the port after a link failure?
>
When the Phy disconnects, we will be getting the PHY DOWN events for
the phys in that port and we will remove that port.
> Cheers,
>
> Hannes
> --
> Dr. Hannes ReineckezSeries & Storage
> h...@suse.de +49 911 74053 688
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
> HRB 21284 (AG Nürnberg)
> --
> 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
--
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] pm80xx: Added pm8006 controller support
Hi James,
This patch is not pulled in yet.
Regards,
Suresh
-Original Message-
From: Jack Wang [mailto:xjtu...@gmail.com]
Sent: Tuesday, February 24, 2015 2:07 PM
To: Suresh Thiagarajan
Cc: linux-scsi@vger.kernel.org; James Bottomley; Viswas G; pmc...@pmcs.com
Subject: Re: [PATCH] pm80xx: Added pm8006 controller support
Sorry for delay, I missed this patch.
Acked-by: Jack Wang
2015-02-12 7:34 GMT+01:00 Suresh Thiagarajan :
> Added the pm8006 controller id in pci table
>
> Signed-off-by: Suresh Thiagarajan
> Signed-off-by: Viswas G
> ---
> drivers/scsi/pm8001/pm8001_defs.h |3 ++-
> drivers/scsi/pm8001/pm8001_init.c |5 -
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_defs.h
> b/drivers/scsi/pm8001/pm8001_defs.h
> index 74a4bb9..dc4233b 100644
> --- a/drivers/scsi/pm8001/pm8001_defs.h
> +++ b/drivers/scsi/pm8001/pm8001_defs.h
> @@ -49,7 +49,8 @@ enum chip_flavors {
> chip_8019,
> chip_8074,
> chip_8076,
> - chip_8077
> + chip_8077,
> + chip_8006,
> };
>
> enum phy_speed {
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 691..e1aee58 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -57,6 +57,7 @@ static const struct pm8001_chip_info pm8001_chips[] = {
> [chip_8074] = {0, 8, &pm8001_80xx_dispatch,},
> [chip_8076] = {0, 16, &pm8001_80xx_dispatch,},
> [chip_8077] = {0, 16, &pm8001_80xx_dispatch,},
> + [chip_8006] = {0, 16, &pm8001_80xx_dispatch,},
> };
> static int pm8001_id;
>
> @@ -1108,6 +1109,8 @@ err_out_enable:
> */
> static struct pci_device_id pm8001_pci_table[] = {
> { PCI_VDEVICE(PMC_Sierra, 0x8001), chip_8001 },
> + { PCI_VDEVICE(PMC_Sierra, 0x8006), chip_8006 },
> + { PCI_VDEVICE(ADAPTEC2, 0x8006), chip_8006 },
> { PCI_VDEVICE(ATTO, 0x0042), chip_8001 },
> /* Support for SPC/SPCv/SPCve controllers */
> { PCI_VDEVICE(ADAPTEC2, 0x8001), chip_8001 }, @@ -1218,7
> +1221,7 @@ MODULE_AUTHOR("Anand Kumar Santhanam
> ");
> MODULE_AUTHOR("Sangeetha Gnanasekaran
> ");
> MODULE_AUTHOR("Nikith Ganigarakoppal
> ");
> MODULE_DESCRIPTION(
> - "PMC-Sierra PM8001/8081/8088/8089/8074/8076/8077 "
> + "PMC-Sierra PM8001/8006/8081/8088/8089/8074/8076/8077 "
> "SAS/SATA controller driver");
> MODULE_VERSION(DRV_VERSION); MODULE_LICENSE("GPL");
> --
> 1.7.1
>
N�r��yb�X��ǧv�^�){.n�+{���"�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
RE: [PATCH 0/8] pm80xx: Driver updates
On Wed, Jul 29, 2015 at 2:40 PM, Jack Wang wrote: > 2015-07-29 8:27 GMT+02:00 : >> From: Viswas G >> >> This patch set contains bug fixes for pm80xx driver. >> Please consider these patches for next kernel release. >> >> Viswas G (8): >> pm80xx: Updated link rate >> pm80xx: Corrected device state changes in I_T_Nexus_Reset >> pm80xx: Update For Thermal Page Code >> pm80xx: Fix for Incorrect DMA Unmapping of SG List >> pm80xx: Remove unnecessary phy disconnect while link error >> pm80xx: Add PORT RECOVERY TIMEOUT support >> pm80xx: Handling Invalid SSP Response frame >> pm80xx: Bump pm80xx driver version to 0.1.38 >> >> drivers/scsi/pm8001/pm8001_defs.h |1 + >> drivers/scsi/pm8001/pm8001_hwi.c |4 + >> drivers/scsi/pm8001/pm8001_sas.c | 15 - >> drivers/scsi/pm8001/pm8001_sas.h | 12 +++- >> drivers/scsi/pm8001/pm80xx_hwi.c | 111 >> +++-- >> drivers/scsi/pm8001/pm80xx_hwi.h |5 +- >> 6 files changed, 112 insertions(+), 36 deletions(-) >> > For the whole patchset: > > Reviewed-by: Jack Wang For the whole patchset again: Reviewed-by: Suresh Thiagarajan -Suresh > > PS: company policy requests to use the email address of the company, > please cc me to above address next time, I will send a patch to update > my email > in MAINTAINERS file. > > Thanks > Jack
[PATCH] MAINTAINERS: update email for pm8001
Company has policy to use company email address, so update my email address to company address. Signed-off-by: Jack Wang --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a226416..c82f964 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8040,7 +8040,7 @@ S:Supported F: drivers/scsi/pmcraid.* PMC SIERRA PM8001 DRIVER -M: xjtu...@gmail.com +M: Jack Wang M: lindar_...@usish.com L: pmc...@pmcs.com L: linux-scsi@vger.kernel.org -- 1.9.1 -- 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 4/8] xen: Use the correctly the Xen memory terminologies
On Tue, Jul 28, 2015 at 04:02:45PM +0100, Julien Grall wrote:
[...]
> diff --git a/drivers/net/xen-netback/netback.c
> b/drivers/net/xen-netback/netback.c
> index 7d50711..3b7b7c3 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
> *queue, struct sk_buff *skb
> } else {
> copy_gop->source.domid = DOMID_SELF;
> copy_gop->source.u.gmfn =
> - virt_to_mfn(page_address(page));
> + virt_to_gfn(page_address(page));
> }
> copy_gop->source.offset = offset;
>
> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue
> *queue,
> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
>
> queue->tx_copy_ops[*copy_ops].dest.u.gmfn =
> - virt_to_mfn(skb->data);
> + virt_to_gfn(skb->data);
> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
> queue->tx_copy_ops[*copy_ops].dest.offset =
> offset_in_page(skb->data);
Reviewed-by: Wei Liu
One possible improvement is to change gmfn in copy_gop to gfn as well.
But that's outside of netback code.
Wei.
--
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 0/8] Use correctly the Xen memory terminologies in Linux
On 28/07/15 16:02, Julien Grall wrote: > Hi all, > > This patch series aims to use the memory terminologies described in > include/linux/mm.h [1] for Linux xen code. I mistakenly wrote the wrong include here. It should be include/xen/mm.h from the Xen tree: http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb Regards, -- Julien Grall -- 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: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
On 28/07/15 18:16, David Vrabel wrote: > On 28/07/15 16:02, Julien Grall wrote: >> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN >> is meant, I suspect this is because the first support for Xen was for >> PV. This brough some misimplementation of helpers on ARM and make the >> developper confused the expected behavior. > > For the benefit of other subsystem maintainers, this is a purely > mechanical change in Xen-specific terminology. It doesn't need reviews > or acks from non-Xen people (IMO). > >> For instance, with pfn_to_mfn, we expect to get an MFN based on the name. >> Although, if we look at the implementation on x86, it's returning a GFN. >> >> For clarity and avoid new confusion, replace any reference of mfn into >> gnf in any helpers used by PV drivers. >> >> Take also the opportunity to simplify simple construction such >> as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up >> will come in follow-up patches. >> >> I think it may be possible to do further clean up in the x86 code to >> ensure that helpers returning machine address (such as virt_address) is >> not used by no auto-translated guests. I will let x86 xen expert doing >> it. > > Reviewed-by: David Vrabel > > It looks a bit odd to use GFN in some of the PV code where the > hypervisor API uses MFN but overall I think using the correct > terminology where possible is best. But I'd like to have Boris's or > Konrad's opinion on this. I was thinking to introduce mfn_to_pfn & co which would be used only for PV-guest (a BUG_ON would be here to ensure it) and hypercall related. I didn't do it as I haven't much knowledge on x86 Xen and was able to decide where I have to use pfn_to_mfn. Regards, -- Julien Grall -- 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 4/8] xen: Use the correctly the Xen memory terminologies
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
> On 07/28/2015 11:02 AM, Julien Grall wrote:
>> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
>> is meant, I suspect this is because the first support for Xen was for
>> PV. This brough some misimplementation of helpers on ARM and make the
>> developper confused the expected behavior.
>>
>> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
>> Although, if we look at the implementation on x86, it's returning a GFN.
>>
>> For clarity and avoid new confusion, replace any reference of mfn into
>> gnf in any helpers used by PV drivers.
>
>
>
>
>> @@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned
>> long pfn)
>> struct mmuext_op op;
>>
>> op.cmd = level;
>> -op.arg1.mfn = pfn_to_mfn(pfn);
>> +op.arg1.mfn = pfn_to_gfn(pfn);
>
>
> This looks slightly odd. It is correct but given that purpose of this
> series is to make things more clear perhaps we can add another union
> member (gfn) to mmuext_op.arg1?
>
> (Of course, the hypervisor will continue referring to mfn which could
> still be confusing)
This operation is only used for PV guests, right?
IHMO re-introducing pfn_to_mfn for PV-guests only (i.e with a BUG_ON to
ensure no usage for auto-translated guest) would be the best solution.
It would avoid to have different name than the hypersivor one in the
hypercall interface. It will also make clear that virt_to_machine & co
is only PV specific.
I though doing this but I preferred to defer it to x86 expert as my
knowledge for x86 Xen is very limited. I don't know where it's more
suitable to use MFN or GFN. I guess this file (mmu.c) is mostly PV specific?
Would something like below fine for you?
static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
unsigned long mfn;
BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
mfn = __pfn_to_mfn(pfn);
if (mfn != INVALID_P2M_ENTRY)
mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
return mfn;
}
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
Similar splitting would be done for gfn_to_pfn and mfn_to_pfn.
Regards,
--
Julien Grall
--
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: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Hi Chris, On 28/07/15 20:39, Chris (Christopher) Brand wrote: >> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN is >> meant, >> I suspect this is because the first support for Xen was for PV. This brough >> some > Typo : "brought" > Perhaps "resulted in" would be better ? > >> misimplementation of helpers on ARM and make the developper confused the >> expected behavior. > Typo: "developer". > I'd also suggest "...and confused developers about the...". > > [...] > >> For clarity and avoid new confusion, replace any reference of mfn into gnf >> in any helpers used by PV drivers. > Typo : "gfn" > I'd suggest "...replace any reference to mfn with gfn..." > > [...] Thanks for telling me the typoes. I will fix it in the next version of this series. Regards, -- Julien Grall -- 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: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Hi Wei,
On 29/07/15 11:13, Wei Liu wrote:
> On Tue, Jul 28, 2015 at 04:02:45PM +0100, Julien Grall wrote:
> [...]
>> diff --git a/drivers/net/xen-netback/netback.c
>> b/drivers/net/xen-netback/netback.c
>> index 7d50711..3b7b7c3 100644
>> --- a/drivers/net/xen-netback/netback.c
>> +++ b/drivers/net/xen-netback/netback.c
>> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
>> *queue, struct sk_buff *skb
>> } else {
>> copy_gop->source.domid = DOMID_SELF;
>> copy_gop->source.u.gmfn =
>> -virt_to_mfn(page_address(page));
>> +virt_to_gfn(page_address(page));
>> }
>> copy_gop->source.offset = offset;
>>
>> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue
>> *queue,
>> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
>>
>> queue->tx_copy_ops[*copy_ops].dest.u.gmfn =
>> -virt_to_mfn(skb->data);
>> +virt_to_gfn(skb->data);
>> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
>> queue->tx_copy_ops[*copy_ops].dest.offset =
>> offset_in_page(skb->data);
>
> Reviewed-by: Wei Liu
>
> One possible improvement is to change gmfn in copy_gop to gfn as well.
> But that's outside of netback code.
The structure gnttab_copy is part of the hypervisor interface. Is it
fine to differ on the naming between Xen and Linux?
Or maybe we could do the change in the public headers in Xen repo too.
Is it fine to do field renaming in public headers?
Regards,
--
Julien Grall
--
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: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
On 29/07/15 12:35, Julien Grall wrote:
> Hi Wei,
>
> On 29/07/15 11:13, Wei Liu wrote:
>> On Tue, Jul 28, 2015 at 04:02:45PM +0100, Julien Grall wrote:
>> [...]
>>> diff --git a/drivers/net/xen-netback/netback.c
>>> b/drivers/net/xen-netback/netback.c
>>> index 7d50711..3b7b7c3 100644
>>> --- a/drivers/net/xen-netback/netback.c
>>> +++ b/drivers/net/xen-netback/netback.c
>>> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
>>> *queue, struct sk_buff *skb
>>> } else {
>>> copy_gop->source.domid = DOMID_SELF;
>>> copy_gop->source.u.gmfn =
>>> - virt_to_mfn(page_address(page));
>>> + virt_to_gfn(page_address(page));
>>> }
>>> copy_gop->source.offset = offset;
>>>
>>> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue
>>> *queue,
>>> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
>>>
>>> queue->tx_copy_ops[*copy_ops].dest.u.gmfn =
>>> - virt_to_mfn(skb->data);
>>> + virt_to_gfn(skb->data);
>>> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
>>> queue->tx_copy_ops[*copy_ops].dest.offset =
>>> offset_in_page(skb->data);
>>
>> Reviewed-by: Wei Liu
>>
>> One possible improvement is to change gmfn in copy_gop to gfn as well.
>> But that's outside of netback code.
>
> The structure gnttab_copy is part of the hypervisor interface. Is it
> fine to differ on the naming between Xen and Linux?
>
> Or maybe we could do the change in the public headers in Xen repo too.
> Is it fine to do field renaming in public headers?
I think this series should not alter than Xen API.
David
--
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: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
On Wed, Jul 29, 2015 at 12:35:54PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 29/07/15 11:13, Wei Liu wrote:
> > On Tue, Jul 28, 2015 at 04:02:45PM +0100, Julien Grall wrote:
> > [...]
> >> diff --git a/drivers/net/xen-netback/netback.c
> >> b/drivers/net/xen-netback/netback.c
> >> index 7d50711..3b7b7c3 100644
> >> --- a/drivers/net/xen-netback/netback.c
> >> +++ b/drivers/net/xen-netback/netback.c
> >> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
> >> *queue, struct sk_buff *skb
> >>} else {
> >>copy_gop->source.domid = DOMID_SELF;
> >>copy_gop->source.u.gmfn =
> >> - virt_to_mfn(page_address(page));
> >> + virt_to_gfn(page_address(page));
> >>}
> >>copy_gop->source.offset = offset;
> >>
> >> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue
> >> *queue,
> >>queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
> >>
> >>queue->tx_copy_ops[*copy_ops].dest.u.gmfn =
> >> - virt_to_mfn(skb->data);
> >> + virt_to_gfn(skb->data);
> >>queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
> >>queue->tx_copy_ops[*copy_ops].dest.offset =
> >>offset_in_page(skb->data);
> >
> > Reviewed-by: Wei Liu
> >
> > One possible improvement is to change gmfn in copy_gop to gfn as well.
> > But that's outside of netback code.
>
> The structure gnttab_copy is part of the hypervisor interface. Is it
> fine to differ on the naming between Xen and Linux?
>
> Or maybe we could do the change in the public headers in Xen repo too.
> Is it fine to do field renaming in public headers?
>
Oh well. Never mind then. I mistook that structure as internal to Linux.
Wei.
> Regards,
>
> --
> Julien Grall
--
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 4/8] xen: Use the correctly the Xen memory terminologies
On 07/29/2015 07:25 AM, Julien Grall wrote:
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
On 07/28/2015 11:02 AM, Julien Grall wrote:
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This brough some misimplementation of helpers on ARM and make the
developper confused the expected behavior.
For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.
For clarity and avoid new confusion, replace any reference of mfn into
gnf in any helpers used by PV drivers.
@@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned
long pfn)
struct mmuext_op op;
op.cmd = level;
-op.arg1.mfn = pfn_to_mfn(pfn);
+op.arg1.mfn = pfn_to_gfn(pfn);
This looks slightly odd. It is correct but given that purpose of this
series is to make things more clear perhaps we can add another union
member (gfn) to mmuext_op.arg1?
(Of course, the hypervisor will continue referring to mfn which could
still be confusing)
This operation is only used for PV guests, right?
IHMO re-introducing pfn_to_mfn for PV-guests only (i.e with a BUG_ON to
ensure no usage for auto-translated guest) would be the best solution.
It would avoid to have different name than the hypersivor one in the
hypercall interface. It will also make clear that virt_to_machine & co
is only PV specific.
I though doing this but I preferred to defer it to x86 expert as my
knowledge for x86 Xen is very limited. I don't know where it's more
suitable to use MFN or GFN. I guess this file (mmu.c) is mostly PV specific?
Would something like below fine for you?
static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
unsigned long mfn;
BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
mfn = __pfn_to_mfn(pfn);
if (mfn != INVALID_P2M_ENTRY)
mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
return mfn;
}
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
But you'd still say 'op.arg1.mfn = pfn_to_gfn(pfn);' in xen_do_pin()
i.e. assign GFN to MFN, right? That's what I was referring to.
(In general, I am not sure a guest should ever use 'mfn' as it is purely
a hypervisor construct. Including p2m, which I think should really be
p2g as this is what we use to figure out what to stick into page tables)
-boris
Similar splitting would be done for gfn_to_pfn and mfn_to_pfn.
Regards,
--
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 4/8] xen: Use the correctly the Xen memory terminologies
On 29/07/15 15:14, Boris Ostrovsky wrote:
>> static inline unsigned long pfn_to_gfn(unsigned long pfn)
>> {
>> if (xen_feature(XENFEAT_autotranslated_physmap))
>> return pfn;
>> else
>> return pfn_to_mfn(pfn);
>> }
>
>
> But you'd still say 'op.arg1.mfn = pfn_to_gfn(pfn);' in xen_do_pin()
> i.e. assign GFN to MFN, right? That's what I was referring to.
Well no. I would use op.arg1.mfn = pfn_to_mfn(pfn) given that the code,
if I'm right, is only executed for PV.
mfn = pfn_to_gfn(...) was valid too because on PV is always an MFN. The
suggestion of pfn_to_mfn was just for more readability,
> (In general, I am not sure a guest should ever use 'mfn' as it is purely
> a hypervisor construct. Including p2m, which I think should really be
> p2g as this is what we use to figure out what to stick into page tables)
I think avoid to use mfn in the hypervisor interface is out-of-scope for
this series. If we ever want to modify the Xen API in Linux, we should
do in sync with Xen to avoid inconsistency on naming.
Anyway, the oddity of mfn = pfn_to_gfn(...) is mostly contained in the
x86 specific code. I don't mind to either add pfn_to_mfn and use it or
add a comment /* PV-specific so mfn == gfn */ for every use of mfn =
pfn_to_gfn(...).
Regards,
--
Julien Grall
--
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 4/8] xen: Use the correctly the Xen memory terminologies
On 07/29/2015 10:23 AM, Julien Grall wrote:
On 29/07/15 15:14, Boris Ostrovsky wrote:
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
But you'd still say 'op.arg1.mfn = pfn_to_gfn(pfn);' in xen_do_pin()
i.e. assign GFN to MFN, right? That's what I was referring to.
Well no. I would use op.arg1.mfn = pfn_to_mfn(pfn) given that the code,
if I'm right, is only executed for PV.
mfn = pfn_to_gfn(...) was valid too because on PV is always an MFN. The
suggestion of pfn_to_mfn was just for more readability,
Right, and my comments were also not about correctness.
(In general, I am not sure a guest should ever use 'mfn' as it is purely
a hypervisor construct. Including p2m, which I think should really be
p2g as this is what we use to figure out what to stick into page tables)
I think avoid to use mfn in the hypervisor interface is out-of-scope for
this series. If we ever want to modify the Xen API in Linux, we should
do in sync with Xen to avoid inconsistency on naming.
Anyway, the oddity of mfn = pfn_to_gfn(...) is mostly contained in the
x86 specific code. I don't mind to either add pfn_to_mfn and use it or
add a comment /* PV-specific so mfn == gfn */ for every use of mfn =
pfn_to_gfn(...).
I think the former is better (even thought it adds a test)
-boris
--
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 1/8] pm80xx: Updated link rate
On 29.7.2015 08:27, viswa...@pmcs.com wrote: > From: Viswas G > > > Updated 12G linkrate to libsas. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan > Reviewed-by: Tomas Henzl 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
Re: [PATCH 2/8] pm80xx: Corrected device state changes in I_T_Nexus_Reset
On 29.7.2015 08:27, viswa...@pmcs.com wrote:
> From: Viswas G
>
> In Nexus reset the device state set to DS_IN_RECOVERY before doing
> phy reset and internal cleanup. Once internal cleanup finishes,
> the device state will set to DS_OPERATIONAL.
>
> Signed-off-by: Viswas G
> Signed-off-by: Suresh Thiagarajan
> ---
> drivers/scsi/pm8001/pm8001_sas.c | 14 +++---
> drivers/scsi/pm8001/pm8001_sas.h |8
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_sas.c
> b/drivers/scsi/pm8001/pm8001_sas.c
> index b93f289..4e6955f 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -980,13 +980,21 @@ int pm8001_I_T_nexus_reset(struct domain_device *dev)
> rc = 0;
> goto out;
> }
> + pm8001_dev->setds_completion = &completion_setstate;
> + PM8001_CHIP_DISP->set_dev_state_req(pm8001_ha,
> + pm8001_dev, DS_IN_RECOVERY);
> + wait_for_completion(&completion_setstate);
> rc = sas_phy_reset(phy, 1);
> msleep(2000);
> + if (rc) {
> + PM8001_EH_DBG(pm8001_ha,
> + pm8001_printk("phy reset failed for device %x\n"
> + "with rc %d\n", pm8001_dev->device_id, rc));
> + }
> rc = pm8001_exec_internal_task_abort(pm8001_ha, pm8001_dev ,
> dev, 1, 0);
> - pm8001_dev->setds_completion = &completion_setstate;
> - rc = PM8001_CHIP_DISP->set_dev_state_req(pm8001_ha,
> - pm8001_dev, 0x01);
> + PM8001_CHIP_DISP->set_dev_state_req(pm8001_ha,
> + pm8001_dev, DS_OPERATIONAL);
Hi Viswas,
the set_dev_state_req can't fail any more ? Also the
pm8001_exec_internal_task_abort may fail - shouldn't
be error handling also added ?
Cheers,
Tomas
> wait_for_completion(&completion_setstate);
> } else {
> rc = sas_phy_reset(phy, 1);
> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
> b/drivers/scsi/pm8001/pm8001_sas.h
> index 8dd8b78..c9736cc 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.h
> +++ b/drivers/scsi/pm8001/pm8001_sas.h
> @@ -569,6 +569,14 @@ struct pm8001_fw_image_header {
> #define NCQ_READ_LOG_FLAG 0x8000
> #define NCQ_ABORT_ALL_FLAG 0x4000
> #define NCQ_2ND_RLE_FLAG0x2000
> +
> +/* Device states */
> +#define DS_OPERATIONAL 0x01
> +#define DS_PORT_IN_RESET 0x02
> +#define DS_IN_RECOVERY 0x03
> +#define DS_IN_ERROR 0x04
> +#define DS_NON_OPERATIONAL 0x07
> +
> /**
> * brief param structure for firmware flash update.
> */
>
--
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 3/8] pm80xx: Update For Thermal Page Code
On 29.7.2015 08:27, viswa...@pmcs.com wrote: > From: Viswas G > > Thermal page code has been changed to 7 for the 12G controllers. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan Reviewed-by: Tomas Henzl 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
Re: [PATCH 4/8] pm80xx: Fix for Incorrect DMA Unmapping of SG List
On 29.7.2015 08:27, viswa...@pmcs.com wrote: > From: Viswas G > > In pm8001_ccb_task_free(), the dma unmapping is done based on > ccb->n_elem value. This should be initialized to zero in the > task_abort(). Otherwise, pm8001_ccb_task_free() will try for > dma_unmap_sg() which is invalid for task abort and can lead to > kernel crash. > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan Reviewed-by: Tomas Henzl 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] scsi: a100u2w: trivial typo in printk
From: Colin Ian King
Trivial typo fix, \b should be \n
Signed-off-by: Colin Ian King
---
drivers/scsi/a100u2w.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/a100u2w.c b/drivers/scsi/a100u2w.c
index cac6b37..8086bd0 100644
--- a/drivers/scsi/a100u2w.c
+++ b/drivers/scsi/a100u2w.c
@@ -888,7 +888,7 @@ static int inia100_build_scb(struct orc_host * host, struct
orc_scb * scb, struc
scb->sense_len = SENSE_SIZE;
scb->cdb_len = cmd->cmd_len;
if (scb->cdb_len >= IMAX_CDB) {
- printk("max cdb length= %x\b", cmd->cmd_len);
+ printk("max cdb length= %x\n", cmd->cmd_len);
scb->cdb_len = IMAX_CDB;
}
scb->ident = (u8)(cmd->device->lun & 0xff) | DISC_ALLOW;
--
2.4.6
--
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] scsi: pmcraid: trivial typo in printk
Trivial typo fixes:
o \b should be \n
o coalesce format to avoid excess spaces
Signed-off-by: Joe Perches
---
And another here:
drivers/scsi/pmcraid.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index ed31d8c..b421de2 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -1558,8 +1558,7 @@ static void pmcraid_handle_config_change(struct
pmcraid_instance *pinstance)
cfg_entry = &ccn_hcam->cfg_entry;
fw_version = be16_to_cpu(pinstance->inq_data->fw_version);
- pmcraid_info("CCN(%x): %x timestamp: %llx type: %x lost: %x flags: %x \
-res: %x:%x:%x:%x\n",
+ pmcraid_info("CCN(%x): %x timestamp: %llx type: %x lost: %x flags: %x
res: %x:%x:%x:%x\n",
pinstance->ccn.hcam->ilid,
pinstance->ccn.hcam->op_code,
((pinstance->ccn.hcam->timestamp1) |
@@ -1583,7 +1582,7 @@ static void pmcraid_handle_config_change(struct
pmcraid_instance *pinstance)
if (pinstance->ccn.hcam->notification_lost) {
cfgcmd = pmcraid_get_free_cmd(pinstance);
if (cfgcmd) {
- pmcraid_info("lost CCN, reading config table\b");
+ pmcraid_info("lost CCN, reading config table\n");
pinstance->reinit_cfg_table = 1;
pmcraid_querycfg(cfgcmd);
} else {
--
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] [SCSI] atp870u: 64 bit bug in probe()
On 64 bit CPUs there is a memory corruption bug on probe(). It should
be a u32 pointer instead of an unsigned long pointer or we write past
the end of the setupdata[] array.
Signed-off-by: Dan Carpenter
---
Someone reported in 2003 that probe has a NULL deref so maybe it's
related to this memory corruption?
https://bugzilla.kernel.org/show_bug.cgi?id=1118
If only we had applied this patch when I originally sent it two years
ago, then it would only be 10 years too late instead of 12! :P
diff --git a/drivers/scsi/atp870u.c b/drivers/scsi/atp870u.c
index 05301bc..62acabd 100644
--- a/drivers/scsi/atp870u.c
+++ b/drivers/scsi/atp870u.c
@@ -2791,11 +2791,11 @@ next_fblk_885:
p->global_map[m]= 0;
for (k=0; k < 4; k++) {
outw(n++,base_io + 0x3c);
- ((unsigned long *)&setupdata[m][0])[k]=inl(base_io +
0x38);
+ ((u32 *)&setupdata[m][0])[k]=inl(base_io + 0x38);
}
for (k=0; k < 4; k++) {
outw(n++,base_io + 0x3c);
- ((unsigned long *)&p->sp[m][0])[k]=inl(base_io + 0x38);
+ ((u32 *)&p->sp[m][0])[k]=inl(base_io + 0x38);
}
n += 8;
}
--
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] cxlflash: Base error recovery support
Subject: [PATCH v2 1/3] cxlflash: Base error recovery support
Date: Thu, 16 Jul 2015 18:26:35 -0500
From: Matthew R. Ochs
To: linux-scsi@vger.kernel.org,
james.bottom...@hansenpartnership.com, n...@linux-iscsi.org,
brk...@linux.vnet.ibm.com
CC: h...@infradead.org, mi...@neuling.org, imun...@au1.ibm.com,
d...@ozlabs.au.ibm.com, Manoj N. Kumar
Introduce support for enhanced I/O error handling.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
---
drivers/scsi/cxlflash/common.h | 11 +++-
drivers/scsi/cxlflash/main.c | 135
++---
2 files changed, 133 insertions(+), 13 deletions(-)
+/**
+ * cxlflash_pci_error_detected() - called when a PCI error is detected
+ * @pdev: PCI device struct.
+ * @state: PCI channel state.
+ *
+ * Return: PCI_ERS_RESULT_NEED_RESET or PCI_ERS_RESULT_DISCONNECT
+ */
+static pci_ers_result_t cxlflash_pci_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state)
+{
+ struct cxlflash_cfg *cfg = pci_get_drvdata(pdev);
+
+ pr_debug("%s: pdev=%p state=%u\n", __func__, pdev, state);
+
+ switch (state) {
+ case pci_channel_io_frozen:
+ cfg->eeh_active = EEH_STATE_ACTIVE;
+ udelay(100);
+
+ term_mc(cfg, UNDO_START);
+ stop_afu(cfg);
+
+ return PCI_ERS_RESULT_CAN_RECOVER;
+ case pci_channel_io_perm_failure:
+ cfg->eeh_active = EEH_STATE_FAILED;
+ wake_up_all(&cfg->eeh_waitq);
+ return PCI_ERS_RESULT_DISCONNECT;
+ default:
+ break;
+ }
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * cxlflash_pci_slot_reset() - called when PCI slot has been reset
+ * @pdev: PCI device struct.
+ *
+ * This routine is called by the pci error recovery code after the PCI
+ * slot has been reset, just before we should resume normal operations.
+ *
+ * Return: PCI_ERS_RESULT_RECOVERED or PCI_ERS_RESULT_DISCONNECT
+ */
+static pci_ers_result_t cxlflash_pci_slot_reset(struct pci_dev *pdev)
+{
+ int rc = 0;
+ struct cxlflash_cfg *cfg = pci_get_drvdata(pdev);
+
+ pr_debug("%s: pdev=%p\n", __func__, pdev);
+
+ rc = init_afu(cfg);
+ if (unlikely(rc)) {
+ pr_err("%s: EEH recovery failed! (%d)\n", __func__, rc);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * cxlflash_pci_resume() - called when normal operation can resume
+ * @pdev: PCI device struct
+ */
+static void cxlflash_pci_resume(struct pci_dev *pdev)
+{
+ struct cxlflash_cfg *cfg = pci_get_drvdata(pdev);
+
+ pr_debug("%s: pdev=%p\n", __func__, pdev);
+
+ cfg->eeh_active = EEH_STATE_NONE;
+ wake_up_all(&cfg->eeh_waitq);
+}
+
Do you need host->lock in these EEH callback functions?
+static const struct pci_error_handlers cxlflash_err_handler = {
+ .error_detected = cxlflash_pci_error_detected,
+ .slot_reset = cxlflash_pci_slot_reset,
+ .resume = cxlflash_pci_resume,
+};
+
/*
* PCI device structure
*/
@@ -2267,6 +2381,7 @@ static struct pci_driver cxlflash_driver = {
.id_table = cxlflash_pci_table,
.probe = cxlflash_probe,
.remove = cxlflash_remove,
+ .err_handler = &cxlflash_err_handler,
};
/**
--
2.1.0
Thanks,
Wendy
--
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 3/3] cxlflash: Virtual LUN support
Forwarded Message
Subject: [PATCH v2 3/3] cxlflash: Virtual LUN support
Date: Thu, 16 Jul 2015 18:26:57 -0500
From: Matthew R. Ochs
To: linux-scsi@vger.kernel.org,
james.bottom...@hansenpartnership.com, n...@linux-iscsi.org,
brk...@linux.vnet.ibm.com
CC: h...@infradead.org, mi...@neuling.org, imun...@au1.ibm.com,
d...@ozlabs.au.ibm.com, Manoj N. Kumar
Add support for physical LUN segmentation (virtual LUNs) to device
driver supporting the IBM CXL Flash adapter. This patch allows user
space applications to virtually segment a physical LUN into N virtual
LUNs, taking advantage of the translation features provided by this
adapter.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
---
drivers/scsi/cxlflash/Makefile |2 +-
drivers/scsi/cxlflash/common.h |3 +
drivers/scsi/cxlflash/main.c | 12 +
drivers/scsi/cxlflash/sislite.h|3 +
drivers/scsi/cxlflash/superpipe.c | 56 ++
drivers/scsi/cxlflash/superpipe.h | 50 +-
drivers/scsi/cxlflash/vlun.c | 1187
drivers/scsi/cxlflash/vlun.h | 68 +++
include/uapi/scsi/cxlflash_ioctl.h | 29 +
9 files changed, 1408 insertions(+), 2 deletions(-)
create mode 100644 drivers/scsi/cxlflash/vlun.c
create mode 100644 drivers/scsi/cxlflash/vlun.h
+ * ba_alloc() - allocates a block from the block allocator
+ * @ba_lun:Block allocator from which to allocate a block.
+ *
+ * Return: The allocated block, -1 on failure
+ */
+static u64 ba_alloc(struct ba_lun *ba_lun)
+{
+ u64 bit_pos = -1;
+ int bit_word = 0;
+ struct ba_lun_info *lun_info = NULL;
+
+ lun_info = (struct ba_lun_info *)ba_lun->ba_lun_handle;
+
+ pr_debug("%s: Received block allocation request: "
+"lun_id = %llX, free_aun_cnt = %llX\n",
+__func__, ba_lun->lun_id, lun_info->free_aun_cnt);
+
+ if (lun_info->free_aun_cnt == 0) {
+ pr_err("%s: No space left on LUN: lun_id = %llX\n",
+ __func__, ba_lun->lun_id);
+ return -1ULL;
+ }
+
+ /* Search to find a free entry, curr->high then low->curr */
+ bit_pos = find_free_range(lun_info->free_curr_idx,
+ lun_info->free_high_idx, lun_info, &bit_word);
+ if (bit_pos == -1) {
+ bit_pos = find_free_range(lun_info->free_low_idx,
+ lun_info->free_curr_idx,
+ lun_info, &bit_word);
+ if (bit_pos == -1) {
+ pr_err("%s: Could not find an allocation unit on LUN: "
+ "lun_id = %llX\n", __func__, ba_lun->lun_id);
+ return -1ULL;
+ }
+ }
+
+ /* Update the free_curr_idx */
+ if (bit_pos == 63)
+ lun_info->free_curr_idx = bit_word + 1;
Predefined Macros for 63 and 64?
+ else
+ lun_info->free_curr_idx = bit_word;
+
+ pr_debug("%s: Allocating AU number %llX, on lun_id %llX, "
+"free_aun_cnt = %llX\n", __func__,
+((bit_word * 64) + bit_pos), ba_lun->lun_id,
+lun_info->free_aun_cnt);
+
+ return (u64) ((bit_word * 64) + bit_pos);
+}
+/**
+ * ba_free() - frees a block from the block allocator
+ * @ba_lun:Block allocator from which to allocate a block.
+ * @to_free: Block to free.
+ *
+ * Return: 0 on success, -1 on failure
+ */
+static int ba_free(struct ba_lun *ba_lun, u64 to_free)
+{
+ int idx = 0, bit_pos = 0;
+ struct ba_lun_info *lun_info = NULL;
+
+ lun_info = (struct ba_lun_info *)ba_lun->ba_lun_handle;
+
struct ba_lun_info *lun_info =(struct ba_lun_info *)ba_lun->ba_lun_handle;
+ if (validate_alloc(lun_info, to_free)) {
+ pr_err("%s: The AUN %llX is not allocated on lun_id %llX\n",
+ __func__, to_free, ba_lun->lun_id);
+ return -1;
+ }
+
+ pr_debug("%s: Received a request to free AU %llX on lun_id %llX, "
+"free_aun_cnt = %llX\n", __func__, to_free, ba_lun->lun_id,
+lun_info->free_aun_cnt);
+
+ if (lun_info->aun_clone_map[to_free] > 0) {
+ pr_debug("%s: AUN %llX on lun_id %llX has been cloned. Clone "
+"count = %X\n", __func__, to_free, ba_lun->lun_id,
+lun_info->aun_clone_map[to_free]);
+ lun_info->aun_clone_map[to_free]--;
+ return 0;
+ }
+
+ idx = to_free / 64;
+ bit_pos = to_free % 64;
+
+ set_bit(bit_pos, (ulong *)&lun_info->lun_alloc_map[idx]);
+ lun_info->free_aun_cnt++;
+
+ if (idx < lun_info->free_low_idx)
+ lun_info->free_low_idx = idx;
+ else if (idx > lun_info->free_high_idx)
+ lun_info->free_high_idx = idx;
+
+ pr_debug("%s: Successfully freed AU at bit_pos %X, bit
RE: [patch] Revert "block: remove artifical max_hw_sectors cap"
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Jeff Moyer > Sent: Wednesday, July 29, 2015 11:53 AM > To: Christoph Hellwig > Cc: Jens Axboe ; linux-ker...@vger.kernel.org; > dmilb...@redhat.com Adding linux-scsi... > Subject: Re: [patch] Revert "block: remove artifical max_hw_sectors cap" > > Christoph Hellwig writes: > > > On Mon, Jul 20, 2015 at 03:17:07PM -0400, Jeff Moyer wrote: > >> For SAN storage, we've seen initial write and re-write performance drop > >> 25-50% across all I/O sizes. On locally attached storage, we've seen > >> regressions of 40% for all I/O types, but only for I/O sizes larger > than > >> 1MB. > > > > Workload, and hardare please. An only mainline numbers, not some old > > hacked vendor kernel, please. > > I've attached a simple fio config that reproduces the problem. It just > does sequential, O_DIRECT write I/O with I/O sizes of 1M, 2M and 4M. So > far I've tested it on an HP HSV400 and an IBM XIV SAN array connected > via a qlogic adapter, a nearline sata driveand a WD Red (NAS) sata disk > connected via an intel ich9r sata controller. The kernel I tested was > 4.2.0-rc3, and the testing was done across 3 different hosts (just > because I don't have all the hardware connected to a single box). I did > 10 runs using max_sectors_kb set to 1024, and 10 runs with it set to > 32767. Results compare the averages of those 10 runs. In no cases did > I see a performance gain. In two cases, there is a performance hit. > > In addition to my testing, our performance teams have seen performance > regressions running iozone on fibre channel-attached HP MSA1000 storage, > as well as on an SSD hidden behind a megaraid controller. I was not > able to get the exact details on the SSD. iozone configurations can be > provided, but I think I've nailed the underlying problem with this test > case. > > But, don't take my word for it. Run the fio script on your own > hardware. All you have to do is echo a couple of values into > /sys/block/sdX/queue/max_sectors_kb to test, no kernel rebuilding > required. > > In the tables below, concentrate on the BW/IOPS numbers under the WRITE > column. Negative numbers indicate that max_sectors_kb of 32767 shows a > performance regression of the indicated percentage when compared with a > setting of 1024. > > Christoph, did you have some hardware where a higher max_sectors_kb > improved performance? I don't still have performance numbers, but the old default of 512 KiB was interfering with building large writes that RAID controllers can treat as full stripe writes (avoiding the need to read the old parity). With the SCSI LLD value bumped up, some other limits remain: * the block layer BIO_MAX_PAGES value of 256 limits IOs to a maximum of 1 MiB (bio chaining affects this too) * the SCSI LLD maximum number of scatter gather entries reported in /sys/block/sdNN/queue/max_segments and /sys/block/sdNN/queue/max_segment_size creates a limit based on how fragmented the data buffer is in virtual memory * the Block Limits VPD page MAXIMUM TRANSFER LENGTH field indicates the maximum transfer size for one command over the SCSI transport protocol supported by the drive itself The patch let 1 MiB IOs flow through the stack, which is a better fit for modern strip sizes than 512 KiB. Software using large IOs must be prepared for long latencies in exchange for the potential bandwidth gains, and must use a low (but greater than 1) queue depth to keep the IOs flowing back-to-back. Are you finding real software generating such IOs but relying on the storage stack to break them up for decent performance? Your fio script is using the sync IO engine, which means no queuing. This forces a turnaround time between IOs, preventing the device from looking ahead to see what's next (for sequential IOs, probably continuing data transfers with minimal delay). If the storage stack breaks up large sync IOs, the drive might be better at detecting that the access pattern is sequential (e.g., the gaps are between every set of 2 IOs rather than every IO). This is very drive-specific. If we have to go back to that artificial limit, then modern drivers (e.g., blk-mq capable drivers) need a way to raise the default; relying on users to change the sysfs settings means they're usually not changed. --- Robert Elliott, HP Server Storage -- 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 2/8] pm80xx: Corrected device state changes in I_T_Nexus_Reset
On Wed, Jul 29, 2015 at 9:40 PM, Tomas Henzl wrote:
> On 29.7.2015 08:27, viswa...@pmcs.com wrote:
>> From: Viswas G
>>
>> In Nexus reset the device state set to DS_IN_RECOVERY before doing
>> phy reset and internal cleanup. Once internal cleanup finishes,
>> the device state will set to DS_OPERATIONAL.
>>
>> Signed-off-by: Viswas G
>> Signed-off-by: Suresh Thiagarajan
>> ---
>> drivers/scsi/pm8001/pm8001_sas.c | 14 +++---
>> drivers/scsi/pm8001/pm8001_sas.h |8
>> 2 files changed, 19 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/scsi/pm8001/pm8001_sas.c
>> b/drivers/scsi/pm8001/pm8001_sas.c
>> index b93f289..4e6955f 100644
>> --- a/drivers/scsi/pm8001/pm8001_sas.c
>> +++ b/drivers/scsi/pm8001/pm8001_sas.c
>> @@ -980,13 +980,21 @@ int pm8001_I_T_nexus_reset(struct domain_device *dev)
>> rc = 0;
>> goto out;
>> }
>> + pm8001_dev->setds_completion = &completion_setstate;
>> + PM8001_CHIP_DISP->set_dev_state_req(pm8001_ha,
>> + pm8001_dev, DS_IN_RECOVERY);
>> + wait_for_completion(&completion_setstate);
>> rc = sas_phy_reset(phy, 1);
>> msleep(2000);
>> + if (rc) {
>> + PM8001_EH_DBG(pm8001_ha,
>> + pm8001_printk("phy reset failed for device %x\n"
>> + "with rc %d\n", pm8001_dev->device_id, rc));
>> + }
>> rc = pm8001_exec_internal_task_abort(pm8001_ha, pm8001_dev ,
>> dev, 1, 0);
>> - pm8001_dev->setds_completion = &completion_setstate;
>> - rc = PM8001_CHIP_DISP->set_dev_state_req(pm8001_ha,
>> - pm8001_dev, 0x01);
>> + PM8001_CHIP_DISP->set_dev_state_req(pm8001_ha,
>> + pm8001_dev, DS_OPERATIONAL);
> Hi Viswas,
> the set_dev_state_req can't fail any more ? Also the
> pm8001_exec_internal_task_abort may fail - shouldn't
> be error handling also added ?
> Cheers,
> Tomas
Hi Tomas,
The set_dev_state can fail if the ccb/Inbound queue slot is not available. It
can happen
If there are more than 256 requests are penning with controller.
Internal task abort failure also can be handled. Will resent the patch with
these changes.
Regards,
Viswas G
>> wait_for_completion(&completion_setstate);
>> } else {
>> rc = sas_phy_reset(phy, 1);
>> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
>> b/drivers/scsi/pm8001/pm8001_sas.h
>> index 8dd8b78..c9736cc 100644
>> --- a/drivers/scsi/pm8001/pm8001_sas.h
>> +++ b/drivers/scsi/pm8001/pm8001_sas.h
>> @@ -569,6 +569,14 @@ struct pm8001_fw_image_header {
>> #define NCQ_READ_LOG_FLAG 0x8000
>> #define NCQ_ABORT_ALL_FLAG 0x4000
>> #define NCQ_2ND_RLE_FLAG0x2000
>> +
>> +/* Device states */
>> +#define DS_OPERATIONAL 0x01
>> +#define DS_PORT_IN_RESET 0x02
>> +#define DS_IN_RECOVERY 0x03
>> +#define DS_IN_ERROR 0x04
>> +#define DS_NON_OPERATIONAL 0x07
>> +
>> /**
>> * brief param structure for firmware flash update.
>> */
>>
>
> --
> 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
-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Wednesday, July 29, 2015 9:40 PM
To: Viswas G; linux-scsi@vger.kernel.org
Cc: xjtu...@gmail.com; jbottom...@parallels.com; Suresh Thiagarajan
Subject: Re: [PATCH 2/8] pm80xx: Corrected device state changes in
I_T_Nexus_Reset
On 29.7.2015 08:27, viswa...@pmcs.com wrote:
> From: Viswas G
>
> In Nexus reset the device state set to DS_IN_RECOVERY before doing phy
> reset and internal cleanup. Once internal cleanup finishes, the device
> state will set to DS_OPERATIONAL.
>
> Signed-off-by: Viswas G
> Signed-off-by: Suresh Thiagarajan
> ---
> drivers/scsi/pm8001/pm8001_sas.c | 14 +++---
> drivers/scsi/pm8001/pm8001_sas.h |8
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_sas.c
> b/drivers/scsi/pm8001/pm8001_sas.c
> index b93f289..4e6955f 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -980,13 +980,21 @@ int pm8001_I_T_nexus_reset(struct domain_device *dev)
> rc = 0;
> goto out;
> }
> + pm8001_dev->setds_completion = &completion_setstate;
> + PM8001_CHIP_DISP->set_dev_state_req(pm8001_ha,
> + pm8001_dev, DS_IN_RECOVERY);
> + wait_for_completion(&completion_setstate);
> rc = sas_phy_reset(phy, 1);
>
[PATCH] target: Wait RCU grace-period before backend/fabric unload
From: Nicholas Bellinger
This patch addresses a v4.2-rc1 regression where backend driver
struct module unload immediately after ->free_device() has done
an internal call_rcu(), results in IRQ rcu_process_callbacks()
use-after-free paging OOPsen.
It adds a explicit synchronize_rcu() in target_backend_unregister()
to wait a full RCU grace period before releasing target_backend_ops
memory, and allowing TBO->module exit to proceed.
Also, go ahead and do the same for target_unregister_template()
to ensure se_deve_entry->rcu_head -> kfree_rcu() grace period has
passed, before allowing target_core_fabric_ops->owner module exit
to proceed.
Cc: Paul E. McKenney
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_configfs.c | 10 +-
drivers/target/target_core_hba.c | 10 +-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/target/target_core_configfs.c
b/drivers/target/target_core_configfs.c
index c2e9fea..b4c3ae0 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -457,8 +457,16 @@ void target_unregister_template(const struct
target_core_fabric_ops *fo)
if (!strcmp(t->tf_ops->name, fo->name)) {
BUG_ON(atomic_read(&t->tf_access_cnt));
list_del(&t->tf_list);
+ mutex_unlock(&g_tf_lock);
+ /*
+* Allow any outstanding fabric se_deve_entry->rcu_head
+* grace periods to expire post kfree_rcu(), before
allowing
+* fabric driver unload of
target_core_fabric_ops->module
+* to proceed.
+*/
+ synchronize_rcu();
kfree(t);
- break;
+ return;
}
}
mutex_unlock(&g_tf_lock);
diff --git a/drivers/target/target_core_hba.c b/drivers/target/target_core_hba.c
index 62ea4e8..0fb830b 100644
--- a/drivers/target/target_core_hba.c
+++ b/drivers/target/target_core_hba.c
@@ -84,8 +84,16 @@ void target_backend_unregister(const struct
target_backend_ops *ops)
list_for_each_entry(tb, &backend_list, list) {
if (tb->ops == ops) {
list_del(&tb->list);
+ mutex_unlock(&backend_mutex);
+ /*
+* Allow any outstanding backend driver ->rcu_head grace
+* period to expire post ->free_device() -> call_rcu(),
+* before allowing backend driver module unload of
+* target_backend_ops->owner to proceed.
+*/
+ synchronize_rcu();
kfree(tb);
- break;
+ return;
}
}
mutex_unlock(&backend_mutex);
--
1.9.1
--
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] scsi: pmcraid: trivial typo in printk
On 07/29/2015 08:39 PM, Joe Perches wrote: > Trivial typo fixes: > > o \b should be \n > o coalesce format to avoid excess spaces > > Signed-off-by: Joe Perches > --- Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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] [SCSI] atp870u: 64 bit bug in probe()
On 07/29/2015 11:36 PM, Dan Carpenter wrote: > On 64 bit CPUs there is a memory corruption bug on probe(). It should > be a u32 pointer instead of an unsigned long pointer or we write past > the end of the setupdata[] array. > > Signed-off-by: Dan Carpenter > --- > Someone reported in 2003 that probe has a NULL deref so maybe it's > related to this memory corruption? > https://bugzilla.kernel.org/show_bug.cgi?id=1118 > > If only we had applied this patch when I originally sent it two years > ago, then it would only be 10 years too late instead of 12! :P > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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] scsi: a100u2w: trivial typo in printk
On 07/29/2015 08:19 PM, Colin King wrote: > From: Colin Ian King > > Trivial typo fix, \b should be \n > > Signed-off-by: Colin Ian King > --- Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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
