linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomas Henzl <thenzl@redhat.com>
To: Don Brace <Don.Brace@pmcs.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Cc: Scott Teel <Scott.Teel@pmcs.com>,
	Justin Lindley <Justin.Lindley@pmcs.com>,
	Kevin Barnett <Kevin.Barnett@pmcs.com>
Subject: Re: [PATCH] hpsa: dont meddle with hw which isn't ours (cciss)
Date: Tue, 19 May 2015 13:13:30 +0200	[thread overview]
Message-ID: <555B1ADA.3080809@redhat.com> (raw)
In-Reply-To: <07F70BBF6832E34FA1C923241E8833AB486A9D96@BBYEXM01.pmc-sierra.internal>

On 05/18/2015 11:53 PM, Don Brace wrote:
> So, in the context of a kdump, you would like the hpsa driver to not manage kdump and allow the cciss driver to manage the kdump operation?
> 
> I.E. Is this for a controller managed by cciss in the normal kernel and the hpsa reference driver is managing kdump?
I'm not changing this - so what was managed by certain driver
in normal mode remains so in kdump.

This fixes a situation when there is cciss hw only.
When a kernel starts the hpsa driver is invoked
because of the wildcards in the pci-id table and tries
to talk to the hw even if the hw was _not_ meant for
hpsa. That (in kdump) makes the cciss driver later fail.
The cciss driver should be actually immune against this,
but it isn't.
This patch moves the pci-id check closer to the hpsa driver
start before it communicates with the hw.

> 
>> -----Original Message-----
>> From: Tomas Henzl [mailto:thenzl@redhat.com]
>> Sent: Thursday, April 02, 2015 8:26 AM
>> To: linux-scsi@vger.kernel.org
>> Cc: Don Brace; Scott Teel; Justin Lindley; Kevin Barnett
>> Subject: [PATCH] hpsa: dont meddle with hw which isn't ours (cciss)
>>
>> The hpsa driver touches the hardware before checking the pci-id table.
>> This way, especially in kdump, it may confuse the proper driver (cciss).
>>
>> Signed-off-by: Tomas Henzl <thenzl@redhat.com>
>> ---
>>  drivers/scsi/hpsa.c | 21 +++++++++++----------
>>  1 file changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
>> index bddb33d30f..c33a077636 100644
>> --- a/drivers/scsi/hpsa.c
>> +++ b/drivers/scsi/hpsa.c
>> @@ -6737,7 +6737,7 @@ static int controller_reset_failed(struct CfgTable
>> __iomem *cfgtable)
>>  /* This does a hard reset of the controller using PCI power management
>>   * states or the using the doorbell register.
>>   */
>> -static int hpsa_kdump_hard_reset_controller(struct pci_dev *pdev)
>> +static int hpsa_kdump_hard_reset_controller(struct pci_dev *pdev, u32
>> board_id)
>>  {
>>  	u64 cfg_offset;
>>  	u32 cfg_base_addr;
>> @@ -6748,7 +6748,6 @@ static int hpsa_kdump_hard_reset_controller(struct
>> pci_dev *pdev)
>>  	int rc;
>>  	struct CfgTable __iomem *cfgtable;
>>  	u32 use_doorbell;
>> -	u32 board_id;
>>  	u16 command_register;
>>
>>  	/* For controllers as old as the P600, this is very nearly
>> @@ -6764,11 +6763,6 @@ static int hpsa_kdump_hard_reset_controller(struct
>> pci_dev *pdev)
>>  	 * using the doorbell register.
>>  	 */
>>
>> -	rc = hpsa_lookup_board_id(pdev, &board_id);
>> -	if (rc < 0) {
>> -		dev_warn(&pdev->dev, "Board ID not found\n");
>> -		return rc;
>> -	}
>>  	if (!ctlr_is_resettable(board_id)) {
>>  		dev_warn(&pdev->dev, "Controller not resettable\n");
>>  		return -ENODEV;
>> @@ -7413,7 +7407,7 @@ static void hpsa_hba_inquiry(struct ctlr_info *h)
>>  	}
>>  }
>>
>> -static int hpsa_init_reset_devices(struct pci_dev *pdev)
>> +static int hpsa_init_reset_devices(struct pci_dev *pdev, u32 board_id)
>>  {
>>  	int rc, i;
>>  	void __iomem *vaddr;
>> @@ -7449,7 +7443,7 @@ static int hpsa_init_reset_devices(struct pci_dev
>> *pdev)
>>  	iounmap(vaddr);
>>
>>  	/* Reset the controller with a PCI power-cycle or via doorbell */
>> -	rc = hpsa_kdump_hard_reset_controller(pdev);
>> +	rc = hpsa_kdump_hard_reset_controller(pdev, board_id);
>>
>>  	/* -ENOTSUPP here means we cannot reset the controller
>>  	 * but it's already (and still) up and running in
>> @@ -7927,11 +7921,18 @@ static int hpsa_init_one(struct pci_dev *pdev, const
>> struct pci_device_id *ent)
>>  	struct ctlr_info *h;
>>  	int try_soft_reset = 0;
>>  	unsigned long flags;
>> +	u32 board_id;
>>
>>  	if (number_of_controllers == 0)
>>  		printk(KERN_INFO DRIVER_NAME "\n");
>>
>> -	rc = hpsa_init_reset_devices(pdev);
>> +	rc = hpsa_lookup_board_id(pdev, &board_id);
>> +	if (rc < 0) {
>> +		dev_warn(&pdev->dev, "Board ID not found\n");
>> +		return rc;
>> +	}
>> +
>> +	rc = hpsa_init_reset_devices(pdev, board_id);
>>  	if (rc) {
>>  		if (rc != -ENOTSUPP)
>>  			return rc;
>> --
>> 1.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2015-05-19 11:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-02 13:25 [PATCH] hpsa: dont meddle with hw which isn't ours (cciss) Tomas Henzl
2015-05-18 21:53 ` Don Brace
2015-05-19 11:13   ` Tomas Henzl [this message]
2015-05-19 19:00 ` Don Brace

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=555B1ADA.3080809@redhat.com \
    --to=thenzl@redhat.com \
    --cc=Don.Brace@pmcs.com \
    --cc=Justin.Lindley@pmcs.com \
    --cc=Kevin.Barnett@pmcs.com \
    --cc=Scott.Teel@pmcs.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).