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

Reply via email to