From: Bjorn Helgaas <helgaas@kernel.org> To: Vaibhav Gupta <vaibhavgupta40@gmail.com> Cc: Bjorn Helgaas <bhelgaas@google.com>, Bjorn Helgaas <bjorn@helgaas.com>, Vaibhav Gupta <vaibhav.varodek@gmail.com>, Adam Radford <aradford@gmail.com>, "James E.J. Bottomley" <jejb@linux.ibm.com>, "Martin K. Petersen" <martin.petersen@oracle.com>, Adaptec OEM Raid Solutions <aacraid@microsemi.com>, Hannes Reinecke <hare@suse.com>, Bradley Grove <linuxdrivers@attotech.com>, John Garry <john.garry@huawei.com>, Don Brace <don.brace@microsemi.com>, James Smart <james.smart@broadcom.com>, Dick Kennedy <dick.kennedy@broadcom.com>, Kashyap Desai <kashyap.desai@broadcom.com>, Sumit Saxena <sumit.saxena@broadcom.com>, Shivasharan S <shivasharan.srikanteshwara@broadcom.com>, Sathya Prakash <sathya.prakash@broadcom.com>, Sreekanth Reddy <sreekanth.reddy@broadcom.com>, Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>, Jack Wang <jinpu.wang@cloud.ionos.com>, Shuah Khan <skhan@linuxfoundation.org>, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linuxfoundation.org, linux-scsi@vger.kernel.org, esc.storagedev@microsemi.com, megaraidlinux.pdl@broadcom.com, MPT-FusionLinux.pdl@broadcom.com Subject: Re: [PATCH v2 01/15] scsi: megaraid_sas: use generic power management Date: Wed, 9 Sep 2020 08:23:32 -0500 [thread overview] Message-ID: <20200909132332.GA696701@bjorn-Precision-5520> (raw) In-Reply-To: <20200909100315.GA13015@gmail.com> On Wed, Sep 09, 2020 at 03:33:15PM +0530, Vaibhav Gupta wrote: > On Tue, Sep 08, 2020 at 12:32:09PM -0500, Bjorn Helgaas wrote: > > On Mon, Jul 20, 2020 at 07:04:14PM +0530, Vaibhav Gupta wrote: > > > With legacy PM hooks, it was the responsibility of a driver to manage PCI > > > states and also the device's power state. The generic approach is to let > > > the PCI core handle the work. > > > > > > PCI core passes "struct device*" as an argument to the .suspend() and > > > .resume() callbacks. As the .suspend() work with "struct instance*", > > > extract it from "struct device*" using dev_get_drv_data(). > > > > > > Driver was also using PCI helper functions like pci_save/restore_state(), > > > pci_disable/enable_device(), pci_set_power_state() and pci_enable_wake(). > > > They should not be invoked by the driver. > > > > > > Compile-tested only. > > > > > > Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com> > > > --- > > > drivers/scsi/megaraid/megaraid_sas_base.c | 61 ++++++----------------- > > > 1 file changed, 16 insertions(+), 45 deletions(-) > > > > > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c > > > index 00668335c2af..4a6ee7778977 100644 > > > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > > > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > > > @@ -7539,25 +7539,21 @@ static void megasas_shutdown_controller(struct megasas_instance *instance, > > > megasas_return_cmd(instance, cmd); > > > } > > > > > > -#ifdef CONFIG_PM > > > /** > > > * megasas_suspend - driver suspend entry point > > > - * @pdev: PCI device structure > > > - * @state: PCI power state to suspend routine > > > + * @dev: Device structure > > > */ > > > -static int > > > -megasas_suspend(struct pci_dev *pdev, pm_message_t state) > > > +static int __maybe_unused > > > +megasas_suspend(struct device *dev) > > > { > > > - struct megasas_instance *instance; > > > - > > > - instance = pci_get_drvdata(pdev); > > > + struct megasas_instance *instance = dev_get_drvdata(dev); > > > > > > if (!instance) > > > return 0; > > > > > > instance->unload = 1; > > > > > > - dev_info(&pdev->dev, "%s is called\n", __func__); > > > + dev_info(dev, "%s is called\n", __func__); > > > > > > /* Shutdown SR-IOV heartbeat timer */ > > > if (instance->requestorId && !instance->skip_heartbeat_timer_del) > > > @@ -7579,7 +7575,7 @@ megasas_suspend(struct pci_dev *pdev, pm_message_t state) > > > > > > tasklet_kill(&instance->isr_tasklet); > > > > > > - pci_set_drvdata(instance->pdev, instance); > > > + dev_set_drvdata(dev, instance); > > > > It *might* be correct to replace "instance->pdev" with "dev", but it's > > not obvious and deserves some explanation. It's true that you can > > replace &pdev->dev with dev, but I don't know anything about > > instance->dev. Sorry, I meant "instance->pdev" here. > > I don't think this change is actually necessary, is it? > > "instance->pdev" is still a pci_dev pointer, so pci_set_drvdata() > > should work fine. ... > > > There is no instance->dev . The 'dev' passed dev_set_drvdata() is > same &pdev->dev. Yes, it's true that "dev" here is the same as the "&pdev->dev" we had previously. But we passed "instance->pdev" (not "pdev") to pci_set_drvdata(). So the question is whether instance->pdev->dev == dev. They *might* be the same, but I don't think it's obvious. > The dev pointer used here, points to same value. > > pci_get_drvdata() and pci_set_drvdata() invoke dev_get_drvdata() and > dev_set_drvdata() respectively. And they do nothing else. Seems like > additional unnecessary function calls and operations.
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org> To: Vaibhav Gupta <vaibhavgupta40@gmail.com> Cc: Don Brace <don.brace@microsemi.com>, Vaibhav Gupta <vaibhav.varodek@gmail.com>, Bjorn Helgaas <bhelgaas@google.com>, Hannes Reinecke <hare@suse.com>, Bradley Grove <linuxdrivers@attotech.com>, linux-scsi@vger.kernel.org, Sathya Prakash <sathya.prakash@broadcom.com>, esc.storagedev@microsemi.com, James Smart <james.smart@broadcom.com>, Kashyap Desai <kashyap.desai@broadcom.com>, Jack Wang <jinpu.wang@cloud.ionos.com>, linux-kernel-mentees@lists.linuxfoundation.org, Dick Kennedy <dick.kennedy@broadcom.com>, Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>, "James E.J. Bottomley" <jejb@linux.ibm.com>, John Garry <john.garry@huawei.com>, Adam Radford <aradford@gmail.com>, Adaptec OEM Raid Solutions <aacraid@microsemi.com>, megaraidlinux.pdl@broadcom.com, Sreekanth Reddy <sreekanth.reddy@broadcom.com>, "Martin K. Petersen" <martin.petersen@oracle.com>, Shivasharan S <shivasharan.srikanteshwara@broadcom.com>, MPT-FusionLinux.pdl@broadcom.com, linux-kernel@vger.kernel.org, Sumit Saxena <sumit.saxena@broadcom.com> Subject: Re: [Linux-kernel-mentees] [PATCH v2 01/15] scsi: megaraid_sas: use generic power management Date: Wed, 9 Sep 2020 08:23:32 -0500 [thread overview] Message-ID: <20200909132332.GA696701@bjorn-Precision-5520> (raw) In-Reply-To: <20200909100315.GA13015@gmail.com> On Wed, Sep 09, 2020 at 03:33:15PM +0530, Vaibhav Gupta wrote: > On Tue, Sep 08, 2020 at 12:32:09PM -0500, Bjorn Helgaas wrote: > > On Mon, Jul 20, 2020 at 07:04:14PM +0530, Vaibhav Gupta wrote: > > > With legacy PM hooks, it was the responsibility of a driver to manage PCI > > > states and also the device's power state. The generic approach is to let > > > the PCI core handle the work. > > > > > > PCI core passes "struct device*" as an argument to the .suspend() and > > > .resume() callbacks. As the .suspend() work with "struct instance*", > > > extract it from "struct device*" using dev_get_drv_data(). > > > > > > Driver was also using PCI helper functions like pci_save/restore_state(), > > > pci_disable/enable_device(), pci_set_power_state() and pci_enable_wake(). > > > They should not be invoked by the driver. > > > > > > Compile-tested only. > > > > > > Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com> > > > --- > > > drivers/scsi/megaraid/megaraid_sas_base.c | 61 ++++++----------------- > > > 1 file changed, 16 insertions(+), 45 deletions(-) > > > > > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c > > > index 00668335c2af..4a6ee7778977 100644 > > > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > > > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > > > @@ -7539,25 +7539,21 @@ static void megasas_shutdown_controller(struct megasas_instance *instance, > > > megasas_return_cmd(instance, cmd); > > > } > > > > > > -#ifdef CONFIG_PM > > > /** > > > * megasas_suspend - driver suspend entry point > > > - * @pdev: PCI device structure > > > - * @state: PCI power state to suspend routine > > > + * @dev: Device structure > > > */ > > > -static int > > > -megasas_suspend(struct pci_dev *pdev, pm_message_t state) > > > +static int __maybe_unused > > > +megasas_suspend(struct device *dev) > > > { > > > - struct megasas_instance *instance; > > > - > > > - instance = pci_get_drvdata(pdev); > > > + struct megasas_instance *instance = dev_get_drvdata(dev); > > > > > > if (!instance) > > > return 0; > > > > > > instance->unload = 1; > > > > > > - dev_info(&pdev->dev, "%s is called\n", __func__); > > > + dev_info(dev, "%s is called\n", __func__); > > > > > > /* Shutdown SR-IOV heartbeat timer */ > > > if (instance->requestorId && !instance->skip_heartbeat_timer_del) > > > @@ -7579,7 +7575,7 @@ megasas_suspend(struct pci_dev *pdev, pm_message_t state) > > > > > > tasklet_kill(&instance->isr_tasklet); > > > > > > - pci_set_drvdata(instance->pdev, instance); > > > + dev_set_drvdata(dev, instance); > > > > It *might* be correct to replace "instance->pdev" with "dev", but it's > > not obvious and deserves some explanation. It's true that you can > > replace &pdev->dev with dev, but I don't know anything about > > instance->dev. Sorry, I meant "instance->pdev" here. > > I don't think this change is actually necessary, is it? > > "instance->pdev" is still a pci_dev pointer, so pci_set_drvdata() > > should work fine. ... > > > There is no instance->dev . The 'dev' passed dev_set_drvdata() is > same &pdev->dev. Yes, it's true that "dev" here is the same as the "&pdev->dev" we had previously. But we passed "instance->pdev" (not "pdev") to pci_set_drvdata(). So the question is whether instance->pdev->dev == dev. They *might* be the same, but I don't think it's obvious. > The dev pointer used here, points to same value. > > pci_get_drvdata() and pci_set_drvdata() invoke dev_get_drvdata() and > dev_set_drvdata() respectively. And they do nothing else. Seems like > additional unnecessary function calls and operations. _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
next prev parent reply other threads:[~2020-09-09 13:52 UTC|newest] Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-20 13:34 [PATCH v2 00/15] scsi: use generic power management Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 01/15] scsi: megaraid_sas: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 16:57 ` Vaibhav Gupta 2020-09-08 16:57 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 17:32 ` Bjorn Helgaas 2020-09-08 17:32 ` [Linux-kernel-mentees] " Bjorn Helgaas 2020-09-09 10:03 ` Vaibhav Gupta 2020-09-09 10:03 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-09 13:23 ` Bjorn Helgaas [this message] 2020-09-09 13:23 ` Bjorn Helgaas 2020-09-09 15:20 ` Vaibhav Gupta 2020-09-09 15:20 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-09 16:21 ` Bjorn Helgaas 2020-09-09 16:21 ` [Linux-kernel-mentees] " Bjorn Helgaas 2020-07-20 13:34 ` [PATCH v2 02/15] scsi: aacraid: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-23 6:58 ` Balsundar.P 2020-07-23 6:58 ` [Linux-kernel-mentees] " Balsundar.P--- via Linux-kernel-mentees 2020-09-08 16:58 ` Vaibhav Gupta 2020-09-08 16:58 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 03/15] scsi: aic7xxx: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 16:59 ` Vaibhav Gupta 2020-09-08 16:59 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 04/15] scsi: aic79xx: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 16:59 ` Vaibhav Gupta 2020-09-08 16:59 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 05/15] scsi: arcmsr: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 17:00 ` Vaibhav Gupta 2020-09-08 17:00 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 06/15] scsi: esas2r: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 17:01 ` Vaibhav Gupta 2020-09-08 17:01 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 07/15] scsi: hisi_sas_v3_hw: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-21 1:36 ` chenxiang (M) 2020-07-21 1:36 ` [Linux-kernel-mentees] " chenxiang (M) 2020-09-08 17:02 ` Vaibhav Gupta 2020-09-08 17:02 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 08/15] scsi: mpt3sas_scsih: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 17:03 ` Vaibhav Gupta 2020-09-08 17:03 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 09/15] scsi: lpfc: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 17:03 ` Vaibhav Gupta 2020-09-08 17:03 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 10/15] scsi: pm_8001: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-23 7:02 ` Jinpu Wang 2020-07-23 7:02 ` [Linux-kernel-mentees] " Jinpu Wang 2020-09-08 17:04 ` Vaibhav Gupta 2020-09-08 17:04 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 11/15] scsi: hpsa: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 22:23 ` Don.Brace 2020-07-20 22:23 ` [Linux-kernel-mentees] " Don.Brace--- via Linux-kernel-mentees 2020-09-08 17:05 ` Vaibhav Gupta 2020-09-08 17:05 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 12/15] scsi: 3w-9xxx: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 17:05 ` Vaibhav Gupta 2020-09-08 17:05 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 13/15] scsi: 3w-sas: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 17:06 ` Vaibhav Gupta 2020-09-08 17:06 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 14/15] scsi: mvumi: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 17:07 ` Vaibhav Gupta 2020-09-08 17:07 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-07-20 13:34 ` [PATCH v2 15/15] scsi: pmcraid: " Vaibhav Gupta 2020-07-20 13:34 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 17:08 ` Vaibhav Gupta 2020-09-08 17:08 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-08-17 8:16 ` [PATCH v2 00/15] scsi: " Vaibhav Gupta 2020-08-17 8:16 ` [Linux-kernel-mentees] " Vaibhav Gupta 2020-09-08 16:54 ` Vaibhav Gupta 2020-09-08 16:54 ` [Linux-kernel-mentees] " Vaibhav Gupta
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=20200909132332.GA696701@bjorn-Precision-5520 \ --to=helgaas@kernel.org \ --cc=MPT-FusionLinux.pdl@broadcom.com \ --cc=aacraid@microsemi.com \ --cc=aradford@gmail.com \ --cc=bhelgaas@google.com \ --cc=bjorn@helgaas.com \ --cc=dick.kennedy@broadcom.com \ --cc=don.brace@microsemi.com \ --cc=esc.storagedev@microsemi.com \ --cc=hare@suse.com \ --cc=james.smart@broadcom.com \ --cc=jejb@linux.ibm.com \ --cc=jinpu.wang@cloud.ionos.com \ --cc=john.garry@huawei.com \ --cc=kashyap.desai@broadcom.com \ --cc=linux-kernel-mentees@lists.linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=linuxdrivers@attotech.com \ --cc=martin.petersen@oracle.com \ --cc=megaraidlinux.pdl@broadcom.com \ --cc=sathya.prakash@broadcom.com \ --cc=shivasharan.srikanteshwara@broadcom.com \ --cc=skhan@linuxfoundation.org \ --cc=sreekanth.reddy@broadcom.com \ --cc=suganath-prabu.subramani@broadcom.com \ --cc=sumit.saxena@broadcom.com \ --cc=vaibhav.varodek@gmail.com \ --cc=vaibhavgupta40@gmail.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.