* Re: [PATCH net 0/2] tcp: fix possible crash in tcp_v4_err()
From: David Miller @ 2019-02-18 19:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: edumazet, netdev, ncardwell, ycheng, soukjin.bae
In-Reply-To: <8e6280f3-ea5b-48bd-4dc0-da134d4125d2@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 17 Feb 2019 18:20:21 -0800
>
>
> On 02/17/2019 03:47 PM, David Miller wrote:
>> From: Eric Dumazet <edumazet@google.com>
>> Date: Fri, 15 Feb 2019 13:36:19 -0800
>>
>>> soukjin bae reported a crash in tcp_v4_err() that we
>>> root caused to a missing initialization.
>>>
>>> Second patch adds a sanity check in tcp_v4_err() to avoid
>>> future potential problems. Ignoring an ICMP message
>>> is probably better than crashing a machine.
>>
>> Series applied, thanks Eric.
>>
>> Want me to queue these up for -stable?
>>
>
> Yes please, I put no Fixes: tag because it seemed to be a day-0 bug.
Done.
^ permalink raw reply
* Re: [RFC PATCH net-next v3 02/21] ethtool: move to its own directory
From: Jakub Kicinski @ 2019-02-18 20:01 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, David Miller, Andrew Lunn, Jiri Pirko, linux-kernel
In-Reply-To: <2078f959ed3474c4228fd6016c892331f8e2c7b8.1550513384.git.mkubecek@suse.cz>
On Mon, 18 Feb 2019 19:21:34 +0100 (CET), Michal Kubecek wrote:
> The ethtool netlink interface is going to be split into multiple files so
> that it will be more convenient to put all of them in a separate directory
> net/ethtool. Start by moving current ethtool.c with ioctl interface into
> this directory and renaming it to ioct.c.
nit: s/ioct.c/ioctl.c/
^ permalink raw reply
* Re: [PATCH net v2] net: crypto set sk to NULL when af_alg_release.
From: David Miller @ 2019-02-18 20:02 UTC (permalink / raw)
To: maowenan; +Cc: netdev, xiyou.wangcong, linux-kernel
In-Reply-To: <20190218024444.137328-1-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Mon, 18 Feb 2019 10:44:44 +0800
> KASAN has found use-after-free in sockfs_setattr.
> The existed commit 6d8c50dcb029 ("socket: close race condition between sock_close()
> and sockfs_setattr()") is to fix this simillar issue, but it seems to ignore
> that crypto module forgets to set the sk to NULL after af_alg_release.
>
> KASAN report details as below:
> BUG: KASAN: use-after-free in sockfs_setattr+0x120/0x150
> Write of size 4 at addr ffff88837b956128 by task syz-executor0/4186
...
> Fixes: 6d8c50dcb029 ("socket: close race condition between sock_close() and sockfs_setattr()")
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: general protection fault in tc_ctl_chain
From: Cong Wang @ 2019-02-18 20:02 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs, Vlad Buslov
In-Reply-To: <0000000000006694750581ca4139@google.com>
(Cc'ing Vlad, please fix it)
On Wed, Feb 13, 2019 at 9:56 AM syzbot
<syzbot+eff9cae063e4b633c6c1@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: bd3606c29fcc rocker: Remove port_attr_bridge_flags_get ass..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=121bbf87400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=8572a6e4661225f4
> dashboard link: https://syzkaller.appspot.com/bug?extid=eff9cae063e4b633c6c1
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11cbd404c00000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fc80d4c00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+eff9cae063e4b633c6c1@syzkaller.appspotmail.com
>
> audit: type=1800 audit(1550028783.638:30): pid=7517 uid=0 auid=4294967295
> ses=4294967295 subj==unconfined op=collect_data cause=failed(directio)
> comm="startpar" name="rmnologin" dev="sda1" ino=2423 res=0
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 7669 Comm: syz-executor789 Not tainted 5.0.0-rc5+ #60
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__lock_acquire+0x8df/0x4700 kernel/locking/lockdep.c:3215
> Code: 28 00 00 00 0f 85 35 27 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
> 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
> 85 dc 27 00 00 49 81 3c 24 20 45 9a 89 0f 84 03 f8
> RSP: 0018:ffff88808b44f180 EFLAGS: 00010006
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000060
> RBP: ffff88808b44f350 R08: 0000000000000001 R09: 0000000000000001
> R10: ffff88808b44f570 R11: 0000000000000001 R12: 0000000000000060
> R13: 0000000000000000 R14: 0000000000000000 R15: ffff8880915d4680
> FS: 0000000001ef6880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020000080 CR3: 0000000093549000 CR4: 00000000001406f0
> Call Trace:
> lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841
> __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> __mutex_lock+0xf7/0x1310 kernel/locking/mutex.c:1072
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> tc_ctl_chain+0x42f/0x11a0 net/sched/cls_api.c:2812
> rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192
> netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485
> rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210
> netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
> netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
> netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xdd/0x130 net/socket.c:631
> ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> __do_sys_sendmsg net/socket.c:2183 [inline]
> __se_sys_sendmsg net/socket.c:2181 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4400d9
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ffd09281608 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004400d9
> RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401960
> R13: 00000000004019f0 R14: 0000000000000000 R15: 0000000000000000
> Modules linked in:
> ---[ end trace 25ab48d993ef9249 ]---
> RIP: 0010:__lock_acquire+0x8df/0x4700 kernel/locking/lockdep.c:3215
> Code: 28 00 00 00 0f 85 35 27 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
> 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
> 85 dc 27 00 00 49 81 3c 24 20 45 9a 89 0f 84 03 f8
> RSP: 0018:ffff88808b44f180 EFLAGS: 00010006
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000060
> RBP: ffff88808b44f350 R08: 0000000000000001 R09: 0000000000000001
> R10: ffff88808b44f570 R11: 0000000000000001 R12: 0000000000000060
> R13: 0000000000000000 R14: 0000000000000000 R15: ffff8880915d4680
> FS: 0000000001ef6880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020000080 CR3: 0000000093549000 CR4: 00000000001406f0
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH 2/2] RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through.
From: David Miller @ 2019-02-18 20:03 UTC (permalink / raw)
To: david0813
Cc: linux-usb, netdev, linux-kernel, hayeswang, mario.limonciello,
bigeasy, edumazet, jslaby, f.fainelli, david.chen7, kai.heng.feng,
zhongjiang
In-Reply-To: <20190218034817.7515-1-david0813@gmail.com>
Where is patch #1?
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: fix spelling mistake: "quiting" -> "quitting"
From: David Miller @ 2019-02-18 20:08 UTC (permalink / raw)
To: colin.king; +Cc: tariqt, netdev, linux-rdma, kernel-janitors, linux-kernel
In-Reply-To: <20190217230331.18678-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sun, 17 Feb 2019 23:03:31 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in a en_err error message. Fix it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks Colin.
And I agree that this doesn't really deserve a Fixes: tag.
Fixes: tags should really be for changes that introduce truly
functional bugs.
And that could even be applied in this case _iff_ the string
was essential in some way for userland tools which parse the
output or similar. But that is not the case here.
Anyways, thanks.
^ permalink raw reply
* [PATCH] net: netcp: Fix ethss driver probe issue
From: Murali Karicheri @ 2019-02-18 20:10 UTC (permalink / raw)
To: w-kwok2, davem, netdev, linux-kernel
Recent commit below has introduced a bug in netcp driver that causes
the ethss driver probe failure and thus break the networking function
on K2 SoCs such as K2HK, K2L, K2E etc. This patch fixes the issue to
restore networking on the above SoCs.
Fixes: 21c328dcecfc ("net: ethernet: Convert to using %pOFn instead of device_node.name")
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
Failure log: https://pastebin.ubuntu.com/p/cGCFZC4WkC/
With fix: https://pastebin.ubuntu.com/p/G9qYzXXNbw/
drivers/net/ethernet/ti/netcp_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 1f612268c998..d847f672a705 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -259,7 +259,7 @@ static int netcp_module_probe(struct netcp_device *netcp_device,
const char *name;
char node_name[32];
- if (of_property_read_string(node, "label", &name) < 0) {
+ if (of_property_read_string(child, "label", &name) < 0) {
snprintf(node_name, sizeof(node_name), "%pOFn", child);
name = node_name;
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] net: hamradio: remove unused hweight*() defines
From: David Miller @ 2019-02-18 20:10 UTC (permalink / raw)
To: yamada.masahiro; +Cc: netdev, linux-hams, t.sailer, linux-kernel
In-Reply-To: <1550471725-5575-1-git-send-email-yamada.masahiro@socionext.com>
From: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Mon, 18 Feb 2019 15:35:25 +0900
> This file does not use hweight*() at all, and the definition is
> surrounded by #if 0 ... #endif.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum: Change IP2ME CPU policer rate and burst size values
From: David Miller @ 2019-02-18 20:11 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, mlxsw, shalomt
In-Reply-To: <20190218071925.14727-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Mon, 18 Feb 2019 07:19:44 +0000
> From: Shalom Toledo <shalomt@mellanox.com>
>
> The IP2ME packet trap is triggered by packets hitting local routes.
> After evaluating current defaults used by the driver it was decided to
> reduce the amount of traffic generated by this trap to 1Kpps and
> increase the burst size. This is inline with similarly deployed systems.
>
> Signed-off-by: Shalom Toledo <shalomt@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] yellowfin: fix remove set but not used variable warning
From: David Miller @ 2019-02-18 20:13 UTC (permalink / raw)
To: yuehaibing; +Cc: yang.wei9, netdev, kernel-janitors
In-Reply-To: <20190218081546.189509-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 18 Feb 2019 08:15:46 +0000
> @@ -1050,8 +1050,11 @@ static int yellowfin_rx(struct net_device *dev)
> struct sk_buff *rx_skb = yp->rx_skbuff[entry];
> s16 frame_status;
> u16 desc_status;
> - int data_size, yf_size;
> + int data_size;
> u8 *buf_addr;
> +#ifdef YF_PROTOTYPE
> + int yf_size = sizeof(struct yellowfin_desc);
> +#endif
This is just silly.
Please move this variable declaration and initialization into the
YF_PROTOTYPE basic block in the code below it, like this:
#ifdef YF_PROTOTYPE /* Support for prototype hardware errata. */
} else if ((yp->flags & HasMACAddrBug) &&
int yf_size = sizeof(struct yellowfin_desc);
!ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
entry * yf_size),
dev->dev_addr) &&
!ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
entry * yf_size),
"\377\377\377\377\377\377")) {
if (bogus_rx++ == 0)
netdev_warn(dev, "Bad frame to %pM\n",
buf_addr);
#endif
Thanks.
^ permalink raw reply
* Re: [RFC PATCH net-next v3 04/21] ethtool: helper functions for netlink interface
From: Jakub Kicinski @ 2019-02-18 20:15 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, David Miller, Andrew Lunn, Jiri Pirko, linux-kernel
In-Reply-To: <266b4ea3596de134329f8bbd5d13e282d1d27442.1550513384.git.mkubecek@suse.cz>
On Mon, 18 Feb 2019 19:21:44 +0100 (CET), Michal Kubecek wrote:
> +/* create skb for a reply and fill device identification
> + * payload: payload length (without netlink and genetlink header)
> + * dev: device the reply is about (may be null)
> + * cmd: ETHNL_CMD_* command for reply
> + * info: info for the received packet we respond to
> + * ehdrp: place to store payload pointer returned by genlmsg_new()
> + * returns: skb or null on error
> + */
nit: why not correct kdoc?
> +struct sk_buff *ethnl_reply_init(size_t payload, struct net_device *dev, u8 cmd,
> + u16 dev_attrtype, struct genl_info *info,
> + void **ehdrp)
> +{
> + void *ehdr;
> + struct sk_buff *rskb;
nit: reverse xmas tree
^ permalink raw reply
* [PATCH net-next 0/4] net: phy: improve generic clause 45 aneg configuration
From: Heiner Kallweit @ 2019-02-18 20:18 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Improve generic clause 45 aneg configuration.
Heiner Kallweit (4):
net: phy: export genphy_config_eee_advert
net: phy: use genphy_config_eee_advert in genphy_c45_an_config_aneg
net: phy: add genphy_c45_check_and_restart_aneg
net: phy: marvell10g: use genphy_c45_check_and_restart_aneg in
mv3310_config_aneg
drivers/net/phy/marvell10g.c | 15 +--------------
drivers/net/phy/phy-c45.c | 34 +++++++++++++++++++++++++++++++++-
drivers/net/phy/phy_device.c | 3 ++-
include/linux/phy.h | 2 ++
4 files changed, 38 insertions(+), 16 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net-next 1/4] net: phy: export genphy_config_eee_advert
From: Heiner Kallweit @ 2019-02-18 20:26 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <35d86611-9a07-7239-3310-767d8d1050b5@gmail.com>
We want to use this function in phy-c45.c too, therefore export it.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 3 ++-
include/linux/phy.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 4bb3b6c28..49fdd1ee7 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1575,7 +1575,7 @@ static int genphy_config_advert(struct phy_device *phydev)
* efficent ethernet modes. Returns 0 if the PHY's advertisement hasn't
* changed, and 1 if it has changed.
*/
-static int genphy_config_eee_advert(struct phy_device *phydev)
+int genphy_config_eee_advert(struct phy_device *phydev)
{
int err;
@@ -1588,6 +1588,7 @@ static int genphy_config_eee_advert(struct phy_device *phydev)
/* If the call failed, we assume that EEE is not supported */
return err < 0 ? 0 : err;
}
+EXPORT_SYMBOL(genphy_config_eee_advert);
/**
* genphy_setup_forced - configures/forces speed/duplex from @phydev
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3db507e68..761131de4 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1077,6 +1077,7 @@ void phy_attached_info(struct phy_device *phydev);
int genphy_config_init(struct phy_device *phydev);
int genphy_setup_forced(struct phy_device *phydev);
int genphy_restart_aneg(struct phy_device *phydev);
+int genphy_config_eee_advert(struct phy_device *phydev);
int genphy_config_aneg(struct phy_device *phydev);
int genphy_aneg_done(struct phy_device *phydev);
int genphy_update_link(struct phy_device *phydev);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 2/4] net: phy: use genphy_config_eee_advert in genphy_c45_an_config_aneg
From: Heiner Kallweit @ 2019-02-18 20:27 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <35d86611-9a07-7239-3310-767d8d1050b5@gmail.com>
Like in genphy_config_aneg() for clause 22 PHY's, we should keep modes
from being advertised that are known to be broken with EEE.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-c45.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index 16636d49b..2f5721430 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -89,12 +89,14 @@ EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
*/
int genphy_c45_an_config_aneg(struct phy_device *phydev)
{
- int changed = 0, ret;
+ int changed, ret;
u32 adv;
linkmode_and(phydev->advertising, phydev->advertising,
phydev->supported);
+ changed = genphy_config_eee_advert(phydev);
+
adv = linkmode_adv_to_mii_adv_t(phydev->advertising);
ret = phy_modify_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE,
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 3/4] net: phy: add genphy_c45_check_and_restart_aneg
From: Heiner Kallweit @ 2019-02-18 20:27 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <35d86611-9a07-7239-3310-767d8d1050b5@gmail.com>
This function will be used by config_aneg callback implementations of
PHY drivers and allows to reduce boilerplate code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-c45.c | 30 ++++++++++++++++++++++++++++++
include/linux/phy.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index 2f5721430..fc3173cc0 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -156,6 +156,36 @@ int genphy_c45_restart_aneg(struct phy_device *phydev)
}
EXPORT_SYMBOL_GPL(genphy_c45_restart_aneg);
+/**
+ * genphy_c45_check_and_restart_aneg - Enable and restart auto-negotiation
+ * @phydev: target phy_device struct
+ * @restart: whether aneg restart is requested
+ *
+ * This assumes that the auto-negotiation MMD is present.
+ *
+ * Check, and restart auto-negotiation if needed.
+ */
+int genphy_c45_check_and_restart_aneg(struct phy_device *phydev, bool restart)
+{
+ int ret = 0;
+
+ if (!restart) {
+ /* Configure and restart aneg if it wasn't set before */
+ ret = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1);
+ if (ret < 0)
+ return ret;
+
+ if (!(ret & MDIO_AN_CTRL1_ENABLE))
+ restart = true;
+ }
+
+ if (restart)
+ ret = genphy_c45_restart_aneg(phydev);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(genphy_c45_check_and_restart_aneg);
+
/**
* genphy_c45_aneg_done - return auto-negotiation complete status
* @phydev: target phy_device struct
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 761131de4..8e9fc5764 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1097,6 +1097,7 @@ int genphy_write_mmd_unsupported(struct phy_device *phdev, int devnum,
/* Clause 45 PHY */
int genphy_c45_restart_aneg(struct phy_device *phydev);
+int genphy_c45_check_and_restart_aneg(struct phy_device *phydev, bool restart);
int genphy_c45_aneg_done(struct phy_device *phydev);
int genphy_c45_read_link(struct phy_device *phydev);
int genphy_c45_read_lpa(struct phy_device *phydev);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 4/4] net: phy: marvell10g: use genphy_c45_check_and_restart_aneg in mv3310_config_aneg
From: Heiner Kallweit @ 2019-02-18 20:27 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <35d86611-9a07-7239-3310-767d8d1050b5@gmail.com>
Use new function genphy_c45_check_and_restart_aneg() to reduce
boilerplate code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/marvell10g.c | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 67066127b..8cbf35964 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -291,20 +291,7 @@ static int mv3310_config_aneg(struct phy_device *phydev)
if (ret > 0)
changed = true;
- if (!changed) {
- /* Configure and restart aneg if it wasn't set before */
- ret = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1);
- if (ret < 0)
- return ret;
-
- if (!(ret & MDIO_AN_CTRL1_ENABLE))
- changed = 1;
- }
-
- if (changed)
- ret = genphy_c45_restart_aneg(phydev);
-
- return ret;
+ return genphy_c45_check_and_restart_aneg(phydev, changed);
}
static int mv3310_aneg_done(struct phy_device *phydev)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 3/3] dt-bindings: can: rcar_canfd: Document r8a774a1 support
From: Rob Herring @ 2019-02-18 20:33 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Fabrizio Castro,
David S. Miller, Simon Horman, Magnus Damm, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-can, netdev, devicetree,
linux-renesas-soc, linux-clk
In-Reply-To: <1547736856-16539-4-git-send-email-fabrizio.castro@bp.renesas.com>
On Thu, 17 Jan 2019 14:54:16 +0000, Fabrizio Castro wrote:
> Document support for rcar_canfd on R8A774A1 SoC devices.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
> ---
> This patch depends on:
> https://patchwork.kernel.org/patch/10766781/
>
> Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH net-next] net: phy: improve definition of __ETHTOOL_LINK_MODE_MASK_NBITS
From: Heiner Kallweit @ 2019-02-18 20:43 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
The way to define __ETHTOOL_LINK_MODE_MASK_NBITS seems to be overly
complicated, go with a standard approach instead.
Whilst we're at it, move the comment to the right place.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/ethtool.h | 4 ----
include/uapi/linux/ethtool.h | 17 +++++++++--------
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 19a8de532..e6ebc9761 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -98,10 +98,6 @@ static inline u32 ethtool_rxfh_indir_default(u32 index, u32 n_rx_rings)
return index % n_rx_rings;
}
-/* number of link mode bits/ulongs handled internally by kernel */
-#define __ETHTOOL_LINK_MODE_MASK_NBITS \
- (__ETHTOOL_LINK_MODE_LAST + 1)
-
/* declare a link mode bitmap */
#define __ETHTOOL_DECLARE_LINK_MODE_MASK(name) \
DECLARE_BITMAP(name, __ETHTOOL_LINK_MODE_MASK_NBITS)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 17be76aeb..17128eed3 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1432,6 +1432,13 @@ enum ethtool_link_mode_bit_indices {
ETHTOOL_LINK_MODE_56000baseSR4_Full_BIT = 29,
ETHTOOL_LINK_MODE_56000baseLR4_Full_BIT = 30,
ETHTOOL_LINK_MODE_25000baseCR_Full_BIT = 31,
+
+ /* Last allowed bit for __ETHTOOL_LINK_MODE_LEGACY_MASK is bit
+ * 31. Please do NOT define any SUPPORTED_* or ADVERTISED_*
+ * macro for bits > 31. The only way to use indices > 31 is to
+ * use the new ETHTOOL_GLINKSETTINGS/ETHTOOL_SLINKSETTINGS API.
+ */
+
ETHTOOL_LINK_MODE_25000baseKR_Full_BIT = 32,
ETHTOOL_LINK_MODE_25000baseSR_Full_BIT = 33,
ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT = 34,
@@ -1454,14 +1461,8 @@ enum ethtool_link_mode_bit_indices {
ETHTOOL_LINK_MODE_FEC_RS_BIT = 50,
ETHTOOL_LINK_MODE_FEC_BASER_BIT = 51,
- /* Last allowed bit for __ETHTOOL_LINK_MODE_LEGACY_MASK is bit
- * 31. Please do NOT define any SUPPORTED_* or ADVERTISED_*
- * macro for bits > 31. The only way to use indices > 31 is to
- * use the new ETHTOOL_GLINKSETTINGS/ETHTOOL_SLINKSETTINGS API.
- */
-
- __ETHTOOL_LINK_MODE_LAST
- = ETHTOOL_LINK_MODE_FEC_BASER_BIT,
+ /* must be last entry */
+ __ETHTOOL_LINK_MODE_MASK_NBITS
};
#define __ETHTOOL_LINK_MODE_LEGACY_MASK(base_name) \
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next 09/12] net: sched: flower: handle concurrent tcf proto deletion
From: Cong Wang @ 2019-02-18 20:47 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller
In-Reply-To: <20190214074712.17846-10-vladbu@mellanox.com>
On Wed, Feb 13, 2019 at 11:47 PM Vlad Buslov <vladbu@mellanox.com> wrote:
>
> Without rtnl lock protection tcf proto can be deleted concurrently. Check
> tcf proto 'deleting' flag after taking tcf spinlock to verify that no
> concurrent deletion is in progress. Return EAGAIN error if concurrent
> deletion detected, which will cause caller to retry and possibly create new
> instance of tcf proto.
>
Please state the reason why you prefer retry over locking the whole
tp without retrying, that is why and how it is better?
Personally I always prefer non-retry logic, because it is very easy
to understand and justify its correctness.
As you prefer otherwise, please share your reasoning in changelog.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: don't use 10BaseT/half as default in genphy_read_status
From: Florian Fainelli @ 2019-02-18 21:08 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <f56cc2be-6a75-94be-598a-9478c462c092@gmail.com>
On 2/18/2019 11:29 AM, Heiner Kallweit wrote:
> If link partner and we can't agree on any mode, then it doesn't make
> sense to pretend we would have agreed on 10/half. Therefore set a
> proper default.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth
From: Rob Herring @ 2019-02-18 21:10 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: David S. Miller, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Marcel Holtmann, Johan Hedberg, netdev, devicetree,
linux-arm-kernel, linux-bluetooth
In-Reply-To: <20190118170232.16142-4-anarsoul@gmail.com>
On Fri, Jan 18, 2019 at 09:02:27AM -0800, Vasily Khoruzhick wrote:
> Add binding document for bluetooth part of RTL8723BS/RTL8723CS
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> .../bindings/net/rtl8723bs-bluetooth.txt | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
>
> diff --git a/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt b/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
> new file mode 100644
> index 000000000000..8357f242ae4c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
> @@ -0,0 +1,35 @@
> +RTL8723BS/RTL8723CS Bluetooth
> +---------------------
> +
> +RTL8723CS/RTL8723CS is WiFi + BT chip. WiFi part is connected over SDIO, while
> +BT is connected over serial. It speaks H5 protocol with few extra commands
> +to upload firmware and change module speed.
> +
> +Required properties:
> +
> + - compatible: should be one of the following:
> + * "realtek,rtl8723bs-bt"
> + * "realtek,rtl8723cs-bt"
> +Optional properties:
> +
> + - device-wake-gpios: GPIO specifier, used to wakeup the BT module (active high)
> + - enable-gpios: GPIO specifier, used to enable the BT module (active high)
> + - host-wake-gpios: GPIO specifier, used to wakeup the host processor (active high)
> + - firmware-postfix: firmware postfix to be used for firmware config
How is this used?
Rob
^ permalink raw reply
* Re: [PATCH][unix] missing barriers in some of unix_sock ->addr and ->path accesses
From: Sasha Levin @ 2019-02-18 21:14 UTC (permalink / raw)
To: Sasha Levin, Al Viro, netdev; +Cc: David Miller, stable, stable
In-Reply-To: <20190215200934.GM2217@ZenIV.linux.org.uk>
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: .+
The bot has tested the following trees: v4.20.10, v4.19.23, v4.14.101, v4.9.158, v4.4.174, v3.18.134.
v4.20.10: Build OK!
v4.19.23: Build OK!
v4.14.101: Failed to apply! Possible dependencies:
27204aaa9dc6 ("tcp: uniform the set up of sockets after successful connection")
3830d0771ef6 ("soc: qcom: Introduce QMI helpers")
64ac5f5977df ("tipc: refactor function filter_rcv()")
75da2163dbb6 ("tipc: introduce communication groups")
9b2c45d479d0 ("net: make getname() functions return length rather than use int* parameter")
9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder")
a3f8683bf7d5 ("->poll() methods should return __poll_t")
a50ff19d0658 ("of/platform: Generalize /reserved-memory handling")
a80ae5306a73 ("tipc: improve destination linked list")
ade994f4f6c8 ("net: annotate ->poll() instances")
d1de6d6c639b ("soc: qcom: Remote filesystem memory driver")
v4.9.158: Failed to apply! Possible dependencies:
13d3b1ebe287 ("bpf: Support for setting initial receive window")
27204aaa9dc6 ("tcp: uniform the set up of sockets after successful connection")
3007098494be ("cgroup: add support for eBPF programs")
3830d0771ef6 ("soc: qcom: Introduce QMI helpers")
40304b2a1567 ("bpf: BPF support for sock_ops")
526735ddc0ae ("net: fix AF_SMC related typo")
610236587600 ("bpf: Add new cgroup attach type to enable sock modifications")
8550f328f45d ("bpf: Support for per connection SYN/SYN-ACK RTOs")
8c9814b97002 ("net: convert unix_address.refcnt from atomic_t to refcount_t")
9872a4bde31b ("bpf: Add TCP connection BPF callbacks")
9b2c45d479d0 ("net: make getname() functions return length rather than use int* parameter")
9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder")
a3f8683bf7d5 ("->poll() methods should return __poll_t")
a50ff19d0658 ("of/platform: Generalize /reserved-memory handling")
ac7138746e14 ("smc: establish new socket family")
ade994f4f6c8 ("net: annotate ->poll() instances")
b2cd12574aa3 ("bpf: Refactor cgroups code in prep for new type")
cb5da847af44 ("tipc: set kern=0 in sk_alloc() during tipc_accept()")
cdfbabfb2f0c ("net: Work around lockdep limitation in sockets that use sockets")
d1de6d6c639b ("soc: qcom: Remote filesystem memory driver")
v4.4.174: Failed to apply! Possible dependencies:
35da60941e44 ("pstore/ram: add Device Tree bindings")
3830d0771ef6 ("soc: qcom: Introduce QMI helpers")
4420cfd3f51c ("staging: lustre: format properly all comment blocks for LNet core")
44a7185c2ae6 ("of/platform: Add common method to populate default bus")
4c3523623dc0 ("net: add driver for Netronome NFP4000/NFP6000 NIC VFs")
529182e204db ("ramoops: use DT reserved-memory bindings")
53692b1de419 ("sctp: Rename NETIF_F_SCTP_CSUM to NETIF_F_SCTP_CRC")
5fd88337d209 ("staging: lustre: fix all conditional comparison to zero in LNet layer")
8c9814b97002 ("net: convert unix_address.refcnt from atomic_t to refcount_t")
9b2c45d479d0 ("net: make getname() functions return length rather than use int* parameter")
9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder")
a188222b6ed2 ("net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK")
a50ff19d0658 ("of/platform: Generalize /reserved-memory handling")
d1de6d6c639b ("soc: qcom: Remote filesystem memory driver")
fc520f8b4fa3 ("of/platform: disable the of_platform_default_populate_init() for all the ppc boards")
v3.18.134: Failed to apply! Possible dependencies:
35da60941e44 ("pstore/ram: add Device Tree bindings")
3830d0771ef6 ("soc: qcom: Introduce QMI helpers")
43443ad692cf ("of/platform: add function to populate default bus")
44a7185c2ae6 ("of/platform: Add common method to populate default bus")
4b638df4c9d5 ("soc: qcom: Add Shared Memory Manager driver")
529182e204db ("ramoops: use DT reserved-memory bindings")
7ce75bb2c05e ("ARM: qcom: Add Subsystem Power Manager (SPM) driver")
7d0c8beea6b8 ("soc: qcom: Reorder SMEM/SMD configs")
8c9814b97002 ("net: convert unix_address.refcnt from atomic_t to refcount_t")
936f14cf4e67 ("soc: qcom: Driver for the Qualcomm RPM over SMD")
9b2c45d479d0 ("net: make getname() functions return length rather than use int* parameter")
9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder")
a50ff19d0658 ("of/platform: Generalize /reserved-memory handling")
d1de6d6c639b ("soc: qcom: Remote filesystem memory driver")
f2ab3298fb49 ("soc: qcom: Add Shared Memory Driver")
fc520f8b4fa3 ("of/platform: disable the of_platform_default_populate_init() for all the ppc boards")
How should we proceed with this patch?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth
From: Vasily Khoruzhick @ 2019-02-18 21:24 UTC (permalink / raw)
To: Rob Herring
Cc: David S. Miller, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Marcel Holtmann, Johan Hedberg, netdev, devicetree, arm-linux,
linux-bluetooth
In-Reply-To: <20190218211035.GA28145@bogus>
On Mon, Feb 18, 2019 at 1:10 PM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, Jan 18, 2019 at 09:02:27AM -0800, Vasily Khoruzhick wrote:
> > Add binding document for bluetooth part of RTL8723BS/RTL8723CS
> >
> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > ---
> > .../bindings/net/rtl8723bs-bluetooth.txt | 35 +++++++++++++++++++
> > 1 file changed, 35 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt b/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
> > new file mode 100644
> > index 000000000000..8357f242ae4c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
> > @@ -0,0 +1,35 @@
> > +RTL8723BS/RTL8723CS Bluetooth
> > +---------------------
> > +
> > +RTL8723CS/RTL8723CS is WiFi + BT chip. WiFi part is connected over SDIO, while
> > +BT is connected over serial. It speaks H5 protocol with few extra commands
> > +to upload firmware and change module speed.
> > +
> > +Required properties:
> > +
> > + - compatible: should be one of the following:
> > + * "realtek,rtl8723bs-bt"
> > + * "realtek,rtl8723cs-bt"
> > +Optional properties:
> > +
> > + - device-wake-gpios: GPIO specifier, used to wakeup the BT module (active high)
> > + - enable-gpios: GPIO specifier, used to enable the BT module (active high)
> > + - host-wake-gpios: GPIO specifier, used to wakeup the host processor (active high)
> > + - firmware-postfix: firmware postfix to be used for firmware config
>
> How is this used?
rtl8723bs-bt needs 2 firmware binaries -- one is actual firmware,
another is firmware config which is specific to the board. If
firmware-postfix is specified, driver appends it to the name of config
and requests board-specific config while loading firmware. I.e. if
'pine64' is specified as firmware-postfix driver will load
rtl8723bs_config-pine64.bin.
> Rob
>
^ permalink raw reply
* Re: [PATCH][unix] missing barriers in some of unix_sock ->addr and ->path accesses
From: Al Viro @ 2019-02-18 21:32 UTC (permalink / raw)
To: Sasha Levin; +Cc: netdev, David Miller, stable, stable
In-Reply-To: <20190218211434.05DF121773@mail.kernel.org>
On Mon, Feb 18, 2019 at 09:14:33PM +0000, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
Ugh... Should've removed Cc; stable from netdev posting; my apologies.
> How should we proceed with this patch?
Wait for it to get into davem's tree, for starters?
Sorry about that, again...
FWIW, further adventures in net/unix land:
unix_dgram_poll() contains
/* connection hasn't started yet? */
if (sk->sk_state == TCP_SYN_SENT)
return mask;
and nothing in there sets TCP_SYN_SENT state (not that it would've made
any sense of AF_UNIX).
unix_poll() contains
/* Connection-based need to check for termination and startup */
if ((sk->sk_type == SOCK_STREAM || sk->sk_type == SOCK_SEQPACKET) &&
sk->sk_state == TCP_CLOSE)
while it can only be called as ->poll of unix_stream_ops, which means
that sk->sk_type can't be anything other that SOCK_STREAM in there.
static void scan_children(struct sock *x, void (*func)(struct unix_sock *),
struct sk_buff_head *hitlist)
{
if (x->sk_state != TCP_LISTEN) {
scan_inflight(x, func, hitlist);
} else {
...
has no exclusion or barriers to deal with the store of TCP_LISTEN into
->sk_state inside unix_listen(). That one's potentially nasty - we won't
find SCM_RIGHTS already queued to embrios in x's queue until we notice
that x->sk_state == TCP_LISTEN, which can happen between two calls of
scan_children() in the same unix_gc() run. The race is narrow, but not
impossible, AFAICS. Reasonably easy to fix - lift locking the queue
out of scan_inflight(), grab the queue lock before checking if it's
a listener and have unix_listen() either grab the queue lock around the
assignment to ->sk_state, or pump it up and down before dropping
unix_state_lock() (at which point connect() might be able to find it, etc.)
Al, still digging through net/unix...
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Borislav Petkov @ 2019-02-18 21:49 UTC (permalink / raw)
To: Kalle Valo
Cc: Masahiro Yamada, Ingo Molnar, Thomas Gleixner, H . Peter Anvin,
x86, linux-wireless, Christoph Hellwig, David S. Miller, netdev,
linux-kernel, Lorenzo Bianconi, linux-mediatek, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <87pnrosy29.fsf@kamboji.qca.qualcomm.com>
On Mon, Feb 18, 2019 at 09:20:46PM +0200, Kalle Valo wrote:
> So Masahiro, could you hold your x86 patch for a while until the mt76
> patch will be in Linus' tree? That should not take more than two weeks,
> I think.
No hurry - I won't take it into the x86 now and queue it for 5.1 because
it is not something urgent or fixing a bug or so. It is a cleanup and as
such it can surely wait for 5.2, I'd say. Unless there are other aspects
which I'm not thinking of right now...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ 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