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 <ba...@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 <rog...@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 linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
