linux-kernel - Re: [PATCH v3 20/20] dt-bindings: pwm: sti: Update DT bindings with recent changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160713090246.GA11154@dell>
Date:	Wed, 13 Jul 2016 10:02:46 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	Rob Herring <robh@...nel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	kernel@...inux.com, maxime.coquelin@...com, patrice.chotard@...com,
	linux-pwm@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 20/20] dt-bindings: pwm: sti: Update DT bindings with
 recent changes

On Fri, 10 Jun 2016, Thierry Reding wrote:
> On Fri, Jun 10, 2016 at 03:06:35PM +0100, Lee Jones wrote:
> > On Fri, 10 Jun 2016, Thierry Reding wrote:
> > 
> > > > > > 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.
> > 
> > Yes, I am aware of the strategy, and happy to oblige if this is your
> > suggestion.  I'll move all platform data into the driver and eradicate
> > the DT properties.
> 
> Great!

Sorry it's taken so long to get back around to this.

So I just had a crack at implementing this solution and ran into
issues.  Unfortunately, the configuration isn't easy to describe using
compatible strings.

Unless we are prepared to have strings like:

  st,sti-pwm-stih407-pwm0
  st,sti-pwm-stih407-pwm1
  st,sti-pwm-stih416-pwm0
  st,sti-pwm-stih416-pwm1

Or perhaps:

  st,sti-pwm-4out-2cpt
  st,sti-pwm-1out-1cpt

... since some of the PWMs have an odd number of OUT and CPT
channels/devices.  In my opinion however, this is ugly.  I don't think
we do this for any other type of channel/device/port etc, do we?

Personally I think there isn't anything wrong with having DT
properties describing how many channels/devices there are, but I'm
okay with whatever you both decide.  No skin of my nose really. :)

What say you?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog