lkml.org 
[lkml]   [2016]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ARM: tegra: fix erroneous address in dts
From
Date
On 07/15/2016 06:01 PM, Stephen Warren wrote:
> On 07/15/2016 03:37 AM, Ralf Ramsauer wrote:
>> On 07/15/2016 12:02 AM, Thierry Reding wrote:
>>> On Thu, Jul 14, 2016 at 06:48:57PM +0200, Ralf Ramsauer wrote:
>>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
>>>> specification inside the dts is wrong. Fix it and use the correct
>>>> address.
>>>>
>>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1
>>>> device tree")
>>>> Signed-off-by: Ralf Ramsauer <ralf@ramses-pyramidenbau.de>
>>>> ---
>>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> These addresses are correct. The 0, prefix was dropped from the unit
>>> address in commit b5896f67ab3c ("ARM: tegra: Remove commas from unit
>>> addresses on Tegra124").
>>>
>>> What's the problem that you're seeing? What's not working for you?
>>
>> I cannot find b5896f67ab3c neither in swarren's tree nor in linux
>> upstream. But there's d0bc5aaf890 in swarren's linux-tegra tree that
>> matches your described changes and was committed on 1st of July. But
>> this patch is not upstream yet, while the other patch is.
>
> The fix is in linux-next, and will be in mainline soon I expect.
Ah okay, but I still wonder how my original patch got changed on its
way... The original version on the mailinglist was not buggy.
>
> My github linux-tegra.git isn't relevant since it's just my own personal
> dev branch, but for reference, the commit is there since it's based on
> linux-next.
>
>> Have a look at mainline tegra124-jetson-tk1.dts, there the addresses are
>> erroneous as they still use the 0, annotation. And I just realised, that
>> somehow, upstream patch c90bb7b slightly differs from my initial patch
>> [1] on the mailing list.
>
> Your patch should probably be CC: stable so that existing kernel
> versions get fixed. That said, I'd argue that since the original patch
> never actually had any effect since it applied to the wrong node, the
> best fix for stable kernels is simply to revert it rather than fixing
> it, to avoid the potential for behaviour changes and regressions.
> Starting with kernel 4.8 (I think), that patch will begin to have actual
> effect.
There is no current existing stable kernel that is affected, as it went
in during the last merge window in 4.6-rc1. So no need for fixing
stable. Maybe it's still possible to fix it as the stabilisation window
is still open and 4.7 is not released yet?

Ralf
--
Ralf Ramsauer
PGP: 0x8F10049B

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2016-07-15 18:41    [W:0.059 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site