linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Yan-Hsuan Chuang <tony0620emma@gmail.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Andy Huang <tehuang@realtek.com>
Subject: Re: [PATCH v8 2/2] rtw88: add adaptivity support for EU/JP regulatory
Date: Wed, 09 Dec 2020 11:44:01 +0200	[thread overview]
Message-ID: <87mtynb9ge.fsf@codeaurora.org> (raw)
In-Reply-To: <CA+ASDXMXfTBdK2G_QbrUOz2GpR27TcSxd-RHVdpyKu7k_d-qGQ@mail.gmail.com> (Brian Norris's message of "Tue, 8 Dec 2020 15:10:36 -0800")

Brian Norris <briannorris@chromium.org> writes:

> + Tony's new address
>
> On Thu, Jul 30, 2020 at 7:46 PM <yhchuang@realtek.com> wrote:
>>
>> From: Tzu-En Huang <tehuang@realtek.com>
>>
>> From MIC Ordinance Regulating Radio Equipment article 49.20,
>> ETSI EN-300-328 and EN-301-893, the device should be able to
>> dynamically pause TX activity when energy detected on the air.
>>
>> To achieve this, add Energy Detected CCA (EDCCA) support to
>> detect the energy in the channel. Driver will set corresponding
>> thresholds to the device, if the energy detected exceeds the
>> threshold, the TX activity will be halted immediately.
>>
>> As this could lead to performance downgrade when the environment
>> is noisy, add a debugfs to disable this for debugging usage.
>>
>> Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
>> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> I see that this patch series is still marked Deferred:
> https://patchwork.kernel.org/project/linux-wireless/patch/20200731024607.5817-2-yhchuang@realtek.com/
> https://patchwork.kernel.org/project/linux-wireless/patch/20200731024607.5817-3-yhchuang@realtek.com/
>
> and I'm still rebasing these patches in my tree. I realize the docs
> say "the maintainer will revisit the patch in a later time":
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork
> but I figured 4-5 months might be long enough to wait ;)

Yeah, I have 145 patches in the notorious deferred state at the moment:

https://patchwork.kernel.org/project/linux-wireless/list/?state=10&delegate=25621&order=date

I am trying to make it shorter but always more important things pop up
so it's no easy task.

> Was there something controversial about this patch set that makes it
> difficult? Or should it get moved back to New? Or do Realtek folks
> need to rebase/resubmit/

I would need to check the old discussions what was the holdback, but
first thing after looking at the patchset I see this:

+config RTW88_REGD_USER_REG_HINTS
+	bool "Realtek rtw88 user regulatory hints"
+	depends on RTW88_CORE
+	default n
+	help
+	  Enable regulatoy user hints
+
+	  If unsure, say N. This should only be allowed on distributions
+	  that need this to correct the regulatory.

Why is this needed? The help text is not really helpful, what does "to
correct the regulatory" mean? If someone would ask me who, when and why
this should be enabled I would not have an answer.

And yes, I know there's a similar CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS.
I don't know what it does either (and no time to check right now).

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

      reply	other threads:[~2020-12-09  9:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31  2:46 [PATCH v8 0/2] rtw88: update regulatory settings yhchuang
2020-07-31  2:46 ` [PATCH v8 1/2] rtw88: add regulatory process strategy for different chipset yhchuang
2020-07-31  2:46 ` [PATCH v8 2/2] rtw88: add adaptivity support for EU/JP regulatory yhchuang
2020-12-08 23:10   ` Brian Norris
2020-12-09  9:44     ` Kalle Valo [this message]

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=87mtynb9ge.fsf@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=briannorris@chromium.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=tehuang@realtek.com \
    --cc=tony0620emma@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).