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 <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kory Maincent <[email protected]>
---
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/[email protected]/
---
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 <[email protected]>
> Acked-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Kory Maincent <[email protected]>
> ---
>
> 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/[email protected]/
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 <[email protected]>
> > Acked-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Kory Maincent <[email protected]>
> > ---
> >
> > 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/[email protected]/
>
> 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 <[email protected]>
> > > Acked-by: Greg Kroah-Hartman <[email protected]>
> > > Signed-off-by: Kory Maincent <[email protected]>
> > > ---
> > >
> > > 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/[email protected]/
> >
> > 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 <[email protected]> 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/[email protected]/
> > > >
> > >
> > > 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.