Hi Henrique, > > > I don't think we should expect userspace to know whether or not a device > > > has a persistent state. Yes, it _could_ maintain whitelists, but why > > > should it have to if the driver already knows? > > > > If you want that, then the best approach seems an extra sysfs attribute > > for this. It is not intrusive on the event API and lets udev etc. have > > these information, too. > > I have no problems with either approach. As long as the information of > which devices have restored their initial state from NVS is available to > userspace, it is enough. just to get the semantic right here. We are not telling userspace if a state has been restored or not. We are telling userspace that this specific RFKILL switch is capable of storing something in a persistent state over boot. There is a difference here. If a RFKILL driver claims it is capable of persistent storage then it better work or it should not claims it. Either it does it all the time or doesn't do it at all. Otherwise we end up in policy again and that is not the job of the kernel. > Do note that this information also needs to be available for resume (state > should be checkpointed to NVS on sleep, and restored from NVS on resume. I > believe tpacpi does this, but if it doesn't, I will fix it eventually). Correct. That is the job of the driver. If it is broken, that needs fixing. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
