linux-kernel - Re: [regression] Bug 216753 - 6e 6 ghz bands are disabled since 5.16 on intel ax211

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] [day] [month] [year] [list]

Message-ID: <bc0b159321826c0336f074ca23244fc0cde507f2.camel@intel.com>
Date:   Thu, 19 Jan 2023 14:09:18 +0000
From:   "Greenman, Gregory" <gregory.greenman@...el.com>
To:     "chiluk@...ntu.com" <chiluk@...ntu.com>
CC:     "regressions@...mhuis.info" <regressions@...mhuis.info>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "johannes@...solutions.net" <johannes@...solutions.net>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Coelho, Luciano" <luciano.coelho@...el.com>,
        "marcel@...tmann.org" <marcel@...tmann.org>
Subject: Re: [regression] Bug 216753 - 6e 6 ghz bands are disabled since 5.16
 on intel ax211

On Fri, 2023-01-06 at 09:37 -0600, Dave Chiluk wrote:
> On Thu, Jan 5, 2023 at 12:15 AM Greenman, Gregory
> <gregory.greenman@...el.com> wrote:
> > 
> > I'll try to explain, the problem here is not technical. After some
> > internal checks, it appears that we (wifi driver) aren't allowed to
> > decide if 6E should be enabled or not. Because of the legal restrictions,
> > OEM should make this decision and enable/disable 6E in the BIOS. This
> > commit only gets the value from the BIOS and configures the firmware
> > accordingly. So, unfortunately, legal restriction is the reason we cannot
> > revert/overwrite 6E enablement...
> > 
> Thank you Gregory, I've been reading between the lines, and this is
> pretty much what I expected you to say.  So in the past when
> OEMs/systems manufacturers have been irresponsible/inept like this we
> have implemented flags to force ignore the values coming out of the
> bios.  As it's now obvious that the problem here is a legal/regulatory
> issue, I'd hope that having a force flag would be acceptable from a
> that perspective.  I'm no lawyer, but I expect once a user decides to
> explicitly set a force flag to ignore the bios values I'd suspect the
> responsibility would shift from the manufacturers and back onto the
> user.
> 
> Would such a patch be theoretically acceptable?  If so I'll write up a
> patch to do this and submit it next week hopefully.

Sorry for the long delay...
We looked at it again and this particular scenario looks more like some
bug maybe in the firmware since in US it should be enabled by default.
Can I ask to collect a trace-cmd dump for the case when it doesn't
work with "-e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg"?