1. 04 Aug, 2017 6 commits
  2. 02 Aug, 2017 1 commit
  3. 29 Jul, 2017 1 commit
    • Geert Uytterhoeven's avatar
      ARM: shmobile: rcar-gen2: Fix deadlock in regulator quirk · fce8dc5e
      Geert Uytterhoeven authored
      Simon Horman reported that Koelsch and Lager hang during boot, and
      bisected this to commit 1c3c5eab ("sched/core: Enable
      might_sleep() and smp_processor_id() checks early").
      
      The da9063/da9210 regulator quirk for R-Car Gen2 boards uses a bus
      notifier, and unregisters the notifier when it is no longer needed.
      However, a notifier must not be unregistered from within the call chain.
      
      This bug went unnoticed, as blocking_notifier_chain_unregister() didn't
      take the semaphore during early boot.  The aforementioned commit changed
      that behavior, leading to a deadlock.
      
      Fix this by removing the call to bus_unregister_notifier(), and keeping
      local completion state instead.
      Reported-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Fixes: 663fbb52 ("ARM: shmobile: R-Car Gen2: Add da9063/da9210 regulator quirk")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      fce8dc5e
  4. 27 Jul, 2017 22 commits
    • Arnd Bergmann's avatar
      ARM: pxa: select both FB and FB_W100 for eseries · 1d20d8a9
      Arnd Bergmann authored
      We get a link error trying to access the w100fb_gpio_read/write
      functions from the platform when the driver is a loadable module
      or not built-in, so the platform already uses 'select' to hard-enable
      the driver.
      
      However, that fails if the framebuffer subsystem is disabled
      altogether.
      
      I've considered various ways to fix this properly, but they
      all seem like too much work or too risky, so this simply
      adds another 'select' to force the subsystem on as well.
      
      Fixes: 82427de2 ("ARM: pxa: PXA_ESERIES depends on FB_W100.")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      1d20d8a9
    • Arnd Bergmann's avatar
      ARM: ixp4xx: fix ioport_unmap definition · c4caa8db
      Arnd Bergmann authored
      An empty macro definition can cause unexpected behavior, in
      case of the ixp4xx ioport_unmap, we get two warnings:
      
      drivers/net/wireless/marvell/libertas/if_cs.c: In function 'if_cs_release':
      drivers/net/wireless/marvell/libertas/if_cs.c:826:3: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
         ioport_unmap(card->iobase);
      drivers/vfio/pci/vfio_pci_rdwr.c: In function 'vfio_pci_vga_rw':
      drivers/vfio/pci/vfio_pci_rdwr.c:230:15: error: the omitted middle operand in ?: will always be 'true', suggest explicit middle operand [-Werror=parentheses]
         is_ioport ? ioport_unmap(iomem) : iounmap(iomem);
      
      This uses an inline function to define the macro in a safer way.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarKrzysztof Halasa <khalasa@piap.pl>
      c4caa8db
    • Arnd Bergmann's avatar
      ARM: ep93xx: use ARM_PATCH_PHYS_VIRT correctly · cd5bad41
      Arnd Bergmann authored
      Just like ARCH_MULTIPLATFORM, we want to use ARM_PATCH_PHYS_VIRT
      when possible, but that fails for NOMMU or XIP_KERNEL configurations.
      Using 'imply' instead of 'select' gets this right and only uses
      the symbol when we don't have to hardcode the address anyway.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarAlexander Sverdlin <alexander.sverdlin@gmail.com>
      cd5bad41
    • Arnd Bergmann's avatar
      ARM: mmp: mark usb_dma_mask as __maybe_unused · 1c1953f3
      Arnd Bergmann authored
      This variable may be used by some devices that each have their
      on Kconfig symbol, or by none of them, and that causes a build
      warning:
      
      arch/arm/mach-mmp/devices.c:241:12: error: 'usb_dma_mask' defined but not used [-Werror=unused-variable]
      
      Marking it __maybe_unused avoids the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      1c1953f3
    • Arnd Bergmann's avatar
      ARM: omap2: mark unused functions as __maybe_unused · 293ea3d0
      Arnd Bergmann authored
      The omap_generic_init() and omap_hwmod_init_postsetup() functions are
      used in the initialization for all OMAP2+ SoC types, but in the
      extreme case that those are all disabled, we get a warning about
      unused code:
      
      arch/arm/mach-omap2/io.c:412:123: error: 'omap_hwmod_init_postsetup' defined but not used [-Werror=unused-function]
      arch/arm/mach-omap2/board-generic.c:30:123: error: 'omap_generic_init' defined but not used [-Werror=unused-function]
      
      This annotates both as __maybe_unused to shut up that warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Reviewed-by: default avatarSebastian Reichel <sebastian.reichel@collabora.co.uk>
      293ea3d0
    • Arnd Bergmann's avatar
      ARM: omap1: avoid unused variable warning · d1c88887
      Arnd Bergmann authored
      The osk_mistral_init() contains code that is only compiled when
      CONFIG_PM is set, but it uses a variable that is declared outside
      of the #ifdef:
      
      arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
      arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]
      
      This removes the #ifdef around the user of the variable,
      make it always used.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Suggested-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      d1c88887
    • Arnd Bergmann's avatar
      ARM: sirf: mark sirfsoc_init_late as __maybe_unused · c1ae3f7c
      Arnd Bergmann authored
      sirfsoc_init_late is called by each of the three individual
      SoC definitions, but in a randconfig build, we can encounter
      a situation where they are all disabled:
      
      arch/arm/mach-prima2/common.c:18:123: warning: 'sirfsoc_init_late' defined but not used [-Wunused-function]
      
      While that is not a useful configuration, the warning also
      doesn't help, so this patch marks the function as __maybe_unused
      to let the compiler know it is there intentionally.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      c1ae3f7c
    • Arnd Bergmann's avatar
      ARM: ixp4xx: use normal prototype for {read,write}s{b,w,l} · 1f3b4d8f
      Arnd Bergmann authored
      ixp4xx defines the arguments to its __indirect_writesb() and other
      functions as pointers to fixed-size data. This is not necessarily
      wrong, and it works most of the time, but it causes warnings in
      at least one driver:
      
      drivers/net/ethernet/smsc/smc91x.c: In function 'smc_rcv':
      drivers/net/ethernet/smsc/smc91x.c:495:21: error: passing argument 2 of '__indirect_readsw' from incompatible pointer type [-Werror=incompatible-pointer-types]
         SMC_PULL_DATA(lp, data, packet_len - 4);
      
      All other definitions of the same functions pass void pointers,
      so doing the same here avoids the warnings.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarKrzysztof Halasa <khalasa@piap.pl>
      1f3b4d8f
    • Arnd Bergmann's avatar
      ARM: omap1/ams-delta: warn about failed regulator enable · 595a9f9a
      Arnd Bergmann authored
      The modem pm handler in the ams-delta board uses regulator_enable()
      but does not check for a successful return code:
      
      board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]
      
      It is not easy to propagate that return code to the callers in
      uart_configure_port/uart_suspend_port/uart_resume_port, unless
      we change all UART drivers, and it is unclear what those would
      do with the return code.
      
      Instead, this patch uses a runtime warning to replace the
      compiletime warning. I have checked that the regulator in question
      is hardcoded to a fixed-voltage GPIO regulator, and that should
      never fail to get enabled if I understand the code right.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Link: https://patchwork.kernel.org/patch/8391981/Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      595a9f9a
    • Arnd Bergmann's avatar
      ARM: rpc: rename RAM_SIZE macro · 47589c4a
      Arnd Bergmann authored
      The RAM_SIZE macro in mach/hardware.h conflicts with macros of
      the same name in multiple drivers, leading to annoying build warnings:
      
      In file included from drivers/net/ethernet/cirrus/cs89x0.c:79:0:
      drivers/net/ethernet/cirrus/cs89x0.h:324:0: error: "RAM_SIZE" redefined [-Werror]
       #define RAM_SIZE 0x1000       /*  The card has 4k bytes or RAM */
       ^
      In file included from /git/arm-soc/arch/arm/mach-rpc/include/mach/io.h:16:0,
                       from /git/arm-soc/arch/arm/include/asm/io.h:194,
                       from /git/arm-soc/include/linux/scatterlist.h:8,
                       from /git/arm-soc/include/linux/dmaengine.h:24,
                       from /git/arm-soc/include/linux/netdevice.h:38,
                       from /git/arm-soc/drivers/net/ethernet/cirrus/cs89x0.c:54:
      arch/arm/mach-rpc/include/mach/hardware.h:28:0: note: this is the location of the previous definition
       #define RAM_SIZE  0x10000000
      
      We don't use RAM_SIZE/RAM_START at all, so we could just remove
      them, but it might be nice to leave them for documentation purposes,
      so this renames them to RPC_RAM_SIZE/RPC_RAM_START in order to
      avoid the build warnings
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      47589c4a
    • Arnd Bergmann's avatar
      ARM: w90x900: normalize clk API · bd7fefe1
      Arnd Bergmann authored
      w90x900 still provides its own variant of the clk API rather than using
      the generic COMMON_CLK API. This generally works, but it causes some link
      errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent
      or clk_round_rate functions when a platform lacks those interfaces.
      
      This adds empty stub implementations for each of them, and I don't even
      try to do something useful here but instead just print a WARN() message
      to make it obvious what is going on if they ever end up being called.
      
      The drivers that call these won't be used on these platforms (otherwise
      we'd get a link error today), so the added code is harmless bloat and
      will warn about accidental use.
      
      A while ago there was a proposal to change w90x900 to use the common-clk
      implementation, which would be the way it should be handled properly.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      bd7fefe1
    • Alexander Sverdlin's avatar
      ARM: ep93xx: normalize clk API · ef8aa4e0
      Alexander Sverdlin authored
      It's a combination of the patch from Arnd Bergmann, which added empty stubs
      for clk_round_rate() and clk_set_parent() and a working trivial
      implementation of clk_get_parent(). The later is required for ADC driver.
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@gmail.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      ef8aa4e0
    • Arnd Bergmann's avatar
      ARM: sa1100: normalize clk API · 77a374c2
      Arnd Bergmann authored
      sa1100 provides its own variant of the clk API rather than using the
      generic COMMON_CLK API. This generally works, but it causes some link
      errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent
      or clk_round_rate functions when a platform lacks those interfaces.
      
      This adds trivial stub implementations for each of them, based on
      the behavior of the COMMON_CLK implementation:
      
      - set_rate() and set_parent() report success without doing anything
      - round_rate() returns the clk rate
      - get_parent() returns NULL.
      
      This adds the minimal bloat and should do the right thing for
      the simple clock hardware in this SoC.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      77a374c2
    • Arnd Bergmann's avatar
      ARM: davinci: normalize clk API · 31d5cf14
      Arnd Bergmann authored
      davinci still has its own clk implementation, but lacks
      a clk_get_parent() helper, which can lead to link errors
      in randconfig builds.
      
      This adds the usual implementation.
      Acked-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      31d5cf14
    • Arnd Bergmann's avatar
      ARM: sa1100/pxa: fix MTD_XIP build · d997211e
      Arnd Bergmann authored
      In commit 3169663a "ARM: sa11x0/pxa: convert OS timer registers
      to IOMEM", the definition of the OSCR macro was changed to be an
      __iomem pointer, but the same register is also used by the XIP
      code. This patch does the corresponding change here as well.
      
      On PXA, the IRQ register definitions were removed even earlier, in
      commit 5d284e35 ("ARM: pxa: avoid accessing interrupt registers
      directly"). This patch unfortunately brings some of that back. An
      earlier version of my patch moved the code into an external function,
      which could not work for CONFIG_XIP_KERNEL+CONFIG_MTD_XIP, so this
      restores something close to the original code.
      
      Link: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241716.htmlAcked-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d997211e
    • Arnd Bergmann's avatar
      ARM: davinci: don't mark vpif_input structures as 'const' · 8b974017
      Arnd Bergmann authored
      A change to the platform data definitions caused a warning in the board code:
      
      arch/arm/mach-davinci/board-da850-evm.c:1221:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
      arch/arm/mach-davinci/board-da850-evm.c:1231:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
      
      This is a bit unfortunate, since we generally like structure definitions to
      be const, but as this is legacy code, the easiest way out is still to
      remove the 'const' annotation here.
      
      Fixes: 4a5f8ae5 ("[media] davinci: vpif_capture: get subdevs from DT when available")
      Fixes: 231ce279 ("ARM: davinci: fix const warnings")
      Acked-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      8b974017
    • Geert Uytterhoeven's avatar
      soc: zte: Restrict SOC_ZTE to ARCH_ZX or COMPILE_TEST · fe89168c
      Geert Uytterhoeven authored
      The ZTE SoC drivers are only useful when building for a ZTE ZX platform.
      
      Fixes: 4c2c2e39 ("soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: default avatarBaoyou Xie <baoyou.xie@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      fe89168c
    • Arnd Bergmann's avatar
      Merge tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu into fixes · 75f4e381
      Arnd Bergmann authored
      Pull "mvebu fixes for 4.13 (part 1)" from Gregory CLEMENT:
      
      - Fix wrong irq type for gpio expeander on Armada 388 GP
      - Use __pa_symbol instead of virt_to_phys in the mv98dx3236 platform
        SMP code
      
      * tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu:
        ARM: dts: armada-38x: Fix irq type for pca955
        ARM: mvebu: use __pa_symbol in the mv98dx3236 platform SMP code
      75f4e381
    • Krzysztof Kozlowski's avatar
      ARM: dts: exynos: Add clocks to audss block to fix silent hang on Exynos4412 · a3c0d2fb
      Krzysztof Kozlowski authored
      Add necessary parent clocks for audss (Audio SubSystem, MAUDIO) clock
      controller block.
      
      This allows driver to keep EPLL enabled before accessing any MAUDIO
      registers thus fixing silent hang.  This silent hang appeared with
      commit 6edfa11c ("clk: samsung: Add enable/disable operation for
      PLL36XX clocks"), e.g. on Odroid U3 usually with last (but unrelated)
      messages:
      
      	[    2.382741] input: gpio_keys as /devices/platform/gpio_keys/input/input0
      	[    2.405686] usb 1-3: new high-speed USB device number 3 using exynos-ehci
      	[    2.419843] max77686-rtc max77686-rtc: setting system clock to 2017-06-21 17:04:13 UTC (1498064653)
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      a3c0d2fb
    • Arnd Bergmann's avatar
      Merge tag 'renesas-fixes2-for-v4.13' of... · b2e58cbe
      Arnd Bergmann authored
      Merge tag 'renesas-fixes2-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
      
      Pull "Second Round of Renesas ARM Based SoC Fixes for v4.13" from Simon Horman:
      
      Correct order of sound clock frequencies for ULCB boards
      used by r8a7795 and r8a7796 SoCs.
      
      These sounds clock frequencies are used as the ADG clock (output clocks
      for audio module) initial setting and sound codec's initial system clock
      which needs the maximum clock frequency. Thus, descending order is
      required.
      
      * tag 'renesas-fixes2-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
        arm64: dts: renesas: ulcb: sound clock-frequency needs descending order
      b2e58cbe
    • Arnd Bergmann's avatar
      Merge tag 'omap-for-v4.13/fixes-merge-window' of... · d4e74005
      Arnd Bergmann authored
      Merge tag 'omap-for-v4.13/fixes-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
      
      Pull "Few fixes for omaps for issues found recently" from Tony Lindgren:
      
      - Fix disable_irq related shared IRQ warnings for omap3 PRM
      
      - Fix omap4 legacy code regression that accidentally removed code that
        we still need for PRM interrupts
      
      - Fix dm8168-evm NAND pins and MMC write protect pin direction
      
      - Fix dra71-evm mdio impedance values
      
      * tag 'omap-for-v4.13/fixes-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
        ARM: dts: dra71-evm: mdio: Fix impedance values
        ARM: dts: dm816x: Correct the state of the write protect pin
        ARM: dts: dm816x: Correct NAND support nodes
        ARM: OMAP4: Fix legacy code clean-up regression
        ARM: OMAP2+: Fix omap3 prm shared irq
      d4e74005
    • Arnd Bergmann's avatar
      Merge tag 'renesas-fixes-for-v4.13' of... · 2f9227c7
      Arnd Bergmann authored
      Merge tag 'renesas-fixes-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
      
      Pull "Renesas ARM Based SoC Fixes for v4.13" from Simon Horman:
      
      Correct order of sound clock frequencies for Salvator boards
      used by r8a7795 and r8a7796 SoCs.
      
      These sounds clock frequencies are used as the ADG clock (output clocks
      for audio module) initial setting and sound codec's initial system clock
      which needs the maximum clock frequency. Thus, descending order is
      required.
      
      * tag 'renesas-fixes-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
        arm64: renesas: salvator-common: sound clock-frequency needs descending order
      2f9227c7
  5. 23 Jul, 2017 8 commits
  6. 22 Jul, 2017 2 commits