1. 22 3月, 2016 2 次提交
  2. 21 3月, 2016 2 次提交
  3. 19 3月, 2016 11 次提交
  4. 18 3月, 2016 2 次提交
  5. 17 3月, 2016 3 次提交
  6. 16 3月, 2016 2 次提交
    • S
      clk: renesas: Rename header file renesas.h · 09c32427
      Simon Horman 提交于
      This is part of an ongoing process to migrate from ARCH_SHMOBILE to
      ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
      appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
      
      Along with the above mentioned Kconfig changes it seems appropriate
      to also rename files.
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      09c32427
    • A
      ARM: pxa/raumfeld: use PROPERTY_ENTRY_INTEGER to define props · 4d2508a5
      Arnd Bergmann 提交于
      gcc-6.0 notices that the use of the property_entry in this file that
      was recently introduced cannot work right, as we initialize the wrong
      field:
      
      raumfeld.c:387:3: error: the address of 'raumfeld_rotary_encoder_steps' will always evaluate as 'true' [-Werror=address]
         DEV_PROP_U32, 1, &raumfeld_rotary_encoder_steps, },
         ^~~~~~~~~~~~
      raumfeld.c:389:3: error: the address of 'raumfeld_rotary_encoder_axis' will always evaluate as 'true' [-Werror=address]
         DEV_PROP_U32, 1, &raumfeld_rotary_encoder_axis, },
         ^~~~~~~~~~~~
      raumfeld.c:391:3: error: the address of 'raumfeld_rotary_encoder_relative_axis' will always evaluate as 'true' [-Werror=address]
         DEV_PROP_U32, 1, &raumfeld_rotary_encoder_relative_axis, },
         ^~~~~~~~~~~~
      
      The problem appears to stem from relying on an old definition of
      'struct property', but it has changed several times since the code
      could have last been correct.
      
      This changes the code to use the PROPERTY_ENTRY_INTEGER() macro instead,
      which works fine for the current definition and is a safer way of doing
      the initialization.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: a9e340dc ("Input: rotary_encoder - move away from platform data structure")
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      4d2508a5
  7. 15 3月, 2016 6 次提交
  8. 14 3月, 2016 2 次提交
    • A
      ipv6: Pass proto to csum_ipv6_magic as __u8 instead of unsigned short · 1e940829
      Alexander Duyck 提交于
      This patch updates csum_ipv6_magic so that it correctly recognizes that
      protocol is a unsigned 8 bit value.
      
      This will allow us to better understand what limitations may or may not be
      present in how we handle the data.  For example there are a number of
      places that call htonl on the protocol value.  This is likely not necessary
      and can be replaced with a multiplication by ntohl(1) which will be
      converted to a shift by the compiler.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e940829
    • A
      ipv4: Update parameters for csum_tcpudp_magic to their original types · 01cfbad7
      Alexander Duyck 提交于
      This patch updates all instances of csum_tcpudp_magic and
      csum_tcpudp_nofold to reflect the types that are usually used as the source
      inputs.  For example the protocol field is populated based on nexthdr which
      is actually an unsigned 8 bit value.  The length is usually populated based
      on skb->len which is an unsigned integer.
      
      This addresses an issue in which the IPv6 function csum_ipv6_magic was
      generating a checksum using the full 32b of skb->len while
      csum_tcpudp_magic was only using the lower 16 bits.  As a result we could
      run into issues when attempting to adjust the checksum as there was no
      protocol agnostic way to update it.
      
      With this change the value is still truncated as many architectures use
      "(len + proto) << 8", however this truncation only occurs for values
      greater than 16776960 in length and as such is unlikely to occur as we stop
      the inner headers at ~64K in size.
      
      I did have to make a few minor changes in the arm, mn10300, nios2, and
      score versions of the function in order to support these changes as they
      were either using things such as an OR to combine the protocol and length,
      or were using ntohs to convert the length which would have truncated the
      value.
      
      I also updated a few spots in terms of whitespace and type differences for
      the addresses.  Most of this was just to make sure all of the definitions
      were in sync going forward.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      01cfbad7
  9. 13 3月, 2016 4 次提交
  10. 12 3月, 2016 1 次提交
    • T
      ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window · d7d5a43c
      Thomas Petazzoni 提交于
      When the Crypto SRAM mappings were added to the Device Tree files
      describing the Armada XP boards in commit c466d997 ("ARM: mvebu:
      define crypto SRAM ranges for all armada-xp boards"), the fact that
      those mappings were overlaping with the PCIe memory aperture was
      overlooked. Due to this, we currently have for all Armada XP platforms
      a situation that looks like this:
      
      Memory mapping on Armada XP boards with internal registers at
      0xf1000000:
      
       - 0x00000000 -> 0xf0000000	3.75G 	RAM
       - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
       - 0xf1000000 -> 0xf1100000	1M	internal registers
       - 0xf8000000 -> 0xffe0000	126M	PCIe memory aperture
       - 0xf8100000 -> 0xf8110000	64KB	Crypto SRAM #0	=> OVERLAPS WITH PCIE !
       - 0xf8110000 -> 0xf8120000	64KB	Crypto SRAM #1	=> OVERLAPS WITH PCIE !
       - 0xffe00000 -> 0xfff00000	1M	PCIe I/O aperture
       - 0xfff0000  -> 0xffffffff	1M	BootROM
      
      The overlap means that when PCIe devices are added, depending on their
      memory window needs, they might or might not be mapped into the
      physical address space. Indeed, they will not be mapped if the area
      allocated in the PCIe memory aperture by the PCI core overlaps with
      one of the Crypto SRAM. Typically, a Intel IGB PCIe NIC that needs 8MB
      of PCIe memory will see its PCIe memory window allocated from
      0xf80000000 for 8MB, which overlaps with the Crypto SRAM windows. Due
      to this, the PCIe window is not created, and any attempt to access the
      PCIe window makes the kernel explode:
      
      [    3.302213] igb: Copyright (c) 2007-2014 Intel Corporation.
      [    3.307841] pci 0000:00:09.0: enabling device (0140 -> 0143)
      [    3.313539] mvebu_mbus: cannot add window '4:f8', conflicts with another window
      [    3.320870] mvebu-pcie soc:pcie-controller: Could not create MBus window at [mem 0xf8000000-0xf87fffff]: -22
      [    3.330811] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf08c0018
      
      This problem does not occur on Armada 370 boards, because we use the
      following memory mapping (for boards that have internal registers at
      0xf1000000):
      
       - 0x00000000 -> 0xf0000000	3.75G 	RAM
       - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
       - 0xf1000000 -> 0xf1100000	1M	internal registers
       - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0 => OK !
       - 0xf8000000 -> 0xffe0000	126M	PCIe memory
       - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
       - 0xfff0000  -> 0xffffffff	1M	BootROM
      
      Obviously, the solution is to align the location of the Crypto SRAM
      mappings of Armada XP to be similar with the ones on Armada 370, i.e
      have them between the "internal registers" area and the beginning of
      the PCIe aperture.
      
      However, we have a special case with the OpenBlocks AX3-4 platform,
      which has a 128 MB NOR flash. Currently, this NOR flash is mapped from
      0xf0000000 to 0xf8000000. This is possible because on OpenBlocks
      AX3-4, the internal registers are not at 0xf1000000. And this explains
      why the Crypto SRAM mappings were not configured at the same place on
      Armada XP.
      
      Hence, the solution is two-fold:
      
       (1) Move the NOR flash mapping on Armada XP OpenBlocks AX3-4 from
           0xe8000000 to 0xf0000000. This frees the 0xf0000000 ->
           0xf80000000 space.
      
       (2) Move the Crypto SRAM mappings on Armada XP to be similar to
           Armada 370 (except of course that Armada XP has two Crypto SRAM
           and not one).
      
      After this patch, the memory mapping on Armada XP boards with
      registers at 0xf1 is:
      
       - 0x00000000 -> 0xf0000000	3.75G 	RAM
       - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
       - 0xf1000000 -> 0xf1100000	1M	internal registers
       - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
       - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
       - 0xf8000000 -> 0xffe0000	126M	PCIe memory
       - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
       - 0xfff0000  -> 0xffffffff	1M	BootROM
      
      And the memory mapping for the special case of the OpenBlocks AX3-4
      (internal registers at 0xd0000000, NOR of 128 MB):
      
       - 0x00000000 -> 0xc0000000	3G 	RAM
       - 0xd0000000 -> 0xd1000000	1M	internal registers
       - 0xe800000  -> 0xf0000000	128M	NOR flash
       - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
       - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
       - 0xf8000000 -> 0xffe0000	126M	PCIe memory
       - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
       - 0xfff0000  -> 0xffffffff	1M	BootROM
      
      Fixes: c466d997 ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards")
      Reported-by: NPhil Sutter <phil@nwl.cc>
      Cc: Phil Sutter <phil@nwl.cc>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      d7d5a43c
  11. 09 3月, 2016 2 次提交
    • L
      dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc() · f6e45661
      Luis R. Rodriguez 提交于
      Rename dma_*_writecombine() to dma_*_wc(), so that the naming
      is coherent across the various write-combining APIs. Keep the
      old names for compatibility for a while, these can be removed
      at a later time. A guard is left to enable backporting of the
      rename, and later remove of the old mapping defines seemlessly.
      
      Build tested successfully with allmodconfig.
      
      The following Coccinelle SmPL patch was used for this simple
      transformation:
      
      @ rename_dma_alloc_writecombine @
      expression dev, size, dma_addr, gfp;
      @@
      
      -dma_alloc_writecombine(dev, size, dma_addr, gfp)
      +dma_alloc_wc(dev, size, dma_addr, gfp)
      
      @ rename_dma_free_writecombine @
      expression dev, size, cpu_addr, dma_addr;
      @@
      
      -dma_free_writecombine(dev, size, cpu_addr, dma_addr)
      +dma_free_wc(dev, size, cpu_addr, dma_addr)
      
      @ rename_dma_mmap_writecombine @
      expression dev, vma, cpu_addr, dma_addr, size;
      @@
      
      -dma_mmap_writecombine(dev, vma, cpu_addr, dma_addr, size)
      +dma_mmap_wc(dev, vma, cpu_addr, dma_addr, size)
      
      We also keep the old names as compatibility helpers, and
      guard against their definition to make backporting easier.
      
      Generated-by: Coccinelle SmPL
      Suggested-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: airlied@linux.ie
      Cc: akpm@linux-foundation.org
      Cc: benh@kernel.crashing.org
      Cc: bhelgaas@google.com
      Cc: bp@suse.de
      Cc: dan.j.williams@intel.com
      Cc: daniel.vetter@ffwll.ch
      Cc: dhowells@redhat.com
      Cc: julia.lawall@lip6.fr
      Cc: konrad.wilk@oracle.com
      Cc: linux-fbdev@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: luto@amacapital.net
      Cc: mst@redhat.com
      Cc: tomi.valkeinen@ti.com
      Cc: toshi.kani@hp.com
      Cc: vinod.koul@intel.com
      Cc: xen-devel@lists.xensource.com
      Link: http://lkml.kernel.org/r/1453516462-4844-1-git-send-email-mcgrof@do-not-panic.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      f6e45661
    • B
      PCI: Include pci/pcie/Kconfig directly from pci/Kconfig · 5f8fc432
      Bogicevic Sasa 提交于
      Include pci/pcie/Kconfig directly from pci/Kconfig, so arches don't
      have to source both pci/Kconfig and pci/pcie/Kconfig.
      
      Note that this effectively adds pci/pcie/Kconfig to the following
      arches, because they already sourced drivers/pci/Kconfig but they
      previously did not source drivers/pci/pcie/Kconfig:
      
        alpha
        avr32
        blackfin
        frv
        m32r
        m68k
        microblaze
        mn10300
        parisc
        sparc
        unicore32
        xtensa
      
      [bhelgaas: changelog, source pci/pcie/Kconfig at top of pci/Kconfig, whitespace]
      Signed-off-by: NSasa Bogicevic <brutallesale@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5f8fc432
  12. 08 3月, 2016 1 次提交
  13. 07 3月, 2016 2 次提交
    • M
      ARM: dts: dra7: do not gate cpsw clock due to errata i877 · 0f514e69
      Mugunthan V N 提交于
      Errata id: i877
      
      Description:
      ------------
      The RGMII 1000 Mbps Transmit timing is based on the output clock
      (rgmiin_txc) being driven relative to the rising edge of an internal
      clock and the output control/data (rgmiin_txctl/txd) being driven relative
      to the falling edge of an internal clock source. If the internal clock
      source is allowed to be static low (i.e., disabled) for an extended period
      of time then when the clock is actually enabled the timing delta between
      the rising edge and falling edge can change over the lifetime of the
      device. This can result in the device switching characteristics degrading
      over time, and eventually failing to meet the Data Manual Delay Time/Skew
      specs.
      To maintain RGMII 1000 Mbps IO Timings, SW should minimize the
      duration that the Ethernet internal clock source is disabled. Note that
      the device reset state for the Ethernet clock is "disabled".
      Other RGMII modes (10 Mbps, 100Mbps) are not affected
      
      Workaround:
      -----------
      If the SoC Ethernet interface(s) are used in RGMII mode at 1000 Mbps,
      SW should minimize the time the Ethernet internal clock source is disabled
      to a maximum of 200 hours in a device life cycle. This is done by enabling
      the clock as early as possible in IPL (QNX) or SPL/u-boot (Linux/Android)
      by setting the register CM_GMAC_CLKSTCTRL[1:0]CLKTRCTRL = 0x2:SW_WKUP.
      
      So, do not allow to gate the cpsw clocks using ti,no-idle property in
      cpsw node assuming 1000 Mbps is being used all the time. If someone does
      not need 1000 Mbps and wants to gate clocks to cpsw, this property needs
      to be deleted in their respective board files.
      Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      0f514e69
    • L
      ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property · 2e18f5a1
      Lokesh Vutla 提交于
      Introduce a dt property, ti,no-idle, that prevents an IP to idle at any
      point. This is to handle Errata i877, which tells that GMAC clocks
      cannot be disabled.
      Acked-by: NRoger Quadros <rogerq@ti.com>
      Tested-by: NMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      2e18f5a1