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
>
next prev parent 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).