Hi Kishon, On Tue, 4 May 2021 at 04:42, Kishon Vijay Abraham I <kis...@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 <vigne...@ti.com> > Signed-off-by: Kishon Vijay Abraham I <kis...@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 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? Regards, Simon
