From: Kalle Valo <kvalo@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org, keescook@chromium.org,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Arend van Spriel <aspriel@gmail.com>,
Franky Lin <franky.lin@broadcom.com>,
Hante Meuleman <hante.meuleman@broadcom.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Gregory Greenman <gregory.greenman@intel.com>,
linux-input@vger.kernel.org, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
Subject: Re: [PATCH 0/4] efivar: remove inappropriate uses of the efivar API
Date: Mon, 20 Jun 2022 12:00:45 +0300 [thread overview]
Message-ID: <87bkunpv42.fsf@kernel.org> (raw)
In-Reply-To: <20220617174851.1286026-1-ardb@kernel.org> (Ard Biesheuvel's message of "Fri, 17 Jun 2022 19:48:47 +0200")
Ard Biesheuvel <ardb@kernel.org> writes:
> The efivar layer is a caching non-volatile variable store abstraction
> that is normally backed by EFI, but in some cases, might be backed by
> Google SMI firmware interfaces instead.
>
> It is mainly used by efivarfs and EFI pstore, both of which actually
> need the caching and abstraction properties. However, there are a few
> other occurrences where efivar is not necessary, or used in an invalid
> way. So let's fix this up, and remove some impediments to refactoring
> and cleaning up the efivars layer in the future.
>
> Assuming there are no objections to these changes, I intend to queue
> them up in the EFI tree fairly soon, so that ongoing work depending on
> these changes can continue as well.
>
[...]
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 25 ++---
> drivers/net/wireless/intel/iwlwifi/fw/uefi.c | 96 ++++++------------
Feel free to take the wireless patches via your tree:
Acked-by: Kalle Valo <kvalo@kernel.org>
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2022-06-20 9:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 17:48 [PATCH 0/4] efivar: remove inappropriate uses of the efivar API Ard Biesheuvel
2022-06-17 17:48 ` [PATCH 1/4] efi: avoid efivars layer when loading SSDTs from variables Ard Biesheuvel
2022-06-17 17:48 ` [PATCH 2/4] Input: applespi - avoid efivars API and invoke EFI services directly Ard Biesheuvel
2022-06-24 8:16 ` Ard Biesheuvel
2022-06-17 17:48 ` [PATCH 3/4] iwlwifi: Switch to proper EFI variable store interface Ard Biesheuvel
2022-06-17 17:48 ` [PATCH 4/4] brcmfmac: Switch to appropriate helper to load EFI variable contents Ard Biesheuvel
2022-06-20 9:00 ` Kalle Valo [this message]
2022-06-21 16:19 ` [PATCH 0/4] efivar: remove inappropriate uses of the efivar API Ard Biesheuvel
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=87bkunpv42.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ardb@kernel.org \
--cc=aspriel@gmail.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=davem@davemloft.net \
--cc=dmitry.torokhov@gmail.com \
--cc=edumazet@google.com \
--cc=franky.lin@broadcom.com \
--cc=gregory.greenman@intel.com \
--cc=hante.meuleman@broadcom.com \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pabeni@redhat.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 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.