No udev events when exporting / unexporting pwm devices on BeagleBone Blue

[HappyFox]

On kernel 4.4.49-ti-r89 of the default beaglebone blue image, when exporting and un-exporting there is no udev event fired.

root@beaglebone:/sys/devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2# echo 0 > unexport
root@beaglebone:/sys/devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2# echo 0 > export

No udev events from udevadm monitor

With the gpio lines you get a udev event for export/uneport:

root@beaglebone:/sys/class/gpio# echo 10 > unexport
root@beaglebone:/sys/class/gpio# echo 10 > export  

generates:

debian@beaglebone:~$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[449.118706] remove   /devices/platform/ocp/44e07000.gpio/gpio/gpio10 (gpio)
UDEV  [449.193955] remove   /devices/platform/ocp/44e07000.gpio/gpio/gpio10 (gpio)
KERNEL[454.849166] add      /devices/platform/ocp/44e07000.gpio/gpio/gpio10 (gpio)
UDEV  [456.275388] add      /devices/platform/ocp/44e07000.gpio/gpio/gpio10 (gpio)

With no udev rules to firing it makes it impossible to have a rule to set the permissions. This is compounded by the having to unexport the export one channel to set the frequency of the pwm chip.

[RobertCNelson]

@HappyFox we have a patch in development:

https://github.com/RobertCNelson/linux-dev/blob/master/patches/drivers/pwm/0001-pwm-Create-device-class-for-pwm-channels.patch

However it's going to change a few things under /sys/class/pwm, which require fixes to bonscript/adafruit_bbio/etc @jadonk @pdp7 are helping so when i do back port taht to v4.4.x-ti userspace will be ready..

Regards,

[HappyFox]

Excellent, if I build following https://github.com/RobertCNelson/linux-dev will that include that patch by default ?

Also do you want me to close this issue, or leave it up in case anyone is searching for this issue.

Thanks!

[troywweber7]

When is that patch going to come out?

[RobertCNelson]

@HappyFox yes..

[RobertCNelson]

@troywweber7, as soon as bonescript and the adafruit-beaglebone-io-python library are patched..

[pdp7]

@HappyFox Is this still an open issue?

@jadonk @RobertCNelson are we going to continue carrying the naming patch? it doesn't look like it landed in mainline as far as I can tell

[RobertCNelson]

@pdp7 that is correct.

[rubberduck203]

The naming patch seriously burnt me today. It breaks api compatibility with the mainline kernel. So far as I can tell, the udev issue has been fixed in a different way upstream.

torvalds/linux@552c02e#diff-9a7f97bd71e4a800329b87fd81fd7666

[RobertCNelson]

thanks @rubberduck203 i'll take a look at it later to see if they actually fixed the issue.. tagged in the release tracker..

[rubberduck203]

Thanks for looking @RobertCNelson

[RobertCNelson]

@rubberduck203 ps, we do have a newer udev rule, to "help" the situation too.. (this was after our pwm patch hack..)

/dev/pwm/*

This helps before and after the patch:

https://github.com/beagleboard/customizations/blob/master/etc/udev/rules.d/81-pwm-noroot.rules

mostly to help keep a static name for a specific pwm between different kernel's..

Regards,

[rubberduck203]

I should clarify my problem, which should probably be it’s own issue. The patch that was referenced earlier changes the naming of the channel files from pwmN to pwm-chip:N.

0e09cd3#diff-9a7f97bd71e4a800329b87fd81fd7666

This breaks any library that assumes the pwmN naming based on the mainline documentation. This means I have to somehow detect that my code is running on this kernel and change how the file path is built or expose it as a configuration option if I want to write code that runs on many different SBCs.

mostly to help keep a static name for a specific pwm between different kernel's

It’s great that there’s a udev rule to help address this, but that still leaves me rewriting libraries that already exist because it’s still not at the documented path.

I don’t mean to sound ungrateful. I appreciate all the work that goes into a project like this. I just spent a solid afternoon figuring out why I couldn’t get a widely used library to work, so my frustration may be leaking into my speech. It’s not directed at you, I promise. I appreciate you retesting mainline to see if your original problem has been addressed.

[pdp7]

@rubberduck203 thank you for pointing out torvalds/linux@552c02e

That does look like that solves the problem that David Hsu's patch was trying to solve.

I'll try this out as am already running mainline 5.7-rc4 on a BeagleBone Black (built using @RobertCNelson's omap2plus-mainline-linux)

[pdp7]

root@beaglebone:/sys/class/pwm# uname -a
Linux beaglebone 5.7.0-rc4-omap2plus-r0 #3 SMP Thu May 21 21:57:33 CEST 2020 armv7l GNU/Linux
root@beaglebone:/sys/class/pwm# ls -la pwmchip?/pwm?/duty_cycle
-rw-rw-r-- 1 root gpio 4096 Nov 3 2016 pwmchip0/pwm0/duty_cycle
-rw-rw-r-- 1 root gpio 4096 Nov 3 2016 pwmchip0/pwm1/duty_cycle
-rw-rw-r-- 1 root gpio 4096 Nov 3 2016 pwmchip2/pwm0/duty_cycle
-rw-rw-r-- 1 root gpio 4096 Nov 3 2016 pwmchip2/pwm1/duty_cycle

[pdp7]

@RobertCNelson I think this will be solved in the next release, right?