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: <b61b5b11-b078-4cf5-bb40-7c3ff8ffa972@microchip.com>
Date: Fri, 15 Nov 2024 20:04:03 +0000
From: <Ajay.Kathat@...rochip.com>
To: <marex@...x.de>, <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

Hi Marek,

On 11/15/24 07:33, Marek Vasut wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> 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 ?

I did test the same procedure in my setup, but I couldn't reproduce this issue
even after running it for a long duration. In my test setup, I used the
sama5d27-som1-ek1 host and wilc3000 firmware version 16.3.

I think this issue could be related to the host MMCI controller driver.
Normally, the wilc SDIO bus failures are captured by driver logs with an error
code (e.g., timeout), but if the MMCI controller is outputting the warning
message, then the error could be related to it. Does the MMCI controller error
point to any specific function? Which host was used to test this scenario, and
is it possible to test with different host or different configuration on the
same host, like disabling power save on the host?


Regards,
Ajay

Regards,
Ajay