linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: Rob Herring <robh@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kernel@stlinux.com,
	maxime.coquelin@st.com, patrice.chotard@st.com,
	linux-pwm@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 20/20] dt-bindings: pwm: sti: Update DT bindings with recent changes
Date: Fri, 10 Jun 2016 15:18:55 +0200	[thread overview]
Message-ID: <20160610131855.GG27142@ulmo.ba.sec> (raw)
In-Reply-To: <20160609114107.GB1388@dell>

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

On Thu, Jun 09, 2016 at 12:41:07PM +0100, Lee Jones wrote:
> On Wed, 08 Jun 2016, Rob Herring wrote:
> 
> > On Wed, Jun 08, 2016 at 10:21:35AM +0100, Lee Jones wrote:
> > > We're renaming the 'st,pwm-num-chan' binding to 'st,pwm-num-devs' to
> > > be more inline with the naming conventions of the subsystem.  Where
> > > we used to treat each line as a channel, the PWM convention is to
> > > describe them as devices.
> > 
> > That's all linux implementation details and you are breaking 
> > compatibility.
> 
> Normally I'd agree with you, but I happen to know that a) this IP is
> currently unused and b) up until this point (and probably beyond), ST
> always ship the DTB with the kernel, so there will be no breakage.

Heh... I've long given up on trying to make that argument go anywhere.
The general rule is that once we support a binding in a kernel release
we have to support it indefinitely. If you really want to go ahead with
this change (I don't think you should), you'd at least have to document
both properties and support st,pwm-num-chan in the driver for backwards
compatibility.

> > > The second documentation adaption entails adding support for PWM
> > > capture devices.  A new clock is required as well as an IRQ line.
> > > We're also adding a new property similar to the one described
> > > above, but for capture channels.  Typically, there will be less
> > > capture channels than PWM-out, since all channels have the latter
> > > capability, but only some have capture support.
> > 
> > Humm, sounds like all of this should be implied from compatible strings.
> 
> You mean have a bunch of of_machine_is_compatibles() scattered around?

I don't understand why you need this at all. Quite frankly I don't even
know why st,pwm-num-devs exists. I probably missed it back at the time.
Usually, like Rob suggests, this should be inferred from the compatible
string. One commonly used way to avoid scattering explicit checks for
the compatible string is to add this information to the of_device_id
table. See a bunch of existing drivers for reference.

Also, why make a separation of output vs. capture channels at this
point? Could you not simply obtain the total number of PWM channels,
preferably from SoC data associated with the compatible string, and
check at ->capture() time whether or not the particular PWM supports
this?

As-is, you imply that you have n (output) + m (capture) channels, and
that 0..n-1 are output and n..n+m-1 are capture channels. What if that
no longer holds true, but 0 and 2 are the only ones that support
capture?

If you check for this at runtime you can avoid complicated DT parsing
code, but still get the safety check which should be enough to encourage
people to use the right channels in DT.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-06-10 13:19 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08  9:21 [PATCH v3 00/20] pwm: Add support for PWM Capture Lee Jones
2016-06-08  9:21 ` [PATCH v3 01/20] ARM: dts: STi: Rename properites in line with PWM naming conventions Lee Jones
2016-06-08  9:21 ` [PATCH v3 02/20] ARM: dts: STiH407: Supply PWM Capture IRQ Lee Jones
2016-06-08  9:21 ` [PATCH v3 03/20] ARM: dts: STiH407: Declare PWM Capture data lines via Pinctrl Lee Jones
2016-06-08  9:21 ` [PATCH v3 04/20] ARM: dts: STiH416: Supply PWM Capture IRQs Lee Jones
2016-06-08  9:21 ` [PATCH v3 05/20] ARM: dts: STiH416: Declare PWM Capture data lines via Pinctrl Lee Jones
2016-06-08  9:21 ` [PATCH v3 06/20] ARM: dts: STiH416: Define PWM Capture clock Lee Jones
2016-06-08  9:21 ` [PATCH v3 07/20] ARM: dts: STiH416: Define the number of PWM Capture channels Lee Jones
2016-06-08  9:21 ` [PATCH v3 08/20] pwm: Add PWM Capture support Lee Jones
2016-06-10 13:53   ` Thierry Reding
2016-06-10 14:38     ` Lee Jones
2016-06-10 16:39       ` Thierry Reding
2016-06-20 11:14         ` Lee Jones
2016-06-08  9:21 ` [PATCH v3 09/20] pwm: sti: Rename channel => device Lee Jones
2016-06-08  9:21 ` [PATCH v3 10/20] pwm: sysfs: Add PWM Capture support Lee Jones
2016-06-10 14:04   ` Thierry Reding
2016-06-10 14:36     ` Lee Jones
2016-06-08  9:21 ` [PATCH v3 11/20] pwm: sti: Reorganise register names in preparation for new functionality Lee Jones
2016-06-08  9:21 ` [PATCH v3 12/20] pwm: sti: Only request clock rate when you need to Lee Jones
2016-06-08  9:21 ` [PATCH v3 13/20] pwm: sti: Supply PWM Capture register addresses and bit locations Lee Jones
2016-06-08  9:21 ` [PATCH v3 14/20] pwm: sti: Supply PWM Capture clock handling Lee Jones
2016-06-08  9:21 ` [PATCH v3 15/20] pwm: sti: Initialise PWM Capture device data Lee Jones
2016-06-08  9:21 ` [PATCH v3 16/20] pwm: sti: Add support for PWM Capture IRQs Lee Jones
2016-06-08  9:21 ` [PATCH v3 17/20] pwm: sti: Add PWM Capture call-back Lee Jones
2016-06-08  9:21 ` [PATCH v3 18/20] pwm: sti: It's now valid for number of PWM channels to be zero Lee Jones
2016-06-08  9:21 ` [PATCH v3 19/20] pwm: sti: Take the opportunity to conduct a little house keeping Lee Jones
2016-06-08  9:21 ` [PATCH v3 20/20] dt-bindings: pwm: sti: Update DT bindings with recent changes Lee Jones
2016-06-08 20:51   ` Rob Herring
2016-06-09 11:41     ` Lee Jones
2016-06-10 13:18       ` Thierry Reding [this message]
2016-06-10 14:06         ` Lee Jones
2016-06-10 14:53           ` Thierry Reding
2016-06-10 15:19             ` Lee Jones
2016-07-13  9:02             ` Lee Jones
2016-06-10 13:10     ` 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=20160610131855.GG27142@ulmo.ba.sec \
    --to=thierry.reding@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@stlinux.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=maxime.coquelin@st.com \
    --cc=patrice.chotard@st.com \
    --cc=robh@kernel.org \
    --subject='Re: [PATCH v3 20/20] dt-bindings: pwm: sti: Update DT bindings with recent changes' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).