No error code are available to signal an invalid firmware content.
Drivers that can check the firmware content validity can not return this
specific failure to the user-space

Expand the firmware error code with an additional code:
- "firmware invalid" code which can be used when the provided firmware
  is invalid

Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---

This patch was initially submitted as part of a net patch series.
Conor expressed interest in using it in a different subsystem.
Consequently, I extracted it from the series and submitted it separately
to the main tree, driver-core.
https://lore.kernel.org/netdev/20231116-feature_poe-v1-7-be48044bf249@bootlin.com/
---
 drivers/base/firmware_loader/sysfs_upload.c | 1 +
 include/linux/firmware.h                    | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/base/firmware_loader/sysfs_upload.c b/drivers/base/firmware_loader/sysfs_upload.c
index a0af8f5f13d8..829270067d16 100644
--- a/drivers/base/firmware_loader/sysfs_upload.c
+++ b/drivers/base/firmware_loader/sysfs_upload.c
@@ -27,6 +27,7 @@ static const char * const fw_upload_err_str[] = {
 	[FW_UPLOAD_ERR_INVALID_SIZE] = "invalid-file-size",
 	[FW_UPLOAD_ERR_RW_ERROR]     = "read-write-error",
 	[FW_UPLOAD_ERR_WEAROUT]	     = "flash-wearout",
+	[FW_UPLOAD_ERR_FW_INVALID]   = "firmware-invalid",
 };
 
 static const char *fw_upload_progress(struct device *dev,
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index de7fea3bca51..0311858b46ce 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -27,6 +27,7 @@ struct firmware {
  * @FW_UPLOAD_ERR_INVALID_SIZE: invalid firmware image size
  * @FW_UPLOAD_ERR_RW_ERROR: read or write to HW failed, see kernel log
  * @FW_UPLOAD_ERR_WEAROUT: FLASH device is approaching wear-out, wait & retry
+ * @FW_UPLOAD_ERR_FW_INVALID: invalid firmware file
  * @FW_UPLOAD_ERR_MAX: Maximum error code marker
  */
 enum fw_upload_err {
@@ -38,6 +39,7 @@ enum fw_upload_err {
 	FW_UPLOAD_ERR_INVALID_SIZE,
 	FW_UPLOAD_ERR_RW_ERROR,
 	FW_UPLOAD_ERR_WEAROUT,
+	FW_UPLOAD_ERR_FW_INVALID,
 	FW_UPLOAD_ERR_MAX
 };
 

---
base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86
change-id: 20231117-feature_firmware_error_code-b8d7af08a8fe

Best regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

On Fri, Nov 17, 2023 at 11:27:53AM +0100, Kory Maincent wrote:
> No error code are available to signal an invalid firmware content.
> Drivers that can check the firmware content validity can not return this
> specific failure to the user-space
> 
> Expand the firmware error code with an additional code:
> - "firmware invalid" code which can be used when the provided firmware
>   is invalid
> 
> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
> 
> This patch was initially submitted as part of a net patch series.
> Conor expressed interest in using it in a different subsystem.
> Consequently, I extracted it from the series and submitted it separately
> to the main tree, driver-core.
> https://lore.kernel.org/netdev/20231116-feature_poe-v1-7-be48044bf249@bootlin.com/

So you want me to take it through my tree?  Sure, but if you are relying
on this for any other code, it will be a while before it gets into
Linus's tree, not until 6.8-rc1, is that ok?

thanks,

greg k-h

On Fri, Nov 17, 2023 at 08:45:59AM -0500, Greg Kroah-Hartman wrote:
> On Fri, Nov 17, 2023 at 11:27:53AM +0100, Kory Maincent wrote:
> > No error code are available to signal an invalid firmware content.
> > Drivers that can check the firmware content validity can not return this
> > specific failure to the user-space
> > 
> > Expand the firmware error code with an additional code:
> > - "firmware invalid" code which can be used when the provided firmware
> >   is invalid
> > 
> > Acked-by: Luis Chamberlain <mcgrof@kernel.org>
> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> > ---
> > 
> > This patch was initially submitted as part of a net patch series.
> > Conor expressed interest in using it in a different subsystem.
> > Consequently, I extracted it from the series and submitted it separately
> > to the main tree, driver-core.
> > https://lore.kernel.org/netdev/20231116-feature_poe-v1-7-be48044bf249@bootlin.com/
> 
> So you want me to take it through my tree?  Sure, but if you are relying
> on this for any other code, it will be a while before it gets into
> Linus's tree, not until 6.8-rc1, is that ok?

My idea was that you could create a stable branch, which can then be
pulled into netdev and arm-soc.

If you don't want to do that, we can ask Arnd to take it, and he can
create a stable branch which we pull into netdev.

       Andrew

On Fri, Nov 17, 2023 at 03:06:44PM +0100, Andrew Lunn wrote:
> On Fri, Nov 17, 2023 at 08:45:59AM -0500, Greg Kroah-Hartman wrote:
> > On Fri, Nov 17, 2023 at 11:27:53AM +0100, Kory Maincent wrote:
> > > No error code are available to signal an invalid firmware content.
> > > Drivers that can check the firmware content validity can not return this
> > > specific failure to the user-space
> > > 
> > > Expand the firmware error code with an additional code:
> > > - "firmware invalid" code which can be used when the provided firmware
> > >   is invalid
> > > 
> > > Acked-by: Luis Chamberlain <mcgrof@kernel.org>
> > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> > > ---
> > > 
> > > This patch was initially submitted as part of a net patch series.
> > > Conor expressed interest in using it in a different subsystem.
> > > Consequently, I extracted it from the series and submitted it separately
> > > to the main tree, driver-core.
> > > https://lore.kernel.org/netdev/20231116-feature_poe-v1-7-be48044bf249@bootlin.com/
> > 
> > So you want me to take it through my tree?  Sure, but if you are relying
> > on this for any other code, it will be a while before it gets into
> > Linus's tree, not until 6.8-rc1, is that ok?
> 
> My idea was that you could create a stable branch, which can then be
> pulled into netdev and arm-soc.

I'll be glad to do so, you just need to ask me to do that, I don't see
that request here :)

> If you don't want to do that, we can ask Arnd to take it, and he can
> create a stable branch which we pull into netdev.

You want a stable tag to pull from, right?

But really, why not just take this through netdev?  It's just one
commit, I have no problem with it going that way at all.  If the odd
chance there's a merge conflict in the future, I can handle it.

thanks,

greg k-h

On Fri, 17 Nov 2023 14:48:32 -0500
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> > > > This patch was initially submitted as part of a net patch series.
> > > > Conor expressed interest in using it in a different subsystem.
> > > > Consequently, I extracted it from the series and submitted it separately
> > > > to the main tree, driver-core.
> > > > https://lore.kernel.org/netdev/20231116-feature_poe-v1-7-be48044bf249@bootlin.com/
> > > >  
> > > 
> > > So you want me to take it through my tree?  Sure, but if you are relying
> > > on this for any other code, it will be a while before it gets into
> > > Linus's tree, not until 6.8-rc1, is that ok?  
> > 
> > My idea was that you could create a stable branch, which can then be
> > pulled into netdev and arm-soc.  
> 
> I'll be glad to do so, you just need to ask me to do that, I don't see
> that request here :)

Sorry, my fault, I did not know well the merge actions that were needed for
this particular case.

> > If you don't want to do that, we can ask Arnd to take it, and he can
> > create a stable branch which we pull into netdev.  
> 
> You want a stable tag to pull from, right?
> 
> But really, why not just take this through netdev?  It's just one
> commit, I have no problem with it going that way at all.  If the odd
> chance there's a merge conflict in the future, I can handle it.

Seems a good and simple idea to me, Andrew any thoughts about it?
Do I send a single patch to net-next and ask Conor to pull it in his
subsystem for his patch series?

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

> Sorry, my fault, I did not know well the merge actions that were needed for
> this particular case.
> 
> > > If you don't want to do that, we can ask Arnd to take it, and he can
> > > create a stable branch which we pull into netdev.  
> > 
> > You want a stable tag to pull from, right?
> > 
> > But really, why not just take this through netdev?  It's just one
> > commit, I have no problem with it going that way at all.  If the odd
> > chance there's a merge conflict in the future, I can handle it.
> 
> Seems a good and simple idea to me, Andrew any thoughts about it?
> Do I send a single patch to net-next and ask Conor to pull it in his
> subsystem for his patch series?

Yes, send a single patch to netdev. Under the ---, ask for a stable
branch. Jakub should then hopefully reply with information about the
branch, which other Maintainers can then pull.

	Andrew

On Mon, Nov 20, 2023 at 05:52:09PM +0100, Andrew Lunn wrote:
> > Sorry, my fault, I did not know well the merge actions that were needed for
> > this particular case.
> > 
> > > > If you don't want to do that, we can ask Arnd to take it, and he can
> > > > create a stable branch which we pull into netdev.  
> > > 
> > > You want a stable tag to pull from, right?
> > > 
> > > But really, why not just take this through netdev?  It's just one
> > > commit, I have no problem with it going that way at all.  If the odd
> > > chance there's a merge conflict in the future, I can handle it.
> > 
> > Seems a good and simple idea to me, Andrew any thoughts about it?
> > Do I send a single patch to net-next and ask Conor to pull it in his
> > subsystem for his patch series?
> 
> Yes, send a single patch to netdev. Under the ---, ask for a stable
> branch. Jakub should then hopefully reply with information about the
> branch, which other Maintainers can then pull.

Sry, lost track of this a little with catching up on life after being in
the US for a week. Obv. stable branch doesn't matter to me where it
comes from, so that'd be neat.

Cheers,
Conor.