All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: haver <haver@linux.vnet.ibm.com>
Cc: arnd@arndb.de, gregkh@linuxfoundation.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Michael Jung <mijung@gmx.net>,
	Michael Ruettger <michael@ibmra.de>,
	Frank Haverkamp <haver@linux.ibm.com>,
	Joerg-Stephan Vogt <jsvogt@de.ibm.com>
Subject: Re: [PATCH 17/20] misc: genwqe: card_base: Do not pass unused argument 'fatal_err'
Date: Tue, 30 Jun 2020 15:00:38 +0100	[thread overview]
Message-ID: <20200630140038.GN1179328@dell> (raw)
In-Reply-To: <235f96392b5a2f06b4410e9532b1322b@linux.vnet.ibm.com>

On Tue, 30 Jun 2020, haver wrote:

> On 2020-06-30 11:10, Lee Jones wrote:
> > On Tue, 30 Jun 2020, haver wrote:
> > 
> > > On 2020-06-29 16:04, Lee Jones wrote:
> > > > 'fatal_err' is taken as an argument to a static function which is only
> > > > invoked once.  During this invocation 'fatal_err' is not set.  There
> > > > doesn't appear to be a good reason to keep it around.
> > > >
> > > > Also fixes the following W=1 kernel build warning:
> > > >
> > > >  drivers/misc/genwqe/card_base.c:588: warning: Function parameter or
> > > > member 'fatal_err' not described in 'genwqe_recover_card'
> > > >
> > > > Cc: Michael Jung <mijung@gmx.net>
> > > > Cc: Michael Ruettger <michael@ibmra.de>
> > > > Cc: Frank Haverkamp <haver@linux.ibm.com>
> > > > Cc: Joerg-Stephan Vogt <jsvogt@de.ibm.com>
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > ---
> > > >  drivers/misc/genwqe/card_base.c | 18 +++---------------
> > > >  1 file changed, 3 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/misc/genwqe/card_base.c
> > > > b/drivers/misc/genwqe/card_base.c
> > > > index bceebf49de2d5..809a6f46f6de3 100644
> > > > --- a/drivers/misc/genwqe/card_base.c
> > > > +++ b/drivers/misc/genwqe/card_base.c
> > > > @@ -569,30 +569,18 @@ static int genwqe_stop(struct genwqe_dev *cd)
> > > >
> > > >  /**
> > > >   * genwqe_recover_card() - Try to recover the card if it is possible
> > > > - *
> > > > - * If fatal_err is set no register access is possible anymore. It is
> > > > - * likely that genwqe_start fails in that situation. Proper error
> > > > - * handling is required in this case.
> > > > + * @cd: GenWQE device information
> > > >   *
> > > >   * genwqe_bus_reset() will cause the pci code to call genwqe_remove()
> > > >   * and later genwqe_probe() for all virtual functions.
> > > >   */
> > > > -static int genwqe_recover_card(struct genwqe_dev *cd, int fatal_err)
> > > > +static int genwqe_recover_card(struct genwqe_dev *cd)
> > > >  {
> > > >  	int rc;
> > > >  	struct pci_dev *pci_dev = cd->pci_dev;
> > > >
> > > >  	genwqe_stop(cd);
> > > >
> > > > -	/*
> > > > -	 * Make sure chip is not reloaded to maintain FFDC. Write SLU
> > > > -	 * Reset Register, CPLDReset field to 0.
> > > > -	 */
> > > > -	if (!fatal_err) {
> > > > -		cd->softreset = 0x70ull;
> > > > -		__genwqe_writeq(cd, IO_SLC_CFGREG_SOFTRESET, cd->softreset);
> > > > -	}
> > > > -
> > > >  	rc = genwqe_bus_reset(cd);
> > > >  	if (rc != 0) {
> > > >  		dev_err(&pci_dev->dev,
> > > > @@ -958,7 +946,7 @@ static int genwqe_health_thread(void *data)
> > > >
> > > >  			cd->card_state = GENWQE_CARD_FATAL_ERROR;
> > > >
> > > > -			rc = genwqe_recover_card(cd, 0);
> > > > +			rc = genwqe_recover_card(cd);
> > > >  			if (rc < 0) {
> > > >  				/* FIXME Card is unusable and needs unbind! */
> > > >  				goto fatal_error;
> > > 
> > > I think this one I want to keep. Since fatal_err is 0, !fatal_error
> > > is 1 and
> > > the register write is actually executed.
> > 
> > Ah yes, good catch.
> > 
> > What if we *always* did instead then?
> 
> I knew you would ask that ;-).
> 
> > 
> > > I also want to keep the parameter even though it is only used with
> > > 0. The
> > > register bit causes a less drastic recovery, but if we would
> > > discover that
> > > that is not working ok, we rather discard the debug data we get in
> > > this case
> > > instead of letting the recovery fail. I think it does not hurt to
> > > keep it.
> > 
> > I'm not 100% against it, but it is dead code.
> > 
> > > Maybe you can add a comment?
> > 
> > If you really want to keep it, I can just update the kerneldoc
> > instead.
> 
> I prefer that option. I want to indicate that there are two possible ways to
> recover on a problem. If we delete the currently not exploited parameter,
> this information gets lost.

That's fine.  Will fix.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: haver <haver@linux.vnet.ibm.com>
Cc: Joerg-Stephan Vogt <jsvogt@de.ibm.com>,
	arnd@arndb.de, gregkh@linuxfoundation.org,
	Frank Haverkamp <haver@linux.ibm.com>,
	Michael Jung <mijung@gmx.net>,
	linux-kernel@vger.kernel.org, Michael Ruettger <michael@ibmra.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 17/20] misc: genwqe: card_base: Do not pass unused argument 'fatal_err'
Date: Tue, 30 Jun 2020 15:00:38 +0100	[thread overview]
Message-ID: <20200630140038.GN1179328@dell> (raw)
In-Reply-To: <235f96392b5a2f06b4410e9532b1322b@linux.vnet.ibm.com>

On Tue, 30 Jun 2020, haver wrote:

> On 2020-06-30 11:10, Lee Jones wrote:
> > On Tue, 30 Jun 2020, haver wrote:
> > 
> > > On 2020-06-29 16:04, Lee Jones wrote:
> > > > 'fatal_err' is taken as an argument to a static function which is only
> > > > invoked once.  During this invocation 'fatal_err' is not set.  There
> > > > doesn't appear to be a good reason to keep it around.
> > > >
> > > > Also fixes the following W=1 kernel build warning:
> > > >
> > > >  drivers/misc/genwqe/card_base.c:588: warning: Function parameter or
> > > > member 'fatal_err' not described in 'genwqe_recover_card'
> > > >
> > > > Cc: Michael Jung <mijung@gmx.net>
> > > > Cc: Michael Ruettger <michael@ibmra.de>
> > > > Cc: Frank Haverkamp <haver@linux.ibm.com>
> > > > Cc: Joerg-Stephan Vogt <jsvogt@de.ibm.com>
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > ---
> > > >  drivers/misc/genwqe/card_base.c | 18 +++---------------
> > > >  1 file changed, 3 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/misc/genwqe/card_base.c
> > > > b/drivers/misc/genwqe/card_base.c
> > > > index bceebf49de2d5..809a6f46f6de3 100644
> > > > --- a/drivers/misc/genwqe/card_base.c
> > > > +++ b/drivers/misc/genwqe/card_base.c
> > > > @@ -569,30 +569,18 @@ static int genwqe_stop(struct genwqe_dev *cd)
> > > >
> > > >  /**
> > > >   * genwqe_recover_card() - Try to recover the card if it is possible
> > > > - *
> > > > - * If fatal_err is set no register access is possible anymore. It is
> > > > - * likely that genwqe_start fails in that situation. Proper error
> > > > - * handling is required in this case.
> > > > + * @cd: GenWQE device information
> > > >   *
> > > >   * genwqe_bus_reset() will cause the pci code to call genwqe_remove()
> > > >   * and later genwqe_probe() for all virtual functions.
> > > >   */
> > > > -static int genwqe_recover_card(struct genwqe_dev *cd, int fatal_err)
> > > > +static int genwqe_recover_card(struct genwqe_dev *cd)
> > > >  {
> > > >  	int rc;
> > > >  	struct pci_dev *pci_dev = cd->pci_dev;
> > > >
> > > >  	genwqe_stop(cd);
> > > >
> > > > -	/*
> > > > -	 * Make sure chip is not reloaded to maintain FFDC. Write SLU
> > > > -	 * Reset Register, CPLDReset field to 0.
> > > > -	 */
> > > > -	if (!fatal_err) {
> > > > -		cd->softreset = 0x70ull;
> > > > -		__genwqe_writeq(cd, IO_SLC_CFGREG_SOFTRESET, cd->softreset);
> > > > -	}
> > > > -
> > > >  	rc = genwqe_bus_reset(cd);
> > > >  	if (rc != 0) {
> > > >  		dev_err(&pci_dev->dev,
> > > > @@ -958,7 +946,7 @@ static int genwqe_health_thread(void *data)
> > > >
> > > >  			cd->card_state = GENWQE_CARD_FATAL_ERROR;
> > > >
> > > > -			rc = genwqe_recover_card(cd, 0);
> > > > +			rc = genwqe_recover_card(cd);
> > > >  			if (rc < 0) {
> > > >  				/* FIXME Card is unusable and needs unbind! */
> > > >  				goto fatal_error;
> > > 
> > > I think this one I want to keep. Since fatal_err is 0, !fatal_error
> > > is 1 and
> > > the register write is actually executed.
> > 
> > Ah yes, good catch.
> > 
> > What if we *always* did instead then?
> 
> I knew you would ask that ;-).
> 
> > 
> > > I also want to keep the parameter even though it is only used with
> > > 0. The
> > > register bit causes a less drastic recovery, but if we would
> > > discover that
> > > that is not working ok, we rather discard the debug data we get in
> > > this case
> > > instead of letting the recovery fail. I think it does not hurt to
> > > keep it.
> > 
> > I'm not 100% against it, but it is dead code.
> > 
> > > Maybe you can add a comment?
> > 
> > If you really want to keep it, I can just update the kerneldoc
> > instead.
> 
> I prefer that option. I want to indicate that there are two possible ways to
> recover on a problem. If we delete the currently not exploited parameter,
> this information gets lost.

That's fine.  Will fix.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-06-30 14:00 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-29 14:04 [PATCH 00/20] Fix a bunch more W=1 warnings in Misc Lee Jones
2020-06-29 14:04 ` Lee Jones
2020-06-29 14:04 ` [PATCH 01/20] misc: pti: Repair kerneldoc formatting issues Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:04 ` [PATCH 02/20] misc: pti: Remove unparsable empty line in function header Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:04 ` [PATCH 03/20] misc: habanalabs: firmware_if: Add missing 'fw_name' and 'dst' entries to " Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:57   ` Oded Gabbay
2020-06-29 14:57     ` Oded Gabbay
2020-06-29 14:04 ` [PATCH 04/20] misc: habanalabs: pci: Fix a variety of kerneldoc issues Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:58   ` Oded Gabbay
2020-06-29 14:58     ` Oded Gabbay
2020-06-29 14:04 ` [PATCH 05/20] misc: habanalabs: irq: Repair kerneldoc formatting issues Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:59   ` Oded Gabbay
2020-06-29 14:59     ` Oded Gabbay
2020-06-29 14:04 ` [PATCH 06/20] misc: habanalabs: goya: Omit pointless check ensuring addr is >=0 Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 15:00   ` Oded Gabbay
2020-06-29 15:00     ` Oded Gabbay
2020-06-29 14:04 ` [PATCH 07/20] misc: habanalabs: pci: Scrub documentation for non-present function argument Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 15:00   ` Oded Gabbay
2020-06-29 15:00     ` Oded Gabbay
2020-06-29 14:04 ` [PATCH 08/20] misc: habanalabs: goya: goya_coresight: Remove set but unused variable 'val' Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 15:01   ` Oded Gabbay
2020-06-29 15:01     ` Oded Gabbay
2020-06-29 14:04 ` [PATCH 09/20] misc: habanalabs: gaudi: Remove ill placed asterisk from kerneldoc header Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 15:01   ` Oded Gabbay
2020-06-29 15:01     ` Oded Gabbay
2020-06-29 14:04 ` [PATCH 10/20] misc: habanalabs: gaudi: gaudi_security: Repair incorrectly named function arg Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 15:02   ` Oded Gabbay
2020-06-29 15:02     ` Oded Gabbay
2020-06-29 16:23   ` [PATCH v2 " Lee Jones
2020-06-29 16:23     ` Lee Jones
2020-06-29 14:04 ` [PATCH 11/20] misc: enclosure: Fix some kerneldoc anomalies Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:04 ` [PATCH 12/20] misc: lattice-ecp3-config: Remove set but clearly unused variable 'ret' Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:04 ` [PATCH 13/20] misc: pch_phub: Provide descriptions for 'chip' argument Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:04 ` [PATCH 14/20] misc: pch_phub: Remove superfluous descriptions to non-existent args 'offset_address' Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:04 ` [PATCH 15/20] misc: enclosure: Update enclosure_remove_device() documentation to match reality Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-29 14:04 ` [PATCH 16/20] misc: genwqe: card_base: Remove set but unused variable 'rc' Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-30  7:17   ` haver
2020-06-30  7:17     ` haver
2020-06-30  7:42     ` Lee Jones
2020-06-30  7:42       ` Lee Jones
2020-06-30  8:03       ` haver
2020-06-30  8:03         ` haver
2020-06-30  8:12         ` Lee Jones
2020-06-30  8:12           ` Lee Jones
2020-06-29 14:04 ` [PATCH 17/20] misc: genwqe: card_base: Do not pass unused argument 'fatal_err' Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-30  7:35   ` haver
2020-06-30  7:35     ` haver
2020-06-30  9:10     ` Lee Jones
2020-06-30  9:10       ` Lee Jones
2020-06-30  9:54       ` haver
2020-06-30  9:54         ` haver
2020-06-30 14:00         ` Lee Jones [this message]
2020-06-30 14:00           ` Lee Jones
2020-06-29 14:04 ` [PATCH 18/20] misc: genwqe: card_base: Whole host of kerneldoc fixes Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-30  7:24   ` haver
2020-06-30  7:24     ` haver
2020-06-29 14:04 ` [PATCH 19/20] misc: genwqe: card_dev: " Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-30  7:25   ` haver
2020-06-30  7:25     ` haver
2020-06-29 14:04 ` [PATCH 20/20] misc: genwqe: card_utils: Whole a plethora of documentation issues Lee Jones
2020-06-29 14:04   ` Lee Jones
2020-06-30  7:26   ` haver
2020-06-30  7:26     ` haver

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=20200630140038.GN1179328@dell \
    --to=lee.jones@linaro.org \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=haver@linux.ibm.com \
    --cc=haver@linux.vnet.ibm.com \
    --cc=jsvogt@de.ibm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@ibmra.de \
    --cc=mijung@gmx.net \
    /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.