* Re: [PATCH 1/2] docs: net: ieee802154: change link to new project URL
From: Stefan Schmidt @ 2020-06-19 7:14 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-wpan, alex.aring
In-Reply-To: <20200616065814.816248-1-stefan@datenfreihafen.org>
Hello Dave.
On 16.06.20 08:58, Stefan Schmidt wrote:
> We finally came around to setup a new project website.
> Update the reference here.
>
> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
> ---
> Documentation/networking/ieee802154.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/networking/ieee802154.rst b/Documentation/networking/ieee802154.rst
> index 36ca823a1122..6f4bf8447a21 100644
> --- a/Documentation/networking/ieee802154.rst
> +++ b/Documentation/networking/ieee802154.rst
> @@ -30,8 +30,8 @@ Socket API
>
> The address family, socket addresses etc. are defined in the
> include/net/af_ieee802154.h header or in the special header
> -in the userspace package (see either http://wpan.cakelab.org/ or the
> -git tree at https://github.com/linux-wpan/wpan-tools).
> +in the userspace package (see either https://linux-wpan.org/wpan-tools.html
> +or the git tree at https://github.com/linux-wpan/wpan-tools).
>
> 6LoWPAN Linux implementation
> ============================
>
I see you marked both patches here as awaiting upstream in patchwork. I
am not really sure what to do best now. Am I supposed to pick them up
myself and send them in my usual ieee802154 pull request?
Before you had been picking up docs and MAINTAINERS patches directly. I
am fine with either way. Just want to check what you expect.
regards
Stefan Schmidt
^ permalink raw reply
* RE: [PATCH net-next 5/5] net: dsa: felix: use the Lynx PCS helpers
From: Ioana Ciornei @ 2020-06-19 7:43 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev@vger.kernel.org, davem@davemloft.net, Vladimir Oltean,
Claudiu Manoil, Alexandru Marginean, michael@walle.cc,
andrew@lunn.ch, linux@armlinux.org.uk, f.fainelli@gmail.com
In-Reply-To: <20200618084844.1540e6d2@kicinski-fedora-PC1C0HJN>
> Subject: Re: [PATCH net-next 5/5] net: dsa: felix: use the Lynx PCS helpers
>
> On Thu, 18 Jun 2020 15:08:37 +0300 Ioana Ciornei wrote:
> > Use the helper functions introduced by the newly added Lynx PCS MDIO
> > module.
> >
> > Instead of representing the PCS as a phy_device, a mdio_device
> > structure will be passed to the Lynx module which is now actually
> > implementing all the PCS configuration and status reporting.
> >
> > All code previously used for PCS momnitoring and runtime configuration
> > is removed and replaced will calls to the Lynx PCS operations.
> >
> > Tested on the following SERDES protocols of LS1028A: 0x7777
> > (2500Base-X), 0x85bb (QSGMII), 0x9999 (SGMII) and 0x13bb (USXGMII).
> >
> > Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> > Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> Hm, this does not build with allmodconfig.
>
> drivers/net/phy/mdio-lynx-pcs.o: In function `lynx_pcs_link_up':
> mdio-lynx-pcs.c:(.text+0x115): undefined reference to `mdiobus_modify'
> mdio-lynx-pcs.c:(.text+0x1a3): undefined reference to `mdiobus_write'
> drivers/net/phy/mdio-lynx-pcs.o: In function `lynx_pcs_config':
> mdio-lynx-pcs.c:(.text+0x33a): undefined reference to `mdiobus_write'
> mdio-lynx-pcs.c:(.text+0x371): undefined reference to `mdiobus_modify'
> mdio-lynx-pcs.c:(.text+0x384): undefined reference to
> `phylink_mii_c22_pcs_config'
> mdio-lynx-pcs.c:(.text+0x3e4): undefined reference to `mdiobus_write'
> mdio-lynx-pcs.c:(.text+0x40d): undefined reference to `mdiobus_write'
> mdio-lynx-pcs.c:(.text+0x422): undefined reference to `mdiobus_write'
> drivers/net/phy/mdio-lynx-pcs.o: In function
> `lynx_pcs_get_state_usxgmii.isra.0':
> mdio-lynx-pcs.c:(.text+0x457): undefined reference to `mdiobus_read'
> mdio-lynx-pcs.c:(.text+0x4f1): undefined reference to `mdiobus_read'
> drivers/net/phy/mdio-lynx-pcs.o: In function `lynx_pcs_get_state':
> mdio-lynx-pcs.c:(.text+0x650): undefined reference to
> `phylink_mii_c22_pcs_get_state'
> mdio-lynx-pcs.c:(.text+0x6fb): undefined reference to `phy_duplex_to_str'
> mdio-lynx-pcs.c:(.text+0x711): undefined reference to `phy_speed_to_str'
> mdio-lynx-pcs.c:(.text+0x7c0): undefined reference to `mdiobus_read'
> mdio-lynx-pcs.c:(.text+0x7d4): undefined reference to `mdiobus_read'
> drivers/net/phy/mdio-lynx-pcs.o: In function `lynx_pcs_an_restart':
> mdio-lynx-pcs.c:(.text+0x954): undefined reference to `mdiobus_write'
> mdio-lynx-pcs.c:(.text+0x978): undefined reference to
> `phylink_mii_c22_pcs_an_restart'
> make[1]: *** [vmlinux] Error 1
> make: *** [__sub-make] Error 2
Hmm, it seems that making the Kconfig just bool instead of tristate is the problem.
Thank,
Ioana
^ permalink raw reply
* [PATCH 4/5] esp: select CRYPTO_SEQIV
From: Steffen Klassert @ 2020-06-19 7:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20200619074342.14095-1-steffen.klassert@secunet.com>
From: Eric Biggers <ebiggers@google.com>
Commit f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV") made
CRYPTO_CTR stop selecting CRYPTO_SEQIV. This breaks IPsec for most
users since GCM and several other encryption algorithms require "seqiv"
-- and RFC 8221 lists AES-GCM as "MUST" be implemented.
Just make XFRM_ESP select CRYPTO_SEQIV.
Fixes: f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV")
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Corentin Labbe <clabbe@baylibre.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index 169c22140709..b2ff8df2c836 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -86,6 +86,7 @@ config XFRM_ESP
select CRYPTO_SHA1
select CRYPTO_DES
select CRYPTO_ECHAINIV
+ select CRYPTO_SEQIV
config XFRM_IPCOMP
tristate
--
2.17.1
^ permalink raw reply related
* [PATCH 2/5] xfrm: merge fixup for "remove output_finish indirection from xfrm_state_afinfo"
From: Steffen Klassert @ 2020-06-19 7:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20200619074342.14095-1-steffen.klassert@secunet.com>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_output.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index e4c23f69f69f..a7ab19353313 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -574,16 +574,12 @@ int xfrm_output(struct sock *sk, struct sk_buff *skb)
switch (x->outer_mode.family) {
case AF_INET:
memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
-#ifdef CONFIG_NETFILTER
IPCB(skb)->flags |= IPSKB_XFRM_TRANSFORMED;
-#endif
break;
case AF_INET6:
memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
-#ifdef CONFIG_NETFILTER
IP6CB(skb)->flags |= IP6SKB_XFRM_TRANSFORMED;
-#endif
break;
}
--
2.17.1
^ permalink raw reply related
* [PATCH 5/5] esp, ah: modernize the crypto algorithm selections
From: Steffen Klassert @ 2020-06-19 7:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20200619074342.14095-1-steffen.klassert@secunet.com>
From: Eric Biggers <ebiggers@google.com>
The crypto algorithms selected by the ESP and AH kconfig options are
out-of-date with the guidance of RFC 8221, which lists the legacy
algorithms MD5 and DES as "MUST NOT" be implemented, and some more
modern algorithms like AES-GCM and HMAC-SHA256 as "MUST" be implemented.
But the options select the legacy algorithms, not the modern ones.
Therefore, modify these options to select the MUST algorithms --
and *only* the MUST algorithms.
Also improve the help text.
Note that other algorithms may still be explicitly enabled in the
kconfig, and the choice of which to actually use is still controlled by
userspace. This change only modifies the list of algorithms for which
kernel support is guaranteed to be present.
Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
Suggested-by: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Corentin Labbe <clabbe@baylibre.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/Kconfig | 18 ++++++++++++++++--
net/ipv6/Kconfig | 18 ++++++++++++++++--
net/xfrm/Kconfig | 15 +++++++++------
3 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 39a7a21744dc..dc9dfaef77e5 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -342,7 +342,14 @@ config INET_AH
tristate "IP: AH transformation"
select XFRM_AH
---help---
- Support for IPsec AH.
+ Support for IPsec AH (Authentication Header).
+
+ AH can be used with various authentication algorithms. Besides
+ enabling AH support itself, this option enables the generic
+ implementations of the algorithms that RFC 8221 lists as MUST be
+ implemented. If you need any other algorithms, you'll need to enable
+ them in the crypto API. You should also enable accelerated
+ implementations of any needed algorithms when available.
If unsure, say Y.
@@ -350,7 +357,14 @@ config INET_ESP
tristate "IP: ESP transformation"
select XFRM_ESP
---help---
- Support for IPsec ESP.
+ Support for IPsec ESP (Encapsulating Security Payload).
+
+ ESP can be used with various encryption and authentication algorithms.
+ Besides enabling ESP support itself, this option enables the generic
+ implementations of the algorithms that RFC 8221 lists as MUST be
+ implemented. If you need any other algorithms, you'll need to enable
+ them in the crypto API. You should also enable accelerated
+ implementations of any needed algorithms when available.
If unsure, say Y.
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index 70313f16319d..414a68b16869 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -51,7 +51,14 @@ config INET6_AH
tristate "IPv6: AH transformation"
select XFRM_AH
---help---
- Support for IPsec AH.
+ Support for IPsec AH (Authentication Header).
+
+ AH can be used with various authentication algorithms. Besides
+ enabling AH support itself, this option enables the generic
+ implementations of the algorithms that RFC 8221 lists as MUST be
+ implemented. If you need any other algorithms, you'll need to enable
+ them in the crypto API. You should also enable accelerated
+ implementations of any needed algorithms when available.
If unsure, say Y.
@@ -59,7 +66,14 @@ config INET6_ESP
tristate "IPv6: ESP transformation"
select XFRM_ESP
---help---
- Support for IPsec ESP.
+ Support for IPsec ESP (Encapsulating Security Payload).
+
+ ESP can be used with various encryption and authentication algorithms.
+ Besides enabling ESP support itself, this option enables the generic
+ implementations of the algorithms that RFC 8221 lists as MUST be
+ implemented. If you need any other algorithms, you'll need to enable
+ them in the crypto API. You should also enable accelerated
+ implementations of any needed algorithms when available.
If unsure, say Y.
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index b2ff8df2c836..e77ba529229c 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -67,26 +67,29 @@ config XFRM_STATISTICS
If unsure, say N.
+# This option selects XFRM_ALGO along with the AH authentication algorithms that
+# RFC 8221 lists as MUST be implemented.
config XFRM_AH
tristate
select XFRM_ALGO
select CRYPTO
select CRYPTO_HMAC
- select CRYPTO_MD5
- select CRYPTO_SHA1
+ select CRYPTO_SHA256
+# This option selects XFRM_ALGO along with the ESP encryption and authentication
+# algorithms that RFC 8221 lists as MUST be implemented.
config XFRM_ESP
tristate
select XFRM_ALGO
select CRYPTO
+ select CRYPTO_AES
select CRYPTO_AUTHENC
- select CRYPTO_HMAC
- select CRYPTO_MD5
select CRYPTO_CBC
- select CRYPTO_SHA1
- select CRYPTO_DES
select CRYPTO_ECHAINIV
+ select CRYPTO_GCM
+ select CRYPTO_HMAC
select CRYPTO_SEQIV
+ select CRYPTO_SHA256
config XFRM_IPCOMP
tristate
--
2.17.1
^ permalink raw reply related
* [PATCH 1/5] xfrm: Fix double ESP trailer insertion in IPsec crypto offload.
From: Steffen Klassert @ 2020-06-19 7:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20200619074342.14095-1-steffen.klassert@secunet.com>
From: Huy Nguyen <huyn@mellanox.com>
During IPsec performance testing, we see bad ICMP checksum. The error packet
has duplicated ESP trailer due to double validate_xmit_xfrm calls. The first call
is from ip_output, but the packet cannot be sent because
netif_xmit_frozen_or_stopped is true and the packet gets dev_requeue_skb. The second
call is from NET_TX softirq. However after the first call, the packet already
has the ESP trailer.
Fix by marking the skb with XFRM_XMIT bit after the packet is handled by
validate_xmit_xfrm to avoid duplicate ESP trailer insertion.
Fixes: f6e27114a60a ("net: Add a xfrm validate function to validate_xmit_skb")
Signed-off-by: Huy Nguyen <huyn@mellanox.com>
Reviewed-by: Boris Pismenny <borisp@mellanox.com>
Reviewed-by: Raed Salem <raeds@mellanox.com>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/net/xfrm.h | 1 +
net/xfrm/xfrm_device.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 094fe682f5d7..c7d213c9f9d8 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1008,6 +1008,7 @@ struct xfrm_offload {
#define XFRM_GRO 32
#define XFRM_ESP_NO_TRAILER 64
#define XFRM_DEV_RESUME 128
+#define XFRM_XMIT 256
__u32 status;
#define CRYPTO_SUCCESS 1
diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
index f50d1f97cf8e..626096bd0d29 100644
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@ -108,7 +108,7 @@ struct sk_buff *validate_xmit_xfrm(struct sk_buff *skb, netdev_features_t featur
struct xfrm_offload *xo = xfrm_offload(skb);
struct sec_path *sp;
- if (!xo)
+ if (!xo || (xo->flags & XFRM_XMIT))
return skb;
if (!(features & NETIF_F_HW_ESP))
@@ -129,6 +129,8 @@ struct sk_buff *validate_xmit_xfrm(struct sk_buff *skb, netdev_features_t featur
return skb;
}
+ xo->flags |= XFRM_XMIT;
+
if (skb_is_gso(skb)) {
struct net_device *dev = skb->dev;
--
2.17.1
^ permalink raw reply related
* pull request (net): ipsec 2020-06-19
From: Steffen Klassert @ 2020-06-19 7:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
1) Fix double ESP trailer insertion in IPsec crypto offload if
netif_xmit_frozen_or_stopped is true. From Huy Nguyen.
2) Merge fixup for "remove output_finish indirection from
xfrm_state_afinfo". From Stephen Rothwell.
3) Select CRYPTO_SEQIV for ESP as this is needed for GCM and several
other encryption algorithms. Also modernize the crypto algorithm
selections for ESP and AH, remove those that are maked as "MUST NOT"
and add those that are marked as "MUST" be implemented in RFC 8221.
From Eric Biggers.
Please note the merge conflict between commit:
a7f7f6248d97 ("treewide: replace '---help---' in Kconfig files with 'help'")
from Linus' tree and commits:
7d4e39195925 ("esp, ah: consolidate the crypto algorithm selections")
be01369859b8 ("esp, ah: modernize the crypto algorithm selections")
from the ipsec tree.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next (2020-06-03 16:27:18 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master
for you to fetch changes up to be01369859b8aa07346e497381bb46d377da0d8c:
esp, ah: modernize the crypto algorithm selections (2020-06-15 06:52:16 +0200)
----------------------------------------------------------------
Eric Biggers (3):
esp, ah: consolidate the crypto algorithm selections
esp: select CRYPTO_SEQIV
esp, ah: modernize the crypto algorithm selections
Huy Nguyen (1):
xfrm: Fix double ESP trailer insertion in IPsec crypto offload.
Stephen Rothwell (1):
xfrm: merge fixup for "remove output_finish indirection from xfrm_state_afinfo"
include/net/xfrm.h | 1 +
net/ipv4/Kconfig | 34 ++++++++++++++++++----------------
net/ipv6/Kconfig | 34 ++++++++++++++++++----------------
net/xfrm/Kconfig | 24 ++++++++++++++++++++++++
net/xfrm/xfrm_device.c | 4 +++-
net/xfrm/xfrm_output.c | 4 ----
6 files changed, 64 insertions(+), 37 deletions(-)
^ permalink raw reply
* [PATCH 3/5] esp, ah: consolidate the crypto algorithm selections
From: Steffen Klassert @ 2020-06-19 7:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20200619074342.14095-1-steffen.klassert@secunet.com>
From: Eric Biggers <ebiggers@google.com>
Instead of duplicating the algorithm selections between INET_AH and
INET6_AH and between INET_ESP and INET6_ESP, create new tristates
XFRM_AH and XFRM_ESP that do the algorithm selections, and make these be
selected by the corresponding INET* options.
Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Corentin Labbe <clabbe@baylibre.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/Kconfig | 16 ++--------------
net/ipv6/Kconfig | 16 ++--------------
net/xfrm/Kconfig | 20 ++++++++++++++++++++
3 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 23ba5045e3d3..39a7a21744dc 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -340,11 +340,7 @@ config NET_FOU_IP_TUNNELS
config INET_AH
tristate "IP: AH transformation"
- select XFRM_ALGO
- select CRYPTO
- select CRYPTO_HMAC
- select CRYPTO_MD5
- select CRYPTO_SHA1
+ select XFRM_AH
---help---
Support for IPsec AH.
@@ -352,15 +348,7 @@ config INET_AH
config INET_ESP
tristate "IP: ESP transformation"
- select XFRM_ALGO
- select CRYPTO
- select CRYPTO_AUTHENC
- select CRYPTO_HMAC
- select CRYPTO_MD5
- select CRYPTO_CBC
- select CRYPTO_SHA1
- select CRYPTO_DES
- select CRYPTO_ECHAINIV
+ select XFRM_ESP
---help---
Support for IPsec ESP.
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index 4f03aece2980..70313f16319d 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -49,11 +49,7 @@ config IPV6_OPTIMISTIC_DAD
config INET6_AH
tristate "IPv6: AH transformation"
- select XFRM_ALGO
- select CRYPTO
- select CRYPTO_HMAC
- select CRYPTO_MD5
- select CRYPTO_SHA1
+ select XFRM_AH
---help---
Support for IPsec AH.
@@ -61,15 +57,7 @@ config INET6_AH
config INET6_ESP
tristate "IPv6: ESP transformation"
- select XFRM_ALGO
- select CRYPTO
- select CRYPTO_AUTHENC
- select CRYPTO_HMAC
- select CRYPTO_MD5
- select CRYPTO_CBC
- select CRYPTO_SHA1
- select CRYPTO_DES
- select CRYPTO_ECHAINIV
+ select XFRM_ESP
---help---
Support for IPsec ESP.
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index b7fd9c838416..169c22140709 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -67,6 +67,26 @@ config XFRM_STATISTICS
If unsure, say N.
+config XFRM_AH
+ tristate
+ select XFRM_ALGO
+ select CRYPTO
+ select CRYPTO_HMAC
+ select CRYPTO_MD5
+ select CRYPTO_SHA1
+
+config XFRM_ESP
+ tristate
+ select XFRM_ALGO
+ select CRYPTO
+ select CRYPTO_AUTHENC
+ select CRYPTO_HMAC
+ select CRYPTO_MD5
+ select CRYPTO_CBC
+ select CRYPTO_SHA1
+ select CRYPTO_DES
+ select CRYPTO_ECHAINIV
+
config XFRM_IPCOMP
tristate
select XFRM_ALGO
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] linux++, this: rename "struct notifier_block *this"
From: Christoph Hellwig @ 2020-06-19 7:46 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: torvalds, linux-kernel, netdev, linux-arch, netfilter-devel
In-Reply-To: <20200618210645.GB2212102@localhost.localdomain>
On Fri, Jun 19, 2020 at 12:06:45AM +0300, Alexey Dobriyan wrote:
> Rename
> struct notifier_block *this
> to
> struct notifier_block *nb
>
> "nb" is arguably a better name for notifier block.
But not enough better to cause tons of pointless churn. Feel free
to use better naming in new code you write or do significant changes
to, but stop these pointless renames.
^ permalink raw reply
* Re: [PATCHv2 net] tc-testing: update geneve options match in tunnel_key unit tests
From: Davide Caratti @ 2020-06-19 8:02 UTC (permalink / raw)
To: Hangbin Liu, netdev; +Cc: Lucas Bates, Simon Horman, David Miller
In-Reply-To: <20200619032445.664868-1-liuhangbin@gmail.com>
thanks for the patch,
On Fri, 2020-06-19 at 11:24 +0800, Hangbin Liu wrote:
> Since iproute2 commit f72c3ad00f3b ("tc: m_tunnel_key: add options
> support for vxlan"), the geneve opt output use key word "geneve_opts"
> instead of "geneve_opt". To make compatibility for both old and new
> iproute2, let's accept both "geneve_opt" and "geneve_opts".
>
> Suggested-by: Davide Caratti <dcaratti@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> .../tc-testing/tc-tests/actions/tunnel_key.json | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
it has been successfully verified with the following command:
# for t in 4f20 e33d 0778 4ae8 4039 26a6 f44d ; do ./tdc.py -e $t ; done
using two tc binaries, one compiled from f72c3ad00f3b^ and the other one
from HEAD. I would have liked to see a list of OK with this command:
# ./tdc.cy -c tunnel_key
but (at least on my test setup) I see a failure here:
# ./tdc.py -e 364d
Test 364d: Replace tunnel_key set action with all parameters and cookie
-----> prepare stage *** Could not execute: "$TC actions add action tunnel_key set src_ip 10.10.10.1 dst_ip 20.20.20.2 dst_port 3128 nocsum id 1 index 1 cooki
e aabbccddeeff112233445566778800a"
-----> prepare stage *** Error message: "Error: argument "aabbccddeeff112233445566778800a" is wrong: cookie must be a hex string
"
returncode 255; expected [0]
-----> prepare stage *** Aborting test run.
<_io.BufferedReader name=3> *** stdout ***
<_io.BufferedReader name=5> *** stderr ***
"-----> prepare stage" did not complete successfully
Exception <class '__main__.PluginMgrTestFail'> ('setup', None, '"-----> prepare stage" did not complete successfully') (caught in test_runner, running test 2
364d Replace tunnel_key set action with all parameters and cookie stage setup)
---------------
traceback
File "./tdc.py", line 371, in test_runner
res = run_one_test(pm, args, index, tidx)
File "./tdc.py", line 272, in run_one_test
prepare_env(args, pm, 'setup', "-----> prepare stage", tidx["setup"])
File "./tdc.py", line 245, in prepare_env
raise PluginMgrTestFail(
---------------
---------------
All test results:
1..1
ok 1 364d - Replace tunnel_key set action with all parameters and cookie # skipped - "-----> prepare stage" did not complete successfully
I checked twice, and the problem only happens with the new iproute2 binary.
So, there seems to be an additional tdc breakage in the latest iproute2.
But the problem looks unrelated to your patch, and I follow-up in the next hours.
Tested-by: Davide Caratti <dcaratti@redhat.com>
^ permalink raw reply
* Re: [RFC PATCH 2/9] net: dsa: Add DSA driver for Hirschmann Hellcreek switches
From: Kurt Kanzenbach @ 2020-06-19 8:12 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, Jakub Kicinski,
netdev, Rob Herring, devicetree, Sebastian Andrzej Siewior,
Richard Cochran, Kamil Alkhouri, ilias.apalodimas
In-Reply-To: <20200618152247.GF240559@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 5947 bytes --]
Hi Andrew,
first off thank you for the review.
On Thu Jun 18 2020, Andrew Lunn wrote:
>> +static void __hellcreek_select_port(struct hellcreek *hellcreek, int port)
>
> Hi Kurt
>
> In general, please can you drop all these __ prefixes. They are useful
> when you have for example hellcreek_select_port() takes a lock and
> then calls _hellcreek_select_port(), but here, there is no need for
> them.
OK, sure.
>
>> +static int hellcreek_detect(struct hellcreek *hellcreek)
>> +{
>> + u8 tgd_maj, tgd_min;
>> + u16 id, rel_low, rel_high, date_low, date_high, tgd_ver;
>> + u32 rel, date;
>
> Reverse Christmas tree please. Here and everywhere else.
OK.
>
>> +
>> + id = hellcreek_read(hellcreek, HR_MODID_C);
>> + rel_low = hellcreek_read(hellcreek, HR_REL_L_C);
>> + rel_high = hellcreek_read(hellcreek, HR_REL_H_C);
>> + date_low = hellcreek_read(hellcreek, HR_BLD_L_C);
>> + date_high = hellcreek_read(hellcreek, HR_BLD_H_C);
>> + tgd_ver = hellcreek_read(hellcreek, TR_TGDVER);
>> +
>> + if (id != HELLCREEK_MODULE_ID)
>> + return -ENODEV;
>> +
>> + rel = rel_low | (rel_high << 16);
>> + date = date_low | (date_high << 16);
>> + tgd_maj = (tgd_ver & TR_TGDVER_REV_MAJ_MASK) >> TR_TGDVER_REV_MAJ_SHIFT;
>> + tgd_min = (tgd_ver & TR_TGDVER_REV_MIN_MASK) >> TR_TGDVER_REV_MIN_SHIFT;
>> +
>> + dev_info(hellcreek->dev, "Module ID=%02x Release=%04x Date=%04x TGD Version=%02x.%02x\n",
>> + id, rel, date, tgd_maj, tgd_min);
>> +
>> + return 0;
>> +}
>
>> +static int hellcreek_port_enable(struct dsa_switch *ds, int port,
>> + struct phy_device *phy)
>> +{
>> + struct hellcreek *hellcreek = ds->priv;
>> + struct hellcreek_port *hellcreek_port = &hellcreek->ports[port];
>> + unsigned long flags;
>> + u16 val;
>> +
>> + if (port >= NUM_PORTS)
>> + return -EINVAL;
>> +
>> + dev_info(hellcreek->dev, "Enable port %d\n", port);
>
> dev_dbg().
These are debug messages. I'll change that in the complete code.
>
> +
>> + spin_lock_irqsave(&hellcreek->reg_lock, flags);
>
> I've not seen any interrupt handling code in the driver, and there is
> no mention of an interrupt in the DT binding. Do you really need
> _irqsave spin locks?
Yes, I do. The TAPRIO offloading patch later adds hrtimers and that's
why it's needed. However, in this particular patch it is not required,
but I didn't want to change all spin lock calls later.
>
>> +
>> + __hellcreek_select_port(hellcreek, port);
>> + val = hellcreek_port->ptcfg;
>> + val |= HR_PTCFG_ADMIN_EN;
>> + hellcreek_write(hellcreek, val, HR_PTCFG);
>> + hellcreek_port->ptcfg = val;
>> +
>> + spin_unlock_irqrestore(&hellcreek->reg_lock, flags);
>> +
>> + return 0;
>> +}
>> +
>> +static void hellcreek_port_disable(struct dsa_switch *ds, int port)
>> +{
>> + struct hellcreek *hellcreek = ds->priv;
>> + struct hellcreek_port *hellcreek_port = &hellcreek->ports[port];
>> + unsigned long flags;
>> + u16 val;
>> +
>> + if (port >= NUM_PORTS)
>> + return;
>
> I don't think this test is actually needed, here or in any of the
> other callbacks. If it does happen, it means we have a core bug we
> should fix.
Agreed.
>
>> +
>> + dev_info(hellcreek->dev, "Disable port %d\n", port);
>
> dev_dbg()
>
>> + spin_lock_irqsave(&hellcreek->reg_lock, flags);
>> +
>> + __hellcreek_select_port(hellcreek, port);
>> + val = hellcreek_port->ptcfg;
>> + val &= ~HR_PTCFG_ADMIN_EN;
>> + hellcreek_write(hellcreek, val, HR_PTCFG);
>> + hellcreek_port->ptcfg = val;
>> +
>> + spin_unlock_irqrestore(&hellcreek->reg_lock, flags);
>> +}
>> +
>
>> +static void hellcreek_get_ethtool_stats(struct dsa_switch *ds, int port,
>> + uint64_t *data)
>> +{
>> + struct hellcreek *hellcreek = ds->priv;
>> + struct hellcreek_port *hellcreek_port = &hellcreek->ports[port];
>> + unsigned long flags;
>> + int i;
>> +
>> + if (port >= NUM_PORTS)
>> + return;
>> +
>> + spin_lock_irqsave(&hellcreek->reg_lock, flags);
>> + for (i = 0; i < ARRAY_SIZE(hellcreek_counter); ++i) {
>> + const struct hellcreek_counter *counter = &hellcreek_counter[i];
>> + u8 offset = counter->offset + port * 64;
>> + u16 high, low;
>> + u64 value = 0;
>> +
>> + __hellcreek_select_counter(hellcreek, offset);
>> +
>> + high = hellcreek_read(hellcreek, HR_CRDH);
>> + low = hellcreek_read(hellcreek, HR_CRDL);
>> + value = (high << 16) | low;
>
> Is there some sort of snapshot happening here? Or do you need to read
> high again, to make sure it has not incremented when low was being
> read?
Yes, there is. When the counter is selected via
__hellcreek_select_counter() both registers are locked. That's why
there's no need to read high again. I'll add a comment for clarity.
>
>> +
>> + hellcreek_port->counter_values[i] += value;
>> + data[i] = hellcreek_port->counter_values[i];
>> + }
>> + spin_unlock_irqrestore(&hellcreek->reg_lock, flags);
>> +}
>> +
>> +static int hellcreek_vlan_prepare(struct dsa_switch *ds, int port,
>> + const struct switchdev_obj_port_vlan *vlan)
>> +{
>> + struct hellcreek *hellcreek = ds->priv;
>> +
>> + /* Nothing todo */
>> + dev_info(hellcreek->dev, "VLAN prepare for port %d\n", port);
>
> dev_dbg()
>
>> +
>> + return 0;
>> +}
>> +
>
>> +static void hellcreek_vlan_add(struct dsa_switch *ds, int port,
>> + const struct switchdev_obj_port_vlan *vlan)
>> +{
>> + struct hellcreek *hellcreek = ds->priv;
>> + bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
>> + bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
>> + unsigned long flags;
>> + u16 vid;
>> +
>> + if (port >= NUM_PORTS || vlan->vid_end >= 4096)
>
> Again, if vlan->vid_end >= 4096 is true, there is a core bug which
> needs fixing.
>
>> + return;
>> +
>> + dev_info(hellcreek->dev, "Add VLANs (%d -- %d) on port %d, %s, %s\n",
>> + vlan->vid_begin, vlan->vid_end, port,
>> + untagged ? "untagged" : "tagged",
>> + pvid ? "PVID" : "no PVID");
>
> Please go thought the driver and consider all you dev_info()
> statements. Should they be dev_dbg()?
I'll do.
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: qca8k: introduce SGMII configuration options
From: Dan Carpenter @ 2020-06-19 8:12 UTC (permalink / raw)
To: kbuild, Jonathan McDowell, Andrew Lunn, Vivien Didelot,
Florian Fainelli, David S. Miller, Jakub Kicinski, linux-kernel
Cc: lkp, kbuild-all, netdev
In-Reply-To: <8ddd76e484e1bedd12c87ea0810826b60e004a65.1591380105.git.noodles@earth.li>
[-- Attachment #1: Type: text/plain, Size: 3704 bytes --]
Hi Jonathan,
url: https://github.com/0day-ci/linux/commits/Jonathan-McDowell/net-dsa-qca8k-Add-SGMII-configuration-options/20200606-021254
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-randconfig-m021-20200618 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch warnings:
drivers/net/dsa/qca8k.c:438 qca8k_setup_sgmii() error: uninitialized symbol 'mode'.
# https://github.com/0day-ci/linux/commit/27dd896d27e5048d2c402879fb04f6e23536ea72
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 27dd896d27e5048d2c402879fb04f6e23536ea72
vim +/mode +438 drivers/net/dsa/qca8k.c
27dd896d27e5048 Jonathan McDowell 2020-06-05 421 static int
27dd896d27e5048 Jonathan McDowell 2020-06-05 422 qca8k_setup_sgmii(struct qca8k_priv *priv)
27dd896d27e5048 Jonathan McDowell 2020-06-05 423 {
27dd896d27e5048 Jonathan McDowell 2020-06-05 424 const char *mode;
^^^^
27dd896d27e5048 Jonathan McDowell 2020-06-05 425 u32 val;
27dd896d27e5048 Jonathan McDowell 2020-06-05 426
27dd896d27e5048 Jonathan McDowell 2020-06-05 427 val = qca8k_read(priv, QCA8K_REG_SGMII_CTRL);
27dd896d27e5048 Jonathan McDowell 2020-06-05 428
27dd896d27e5048 Jonathan McDowell 2020-06-05 429 val |= QCA8K_SGMII_EN_PLL | QCA8K_SGMII_EN_RX |
27dd896d27e5048 Jonathan McDowell 2020-06-05 430 QCA8K_SGMII_EN_TX | QCA8K_SGMII_EN_SD;
27dd896d27e5048 Jonathan McDowell 2020-06-05 431
27dd896d27e5048 Jonathan McDowell 2020-06-05 432 if (of_property_read_bool(priv->dev->of_node, "sgmii-delay"))
27dd896d27e5048 Jonathan McDowell 2020-06-05 433 val |= QCA8K_SGMII_CLK125M_DELAY;
27dd896d27e5048 Jonathan McDowell 2020-06-05 434
27dd896d27e5048 Jonathan McDowell 2020-06-05 435 if (of_property_read_string(priv->dev->of_node, "sgmii-mode", &mode)) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This if condition is reversed.
27dd896d27e5048 Jonathan McDowell 2020-06-05 436 val &= ~QCA8K_SGMII_MODE_CTRL_MASK;
27dd896d27e5048 Jonathan McDowell 2020-06-05 437
27dd896d27e5048 Jonathan McDowell 2020-06-05 @438 if (!strcasecmp(mode, "basex")) {
27dd896d27e5048 Jonathan McDowell 2020-06-05 439 val |= QCA8K_SGMII_MODE_CTRL_BASEX;
27dd896d27e5048 Jonathan McDowell 2020-06-05 440 } else if (!strcasecmp(mode, "mac")) {
27dd896d27e5048 Jonathan McDowell 2020-06-05 441 val |= QCA8K_SGMII_MODE_CTRL_MAC;
27dd896d27e5048 Jonathan McDowell 2020-06-05 442 } else if (!strcasecmp(mode, "phy")) {
27dd896d27e5048 Jonathan McDowell 2020-06-05 443 val |= QCA8K_SGMII_MODE_CTRL_PHY;
27dd896d27e5048 Jonathan McDowell 2020-06-05 444 } else {
27dd896d27e5048 Jonathan McDowell 2020-06-05 445 pr_err("Unrecognised SGMII mode %s\n", mode);
27dd896d27e5048 Jonathan McDowell 2020-06-05 446 return -EINVAL;
27dd896d27e5048 Jonathan McDowell 2020-06-05 447 }
27dd896d27e5048 Jonathan McDowell 2020-06-05 448 }
27dd896d27e5048 Jonathan McDowell 2020-06-05 449
27dd896d27e5048 Jonathan McDowell 2020-06-05 450 qca8k_write(priv, QCA8K_REG_SGMII_CTRL, val);
27dd896d27e5048 Jonathan McDowell 2020-06-05 451
27dd896d27e5048 Jonathan McDowell 2020-06-05 452 return 0;
27dd896d27e5048 Jonathan McDowell 2020-06-05 453 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35248 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 3/9] net: dsa: hellcreek: Add PTP clock support
From: Kurt Kanzenbach @ 2020-06-19 8:13 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller,
netdev, Rob Herring, devicetree, Sebastian Andrzej Siewior,
Richard Cochran, Kamil Alkhouri, ilias.apalodimas
In-Reply-To: <20200618084614.7ef6b35c@kicinski-fedora-PC1C0HJN>
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
Hi Jakub,
On Thu Jun 18 2020, Jakub Kicinski wrote:
> On Thu, 18 Jun 2020 08:40:23 +0200 Kurt Kanzenbach wrote:
>> From: Kamil Alkhouri <kamil.alkhouri@hs-offenburg.de>
>>
>> The switch has internal PTP hardware clocks. Add support for it. There are three
>> clocks:
>>
>> * Synchronized
>> * Syntonized
>> * Free running
>>
>> Currently the synchronized clock is exported to user space which is a good
>> default for the beginning. The free running clock might be exported later
>> e.g. for implementing 802.1AS-2011/2020 Time Aware Bridges (TAB). The switch
>> also supports cross time stamping for that purpose.
>>
>> The implementation adds support setting/getting the time as well as offset and
>> frequency adjustments. However, the clock only holds a partial timeofday
>> timestamp. This is why we track the seconds completely in software (see overflow
>> work and last_ts).
>>
>> Furthermore, add the PTP multicast addresses into the FDB to forward that
>> packages only to the CPU port where they are processed by a PTP program.
>>
>> Signed-off-by: Kamil Alkhouri <kamil.alkhouri@hs-offenburg.de>
>> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
>
> Please make sure each patch in the series builds cleanly with the W=1
> C=1 flags. Here we have:
>
> ../drivers/net/dsa/hirschmann/hellcreek_ptp.c: In function ‘__hellcreek_ptp_clock_read’:
> ../drivers/net/dsa/hirschmann/hellcreek_ptp.c:30:28: warning: variable ‘sech’ set but not used [-Wunused-but-set-variable]
> 30 | u16 nsl, nsh, secl, secm, sech;
> | ^~~~
> ../drivers/net/dsa/hirschmann/hellcreek_ptp.c:30:22: warning: variable ‘secm’ set but not used [-Wunused-but-set-variable]
> 30 | u16 nsl, nsh, secl, secm, sech;
> | ^~~~
> ../drivers/net/dsa/hirschmann/hellcreek_ptp.c:30:16: warning: variable ‘secl’ set but not used [-Wunused-but-set-variable]
> 30 | u16 nsl, nsh, secl, secm, sech;
> | ^~~~
>
> Next patch adds a few more.
Sorry, I did test with C=1 only. I'll fix it.
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* RE: [PATCH v5 3/7] fs: Add fd_install_received() wrapper for __fd_install_received()
From: David Laight @ 2020-06-19 8:20 UTC (permalink / raw)
To: 'Kees Cook', Sargun Dhillon
Cc: linux-kernel@vger.kernel.org, Christian Brauner, Tycho Andersen,
Christoph Hellwig, David S. Miller, Jakub Kicinski,
Alexander Viro, Aleksa Sarai, Matt Denton, Jann Horn,
Chris Palmer, Robert Sesek, Giuseppe Scrivano, Greg Kroah-Hartman,
Andy Lutomirski, Will Drewry, Shuah Khan, netdev@vger.kernel.org,
containers@lists.linux-foundation.org, linux-api@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org
In-Reply-To: <202006181305.01F1B08@keescook>
From: Kees Cook
> Sent: 18 June 2020 21:13
> On Thu, Jun 18, 2020 at 05:49:19AM +0000, Sargun Dhillon wrote:
> > On Wed, Jun 17, 2020 at 03:03:23PM -0700, Kees Cook wrote:
> > > [...]
> > > static inline int fd_install_received_user(struct file *file, int __user *ufd,
> > > unsigned int o_flags)
> > > {
> > > + if (ufd == NULL)
> > > + return -EFAULT;
> > Isn't this *technically* a behvaiour change? Nonetheless, I think this is a much better
> > approach than forcing everyone to do null checking, and avoids at least one error case
> > where the kernel installs FDs for SCM_RIGHTS, and they're not actualy usable.
>
> So, the only behavior change I see is that the order of sanity checks is
> changed.
>
> The loop in scm_detach_fds() is:
>
>
> for (i = 0; i < fdmax; i++) {
> err = __scm_install_fd(scm->fp->fp[i], cmsg_data + i, o_flags);
> if (err < 0)
> break;
> }
>
> Before, __scm_install_fd() does:
>
> error = security_file_receive(file);
> if (error)
> return error;
>
> new_fd = get_unused_fd_flags(o_flags);
> if (new_fd < 0)
> return new_fd;
>
> error = put_user(new_fd, ufd);
> if (error) {
> put_unused_fd(new_fd);
> return error;
> }
> ...
>
> After, fd_install_received_user() and __fd_install_received() does:
>
> if (ufd == NULL)
> return -EFAULT;
> ...
> error = security_file_receive(file);
> if (error)
> return error;
> ...
> new_fd = get_unused_fd_flags(o_flags);
> if (new_fd < 0)
> return new_fd;
> ...
> error = put_user(new_fd, ufd);
> if (error) {
> put_unused_fd(new_fd);
> return error;
> }
>
> i.e. if a caller attempts a receive that is rejected by LSM *and*
> includes a NULL userpointer destination, they will get an EFAULT now
> instead of an EPERM.
The 'user' pointer the fd is written to is in the middle of
the 'cmsg' buffer.
So to hit 'ufd == NULL' the program would have to pass a small
negative integer!
The error paths are strange if there are multiple fd in the message.
A quick look at the old code seems to imply that if the user doesn't
supply a big enough buffer then the extra 'file *' just get closed.
OTOH if there is an error processing one of the files the request
fails with the earlier file allocated fd numbers.
In addition most of the userspace buffer is written after the
loop - any errors there return -EFAULT (SIGSEGV) without
even trying to tidy up the allocated fd.
ISTM that the put_user(new_fd, ufd) could be done in __scm_install_fd()
after __fd_install_received() returns.
scm_detach_fds() could do the put_user(SOL_SOCKET,...) before actually
processing the first file - so that the state can be left unchanged
when a naff buffer is passed.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [RFC PATCH 3/9] net: dsa: hellcreek: Add PTP clock support
From: Kurt Kanzenbach @ 2020-06-19 8:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, Jakub Kicinski,
netdev, Rob Herring, devicetree, Sebastian Andrzej Siewior,
Richard Cochran, Kamil Alkhouri, ilias.apalodimas
In-Reply-To: <20200618172304.GG240559@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]
Hi Andrew,
On Thu Jun 18 2020, Andrew Lunn wrote:
>> +static u64 __hellcreek_ptp_clock_read(struct hellcreek *hellcreek)
>> +{
>> + u16 nsl, nsh, secl, secm, sech;
>> +
>> + /* Take a snapshot */
>> + hellcreek_ptp_write(hellcreek, PR_COMMAND_C_SS, PR_COMMAND_C);
>> +
>> + /* The time of the day is saved as 96 bits. However, due to hardware
>> + * limitations the seconds are not or only partly kept in the PTP
>> + * core. That's why only the nanoseconds are used and the seconds are
>> + * tracked in software. Anyway due to internal locking all five
>> + * registers should be read.
>> + */
>> + sech = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> + secm = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> + secl = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> + nsh = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> + nsl = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> +
>> + return (u64)nsl | ((u64)nsh << 16);
>
> Hi Kurt
>
> What are the hardware limitations? There seems to be 48 bits for
> seconds? That allows for 8925104 years?
In theory, yes. Due to hardware hardware considerations only a few or
none of these bits are used for the seconds. The rest is zero. Meaning
that the wraparound is not 8925104 years, but at e.g. 8 seconds when
using 3 bits for the seconds.
I've discussed this the Hirschmann people and they suggested to use the
nanoseconds only. That's what I did here.
>
>> +static u64 __hellcreek_ptp_gettime(struct hellcreek *hellcreek)
>> +{
>> + u64 ns;
>> +
>> + ns = __hellcreek_ptp_clock_read(hellcreek);
>> + if (ns < hellcreek->last_ts)
>> + hellcreek->seconds++;
>> + hellcreek->last_ts = ns;
>> + ns += hellcreek->seconds * NSEC_PER_SEC;
>
> So the assumption is, this gets called at least once per second. And
> if that does not happen, there is no recovery. The second is lost.
Yes, exactly. If a single overflow is missed, then the time is wrong.
>
> I'm just wondering if there is something more robust using what the
> hardware does provide, even if the hardware is not perfect.
I don't think there's a more robust way to do this. The overflow period
is a second which should be enough time to catch the overflow even if
the system is loaded. We did long running tests for days and the
mechanism worked fine. We could also consider to move the delayed work
to a dedicated thread which could be run with real time (SCHED_FIFO)
priority. But, I didn't see the need for it.
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 6/9] net: dsa: hellcreek: Add debugging mechanisms
From: Kurt Kanzenbach @ 2020-06-19 8:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, Jakub Kicinski,
netdev, Rob Herring, devicetree, Sebastian Andrzej Siewior,
Richard Cochran, Kamil Alkhouri, ilias.apalodimas
In-Reply-To: <20200618173458.GH240559@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
Hi Andrew,
On Thu Jun 18 2020, Andrew Lunn wrote:
> On Thu, Jun 18, 2020 at 08:40:26AM +0200, Kurt Kanzenbach wrote:
>> The switch has registers which are useful for debugging issues:
>
> debugfs is not particularly likes. Please try to find other means
> where possible. Memory usage fits nicely into devlink. See mv88e6xxx
> which exports the ATU fill for example.
OK, I'll have a look at devlink and the mv88e6xxx driver to see if that
could be utilized.
> Are trace registers counters?
No. The trace registers provide bits for error conditions and if packets
have been dropped e.g. because of full queues or FCS errors, and so on.
>
>> +static int hellcreek_debugfs_init(struct hellcreek *hellcreek)
>> +{
>> + struct dentry *file;
>> +
>> + hellcreek->debug_dir = debugfs_create_dir(dev_name(hellcreek->dev),
>> + NULL);
>> + if (!hellcreek->debug_dir)
>> + return -ENOMEM;
>
> Just a general comment. You should not check the return value from any
> debugfs call, since it is totally optional. It will also do the right
> thing if the previous call has failed. There are numerous emails from
> GregKH about this.
OK.
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 7/9] net: dsa: hellcreek: Add PTP status LEDs
From: Kurt Kanzenbach @ 2020-06-19 8:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, Jakub Kicinski,
netdev, Rob Herring, devicetree, Sebastian Andrzej Siewior,
Richard Cochran, Kamil Alkhouri, ilias.apalodimas
In-Reply-To: <20200618174650.GI240559@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
Hi Andrew,
On Thu Jun 18 2020, Andrew Lunn wrote:
> On Thu, Jun 18, 2020 at 08:40:27AM +0200, Kurt Kanzenbach wrote:
>> The switch has two controllable I/Os which are usually connected to LEDs. This
>> is useful to immediately visually see the PTP status.
>>
>> These provide two signals:
>>
>> * is_gm
>>
>> This LED can be activated if the current device is the grand master in that
>> PTP domain.
>>
>> * sync_good
>>
>> This LED can be activated if the current device is in sync with the network
>> time.
>>
>> Expose these via the LED framework to be controlled via user space
>> e.g. linuxptp.
>
> Hi Kurt
>
> Is the hardware driving these signals at all? Or are these just
> suggested names in the documentation? It would not be an issue to have
> user space to configure them to use the heartbeat trigger, etc?
These are more like GPIOs. If a 1 is set into the register then the
hardware drives the signal to high. The names are from the
documentation:
* sync_good: This signal indicates that the switch is in sync
* is_gm: This signal indicates that the switch is the grand master
However, these signals have to be set by user space. Most likely these
signals are connected to LEDs.
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 9/9] dt-bindings: net: dsa: Add documentation for Hellcreek switches
From: Kurt Kanzenbach @ 2020-06-19 8:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, Jakub Kicinski,
netdev, Rob Herring, devicetree, Sebastian Andrzej Siewior,
Richard Cochran, Kamil Alkhouri, ilias.apalodimas
In-Reply-To: <20200618134704.GQ249144@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
Hi Andrew,
On Thu Jun 18 2020, Andrew Lunn wrote:
>> +Ethernet switch connected memory mapped to the host, CPU port wired to gmac0:
>> +
>> +soc {
>> + switch0: switch@0xff240000 {
>> + compatible = "hirschmann,hellcreek";
>> + status = "okay";
>> + reg = <0xff240000 0x1000 /* TSN base */
>> + 0xff250000 0x1000>; /* PTP base */
>> + dsa,member = <0 0>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + label = "cpu";
>> + ethernet = <&gmac0>;
>> + };
>> +
>> + port@2 {
>> + reg = <2>;
>> + label = "lan0";
>> + phy-handle = <&phy1>;
>> + };
>> +
>> + port@3 {
>> + reg = <3>;
>> + label = "lan1";
>> + phy-handle = <&phy2>;
>> + };
>> + };
>> + };
>> +};
>> +
>> +&gmac0 {
>> + status = "okay";
>> + phy-mode = "mii";
>> +
>> + fixed-link {
>> + speed = <100>;
>> + full-duplex;
>
> Hi Kurt
>
> The switch is 100/100Mbps right? The MAC is only Fast ethernet. Do you
> need some properties in the port@0 node to tell the switch to only use
> 100Mbps? I would expect it to default to 1G. Not looked at the code
> yet...
No, that is not needed. That is a hardware configuration and AFAIK
cannot be changed at run time.
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 9/9] dt-bindings: net: dsa: Add documentation for Hellcreek switches
From: Kurt Kanzenbach @ 2020-06-19 8:48 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, Vivien Didelot
Cc: David S. Miller, Jakub Kicinski, netdev, Rob Herring, devicetree,
Sebastian Andrzej Siewior, Richard Cochran, Kamil Alkhouri,
ilias.apalodimas
In-Reply-To: <e8085c6a-0b61-60f9-f411-2540dec80926@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]
Hi Florian,
On Thu Jun 18 2020, Florian Fainelli wrote:
> On 6/17/2020 11:40 PM, Kurt Kanzenbach wrote:
>> Add basic documentation and example.
>>
>> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
>> ---
>> .../devicetree/bindings/net/dsa/hellcreek.txt | 72 +++++++++++++++++++
>> 1 file changed, 72 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/dsa/hellcreek.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/dsa/hellcreek.txt b/Documentation/devicetree/bindings/net/dsa/hellcreek.txt
>> new file mode 100644
>> index 000000000000..9ea6494dc554
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/dsa/hellcreek.txt
>
> This should be a YAML binding and we should also convert the DSA binding
> to YAML one day.
OK.
>
>> @@ -0,0 +1,72 @@
>> +Hirschmann hellcreek switch driver
>> +==================================
>> +
>> +Required properties:
>> +
>> +- compatible:
>> + Must be one of:
>> + - "hirschmann,hellcreek"
>> +
>> +See Documentation/devicetree/bindings/net/dsa/dsa.txt for the list of standard
>> +DSA required and optional properties.
>> +
>> +Example
>> +-------
>> +
>> +Ethernet switch connected memory mapped to the host, CPU port wired to gmac0:
>> +
>> +soc {
>> + switch0: switch@0xff240000 {
>
> Please remove the leading 0x from the unit address.
Sure.
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH 2/3] net: phy: marvell: Add Marvell 88E1340S support
From: Maxim Kochetkov @ 2020-06-19 8:49 UTC (permalink / raw)
To: netdev
Cc: Maxim Kochetkov, Andrew Lunn, Florian Fainelli, Heiner Kallweit,
Russell King, David S. Miller, Jakub Kicinski
In-Reply-To: <20200619084904.95432-1-fido_max@inbox.ru>
Add support for this new phy ID.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
---
drivers/net/phy/marvell.c | 23 +++++++++++++++++++++++
include/linux/marvell_phy.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index db5257f3b362..de6bd07a5983 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2459,6 +2459,28 @@ static struct phy_driver marvell_drivers[] = {
.get_tunable = m88e1540_get_tunable,
.set_tunable = m88e1540_set_tunable,
},
+ {
+ .phy_id = MARVELL_PHY_ID_88E1340S,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
+ .name = "Marvell 88E1340S",
+ .probe = m88e1510_probe,
+ /* PHY_GBIT_FEATURES */
+ .config_init = marvell_config_init,
+ .config_aneg = m88e1510_config_aneg,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .did_interrupt = m88e1121_did_interrupt,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
+ .read_page = marvell_read_page,
+ .write_page = marvell_write_page,
+ .get_sset_count = marvell_get_sset_count,
+ .get_strings = marvell_get_strings,
+ .get_stats = marvell_get_stats,
+ .get_tunable = m88e1540_get_tunable,
+ .set_tunable = m88e1540_set_tunable,
+ },
};
module_phy_driver(marvell_drivers);
@@ -2479,6 +2501,7 @@ static struct mdio_device_id __maybe_unused marvell_tbl[] = {
{ MARVELL_PHY_ID_88E1545, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E3016, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E6390, MARVELL_PHY_ID_MASK },
+ { MARVELL_PHY_ID_88E1340S, MARVELL_PHY_ID_MASK },
{ }
};
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index af6b11d4d673..c4390e9cbf15 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -15,6 +15,7 @@
#define MARVELL_PHY_ID_88E1149R 0x01410e50
#define MARVELL_PHY_ID_88E1240 0x01410e30
#define MARVELL_PHY_ID_88E1318S 0x01410e90
+#define MARVELL_PHY_ID_88E1340S 0x01410dc0
#define MARVELL_PHY_ID_88E1116R 0x01410e40
#define MARVELL_PHY_ID_88E1510 0x01410dd0
#define MARVELL_PHY_ID_88E1540 0x01410eb0
--
2.25.1
^ permalink raw reply related
* [PATCH 0/3] Add Marvell 88E1340S, 88E1548P support
From: Maxim Kochetkov @ 2020-06-19 8:49 UTC (permalink / raw)
To: netdev
Cc: Maxim Kochetkov, Andrew Lunn, Florian Fainelli, Heiner Kallweit,
Russell King, David S. Miller, Jakub Kicinski
This patch series add new PHY id support.
Russell King asked to use single style for referencing functions.
Maxim Kochetkov (3):
net: phy: marvell: use a single style for referencing functions
net: phy: marvell: Add Marvell 88E1340S support
net: phy: marvell: Add Marvell 88E1548P support
drivers/net/phy/marvell.c | 269 +++++++++++++++++++++---------------
include/linux/marvell_phy.h | 2 +
2 files changed, 160 insertions(+), 111 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 1/3] net: phy: marvell: use a single style for referencing functions
From: Maxim Kochetkov @ 2020-06-19 8:49 UTC (permalink / raw)
To: netdev
Cc: Maxim Kochetkov, Andrew Lunn, Florian Fainelli, Heiner Kallweit,
Russell King, David S. Miller, Jakub Kicinski
In-Reply-To: <20200619084904.95432-1-fido_max@inbox.ru>
The kernel in general does not use &func referencing format.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
---
drivers/net/phy/marvell.c | 222 +++++++++++++++++++-------------------
1 file changed, 111 insertions(+), 111 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 7fc8e10c5f33..db5257f3b362 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2157,12 +2157,12 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1101",
/* PHY_GBIT_FEATURES */
.probe = marvell_probe,
- .config_init = &marvell_config_init,
- .config_aneg = &m88e1101_config_aneg,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = marvell_config_init,
+ .config_aneg = m88e1101_config_aneg,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2175,12 +2175,12 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1112",
/* PHY_GBIT_FEATURES */
.probe = marvell_probe,
- .config_init = &m88e1111_config_init,
- .config_aneg = &marvell_config_aneg,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = m88e1111_config_init,
+ .config_aneg = marvell_config_aneg,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2195,13 +2195,13 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1111",
/* PHY_GBIT_FEATURES */
.probe = marvell_probe,
- .config_init = &m88e1111_config_init,
- .config_aneg = &marvell_config_aneg,
- .read_status = &marvell_read_status,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = m88e1111_config_init,
+ .config_aneg = marvell_config_aneg,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2216,12 +2216,12 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1118",
/* PHY_GBIT_FEATURES */
.probe = marvell_probe,
- .config_init = &m88e1118_config_init,
- .config_aneg = &m88e1118_config_aneg,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = m88e1118_config_init,
+ .config_aneg = m88e1118_config_aneg,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2233,15 +2233,15 @@ static struct phy_driver marvell_drivers[] = {
.phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1121R",
/* PHY_GBIT_FEATURES */
- .probe = &m88e1121_probe,
- .config_init = &marvell_config_init,
- .config_aneg = &m88e1121_config_aneg,
- .read_status = &marvell_read_status,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .did_interrupt = &m88e1121_did_interrupt,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .probe = m88e1121_probe,
+ .config_init = marvell_config_init,
+ .config_aneg = m88e1121_config_aneg,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .did_interrupt = m88e1121_did_interrupt,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2256,16 +2256,16 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1318S",
/* PHY_GBIT_FEATURES */
.probe = marvell_probe,
- .config_init = &m88e1318_config_init,
- .config_aneg = &m88e1318_config_aneg,
- .read_status = &marvell_read_status,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .did_interrupt = &m88e1121_did_interrupt,
- .get_wol = &m88e1318_get_wol,
- .set_wol = &m88e1318_set_wol,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = m88e1318_config_init,
+ .config_aneg = m88e1318_config_aneg,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .did_interrupt = m88e1121_did_interrupt,
+ .get_wol = m88e1318_get_wol,
+ .set_wol = m88e1318_set_wol,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2278,13 +2278,13 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1145",
/* PHY_GBIT_FEATURES */
.probe = marvell_probe,
- .config_init = &m88e1145_config_init,
- .config_aneg = &m88e1101_config_aneg,
- .read_status = &genphy_read_status,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = m88e1145_config_init,
+ .config_aneg = m88e1101_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2299,12 +2299,12 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1149R",
/* PHY_GBIT_FEATURES */
.probe = marvell_probe,
- .config_init = &m88e1149_config_init,
- .config_aneg = &m88e1118_config_aneg,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = m88e1149_config_init,
+ .config_aneg = m88e1118_config_aneg,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2317,12 +2317,12 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1240",
/* PHY_GBIT_FEATURES */
.probe = marvell_probe,
- .config_init = &m88e1111_config_init,
- .config_aneg = &marvell_config_aneg,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = m88e1111_config_init,
+ .config_aneg = marvell_config_aneg,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2335,11 +2335,11 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1116R",
/* PHY_GBIT_FEATURES */
.probe = marvell_probe,
- .config_init = &m88e1116r_config_init,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = m88e1116r_config_init,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2353,17 +2353,17 @@ static struct phy_driver marvell_drivers[] = {
.phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1510",
.features = PHY_GBIT_FIBRE_FEATURES,
- .probe = &m88e1510_probe,
- .config_init = &m88e1510_config_init,
- .config_aneg = &m88e1510_config_aneg,
- .read_status = &marvell_read_status,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .did_interrupt = &m88e1121_did_interrupt,
- .get_wol = &m88e1318_get_wol,
- .set_wol = &m88e1318_set_wol,
- .resume = &marvell_resume,
- .suspend = &marvell_suspend,
+ .probe = m88e1510_probe,
+ .config_init = m88e1510_config_init,
+ .config_aneg = m88e1510_config_aneg,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .did_interrupt = m88e1121_did_interrupt,
+ .get_wol = m88e1318_get_wol,
+ .set_wol = m88e1318_set_wol,
+ .resume = marvell_resume,
+ .suspend = marvell_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2379,14 +2379,14 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1540",
/* PHY_GBIT_FEATURES */
.probe = m88e1510_probe,
- .config_init = &marvell_config_init,
- .config_aneg = &m88e1510_config_aneg,
- .read_status = &marvell_read_status,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .did_interrupt = &m88e1121_did_interrupt,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = marvell_config_init,
+ .config_aneg = m88e1510_config_aneg,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .did_interrupt = m88e1121_did_interrupt,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2401,14 +2401,14 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1545",
.probe = m88e1510_probe,
/* PHY_GBIT_FEATURES */
- .config_init = &marvell_config_init,
- .config_aneg = &m88e1510_config_aneg,
- .read_status = &marvell_read_status,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .did_interrupt = &m88e1121_did_interrupt,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = marvell_config_init,
+ .config_aneg = m88e1510_config_aneg,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .did_interrupt = m88e1121_did_interrupt,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2423,14 +2423,14 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E3016",
/* PHY_BASIC_FEATURES */
.probe = marvell_probe,
- .config_init = &m88e3016_config_init,
- .aneg_done = &marvell_aneg_done,
- .read_status = &marvell_read_status,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .did_interrupt = &m88e1121_did_interrupt,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = m88e3016_config_init,
+ .aneg_done = marvell_aneg_done,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .did_interrupt = m88e1121_did_interrupt,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
@@ -2443,14 +2443,14 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E6390",
/* PHY_GBIT_FEATURES */
.probe = m88e6390_probe,
- .config_init = &marvell_config_init,
- .config_aneg = &m88e6390_config_aneg,
- .read_status = &marvell_read_status,
- .ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
- .did_interrupt = &m88e1121_did_interrupt,
- .resume = &genphy_resume,
- .suspend = &genphy_suspend,
+ .config_init = marvell_config_init,
+ .config_aneg = m88e6390_config_aneg,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .did_interrupt = m88e1121_did_interrupt,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
.read_page = marvell_read_page,
.write_page = marvell_write_page,
.get_sset_count = marvell_get_sset_count,
--
2.25.1
^ permalink raw reply related
* [PATCH 3/3] net: phy: marvell: Add Marvell 88E1548P support
From: Maxim Kochetkov @ 2020-06-19 8:49 UTC (permalink / raw)
To: netdev
Cc: Maxim Kochetkov, Andrew Lunn, Florian Fainelli, Heiner Kallweit,
Russell King, David S. Miller, Jakub Kicinski
In-Reply-To: <20200619084904.95432-1-fido_max@inbox.ru>
Add support for this new phy ID.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
---
drivers/net/phy/marvell.c | 24 ++++++++++++++++++++++++
include/linux/marvell_phy.h | 1 +
2 files changed, 25 insertions(+)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index de6bd07a5983..38e3ed448c64 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2481,6 +2481,29 @@ static struct phy_driver marvell_drivers[] = {
.get_tunable = m88e1540_get_tunable,
.set_tunable = m88e1540_set_tunable,
},
+ {
+ .phy_id = MARVELL_PHY_ID_88E1548P,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
+ .name = "Marvell 88E1548P",
+ .probe = m88e1510_probe,
+ .features = PHY_GBIT_FIBRE_FEATURES,
+ .config_init = marvell_config_init,
+ .config_aneg = m88e1510_config_aneg,
+ .read_status = marvell_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+ .config_intr = marvell_config_intr,
+ .did_interrupt = m88e1121_did_interrupt,
+ .resume = genphy_resume,
+ .suspend = genphy_suspend,
+ .read_page = marvell_read_page,
+ .write_page = marvell_write_page,
+ .get_sset_count = marvell_get_sset_count,
+ .get_strings = marvell_get_strings,
+ .get_stats = marvell_get_stats,
+ .get_tunable = m88e1540_get_tunable,
+ .set_tunable = m88e1540_set_tunable,
+ },
+
};
module_phy_driver(marvell_drivers);
@@ -2502,6 +2525,7 @@ static struct mdio_device_id __maybe_unused marvell_tbl[] = {
{ MARVELL_PHY_ID_88E3016, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E6390, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E1340S, MARVELL_PHY_ID_MASK },
+ { MARVELL_PHY_ID_88E1548P, MARVELL_PHY_ID_MASK },
{ }
};
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index c4390e9cbf15..ff7b7607c8cf 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -20,6 +20,7 @@
#define MARVELL_PHY_ID_88E1510 0x01410dd0
#define MARVELL_PHY_ID_88E1540 0x01410eb0
#define MARVELL_PHY_ID_88E1545 0x01410ea0
+#define MARVELL_PHY_ID_88E1548P 0x01410ec0
#define MARVELL_PHY_ID_88E3016 0x01410e60
#define MARVELL_PHY_ID_88X3310 0x002b09a0
#define MARVELL_PHY_ID_88E2110 0x002b09b0
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] bpf: Allow small structs to be type of function argument
From: Jiri Olsa @ 2020-06-19 8:50 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: John Fastabend, Jiri Olsa, Alexei Starovoitov, Daniel Borkmann,
netdev, bpf, Yonghong Song, Martin KaFai Lau, Jakub Kicinski,
David Miller, Jesper Dangaard Brouer, Andrii Nakryiko, KP Singh,
Masanori Misono
In-Reply-To: <20200618220511.jrwes44dfh7v52tt@ast-mbp.dhcp.thefacebook.com>
On Thu, Jun 18, 2020 at 03:05:11PM -0700, Alexei Starovoitov wrote:
> On Thu, Jun 18, 2020 at 01:48:06PM +0200, Jiri Olsa wrote:
> > On Wed, Jun 17, 2020 at 04:20:54PM -0700, John Fastabend wrote:
> > > Jiri Olsa wrote:
> > > > This way we can have trampoline on function
> > > > that has arguments with types like:
> > > >
> > > > kuid_t uid
> > > > kgid_t gid
> > > >
> > > > which unwind into small structs like:
> > > >
> > > > typedef struct {
> > > > uid_t val;
> > > > } kuid_t;
> > > >
> > > > typedef struct {
> > > > gid_t val;
> > > > } kgid_t;
> > > >
> > > > And we can use them in bpftrace like:
> > > > (assuming d_path changes are in)
>
> the patch doesn't seem to be related to d_path. Unless I'm missing something.
ugh, sry.. I had bpftrace example with dpath call in it,
then I removed it, but did not remove the comment ;-)
>
> Please add a selftest. bpftrace example is nice, but selftest is still mandatory.
ok
>
> > > >
> > > > # bpftrace -e 'lsm:path_chown { printf("uid %d, gid %d\n", args->uid, args->gid) }'
> > > > Attaching 1 probe...
> > > > uid 0, gid 0
> > > > uid 1000, gid 1000
> > > > ...
> > > >
> > > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > > > ---
> > > > kernel/bpf/btf.c | 12 +++++++++++-
> > > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> > > > index 58c9af1d4808..f8fee5833684 100644
> > > > --- a/kernel/bpf/btf.c
> > > > +++ b/kernel/bpf/btf.c
> > > > @@ -362,6 +362,14 @@ static bool btf_type_is_struct(const struct btf_type *t)
> > > > return kind == BTF_KIND_STRUCT || kind == BTF_KIND_UNION;
> > > > }
> > > >
> > > > +/* type is struct and its size is within 8 bytes
> > > > + * and it can be value of function argument
> > > > + */
> > > > +static bool btf_type_is_struct_arg(const struct btf_type *t)
> > > > +{
> > > > + return btf_type_is_struct(t) && (t->size <= sizeof(u64));
>
> extra () are unnecessary.
>
> the function needs different name. May btf_type_is_struct_by_value() ?
ok
>
> > >
> > > Can you comment on why sizeof(u64) here? The int types can be larger
> > > than 64 for example and don't have a similar check, maybe the should
> > > as well?
> > >
> > > Here is an example from some made up program I ran through clang and
> > > bpftool.
> > >
> > > [2] INT '__int128' size=16 bits_offset=0 nr_bits=128 encoding=SIGNED
> > >
> > > We also have btf_type_int_is_regular to decide if the int is of some
> > > "regular" size but I don't see it used in these paths.
> >
> > so this small structs are passed as scalars via function arguments,
> > so the size limit is to fit teir value into register size which holds
> > the argument
> >
> > I'm not sure how 128bit numbers are passed to function as argument,
> > but I think we can treat them separately if there's a need
> >
> > jirka
> >
> > >
> > > > +}
> > > > +
> > > > static bool __btf_type_is_struct(const struct btf_type *t)
> > > > {
> > > > return BTF_INFO_KIND(t->info) == BTF_KIND_STRUCT;
> > > > @@ -3768,7 +3776,7 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type,
> > > > /* skip modifiers */
> > > > while (btf_type_is_modifier(t))
> > > > t = btf_type_by_id(btf, t->type);
> > > > - if (btf_type_is_int(t) || btf_type_is_enum(t))
> > > > + if (btf_type_is_int(t) || btf_type_is_enum(t) || btf_type_is_struct_arg(t))
> > > > /* accessing a scalar */
> > > > return true;
>
> It probably needs to be x86 gated?
> I don't think all archs do that for small structs.
right, but if btf_type_is_struct_arg == true in here,
the struct is in the argument value
>
> What kind of code clang generates for bpf prog?
> I don't remember what we told clang to do for struct by value.
> That has to be carefully defined and tested.
will check,
thanks
jirka
^ permalink raw reply
* [PATCH 1/1] net: ethernet: neterion: vxge: fix spelling mistake
From: Flavio Suligoi @ 2020-06-19 9:02 UTC (permalink / raw)
To: Jon Mason, David S . Miller, Jakub Kicinski, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Zheng Wei
Cc: netdev, linux-kernel, bpf, Flavio Suligoi
Fix typo: "trigered" --> "triggered"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
drivers/net/ethernet/neterion/vxge/vxge-config.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-config.h b/drivers/net/ethernet/neterion/vxge/vxge-config.h
index 628fa9b2f741..373165119850 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-config.h
+++ b/drivers/net/ethernet/neterion/vxge/vxge-config.h
@@ -297,7 +297,7 @@ struct vxge_hw_fifo_config {
* @greedy_return: If Set it forces the device to return absolutely all RxD
* that are consumed and still on board when a timer interrupt
* triggers. If Clear, then if the device has already returned
- * RxD before current timer interrupt trigerred and after the
+ * RxD before current timer interrupt triggered and after the
* previous timer interrupt triggered, then the device is not
* forced to returned the rest of the consumed RxD that it has
* on board which account for a byte count less than the one
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox