So just fall back to "gpio" if there is no label? The only character that's
not valid in a pathname is '/', so that's trivial to check for.
const char *label = chip->label && !strchr(chip->label, '/') ?
chip->label : "gpio"; /* or "generic" or "unknown", or ...*/
This means you don't need a file with number to device assignents. It makes
shell scripting a lot easier too. Say I want the first gpio on a pca9557 gpio
expander? It's will be something like: /sys/class/gpio/pca9557-0:0
You don't have to worry about dynamic assigments. You don't have to resort to
convoluted shell script code to extract the proper range from a mapping file
and then construct the name.
It's nice to be able to see what a driver is using a gpio for. You could also
assign labels from userspace this way.
So make them appear when something in the kernel requests them, explictly
exports them to user-space, or they are requested from user space. The last
two can offer write access, the first only read. I don't see why the explicit
request is necessary for something to show up in sysfs. Nothing else in sysfs
seems to work this way. At least, I see plenty of files in there that I
didn't have to manually make appear.
$ ls /sys/class/tty/ | wc
579 579 4042
What's a few hundred more?
I didn't mean for gpiolib to create that device, that's obviously wrong. What
I meant was the platform code, e.g. the code the calls gpiochip_add(), could
just call that one function and then it would have a device for the gpios to
appear under in sysfs. You said that many systems "can't" have a device for
the gpios and I don't see how this is so. Could you give me an example of
something that calls gpiochip_add() and can't provide a dev field in the
gpio_chip struct?
If memory allocations don't work, then gpiochip_add() can't possibly do
anything with sysfs, so having a device to parent the sysfs files from is a
moot point.
It's one line of code.
I thought you meant comments to my patch.
--
