| Message ID | 20231116-feature_poe-v1-7-be48044bf249@bootlin.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: Add support for Power over Ethernet (PoE) | expand |
On Thu, Nov 16, 2023 at 03:01:39PM +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 > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Luis
On Thu, Nov 16, 2023 at 03:01:39PM +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 > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > --- > drivers/base/firmware_loader/sysfs_upload.c | 1 + > include/linux/firmware.h | 2 ++ > 2 files changed, 3 insertions(+) Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On Thu, Nov 16, 2023 at 03:01:39PM +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 > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> This would be rather helpful to me for some stuff that I am currently working on and was hoping to send to Arnd for inclusion in 6.8: https://lore.kernel.org/all/20231020-series-uncooked-077b107af3ae@spud/ I'm currently returning a "HW_ERROR" for something that this would fit the bill for (in mpfs_auto_update_write()). What would the ETA for this stuff landing via the net tree be? Since I am not a netdev contributor its hard to tell how controversial these patches are! Cheers, Conor.
> This would be rather helpful to me for some stuff that I am currently > working on and was hoping to send to Arnd for inclusion in 6.8: > https://lore.kernel.org/all/20231020-series-uncooked-077b107af3ae@spud/ > > I'm currently returning a "HW_ERROR" for something that this would fit > the bill for (in mpfs_auto_update_write()). What would the ETA for this > stuff landing via the net tree be? > Since I am not a netdev contributor its hard to tell how controversial > these patches are! It already has the needed ACKs, so it could be merged anytime. However, it seems like two different subsystems are interested in it. So rather than merge it via netdev, it might make sense to merge it via its normal tree, driver-core. Then ask for a stable branch which can be pulled into netdev and arm-soc. Andrew
On Thu, 16 Nov 2023 22:56:10 +0100 Andrew Lunn <andrew@lunn.ch> wrote: > > This would be rather helpful to me for some stuff that I am currently > > working on and was hoping to send to Arnd for inclusion in 6.8: > > https://lore.kernel.org/all/20231020-series-uncooked-077b107af3ae@spud/ > > > > I'm currently returning a "HW_ERROR" for something that this would fit > > the bill for (in mpfs_auto_update_write()). What would the ETA for this > > stuff landing via the net tree be? > > Since I am not a netdev contributor its hard to tell how controversial > > these patches are! > > It already has the needed ACKs, so it could be merged > anytime. However, it seems like two different subsystems are > interested in it. So rather than merge it via netdev, it might make > sense to merge it via its normal tree, driver-core. Then ask for a > stable branch which can be pulled into netdev and arm-soc. Ok, I will remove this patch from this series in v2 and send it through normal tree. Regards,
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 };
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 Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> --- drivers/base/firmware_loader/sysfs_upload.c | 1 + include/linux/firmware.h | 2 ++ 2 files changed, 3 insertions(+)