> Extending the supported alarms would be fine, although I would not aggregate > them all under one sysfs file, just make a gpio#_alarm sysfs file, and make the > presence of this file conditional on the configuration of the gpio pins. > Would that work for you ? It would. I suggested combining the status into a single file because that file name is already supported. In case an extension is accptable and for further clarification I would suggest the following: device alarm | alarm file ---------------------+------------------ gpio 2 pulled low | gpio2_alarm gpio 1 pulled low | gpio1_alarm Tachometer overflow | fan1_tach_alarm Minimum output level | fan1_min_alarm Maximum output level | fan1_max_alarm All 5 sources can be enabled independently with POR 'all disabled'. The first 2 sources make only sense depending on the gpio definitions, while the other 3 would be provided just by the chip itself. After the previous discussion I would then leave the setup of the gpios and the enabling of appropriate alarm sources completely to the firmware. The driver shall discover the alarms enabled by the firmware at startup and use that information as a condition for adding the alarm files as shown above for enabled alarms. Regards, Christian
