All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Crispin <john@phrozen.org>
To: Thierry Reding <thierry.reding@gmail.com>,
	Ryder Lee <ryder.lee@mediatek.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	linux-pwm@vger.kernel.org, Weijie Gao <weijie.gao@mediatek.com>,
	Roy Luo <cheng-hao.luo@mediatek.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [resend PATCH 1/3] pwm: mediatek: drop flag 'has_clks'
Date: Wed, 14 Nov 2018 14:27:25 +0100	[thread overview]
Message-ID: <2fc9dbac-4919-4ceb-49ac-67ddd7f203b5@phrozen.org> (raw)
In-Reply-To: <20181114124752.GI2620@ulmo>


On 14/11/2018 13:47, Thierry Reding wrote:
> On Tue, Nov 13, 2018 at 10:08:22AM +0800, Ryder Lee wrote:
>> The flag 'has_clks' and related checks are superfluous as the CCF
>> subsystem does this for you.
> Both of these mechanisms aren't equivalent. While CCF can deal with
> optional clocks, what the has_clks flag actually means is that the
> device doesn't need a clock (or doesn't have a clock input) on the
> devices where it is cleared.
>
> So I'd actually be in favor of keeping the has_clks property because it
> serves as an additional sanity check. For example if you run this driver
> on an SoC that "has clocks" but if you don't list them in DT, then after
> this patch the driver will happily continue without clocks, even though
> it may break completely without those clocks. I've seen SoCs respond to
> disabled clocks for a hardware block in different ways, in many cases an
> access to any of the registers will completely hang the CPU. In other
> cases it may just crash in some other way or give you some sort of
> machine exception. None of those are good, and make the tiny bit of
> additional code required to support the has_clks flag very attractive.
>
> But that's just my opinion. If you prefer to throw away that safety
> barrier, be my guest. But if you do, please move this functionality into
> the clock framework first and then make the driver use it.
>
> Thierry

Hi,

sorry for my late response. I added the flag for the legacy MIPS 
silicon. These SoCs only have a single clock register with a few on/off 
bits. there is no complex clocktree or scaling. Hence COMMON_CLK is not 
supported by those SoCs. I fully agree with Thierry, that the flag makes 
this explicit and the intent was indeed to make sure that on silicon 
where clocks are required, that they really are listed in OF. This is 
indeed an extra sanity check and hiding it in an implicit check inside 
CCF does not feel right.

     John


WARNING: multiple messages have this Message-ID (diff)
From: john@phrozen.org (John Crispin)
To: linux-arm-kernel@lists.infradead.org
Subject: [resend PATCH 1/3] pwm: mediatek: drop flag 'has_clks'
Date: Wed, 14 Nov 2018 14:27:25 +0100	[thread overview]
Message-ID: <2fc9dbac-4919-4ceb-49ac-67ddd7f203b5@phrozen.org> (raw)
In-Reply-To: <20181114124752.GI2620@ulmo>


On 14/11/2018 13:47, Thierry Reding wrote:
> On Tue, Nov 13, 2018 at 10:08:22AM +0800, Ryder Lee wrote:
>> The flag 'has_clks' and related checks are superfluous as the CCF
>> subsystem does this for you.
> Both of these mechanisms aren't equivalent. While CCF can deal with
> optional clocks, what the has_clks flag actually means is that the
> device doesn't need a clock (or doesn't have a clock input) on the
> devices where it is cleared.
>
> So I'd actually be in favor of keeping the has_clks property because it
> serves as an additional sanity check. For example if you run this driver
> on an SoC that "has clocks" but if you don't list them in DT, then after
> this patch the driver will happily continue without clocks, even though
> it may break completely without those clocks. I've seen SoCs respond to
> disabled clocks for a hardware block in different ways, in many cases an
> access to any of the registers will completely hang the CPU. In other
> cases it may just crash in some other way or give you some sort of
> machine exception. None of those are good, and make the tiny bit of
> additional code required to support the has_clks flag very attractive.
>
> But that's just my opinion. If you prefer to throw away that safety
> barrier, be my guest. But if you do, please move this functionality into
> the clock framework first and then make the driver use it.
>
> Thierry

Hi,

sorry for my late response. I added the flag for the legacy MIPS 
silicon. These SoCs only have a single clock register with a few on/off 
bits. there is no complex clocktree or scaling. Hence COMMON_CLK is not 
supported by those SoCs. I fully agree with Thierry, that the flag makes 
this explicit and the intent was indeed to make sure that on silicon 
where clocks are required, that they really are listed in OF. This is 
indeed an extra sanity check and hiding it in an implicit check inside 
CCF does not feel right.

 ??? John

  reply	other threads:[~2018-11-14 13:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13  2:08 [resend PATCH 1/3] pwm: mediatek: drop flag 'has_clks' Ryder Lee
2018-11-13  2:08 ` Ryder Lee
2018-11-13  2:08 ` Ryder Lee
2018-11-13  2:08 ` [resend PATCH 2/3] pwm: mediatek: add pwm support for MT7629 SoC Ryder Lee
2018-11-13  2:08   ` Ryder Lee
2018-11-13  2:08   ` Ryder Lee
2018-11-15 19:20   ` Sean Wang
2018-11-15 19:20     ` Sean Wang
2018-11-13  2:08 ` [resend PATCH 3/3] dt-bindings: pwm: update bindings " Ryder Lee
2018-11-13  2:08   ` Ryder Lee
2018-11-13  2:08   ` Ryder Lee
2018-11-13  9:55   ` Uwe Kleine-König
2018-11-13  9:55     ` Uwe Kleine-König
2018-11-13  9:52 ` [resend PATCH 1/3] pwm: mediatek: drop flag 'has_clks' Uwe Kleine-König
2018-11-13  9:52   ` Uwe Kleine-König
2018-11-13 18:00   ` Stephen Boyd
2018-11-13 18:00     ` Stephen Boyd
2018-11-14 12:47 ` Thierry Reding
2018-11-14 12:47   ` Thierry Reding
2018-11-14 13:27   ` John Crispin [this message]
2018-11-14 13:27     ` John Crispin
2018-11-15  2:16     ` Ryder Lee
2018-11-15  2:16       ` Ryder Lee
2018-11-15  2:16       ` Ryder Lee
2018-11-16  6:47   ` Uwe Kleine-König
2018-11-16  6:47     ` Uwe Kleine-König
2018-11-16 10:22     ` Thierry Reding
2018-11-16 10:22       ` Thierry Reding

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=2fc9dbac-4919-4ceb-49ac-67ddd7f203b5@phrozen.org \
    --to=john@phrozen.org \
    --cc=cheng-hao.luo@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=ryder.lee@mediatek.com \
    --cc=thierry.reding@gmail.com \
    --cc=weijie.gao@mediatek.com \
    /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.