From: Bjorn Helgaas <helgaas@kernel.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-pci@vger.kernel.org, "Oliver O'Halloran" <oohall@gmail.com>,
linuxppc-dev@lists.ozlabs.org,
"Paul Mackerras" <paulus@samba.org>
Subject: Re: [PATCH 2/2] powerpc/eeh: Use pcie_reset_state_t type in function arguments
Date: Thu, 24 Mar 2022 17:09:08 -0500 [thread overview]
Message-ID: <20220324220908.GA171268@bhelgaas> (raw)
In-Reply-To: <f55dba9c-f00f-3aa9-d84d-1cda2b660dcb@csgroup.eu>
On Thu, Mar 10, 2022 at 09:51:13AM +0100, Christophe Leroy wrote:
> Le 13/07/2021 à 02:25, Krzysztof Wilczyński a écrit :
> > The pcie_reset_state_t type has been introduced in the commit
> > f7bdd12d234d ("pci: New PCI-E reset API") along with the enum
> > pcie_reset_state, but it has never been used for anything else
> > other than to define the members of the enumeration set in the
> > enum pcie_reset_state.
> >
> > Thus, replace the direct use of enum pcie_reset_state in function
> > arguments and replace it with pcie_reset_state_t type so that the
> > argument type matches the type used in enum pcie_reset_state.
> >
> > Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
>
> I don't understand the purpose of this change. Does any tool like
> sparse of so reports an error here ?
>
> My feeling is that by doing this you loose the added value of using
> an enumerate.
>
> state is used in a switch/case, that's exactly what we expect from
> an enum.
I think this is true: in the patch below, we remove use of "enum
pcie_reset_state", so the compiler no longer knows that "state" is an
enum, and it cannot verify that "state" has a legal value in the
switch statement. And at least with "gcc -Wall", it looks like it
*does* complain in that case.
Whether that value is worthwhile, I don't know. AFAICT this is the
only place that uses "state", so there's not *much* value.
If we did apply the patch below, I think we could probably make "enum
pcie_reset_state" an anonymous enum instead, like the enum for
pci_channel_state_t.
But let's back up for a minute. This is only used in the
pci_set_pcie_reset_state() path, and that's only used by three
drivers: cxl, genwqe, and ipr, and obviously only on powerpc, since
that's the only arch that implements pcibios_set_pcie_reset_state().
What's special about them? Why do they need this and no other drivers
do? And why only on powerpc?
I wonder if that powerpc functionality could be implemented in some
way that's more integrated into the PCI core reset and error handling
framework.
> > ---
> > arch/powerpc/kernel/eeh.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> > index 3bbdcc86d01b..15485abb89ff 100644
> > --- a/arch/powerpc/kernel/eeh.c
> > +++ b/arch/powerpc/kernel/eeh.c
> > @@ -714,7 +714,7 @@ static void eeh_restore_dev_state(struct eeh_dev *edev, void *userdata)
> > * Return value:
> > * 0 if success
> > */
> > -int pcibios_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state state)
> > +int pcibios_set_pcie_reset_state(struct pci_dev *dev, pcie_reset_state_t state)
> > {
> > struct eeh_dev *edev = pci_dev_to_eeh_dev(dev);
> > struct eeh_pe *pe = eeh_dev_to_pe(edev);
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
linux-pci@vger.kernel.org, "Oliver O'Halloran" <oohall@gmail.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Paul Mackerras" <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] powerpc/eeh: Use pcie_reset_state_t type in function arguments
Date: Thu, 24 Mar 2022 17:09:08 -0500 [thread overview]
Message-ID: <20220324220908.GA171268@bhelgaas> (raw)
In-Reply-To: <f55dba9c-f00f-3aa9-d84d-1cda2b660dcb@csgroup.eu>
On Thu, Mar 10, 2022 at 09:51:13AM +0100, Christophe Leroy wrote:
> Le 13/07/2021 à 02:25, Krzysztof Wilczyński a écrit :
> > The pcie_reset_state_t type has been introduced in the commit
> > f7bdd12d234d ("pci: New PCI-E reset API") along with the enum
> > pcie_reset_state, but it has never been used for anything else
> > other than to define the members of the enumeration set in the
> > enum pcie_reset_state.
> >
> > Thus, replace the direct use of enum pcie_reset_state in function
> > arguments and replace it with pcie_reset_state_t type so that the
> > argument type matches the type used in enum pcie_reset_state.
> >
> > Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
>
> I don't understand the purpose of this change. Does any tool like
> sparse of so reports an error here ?
>
> My feeling is that by doing this you loose the added value of using
> an enumerate.
>
> state is used in a switch/case, that's exactly what we expect from
> an enum.
I think this is true: in the patch below, we remove use of "enum
pcie_reset_state", so the compiler no longer knows that "state" is an
enum, and it cannot verify that "state" has a legal value in the
switch statement. And at least with "gcc -Wall", it looks like it
*does* complain in that case.
Whether that value is worthwhile, I don't know. AFAICT this is the
only place that uses "state", so there's not *much* value.
If we did apply the patch below, I think we could probably make "enum
pcie_reset_state" an anonymous enum instead, like the enum for
pci_channel_state_t.
But let's back up for a minute. This is only used in the
pci_set_pcie_reset_state() path, and that's only used by three
drivers: cxl, genwqe, and ipr, and obviously only on powerpc, since
that's the only arch that implements pcibios_set_pcie_reset_state().
What's special about them? Why do they need this and no other drivers
do? And why only on powerpc?
I wonder if that powerpc functionality could be implemented in some
way that's more integrated into the PCI core reset and error handling
framework.
> > ---
> > arch/powerpc/kernel/eeh.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> > index 3bbdcc86d01b..15485abb89ff 100644
> > --- a/arch/powerpc/kernel/eeh.c
> > +++ b/arch/powerpc/kernel/eeh.c
> > @@ -714,7 +714,7 @@ static void eeh_restore_dev_state(struct eeh_dev *edev, void *userdata)
> > * Return value:
> > * 0 if success
> > */
> > -int pcibios_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state state)
> > +int pcibios_set_pcie_reset_state(struct pci_dev *dev, pcie_reset_state_t state)
> > {
> > struct eeh_dev *edev = pci_dev_to_eeh_dev(dev);
> > struct eeh_pe *pe = eeh_dev_to_pe(edev);
next prev parent reply other threads:[~2022-03-24 22:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-13 0:25 [PATCH 1/2] PCI: Use pcie_reset_state_t type in function arguments Krzysztof Wilczyński
2021-07-13 0:25 ` Krzysztof Wilczyński
2021-07-13 0:25 ` [PATCH 2/2] powerpc/eeh: " Krzysztof Wilczyński
2021-07-13 0:25 ` Krzysztof Wilczyński
2022-03-10 8:51 ` Christophe Leroy
2022-03-10 8:51 ` Christophe Leroy
2022-03-24 22:09 ` Bjorn Helgaas [this message]
2022-03-24 22:09 ` Bjorn Helgaas
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=20220324220908.GA171268@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=christophe.leroy@csgroup.eu \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=oohall@gmail.com \
--cc=paulus@samba.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 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.