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@xxxxxxxxxxxxxxxxxxxxxx> >>>> --- >>>> 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:
signature.asc
Description: OpenPGP digital signature