1. 04 Jan, 2018 3 commits
    • Masahiro Yamada's avatar
      arm64: dts: uniphier: fix gpio-ranges property of PXs3 SoC · abb62c46
      Masahiro Yamada authored
      This is probably a copy-paste mistake.  The gpio-ranges of PXs3 is
      different from that of LD20.
      
      Fixes: 277b51e7 ("arm64: dts: uniphier: add GPIO controller nodes")
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      abb62c46
    • Arnd Bergmann's avatar
      Merge tag 'sunxi-fixes-for-4.15' of... · d84baa5a
      Arnd Bergmann authored
      Merge tag 'sunxi-fixes-for-4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes
      
      Pull "Allwinner fixes for 4.15" from Chen-Yu Tsai:
      
      First, one fix that adds proper regulator references for the EMAC
      external PHYs on A64 boards. The EMAC bindings were developed for 4.13,
      but reverted at the last minute. They were finalized and brought back
      for 4.15. However in the time between, regulator support for the A64
      boards was merged. When EMAC device tree changes were reintroduced,
      this was not taken into account.
      
      Second, a patch that adds OF based modalias uevent for RSB slave devices.
      This has been missing since the introduction of RSB, and recently with
      PMIC regulator support introduced for the A64, has been seen affecting
      distributions, which have the all-important PMIC mfd drivers built as
      modules, which then don't get loaded.
      
      Other minor cleanups include final conversion of raw indices to CCU
      binding macros for sun[4567]i HDMI, cleanup of dummy regulators on the
      A64 SOPINE, a SD card detection polarity fix for the Orange Pi Zero
      Plus2, and adding a missing compatible for the PMIC on the TBS A711
      tablet.
      
      * tag 'sunxi-fixes-for-4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
        ARM: dts: sun8i: a711: Reinstate the PMIC compatible
        arm64: dts: orange-pi-zero-plus2: fix sdcard detect
        arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3
        ARM: dts: sunxi: Convert to CCU index macros for HDMI controller
        sunxi-rsb: Include OF based modalias in device uevent
        arm64: allwinner: a64: add Ethernet PHY regulator for several boards
      d84baa5a
    • Arnd Bergmann's avatar
      Merge tag 'renesas-fixes-for-v4.15' of... · 3bfbed8d
      Arnd Bergmann authored
      Merge tag 'renesas-fixes-for-v4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
      
      Pull "Renesas ARM Based SoC Fixes for v4.15" from Simon Horman:
      
      Vladimir Zapolskiy says:
      
      The present change is a bug fix for AVB link iteratively up/down.
      
      Steps to reproduce:
      - start AVB TX stream (Using aplay via MSE),
      - disconnect+reconnect the eth cable,
      - after a reconnection the eth connection goes iteratively up/down
        without user interaction,
      - this may heal after some seconds or even stay for minutes.
      
      As the documentation specifies, the "renesas,no-ether-link" option
      should be used when a board does not provide a proper AVB_LINK signal.
      There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
      and ULCB starter kits since the AVB_LINK is correctly handled by HW.
      
      Choosing to keep or remove the "renesas,no-ether-link" option will
      have impact on the code flow in the following ways:
      - keeping this option enabled may lead to unexpected behavior since
        the RX & TX are enabled/disabled directly from adjust_link function
        without any HW interrogation,
      - removing this option, the RX & TX will only be enabled/disabled after
        HW interrogation. The HW check is made through the LMON pin in PSR
        register which specifies AVB_LINK signal value (0 - at low level;
        1 - at high level).
      
      In conclusion, the change is also a safety improvement because it
      removes the "renesas,no-ether-link" option leading to a proper way
      of detecting the link state based on HW interrogation and not on
      software heuristic.
      
      Note that DTS files for V3M Starter Kit, Draak and Eagle boards
      contain the same property, the files are untouched due to unavailable
      schematics to verify if the fix applies to these boards as well.
      
      * tag 'renesas-fixes-for-v4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
        arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
        arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property
      3bfbed8d
  2. 22 Dec, 2017 4 commits
    • Bogdan Mirea's avatar
      arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property · 7d2901f8
      Bogdan Mirea authored
      The present change is a bug fix for AVB link iteratively up/down.
      
      Steps to reproduce:
      - start AVB TX stream (Using aplay via MSE),
      - disconnect+reconnect the eth cable,
      - after a reconnection the eth connection goes iteratively up/down
        without user interaction,
      - this may heal after some seconds or even stay for minutes.
      
      As the documentation specifies, the "renesas,no-ether-link" option
      should be used when a board does not provide a proper AVB_LINK signal.
      There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
      and ULCB starter kits since the AVB_LINK is correctly handled by HW.
      
      Choosing to keep or remove the "renesas,no-ether-link" option will
      have impact on the code flow in the following ways:
      - keeping this option enabled may lead to unexpected behavior since
        the RX & TX are enabled/disabled directly from adjust_link function
        without any HW interrogation,
      - removing this option, the RX & TX will only be enabled/disabled after
        HW interrogation. The HW check is made through the LMON pin in PSR
        register which specifies AVB_LINK signal value (0 - at low level;
        1 - at high level).
      
      In conclusion, the present change is also a safety improvement because
      it removes the "renesas,no-ether-link" option leading to a proper way
      of detecting the link state based on HW interrogation and not on
      software heuristic.
      
      Fixes: dc36965a ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
      Fixes: 6fa501c5 ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
      Signed-off-by: default avatarBogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
      Signed-off-by: default avatarVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      7d2901f8
    • Bogdan Mirea's avatar
      arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property · 87c059e9
      Bogdan Mirea authored
      The present change is a bug fix for AVB link iteratively up/down.
      
      Steps to reproduce:
      - start AVB TX stream (Using aplay via MSE),
      - disconnect+reconnect the eth cable,
      - after a reconnection the eth connection goes iteratively up/down
        without user interaction,
      - this may heal after some seconds or even stay for minutes.
      
      As the documentation specifies, the "renesas,no-ether-link" option
      should be used when a board does not provide a proper AVB_LINK signal.
      There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
      and ULCB starter kits since the AVB_LINK is correctly handled by HW.
      
      Choosing to keep or remove the "renesas,no-ether-link" option will
      have impact on the code flow in the following ways:
      - keeping this option enabled may lead to unexpected behavior since
        the RX & TX are enabled/disabled directly from adjust_link function
        without any HW interrogation,
      - removing this option, the RX & TX will only be enabled/disabled after
        HW interrogation. The HW check is made through the LMON pin in PSR
        register which specifies AVB_LINK signal value (0 - at low level;
        1 - at high level).
      
      In conclusion, the present change is also a safety improvement because
      it removes the "renesas,no-ether-link" option leading to a proper way
      of detecting the link state based on HW interrogation and not on
      software heuristic.
      
      Fixes: dc36965a ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
      Fixes: 6fa501c5 ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
      Signed-off-by: default avatarBogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
      Signed-off-by: default avatarVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      87c059e9
    • Arnd Bergmann's avatar
      ARM: dts: tango4: remove bogus interrupt-controller property · fbd90b4c
      Arnd Bergmann authored
      dtc points out that the parent node of the interrupt controllers is not
      actually an interrupt controller itself, and lacks an #interrupt-cells
      property:
      
      arch/arm/boot/dts/tango4-vantage-1172.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/interrupt-controller@6e000
      
      This removes the annotation.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      fbd90b4c
    • Arnd Bergmann's avatar
      ARM: dts: ls1021a: fix incorrect clock references · 506e8a91
      Arnd Bergmann authored
      dtc warns about two 'clocks' properties that have an extraneous '1'
      at the end:
      
      arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a
      arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a:clocks[1])
      Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2190000/sgtl5000@a
      arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2190000/sgtl5000@a:clocks[1])
      
      The clocks that get referenced here are fixed-rate, so they do not
      take any argument, and dtc interprets the next cell as a phandle, which
      is invalid.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      506e8a91
  3. 21 Dec, 2017 6 commits
  4. 19 Dec, 2017 1 commit
  5. 10 Dec, 2017 3 commits
  6. 08 Dec, 2017 2 commits
  7. 07 Dec, 2017 5 commits
  8. 06 Dec, 2017 1 commit
    • Heiko Stuebner's avatar
      arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now · bc631943
      Heiko Stuebner authored
      It looks like either the current kernel or the hardware has reliability
      issues when the gmac is actually running at 1GBit. In my test-case
      it is not able to boot on a nfsroot at this speed, as the system
      will always lose the connection to the nfs-server during boot, before
      reaching any login prompt and not recover from this.
      
      So until this is solved, limit the speed to 100MBit as with this the
      nfsroot survives stress tests like an apt-get upgrade without problems.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      bc631943
  9. 05 Dec, 2017 7 commits
  10. 04 Dec, 2017 8 commits
    • Peter Rosin's avatar
      ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850 · bc53e3aa
      Peter Rosin authored
      The I2C adapter driver is sometimes slow, causing the SCL line to
      be stuck low for more than the stipulated SMBUS timeout of 25-35 ms.
      This causes the client device to give up which in turn causes silent
      corruption of data. So, disable the SMBUS timeout in the client device.
      Signed-off-by: default avatarPeter Rosin <peda@axentia.se>
      Acked-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      bc53e3aa
    • Heiko Stuebner's avatar
      arm64: dts: rockchip: fix trailing 0 in rk3328 tsadc interrupts · 3fa8c49f
      Heiko Stuebner authored
      Probably due to some copy-paste mistake, the tsadc of rk3328 ended up
      with a 0 as 4th element that shouldn't be there, as interrupts on the
      rk3328 only have multiples of 3, making dtc complain. So remove it.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      3fa8c49f
    • Kim Phillips's avatar
      bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left. · b69f63eb
      Kim Phillips authored
      Unregistering the driver before calling cpuhp_remove_multi_state() removes
      any remaining hotplug cpu instances so __cpuhp_remove_state_cpuslocked()
      doesn't emit this warning:
      
      [  268.748362] Error: Removing state 147 which has instances left.
      [  268.748373] ------------[ cut here ]------------
      [  268.748386] WARNING: CPU: 2 PID: 5476 at kernel/cpu.c:1734 __cpuhp_remove_state_cpuslocked+0x454/0x4f0
      [  268.748389] Modules linked in: arm_ccn(-) [last unloaded: arm_ccn]
      [  268.748403] CPU: 2 PID: 5476 Comm: rmmod Tainted: G        W       4.14.0-rc4+ #3
      [  268.748406] Hardware name: AMD Seattle/Seattle, BIOS 10:18:39 Dec  8 2016
      [  268.748410] task: ffff8001a18ca000 task.stack: ffff80019c120000
      [  268.748416] PC is at __cpuhp_remove_state_cpuslocked+0x454/0x4f0
      [  268.748421] LR is at __cpuhp_remove_state_cpuslocked+0x448/0x4f0
      [  268.748425] pc : [<ffff2000081729ec>] lr : [<ffff2000081729e0>] pstate: 60000145
      [  268.748427] sp : ffff80019c127d30
      [  268.748430] x29: ffff80019c127d30 x28: ffff8001a18ca000
      [  268.748437] x27: ffff20000c2cb000 x26: 1fffe4000042d490
      [  268.748443] x25: ffff20000216a480 x24: 0000000000000000
      [  268.748449] x23: ffff20000b08e000 x22: 0000000000000001
      [  268.748455] x21: 0000000000000093 x20: 00000000000016f8
      [  268.748460] x19: ffff20000c2cbb80 x18: 0000ffffb5fe7c58
      [  268.748466] x17: 00000000004402d0 x16: 1fffe40001864f01
      [  268.748472] x15: ffff20000c4bf8b0 x14: 0000000000000000
      [  268.748477] x13: 0000000000007032 x12: ffff20000829ae48
      [  268.748483] x11: ffff20000c4bf000 x10: 0000000000000004
      [  268.748488] x9 : 0000000000006fbc x8 : ffff20000c318a40
      [  268.748494] x7 : 0000000000000000 x6 : ffff040001864f02
      [  268.748500] x5 : 0000000000000000 x4 : 0000000000000000
      [  268.748505] x3 : 0000000000000007 x2 : dfff200000000000
      [  268.748510] x1 : 000000000000ad3d x0 : 00000000000001f0
      [  268.748516] Call trace:
      [  268.748521] Exception stack(0xffff80019c127bf0 to 0xffff80019c127d30)
      [  268.748526] 7be0:                                   00000000000001f0 000000000000ad3d
      [  268.748531] 7c00: dfff200000000000 0000000000000007 0000000000000000 0000000000000000
      [  268.748535] 7c20: ffff040001864f02 0000000000000000 ffff20000c318a40 0000000000006fbc
      [  268.748539] 7c40: 0000000000000004 ffff20000c4bf000 ffff20000829ae48 0000000000007032
      [  268.748544] 7c60: 0000000000000000 ffff20000c4bf8b0 1fffe40001864f01 00000000004402d0
      [  268.748548] 7c80: 0000ffffb5fe7c58 ffff20000c2cbb80 00000000000016f8 0000000000000093
      [  268.748553] 7ca0: 0000000000000001 ffff20000b08e000 0000000000000000 ffff20000216a480
      [  268.748557] 7cc0: 1fffe4000042d490 ffff20000c2cb000 ffff8001a18ca000 ffff80019c127d30
      [  268.748562] 7ce0: ffff2000081729e0 ffff80019c127d30 ffff2000081729ec 0000000060000145
      [  268.748566] 7d00: 00000000000001f0 0000000000000000 0001000000000000 0000000000000000
      [  268.748569] 7d20: ffff80019c127d30 ffff2000081729ec
      [  268.748575] [<ffff2000081729ec>] __cpuhp_remove_state_cpuslocked+0x454/0x4f0
      [  268.748580] [<ffff200008172adc>] __cpuhp_remove_state+0x54/0x80
      [  268.748597] [<ffff20000215dd84>] arm_ccn_exit+0x2c/0x70 [arm_ccn]
      [  268.748604] [<ffff20000834cfbc>] SyS_delete_module+0x5a4/0x708
      [  268.748607] Exception stack(0xffff80019c127ec0 to 0xffff80019c128000)
      [  268.748612] 7ec0: 0000000019bb7258 0000000000000800 ba64d0fb3d26a800 00000000000000da
      [  268.748616] 7ee0: 0000ffffb6144e28 0000ffffcd95b409 fefefefefefefeff 7f7f7f7f7f7f7f7f
      [  268.748621] 7f00: 000000000000006a 1999999999999999 0000ffffb6179000 0000000000bbcc6d
      [  268.748625] 7f20: 0000ffffb6176b98 0000ffffcd95c2d0 0000ffffb5fe7b58 0000ffffb6163000
      [  268.748630] 7f40: 0000ffffb60ad3e0 00000000004402d0 0000ffffb5fe7c58 0000000019bb71f0
      [  268.748634] 7f60: 0000ffffcd95c740 0000000000000000 0000000019bb71f0 0000000000416700
      [  268.748639] 7f80: 0000000000000000 00000000004402e8 0000000019bb6010 0000ffffcd95c748
      [  268.748643] 7fa0: 0000000000000000 0000ffffcd95c460 00000000004113a8 0000ffffcd95c460
      [  268.748648] 7fc0: 0000ffffb60ad3e8 0000000080000000 0000000019bb7258 000000000000006a
      [  268.748652] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  268.748657] [<ffff200008084f9c>] __sys_trace_return+0x0/0x4
      [  268.748661] ---[ end trace a996d358dcaa7f9c ]---
      
      Fixes: 8df03872 ("bus/arm-ccn: Use cpu-hp's multi instance support instead custom list")
      Signed-off-by: default avatarKim Phillips <kim.phillips@arm.com>
      Acked-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: stable@vger.kernel.org # 4.8+
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      b69f63eb
    • Marc Zyngier's avatar
      bus: arm-cci: Fix use of smp_processor_id() in preemptible context · 4608af8a
      Marc Zyngier authored
      The ARM CCI driver seem to be using smp_processor_id() in a
      preemptible context, which is likely to make a DEBUG_PREMPT
      kernel scream at boot time.
      
      Turn this into a get_cpu()/put_cpu() that extends over the CPU
      hotplug registration, making sure that we don't race against
      a CPU down operation.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: stable@vger.kernel.org # 4.2+
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      4608af8a
    • Marc Zyngier's avatar
      bus: arm-ccn: Fix use of smp_processor_id() in preemptible context · b18c2b94
      Marc Zyngier authored
      Booting a DEBUG_PREEMPT enabled kernel on a CCN-based system
      results in the following splat:
      
      [...]
      arm-ccn e8000000.ccn: No access to interrupts, using timer.
      BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
      caller is debug_smp_processor_id+0x1c/0x28
      CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0 #6111
      Hardware name: AMD Seattle/Seattle, BIOS 17:08:23 Jun 26 2017
      Call trace:
      [<ffff000008089e78>] dump_backtrace+0x0/0x278
      [<ffff00000808a22c>] show_stack+0x24/0x30
      [<ffff000008bc3bc4>] dump_stack+0x8c/0xb0
      [<ffff00000852b534>] check_preemption_disabled+0xfc/0x100
      [<ffff00000852b554>] debug_smp_processor_id+0x1c/0x28
      [<ffff000008551bd8>] arm_ccn_probe+0x358/0x4f0
      [...]
      
      as we use smp_processor_id() in the wrong context.
      
      Turn this into a get_cpu()/put_cpu() that extends over the CPU hotplug
      registration, making sure that we don't race against a CPU down operation.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: stable@vger.kernel.org # 4.2+
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      b18c2b94
    • Christophe JAILLET's avatar
      bus: arm-ccn: Simplify code · 0f9afd36
      Christophe JAILLET authored
      Use 'devm_kasprintf()' to simplify the code.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Acked-by: default avatarScott Branden <scott.branden@broadcom.com>
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      0f9afd36
    • Christophe JAILLET's avatar
      bus: arm-ccn: Check memory allocation failure · 24771179
      Christophe JAILLET authored
      Check memory allocation failures and return -ENOMEM in such cases
      
      This avoids a potential NULL pointer dereference.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Acked-by: default avatarScott Branden <scott.branden@broadcom.com>
      Cc: stable@vger.kernel.org # 3.17+
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      24771179
    • Arvind Yadav's avatar
      bus: arm-ccn: constify attribute_group structures. · 8a84bf45
      Arvind Yadav authored
      attribute_groups are not supposed to change at runtime. All functions
      working with attribute_groups provided by <linux/sysfs.h> work with const
      attribute_group. So mark the non-const structs as const.
      
      File size before:
         text	   data	    bss	    dec	    hex	filename
         9074	   5592	    416	  15082	   3aea	drivers/bus/arm-ccn.o
      
      File size After adding 'const':
         text	   data	    bss	    dec	    hex	filename
         9327	   5336	    416	  15079	   3ae7	drivers/bus/arm-ccn.o
      Signed-off-by: default avatarArvind Yadav <arvind.yadav.cs@gmail.com>
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      8a84bf45