2019-01-21 19:05:50 +01:00
|
|
|
|
2014-01-05 03:17:06 +03:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-28 22:42:14 -07:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2012-06-09 07:49:07 +00:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:36 +02:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2017-01-25 11:39:49 +01:00
|
|
|
|
2019-11-15 19:56:51 +00:00
|
|
|
|
2006-10-03 16:18:35 +01:00
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
2014-01-05 03:17:06 +03:00
|
|
|
|
|
|
|
|
|
2011-07-26 16:09:06 -07:00
|
|
|
|
2022-06-28 12:15:08 +02:00
|
|
|
|
2020-05-10 21:12:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-05 03:17:06 +03:00
|
|
|
|
2025-02-22 09:36:10 +01:00
|
|
|
|
2025-03-07 18:36:00 +01:00
|
|
|
|
2025-02-22 09:36:10 +01:00
|
|
|
|
2019-05-30 15:11:06 +02:00
|
|
|
|
|
|
|
|
|
2015-05-16 10:17:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
2015-05-16 10:17:56 -07:00
|
|
|
|
2023-05-22 16:58:08 +01:00
|
|
|
|
2015-05-16 10:17:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-16 13:33:24 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
|
|
|
|
|
2020-05-18 15:23:59 -07:00
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-18 15:23:59 -07:00
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
2020-05-18 15:23:59 -07:00
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
2022-11-04 12:01:25 -07:00
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
2015-05-16 10:17:56 -07:00
|
|
|
|
2019-05-05 19:03:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-05 03:17:06 +03:00
|
|
|
|
2014-02-11 17:27:34 -08:00
|
|
|
|
2020-03-20 17:51:38 +01:00
|
|
|
|
2014-02-11 17:27:35 -08:00
|
|
|
|
2017-07-25 15:02:42 +01:00
|
|
|
|
2020-03-20 17:51:38 +01:00
|
|
|
|
2019-05-05 19:03:51 +02:00
|
|
|
|
2014-01-05 03:17:06 +03:00
|
|
|
|
2014-02-11 17:27:33 -08:00
|
|
|
|
2014-01-05 03:17:06 +03:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
net: phy: Add support for rate matching
This adds support for rate matching (also known as rate adaptation) to
the phy subsystem. The general idea is that the phy interface runs at
one speed, and the MAC throttles the rate at which it sends packets to
the link speed. There's a good overview of several techniques for
achieving this at [1]. This patch adds support for three: pause-frame
based (such as in Aquantia phys), CRS-based (such as in 10PASS-TS and
2BASE-TL), and open-loop-based (such as in 10GBASE-W).
This patch makes a few assumptions and a few non assumptions about the
types of rate matching available. First, it assumes that different phys
may use different forms of rate matching. Second, it assumes that phys
can use rate matching for any of their supported link speeds (e.g. if a
phy supports 10BASE-T and XGMII, then it can adapt XGMII to 10BASE-T).
Third, it does not assume that all interface modes will use the same
form of rate matching. Fourth, it does not assume that all phy devices
will support rate matching (even if some do). Relaxing or strengthening
these (non-)assumptions could result in a different API. For example, if
all interface modes were assumed to use the same form of rate matching,
then a bitmask of interface modes supportting rate matching would
suffice.
For some better visibility into the process, the current rate matching
mode is exposed as part of the ethtool ksettings. For the moment, only
read access is supported. I'm not sure what userspace might want to
configure yet (disable it altogether, disable just one mode, specify the
mode to use, etc.). For the moment, since only pause-based rate
adaptation support is added in the next few commits, rate matching can
be disabled altogether by adjusting the advertisement.
802.3 calls this feature "rate adaptation" in clause 49 (10GBASE-R) and
"rate matching" in clause 61 (10PASS-TL and 2BASE-TS). Aquantia also calls
this feature "rate adaptation". I chose "rate matching" because it is
shorter, and because Russell doesn't think "adaptation" is correct in this
context.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-20 18:12:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-11 17:27:38 -08:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2018-11-09 18:35:52 +01:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2018-11-09 18:35:52 +01:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2014-01-05 03:21:52 +03:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2014-01-05 03:21:52 +03:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
2017-06-05 12:23:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2014-02-11 17:27:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2016-11-10 17:10:46 -06:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2017-02-23 14:22:19 -08:00
|
|
|
|
2014-02-11 17:27:37 -08:00
|
|
|
|
2019-03-02 17:10:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2016-11-10 17:10:46 -06:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2016-10-17 10:49:54 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-07 18:36:00 +01:00
|
|
|
|
2016-10-17 10:49:54 -05:00
|
|
|
|
|
|
|
|
|
2015-02-17 09:36:22 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-11 08:41:08 +01:00
|
|
|
|
2015-02-17 09:36:22 -08:00
|
|
|
|
2025-03-07 18:36:02 +01:00
|
|
|
|
2015-02-17 09:36:22 -08:00
|
|
|
|
2023-02-11 08:41:08 +01:00
|
|
|
|
2015-02-17 09:36:22 -08:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2010-10-21 08:37:41 +00:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
net: phy: phy_caps: Allow looking-up link caps based on speed and duplex
As the link_caps array is efficient for <speed,duplex> lookups,
implement a function for speed/duplex lookups that matches a given
mask. This replicates to some extent the phy_lookup_settings()
behaviour, matching full link_capabilities instead of a single linkmode.
phy.c's phy_santize_settings() and phylink's
phylink_ethtool_ksettings_set() performs such lookup using the
phy_settings table, but are only interested in the actual speed/duplex
that were matched, rathet than the individual linkmode.
Similar to phy_lookup_settings(), the newly introduced phy_caps_lookup()
will run through the link_caps[] array by descending speed/duplex order.
If the link_capabilities for a given <speed/duplex> tuple intersects the
passed linkmodes, we consider that a match.
Similar to phy_lookup_settings(), we also allow passing an 'exact'
boolean, allowing non-exact match. Here, we MUST always match the
linkmodes mask, but we allow matching on lower speed settings.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20250307173611.129125-8-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-07 18:36:04 +01:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
net: phy: phy_caps: Allow looking-up link caps based on speed and duplex
As the link_caps array is efficient for <speed,duplex> lookups,
implement a function for speed/duplex lookups that matches a given
mask. This replicates to some extent the phy_lookup_settings()
behaviour, matching full link_capabilities instead of a single linkmode.
phy.c's phy_santize_settings() and phylink's
phylink_ethtool_ksettings_set() performs such lookup using the
phy_settings table, but are only interested in the actual speed/duplex
that were matched, rathet than the individual linkmode.
Similar to phy_lookup_settings(), the newly introduced phy_caps_lookup()
will run through the link_caps[] array by descending speed/duplex order.
If the link_capabilities for a given <speed/duplex> tuple intersects the
passed linkmodes, we consider that a match.
Similar to phy_lookup_settings(), we also allow passing an 'exact'
boolean, allowing non-exact match. Here, we MUST always match the
linkmodes mask, but we allow matching on lower speed settings.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20250307173611.129125-8-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-07 18:36:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: phy: improve phylib correctness for non-autoneg settings
phylib has some undesirable behaviour when forcing a link mode through
ethtool. phylib uses this code:
idx = phy_find_valid(phy_find_setting(phydev->speed, phydev->duplex),
features);
to find an index in the settings table. phy_find_setting() starts at
index 0, and scans upwards looking for an exact speed and duplex match.
When it doesn't find it, it returns MAX_NUM_SETTINGS - 1, which is
10baseT-Half duplex.
phy_find_valid() then scans from the point (and effectively only checks
one entry) before bailing out, returning MAX_NUM_SETTINGS - 1.
phy_sanitize_settings() then sets ->speed to SPEED_10 and ->duplex to
DUPLEX_HALF whether or not 10baseT-Half is supported or not. This goes
against all the comments against these functions, and 10baseT-Half may
not even be supported by the hardware.
Rework these functions, introducing a new method of scanning the table.
There are two modes of lookup that phylib wants: exact, and inexact.
- in exact mode, we return either an exact match or failure
- in inexact mode, we return an exact match if it exists, a match at
the highest speed that is not greater than the requested speed
(ignoring duplex), or failing that, the lowest supported speed, or
failure.
The biggest difference is that we always check whether the entry is
supported before further consideration, so all unsupported entries are
not considered as candidates.
This results in arguably saner behaviour, better matches the comments,
and is probably what users would expect.
This becomes important as ethernet speeds increase, PHYs exist which do
not support the 10Mbit speeds, and half-duplex is likely to become
obsolete - it's already not even an option on 10Gbit and faster links.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-13 16:49:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
2017-06-13 10:09:46 +03:00
|
|
|
|
|
|
|
|
|
2016-04-15 00:35:00 +02:00
|
|
|
|
2021-10-24 21:48:02 +02:00
|
|
|
|
2018-11-10 23:43:33 +01:00
|
|
|
|
|
|
|
|
|
2018-11-10 23:43:34 +01:00
|
|
|
|
2016-04-15 00:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-05 08:35:05 +02:00
|
|
|
|
|
|
|
|
|
net: phy: Add support for rate matching
This adds support for rate matching (also known as rate adaptation) to
the phy subsystem. The general idea is that the phy interface runs at
one speed, and the MAC throttles the rate at which it sends packets to
the link speed. There's a good overview of several techniques for
achieving this at [1]. This patch adds support for three: pause-frame
based (such as in Aquantia phys), CRS-based (such as in 10PASS-TS and
2BASE-TL), and open-loop-based (such as in 10GBASE-W).
This patch makes a few assumptions and a few non assumptions about the
types of rate matching available. First, it assumes that different phys
may use different forms of rate matching. Second, it assumes that phys
can use rate matching for any of their supported link speeds (e.g. if a
phy supports 10BASE-T and XGMII, then it can adapt XGMII to 10BASE-T).
Third, it does not assume that all interface modes will use the same
form of rate matching. Fourth, it does not assume that all phy devices
will support rate matching (even if some do). Relaxing or strengthening
these (non-)assumptions could result in a different API. For example, if
all interface modes were assumed to use the same form of rate matching,
then a bitmask of interface modes supportting rate matching would
suffice.
For some better visibility into the process, the current rate matching
mode is exposed as part of the ethtool ksettings. For the moment, only
read access is supported. I'm not sure what userspace might want to
configure yet (disable it altogether, disable just one mode, specify the
mode to use, etc.). For the moment, since only pause-based rate
adaptation support is added in the next few commits, rate matching can
be disabled altogether by adjusting the advertisement.
802.3 calls this feature "rate adaptation" in clause 49 (10GBASE-R) and
"rate matching" in clause 61 (10PASS-TL and 2BASE-TS). Aquantia also calls
this feature "rate adaptation". I chose "rate matching" because it is
shorter, and because Russell doesn't think "adaptation" is correct in this
context.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-20 18:12:31 -04:00
|
|
|
|
2016-04-15 00:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-09 17:38:52 +01:00
|
|
|
|
2025-02-13 22:51:53 +01:00
|
|
|
|
2017-09-20 15:52:14 -07:00
|
|
|
|
2016-04-15 00:35:00 +02:00
|
|
|
|
|
|
|
|
|
2016-11-29 15:16:47 +05:30
|
|
|
|
|
|
|
|
|
2021-10-24 21:48:02 +02:00
|
|
|
|
2016-04-15 00:35:00 +02:00
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-09 13:41:59 +00:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2014-01-05 03:17:06 +03:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2010-07-17 08:48:55 +00:00
|
|
|
|
2023-11-14 12:28:29 +01:00
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2014-11-11 13:39:39 -07:00
|
|
|
|
2023-11-14 12:28:29 +01:00
|
|
|
|
2019-05-28 10:57:29 +01:00
|
|
|
|
2023-11-14 12:28:29 +01:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-06 20:11:16 +01:00
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2008-09-18 03:06:52 +00:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2019-05-28 10:57:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-03 19:15:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-28 10:57:29 +01:00
|
|
|
|
2024-09-03 19:15:36 +02:00
|
|
|
|
|
|
|
|
|
2019-05-28 10:57:29 +01:00
|
|
|
|
2024-09-03 19:15:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-05 03:21:52 +03:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
2019-05-28 10:57:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2014-11-11 13:39:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2014-11-11 13:39:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-16 18:01:23 +08:00
|
|
|
|
2014-11-11 13:39:39 -07:00
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2014-11-11 13:39:39 -07:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
2018-12-05 21:49:45 +01:00
|
|
|
|
|
|
|
|
|
2014-11-11 13:39:39 -07:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2019-10-04 17:05:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-30 19:30:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-10 06:52:13 +00:00
|
|
|
|
2019-05-28 10:57:29 +01:00
|
|
|
|
|
|
|
|
|
2013-12-06 13:01:31 -08:00
|
|
|
|
2014-01-05 03:21:52 +03:00
|
|
|
|
2014-11-11 13:39:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-05 03:21:52 +03:00
|
|
|
|
2007-11-28 19:56:34 +00:00
|
|
|
|
2010-07-17 08:49:36 +00:00
|
|
|
|
2025-11-24 18:11:45 +00:00
|
|
|
|
2023-11-14 12:28:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-24 18:11:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 12:28:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2010-07-17 08:49:36 +00:00
|
|
|
|
2007-11-28 19:56:34 +00:00
|
|
|
|
2008-09-18 03:06:52 +00:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
2007-09-17 22:21:40 +02:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2020-01-19 14:31:55 +01:00
|
|
|
|
2021-07-27 15:45:13 +02:00
|
|
|
|
2020-01-19 14:31:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-20 22:17:11 +01:00
|
|
|
|
2020-01-19 14:31:55 +01:00
|
|
|
|
2020-01-20 22:17:11 +01:00
|
|
|
|
2020-01-19 14:31:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-20 22:17:11 +01:00
|
|
|
|
|
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
2021-07-27 15:45:13 +02:00
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-20 22:17:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-20 22:16:07 +01:00
|
|
|
|
2020-01-19 14:31:55 +01:00
|
|
|
|
2023-08-01 17:28:23 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-24 18:11:46 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 12:28:30 +01:00
|
|
|
|
2023-08-01 17:28:23 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-24 18:11:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 12:28:30 +01:00
|
|
|
|
|
|
|
|
|
2023-08-01 17:28:23 +03:00
|
|
|
|
|
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-13 22:50:02 +01:00
|
|
|
|
|
|
|
|
|
2018-11-07 08:15:58 +01:00
|
|
|
|
|
|
|
|
|
2019-05-30 15:11:06 +02:00
|
|
|
|
2018-11-07 08:15:58 +01:00
|
|
|
|
|
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
2020-11-16 11:17:57 +01:00
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-01 14:50:56 +02:00
|
|
|
|
2018-11-07 08:15:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-01 14:50:56 +02:00
|
|
|
|
2018-11-07 08:15:58 +01:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:36 +02:00
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-08 09:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-08 09:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-08 09:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 07:05:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-09 18:00:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2023-01-09 18:00:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:39 +02:00
|
|
|
|
2020-05-10 21:12:36 +02:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-27 00:21:38 +02:00
|
|
|
|
2020-05-10 21:12:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
2020-05-18 15:23:59 -07:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
2020-05-10 21:12:39 +02:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:39 +02:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
2020-05-10 21:12:36 +02:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:32 +02:00
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-27 00:21:38 +02:00
|
|
|
|
2020-05-27 00:21:41 +02:00
|
|
|
|
|
|
|
|
|
2020-05-27 00:21:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-27 00:21:41 +02:00
|
|
|
|
2020-05-27 00:21:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-19 15:01:02 +02:00
|
|
|
|
2018-07-12 21:31:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-23 18:06:15 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-21 11:00:46 +00:00
|
|
|
|
2018-07-23 18:06:15 +03:00
|
|
|
|
|
|
|
|
|
2018-07-12 21:31:54 +02:00
|
|
|
|
2021-04-19 15:01:02 +02:00
|
|
|
|
2018-07-12 21:31:54 +02:00
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-06 14:03:40 +01:00
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
2019-09-05 13:43:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-20 17:51:38 +01:00
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
2025-02-16 22:20:07 +01:00
|
|
|
|
2024-11-23 14:50:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-02 20:53:03 +01:00
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-23 14:50:12 +00:00
|
|
|
|
2024-03-02 20:53:01 +01:00
|
|
|
|
2020-05-18 15:23:59 -07:00
|
|
|
|
2018-11-07 20:45:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-03 15:31:02 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-03 15:31:18 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem description
===================
Lockdep reports a possible circular locking dependency (AB/BA) between
&pl->state_mutex and &phy->lock, as follows.
phylink_resolve() // acquires &pl->state_mutex
-> phylink_major_config()
-> phy_config_inband() // acquires &pl->phydev->lock
whereas all the other call sites where &pl->state_mutex and
&pl->phydev->lock have the locking scheme reversed. Everywhere else,
&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at
the lower level. A clear example is phylink_bringup_phy().
The outlier is the newly introduced phy_config_inband() and the existing
lock order is the correct one. To understand why it cannot be the other
way around, it is sufficient to consider phylink_phy_change(), phylink's
callback from the PHY device's phy->phy_link_change() virtual method,
invoked by the PHY state machine.
phy_link_up() and phy_link_down(), the (indirect) callers of
phylink_phy_change(), are called with &phydev->lock acquired.
Then phylink_phy_change() acquires its own &pl->state_mutex, to
serialize changes made to its pl->phy_state and pl->link_config.
So all other instances of &pl->state_mutex and &phydev->lock must be
consistent with this order.
Problem impact
==============
I think the kernel runs a serious deadlock risk if an existing
phylink_resolve() thread, which results in a phy_config_inband() call,
is concurrent with a phy_link_up() or phy_link_down() call, which will
deadlock on &pl->state_mutex in phylink_phy_change(). Practically
speaking, the impact may be limited by the slow speed of the medium
auto-negotiation protocol, which makes it unlikely for the current state
to still be unresolved when a new one is detected, but I think the
problem is there. Nonetheless, the problem was discovered using lockdep.
Proposed solution
=================
Practically speaking, the phy_config_inband() requirement of having
phydev->lock acquired must transfer to the caller (phylink is the only
caller). There, it must bubble up until immediately before
&pl->state_mutex is acquired, for the cases where that takes place.
Solution details, considerations, notes
=======================================
This is the phy_config_inband() call graph:
sfp_upstream_ops :: connect_phy()
|
v
phylink_sfp_connect_phy()
|
v
phylink_sfp_config_phy()
|
| sfp_upstream_ops :: module_insert()
| |
| v
| phylink_sfp_module_insert()
| |
| | sfp_upstream_ops :: module_start()
| | |
| | v
| | phylink_sfp_module_start()
| | |
| v v
| phylink_sfp_config_optical()
phylink_start() | |
| phylink_resume() v v
| | phylink_sfp_set_config()
| | |
v v v
phylink_mac_initial_config()
| phylink_resolve()
| | phylink_ethtool_ksettings_set()
v v v
phylink_major_config()
|
v
phy_config_inband()
phylink_major_config() caller #1, phylink_mac_initial_config(), does not
acquire &pl->state_mutex nor do its callers. It must acquire
&pl->phydev->lock prior to calling phylink_major_config().
phylink_major_config() caller #2, phylink_resolve() acquires
&pl->state_mutex, thus also needs to acquire &pl->phydev->lock.
phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is
completely uninteresting, because it only calls phylink_major_config()
if pl->phydev is NULL (otherwise it calls phy_ethtool_ksettings_set()).
We need to change nothing there.
Other solutions
===============
The lock inversion between &pl->state_mutex and &pl->phydev->lock has
occurred at least once before, as seen in commit c718af2d00a3 ("net:
phylink: fix ethtool -A with attached PHYs"). The solution there was to
simply not call phy_set_asym_pause() under the &pl->state_mutex. That
cannot be extended to our case though, where the phy_config_inband()
call is much deeper inside the &pl->state_mutex section.
Fixes: 5fd0f1a02e75 ("net: phylink: add negotiation of in-band capabilities")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/20250904125238.193990-2-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-04 15:52:38 +03:00
|
|
|
|
2024-12-03 15:31:18 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem description
===================
Lockdep reports a possible circular locking dependency (AB/BA) between
&pl->state_mutex and &phy->lock, as follows.
phylink_resolve() // acquires &pl->state_mutex
-> phylink_major_config()
-> phy_config_inband() // acquires &pl->phydev->lock
whereas all the other call sites where &pl->state_mutex and
&pl->phydev->lock have the locking scheme reversed. Everywhere else,
&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at
the lower level. A clear example is phylink_bringup_phy().
The outlier is the newly introduced phy_config_inband() and the existing
lock order is the correct one. To understand why it cannot be the other
way around, it is sufficient to consider phylink_phy_change(), phylink's
callback from the PHY device's phy->phy_link_change() virtual method,
invoked by the PHY state machine.
phy_link_up() and phy_link_down(), the (indirect) callers of
phylink_phy_change(), are called with &phydev->lock acquired.
Then phylink_phy_change() acquires its own &pl->state_mutex, to
serialize changes made to its pl->phy_state and pl->link_config.
So all other instances of &pl->state_mutex and &phydev->lock must be
consistent with this order.
Problem impact
==============
I think the kernel runs a serious deadlock risk if an existing
phylink_resolve() thread, which results in a phy_config_inband() call,
is concurrent with a phy_link_up() or phy_link_down() call, which will
deadlock on &pl->state_mutex in phylink_phy_change(). Practically
speaking, the impact may be limited by the slow speed of the medium
auto-negotiation protocol, which makes it unlikely for the current state
to still be unresolved when a new one is detected, but I think the
problem is there. Nonetheless, the problem was discovered using lockdep.
Proposed solution
=================
Practically speaking, the phy_config_inband() requirement of having
phydev->lock acquired must transfer to the caller (phylink is the only
caller). There, it must bubble up until immediately before
&pl->state_mutex is acquired, for the cases where that takes place.
Solution details, considerations, notes
=======================================
This is the phy_config_inband() call graph:
sfp_upstream_ops :: connect_phy()
|
v
phylink_sfp_connect_phy()
|
v
phylink_sfp_config_phy()
|
| sfp_upstream_ops :: module_insert()
| |
| v
| phylink_sfp_module_insert()
| |
| | sfp_upstream_ops :: module_start()
| | |
| | v
| | phylink_sfp_module_start()
| | |
| v v
| phylink_sfp_config_optical()
phylink_start() | |
| phylink_resume() v v
| | phylink_sfp_set_config()
| | |
v v v
phylink_mac_initial_config()
| phylink_resolve()
| | phylink_ethtool_ksettings_set()
v v v
phylink_major_config()
|
v
phy_config_inband()
phylink_major_config() caller #1, phylink_mac_initial_config(), does not
acquire &pl->state_mutex nor do its callers. It must acquire
&pl->phydev->lock prior to calling phylink_major_config().
phylink_major_config() caller #2, phylink_resolve() acquires
&pl->state_mutex, thus also needs to acquire &pl->phydev->lock.
phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is
completely uninteresting, because it only calls phylink_major_config()
if pl->phydev is NULL (otherwise it calls phy_ethtool_ksettings_set()).
We need to change nothing there.
Other solutions
===============
The lock inversion between &pl->state_mutex and &pl->phydev->lock has
occurred at least once before, as seen in commit c718af2d00a3 ("net:
phylink: fix ethtool -A with attached PHYs"). The solution there was to
simply not call phy_set_asym_pause() under the &pl->state_mutex. That
cannot be extended to our case though, where the phy_config_inband()
call is much deeper inside the &pl->state_mutex section.
Fixes: 5fd0f1a02e75 ("net: phylink: add negotiation of in-band capabilities")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/20250904125238.193990-2-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-04 15:52:38 +03:00
|
|
|
|
2024-12-03 15:31:18 +00:00
|
|
|
|
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem description
===================
Lockdep reports a possible circular locking dependency (AB/BA) between
&pl->state_mutex and &phy->lock, as follows.
phylink_resolve() // acquires &pl->state_mutex
-> phylink_major_config()
-> phy_config_inband() // acquires &pl->phydev->lock
whereas all the other call sites where &pl->state_mutex and
&pl->phydev->lock have the locking scheme reversed. Everywhere else,
&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at
the lower level. A clear example is phylink_bringup_phy().
The outlier is the newly introduced phy_config_inband() and the existing
lock order is the correct one. To understand why it cannot be the other
way around, it is sufficient to consider phylink_phy_change(), phylink's
callback from the PHY device's phy->phy_link_change() virtual method,
invoked by the PHY state machine.
phy_link_up() and phy_link_down(), the (indirect) callers of
phylink_phy_change(), are called with &phydev->lock acquired.
Then phylink_phy_change() acquires its own &pl->state_mutex, to
serialize changes made to its pl->phy_state and pl->link_config.
So all other instances of &pl->state_mutex and &phydev->lock must be
consistent with this order.
Problem impact
==============
I think the kernel runs a serious deadlock risk if an existing
phylink_resolve() thread, which results in a phy_config_inband() call,
is concurrent with a phy_link_up() or phy_link_down() call, which will
deadlock on &pl->state_mutex in phylink_phy_change(). Practically
speaking, the impact may be limited by the slow speed of the medium
auto-negotiation protocol, which makes it unlikely for the current state
to still be unresolved when a new one is detected, but I think the
problem is there. Nonetheless, the problem was discovered using lockdep.
Proposed solution
=================
Practically speaking, the phy_config_inband() requirement of having
phydev->lock acquired must transfer to the caller (phylink is the only
caller). There, it must bubble up until immediately before
&pl->state_mutex is acquired, for the cases where that takes place.
Solution details, considerations, notes
=======================================
This is the phy_config_inband() call graph:
sfp_upstream_ops :: connect_phy()
|
v
phylink_sfp_connect_phy()
|
v
phylink_sfp_config_phy()
|
| sfp_upstream_ops :: module_insert()
| |
| v
| phylink_sfp_module_insert()
| |
| | sfp_upstream_ops :: module_start()
| | |
| | v
| | phylink_sfp_module_start()
| | |
| v v
| phylink_sfp_config_optical()
phylink_start() | |
| phylink_resume() v v
| | phylink_sfp_set_config()
| | |
v v v
phylink_mac_initial_config()
| phylink_resolve()
| | phylink_ethtool_ksettings_set()
v v v
phylink_major_config()
|
v
phy_config_inband()
phylink_major_config() caller #1, phylink_mac_initial_config(), does not
acquire &pl->state_mutex nor do its callers. It must acquire
&pl->phydev->lock prior to calling phylink_major_config().
phylink_major_config() caller #2, phylink_resolve() acquires
&pl->state_mutex, thus also needs to acquire &pl->phydev->lock.
phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is
completely uninteresting, because it only calls phylink_major_config()
if pl->phydev is NULL (otherwise it calls phy_ethtool_ksettings_set()).
We need to change nothing there.
Other solutions
===============
The lock inversion between &pl->state_mutex and &pl->phydev->lock has
occurred at least once before, as seen in commit c718af2d00a3 ("net:
phylink: fix ethtool -A with attached PHYs"). The solution there was to
simply not call phy_set_asym_pause() under the &pl->state_mutex. That
cannot be extended to our case though, where the phy_config_inband()
call is much deeper inside the &pl->state_mutex section.
Fixes: 5fd0f1a02e75 ("net: phylink: add negotiation of in-band capabilities")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/20250904125238.193990-2-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-04 15:52:38 +03:00
|
|
|
|
2024-12-03 15:31:18 +00:00
|
|
|
|
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem description
===================
Lockdep reports a possible circular locking dependency (AB/BA) between
&pl->state_mutex and &phy->lock, as follows.
phylink_resolve() // acquires &pl->state_mutex
-> phylink_major_config()
-> phy_config_inband() // acquires &pl->phydev->lock
whereas all the other call sites where &pl->state_mutex and
&pl->phydev->lock have the locking scheme reversed. Everywhere else,
&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at
the lower level. A clear example is phylink_bringup_phy().
The outlier is the newly introduced phy_config_inband() and the existing
lock order is the correct one. To understand why it cannot be the other
way around, it is sufficient to consider phylink_phy_change(), phylink's
callback from the PHY device's phy->phy_link_change() virtual method,
invoked by the PHY state machine.
phy_link_up() and phy_link_down(), the (indirect) callers of
phylink_phy_change(), are called with &phydev->lock acquired.
Then phylink_phy_change() acquires its own &pl->state_mutex, to
serialize changes made to its pl->phy_state and pl->link_config.
So all other instances of &pl->state_mutex and &phydev->lock must be
consistent with this order.
Problem impact
==============
I think the kernel runs a serious deadlock risk if an existing
phylink_resolve() thread, which results in a phy_config_inband() call,
is concurrent with a phy_link_up() or phy_link_down() call, which will
deadlock on &pl->state_mutex in phylink_phy_change(). Practically
speaking, the impact may be limited by the slow speed of the medium
auto-negotiation protocol, which makes it unlikely for the current state
to still be unresolved when a new one is detected, but I think the
problem is there. Nonetheless, the problem was discovered using lockdep.
Proposed solution
=================
Practically speaking, the phy_config_inband() requirement of having
phydev->lock acquired must transfer to the caller (phylink is the only
caller). There, it must bubble up until immediately before
&pl->state_mutex is acquired, for the cases where that takes place.
Solution details, considerations, notes
=======================================
This is the phy_config_inband() call graph:
sfp_upstream_ops :: connect_phy()
|
v
phylink_sfp_connect_phy()
|
v
phylink_sfp_config_phy()
|
| sfp_upstream_ops :: module_insert()
| |
| v
| phylink_sfp_module_insert()
| |
| | sfp_upstream_ops :: module_start()
| | |
| | v
| | phylink_sfp_module_start()
| | |
| v v
| phylink_sfp_config_optical()
phylink_start() | |
| phylink_resume() v v
| | phylink_sfp_set_config()
| | |
v v v
phylink_mac_initial_config()
| phylink_resolve()
| | phylink_ethtool_ksettings_set()
v v v
phylink_major_config()
|
v
phy_config_inband()
phylink_major_config() caller #1, phylink_mac_initial_config(), does not
acquire &pl->state_mutex nor do its callers. It must acquire
&pl->phydev->lock prior to calling phylink_major_config().
phylink_major_config() caller #2, phylink_resolve() acquires
&pl->state_mutex, thus also needs to acquire &pl->phydev->lock.
phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is
completely uninteresting, because it only calls phylink_major_config()
if pl->phydev is NULL (otherwise it calls phy_ethtool_ksettings_set()).
We need to change nothing there.
Other solutions
===============
The lock inversion between &pl->state_mutex and &pl->phydev->lock has
occurred at least once before, as seen in commit c718af2d00a3 ("net:
phylink: fix ethtool -A with attached PHYs"). The solution there was to
simply not call phy_set_asym_pause() under the &pl->state_mutex. That
cannot be extended to our case though, where the phy_config_inband()
call is much deeper inside the &pl->state_mutex section.
Fixes: 5fd0f1a02e75 ("net: phylink: add negotiation of in-band capabilities")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/20250904125238.193990-2-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-04 15:52:38 +03:00
|
|
|
|
2024-12-03 15:31:18 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-24 21:48:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-18 14:25:36 +01:00
|
|
|
|
2021-10-24 21:48:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-18 14:25:36 +01:00
|
|
|
|
2021-10-24 21:48:04 +02:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2018-10-15 21:25:13 +02:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
2018-10-15 21:25:13 +02:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-29 10:05:09 -06:00
|
|
|
|
2021-10-24 21:48:04 +02:00
|
|
|
|
2008-01-29 10:05:09 -06:00
|
|
|
|
2017-04-20 14:00:04 +03:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-24 21:48:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-21 11:29:05 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-24 21:48:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-24 21:48:05 +02:00
|
|
|
|
2021-10-24 21:48:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-03 22:08:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-24 21:48:03 +02:00
|
|
|
|
2021-10-24 21:48:05 +02:00
|
|
|
|
2021-10-24 21:48:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-12 23:52:19 +02:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
2019-08-12 23:52:19 +02:00
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
2019-08-12 23:52:19 +02:00
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
2018-11-10 23:43:33 +01:00
|
|
|
|
2019-08-12 23:52:19 +02:00
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-12 23:52:19 +02:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
2019-08-12 23:52:19 +02:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
2019-08-12 23:52:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-10 23:43:33 +01:00
|
|
|
|
2019-08-12 23:52:19 +02:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-12 21:32:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2017-07-26 12:05:38 -07:00
|
|
|
|
|
|
|
|
|
2014-01-05 03:27:17 +03:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2014-01-05 03:27:17 +03:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2018-10-11 19:31:47 +02:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2017-07-25 15:03:03 +01:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2017-07-26 12:05:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-13 15:41:19 -07:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2008-01-29 10:05:09 -06:00
|
|
|
|
2019-02-13 20:11:40 +01:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2008-01-29 10:05:09 -06:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
2023-03-23 14:45:59 -07:00
|
|
|
|
|
|
|
|
|
2023-08-18 15:54:45 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-22 16:58:08 +01:00
|
|
|
|
2023-03-23 14:45:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2023-05-22 16:58:08 +01:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2023-05-22 16:58:08 +01:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2023-08-18 15:54:45 +03:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2020-11-01 14:50:56 +02:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2018-12-16 19:18:26 +01:00
|
|
|
|
2023-03-23 14:45:59 -07:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2020-11-01 14:50:56 +02:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2026-04-08 06:18:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-24 15:58:24 +08:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2026-04-08 06:18:16 -07:00
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2026-04-08 06:18:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
2018-03-08 16:23:03 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-09 18:58:01 +01:00
|
|
|
|
2018-03-08 16:23:03 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-06 08:08:15 +02:00
|
|
|
|
2018-03-08 16:23:03 -06:00
|
|
|
|
2022-06-28 12:15:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-27 16:33:46 +01:00
|
|
|
|
2022-06-28 12:15:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-06 08:08:15 +02:00
|
|
|
|
2024-02-02 17:41:45 +00:00
|
|
|
|
2022-05-06 08:08:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-08 16:23:03 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 07:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2019-05-30 15:09:15 +02:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
2019-05-30 15:09:15 +02:00
|
|
|
|
2007-03-06 02:41:48 -08:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
|
|
|
|
|
2019-01-23 07:31:58 +01:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
2019-01-23 07:31:58 +01:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
2019-01-23 07:31:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-30 15:09:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-23 07:31:58 +01:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
2019-01-23 07:31:58 +01:00
|
|
|
|
2005-08-24 18:46:21 -05:00
|
|
|
|
2019-05-30 15:09:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-10 09:23:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
2020-05-10 21:12:39 +02:00
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
2023-03-23 14:45:59 -07:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
2013-12-17 21:38:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
2013-12-17 21:38:12 -08:00
|
|
|
|
|
|
|
|
|
2018-11-07 20:47:53 +01:00
|
|
|
|
|
|
|
|
|
2023-03-23 14:45:59 -07:00
|
|
|
|
2025-01-10 07:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 21:38:12 -08:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:39 +02:00
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-10 21:12:36 +02:00
|
|
|
|
2020-05-10 21:12:39 +02:00
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
2020-05-10 21:12:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 21:38:12 -08:00
|
|
|
|
2025-09-17 11:47:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-22 16:58:08 +01:00
|
|
|
|
2013-12-17 21:38:12 -08:00
|
|
|
|
|
|
|
|
|
2025-09-12 15:20:00 +02:00
|
|
|
|
|
|
|
|
|
2020-05-18 15:23:59 -07:00
|
|
|
|
2013-12-17 21:38:12 -08:00
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
2013-12-17 21:38:12 -08:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
|
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
2023-09-14 16:35:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
|
|
|
|
|
2021-06-07 10:27:26 +02:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2023-03-23 14:45:59 -07:00
|
|
|
|
2005-07-30 19:31:23 -04:00
|
|
|
|
2023-03-16 13:33:24 -07:00
|
|
|
|
2015-05-16 10:17:56 -07:00
|
|
|
|
2016-01-18 19:33:06 -08:00
|
|
|
|
2021-02-14 15:16:23 +01:00
|
|
|
|
2018-09-20 22:34:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-18 19:33:06 -08:00
|
|
|
|
2018-12-16 18:30:14 +01:00
|
|
|
|
2025-02-10 09:23:57 +01:00
|
|
|
|
|
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-13 20:12:54 +01:00
|
|
|
|
2023-09-14 16:35:47 +01:00
|
|
|
|
2023-09-14 16:35:57 +01:00
|
|
|
|
2008-01-29 10:05:09 -06:00
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
2023-09-14 16:35:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-14 16:36:02 +01:00
|
|
|
|
2023-09-14 16:35:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-14 16:36:02 +01:00
|
|
|
|
2023-09-14 16:35:52 +01:00
|
|
|
|
|
|
|
|
|
2023-09-14 16:36:02 +01:00
|
|
|
|
2023-09-14 16:35:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-16 19:56:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-10 21:21:31 +01:00
|
|
|
|
|
|
|
|
|
2016-10-16 19:56:51 +02:00
|
|
|
|
2018-01-10 21:21:31 +01:00
|
|
|
|
2013-05-19 22:53:43 +00:00
|
|
|
|
2016-01-18 19:33:07 -08:00
|
|
|
|
2018-11-09 18:56:52 +01:00
|
|
|
|
2013-05-19 22:53:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-12 21:30:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-15 20:42:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-08 16:47:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-11 08:41:12 +01:00
|
|
|
|
|
|
|
|
|
2017-02-17 16:07:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-16 22:20:07 +01:00
|
|
|
|
2023-02-11 08:41:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
2023-02-11 08:41:12 +01:00
|
|
|
|
2025-01-08 16:47:33 +00:00
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
2023-02-11 08:41:12 +01:00
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
2017-02-17 16:07:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-27 14:25:09 +01:00
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
2024-12-05 10:42:15 +00:00
|
|
|
|
|
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
2024-01-27 14:25:09 +01:00
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
2017-02-17 16:07:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
2024-03-02 20:53:02 +01:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-02 20:53:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-16 21:52:15 +01:00
|
|
|
|
2024-03-02 20:53:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-16 21:52:15 +01:00
|
|
|
|
2024-03-02 20:53:03 +01:00
|
|
|
|
2024-11-23 14:50:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-16 21:52:15 +01:00
|
|
|
|
2024-11-23 14:50:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-02 20:53:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-27 14:25:09 +01:00
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-27 14:25:09 +01:00
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
2024-11-16 21:52:15 +01:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
2017-02-17 16:07:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
2024-11-16 21:52:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
2024-11-16 21:52:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
2024-03-02 20:53:03 +01:00
|
|
|
|
2012-06-27 21:14:38 +00:00
|
|
|
|
|
|
|
|
|
2013-03-11 13:56:44 +00:00
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-11 13:56:44 +00:00
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-11 13:56:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-11 13:56:44 +00:00
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
2013-03-11 13:56:44 +00:00
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
2013-03-11 13:56:44 +00:00
|
|
|
|
|
|
|
|
|
2016-05-10 00:19:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-13 10:09:46 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-10 00:19:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-15 10:06:30 -08:00
|
|
|
|
2020-09-23 00:29:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-15 10:06:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
2016-11-15 10:06:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-17 16:07:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 04:07:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-15 10:06:30 -08:00
|
|
|
|
|
|
|
|
|