On Fri, Jun 27, 2014 at 10:23 PM, Olof Johansson <olof@xxxxxxxxx> wrote: > On Fri, Jun 27, 2014 at 9:32 AM, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: >> Felipe, >> >> On Fri, Jun 27, 2014 at 8:59 AM, Felipe Balbi <balbi@xxxxxx> wrote: >>>> I'll admit to not having been involved with the previous discussions, >>>> but this seems strange to me. Are we throwing in the towel and >>>> deciding that it's too hard to get the Kconfigs right and that we'll >>>> just rely on individual users to figure out the right answer for >>>> themselves? >>> >>> no. select prevents a driver from be built as a dynamically linked >>> module and distro-kernels might want to enable everything as modules. >> >> Ah, that's what the problem was! I wasn't aware of this issue with >> SELECT. Sorry for the noob-ness. > > Select is also fragile, for example if a main subsystem isn't enabled, > the specific option will still be enabled (or there'll be a > warning/error about it). Overall it tends to cause headaches so many > maintainers are starting to push back against it. > >> Really we want the PHY to be "=y" if the USB driver is "=y" or "=m" if >> the USB driver is "=m", I think. You could argue that one might want >> to build the main USB driver into the kernel but have the phy drivers >> as modules, so you could possibly also try to support that... >> >> If there's not a good way to specify that, I guess we'll just have to >> use "default" and rely on the user not to purposely choose the wrong >> thing. Like the following (untested): >> >> config PHY_SAMSUNG_USB2 >> depends on USB_OHCI_EXYNOS || USB_EHCI_EXYNOS >> default y if ARCH_EXYNOS=y && (USB_OHCI_EXYNOS=y || USB_EHCI_EXYNOS=y) >> default m if ARCH_EXYNOS=m && (USB_OHCI_EXYNOS=m || USB_EHCI_EXYNOS=m) >> ... >> >> I see some syntax like that elsewhere in Kconfig so I assume it's reasonable... > > I think you can take out the test for ARCH_EXYNOS here (first of all, > it can never be modular). > > I'm not sure it makes sense to work so hard to set the default right > either, as long as the dependencies are correct. I.e. it'll still mess > up randconfig if the combination doesn't build, and distros can still > downgrade to 'm' if they want to. That'll just leave: > > config PHY_SAMSUNG_USB2 > tristate "foo" > depends on USB_OHCI_EXYNOS || USB_EHCI_EXYNOS > default y (no need to add an if since it's taken care of by the depends) > >> With the above the user could purposely enable the OHCI or EHCI driver >> and disable the PHY driver which is not really sensible. ...but it >> wouldn't cause a compile failure or crash--USB just won't work. > > Just make the sub-drivers silent options with defaults. I.e: > > config PHY_EXYNOS5250_USB2 > bool SOC_EXYNOS5250 > depends on PHY_SAMSUNG_USB2 > > and so on. Note that it doesn't actually scale to make it depend on a > specific SoC though, so it should probably just be cut down the line > of EXYNOS4/5 and err on the side of including a bit too much code > instead. Yes, that seems the right thing to do. However, for now I will retain the SoC based structure. Considering the fragility involved in using 'select', I will re-do this by playing around with the default option. Thanks everyone for your inputs. -- Regards, Sachin. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |