On 20 June 2013 03:55, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Wednesday, June 19, 2013 10:31:02 PM Lukasz Majewski wrote: >> On Wed, 19 Jun 2013 10:48:53 -0700 >> Dirk Brandewie <dirk.brandewie@xxxxxxxxx> wrote: >> >> > On 06/19/2013 10:12 AM, Lukasz Majewski wrote: >> > > @@ -1936,6 +2019,16 @@ int cpufreq_register_driver(struct >> > > + if (!cpufreq_driver->boost_supported) >> > > + boost.attr.mode = 0444; >> > > + >> > > + ret = cpufreq_sysfs_create_file(&(boost.attr)); >> > > + if (ret) { >> > > + pr_err("%s: cannot register global boost sysfs >> > > file\n", >> > > + __func__); >> > > + goto err_null_driver; >> > > + } >> > > + >> > >> > I do not think the boost sysfs should be created at all if boost is >> > not supported. >> >> This was my first thought. But unfortunately this "boost" attribute is >> always exported at acpi-cpufreq.c and in my opinion is part of a >> legacy API. >> >> I totally agree with the idea of exporting boost only when supported, >> but I would like to know the community opinion about this (especially >> Viresh and Rafael shall speak up). > > Simple: Export it only when supported. Guys, I got confused here. We originally decided to keep this feature as is for acpi-cpufreq. So, For acpi-cpufreq: - when boost isn't supported: create sysfs boost with ro permissions - when boost is supported: create sysfs boost with rw permissions So, For others: - create sysfs boost with rw permissions only when boost is supported . Do you want something else? or do you want to change behavior of acpi-cpufreq driver? I don't why it was designed this way and what applications use it. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html