[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <182e449a-3e6d-4727-a538-6fd518ae75f8@denx.de>
Date: Tue, 27 Aug 2024 17:34:33 +0200
From: Marek Vasut <marex@...x.de>
To: Alexis Lothoré <alexis.lothore@...tlin.com>,
linux-wireless@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>,
Adham Abozaeid <adham.abozaeid@...rochip.com>,
Ajay Singh <ajay.kathat@...rochip.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>, Conor Dooley
<conor+dt@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Kalle Valo <kvalo@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH v2 2/4] wifi: wilc1000: Fold wilc_get_chipid() into wlan.c
On 8/27/24 9:51 AM, Alexis Lothoré wrote:
Hi,
>> +static u32 wilc_get_chipid(struct wilc *wilc)
>> +{
>> + u32 chipid = 0;
>> + u32 rfrevid = 0;
>> +
>> + if (wilc->chipid == 0) {
>> + wilc->hif_func->hif_read_reg(wilc, WILC_CHIPID, &chipid);
> If we search for WILC_CHIPID in the whole driver, there are still two places
> manually reading this register. Shouldn't those places also benefit from
> wilc_get_chipid ?
Both the one in wilc_wlan_start() and wilc_validate_chipid() look more
like some sort of communication check attempt, rather than reading out
the chipid for any sort of actual chip identification purpose. I could
simply remove those ?
>> + wilc->hif_func->hif_read_reg(wilc, WILC_RF_REVISION_ID,
>> + &rfrevid);
>> + if (!is_wilc1000(chipid)) {
>> + wilc->chipid = 0;
>
> While at it, since you have trimmed the update parameter, it would be nice to
> also fix this return value (ie make wilc_getchipid() not return 0 but a real
> error code if we can not read the chip id.
Fixed in V3, thanks .
Powered by blists - more mailing lists