1. 28 1月, 2017 1 次提交
  2. 22 1月, 2017 1 次提交
  3. 20 1月, 2017 1 次提交
  4. 15 1月, 2017 1 次提交
  5. 14 1月, 2017 2 次提交
  6. 11 1月, 2017 2 次提交
  7. 31 12月, 2016 2 次提交
  8. 30 12月, 2016 1 次提交
  9. 28 12月, 2016 2 次提交
  10. 21 12月, 2016 2 次提交
    • D
      net: hix5hd2_gmac: fix compatible strings name · f7ca8e3b
      Dongpo Li 提交于
      The SoC hix5hd2 compatible string has the suffix "-gmac" and
      we should not change its compatible string.
      So we should name all the compatible string with the suffix "-gmac".
      Creating a new name suffix "-gemac" is unnecessary.
      
      We also add another SoC compatible string in dt binding documentation
      and describe which generic version the SoC belongs to.
      
      Fixes: d0fb6ba7 ("net: hix5hd2_gmac: add generic compatible string")
      Signed-off-by: NDongpo Li <lidongpo@hisilicon.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7ca8e3b
    • J
      dt: bindings: net: use boolean dt properties for eee broken modes · 308d3165
      jbrunet 提交于
      The patches regarding eee-broken-modes was merged before all people
      involved could find an agreement on the best way to move forward.
      
      While we agreed on having a DT property to mark particular modes as broken,
      the value used for eee-broken-modes mapped the phy register in very direct
      way. Because of this, the concern is that it could be used to implement
      configuration policies instead of describing a broken HW.
      
      In the end, having a boolean property for each mode seems to be preferred
      over one bit field value mapping the register (too) directly.
      
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      308d3165
  11. 20 12月, 2016 1 次提交
  12. 19 12月, 2016 1 次提交
  13. 16 12月, 2016 1 次提交
  14. 12 12月, 2016 2 次提交
    • S
      i2c: sh_mobile: Add per-Generation fallback bindings · b880ccaf
      Simon Horman 提交于
      Add per-Generation fallback bindings for R-Car SoCs.
      
      This is in keeping with the compatibility string scheme is being adopted
      for drivers for Renesas SoCs.
      
      Also, improve readability by listing the rmobile fallback compatibility
      string after the more-specific compatibility strings they provide a
      fallback for.
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      b880ccaf
    • S
      i2c: rcar: Add per-Generation fallback bindings · ad4a8dc3
      Simon Horman 提交于
      In the case of Renesas R-Car hardware we know that there are generations of
      SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the
      relationship between IP blocks might be. For example, I believe that
      r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
      descendant of the former or vice versa.
      
      We can, however, by examining the documentation and behaviour of the
      hardware at run-time observe that the current driver implementation appears
      to be compatible with the IP blocks on SoCs within a given generation.
      
      For the above reasons and convenience when enabling new SoCs a
      per-generation fallback compatibility string scheme is being adopted for
      drivers for Renesas SoCs.
      
      Also:
      * Deprecate renesas,i2c-rcar. It seems poorly named as it is only
        compatible with R-Car Gen 1. It also appears unused in mainline.
      * Add some text to describe per-SoC bindings
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      ad4a8dc3
  15. 10 12月, 2016 6 次提交
  16. 09 12月, 2016 5 次提交
  17. 08 12月, 2016 4 次提交
  18. 07 12月, 2016 5 次提交