On Wed, Jan 08, 2014 at 01:11:22AM +0100, Rafael J. Wysocki wrote: > Well, I personally think that this code should go into arch/x86/ as library code > needed to access IOSF Sideband on some platforms. I don't disagree. However for the record this is not the first time it has been discussed and I already moved it from arch/x86 to platform on the suggestion of several maintainers. I will keep the interface generic except that it has to be stated that it will only support those platforms that can enumerate this device using PCI. Plus I learned there are others who plan to patch when it gets accepted to support other platforms using different methods of enumeration/communication. I would thik this probably cements its placement in arch/x86. > I probably would make modules > depending on it select it, so for example if the RAPL driver is going to be > built, your driver should be build either and rather unconditionally in that > case. > Wouldn't such a dependency be handled by the RAPL driver et al. How can I force modules to build this driver? Reverse dependency? Also the biggest consumer of the driver doesn't have code upstream yet. > So the rule should be "if something *may* need it, build it" in my opinion. You suggest that even though non-IOSF systems don't need this driver to enable RAPL, it should build anyway since it's a dependency for systems that do have IOSF? Even if this is what you suggest I'd prefer the owner of the driver that has the dependency be the one to patch this driver to make in build in that case. I do not know all who would use it. Dave Box -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
