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: <AANLkTik7VgWW8r-fU5FuekxJGH-n6NxUdGJtfB-OXv6B@mail.gmail.com>
Date:	Thu, 10 Mar 2011 15:34:42 -0600
From:	Bill Gatliff <bgat@...lgatliff.com>
To:	Alexander Stein <alexander.stein@...tec-electronic.com>
Cc:	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org
Subject: Re: [PWM v7 3/3] PWM: Atmel PWMC driver

Alexander:

On Thu, Mar 10, 2011 at 1:36 AM, Alexander Stein
<alexander.stein@...tec-electronic.com> wrote:
> As far as I can see, the previosly support for pwm_channel_handler has been
> dropped. The new API doesn't support such things.
> What do you think about adding this? It might be important to change the PWM
> setup after a specific amount of time.

Reviewers of the implementation noted some race conditions, and had
additional objections to the implementation.  They suggested that I
reimplement channel handlers using genirq.

Since the pwm_channel_handler implementation was broken, I removed it
from the implementation.  I haven't yet started on the genirq-based
approach, for two reasons: I'm trying to get everything else into
mainline; and, I'm not quite sure yet how to stitch genirq together
with "genpwm".

There is a larger question, however, that I would like to hear your
answer on since you seem interested in the subject: are end-of-period
callbacks really necessary?  If you are trying to "ramp" a PWM signal
from a low duty cycle to a high one, would an hrtimer suffice?
Assuming that a PWM device driver can implement duty cycle and/or
period changes without glitches, is it really necessary to stay so
tightly synchronized to the PWM signal the way that an end-of-period
callback would allow?

In my work, I haven't encountered a need for end-of-period callbacks
when doing mere PWM signal generation (though the topic is very
important when counting pulses, which I'm considering a different
implementation/API for).  I don't know if my experience is
comprehensive, however.  Would love to hear your opinion.


b.g.
-- 
Bill Gatliff
bgat@...lgatliff.com
--
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