All of lore.kernel.org
 help / color / mirror / Atom feed
From: pradeepc@codeaurora.org
To: Sven Eckelmann <sven@narfation.org>
Cc: Ben Greear <greearb@candelatech.com>,
	linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
	Sebastian Gottschall <s.gottschall@dd-wrt.com>
Subject: Re: [PATCH v2] ath10k: support for multicast rate control
Date: Wed, 09 May 2018 19:46:54 -0700	[thread overview]
Message-ID: <aaa5893622e3be98cc32c5472501dc44@codeaurora.org> (raw)
In-Reply-To: <63c78277-183e-b10e-7355-154683375711@candelatech.com>

On 2018-05-09 07:31, Ben Greear wrote:
> On 05/08/2018 11:57 PM, Sebastian Gottschall wrote:
>> 
>> 
>> Am 09.05.2018 um 08:15 schrieb Sven Eckelmann:
>>> On Montag, 7. Mai 2018 18:34:51 CEST Pradeep Kumar Chitrapu wrote:
>>>> Issues wmi command to firmwre when multicast rate change is received
>>>> with the new BSS_CHANGED_MCAST_RATE flag.
>>>> Also fixes the incorrect fixed_rate setting for CCK rates which got
>>>> introduced with addition of ath10k_rates_rev2 enum.
>>>> 
>>>> Tested on QCA9984 with firmware ver 10.4-3.6-00104
>>>> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
>>>> ---
>>>> v2:
>>>>   - fixed the CCK rates setting for mcast_rate and fixed_rate paths.
>>>>   - set broadcast rate along with multicast rate setting.
>>> These things are only modified in ath10k_bss_info_changed and not 
>>> saved/
>>> restored. What happens when the HW needs to be reset (there are are 
>>> couple of
>>> firmware crashes which can be seen in the wild and are handled by 
>>> ath10k)? I
>>> would guess that not all of them automatically cause an 
>>> .bss_info_changed.
> 
> Yes, that sounds like a good idea to me.
> 
Hi Sven, Thanks for the review.
In case of HW reset, I see ieee80211_reconfig triggers bss_info changed 
and
BSS_CHANGED_MCAST_RATE is already being set in this function.
(https://patchwork.kernel.org/patch/10302175/). isn't this sufficient 
for the
re-configuring the mcast rate? Please let me know if I am missing 
something.

Thanks
Pradeep

>> i have never seen a card properly recovering after a firmware crash, 
>> all firmware crashes i have seen
>> are caused by bugs in firmware handling or the firmware itself. so if 
>> it recovers it crashes immediatly again
>> ending in a endless crashloop since the cause for the crash hasnt been 
>> fixed. they are often triggered by extern clients for instance which 
>> still remain in the field.
>> i think firmware crashes should not be hidden by recovering. this 
>> would also force users to report problems more frequently, than they 
>> do
>> since they dont even take notice of such problems
> 
> We see recovery work often.  If you see repeatable crashes, post them
> to the list.
> 
> Do you know of any particular external clients that cause these 
> crashes?
> 
> Thanks,
> Ben

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: pradeepc@codeaurora.org
To: Sven Eckelmann <sven@narfation.org>
Cc: Sebastian Gottschall <s.gottschall@dd-wrt.com>,
	Ben Greear <greearb@candelatech.com>,
	ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] ath10k: support for multicast rate control
Date: Wed, 09 May 2018 19:46:54 -0700	[thread overview]
Message-ID: <aaa5893622e3be98cc32c5472501dc44@codeaurora.org> (raw)
In-Reply-To: <63c78277-183e-b10e-7355-154683375711@candelatech.com>

On 2018-05-09 07:31, Ben Greear wrote:
> On 05/08/2018 11:57 PM, Sebastian Gottschall wrote:
>> 
>> 
>> Am 09.05.2018 um 08:15 schrieb Sven Eckelmann:
>>> On Montag, 7. Mai 2018 18:34:51 CEST Pradeep Kumar Chitrapu wrote:
>>>> Issues wmi command to firmwre when multicast rate change is received
>>>> with the new BSS_CHANGED_MCAST_RATE flag.
>>>> Also fixes the incorrect fixed_rate setting for CCK rates which got
>>>> introduced with addition of ath10k_rates_rev2 enum.
>>>> 
>>>> Tested on QCA9984 with firmware ver 10.4-3.6-00104
>>>> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
>>>> ---
>>>> v2:
>>>>   - fixed the CCK rates setting for mcast_rate and fixed_rate paths.
>>>>   - set broadcast rate along with multicast rate setting.
>>> These things are only modified in ath10k_bss_info_changed and not 
>>> saved/
>>> restored. What happens when the HW needs to be reset (there are are 
>>> couple of
>>> firmware crashes which can be seen in the wild and are handled by 
>>> ath10k)? I
>>> would guess that not all of them automatically cause an 
>>> .bss_info_changed.
> 
> Yes, that sounds like a good idea to me.
> 
Hi Sven, Thanks for the review.
In case of HW reset, I see ieee80211_reconfig triggers bss_info changed 
and
BSS_CHANGED_MCAST_RATE is already being set in this function.
(https://patchwork.kernel.org/patch/10302175/). isn't this sufficient 
for the
re-configuring the mcast rate? Please let me know if I am missing 
something.

Thanks
Pradeep

>> i have never seen a card properly recovering after a firmware crash, 
>> all firmware crashes i have seen
>> are caused by bugs in firmware handling or the firmware itself. so if 
>> it recovers it crashes immediatly again
>> ending in a endless crashloop since the cause for the crash hasnt been 
>> fixed. they are often triggered by extern clients for instance which 
>> still remain in the field.
>> i think firmware crashes should not be hidden by recovering. this 
>> would also force users to report problems more frequently, than they 
>> do
>> since they dont even take notice of such problems
> 
> We see recovery work often.  If you see repeatable crashes, post them
> to the list.
> 
> Do you know of any particular external clients that cause these 
> crashes?
> 
> Thanks,
> Ben

  reply	other threads:[~2018-05-10  2:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cebad8674a69761e32a1a882de9a1259657c65d4>
2018-05-08  1:34 ` [PATCH v2] ath10k: support for multicast rate control Pradeep Kumar Chitrapu
2018-05-08  1:34   ` Pradeep Kumar Chitrapu
2018-05-09  6:15   ` Sven Eckelmann
2018-05-09  6:15     ` Sven Eckelmann
2018-05-09  6:57     ` Sebastian Gottschall
2018-05-09  6:57       ` Sebastian Gottschall
2018-05-09 14:31       ` Ben Greear
2018-05-09 14:31         ` Ben Greear
2018-05-10  2:46         ` pradeepc [this message]
2018-05-10  2:46           ` pradeepc
2018-06-14 14:46   ` [v2] " Kalle Valo
2018-06-14 14:46   ` Kalle Valo
2018-07-30 17:47   ` [PATCH v2] " Kalle Valo
2018-07-30 17:47   ` Kalle Valo

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=aaa5893622e3be98cc32c5472501dc44@codeaurora.org \
    --to=pradeepc@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=s.gottschall@dd-wrt.com \
    --cc=sven@narfation.org \
    /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.