On Do, 2018-12-13 at 15:38 +0300, Dan Carpenter wrote: > On Wed, Dec 12, 2018 at 03:31:13PM +0000, Christian.Gromm@microchip.c > om wrote: > > > > An additional field is added to the configuration parameter, > > which is provided by user space. > > This seemed to be less painful than adding a new sysfs > > file and make the configuration even more complicated. > I think that adding a bunch of new sysfs files *and directories* is > the > way to go actually. > > echo "mdev0:ep01:sound:most51_playback.6x16" >$(DRV_DIR)/add_link > > I've never used the most driver but my guess is that $DRV_DIR is > /sys/module/most/. In theory, you're supposed to write one word or > number to sysfs files so this is sort of a misuse of the API. > Well, you have to have a MOST or INICnet Infotainment network on your desk to use the driver. Actually, the $DRV_DIR is /sys/bus/most/drivers/most_core. And if the driver is loaded and a MOST device is attached that features two channels we get: /sys/bus/most/ ├── devices │ └── mdev0 -> ../../../devices/most_bus/mdev0 ├── drivers │ └── most_core │ ├── add_link │ ├── bind │ ├── components │ ├── links │ ├── mdev0 -> ../../../../devices/most_bus/mdev0 │ ├── remove_link │ ├── uevent │ └── unbind ├── drivers_autoprobe ├── drivers_probe └── uevent Having a new default attr under $DRV_DIR that is exclusively used for the sound module is not really nice, unless it appears only in case the sound module itself is loaded. But as I said, I'm not sure if we can establish that with the current struct core_component as it lacks the struct device. thanks, Chris _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
