Received-SPF: pass (google.com: domain of linux-wireless+bounces-2367-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <7615dcfe-4363-4d00-aac0-510c279f6b96@bootlin.com>
Date: Tue, 23 Jan 2024 10:16:48 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: RFQ: wifi: wilc1000: make wilc1000-spi bus-probe useful
Content-Language: en-US
To: David Mosberger-Tang <davidm@egauge.net>, Ajay.Kathat@microchip.com
Cc: linux-wireless@vger.kernel.org, kvalo@kernel.org
References: <90fb762e5840f9d5a6ae46f81692fb947a7796a4.camel@egauge.net>
 <e17d654a-8bd5-4327-8bf2-ad81c2f7355b@bootlin.com>
 <5ff15ae65ccb7c144ba8e0f07dc2ac25bd8b2b42.camel@egauge.net>
From: =?UTF-8?Q?Alexis_Lothor=C3=A9?= <alexis.lothore@bootlin.com>
In-Reply-To: <5ff15ae65ccb7c144ba8e0f07dc2ac25bd8b2b42.camel@egauge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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).

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com