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@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" :-) and the bisectability issue. -- balbi
Attachment:
signature.asc
Description: Digital signature
