kernel/drivers/net/phy/Kconfig, branch linux-5.1.y

net: phy: rename Asix Electronics PHY driver

2019-07-14T06:09:39Z

[ Upstream commit a9520543b123bbd7275a0ab8d0375a5412683b41 ] [Resent to net instead of net-next - may clash with Anders Roxell's patch series addressing duplicate module names] Commit 31dd83b96641 ("net-next: phy: new Asix Electronics PHY driver") introduced a new PHY driver drivers/net/phy/asix.c that causes a module name conflict with a pre-existiting driver (drivers/net/usb/asix.c). The PHY driver is used by the X-Surf 100 ethernet card driver, and loaded by that driver via its PHY ID. A rename of the driver looks unproblematic. Rename PHY driver to ax88796b.c in order to resolve name conflict. Signed-off-by: Michael Schmitz Tested-by: Michael Schmitz Fixes: 31dd83b96641 ("net-next: phy: new Asix Electronics PHY driver") Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: phy: Re-parent menus for MDIO bus drivers correctly

2019-03-24T00:55:21Z

After 90eff9096c01 ("net: phy: Allow splitting MDIO bus/device support from PHYs") the various MDIO bus drivers were no longer parented with config PHYLIB but with config MDIO_BUS which is not a menuconfig, fix this by depending on MDIO_DEVICE which is a menuconfig. This is visually nicer and less confusing for users. Fixes: 90eff9096c01 ("net: phy: Allow splitting MDIO bus/device support from PHYs") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller

phy: mdio-mux: fix Kconfig dependencies

2019-03-04T21:12:48Z

MDIO_BUS_MUX can only be selected if OF_MDIO is already turned on: WARNING: unmet direct dependencies detected for MDIO_BUS_MUX Depends on [n]: NETDEVICES [=y] && MDIO_BUS [=m] && OF_MDIO [=n] Selected by [m]: - MDIO_BUS_MUX_MULTIPLEXER [=m] && NETDEVICES [=y] && MDIO_BUS [=m] && OF [=y] Fixes: 7865ad6551c9 ("drivers: net: phy: mdio-mux: Add support for Generic Mux controls") Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller

drivers: net: phy: mdio-mux: Add support for Generic Mux controls

2019-02-27T20:52:20Z

Add support for Generic Mux controls, when Mdio mux node is a consumer of mux produced by some other device. Signed-off-by: Pankaj Bansal Signed-off-by: David S. Miller

net: phy: bcm63xx: Allow to be built with COMPILE_TEST

2018-09-13T03:24:20Z

There is nothing in this driver which prevents it to be compiled for other architectures. Add COMPILE_TEST so we get better compile test coverage. Signed-off-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller

net: phy: sfp: Do not use "imply HWMON"

2018-07-22T02:26:54Z

"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: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Cc: Andrew Lunn Signed-off-by: Guenter Roeck Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

net: phy: Drop OF dependency for MDIO_BCM_UNIMAC

2018-07-18T20:53:47Z

The driver builds fine even with CONFIG_OF=n since we now have stubs that are provided. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller

net: phy: sfp: Add HWMON support for module sensors

2018-07-18T01:02:02Z

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: Andrew Lunn Acked-by: Guenter Roeck Signed-off-by: David S. Miller

net: phy: Allow compile test of GPIO consumers if !GPIOLIB

2018-06-23T01:33:56Z

The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer functionality only, can still be compiled if GPIOLIB is not enabled. Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where appropriate. Signed-off-by: Geert Uytterhoeven Acked-by: Linus Walleij Signed-off-by: David S. Miller

net: phy: Allow MDIO_MOXART and MDIO_SUN4I with COMPILE_TEST

2018-05-17T21:11:06Z

Those drivers build just fine with COMPILE_TEST, so make that possible. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller