Date:   Tue, 3 Apr 2018 16:05:17 +0530
From:   Vivek Gautam <vivek.gautam@...eaurora.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Philipp Zabel <p.zabel@...gutronix.de>
Cc:     Felipe Balbi <felipe.balbi@...ux.intel.com>,
        linux-usb@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Felipe Balbi <balbi@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: dwc3: of-simple: use managed and shared reset
 control



On 4/3/2018 3:49 PM, Masahiro Yamada wrote:
> 2018-04-03 17:46 GMT+09:00 Philipp Zabel <p.zabel@...gutronix.de>:
>> On Tue, 2018-04-03 at 17:30 +0900, Masahiro Yamada wrote:
>>> 2018-04-03 17:00 GMT+09:00 Philipp Zabel <p.zabel@...gutronix.de>:
>>>> On Thu, 2018-03-29 at 15:07 +0900, Masahiro Yamada wrote:
>>>>> This driver handles the reset control in a common manner; deassert
>>>>> resets before use, assert them after use.  There is no good reason
>>>>> why it should be exclusive.
>>>> Is this preemptive cleanup, or do you have hardware on the horizon that
>>>> shares these reset lines with other peripherals?
>>> This patch is necessary for Socionext SoCs.
>>>
>>> The same reset lines are shared between
>>> this dwc3-of_simple and other glue circuits.
>> Thanks, this is helpful information.
>>
>>>>> Also, use devm_ for clean-up.
>>>>>
>>>>> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
>>>>> ---
>>>>>
>>>>> CCing Philipp Zabel.
>>>>> I see his sob in commit 06c47e6286d5.
>>>> At the time I was concerned with the reset_control_array addition and
>>>> didn't look closely at the exclusive vs shared issue.
>>>>>   drivers/usb/dwc3/dwc3-of-simple.c | 7 ++-----
>>>>>   1 file changed, 2 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c b/drivers/usb/dwc3/dwc3-of-simple.c
>>>>> index e54c362..bd6ab65 100644
>>>>> --- a/drivers/usb/dwc3/dwc3-of-simple.c
>>>>> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
>>>>> @@ -91,7 +91,7 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
>>>>>        platform_set_drvdata(pdev, simple);
>>>>>        simple->dev = dev;
>>>>>
>>>>> -     simple->resets = of_reset_control_array_get_optional_exclusive(np);
>>>>> +     simple->resets = devm_reset_control_array_get_optional_shared(dev);
>>>>  From the usage in the driver, it does indeed look like _shared reset
>>>> usage is appropriate. I assume that the hardware has no need for the
>>>> reset to be asserted right before probe or after remove, it just
>>>> requires that the reset line is kept deasserted while the driver is
>>>> probed.
>>>>
>>>>>        if (IS_ERR(simple->resets)) {
>>>>>                ret = PTR_ERR(simple->resets);
>>>>>                dev_err(dev, "failed to get device resets, err=%d\n", ret);
>>>>> @@ -100,7 +100,7 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
>>>>>
>>>>>        ret = reset_control_deassert(simple->resets);
>>>>>        if (ret)
>>>>> -             goto err_resetc_put;
>>>>> +             return ret;
>>>>>
>>>>>        ret = dwc3_of_simple_clk_init(simple, of_count_phandle_with_args(np,
>>>>>                                                "clocks", "#clock-cells"));
>>>>> @@ -126,8 +126,6 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
>>>>>   err_resetc_assert:
>>>>>        reset_control_assert(simple->resets);
>>>>>
>>>>> -err_resetc_put:
>>>>> -     reset_control_put(simple->resets);
>>>>>        return ret;
>>>>>   }
>>>>>
>>>>> @@ -146,7 +144,6 @@ static int dwc3_of_simple_remove(struct platform_device *pdev)
>>>>>        simple->num_clocks = 0;
>>>>>
>>>>>        reset_control_assert(simple->resets);
>>>>> -     reset_control_put(simple->resets);
>>>>>
>>>>>        pm_runtime_put_sync(dev);
>>>>>        pm_runtime_disable(dev);
>>>> Changing to devm_ changes the order here. Whether or not it could be a
>>>> problem to assert the reset only after pm_runtime_put (or potentially
>>>> never), I can't say. I assume this is a non-issue, but somebody who
>>>> knows the hardware better would have to decide.
>>>
>>>
>>> I do not understand what you mean.
>> Sorry for the confusion, I have mixed up things here.
>>
>>> Can you describe your concern in more details?
>>>
>>> I am not touching reset_control_assert() here.
>> With the change to shared reset control, reset_control_assert
>> potentially does nothing, so it could be possible that
>> pm_runtime_put_sync cuts the power before the reset es asserted again.
>>
>>> I am delaying the call for reset_control_put().
>> Yes, please disregard my comment about the devm_ change, that should
>> have no effect whatsoever and looks fine to me.
>>
>>> If I understand reset_control_put() correctly,
>>> the effects of this change are:
>>>    - The ref_count and module ownership for the reset controller
>>>      driver will be held a little longer
>>>    - The call for kfree() will be a little bit delayed.
>> Correct.
>>
>>> Why do you need knowledge about this hardware?
>> Is it ok to keep the reset deasserted while the power is cut?
>> Or do you
>> have to guarantee that drivers sharing the same reset also keep the same
>> power domains active?
>>
> If this were really a problem, the driver would have to check
> the error code from reset_control_assert().

Just to understand this - If the power domain isn't active for the said 
device,
does it matter if it is in reset state or not?

>
>
>   ret = reset_control_assert(simple->resets);
>   if (ret)
>             return ret; /* if we cannot assert reset, do not allow
> driver detach */

What's the point of this. The power domain and reset should be independent
of each other, and when we are doing a driver detach, the state of hardware
should be of less concern.
The device should anyways not leak power when the power domain isn't active.

Regards
Vivek
>
>   pm_runtime_put_sync(dev);
>   pm_runtime_disable(dev);
>   return 0;
>
>
>
> What I can tell is, the current situation is
> blocking hardware with shared reset lines
> from using this driver.
>
>
>

Powered by blists - more mailing lists