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:	Mon, 07 Mar 2011 20:26:55 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Bill Gatliff <bgat@...lgatliff.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PWM v6 1/3] PWM: Implement a generic PWM framework

On 03/07/2011 05:28 PM, Bill Gatliff wrote:
> Lars:
> 
> On Sun, Mar 6, 2011 at 12:35 AM, Lars-Peter Clausen <lars@...afoo.de> wrote:
>> On 03/06/2011 07:16 AM, Lars-Peter Clausen wrote:
>>> On 03/06/2011 05:17 AM, Bill Gatliff wrote:
>>>> +
>>>> +
>>>> +pwm_set_handler() -- Defines an end-of-period callback.  The indicated
>>>> +function will be invoked in a worker thread at the end of each PWM
>>>> +period, and can subsequently invoke pwm_config(), etc.  Must be used
>>>> +with extreme care for high-speed PWM outputs.  Set the handler
>>>> +function to NULL to un-set the handler.
>>>> +
>>
>> This looks like a poor man's IRQ handler implementation. In my opinion something
>> like pwm_to_irq would be better suited interface.
> 
> Not sure what you mean here.  Can you elaborate?
> 
> 
> b.g.

I was thinking about an interface similar to gpio_to_irq. So you could map a
PWM device to a IRQ number and use the existing the existing genirq framework
to manage the callback handler.

The hardware will quite likely inform the software about when the period has
ended through an interrupt.
So what you basically will end up doing in almost every PWM device driver
implementation is to call pwm_handler() from its interrupt handler.

I for example have a SoC with an PWM unit where at least for some channels an
IRQ number from the main interrupt controller is directly mapped to PWM
channel. In such an case I could simply return the IRQ number directly instead
of implementing a IRQ handler which does nothing but calls pwm_handler().
For other case where the IRQ is muxed onto multiple PWM device you can use an
irq_chip.

I think there are still some problems with your current callback handler
implementation that could prove to be racy. Also each driver has to keep track
whether the handler should be invoked or not.
All these problems should go away with a genirq based implementation.

Maybe I'm on the wrong track here though. Could you explain what your expected
use case is for this part of the API? For example what would a driver using a
PWM device normally be doing in the handler it passed to the PWM device?

Oh and another thing, will it be mandatory for a PWM driver to provide callback
functionality and what if the underlying hardware does not support it?

- Lars
--
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