1. 28 7月, 2017 8 次提交
    • A
      ARM: omap2: mark unused functions as __maybe_unused · 293ea3d0
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
      293ea3d0
    • A
      ARM: omap1: avoid unused variable warning · d1c88887
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Suggested-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      d1c88887
    • A
      ARM: sirf: mark sirfsoc_init_late as __maybe_unused · c1ae3f7c
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      c1ae3f7c
    • A
      ARM: ixp4xx: use normal prototype for {read,write}s{b,w,l} · 1f3b4d8f
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NKrzysztof Halasa <khalasa@piap.pl>
      1f3b4d8f
    • A
      ARM: omap1/ams-delta: warn about failed regulator enable · 595a9f9a
      Arnd Bergmann 提交于
      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: NTony Lindgren <tony@atomide.com>
      Acked-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Link: https://patchwork.kernel.org/patch/8391981/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      595a9f9a
    • A
      ARM: rpc: rename RAM_SIZE macro · 47589c4a
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      47589c4a
    • A
      ARM: w90x900: normalize clk API · bd7fefe1
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      bd7fefe1
    • A
      ARM: ep93xx: normalize clk API · ef8aa4e0
      Alexander Sverdlin 提交于
      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: NAlexander Sverdlin <alexander.sverdlin@gmail.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      ef8aa4e0
  2. 27 7月, 2017 5 次提交
    • A
      ARM: sa1100: normalize clk API · 77a374c2
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      77a374c2
    • A
      ARM: davinci: normalize clk API · 31d5cf14
      Arnd Bergmann 提交于
      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: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      31d5cf14
    • A
      ARM: sa1100/pxa: fix MTD_XIP build · d997211e
      Arnd Bergmann 提交于
      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: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      d997211e
    • A
      ARM: davinci: don't mark vpif_input structures as 'const' · 8b974017
      Arnd Bergmann 提交于
      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: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      8b974017
    • K
      ARM: dts: exynos: Add clocks to audss block to fix silent hang on Exynos4412 · a3c0d2fb
      Krzysztof Kozlowski 提交于
      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: NKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      a3c0d2fb
  3. 20 7月, 2017 1 次提交
  4. 18 7月, 2017 2 次提交
  5. 13 7月, 2017 2 次提交
  6. 11 7月, 2017 3 次提交
  7. 10 7月, 2017 2 次提交
  8. 05 7月, 2017 3 次提交
  9. 04 7月, 2017 2 次提交
  10. 03 7月, 2017 3 次提交
    • A
      ARM: owl: smp: Drop bogus holding pen · 18cfd942
      Andreas Färber 提交于
      The S500 SoC can start secondary CPUs without busy-looping for pen_release,
      so simplify the SMP code compared to the LeMaker kernel tree.
      
      Fixes: 172067e0 ("ARM: owl: Implement CPU enable-method for S500")
      Suggested-by: NArnd Bergmann <arnd@arndb.de>
      Cc: David Liu <liuwei@actions-semi.com>
      Signed-off-by: NAndreas Färber <afaerber@suse.de>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      18cfd942
    • A
      ARM: owl: Drop custom machine · eb382745
      Andreas Färber 提交于
      Rely on the fallback to "Generic DT based system".
      This change is visible in /proc/cpuinfo.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAndreas Färber <afaerber@suse.de>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      eb382745
    • L
      ARM/PCI: Remove pci_fixup_irqs() call for bios32 host controllers · 16508469
      Lorenzo Pieralisi 提交于
      Legacy PCI host controllers (ie host controllers that set-up the PCI bus
      through the ARM pci_common_init() API) are currently relying on
      pci_fixup_irqs() to assign legacy PCI irqs to devices.  This is not ideal
      in that pci_fixup_irqs() assigns IRQs for all PCI devices present in a given
      system some of which may well be enabled by the time pci_fixup_irqs() is
      called (ie a system with multiple host controllers).  With the introduction
      of struct pci_host_bridge.(*map_irq) pointer it is possible to assign IRQs
      for all devices originating from a PCI host bridge at probe time; this is
      implemented through pci_assign_irq() that relies on the struct
      pci_host_bridge.map_irq pointer to map IRQ for a given device.
      
      The benefits this brings are twofold:
      
        - the IRQ for a device is assigned once at probe time
        - the IRQ assignment works also for hotplugged devices
      
      Remove pci_fixup_irqs() call from bios32 code and rely on pci_assign_irq()
      to carry out the IRQ mapping at device probe time.
      
      The map_irq() and swizzle_irq() struct pci_host_bridge callbacks are set-up
      in the struct pci_host_bridge created in the bios32 pcibios_init_hw()
      function and mach-* code paths (for PCI mach implementations that require a
      specific struct hw_pci.(*scan) function callback).
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      [bhelgaas: folded in fixes from Lorenzo:
      http://lkml.kernel.org/r/20170701140629.GC8977@red-moon]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Andrew Lunn <andrew@lunn.ch>
      16508469
  11. 02 7月, 2017 1 次提交
  12. 01 7月, 2017 5 次提交
  13. 30 6月, 2017 3 次提交
    • T
      ARM: OMAP4: Fix legacy code clean-up regression · c5b39558
      Tony Lindgren 提交于
      Commit 2a26d31b ("ARM: OMAP2+: Remove unused legacy code for PRM")
      removed PRM platform init code that I thought is unused. Turns out omap4
      still needs this code, so let's do a partial revert to add it back.
      
      I probably missed this earlier as the comments used to say
      "OMAP4+ is DT only now" for !of_have_populated_dt() to exit early and
      missed the negative test. Let's not add those lines back as they are
      confusing and no longer needed as we only boot in device tree mode.
      
      Without things things can mysterious fail for i2c, for example LM75
      I2C temperature sensor can stop working as the PRM interrupts won't work.
      
      Fixes: 2a26d31b ("ARM: OMAP2+: Remove unused legacy code for PRM")
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c5b39558
    • T
      ARM: OMAP2+: Fix omap3 prm shared irq · 324dd7a6
      Tony Lindgren 提交于
      Shared interrupts with IRQ_NOAUTOEN got a warning added with commit
      04c848d3 ("genirq: Warn when IRQ_NOAUTOEN is used with shared
      interrupts").
      
      Let's just drop the IRQ_NOAUTOEN use for omap3 PRM shared interrupt as
      it does not seem to cause any other issues based on my testing. We have
      moved a lot of the code to initialize later, and whatever problems the
      legacy booting had seem to be gone now with pinctrl driver and device
      tree based booting.
      
      Otherwise we will get:
      
      WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1348 __setup_irq+0x5d0/0x64c
      [<c01b0260>] (__setup_irq) from [<c01b0480>]
      (request_threaded_irq+0xdc/0x188)
      [<c01b0480>] (request_threaded_irq) from [<c051c780>]
      (pcs_probe+0x6ec/0x8a4)
      [<c051c780>] (pcs_probe) from [<c05a84b8>] (platform_drv_probe+0x50/0xb0)
      [<c05a84b8>] (platform_drv_probe) from [<c05a6288>]
      (driver_probe_device+0x33c/0x478)
      
      Note that we also need to remove the related enable_irq() to avoid
      getting the following:
      
      WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:529 enable_irq+0x34/0x70
      [<c01afa04>] (enable_irq) from [<c0c0f1fc>] (omap3_pm_init+0x118/0x3f8)
      [<c0c0f1fc>] (omap3_pm_init) from [<c0c0ae7c>] (am35xx_init_late+0x10/0x18)
      
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      324dd7a6
    • D
      ARM: 8685/1: ensure memblock-limit is pmd-aligned · 9e25ebfe
      Doug Berger 提交于
      The pmd containing memblock_limit is cleared by prepare_page_table()
      which creates the opportunity for early_alloc() to allocate unmapped
      memory if memblock_limit is not pmd aligned causing a boot-time hang.
      
      Commit 965278dc ("ARM: 8356/1: mm: handle non-pmd-aligned end of RAM")
      attempted to resolve this problem, but there is a path through the
      adjust_lowmem_bounds() routine where if all memory regions start and
      end on pmd-aligned addresses the memblock_limit will be set to
      arm_lowmem_limit.
      
      Since arm_lowmem_limit can be affected by the vmalloc early parameter,
      the value of arm_lowmem_limit may not be pmd-aligned. This commit
      corrects this oversight such that memblock_limit is always rounded
      down to pmd-alignment.
      
      Fixes: 965278dc ("ARM: 8356/1: mm: handle non-pmd-aligned end of RAM")
      Signed-off-by: NDoug Berger <opendmb@gmail.com>
      Suggested-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      9e25ebfe