Skip to content
Snippets Groups Projects
  1. Jun 03, 2016
  2. May 17, 2016
  3. Mar 22, 2016
  4. Nov 09, 2015
  5. Oct 03, 2015
    • Stas Sergeev's avatar
      of_mdio: add new DT property 'managed' to specify the PHY management type · ebfd3e10
      Stas Sergeev authored
      [ Upstream commit 4cba5c21 in net-next tree,
        will be pushed to Linus very soon. ]
      
      Currently the PHY management type is selected by the MAC driver arbitrary.
      The decision is based on the presence of the "fixed-link" node and on a
      will of the driver's authors.
      This caused a regression recently, when mvneta driver suddenly started
      to use the in-band status for auto-negotiation on fixed links.
      It appears the auto-negotiation may not work when expected by the MAC driver.
      Sebastien Rannou explains:
      << Yes, I confirm that my HW does not generate an in-band status. AFAIK, it's
      a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY (with
      inband status) is connected to the switch through QSGMII, and in this context
      we are on the media side of the PHY. >>
      https://lkml.org/lkml/2015/7/10/206
      
      
      
      This patch introduces the new string property 'managed' that allows
      the user to set the management type explicitly.
      The supported values are:
      "auto" - default. Uses either MDIO or nothing, depending on the presence
      of the fixed-link node
      "in-band-status" - use in-band status
      
      Signed-off-by: default avatarStas Sergeev <stsp@users.sourceforge.net>
      
      CC: Rob Herring <robh+dt@kernel.org>
      CC: Pawel Moll <pawel.moll@arm.com>
      CC: Mark Rutland <mark.rutland@arm.com>
      CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
      CC: Kumar Gala <galak@codeaurora.org>
      CC: Florian Fainelli <f.fainelli@gmail.com>
      CC: Grant Likely <grant.likely@linaro.org>
      CC: devicetree@vger.kernel.org
      CC: linux-kernel@vger.kernel.org
      CC: netdev@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebfd3e10
  6. Aug 17, 2015
  7. Aug 03, 2015
  8. Jul 21, 2015
  9. Jul 10, 2015
  10. Jun 19, 2015
  11. May 29, 2015
  12. May 26, 2015
  13. May 22, 2015
  14. May 15, 2015
  15. May 08, 2015
  16. May 06, 2015
  17. May 04, 2015
    • Suman Anna's avatar
      bus: omap_l3_noc: Fix master id address decoding for OMAP5 · e7309c26
      Suman Anna authored
      
      The L3 Error handling on OMAP5 for the most part is very similar
      to that of OMAP4, and had leveraged common data structures and
      register layout definitions so far. Upon closer inspection, there
      are a few minor differences causing an incorrect decoding and
      reporting of the master NIU upon an error:
      
        1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
           11 bits on OMAP5 as against 8 bits on OMAP4, with the master
           NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
           field.
        2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
           input sources on OMAP5. The common DEBUGSS source is at a
           different input on each SoC.
      
      Fix the above issues by using a OMAP5-specific compatible property
      and using SoC-specific data where there are differences.
      
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Acked-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      e7309c26
  18. Apr 27, 2015
  19. Apr 23, 2015
  20. Apr 22, 2015
  21. Apr 20, 2015
  22. Apr 17, 2015
  23. Apr 16, 2015
  24. Apr 15, 2015
  25. Apr 13, 2015
  26. Apr 10, 2015
Loading