| Message ID | 1398693687-13967-4-git-send-email-rogerq@ti.com |
|---|---|
| State | New |
| Headers | show |
Hi, On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: > As clocks might be named differently on multiple platforms, use a generic > name in the driver and allow device tree node to specify the platform > specific clock name. > > Signed-off-by: Roger Quadros <rogerq@ti.com> > --- > drivers/phy/phy-omap-usb2.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c > index a2205a8..fb5e515 100644 > --- a/drivers/phy/phy-omap-usb2.c > +++ b/drivers/phy/phy-omap-usb2.c > @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) > if (IS_ERR(phy_provider)) > return PTR_ERR(phy_provider); > > - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); > + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); doesn't this patch cause a regression ? I mean, you're changing the clock name before fixing DTS. Also, that DTS has been in a major version of the kernel, so we need to maintain compatibility with it. How about: phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); if (IS_ERR(phy->wkupclk)) { dev_err(&pdev->dev, "unable to get wkupclk, trying old name\n"); phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); if (IS_ERR(phy->wkupclk)) { dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n"); return PTR_ERR(phy->wkupclk); } else { dev_warn(&pdev->dev, "found usb_phy_cm_clk32k, please fix your DTS\n"); } } a bit ugly, but at least we don't cause any regressions. Likewise for other clocks.
+Nishant Hi, On 04/28/2014 07:03 PM, Felipe Balbi wrote: > Hi, > > On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: >> As clocks might be named differently on multiple platforms, use a generic >> name in the driver and allow device tree node to specify the platform >> specific clock name. >> >> Signed-off-by: Roger Quadros <rogerq@ti.com> >> --- >> drivers/phy/phy-omap-usb2.c | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c >> index a2205a8..fb5e515 100644 >> --- a/drivers/phy/phy-omap-usb2.c >> +++ b/drivers/phy/phy-omap-usb2.c >> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) >> if (IS_ERR(phy_provider)) >> return PTR_ERR(phy_provider); >> >> - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); >> + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); > > doesn't this patch cause a regression ? I mean, you're changing the > clock name before fixing DTS. Also, that DTS has been in a major version > of the kernel, so we need to maintain compatibility with it. How about: I'm changing the DTS in Patch 4, but I prefer to do it in this patch to prevent synchronization issues in -next. About backward compatibility, I agree with you but at the same time I don't think anyone using TI SoCs burns the DTB to ROM and needs backward compatibility. We supply our BSPs/SDKs with the updated DTBs. Do you feel strict backward compatibility is worth the effort for TI specific blocks? > > phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); > if (IS_ERR(phy->wkupclk)) { > dev_err(&pdev->dev, "unable to get wkupclk, trying old name\n"); > phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); > if (IS_ERR(phy->wkupclk)) { > dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n"); > return PTR_ERR(phy->wkupclk); > } else { > dev_warn(&pdev->dev, "found usb_phy_cm_clk32k, please fix your DTS\n"); > } > } > > a bit ugly, but at least we don't cause any regressions. Likewise for > other clocks. > cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: > +Nishant > > Hi, > > On 04/28/2014 07:03 PM, Felipe Balbi wrote: > > Hi, > > > > On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: > >> As clocks might be named differently on multiple platforms, use a generic > >> name in the driver and allow device tree node to specify the platform > >> specific clock name. > >> > >> Signed-off-by: Roger Quadros <rogerq@ti.com> > >> --- > >> drivers/phy/phy-omap-usb2.c | 8 ++++---- > >> 1 file changed, 4 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c > >> index a2205a8..fb5e515 100644 > >> --- a/drivers/phy/phy-omap-usb2.c > >> +++ b/drivers/phy/phy-omap-usb2.c > >> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) > >> if (IS_ERR(phy_provider)) > >> return PTR_ERR(phy_provider); > >> > >> - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); > >> + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); > > > > doesn't this patch cause a regression ? I mean, you're changing the > > clock name before fixing DTS. Also, that DTS has been in a major version > > of the kernel, so we need to maintain compatibility with it. How about: > > I'm changing the DTS in Patch 4, but I prefer to do it in this patch > to prevent synchronization issues in -next. > > About backward compatibility, I agree with you but at the same time I > don't think anyone using TI SoCs burns the DTB to ROM and needs > backward compatibility. We supply our BSPs/SDKs with the updated DTBs. > Do you feel strict backward compatibility is worth the effort for TI > specific blocks? dunno, but it would, at least, avoid "synchronization issues with linux-next" :-)
On Tue, Apr 29, 2014 at 11:14:20AM -0500, Felipe Balbi wrote: > On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: > > +Nishant > > > > Hi, > > > > On 04/28/2014 07:03 PM, Felipe Balbi wrote: > > > Hi, > > > > > > On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: > > >> As clocks might be named differently on multiple platforms, use a generic > > >> name in the driver and allow device tree node to specify the platform > > >> specific clock name. > > >> > > >> Signed-off-by: Roger Quadros <rogerq@ti.com> > > >> --- > > >> drivers/phy/phy-omap-usb2.c | 8 ++++---- > > >> 1 file changed, 4 insertions(+), 4 deletions(-) > > >> > > >> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c > > >> index a2205a8..fb5e515 100644 > > >> --- a/drivers/phy/phy-omap-usb2.c > > >> +++ b/drivers/phy/phy-omap-usb2.c > > >> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) > > >> if (IS_ERR(phy_provider)) > > >> return PTR_ERR(phy_provider); > > >> > > >> - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); > > >> + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); > > > > > > doesn't this patch cause a regression ? I mean, you're changing the > > > clock name before fixing DTS. Also, that DTS has been in a major version > > > of the kernel, so we need to maintain compatibility with it. How about: > > > > I'm changing the DTS in Patch 4, but I prefer to do it in this patch > > to prevent synchronization issues in -next. > > > > About backward compatibility, I agree with you but at the same time I > > don't think anyone using TI SoCs burns the DTB to ROM and needs > > backward compatibility. We supply our BSPs/SDKs with the updated DTBs. > > Do you feel strict backward compatibility is worth the effort for TI > > specific blocks? > > dunno, but it would, at least, avoid "synchronization issues with > linux-next" :-) and the bisectability issue.
On 04/29/2014 07:16 PM, Felipe Balbi wrote: > On Tue, Apr 29, 2014 at 11:14:20AM -0500, Felipe Balbi wrote: >> On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: >>> +Nishant >>> >>> Hi, >>> >>> On 04/28/2014 07:03 PM, Felipe Balbi wrote: >>>> Hi, >>>> >>>> On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: >>>>> As clocks might be named differently on multiple platforms, use a generic >>>>> name in the driver and allow device tree node to specify the platform >>>>> specific clock name. >>>>> >>>>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>>>> --- >>>>> drivers/phy/phy-omap-usb2.c | 8 ++++---- >>>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c >>>>> index a2205a8..fb5e515 100644 >>>>> --- a/drivers/phy/phy-omap-usb2.c >>>>> +++ b/drivers/phy/phy-omap-usb2.c >>>>> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) >>>>> if (IS_ERR(phy_provider)) >>>>> return PTR_ERR(phy_provider); >>>>> >>>>> - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); >>>>> + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); >>>> >>>> doesn't this patch cause a regression ? I mean, you're changing the >>>> clock name before fixing DTS. Also, that DTS has been in a major version >>>> of the kernel, so we need to maintain compatibility with it. How about: >>> >>> I'm changing the DTS in Patch 4, but I prefer to do it in this patch >>> to prevent synchronization issues in -next. >>> >>> About backward compatibility, I agree with you but at the same time I >>> don't think anyone using TI SoCs burns the DTB to ROM and needs >>> backward compatibility. We supply our BSPs/SDKs with the updated DTBs. >>> Do you feel strict backward compatibility is worth the effort for TI >>> specific blocks? >> >> dunno, but it would, at least, avoid "synchronization issues with >> linux-next" :-) > > and the bisectability issue. > If backward compatibility is not the real worry then we could avoid the synchronization/bisectability issue by squashing the dts changes with this patch. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 29, 2014 at 11:16 AM, Felipe Balbi <balbi@ti.com> wrote: > On Tue, Apr 29, 2014 at 11:14:20AM -0500, Felipe Balbi wrote: >> On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: >> > +Nishant >> > >> > Hi, >> > >> > On 04/28/2014 07:03 PM, Felipe Balbi wrote: >> > > Hi, >> > > >> > > On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: >> > >> As clocks might be named differently on multiple platforms, use a generic >> > >> name in the driver and allow device tree node to specify the platform >> > >> specific clock name. >> > >> >> > >> Signed-off-by: Roger Quadros <rogerq@ti.com> >> > >> --- >> > >> drivers/phy/phy-omap-usb2.c | 8 ++++---- >> > >> 1 file changed, 4 insertions(+), 4 deletions(-) >> > >> >> > >> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c >> > >> index a2205a8..fb5e515 100644 >> > >> --- a/drivers/phy/phy-omap-usb2.c >> > >> +++ b/drivers/phy/phy-omap-usb2.c >> > >> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) >> > >> if (IS_ERR(phy_provider)) >> > >> return PTR_ERR(phy_provider); >> > >> >> > >> - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); >> > >> + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); >> > > >> > > doesn't this patch cause a regression ? I mean, you're changing the >> > > clock name before fixing DTS. Also, that DTS has been in a major version >> > > of the kernel, so we need to maintain compatibility with it. How about: >> > >> > I'm changing the DTS in Patch 4, but I prefer to do it in this patch >> > to prevent synchronization issues in -next. >> > >> > About backward compatibility, I agree with you but at the same time I >> > don't think anyone using TI SoCs burns the DTB to ROM and needs >> > backward compatibility. We supply our BSPs/SDKs with the updated DTBs. >> > Do you feel strict backward compatibility is worth the effort for TI >> > specific blocks? >> >> dunno, but it would, at least, avoid "synchronization issues with >> linux-next" :-) > > and the bisectability issue. I agree - we cannot drop backward compatibility for DTBs http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7 " + + 3) Bindings can be augmented, but the driver shouldn't break when given + the old binding. ie. add additional properties, but don't change the + meaning of an existing property. For drivers, default to the original + behaviour when a newly added property is missing. " Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/30/2014 06:20 PM, Nishanth Menon wrote: > On Tue, Apr 29, 2014 at 11:16 AM, Felipe Balbi <balbi@ti.com> wrote: >> On Tue, Apr 29, 2014 at 11:14:20AM -0500, Felipe Balbi wrote: >>> On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: >>>> +Nishant >>>> >>>> Hi, >>>> >>>> On 04/28/2014 07:03 PM, Felipe Balbi wrote: >>>>> Hi, >>>>> >>>>> On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: >>>>>> As clocks might be named differently on multiple platforms, use a generic >>>>>> name in the driver and allow device tree node to specify the platform >>>>>> specific clock name. >>>>>> >>>>>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>>>>> --- >>>>>> drivers/phy/phy-omap-usb2.c | 8 ++++---- >>>>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>>>> >>>>>> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c >>>>>> index a2205a8..fb5e515 100644 >>>>>> --- a/drivers/phy/phy-omap-usb2.c >>>>>> +++ b/drivers/phy/phy-omap-usb2.c >>>>>> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) >>>>>> if (IS_ERR(phy_provider)) >>>>>> return PTR_ERR(phy_provider); >>>>>> >>>>>> - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); >>>>>> + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); >>>>> >>>>> doesn't this patch cause a regression ? I mean, you're changing the >>>>> clock name before fixing DTS. Also, that DTS has been in a major version >>>>> of the kernel, so we need to maintain compatibility with it. How about: >>>> >>>> I'm changing the DTS in Patch 4, but I prefer to do it in this patch >>>> to prevent synchronization issues in -next. >>>> >>>> About backward compatibility, I agree with you but at the same time I >>>> don't think anyone using TI SoCs burns the DTB to ROM and needs >>>> backward compatibility. We supply our BSPs/SDKs with the updated DTBs. >>>> Do you feel strict backward compatibility is worth the effort for TI >>>> specific blocks? >>> >>> dunno, but it would, at least, avoid "synchronization issues with >>> linux-next" :-) >> >> and the bisectability issue. > > I agree - we cannot drop backward compatibility for DTBs > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7 That says backward compatibility for stable bindings. In this case, the binding that I changed doesn't even exist in Documentation/devicetree/bindings, so it never was a stable binding. > " > + > + 3) Bindings can be augmented, but the driver shouldn't break when given > + the old binding. ie. add additional properties, but don't change the > + meaning of an existing property. For drivers, default to the original > + behaviour when a newly added property is missing. > " cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/05/2014 10:23 AM, Roger Quadros wrote: > On 04/30/2014 06:20 PM, Nishanth Menon wrote: >> On Tue, Apr 29, 2014 at 11:16 AM, Felipe Balbi <balbi@ti.com> wrote: >>> On Tue, Apr 29, 2014 at 11:14:20AM -0500, Felipe Balbi wrote: >>>> On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: >>>>> +Nishant >>>>> >>>>> Hi, >>>>> >>>>> On 04/28/2014 07:03 PM, Felipe Balbi wrote: >>>>>> Hi, >>>>>> >>>>>> On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: >>>>>>> As clocks might be named differently on multiple platforms, use a generic >>>>>>> name in the driver and allow device tree node to specify the platform >>>>>>> specific clock name. >>>>>>> >>>>>>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>>>>>> --- >>>>>>> drivers/phy/phy-omap-usb2.c | 8 ++++---- >>>>>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c >>>>>>> index a2205a8..fb5e515 100644 >>>>>>> --- a/drivers/phy/phy-omap-usb2.c >>>>>>> +++ b/drivers/phy/phy-omap-usb2.c >>>>>>> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) >>>>>>> if (IS_ERR(phy_provider)) >>>>>>> return PTR_ERR(phy_provider); >>>>>>> >>>>>>> - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); >>>>>>> + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); >>>>>> >>>>>> doesn't this patch cause a regression ? I mean, you're changing the >>>>>> clock name before fixing DTS. Also, that DTS has been in a major version >>>>>> of the kernel, so we need to maintain compatibility with it. How about: >>>>> >>>>> I'm changing the DTS in Patch 4, but I prefer to do it in this patch >>>>> to prevent synchronization issues in -next. >>>>> >>>>> About backward compatibility, I agree with you but at the same time I >>>>> don't think anyone using TI SoCs burns the DTB to ROM and needs >>>>> backward compatibility. We supply our BSPs/SDKs with the updated DTBs. >>>>> Do you feel strict backward compatibility is worth the effort for TI >>>>> specific blocks? >>>> >>>> dunno, but it would, at least, avoid "synchronization issues with >>>> linux-next" :-) >>> >>> and the bisectability issue. >> >> I agree - we cannot drop backward compatibility for DTBs >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7 > > That says backward compatibility for stable bindings. > In this case, the binding that I changed doesn't even exist in Documentation/devicetree/bindings, > so it never was a stable binding. Forgot to mention, I'm sending a revised version based on your and Felipe's suggestion. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c index a2205a8..fb5e515 100644 --- a/drivers/phy/phy-omap-usb2.c +++ b/drivers/phy/phy-omap-usb2.c @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) if (IS_ERR(phy_provider)) return PTR_ERR(phy_provider); - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); if (IS_ERR(phy->wkupclk)) { - dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n"); + dev_err(&pdev->dev, "unable to get wkupclk\n"); return PTR_ERR(phy->wkupclk); } clk_prepare(phy->wkupclk); - phy->optclk = devm_clk_get(phy->dev, "usb_otg_ss_refclk960m"); + phy->optclk = devm_clk_get(phy->dev, "refclk"); if (IS_ERR(phy->optclk)) - dev_vdbg(&pdev->dev, "unable to get refclk960m\n"); + dev_dbg(&pdev->dev, "unable to get refclk\n"); else clk_prepare(phy->optclk);
As clocks might be named differently on multiple platforms, use a generic name in the driver and allow device tree node to specify the platform specific clock name. Signed-off-by: Roger Quadros <rogerq@ti.com> --- drivers/phy/phy-omap-usb2.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)