On Tue, May 28, 2013 at 09:13:15PM -0500, H Hartley Sweeten wrote: > > But let's take a step back, what are you trying to do by creating a new > > sysfs directory? You should never create a subdir in the device tree in > > sysfs, that is not a 'struct device'. That is because udev / userspace > > will not see the directory, so any attribute under it will not be > > accessable by the tools that users use to access them. > > I'm cleaning up the ep93xx pwm driver for conversion to the PWM > framework. My use of that driver requires user space control so I'm > trying to add a sysfs interface to the PWM framework as suggested > by Thierry Reding. Lars Poeschel did some initial work on this: > > [0]: http://marc.info/?l=linux-kernel&m=136499756101273&w=2 > > Unfortunately he will not be able to do any further work for a couple > months. > > Lars initially followed the sysfs implementation in gpiolib which looks > like this: > > /sys/class/pwm > /export ... asks the kernel to export a PWM to userspace > /unexport ... returns a PWM to the kernel > /pwmN ... for each exported PWM #N > /duty_ns ... r/w, duty cycle in ns > /period_ns ... r/w, PWM period in ns > /polarity ... r/w, normal(0) or inverse(1) polarity > /run ... r/w, start(1) and stop(0) the PWM > /pwmchipN ... for each pwmchip; #N is its first PWM > /base ... (r/o), same as N > /npwm ... (r/o), number of PWM > > Thierry Reding did a pretty thorough review and said he would > rather have the exported PWMs appear under the associated > pwmchip. The PWM subsystem was designed to do per-chip > indexing and the global namespace was introduced only for > backwards compatibility. The goal is to remove the global > namespace. > > It appears Thierry wants the sysfs hierarchy to look like this: > > /sys/class/pwm > /pwmchipN ... for each pwmchip; #N is its first PWM > /npwm ... (r/o), number of PWM > /export ... asks the kernel to export a PWM to userspace > /unexport ... returns a PWM to the kernel > /pwmN ... for each exported PWM #N (of this pwmchip) > /duty_ns ... r/w, duty cycle in ns > /period_ns ... r/w, PWM period in ns > /polarity ... r/w, normal(0) or inverse(1) polarity > /enable ... r/w, start(1) and stop(0) the PWM > > The pwmN subdirectory and the attributes under it are the ones > I'm trying to add. I've been searching the kernel source trying to > find something similar but the only this I have found is the > kobject_create_and_add() stuff. > > Do you have any other suggestions? Yes, use 'struct attribute_group', and set the .name field to pwmN, with the .attrs pointing to the duty_ns, period_ns, and the rest of the files you want to have under that group. No need to use kobjects at all here. Hm, that should be documented somewhere as it comes up about once a year or so, just like the .is_visable callback logic in that same structure... Note, you need to be creating all of these groups _before_ you announce to userspace that your device (pwmchipN) is registered with the system, otherwise you will race with userspace and tools will get confused. So you will have to be careful and do a two-step initialization of the device with the driver core. Look at how the USB core does this if you are curious as to how it is done. Hope this helps, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
