14 Dec, 2020
1 commit
-
In .mdio_bus_phy_may_suspend(), there check netdev is NULL to judge to set
phy to suspend status.netdev is NULL has three cases:
- phy is not found
- phy is found, match to general phy driver
- phy is found, match to specifical phy driverCase 1: phy is not found, cannot communicate by MDIO bus.
Case 2: phy is found:
if phy dev driver probe/bind err, netdev is not __open__ status,
mdio bus is unregistered.
if phy is detached, phy had entered suspended status.
Case 3: phy is found, phy is detached, phy had entered suspended status.So, in here, it shouldn't set phy to suspend by calling mdio bus.
In i.MX6UL evk/arm2 board, if down the ethx interface and do
suspend/resume, system will hang. Because after ethx down all clocks are
gated off, for general phy driver, unbind the phy device, for specifical
phy driver, no unbind the device, and the original driver call mdio bus to
set phy to suspend during system suspend, so system will hang since there
have mdio register access.
The patch can fix it.Signed-off-by: Fugang Duan
18 Sep, 2020
1 commit
-
If we have unbound the PHY driver prior to calling phy_detach() (often
via phy_disconnect()) then we can cause a NULL pointer de-reference
accessing the driver owner member. The steps to reproduce are:echo unimac-mdio-0:01 > /sys/class/net/eth0/phydev/driver/unbind
ip link set eth0 downFixes: cafe8df8b9bc ("net: phy: Fix lack of reference count on PHY driver")
Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
11 Sep, 2020
1 commit
-
Since the micrel phy driver calls phy_init_hw() as a workaround,
the commit 9886a4dbd2aa ("net: phy: call phy_disable_interrupts()
in phy_init_hw()") disables the interrupt unexpectedly. So,
call phy_disable_interrupts() in phy_attach_direct() instead.
Otherwise, the phy cannot link up after the ethernet cable was
disconnected.Note that other drivers (like at803x.c) also calls phy_init_hw().
So, perhaps, the driver caused a similar issue too.Fixes: 9886a4dbd2aa ("net: phy: call phy_disable_interrupts() in phy_init_hw()")
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: David S. Miller
24 Aug, 2020
1 commit
-
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva
09 Aug, 2020
1 commit
-
A recent commit introduced a late error path in phy_device_create()
which fails to release the device name allocated by dev_set_name().Fixes: 13d0ab6750b2 ("net: phy: check return code when requesting PHY driver module")
Cc: Heiner Kallweit
Signed-off-by: Johan Hovold
Signed-off-by: David S. Miller
23 Jul, 2020
1 commit
-
After the patch below, the iteration through the available MMDs is
completely short-circuited, and devs_in_pkg remains set to the initial
value of zero.Due to devs_in_pkg being zero, the rest of get_phy_c45_ids() is
short-circuited too: the following loop never reaches below this point
either (it executes "continue" for every device in package, failing to
retrieve PHY ID for any of them):/* Now probe Device Identifiers for each device present. */
for (i = 1; i < num_ids; i++) {
if (!(devs_in_pkg & (1 << i)))
continue;So c45_ids->device_ids remains populated with zeroes. This causes an
Aquantia AQR412 PHY (same as any C45 PHY would, in fact) to be probed by
the Generic PHY driver.The issue seems to be a case of submitting partially committed work (and
therefore testing something other than was submitted).The intention of the patch was to delay exiting the loop until one more
condition is reached (the devs_in_pkg read from hardware is either 0, OR
mostly f's). So fix the patch to reflect that.Tested with traffic on a LS1028A-QDS, the PHY is now probed correctly
using the Aquantia driver. The devs_in_pkg bit field is set to
0xe000009a, and the MMDs that are present have the following IDs:[ 5.600772] libphy: get_phy_c45_ids: device_ids[1]=0x3a1b662
[ 5.618781] libphy: get_phy_c45_ids: device_ids[3]=0x3a1b662
[ 5.630797] libphy: get_phy_c45_ids: device_ids[4]=0x3a1b662
[ 5.654535] libphy: get_phy_c45_ids: device_ids[7]=0x3a1b662
[ 5.791723] libphy: get_phy_c45_ids: device_ids[29]=0x3a1b662
[ 5.804050] libphy: get_phy_c45_ids: device_ids[30]=0x3a1b662
[ 5.816375] libphy: get_phy_c45_ids: device_ids[31]=0x0[ 7.690237] mscc_felix 0000:00:00.5: PHY [0.5:00] driver [Aquantia AQR412] (irq=POLL)
[ 7.704739] mscc_felix 0000:00:00.5: PHY [0.5:01] driver [Aquantia AQR412] (irq=POLL)
[ 7.718918] mscc_felix 0000:00:00.5: PHY [0.5:02] driver [Aquantia AQR412] (irq=POLL)
[ 7.733044] mscc_felix 0000:00:00.5: PHY [0.5:03] driver [Aquantia AQR412] (irq=POLL)Fixes: bba238ed037c ("net: phy: continue searching for C45 MMDs even if first returned ffff:ffff")
Reported-by: Colin King
Reported-by: Ioana Ciornei
Signed-off-by: Vladimir Oltean
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
18 Jul, 2020
1 commit
-
At the time of introduction, in commit bdeced75b13f ("net: dsa: felix:
Add PCS operations for PHYLINK"), support for the Lynx PCS inside Felix
was relying, for USXGMII support, on the fact that get_phy_device() is
able to parse the Lynx PCS "device-in-package" registers for this C45
MDIO device and identify it correctly.However, this was actually working somewhat by mistake (in the sense
that, even though it was detected, it was detected for the wrong
reasons).The get_phy_c45_ids() function works by iterating through all MMDs
starting from 1 (MDIO_MMD_PMAPMD) and stops at the first one which
returns a non-zero value in the "device-in-package" register pair,
proceeding to see what that non-zero value is.For the Felix PCS, the first MMD (1, for the PMA/PMD) returns a non-zero
value of 0xffffffff in the "device-in-package" registers. There is a
code branch which is supposed to treat this case and flag it as wrong,
and normally, this would have caught my attention when adding initial
support for this PCS:if ((devs_in_pkg & 0x1fffffff) == 0x1fffffff) {
/* If mostly Fs, there is no device there, then let's probe
* MMD 0, as some 10G PHYs have zero Devices In package,
* e.g. Cortina CS4315/CS4340 PHY.
*/However, this code never actually kicked in, it seems, because this
snippet from get_phy_c45_devs_in_pkg() was basically sabotaging itself,
by returning 0xfffffffe instead of 0xffffffff:/* Bit 0 doesn't represent a device, it indicates c22 regs presence */
*devices_in_package &= ~BIT(0);Then the rest of the code just carried on thinking "ok, MMD 1 (PMA/PMD)
says that there are 31 devices in that package, each having a device id
of ffff:ffff, that's perfectly fine, let's go ahead and probe this PHY
device".But after cleanup commit 320ed3bf9000 ("net: phy: split
devices_in_package"), this got "fixed", and now devs_in_pkg is no longer
0xfffffffe, but 0xffffffff. So now, get_phy_device is returning -ENODEV
for the Lynx PCS, because the semantics have remained mostly unchanged:
the loop stops at the first MMD that returns a non-zero value, and that
is MMD 1.But the Lynx PCS is simply a clause 37 PCS which implements the required
MAC-side functionality for USXGMII (when operated in C45 mode, which is
where C45 devices-in-package detection is relevant to). Of course it
will fail the PMD/PMA test (MMD 1), since it is not a PHY. But it does
implement detection for MDIO_MMD_PCS (3):- MDIO_DEVS1=0x008a, MDIO_DEVS2=0x0000,
- MDIO_DEVID1=0x0083, MDIO_DEVID2=0xe400Let get_phy_c45_ids() continue searching for valid MMDs, and don't
assume that every phy_device has a PMA/PMD MMD implemented.Signed-off-by: Vladimir Oltean
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
09 Jul, 2020
1 commit
-
Extend ethtool_phy_ops to include the 3 function pointers necessary for
implementing PHY statistics. In a subsequent change we will uninline
those functions.Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
08 Jul, 2020
3 commits
-
Utilize ethtool_set_ethtool_phy_ops to register a suitable set of PHY
ethtool operations in a dynamic fashion such that ethtool will no longer
directy reference PHY library symbols.Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller -
This array is not used outside of phy_device.c, so make it static.
Reviewed-by: Florian Fainelli
Signed-off-by: Andrew Lunn
Signed-off-by: David S. Miller -
Avoid the W=1 warning that symbol 'genphy_c45_driver' was not
declared. Should it be static?Declare it on the phy header file.
Reviewed-by: Florian Fainelli
Signed-off-by: Andrew Lunn
Signed-off-by: David S. Miller
27 Jun, 2020
2 commits
-
Currently we only call phy_device_reset() if the PHY driver implements
the probe() callback. This is not mandatory and many drivers (e.g.
realtek) don't need probe() for most devices but still can have reset
GPIOs defined. There's no reason to depend on the presence of probe()
here so pull the reset code out of the if clause.Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
Keeping the headers in alphabetical order is better for readability and
allows to easily see if given header is already included.Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
26 Jun, 2020
2 commits
-
Minor overlapping changes in xfrm_device.c, between the double
ESP trailing bug fix setting the XFRM_INIT flag and the changes
in net-next preparing for bonding encryption support.Signed-off-by: David S. Miller
-
Add a helper function that will return the index in the array for the
passed in internal delay value. The helper requires the array, size and
delay value.The helper will then return the index for the exact match or return the
index for the index to the closest smaller value.Signed-off-by: Dan Murphy
Signed-off-by: David S. Miller
25 Jun, 2020
1 commit
-
Call phy_disable_interrupts() in phy_init_hw() to "have a defined init
state as we don't know in which state the PHY is if the PHY driver is
loaded. We shouldn't assume that it's the chip power-on defaults, BIOS
or boot loader could have changed this. Or in case of dual-boot
systems the other OS could leave the PHY in whatever state." as pointed
out by Heiner.Suggested-by: Heiner Kallweit
Signed-off-by: Jisheng Zhang
Signed-off-by: David S. Miller
20 Jun, 2020
10 commits
-
Expand the device_ids[] array to allow all MMD IDs to be read rather
than just the first 8 MMDs, but only read the ID if the MDIO_STAT2
register reports that a device really is present here for these new
devices to maintain compatibility with our current behaviour. Note
that only a limited number of devices have MDIO_STAT2.88X3310 PHY vendor MMDs do are marked as present in the
devices_in_package, but do not contain IEE 802.3 compatible register
sets in their lower space. This avoids reading incorrect values as MMD
identifiers.Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
We have two competing requirements for the devices_in_package field.
We want to use it as a bit array indicating which MMDs are present, but
we also want to know if the Clause 22 registers are present.Since "devices in package" is a term used in the 802.3 specification,
keep this as the as-specified values read from the PHY, and introduce
a new member "mmds_present" to indicate which MMDs are actually
present in the PHY, derived from the "devices in package" value.Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Only set the devices_in_package to a non-zero value if we find a valid
value for this field, so we avoid leaving it set to e.g. 0x1fffffff.Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Add support for probing MMDs above 7 for a valid devices-in-package
specifier, but only probe the vendor MMDs for this if they also report
that there the device is present in status register 2. This avoids
issues where the MMD is implemented, but does not provide IEEE 802.3
compliant registers (such as the MV88X3310 PHY.)Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Reword the get_phy_device() kerneldoc to be more explicit about how
we probe for the PHY, and what the various return conditions signify.Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Move the ID check from get_phy_device() into get_phy_c22_id(), which
simplifies get_phy_device(). The ID reading functions are now
responsible for indicating whether they found a PHY or not via their
return code - they must return -ENODEV when a PHY is not present.Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
When we decide that a PHY is not present, we do not need to go through
the hoops of setting *phy_id to 0xffffffff, and then return zero to
make get_phy_device() fail - we can return -ENODEV which will have the
same effect.Doing so means we no longer have to pass a pointer to phy_id in, and
we can then clean up the clause 22 path in a similar way.Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Rearrange the code to read the PHY IDs, so we don't call get_phy_id()
only to immediately call get_phy_c45_ids(). Move that logic into
get_phy_device(), which results in better readability.Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Move the Cortina PHY workaround out of the "devices in package" loop;
it doesn't need to be in there as the control flow will terminate the
loop once we enter the workaround irrespective of the workaround's
outcome. The workaround is triggered by the ID being mostly 1's, which
will in any case terminate the loop.Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Commit 02a6efcab675 ("net: phy: allow scanning busses with missing
phys") added a special condition to return -ENODEV in case -ENODEV or
-EIO was returned from the first read of the MII_PHYSID1 register.In case the MDIO bus data line pull-up is not strong enough, the MDIO
bus controller will not flag this as a read error. This can happen when
a pluggable daughter card is not connected and weak internal pull-ups
are used (since that is the only option, otherwise the pins are
floating).The second read of MII_PHYSID2 will be correctly flagged an error
though, but now we will return -EIO which will be treated as a hard
error, thus preventing MDIO bus scanning loops to continue succesfully.Apply the same logic to both register reads, thus allowing the scanning
logic to proceed.Fixes: 02a6efcab675 ("net: phy: allow scanning busses with missing phys")
Reviewed-by: Andrew Lunn
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
27 May, 2020
1 commit
-
There is a recurring pattern throughout some of the PHY code converting
a devad and regnum to our packed clause 45 representation. Rather than
having this scattered around the code, let's put a common translation
function in mdio.h, and provide some register accessors.Convert the phylib core, phylink, bcm87xx and cortina to use these.
Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
25 May, 2020
1 commit
-
The MSCC bug fix in 'net' had to be slightly adjusted because the
register accesses are done slightly differently in net-next.Signed-off-by: David S. Miller
19 May, 2020
1 commit
-
This function was introduced to allow for different handling of
link up and link down events particularly with regard to the
netif_carrier. The third argument do_carrier allowed the flag to
be left unchanged.Since then the phylink has introduced an implementation that
completely ignores the third parameter since it never wants to
change the flag and the phylib always sets the third parameter
to true so the flag is always changed.Therefore the third argument (i.e. do_carrier) is no longer
necessary and can be removed. This also means that the phylib
phy_link_down() function no longer needs its second argument.Signed-off-by: Doug Berger
Signed-off-by: David S. Miller
18 May, 2020
1 commit
-
The compilation warning below reveals that the errors returned from
the sfp_bus_add_upstream() call are not propagated to the callers.
Fix it by returning "ret".14:37:51 drivers/net/phy/phy_device.c: In function 'phy_sfp_probe':
14:37:51 drivers/net/phy/phy_device.c:1236:6: warning: variable 'ret'
set but not used [-Wunused-but-set-variable]
14:37:51 1236 | int ret;
14:37:51 | ^~~Fixes: 298e54fa810e ("net: phy: add core phylib sfp support")
Signed-off-by: Leon Romanovsky
Signed-off-by: David S. Miller
08 May, 2020
1 commit
-
The unsigned variable val is being checked for an error by checking
if it is less than zero. This can never occur because val is unsigned.
Fix this by making val a plain int.Addresses-Coverity: ("Unsigned compared against zero")
Fixes: bdbdac7649fa ("ethtool: provide UAPI for PHY master/slave configuration.")
Signed-off-by: Colin Ian King
Signed-off-by: David S. Miller
07 May, 2020
2 commits
-
This UAPI is needed for BroadR-Reach 100BASE-T1 devices. Due to lack of
auto-negotiation support, we needed to be able to configure the
MASTER-SLAVE role of the port manually or from an application in user
space.The same UAPI can be used for 1000BASE-T or MultiGBASE-T devices to
force MASTER or SLAVE role. See IEEE 802.3-2018:
22.2.4.3.7 MASTER-SLAVE control register (Register 9)
22.2.4.3.8 MASTER-SLAVE status register (Register 10)
40.5.2 MASTER-SLAVE configuration resolution
45.2.1.185.1 MASTER-SLAVE config value (1.2100.14)
45.2.7.10 MultiGBASE-T AN control 1 register (Register 7.32)The MASTER-SLAVE role affects the clock configuration:
-------------------------------------------------------------------------------
When the PHY is configured as MASTER, the PMA Transmit function shall
source TX_TCLK from a local clock source. When configured as SLAVE, the
PMA Transmit function shall source TX_TCLK from the clock recovered from
data stream provided by MASTER.iMX6Q KSZ9031 XXX
------\ /-----------\ /------------\
| | | | |
MAC || PHY Slave || PHY Master |
|
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
There are packages which contain multiple PHY devices, eg. a quad PHY
transceiver. Provide functions to allocate and free shared storage.Usually, a quad PHY contains global registers, which don't belong to any
PHY. Provide convenience functions to access these registers.Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
25 Apr, 2020
3 commits
-
If a soft reset is triggered whilst PHY is in power-down, then
phydev->suspended will remain set. Seems we didn't face any issue yet
caused by this, but better reset the suspended flag after soft reset.See also the following from 22.2.4.1.1
Resetting a PHY is accomplished by setting bit 0.15 to a logic one.
This action shall set the status and control registers to their default
states.Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller -
Since 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
we don't need genphy_no_soft_reset() any longer. Not setting
callback soft_reset results in a no-op now.Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller -
Gently handle the case that phy_suspend() is called whilst PHY is in
power-down.Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller
27 Mar, 2020
2 commits
-
So far we set phydev->suspended to true in phy_suspend() even if the
PHY driver doesn't implement the suspend callback. This applies
accordingly for the resume path. The current behavior doesn't cause
any issue I'd be aware of, but it's not logical and misleading,
especially considering the description of the flag:
"suspended: Set to true if this phy has been suspended successfully"Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
If we have scenarios like
mdiobus_register()
-> loads PHY driver module(s)
-> registers PHY driver(s)
-> may schedule async probe
phydev = mdiobus_get_phy()or
phydev = phy_device_create()
-> loads PHY driver module
-> registers PHY driver
-> may schedule async probethen we expect the PHY driver to be bound to the phydev when triggering
the action. This may not be the case in case of asynchronous probing.
Therefore ensure that PHY drivers are probed synchronously.Default still is sync probing, except async probing is explicitly
requested. I saw some comments that the intention is to promote
async probing for more parallelism in boot process and want to be
prepared for the case that the default is changed to async probing.Signed-off-by: Heiner Kallweit
Reviewed-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
24 Mar, 2020
1 commit
-
use phy_read_poll_timeout() to replace the poll codes for
simplify the code in phy_poll_reset() function.Reviewed-by: Andrew Lunn
Signed-off-by: Dejin Zheng
Signed-off-by: David S. Miller
13 Mar, 2020
1 commit
-
Minor overlapping changes, nothing serious.
Signed-off-by: David S. Miller