From: Kalle Valo <kvalo@kernel.org>
To: "Alexis Lothoré" <alexis.lothore@bootlin.com>
Cc: David Mosberger-Tang <davidm@egauge.net>,
Ajay.Kathat@microchip.com, linux-wireless@vger.kernel.org
Subject: Re: RFQ: wifi: wilc1000: make wilc1000-spi bus-probe useful
Date: Tue, 23 Jan 2024 11:28:36 +0200 [thread overview]
Message-ID: <877ck02ybf.fsf@kernel.org> (raw)
In-Reply-To: <7615dcfe-4363-4d00-aac0-510c279f6b96@bootlin.com> ("Alexis Lothoré"'s message of "Tue, 23 Jan 2024 10:16:48 +0100")
Alexis Lothoré <alexis.lothore@bootlin.com> writes:
> Hello David,
> just reacting to your answers, but I will take a look at your updated patch
>
> On 1/22/24 21:41, David Mosberger-Tang wrote:
>> Alexis,
>>
>> Thanks for your feedback!
>>
>> On Mon, 2024-01-22 at 15:19 +0100, Alexis Lothoré wrote:
>>> Hello,
>>>
>>> On 1/19/24 22:51, David Mosberger-Tang wrote:
>
> [...]
>
>>>> + if (ret) {
>>>> + ret = -ENODEV;
>>>
>>> I would keep wilc_spi_configure_bus_protocol original error instead of
>>> rewriting/forcing it to -ENODEV here. I mean, if something fails in
>>> wilc_spi_configure_bus_protocol but not right at the first attempt to
>>> communicate with the chip, it does not translate automatically to an absence of
>>> chip, right ?
>>
>> Hmmh, I'm happy to change it, but, as it happens, all failure returns in
>> wilc_spi_configure_bus_protocol() basically mean that the device isn't present
>> or a device is present which the driver doesn't support, so I think -ENODEV is
>> more useful than returning -EINVAL (as would be the case). Let me know if you
>> still think I should change it.
>
> Yeah, but then I would change wilc_spi_configure_bus_protocol() to return
> -ENODEV instead of -EINVAL, if that's really the cause, and just let calling
> functions propagate it. That may just be a personal taste, but I find it pretty
> tedious to debug some error code and eventually realize that some intermediate
> function just rewrote the real error to another one (and sometime, loosing some
> info while doing so).
Yeah, changing error values is very much discouraged.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2024-01-23 9:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 21:51 RFQ: wifi: wilc1000: make wilc1000-spi bus-probe useful David Mosberger-Tang
2024-01-22 14:19 ` Alexis Lothoré
2024-01-22 20:41 ` David Mosberger-Tang
2024-01-22 21:13 ` David Mosberger-Tang
2024-01-22 21:13 ` [PATCH] wifi: wilc1000: validate chip id during bus probe David Mosberger-Tang
2024-01-22 22:01 ` David Mosberger-Tang
2024-01-22 22:03 ` David Mosberger-Tang
2024-01-23 10:18 ` Alexis Lothoré
2024-01-23 11:06 ` Kalle Valo
2024-01-23 12:44 ` Alexis Lothoré
2024-01-23 12:59 ` Kalle Valo
2024-01-23 13:29 ` Alexis Lothoré
2024-01-23 17:39 ` David Mosberger-Tang
2024-01-24 9:01 ` Alexis Lothoré
2024-01-24 16:15 ` David Mosberger-Tang
2024-01-24 17:31 ` David Mosberger-Tang
2024-01-24 18:45 ` David Mosberger-Tang
2024-01-25 6:23 ` Ajay.Kathat
2024-01-25 11:04 ` Alexis Lothoré
2024-01-25 17:15 ` Ajay.Kathat
2024-01-25 19:17 ` David Mosberger-Tang
2024-01-23 9:16 ` RFQ: wifi: wilc1000: make wilc1000-spi bus-probe useful Alexis Lothoré
2024-01-23 9:28 ` Kalle Valo [this message]
2024-01-22 16:57 ` Ajay.Kathat
2024-01-22 20:44 ` David Mosberger-Tang
2024-01-23 6:31 ` Kalle Valo
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=877ck02ybf.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.