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@xxxxxx> > >> --- > >> 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" :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
