Re: [PATCH] ARM: tegra: fix erroneous address in dts

[Ralf Ramsauer <ralf-ex4EvEgDZR1o7HI0AxOeTKwczVv4G7md@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2622 bytes --]

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-ex4EvEgDZR1o7HI0AxOeTKwczVv4G7md@public.gmane.org>
>>>> ---
>>>>   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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]