From: <Ajay.Kathat@microchip.com>
To: <alexis.lothore@bootlin.com>, <kvalo@kernel.org>
Cc: <linux-wireless@vger.kernel.org>, <claudiu.beznea@tuxon.dev>,
<davidm@egauge.net>, <thomas.petazzoni@bootlin.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/5] wifi: wilc1000: set preamble size to auto as default in wilc_init_fw_config()
Date: Fri, 19 Jan 2024 18:19:43 +0000 [thread overview]
Message-ID: <2a7cdcb3-03ef-46b8-8cda-e5d28801f6a0@microchip.com> (raw)
In-Reply-To: <b215909e-43c7-47b5-ac0b-2a194b55cb39@bootlin.com>
Hi Alexis,
On 1/19/24 00:43, Alexis Lothoré wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On 1/18/24 17:52, Ajay.Kathat@microchip.com wrote:
>> On 1/18/24 08:08, Alexis Lothoré wrote:
>
> [...]
>
>>> "WILC driver currently applies some default configuration whenever the firmware
>>> is initialized, and sets the default preamble size to short. However, despite
>>> this passed option, firmware is also able to successfully connect to access
>>> points only using long preamble, so this setting does not really enforce short
>>> preambles and is misleading regarding applied configuration.
>>>
>>> Update default configuration and make it match the firmware behavior by passing
>>> the existing WILC_FW_PREAMBLE_AUTO value (2 instead of 0). The updated setting
>>> does not really alter firmware behavior since it is still capable to connect to
>>> both short preamble and long preamble access points, but at list the setting now
>>> expresses for real the corresponding firmware behavior"
>>>
>>> To give a bit of context around this one: I do not have access to the firmware
>>> internals, I just took the patch from Ajay and I merely did some tests around it
>>> with multiple APs (basically, making a WILC STA connect and ping the AP), and
>>> ensured with wireshark to get at least one AP be really "locked" with long
>>> preamble, with WILC managing to connect to it.
>>>
>>
>> Here are some more details about this change. It have been implemented
>> to address the transmission(Tx) blackout issue observed in the 802.11b
>> mode. The modification has no impact on the other modes, which will
>> continue to work as they did in the previous implementation. This change
>> will allow the 802.11b transmission(2, 5.5, 11Mbps) to use long preamble.
>
> Ah, so it fixes a specific bug (and makes parts of my suggested description
> wrong). Has there been any report about this "TX blackout issue" on the mailing
> lists ? If so, we could enrich the message with some details from the report and
> add some missing Reported-By/Fixes/Closes tags.
>
For this issue, there are no details on the mailing lists. It was
discovered by internal QA team.
Regards,
Ajay
next prev parent reply other threads:[~2024-01-19 18:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 14:56 [PATCH 0/5] wifi: wilc1000: minor fixes Alexis Lothoré
2024-01-15 14:56 ` [PATCH 1/5] wifi: wilc1000: set preamble size to auto as default in wilc_init_fw_config() Alexis Lothoré
2024-01-18 9:31 ` Kalle Valo
2024-01-18 15:08 ` Alexis Lothoré
2024-01-18 16:52 ` Ajay.Kathat
2024-01-19 7:43 ` Alexis Lothoré
2024-01-19 18:19 ` Ajay.Kathat [this message]
2024-02-12 15:36 ` [1/5] " Kalle Valo
2024-01-15 14:56 ` [PATCH 2/5] wifi: wilc1000: fix driver_handler when committing initial configuration Alexis Lothoré
2024-01-18 9:35 ` Kalle Valo
2024-01-15 14:56 ` [PATCH 3/5] wilc: wifi: do not realloc workqueue everytime an interface is added Alexis Lothoré
2024-01-15 14:56 ` [PATCH 4/5] wifi: wilc1000: fix incorrect power down sequence Alexis Lothoré
2024-01-15 14:56 ` [PATCH 5/5] wifi: wilc1000: fix multi-vif management when deleting a vif Alexis Lothoré
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2a7cdcb3-03ef-46b8-8cda-e5d28801f6a0@microchip.com \
--to=ajay.kathat@microchip.com \
--cc=alexis.lothore@bootlin.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=davidm@egauge.net \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.