Messages in this thread | | | Date | Tue, 26 Apr 2022 16:35:28 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH 02/22] firmware: arm_scmi: Make protocols init fail on basic errors |
| |
On Wed, Mar 30, 2022 at 04:05:31PM +0100, Cristian Marussi wrote: > Bail out of protocol initialization routine early when basic information > about protocol version and attributes could not be retrieved: failing to > act this way can lead to a successfully initialized SCMI protocol which > is in fact not fully functional. > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > --- > drivers/firmware/arm_scmi/base.c | 5 ++++- > drivers/firmware/arm_scmi/clock.c | 8 ++++++-- > drivers/firmware/arm_scmi/perf.c | 10 +++++++--- > drivers/firmware/arm_scmi/power.c | 10 +++++++--- > drivers/firmware/arm_scmi/reset.c | 10 +++++++--- > drivers/firmware/arm_scmi/sensors.c | 4 +++- > drivers/firmware/arm_scmi/system.c | 5 ++++- > 7 files changed, 38 insertions(+), 14 deletions(-) > > @@ -370,7 +372,9 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph) > if (!cinfo) > return -ENOMEM; > > - scmi_clock_protocol_attributes_get(ph, cinfo); > + ret = scmi_clock_protocol_attributes_get(ph, cinfo); > + if (ret) > + return ret;
Does this result in removal of scmi_dev associated with devm_* calls ? Otherwise we may need to free the allocated buffers ? I am not sure if the dev here is individual scmi_dev or the platform scmi device. I assume latter and it is unlikely to be removed/freed with the error in the above path.
Similarly in couple of other instances/protocols.
-- Regards, Sudeep
| |