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
prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).