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: <260a505e-53ec-4f1d-94fe-2b71af48f1b7@denx.de>
Date: Fri, 15 Nov 2024 15:33:30 +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 5:10 PM, Marek Vasut wrote:
> 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.

Are there any news ?