netdev - Re: [PATCH] wifi: wilc1000: Rework bus locking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fcdfa93a-2db4-49ad-8947-ca43be329250@denx.de>
Date: Thu, 7 Nov 2024 17:10:13 +0100
From: Marek Vasut <marex@...x.de>
To: Ajay.Kathat@...rochip.com, alexis.lothore@...tlin.com,
 linux-wireless@...r.kernel.org
Cc: davem@...emloft.net, adham.abozaeid@...rochip.com,
 claudiu.beznea@...on.dev, conor+dt@...nel.org, edumazet@...gle.com,
 kuba@...nel.org, kvalo@...nel.org, krzk+dt@...nel.org, pabeni@...hat.com,
 robh@...nel.org, devicetree@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] wifi: wilc1000: Rework bus locking

On 11/7/24 2:28 AM, Ajay.Kathat@...rochip.com wrote:
> Hi Marek,

Hello Ajay,

> On 11/4/24 04:44, Marek Vasut wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> On 10/23/24 8:47 PM, Marek Vasut wrote:
>>
>> Hello again,
>>
>>>> Is power-save enabled during the test. With PS enabled, The SDIO
>>>> commands may
>>>> fail momentarily but it should recover.
>>>
>>> It seems it gets enabled after first ifconfig up, that's a good hint,
>>> I'll try to disable it and see if that makes them errors go away. Thanks!
>>>
>>> Do you have any details on WHY would such sporadic errors occur and how
>>> to make those go away even with PS enabled ?
>> Can you explain why does uAPSD (iw ...set power_save off) adversely
>> affect SDIO bus stability ?
>>
> 
> SDIO bus errors can occur for different reasons and those errors can be of
> recoverable or non-recoverable type. For non-recoverable failures like
> firmware crashes, the retry mechanism may not help to resolve the issue. If
> the error is recoverable then driver should work with retry attempts.
> I think you are observing the bus errors messages and it is recovering after
> that. Is my understanding correct?

I don't know. Is there any way to make the WILC firmware produce debug 
output , so we can figure out what is going on "on the other side" ?

Are you able to provide me (maybe off-list) some debug firmware build ?
(or can I get firmware sources and build and debug my own WILC firmware 
on the Cortus CPU?)

> With the previous shared test procedure, which makes the interface up/down
> continuously, the station may not go into the Doze/Awake sequence since that
> mode switching gets activated after connection with AP.

What does this mean ? I can trigger the SDIO errors even without being 
connected to any AP , so this is something between the WILC and the SDIO 
host, the radio is likely not involved , right ?

>> Can you explain how to prevent that or shall we disable uAPSD altogether ?
> 
> Could you please share the test procedure and logs. I am occupied at the
> moment but I shall make some time to look into it and get a better understanding.

The simplest test procedure is this:

$ while true ; do ifconfig wlan0 up ; ifconfig wlan0 down ; done

As for the logs, MMCI controller sporadically reports either Command or 
Data CRC error, so likely the SDIO response (from WILC to Host) is 
corrupted.