> > After giving it some thought, I agree with you and Hridesh. Kernel > should not limit profile choices if they *are* selectable. > > If a "proof of concept" patch is still interesting I'll be glad to send > it, otherwise I think my original idea has too many problems. User-space > should be able to handle these special cases. > > I think an attribute allowing/disallowing power sensitive values is > interesting. Maybe allow users too attach/detach individual profiles > from being selected/cycled? On that note, it would also be interesting to > be able to detach invidivual "profile handlers" from the legacy > `acpi_kobj`. But I'm not sure if this added complexity would be worth it. > > Anyway.. Mario, do you think hiding platform_profile_handler from > drivers is something worth pursuing? Similar to what the hwmon class > does. I feel having some struct members like `minor` and `choices` > exposed, or having the profile_get/profile_set callbacks not being > const, while it's not the end of the world, could be problematic. Yeah, I think this is still an interesting idea that's still worth pursuing. Making the API simpler for drivers is a net benefit and reduction in tech debt.
