* [PATCH 0/2] sh_eth: couple of software reset bit cleanups
From: Sergei Shtylyov @ 2016-04-24 20:42 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc
Hello.
Here's a set of 2 patches against DaveM's 'net-next.git' repo. We clean up
the use of the software reset bits...
[1/2] sh_eth: use EDMR_SRST_GETHER in sh_eth_check_reset()
[2/2] sh_eth: rename ARSTR register bit
MBR, Sergei
^ permalink raw reply
* [PATCH 1/2] sh_eth: use EDMR_SRST_GETHER in sh_eth_check_reset()
From: Sergei Shtylyov @ 2016-04-24 20:45 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc
In-Reply-To: <16246598.T4zYgEztZA@wasted.cogentembedded.com>
sh_eth_check_reset() uses a bare number where EDMR_SRST_GETHER would fit,
i.e. the receive/trasmit software reset bits that comprise EDMR_SRST_GETHER
read as 1 while the corresponding reset is in progress and thus, when both
are 0, the reset is complete.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -899,7 +899,7 @@ static int sh_eth_check_reset(struct net
int cnt = 100;
while (cnt > 0) {
- if (!(sh_eth_read(ndev, EDMR) & 0x3))
+ if (!(sh_eth_read(ndev, EDMR) & EDMR_SRST_GETHER))
break;
mdelay(1);
cnt--;
^ permalink raw reply
* [PATCH 2/2] sh_eth: rename ARSTR register bit
From: Sergei Shtylyov @ 2016-04-24 20:46 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc
In-Reply-To: <16246598.T4zYgEztZA@wasted.cogentembedded.com>
The Renesas RZ/A1H manual names the software reset bit in the software reset
register (ARSTR) ARST which makes a bit more sense than the ARSTR_ARSTR name
used now by the driver -- rename the latter to ARSTR_ARST.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 6 +++---
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -482,7 +482,7 @@ static void sh_eth_chip_reset(struct net
struct sh_eth_private *mdp = netdev_priv(ndev);
/* reset device */
- sh_eth_tsu_write(mdp, ARSTR_ARSTR, ARSTR);
+ sh_eth_tsu_write(mdp, ARSTR_ARST, ARSTR);
mdelay(1);
}
@@ -540,7 +540,7 @@ static void sh_eth_chip_reset_r8a7740(st
struct sh_eth_private *mdp = netdev_priv(ndev);
/* reset device */
- sh_eth_tsu_write(mdp, ARSTR_ARSTR, ARSTR);
+ sh_eth_tsu_write(mdp, ARSTR_ARST, ARSTR);
mdelay(1);
sh_eth_select_mii(ndev);
@@ -735,7 +735,7 @@ static void sh_eth_chip_reset_giga(struc
}
/* reset device */
- iowrite32(ARSTR_ARSTR, (void *)(SH_GIGA_ETH_BASE + 0x1800));
+ iowrite32(ARSTR_ARST, (void *)(SH_GIGA_ETH_BASE + 0x1800));
mdelay(1);
/* restore MAHR and MALR */
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -394,7 +394,7 @@ enum RPADIR_BIT {
#define DEFAULT_FDR_INIT 0x00000707
/* ARSTR */
-enum ARSTR_BIT { ARSTR_ARSTR = 0x00000001, };
+enum ARSTR_BIT { ARSTR_ARST = 0x00000001, };
/* TSU_FWEN0 */
enum TSU_FWEN0_BIT {
^ permalink raw reply
* Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408
From: Eric Dumazet @ 2016-04-24 21:00 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Hannes Frederic Sowa, David Miller, netdev, linux-kernel
In-Reply-To: <176911.1461527778@turing-police.cc.vt.edu>
On Sun, 2016-04-24 at 15:56 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 24 Apr 2016 12:46:42 -0700, Eric Dumazet said:
>
> > >>> + return !debug_locks ||
> > >>> + lockdep_is_held(&sk->sk_lock) ||
>
> > Issue here is that once lockdep detected a problem (not necessarily in
> > net/ tree btw), your helper always 'detect' a problem, since lockdep
> > automatically disables itself.
>
> "D'Oh!" -- H. Simpson
>
> I thought this patch looked suspect, but couldn't put my finger on it. The
> reason why I got like 41,000 of them is because I built a kernel that has
> lockdep enabled, but I have an out-of-tree module that doesn't init something,
> so I get this:
>
> [ 48.898156] INFO: trying to register non-static key.
> [ 48.898157] the code is fine but needs lockdep annotation.
> [ 48.898157] turning off the locking correctness validator.
>
> After which point, even with this patch, every time through it's still going to
> explode.
Which patch are you talking about ?
^ permalink raw reply
* Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408
From: Valdis.Kletnieks @ 2016-04-24 21:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Hannes Frederic Sowa, David Miller, netdev, linux-kernel
In-Reply-To: <1461531617.5535.3.camel@edumazet-glaptop3.roam.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
On Sun, 24 Apr 2016 14:00:17 -0700, Eric Dumazet said:
> On Sun, 2016-04-24 at 15:56 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Sun, 24 Apr 2016 12:46:42 -0700, Eric Dumazet said:
> >
> > > >>> + return !debug_locks ||
> > > >>> + lockdep_is_held(&sk->sk_lock) ||
> >
> > > Issue here is that once lockdep detected a problem (not necessarily in
> > > net/ tree btw), your helper always 'detect' a problem, since lockdep
> > > automatically disables itself.
> >
> > "D'Oh!" -- H. Simpson
> >
> > I thought this patch looked suspect, but couldn't put my finger on it. The
> > reason why I got like 41,000 of them is because I built a kernel that has
> > lockdep enabled, but I have an out-of-tree module that doesn't init something,
> > so I get this:
> >
> > [ 48.898156] INFO: trying to register non-static key.
> > [ 48.898157] the code is fine but needs lockdep annotation.
> > [ 48.898157] turning off the locking correctness validator.
> >
> > After which point, even with this patch, every time through it's still going to
> > explode.
>
> Which patch are you talking about ?
The one that adds the !debug_locks check - once my out-of-kernel module
hits something that turns off lockdep, it's *still* going to complain on
pretty much all the same packets it complained about earlier. I thought
it looked suspicious, but you clarified why...
[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]
^ permalink raw reply
* Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408
From: Eric Dumazet @ 2016-04-24 21:25 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Hannes Frederic Sowa, David Miller, netdev, linux-kernel
In-Reply-To: <181815.1461532395@turing-police.cc.vt.edu>
On Sun, 2016-04-24 at 17:13 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 24 Apr 2016 14:00:17 -0700, Eric Dumazet said:
> > On Sun, 2016-04-24 at 15:56 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > On Sun, 24 Apr 2016 12:46:42 -0700, Eric Dumazet said:
> > >
> > > > >>> + return !debug_locks ||
> > > > >>> + lockdep_is_held(&sk->sk_lock) ||
> > >
> > > > Issue here is that once lockdep detected a problem (not necessarily in
> > > > net/ tree btw), your helper always 'detect' a problem, since lockdep
> > > > automatically disables itself.
> > >
> > > "D'Oh!" -- H. Simpson
> > >
> > > I thought this patch looked suspect, but couldn't put my finger on it. The
> > > reason why I got like 41,000 of them is because I built a kernel that has
> > > lockdep enabled, but I have an out-of-tree module that doesn't init something,
> > > so I get this:
> > >
> > > [ 48.898156] INFO: trying to register non-static key.
> > > [ 48.898157] the code is fine but needs lockdep annotation.
> > > [ 48.898157] turning off the locking correctness validator.
> > >
> > > After which point, even with this patch, every time through it's still going to
> > > explode.
> >
> > Which patch are you talking about ?
>
> The one that adds the !debug_locks check - once my out-of-kernel module
> hits something that turns off lockdep, it's *still* going to complain on
> pretty much all the same packets it complained about earlier. I thought
> it looked suspicious, but you clarified why...
It does not make sense to me. If lockdep is disabled, then debug_locks
is 0.
So no complain should happen from networking.
I was about to send following patch, please check it solves the issue. ?
(It certainly did for me, once I forced a lockdep splat loading a buggy
module)
Thanks
From: Eric Dumazet <edumazet@google.com>
Valdis reported tons of stack dumps caused by WARN_ON() in sock_owned_by_user()
This test needs to be relaxed if/when lockdep disables itself.
Note that other lockdep_sock_is_held() callers are all from
rcu_dereference_protected() sections which already are disabled
if/when lockdep has been disabled.
Fixes: fafc4e1ea1a4 ("sock: tigthen lockdep checks for sock_owned_by_user")
Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/sock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 52448baf19d7..f492d01512ed 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1409,7 +1409,7 @@ static inline void unlock_sock_fast(struct sock *sk, bool slow)
static inline bool sock_owned_by_user(const struct sock *sk)
{
#ifdef CONFIG_LOCKDEP
- WARN_ON(!lockdep_sock_is_held(sk));
+ WARN_ON_ONCE(!lockdep_sock_is_held(sk) && !debug_locks);
#endif
return sk->sk_lock.owned;
}
^ permalink raw reply related
* Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408
From: Eric Dumazet @ 2016-04-24 21:28 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Hannes Frederic Sowa, David Miller, netdev, linux-kernel
In-Reply-To: <1461533101.5535.15.camel@edumazet-glaptop3.roam.corp.google.com>
On Sun, 2016-04-24 at 14:25 -0700, Eric Dumazet wrote:
> On Sun, 2016-04-24 at 17:13 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Sun, 24 Apr 2016 14:00:17 -0700, Eric Dumazet said:
> > > On Sun, 2016-04-24 at 15:56 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > > On Sun, 24 Apr 2016 12:46:42 -0700, Eric Dumazet said:
> > > >
> > > > > >>> + return !debug_locks ||
> > > > > >>> + lockdep_is_held(&sk->sk_lock) ||
> > > >
> > > > > Issue here is that once lockdep detected a problem (not necessarily in
> > > > > net/ tree btw), your helper always 'detect' a problem, since lockdep
> > > > > automatically disables itself.
> > > >
> > > > "D'Oh!" -- H. Simpson
> > > >
> > > > I thought this patch looked suspect, but couldn't put my finger on it. The
> > > > reason why I got like 41,000 of them is because I built a kernel that has
> > > > lockdep enabled, but I have an out-of-tree module that doesn't init something,
> > > > so I get this:
> > > >
> > > > [ 48.898156] INFO: trying to register non-static key.
> > > > [ 48.898157] the code is fine but needs lockdep annotation.
> > > > [ 48.898157] turning off the locking correctness validator.
> > > >
> > > > After which point, even with this patch, every time through it's still going to
> > > > explode.
> > >
> > > Which patch are you talking about ?
> >
> > The one that adds the !debug_locks check - once my out-of-kernel module
> > hits something that turns off lockdep, it's *still* going to complain on
> > pretty much all the same packets it complained about earlier. I thought
> > it looked suspicious, but you clarified why...
>
> It does not make sense to me. If lockdep is disabled, then debug_locks
> is 0.
>
> So no complain should happen from networking.
>
> I was about to send following patch, please check it solves the issue. ?
>
> (It certainly did for me, once I forced a lockdep splat loading a buggy
> module)
>
> Thanks
>
> From: Eric Dumazet <edumazet@google.com>
>
> Valdis reported tons of stack dumps caused by WARN_ON() in sock_owned_by_user()
>
> This test needs to be relaxed if/when lockdep disables itself.
>
> Note that other lockdep_sock_is_held() callers are all from
> rcu_dereference_protected() sections which already are disabled
> if/when lockdep has been disabled.
>
> Fixes: fafc4e1ea1a4 ("sock: tigthen lockdep checks for sock_owned_by_user")
> Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> include/net/sock.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 52448baf19d7..f492d01512ed 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1409,7 +1409,7 @@ static inline void unlock_sock_fast(struct sock *sk, bool slow)
> static inline bool sock_owned_by_user(const struct sock *sk)
> {
> #ifdef CONFIG_LOCKDEP
> - WARN_ON(!lockdep_sock_is_held(sk));
> + WARN_ON_ONCE(!lockdep_sock_is_held(sk) && !debug_locks);
Silly me, I tested the opposite test of course :
WARN_ON_ONCE(!lockdep_sock_is_held(sk) && debug_locks);
> #endif
> return sk->sk_lock.owned;
> }
>
^ permalink raw reply
* [PATCH v2 net-next] net: ethernet: enc28j60: add device tree support
From: Michael Heimpold @ 2016-04-24 21:28 UTC (permalink / raw)
To: Jonathan Cameron, Andrew F . Davis, Mark Brown, netdev,
devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala
Cc: Michael Heimpold
In-Reply-To: <31567588.rB9VrggOb6@wuerfel>
The following patch adds the required match table for device tree support
(and while at, fix the indent). It's also possible to specify the
MAC address in the DT blob.
Also add the corresponding binding documentation file.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
---
v2: * took care of Arnd Bergmann's review comments
- allow to specify MAC address via DT
- unconditionally define DT id table
* increased the driver version minor number
* driver author's email address bounces, removed from address list
.../devicetree/bindings/net/microchip-enc28j60.txt | 50 ++++++++++++++++++++++
drivers/net/ethernet/microchip/enc28j60.c | 20 +++++++--
2 files changed, 67 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip-enc28j60.txt
diff --git a/Documentation/devicetree/bindings/net/microchip-enc28j60.txt b/Documentation/devicetree/bindings/net/microchip-enc28j60.txt
new file mode 100644
index 0000000..847a97b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip-enc28j60.txt
@@ -0,0 +1,50 @@
+* Microchip ENC28J60
+
+This is a standalone 10 MBit ethernet controller with SPI interface.
+
+For each device connected to a SPI bus, define a child node within
+the SPI master node.
+
+Required properties:
+- compatible: Should be "microchip,enc28j60"
+- reg: Specify the SPI chip select the ENC28J60 is wired to
+- interrupts: Specify the interrupt and interrupt type (usually falling edge)
+
+Optional properties:
+- interrupt-parent: Specify the pHandle of the source interrupt
+- spi-max-frequency: Maximum frequency of the SPI bus when accessing the ENC28J60.
+ According to the ENC28J80 datasheet, the chip allows a maximum of 20 MHz, however,
+ board designs may need to limit this value.
+- local-mac-address: See ethernet.txt in the same directory.
+
+
+Example (for NXP i.MX28 with pin control stuff for GPIO irq):
+
+ ssp2: ssp@80014000 {
+ compatible = "fsl,imx28-spi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi2_pins_b &spi2_sck_cfg>;
+ status = "okay";
+
+ enc28j60: ethernet@0 {
+ compatible = "microchip,enc28j60";
+ pinctrl-names = "default";
+ pinctrl-0 = <&enc28j60_pins>;
+ reg = <0>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <12000000>;
+ };
+ };
+
+ pinctrl@80018000 {
+ enc28j60_pins: enc28j60_pins@0 {
+ reg = <0>;
+ fsl,pinmux-ids = <
+ MX28_PAD_AUART0_RTS__GPIO_3_3 /* Interrupt */
+ >;
+ fsl,drive-strength = <MXS_DRIVE_4mA>;
+ fsl,voltage = <MXS_VOLTAGE_HIGH>;
+ fsl,pull-up = <MXS_PULL_DISABLE>;
+ };
+ };
diff --git a/drivers/net/ethernet/microchip/enc28j60.c b/drivers/net/ethernet/microchip/enc28j60.c
index b723622..7066954 100644
--- a/drivers/net/ethernet/microchip/enc28j60.c
+++ b/drivers/net/ethernet/microchip/enc28j60.c
@@ -28,11 +28,12 @@
#include <linux/skbuff.h>
#include <linux/delay.h>
#include <linux/spi/spi.h>
+#include <linux/of_net.h>
#include "enc28j60_hw.h"
#define DRV_NAME "enc28j60"
-#define DRV_VERSION "1.01"
+#define DRV_VERSION "1.02"
#define SPI_OPLEN 1
@@ -1548,6 +1549,7 @@ static int enc28j60_probe(struct spi_device *spi)
{
struct net_device *dev;
struct enc28j60_net *priv;
+ const void *macaddr;
int ret = 0;
if (netif_msg_drv(&debug))
@@ -1579,7 +1581,12 @@ static int enc28j60_probe(struct spi_device *spi)
ret = -EIO;
goto error_irq;
}
- eth_hw_addr_random(dev);
+
+ macaddr = of_get_mac_address(spi->dev.of_node);
+ if (macaddr)
+ ether_addr_copy(dev->dev_addr, macaddr);
+ else
+ eth_hw_addr_random(dev);
enc28j60_set_hw_macaddr(dev);
/* Board setup must set the relevant edge trigger type;
@@ -1634,9 +1641,16 @@ static int enc28j60_remove(struct spi_device *spi)
return 0;
}
+static const struct of_device_id enc28j60_dt_ids[] = {
+ { .compatible = "microchip,enc28j60" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, enc28j60_dt_ids);
+
static struct spi_driver enc28j60_driver = {
.driver = {
- .name = DRV_NAME,
+ .name = DRV_NAME,
+ .of_match_table = enc28j60_dt_ids,
},
.probe = enc28j60_probe,
.remove = enc28j60_remove,
--
2.5.0
^ permalink raw reply related
* Re: [PATCH net-next 2/6] atl1c: remove private tx lock
From: Francois Romieu @ 2016-04-24 22:05 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev, linux-kernel, Jay Cliburn, Chris Snook
In-Reply-To: <1461526694-11367-3-git-send-email-fw@strlen.de>
Florian Westphal <fw@strlen.de> :
[...]
> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> index d0084d4..a3200ea 100644
> --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
[...]
> @@ -2217,16 +2215,10 @@ static netdev_tx_t atl1c_xmit_frame(struct sk_buff *skb,
> }
>
> tpd_req = atl1c_cal_tpd_req(skb);
> - if (!spin_trylock_irqsave(&adapter->tx_lock, flags)) {
> - if (netif_msg_pktdata(adapter))
> - dev_info(&adapter->pdev->dev, "tx locked\n");
> - return NETDEV_TX_LOCKED;
> - }
>
> if (atl1c_tpd_avail(adapter, type) < tpd_req) {
> /* no enough descriptor, just stop queue */
> netif_stop_queue(netdev);
> - spin_unlock_irqrestore(&adapter->tx_lock, flags);
> return NETDEV_TX_BUSY;
> }
>
Play it safe and keep the implicit local_irq_{save / restore} call ?
It may not be needed but it will help avoiding any unexpected regression
report pointing at the NETDEV_TX_LOCKED removal change.
--
Ueimor
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Mark Brown @ 2016-04-24 22:59 UTC (permalink / raw)
To: Jeff Kirsher
Cc: David Miller, sfr, netdev, linux-next, linux-kernel,
mark.d.rustad, andrewx.bowers, kernel-build-reports,
linaro-kernel
In-Reply-To: <1461367243.3018.42.camel@intel.com>
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]
On Fri, Apr 22, 2016 at 04:20:43PM -0700, Jeff Kirsher wrote:
> On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote:
> > > Jeff, please have your folks look into this. Probably just a
> > simple
> > > conversion to mdelay().
> > This is still present, it's been breaking ARM allmodconfig builds for
> > about two weeks now.
> Interesting that no one spoke up until just a week ago. I have a fix
> and I ready to push it to David Miller.
Like Stephen said it had been there for a couple of days already at the
time it was reported; I happened to be busy at the time it came up so
wasn't looking at the build reports myself. If you've got a fix please
get it submitted ASAP, having common test configurations broken for any
length of time does get disruptive.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: VRF_DEVICE integration plan
From: David Ahern @ 2016-04-24 23:30 UTC (permalink / raw)
To: Elluru, Krishna Mohan, netdev@vger.kernel.org
In-Reply-To: <AT5PR84MB00652788CA3C3F63146F9C08CA610@AT5PR84MB0065.NAMPRD84.PROD.OUTLOOK.COM>
On 4/23/16 10:07 PM, Elluru, Krishna Mohan wrote:
> HI Netdev team,
>
> Greetings. We have been monitoring the vrf device approach for l3 isolation from cumulus networks and we are currently interested in validating it. We have following questions on them and hoping to get answers from you/concerned team.
>
> 1. As per the linux documentation, there are known limits on if_index lookup, as the incoming if_index is changed to vrf_device index and thus an application receiving this packet will perceive this as a vrf_device packet, than right if_index. I saw you mentioned about a special flag to identify the origin, but didn't see the same in the latest linux 4.4.2 version code. Is there a patch expected for it?
you are referring to IP{6}_PKTINFO? I have patches from our 4.1 kernel
tree that I have rebased to top of tree. I hope to send those out in the
next few weeks.
>
> 2. What are the future additions planned for this approach? Are there any ipv4 and ipv6 known bugs with vrf_device model?
We have about 20 patches in our tree that I have not sent upstream yet.
Those patches fix PKTINFO, allow local traffic (e.g, ping in a VRF to a
local address in a VRF), allow IPv6 multicast and linklocal traffic, and
the cgroup implementation which has been sent as an RFC.
I posted a few bug fix patches a week or two ago. Not sure what the
status is with respect to 4.3 - 4.5 trees.
>
> 3. It has been said in the documentation that, with addition of cgroup functionality for vrf device, with net_admin capabilities, we should be able to add an interface to vrf_device, currently it is not so. Any timelines on these?
I don't understand that question. The current implementation allows
adding interfaces (netdev's) to a VRF. The cgroup allows running a
process in a VRF context such that AF_INET{6} sockets are automatically
bound to the VRF device.
>
> 4. Currently the changes are available and portable from 4.3.x onwards. Is there a plan to port them to previous kernel versions?
no. Anyone wanting to use the vrf patches on other kernel versions will
need to port them.
>
> 5. Is there a possibility of enabling secondary level lookup, to give a leak functionality to parent route table from device local route table? I tested with veth pair, configured one as default gateway, it is possible to forward traffic b/w the interfaces, looking for cleaner method.
Are you referring to inter-vrf routing? See slide 27
http://www.netdevconf.org/1.1/proceedings/slides/ahern-vrf-tutorial.pdf
>
> 6. With "VRF Device" in place, please confirm if there are any plans to add VRF support for applications like
>
> 1. Ping
no need. ping{6} -I <vrf device> ...
> 2. Traceroute
no need. traceroute{6} -i <vrf device> ...
> 3. DNS-Client [glibc]
>
> In case of DNS-Client, most of the name resolution APIs will have to consider the VRF to do the lookup in and the way the domain-name/name-server configuration is stored.
I have looked into it but no patches worth distributing at the moment.
^ permalink raw reply
* Re: [PATCH] sh_eth: get rid of the 2nd parameter to sh_eth_dev_init()
From: Simon Horman @ 2016-04-25 0:30 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <1615196.r6Bb3HFTJZ@wasted.cogentembedded.com>
On Sun, Apr 24, 2016 at 07:11:07PM +0300, Sergei Shtylyov wrote:
> sh_eth_dev_init() is now always called with 'true' as the 2nd argument,
> so that there's no more sense in having 2 parameters to this function...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 1/2] sh_eth: use EDMR_SRST_GETHER in sh_eth_check_reset()
From: Simon Horman @ 2016-04-25 0:31 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <10299839.69pLJTKjhc@wasted.cogentembedded.com>
On Sun, Apr 24, 2016 at 11:45:23PM +0300, Sergei Shtylyov wrote:
> sh_eth_check_reset() uses a bare number where EDMR_SRST_GETHER would fit,
> i.e. the receive/trasmit software reset bits that comprise EDMR_SRST_GETHER
> read as 1 while the corresponding reset is in progress and thus, when both
> are 0, the reset is complete.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 2/2] sh_eth: rename ARSTR register bit
From: Simon Horman @ 2016-04-25 0:37 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <11425579.ULGl4KSfTY@wasted.cogentembedded.com>
On Sun, Apr 24, 2016 at 11:46:15PM +0300, Sergei Shtylyov wrote:
> The Renesas RZ/A1H manual names the software reset bit in the software reset
> register (ARSTR) ARST which makes a bit more sense than the ARSTR_ARSTR name
> used now by the driver -- rename the latter to ARSTR_ARST.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* RE: [PATCH net 1/1] net: fec: update dirty_tx even if no skb
From: Fugang Duan @ 2016-04-25 1:57 UTC (permalink / raw)
To: Troy Kisky, netdev@vger.kernel.org, davem@davemloft.net,
lznuaa@gmail.com
Cc: Fabio Estevam, l.stach@pengutronix.de, andrew@lunn.ch,
tremyfr@gmail.com, gerg@uclinux.org,
linux-arm-kernel@lists.infradead.org, johannes@sipsolutions.net,
stillcompiling@gmail.com, sergei.shtylyov@cogentembedded.com,
arnd@arndb.de, holgerschurig@gmail.com
In-Reply-To: <571A4D36.2000506@boundarydevices.com>
From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Saturday, April 23, 2016 12:12 AM
> To: Fugang Duan <fugang.duan@nxp.com>; netdev@vger.kernel.org;
> davem@davemloft.net; lznuaa@gmail.com
> Cc: Fabio Estevam <fabio.estevam@nxp.com>; l.stach@pengutronix.de;
> andrew@lunn.ch; tremyfr@gmail.com; gerg@uclinux.org; linux-arm-
> kernel@lists.infradead.org; johannes@sipsolutions.net;
> stillcompiling@gmail.com; sergei.shtylyov@cogentembedded.com;
> arnd@arndb.de; holgerschurig@gmail.com
> Subject: Re: [PATCH net 1/1] net: fec: update dirty_tx even if no skb
>
> On 4/21/2016 10:59 PM, Fugang Duan wrote:
> > From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Friday, April
> > 22, 2016 10:01 AM
> >> To: netdev@vger.kernel.org; davem@davemloft.net; Fugang Duan
> >> <fugang.duan@nxp.com>; lznuaa@gmail.com
> >> Cc: Fabio Estevam <fabio.estevam@nxp.com>; l.stach@pengutronix.de;
> >> andrew@lunn.ch; tremyfr@gmail.com; gerg@uclinux.org; linux-arm-
> >> kernel@lists.infradead.org; johannes@sipsolutions.net;
> >> stillcompiling@gmail.com; sergei.shtylyov@cogentembedded.com;
> >> arnd@arndb.de; holgerschurig@gmail.com; Troy Kisky
> >> <troy.kisky@boundarydevices.com>
> >> Subject: [PATCH net 1/1] net: fec: update dirty_tx even if no skb
> >>
> >> If dirty_tx isn't updated, then dma_unmap_single will be called twice.
> >>
> >> This fixes a
> >> [ 58.420980] ------------[ cut here ]------------
> >> [ 58.425667] WARNING: CPU: 0 PID: 377 at /home/schurig/d/mkarm/linux-
> >> 4.5/lib/dma-debug.c:1096 check_unmap+0x9d0/0xab8()
> >> [ 58.436405] fec 2188000.ethernet: DMA-API: device driver tries to free
> DMA
> >> memory it has not allocated [device address=0x0000000000000000]
> >> [size=66 bytes]
> >>
> >> encountered by Holger
> >>
> >> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> >> Tested-by: <holgerschurig@gmail.com>
> >> ---
> >> drivers/net/ethernet/freescale/fec_main.c | 8 +++-----
> >> 1 file changed, 3 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> >> b/drivers/net/ethernet/freescale/fec_main.c
> >> index 08243c2..b71654c 100644
> >> --- a/drivers/net/ethernet/freescale/fec_main.c
> >> +++ b/drivers/net/ethernet/freescale/fec_main.c
> >> @@ -1197,10 +1197,8 @@ fec_enet_tx_queue(struct net_device *ndev,
> u16
> >> queue_id)
> >> fec16_to_cpu(bdp->cbd_datlen),
> >> DMA_TO_DEVICE);
> >> bdp->cbd_bufaddr = cpu_to_fec32(0);
> >> - if (!skb) {
> >> - bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
> >> - continue;
> >> - }
> >> + if (!skb)
> >> + goto skb_done;
> >>
> >> /* Check for errors. */
> >> if (status & (BD_ENET_TX_HB | BD_ENET_TX_LC | @@ -1239,7
> >> +1237,7 @@ fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
> >>
> >> /* Free the sk buffer associated with this last transmit */
> >> dev_kfree_skb_any(skb);
> >> -
> >> +skb_done:
> >> /* Make sure the update to bdp and tx_skbuff are performed
> >> * before dirty_tx
> >> */
> >> --
> >> 2.5.0
> >
> > The patch is fine for me.
> > Can you review below patch that also fix the issue. It can take much
> > effort due to less rmb() and READ_ONCE() operation that is very
> > sensitive for duplex Gbps test for i.MX6SX/i.MX7d SOC. (i.MX6SX can
> > reach at 1.4Gbps, i.MX7D can reach at 1.8Gbps.)
>
>
>
> If "READ_ONCE(bdp->cbd_sc)" is really that expensive, then you should skip the
> 1st read as well and only do it after skb presence is verified. But some numbers
> would really help sell the patch.
> Also, I comment as to why the code is reorganized would be warranted
>
I will do the performance test on i.MX7d to compare the data for the two patches.
Wait my result...
Thanks.
>
> >
> > --- a/drivers/net/ethernet/freescale/fec_main.c
> > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > @@ -1160,12 +1160,13 @@ static void
> > fec_enet_tx_queue(struct net_device *ndev, u16 queue_id) {
> > struct fec_enet_private *fep;
> > - struct bufdesc *bdp;
> > + struct bufdesc *bdp, *bdp_t;
> > unsigned short status;
> > struct sk_buff *skb;
> > struct fec_enet_priv_tx_q *txq;
> > struct netdev_queue *nq;
> > int index = 0;
> > + int i, bdnum;
> > int entries_free;
> >
> > fep = netdev_priv(ndev);
> > @@ -1187,20 +1188,28 @@ fec_enet_tx_queue(struct net_device *ndev,
> u16 queue_id)
> > if (status & BD_ENET_TX_READY)
> > break;
> >
> > - index = fec_enet_get_bd_index(bdp, &txq->bd);
> > -
> > + bdp_t = bdp;
> > + bdnum = 1;
> > + index = fec_enet_get_bd_index(txq->tx_bd_base, bdp_t,
> > + fep);
> > skb = txq->tx_skbuff[index];
> > - txq->tx_skbuff[index] = NULL;
> > - if (!IS_TSO_HEADER(txq, fec32_to_cpu(bdp->cbd_bufaddr)))
> > - dma_unmap_single(&fep->pdev->dev,
> > - fec32_to_cpu(bdp->cbd_bufaddr),
> > - fec16_to_cpu(bdp->cbd_datlen),
> > - DMA_TO_DEVICE);
> > - bdp->cbd_bufaddr = cpu_to_fec32(0);
> > - if (!skb) {
> > - bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
> > - continue;
> > + while (!skb) {
> > + bdp_t = fec_enet_get_nextdesc(bdp_t, &txq->bd);
> > + index = fec_enet_get_bd_index(txq->tx_bd_base, bdp_t, fep);
> > + skb = txq->tx_skbuff[index];
> > + bdnum++;
> > + }
> > + status = fec16_to_cpu(READ_ONCE(bdp->cbd_sc));
> > + if (status & BD_ENET_TX_READY)
> > + break;
> > +
> > + for (i = 0; i < bdnum; i++) {
> > + if (!IS_TSO_HEADER(txq, bdp->cbd_bufaddr))
> > + dma_unmap_single(&fep->pdev->dev, bdp->cbd_bufaddr,
> > + bdp->cbd_datlen, DMA_TO_DEVICE);
> > + bdp->cbd_bufaddr = 0;
> > + if (i < bdnum - 1)
> > + bdp = fec_enet_get_nextdesc(bdp,
> > + &txq->bd);
> > }
> > + txq->tx_skbuff[index] = NULL;
> >
> >
> > Regards,
> > Andy
> >
^ permalink raw reply
* Hi netdev
From: Oliver Carter @ 2016-04-25 3:20 UTC (permalink / raw)
To: netdev
hello netdev
http://fashion-management.talentedge.in/blew.php?largest=yuh140w0gem9pw
Oliver Carter
olivercarter_google@yahoo.co.uk
^ permalink raw reply
* Re: [PATCH net] ipv4/fib: don't warn when primary address is missing if in_dev is dead
From: David Miller @ 2016-04-25 3:26 UTC (permalink / raw)
To: pabeni; +Cc: netdev, kuznet, linux-kernel
In-Reply-To: <d6406682cc84a9de9a52bd31eaa6a372f3251f88.1461269273.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 21 Apr 2016 22:23:31 +0200
> After commit fbd40ea0180a ("ipv4: Don't do expensive useless work
> during inetdev destroy.") when deleting an interface,
> fib_del_ifaddr() can be executed without any primary address
> present on the dead interface.
>
> The above is safe, but triggers some "bug: prim == NULL" warnings.
>
> This commit avoids warning if the in_dev is dead
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] hv_netvsc: Fix the list processing for network change event
From: David Miller @ 2016-04-25 3:28 UTC (permalink / raw)
To: haiyangz; +Cc: netdev, kys, olaf, vkuznets, linux-kernel, driverdev-devel
In-Reply-To: <1461280381-17530-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Thu, 21 Apr 2016 16:13:01 -0700
> RNDIS_STATUS_NETWORK_CHANGE event is handled as two "half events" --
> media disconnect & connect. The second half should be added to the list
> head, not to the tail. So all events are processed in normal order.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied, thanks.
^ permalink raw reply
* RE: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Pramod Kumar @ 2016-04-25 4:09 UTC (permalink / raw)
To: David Miller
Cc: robh+dt, catalin.marinas, will.deacon, yamada.masahiro, wens,
bcm-kernel-feedback-list, pawel.moll, mark.rutland, arnd,
suzuki.poulose, punit.agrawal, devicetree, linux-arm-kernel,
linux-kernel, netdev, Anup Patel
In-Reply-To: <20160424.141806.786009616301278103.davem@davemloft.net>
Hi David,
Thanks for providing input over the patch. Will address the comment as
described below.
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: 24 April 2016 23:48
> To: pramod.kumar@broadcom.com
> Cc: robh+dt@kernel.org; catalin.marinas@arm.com; will.deacon@arm.com;
> yamada.masahiro@socionext.com; wens@csie.org; bcm-kernel-feedback-
> list@broadcom.com; pawel.moll@arm.com; mark.rutland@arm.com;
> arnd@arndb.de; suzuki.poulose@arm.com; punit.agrawal@arm.com;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org; anup.patel@broadcom.com
> Subject: Re: [PATCH 1/6] bus: Add shared MDIO bus framework
>
> From: Pramod Kumar <pramod.kumar@broadcom.com>
> Date: Thu, 21 Apr 2016 14:48:38 +0530
>
> > +struct shared_mdio_master *shared_mdio_alloc_master(struct device
> *parent,
> > + struct device_node
*node)
> > +{
> > + int ret = 0;
> > + struct shared_mdio_master *master;
>
> Always order local variable declarations in reverse christmas tree
(longest to
> shortest line) order.
>
Sure. Next patch will address this.
> > +static int shared_mdio_driver_probe(struct device *dev) {
> > + int rc;
> > + struct shared_mdio_master *master = to_shared_mdio_master(dev);
> > + struct shared_mdio_driver *drv =
to_shared_mdio_driver(dev->driver);
>
> Likewise.
Sure.
> Please audit your entire submission for this issue.
Sure. I'll audit the entire patch set for above issue.
Regards,
Pramod
^ permalink raw reply
* [PATCH v2 net-next] net: ipv6: Use passed in table for nexthop lookups
From: David Ahern @ 2016-04-25 4:26 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
Similar to 3bfd847203c6 ("net: Use passed in table for nexthop lookups")
for IPv4, if the route spec contains a table id use that to lookup the
next hop first and fall back to a full lookup if it fails (per the fix
4c9bcd117918b ("net: Fix nexthop lookups")).
Example:
root@kenny:~# ip -6 ro ls table red
local 2100:1::1 dev lo proto none metric 0 pref medium
2100:1::/120 dev eth1 proto kernel metric 256 pref medium
local 2100:2::1 dev lo proto none metric 0 pref medium
2100:2::/120 dev eth2 proto kernel metric 256 pref medium
local fe80::e0:f9ff:fe09:3cac dev lo proto none metric 0 pref medium
local fe80::e0:f9ff:fe1c:b974 dev lo proto none metric 0 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth2 proto kernel metric 256 pref medium
ff00::/8 dev red metric 256 pref medium
ff00::/8 dev eth1 metric 256 pref medium
ff00::/8 dev eth2 metric 256 pref medium
unreachable default dev lo metric 240 error -113 pref medium
root@kenny:~# ip -6 ro add table red 2100:3::/64 via 2100:1::64
RTNETLINK answers: No route to host
Route add fails even though 2100:1::64 is a reachable next hop:
root@kenny:~# ping6 -I red 2100:1::64
ping6: Warning: source address might be selected on device other than red.
PING 2100:1::64(2100:1::64) from 2100:1::1 red: 56 data bytes
64 bytes from 2100:1::64: icmp_seq=1 ttl=64 time=1.33 ms
With this patch:
root@kenny:~# ip -6 ro add table red 2100:3::/64 via 2100:1::64
root@kenny:~# ip -6 ro ls table red
local 2100:1::1 dev lo proto none metric 0 pref medium
2100:1::/120 dev eth1 proto kernel metric 256 pref medium
local 2100:2::1 dev lo proto none metric 0 pref medium
2100:2::/120 dev eth2 proto kernel metric 256 pref medium
2100:3::/64 via 2100:1::64 dev eth1 metric 1024 pref medium
local fe80::e0:f9ff:fe09:3cac dev lo proto none metric 0 pref medium
local fe80::e0:f9ff:fe1c:b974 dev lo proto none metric 0 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth2 proto kernel metric 256 pref medium
ff00::/8 dev red metric 256 pref medium
ff00::/8 dev eth1 metric 256 pref medium
ff00::/8 dev eth2 metric 256 pref medium
unreachable default dev lo metric 240 error -113 pref medium
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
v2
- addressed DaveM's comment that table lookup failure falls back to full
lookup to be consistent with ipv4
- moved new code to a helper for better readability
net/ipv6/route.c | 40 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index d916d6ab9ad2..af46e19205f5 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1769,6 +1769,37 @@ static int ip6_convert_metrics(struct mx6_config *mxc,
return -EINVAL;
}
+static struct rt6_info *ip6_nh_lookup_table(struct net *net,
+ struct fib6_config *cfg,
+ const struct in6_addr *gw_addr)
+{
+ struct flowi6 fl6 = {
+ .flowi6_oif = cfg->fc_ifindex,
+ .daddr = *gw_addr,
+ .saddr = cfg->fc_prefsrc,
+ };
+ struct fib6_table *table;
+ struct rt6_info *rt;
+ int flags = 0;
+
+ table = fib6_get_table(net, cfg->fc_table);
+ if (!table)
+ return NULL;
+
+ if (!ipv6_addr_any(&cfg->fc_prefsrc))
+ flags |= RT6_LOOKUP_F_HAS_SADDR;
+
+ rt = ip6_pol_route(net, table, cfg->fc_ifindex, &fl6, flags);
+
+ /* if table lookup failed, fall back to full lookup */
+ if (rt == net->ipv6.ip6_null_entry) {
+ ip6_rt_put(rt);
+ rt = NULL;
+ }
+
+ return rt;
+}
+
static struct rt6_info *ip6_route_info_create(struct fib6_config *cfg)
{
struct net *net = cfg->fc_nlinfo.nl_net;
@@ -1940,7 +1971,7 @@ static struct rt6_info *ip6_route_info_create(struct fib6_config *cfg)
rt->rt6i_gateway = *gw_addr;
if (gwa_type != (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST)) {
- struct rt6_info *grt;
+ struct rt6_info *grt = NULL;
/* IPv6 strictly inhibits using not link-local
addresses as nexthop address.
@@ -1952,7 +1983,12 @@ static struct rt6_info *ip6_route_info_create(struct fib6_config *cfg)
if (!(gwa_type & IPV6_ADDR_UNICAST))
goto out;
- grt = rt6_lookup(net, gw_addr, NULL, cfg->fc_ifindex, 1);
+ if (cfg->fc_table)
+ grt = ip6_nh_lookup_table(net, cfg, gw_addr);
+
+ if (!grt)
+ grt = rt6_lookup(net, gw_addr, NULL,
+ cfg->fc_ifindex, 1);
err = -EHOSTUNREACH;
if (!grt)
--
2.1.4
^ permalink raw reply related
* RE: [PATCH 2/6] Documentation: DT binding doc for iProc Shared MDIO Controller.
From: Pramod Kumar @ 2016-04-25 4:27 UTC (permalink / raw)
To: Rob Herring
Cc: Catalin Marinas, Will Deacon, Masahiro Yamada, Chen-Yu Tsai,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Arnd Bergmann, Suzuki K Poulose, netdev-u79uwXL29TY76Z2rM5mHXA,
Punit Agrawal, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
BCM Kernel Feedback,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20160422201045.GA32303@rob-hp-laptop>
Hi Rob,
Thanks for reviewing and providing your valuable comments.
> -----Original Message-----
> From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: 23 April 2016 01:41
> To: Pramod Kumar
> Cc: Catalin Marinas; Will Deacon; Masahiro Yamada; Chen-Yu Tsai; Mark
> Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Pawel Moll; Arnd Bergmann; Suzuki K
> Poulose; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Punit Agrawal;
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> BCM Kernel Feedback; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH 2/6] Documentation: DT binding doc for iProc Shared
MDIO
> Controller.
>
> On Thu, Apr 21, 2016 at 02:48:39PM +0530, Pramod Kumar wrote:
> > Add DT binding doc for iProc Shared MDIO Controller which populate all
> > masters to Shared MDIO framework.
> >
> > Signed-off-by: Pramod Kumar <pramod.kumar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> > Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> > Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> > ---
> > .../bindings/bus/brcm,iproc-shared-mdio.txt | 76
> ++++++++++++++++++++++
> > 1 file changed, 76 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/bus/brcm,iproc-shared-mdio.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/bus/brcm,iproc-shared-mdio.txt
> > b/Documentation/devicetree/bindings/bus/brcm,iproc-shared-mdio.txt
> > new file mode 100644
> > index 0000000..f455f3d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/bus/brcm,iproc-shared-mdio.txt
> > @@ -0,0 +1,76 @@
> > +Broadcom iProc Shared MDIO Controller
> > +
> > +Required properties:
> > +- compatible:
> > + "brcm,iproc-shared-mdio" for shared MDIO controller.
> > +- reg: specifies the base physical address and size of the registers
> > +- reg-names: should be "mdio"
> > +- #address-cells: must be 1.
> > +- #size-cells: must be 0.
> > +
> > +optional:
> > +child nodes: Masters are represented as a child node of shared MDIO
> > +controller and all the PHYs handled by this master are represented as
its child
> node.
>
> Seems kind of useless if child nodes are optional.
>
I agree. I'll put it under required properties.
> > +
> > +Master nodes properties are defined as-
> > +
> > +Required properties:
> > +- compatible: Used to match driver of this PHY.
> > +- reg: MDIO master ID.
> > +- #address-cells: must be 1.
> > +- #size-cells: must be 0.
> > +
> > +optional:
> > +-brcm,phy-internal: if presents, PHYs are internal. Absence shows phy
> > +is external.
> > +-brcm,is-c45: if presents, Controller uses Clause-45 to issue MDIO
> transaction.
> > +else Controller uses Clause-22 for transactions.
>
> Isn't this a property of the phy? IIRC, there is a standard property or
compatible
> string for this.
>
Shared MDIO controller's master holds all above property to ensure the
proper MDIO transaction over its bus. Hence tried to pinned here.
These properties are standard one for the Ethernet PHY but Broadcom SoCs
MDIO is shared even with other I/O subsystem. Other subsystem does not
defines this property hence has been defined here.
> > +
> > +PHY nodes are represented as the child node of Master. Child nodes
> > +properties are defined as-
> > +
> > +Required properties:
> > +-reg: phy id of attached PHY.
> > +
> > +optional:
> > +There could be additional properties required to configure the
> > +specific phy like phy-mode in case of gpphy node below. These should
> > +be defined here and used by respective drivers.
> > +
> > +Example:
> > +iproc_mdio: iproc_mdio@663f0000 {
> > + compatible = "brcm,iproc-shared-mdio";
> > + reg = <0x6602023c 0x14>;
> > + reg-names = "mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sata-master@6 {
>
> mdio@6
Do you advise us to rename the node name as mdio@6? If yes, I don't have
any personal preferences here and would do it. I'd thought to give proper
name so that consumer could get what this node is representing.
Please suggest us.
>
> > + compatible = "brcm,iproc-ns2-sata-phy";
> > + reg = <0x6>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + brcm,phy-internal;
> > +
> > + sata_phy0: sata-phy@1 {
>
> phy@1
>
Same as above.
> > + reg = <0x1>;
> > + #phy-cells = <0>;
> > + };
> > +
> > + sata_phy1: sata-phy@2 {
>
> phy@2
>
Same as above.
> > + reg = <0x2>;
> > + #phy-cells = <0>;
> > + };
> > + };
> > +
> > + eth-master@0 {
>
> mdio@0
Same as above.
>
> > + compatible = "brcm,iproc-mdio-master-eth";
> > + reg = <0x0>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + gphy0: eth-phy@10 {
>
> phy@10
>
Same as above.
> > + reg = <0x10>;
> > + phy-mode = "mii";
> > + };
> > + };
> > +};
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Regards,
Pramod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 5/6] Documentation: Binding doc for ethernet master in NS2
From: Pramod Kumar @ 2016-04-25 4:43 UTC (permalink / raw)
To: Rob Herring
Cc: Catalin Marinas, Will Deacon, Masahiro Yamada, Chen-Yu Tsai,
BCM Kernel Feedback, Pawel Moll, Mark Rutland, Arnd Bergmann,
Suzuki K Poulose, Punit Agrawal,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160422201351.GA3048@rob-hp-laptop>
Hi Rob,
Thanks for review and providing your valuable comments.
> -----Original Message-----
> From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: 23 April 2016 01:44
> To: Pramod Kumar
> Cc: Catalin Marinas; Will Deacon; Masahiro Yamada; Chen-Yu Tsai; BCM
Kernel
> Feedback; Pawel Moll; Mark Rutland; Arnd Bergmann; Suzuki K Poulose;
Punit
> Agrawal; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCH 5/6] Documentation: Binding doc for ethernet master
in
> NS2
>
> On Thu, Apr 21, 2016 at 02:48:42PM +0530, Pramod Kumar wrote:
> > Adding binding doc for ethernet master present in shared MDIO
> > controller.
> >
> > Signed-off-by: Pramod Kumar <pramod.kumar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> > Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> > Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> > ---
> > .../bindings/net/brcm,iproc-mdio-shared.txt | 32
> ++++++++++++++++++++++
> > 1 file changed, 32 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/net/brcm,iproc-mdio-shared.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/brcm,iproc-mdio-shared.txt
> > b/Documentation/devicetree/bindings/net/brcm,iproc-mdio-shared.txt
> > new file mode 100644
> > index 0000000..1ffdd4b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/brcm,iproc-mdio-shared.txt
> > @@ -0,0 +1,32 @@
> > +Broadcom Ethernet master for shared mdio controller
> > +
> > +Required properties:
> > +- compatible: must be "brcm,iproc-mdio-master-eth"
> > +- reg: master id of Ethernet block
> > +- address-cells: should be 1
> > +- size-cells: should be 0
> > +
> > +Sub-nodes:
> > + Each port's PHY should be represented as a sub-node.
> > +
> > +Sub-nodes required properties:
> > +- reg: the PHY number
> > +- phy-mode: media type connecting the PHY and MAC.
> > +
> > +
> > +Example:
> > + eth-master@0 {
>
> Is this a child of something?
>
This is an Shared MDIO master node as described in cover letter and is the
child node of iProc_shared_mdio plarform driver.
> Why is this not just an mdio bus underneath the ethernet controller? How
is this
> accessed?
This is the part for Shared MDIO controller which is shared among other
subsystem as well hence defined here. This works as glue layer between
This controller and legacy MDIO framework and register the MDIO bus to
legacy framework.
When any read/write request is issue from Legacy MDIO controller framework
it gets propagated to Shared controller platform driver via this driver
and finally platform driver issue MDIO transaction over bus.
>
> > + compatible = "brcm,iproc-mdio-master-eth";
> > + reg = <0x0>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + gphy0: eth-phy@10 {
> > + reg = <0x10>;
> > + phy-mode = "mii";
> > + };
> > + status = "ok"
> > + };
> > +
> > +For more info on ethernet phy binding, please,refer to:
> > +Documentation/devicetree/bindings/net/phy.txt
> > +Documentation/devicetree/bindings/net/ethernet.txt
> > --
> > 1.9.1
> >
Regards,
Pramod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH net 1/1] net: fec: update dirty_tx even if no skb
From: Fugang Duan @ 2016-04-25 6:28 UTC (permalink / raw)
To: Fugang Duan, Troy Kisky, netdev@vger.kernel.org,
davem@davemloft.net, lznuaa@gmail.com
Cc: andrew@lunn.ch, stillcompiling@gmail.com, arnd@arndb.de,
sergei.shtylyov@cogentembedded.com, gerg@uclinux.org,
Fabio Estevam, johannes@sipsolutions.net, l.stach@pengutronix.de,
holgerschurig@gmail.com, linux-arm-kernel@lists.infradead.org,
tremyfr@gmail.com
In-Reply-To: <HE1PR0401MB1849C9460B0FCC6A0FB2CDBEFF620@HE1PR0401MB1849.eurprd04.prod.outlook.com>
From: Fugang Duan <fugang.duan@nxp.com> Sent: Monday, April 25, 2016 9:58 AM
> To: Troy Kisky <troy.kisky@boundarydevices.com>; netdev@vger.kernel.org;
> davem@davemloft.net; lznuaa@gmail.com
> Cc: Fabio Estevam <fabio.estevam@nxp.com>; l.stach@pengutronix.de;
> andrew@lunn.ch; tremyfr@gmail.com; gerg@uclinux.org; linux-arm-
> kernel@lists.infradead.org; johannes@sipsolutions.net;
> stillcompiling@gmail.com; sergei.shtylyov@cogentembedded.com;
> arnd@arndb.de; holgerschurig@gmail.com
> Subject: RE: [PATCH net 1/1] net: fec: update dirty_tx even if no skb
>
> From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Saturday, April 23,
> 2016 12:12 AM
> > To: Fugang Duan <fugang.duan@nxp.com>; netdev@vger.kernel.org;
> > davem@davemloft.net; lznuaa@gmail.com
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>; l.stach@pengutronix.de;
> > andrew@lunn.ch; tremyfr@gmail.com; gerg@uclinux.org; linux-arm-
> > kernel@lists.infradead.org; johannes@sipsolutions.net;
> > stillcompiling@gmail.com; sergei.shtylyov@cogentembedded.com;
> > arnd@arndb.de; holgerschurig@gmail.com
> > Subject: Re: [PATCH net 1/1] net: fec: update dirty_tx even if no skb
> >
> > On 4/21/2016 10:59 PM, Fugang Duan wrote:
> > > From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Friday,
> > > April 22, 2016 10:01 AM
> > >> To: netdev@vger.kernel.org; davem@davemloft.net; Fugang Duan
> > >> <fugang.duan@nxp.com>; lznuaa@gmail.com
> > >> Cc: Fabio Estevam <fabio.estevam@nxp.com>; l.stach@pengutronix.de;
> > >> andrew@lunn.ch; tremyfr@gmail.com; gerg@uclinux.org; linux-arm-
> > >> kernel@lists.infradead.org; johannes@sipsolutions.net;
> > >> stillcompiling@gmail.com; sergei.shtylyov@cogentembedded.com;
> > >> arnd@arndb.de; holgerschurig@gmail.com; Troy Kisky
> > >> <troy.kisky@boundarydevices.com>
> > >> Subject: [PATCH net 1/1] net: fec: update dirty_tx even if no skb
> > >>
> > >> If dirty_tx isn't updated, then dma_unmap_single will be called twice.
> > >>
> > >> This fixes a
> > >> [ 58.420980] ------------[ cut here ]------------
> > >> [ 58.425667] WARNING: CPU: 0 PID: 377 at
> /home/schurig/d/mkarm/linux-
> > >> 4.5/lib/dma-debug.c:1096 check_unmap+0x9d0/0xab8()
> > >> [ 58.436405] fec 2188000.ethernet: DMA-API: device driver tries to free
> > DMA
> > >> memory it has not allocated [device address=0x0000000000000000]
> > >> [size=66 bytes]
> > >>
> > >> encountered by Holger
> > >>
> > >> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> > >> Tested-by: <holgerschurig@gmail.com>
> > >> ---
> > >> drivers/net/ethernet/freescale/fec_main.c | 8 +++-----
> > >> 1 file changed, 3 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> > >> b/drivers/net/ethernet/freescale/fec_main.c
> > >> index 08243c2..b71654c 100644
> > >> --- a/drivers/net/ethernet/freescale/fec_main.c
> > >> +++ b/drivers/net/ethernet/freescale/fec_main.c
> > >> @@ -1197,10 +1197,8 @@ fec_enet_tx_queue(struct net_device *ndev,
> > u16
> > >> queue_id)
> > >> fec16_to_cpu(bdp->cbd_datlen),
> > >> DMA_TO_DEVICE);
> > >> bdp->cbd_bufaddr = cpu_to_fec32(0);
> > >> - if (!skb) {
> > >> - bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
> > >> - continue;
> > >> - }
> > >> + if (!skb)
> > >> + goto skb_done;
> > >>
> > >> /* Check for errors. */
> > >> if (status & (BD_ENET_TX_HB | BD_ENET_TX_LC | @@ -1239,7
> > >> +1237,7 @@ fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
> > >>
> > >> /* Free the sk buffer associated with this last transmit */
> > >> dev_kfree_skb_any(skb);
> > >> -
> > >> +skb_done:
> > >> /* Make sure the update to bdp and tx_skbuff are performed
> > >> * before dirty_tx
> > >> */
> > >> --
> > >> 2.5.0
> > >
> > > The patch is fine for me.
> > > Can you review below patch that also fix the issue. It can take much
> > > effort due to less rmb() and READ_ONCE() operation that is very
> > > sensitive for duplex Gbps test for i.MX6SX/i.MX7d SOC. (i.MX6SX can
> > > reach at 1.4Gbps, i.MX7D can reach at 1.8Gbps.)
> >
> >
> >
> > If "READ_ONCE(bdp->cbd_sc)" is really that expensive, then you should
> > skip the 1st read as well and only do it after skb presence is
> > verified. But some numbers would really help sell the patch.
> > Also, I comment as to why the code is reorganized would be warranted
> >
> I will do the performance test on i.MX7d to compare the data for the two
> patches.
> Wait my result...
>
> Thanks.
>
I did simple test for tcp bidirectional test on i.MX7d platform:
With my patch:
[ 3] 0.0-20.0 sec 1.79 GBytes 770 Mbits/sec
[ 5] 0.0-20.0 sec 1.93 GBytes 828 Mbits/sec
With your patch on this thread:
[ 3] 0.0-20.0 sec 1.75 GBytes 750 Mbits/sec
[ 5] 0.0-20.0 sec 1.78 GBytes 762 Mbits/sec
And then turn of tso feature (ethtool -K eth0 tso off):
[ 3] 0.0-20.0 sec 1.57 GBytes 673 Mbits/sec
[ 5] 0.0-20.0 sec 1.58 GBytes 677 Mbits/sec
Then turn off sg (ethtool -K eth0 sg off):
[ 3] 0.0-20.0 sec 1.09 GBytes 469 Mbits/sec
[ 5] 0.0-20.0 sec 1.09 GBytes 468 Mbits/sec
It seems there have more tcp segments during iperf testing. I think rmb() is expensive, to reduce rmb() in one tcp frame can increase little performance.
> >
> > >
> > > --- a/drivers/net/ethernet/freescale/fec_main.c
> > > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > > @@ -1160,12 +1160,13 @@ static void
> > > fec_enet_tx_queue(struct net_device *ndev, u16 queue_id) {
> > > struct fec_enet_private *fep;
> > > - struct bufdesc *bdp;
> > > + struct bufdesc *bdp, *bdp_t;
> > > unsigned short status;
> > > struct sk_buff *skb;
> > > struct fec_enet_priv_tx_q *txq;
> > > struct netdev_queue *nq;
> > > int index = 0;
> > > + int i, bdnum;
> > > int entries_free;
> > >
> > > fep = netdev_priv(ndev);
> > > @@ -1187,20 +1188,28 @@ fec_enet_tx_queue(struct net_device *ndev,
> > u16 queue_id)
> > > if (status & BD_ENET_TX_READY)
> > > break;
> > >
> > > - index = fec_enet_get_bd_index(bdp, &txq->bd);
> > > -
> > > + bdp_t = bdp;
> > > + bdnum = 1;
> > > + index = fec_enet_get_bd_index(txq->tx_bd_base,
> > > + bdp_t, fep);
> > > skb = txq->tx_skbuff[index];
> > > - txq->tx_skbuff[index] = NULL;
> > > - if (!IS_TSO_HEADER(txq, fec32_to_cpu(bdp->cbd_bufaddr)))
> > > - dma_unmap_single(&fep->pdev->dev,
> > > - fec32_to_cpu(bdp->cbd_bufaddr),
> > > - fec16_to_cpu(bdp->cbd_datlen),
> > > - DMA_TO_DEVICE);
> > > - bdp->cbd_bufaddr = cpu_to_fec32(0);
> > > - if (!skb) {
> > > - bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
> > > - continue;
> > > + while (!skb) {
> > > + bdp_t = fec_enet_get_nextdesc(bdp_t, &txq->bd);
> > > + index = fec_enet_get_bd_index(txq->tx_bd_base, bdp_t, fep);
> > > + skb = txq->tx_skbuff[index];
> > > + bdnum++;
> > > + }
> > > + status = fec16_to_cpu(READ_ONCE(bdp->cbd_sc));
> > > + if (status & BD_ENET_TX_READY)
> > > + break;
> > > +
> > > + for (i = 0; i < bdnum; i++) {
> > > + if (!IS_TSO_HEADER(txq, bdp->cbd_bufaddr))
> > > + dma_unmap_single(&fep->pdev->dev, bdp->cbd_bufaddr,
> > > + bdp->cbd_datlen, DMA_TO_DEVICE);
> > > + bdp->cbd_bufaddr = 0;
> > > + if (i < bdnum - 1)
> > > + bdp = fec_enet_get_nextdesc(bdp,
> > > + &txq->bd);
> > > }
> > > + txq->tx_skbuff[index] = NULL;
> > >
> > >
> > > Regards,
> > > Andy
> > >
^ permalink raw reply
* Re: [RFC][PATCH] net: stmmac: Call custom init from stmmac_dvr_probe
From: Joachim Eastwood @ 2016-04-25 6:30 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, peppe.cavallaro, alexandre.torgue, Maxime Ripard,
Chen-Yu Tsai, Matthew Gerlach, Dinh Nguyen, David S . Miller
In-Reply-To: <1461240748-5464-1-git-send-email-marex@denx.de>
Hi Marek,
On 21 April 2016 at 14:12, Marek Vasut <marex@denx.de> wrote:
> Each and every driver which implements custom plat_data->init function
> calls it exactly before stmmac_dvr_probe(). Trim down the code duplication
> by calling the plat_data->init function from stmmac_dvr_probe() instead.
This is a result of my refactoring that started a long time ago, but
the cleanup after this is still missing. I have a patch set that
removes the init/exit callbacks from most of the drivers and replace
them with proper PM and remove callbacks. Patches can be found here:
https://github.com/manabian/linux-lpc/tree/net-next-dwmac. Note that
the branch is outdated now and needs to be rebased.
Sadly I haven't had much time to work on this lately. One of reason
why I want to get rid of the init/exit callback is that it kinda
forces the driver to call the same code for probe/resume and
remove/suspend. This does not work for all drivers and this has to
worked around in some drivers. In the end the dwmac drivers will look
more standard Linux drivers and the stmmac will be used as library
that drivers call into. Note that for "legacy" platforms which use the
generic driver I intend to keep the init/exit callbacks since they are
still used by Blackfin and Loongson, but new DT enabled drivers should
not use these callbacks anymore.
If you are willing to test my patch set for dwmac-socfpga(?). I'll see
if I can create the time to send them to netdev early this week.
regards,
Joachim Eastwood
^ permalink raw reply
* [PATCH net 1/3] bnxt_en: Don't fallback to INTA on VF.
From: Michael Chan @ 2016-04-25 6:30 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1461565851-32524-1-git-send-email-michael.chan@broadcom.com>
Only MSI-X can be used on a VF. The driver should fail initialization
if it cannot successfully enable MSI-X.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 12a009d..e787deb 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4309,7 +4309,7 @@ static int bnxt_setup_int_mode(struct bnxt *bp)
if (bp->flags & BNXT_FLAG_MSIX_CAP)
rc = bnxt_setup_msix(bp);
- if (!(bp->flags & BNXT_FLAG_USING_MSIX)) {
+ if (!(bp->flags & BNXT_FLAG_USING_MSIX) && BNXT_PF(bp)) {
/* fallback to INTA */
rc = bnxt_setup_inta(bp);
}
--
1.8.3.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