From: Shuah Khan <shuahkh@osg.samsung.com>
To: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org, balbi@kernel.org,
gregkh@linuxfoundation.org, kgene@kernel.org, krzk@kernel.org,
javier@osg.samsung.com, linux-samsung-soc@vger.kernel.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Shuah Khan <shuahkh@osg.samsung.com>
Subject: Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
Date: Tue, 10 Jan 2017 09:28:52 -0700 [thread overview]
Message-ID: <28815306-e220-4847-99ce-b058baae0d07@osg.samsung.com> (raw)
In-Reply-To: <8784459.rxWqZlDLVg@amdc3058>
On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>>>> error path only when susp_clk has been set from remove and probe error
>>>>> paths.
>>>>
>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>>>> for NULL clock. Also your patch changes susp_clk handling while
>>>> leaves axius_clk handling (which also can be NULL) untouched.
>>>>
>>>> Do you actually see some runtime problem with the current code?
>>>>
>>>> If not then the patch should probably be dropped.
>>>>
>>>> Best regards,
>>>> --
>>>> Bartlomiej Zolnierkiewicz
>>>> Samsung R&D Institute Poland
>>>> Samsung Electronics
>>>
>>> Hi Bartlomiej,
>>>
>>> I am seeing the "no suspend clk specified" message in dmesg.
>>> After that it sets the exynos->susp_clk = NULL and starts
>>> calling clk_prepare_enable(exynos->susp_clk);
>>>
>>> That can't be good. If you see the logic right above this
>>> one for exynos->clk, it returns error and fails the probe.
>>> This this case it doesn't, but tries to use null susp_clk.
>
> exynos->susp_clk is optional, exynos->clk is not.
Right. That is clear since we don't fail the probe.
>
>>> I believe this patch is necessary.
>>
>> Let me clarify this a bit further. Since we already know
>> susp_clk is null, with this patch we can avoid extra calls
>> to clk_prepare_enable() and clk_disable_unprepare().
>>
>> One can say, it also adds extra checks, hence I will let you
>> decide one way or the other. :)
>
> I would prefer to leave the things as they are currently.
>
> The code in question is not performance sensitive so extra
> calls are not a problem. No extra checks means less code.
>
> Also the current code seems to be more in line with the rest
> of the kernel.
What functionality is missing without the suspend clock? Would
it make sense to change the info. message to include what it
means. At the moment it doesn't anything more than "no suspend
clock" which is a very cryptic user visible message. It would be
helpful for it to also include what functionality is impacted.
thanks,
-- Shuah
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
>> thanks,
>> -- Shuah
>>
>>>
>>> thanks,
>>> -- Shuah
>>>
>>>>
>>>>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>>>>> ---
>>>>> drivers/usb/dwc3/dwc3-exynos.c | 10 ++++++----
>>>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>>>>> index e27899b..f97a3d7 100644
>>>>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>>>>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>>>>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>>>>> if (IS_ERR(exynos->susp_clk)) {
>>>>> dev_info(dev, "no suspend clk specified\n");
>>>>> exynos->susp_clk = NULL;
>>>>> - }
>>>>> - clk_prepare_enable(exynos->susp_clk);
>>>>> + } else
>>>>> + clk_prepare_enable(exynos->susp_clk);
>>>>>
>>>>> if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
>>>>> exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
>>>>> @@ -196,7 +196,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>>>>> regulator_disable(exynos->vdd33);
>>>>> err2:
>>>>> clk_disable_unprepare(exynos->axius_clk);
>>>>> - clk_disable_unprepare(exynos->susp_clk);
>>>>> + if (exynos->susp_clk)
>>>>> + clk_disable_unprepare(exynos->susp_clk);
>>>>> clk_disable_unprepare(exynos->clk);
>>>>> return ret;
>>>>> }
>>>>> @@ -210,7 +211,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
>>>>> platform_device_unregister(exynos->usb3_phy);
>>>>>
>>>>> clk_disable_unprepare(exynos->axius_clk);
>>>>> - clk_disable_unprepare(exynos->susp_clk);
>>>>> + if (exynos->susp_clk)
>>>>> + clk_disable_unprepare(exynos->susp_clk);
>>>>> clk_disable_unprepare(exynos->clk);
>>>>>
>>>>> regulator_disable(exynos->vdd33);
>
next prev parent reply other threads:[~2017-01-10 16:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-10 2:21 Shuah Khan
2017-01-10 11:20 ` Sergei Shtylyov
2017-01-10 14:38 ` Shuah Khan
[not found] ` <CGME20170110120605epcas1p1c26f7f90fca4765ab9cc339c51d11347@epcas1p1.samsung.com>
2017-01-10 12:05 ` Bartlomiej Zolnierkiewicz
2017-01-10 14:16 ` Shuah Khan
2017-01-10 14:36 ` Shuah Khan
[not found] ` <CGME20170110160532epcas1p198cef8317dcbc8740366d06b38e7465f@epcas1p1.samsung.com>
2017-01-10 16:05 ` Bartlomiej Zolnierkiewicz
2017-01-10 16:28 ` Shuah Khan [this message]
[not found] ` <CGME20170110170942epcas1p3decee28366d7d42b70e7b0669b97326f@epcas1p3.samsung.com>
2017-01-10 17:09 ` Bartlomiej Zolnierkiewicz
2017-01-10 17:49 ` vivek.gautam
2017-01-10 18:25 ` Krzysztof Kozlowski
2017-01-11 2:43 ` pankaj.dubey
2017-01-10 17:53 ` Anand Moon
[not found] ` <CGME20170110180359epcas1p4729103fd575fe628bfd3ea7966ec4856@epcas1p4.samsung.com>
2017-01-10 18:03 ` Bartlomiej Zolnierkiewicz
[not found] ` <CGME20170110182345epcas1p3112f94aad300625ff1f75860c55a2b7e@epcas1p3.samsung.com>
2017-01-10 18:23 ` Bartlomiej Zolnierkiewicz
2017-01-10 18:37 ` Shuah Khan
2017-01-10 18:59 ` Krzysztof Kozlowski
2017-01-10 19:20 ` Shuah Khan
2017-01-10 18:36 ` Anand Moon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28815306-e220-4847-99ce-b058baae0d07@osg.samsung.com \
--to=shuahkh@osg.samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=javier@osg.samsung.com \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®