Re: [PATCH v2 3/7] phy: omap-usb2: Use generic clock names "wkupclk" and "refclk"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, Apr 29, 2014 at 11:16 AM, Felipe Balbi <balbi@xxxxxx> 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@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.

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux