From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F08A6C433EF for ; Mon, 20 Jun 2022 09:00:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240225AbiFTJA4 (ORCPT ); Mon, 20 Jun 2022 05:00:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240148AbiFTJAw (ORCPT ); Mon, 20 Jun 2022 05:00:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E6EFF5AF; Mon, 20 Jun 2022 02:00:51 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2A7F76112E; Mon, 20 Jun 2022 09:00:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6AE70C3411B; Mon, 20 Jun 2022 09:00:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655715650; bh=yzwb89a50kjFZmjIaMeAKFjLE58t4BBZb0rlVAPAnss=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=PR3GANp6Ak21sG/UAxVizxxDj2i2izpRr7KA6sR0960EgFKkvixokHjg5g3fytWUO euXbDcHnhIJFj8EszeyH1UN5QwFc8voqbPPBdTGXurkeQbxMlVpVfWgpIJGuQRtGRJ zPpnlkFWHP2dDCSHxN5OmqwpKelbfwDZKfkQU7JhtaRdvOGBEfAkQgXUjPNzJcHWm8 2VFGth6KLO/eZvUIafg4IDoPRV3dBC6yonXsEKWjWjPeYGZrNSei/JW1QHAlQRBKTZ bWG9eCpK2x8/jlTDsHH4BaBZaFlZz80Yrhn1pG+vU42qRtAXweOHEY0Gh/7s9V40M3 z1AIB5PZOCitQ== From: Kalle Valo To: Ard Biesheuvel Cc: linux-efi@vger.kernel.org, keescook@chromium.org, Dmitry Torokhov , Arend van Spriel , Franky Lin , Hante Meuleman , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Gregory Greenman , 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 References: <20220617174851.1286026-1-ardb@kernel.org> Date: Mon, 20 Jun 2022 12:00:45 +0300 In-Reply-To: <20220617174851.1286026-1-ardb@kernel.org> (Ard Biesheuvel's message of "Fri, 17 Jun 2022 19:48:47 +0200") Message-ID: <87bkunpv42.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org Ard Biesheuvel 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 -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches