From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomas Henzl Subject: Re: [PATCH] hpsa: dont meddle with hw which isn't ours (cciss) Date: Tue, 19 May 2015 13:13:30 +0200 Message-ID: <555B1ADA.3080809@redhat.com> References: <1427981154-27659-1-git-send-email-thenzl@redhat.com> <07F70BBF6832E34FA1C923241E8833AB486A9D96@BBYEXM01.pmc-sierra.internal> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:59389 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752829AbbESLNe (ORCPT ); Tue, 19 May 2015 07:13:34 -0400 In-Reply-To: <07F70BBF6832E34FA1C923241E8833AB486A9D96@BBYEXM01.pmc-sierra.internal> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Don Brace , "linux-scsi@vger.kernel.org" Cc: Scott Teel , Justin Lindley , Kevin Barnett 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 >> --- >> 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 >