[PATCH 02/16] drivers: reset: Handle gracefully NULL pointers

Kishon Vijay Abraham I kishon at ti.com
Tue Mar 23 08:16:32 CET 2021


Hi Simon,

On 23/03/21 6:26 am, Simon Glass wrote:
> Hi Kishon,
> 
> On Mon, 22 Mar 2021 at 18:11, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>>
>> Hi Simon,
>>
>> On 12/03/21 10:15 am, Simon Glass wrote:
>>> Hi Kishon,
>>>
>>> On Tue, 9 Mar 2021 at 05:27, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>>>>
>>>> From: Jean-Jacques Hiblot <jjhiblot at ti.com>
>>>>
>>>> Prepare the way for a managed reset API by handling NULL pointers without
>>>> crashing nor failing.
>>>>
>>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot at ti.com>
>>>> Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
>>>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>>>> ---
>>>>  drivers/reset/reset-uclass.c | 30 +++++++++++++++++-------------
>>>>  1 file changed, 17 insertions(+), 13 deletions(-)
>>>
>>> Why do you want this? This patch is missing the motivation which
>>> should be at the start of the commit message.
>>
>> This is for "optional" reset controllers used by peripheral drivers.
>> This will help avoid adding checks in peripheral drivers.
> 
> Can you please be more specific?

Sorry for not being clear.

Cadence Torrent SERDES has a reset line for APB (APB_RESET). This reset
line is connected in Cadence platform but not connected in TI platform
which also uses the Torrent SERDES.

So in the Cadence Torrent driver we use
devm_reset_control_get_optional() which returns NULL when used in TI
platform. However if we use the return value of
devm_reset_control_get_optional() directly in reset_ops (for TI), it
will result in abort.

This patch helps to avoid adding additional checks before invoking
reset_ops.

Thanks
Kishon


More information about the U-Boot mailing list