* Re: [PATCH net-next] dpaa2-eth: Introduce TX congestion management
From: David Miller @ 2018-11-08 6:07 UTC (permalink / raw)
To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei
In-Reply-To: <1541586669-24334-1-git-send-email-ruxandra.radulescu@nxp.com>
From: Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>
Date: Wed, 7 Nov 2018 10:31:16 +0000
> We chose this mechanism over BQL (to which it is conceptually
> very similar) because a) we can take advantage of the hardware
> offloading and b) BQL doesn't match well with our driver fastpath
> (we process ingress (Rx or Tx conf) frames in batches of up to 16,
> which in certain scenarios confuses the BQL adaptive algorithm,
> resulting in too low values of the limit and low performance).
First, this kind of explanation belongs in the commit message.
Second, you'll have to describe better what BQL, which is the
ultimate standard mechanism for every single driver in the
kernel to deal with this issue.
Are you saying that if 15 TX frames are pending, not TX interrupt
will arrive at all?
There absolutely must be some timeout or similar interrupt that gets
sent in that kind of situation. You cannot leave stale TX packets
on your ring unprocessed just because a non-multiple of 16 packets
were queued up and then TX activity stopped.
^ permalink raw reply
* [PATCH net] inet: frags: better deal with smp races
From: Eric Dumazet @ 2018-11-08 6:10 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, 배석진
Multiple cpus might attempt to insert a new fragment in rhashtable,
if for example RPS is buggy, as reported by 배석진in
https://patchwork.ozlabs.org/patch/994601/
We use rhashtable_lookup_get_insert_key() instead of
rhashtable_insert_fast() to let cpus losing the race
free their own inet_frag_queue and use the one that
was inserted by another cpu.
Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: 배석진 <soukjin.bae@samsung.com>
---
net/ipv4/inet_fragment.c | 29 +++++++++++++++--------------
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index bcb11f3a27c0c34115af05034a5a20f57842eb0a..ced9abd4bec6cd494e352c1d6a97da8f67cf6073 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -178,21 +178,22 @@ static struct inet_frag_queue *inet_frag_alloc(struct netns_frags *nf,
}
static struct inet_frag_queue *inet_frag_create(struct netns_frags *nf,
- void *arg)
+ void *arg,
+ struct inet_frag_queue **prev)
{
struct inet_frags *f = nf->f;
struct inet_frag_queue *q;
- int err;
q = inet_frag_alloc(nf, f, arg);
- if (!q)
+ if (!q) {
+ *prev = ERR_PTR(-ENOMEM);
return NULL;
-
+ }
mod_timer(&q->timer, jiffies + nf->timeout);
- err = rhashtable_insert_fast(&nf->rhashtable, &q->node,
- f->rhash_params);
- if (err < 0) {
+ *prev = rhashtable_lookup_get_insert_key(&nf->rhashtable, &q->key,
+ &q->node, f->rhash_params);
+ if (*prev) {
q->flags |= INET_FRAG_COMPLETE;
inet_frag_kill(q);
inet_frag_destroy(q);
@@ -204,22 +205,22 @@ static struct inet_frag_queue *inet_frag_create(struct netns_frags *nf,
/* TODO : call from rcu_read_lock() and no longer use refcount_inc_not_zero() */
struct inet_frag_queue *inet_frag_find(struct netns_frags *nf, void *key)
{
- struct inet_frag_queue *fq;
+ struct inet_frag_queue *fq, *prev;
if (!nf->high_thresh || frag_mem_limit(nf) > nf->high_thresh)
return NULL;
rcu_read_lock();
- fq = rhashtable_lookup(&nf->rhashtable, key, nf->f->rhash_params);
- if (fq) {
+ prev = rhashtable_lookup(&nf->rhashtable, key, nf->f->rhash_params);
+ if (!prev)
+ fq = inet_frag_create(nf, key, &prev);
+ if (prev && !IS_ERR(prev)) {
+ fq = prev;
if (!refcount_inc_not_zero(&fq->refcnt))
fq = NULL;
- rcu_read_unlock();
- return fq;
}
rcu_read_unlock();
-
- return inet_frag_create(nf, key);
+ return fq;
}
EXPORT_SYMBOL(inet_frag_find);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* Re: [net-next 06/12] i40e/ixgbe/igb: fail on new WoL flag setting WAKE_MAGICSECURE
From: Kevin Easton @ 2018-11-08 6:05 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Todd Fujinaka, netdev, nhorman, sassmann
In-Reply-To: <20181107224830.9737-7-jeffrey.t.kirsher@intel.com>
On Wed, Nov 07, 2018 at 02:48:24PM -0800, Jeff Kirsher wrote:
> From: Todd Fujinaka <todd.fujinaka@intel.com>
>
> There's a new flag for setting WoL filters that is only
> enabled on one manufacturer's NICs, and it's not ours. Fail
> with EOPNOTSUPP.
>
> Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 ++-
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 3 ++-
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> index 9f8464f80783..9c1211ad2c6b 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> @@ -2377,7 +2377,8 @@ static int i40e_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> return -EOPNOTSUPP;
>
> /* only magic packet is supported */
> - if (wol->wolopts && (wol->wolopts != WAKE_MAGIC))
> + if (wol->wolopts && (wol->wolopts != WAKE_MAGIC)
> + | (wol->wolopts != WAKE_FILTER))
> return -EOPNOTSUPP;
This doesn't look right. WAKE_MAGIC and WAKE_FILTER are distinct, so
(wol->wolopts != WAKE_MAGIC) | (wol->wolopts != WAKE_FILTER)
will always be 1.
It looks like the existing test in this driver was fine - it *only*
accepted wol->wolopts of either 0 or WAKE_MAGIC, it was already
rejecting everything else including WAKE_FILTER.
Suggest you drop that hunk.
- Kevin
>
>
> /* is this a new value? */
> diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> index 5acf3b743876..c57671068245 100644
> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> @@ -2113,7 +2113,7 @@ static int igb_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> {
> struct igb_adapter *adapter = netdev_priv(netdev);
>
> - if (wol->wolopts & (WAKE_ARP | WAKE_MAGICSECURE))
> + if (wol->wolopts & (WAKE_ARP | WAKE_MAGICSECURE | WAKE_FILTER))
> return -EOPNOTSUPP;
>
> if (!(adapter->flags & IGB_FLAG_WOL_SUPPORTED))
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> index 732b1e6ecc43..acba067cc15a 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> @@ -2206,7 +2206,8 @@ static int ixgbe_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> {
> struct ixgbe_adapter *adapter = netdev_priv(netdev);
>
> - if (wol->wolopts & (WAKE_PHY | WAKE_ARP | WAKE_MAGICSECURE))
> + if (wol->wolopts & (WAKE_PHY | WAKE_ARP | WAKE_MAGICSECURE |
> + WAKE_FILTER))
> return -EOPNOTSUPP;
>
> if (ixgbe_wol_exclusion(adapter, wol))
> --
> 2.19.1
>
>
>
^ permalink raw reply
* Re: (2) (2) [Kernel][NET] Bug report on packet defragmenting
From: Eric Dumazet @ 2018-11-08 6:13 UTC (permalink / raw)
To: soukjin.bae, netdev@vger.kernel.org
In-Reply-To: <8b2209af-1221-f4f5-54e5-d9f5a503373e@gmail.com>
On 11/07/2018 08:26 PM, Eric Dumazet wrote:
>
>
> On 11/07/2018 08:10 PM, 배석진 wrote:
>>> --------- Original Message ---------
>>> Sender : Eric Dumazet <eric.dumazet@gmail.com>
>>> Date : 2018-11-08 12:57 (GMT+9)
>>> Title : Re: (2) [Kernel][NET] Bug report on packet defragmenting
>>>
>>> On 11/07/2018 07:24 PM, Eric Dumazet wrote:
>>>
>>>> Sure, it is better if RPS is smarter, but if there is a bug in IPv6 defrag unit
>>>> we must investigate and root-cause it.
>>>
>>> BTW, IPv4 defrag seems to have the same issue.
>>
>>
>> yes, it could be.
>> key point isn't limitted to ipv6.
>>
>> maybe because of faster air-network and modem,
>> it looks like occure more often and we got recognized that.
>>
>> anyway,
>> we'll apply our patch to resolve this problem.
>
> Yeah, and I will fix the defrag units.
>
> We can not rely on other layers doing proper no-reorder logic for us.
>
> Problem here is that multiple cpus attempt concurrent rhashtable_insert_fast()
> and do not properly recover in case -EEXIST is returned.
>
> This is silly, of course :/
Patch would be https://patchwork.ozlabs.org/patch/994658/
^ permalink raw reply
* Re: [PATCH] [stable, netdev 4.4+] lan78xx: make sure RX_ADDRL & RX_ADDRH regs are always up to date
From: Sasha Levin @ 2018-11-08 15:49 UTC (permalink / raw)
To: Paolo Pisati
Cc: Woojung Huh, Microchip Linux Driver Support, netdev, stable,
linux-usb, linux-kernel
In-Reply-To: <20181108110127.GA8415@harukaze>
On Thu, Nov 08, 2018 at 12:01:27PM +0100, Paolo Pisati wrote:
>On Wed, Nov 07, 2018 at 07:17:51PM -0500, Sasha Levin wrote:
>> So why not just take 760db29bdc completely? It looks safer than taking a
>> partial backport, and will make applying future patches easier.
>>
>> I tried to do it and it doesn't look like there are any dependencies
>> that would cause an issue.
>
>Somehow i was convinced it didn't build on 4.4.x... can you pick it up?
>
>commit 760db29bdc97b73ff60b091315ad787b1deb5cf5
>Author: Phil Elwell <phil@raspberrypi.org>
>Date: Thu Apr 19 17:59:38 2018 +0100
>
> lan78xx: Read MAC address from DT if present
>
> There is a standard mechanism for locating and using a MAC address from
> the Device Tree. Use this facility in the lan78xx driver to support
> applications without programmed EEPROM or OTP. At the same time,
> regularise the handling of the different address sources.
>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Can you confirm it actually works on 4.4?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH net-next] net: phy: make phy_trigger_machine static
From: David Miller @ 2018-11-08 6:19 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <291aa78f-678b-14b4-7c98-d73799a5e455@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 7 Nov 2018 08:15:58 +0100
> phy_trigger_machine() is used in phy.c only, so we can make it static.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: realtek: load driver for all PHYs with a Realtek OUI
From: David Miller @ 2018-11-08 6:19 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <a1a08754-1f94-3689-f26b-076283d9cc03@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 7 Nov 2018 08:52:46 +0100
> Instead of listing every single PHYID, load the driver for every PHYID
> with a Realtek OUI, independent of model number and revision.
>
> This patch also improves two further aspects:
> - constify realtek_tbl[]
> - the mask should have been 0xffffffff instead of 0x001fffff so far,
> by masking out some bits a PHY from another vendor could have been
> matched
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/wan/fsl_ucc_hdlc: add BQL support
From: David Miller @ 2018-11-08 6:21 UTC (permalink / raw)
To: mathias.thore
Cc: qiang.zhao, linuxppc-dev, netdev, joakim.tjernlund,
david.gounaris
In-Reply-To: <20181107080945.30651-1-mathias.thore@infinera.com>
From: Mathias Thore <mathias.thore@infinera.com>
Date: Wed, 7 Nov 2018 09:09:45 +0100
> Add byte queue limits support in the fsl_ucc_hdlc driver.
>
> Signed-off-by: Mathias Thore <mathias.thore@infinera.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] virtio_ring: add packed ring support
From: Michael S. Tsirkin @ 2018-11-08 15:56 UTC (permalink / raw)
To: Tiwei Bie
Cc: Jason Wang, virtualization, linux-kernel, netdev, virtio-dev,
wexu, jfreimann
In-Reply-To: <20181108115148.GA15701@debian>
On Thu, Nov 08, 2018 at 07:51:48PM +0800, Tiwei Bie wrote:
> On Thu, Nov 08, 2018 at 04:18:25PM +0800, Jason Wang wrote:
> >
> > On 2018/11/8 上午9:38, Tiwei Bie wrote:
> > > > > +
> > > > > + if (vq->vq.num_free < descs_used) {
> > > > > + pr_debug("Can't add buf len %i - avail = %i\n",
> > > > > + descs_used, vq->vq.num_free);
> > > > > + /* FIXME: for historical reasons, we force a notify here if
> > > > > + * there are outgoing parts to the buffer. Presumably the
> > > > > + * host should service the ring ASAP. */
> > > > I don't think we have a reason to do this for packed ring.
> > > > No historical baggage there, right?
> > > Based on the original commit log, it seems that the notify here
> > > is just an "optimization". But I don't quite understand what does
> > > the "the heuristics which KVM uses" refer to. If it's safe to drop
> > > this in packed ring, I'd like to do it.
> >
> >
> > According to the commit log, it seems like a workaround of lguest networking
> > backend.
>
> Do you know why removing this notify in Tx will break "the
> heuristics which KVM uses"? Or what does "the heuristics
> which KVM uses" refer to?
Yes. QEMU has a mode where it disables notifications and processes TX
ring periodically from a timer. It's off by default but used to be on
by default a long time ago. If ring becomes full this causes traffic
stalls. As a work-around Rusty put in this hack to kick on ring full
even with notifications disabled. It's easy enough to make sure QEMU
does not combine devices with packed ring support with the timer hack.
And I am guessing it's safe enough to also block that option completely
e.g. when virtio 1.0 is enabled.
>
> > I agree to drop it, we should not have such burden.
> >
> > But we should notice that, with this removed, the compare between packed vs
> > split is kind of unfair. Consider the removal of lguest support recently,
> > maybe we can drop this for split ring as well?
> >
> > Thanks
> >
> >
> > >
> > > commit 44653eae1407f79dff6f52fcf594ae84cb165ec4
> > > Author: Rusty Russell<rusty@rustcorp.com.au>
> > > Date: Fri Jul 25 12:06:04 2008 -0500
> > >
> > > virtio: don't always force a notification when ring is full
> > > We force notification when the ring is full, even if the host has
> > > indicated it doesn't want to know. This seemed like a good idea at
> > > the time: if we fill the transmit ring, we should tell the host
> > > immediately.
> > > Unfortunately this logic also applies to the receiving ring, which is
> > > refilled constantly. We should introduce real notification thesholds
> > > to replace this logic. Meanwhile, removing the logic altogether breaks
> > > the heuristics which KVM uses, so we use a hack: only notify if there are
> > > outgoing parts of the new buffer.
> > > Here are the number of exits with lguest's crappy network implementation:
> > > Before:
> > > network xmit 7859051 recv 236420
> > > After:
> > > network xmit 7858610 recv 118136
> > > Signed-off-by: Rusty Russell<rusty@rustcorp.com.au>
> > >
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > index 72bf8bc09014..21d9a62767af 100644
> > > --- a/drivers/virtio/virtio_ring.c
> > > +++ b/drivers/virtio/virtio_ring.c
> > > @@ -87,8 +87,11 @@ static int vring_add_buf(struct virtqueue *_vq,
> > > if (vq->num_free < out + in) {
> > > pr_debug("Can't add buf len %i - avail = %i\n",
> > > out + in, vq->num_free);
> > > - /* We notify*even if* VRING_USED_F_NO_NOTIFY is set here. */
> > > - vq->notify(&vq->vq);
> > > + /* FIXME: for historical reasons, we force a notify here if
> > > + * there are outgoing parts to the buffer. Presumably the
> > > + * host should service the ring ASAP. */
> > > + if (out)
> > > + vq->notify(&vq->vq);
> > > END_USE(vq);
> > > return -ENOSPC;
> > > }
> > >
> > >
^ permalink raw reply
* Re: [PATCH net-next] tun: compute the RFS hash only if needed.
From: David Miller @ 2018-11-08 6:23 UTC (permalink / raw)
To: pabeni; +Cc: netdev, jasowang
In-Reply-To: <12347537bd5fd8b1176ca62ddf51ea9080fe1b41.1541436099.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 7 Nov 2018 10:34:36 +0100
> The tun XDP sendmsg code path, unconditionally computes the symmetric
> hash of each packet for RFS's sake, even when we could skip it. e.g.
> when the device has a single queue.
>
> This change adds the check already in-place for the skb sendmsg path
> to avoid unneeded hashing.
>
> The above gives small, but measurable, performance gain for VM xmit
> path when zerocopy is not enabled.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: vlan: add support for tunnel offload
From: David Miller @ 2018-11-08 6:23 UTC (permalink / raw)
To: dcaratti; +Cc: xiyou.wangcong, netdev, fbl, fw
In-Reply-To: <b55216ca2bf962175a3f79c73e08607deb4c6e7d.1541586443.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 7 Nov 2018 11:28:18 +0100
> GSO tunneled packets are always segmented in software before they are
> transmitted by a VLAN, even when the lower device can offload tunnel
> encapsulation and VLAN together (i.e., some bits in NETIF_F_GSO_ENCAP_ALL
> mask are set in the lower device 'vlan_features'). If we let VLANs have
> the same tunnel offload capabilities as their lower device, throughput
> can improve significantly when CPU is limited on the transmitter side.
>
> - set NETIF_F_GSO_ENCAP_ALL bits in the VLAN 'hw_features', to ensure
> that 'features' will have those bits zeroed only when the lower device
> has no hardware support for tunnel encapsulation.
> - for the same reason, copy GSO-related bits of 'hw_enc_features' from
> lower device to VLAN, and ensure to update that value when the lower
> device changes its features.
> - set NETIF_F_HW_CSUM bit in the VLAN 'hw_enc_features' if 'real_dev'
> is able to compute checksums at least for a kind of packets, like done
> with commit 8403debeead8 ("vlan: Keep NETIF_F_HW_CSUM similar to other
> software devices"). This avoids software segmentation due to mismatching
> checksum capabilities between VLAN's 'features' and 'hw_enc_features'.
>
> Reported-by: Flavio Leitner <fbl@redhat.com>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Applied.
^ permalink raw reply
* [PATCH resend] can: rcar_can: convert to SPDX identifiers
From: Kuninori Morimoto @ 2018-11-08 6:33 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde; +Cc: linux-can, netdev
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
This patch updates license to use SPDX-License-Identifier
instead of verbose license text.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
---
drivers/net/can/rcar/Kconfig | 1 +
drivers/net/can/rcar/Makefile | 1 +
drivers/net/can/rcar/rcar_can.c | 6 +-----
drivers/net/can/rcar/rcar_canfd.c | 6 +-----
4 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/rcar/Kconfig b/drivers/net/can/rcar/Kconfig
index 7b03a3a..bd5a8fc 100644
--- a/drivers/net/can/rcar/Kconfig
+++ b/drivers/net/can/rcar/Kconfig
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
config CAN_RCAR
tristate "Renesas R-Car CAN controller"
depends on ARCH_RENESAS || ARM
diff --git a/drivers/net/can/rcar/Makefile b/drivers/net/can/rcar/Makefile
index 08de36a..c9185b0 100644
--- a/drivers/net/can/rcar/Makefile
+++ b/drivers/net/can/rcar/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
#
# Makefile for the Renesas R-Car CAN & CAN FD controller drivers
#
diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
index 11662f4..06f90a0 100644
--- a/drivers/net/can/rcar/rcar_can.c
+++ b/drivers/net/can/rcar/rcar_can.c
@@ -1,12 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN device driver
*
* Copyright (C) 2013 Cogent Embedded, Inc. <source@cogentembedded.com>
* Copyright (C) 2013 Renesas Solutions Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
#include <linux/module.h>
diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index 602c19e..0541000 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -1,11 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN FD device driver
*
* Copyright (C) 2015 Renesas Electronics Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
/* The R-Car CAN FD controller can operate in either one of the below two modes
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] ibmvnic: fix accelerated VLAN handling
From: David Miller @ 2018-11-08 6:37 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, tlfalcon, jallen
In-Reply-To: <3cad1feb702479b9db69b3cdb393e9b331fe4ce7.1541609304.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Wed, 07 Nov 2018 17:50:52 +0100
> Don't request tag insertion when it isn't present in outgoing skb.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] qlcnic: remove assumption that vlan_tci != 0
From: David Miller @ 2018-11-08 6:38 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, Shahed.Shaikh, manish.chopra, Dept-GELinuxNICDev
In-Reply-To: <aada372e836662d36115ccd292f4191016a4e02d.1541609304.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Wed, 07 Nov 2018 17:50:53 +0100
> VLAN.TCI == 0 is perfectly valid (802.1p), so allow it to be accelerated.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net/vlan: prepare for removal of VLAN_TAG_PRESENT
From: David Miller @ 2018-11-08 6:41 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev
In-Reply-To: <cover.1541610138.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Wed, 07 Nov 2018 18:07:02 +0100
> This is a preparatory patchset before removing the use of VLAN_TAG_PRESENT
> bit in skb->vlan_tci as indication of VLAN offload. This set includes
> only cleanups that allow abstracting of code testing VLAN tag presence
> in drivers and networking code.
Series applied.
^ permalink raw reply
* Re: [net-next 06/12] i40e/ixgbe/igb: fail on new WoL flag setting WAKE_MAGICSECURE
From: Michal Kubecek @ 2018-11-08 6:42 UTC (permalink / raw)
To: Kevin Easton
Cc: Jeff Kirsher, davem, Todd Fujinaka, netdev, nhorman, sassmann
In-Reply-To: <20181108060526.GA11230@ip-172-31-15-78>
On Thu, Nov 08, 2018 at 06:05:26AM +0000, Kevin Easton wrote:
> On Wed, Nov 07, 2018 at 02:48:24PM -0800, Jeff Kirsher wrote:
> > From: Todd Fujinaka <todd.fujinaka@intel.com>
> >
> > There's a new flag for setting WoL filters that is only
> > enabled on one manufacturer's NICs, and it's not ours. Fail
> > with EOPNOTSUPP.
> >
> > Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
> > Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 ++-
> > drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +-
> > drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 3 ++-
> > 3 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > index 9f8464f80783..9c1211ad2c6b 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > @@ -2377,7 +2377,8 @@ static int i40e_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> > return -EOPNOTSUPP;
> >
> > /* only magic packet is supported */
> > - if (wol->wolopts && (wol->wolopts != WAKE_MAGIC))
> > + if (wol->wolopts && (wol->wolopts != WAKE_MAGIC)
> > + | (wol->wolopts != WAKE_FILTER))
> > return -EOPNOTSUPP;
>
> This doesn't look right. WAKE_MAGIC and WAKE_FILTER are distinct, so
>
> (wol->wolopts != WAKE_MAGIC) | (wol->wolopts != WAKE_FILTER)
>
> will always be 1.
Right. Also, using "|" with logical values is rather confusing. While
the result works as expected, its priority is higher than priority of
&& (which would not be true for ||), making the code counterintuitive.
BtW, the patch subject is also wrong, the newly added flag it is dealing
with is WAKE_FILTER, not WAKE_MAGICSECURE.
> It looks like the existing test in this driver was fine - it *only*
> accepted wol->wolopts of either 0 or WAKE_MAGIC, it was already
> rejecting everything else including WAKE_FILTER.
Another way to write the check would be
if (wol->wolopts & ~WAKE_MAGIC)
> > diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> > index 5acf3b743876..c57671068245 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> > @@ -2113,7 +2113,7 @@ static int igb_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> > {
> > struct igb_adapter *adapter = netdev_priv(netdev);
> >
> > - if (wol->wolopts & (WAKE_ARP | WAKE_MAGICSECURE))
> > + if (wol->wolopts & (WAKE_ARP | WAKE_MAGICSECURE | WAKE_FILTER))
> > return -EOPNOTSUPP;
> >
> > if (!(adapter->flags & IGB_FLAG_WOL_SUPPORTED))
I would also suggest taking the opposite approach here, i.e. listing the
flags which _are_ supported so that we don't have to update the code if
another wol flag is added (or userspace sends an invalid one):
#define SUPPORTED_WOL_MODES \
(WAKE_PHY | WAKE_UCAST | WAKE_MCAST | WAKE_BCAST | WAKE_MAGIC)
...
if (wol->wolopts & ~SUPPORTED_WOL_MODES)
return -EOPNOTSUPP;
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> > index 732b1e6ecc43..acba067cc15a 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> > @@ -2206,7 +2206,8 @@ static int ixgbe_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> > {
> > struct ixgbe_adapter *adapter = netdev_priv(netdev);
> >
> > - if (wol->wolopts & (WAKE_PHY | WAKE_ARP | WAKE_MAGICSECURE))
> > + if (wol->wolopts & (WAKE_PHY | WAKE_ARP | WAKE_MAGICSECURE |
> > + WAKE_FILTER))
> > return -EOPNOTSUPP;
> >
> > if (ixgbe_wol_exclusion(adapter, wol))
...and here.
Michal Kubecek
^ permalink raw reply
* Re: [RFC PATCH 12/12] soc: qcom: ipa: build and "ipa_i.h"
From: Alex Elder @ 2018-11-08 16:22 UTC (permalink / raw)
To: Randy Dunlap, davem, arnd, bjorn.andersson, ilias.apalodimas
Cc: netdev, devicetree, linux-arm-msm, linux-soc, linux-arm-kernel,
linux-kernel, syadagir, mjavid, robh+dt, mark.rutland
In-Reply-To: <cebe0d3c-4a24-60a4-88c8-5195a5d0da4b@infradead.org>
On 11/6/18 6:40 PM, Randy Dunlap wrote:
> Hi-
Thanks Randy, I've fixed this in my own tree. -Alex
>
> On 11/6/18 4:32 PM, Alex Elder wrote:
>> diff --git a/drivers/net/ipa/Kconfig b/drivers/net/ipa/Kconfig
>> new file mode 100644
>> index 000000000000..f8ea9363f532
>> --- /dev/null
>> +++ b/drivers/net/ipa/Kconfig
>> @@ -0,0 +1,30 @@
>> +config IPA
>> + tristate "Qualcomm IPA support"
>> + depends on NET
>> + select QCOM_QMI_HELPERS
>> + select QCOM_MDT_LOADER
>> + default n
>> + help
>> + Choose Y here to include support for the Qualcomm IP
>> + Accelerator (IPA), a hardware block present in some
>> + Qualcomm SoCs. The IPA is a programmable protocol
>> + processor that is capable of generic hardware handling
>> + of IP packets, including routing, filtering, and NAT.
>> + Currently the IPA driver supports only basic transport
>> + of network traffic between the AP and modem, on the
>> + Qualcomm SDM845 SoC.
>> +
>> + If unsure, say N.
>> +
>> +config IPA_ASSERT
>> + bool "Enable IPA assertions"
>> + depends on IPA
>> + default y
>> + help
>> + Incorporate IPA assertion verification in the build. This
>> + cause various design assumptions to be checked at runtime,
>
> causes
>
>> + generating a report (and a crash) if any assumed condition
>> + does not hold. You may wish to disable this to avoid the
>> + overhead of checking.
>> +
>> + If unsure doubt, say "Y" here.
>
>
^ permalink raw reply
* Re: [PATCH net-next] sfc: add missing NVRAM partition types for EF10
From: David Miller @ 2018-11-08 6:58 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, netdev
In-Reply-To: <690d4b01-c19d-e8ec-7fb6-f293bf6dd278@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Wed, 7 Nov 2018 18:12:42 +0000
> Expose the MUM/SUC Firmware, UEFI Expansion ROM and MC Status partitions
> of the NIC's NVRAM as MTDs if found on the NIC. The first two are needed
> in order to properly update them when performing firmware updates; the MC
> Status partition is used to determine whether a signed firmware image was
> accepted or rejected by a Secure NIC.
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied, thanks.
^ permalink raw reply
* [PATCH][net-next][v2] net/ipv6: compute anycast address hash only if dev is null
From: Li RongQing @ 2018-11-08 6:58 UTC (permalink / raw)
To: netdev
avoid to compute the hash value if dev is not null, since
hash value is not used
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/ipv6/anycast.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 94999058e110..cca3b3603c42 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -433,7 +433,6 @@ static bool ipv6_chk_acast_dev(struct net_device *dev, const struct in6_addr *ad
bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
const struct in6_addr *addr)
{
- unsigned int hash = inet6_acaddr_hash(net, addr);
struct net_device *nh_dev;
struct ifacaddr6 *aca;
bool found = false;
@@ -441,7 +440,9 @@ bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
rcu_read_lock();
if (dev)
found = ipv6_chk_acast_dev(dev, addr);
- else
+ else {
+ unsigned int hash = inet6_acaddr_hash(net, addr);
+
hlist_for_each_entry_rcu(aca, &inet6_acaddr_lst[hash],
aca_addr_lst) {
nh_dev = fib6_info_nh_dev(aca->aca_rt);
@@ -452,6 +453,7 @@ bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
break;
}
}
+ }
rcu_read_unlock();
return found;
}
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net-next 0/3] nfp: add and use tunnel netdev helpers
From: David Miller @ 2018-11-08 7:00 UTC (permalink / raw)
To: john.hurley; +Cc: netdev, oss-drivers, jakub.kicinski
In-Reply-To: <1541615570-523-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Wed, 7 Nov 2018 18:32:47 +0000
> A recent patch introduced the function netif_is_vxlan() to verify the
> tunnel type of a given netdev as vxlan.
>
> Add a similar function to detect geneve netdevs and make use of this
> function in the NFP driver. Also make use of the vxlan helper where
> applicable.
Series applied.
^ permalink raw reply
* [PATCH 1/3] ath6kl: Only use match sets when firmware supports it
From: Kyle Roeschley @ 2018-11-08 16:36 UTC (permalink / raw)
To: Kalle Valo
Cc: David S . Miller, linux-wireless, netdev, linux-kernel,
Kyle Roeschley
Commit dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan")
merged the probed and matched SSID lists before sending them to the
firmware. In the process, it assumed match set support is always available
in ath6kl_set_probed_ssids, which breaks scans for hidden SSIDs. Now, check
that the firmware supports matching SSIDs in scheduled scans before setting
MATCH_SSID_FLAG.
Fixes: dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan")
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index e121187f371f..6c98d7903ffb 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -939,7 +939,7 @@ static int ath6kl_set_probed_ssids(struct ath6kl *ar,
else
ssid_list[i].flag = ANY_SSID_FLAG;
- if (n_match_ssid == 0)
+ if (ar->wiphy->max_match_sets != 0 && n_match_ssid == 0)
ssid_list[i].flag |= MATCH_SSID_FLAG;
}
--
2.19.1
^ permalink raw reply related
* [PATCH 2/3] ath6kl: Fix off by one error in scan completion
From: Kyle Roeschley @ 2018-11-08 16:36 UTC (permalink / raw)
To: Kalle Valo
Cc: David S . Miller, linux-wireless, netdev, linux-kernel,
Kyle Roeschley
In-Reply-To: <20181108163659.19535-1-kyle.roeschley@ni.com>
When ath6kl was reworked to share code between regular and scheduled scans
in commit 3b8ffc6a22ba ("ath6kl: Configure probed SSID list consistently"),
probed SSID entry changed from 1-index to 0-indexed. However,
ath6kl_cfg80211_scan_complete_event() was missed in that change. Fix its
indexing so that we correctly clear out the probed SSID list.
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 6c98d7903ffb..d7c626d9594e 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -1093,7 +1093,7 @@ void ath6kl_cfg80211_scan_complete_event(struct ath6kl_vif *vif, bool aborted)
if (vif->scan_req->n_ssids && vif->scan_req->ssids[0].ssid_len) {
for (i = 0; i < vif->scan_req->n_ssids; i++) {
ath6kl_wmi_probedssid_cmd(ar->wmi, vif->fw_vif_idx,
- i + 1, DISABLE_SSID_FLAG,
+ i, DISABLE_SSID_FLAG,
0, NULL);
}
}
--
2.19.1
^ permalink raw reply related
* Re: [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2018-11-07
From: David Miller @ 2018-11-08 7:07 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20181107224830.9737-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 7 Nov 2018 14:48:18 -0800
> This series contains updates to almost all of the Intel wired LAN
> drivers.
...
> The following are changes since commit 7c588c7468ea3f9b2fc8fa6840bed6262b5d1b00:
> Merge branch 'net-systemport-Unmap-queues-upon-DSA-unregister-event'
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 1GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: phy: improve and simplify phylib state machine
From: Heiner Kallweit @ 2018-11-08 7:20 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <67c3bafb-5b4b-c33e-fd84-4cc6919b4bcb@gmail.com>
On 07.11.2018 21:45, Heiner Kallweit wrote:
> On 07.11.2018 21:21, Andrew Lunn wrote:
>> On Wed, Nov 07, 2018 at 09:05:49PM +0100, Heiner Kallweit wrote:
>>> On 07.11.2018 20:48, Andrew Lunn wrote:
>>>> On Wed, Nov 07, 2018 at 08:41:52PM +0100, Heiner Kallweit wrote:
>>>>> This patch series is based on two axioms:
>>>>>
>>>>> - During autoneg a PHY always reports the link being down
>>>>
>>>> Hi Heiner
>>>>
>>>> I think that is a risky assumption to make.
>>>>
>>> I wasn't sure initially too (found no clear rule in 802.3 clause 22)
>>> and therefore asked around. Florian agrees to the assumption,
>>> see here: https://www.spinics.net/lists/netdev/msg519242.html
>>>
>>> If a PHY reports the link as up then every user would assume that
>>> data can be transferred. But that's not the case during aneg.
>>> Therefore reporting the link as up during aneg wouldn't make sense.
>>
>> Hi Heiner
>>
>> If auto-neg has already been completed once before, i can see a lazy
>> hardware designed not reporting link down, or at least, not until
>> auto-neg actually fails.
>>
> "aneg finished" flag means that the aneg parameters in the register set
> are valid. Once the link goes down that's not necessarily the case any
> longer. E.g. some PHYs have an "auto speed down" feature and reduce
> the speed to save power once they detect the link is down.
> Of course I can not rule out that there are broken designs (or as you
> stated more politely: lazy designs) out there. But in this case I assume
> we would see issues already. And we would have to think about whether we
> want to support such broken / lazy designs in phylib.
>
Had one more look at the changes to check what happens if "link up" and
"aneg done" are not in sync.
When link goes down the changes don't change current behavior. We just
check the "link up" bit.
When link goes up and aneg isn't finished yet, then we would report
"link is up" earlier to userspace than we do now. If userspace starts
some network activity based on the "link up" event then they may fail.
But it really would be a major flaw if a PHY signals "link up" whilst
it's not actually ready yet to transfer data.
In case of such a broken design we would have issues with the current
code already, at least if interrupts are used. The "link up" interrupt
would cause the state machine to go to PHY_CHANGELINK which doesn't
check for aneg status.
>> And what about if link is down for too short a time for us to notice?
>> I've seen some code fail because the kernel went off and did something
>> else for too long, and a state change was missed.
>>
> This is a case we have already, independent of my change.
> genphy_update_link() reads BMSR twice, thus ignoring potential latched
> info about a temporary link failure. When polling phylib ignores
> everything that happens between two poll intervals.
>
>>>> What happens if this assumption is incorrect?
>>>>
>>> Then we have to flush this patch series down the drain ;)
>>> At least I would have to check in detail which parts need to be
>>> changed. I clearly mention the assumptions so that every
>>> reviewer can check whether he agrees.
>>
>> Thanks for doing that. I want to be happy this is safe, and not going
>> to introduce regressions.
>>
>> Andrew
>>
>
^ permalink raw reply
* [RFC PATCH 0/3] acpi: Add acpi mdio support code
From: Wang Dongsheng @ 2018-11-08 7:21 UTC (permalink / raw)
To: andrew, timur
Cc: Wang Dongsheng, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <20181029124044.GB9174@lunn.ch>
Originally I just push "phy-handle" support for ACPI on the QCOM QDF2400
platform. After some discussion and following Andrew's advice, I send
out with a generic version of ACPI.
Current there is no clear documentation about MDIO/PHY for ACPI, so when
I reading some documents about ACPI [1], I think we just need to reuse the
DT binding in the ACPI.[2]. However, this series of patches are not
fully compatible with all contents specified in DT binding.
The most important thing about this iseries is link the phy device and
fwnode of acpi. Besides, we need to carry out bus scan at the mdio
register. Therefore, I am not compatible with more DT binding properties
in this series of patches. More support will be in the follow-up patches
support, or some people do the support.
Example:
Based on ACPI doc:
Documentation/acpi/dsd/data-node-references.txt
Documentation/acpi/dsd/graph.txt
With _DSD device properties we can finally do this:
Device (MDIO) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "ethernet-phy@0", PHY0 }, }
})
Name (PHY0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x0 }, }
})
}
Device (MACO) {
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
})
}
Tested: QDF2400 (ACPI), buildin/insmod/rmmod
[1]:
Documentation/acpi/dsd/data-node-references.txt
Documentation/acpi/dsd/graph.txt
[2]:
Documentation/devicetree/bindings/phy/phy-bindings.txt
https://lore.kernel.org/patchwork/patch/597296/
Wang Dongsheng (3):
acpi: Add acpi mdio support code
net: qcom/emac: split phy_config to mdio bus create and get phy device
net: qcom/emac: add phy-handle support for ACPI
drivers/acpi/Kconfig | 6 +
drivers/acpi/Makefile | 1 +
drivers/acpi/acpi_mdio.c | 167 ++++++++++++++++++
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 19 +-
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 142 ++++++++++-----
drivers/net/phy/mdio_bus.c | 3 +
include/linux/acpi_mdio.h | 82 +++++++++
7 files changed, 369 insertions(+), 51 deletions(-)
create mode 100644 drivers/acpi/acpi_mdio.c
create mode 100644 include/linux/acpi_mdio.h
--
2.18.0
^ permalink raw reply
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