| Message ID | 1386601737-8735-5-git-send-email-heikki.krogerus@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote: > Provide a complete association for the phy and it's user > (musb) with the new phy_lookup_table. > > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- > arch/arm/mach-omap2/twl-common.c | 15 ++++++--------- > 1 file changed, 6 insertions(+), 9 deletions(-) > > diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c > index b0d54da..972430b 100644 > --- a/arch/arm/mach-omap2/twl-common.c > +++ b/arch/arm/mach-omap2/twl-common.c > @@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void) > } > > #if defined(CONFIG_ARCH_OMAP3) > -struct phy_consumer consumers[] = { > - PHY_CONSUMER("musb-hdrc.0", "usb"), > -}; > - > -struct phy_init_data init_data = { > - .consumers = consumers, > - .num_consumers = ARRAY_SIZE(consumers), > +static struct phy_lookup_table twl4030_usb_lookup = { > + .dev_id = "musb-hdrc.0", > + .table = PHY_LOOKUP("phy-twl4030_usb.0", NULL), > }; had a similar approach during the initial version of phy framework [1] (see phy_bind) but changed it later [2] . Here you should know the device names of two devices and even if one of them started using DEVID_AUTO, it'll start breaking. Such an approach needs to reviewed carefully. [1] -> https://lkml.org/lkml/2013/4/3/258 [2] -> http://www.spinics.net/lists/linux-usb/msg85299.html (removed phy_bind) Cheers Kishon > > static struct twl4030_usb_data omap3_usb_pdata = { > .usb_mode = T2_USB_MODE_ULPI, > - .init_data = &init_data, > }; > > static int omap3_batt_table[] = { > @@ -225,8 +220,10 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data, > } > > /* Common platform data configurations */ > - if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb) > + if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb) { > + phy_add_lookup_table(&twl4030_usb_lookup); > pmic_data->usb = &omap3_usb_pdata; > + } > > if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci) > pmic_data->bci = &omap3_bci_pdata; > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Mon, Dec 16, 2013 at 04:34:35PM +0530, Kishon Vijay Abraham I wrote: > On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote: > > Provide a complete association for the phy and it's user > > (musb) with the new phy_lookup_table. > > > > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > > --- > > arch/arm/mach-omap2/twl-common.c | 15 ++++++--------- > > 1 file changed, 6 insertions(+), 9 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c > > index b0d54da..972430b 100644 > > --- a/arch/arm/mach-omap2/twl-common.c > > +++ b/arch/arm/mach-omap2/twl-common.c > > @@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void) > > } > > > > #if defined(CONFIG_ARCH_OMAP3) > > -struct phy_consumer consumers[] = { > > - PHY_CONSUMER("musb-hdrc.0", "usb"), > > -}; > > - > > -struct phy_init_data init_data = { > > - .consumers = consumers, > > - .num_consumers = ARRAY_SIZE(consumers), > > +static struct phy_lookup_table twl4030_usb_lookup = { > > + .dev_id = "musb-hdrc.0", > > + .table = PHY_LOOKUP("phy-twl4030_usb.0", NULL), > > }; > > had a similar approach during the initial version of phy framework [1] (see > phy_bind) but changed it later [2] . Here you should know the device names of > two devices and even if one of them started using DEVID_AUTO, it'll start > breaking. Such an approach needs to reviewed carefully. If somebody creates a regression by changing something like the platform device id without checking all the users, he deserves to get into big trouble. I don't see why an individual framework should provide protection against such cases. In any case, having two device names to deal with does not add any more risk. These associations should always be made in the place where the phy device is created so you will always know it's device name. Normally the platform code creates these associations in the same place it creates the platform devices, so you definitely know what the device names will be. In this case it's actually created in drivers/mfd/twl-core.c, so I do need to update this and move the lookup table there. We can still deliver the user name as platform data, though I believe it's always "musb". Maybe we could actually skip that and just hard code the name? The name of the phy we will of course know as the platform device is created there and then, so the two device names don't create any more risk even in this case. Thanks,
Hi, On Monday 16 December 2013 08:13 PM, Heikki Krogerus wrote: > Hi, > > On Mon, Dec 16, 2013 at 04:34:35PM +0530, Kishon Vijay Abraham I wrote: >> On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote: >>> Provide a complete association for the phy and it's user >>> (musb) with the new phy_lookup_table. >>> >>> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> >>> --- >>> arch/arm/mach-omap2/twl-common.c | 15 ++++++--------- >>> 1 file changed, 6 insertions(+), 9 deletions(-) >>> >>> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c >>> index b0d54da..972430b 100644 >>> --- a/arch/arm/mach-omap2/twl-common.c >>> +++ b/arch/arm/mach-omap2/twl-common.c >>> @@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void) >>> } >>> >>> #if defined(CONFIG_ARCH_OMAP3) >>> -struct phy_consumer consumers[] = { >>> - PHY_CONSUMER("musb-hdrc.0", "usb"), >>> -}; >>> - >>> -struct phy_init_data init_data = { >>> - .consumers = consumers, >>> - .num_consumers = ARRAY_SIZE(consumers), >>> +static struct phy_lookup_table twl4030_usb_lookup = { >>> + .dev_id = "musb-hdrc.0", >>> + .table = PHY_LOOKUP("phy-twl4030_usb.0", NULL), >>> }; >> >> had a similar approach during the initial version of phy framework [1] (see >> phy_bind) but changed it later [2] . Here you should know the device names of >> two devices and even if one of them started using DEVID_AUTO, it'll start >> breaking. Such an approach needs to reviewed carefully. > > If somebody creates a regression by changing something like the > platform device id without checking all the users, he deserves to get > into big trouble. I don't see why an individual framework should > provide protection against such cases. > > In any case, having two device names to deal with does not add any > more risk. These associations should always be made in the place where > the phy device is created so you will always know it's device name. huh.. we should also know the 'controller' device name while defining these associations and in some cases the controller device and phy device are created in entirely different places. > Normally the platform code creates these associations in the same > place it creates the platform devices, so you definitely know what the > device names will be. > > In this case it's actually created in drivers/mfd/twl-core.c, so I do > need to update this and move the lookup table there. We can still > deliver the user name as platform data, though I believe it's always > "musb". Maybe we could actually skip that and just hard code the name? I would rather leave the way it is modelled now. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Heikki Krogerus <heikki.krogerus@linux.intel.com> [131209 07:10]: > Provide a complete association for the phy and it's user > (musb) with the new phy_lookup_table. This seems safe to queue via the USB list: Acked-by: Tony Lindgren <tony@atomide.com> > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- > arch/arm/mach-omap2/twl-common.c | 15 ++++++--------- > 1 file changed, 6 insertions(+), 9 deletions(-) > > diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c > index b0d54da..972430b 100644 > --- a/arch/arm/mach-omap2/twl-common.c > +++ b/arch/arm/mach-omap2/twl-common.c > @@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void) > } > > #if defined(CONFIG_ARCH_OMAP3) > -struct phy_consumer consumers[] = { > - PHY_CONSUMER("musb-hdrc.0", "usb"), > -}; > - > -struct phy_init_data init_data = { > - .consumers = consumers, > - .num_consumers = ARRAY_SIZE(consumers), > +static struct phy_lookup_table twl4030_usb_lookup = { > + .dev_id = "musb-hdrc.0", > + .table = PHY_LOOKUP("phy-twl4030_usb.0", NULL), > }; > > static struct twl4030_usb_data omap3_usb_pdata = { > .usb_mode = T2_USB_MODE_ULPI, > - .init_data = &init_data, > }; > > static int omap3_batt_table[] = { > @@ -225,8 +220,10 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data, > } > > /* Common platform data configurations */ > - if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb) > + if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb) { > + phy_add_lookup_table(&twl4030_usb_lookup); > pmic_data->usb = &omap3_usb_pdata; > + } > > if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci) > pmic_data->bci = &omap3_bci_pdata; > -- > 1.8.5.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 07, 2014 at 06:31:52PM +0530, Kishon Vijay Abraham I wrote: > > In any case, having two device names to deal with does not add any > > more risk. These associations should always be made in the place where > > the phy device is created so you will always know it's device name. > > huh.. we should also know the 'controller' device name while defining these > associations and in some cases the controller device and phy device are created > in entirely different places. If you don't want to use the controller device name to do the matching, we can use the con_id string as well. I believe the lookup method I use in this set just needs a small change. Is that OK with you? > > Normally the platform code creates these associations in the same > > place it creates the platform devices, so you definitely know what the > > device names will be. > > > > In this case it's actually created in drivers/mfd/twl-core.c, so I do > > need to update this and move the lookup table there. We can still > > deliver the user name as platform data, though I believe it's always > > "musb". Maybe we could actually skip that and just hard code the name? > > I would rather leave the way it is modelled now. Do you mean, leave it in the platform code? Why? We would reduce the platform code by moving it to the mfd driver. Or did I misunderstood something? Hope I'm not forgetting something we have talked before my vacation. Thanks,
Hi, On Tuesday 14 January 2014 08:08 PM, Heikki Krogerus wrote: > On Tue, Jan 07, 2014 at 06:31:52PM +0530, Kishon Vijay Abraham I wrote: >>> In any case, having two device names to deal with does not add any >>> more risk. These associations should always be made in the place where >>> the phy device is created so you will always know it's device name. >> >> huh.. we should also know the 'controller' device name while defining these >> associations and in some cases the controller device and phy device are created >> in entirely different places. > > If you don't want to use the controller device name to do the > matching, we can use the con_id string as well. I believe the lookup > method I use in this set just needs a small change. The point I'm trying to make is that we won't 'always' know the device names in advance. Btw how are you planning to differentiate between multiple controllers of the same type with con_id? Maybe I'm missing the actual intention of this patch. Do you face problem if the PHY's have to know about it's consumers in ACPI? > > Is that OK with you? > > >>> Normally the platform code creates these associations in the same >>> place it creates the platform devices, so you definitely know what the >>> device names will be. >>> >>> In this case it's actually created in drivers/mfd/twl-core.c, so I do >>> need to update this and move the lookup table there. We can still >>> deliver the user name as platform data, though I believe it's always >>> "musb". Maybe we could actually skip that and just hard code the name? >> >> I would rather leave the way it is modelled now. > > Do you mean, leave it in the platform code? Why? We would reduce the > platform code by moving it to the mfd driver. Or did I misunderstood > something? In this case, the lookup table will be used only for non-dt boot so don't see much use in moving to mfd driver. I meant if the new method is not solving any problem then I would prefer the way it is modelled now where the PHY's know about it's consumers. Btw where does device gets created in ACPI boot? Cheers Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 15, 2014 at 07:41:55PM +0530, Kishon Vijay Abraham I wrote: > The point I'm trying to make is that we won't 'always' know the device names in > advance. In which cases do we not know the device names, and please note, cases where we would need to use the lookup? The normal cases we would use it are.. 1) A driver creating a child device, like dwc3 when it creates the xhci. There the parent just delivers the phys it has to the child, so both the device name and the phys are known. 2) Platform code. Hopefully we can get rid of the platform code one day, but in any case, when we use it, we always know at least how many users a phy has, and if there is only a singe user, we can rely con_id to do the matching. Though I still don't really see much risk in using the controller device name also there. The lookup table should in any case be made in the place where the phy devices are created, so the phy name is definitely always known. 3) Phys part of something like mfd. This is in practice the same as the platform code case. For example, with twl we always know there is only one user for the phy, which is musb. So we can just use musb's con_id if it's to scary to use "musb-hdrc.0". In any other case, you get the phy from DT, and there is no need to use the lookup when linking the phys and the users. > Btw how are you planning to differentiate between multiple controllers of the > same type with con_id? You don't rely on the con_id alone in those cases. You then use the device name. The con_id is just one parameter you can use to do the matching. > Maybe I'm missing the actual intention of this patch. Do you face problem if > the PHY's have to know about it's consumers in ACPI? <snip> > >> I would rather leave the way it is modelled now. > > > > Do you mean, leave it in the platform code? Why? We would reduce the > > platform code by moving it to the mfd driver. Or did I misunderstood > > something? > > In this case, the lookup table will be used only for non-dt boot so don't see > much use in moving to mfd driver. > I meant if the new method is not solving any problem then I would prefer the > way it is modelled now where the PHY's know about it's consumers. OK, so that's what you meant. Things like that init_data promotes use of platform data in the drivers, something that we really should get rid of. Is that not a problem to you? The phy drivers simply should not need to care about the consumers. They should not need to care about anything DT, ACPI, platform specific if it's possible, and here there is nothing preventing it. Let me clarify.. The plan is that ultimately the drivers (meaning all the drivers, not just phy) don't need to care about things like DT properties, ACPI properties or anything DT, ACPI, platform specific. We will have generic driver properties and capabilities and the upper layers will take care of delivering the correct values from the source at hand. The drivers can be made truly platform agnostic. That is the goal, and we should make everything new by keeping that in mind. Many existing frameworks are being converted to that direction, like the gpio framework and DMA Engine API. The way you force the phy drivers the deliver the consumers is taking a step backwards. > Btw where does device gets created in ACPI boot? drivers/acpi/acpi_platform.c Thanks,
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c index b0d54da..972430b 100644 --- a/arch/arm/mach-omap2/twl-common.c +++ b/arch/arm/mach-omap2/twl-common.c @@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void) } #if defined(CONFIG_ARCH_OMAP3) -struct phy_consumer consumers[] = { - PHY_CONSUMER("musb-hdrc.0", "usb"), -}; - -struct phy_init_data init_data = { - .consumers = consumers, - .num_consumers = ARRAY_SIZE(consumers), +static struct phy_lookup_table twl4030_usb_lookup = { + .dev_id = "musb-hdrc.0", + .table = PHY_LOOKUP("phy-twl4030_usb.0", NULL), }; static struct twl4030_usb_data omap3_usb_pdata = { .usb_mode = T2_USB_MODE_ULPI, - .init_data = &init_data, }; static int omap3_batt_table[] = { @@ -225,8 +220,10 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data, } /* Common platform data configurations */ - if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb) + if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb) { + phy_add_lookup_table(&twl4030_usb_lookup); pmic_data->usb = &omap3_usb_pdata; + } if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci) pmic_data->bci = &omap3_bci_pdata;
Provide a complete association for the phy and it's user (musb) with the new phy_lookup_table. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> --- arch/arm/mach-omap2/twl-common.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-)