On Mon, Oct 6, 2014 at 11:55 AM, Thomas Petazzoni <[email protected]> wrote: > Dear Mike Turquette, > > On Mon, 06 Oct 2014 11:36:24 -0700, Mike Turquette wrote: > >> Thomas, >> >> Does such a solution solve your problem? Do you still need to create a >> platform_device if you can easily get at the driver flags with this >> function? > > Hum, I'm not sure to get the question: of course to instantiate cpufreq > I need to create a platform_device. The only difference between my v1 > and v2 is that in v1 I was using those driver flags to pass from the > cpufreq ->probe() function to the cpufreq ->init() function that we > have independent clocks, while in v2, I'm using a new void *driver_data > field. Really, it doesn't change anything and is purely a matter of > taste.
Poorly worded question. I was asking if the above patch would work for you and it seems the answer is yes. The reason I care is that I am working on a governor that needs to know a driver flag. It would be painful for the machine-independent governor to understand a machine-specific private data structure from the driver. The flags are listed in cpufreq.h so it makes life easy. Regards, Mike > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
