diff mbox series

[v12,03/10] firmware: Rename FW_OPT_NOFALLBACK to FW_OPT_NOFALLBACK_SYSFS

Message ID 20200115163554.101315-4-hdegoede@redhat.com (mailing list archive)
State New, archived
Headers show
Series efi/firmware/platform-x86: Add EFI embedded fw support | expand

Commit Message

Hans de Goede Jan. 15, 2020, 4:35 p.m. UTC 
This is a preparation patch for adding a new platform fallback mechanism,
which will have its own enable/disable FW_OPT_xxx option.

Note this also fixes a typo in one of the re-wordwrapped comments:
enfoce -> enforce.

Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/base/firmware_loader/fallback.c | 11 ++++++-----
 drivers/base/firmware_loader/firmware.h | 16 ++++++++--------
 drivers/base/firmware_loader/main.c     |  2 +-
 3 files changed, 15 insertions(+), 14 deletions(-)

Comments

Greg KH Jan. 24, 2020, 8:57 a.m. UTC | #1 
On Wed, Jan 15, 2020 at 05:35:47PM +0100, Hans de Goede wrote:
> This is a preparation patch for adding a new platform fallback mechanism,
> which will have its own enable/disable FW_OPT_xxx option.
> 
> Note this also fixes a typo in one of the re-wordwrapped comments:
> enfoce -> enforce.
> 
> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

I've taken this in my tree for now in a quest to try to get others to
pay attention to this series...

thanks,

greg k-h
Hans de Goede Jan. 24, 2020, 9:16 a.m. UTC | #2 
Hi,

On 1/24/20 9:57 AM, Greg Kroah-Hartman wrote:
> On Wed, Jan 15, 2020 at 05:35:47PM +0100, Hans de Goede wrote:
>> This is a preparation patch for adding a new platform fallback mechanism,
>> which will have its own enable/disable FW_OPT_xxx option.
>>
>> Note this also fixes a typo in one of the re-wordwrapped comments:
>> enfoce -> enforce.
>>
>> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> I've taken this in my tree for now in a quest to try to get others to
> pay attention to this series...

Thank you.

As mentioned before I believe that this series is ready for merging now.

Andy Lutomirski had one last change request for v12 of the second
patch in the series, specifically to replace the loop searching for
the prefix with a memem, but the kernel does not have memmem.

Andy, are you ok with v12 as is, given that we don't have memmem ?

Assuming Andy is ok with v12 as is, then to merge this we need
to probably wait for 5.6-rc1 and then have the x86/efi folks do
an immutable branch with the first 2 patches of the series.

After that you (Greg) can merge patches 3-10 (after merging the
branch) and the platform/drivers/x86 folks can take 11 and 12
(also after merging the branch).

Regards,

Hans
Greg KH March 18, 2020, 1:27 p.m. UTC | #3 
On Fri, Jan 24, 2020 at 10:16:48AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 1/24/20 9:57 AM, Greg Kroah-Hartman wrote:
> > On Wed, Jan 15, 2020 at 05:35:47PM +0100, Hans de Goede wrote:
> > > This is a preparation patch for adding a new platform fallback mechanism,
> > > which will have its own enable/disable FW_OPT_xxx option.
> > > 
> > > Note this also fixes a typo in one of the re-wordwrapped comments:
> > > enfoce -> enforce.
> > > 
> > > Acked-by: Luis Chamberlain <mcgrof@kernel.org>
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > 
> > I've taken this in my tree for now in a quest to try to get others to
> > pay attention to this series...
> 
> Thank you.
> 
> As mentioned before I believe that this series is ready for merging now.
> 
> Andy Lutomirski had one last change request for v12 of the second
> patch in the series, specifically to replace the loop searching for
> the prefix with a memem, but the kernel does not have memmem.
> 
> Andy, are you ok with v12 as is, given that we don't have memmem ?
> 
> Assuming Andy is ok with v12 as is, then to merge this we need
> to probably wait for 5.6-rc1 and then have the x86/efi folks do
> an immutable branch with the first 2 patches of the series.

Did this every happen?  Or do I need to dump this all into my tree?

thanks,

greg k-h
Hans de Goede March 18, 2020, 1:56 p.m. UTC | #4 
Hi Greg,

On 3/18/20 2:27 PM, Greg Kroah-Hartman wrote:
> On Fri, Jan 24, 2020 at 10:16:48AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 1/24/20 9:57 AM, Greg Kroah-Hartman wrote:
>>> On Wed, Jan 15, 2020 at 05:35:47PM +0100, Hans de Goede wrote:
>>>> This is a preparation patch for adding a new platform fallback mechanism,
>>>> which will have its own enable/disable FW_OPT_xxx option.
>>>>
>>>> Note this also fixes a typo in one of the re-wordwrapped comments:
>>>> enfoce -> enforce.
>>>>
>>>> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>
>>> I've taken this in my tree for now in a quest to try to get others to
>>> pay attention to this series...
>>
>> Thank you.
>>
>> As mentioned before I believe that this series is ready for merging now.
>>
>> Andy Lutomirski had one last change request for v12 of the second
>> patch in the series, specifically to replace the loop searching for
>> the prefix with a memem, but the kernel does not have memmem.
>>
>> Andy, are you ok with v12 as is, given that we don't have memmem ?
>>
>> Assuming Andy is ok with v12 as is, then to merge this we need
>> to probably wait for 5.6-rc1 and then have the x86/efi folks do
>> an immutable branch with the first 2 patches of the series.
> 
> Did this every happen?  Or do I need to dump this all into my tree?

Ard has done a immutable branch with just the 2 patches:

https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=stable-shared-branch-for-driver-tree

I did not see any mails about this being pulled / merged, but I just
checked and this has landed in the tip tree 10 days ago:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/include/linux/efi.h?h=efi/core

So if you merge the stable-shared-branch-for-driver-tree tag and then
merge patches 3-8 of this series (or rather 4-8 since you already
merged 3 IIRC) that would be great.

Regards,

Hans
Greg KH March 20, 2020, 2:02 p.m. UTC | #5 
On Wed, Mar 18, 2020 at 02:56:23PM +0100, Hans de Goede wrote:
> Hi Greg,
> 
> On 3/18/20 2:27 PM, Greg Kroah-Hartman wrote:
> > On Fri, Jan 24, 2020 at 10:16:48AM +0100, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 1/24/20 9:57 AM, Greg Kroah-Hartman wrote:
> > > > On Wed, Jan 15, 2020 at 05:35:47PM +0100, Hans de Goede wrote:
> > > > > This is a preparation patch for adding a new platform fallback mechanism,
> > > > > which will have its own enable/disable FW_OPT_xxx option.
> > > > > 
> > > > > Note this also fixes a typo in one of the re-wordwrapped comments:
> > > > > enfoce -> enforce.
> > > > > 
> > > > > Acked-by: Luis Chamberlain <mcgrof@kernel.org>
> > > > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > > 
> > > > I've taken this in my tree for now in a quest to try to get others to
> > > > pay attention to this series...
> > > 
> > > Thank you.
> > > 
> > > As mentioned before I believe that this series is ready for merging now.
> > > 
> > > Andy Lutomirski had one last change request for v12 of the second
> > > patch in the series, specifically to replace the loop searching for
> > > the prefix with a memem, but the kernel does not have memmem.
> > > 
> > > Andy, are you ok with v12 as is, given that we don't have memmem ?
> > > 
> > > Assuming Andy is ok with v12 as is, then to merge this we need
> > > to probably wait for 5.6-rc1 and then have the x86/efi folks do
> > > an immutable branch with the first 2 patches of the series.
> > 
> > Did this every happen?  Or do I need to dump this all into my tree?
> 
> Ard has done a immutable branch with just the 2 patches:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=stable-shared-branch-for-driver-tree
> 
> I did not see any mails about this being pulled / merged, but I just
> checked and this has landed in the tip tree 10 days ago:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/include/linux/efi.h?h=efi/core
> 
> So if you merge the stable-shared-branch-for-driver-tree tag and then
> merge patches 3-8 of this series (or rather 4-8 since you already
> merged 3 IIRC) that would be great.

Ok, I've merged the above branch with just the two patches, and the rest
of yours now, sorry this took so long.

greg k-h
Hans de Goede March 20, 2020, 4:41 p.m. UTC | #6 
Hi,

On 3/20/20 3:02 PM, Greg Kroah-Hartman wrote:
> On Wed, Mar 18, 2020 at 02:56:23PM +0100, Hans de Goede wrote:
>> Hi Greg,
>>
>> On 3/18/20 2:27 PM, Greg Kroah-Hartman wrote:
>>> On Fri, Jan 24, 2020 at 10:16:48AM +0100, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 1/24/20 9:57 AM, Greg Kroah-Hartman wrote:
>>>>> On Wed, Jan 15, 2020 at 05:35:47PM +0100, Hans de Goede wrote:
>>>>>> This is a preparation patch for adding a new platform fallback mechanism,
>>>>>> which will have its own enable/disable FW_OPT_xxx option.
>>>>>>
>>>>>> Note this also fixes a typo in one of the re-wordwrapped comments:
>>>>>> enfoce -> enforce.
>>>>>>
>>>>>> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
>>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>>>
>>>>> I've taken this in my tree for now in a quest to try to get others to
>>>>> pay attention to this series...
>>>>
>>>> Thank you.
>>>>
>>>> As mentioned before I believe that this series is ready for merging now.
>>>>
>>>> Andy Lutomirski had one last change request for v12 of the second
>>>> patch in the series, specifically to replace the loop searching for
>>>> the prefix with a memem, but the kernel does not have memmem.
>>>>
>>>> Andy, are you ok with v12 as is, given that we don't have memmem ?
>>>>
>>>> Assuming Andy is ok with v12 as is, then to merge this we need
>>>> to probably wait for 5.6-rc1 and then have the x86/efi folks do
>>>> an immutable branch with the first 2 patches of the series.
>>>
>>> Did this every happen?  Or do I need to dump this all into my tree?
>>
>> Ard has done a immutable branch with just the 2 patches:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=stable-shared-branch-for-driver-tree
>>
>> I did not see any mails about this being pulled / merged, but I just
>> checked and this has landed in the tip tree 10 days ago:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/include/linux/efi.h?h=efi/core
>>
>> So if you merge the stable-shared-branch-for-driver-tree tag and then
>> merge patches 3-8 of this series (or rather 4-8 since you already
>> merged 3 IIRC) that would be great.
> 
> Ok, I've merged the above branch with just the two patches, and the rest
> of yours now, 

Great, thank you!

> sorry this took so long.

No problem, I'm quite happy this is queued for 5.7 now, I was
afraid it was going to slip to 5.8.

Regards,

Hans
diff mbox series

Patch

diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
index 62ee90b4db56..8704e1bae175 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -606,7 +606,7 @@  static bool fw_run_sysfs_fallback(enum fw_opt opt_flags)
 		return false;
 	}
 
-	if ((opt_flags & FW_OPT_NOFALLBACK))
+	if ((opt_flags & FW_OPT_NOFALLBACK_SYSFS))
 		return false;
 
 	/* Also permit LSMs and IMA to fail firmware sysfs fallback */
@@ -630,10 +630,11 @@  static bool fw_run_sysfs_fallback(enum fw_opt opt_flags)
  * interface. Userspace is in charge of loading the firmware through the sysfs
  * loading interface. This sysfs fallback mechanism may be disabled completely
  * on a system by setting the proc sysctl value ignore_sysfs_fallback to true.
- * If this false we check if the internal API caller set the @FW_OPT_NOFALLBACK
- * flag, if so it would also disable the fallback mechanism. A system may want
- * to enfoce the sysfs fallback mechanism at all times, it can do this by
- * setting ignore_sysfs_fallback to false and force_sysfs_fallback to true.
+ * If this is false we check if the internal API caller set the
+ * @FW_OPT_NOFALLBACK_SYSFS flag, if so it would also disable the fallback
+ * mechanism. A system may want to enforce the sysfs fallback mechanism at all
+ * times, it can do this by setting ignore_sysfs_fallback to false and
+ * force_sysfs_fallback to true.
  * Enabling force_sysfs_fallback is functionally equivalent to build a kernel
  * with CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
  **/
diff --git a/drivers/base/firmware_loader/firmware.h b/drivers/base/firmware_loader/firmware.h
index 7ecd590e67fe..8656e5239a80 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -27,16 +27,16 @@ 
  *	firmware file lookup on storage is avoided. Used for calls where the
  *	file may be too big, or where the driver takes charge of its own
  *	firmware caching mechanism.
- * @FW_OPT_NOFALLBACK: Disable the fallback mechanism. Takes precedence over
- *	&FW_OPT_UEVENT and &FW_OPT_USERHELPER.
+ * @FW_OPT_NOFALLBACK_SYSFS: Disable the sysfs fallback mechanism. Takes
+ *	precedence over &FW_OPT_UEVENT and &FW_OPT_USERHELPER.
  */
 enum fw_opt {
-	FW_OPT_UEVENT =         BIT(0),
-	FW_OPT_NOWAIT =         BIT(1),
-	FW_OPT_USERHELPER =     BIT(2),
-	FW_OPT_NO_WARN =        BIT(3),
-	FW_OPT_NOCACHE =        BIT(4),
-	FW_OPT_NOFALLBACK =     BIT(5),
+	FW_OPT_UEVENT			= BIT(0),
+	FW_OPT_NOWAIT			= BIT(1),
+	FW_OPT_USERHELPER		= BIT(2),
+	FW_OPT_NO_WARN			= BIT(3),
+	FW_OPT_NOCACHE			= BIT(4),
+	FW_OPT_NOFALLBACK_SYSFS		= BIT(5),
 };
 
 enum fw_status {
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index 249add8c5e05..57133a9dad09 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -877,7 +877,7 @@  int request_firmware_direct(const struct firmware **firmware_p,
 	__module_get(THIS_MODULE);
 	ret = _request_firmware(firmware_p, name, device, NULL, 0,
 				FW_OPT_UEVENT | FW_OPT_NO_WARN |
-				FW_OPT_NOFALLBACK);
+				FW_OPT_NOFALLBACK_SYSFS);
 	module_put(THIS_MODULE);
 	return ret;
 }