[ Upstream commit fc92d9e3de ]
KASAN report out-of-bounds read as follows:
BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380
Read of size 4 at addr ffffffffc00e4658 by task cat/278
Call Trace:
afe4404_read_raw
iio_read_channel_info
dev_attr_show
The buggy address belongs to the variable:
afe4404_channel_leds+0x18/0xffffffffffffe9c0
This issue can be reproduce by singe command:
$ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw
The array size of afe4404_channel_leds and afe4404_channel_offdacs
are less than channels, so access with chan->address cause OOB read
in afe4404_[read|write]_raw. Fix it by moving access before use them.
Fixes: b36e825764 ("iio: health/afe440x: Use regmap fields")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20221107152010.95937-1-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 58143c1ed5 ]
KASAN report out-of-bounds read as follows:
BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0
Read of size 4 at addr ffffffffc02ac638 by task cat/279
Call Trace:
afe4403_read_raw
iio_read_channel_info
dev_attr_show
The buggy address belongs to the variable:
afe4403_channel_leds+0x18/0xffffffffffffe9e0
This issue can be reproduced by singe command:
$ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw
The array size of afe4403_channel_leds is less than channels, so access
with chan->address cause OOB read in afe4403_read_raw. Fix it by moving
access before use it.
Fixes: b36e825764 ("iio: health/afe440x: Use regmap fields")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20221107151946.89260-1-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 20543be93c ]
drm_display_info is updated by drm_get_edid() or
drm_connector_update_edid_property(). In the amdgpu driver it is almost
always updated when the edid is read in amdgpu_connector_get_edid(),
but not always. Change amdgpu_connector_get_edid() and
amdgpu_connector_free_edid() to keep drm_display_info updated.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Claudio Suarez <cssk@net-c.es>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Stable-dep-of: 602ad43c3c ("drm/amdgpu: Partially revert "drm/amdgpu: update drm_display_info correctly when the edid is read"")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2f3a127386 ]
Looks like that we're accidentally dropping a pretty important return code
here. For some reason, we just return -EINVAL if we fail to get the MST
topology state. This is wrong: error codes are important and should never
be squashed without being handled, which here seems to have the potential
to cause a deadlock.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Fixes: 8ec046716c ("drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs")
Cc: <stable@vger.kernel.org> # v5.6+
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit db5df25412 ]
Instead of having 2 places that short circuit the qgroup leaf scan have
everything in the qgroup_rescan_leaf function. In addition to that, also
ensure that the inconsistent qgroup flag is set when rescan_should_stop
returns true. This both retains the old behavior when -EINTR was set in
the body of the loop and at the same time also extends this behavior
when scanning is interrupted due to remount or unmount operations.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Stable-dep-of: f7e942b5bb ("btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit db2d2dc9a0 ]
In case the requested bus clock is higher than the input clock, the correct
dividers (pre = 0, post = 0) are returned from mx51_ecspi_clkdiv(), but
*fres is left uninitialized and therefore contains an arbitrary value.
This causes trouble for the recently introduced PIO polling feature as the
value in spi_imx->spi_bus_clk is used there to calculate for which
transfers to enable PIO polling.
Fix this by setting *fres even if no clock dividers are in use.
This issue was observed on Kontron BL i.MX8MM with an SPI peripheral clock set
to 50 MHz by default and a requested SPI bus clock of 80 MHz for the SPI NOR
flash.
With the fix applied the debug message from mx51_ecspi_clkdiv() now prints the
following:
spi_imx 30820000.spi: mx51_ecspi_clkdiv: fin: 50000000, fspi: 50000000,
post: 0, pre: 0
Fixes: 6fd8b8503a ("spi: spi-imx: Fix out-of-order CS/SCLK operation at low speeds")
Fixes: 07e7593877 ("spi: spi-imx: add PIO polling support")
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: David Jander <david@protonic.nl>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Marek Vasut <marex@denx.de>
Cc: stable@vger.kernel.org
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20221115181002.2068270-1-frieder@fris.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 418ffb9e3c ]
btrfs_ioctl_logical_to_ino() frees the search path after the userspace
copy from the temp buffer @inodes. Which potentially can lead to a lock
splat.
Fix this by freeing the path before we copy @inodes to userspace.
CC: stable@vger.kernel.org # 4.19+
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e3059ec06b ]
There's only one function we pass to iterate_inodes_from_logical as
iterator, so we can drop the indirection and call it directly, after
moving the function to backref.c
Signed-off-by: David Sterba <dsterba@suse.com>
Stable-dep-of: 418ffb9e3c ("btrfs: free btrfs_path before copying inodes to userspace")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b0b0f2d225 ]
We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is created. It just has to look real enough.
Also kill pin_mutex, it's not compatible with ww locking,
and we can use the vm lock instead.
v2:
- Drop IS_SHRINKABLE and shorten overly long line
v3:
- Checkpatch fix for alignment
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211117142024.1043017-2-matthew.auld@intel.com
Stable-dep-of: 20e377e7b2 ("drm/i915/gt: Use i915_vm_put on ppgtt_create error paths")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a8e5e5146a ]
Prior to commit 69e3b846d8 ("arm64: mte: Sync tags for pages where PTE
is untagged"), mte_sync_tags() was only called for pte_tagged() entries
(those mapped with PROT_MTE). Therefore mte_sync_tags() could safely use
test_and_set_bit(PG_mte_tagged, &page->flags) without inadvertently
setting PG_mte_tagged on an untagged page.
The above commit was required as guests may enable MTE without any
control at the stage 2 mapping, nor a PROT_MTE mapping in the VMM.
However, the side-effect was that any page with a PTE that looked like
swap (or migration) was getting PG_mte_tagged set automatically. A
subsequent page copy (e.g. migration) copied the tags to the destination
page even if the tags were owned by KASAN.
This issue was masked by the page_kasan_tag_reset() call introduced in
commit e5b8d92189 ("arm64: mte: reset the page tag in page->flags").
When this commit was reverted (20794545c1), KASAN started reporting
access faults because the overriding tags in a page did not match the
original page->flags (with CONFIG_KASAN_HW_TAGS=y):
BUG: KASAN: invalid-access in copy_page+0x10/0xd0 arch/arm64/lib/copy_page.S:26
Read at addr f5ff000017f2e000 by task syz-executor.1/2218
Pointer tag: [f5], memory tag: [f2]
Move the PG_mte_tagged bit setting from mte_sync_tags() to the actual
place where tags are cleared (mte_sync_page_tags()) or restored
(mte_restore_tags()).
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: syzbot+c2c79c6d6eddc5262b77@syzkaller.appspotmail.com
Fixes: 69e3b846d8 ("arm64: mte: Sync tags for pages where PTE is untagged")
Cc: <stable@vger.kernel.org> # 5.14.x
Cc: Steven Price <steven.price@arm.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/0000000000004387dc05e5888ae5@google.com/
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://lore.kernel.org/r/20221006163354.3194102-1-catalin.marinas@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
The recently introduced support for pKVM modules has clearly lacked a
bit of testing with CONFIG_MODULES=n.
Make sure to not access __pkvm_modules_enabled when CONFIG_MODULES=n to
fix the link.
Bug: 244543039
Bug: 244373730
Reported-by: kernel test robot <lkp@intel.com>
Change-Id: I65c6ad7c07c2812b85dcd435b24b3444c0ce7f1e
Signed-off-by: Quentin Perret <qperret@google.com>
The recently introduced support for pKVM modules has clearly lacked a
bit of testing with CONFIG_MODULES=n.
Fix the broken __pkvm_init_module() stub to make the bots happy.
Bug: 244543039
Bug: 244373730
Reported-by: kernel test robot <lkp@intel.com>
Change-Id: Ie59cbf46442721de78ef51523debadc4c156530e
Signed-off-by: Quentin Perret <qperret@google.com>
Disable module loading, based on the cmdline option
kvm-arm.protected_modules. If enabled, the feature can later be
irreversibly disabled with the HVC __pkvm_close_module_registration().
Bug: 244543039
Bug: 244373730
Change-Id: I693a1db350ae15bcaab59103a68b60f087dcc6b4
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Return the fixmap VA with the page offset, instead of the page base
address.
Bug: 244543039
Bug: 229972309
Change-Id: I40c342f84e3cd395156ef846f0434c028d4e3fa3
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
In order to allow the registration of dynamic HVCs by pKVM modules, let's
expose the __pkvm_register_el2_call() function in the GKI ABI.
Bug: 244543039
Bug: 244373730
Change-Id: Iae1d0f94776f8c097410a6cf6527c825fee30184
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
When pKVM is in use, allow pKVM modules to register custom hypercall
handlers:
* pkvm_register_el2_call(): Give a handler to the hypervisor and gets in
return the newly registered hypercall number.
* pkvm_el2_mod_call(): Call the previously registered hypercall handler.
There is a limit of 128 hypercalls that can be registered.
Bug: 244543039
Bug: 244373730
Change-Id: I3d6c89675efe5f65f6b53c3b45ae155d1a00164c
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Later introduction of custom HVCs will require to store some data.
Conviniently, the only thing we need is the start addr (in the hyp VA) of
the text section. So use this value as a token to avoid having to store
it anywhere.
Bug: 244543039
Bug: 244373730
Change-Id: Idd0bcbbb36d189aa4932833ca5b40382c2cddb08
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
In preparation for allowing to restrict host permissions at stage-2 for
certain pages, introduce some infrastructure allowing a pKVM module to
register a permission fault handler.
Bug: 244543039
Bug: 244373730
Change-Id: I8035c64969cc0ebb01c8936b1974b3bc103ba84f
Signed-off-by: Quentin Perret <qperret@google.com>
pKVM currently doesn't map pages with reduced permissions in stage2
page-tables, for both host and guests. But in preparation for allowing
that to happen, introduce a new page 'meta-state' that is set whenever a
page has non-default permissions. Introducing it ensures that e.g.
host-to-guest donations or shares will fail for a page that the host has
read-only, as the page will no longer be PKVM_PAGE_OWNED only.
Bug: 244543039
Bug: 244373730
Change-Id: Ib3b20c7edabafb9a305f000a37bbdb4bcc8fdbbb
Signed-off-by: Quentin Perret <qperret@google.com>
Expose the hyp_fixmap helpers in the module_ops struct to allow dynamic
mapping and unmapping of pages from pKVM modules.
Bug: 244543039
Bug: 244373730
Change-Id: I201db6044ed5eb4c2821a64a6b650b931dd2e389
Signed-off-by: Quentin Perret <qperret@google.com>
Expose the hyp_puts() and hyp_putx64() helpers in the module_ops struct
to allow logging messages on the UART from pKVM modules.
Bug: 244543039
Bug: 244373730
Change-Id: Ica578667297e5a1f94c370603c29482be89982a9
Signed-off-by: Quentin Perret <qperret@google.com>
Debugging a hypervisor tends to be trickier than normal system code
such as the kernel. The lack of availability of a UART framework is a
significant contributor to that. In order to address this, introduce a
framework allowing to load serial drivers into the hypervisor.
Bug: 244543039
Bug: 244373730
Change-Id: I2e7a1fd9abc9d5aa9d95f1d271a997d54a8fd582
Signed-off-by: Quentin Perret <qperret@google.com>
pKVM has an internal API allowing to create mappings in the 'private'
range of the hypervisor VA space for which there are no rules
constraining the VA-PA relation (hence comparable to the vmalloc area in
the kernel). This will be a useful API for hypervisor modules, so expose
it in the recently introduced module ops struct.
Bug: 244543039
Bug: 244373730
Change-Id: I2a8f958a02c3c3b9871224b65b00b207820a507a
Signed-off-by: Quentin Perret <qperret@google.com>
In order to allow loading el2 modules from kernel modules, let's expose
the __pkvm_load_el2_module() function in the GKI ABI.
Bug: 244543039
Bug: 244373730
Change-Id: I65410a02c67178427d4e0c115a24de1584f1adc7
Signed-off-by: Quentin Perret <qperret@google.com>
Since .hyp.rodata sections of pKVM modules are emitted with SHT_MERGE,
ld.ldd feels free to attempt merging it with other sections.
Unfortunately, the pKVM module linker script doesn't always place them
in output sections, hence causing link failures:
ld.lld: error: drivers/misc/pkvm-pl011/hyp/kvm_nvhe.tmp.o:(.hyp.rodata):
offset is outside the section
In practice, ld.ldd only seems to attempt merging .note.gnu.property with
.hyp.rodata. To work around the problem, make sure to explicitely place
the .note.gnu.property in .hyp.rodata from the start, hence preventing
ld.ldd from trying to optimize further.
A preferable solution would be to teach ld.lld that merging pKVM modules
sections is a bad idea, or to make sure the sections are not emitted
with SHT_MERGE to begin with, but we couldn't find an obvious way to make
that happen. This workaround is nothing more than a pratical compromise.
Bug: 244543039
Reported-by: Will Deacon <will@kernel.org>
Suggested-by: Will Deacon <will@kernel.org>
Change-Id: Iae902bdfd21915f552e218515cd77881a95fef2d
Signed-off-by: Quentin Perret <qperret@google.com>
All nVHE hypervisor code is currently required to be statically linked
into the kernel image. Sadly, scaling pKVM will inevitably require
running _some_ hardware-specific code in the hypervisor due to the
absence of architecture requirements regarding IOMMU implementations or
power management, for example.
In order to address this issue, introduce the ability to load modules
in the pKVM hypervisor at run-time. pKVM modules are expected to be
embedded inside kernel modules, and to be loaded into pKVM when their
kernel counterpart is loaded at EL1. pKVM module loading is defined as a
privileged operation -- all of them must be loaded while the host kernel
is still part of the trusted computing base.
Bug: 244543039
Bug: 244373730
Co-authored-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: If8e5d3ac0a2893c892aff09e5b51d3b8e14693f8
Building and linking hypervisor modules into kernel modules involves
very similar problems to building and linking the KVM nVHE hypervisor
object into the kernel image. In order to re-use the same building
procedure, let's factor out and generalize the nVHE makefile in a way
that allows it to be re-used for module builds.
Bug: 244543039
Bug: 244373730
Change-Id: I89b2630f8cfd3ce5b624300fc277749be4fc9e04
Signed-off-by: Quentin Perret <qperret@google.com>
[vdonnefort@: Merge with updated nvhe/Makefile]
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
The start and end pointers of the hyp relocs section are currently
specified in the vmlinux linker script. In order to ease re-using the
same relocation procedure for hypervisor modules, emit the delimiters
from the generated hyp-reloc.S file directly.
Bug: 244543039
Bug: 244373730
Change-Id: I845af2d40e1dd13301069537c6325f6a6f381ce4
Signed-off-by: Quentin Perret <qperret@google.com>
In order to allow re-use of the gen-hyprel tool to build hypervisor
modules in the future, move it up to the arm64 tools folder.
Bug: 244543039
Bug: 244373730
Change-Id: I188a2dac1acf4974213499970cc29552807497eb
Signed-off-by: Quentin Perret <qperret@google.com>
The new pkvm_remove_mappings() allows the caller to unmap a memory range
from the hypervisor.
This is to allow later introduction of in-hypervisor tracing.
Bug: 244543039
Bug: 229972309
Change-Id: I9edc7c2ae55c4b7f5d464d26ce3351b5fd4bf9f3
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
The process of applying hypervisor relocations involves patching
addresses in the hypervisor object. In the existing KVM nVHE relocation
procedure, the relocations are applied early enough for write-permission
not to be a problem when touching e.g. the rodata section. But applying
relocations on hypervisor modules embedded in a kernel module proves
more challenging, as the kernel module loader will actively map text and
rodata sections read-only. In order to allow patching in those sections,
let's introduce a new helper function using the text fixmap to
temporarily map the relevant pages writable.
Bug: 244543039
Bug: 244373730
Change-Id: I9dcdade1927e5bc121db87bc950fb70a374c44cd
Signed-off-by: Quentin Perret <qperret@google.com>
In order to allow the re-use of __arch64_insn_write() to fixup
relocations in pKVM modules, refactor it into a more abstract
__arch64_text_write() function which also takes a size as parameter.
No functional changes intended.
Bug: 244543039
Bug: 244373730
Change-Id: I60d789d8a4b1271deeb2f6ac6d3b7fc55bdbb465
Signed-off-by: Quentin Perret <qperret@google.com>
Add a new extended feature bit signifying that the wireless hardware
supports changing the MAC address while the underlying net_device is
powered. Note that this has a different meaning from
IFF_LIVE_ADDR_CHANGE as additional restrictions might be imposed by
the hardware, such as:
- No connection is active on this interface, carrier is off
- No scan is in progress
- No offchannel operations are in progress
Signed-off-by: James Prestwood <prestwoj@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: Bug: 253289327
(cherry picked from commit a36c421690)
Change-Id: If579ffacd49fdf478c310e8ff991ca220abafbf9
Signed-off-by: Carlos Llamas <cmllamas@google.com>
When invoking function cfg80211_calculate_bitrate_eht about
(320 MHz, EHT-MCS 13, EHT-NSS 2, EHT-GI 0), which means the
parameters as flags: 0x80, bw: 7, mcs: 13, eht_gi: 0, nss: 2,
this formula (result * rate->nss) will overflow and causes
the returned bitrate to be 3959 when it should be 57646.
Here is the explanation:
u64 tmp;
u32 result;
…
/* tmp = result = 4 * rates_996[0]
* = 4 * 480388888 = 0x72889c60
*/
tmp = result;
/* tmp = 0x72889c60 * 6144 = 0xabccea90000 */
tmp *= SCALE;
/* tmp = 0xabccea90000 / mcs_divisors[13]
* = 0xabccea90000 / 5120 = 0x8970bba6
*/
do_div(tmp, mcs_divisors[rate->mcs]);
/* result = 0x8970bba6 */
result = tmp;
/* normally (result * rate->nss) = 0x8970bba6 * 2 = 0x112e1774c,
* but since result is u32, (result * rate->nss) = 0x12e1774c,
* overflow happens and it loses the highest bit.
* Then result = 0x12e1774c / 8 = 39595753,
*/
result = (result * rate->nss) / 8;
Signed-off-by: Paul Zhang <quic_paulz@quicinc.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 253289327
(cherry picked from commit 18429c51c7)
Change-Id: I0f6e6247be15cc0496539e8d7432d01d7add0cc9
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Add an MLD address attribute to BSS entries that the interface
is currently associated with to help userspace figure out what's
going on.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 253289327
(cherry picked from commit 6522047c65)
Change-Id: I1fc7a2091f3c2b3f1581dd2f281bfd383d68cf2c
Signed-off-by: Carlos Llamas <cmllamas@google.com>
For AP/non-AP the EHT MCS/NSS subfield size differs, the
4-octet subfield is only used for 20 MHz-only non-AP STA.
Pass an argument around everywhere to be able to parse it
properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 253289327
Change-Id: I40a3f916cf6bb26ab0e7e36fbb32fefefeb3645b
(cherry picked from commit ea5cba269f)
[Kiran Kumar Lokere: Skipped changes in net/mac80211 due to missing
dependency changes]
Signed-off-by: Kiran Kumar Lokere <quic_klokere@quicinc.com>
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Add support for various key operations on MLD by adding new parameter
link_id. Pass the link_id received from userspace to driver for add_key,
get_key, del_key, set_default_key, set_default_mgmt_key and
set_default_beacon_key to support configuring keys specific to each MLO
link. Userspace must not specify link ID for MLO pairwise key since it
is common for all the MLO links.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20220730052643.1959111-4-quic_vjakkam@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 241223350
(cherry picked from commit e7a7b84e33)
[cmllamas: fix trivial merge conflict in
drivers/net/wireless/microchip/wilc1000/cfg80211.c]
Change-Id: I423057a29c0795c58ff013fd2a4b54bc5ced0217
Signed-off-by: Carlos Llamas <cmllamas@google.com>
