[PATCH v3 03/20] drivers: reset: Handle gracefully NULL pointers
Kishon Vijay Abraham I
kishon at ti.com
Wed May 5 06:25:20 CEST 2021
On 04/05/21 10:28 pm, Simon Glass wrote:
> Hi Kishon,
> On Tue, 4 May 2021 at 04:42, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>> The reset framework provides devm_reset_control_get_optional()
>> which can return NULL (not an error case). So all the other reset_ops
>> should handle NULL gracefully. Prepare the way for a managed reset
>> API by handling NULL pointers without crashing nor failing.
>> 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 | 35 ++++++++++++++++++++++++++++++-----
>> 1 file changed, 30 insertions(+), 5 deletions(-)
> I am still not a fan of this. There is no way to know whether the
> reset API call actually did anything. Normally we return -EINVAL or
> something like that when the value is invalid (e.g. see GPIO uclass).
The reset modification is more in-line with how clk uclass is designed.
There every API first checks if the clock is valid and returns 0 (will
be the case for optional clocks)
If you don't prefer this approach, I'll drop this patch and handle it
appropriately in the client driver (serdes driver). Please let me know.
> The function you mention says: * Returns a struct reset_ctl or a
> dummy reset controller if it failed.
> But it does not appear to do that?
Right, looks like it's incorrect from when the patch was actually
introduced. It was returning "NULL" for optional resets.
Author: Jean-Jacques Hiblot <jjhiblot at ti.com>
Date: Wed Sep 9 15:37:03 2020 +0530
drivers: reset: Add a managed API to get reset controllers from the DT
More information about the U-Boot