Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 11月, 2019 1 次提交
  3. 26 9月, 2019 1 次提交
  5. 17 8月, 2019 1 次提交
  7. 07 8月, 2019 1 次提交
    • N
      net: mdio-octeon: Fix Kconfig warnings and build errors · b8fb6406
      由 Nathan Chancellor 提交于 
      After commit 171a9bae ("staging/octeon: Allow test build on
!MIPS"), the following combination of configs cause a few Kconfig
warnings and build errors (distilled from arm allyesconfig and Randy's
randconfig builds):

    CONFIG_NETDEVICES=y
    CONFIG_STAGING=y
    CONFIG_COMPILE_TEST=y

and CONFIG_OCTEON_ETHERNET as either a module or built-in.

WARNING: unmet direct dependencies detected for MDIO_OCTEON
  Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
&& 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
  Selected by [y]:
  - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC ||
COMPILE_TEST [=y]) && NETDEVICES [=y]

In file included from ../drivers/net/phy/mdio-octeon.c:14:
../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
function ‘writeq’; did you mean ‘writel’?
[-Werror=implicit-function-declaration]
  111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
      |                                    ^~~~~~

CONFIG_64BIT is not strictly necessary if the proper readq/writeq
definitions are included from io-64-nonatomic-lo-hi.h.

CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
of commit f9dc9ac5 ("of/mdio: Add dummy functions in of_mdio.h.").

Fixes: 171a9bae ("staging/octeon: Allow test build on !MIPS")
Reported-by: Nkbuild test robot <lkp@intel.com>
Reported-by: NMark Brown <broonie@kernel.org>
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8fb6406
  9. 03 8月, 2019 1 次提交
    • A
      net: phy: Add mdio-aspeed · f160e994
      由 Andrew Jeffery 提交于 
      The AST2600 design separates the MDIO controllers from the MAC, which is
where they were placed in the AST2400 and AST2500. Further, the register
interface is reworked again, so now we have three possible different
interface implementations, however this driver only supports the
interface provided by the AST2600. The AST2400 and AST2500 will continue
to be supported by the MDIO support embedded in the FTGMAC100 driver.

The hardware supports both C22 and C45 mode, but for the moment only C22
support is implemented.
Signed-off-by: NAndrew Jeffery <andrew@aj.id.au>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f160e994
  11. 10 6月, 2019 1 次提交
  13. 27 5月, 2019 1 次提交
  15. 21 5月, 2019 1 次提交
  17. 24 4月, 2019 1 次提交
    • K
      net: phy: mscc: add support for VSC8514 PHY. · e4f9ba64
      由 Kavya Sree Kotagiri 提交于 
      The VSC8514 PHY is a 4-ports PHY that is 10/100/1000BASE-T, 100BASE-FX,
1000BASE-X, can communicate with the MAC via QSGMII.
The MAC interface protocol for each port within QSGMII can
be either 1000BASE-X or SGMII, if the QSGMII MAC that the VSC8514 is
connecting to supports this functionality.
VSC8514 also supports SGMII MAC-side autonegotiation on each individual
port, downshifting, can set the blinking pattern of each of its 4 LEDs,
SyncE, 1000BASE-T Ring Resiliency as well as HP Auto-MDIX detection.

This adds support for 10BASE-T, 100BASE-TX, and 1000BASE-T,
QSGMII link with the MAC, downshifting, HP Auto-MDIX detection
and blinking pattern for its 4 LEDs.

The GPIO register bank is a set of registers that are common to all PHYs
in the package. So any modification in any register of this bank affects
all PHYs of the package.

If the PHYs haven't been reset before booting the Linux kernel and were
configured to use interrupts for e.g. link status updates, it is
required to clear the interrupts mask register of all PHYs before being
able to use interrupts with any PHY. The first PHY of the package that
will be init will take care of clearing all PHYs interrupts mask
registers. Thus, we need to keep track of the init sequence in the
package, if it's already been done or if it's to be done.

Most of the init sequence of a PHY of the package is common to all PHYs
in the package, thus we use the SMI broadcast feature which enables us
to propagate a write in one register of one PHY to all PHYs in the same
package.
Signed-off-by: NKavya Sree Kotagiri <kavyasree.kotagiri@microchip.com>
Signed-off-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Co-developed-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4f9ba64
  19. 07 4月, 2019 1 次提交
  21. 24 3月, 2019 2 次提交
  23. 22 3月, 2019 1 次提交
  25. 05 3月, 2019 1 次提交
  27. 28 2月, 2019 1 次提交
  29. 13 9月, 2018 1 次提交
  31. 22 7月, 2018 1 次提交
    • G
      net: phy: sfp: Do not use "imply HWMON" · b5293443
      由 Guenter Roeck 提交于 
      "imply HWMON" was supposed to ensure that the SFP phy code can be built
with HWMON enabled or disabled while at the same time ensuring that
HWMON is not built as module if SFP is built into the kernel.
Unfortunately, that does not work as intended. With "allmodconfig", it
results in several unrelated HWMON drivers to be disabled instead of
being built as module as expected.

Let's use the old "depends on HWMON || HWMON=n" instead. This is slightly
different (it enforces SFP to be built as module if HWMON is built as
module), but it is better than the alternative of using "IS_REACHABLE()"
in the driver since that would disable sensor support if HWMON is built
as module and SFP is built into the kernel.

Fixes: 1323061a ("net: phy: sfp: Add HWMON support for module sensors")
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5293443
  33. 19 7月, 2018 1 次提交
  35. 18 7月, 2018 1 次提交
    • A
      net: phy: sfp: Add HWMON support for module sensors · 1323061a
      由 Andrew Lunn 提交于 
      SFP modules can contain a number of sensors. The EEPROM also contains
recommended alarm and critical values for each sensor, and indications
of if these have been exceeded. Export this information via
HWMON. Currently temperature, VCC, bias current, transmit power, and
possibly receiver power is supported.

The sensors in the modules can either return calibrate or uncalibrated
values. Uncalibrated values need to be manipulated, using coefficients
provided in the SFP EEPROM. Uncalibrated receive power values require
floating point maths in order to calibrate them. Performing this in
the kernel is hard. So if the SFP module indicates it uses
uncalibrated values, RX power is not made available.

With this hwmon device, it is possible to view the sensor values using
lm-sensors programs:

in0:          +3.29 V  (crit min =  +2.90 V, min =  +3.00 V)
                       (max =  +3.60 V, crit max =  +3.70 V)
temp1:        +33.0°C  (low  =  -5.0°C, high = +80.0°C)
                       (crit low = -10.0°C, crit = +85.0°C)
power1:      1000.00 nW (max = 794.00 uW, min =  50.00 uW)  ALARM (LCRIT)
                       (lcrit =  40.00 uW, crit = 1000.00 uW)
curr1:        +0.00 A  (crit min =  +0.00 A, min =  +0.00 A)  ALARM (LCRIT, MIN)
                       (max =  +0.01 A, crit max =  +0.01 A)

The scaling sensors performs on the bias current is not particularly
good. The raw values are more useful:

curr1:
  curr1_input: 0.000
  curr1_min: 0.002
  curr1_max: 0.010
  curr1_lcrit: 0.000
  curr1_crit: 0.011
  curr1_min_alarm: 1.000
  curr1_max_alarm: 0.000
  curr1_lcrit_alarm: 1.000
  curr1_crit_alarm: 0.000

In order to keep the I2C overhead to a minimum, the constant values,
such as limits and calibration coefficients are read once at module
insertion time. Thus only reading *_input and *_alarm properties
requires i2c read operations.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1323061a
  37. 23 6月, 2018 1 次提交
  39. 18 5月, 2018 1 次提交
  41. 16 5月, 2018 1 次提交
  43. 12 5月, 2018 1 次提交
  45. 11 5月, 2018 1 次提交
  47. 29 4月, 2018 1 次提交
    • F
      net: phy: Fix modular PHYLIB build · 9e8d438e
      由 Florian Fainelli 提交于 
      After commit c59530d0 ("net: Move PHY statistics code into PHY
library helpers") we made net/core/ethtool.c reference symbols which are
part of the library which can be modular. David introduced a temporary
fix with 1ecd6e8a ("phy: Temporary build fix after phylib changes.")
which would prevent such modularity.

This is not desireable of course, so instead, just inline the functions
into include/linux/phy.h to keep both options available.

Fixes: c59530d0 ("net: Move PHY statistics code into PHY library helpers")
Fixes: 1ecd6e8a ("phy: Temporary build fix after phylib changes.")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9e8d438e
  49. 28 4月, 2018 1 次提交
  51. 20 4月, 2018 1 次提交
  53. 08 11月, 2017 1 次提交
  55. 12 10月, 2017 1 次提交
  57. 10 10月, 2017 1 次提交
  59. 20 9月, 2017 1 次提交
  61. 02 9月, 2017 1 次提交
  63. 15 8月, 2017 1 次提交
  65. 12 8月, 2017 1 次提交
  67. 07 8月, 2017 3 次提交
    • 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
      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
  69. 28 7月, 2017 1 次提交
    • A
      net: phy: rework Kconfig settings for MDIO_BUS · 4c3464a8
      由 Arnd Bergmann 提交于 
      I still see build errors in randconfig builds and have had this
patch for a while to locally work around it:

drivers/built-in.o: In function `xgene_mdio_probe':
mux-core.c:(.text+0x352154): undefined reference to `of_mdiobus_register'
mux-core.c:(.text+0x352168): undefined reference to `mdiobus_free'
mux-core.c:(.text+0x3521c0): undefined reference to `mdiobus_alloc_size'

The idea is that CONFIG_MDIO_BUS now reflects whether the mdio_bus
code is built-in or a module, and other drivers that use the core
code can simply depend on that, instead of having a complex
dependency line.

Fixes: 90eff909 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c3464a8
  71. 14 6月, 2017 1 次提交
  73. 07 6月, 2017 1 次提交