David Lechner wrote on Fri, Mar 15, 2024 at 10:53:36AM -0500: > How about using udev rules to create symlinks for each device based on > the label attribute? No changes to the kernel are needed. Right, it's definitely possible to make symlinks for each "device" -- my patch comment links to such an udev script "solution": https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-core/udev/files/verdin-imx8mm/toradex-adc.sh?h=kirkstone-6.x.y (the script is launched by udev here: https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-core/udev/files/verdin-imx8mm/99-toradex.rules ) My conceptual problem with this is that this makes symlinks in /dev to files in /sys and it feels like we're crossing boundaries. As far as I can tell there is no way for userspace to create arbitrary symlinks in /sys, so I think we could have an interface more user-friendly by allowing paths to be static for users with multiple devices. (I guess that's a weak argument given e.g. disks etc will also have an unreliable name in /sys in the general case, but simple programs don't interact with them in /sys and can use stable links in /dev so my expectations here aren't quite the same) Ultimately, the problem might run deeper in that we're having userspace interact with the device through /sys and not the /dev char dev... As far as I could see /dev/iio:deviceX only allows reading buffered values and doesn't have any ioctl or other way of reading immediate values as is possible in /sys though, so that'd require quite a bit of work to duplicate the interface there... Perhaps I'm just thinking too much and symlinks from /dev to /sys are a thing in the IIO world? I've not seen it done anywhere except in that toradex tree when I was looking earlier. Andy Shevchenko wrote on Sat, Mar 16, 2024 at 10:14:35PM +0200: > [...] Thank you for the review! >> +#include <linux/of.h> > > What about ACPI? > Please try avoid hard to use OF-specific code for the new features. Given my suggestion here relied on users giving manual hints in the DTB I'm not sure how that could be interfaced with ACPI, but if you have a suggestion to make paths static that'd work with either interfaces I'd be more than happy to give it a try. I'd also like to add that in my particular case it's a problem created by the OF interface in the first place: devices are currently created in the order they're parsed from OF, and it just so happens that this order doesn't work well for us; I'm not aware of how IIO interacts with ACPI but perhaps the way the list of devices processed from ACPI is "stable enough" in practice? Thank you, -- Dominique
