1. 25 4月, 2016 6 次提交
  2. 09 4月, 2016 2 次提交
  3. 26 3月, 2016 1 次提交
  4. 22 3月, 2016 2 次提交
  5. 21 3月, 2016 2 次提交
  6. 19 3月, 2016 11 次提交
  7. 18 3月, 2016 2 次提交
  8. 17 3月, 2016 3 次提交
  9. 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
  10. 15 3月, 2016 6 次提交
  11. 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
  12. 13 3月, 2016 1 次提交