[PATCH v3 net-next 5/5] dt-bindings: net: dsa: Document dsa-tag-protocol property
The 'dsa-tag-protocol' is used to force a switch tree to use a particular tag protocol, typically because the Ethernet controller that it is connected to is not compatible with the default one. Signed-off-by: Tobias Waldekranz --- Documentation/devicetree/bindings/net/dsa/dsa.yaml | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml index 8a3494db4d8d..16aa192c118e 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml @@ -70,6 +70,15 @@ patternProperties: device is what the switch port is connected to $ref: /schemas/types.yaml#/definitions/phandle + dsa-tag-protocol: +description: + Instead of the default, the switch will use this tag protocol if + possible. Useful when a device supports multiple protcols and + the default is incompatible with the Ethernet device. +enum: + - dsa + - edsa + phy-handle: true phy-mode: true -- 2.25.1
Re: [PATCH v2 net-next 5/5] dt-bindings: net: dsa: Document dsa,tag-protocol property
On Thu, Apr 15, 2021 at 04:27:58PM -0500, Rob Herring wrote: > On Thu, Apr 15, 2021 at 11:26:10AM +0200, Tobias Waldekranz wrote: > > The 'dsa,tag-protocol' is used to force a switch tree to use a > > particular tag protocol, typically because the Ethernet controller > > that it is connected to is not compatible with the default one. > > > > Signed-off-by: Tobias Waldekranz > > --- > > Documentation/devicetree/bindings/net/dsa/dsa.yaml | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > > b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > > index 8a3494db4d8d..c4dec0654c6a 100644 > > --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > > +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > > @@ -70,6 +70,15 @@ patternProperties: > >device is what the switch port is connected to > > $ref: /schemas/types.yaml#/definitions/phandle > > > > + dsa,tag-protocol: > > 'dsa' is not a vendor. 'dsa-tag-protocol' instead. Can confirm, DSA is not a vendor. You can change to 'dsa-tag-protocol' if this makes acceptance any easier.
[PATCH net-next v2 2/9] docs: ethtool: document standard statistics
Add documentation for ETHTOOL_MSG_STATS_GET. Signed-off-by: Jakub Kicinski --- Documentation/networking/ethtool-netlink.rst | 82 1 file changed, 82 insertions(+) diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index f8219e2f489e..48cad2fce147 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -210,6 +210,7 @@ All constants identifying message types use ``ETHTOOL_CMD_`` prefix and suffix ``ETHTOOL_MSG_TUNNEL_INFO_GET`` get tunnel offload info ``ETHTOOL_MSG_FEC_GET`` get FEC settings ``ETHTOOL_MSG_FEC_SET`` set FEC settings + ``ETHTOOL_MSG_STATS_GET`` get standard statistics = Kernel to userspace: @@ -246,6 +247,7 @@ All constants identifying message types use ``ETHTOOL_CMD_`` prefix and suffix ``ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY`` tunnel offload info ``ETHTOOL_MSG_FEC_GET_REPLY`` FEC settings ``ETHTOOL_MSG_FEC_NTF`` FEC settings + ``ETHTOOL_MSG_STATS_GET_REPLY`` standard statistics = = ``GET`` requests are sent by userspace applications to retrieve device @@ -1391,6 +1393,86 @@ accessible. ``ETHTOOL_A_MODULE_EEPROM_DATA`` has an attribute length equal to the amount of bytes driver actually read. +STATS_GET += + +Get standard statistics for the interface. Note that this is not +a re-implementation of ``ETHTOOL_GSTATS`` which exposed driver-defined +stats. + +Request contents: + + === == == + ``ETHTOOL_A_STATS_HEADER`` nested request header + ``ETHTOOL_A_STATS_GROUPS`` bitset requested groups of stats + === == == + +Kernel response contents: + + +---+++ + | ``ETHTOOL_A_STATS_HEADER``| nested | reply header | + +---+++ + | ``ETHTOOL_A_STATS_GRP`` | nested | one or more group of stats | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_ID`` | u32| group ID - ``ETHTOOL_STATS_*`` | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_SS_ID`` | u32| string set ID for names | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_STAT``| nested | nest containing a statistic | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_HIST_RX`` | nested | histogram statistic (Rx) | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_HIST_TX`` | nested | histogram statistic (Tx) | + +-+-+++ + +Users specify which groups of statistics they are requesting via +the ``ETHTOOL_A_STATS_GROUPS`` bitset. Currently defined values are: + + == === + ETHTOOL_STATS_ETH_MAC eth-mac Basic IEEE 802.3 MAC statistics (30.3.1.1.*) + ETHTOOL_STATS_ETH_PHY eth-phy Basic IEEE 802.3 PHY statistics (30.3.2.1.*) + ETHTOOL_STATS_ETH_CTRL eth-ctrl Basic IEEE 802.3 MAC Ctrl statistics (30.3.3.*) + ETHTOOL_STATS_RMON rmon RMON (RFC 2819) statistics + == === + +Each group should have a corresponding ``ETHTOOL_A_STATS_GRP`` in the reply. +``ETHTOOL_A_STATS_GRP_ID`` identifies which group's statistics nest contains. +``ETHTOOL_A_STATS_GRP_SS_ID`` identifies the string set ID for the names of +the statistics in the group, if available. + +Statistics are added to the ``ETHTOOL_A_STATS_GRP`` nest under +``ETHTOOL_A_STATS_GRP_STAT``. ``ETHTOOL_A_STATS_GRP_STAT`` should contain +single 8 byte (u64) attribute inside - the type of that attribute is +the statistic ID and the value is the value of the statistic. +Each group has its own interpretation of statistic IDs. +Attribute IDs correspond to strings from the string set identified +by ``ETHTOOL_A_STATS_GRP_SS_ID``. Complex statistics (such as RMON histogram +entries) are also listed inside ``ETHTOOL_A_STATS_GRP`` and do not have +a string defined in the string set. + +RMON "histogram" counters count number of packets within given size range. +Because RFC does not specify the ranges beyond the standard 1518 MTU devices +differ in definition of buckets. For this reason the definition of packet ranges +is lef
[PATCH v3 1/2] dt-bindings: net: can: Document transceiver implementation as phy
From: Faiz Abbas Some transceivers need a configuration step (for example, pulling the standby or enable lines) for them to start sending messages. The transceiver can be implemented as a phy with the configuration done in the phy driver. The bit rate limitation can the be obtained by the driver using the phy node. Document the above implementation in the bosch mcan bindings Signed-off-by: Faiz Abbas Signed-off-by: Aswath Govindraju Acked-by: Rob Herring --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..25f74db46bae 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -109,6 +109,9 @@ properties: can-transceiver: $ref: can-transceiver.yaml# + phys: +maxItems: 1 + required: - compatible - reg -- 2.17.1
[PATCH net-next 2/9] docs: ethtool: document standard statistics
Add documentation for ETHTOOL_MSG_STATS_GET. Signed-off-by: Jakub Kicinski --- Documentation/networking/ethtool-netlink.rst | 82 1 file changed, 82 insertions(+) diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index f8219e2f489e..48cad2fce147 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -210,6 +210,7 @@ All constants identifying message types use ``ETHTOOL_CMD_`` prefix and suffix ``ETHTOOL_MSG_TUNNEL_INFO_GET`` get tunnel offload info ``ETHTOOL_MSG_FEC_GET`` get FEC settings ``ETHTOOL_MSG_FEC_SET`` set FEC settings + ``ETHTOOL_MSG_STATS_GET`` get standard statistics = Kernel to userspace: @@ -246,6 +247,7 @@ All constants identifying message types use ``ETHTOOL_CMD_`` prefix and suffix ``ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY`` tunnel offload info ``ETHTOOL_MSG_FEC_GET_REPLY`` FEC settings ``ETHTOOL_MSG_FEC_NTF`` FEC settings + ``ETHTOOL_MSG_STATS_GET_REPLY`` standard statistics = = ``GET`` requests are sent by userspace applications to retrieve device @@ -1391,6 +1393,86 @@ accessible. ``ETHTOOL_A_MODULE_EEPROM_DATA`` has an attribute length equal to the amount of bytes driver actually read. +STATS_GET += + +Get standard statistics for the interface. Note that this is not +a re-implementation of ``ETHTOOL_GSTATS`` which exposed driver-defined +stats. + +Request contents: + + === == == + ``ETHTOOL_A_STATS_HEADER`` nested request header + ``ETHTOOL_A_STATS_GROUPS`` bitset requested groups of stats + === == == + +Kernel response contents: + + +---+++ + | ``ETHTOOL_A_STATS_HEADER``| nested | reply header | + +---+++ + | ``ETHTOOL_A_STATS_GRP`` | nested | one or more group of stats | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_ID`` | u32| group ID - ``ETHTOOL_STATS_*`` | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_SS_ID`` | u32| string set ID for names | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_STAT``| nested | nest containing a statistic | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_HIST_RX`` | nested | histogram statistic (Rx) | + +-+-+++ + | | ``ETHTOOL_A_STATS_GRP_HIST_TX`` | nested | histogram statistic (Tx) | + +-+-+++ + +Users specify which groups of statistics they are requesting via +the ``ETHTOOL_A_STATS_GROUPS`` bitset. Currently defined values are: + + == === + ETHTOOL_STATS_ETH_MAC eth-mac Basic IEEE 802.3 MAC statistics (30.3.1.1.*) + ETHTOOL_STATS_ETH_PHY eth-phy Basic IEEE 802.3 PHY statistics (30.3.2.1.*) + ETHTOOL_STATS_ETH_CTRL eth-ctrl Basic IEEE 802.3 MAC Ctrl statistics (30.3.3.*) + ETHTOOL_STATS_RMON rmon RMON (RFC 2819) statistics + == === + +Each group should have a corresponding ``ETHTOOL_A_STATS_GRP`` in the reply. +``ETHTOOL_A_STATS_GRP_ID`` identifies which group's statistics nest contains. +``ETHTOOL_A_STATS_GRP_SS_ID`` identifies the string set ID for the names of +the statistics in the group, if available. + +Statistics are added to the ``ETHTOOL_A_STATS_GRP`` nest under +``ETHTOOL_A_STATS_GRP_STAT``. ``ETHTOOL_A_STATS_GRP_STAT`` should contain +single 8 byte (u64) attribute inside - the type of that attribute is +the statistic ID and the value is the value of the statistic. +Each group has its own interpretation of statistic IDs. +Attribute IDs correspond to strings from the string set identified +by ``ETHTOOL_A_STATS_GRP_SS_ID``. Complex statistics (such as RMON histogram +entries) are also listed inside ``ETHTOOL_A_STATS_GRP`` and do not have +a string defined in the string set. + +RMON "histogram" counters count number of packets within given size range. +Because RFC does not specify the ranges beyond the standard 1518 MTU devices +differ in definition of buckets. For this reason the definition of packet ranges +is lef
Re: [PATCH v2 1/2] dt-bindings: net: can: Document transceiver implementation as phy
On Thu, 15 Apr 2021 21:16:34 +0530, Aswath Govindraju wrote: > From: Faiz Abbas > > Some transceivers need a configuration step (for example, pulling the > standby or enable lines) for them to start sending messages. The > transceiver can be implemented as a phy with the configuration done in the > phy driver. The bit rate limitation can the be obtained by the driver using > the phy node. > > Document the above implementation in the bosch mcan bindings > > Signed-off-by: Faiz Abbas > Signed-off-by: Aswath Govindraju > --- > Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ > 1 file changed, 3 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v2 net-next 5/5] dt-bindings: net: dsa: Document dsa,tag-protocol property
On Thu, Apr 15, 2021 at 11:26:10AM +0200, Tobias Waldekranz wrote: > The 'dsa,tag-protocol' is used to force a switch tree to use a > particular tag protocol, typically because the Ethernet controller > that it is connected to is not compatible with the default one. > > Signed-off-by: Tobias Waldekranz > --- > Documentation/devicetree/bindings/net/dsa/dsa.yaml | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > index 8a3494db4d8d..c4dec0654c6a 100644 > --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > @@ -70,6 +70,15 @@ patternProperties: >device is what the switch port is connected to > $ref: /schemas/types.yaml#/definitions/phandle > > + dsa,tag-protocol: 'dsa' is not a vendor. 'dsa-tag-protocol' instead. > +description: > + Instead of the default, the switch will use this tag protocol > if > + possible. Useful when a device supports multiple protcols and > + the default is incompatible with the Ethernet device. > +enum: > + - dsa > + - edsa > + >phy-handle: true > >phy-mode: true > -- > 2.25.1 >
[PATCH v2 1/2] dt-bindings: net: can: Document transceiver implementation as phy
From: Faiz Abbas Some transceivers need a configuration step (for example, pulling the standby or enable lines) for them to start sending messages. The transceiver can be implemented as a phy with the configuration done in the phy driver. The bit rate limitation can the be obtained by the driver using the phy node. Document the above implementation in the bosch mcan bindings Signed-off-by: Faiz Abbas Signed-off-by: Aswath Govindraju --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..25f74db46bae 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -109,6 +109,9 @@ properties: can-transceiver: $ref: can-transceiver.yaml# + phys: +maxItems: 1 + required: - compatible - reg -- 2.17.1
[PATCH 1/2] dt-bindings: net: can: Document transceiver implementation as phy
From: Faiz Abbas Some transceivers need a configuration step (for example, pulling the standby or enable lines) for them to start sending messages. The transceiver can be implemented as a phy with the configuration done in the phy driver. The bit rate limitation can the be obtained by the driver using the phy node. Document the above implementation in the bosch mcan bindings Signed-off-by: Faiz Abbas Signed-off-by: Aswath Govindraju --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..25f74db46bae 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -109,6 +109,9 @@ properties: can-transceiver: $ref: can-transceiver.yaml# + phys: +maxItems: 1 + required: - compatible - reg -- 2.17.1
[PATCH v2 net-next 5/5] dt-bindings: net: dsa: Document dsa,tag-protocol property
The 'dsa,tag-protocol' is used to force a switch tree to use a particular tag protocol, typically because the Ethernet controller that it is connected to is not compatible with the default one. Signed-off-by: Tobias Waldekranz --- Documentation/devicetree/bindings/net/dsa/dsa.yaml | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml index 8a3494db4d8d..c4dec0654c6a 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml @@ -70,6 +70,15 @@ patternProperties: device is what the switch port is connected to $ref: /schemas/types.yaml#/definitions/phandle + dsa,tag-protocol: +description: + Instead of the default, the switch will use this tag protocol if + possible. Useful when a device supports multiple protcols and + the default is incompatible with the Ethernet device. +enum: + - dsa + - edsa + phy-handle: true phy-mode: true -- 2.25.1
[RFC net-next 2/6] docs: ethtool: document standard statistics
Add documentation for ETHTOOL_MSG_STATS_GET. Signed-off-by: Jakub Kicinski --- Documentation/networking/ethtool-netlink.rst | 74 1 file changed, 74 insertions(+) diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index f8219e2f489e..086a80eb17be 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -210,6 +210,7 @@ All constants identifying message types use ``ETHTOOL_CMD_`` prefix and suffix ``ETHTOOL_MSG_TUNNEL_INFO_GET`` get tunnel offload info ``ETHTOOL_MSG_FEC_GET`` get FEC settings ``ETHTOOL_MSG_FEC_SET`` set FEC settings + ``ETHTOOL_MSG_STATS_GET`` get standard statistics = Kernel to userspace: @@ -246,6 +247,7 @@ All constants identifying message types use ``ETHTOOL_CMD_`` prefix and suffix ``ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY`` tunnel offload info ``ETHTOOL_MSG_FEC_GET_REPLY`` FEC settings ``ETHTOOL_MSG_FEC_NTF`` FEC settings + ``ETHTOOL_MSG_STATS_GET_REPLY`` standard statistics = = ``GET`` requests are sent by userspace applications to retrieve device @@ -1391,6 +1393,78 @@ accessible. ``ETHTOOL_A_MODULE_EEPROM_DATA`` has an attribute length equal to the amount of bytes driver actually read. +STATS_GET += + +Get standard statistics for the interface. Note that this is not +a re-implementation of ``ETHTOOL_GSTATS`` which exposed driver-defined +stats. + +Request contents: + + === == == + ``ETHTOOL_A_STATS_HEADER`` nested request header + ``ETHTOOL_A_STATS_GROUPS`` bitset requested groups of stats + === == == + +Kernel response contents: + + +-++--+ + | ``ETHTOOL_A_STATS_HEADER`` | nested | reply header | + +-++--+ + | ``ETHTOOL_A_STATS_GRP`` | nested | one or more groups of statistics | + +-+---++--+ + | | ``ETHTOOL_A_STATS_GRP_ID``| u32| group ID - ``ETHTOOL_STATS_*`` | + +-+---++--+ + | | ``ETHTOOL_A_STATS_GRP_SS_ID`` | u32| string set ID for names | + +-+---++--+ + | | ``ETHTOOL_A_STATS_*`` | u64| actual statistics | + +-+---++--+ + +Users specify which groups of statistics they are requesting via +the ``ETHTOOL_A_STATS_GROUPS`` bitset. Currently defined values are: + + == === + ETHTOOL_STATS_ETH_MAC eth-mac Basic IEEE 802.3 MAC statistics (30.3.1.1.*) + ETHTOOL_STATS_ETH_PHY eth-phy Basic IEEE 802.3 PHY statistics (30.3.2.1.*) + ETHTOOL_STATS_ETH_CTRL eth-ctrl Basic IEEE 802.3 MAC Ctrl statistics (30.3.3.*) + ETHTOOL_STATS_RMON rmon RMON (RFC 2819) statistics + == === + +Each group should have a corresponding ``ETHTOOL_A_STATS_GRP`` in the reply. +``ETHTOOL_A_STATS_GRP_ID`` identifies which group's statistics nest contains. +``ETHTOOL_A_STATS_GRP_SS_ID`` identifies the string set ID for the names of +the statistics in the group, if available. + +Statistics are added directly to the ``ETHTOOL_A_STATS_GRP`` nest. Each group +has its own interpretation of attribute IDs above +``ETHTOOL_A_STATS_GRP_FIRST_ATTR``. Attribute IDs correspond to strings from +the string set identified by ``ETHTOOL_A_STATS_GRP_SS_ID``. Complex statistics +(such as RMON histogram entries) are also listed directly in +``ETHTOOL_A_STATS_GRP`` and do not have a string defined in the string set. + +RMON "histogram" counters count number of packets within given size range. +Because RFC does not specify the ranges beyond the standard 1518 MTU devices +differ in definition of buckets. For this reason the definition of packet ranges +is left to each driver. + + = == === + ETHTOOL_A_STATS_RMON_HIST nested contains the attributes below + ETHTOOL_A_STATS_RMON_HIST_BKT_LOW u32low bound of the packet size bucket + ETHTOOL_A_STATS_RMON_HIST_BKT_HI u32high bound of the bucket + ETHTOOL_A_STATS_RMON_HIST_VAL u64packet counter + ETHTOOL_A_STATS_RMON_HIST_TX nested same as HIST but counting Tx pkts + =
[PATCH v2 5/6] dt-bindings: net: can: Document transceiver implementation as phy
From: Faiz Abbas Some transceivers need a configuration step (for example, pulling the standby or enable lines) for them to start sending messages. The transceiver can be implemented as a phy with the configuration done in the phy driver. The bit rate limitation can the be obtained by the driver using the phy node. Document the above implementation in the bosch mcan bindings Signed-off-by: Faiz Abbas Signed-off-by: Aswath Govindraju --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..25f74db46bae 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -109,6 +109,9 @@ properties: can-transceiver: $ref: can-transceiver.yaml# + phys: +maxItems: 1 + required: - compatible - reg -- 2.17.1
Re: [PATCH 3/4] dt-bindings: net: can: Document transceiver implementation as phy
On Wed, Apr 14, 2021 at 1:49 AM Aswath Govindraju wrote: > > Hi Rob, > > On 12/04/21 11:21 pm, Rob Herring wrote: > > On Fri, Apr 09, 2021 at 07:10:53PM +0530, Aswath Govindraju wrote: > >> From: Faiz Abbas > >> > >> Some transceivers need a configuration step (for example, pulling the > >> standby or enable lines) for them to start sending messages. The > >> transceiver can be implemented as a phy with the configuration done in the > >> phy driver. The bit rate limitation can the be obtained by the driver using > >> the phy node. > >> > >> Document the above implementation in the bosch mcan bindings > >> > >> Signed-off-by: Faiz Abbas > >> Signed-off-by: Aswath Govindraju > >> --- > >> Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 6 ++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > >> b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > >> index 798fa5fb7bb2..2c01899b1a3e 100644 > >> --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > >> +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > >> @@ -109,6 +109,12 @@ properties: > >>can-transceiver: > >> $ref: can-transceiver.yaml# > >> > >> + phys: > >> +minItems: 1 > > > > maxItems: 1 > > Will add this in the respin. > > > > >> + > >> + phy-names: > >> +const: can_transceiver > > > > Kind of a pointless name. You don't really need a name if there's a > > single entry. > > > > This name used by devm_phy_optional_get() in m_can driver to get the phy > data structure. With no name, you'll get the 1st one. Looks like the phy subsystem warns on this. That's wrong, so please fix that. Rob
Re: [PATCH 3/4] dt-bindings: net: can: Document transceiver implementation as phy
Hi Rob, On 12/04/21 11:21 pm, Rob Herring wrote: > On Fri, Apr 09, 2021 at 07:10:53PM +0530, Aswath Govindraju wrote: >> From: Faiz Abbas >> >> Some transceivers need a configuration step (for example, pulling the >> standby or enable lines) for them to start sending messages. The >> transceiver can be implemented as a phy with the configuration done in the >> phy driver. The bit rate limitation can the be obtained by the driver using >> the phy node. >> >> Document the above implementation in the bosch mcan bindings >> >> Signed-off-by: Faiz Abbas >> Signed-off-by: Aswath Govindraju >> --- >> Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml >> b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml >> index 798fa5fb7bb2..2c01899b1a3e 100644 >> --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml >> +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml >> @@ -109,6 +109,12 @@ properties: >>can-transceiver: >> $ref: can-transceiver.yaml# >> >> + phys: >> +minItems: 1 > > maxItems: 1 Will add this in the respin. > >> + >> + phy-names: >> +const: can_transceiver > > Kind of a pointless name. You don't really need a name if there's a > single entry. > This name used by devm_phy_optional_get() in m_can driver to get the phy data structure. Thank you for the review. Regards, Aswath >> + >> required: >>- compatible >>- reg >> -- >> 2.17.1 >>
Re: [PATCH v3] dt-bindings: net: can: rcar_can: Document r8a77961 support
On 4/9/21 2:00 AM, Yoshihiro Shimoda wrote: > Document SoC specific bindings for R-Car M3-W+ (r8a77961) SoC. > > Also as R8A7796 is now called R8A77960 so that update those > references. > > Signed-off-by: Yoshihiro Shimoda > Reviewed-by: Geert Uytterhoeven > Acked-by: Rob Herring > Reviewed-by: Wolfram Sang Added to latest pull request. Tnx, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: OpenPGP digital signature
[net-next 01/14] dt-bindings: net: can: rcar_can: Document r8a77961 support
From: Yoshihiro Shimoda Document SoC specific bindings for R-Car M3-W+ (r8a77961) SoC. Also as R8A7796 is now called R8A77960 so that update those references. Link: https://lore.kernel.org/r/2021040920.2317696-1-yoshihiro.shimoda...@renesas.com Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring Reviewed-by: Wolfram Sang Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/rcar_can.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt index 6a5956347816..90ac4fef23f5 100644 --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt @@ -19,7 +19,8 @@ Required properties: "renesas,can-r8a7793" if CAN controller is a part of R8A7793 SoC. "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC. "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC. - "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC. + "renesas,can-r8a7796" if CAN controller is a part of R8A77960 SoC. + "renesas,can-r8a77961" if CAN controller is a part of R8A77961 SoC. "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC. "renesas,can-r8a77990" if CAN controller is a part of R8A77990 SoC. "renesas,can-r8a77995" if CAN controller is a part of R8A77995 SoC. @@ -40,7 +41,7 @@ Required properties: - pinctrl-names: must be "default". Required properties for R8A774A1, R8A774B1, R8A774C0, R8A774E1, R8A7795, -R8A7796, R8A77965, R8A77990, and R8A77995: +R8A77960, R8A77961, R8A77965, R8A77990, and R8A77995: For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can be used by both CAN and CAN FD controller at the same time. It needs to be scaled to maximum frequency if any of these controllers use it. This is done base-commit: 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2 -- 2.30.2
Re: [PATCH 3/4] dt-bindings: net: can: Document transceiver implementation as phy
On Fri, Apr 09, 2021 at 07:10:53PM +0530, Aswath Govindraju wrote: > From: Faiz Abbas > > Some transceivers need a configuration step (for example, pulling the > standby or enable lines) for them to start sending messages. The > transceiver can be implemented as a phy with the configuration done in the > phy driver. The bit rate limitation can the be obtained by the driver using > the phy node. > > Document the above implementation in the bosch mcan bindings > > Signed-off-by: Faiz Abbas > Signed-off-by: Aswath Govindraju > --- > Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > index 798fa5fb7bb2..2c01899b1a3e 100644 > --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > @@ -109,6 +109,12 @@ properties: >can-transceiver: > $ref: can-transceiver.yaml# > > + phys: > +minItems: 1 maxItems: 1 > + > + phy-names: > +const: can_transceiver Kind of a pointless name. You don't really need a name if there's a single entry. > + > required: >- compatible >- reg > -- > 2.17.1 >
Re: [RFC PATCH 1/3] dt-bindings: net: xilinx_axienet: convert bindings document to yaml
On Fri, 09 Apr 2021 23:43:20 +0530, Radhey Shyam Pandey wrote: > Convert the bindings document for Xilinx AXI Ethernet Subsystem > from txt to yaml. No changes to existing binding description. > > Signed-off-by: Radhey Shyam Pandey > --- > Pending: Fix below remaining dt_binding_check warning: > > ethernet@40c0: 'device_type' does not match any of > the regexes: 'pinctrl-[0-9]+ > --- > .../devicetree/bindings/net/xilinx_axienet.txt | 80 --- > .../devicetree/bindings/net/xilinx_axienet.yaml| 147 > + > MAINTAINERS| 1 + > 3 files changed, 148 insertions(+), 80 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.txt > create mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/xilinx_axienet.example.dt.yaml: ethernet@40c0: 'device_type' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/xilinx_axienet.yaml See https://patchwork.ozlabs.org/patch/1464502 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
[RFC PATCH 1/3] dt-bindings: net: xilinx_axienet: convert bindings document to yaml
Convert the bindings document for Xilinx AXI Ethernet Subsystem
from txt to yaml. No changes to existing binding description.
Signed-off-by: Radhey Shyam Pandey
---
Pending: Fix below remaining dt_binding_check warning:
ethernet@40c0: 'device_type' does not match any of
the regexes: 'pinctrl-[0-9]+
---
.../devicetree/bindings/net/xilinx_axienet.txt | 80 ---
.../devicetree/bindings/net/xilinx_axienet.yaml| 147 +
MAINTAINERS| 1 +
3 files changed, 148 insertions(+), 80 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.txt
create mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.yaml
diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
b/Documentation/devicetree/bindings/net/xilinx_axienet.txt
deleted file mode 100644
index 2cd452419ed0..
--- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-XILINX AXI ETHERNET Device Tree Bindings
-
-
-Also called AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core
-provides connectivity to an external ethernet PHY supporting different
-interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two
-segments of memory for buffering TX and RX, as well as the capability of
-offloading TX/RX checksum calculation off the processor.
-
-Management configuration is done through the AXI interface, while payload is
-sent and received through means of an AXI DMA controller. This driver
-includes the DMA driver code, so this driver is incompatible with AXI DMA
-driver.
-
-For more details about mdio please refer phy.txt file in the same directory.
-
-Required properties:
-- compatible : Must be one of "xlnx,axi-ethernet-1.00.a",
- "xlnx,axi-ethernet-1.01.a", "xlnx,axi-ethernet-2.01.a"
-- reg : Address and length of the IO space, as well as the address
- and length of the AXI DMA controller IO space, unless
- axistream-connected is specified, in which case the reg
- attribute of the node referenced by it is used.
-- interrupts : Should be a list of 2 or 3 interrupts: TX DMA, RX DMA,
- and optionally Ethernet core. If axistream-connected is
- specified, the TX/RX DMA interrupts should be on that node
- instead, and only the Ethernet core interrupt is optionally
- specified here.
-- phy-handle : Should point to the external phy device.
- See ethernet.txt file in the same directory.
-- xlnx,rxmem : Set to allocated memory buffer for Rx/Tx in the hardware
-
-Optional properties:
-- phy-mode : See ethernet.txt
-- xlnx,phy-type: Deprecated, do not use, but still accepted in
preference
- to phy-mode.
-- xlnx,txcsum : 0 or empty for disabling TX checksum offload,
- 1 to enable partial TX checksum offload,
- 2 to enable full TX checksum offload
-- xlnx,rxcsum : Same values as xlnx,txcsum but for RX checksum offload
-- xlnx,switch-x-sgmii : Boolean to indicate the Ethernet core is configured to
- support both 1000BaseX and SGMII modes. If set, the phy-mode
- should be set to match the mode selected on core reset (i.e.
- by the basex_or_sgmii core input line).
-- clocks : AXI bus clock for the device. Refer to common clock bindings.
- Used to calculate MDIO clock divisor. If not specified, it is
- auto-detected from the CPU clock (but only on platforms where
- this is possible). New device trees should specify this - the
- auto detection is only for backward compatibility.
-- axistream-connected: Reference to another node which contains the resources
- for the AXI DMA controller used by this device.
- If this is specified, the DMA-related resources from that
- device (DMA registers and DMA TX/RX interrupts) rather
- than this one will be used.
- - mdio: Child node for MDIO bus. Must be defined if PHY
access is
- required through the core's MDIO interface (i.e. always,
- unless the PHY is accessed through a different bus).
-
-Example:
- axi_ethernet_eth: ethernet@40c0 {
- compatible = "xlnx,axi-ethernet-1.00.a";
- device_type = "network";
- interrupt-parent = <µblaze_0_axi_intc>;
- interrupts = <2 0 1>;
- clocks = <&axi_clk>;
- phy-mode = "mii";
- reg = <0x40c0 0x4 0x50c0 0x4>;
- xlnx,rxcsum = <0x2&g
[PATCH 3/4] dt-bindings: net: can: Document transceiver implementation as phy
From: Faiz Abbas Some transceivers need a configuration step (for example, pulling the standby or enable lines) for them to start sending messages. The transceiver can be implemented as a phy with the configuration done in the phy driver. The bit rate limitation can the be obtained by the driver using the phy node. Document the above implementation in the bosch mcan bindings Signed-off-by: Faiz Abbas Signed-off-by: Aswath Govindraju --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..2c01899b1a3e 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -109,6 +109,12 @@ properties: can-transceiver: $ref: can-transceiver.yaml# + phys: +minItems: 1 + + phy-names: +const: can_transceiver + required: - compatible - reg -- 2.17.1
Re: [PATCH net-next 3/3] dt-bindings: net: dsa: Document dsa,tag-protocol property
On Tue, Apr 06, 2021 at 03:30:46PM +0200, Andrew Lunn wrote: > > Andrew, Vladimir: I will just list dsa and edsa for now. If it is needed > > on other devices, people can add them to the list after they have tested > > their drivers. Fair? > > O.K. Same here.
Re: [PATCH net-next] ethtool: document PHY tunable callbacks
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Tue, 6 Apr 2021 17:23:59 -0700 you wrote: > Add missing kdoc for phy tunable callbacks. > > Signed-off-by: Jakub Kicinski > --- > Targetting net-next to avoid conflict with upcoming patches. > Should apply cleanly to both trees. > > [...] Here is the summary with links: - [net-next] ethtool: document PHY tunable callbacks https://git.kernel.org/netdev/net-next/c/56f15e2cb1f7 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH net-next] ethtool: document PHY tunable callbacks
On 4/6/2021 5:23 PM, Jakub Kicinski wrote: > Add missing kdoc for phy tunable callbacks. > > Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH net-next] ethtool: document PHY tunable callbacks
On Tue, Apr 06, 2021 at 05:23:59PM -0700, Jakub Kicinski wrote: > Add missing kdoc for phy tunable callbacks. > > Signed-off-by: Jakub Kicinski Reviewed-by: Andrew Lunn Andrew
[PATCH net 2/3] ethtool: document reserved fields in the uAPI
Add a note on expected handling of reserved fields,
and references to all kdocs. This fixes a bunch
of kdoc warnings.
Signed-off-by: Jakub Kicinski
---
include/uapi/linux/ethtool.h | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index dc87ba092891..c9c18e88c215 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -26,6 +26,14 @@
* have the same layout for 32-bit and 64-bit userland.
*/
+/* Note on reserved space.
+ * Reserved fields must not be accessed directly by user space because
+ * they may be replaced by a different field in the future. They must
+ * be initialized to zero before making the request, e.g. via memset
+ * of the entire structure or implicitly by not being set in a structure
+ * initializer.
+ */
+
/**
* struct ethtool_cmd - DEPRECATED, link control and status
* This structure is DEPRECATED, please use struct ethtool_link_settings.
@@ -67,6 +75,7 @@
* and other link features that the link partner advertised
* through autonegotiation; 0 if unknown or not applicable.
* Read-only.
+ * @reserved: Reserved for future use; see the note on reserved space.
*
* The link speed in Mbps is split between @speed and @speed_hi. Use
* the ethtool_cmd_speed() and ethtool_cmd_speed_set() functions to
@@ -155,6 +164,7 @@ static inline __u32 ethtool_cmd_speed(const struct
ethtool_cmd *ep)
* @bus_info: Device bus address. This should match the dev_name()
* string for the underlying bus device, if there is one. May be
* an empty string.
+ * @reserved2: Reserved for future use; see the note on reserved space.
* @n_priv_flags: Number of flags valid for %ETHTOOL_GPFLAGS and
* %ETHTOOL_SPFLAGS commands; also the number of strings in the
* %ETH_SS_PRIV_FLAGS set
@@ -356,6 +366,7 @@ struct ethtool_eeprom {
* @tx_lpi_timer: Time in microseconds the interface delays prior to asserting
* its tx lpi (after reaching 'idle' state). Effective only when eee
* was negotiated and tx_lpi_enabled was set.
+ * @reserved: Reserved for future use; see the note on reserved space.
*/
struct ethtool_eee {
__u32 cmd;
@@ -374,6 +385,7 @@ struct ethtool_eee {
* @cmd: %ETHTOOL_GMODULEINFO
* @type: Standard the module information conforms to %ETH_MODULE_SFF_
* @eeprom_len: Length of the eeprom
+ * @reserved: Reserved for future use; see the note on reserved space.
*
* This structure is used to return the information to
* properly size memory for a subsequent call to %ETHTOOL_GMODULEEEPROM.
@@ -701,6 +713,7 @@ struct ethtool_gstrings {
/**
* struct ethtool_sset_info - string set information
* @cmd: Command number = %ETHTOOL_GSSET_INFO
+ * @reserved: Reserved for future use; see the note on reserved space.
* @sset_mask: On entry, a bitmask of string sets to query, with bits
* numbered according to &enum ethtool_stringset. On return, a
* bitmask of those string sets queried that are supported.
@@ -745,6 +758,7 @@ enum ethtool_test_flags {
* @flags: A bitmask of flags from &enum ethtool_test_flags. Some
* flags may be set by the user on entry; others may be set by
* the driver on return.
+ * @reserved: Reserved for future use; see the note on reserved space.
* @len: On return, the number of test results
* @data: Array of test results
*
@@ -945,6 +959,7 @@ union ethtool_flow_union {
* @vlan_etype: VLAN EtherType
* @vlan_tci: VLAN tag control information
* @data: user defined data
+ * @padding: Reserved for future use; see the note on reserved space.
*
* Note, @vlan_etype, @vlan_tci, and @data are only valid if %FLOW_EXT
* is set in &struct ethtool_rx_flow_spec @flow_type.
@@ -1120,7 +1135,8 @@ struct ethtool_rxfh_indir {
* hardware hash key.
* @hfunc: Defines the current RSS hash function used by HW (or to be set to).
* Valid values are one of the %ETH_RSS_HASH_*.
- * @rsvd: Reserved for future extensions.
+ * @rsvd8: Reserved for future use; see the note on reserved space.
+ * @rsvd32: Reserved for future use; see the note on reserved space.
* @rss_config: RX ring/queue index for each hash value i.e., indirection table
* of @indir_size __u32 elements, followed by hash key of @key_size
* bytes.
@@ -1288,7 +1304,9 @@ struct ethtool_sfeatures {
* @so_timestamping: bit mask of the sum of the supported SO_TIMESTAMPING flags
* @phc_index: device index of the associated PHC, or -1 if there is none
* @tx_types: bit mask of the supported hwtstamp_tx_types enumeration values
+ * @tx_reserved: Reserved for future use; see the note on reserved space.
* @rx_filters: bit mask of the supported hwtstamp_rx_filters enumeration
values
+ * @rx_reserved: Reserved for future use; see the note on reserved space.
*
* The bits in the 'tx_types' and 'rx_filters' fields correspond to
* the 'hwtstamp_tx_types' and 'hwtstamp_rx_fi
[PATCH net-next] ethtool: document PHY tunable callbacks
Add missing kdoc for phy tunable callbacks.
Signed-off-by: Jakub Kicinski
---
Targetting net-next to avoid conflict with upcoming patches.
Should apply cleanly to both trees.
include/linux/ethtool.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 3583f7fc075c..5c631a298994 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -410,6 +410,8 @@ struct ethtool_pause_stats {
* @get_ethtool_phy_stats: Return extended statistics about the PHY device.
* This is only useful if the device maintains PHY statistics and
* cannot use the standard PHY library helpers.
+ * @get_phy_tunable: Read the value of a PHY tunable.
+ * @set_phy_tunable: Set the value of a PHY tunable.
*
* All operations are optional (i.e. the function pointer may be set
* to %NULL) and callers must take this into account. Callers must
--
2.30.2
Re: [PATCH net-next 3/3] dt-bindings: net: dsa: Document dsa,tag-protocol property
> Andrew, Vladimir: I will just list dsa and edsa for now. If it is needed > on other devices, people can add them to the list after they have tested > their drivers. Fair? O.K. Andrew
Re: [PATCH net-next 3/3] dt-bindings: net: dsa: Document dsa,tag-protocol property
On Sat, Mar 27, 2021 at 12:13, Rob Herring wrote: > On Fri, Mar 26, 2021 at 11:56:48AM +0100, Tobias Waldekranz wrote: >> The 'dsa,tag-protocol' is used to force a switch tree to use a >> particular tag protocol, typically because the Ethernet controller >> that it is connected to is not compatible with the default one. >> >> Signed-off-by: Tobias Waldekranz >> --- >> Documentation/devicetree/bindings/net/dsa/dsa.yaml | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml >> b/Documentation/devicetree/bindings/net/dsa/dsa.yaml >> index 8a3494db4d8d..5dcfab049aa2 100644 >> --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml >> +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml >> @@ -70,6 +70,13 @@ patternProperties: >>device is what the switch port is connected to >> $ref: /schemas/types.yaml#/definitions/phandle >> >> + dsa,tag-protocol: > > 'dsa' is not a vendor. It is not. The property is intended to be consumed by the vendor-independent driver. So should it be linux,tag-protocol? Just tag-protocol? >> +description: >> + Instead of the default, the switch will use this tag protocol >> if >> + possible. Useful when a device supports multiple protcols and >> + the default is incompatible with the Ethernet device. >> +$ref: /schemas/types.yaml#/definitions/string > > You need to define the possible strings. Alright. Andrew, Vladimir: I will just list dsa and edsa for now. If it is needed on other devices, people can add them to the list after they have tested their drivers. Fair? >> + >>phy-handle: true >> >>phy-mode: true >> -- >> 2.25.1 >>
Re: [PATCH net-next] net: document a side effect of ip_local_reserved_ports
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Thu, 1 Apr 2021 17:57:05 +0200 you wrote:
> If there is overlapp between ip_local_port_range and ip_local_reserved_ports
> with a huge reserved block, it will affect probability of selecting ephemeral
> ports, see file net/ipv4/inet_hashtables.c:723
>
> int __inet_hash_connect(
> ...
> for (i = 0; i < remaining; i += 2, port += 2) {
> if (unlikely(port >= high))
> port -= remaining;
> if (inet_is_local_reserved_port(net, port))
> continue;
>
> [...]
Here is the summary with links:
- [net-next] net: document a side effect of ip_local_reserved_ports
https://git.kernel.org/netdev/net-next/c/a7a80b17c750
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
[PATCH net-next] net: document a side effect of ip_local_reserved_ports
If there is overlapp between ip_local_port_range and
ip_local_reserved_ports with a huge reserved block, it will affect probability
of selecting ephemeral ports, see file net/ipv4/inet_hashtables.c:723
int __inet_hash_connect(
...
for (i = 0; i < remaining; i += 2, port += 2) {
if (unlikely(port >= high))
port -= remaining;
if (inet_is_local_reserved_port(net, port))
continue;
E.g. if there is reserved block of 1 ports, two ports right after this
block will be 5000 more likely selected than others.
If this was intended, we can/should add note into documentation as proposed
in this commit, otherwise we should think about different solution. One option
could be mapping table of continuous port ranges. Second option could be
letting user to modify step (port+=2) in above loop, e.g. using new sysctl
parameter.
Signed-off-by: Otto Hollmann
---
Documentation/networking/ip-sysctl.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/ip-sysctl.rst
b/Documentation/networking/ip-sysctl.rst
index c7952ac5bd2f..74c458d2686a 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -1073,7 +1073,9 @@ ip_local_reserved_ports - list of comma separated ranges
although this is redundant. However such a setting is useful
if later the port range is changed to a value that will
- include the reserved ports.
+ include the reserved ports. Also keep in mind, that overlapping
+ of these ranges may affect probability of selecting ephemeral
+ ports which are right after block of reserved ports.
Default: Empty
--
2.26.2
Re: [PATCH net-next] Documentation: net: Document resilient next-hop groups
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Mon, 29 Mar 2021 17:57:31 +0200 you wrote: > Add a document describing the principles behind resilient next-hop groups, > and some notes about how to configure and offload them. > > Suggested-by: David Ahern > Signed-off-by: Petr Machata > Reviewed-by: David Ahern > > [...] Here is the summary with links: - [net-next] Documentation: net: Document resilient next-hop groups https://git.kernel.org/netdev/net-next/c/87f2c6716f64 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH net-next] Documentation: net: Document resilient next-hop groups
On Mon, Mar 29, 2021 at 05:57:31PM +0200, Petr Machata wrote: > Add a document describing the principles behind resilient next-hop groups, > and some notes about how to configure and offload them. > > Suggested-by: David Ahern > Signed-off-by: Petr Machata > Reviewed-by: David Ahern Reviewed-by: Ido Schimmel
[PATCH net-next] Documentation: net: Document resilient next-hop groups
Add a document describing the principles behind resilient next-hop groups, and some notes about how to configure and offload them. Suggested-by: David Ahern Signed-off-by: Petr Machata Reviewed-by: David Ahern --- Notes: v1 (from an RFC shared privately): - Dropped a reference to a non-existent footnote [Ido] - Spell out consequences of flow redirection explicitly [Ido] - A handful of wording changes [Ido] - Kept David's R-b due to minor scope of the above fixes Documentation/networking/index.rst| 1 + .../networking/nexthop-group-resilient.rst| 293 ++ 2 files changed, 294 insertions(+) create mode 100644 Documentation/networking/nexthop-group-resilient.rst diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index b8a29997d433..e9ce55992aa9 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -76,6 +76,7 @@ Contents: netdevices netfilter-sysctl netif-msg + nexthop-group-resilient nf_conntrack-sysctl nf_flowtable openvswitch diff --git a/Documentation/networking/nexthop-group-resilient.rst b/Documentation/networking/nexthop-group-resilient.rst new file mode 100644 index ..fabecee24d85 --- /dev/null +++ b/Documentation/networking/nexthop-group-resilient.rst @@ -0,0 +1,293 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +Resilient Next-hop Groups += + +Resilient groups are a type of next-hop group that is aimed at minimizing +disruption in flow routing across changes to the group composition and +weights of constituent next hops. + +The idea behind resilient hashing groups is best explained in contrast to +the legacy multipath next-hop group, which uses the hash-threshold +algorithm, described in RFC 2992. + +To select a next hop, hash-threshold algorithm first assigns a range of +hashes to each next hop in the group, and then selects the next hop by +comparing the SKB hash with the individual ranges. When a next hop is +removed from the group, the ranges are recomputed, which leads to +reassignment of parts of hash space from one next hop to another. RFC 2992 +illustrates it thus:: + + +---+---+---+---+---+ + | 1 | 2 | 3 | 4 | 5 | + +---+-+-+---+---+-+-+---+ + |1|2|4|5| + +-+-+-+-+ + + Before and after deletion of next hop 3 + under the hash-threshold algorithm. + +Note how next hop 2 gave up part of the hash space in favor of next hop 1, +and 4 in favor of 5. While there will usually be some overlap between the +previous and the new distribution, some traffic flows change the next hop +that they resolve to. + +If a multipath group is used for load-balancing between multiple servers, +this hash space reassignment causes an issue that packets from a single +flow suddenly end up arriving at a server that does not expect them. This +can result in TCP connections being reset. + +If a multipath group is used for load-balancing among available paths to +the same server, the issue is that different latencies and reordering along +the way causes the packets to arrive in the wrong order, resulting in +degraded application performance. + +To mitigate the above-mentioned flow redirection, resilient next-hop groups +insert another layer of indirection between the hash space and its +constituent next hops: a hash table. The selection algorithm uses SKB hash +to choose a hash table bucket, then reads the next hop that this bucket +contains, and forwards traffic there. + +This indirection brings an important feature. In the hash-threshold +algorithm, the range of hashes associated with a next hop must be +continuous. With a hash table, mapping between the hash table buckets and +the individual next hops is arbitrary. Therefore when a next hop is deleted +the buckets that held it are simply reassigned to other next hops:: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|1|1|1|2|2|2|2|3|3|3|3|4|4|4|4|5|5|5|5| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +v v v v + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|1|1|1|2|2|2|2|1|2|4|5|4|4|4|4|5|5|5|5| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Before and after deletion of next hop 3 + under the resilient hashing algorithm. + +When weights of next hops in a group are altered, it may be possible to +choose a subset of buckets that are currently not used for forwarding +traffic, and use those to satisfy the new next-hop distribution demands, +keeping the "busy" buckets intact. This way, established flows are ideally +kept being forwarded to the same endpoints through the same paths as before +the next-hop group change. + +Algorithm +--
Re: [PATCH net-next 3/3] dt-bindings: net: dsa: Document dsa,tag-protocol property
On Fri, Mar 26, 2021 at 11:56:48AM +0100, Tobias Waldekranz wrote: > The 'dsa,tag-protocol' is used to force a switch tree to use a > particular tag protocol, typically because the Ethernet controller > that it is connected to is not compatible with the default one. > > Signed-off-by: Tobias Waldekranz > --- > Documentation/devicetree/bindings/net/dsa/dsa.yaml | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > index 8a3494db4d8d..5dcfab049aa2 100644 > --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > @@ -70,6 +70,13 @@ patternProperties: >device is what the switch port is connected to > $ref: /schemas/types.yaml#/definitions/phandle > > + dsa,tag-protocol: 'dsa' is not a vendor. > +description: > + Instead of the default, the switch will use this tag protocol > if > + possible. Useful when a device supports multiple protcols and > + the default is incompatible with the Ethernet device. > +$ref: /schemas/types.yaml#/definitions/string You need to define the possible strings. > + >phy-handle: true > >phy-mode: true > -- > 2.25.1 >
[PATCH net-next 3/3] ethtool: document the enum values not defines
kdoc does not have good support for documenting defines,
and we can't abuse the enum documentation because it
generates warnings.
Signed-off-by: Jakub Kicinski
---
include/uapi/linux/ethtool.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 9a47c3efd8ca..868b513d4f54 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1414,16 +1414,16 @@ struct ethtool_fecparam {
/**
* enum ethtool_fec_config_bits - flags definition of ethtool_fec_configuration
- * @ETHTOOL_FEC_NONE: FEC mode configuration is not supported. Should not
- * be used together with other bits. GET only.
- * @ETHTOOL_FEC_AUTO: Select default/best FEC mode automatically, usually based
- * link mode and SFP parameters read from module's EEPROM.
- * This bit does _not_ mean autonegotiation.
- * @ETHTOOL_FEC_OFF: No FEC Mode
- * @ETHTOOL_FEC_RS: Reed-Solomon FEC Mode
- * @ETHTOOL_FEC_BASER: Base-R/Reed-Solomon FEC Mode
- * @ETHTOOL_FEC_LLRS: Low Latency Reed Solomon FEC Mode (25G/50G Ethernet
- * Consortium)
+ * @ETHTOOL_FEC_NONE_BIT: FEC mode configuration is not supported. Should not
+ * be used together with other bits. GET only.
+ * @ETHTOOL_FEC_AUTO_BIT: Select default/best FEC mode automatically, usually
+ * based link mode and SFP parameters read from module's
+ * EEPROM. This bit does _not_ mean autonegotiation.
+ * @ETHTOOL_FEC_OFF_BIT: No FEC Mode
+ * @ETHTOOL_FEC_RS_BIT: Reed-Solomon FEC Mode
+ * @ETHTOOL_FEC_BASER_BIT: Base-R/Reed-Solomon FEC Mode
+ * @ETHTOOL_FEC_LLRS_BIT: Low Latency Reed Solomon FEC Mode (25G/50G Ethernet
+ * Consortium)
*/
enum ethtool_fec_config_bits {
ETHTOOL_FEC_NONE_BIT,
--
2.30.2
Re: [PATCH net-next v4 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
On Thu, Mar 25, 2021 at 06:04:37PM -0600, Robert Hancock wrote: > Update DT bindings to describe all of the clocks that the axienet > driver will now be able to make use of. > > Acked-by: Rob Herring > Signed-off-by: Robert Hancock Reviewed-by: Andrew Lunn Andrew
[PATCH net-next 3/3] dt-bindings: net: dsa: Document dsa,tag-protocol property
The 'dsa,tag-protocol' is used to force a switch tree to use a particular tag protocol, typically because the Ethernet controller that it is connected to is not compatible with the default one. Signed-off-by: Tobias Waldekranz --- Documentation/devicetree/bindings/net/dsa/dsa.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml index 8a3494db4d8d..5dcfab049aa2 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml @@ -70,6 +70,13 @@ patternProperties: device is what the switch port is connected to $ref: /schemas/types.yaml#/definitions/phandle + dsa,tag-protocol: +description: + Instead of the default, the switch will use this tag protocol if + possible. Useful when a device supports multiple protcols and + the default is incompatible with the Ethernet device. +$ref: /schemas/types.yaml#/definitions/string + phy-handle: true phy-mode: true -- 2.25.1
[PATCH net-next v4 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
Update DT bindings to describe all of the clocks that the axienet driver will now be able to make use of. Acked-by: Rob Herring Signed-off-by: Robert Hancock --- .../bindings/net/xilinx_axienet.txt | 25 ++- 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt b/Documentation/devicetree/bindings/net/xilinx_axienet.txt index 2cd452419ed0..b8e4894bc634 100644 --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt @@ -42,11 +42,23 @@ Optional properties: support both 1000BaseX and SGMII modes. If set, the phy-mode should be set to match the mode selected on core reset (i.e. by the basex_or_sgmii core input line). -- clocks : AXI bus clock for the device. Refer to common clock bindings. - Used to calculate MDIO clock divisor. If not specified, it is - auto-detected from the CPU clock (but only on platforms where - this is possible). New device trees should specify this - the - auto detection is only for backward compatibility. +- clock-names: Tuple listing input clock names. Possible clocks: + s_axi_lite_clk: Clock for AXI register slave interface + axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces + ref_clk: Ethernet reference clock, used by signal delay + primitives and transceivers + mgt_clk: MGT reference clock (used by optional internal + PCS/PMA PHY) + + Note that if s_axi_lite_clk is not specified by name, the + first clock of any name is used for this. If that is also not + specified, the clock rate is auto-detected from the CPU clock + (but only on platforms where this is possible). New device + trees should specify all applicable clocks by name - the + fallbacks to an unnamed clock or to CPU clock are only for + backward compatibility. +- clocks:Phandles to input clocks matching clock-names. Refer to common + clock bindings. - axistream-connected: Reference to another node which contains the resources for the AXI DMA controller used by this device. If this is specified, the DMA-related resources from that @@ -62,7 +74,8 @@ Example: device_type = "network"; interrupt-parent = <µblaze_0_axi_intc>; interrupts = <2 0 1>; - clocks = <&axi_clk>; + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; phy-mode = "mii"; reg = <0x40c0 0x4 0x50c0 0x4>; xlnx,rxcsum = <0x2>; -- 2.27.0
Re: [PATCH net-next v3 v3 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
On Wed, Mar 24, 2021 at 11:19 AM Robert Hancock wrote: > > On Wed, 2021-03-24 at 11:08 -0600, Rob Herring wrote: > > On Fri, Mar 12, 2021 at 01:52:13PM -0600, Robert Hancock wrote: > > > Update DT bindings to describe all of the clocks that the axienet > > > driver will now be able to make use of. > > > > > > Signed-off-by: Robert Hancock > > > --- > > > .../bindings/net/xilinx_axienet.txt | 25 ++- > > > 1 file changed, 19 insertions(+), 6 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > > b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > > index 2cd452419ed0..b8e4894bc634 100644 > > > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > > @@ -42,11 +42,23 @@ Optional properties: > > > support both 1000BaseX and SGMII modes. If set, the phy-mode > > > should be set to match the mode selected on core reset (i.e. > > > by the basex_or_sgmii core input line). > > > -- clocks : AXI bus clock for the device. Refer to common clock > > > bindings. > > > - Used to calculate MDIO clock divisor. If not specified, it > > > is > > > - auto-detected from the CPU clock (but only on platforms > > > where > > > - this is possible). New device trees should specify this - > > > the > > > - auto detection is only for backward compatibility. > > > +- clock-names: Tuple listing input clock names. Possible clocks: > > > + s_axi_lite_clk: Clock for AXI register slave interface > > > + axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS > > > interfaces > > > + ref_clk: Ethernet reference clock, used by signal delay > > > + primitives and transceivers > > > + mgt_clk: MGT reference clock (used by optional internal > > > + PCS/PMA PHY) > > > > '_clk' is redundant. > > True, but there are existing device trees which already referenced these names > because those are what was used by the Xilinx version of this driver and hence > the Xilinx device tree generation software. So for compatibility I think we > are > kind of stuck with those names.. upstream? If not, then it doesn't matter what downstream is doing. However, this isn't that important, so it's fine. Acked-by: Rob Herring
Re: [PATCH net-next v3 v3 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
On Wed, 2021-03-24 at 11:08 -0600, Rob Herring wrote: > On Fri, Mar 12, 2021 at 01:52:13PM -0600, Robert Hancock wrote: > > Update DT bindings to describe all of the clocks that the axienet > > driver will now be able to make use of. > > > > Signed-off-by: Robert Hancock > > --- > > .../bindings/net/xilinx_axienet.txt | 25 ++- > > 1 file changed, 19 insertions(+), 6 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > index 2cd452419ed0..b8e4894bc634 100644 > > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > @@ -42,11 +42,23 @@ Optional properties: > > support both 1000BaseX and SGMII modes. If set, the phy-mode > > should be set to match the mode selected on core reset (i.e. > > by the basex_or_sgmii core input line). > > -- clocks : AXI bus clock for the device. Refer to common clock bindings. > > - Used to calculate MDIO clock divisor. If not specified, it is > > - auto-detected from the CPU clock (but only on platforms where > > - this is possible). New device trees should specify this - the > > - auto detection is only for backward compatibility. > > +- clock-names: Tuple listing input clock names. Possible clocks: > > + s_axi_lite_clk: Clock for AXI register slave interface > > + axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS > > interfaces > > + ref_clk: Ethernet reference clock, used by signal delay > > + primitives and transceivers > > + mgt_clk: MGT reference clock (used by optional internal > > + PCS/PMA PHY) > > '_clk' is redundant. True, but there are existing device trees which already referenced these names because those are what was used by the Xilinx version of this driver and hence the Xilinx device tree generation software. So for compatibility I think we are kind of stuck with those names.. > > > + > > + Note that if s_axi_lite_clk is not specified by name, the > > + first clock of any name is used for this. If that is also not > > + specified, the clock rate is auto-detected from the CPU clock > > + (but only on platforms where this is possible). New device > > + trees should specify all applicable clocks by name - the > > + fallbacks to an unnamed clock or to CPU clock are only for > > + backward compatibility. > > +- clocks:Phandles to input clocks matching clock-names. Refer to > > common > > + clock bindings. > > - axistream-connected: Reference to another node which contains the > > resources > >for the AXI DMA controller used by this device. > >If this is specified, the DMA-related resources from > > that > > @@ -62,7 +74,8 @@ Example: > > device_type = "network"; > > interrupt-parent = <µblaze_0_axi_intc>; > > interrupts = <2 0 1>; > > - clocks = <&axi_clk>; > > + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", > > "mgt_clk"; > > + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, > > <&mgt_clk>; > > phy-mode = "mii"; > > reg = <0x40c0 0x4 0x50c0 0x4>; > > xlnx,rxcsum = <0x2>; > > -- > > 2.27.0 > > -- Robert Hancock Senior Hardware Designer, Calian Advanced Technologies www.calian.com
Re: [PATCH net-next v3 v3 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
On Fri, Mar 12, 2021 at 01:52:13PM -0600, Robert Hancock wrote: > Update DT bindings to describe all of the clocks that the axienet > driver will now be able to make use of. > > Signed-off-by: Robert Hancock > --- > .../bindings/net/xilinx_axienet.txt | 25 ++- > 1 file changed, 19 insertions(+), 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > index 2cd452419ed0..b8e4894bc634 100644 > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > @@ -42,11 +42,23 @@ Optional properties: > support both 1000BaseX and SGMII modes. If set, the phy-mode > should be set to match the mode selected on core reset (i.e. > by the basex_or_sgmii core input line). > -- clocks : AXI bus clock for the device. Refer to common clock bindings. > - Used to calculate MDIO clock divisor. If not specified, it is > - auto-detected from the CPU clock (but only on platforms where > - this is possible). New device trees should specify this - the > - auto detection is only for backward compatibility. > +- clock-names: Tuple listing input clock names. Possible clocks: > + s_axi_lite_clk: Clock for AXI register slave interface > + axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces > + ref_clk: Ethernet reference clock, used by signal delay > +primitives and transceivers > + mgt_clk: MGT reference clock (used by optional internal > +PCS/PMA PHY) '_clk' is redundant. > + > + Note that if s_axi_lite_clk is not specified by name, the > + first clock of any name is used for this. If that is also not > + specified, the clock rate is auto-detected from the CPU clock > + (but only on platforms where this is possible). New device > + trees should specify all applicable clocks by name - the > + fallbacks to an unnamed clock or to CPU clock are only for > + backward compatibility. > +- clocks: Phandles to input clocks matching clock-names. Refer to common > + clock bindings. > - axistream-connected: Reference to another node which contains the resources > for the AXI DMA controller used by this device. > If this is specified, the DMA-related resources from that > @@ -62,7 +74,8 @@ Example: > device_type = "network"; > interrupt-parent = <µblaze_0_axi_intc>; > interrupts = <2 0 1>; > - clocks = <&axi_clk>; > + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", > "mgt_clk"; > + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; > phy-mode = "mii"; > reg = <0x40c0 0x4 0x50c0 0x4>; > xlnx,rxcsum = <0x2>; > -- > 2.27.0 >
[PATCH v2 net-next 06/12] Documentation: networking: dsa: document the port_bridge_flags method
From: Vladimir Oltean The documentation was already lagging behind by not mentioning the old version of port_bridge_flags (port_set_egress_floods). So now we are skipping one step and just explaining how a DSA driver should configure address learning and flooding settings. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Documentation/networking/dsa/dsa.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index b90a852e5329..9c287dfd3c45 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -619,6 +619,17 @@ Bridge layer computing a STP state change based on current and asked parameters and perform the relevant ageing based on the intersection results +- ``port_bridge_flags``: bridge layer function invoked when a port must + configure its settings for e.g. flooding of unknown traffic or source address + learning. The switch driver is responsible for initial setup of the + standalone ports with address learning disabled and egress flooding of all + types of traffic, then the DSA core notifies of any change to the bridge port + flags when the port joins and leaves a bridge. DSA does not currently manage + the bridge port flags for the CPU port. The assumption is that address + learning should be statically enabled (if supported by the hardware) on the + CPU port, and flooding towards the CPU port should also be enabled, due to a + lack of an explicit address filtering mechanism in the DSA core. + Bridge VLAN filtering - -- 2.25.1
[PATCH net-next v3 v3 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
Update DT bindings to describe all of the clocks that the axienet driver will now be able to make use of. Signed-off-by: Robert Hancock --- .../bindings/net/xilinx_axienet.txt | 25 ++- 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt b/Documentation/devicetree/bindings/net/xilinx_axienet.txt index 2cd452419ed0..b8e4894bc634 100644 --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt @@ -42,11 +42,23 @@ Optional properties: support both 1000BaseX and SGMII modes. If set, the phy-mode should be set to match the mode selected on core reset (i.e. by the basex_or_sgmii core input line). -- clocks : AXI bus clock for the device. Refer to common clock bindings. - Used to calculate MDIO clock divisor. If not specified, it is - auto-detected from the CPU clock (but only on platforms where - this is possible). New device trees should specify this - the - auto detection is only for backward compatibility. +- clock-names: Tuple listing input clock names. Possible clocks: + s_axi_lite_clk: Clock for AXI register slave interface + axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces + ref_clk: Ethernet reference clock, used by signal delay + primitives and transceivers + mgt_clk: MGT reference clock (used by optional internal + PCS/PMA PHY) + + Note that if s_axi_lite_clk is not specified by name, the + first clock of any name is used for this. If that is also not + specified, the clock rate is auto-detected from the CPU clock + (but only on platforms where this is possible). New device + trees should specify all applicable clocks by name - the + fallbacks to an unnamed clock or to CPU clock are only for + backward compatibility. +- clocks:Phandles to input clocks matching clock-names. Refer to common + clock bindings. - axistream-connected: Reference to another node which contains the resources for the AXI DMA controller used by this device. If this is specified, the DMA-related resources from that @@ -62,7 +74,8 @@ Example: device_type = "network"; interrupt-parent = <µblaze_0_axi_intc>; interrupts = <2 0 1>; - clocks = <&axi_clk>; + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; phy-mode = "mii"; reg = <0x40c0 0x4 0x50c0 0x4>; xlnx,rxcsum = <0x2>; -- 2.27.0
Re: [PATCH net-next v2 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
On Fri, 2021-03-12 at 18:39 +, Radhey Shyam Pandey wrote: > > -Original Message- > > From: Robert Hancock > > Sent: Friday, March 12, 2021 11:13 PM > > To: Radhey Shyam Pandey ; da...@davemloft.net; > > k...@kernel.org > > Cc: netdev@vger.kernel.org; devicet...@vger.kernel.org; Robert Hancock > > > > Subject: [PATCH net-next v2 1/2] dt-bindings: net: xilinx_axienet: Document > > additional clocks > > > > Update DT bindings to describe all of the clocks that the axienet driver > > will > > now be able to make use of. > > > > Signed-off-by: Robert Hancock > > --- > > .../bindings/net/xilinx_axienet.txt | 25 ++- > > 1 file changed, 19 insertions(+), 6 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > index 2cd452419ed0..5df5ba449b8f 100644 > > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > @@ -42,11 +42,23 @@ Optional properties: > > support both 1000BaseX and SGMII modes. If set, the phy- > > mode > > should be set to match the mode selected on core reset > > (i.e. > > by the basex_or_sgmii core input line). > > -- clocks : AXI bus clock for the device. Refer to common clock > > bindings. > > - Used to calculate MDIO clock divisor. If not specified, it is > > - auto-detected from the CPU clock (but only on platforms > > where > > - this is possible). New device trees should specify this - the > > - auto detection is only for backward compatibility. > > +- clock-names: Tuple listing input clock names. Possible clocks: > > + s_axi_lite_clk: Clock for AXI register slave interface > > + axis_clk: AXI stream clock for DMA block > > Description for axis_clk should be- > axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces. Missed this, will add in. > In this patch I assume we are only adding additional clocks for > 1G ethernet subsystem. For dma clocking support we need to add > more clocks and better to add them in a separate patch. Please refer to > xilinx tree. Correct, here I am just focusing on clocks which are connected to the Ethernet core itself. It seems the DMA core clocks would be more difficult since those clocks are attached to the DMA node in the device tree (based on the Vitis- generated PL device tree content) and not to the node belonging to the Ethernet platform device. Looking at the Xilinx version of this driver, it seems to implement retrieving these clocks, but it is using devm_clk_get on the same platform device used for the Ethernet core, so I am confused how that is working (or maybe it isn't?) The DMA core clocks are less of a concern for us, since (at least in our design) they are driven by the same clock source as one of the Ethernet core clocks, so they should always be enabled when the Ethernet core clocks are enabled. > > + ref_clk: Ethernet reference clock, used by signal delay > > + primitives and transceivers > > + mgt_clk: MGT reference clock (used by optional internal > > + PCS/PMA PHY) > > + > > + Note that if s_axi_lite_clk is not specified by name, the > > + first clock of any name is used for this. If that is also not > > + specified, the clock rate is auto-detected from the CPU > > clock > > + (but only on platforms where this is possible). New device > > + trees should specify all applicable clocks by name - the > > + fallbacks to an unnamed clock or to CPU clock are only for > > + backward compatibility. > > +- clocks:Phandles to input clocks matching clock-names. Refer to > > common > > + clock bindings. > > - axistream-connected: Reference to another node which contains the > > resources > >for the AXI DMA controller used by this device. > >If this is specified, the DMA-related resources from > > that > > @@ -62,7 +74,8 @@ Example: > > device_type = "network"; > > interrupt-parent = <µblaze_0_axi_intc>; > > interrupts = <2 0 1>; > > - clocks = <&axi_clk>; > > + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", > > "mgt_clk"; > > + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, > > <&mgt_clk>; > > phy-mode = "mii"; > > reg = <0x40c0 0x4 0x50c0 0x4>; > > xlnx,rxcsum = <0x2>; > > -- > > 2.27.0
RE: [PATCH net-next v2 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
> -Original Message- > From: Robert Hancock > Sent: Friday, March 12, 2021 11:13 PM > To: Radhey Shyam Pandey ; da...@davemloft.net; > k...@kernel.org > Cc: netdev@vger.kernel.org; devicet...@vger.kernel.org; Robert Hancock > > Subject: [PATCH net-next v2 1/2] dt-bindings: net: xilinx_axienet: Document > additional clocks > > Update DT bindings to describe all of the clocks that the axienet driver will > now be able to make use of. > > Signed-off-by: Robert Hancock > --- > .../bindings/net/xilinx_axienet.txt | 25 ++- > 1 file changed, 19 insertions(+), 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > index 2cd452419ed0..5df5ba449b8f 100644 > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > @@ -42,11 +42,23 @@ Optional properties: > support both 1000BaseX and SGMII modes. If set, the phy- > mode > should be set to match the mode selected on core reset > (i.e. > by the basex_or_sgmii core input line). > -- clocks : AXI bus clock for the device. Refer to common clock > bindings. > - Used to calculate MDIO clock divisor. If not specified, it is > - auto-detected from the CPU clock (but only on platforms > where > - this is possible). New device trees should specify this - the > - auto detection is only for backward compatibility. > +- clock-names: Tuple listing input clock names. Possible clocks: > + s_axi_lite_clk: Clock for AXI register slave interface > + axis_clk: AXI stream clock for DMA block Description for axis_clk should be- axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces. In this patch I assume we are only adding additional clocks for 1G ethernet subsystem. For dma clocking support we need to add more clocks and better to add them in a separate patch. Please refer to xilinx tree. > + ref_clk: Ethernet reference clock, used by signal delay > +primitives and transceivers > + mgt_clk: MGT reference clock (used by optional internal > +PCS/PMA PHY) > + > + Note that if s_axi_lite_clk is not specified by name, the > + first clock of any name is used for this. If that is also not > + specified, the clock rate is auto-detected from the CPU > clock > + (but only on platforms where this is possible). New device > + trees should specify all applicable clocks by name - the > + fallbacks to an unnamed clock or to CPU clock are only for > + backward compatibility. > +- clocks: Phandles to input clocks matching clock-names. Refer to > common > + clock bindings. > - axistream-connected: Reference to another node which contains the > resources > for the AXI DMA controller used by this device. > If this is specified, the DMA-related resources from that > @@ -62,7 +74,8 @@ Example: > device_type = "network"; > interrupt-parent = <µblaze_0_axi_intc>; > interrupts = <2 0 1>; > - clocks = <&axi_clk>; > + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", > "mgt_clk"; > + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, > <&mgt_clk>; > phy-mode = "mii"; > reg = <0x40c0 0x4 0x50c0 0x4>; > xlnx,rxcsum = <0x2>; > -- > 2.27.0
[PATCH net-next v2 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
Update DT bindings to describe all of the clocks that the axienet driver will now be able to make use of. Signed-off-by: Robert Hancock --- .../bindings/net/xilinx_axienet.txt | 25 ++- 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt b/Documentation/devicetree/bindings/net/xilinx_axienet.txt index 2cd452419ed0..5df5ba449b8f 100644 --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt @@ -42,11 +42,23 @@ Optional properties: support both 1000BaseX and SGMII modes. If set, the phy-mode should be set to match the mode selected on core reset (i.e. by the basex_or_sgmii core input line). -- clocks : AXI bus clock for the device. Refer to common clock bindings. - Used to calculate MDIO clock divisor. If not specified, it is - auto-detected from the CPU clock (but only on platforms where - this is possible). New device trees should specify this - the - auto detection is only for backward compatibility. +- clock-names: Tuple listing input clock names. Possible clocks: + s_axi_lite_clk: Clock for AXI register slave interface + axis_clk: AXI stream clock for DMA block + ref_clk: Ethernet reference clock, used by signal delay + primitives and transceivers + mgt_clk: MGT reference clock (used by optional internal + PCS/PMA PHY) + + Note that if s_axi_lite_clk is not specified by name, the + first clock of any name is used for this. If that is also not + specified, the clock rate is auto-detected from the CPU clock + (but only on platforms where this is possible). New device + trees should specify all applicable clocks by name - the + fallbacks to an unnamed clock or to CPU clock are only for + backward compatibility. +- clocks:Phandles to input clocks matching clock-names. Refer to common + clock bindings. - axistream-connected: Reference to another node which contains the resources for the AXI DMA controller used by this device. If this is specified, the DMA-related resources from that @@ -62,7 +74,8 @@ Example: device_type = "network"; interrupt-parent = <µblaze_0_axi_intc>; interrupts = <2 0 1>; - clocks = <&axi_clk>; + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; phy-mode = "mii"; reg = <0x40c0 0x4 0x50c0 0x4>; xlnx,rxcsum = <0x2>; -- 2.27.0
RE: [PATCH net-next 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
Thanks for the patch. > -Original Message- > From: Robert Hancock > Sent: Friday, March 12, 2021 1:41 AM > To: Radhey Shyam Pandey ; da...@davemloft.net; > k...@kernel.org > Cc: netdev@vger.kernel.org; devicet...@vger.kernel.org; Robert Hancock > > Subject: [PATCH net-next 1/2] dt-bindings: net: xilinx_axienet: Document > additional clocks > > Update DT bindings to describe all of the clocks that the axienet driver will > now be able to make use of. > > Signed-off-by: Robert Hancock > --- > .../bindings/net/xilinx_axienet.txt | 23 ++- > 1 file changed, 17 insertions(+), 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > index 2cd452419ed0..1ee1c6c5fc66 100644 > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > @@ -42,11 +42,21 @@ Optional properties: > support both 1000BaseX and SGMII modes. If set, the phy- > mode > should be set to match the mode selected on core reset > (i.e. > by the basex_or_sgmii core input line). > -- clocks : AXI bus clock for the device. Refer to common clock > bindings. > - Used to calculate MDIO clock divisor. If not specified, it is > - auto-detected from the CPU clock (but only on platforms > where > - this is possible). New device trees should specify this - the > - auto detection is only for backward compatibility. > +- clock-names: Tuple listing input clock names. Possible clocks: > + s_axi_lite_clk: Clock for AXI register slave interface > + axis_clk: AXI stream clock for DMA block Based on PG138 , axis_clk is AXI4-Stream clock for TXD RXD TXC and RXS interfaces. In this patch I assume we are only adding additional clocks for 1G ethernet subsystem. For dma clocking support we need to add more clocks and better to add it in separate patch. Please refer to xilinx tree. > + ref_clk: Ethernet reference clock Better to add some more description - used by signal delay primitives and transceivers. > + mgt_clk: MGT reference clock (used by internal PCS/PMA > PHY) (used by optional internal PCS/PMA) > + > + Note that if s_axi_lite_clk is not specified by name, the > + first clock of any name is used for this. If that is also not > + specified, the clock rate is auto-detected from the CPU > clock > + (but only on platforms where this is possible). New device > + trees should specify all applicable clocks by name - the > + fallbacks to an unnamed clock or to CPU clock are only for > + backward compatibility. > +- clocks: Phandles to input clocks matching clock-names. Refer to > common > + clock bindings. > - axistream-connected: Reference to another node which contains the > resources > for the AXI DMA controller used by this device. > If this is specified, the DMA-related resources from that > @@ -62,7 +72,8 @@ Example: > device_type = "network"; > interrupt-parent = <µblaze_0_axi_intc>; > interrupts = <2 0 1>; > - clocks = <&axi_clk>; > + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", > "mgt_clk"; > + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, > <&mgt_clk>; > phy-mode = "mii"; > reg = <0x40c0 0x4 0x50c0 0x4>; > xlnx,rxcsum = <0x2>; > -- > 2.27.0
[PATCH net-next 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
Update DT bindings to describe all of the clocks that the axienet driver will now be able to make use of. Signed-off-by: Robert Hancock --- .../bindings/net/xilinx_axienet.txt | 23 ++- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt b/Documentation/devicetree/bindings/net/xilinx_axienet.txt index 2cd452419ed0..1ee1c6c5fc66 100644 --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt @@ -42,11 +42,21 @@ Optional properties: support both 1000BaseX and SGMII modes. If set, the phy-mode should be set to match the mode selected on core reset (i.e. by the basex_or_sgmii core input line). -- clocks : AXI bus clock for the device. Refer to common clock bindings. - Used to calculate MDIO clock divisor. If not specified, it is - auto-detected from the CPU clock (but only on platforms where - this is possible). New device trees should specify this - the - auto detection is only for backward compatibility. +- clock-names: Tuple listing input clock names. Possible clocks: + s_axi_lite_clk: Clock for AXI register slave interface + axis_clk: AXI stream clock for DMA block + ref_clk: Ethernet reference clock + mgt_clk: MGT reference clock (used by internal PCS/PMA PHY) + + Note that if s_axi_lite_clk is not specified by name, the + first clock of any name is used for this. If that is also not + specified, the clock rate is auto-detected from the CPU clock + (but only on platforms where this is possible). New device + trees should specify all applicable clocks by name - the + fallbacks to an unnamed clock or to CPU clock are only for + backward compatibility. +- clocks:Phandles to input clocks matching clock-names. Refer to common + clock bindings. - axistream-connected: Reference to another node which contains the resources for the AXI DMA controller used by this device. If this is specified, the DMA-related resources from that @@ -62,7 +72,8 @@ Example: device_type = "network"; interrupt-parent = <µblaze_0_axi_intc>; interrupts = <2 0 1>; - clocks = <&axi_clk>; + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; phy-mode = "mii"; reg = <0x40c0 0x4 0x50c0 0x4>; xlnx,rxcsum = <0x2>; -- 2.27.0
[net-next PATCH v7 01/16] Documentation: ACPI: DSD: Document MDIO PHY
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson
---
Changes in v7: None
Changes in v6:
- Minor cleanup
Changes in v5:
- More cleanup
Changes in v4:
- More cleanup
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 133 ++
1 file changed, 133 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst
b/Documentation/firmware-guide/acpi/dsd/phy.rst
new file mode 100644
index ..7d01ae8b3cc6
--- /dev/null
+++ b/Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+MDIO bus and PHYs in ACPI
+=
+
+The PHYs on an MDIO bus [1] are probed and registered using
+fwnode_mdiobus_register_phy().
+
+Later, for connecting these PHYs to their respective MACs, the PHYs registered
+on the MDIO bus have to be referenced.
+
+This document introduces two _DSD properties that are to be used
+for connecting PHYs on the MDIO bus [3] to the MAC layer.
+
+These properties are defined in accordance with the "Device
+Properties UUID For _DSD" [2] document and the
+daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
+Data Descriptors containing them.
+
+phy-handle
+--
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
+
+::
+ Scope(\_SB.MDI0)
+ {
+Device(PHY1) {
+ Name (_ADR, 0x1)
+} // end of PHY1
+
+Device(PHY2) {
+ Name (_ADR, 0x2)
+} // end of PHY2
+ }
+
+Later, during the MAC driver initialization, the registered PHY devices
+have to be retrieved from the MDIO bus. For this, the MAC driver needs
+references to the previously registered PHYs which are provided
+as device object references (e.g. \_SB.MDI0.PHY1).
+
+phy-mode
+
+The "phy-mode" _DSD property is used to describe the connection to
+the PHY. The valid values for "phy-mode" are defined in [4].
+
+The following ASL example illustrates the usage of these properties.
+
+DSDT entry for MDIO node
+
+
+The MDIO bus has an SoC component (MDIO controller) and a platform
+component (PHYs on the MDIO bus).
+
+a) Silicon Component
+This node describes the MDIO controller, MDI0
+-
+::
+ Scope(_SB)
+ {
+ Device(MDI0) {
+ Name(_HID, "NXP0006")
+ Name(_CCA, 1)
+ Name(_UID, 0)
+ Name(_CRS, ResourceTemplate() {
+ Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
+ Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
+ {
+MDI0_IT
+ }
+ }) // end of _CRS for MDI0
+ } // end of MDI0
+ }
+
+b) Platform Component
+The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0
+-
+::
+ Scope(\_SB.MDI0)
+ {
+ Device(PHY1) {
+ Name (_ADR, 0x1)
+ } // end of PHY1
+
+ Device(PHY2) {
+ Name (_ADR, 0x2)
+ } // end of PHY2
+ }
+
+DSDT entries representing MAC nodes
+---
+
+Below are the MAC nodes where PHY nodes are referenced.
+phy-mode and phy-handle are used as explained earlier.
+--
+::
+ Scope(\_SB.MCE0.PR17)
+ {
+ Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package (2) {"phy-mode", "rgmii-id"},
+Package (2) {"phy-handle", \_SB.MDI0.PHY1}
+ }
+ })
+ }
+
+ Scope(\_SB.MCE0.PR18)
+ {
+ Name (_DSD, Package () {
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package () {
+ Package (2) {"phy-mode", "rgmii-id"},
+ Package (2) {"phy-handle", \_SB.MDI0.PHY2}}
+ }
+ })
+ }
+
+References
+==
+
+[1] Documentation/networking/phy.rst
+
+[2]
https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
+
+[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst
+
+[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml
--
2.17.1
Re: [PATCH v1 7/7] dt-bindings: net: qcom-ipa: Document qcom,msm8998-ipa compatible
On Thu, Feb 11, 2021 at 06:50:15PM +0100, AngeloGioacchino Del Regno wrote: > MSM8998 support has been added: document the new compatible. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > index b063c6c1077a..9dacd224b606 100644 > --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > @@ -46,6 +46,7 @@ properties: > oneOf: >- items: >- enum: > + - "qcom,msm8998-ipa" Also, don't need quotes on these. >- "qcom,sdm845-ipa" >- "qcom,sc7180-ipa" > > -- > 2.30.0 >
Re: [PATCH v1 6/7] dt-bindings: net: qcom-ipa: Document qcom,sc7180-ipa compatible
On Thu, Feb 11, 2021 at 06:50:14PM +0100, AngeloGioacchino Del Regno wrote: > The driver supports SC7180, but the binding was not documented. > Just add it. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > index 8a2d12644675..b063c6c1077a 100644 > --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > @@ -43,7 +43,11 @@ description: > > properties: >compatible: > -const: "qcom,sdm845-ipa" > +oneOf: > + - items: > + - enum: Just enum, you don't need oneOf when only 1. And items is implied when only 1 entry. > + - "qcom,sdm845-ipa" > + - "qcom,sc7180-ipa" > >reg: > items: > -- > 2.30.0 >
Re: [PATCH v1 6/7] dt-bindings: net: qcom-ipa: Document qcom,sc7180-ipa compatible
On 2/11/21 11:50 AM, AngeloGioacchino Del Regno wrote: > The driver supports SC7180, but the binding was not documented. > Just add it. I hadn't noticed that! I'm trying to get through reviewing your series today and this will take another hour or so to go validate to my satisfaction. Would you be willing to submit just this patch as a fix, and when you do I will give it a proper review? -Alex > Signed-off-by: AngeloGioacchino Del Regno > > --- > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > index 8a2d12644675..b063c6c1077a 100644 > --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > @@ -43,7 +43,11 @@ description: > > properties: >compatible: > -const: "qcom,sdm845-ipa" > +oneOf: > + - items: > + - enum: > + - "qcom,sdm845-ipa" > + - "qcom,sc7180-ipa" > >reg: > items: >
Re: [PATCH v1 7/7] dt-bindings: net: qcom-ipa: Document qcom,msm8998-ipa compatible
On 2/11/21 11:50 AM, AngeloGioacchino Del Regno wrote: > MSM8998 support has been added: document the new compatible. > > Signed-off-by: AngeloGioacchino Del Regno > With the previous patch in place, this becomes almost automatic. But I don't want to claim support for a platform until things actually *work*. I don't just mean we can compile and load (and load firmware), I want to be able to say we can actually carry LTE data over IPA before we advertise the compatible string here. Maybe I'm being picky, but that's my preference. It adds some motivation for getting the user space tools squared away. Thank you again very much for your patches. -Alex > --- > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > index b063c6c1077a..9dacd224b606 100644 > --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > @@ -46,6 +46,7 @@ properties: > oneOf: >- items: >- enum: > + - "qcom,msm8998-ipa" >- "qcom,sdm845-ipa" >- "qcom,sc7180-ipa" > >
Re: [RFC PATCH net-next 06/12] Documentation: networking: dsa: document the port_bridge_flags method
> + the bridge port flags for the CPU port. The assumption is that address > + learning should be statically enabled (if supported by the hardware) on the > + CPU port, and flooding towards the CPU port should also be enabled, in lack > + of an explicit address filtering mechanism in the DSA core. Hi Vladimir "in lack of" is a bit odd wording. Maybe "due to a lack of" Reviewed-by: Andrew Lunn Andrew
Re: [RFC PATCH net-next 06/12] Documentation: networking: dsa: document the port_bridge_flags method
On 2/21/2021 13:33, Vladimir Oltean wrote: From: Vladimir Oltean The documentation was already lagging behind by not mentioning the old version of port_bridge_flags (port_set_egress_floods). So now we are skipping one step and just explaining how a DSA driver should configure address learning and flooding settings. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
[RFC PATCH net-next 06/12] Documentation: networking: dsa: document the port_bridge_flags method
From: Vladimir Oltean The documentation was already lagging behind by not mentioning the old version of port_bridge_flags (port_set_egress_floods). So now we are skipping one step and just explaining how a DSA driver should configure address learning and flooding settings. Signed-off-by: Vladimir Oltean --- Documentation/networking/dsa/dsa.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 19ce5bb0a7a4..3c6560a43ae0 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -597,6 +597,17 @@ Bridge layer computing a STP state change based on current and asked parameters and perform the relevant ageing based on the intersection results +- ``port_bridge_flags``: bridge layer function invoked when a port must + configure its settings for e.g. flooding of unknown traffic or source address + learning. The switch driver is responsible for initial setup of the + standalone ports with address learning disabled and egress flooding of all + types of traffic, then the DSA core notifies of any change to the bridge port + flags when the port joins and leaves a bridge. DSA does not currently manage + the bridge port flags for the CPU port. The assumption is that address + learning should be statically enabled (if supported by the hardware) on the + CPU port, and flooding towards the CPU port should also be enabled, in lack + of an explicit address filtering mechanism in the DSA core. + Bridge VLAN filtering - -- 2.25.1
[net-next PATCH v6 01/15] Documentation: ACPI: DSD: Document MDIO PHY
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson
---
Changes in v6:
- Minor cleanup
Changes in v5:
- More cleanup
Changes in v4:
- More cleanup
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 133 ++
1 file changed, 133 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst
b/Documentation/firmware-guide/acpi/dsd/phy.rst
new file mode 100644
index ..7d01ae8b3cc6
--- /dev/null
+++ b/Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+MDIO bus and PHYs in ACPI
+=
+
+The PHYs on an MDIO bus [1] are probed and registered using
+fwnode_mdiobus_register_phy().
+
+Later, for connecting these PHYs to their respective MACs, the PHYs registered
+on the MDIO bus have to be referenced.
+
+This document introduces two _DSD properties that are to be used
+for connecting PHYs on the MDIO bus [3] to the MAC layer.
+
+These properties are defined in accordance with the "Device
+Properties UUID For _DSD" [2] document and the
+daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
+Data Descriptors containing them.
+
+phy-handle
+--
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
+
+::
+ Scope(\_SB.MDI0)
+ {
+Device(PHY1) {
+ Name (_ADR, 0x1)
+} // end of PHY1
+
+Device(PHY2) {
+ Name (_ADR, 0x2)
+} // end of PHY2
+ }
+
+Later, during the MAC driver initialization, the registered PHY devices
+have to be retrieved from the MDIO bus. For this, the MAC driver needs
+references to the previously registered PHYs which are provided
+as device object references (e.g. \_SB.MDI0.PHY1).
+
+phy-mode
+
+The "phy-mode" _DSD property is used to describe the connection to
+the PHY. The valid values for "phy-mode" are defined in [4].
+
+The following ASL example illustrates the usage of these properties.
+
+DSDT entry for MDIO node
+
+
+The MDIO bus has an SoC component (MDIO controller) and a platform
+component (PHYs on the MDIO bus).
+
+a) Silicon Component
+This node describes the MDIO controller, MDI0
+-
+::
+ Scope(_SB)
+ {
+ Device(MDI0) {
+ Name(_HID, "NXP0006")
+ Name(_CCA, 1)
+ Name(_UID, 0)
+ Name(_CRS, ResourceTemplate() {
+ Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
+ Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
+ {
+MDI0_IT
+ }
+ }) // end of _CRS for MDI0
+ } // end of MDI0
+ }
+
+b) Platform Component
+The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0
+-
+::
+ Scope(\_SB.MDI0)
+ {
+ Device(PHY1) {
+ Name (_ADR, 0x1)
+ } // end of PHY1
+
+ Device(PHY2) {
+ Name (_ADR, 0x2)
+ } // end of PHY2
+ }
+
+DSDT entries representing MAC nodes
+---
+
+Below are the MAC nodes where PHY nodes are referenced.
+phy-mode and phy-handle are used as explained earlier.
+--
+::
+ Scope(\_SB.MCE0.PR17)
+ {
+ Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package (2) {"phy-mode", "rgmii-id"},
+Package (2) {"phy-handle", \_SB.MDI0.PHY1}
+ }
+ })
+ }
+
+ Scope(\_SB.MCE0.PR18)
+ {
+ Name (_DSD, Package () {
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package () {
+ Package (2) {"phy-mode", "rgmii-id"},
+ Package (2) {"phy-handle", \_SB.MDI0.PHY2}}
+ }
+ })
+ }
+
+References
+==
+
+[1] Documentation/networking/phy.rst
+
+[2]
https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
+
+[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst
+
+[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml
--
2.17.1
[PATCH bpf-next 08/17] bpf: Document BPF_MAP_*_BATCH syscall commands
From: Joe Stringer
Based roughly on the following commits:
* Commit cb4d03ab499d ("bpf: Add generic support for lookup batch op")
* Commit 057996380a42 ("bpf: Add batch ops to all htab bpf map")
* Commit aa2e93b8e58e ("bpf: Add generic support for update and delete
batch ops")
Reviewed-by: Quentin Monnet
Signed-off-by: Joe Stringer
---
CC: Brian Vazquez
CC: Yonghong Song
@Yonghong, would you mind double-checking whether the text is accurate for the
case where BPF_MAP_LOOKUP_AND_DELETE_BATCH returns -EFAULT?
---
include/uapi/linux/bpf.h | 114 +--
1 file changed, 111 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index a07cecfd2148..893803f69a64 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -550,13 +550,55 @@ union bpf_iter_link_info {
* Description
* Iterate and fetch multiple elements in a map.
*
+ * Two opaque values are used to manage batch operations,
+ * *in_batch* and *out_batch*. Initially, *in_batch* must be set
+ * to NULL to begin the batched operation. After each subsequent
+ * **BPF_MAP_LOOKUP_BATCH**, the caller should pass the resultant
+ * *out_batch* as the *in_batch* for the next operation to
+ * continue iteration from the current point.
+ *
+ * The *keys* and *values* are output parameters which must point
+ * to memory large enough to hold *count* items based on the key
+ * and value size of the map *map_fd*. The *keys* buffer must be
+ * of *key_size* * *count*. The *values* buffer must be of
+ * *value_size* * *count*.
+ *
+ * The *elem_flags* argument may be specified as one of the
+ * following:
+ *
+ * **BPF_F_LOCK**
+ * Look up the value of a spin-locked map without
+ * returning the lock. This must be specified if the
+ * elements contain a spinlock.
+ *
+ * On success, *count* elements from the map are copied into the
+ * user buffer, with the keys copied into *keys* and the values
+ * copied into the corresponding indices in *values*.
+ *
+ * If an error is returned and *errno* is not **EFAULT**, *count*
+ * is set to the number of successfully processed elements.
+ *
* Return
* Returns zero on success. On error, -1 is returned and *errno*
* is set appropriately.
*
+ * May set *errno* to **ENOSPC** to indicate that *keys* or
+ * *values* is too small to dump an entire bucket during
+ * iteration of a hash-based map type.
+ *
* BPF_MAP_LOOKUP_AND_DELETE_BATCH
* Description
- * Iterate and delete multiple elements in a map.
+ * Iterate and delete all elements in a map.
+ *
+ * This operation has the same behavior as
+ * **BPF_MAP_LOOKUP_BATCH** with two exceptions:
+ *
+ * * Every element that is successfully returned is also deleted
+ * from the map. This is at least *count* elements. Note that
+ * *count* is both an input and an output parameter.
+ * * Upon returning with *errno* set to **EFAULT**, up to
+ * *count* elements may be deleted without returning the keys
+ * and values of the deleted elements.
*
* Return
* Returns zero on success. On error, -1 is returned and *errno*
@@ -564,15 +606,81 @@ union bpf_iter_link_info {
*
* BPF_MAP_UPDATE_BATCH
* Description
- * Iterate and update multiple elements in a map.
+ * Update multiple elements in a map by *key*.
+ *
+ * The *keys* and *values* are input parameters which must point
+ * to memory large enough to hold *count* items based on the key
+ * and value size of the map *map_fd*. The *keys* buffer must be
+ * of *key_size* * *count*. The *values* buffer must be of
+ * *value_size* * *count*.
+ *
+ * Each element specified in *keys* is sequentially updated to the
+ * value in the corresponding index in *values*. The *in_batch*
+ * and *out_batch* parameters are ignored and should be zeroed.
+ *
+ * The *elem_flags* argument should be specified as one of the
+ * following:
+ *
+ * **BPF_ANY**
+ * Create new elements or update a existing elements.
+ * **BPF_NOEXIST**
+ * Create new elements only if they do not exist.
+ * **BPF_EXIST**
+ * Update existing elements.
+ * **BPF_F_LOCK**
+ * Update spin_lock-ed map elements. This must be
+ * specified if the map value contains a spinlo
[PATCH bpf-next 07/17] bpf: Document BPF_PROG_QUERY syscall command
From: Joe Stringer
Commit 468e2f64d220 ("bpf: introduce BPF_PROG_QUERY command") originally
introduced this, but there have been several additions since then.
Unlike BPF_PROG_ATTACH, it appears that the sockmap progs are not able
to be queried so far.
Reviewed-by: Quentin Monnet
Signed-off-by: Joe Stringer
---
CC: Alexei Starovoitov
---
include/uapi/linux/bpf.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 86fe0445c395..a07cecfd2148 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -386,6 +386,43 @@ union bpf_iter_link_info {
* Obtain information about eBPF programs associated with the
* specified *attach_type* hook.
*
+ * The *target_fd* must be a valid file descriptor for a kernel
+ * object which depends on the attach type of *attach_bpf_fd*:
+ *
+ * **BPF_PROG_TYPE_CGROUP_DEVICE**,
+ * **BPF_PROG_TYPE_CGROUP_SKB**,
+ * **BPF_PROG_TYPE_CGROUP_SOCK**,
+ * **BPF_PROG_TYPE_CGROUP_SOCK_ADDR**,
+ * **BPF_PROG_TYPE_CGROUP_SOCKOPT**,
+ * **BPF_PROG_TYPE_CGROUP_SYSCTL**,
+ * **BPF_PROG_TYPE_SOCK_OPS**
+ *
+ * Control Group v2 hierarchy with the eBPF controller
+ * enabled. Requires the kernel to be compiled with
+ * **CONFIG_CGROUP_BPF**.
+ *
+ * **BPF_PROG_TYPE_FLOW_DISSECTOR**
+ *
+ * Network namespace (eg /proc/self/ns/net).
+ *
+ * **BPF_PROG_TYPE_LIRC_MODE2**
+ *
+ * LIRC device path (eg /dev/lircN). Requires the kernel
+ * to be compiled with **CONFIG_BPF_LIRC_MODE2**.
+ *
+ * **BPF_PROG_QUERY** always fetches the number of programs
+ * attached and the *attach_flags* which were used to attach those
+ * programs. Additionally, if *prog_ids* is nonzero and the number
+ * of attached programs is less than *prog_cnt*, populates
+ * *prog_ids* with the eBPF program ids of the programs attached
+ * at *target_fd*.
+ *
+ * The following flags may alter the result:
+ *
+ * **BPF_F_QUERY_EFFECTIVE**
+ * Only return information regarding programs which are
+ * currently effective at the specified *target_fd*.
+ *
* Return
* Returns zero on success. On error, -1 is returned and *errno*
* is set appropriately.
--
2.27.0
[PATCH bpf-next 06/17] bpf: Document BPF_PROG_TEST_RUN syscall command
From: Joe Stringer
Based on a brief read of the corresponding source code.
Reviewed-by: Quentin Monnet
Signed-off-by: Joe Stringer
---
include/uapi/linux/bpf.h | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 603605c5ca03..86fe0445c395 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -303,14 +303,22 @@ union bpf_iter_link_info {
*
* BPF_PROG_TEST_RUN
* Description
- * Run an eBPF program a number of times against a provided
- * program context and return the modified program context and
- * duration of the test run.
+ * Run the eBPF program associated with the *prog_fd* a *repeat*
+ * number of times against a provided program context *ctx_in* and
+ * data *data_in*, and return the modified program context
+ * *ctx_out*, *data_out* (for example, packet data), result of the
+ * execution *retval*, and *duration* of the test run.
*
* Return
* Returns zero on success. On error, -1 is returned and *errno*
* is set appropriately.
*
+ * **ENOSPC**
+ * Either *data_size_out* or *ctx_size_out* is too small.
+ * **ENOTSUPP**
+ * This command is not supported by the program type of
+ * the program referred to by *prog_fd*.
+ *
* BPF_PROG_GET_NEXT_ID
* Description
* Fetch the next eBPF program currently loaded into the kernel.
--
2.27.0
[PATCH bpf-next 05/17] bpf: Document BPF_PROG_ATTACH syscall command
From: Joe Stringer
Document the prog attach command in more detail, based on git commits:
* commit f4324551489e ("bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH
commands")
* commit 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor
socket TX/RX data")
* commit f4364dcfc86d ("media: rc: introduce BPF_PROG_LIRC_MODE2")
* commit d58e468b1112 ("flow_dissector: implements flow dissector BPF
hook")
Reviewed-by: Quentin Monnet
Signed-off-by: Joe Stringer
---
CC: Daniel Mack
CC: John Fastabend
CC: Sean Young
CC: Petar Penkov
---
include/uapi/linux/bpf.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 8301a19c97de..603605c5ca03 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -250,6 +250,43 @@ union bpf_iter_link_info {
* Attach an eBPF program to a *target_fd* at the specified
* *attach_type* hook.
*
+ * The *attach_type* specifies the eBPF attachment point to
+ * attach the program to, and must be one of *bpf_attach_type*
+ * (see below).
+ *
+ * The *attach_bpf_fd* must be a valid file descriptor for a
+ * loaded eBPF program of a cgroup, flow dissector, LIRC, sockmap
+ * or sock_ops type corresponding to the specified *attach_type*.
+ *
+ * The *target_fd* must be a valid file descriptor for a kernel
+ * object which depends on the attach type of *attach_bpf_fd*:
+ *
+ * **BPF_PROG_TYPE_CGROUP_DEVICE**,
+ * **BPF_PROG_TYPE_CGROUP_SKB**,
+ * **BPF_PROG_TYPE_CGROUP_SOCK**,
+ * **BPF_PROG_TYPE_CGROUP_SOCK_ADDR**,
+ * **BPF_PROG_TYPE_CGROUP_SOCKOPT**,
+ * **BPF_PROG_TYPE_CGROUP_SYSCTL**,
+ * **BPF_PROG_TYPE_SOCK_OPS**
+ *
+ * Control Group v2 hierarchy with the eBPF controller
+ * enabled. Requires the kernel to be compiled with
+ * **CONFIG_CGROUP_BPF**.
+ *
+ * **BPF_PROG_TYPE_FLOW_DISSECTOR**
+ *
+ * Network namespace (eg /proc/self/ns/net).
+ *
+ * **BPF_PROG_TYPE_LIRC_MODE2**
+ *
+ * LIRC device path (eg /dev/lircN). Requires the kernel
+ * to be compiled with **CONFIG_BPF_LIRC_MODE2**.
+ *
+ * **BPF_PROG_TYPE_SK_SKB**,
+ * **BPF_PROG_TYPE_SK_MSG**
+ *
+ * eBPF map of socket type (eg **BPF_MAP_TYPE_SOCKHASH**).
+ *
* Return
* Returns zero on success. On error, -1 is returned and *errno*
* is set appropriately.
--
2.27.0
[PATCH bpf-next 04/17] bpf: Document BPF_PROG_PIN syscall command
From: Joe Stringer
Commit b2197755b263 ("bpf: add support for persistent maps/progs")
contains the original implementation and git logs, used as reference for
this documentation.
Also pull in the filename restriction as documented in commit 6d8cb045cde6
("bpf: comment why dots in filenames under BPF virtual FS are not allowed")
Reviewed-by: Quentin Monnet
Signed-off-by: Joe Stringer
---
CC: Daniel Borkmann
---
include/uapi/linux/bpf.h | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index d02259458fd6..8301a19c97de 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -216,6 +216,22 @@ union bpf_iter_link_info {
* Pin an eBPF program or map referred by the specified *bpf_fd*
* to the provided *pathname* on the filesystem.
*
+ * The *pathname* argument must not contain a dot (".").
+ *
+ * On success, *pathname* retains a reference to the eBPF object,
+ * preventing deallocation of the object when the original
+ * *bpf_fd* is closed. This allow the eBPF object to live beyond
+ * **close**\ (\ *bpf_fd*\ ), and hence the lifetime of the parent
+ * process.
+ *
+ * Applying **unlink**\ (2) or similar calls to the *pathname*
+ * unpins the object from the filesystem, removing the reference.
+ * If no other file descriptors or filesystem nodes refer to the
+ * same object, it will be deallocated (see NOTES).
+ *
+ * The filesystem type for the parent directory of *pathname* must
+ * be **BPF_FS_MAGIC**.
+ *
* Return
* Returns zero on success. On error, -1 is returned and *errno*
* is set appropriately.
@@ -581,13 +597,17 @@ union bpf_iter_link_info {
*
* NOTES
* eBPF objects (maps and programs) can be shared between processes.
- * For example, after **fork**\ (2), the child inherits file descriptors
- * referring to the same eBPF objects. In addition, file descriptors
- * referring to eBPF objects can be transferred over UNIX domain sockets.
- * File descriptors referring to eBPF objects can be duplicated in the
- * usual way, using **dup**\ (2) and similar calls. An eBPF object is
- * deallocated only after all file descriptors referring to the object
- * have been closed.
+ * * After **fork**\ (2), the child inherits file descriptors
+ * referring to the same eBPF objects.
+ * * File descriptors referring to eBPF objects can be transferred over
+ * **unix**\ (7) domain sockets.
+ * * File descriptors referring to eBPF objects can be duplicated in the
+ * usual way, using **dup**\ (2) and similar calls.
+ * * File descriptors referring to eBPF objects can be pinned to the
+ * filesystem using the **BPF_OBJ_PIN** command of **bpf**\ (2).
+ * An eBPF object is deallocated only after all file descriptors referring
+ * to the object have been closed and no references remain pinned to the
+ * filesystem or attached (for example, bound to a program or device).
*/
enum bpf_cmd {
BPF_MAP_CREATE,
--
2.27.0
[PATCH bpf-next 03/17] bpf: Document BPF_F_LOCK in syscall commands
From: Joe Stringer
Document the meaning of the BPF_F_LOCK flag for the map lookup/update
descriptions. Based on commit 96049f3afd50 ("bpf: introduce BPF_F_LOCK
flag").
Reviewed-by: Quentin Monnet
Signed-off-by: Joe Stringer
---
CC: Alexei Starovoitov
---
include/uapi/linux/bpf.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index ac6880d7b01b..d02259458fd6 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -120,6 +120,14 @@ union bpf_iter_link_info {
* Look up an element with a given *key* in the map referred to
* by the file descriptor *map_fd*.
*
+ * The *flags* argument may be specified as one of the
+ * following:
+ *
+ * **BPF_F_LOCK**
+ * Look up the value of a spin-locked map without
+ * returning the lock. This must be specified if the
+ * elements contain a spinlock.
+ *
* Return
* Returns zero on success. On error, -1 is returned and *errno*
* is set appropriately.
@@ -137,6 +145,8 @@ union bpf_iter_link_info {
* Create a new element only if it did not exist.
* **BPF_EXIST**
* Update an existing element.
+ * **BPF_F_LOCK**
+ * Update a spin_lock-ed map element.
*
* Return
* Returns zero on success. On error, -1 is returned and *errno*
--
2.27.0
[PATCH v1 6/7] dt-bindings: net: qcom-ipa: Document qcom,sc7180-ipa compatible
The driver supports SC7180, but the binding was not documented. Just add it. Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/net/qcom,ipa.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 8a2d12644675..b063c6c1077a 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -43,7 +43,11 @@ description: properties: compatible: -const: "qcom,sdm845-ipa" +oneOf: + - items: + - enum: + - "qcom,sdm845-ipa" + - "qcom,sc7180-ipa" reg: items: -- 2.30.0
[PATCH v1 7/7] dt-bindings: net: qcom-ipa: Document qcom,msm8998-ipa compatible
MSM8998 support has been added: document the new compatible. Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index b063c6c1077a..9dacd224b606 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -46,6 +46,7 @@ properties: oneOf: - items: - enum: + - "qcom,msm8998-ipa" - "qcom,sdm845-ipa" - "qcom,sc7180-ipa" -- 2.30.0
[PATCH iproute2 2/6] man8/bridge.8: document that "local" is default for "bridge fdb add"
From: Vladimir Oltean The bridge does this: fdb_modify: /* Assume permanent */ if (!(req.ndm.ndm_state&(NUD_PERMANENT|NUD_REACHABLE))) req.ndm.ndm_state |= NUD_PERMANENT; So let's make the user aware of the fact that if they don't want local entries, they need to specify some other flag like "static". Signed-off-by: Vladimir Oltean --- man/man8/bridge.8 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/man/man8/bridge.8 b/man/man8/bridge.8 index 12c09a56563d..223e65d64757 100644 --- a/man/man8/bridge.8 +++ b/man/man8/bridge.8 @@ -514,7 +514,8 @@ the Ethernet MAC address. the interface to which this address is associated. .B local -- is a local permanent fdb entry +- is a local permanent fdb entry. This flag is default unless "static" or + "dynamic" are explicitly specified. .sp .B permanent -- 2.25.1
[PATCH iproute2 1/6] man8/bridge.8: document the "permanent" flag for "bridge fdb add"
From: Vladimir Oltean
The bridge program parses "local" and "permanent" in just the same way,
so it makes sense to tell that to users:
fdb_modify:
} else if (matches(*argv, "local") == 0 ||
matches(*argv, "permanent") == 0) {
req.ndm.ndm_state |= NUD_PERMANENT;
Signed-off-by: Vladimir Oltean
---
man/man8/bridge.8 | 4
1 file changed, 4 insertions(+)
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index b3414ae31faf..12c09a56563d 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -517,6 +517,10 @@ the interface to which this address is associated.
- is a local permanent fdb entry
.sp
+.B permanent
+- this is a synonym for "local"
+.sp
+
.B static
- is a static (no arp) fdb entry
.sp
--
2.25.1
[PATCH V4 net-next 1/2] dt-bindings: net: document BCM4908 Ethernet controller
From: Rafał Miłecki
BCM4908 is a family of SoCs with integrated Ethernet controller.
Signed-off-by: Rafał Miłecki
---
V3: Use ethernet-controller.yaml#
Rename "compatible" value (use "-")
Drop "interrupt-names" until it's needed
---
.../bindings/net/brcm,bcm4908-enet.yaml | 43 +++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml
diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml
b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml
new file mode 100644
index ..5050974c8550
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/brcm,bcm4908-enet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4908 Ethernet controller
+
+description: Broadcom's Ethernet controller integrated into BCM4908 family SoCs
+
+maintainers:
+ - Rafał Miłecki
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+const: brcm,bcm4908-enet
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: RX interrupt
+
+required:
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+ethernet@80002000 {
+compatible = "brcm,bcm4908-enet";
+reg = <0x80002000 0x1000>;
+
+interrupts = ;
+};
--
2.26.2
Re: [PATCH V2 net-next 1/2] dt-bindings: net: document BCM4908 Ethernet controller
On 09.02.2021 22:43, Rob Herring wrote: On Sun, Feb 07, 2021 at 11:26:31PM +0100, Rafał Miłecki wrote: From: Rafał Miłecki BCM4908 is a family of SoCs with integrated Ethernet controller. Signed-off-by: Rafał Miłecki --- .../bindings/net/brcm,bcm4908enet.yaml| 45 +++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml new file mode 100644 index ..5f12f51c5b19 --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,bcm4908enet.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM4908 Ethernet controller + +description: Broadcom's Ethernet controller integrated into BCM4908 family SoCs + +maintainers: + - Rafał Miłecki + allOf: - $ref: 'ethernet-controller.yaml#' Thanks! +properties: + compatible: +const: brcm,bcm4908enet Normal convention is 'brcm,bcm4908-enet'. (And update the filename/$id) Is it? ;) It seems we have: brcm,bcmgenet (not brcm,bcmg-enet) fsl-enetc (not e.g. fsl-enet-c) xilinx_axienet (not xilinx_axi-enet) apm,xgene1-sgenet (not apm,xgene1-sg-enet) Of course, as you seem to prefer *-enet, I'll make it so! V3 soon. + + reg: +maxItems: 1 + + interrupts: +description: RX interrupt + + interrupt-names: +const: rx Don't really need *-names when only 1 possible entry. I think this controller may have some more interrupts (I don't know about). We can "interrupt-names" later, when we find them out.
[PATCH V3 net-next 1/2] dt-bindings: net: document BCM4908 Ethernet controller
From: Rafał Miłecki
BCM4908 is a family of SoCs with integrated Ethernet controller.
Signed-off-by: Rafał Miłecki
---
V3: Use ethernet-controller.yaml#
Rename "compatible" value (use "-")
Drop "interrupt-names" until it's needed
---
.../bindings/net/brcm,bcm4908-enet.yaml | 43 +++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml
diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml
b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml
new file mode 100644
index ..5050974c8550
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/brcm,bcm4908-enet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4908 Ethernet controller
+
+description: Broadcom's Ethernet controller integrated into BCM4908 family SoCs
+
+maintainers:
+ - Rafał Miłecki
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+const: brcm,bcm4908-enet
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: RX interrupt
+
+required:
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+ethernet@80002000 {
+compatible = "brcm,bcm4908-enet";
+reg = <0x80002000 0x1000>;
+
+interrupts = ;
+};
--
2.26.2
Re: [PATCH V2 net-next 1/2] dt-bindings: net: document BCM4908 Ethernet controller
On Sun, Feb 07, 2021 at 11:26:31PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> BCM4908 is a family of SoCs with integrated Ethernet controller.
>
> Signed-off-by: Rafał Miłecki
> ---
> .../bindings/net/brcm,bcm4908enet.yaml| 45 +++
> 1 file changed, 45 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
> b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
> new file mode 100644
> index ..5f12f51c5b19
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/brcm,bcm4908enet.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom BCM4908 Ethernet controller
> +
> +description: Broadcom's Ethernet controller integrated into BCM4908 family
> SoCs
> +
> +maintainers:
> + - Rafał Miłecki
> +
allOf:
- $ref: 'ethernet-controller.yaml#'
> +properties:
> + compatible:
> +const: brcm,bcm4908enet
Normal convention is 'brcm,bcm4908-enet'. (And update the filename/$id)
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +description: RX interrupt
> +
> + interrupt-names:
> +const: rx
Don't really need *-names when only 1 possible entry.
> +
> +required:
> + - reg
> + - interrupts
> + - interrupt-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +ethernet@80002000 {
> +compatible = "brcm,bcm4908enet";
> +reg = <0x80002000 0x1000>;
> +
> +interrupts = ;
> +interrupt-names = "rx";
> +};
> --
> 2.26.2
>
Re: [PATCH net] Documentation: networking: ip-sysctl: Document src_valid_mark sysctl
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Mon, 08 Feb 2021 17:37:01 -0800 you wrote:
> Provide documentation for src_valid_mark sysctl, which was added
> in commit 28f6aeea3f12 ("net: restore ip source validation").
>
> Signed-off-by: Jay Vosburgh
>
> ---
> Documentation/networking/ip-sysctl.rst | 19 +++
> 1 file changed, 19 insertions(+)
Here is the summary with links:
- [net] Documentation: networking: ip-sysctl: Document src_valid_mark sysctl
https://git.kernel.org/netdev/net-next/c/8cf5d8cc3eae
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [net-next PATCH v5 01/15] Documentation: ACPI: DSD: Document MDIO PHY
On Mon, Feb 08, 2021 at 12:01:57PM -0800, Randy Dunlap wrote: > Hi, > Just a couple of nits below: > > On 2/8/21 7:12 AM, Calvin Johnson wrote: > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > > provide them to be connected to MAC. > > > > Describe properties "phy-handle" and "phy-mode". > > > > Signed-off-by: Calvin Johnson > > --- > > > Documentation/firmware-guide/acpi/dsd/phy.rst | 133 ++ > > 1 file changed, 133 insertions(+) > > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst > > b/Documentation/firmware-guide/acpi/dsd/phy.rst > > new file mode 100644 > > index ..e1e99cae5eb2 > > --- /dev/null > > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > > @@ -0,0 +1,133 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > += > > +MDIO bus and PHYs in ACPI > > += > > + > > +The PHYs on an MDIO bus [1] are probed and registered using > > +fwnode_mdiobus_register_phy(). > > + > > +Later, for connecting these PHYs to MAC, the PHYs registered on the > > to a MAC, Each PHY is connected to a MAC. So I'll change it to "PHYs to their respective MACs". > > > +MDIO bus have to be referenced. > > + > > +This document introduces two _DSD properties that are to be used > > +for connecting PHYs on the MDIO bus [3] to the MAC layer. > > + > > +These properties are defined in accordance with the "Device > > +Properties UUID For _DSD" [2] document and the > > +daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > > +Data Descriptors containing them. > > + > > +phy-handle > > +-- > > ... > > > + > > +Later, during the MAC driver initialization, the registered PHY devices > > +have to be retrieved from the MDIO bus. For this, the MAC driver need > > needs > > > +references to the previously registered PHYs which are provided > > +as device object references (e.g. \_SB.MDI0.PHY1). > > > thanks. > -- > ~Randy >
[PATCH net] Documentation: networking: ip-sysctl: Document src_valid_mark sysctl
Provide documentation for src_valid_mark sysctl, which was added
in commit 28f6aeea3f12 ("net: restore ip source validation").
Signed-off-by: Jay Vosburgh
---
Documentation/networking/ip-sysctl.rst | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.rst
b/Documentation/networking/ip-sysctl.rst
index fa544e9037b9..0fb39c895c95 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -1425,6 +1425,25 @@ rp_filter - INTEGER
Default value is 0. Note that some distributions enable it
in startup scripts.
+src_valid_mark - BOOLEAN
+ - 0 - The fwmark of the packet is not included in reverse path
+ route lookup. This allows for asymmetric routing configurations
+ utilizing the fwmark in only one direction, e.g., transparent
+ proxying.
+
+ - 1 - The fwmark of the packet is included in reverse path route
+ lookup. This permits rp_filter to function when the fwmark is
+ used for routing traffic in both directions.
+
+ This setting also affects the utilization of fmwark when
+ performing source address selection for ICMP replies, or
+ determining addresses stored for the IPOPT_TS_TSANDADDR and
+ IPOPT_RR IP options.
+
+ The max value from conf/{all,interface}/src_valid_mark is used.
+
+ Default value is 0.
+
arp_filter - BOOLEAN
- 1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
--
2.29.GIT
Re: [net-next PATCH v5 01/15] Documentation: ACPI: DSD: Document MDIO PHY
Hi, Just a couple of nits below: On 2/8/21 7:12 AM, Calvin Johnson wrote: > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > provide them to be connected to MAC. > > Describe properties "phy-handle" and "phy-mode". > > Signed-off-by: Calvin Johnson > --- > Documentation/firmware-guide/acpi/dsd/phy.rst | 133 ++ > 1 file changed, 133 insertions(+) > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst > b/Documentation/firmware-guide/acpi/dsd/phy.rst > new file mode 100644 > index ..e1e99cae5eb2 > --- /dev/null > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > @@ -0,0 +1,133 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > += > +MDIO bus and PHYs in ACPI > += > + > +The PHYs on an MDIO bus [1] are probed and registered using > +fwnode_mdiobus_register_phy(). > + > +Later, for connecting these PHYs to MAC, the PHYs registered on the to a MAC, > +MDIO bus have to be referenced. > + > +This document introduces two _DSD properties that are to be used > +for connecting PHYs on the MDIO bus [3] to the MAC layer. > + > +These properties are defined in accordance with the "Device > +Properties UUID For _DSD" [2] document and the > +daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > +Data Descriptors containing them. > + > +phy-handle > +-- ... > + > +Later, during the MAC driver initialization, the registered PHY devices > +have to be retrieved from the MDIO bus. For this, the MAC driver need needs > +references to the previously registered PHYs which are provided > +as device object references (e.g. \_SB.MDI0.PHY1). thanks. -- ~Randy
[net-next PATCH v5 01/15] Documentation: ACPI: DSD: Document MDIO PHY
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson
---
Changes in v5:
- More cleanup
Changes in v4:
- More cleanup
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 133 ++
1 file changed, 133 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst
b/Documentation/firmware-guide/acpi/dsd/phy.rst
new file mode 100644
index ..e1e99cae5eb2
--- /dev/null
+++ b/Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+MDIO bus and PHYs in ACPI
+=
+
+The PHYs on an MDIO bus [1] are probed and registered using
+fwnode_mdiobus_register_phy().
+
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+This document introduces two _DSD properties that are to be used
+for connecting PHYs on the MDIO bus [3] to the MAC layer.
+
+These properties are defined in accordance with the "Device
+Properties UUID For _DSD" [2] document and the
+daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
+Data Descriptors containing them.
+
+phy-handle
+--
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
+
+::
+ Scope(\_SB.MDI0)
+ {
+Device(PHY1) {
+ Name (_ADR, 0x1)
+} // end of PHY1
+
+Device(PHY2) {
+ Name (_ADR, 0x2)
+} // end of PHY2
+ }
+
+Later, during the MAC driver initialization, the registered PHY devices
+have to be retrieved from the MDIO bus. For this, the MAC driver need
+references to the previously registered PHYs which are provided
+as device object references (e.g. \_SB.MDI0.PHY1).
+
+phy-mode
+
+The "phy-mode" _DSD property is used to describe the connection to
+the PHY. The valid values for "phy-mode" are defined in [4].
+
+The following ASL example illustrates the usage of these properties.
+
+DSDT entry for MDIO node
+
+
+The MDIO bus has an SoC component (MDIO controller) and a platform
+component (PHYs on the MDIO bus).
+
+a) Silicon Component
+This node describes the MDIO controller, MDI0
+-
+::
+ Scope(_SB)
+ {
+ Device(MDI0) {
+ Name(_HID, "NXP0006")
+ Name(_CCA, 1)
+ Name(_UID, 0)
+ Name(_CRS, ResourceTemplate() {
+ Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
+ Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
+ {
+MDI0_IT
+ }
+ }) // end of _CRS for MDI0
+ } // end of MDI0
+ }
+
+b) Platform Component
+The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0
+-
+::
+ Scope(\_SB.MDI0)
+ {
+ Device(PHY1) {
+ Name (_ADR, 0x1)
+ } // end of PHY1
+
+ Device(PHY2) {
+ Name (_ADR, 0x2)
+ } // end of PHY2
+ }
+
+DSDT entries representing MAC nodes
+---
+
+Below are the MAC nodes where PHY nodes are referenced.
+phy-mode and phy-handle are used as explained earlier.
+--
+::
+ Scope(\_SB.MCE0.PR17)
+ {
+ Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package (2) {"phy-mode", "rgmii-id"},
+Package (2) {"phy-handle", \_SB.MDI0.PHY1}
+ }
+ })
+ }
+
+ Scope(\_SB.MCE0.PR18)
+ {
+ Name (_DSD, Package () {
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package () {
+ Package (2) {"phy-mode", "rgmii-id"},
+ Package (2) {"phy-handle", \_SB.MDI0.PHY2}}
+ }
+ })
+ }
+
+References
+==
+
+[1] Documentation/networking/phy.rst
+
+[2]
https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
+
+[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst
+
+[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml
--
2.17.1
[PATCH V2 net-next 1/2] dt-bindings: net: document BCM4908 Ethernet controller
From: Rafał Miłecki
BCM4908 is a family of SoCs with integrated Ethernet controller.
Signed-off-by: Rafał Miłecki
---
.../bindings/net/brcm,bcm4908enet.yaml| 45 +++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
new file mode 100644
index ..5f12f51c5b19
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/brcm,bcm4908enet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4908 Ethernet controller
+
+description: Broadcom's Ethernet controller integrated into BCM4908 family SoCs
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,bcm4908enet
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: RX interrupt
+
+ interrupt-names:
+const: rx
+
+required:
+ - reg
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+ethernet@80002000 {
+compatible = "brcm,bcm4908enet";
+reg = <0x80002000 0x1000>;
+
+interrupts = ;
+interrupt-names = "rx";
+};
--
2.26.2
[PATCH net-next 1/2] dt-bindings: net: document BCM4908 Ethernet controller
From: Rafał Miłecki
BCM4908 is a family of SoCs with integrated Ethernet controller.
Signed-off-by: Rafał Miłecki
---
.../bindings/net/brcm,bcm4908enet.yaml| 45 +++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
new file mode 100644
index ..5f12f51c5b19
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/brcm,bcm4908enet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4908 Ethernet controller
+
+description: Broadcom's Ethernet controller integrated into BCM4908 family SoCs
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,bcm4908enet
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: RX interrupt
+
+ interrupt-names:
+const: rx
+
+required:
+ - reg
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+ethernet@80002000 {
+compatible = "brcm,bcm4908enet";
+reg = <0x80002000 0x1000>;
+
+interrupts = ;
+interrupt-names = "rx";
+};
--
2.26.2
Re: [net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
On Fri, Jan 29, 2021 at 6:44 PM Rafael J. Wysocki wrote:
> On Fri, Jan 29, 2021 at 5:37 PM Rafael J. Wysocki wrote:
> > On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson
> > wrote:
...
> > It would work, but I would introduce a wrapper around the _ADR
> > evaluation, something like:
> >
> > int acpi_get_local_address(acpi_handle handle, u32 *addr)
> > {
> > unsigned long long adr;
> > acpi_status status;
> >
> > status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &adr);
> > if (ACPI_FAILURE(status))
> > return -ENODATA;
> >
> > *addr = (u32)adr;
> > return 0;
> > }
> >
> > in drivers/acpi/utils.c and add a static inline stub always returning
> > -ENODEV for it for !CONFIG_ACPI.
...
> BTW, you may not need the fwnode_get_local_addr() at all then, just
> evaluate either the "reg" property for OF or acpi_get_local_address()
> for ACPI in the "caller" code directly. A common helper doing this can
> be added later.
Sounds good to me and it will address your concern about different
semantics of reg/_ADR on per driver/subsystem basis.
--
With Best Regards,
Andy Shevchenko
Re: [net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
On Fri, Jan 29, 2021 at 5:37 PM Rafael J. Wysocki wrote: > > On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson > wrote: > > > > On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson > > > wrote: > > > > > > > > On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote: > > > > > On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson > > > > > wrote: > > > > > > > > > > > > Hi Rafael, > > > > > > > > > > > > Thanks for the review. I'll work on all the comments. > > > > > > > > > > > > On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote: > > > > > > > On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson > > > > > > > wrote: > > > > > > > > > > > > > > > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus > > > > > > > > and > > > > > > > > provide them to be connected to MAC. > > > > > > > > > > > > > > > > Describe properties "phy-handle" and "phy-mode". > > > > > > > > > > > > > > > > Signed-off-by: Calvin Johnson > > > > > > > > --- > > > > > > > > > > > > > > > > Changes in v4: > > > > > > > > - More cleanup > > > > > > > > > > > > > > This looks much better that the previous versions IMV, some nits > > > > > > > below. > > > > > > > > > > > > > > > Changes in v3: None > > > > > > > > Changes in v2: > > > > > > > > - Updated with more description in document > > > > > > > > > > > > > > > > Documentation/firmware-guide/acpi/dsd/phy.rst | 129 > > > > > > > > ++ > > > > > > > > 1 file changed, 129 insertions(+) > > > > > > > > create mode 100644 > > > > > > > > Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > > > > > > > > > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > > b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > > new file mode 100644 > > > > > > > > index ..76fca994bc99 > > > > > > > > --- /dev/null > > > > > > > > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > > @@ -0,0 +1,129 @@ > > > > > > > > +.. SPDX-License-Identifier: GPL-2.0 > > > > > > > > + > > > > > > > > += > > > > > > > > +MDIO bus and PHYs in ACPI > > > > > > > > += > > > > > > > > + > > > > > > > > +The PHYs on an MDIO bus [1] are probed and registered using > > > > > > > > +fwnode_mdiobus_register_phy(). > > > > > > > > > > > > > > Empty line here, please. > > > > > > > > > > > > > > > +Later, for connecting these PHYs to MAC, the PHYs registered > > > > > > > > on the > > > > > > > > +MDIO bus have to be referenced. > > > > > > > > + > > > > > > > > +The UUID given below should be used as mentioned in the > > > > > > > > "Device Properties > > > > > > > > +UUID For _DSD" [2] document. > > > > > > > > + - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 > > > > > > > > > > > > > > I would drop the above paragraph. > > > > > > > > > > > > > > > + > > > > > > > > +This document introduces two _DSD properties that are to be > > > > > > > > used > > > > > > > > +for PHYs on the MDIO bus.[3] > > > > > > > > > > > > > > I'd say "for connecting PHYs on the MDIO bus [3] to the MAC > > > > > > > layer." > > > > > > > above and add the following here: > > &g
Re: [net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson wrote: > > On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote: > > On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson > > wrote: > > > > > > On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote: > > > > On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson > > > > wrote: > > > > > > > > > > Hi Rafael, > > > > > > > > > > Thanks for the review. I'll work on all the comments. > > > > > > > > > > On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote: > > > > > > On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson > > > > > > wrote: > > > > > > > > > > > > > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > > > > > > > provide them to be connected to MAC. > > > > > > > > > > > > > > Describe properties "phy-handle" and "phy-mode". > > > > > > > > > > > > > > Signed-off-by: Calvin Johnson > > > > > > > --- > > > > > > > > > > > > > > Changes in v4: > > > > > > > - More cleanup > > > > > > > > > > > > This looks much better that the previous versions IMV, some nits > > > > > > below. > > > > > > > > > > > > > Changes in v3: None > > > > > > > Changes in v2: > > > > > > > - Updated with more description in document > > > > > > > > > > > > > > Documentation/firmware-guide/acpi/dsd/phy.rst | 129 > > > > > > > ++ > > > > > > > 1 file changed, 129 insertions(+) > > > > > > > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > > > > > > > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > new file mode 100644 > > > > > > > index ..76fca994bc99 > > > > > > > --- /dev/null > > > > > > > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > @@ -0,0 +1,129 @@ > > > > > > > +.. SPDX-License-Identifier: GPL-2.0 > > > > > > > + > > > > > > > += > > > > > > > +MDIO bus and PHYs in ACPI > > > > > > > += > > > > > > > + > > > > > > > +The PHYs on an MDIO bus [1] are probed and registered using > > > > > > > +fwnode_mdiobus_register_phy(). > > > > > > > > > > > > Empty line here, please. > > > > > > > > > > > > > +Later, for connecting these PHYs to MAC, the PHYs registered on > > > > > > > the > > > > > > > +MDIO bus have to be referenced. > > > > > > > + > > > > > > > +The UUID given below should be used as mentioned in the "Device > > > > > > > Properties > > > > > > > +UUID For _DSD" [2] document. > > > > > > > + - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 > > > > > > > > > > > > I would drop the above paragraph. > > > > > > > > > > > > > + > > > > > > > +This document introduces two _DSD properties that are to be used > > > > > > > +for PHYs on the MDIO bus.[3] > > > > > > > > > > > > I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer." > > > > > > above and add the following here: > > > > > > > > > > > > "These properties are defined in accordance with the "Device > > > > > > Properties UUID For _DSD" [2] document and the > > > > > > daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > > > > > > Data Descriptors containing them." > > > > > > > > > > > > > + > > > > > > > +phy-handle > > > > > > > +-- > > > > > > > +For each MAC node, a device property "phy-h
Re: [net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote: > On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson > wrote: > > > > On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson > > > wrote: > > > > > > > > Hi Rafael, > > > > > > > > Thanks for the review. I'll work on all the comments. > > > > > > > > On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote: > > > > > On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson > > > > > wrote: > > > > > > > > > > > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > > > > > > provide them to be connected to MAC. > > > > > > > > > > > > Describe properties "phy-handle" and "phy-mode". > > > > > > > > > > > > Signed-off-by: Calvin Johnson > > > > > > --- > > > > > > > > > > > > Changes in v4: > > > > > > - More cleanup > > > > > > > > > > This looks much better that the previous versions IMV, some nits > > > > > below. > > > > > > > > > > > Changes in v3: None > > > > > > Changes in v2: > > > > > > - Updated with more description in document > > > > > > > > > > > > Documentation/firmware-guide/acpi/dsd/phy.rst | 129 > > > > > > ++ > > > > > > 1 file changed, 129 insertions(+) > > > > > > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > > > > > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > new file mode 100644 > > > > > > index ..76fca994bc99 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > @@ -0,0 +1,129 @@ > > > > > > +.. SPDX-License-Identifier: GPL-2.0 > > > > > > + > > > > > > += > > > > > > +MDIO bus and PHYs in ACPI > > > > > > += > > > > > > + > > > > > > +The PHYs on an MDIO bus [1] are probed and registered using > > > > > > +fwnode_mdiobus_register_phy(). > > > > > > > > > > Empty line here, please. > > > > > > > > > > > +Later, for connecting these PHYs to MAC, the PHYs registered on the > > > > > > +MDIO bus have to be referenced. > > > > > > + > > > > > > +The UUID given below should be used as mentioned in the "Device > > > > > > Properties > > > > > > +UUID For _DSD" [2] document. > > > > > > + - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 > > > > > > > > > > I would drop the above paragraph. > > > > > > > > > > > + > > > > > > +This document introduces two _DSD properties that are to be used > > > > > > +for PHYs on the MDIO bus.[3] > > > > > > > > > > I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer." > > > > > above and add the following here: > > > > > > > > > > "These properties are defined in accordance with the "Device > > > > > Properties UUID For _DSD" [2] document and the > > > > > daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > > > > > Data Descriptors containing them." > > > > > > > > > > > + > > > > > > +phy-handle > > > > > > +-- > > > > > > +For each MAC node, a device property "phy-handle" is used to > > > > > > reference > > > > > > +the PHY that is registered on an MDIO bus. This is mandatory for > > > > > > +network interfaces that have PHYs connected to MAC via MDIO bus. > > > > > > + > > > > > > +During the MDIO bus driver initialization, PHYs on this bus are > > > > > > probed > > > > > > +using the _ADR object as shown below and are register
[PATCH v8 net-next 06/11] net: dsa: document the existing switch tree notifiers and add a new one
From: Vladimir Oltean
The existence of dsa_broadcast has generated some confusion in the past:
https://www.mail-archive.com/netdev@vger.kernel.org/msg365042.html
So let's document the existing dsa_port_notify and dsa_broadcast
functions and explain when each of them should be used.
Also, in fact, the in-between function has always been there but was
lacking a name, and is the main reason for this patch: dsa_tree_notify.
Refactor dsa_broadcast to use it.
This patch also moves dsa_broadcast (a top-level function) to dsa2.c,
where it really belonged in the first place, but had no companion so it
stood with dsa_port_notify.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
Changes in v8:
None.
Changes in v7:
None.
Changes in v6:
None.
Changes in v5:
Patch is new.
net/dsa/dsa2.c | 43 +++
net/dsa/dsa_priv.h | 2 ++
net/dsa/port.c | 36 +---
3 files changed, 58 insertions(+), 23 deletions(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index cc13549120e5..2953d0c1c7bc 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -21,6 +21,49 @@
static DEFINE_MUTEX(dsa2_mutex);
LIST_HEAD(dsa_tree_list);
+/**
+ * dsa_tree_notify - Execute code for all switches in a DSA switch tree.
+ * @dst: collection of struct dsa_switch devices to notify.
+ * @e: event, must be of type DSA_NOTIFIER_*
+ * @v: event-specific value.
+ *
+ * Given a struct dsa_switch_tree, this can be used to run a function once for
+ * each member DSA switch. The other alternative of traversing the tree is only
+ * through its ports list, which does not uniquely list the switches.
+ */
+int dsa_tree_notify(struct dsa_switch_tree *dst, unsigned long e, void *v)
+{
+ struct raw_notifier_head *nh = &dst->nh;
+ int err;
+
+ err = raw_notifier_call_chain(nh, e, v);
+
+ return notifier_to_errno(err);
+}
+
+/**
+ * dsa_broadcast - Notify all DSA trees in the system.
+ * @e: event, must be of type DSA_NOTIFIER_*
+ * @v: event-specific value.
+ *
+ * Can be used to notify the switching fabric of events such as cross-chip
+ * bridging between disjoint trees (such as islands of tagger-compatible
+ * switches bridged by an incompatible middle switch).
+ */
+int dsa_broadcast(unsigned long e, void *v)
+{
+ struct dsa_switch_tree *dst;
+ int err = 0;
+
+ list_for_each_entry(dst, &dsa_tree_list, list) {
+ err = dsa_tree_notify(dst, e, v);
+ if (err)
+ break;
+ }
+
+ return err;
+}
+
/**
* dsa_lag_map() - Map LAG netdev to a linear LAG ID
* @dst: Tree in which to record the mapping.
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 2ce46bb87703..3cc1e6d76e3a 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -283,6 +283,8 @@ void dsa_switch_unregister_notifier(struct dsa_switch *ds);
/* dsa2.c */
void dsa_lag_map(struct dsa_switch_tree *dst, struct net_device *lag);
void dsa_lag_unmap(struct dsa_switch_tree *dst, struct net_device *lag);
+int dsa_tree_notify(struct dsa_switch_tree *dst, unsigned long e, void *v);
+int dsa_broadcast(unsigned long e, void *v);
extern struct list_head dsa_tree_list;
diff --git a/net/dsa/port.c b/net/dsa/port.c
index f5b0f72ee7cd..a8886cf40160 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -13,31 +13,21 @@
#include "dsa_priv.h"
-static int dsa_broadcast(unsigned long e, void *v)
-{
- struct dsa_switch_tree *dst;
- int err = 0;
-
- list_for_each_entry(dst, &dsa_tree_list, list) {
- struct raw_notifier_head *nh = &dst->nh;
-
- err = raw_notifier_call_chain(nh, e, v);
- err = notifier_to_errno(err);
- if (err)
- break;
- }
-
- return err;
-}
-
+/**
+ * dsa_port_notify - Notify the switching fabric of changes to a port
+ * @dp: port on which change occurred
+ * @e: event, must be of type DSA_NOTIFIER_*
+ * @v: event-specific value.
+ *
+ * Notify all switches in the DSA tree that this port's switch belongs to,
+ * including this switch itself, of an event. Allows the other switches to
+ * reconfigure themselves for cross-chip operations. Can also be used to
+ * reconfigure ports without net_devices (CPU ports, DSA links) whenever
+ * a user port's state changes.
+ */
static int dsa_port_notify(const struct dsa_port *dp, unsigned long e, void *v)
{
- struct raw_notifier_head *nh = &dp->ds->dst->nh;
- int err;
-
- err = raw_notifier_call_chain(nh, e, v);
-
- return notifier_to_errno(err);
+ return dsa_tree_notify(dp->ds->dst, e, v);
}
int dsa_port_set_state(struct dsa_port *dp, u8 state)
--
2.25.1
Re: [net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson wrote: > > On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote: > > On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson > > wrote: > > > > > > Hi Rafael, > > > > > > Thanks for the review. I'll work on all the comments. > > > > > > On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote: > > > > On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson > > > > wrote: > > > > > > > > > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > > > > > provide them to be connected to MAC. > > > > > > > > > > Describe properties "phy-handle" and "phy-mode". > > > > > > > > > > Signed-off-by: Calvin Johnson > > > > > --- > > > > > > > > > > Changes in v4: > > > > > - More cleanup > > > > > > > > This looks much better that the previous versions IMV, some nits below. > > > > > > > > > Changes in v3: None > > > > > Changes in v2: > > > > > - Updated with more description in document > > > > > > > > > > Documentation/firmware-guide/acpi/dsd/phy.rst | 129 > > > > > ++ > > > > > 1 file changed, 129 insertions(+) > > > > > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > > > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > new file mode 100644 > > > > > index ..76fca994bc99 > > > > > --- /dev/null > > > > > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > @@ -0,0 +1,129 @@ > > > > > +.. SPDX-License-Identifier: GPL-2.0 > > > > > + > > > > > += > > > > > +MDIO bus and PHYs in ACPI > > > > > += > > > > > + > > > > > +The PHYs on an MDIO bus [1] are probed and registered using > > > > > +fwnode_mdiobus_register_phy(). > > > > > > > > Empty line here, please. > > > > > > > > > +Later, for connecting these PHYs to MAC, the PHYs registered on the > > > > > +MDIO bus have to be referenced. > > > > > + > > > > > +The UUID given below should be used as mentioned in the "Device > > > > > Properties > > > > > +UUID For _DSD" [2] document. > > > > > + - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 > > > > > > > > I would drop the above paragraph. > > > > > > > > > + > > > > > +This document introduces two _DSD properties that are to be used > > > > > +for PHYs on the MDIO bus.[3] > > > > > > > > I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer." > > > > above and add the following here: > > > > > > > > "These properties are defined in accordance with the "Device > > > > Properties UUID For _DSD" [2] document and the > > > > daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > > > > Data Descriptors containing them." > > > > > > > > > + > > > > > +phy-handle > > > > > +-- > > > > > +For each MAC node, a device property "phy-handle" is used to > > > > > reference > > > > > +the PHY that is registered on an MDIO bus. This is mandatory for > > > > > +network interfaces that have PHYs connected to MAC via MDIO bus. > > > > > + > > > > > +During the MDIO bus driver initialization, PHYs on this bus are > > > > > probed > > > > > +using the _ADR object as shown below and are registered on the MDIO > > > > > bus. > > > > > > > > Do you want to mention the "reg" property here? I think it would be > > > > useful to do that. > > > > > > No. I think we should adhere to _ADR in MDIO case. The "reg" property for > > > ACPI > > > may be useful for other use cases that Andy is aware of. > > > > The code should reflect this, then. I mean it sounds like you want to > > check the "reg" property only if this is a non-ACPI node. > > Right. For MDIO case, that is what is required. > "reg" for DT and "_ADR" for ACPI. > > However, Andy pointed out [1] that ACPI nodes can also hold reg property and > therefore, fwnode_get_id() need to be capable to handling that situation as > well. No, please don't confuse those two things. Yes, ACPI nodes can also hold a "reg" property, but the meaning of it depends on the binding which is exactly my point: _ADR is not a fallback replacement for "reg" in general and it is not so for MDIO too. The new function as proposed doesn't match the MDIO requirements and so it should not be used for MDIO. For MDIO, the exact flow mentioned above needs to be implemented (and if someone wants to use it for their use case too, fine). Otherwise the code wouldn't match the documentation.
Re: [net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote: > On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson > wrote: > > > > Hi Rafael, > > > > Thanks for the review. I'll work on all the comments. > > > > On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote: > > > On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson > > > wrote: > > > > > > > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > > > > provide them to be connected to MAC. > > > > > > > > Describe properties "phy-handle" and "phy-mode". > > > > > > > > Signed-off-by: Calvin Johnson > > > > --- > > > > > > > > Changes in v4: > > > > - More cleanup > > > > > > This looks much better that the previous versions IMV, some nits below. > > > > > > > Changes in v3: None > > > > Changes in v2: > > > > - Updated with more description in document > > > > > > > > Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++ > > > > 1 file changed, 129 insertions(+) > > > > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > new file mode 100644 > > > > index ..76fca994bc99 > > > > --- /dev/null > > > > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > > @@ -0,0 +1,129 @@ > > > > +.. SPDX-License-Identifier: GPL-2.0 > > > > + > > > > += > > > > +MDIO bus and PHYs in ACPI > > > > += > > > > + > > > > +The PHYs on an MDIO bus [1] are probed and registered using > > > > +fwnode_mdiobus_register_phy(). > > > > > > Empty line here, please. > > > > > > > +Later, for connecting these PHYs to MAC, the PHYs registered on the > > > > +MDIO bus have to be referenced. > > > > + > > > > +The UUID given below should be used as mentioned in the "Device > > > > Properties > > > > +UUID For _DSD" [2] document. > > > > + - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 > > > > > > I would drop the above paragraph. > > > > > > > + > > > > +This document introduces two _DSD properties that are to be used > > > > +for PHYs on the MDIO bus.[3] > > > > > > I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer." > > > above and add the following here: > > > > > > "These properties are defined in accordance with the "Device > > > Properties UUID For _DSD" [2] document and the > > > daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > > > Data Descriptors containing them." > > > > > > > + > > > > +phy-handle > > > > +-- > > > > +For each MAC node, a device property "phy-handle" is used to reference > > > > +the PHY that is registered on an MDIO bus. This is mandatory for > > > > +network interfaces that have PHYs connected to MAC via MDIO bus. > > > > + > > > > +During the MDIO bus driver initialization, PHYs on this bus are probed > > > > +using the _ADR object as shown below and are registered on the MDIO > > > > bus. > > > > > > Do you want to mention the "reg" property here? I think it would be > > > useful to do that. > > > > No. I think we should adhere to _ADR in MDIO case. The "reg" property for > > ACPI > > may be useful for other use cases that Andy is aware of. > > The code should reflect this, then. I mean it sounds like you want to > check the "reg" property only if this is a non-ACPI node. Right. For MDIO case, that is what is required. "reg" for DT and "_ADR" for ACPI. However, Andy pointed out [1] that ACPI nodes can also hold reg property and therefore, fwnode_get_id() need to be capable to handling that situation as well. Andy, any suggestion? [1] https://lore.kernel.org/netdev/cahp75vef7ln2hwx8byao3sfxb8u2qtsfxppxa_jxmujamfp...@mail.gmail.com/ Thanks Calvin
Re: [net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson wrote: > > Hi Rafael, > > Thanks for the review. I'll work on all the comments. > > On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote: > > On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson > > wrote: > > > > > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > > > provide them to be connected to MAC. > > > > > > Describe properties "phy-handle" and "phy-mode". > > > > > > Signed-off-by: Calvin Johnson > > > --- > > > > > > Changes in v4: > > > - More cleanup > > > > This looks much better that the previous versions IMV, some nits below. > > > > > Changes in v3: None > > > Changes in v2: > > > - Updated with more description in document > > > > > > Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++ > > > 1 file changed, 129 insertions(+) > > > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > > > > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst > > > b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > new file mode 100644 > > > index ..76fca994bc99 > > > --- /dev/null > > > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > > > @@ -0,0 +1,129 @@ > > > +.. SPDX-License-Identifier: GPL-2.0 > > > + > > > += > > > +MDIO bus and PHYs in ACPI > > > += > > > + > > > +The PHYs on an MDIO bus [1] are probed and registered using > > > +fwnode_mdiobus_register_phy(). > > > > Empty line here, please. > > > > > +Later, for connecting these PHYs to MAC, the PHYs registered on the > > > +MDIO bus have to be referenced. > > > + > > > +The UUID given below should be used as mentioned in the "Device > > > Properties > > > +UUID For _DSD" [2] document. > > > + - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 > > > > I would drop the above paragraph. > > > > > + > > > +This document introduces two _DSD properties that are to be used > > > +for PHYs on the MDIO bus.[3] > > > > I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer." > > above and add the following here: > > > > "These properties are defined in accordance with the "Device > > Properties UUID For _DSD" [2] document and the > > daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > > Data Descriptors containing them." > > > > > + > > > +phy-handle > > > +-- > > > +For each MAC node, a device property "phy-handle" is used to reference > > > +the PHY that is registered on an MDIO bus. This is mandatory for > > > +network interfaces that have PHYs connected to MAC via MDIO bus. > > > + > > > +During the MDIO bus driver initialization, PHYs on this bus are probed > > > +using the _ADR object as shown below and are registered on the MDIO bus. > > > > Do you want to mention the "reg" property here? I think it would be > > useful to do that. > > No. I think we should adhere to _ADR in MDIO case. The "reg" property for ACPI > may be useful for other use cases that Andy is aware of. The code should reflect this, then. I mean it sounds like you want to check the "reg" property only if this is a non-ACPI node.
Re: [net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
Hi Rafael, Thanks for the review. I'll work on all the comments. On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote: > On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson > wrote: > > > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > > provide them to be connected to MAC. > > > > Describe properties "phy-handle" and "phy-mode". > > > > Signed-off-by: Calvin Johnson > > --- > > > > Changes in v4: > > - More cleanup > > This looks much better that the previous versions IMV, some nits below. > > > Changes in v3: None > > Changes in v2: > > - Updated with more description in document > > > > Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++ > > 1 file changed, 129 insertions(+) > > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst > > b/Documentation/firmware-guide/acpi/dsd/phy.rst > > new file mode 100644 > > index ..76fca994bc99 > > --- /dev/null > > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > > @@ -0,0 +1,129 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > += > > +MDIO bus and PHYs in ACPI > > += > > + > > +The PHYs on an MDIO bus [1] are probed and registered using > > +fwnode_mdiobus_register_phy(). > > Empty line here, please. > > > +Later, for connecting these PHYs to MAC, the PHYs registered on the > > +MDIO bus have to be referenced. > > + > > +The UUID given below should be used as mentioned in the "Device Properties > > +UUID For _DSD" [2] document. > > + - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 > > I would drop the above paragraph. > > > + > > +This document introduces two _DSD properties that are to be used > > +for PHYs on the MDIO bus.[3] > > I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer." > above and add the following here: > > "These properties are defined in accordance with the "Device > Properties UUID For _DSD" [2] document and the > daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > Data Descriptors containing them." > > > + > > +phy-handle > > +-- > > +For each MAC node, a device property "phy-handle" is used to reference > > +the PHY that is registered on an MDIO bus. This is mandatory for > > +network interfaces that have PHYs connected to MAC via MDIO bus. > > + > > +During the MDIO bus driver initialization, PHYs on this bus are probed > > +using the _ADR object as shown below and are registered on the MDIO bus. > > Do you want to mention the "reg" property here? I think it would be > useful to do that. No. I think we should adhere to _ADR in MDIO case. The "reg" property for ACPI may be useful for other use cases that Andy is aware of. Regards Calvin
[PATCH net-next v2 2/2] net: qmi_wwan: document qmap/mux_id sysfs file
Document qmap/mux_id sysfs file showing qmimux interface id Signed-off-by: Daniele Palmas --- Documentation/ABI/testing/sysfs-class-net-qmi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi b/Documentation/ABI/testing/sysfs-class-net-qmi index c310db4ccbc2..ed79f5893421 100644 --- a/Documentation/ABI/testing/sysfs-class-net-qmi +++ b/Documentation/ABI/testing/sysfs-class-net-qmi @@ -48,3 +48,13 @@ Description: Write a number ranging from 1 to 254 to delete a previously created qmap mux based network device. + +What: /sys/class/net//qmap/mux_id +Date: January 2021 +KernelVersion: 5.12 +Contact: Daniele Palmas +Description: + Unsigned integer + + Indicates the mux id associated to the qmimux network interface + during its creation. -- 2.17.1
[PATCH net-next 2/2] net: qmi_wwan: document qmap/mux_id sysfs file
Document qmap/mux_id sysfs file showing qmimux interface id Signed-off-by: Daniele Palmas --- Documentation/ABI/testing/sysfs-class-net-qmi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi b/Documentation/ABI/testing/sysfs-class-net-qmi index c310db4ccbc2..ed79f5893421 100644 --- a/Documentation/ABI/testing/sysfs-class-net-qmi +++ b/Documentation/ABI/testing/sysfs-class-net-qmi @@ -48,3 +48,13 @@ Description: Write a number ranging from 1 to 254 to delete a previously created qmap mux based network device. + +What: /sys/class/net//qmap/mux_id +Date: January 2021 +KernelVersion: 5.12 +Contact: Daniele Palmas +Description: + Unsigned integer + + Indicates the mux id associated to the qmimux network interface + during its creation. -- 2.17.1
[PATCH v7 net-next 06/11] net: dsa: document the existing switch tree notifiers and add a new one
From: Vladimir Oltean
The existence of dsa_broadcast has generated some confusion in the past:
https://www.mail-archive.com/netdev@vger.kernel.org/msg365042.html
So let's document the existing dsa_port_notify and dsa_broadcast
functions and explain when each of them should be used.
Also, in fact, the in-between function has always been there but was
lacking a name, and is the main reason for this patch: dsa_tree_notify.
Refactor dsa_broadcast to use it.
This patch also moves dsa_broadcast (a top-level function) to dsa2.c,
where it really belonged in the first place, but had no companion so it
stood with dsa_port_notify.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
Changes in v7:
None.
Changes in v6:
None.
Changes in v5:
Patch is new.
net/dsa/dsa2.c | 43 +++
net/dsa/dsa_priv.h | 2 ++
net/dsa/port.c | 36 +---
3 files changed, 58 insertions(+), 23 deletions(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index cc13549120e5..2953d0c1c7bc 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -21,6 +21,49 @@
static DEFINE_MUTEX(dsa2_mutex);
LIST_HEAD(dsa_tree_list);
+/**
+ * dsa_tree_notify - Execute code for all switches in a DSA switch tree.
+ * @dst: collection of struct dsa_switch devices to notify.
+ * @e: event, must be of type DSA_NOTIFIER_*
+ * @v: event-specific value.
+ *
+ * Given a struct dsa_switch_tree, this can be used to run a function once for
+ * each member DSA switch. The other alternative of traversing the tree is only
+ * through its ports list, which does not uniquely list the switches.
+ */
+int dsa_tree_notify(struct dsa_switch_tree *dst, unsigned long e, void *v)
+{
+ struct raw_notifier_head *nh = &dst->nh;
+ int err;
+
+ err = raw_notifier_call_chain(nh, e, v);
+
+ return notifier_to_errno(err);
+}
+
+/**
+ * dsa_broadcast - Notify all DSA trees in the system.
+ * @e: event, must be of type DSA_NOTIFIER_*
+ * @v: event-specific value.
+ *
+ * Can be used to notify the switching fabric of events such as cross-chip
+ * bridging between disjoint trees (such as islands of tagger-compatible
+ * switches bridged by an incompatible middle switch).
+ */
+int dsa_broadcast(unsigned long e, void *v)
+{
+ struct dsa_switch_tree *dst;
+ int err = 0;
+
+ list_for_each_entry(dst, &dsa_tree_list, list) {
+ err = dsa_tree_notify(dst, e, v);
+ if (err)
+ break;
+ }
+
+ return err;
+}
+
/**
* dsa_lag_map() - Map LAG netdev to a linear LAG ID
* @dst: Tree in which to record the mapping.
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 2ce46bb87703..3cc1e6d76e3a 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -283,6 +283,8 @@ void dsa_switch_unregister_notifier(struct dsa_switch *ds);
/* dsa2.c */
void dsa_lag_map(struct dsa_switch_tree *dst, struct net_device *lag);
void dsa_lag_unmap(struct dsa_switch_tree *dst, struct net_device *lag);
+int dsa_tree_notify(struct dsa_switch_tree *dst, unsigned long e, void *v);
+int dsa_broadcast(unsigned long e, void *v);
extern struct list_head dsa_tree_list;
diff --git a/net/dsa/port.c b/net/dsa/port.c
index f5b0f72ee7cd..a8886cf40160 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -13,31 +13,21 @@
#include "dsa_priv.h"
-static int dsa_broadcast(unsigned long e, void *v)
-{
- struct dsa_switch_tree *dst;
- int err = 0;
-
- list_for_each_entry(dst, &dsa_tree_list, list) {
- struct raw_notifier_head *nh = &dst->nh;
-
- err = raw_notifier_call_chain(nh, e, v);
- err = notifier_to_errno(err);
- if (err)
- break;
- }
-
- return err;
-}
-
+/**
+ * dsa_port_notify - Notify the switching fabric of changes to a port
+ * @dp: port on which change occurred
+ * @e: event, must be of type DSA_NOTIFIER_*
+ * @v: event-specific value.
+ *
+ * Notify all switches in the DSA tree that this port's switch belongs to,
+ * including this switch itself, of an event. Allows the other switches to
+ * reconfigure themselves for cross-chip operations. Can also be used to
+ * reconfigure ports without net_devices (CPU ports, DSA links) whenever
+ * a user port's state changes.
+ */
static int dsa_port_notify(const struct dsa_port *dp, unsigned long e, void *v)
{
- struct raw_notifier_head *nh = &dp->ds->dst->nh;
- int err;
-
- err = raw_notifier_call_chain(nh, e, v);
-
- return notifier_to_errno(err);
+ return dsa_tree_notify(dp->ds->dst, e, v);
}
int dsa_port_set_state(struct dsa_port *dp, u8 state)
--
2.25.1
Re: [PATCH net-next 2/2] net: qmi_wwan: document qmap/mux_id sysfs file
Daniele Palmas writes: > Document qmap/mux_id sysfs file showing qmimux interface id > > Signed-off-by: Daniele Palmas Acked-by: Bjørn Mork
Re: [PATCH] doc: networking: ip-sysctl: Document conf/all/disable_ipv6 and conf/default/disable_ipv6
Hello: This patch was applied to netdev/net.git (refs/heads/master): On Thu, 21 Jan 2021 16:02:44 +0100 you wrote: > This patch adds documentation for sysctl conf/all/disable_ipv6 and > conf/default/disable_ipv6 settings which is currently missing. > > Signed-off-by: Pali Rohár > --- > Documentation/networking/ip-sysctl.rst | 12 > 1 file changed, 12 insertions(+) Here is the summary with links: - doc: networking: ip-sysctl: Document conf/all/disable_ipv6 and conf/default/disable_ipv6 https://git.kernel.org/netdev/net/c/fc024c5c07aa You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
wrote:
>
> Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
> provide them to be connected to MAC.
>
> Describe properties "phy-handle" and "phy-mode".
>
> Signed-off-by: Calvin Johnson
> ---
>
> Changes in v4:
> - More cleanup
This looks much better that the previous versions IMV, some nits below.
> Changes in v3: None
> Changes in v2:
> - Updated with more description in document
>
> Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++
> 1 file changed, 129 insertions(+)
> create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
>
> diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst
> b/Documentation/firmware-guide/acpi/dsd/phy.rst
> new file mode 100644
> index ..76fca994bc99
> --- /dev/null
> +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst
> @@ -0,0 +1,129 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=
> +MDIO bus and PHYs in ACPI
> +=
> +
> +The PHYs on an MDIO bus [1] are probed and registered using
> +fwnode_mdiobus_register_phy().
Empty line here, please.
> +Later, for connecting these PHYs to MAC, the PHYs registered on the
> +MDIO bus have to be referenced.
> +
> +The UUID given below should be used as mentioned in the "Device Properties
> +UUID For _DSD" [2] document.
> + - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
I would drop the above paragraph.
> +
> +This document introduces two _DSD properties that are to be used
> +for PHYs on the MDIO bus.[3]
I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer."
above and add the following here:
"These properties are defined in accordance with the "Device
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them."
> +
> +phy-handle
> +--
> +For each MAC node, a device property "phy-handle" is used to reference
> +the PHY that is registered on an MDIO bus. This is mandatory for
> +network interfaces that have PHYs connected to MAC via MDIO bus.
> +
> +During the MDIO bus driver initialization, PHYs on this bus are probed
> +using the _ADR object as shown below and are registered on the MDIO bus.
Do you want to mention the "reg" property here? I think it would be
useful to do that.
> +
> +::
> + Scope(\_SB.MDI0)
> + {
> +Device(PHY1) {
> + Name (_ADR, 0x1)
> +} // end of PHY1
> +
> +Device(PHY2) {
> + Name (_ADR, 0x2)
> +} // end of PHY2
> + }
> +
> +Later, during the MAC driver initialization, the registered PHY devices
> +have to be retrieved from the MDIO bus. For this, MAC driver needs
"the MAC driver" I suppose?
> +reference to the previously registered PHYs which are provided
s/reference/references/ (plural)
> +using reference to the device as {\_SB.MDI0.PHY1}.
"as device object references (e.g. \_SB.MDI0.PHY1}."
> +
> +phy-mode
> +
> +The "phy-mode" _DSD property is used to describe the connection to
> +the PHY. The valid values for "phy-mode" are defined in [4].
> +
One empty line should be sufficient.
> +
> +An ASL example of this is shown below.
"The following ASL example illustrates the usage of these properties."
> +
> +DSDT entry for MDIO node
> +
Empty line here, please.
> +The MDIO bus has an SoC component(MDIO controller) and a platform
Missing space after "component".
> +component (PHYs on the MDIO bus).
> +
> +a) Silicon Component
> +This node describes the MDIO controller, MDI0
> +-
> +::
> + Scope(_SB)
> + {
> + Device(MDI0) {
> + Name(_HID, "NXP0006")
> + Name(_CCA, 1)
> + Name(_UID, 0)
> + Name(_CRS, ResourceTemplate() {
> + Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
> + Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
> + {
> +MDI0_IT
> + }
> + }) // end of _CRS for MDI0
> + } // end of MDI0
> + }
> +
> +b) Platform Component
> +This node defines the PHYs that are connected to the MDIO bus, MDI0
"The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0."
> +---
> +::
> + Scope(\_SB.MDI0)
> + {
> + Device(PHY1) {
> + Name (_ADR,
[net-next PATCH v4 01/15] Documentation: ACPI: DSD: Document MDIO PHY
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson
---
Changes in v4:
- More cleanup
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst
b/Documentation/firmware-guide/acpi/dsd/phy.rst
new file mode 100644
index ..76fca994bc99
--- /dev/null
+++ b/Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+MDIO bus and PHYs in ACPI
+=
+
+The PHYs on an MDIO bus [1] are probed and registered using
+fwnode_mdiobus_register_phy().
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+The UUID given below should be used as mentioned in the "Device Properties
+UUID For _DSD" [2] document.
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
+
+This document introduces two _DSD properties that are to be used
+for PHYs on the MDIO bus.[3]
+
+phy-handle
+--
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
+
+::
+ Scope(\_SB.MDI0)
+ {
+Device(PHY1) {
+ Name (_ADR, 0x1)
+} // end of PHY1
+
+Device(PHY2) {
+ Name (_ADR, 0x2)
+} // end of PHY2
+ }
+
+Later, during the MAC driver initialization, the registered PHY devices
+have to be retrieved from the MDIO bus. For this, MAC driver needs
+reference to the previously registered PHYs which are provided
+using reference to the device as {\_SB.MDI0.PHY1}.
+
+phy-mode
+
+The "phy-mode" _DSD property is used to describe the connection to
+the PHY. The valid values for "phy-mode" are defined in [4].
+
+
+An ASL example of this is shown below.
+
+DSDT entry for MDIO node
+
+The MDIO bus has an SoC component(MDIO controller) and a platform
+component (PHYs on the MDIO bus).
+
+a) Silicon Component
+This node describes the MDIO controller, MDI0
+-
+::
+ Scope(_SB)
+ {
+ Device(MDI0) {
+ Name(_HID, "NXP0006")
+ Name(_CCA, 1)
+ Name(_UID, 0)
+ Name(_CRS, ResourceTemplate() {
+ Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
+ Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
+ {
+MDI0_IT
+ }
+ }) // end of _CRS for MDI0
+ } // end of MDI0
+ }
+
+b) Platform Component
+This node defines the PHYs that are connected to the MDIO bus, MDI0
+---
+::
+ Scope(\_SB.MDI0)
+ {
+ Device(PHY1) {
+ Name (_ADR, 0x1)
+ } // end of PHY1
+
+ Device(PHY2) {
+ Name (_ADR, 0x2)
+ } // end of PHY2
+ }
+
+
+Below are the MAC nodes where PHY nodes are referenced.
+phy-mode and phy-handle are used as explained earlier.
+--
+::
+ Scope(\_SB.MCE0.PR17)
+ {
+ Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package (2) {"phy-mode", "rgmii-id"},
+Package (2) {"phy-handle", \_SB.MDI0.PHY1}
+ }
+ })
+ }
+
+ Scope(\_SB.MCE0.PR18)
+ {
+ Name (_DSD, Package () {
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package () {
+ Package (2) {"phy-mode", "rgmii-id"},
+ Package (2) {"phy-handle", \_SB.MDI0.PHY2}}
+ }
+ })
+ }
+
+References
+==
+
+[1] Documentation/networking/phy.rst
+
+[2]
https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
+
+[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst
+
+[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml
--
2.17.1
[PATCH v2 iproute2] man: tc-taprio.8: document the full offload feature
From: Vladimir Oltean
Since this feature's introduction in commit 9c66d1564676 ("taprio: Add
support for hardware offloading") from kernel v5.4, it never got
documented in the man pages. Due to this reason, we see customer reports
of seemingly contradictory information: the community manpages claim
there is no support for full offload, nonetheless many silicon vendors
have already implemented it.
This patch documents the full offload feature (enabled by specifying
"flags 2" to the taprio qdisc) and gives one more example that tries to
illustrate some of the finer points related to the usage.
Signed-off-by: Vladimir Oltean
---
Changes in v2:
Some wording adjustments.
man/man8/tc-taprio.8 | 51 +++-
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/man/man8/tc-taprio.8 b/man/man8/tc-taprio.8
index e1d19ba19089..d13c86f779b7 100644
--- a/man/man8/tc-taprio.8
+++ b/man/man8/tc-taprio.8
@@ -92,7 +92,11 @@ in the schedule;
clockid
.br
Specifies the clock to be used by qdisc's internal timer for measuring
-time and scheduling events.
+time and scheduling events. This argument must be omitted when using the
+full-offload feature (flags 0x2), since in that case, the clockid is
+implicitly /dev/ptpN (where N is given by
+.B ethtool -T eth0 | grep 'PTP Hardware Clock'
+), and therefore not necessarily synchronized with the system's CLOCK_TAI.
.TP
sched-entry
@@ -115,13 +119,27 @@ before moving to the next entry.
.TP
flags
.br
-Specifies different modes for taprio. Currently, only txtime-assist is
-supported which can be enabled by setting it to 0x1. In this mode, taprio will
-set the transmit timestamp depending on the interval in which the packet needs
-to be transmitted. It will then utililize the
+This is a bit mask which specifies different modes for taprio.
+.RS
+.TP
+.I 0x1
+Enables the txtime-assist feature. In this mode, taprio will set the transmit
+timestamp depending on the interval in which the packet needs to be
+transmitted. It will then utililize the
.BR etf(8)
qdisc to sort and transmit the packets at the right time. The second example
can be used as a reference to configure this mode.
+.TP
+.I 0x2
+Enables the full-offload feature. In this mode, taprio will pass the gate
+control list to the NIC which will execute it cyclically in hardware.
+When using full-offload, there is no need to specify the
+.B clockid
+argument.
+
+The txtime-assist and full-offload features are mutually exclusive, i.e.
+setting flags to 0x3 is invalid.
+.RE
.TP
txtime-delay
@@ -178,5 +196,28 @@ for more information about configuring the ETF qdisc.
offload delta 20 clockid CLOCK_TAI
.EE
+The following is a schedule in full offload mode. The
+.B base-time
+is 200 ns and the
+.B cycle-time
+is implicitly calculated as the sum of all
+.B sched-entry
+durations (i.e. 20 us + 20 us + 60 us = 100 us). Although the base-time is in
+the past, the hardware will start executing the schedule at a PTP time equal to
+the smallest integer multiple of 100 us, plus 200 ns, that is larger than the
+NIC's current PTP time.
+
+.EX
+# tc qdisc add dev eth0 parent root taprio \\
+ num_tc 8 \\
+ map 0 1 2 3 4 5 6 7 \\
+ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \\
+ base-time 200 \\
+ sched-entry S 80 2 \\
+ sched-entry S a0 2 \\
+ sched-entry S df 6 \\
+ flags 0x2
+.EE
+
.SH AUTHORS
Vinicius Costa Gomes
--
2.25.1
Re: [PATCH iproute2] man: tc-taprio.8: document the full offload feature
On 1/21/21 5:37 PM, Vladimir Oltean wrote: > On Thu, Jan 21, 2021 at 04:10:06PM -0700, David Ahern wrote: >> On 1/21/21 2:57 PM, Vladimir Oltean wrote: >>> On Thu, Jan 21, 2021 at 11:47:08PM +0200, Vladimir Oltean wrote: +Enables the full-offload feature. In this mode, taprio will pass the gate +control list to the NIC which will execute cyclically it in hardware. >>> >>> Ugh, I meant "execute it cyclically" not "execute cyclically it". >>> David, could you fix this up or do I need to resend? >>> >> >> I'll fix up > > And I just noticed that ".BR etf(8)" needs to be on a line of its own. > Sorry... > send a new version
Re: [PATCH iproute2] man: tc-taprio.8: document the full offload feature
On Thu, Jan 21, 2021 at 04:10:06PM -0700, David Ahern wrote: > On 1/21/21 2:57 PM, Vladimir Oltean wrote: > > On Thu, Jan 21, 2021 at 11:47:08PM +0200, Vladimir Oltean wrote: > >> +Enables the full-offload feature. In this mode, taprio will pass the gate > >> +control list to the NIC which will execute cyclically it in hardware. > > > > Ugh, I meant "execute it cyclically" not "execute cyclically it". > > David, could you fix this up or do I need to resend? > > > > I'll fix up And I just noticed that ".BR etf(8)" needs to be on a line of its own. Sorry...
Re: [PATCH iproute2] man: tc-taprio.8: document the full offload feature
On 1/21/21 2:57 PM, Vladimir Oltean wrote: > On Thu, Jan 21, 2021 at 11:47:08PM +0200, Vladimir Oltean wrote: >> +Enables the full-offload feature. In this mode, taprio will pass the gate >> +control list to the NIC which will execute cyclically it in hardware. > > Ugh, I meant "execute it cyclically" not "execute cyclically it". > David, could you fix this up or do I need to resend? > I'll fix up
Re: [PATCH iproute2] man: tc-taprio.8: document the full offload feature
On Thu, Jan 21, 2021 at 11:47:08PM +0200, Vladimir Oltean wrote: > +Enables the full-offload feature. In this mode, taprio will pass the gate > +control list to the NIC which will execute cyclically it in hardware. Ugh, I meant "execute it cyclically" not "execute cyclically it". David, could you fix this up or do I need to resend?
[PATCH iproute2] man: tc-taprio.8: document the full offload feature
From: Vladimir Oltean
Since this feature's introduction in commit 9c66d1564676 ("taprio: Add
support for hardware offloading") from kernel v5.4, it never got
documented in the man pages. Due to this reason, we see customer reports
of seemingly contradictory information: the community manpages claim
there is no support for full offload, nonetheless many silicon vendors
have already implemented it.
This patch documents the full offload feature (enabled by specifying
"flags 2" to the taprio qdisc) and gives one more example that tries to
illustrate some of the finer points related to the usage.
Signed-off-by: Vladimir Oltean
---
man/man8/tc-taprio.8 | 58 ++--
1 file changed, 50 insertions(+), 8 deletions(-)
diff --git a/man/man8/tc-taprio.8 b/man/man8/tc-taprio.8
index e1d19ba19089..ed3a2c06e0e9 100644
--- a/man/man8/tc-taprio.8
+++ b/man/man8/tc-taprio.8
@@ -92,7 +92,11 @@ in the schedule;
clockid
.br
Specifies the clock to be used by qdisc's internal timer for measuring
-time and scheduling events.
+time and scheduling events. This argument must be omitted when using the
+full-offload feature (flags 0x2), since in that case, the clockid is
+implicitly /dev/ptpN (where N is given by
+.B ethtool -T eth0 | grep 'PTP Hardware Clock'
+), and therefore not necessarily synchronized with the system's CLOCK_TAI.
.TP
sched-entry
@@ -115,13 +119,26 @@ before moving to the next entry.
.TP
flags
.br
-Specifies different modes for taprio. Currently, only txtime-assist is
-supported which can be enabled by setting it to 0x1. In this mode, taprio will
-set the transmit timestamp depending on the interval in which the packet needs
-to be transmitted. It will then utililize the
-.BR etf(8)
-qdisc to sort and transmit the packets at the right time. The second example
-can be used as a reference to configure this mode.
+This is a bit mask which specifies different modes for taprio.
+.RS
+.TP
+.I 0x1
+Enables the txtime-assist feature. In this mode, taprio will set the transmit
+timestamp depending on the interval in which the packet needs to be
+transmitted. It will then utililize the .BR etf(8) qdisc to sort and transmit
+the packets at the right time. The second example can be used as a reference to
+configure this mode.
+.TP
+.I 0x2
+Enables the full-offload feature. In this mode, taprio will pass the gate
+control list to the NIC which will execute cyclically it in hardware.
+When using full-offload, there is no need to specify the
+.B clockid
+argument.
+
+The txtime-assist and full-offload features are mutually exclusive, i.e.
+setting flags to 0x3 is invalid.
+.RE
.TP
txtime-delay
@@ -178,5 +195,30 @@ for more information about configuring the ETF qdisc.
offload delta 20 clockid CLOCK_TAI
.EE
+The following is an example to enable the full-offload mode in taprio. The
+.B base-time
+is 200 ns and the
+.B cycle-time
+is implicitly calculated as the sum of all
+.B sched-entry
+durations (i.e. 20 us + 20 us + 60 us = 100 us). Because the
+.B base-time
+is when the administratively configured schedule will become operational, this
+in turn means that the hardware will start executing the schedule at a PTP time
+equal to the smallest integer multiple of 100 us, plus 200 ns, that is larger
+than the NIC's current PTP time.
+
+.EX
+# tc qdisc add dev eth0 parent root taprio \\
+ num_tc 8 \\
+ map 0 1 2 3 4 5 6 7 \\
+ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \\
+ base-time 200 \\
+ sched-entry S 80 2 \\
+ sched-entry S a0 2 \\
+ sched-entry S df 6 \\
+ flags 0x2
+.EE
+
.SH AUTHORS
Vinicius Costa Gomes
--
2.25.1
