All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: David Mosberger-Tang <davidm@egauge.net>
Cc: "Alexis Lothoré" <alexis.lothore@bootlin.com>,
	linux-wireless@vger.kernel.org, Ajay.Kathat@microchip.com
Subject: Re: [PATCH] [v4] wifi: wilc1000: validate chip id during bus probe
Date: Wed, 07 Feb 2024 13:41:01 +0200	[thread overview]
Message-ID: <871q9oqz76.fsf@kernel.org> (raw)
In-Reply-To: <706d5fde96f90078f80c7fb4fc88503d1791426f.camel@egauge.net> (David Mosberger-Tang's message of "Tue, 06 Feb 2024 21:52:42 -0700")

David Mosberger-Tang <davidm@egauge.net> writes:

> On Tue, 2024-01-30 at 10:06 +0100, Alexis Lothoré wrote:
>> On 1/27/24 01:43, David Mosberger-Tang wrote:
>> 
>> 
>> > @@ -1142,7 +1170,7 @@ static int wilc_spi_init(struct wilc *wilc, bool resume)
>> >  	}
>> >  	if (ret) {
>> >  		dev_err(&spi->dev, "Failed with CRC7 on and off.\n");
>> > -		return ret;
>> > +		return -ENODEV;
>> 
>> You are still rewriting error codes here. At a lower level, sure, but still...
>> When I suggested setting -ENODEV at lower level, I was thinking about places
>> where no explicit error code was already in use, but
>> spi_internal_read/spi_internal_write already generate proper error codes. Or am
>> I missing a constraint, like the probe chain really needing -ENODEV ?
>
> Lower-level errors are often not meaningful at the higher level.  For
> example, attempting to read a register over SPI may cause a CRC error
> if the device doesn't exist.  That would result in -EINVAL, even though
> there was nothing invalid about the read, it's just that the device
> wasn't there.

Changing the error values makes debugging harder so please avoid doing
it unless absolutely necessary (and then explain the reason in a code
comment).

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

      reply	other threads:[~2024-02-07 11:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-27  0:43 [PATCH] [v4] wifi: wilc1000: validate chip id during bus probe David Mosberger-Tang
2024-01-30  9:06 ` Alexis Lothoré
2024-02-01  2:55   ` Ajay.Kathat
2024-02-07  4:53     ` David Mosberger-Tang
2024-02-01 10:08   ` Kalle Valo
2024-02-07  4:59     ` David Mosberger-Tang
2024-02-07  4:52   ` David Mosberger-Tang
2024-02-07 11:41     ` Kalle Valo [this message]

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=871q9oqz76.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=Ajay.Kathat@microchip.com \
    --cc=alexis.lothore@bootlin.com \
    --cc=davidm@egauge.net \
    --cc=linux-wireless@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 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.