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] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 1 Jul 2011 09:49:43 +0000 (UTC)
From:	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/3] PWM: add pwm framework support

Sascha Hauer wrote:

> On Fri, Jul 01, 2011 at 09:24:05AM +1000, Ryan Mallon wrote:
>> On 01/07/11 03:02, Sascha Hauer wrote:
>> >Bill,
>> >
>> >On Thu, Jun 30, 2011 at 11:17:54AM -0500, Bill Gatliff wrote:
>> >>Guys:
>> >>
>> >>On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann<arnd@...db.de>  wrote:
>> >>
>> >>>A lot of people want to see a framework get merged, and I think it's
>> >>>great that Sascha has volunteered to do the work to push that
>> >>>through this time, especially since you have not been able to
>> >>>finish your work.
>> >>Sascha is wasting his time by reinventing the wheel.  He's traveling
>> >>over exactly the same path I have already covered.  In fact, some of
>> >>his reviewer comments are almost word-for-word the same as those I
>> >>have received and addressed in the past.
>> >>
>> >>My patches were always kept current in this mailing list and others,
>> >>and Sascha clearly has the skills necessary to make improvements and
>> >>corrections should he have chosen to do so.
>> >I think that you made the fundamental mistake to completly ignore the
>> >existing pwm API and its users. With a competing api we are basically
>> >stuck. We can't convert the existing hardware drivers to the new API
>> >because leds-pwm.c, pwm_bl.c and others still depend on the old API and
>> >boards using it would break.
>> 
>> I don't think this is really a blocker to Bill's patches. There are
>> three (that I can see) pwm users currently:
>> drivers/video/backlight/pwm_bl.c
>> drivers/leds/leds-pwm.c
>> drivers/input/misc/pwm-beeper.c
>> 
>> All of those drivers are trivial and good easily be updated to work
>> with Bill's patches. Bill already provided a leds-pwm driver.
>
> Yes, it is easy but that's not my point. The point is that you can't
> convert the drivers without converting *all* hardware drivers in a
> *single* step. If you choose to have two competing APIs in the tree
> for one purpose you can't convert the drivers but instead you have
> to copy them, either with cp or ifdefs. I have just looked at the
> leds-pwm driver Bill provided. Applying it immediately breaks all
> users.

Just my 2c: if we were to introduce another "new" PWM API now
(no matter how good it will be) it would take quite a few years to
convert all current drivers (both following the current PWM API and not
following ones) to this new API. Consider leds API: we had led class for
several years already and only now we can foresee porting of "old" leds
users to new API. I'd definitely vote first to collect all current PWM
drivers into drivers/pwm and then step by step convert all other PWM
providers/users to it, introducing API changes as necessary, step by
step.

-- 
With best wishes
Dmitry



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ