[PATCH v2 4/7] drivers: firmware: ti_sci: Get SCI revision only if TIFS/SYSFW is up
Neha Malcom Francis
n-francis at ti.com
Fri Sep 8 05:34:26 CEST 2023
Hi Nishanth
On 07/09/23 20:35, Nishanth Menon wrote:
> On 19:44-20230907, Neha Malcom Francis wrote:
>> While setting up necessary dependent clocks and power domains, we end up
>> probing the ti_sci driver before TIFS/SYSFW has been loaded in the case
>> of legacy boot flow devices. This leads to panic when getting the SCI
>> revision. Return the revision only if it is combined boot flow. Also
>
> Not clear description of the problem.
Hmm okay I will modify this and the earlier commit message to give a clearer
picture.
>
>> ensure that after TIFS/SYSFW comes up we run ti_sci_cmd_get_revision
>> again so we print the revision right.
>>
>> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
>> ---
>> drivers/firmware/ti_sci.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
>> index 72f572d824..6a85d202f2 100644
>> --- a/drivers/firmware/ti_sci.c
>> +++ b/drivers/firmware/ti_sci.c
>> @@ -2703,6 +2703,9 @@ struct ti_sci_handle *ti_sci_get_handle_from_sysfw(struct udevice *sci_dev)
>> if (!handle)
>> return ERR_PTR(-EINVAL);
>>
>> + /* May have been skipped in case TIFS/SYSFW had come up later */
> Very confusing comment.
>
Understood, will change that.
>> + ti_sci_cmd_get_revision(handle);
>
> should this be protected with if (IS_ENABLED(CONFIG_K3_DM_FW) ?
>
> Since getting the handle is where the entire flow happens, why not do it
> here always?
>
This is a valid point, I am in the process of making sure there's no other
consequences to getting the revision this late for platforms with other boot
devices, if this gets an all clear, I will push it here for the next version,
else I will explain why I couldn't.
> what if ti_sci_cmd_get_revision fails? there is no error handling here.
Yes that would be a consequence since ti_sci_probe, the logic it was written;
used reading the version as an "all okay return 0" for the TIFS/SYSFW binary.
But now after moving, ti_sci_get_handle_from_sysfw happens after k3_sysfw_loader
so we're not checking binary sanity early on in the case of combined boot
I'm hesitant that we are checking version way later after k3_sysfw_loader for
combined platforms and if that is something we want? But there is an
advantage(?) that it will run every time someone tries to get a handle for doing
anything with TISCI and that would be a kind of check (?) if the binary is good?
Correct me if I'm wrong in thinking that.
>> +
>> return handle;
>> }
>>
>> @@ -2825,7 +2828,11 @@ static int ti_sci_probe(struct udevice *dev)
>> list_add_tail(&info->list, &ti_sci_list);
>> ti_sci_setup_ops(info);
>>
>> - ret = ti_sci_cmd_get_revision(&info->handle);
>> + /* Get SCI revision ONLY if we are real */
>> + if (!IS_ENABLED(CONFIG_K3_DM_FW))
>> + ret = ti_sci_cmd_get_revision(&info->handle);
>> + else
>> + ret = 0;
>>
>> INIT_LIST_HEAD(&info->dev_list);
>>
>> --
>> 2.34.1
>>
>
--
Thanking You
Neha Malcom Francis
More information about the U-Boot
mailing list