All of lore.kernel.org
 help / color / mirror / Atom feed
From: cang@codeaurora.org
To: Doug Anderson <dianders@chromium.org>
Cc: subhashj@codeaurora.org, Asutosh Das <asutoshd@codeaurora.org>,
	Vivek Gautam <vivek.gautam@codeaurora.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	Evan Green <evgreen@chromium.org>,
	Vinayak Holikatti <vinholikatti@gmail.com>,
	jejb@linux.vnet.ibm.com,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org, venkatg@codeaurora.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] scsi: ufs: make UFS Tx lane1 clock optional
Date: Wed, 10 Oct 2018 21:46:33 +0800	[thread overview]
Message-ID: <36c6c1a95ff396ac108501f9fe76ef65@codeaurora.org> (raw)
In-Reply-To: <CAD=FV=Xg4UtkJxvVQ2_ky+6-XnM=FvXcnc8xb=uhHeiP5bdFiw@mail.gmail.com>

Hi Doug,

Really thank you for your review.

On 2018-10-10 05:56, Doug Anderson wrote:
> Hi,
> 
> On Sun, Oct 7, 2018 at 9:34 PM Can Guo <cang@codeaurora.org> wrote:
>> 
>> From: Venkat Gopalakrishnan <venkatg@codeaurora.org>
>> 
>> The UFS Tx lane1 clock could be muxed, hence keep it optional by 
>> ignoring
>> it if it is not provided in device tree.
> 
> Thanks for the updated commit message.  This makes much more sense now! 
>  :-)
> 
> 

Yeah, sorry for making you guys confused. My bad previously.

>> @@ -113,10 +110,10 @@ static void ufs_qcom_disable_lane_clks(struct 
>> ufs_qcom_host *host)
>>         if (!host->is_lane_clks_enabled)
>>                 return;
>> 
>> -       if (host->hba->lanes_per_direction > 1)
>> +       if (host->tx_l1_sync_clk)
>>                 clk_disable_unprepare(host->tx_l1_sync_clk);
> 
> I don't believe you need the "if".  A NULL clock is by definition OK
> to enable / disable which is designed to make optional clocks easier
> to deal with.
> 
> 

You are right, I checked the implemention, clock enable/disable func 
would
bail out if clk is NULL just as your comments.

>>         clk_disable_unprepare(host->tx_l0_sync_clk);
>> -       if (host->hba->lanes_per_direction > 1)
>> +       if (host->rx_l1_sync_clk)
>>                 clk_disable_unprepare(host->rx_l1_sync_clk);
> 
> optional: Technically this part of the patch wasn't actually needed,
> right?  "rx_l1_sync_clk" is not optional so that means that
> "rx_l1_sync_clk" should be non-NULL exactly when lanes_per_direction >
> 1.
> 
> ...but actually I'm fine with keeping this part of your patch for
> symmetry.  Especially since you can leverage the
> clk_disable_unprepare(NULL) to simplify your code.  Please mention in
> your commit message that this is a cleanup and just for symmetry.
> Probably also remove the "if" tests that are guarding
> ufs_qcom_host_clk_enable().
> 
> 

Sure, got it.

>>         clk_disable_unprepare(host->rx_l0_sync_clk);
>> 
>> @@ -141,24 +138,21 @@ static int ufs_qcom_enable_lane_clks(struct 
>> ufs_qcom_host *host)
>>         if (err)
>>                 goto disable_rx_l0;
>> 
>> -       if (host->hba->lanes_per_direction > 1) {
>> +       if (host->rx_l1_sync_clk) {
> 
> Similar: the above change isn't required but I'm OK if you want to
> make this change for symmetry / to cleanup clock handling.  Please
> mention in your commit message.
> 
> 

Sure, shall do so.

>> +       /* The tx lane1 clk could be muxed, hence keep this optional 
>> */
>> +       if (host->tx_l1_sync_clk)
>> +               ufs_qcom_host_clk_enable(dev, "tx_lane1_sync_clk",
>> +                                        host->tx_l1_sync_clk);
> 
> If "host->tx_l1_sync_clk" is provided then you should still check the
> return value of ufs_qcom_host_clk_enable(), right?  ...so please leave
> the error path here.
> 
> 

Yeah... you are right.

>> @@ -174,23 +168,33 @@ static int ufs_qcom_init_lane_clks(struct 
>> ufs_qcom_host *host)
>> 
>>         err = ufs_qcom_host_clk_get(dev,
>>                         "rx_lane0_sync_clk", &host->rx_l0_sync_clk);
>> -       if (err)
>> +       if (err) {
>> +               dev_err(dev, "%s: failed to get rx_lane0_sync_clk, err 
>> %d",
>> +                               __func__, err);
> 
> nit: including "__func__" in dev_xxx() calls is discouraged.  The
> "dev_xxx" calls already print the device name and the string within a
> given device driver should be unique enough so __func__ just adds crap
> to the logs.  If you really feel that __func__ adds something for you,
> try posting up a patch to make all "dev_err" functions include
> __func__.  ...but I think you'd probably be rejected.
> 
> suggestion: you'd save a few lines of code and simplify your probe if
> you just passed an "optional" bool to the ufs_qcom_host_clk_get() that
> controlled the printout.
> 
> 

Good idea!

>> -               err = ufs_qcom_host_clk_get(dev, "tx_lane1_sync_clk",
>> -                       &host->tx_l1_sync_clk);
>> +               /* The tx lane1 clk could be muxed, hence keep this 
>> optional */
>> +               ufs_qcom_host_clk_get(dev, "tx_lane1_sync_clk",
>> +                                       &host->tx_l1_sync_clk);
> 
> To be technically correct you should actually check the error value
> returned by ufs_qcom_host_clk_get().  Specifically figure out what the
> error value is when "tx_lane1_sync_clk" isn't specified and check for
> that.
> 
> ...one reason this matters is -EPROBE_DEFER.  In theory devm_clk_get()
> could return -EPROBE_DEFER.  In such a case you'd want to exit the
> probe, not continue on.  It's also just good coding practice to handle
> just the error you want though so that if the function returned some
> other failing case you'd propagate it down instead of eating it.
> 
> If you passed "optional" to ufs_qcom_host_clk_get() as suggested above
> you could put this error-code checking in ufs_qcom_host_clk_get() and
> return 0 from that function if an optional clock was found to not
> exist.
> 
> -Doug

I think I understand it. Thanks a lot for the thorough review and 
suggestions.

-Can Guo

      reply	other threads:[~2018-10-10 13:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-08  4:34 [PATCH 1/1] scsi: ufs: make UFS Tx lane1 clock optional Can Guo
2018-10-08  4:34 ` Can Guo
2018-10-09 21:56 ` Doug Anderson
2018-10-10 13:46   ` cang [this message]

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=36c6c1a95ff396ac108501f9fe76ef65@codeaurora.org \
    --to=cang@codeaurora.org \
    --cc=asutoshd@codeaurora.org \
    --cc=dianders@chromium.org \
    --cc=evgreen@chromium.org \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=rnayak@codeaurora.org \
    --cc=subhashj@codeaurora.org \
    --cc=venkatg@codeaurora.org \
    --cc=vinholikatti@gmail.com \
    --cc=vivek.gautam@codeaurora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.