Hi,
On Tuesday 14 April 2015 06:57 PM, Greg Kroah-Hartman wrote:
On Tue, Apr 14, 2015 at 03:17:30PM +0200, Arnd Bergmann wrote:
On Tuesday 14 April 2015 14:37:37 Greg Kroah-Hartman wrote:
On Tue, Apr 14, 2015 at 01:33:08PM +0200, Arnd Bergmann wrote:
This is true, but all other drivers do the same for GENERIC_PHY at the
moment. If this one gets changed, we should probably apply the same
solution to all current users and fix them consistently.
We can do one of these two:
a) make sure that the framework has 'static inline' stubs that let you
build all drivers using it when the framework itself is disabled.
Yes, please do that.
b) change the drivers using it to 'depends on', and make GENERIC_PHY
itself a hidden option without a Kconfig prompt.
Then how could GENERIC_PHY ever get set?
Right now, every driver that provides a phy uses 'select GENERIC_PHY',
and they would have to keep doing that. This is not unlike what we
do for other silent symbols like MFD_CORE, REGMAP_I2C, or PINCTRL,
and it's not as problematic as 'select' on a user-visible option,
or (worst) mixing 'select' and 'depends on'.
Ok, that would make more sense, but it would be good for the PHY
maintainer to agree to it as well :)
looking at [1], we should use select only for non-visible symbols and for
symbols with no dependencies. As such GENERIC_PHY is not dependent on other
symbols but for now it is "visible".
phy-core has all the stubs already implemented in include/linux/phy/phy.h. So
removing select GENERIC_PHY shouldn't be a problem. But then it might break a
few platforms where GENERIC_PHY is indirectly enabled by selecting the config
of the driver (using default defconfigs in arch/arm/configs).
The simplest thing would be to make GENERIC_PHY an invisible option?
[1] ->
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/kconfig-language.txt#n111
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
