Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: kvalo=codeaurora.org@mg.codeaurora.org
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org BA021C433CA
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
References: <20200731024607.5817-1-yhchuang@realtek.com>
        <20200731024607.5817-3-yhchuang@realtek.com>
        <CA+ASDXMXfTBdK2G_QbrUOz2GpR27TcSxd-RHVdpyKu7k_d-qGQ@mail.gmail.com>
Date:   Wed, 09 Dec 2020 11:44:01 +0200
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")
Message-ID: <87mtynb9ge.fsf@codeaurora.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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