From: "Nuno Sá" <noname.nuno@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
linux-pwm@vger.kernel.org
Subject: Re: [PATCH 3/6] pwm: Add support for pwmchip devices for faster and easier userspace access
Date: Tue, 09 Jul 2024 11:37:13 +0200 [thread overview]
Message-ID: <86fdb6409c8f439bf75d2ed31d1031fb910aa435.camel@gmail.com> (raw)
In-Reply-To: <7490e64bbe12e2046d92716dadef7070881592e6.1720435656.git.u.kleine-koenig@baylibre.com>
On Mon, 2024-07-08 at 12:52 +0200, Uwe Kleine-König wrote:
> With this change each pwmchip can be accessed from userspace via a
> character device. Compared to the sysfs-API this is faster (on a
> stm32mp157 applying a new configuration takes approx 25% only) and
> allows to pass the whole configuration in a single ioctl allowing atomic
> application.
>
> Thanks to Randy Dunlap for pointing out a missing kernel-doc
> description.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
I didn't looked very carefully at the patch but one thing did caught my
attention
...
> +
> +struct pwmchip_waveform {
> + unsigned int hwpwm;
> + __u64 period_length;
> + __u64 duty_length;
> + __u64 duty_offset;
> +};
> +
I do not think we should have holes in the struct given this is an userspace
interface.
One other thing is how likely is this struct to grow? If that is expected we
should probably think in adding some __reserved__ parameters or maybe to modify
the interface so we could make use of:
https://elixir.bootlin.com/linux/latest/source/include/linux/uaccess.h#L348
Like wrapping struct pwmchip_waveform in another struct with an extra member
forcing userspace to specify pwmchip_waveform size. But I agree it's a bit
awkward and ugly (but it could be hidden in libpwm).
Anyways, if this is not likely to change disregard all the compatibility
thingy...
- Nuno Sá
next prev parent reply other threads:[~2024-07-09 9:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 10:52 [PATCH 0/6] pwm: New abstraction and userspace API Uwe Kleine-König
2024-07-08 10:52 ` [PATCH 1/6] pwm: Add more locking Uwe Kleine-König
2024-07-08 10:52 ` [PATCH 2/6] pwm: New abstraction for PWM waveforms Uwe Kleine-König
2024-07-08 18:12 ` Trevor Gamblin
2024-07-08 10:52 ` [PATCH 3/6] pwm: Add support for pwmchip devices for faster and easier userspace access Uwe Kleine-König
2024-07-08 18:13 ` Trevor Gamblin
2024-07-09 9:37 ` Nuno Sá [this message]
2024-07-12 9:48 ` Uwe Kleine-König
2024-07-12 11:01 ` Nuno Sá
2024-07-12 16:28 ` Uwe Kleine-König
2024-07-12 17:20 ` Nuno Sá
2024-07-08 10:52 ` [PATCH 4/6] pwm: Add tracing for waveform callbacks Uwe Kleine-König
2024-07-08 18:14 ` Trevor Gamblin
2024-07-09 6:54 ` Uwe Kleine-König
2024-07-08 10:52 ` [PATCH 5/6] pwm: axi-pwmgen: Implementation of the " Uwe Kleine-König
2024-07-08 18:08 ` Trevor Gamblin
2024-07-08 10:52 ` [PATCH 6/6] pwm: stm32: " Uwe Kleine-König
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=86fdb6409c8f439bf75d2ed31d1031fb910aa435.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=linux-pwm@vger.kernel.org \
--cc=u.kleine-koenig@baylibre.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox