-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make pwm sysfs work for non-root users #1983
Comments
I would expect your patch to be quickly accepted - let us know when it is and we will back-port it to the current rpi- |
@gohai Do you know if this was accepted? If so we can cherry pick it's commit. |
I think they're quite busy with the 4.12 release candidates - I also have patches waiting for review. |
@pelwell Thanks for the heads-up. I'll keep an eye on the mailing list and will report here once it is in some tree... |
@gohai I think your upstream patch got lost. I suggest to resend the patch and also add linux-arm-kernel (moderated list) to CC in order to increase the chance of an reviewer. Another approach is to ask about this topic on kernelnewbies mailing list or IRC, where you get a much fast reply. |
@lategoodbye Just re-sent it, with CC to linux-arm-kernel and linux-rpi-kernel for what it's worth. I dropped by on kernelnewbies IRC, there the suggestion was to just be more insistent (I was told the submission looks fine). |
I've seen Thierry on the mailing list, so maybe you should send a gentle ping. Otherwise the merge window is still open. |
@lategoodbye I've sent it three times already - anyone, feel free to pick this up yourself, but I am wholeheartedly discouraged from further attempting to make a contribution at this point... |
I can see that the patch got no response upstream, which is very disappointing. @gohai - give it one more try, wait a week, and if you get no response I'll apply it downstream and maintain it myself. |
As long as the merge window is open, any attempt would be pointless. We must wait until 4.14rc-1 is released. |
Why pointless? Do all reviewers become mute during the merge window? An indication of whether the submitter is on the right lines or doomed to failure isn't a lot to ask for. |
I think there was enough time to review, so it's all about merging. Some maintainers ignore patches within the merge window. |
It is unreasonable to expect submitters to know about merge windows. Since the original submission, 4.13 gone mainstream and now we are waiting for 4.14 rc1. @thierryreding Should @gohai resubmit his patch or is it already in the pipeline somewhere? |
For folks who find themselves here via google, note that the udev rules suggested in this issue only solve half the problem: while they will result in correct ownership and permissions on |
@larsks The necessary kernel patch is linked in the first sentence of the initial message in this issue. |
@gohai best to resubmit this patch. I don't remember seeing it before and I can't find anything that looks related in my inbox. Maybe it was lost along the way? Sorry. |
@thierryreding I just sent it again, subject should be Might have not made it onto the mailing lists this time, because after 45 minutes I still couldn't get |
I just received it. |
@thierryreding Have you received my patch? The resend made it to linux-pwm... |
Pinging @thierryreding |
Would be good to get some sort of closure on this one.... @thierryreding @gohai @pelwell |
There's shortage of time, and then there's obstruction. @gohai If you submit a PR against 4.9 (and 4.14 if it takes more than a simple cherry-pick) I'll apply it downstream. |
Response on the mailing list that it has been applied to for-next - http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-December/007193.html |
I've cherry-picked - just compile-testing now. |
@6by9 @pelwell @lategoodbye Fantastic. Thanks everyone for your support! |
All merged now - thanks everyone. |
@pelwell The patch seems to cause some issues and was marked to be reverted |
👍 |
This file was suggested here and a corresponding linux kernel patch was implemented to make it work: raspberrypi/linux#1983 Copy this file to /etc/udev/rules.d and reboot.
This file was suggested here and a corresponding linux kernel patch was implemented to make it work: raspberrypi/linux#1983 Copy this file to /etc/udev/rules.d and reboot.
@gohai @pelwell I've tested this and it works, but do you know why the proposed rule change is not part of the default Raspbian installation? The gpio pins can meanwhile be accessed without root rights, so PWM usage should be possible as well, or is there any additional security risk involved in doing so? |
Probably because nobody explicitly asked for it in the right place - try submitting a Pull Request to the raspberrypi-sys-mods repo. |
Request noted and I've put it on my todo list. |
Cool. |
That's down to the asynchronous nature of sysfs, and is essentially unavoidable. The problem was solved for GPIOs by deprecating the sysfs interfacing and providing a much better ioctl-based interface (gpiolib) instead. |
:( I had expected something like that. If this is a known issue then, the workaround will hopefully be acceptable on the client side. |
I sent a one-liner patch to the linux-pwm mailing list, which makes exporting a channel (with
echo 0 > /sys/class/pwm/pwmchip0/export
) send a udev event.With this patch, and the following addition to
/etc/udev/rules.d/99-com.rules
, it is finally possible to use the pwm functionality with the defaultpi
user, instead of having to usesudo
(which is not an option for Processing e.g.):Would you mind giving these changes a try, and consider them for inclusion with Raspbian? I am the author of Processing's Hardware I/O library - this would enable users to use hardware PWM from within Processing on their Raspberry Pi computers.
Let me know if I should send a PR for the kernel part of this - I'll of course also be eying any discussion that happens upstream regarding my patch submission.
The text was updated successfully, but these errors were encountered: