1. 16 5月, 2018 1 次提交
  2. 12 5月, 2018 1 次提交
  3. 11 5月, 2018 1 次提交
  4. 20 4月, 2018 1 次提交
  5. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  6. 12 10月, 2017 1 次提交
  7. 10 10月, 2017 1 次提交
  8. 12 8月, 2017 1 次提交
  9. 07 8月, 2017 4 次提交
    • R
      sfp: add SFP module support · 73970055
      Russell King 提交于
      Add support for SFP hotpluggable modules via sfp-bus and phylink.
      This supports both copper and optical SFP modules, which require
      different Serdes modes in order to properly negotiate the link.
      
      Optical SFP modules typically require the Serdes link to be talking
      1000BaseX mode - this is the gigabit ethernet mode defined by the
      802.3 standard.
      
      Copper SFP modules typically integrate a PHY in the module to convert
      from Serdes to copper, and the PHY will be configured by the vendor
      to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a
      SGMII Serdes link.  However, this is vendor defined, so we instead
      detect the PHY, switch the link to SGMII mode, and use traditional
      PHY based negotiation.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73970055
    • R
    • R
      phylink: add phylink infrastructure · 9525ae83
      Russell King 提交于
      The link between the ethernet MAC and its PHY has become more complex
      as the interface evolves.  This is especially true with serdes links,
      where the part of the PHY is effectively integrated into the MAC.
      
      Serdes links can be connected to a variety of devices, including SFF
      modules soldered down onto the board with the MAC, a SFP cage with
      a hotpluggable SFP module which may contain a PHY or directly modulate
      the serdes signals onto optical media with or without a PHY, or even
      a classical PHY connection.
      
      Moreover, the negotiation information on serdes links comes in two
      varieties - SGMII mode, where the PHY provides its speed/duplex/flow
      control information to the MAC, and 1000base-X mode where both ends
      exchange their abilities and each resolve the link capabilities.
      
      This means we need a more flexible means to support these arrangements,
      particularly with the hotpluggable nature of SFP, where the PHY can
      be attached or detached after the network device has been brought up.
      
      Ethtool information can come from multiple sources:
      - we may have a PHY operating in either SGMII or 1000base-X mode, in
        which case we take ethtool/mii data directly from the PHY.
      - we may have a optical SFP module without a PHY, with the MAC
        operating in 1000base-X mode - the ethtool/mii data needs to come
        from the MAC.
      - we may have a copper SFP module with a PHY whic can't be accessed,
        which means we need to take ethtool/mii data from the MAC.
      
      Phylink aims to solve this by providing an intermediary between the
      MAC and PHY, providing a safe way for PHYs to be hotplugged, and
      allowing a SFP driver to reconfigure the serdes connection.
      
      Phylink also takes over support of fixed link connections, where the
      speed/duplex/flow control are fixed, but link status may be controlled
      by a GPIO signal.  By avoiding the fixed-phy implementation, phylink
      can provide a faster response to link events: fixed-phy has to wait for
      phylib to operate its state machine, which can take several seconds.
      In comparison, phylink takes milliseconds.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      
      - remove sync status
      - rework supported and advertisment handling
      - add 1000base-x speed for fixed links
      - use functionality exported from phy-core, reworking
        __phylink_ethtool_ksettings_set for it
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9525ae83
    • R
      net: phy: add I2C mdio bus · 453d00de
      Russell King 提交于
      Add an I2C MDIO bus bridge library, to allow phylib to access PHYs which
      are connected to an I2C bus instead of the more conventional MDIO bus.
      Such PHYs can be found in SFP adapters and SFF modules.
      
      Since PHYs appear at I2C bus address 0x40..0x5f, and 0x50/0x51 are
      reserved for SFP EEPROMs/diagnostics, we must not allow the MDIO bus
      to access these I2C addresses.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      453d00de
  10. 07 6月, 2017 2 次提交
  11. 31 5月, 2017 1 次提交
  12. 30 3月, 2017 1 次提交
    • F
      net: phy: Allow building mdio-boardinfo into the kernel · d0281a56
      Florian Fainelli 提交于
      mdio-boardinfo contains code that is helpful for platforms to register
      specific MDIO bus devices independent of how CONFIG_MDIO_DEVICE or
      CONFIG_PHYLIB will be selected (modular or built-in). In order to make
      that possible, let's do the following:
      
      - descend into drivers/net/phy/ unconditionally
      
      - make mdiobus_setup_mdiodev_from_board_info() take a callback argument
        which allows us not to expose the internal MDIO board info list and
        mutex, yet maintain the logic within the same file
      
      - relocate the code that creates a MDIO device into
        drivers/net/phy/mdio_bus.c
      
      - build mdio-boardinfo.o into the kernel as soon as MDIO_DEVICE is
        defined (y or m)
      
      Fixes: 90eff909 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
      Fixes: 648ea013 ("net: phy: Allow pre-declaration of MDIO devices")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0281a56
  13. 25 3月, 2017 1 次提交
    • F
      net: phy: Allow splitting MDIO bus/device support from PHYs · 90eff909
      Florian Fainelli 提交于
      Introduce a new configuration symbol: MDIO_DEVICE which allows building
      the MDIO devices and bus code, without pulling in the entire Ethernet
      PHY library and devices code.
      
      PHYLIB nows select MDIO_DEVICE and the relevant Makefile files are
      updated to reflect that.
      
      When MDIO_DEVICE (MDIO bus/device only) is selected, but not PHYLIB, we
      have mdio-bus.ko as a loadable module, and it does not have a
      module_exit() function because the safety of removing a bus class is
      unclear.
      
      When both MDIO_DEVICE and PHYLIB are enabled, we need to assemble
      everything into a common loadable module: libphy.ko because of nasty
      circular dependencies between phy.c, phy_device.c and mdio_bus.c which
      are really tough to untangle.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90eff909
  14. 23 3月, 2017 1 次提交
  15. 07 2月, 2017 1 次提交
  16. 10 11月, 2016 1 次提交
  17. 18 10月, 2016 1 次提交
    • Z
      net: phy: leds: add support for led triggers on phy link state change · 2e0bc452
      Zach Brown 提交于
      Create an option CONFIG_LED_TRIGGER_PHY (default n), which will create a
      set of led triggers for each instantiated PHY device. There is one LED
      trigger per link-speed, per-phy.
      The triggers are registered during phy_attach and unregistered during
      phy_detach.
      
      This allows for a user to configure their system to allow a set of LEDs
      not controlled by the phy to represent link state changes on the phy.
      LEDS controlled by the phy are unaffected.
      
      For example, we have a board where some of the leds in the
      RJ45 socket are controlled by the phy, but others are not. Using the
      triggers provided by this patch the leds not controlled by the phy can
      be configured to show the current speed of the ethernet connection. The
      leds controlled by the phy are unaffected.
      Signed-off-by: NJosh Cartwright <josh.cartwright@ni.com>
      Signed-off-by: NNathan Sullivan <nathan.sullivan@ni.com>
      Signed-off-by: NZach Brown <zach.brown@ni.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e0bc452
  18. 20 8月, 2016 1 次提交
  19. 13 8月, 2016 1 次提交
    • A
      net: phy: Add gmiitorgmii converter support · f411a616
      Appana Durga Kedareswara Rao 提交于
      This patch adds support for gmiitorgmii converter.
      
      The GMII to RGMII IP core provides the Reduced Gigabit Media
      Independent Interface (RGMII) between Ethernet physical media
      Devices and the Gigabit Ethernet controller. This core can
      Switch dynamically between the three different speed modes of
      Operation by configuring the converter register through mdio write.
      
      MDIO interface is used to set operating speed of Ethernet MAC.
      
      This converter sits between the MAC and the external phy
      MAC <==> GMII2RGMII <==> RGMII_PHY
      Signed-off-by: NKedareswara rao Appana <appanad@xilinx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f411a616
  20. 09 8月, 2016 1 次提交
  21. 26 7月, 2016 1 次提交
  22. 17 7月, 2016 1 次提交
  23. 27 6月, 2016 1 次提交
  24. 11 6月, 2016 2 次提交
  25. 15 3月, 2016 2 次提交
    • D
      phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses. · 379d7ac7
      David Daney 提交于
      The Cavium Thunder SoCs have multiple MIDO buses that are part of a
      single PCI device.  To model this in the device tree we call the PCI
      parent device a "cavium,thunder-8890-mdio-nexus", it has several
      children, one for each MDIO bus.
      
      The MDIO bus hardware is identical to that found in the OCTEON SoCs,
      so we use that code for things that are not part of the PCI driver
      probe/remove
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      379d7ac7
    • D
      phy: mdio-octeon: Refactor into two files/modules · 1eefee90
      David Daney 提交于
      A follow-on patch uses PCI probing to find the Thunder MDIO hardware.
      In preparation for this, split out the common code into a new file
      mdio-cavium.c, which will be used by both the existing OCTEON driver,
      and the new Thunder PCI based driver.
      
      As part of the refactoring simplify the struct cavium_mdiobus by
      removing fields that are only ever used in the probe function and can
      just as well be local variables.
      
      Use readq/writeq in preference to readq_relaxed/writeq_relaxed as the
      relaxed form was an optimization for an early chip revision, and the
      MDIO drivers are not performance bottlenecks that need optimization in
      the first place.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1eefee90
  26. 08 1月, 2016 1 次提交
  27. 22 10月, 2015 1 次提交
  28. 08 10月, 2015 3 次提交
  29. 10 9月, 2015 1 次提交
  30. 01 8月, 2015 1 次提交
  31. 21 7月, 2015 1 次提交
  32. 04 6月, 2015 1 次提交