* Re: [PATCH net 0/2] qed: iWARP - fix some syn related issues.
From: David Miller @ 2019-02-19 0:52 UTC (permalink / raw)
To: michal.kalderon; +Cc: ariel.elior, netdev, linux-rdma
In-Reply-To: <20190218132403.12487-1-michal.kalderon@marvell.com>
From: Michal Kalderon <michal.kalderon@marvell.com>
Date: Mon, 18 Feb 2019 15:24:01 +0200
> This series fixes two bugs related to iWARP syn processing flow.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Remove set but not used variable 'mfw_vn'
From: David Miller @ 2019-02-19 0:48 UTC (permalink / raw)
To: yuehaibing; +Cc: aelior, skalluru, GR-everest-linux-l2, netdev, kernel-janitors
In-Reply-To: <20190218121954.78928-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 18 Feb 2019 12:19:54 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function 'bnx2x_get_hwinfo':
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:11940:10: warning:
> variable 'mfw_vn' set but not used [-Wunused-but-set-variable]
>
> It's never used since introduction.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: phy: add helpers for handling C45 10GBT AN register values
From: David Miller @ 2019-02-19 0:44 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <c6be00e5-d4e5-69a1-cb9c-31cd446556be@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 16 Feb 2019 17:24:58 +0100
> Similar to the existing helpers for the Clause 22 registers add helpers
> to deal with converting Clause 45 advertisement registers to / from
> link mode bitmaps.
>
> Note that these helpers are defined in linux/mdio.h, not like the
> Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
> constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
> includes linux/mii.h before defining the C45 register constants.
>
> v2:
> - Remove few helpers which aren't used by this series. They will
> follow together with the users.
Series applied with fuzz on patch #1 :-)))))
^ permalink raw reply
* Re: [PATCH net-next] liquidio: using NULL instead of plain integer
From: David Miller @ 2019-02-19 0:42 UTC (permalink / raw)
To: yuehaibing; +Cc: dchickles, sburla, fmanlunas, linux-kernel, netdev
In-Reply-To: <20190216095310.22544-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 16 Feb 2019 17:53:10 +0800
> Fix following warning:
>
> drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c:1453:35: warning: Using plain integer as NULL pointer
> drivers/net/ethernet/cavium/liquidio/lio_main.c:2910:23: warning: Using plain integer as NULL pointer
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: remove unneeded mmiowb barriers
From: David Miller @ 2019-02-19 0:39 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <10883db9-493c-7434-2379-de79712cee85@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 16 Feb 2019 10:20:15 +0100
> writex() has implicit barriers, that's what makes it different from
> writex_relaxed(). Therefore these calls to mmiowb() can be removed.
>
> This patch was recently reverted due to a dependency with another
> problematic patch. But because it didn't contribute to the problem
> it was rebased and can be resubmitted.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] r8152: Add support for MAC address pass through on RTL8153-BD
From: David Miller @ 2019-02-19 0:38 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: <20190216091642.21388-1-david0813@gmail.com>
From: David Chen <david0813@gmail.com>
Date: Sat, 16 Feb 2019 17:16:42 +0800
> From: David Chen <david.chen7@dell.com>
>
> 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.
>
> Per confirming with Realtek all devices containing RTL8153-BD should
> activate MAC pass through and there won't use pass through bit on efuse
> like in RTL8153-AD.
>
> Signed-off-by: David Chen <david.chen7@dell.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] net: dsa: Implement flow_dissect callback for tag_dsa.
From: David Miller @ 2019-02-19 0:36 UTC (permalink / raw)
To: rdong.ge; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20190216083524.860-1-rdong.ge@gmail.com>
From: Rundong Ge <rdong.ge@gmail.com>
Date: Sat, 16 Feb 2019 08:35:24 +0000
> RPS not work for DSA devices since the 'skb_get_hash'
> will always get the invalid hash for dsa tagged packets.
>
> "[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
> introduced the flow_dissect callback to get the right hash for
> MTK tagged packet. Tag_dsa and tag_edsa also need to implement
> the callback.
>
> Signed-off-by: Rundong Ge <rdong.ge@gmail.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] net: sched: using kfree_rcu() to simplify the code
From: David Miller @ 2019-02-19 0:36 UTC (permalink / raw)
To: weiyongjun1; +Cc: jhs, xiyou.wangcong, jiri, netdev, kernel-janitors
In-Reply-To: <20190216081955.93243-1-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Sat, 16 Feb 2019 08:19:55 +0000
> The callback function of call_rcu() just calls a kfree(), so we
> can use kfree_rcu() instead of call_rcu() + callback function.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next] mdio_bus: Fix PTR_ERR() usage after initialization to constant
From: David Miller @ 2019-02-19 0:36 UTC (permalink / raw)
To: yuehaibing; +Cc: andrew, f.fainelli, hkallweit1, linux-kernel, netdev
In-Reply-To: <20190216025935.22888-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 16 Feb 2019 10:59:35 +0800
> Fix coccinelle warning:
>
> ./drivers/net/phy/mdio_bus.c:51:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
> ./drivers/net/phy/mdio_bus.c:52:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
>
> fix this by using IS_ERR before PTR_ERR
>
> Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> v2: remove variable 'ret'
Applied.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2019-02-19 0:30 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Eric Dumazet
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/tcp.c
between commit:
04c03114be82 ("tcp: clear icsk_backoff in tcp_write_queue_purge()")
from the net tree and commit:
3a9a57f63794 ("tcp: move snd_cwnd & snd_cwnd_cnt init to tcp_disconnect()")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/tcp.c
index cf3c5095c10e,cab6b2f2f61d..000000000000
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@@ -2577,9 -2595,11 +2596,10 @@@ int tcp_disconnect(struct sock *sk, in
tp->write_seq += tp->max_window + 2;
if (tp->write_seq == 0)
tp->write_seq = 1;
- tp->snd_cwnd = 2;
- icsk->icsk_backoff = 0;
icsk->icsk_probes_out = 0;
+ icsk->icsk_rto = TCP_TIMEOUT_INIT;
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
+ tp->snd_cwnd = TCP_INIT_CWND;
tp->snd_cwnd_cnt = 0;
tp->window_clamp = 0;
tp->delivered_ce = 0;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] mac80211: mesh: fix missing unlock on error in table_path_del()
From: David Miller @ 2019-02-19 0:30 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, herbert, weiyongjun1
In-Reply-To: <20190218102929.22276-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 18 Feb 2019 11:29:29 +0100
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> spin_lock_bh() is used in table_path_del() but rcu_read_unlock()
> is used for unlocking. Fix it by using spin_unlock_bh() instead
> of rcu_read_unlock() in the error handling case.
>
> Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> Dave, can you take this directly? I see little value in sending a
> pull request for this one patch (but if you prefer can do so.)
Applied, thanks Johannes.
^ permalink raw reply
* Re: [PATCH v2 1/2] net: phy: at803x: dont inline helpers
From: David Miller @ 2019-02-19 0:28 UTC (permalink / raw)
To: vkoul
Cc: linux-arm-msm, bjorn.andersson, netdev, niklas.cassel, andrew,
f.fainelli, nsekhar, peter.ujfalusi, marc.w.gonzalez
In-Reply-To: <20190218101853.4290-1-vkoul@kernel.org>
From: Vinod Koul <vkoul@kernel.org>
Date: Mon, 18 Feb 2019 15:48:52 +0530
> Some helpers were inlined, but makes more sense to allow compiler
> to do the right optiomazations instead, so remove inline for
> at803x_disable_rx_delay() and at803x_disable_tx_delay()
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Two problem with this patch series.
1) It fixes a bug in 'net' but the patches only apply cleanly to
'net-next'. Please respin this against 'net'.
2) This series lacks a header posting "[PATCH vX 0/N] " which
explains at a high level what the series is doing, how it is
doing it, and why it is doing it that way.
Thanks.
^ permalink raw reply
* Re: Possible bug into DSA2 code.
From: Andrew Lunn @ 2019-02-19 0:03 UTC (permalink / raw)
To: Rodolfo Giometti
Cc: Florian Fainelli, Vivien Didelot, David S. Miller, netdev
In-Reply-To: <f3fc92ec-606c-fc48-6482-a3015a82c72d@enneenne.com>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 54a5b660640a..bb46ebbb2bb8 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2399,7 +2399,7 @@ static int mv88e6xxx_setup(struct dsa_switch *ds)
> int i;
>
> chip->ds = ds;
> - ds->slave_mii_bus = mv88e6xxx_default_mdio_bus(chip);
> + ds->slave_mii_bus = NULL;
>
> mutex_lock(&chip->reg_lock);
>
> Is that right?
Hi Rodolfo
Humm, that needs testing. There are two used combinations you need to
test:
No MDIO node in device tree, e.g.
arch/arm/boot/dts/kirkwood-dir665.dts
MDIO node in device tree, e.g:
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
There is a third combination which will appear soon. There is only the
external mdio bus in device tree:
port@9 {
reg = <9>;
label = "eth_cu_1000_2";
phy-handle = <&phy9>;
phy-mode = "sgmii";
managed = "in-band-status";
};
};
mdio1 {
compatible = "marvell,mv88e6xxx-mdio-external";
#address-cells = <1>;
#size-cells = <0>;
phy9: phy9@0 {
compatible = "ethernet-phy-ieee802.3-c45";
pinctrl-0 = <&pinctrl_gpio_phy9>;
pinctrl-names = "default";
interrupt-parent = <&gpio2>;
interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
reg = <0>;
};
};
Here port 9 uses the external MDIO bus and all the other ports
implicitly make use of the internal MDIO bus.
Andrew
^ permalink raw reply
* Re: [RFC PATCH net-next v3 07/21] ethtool: implement EVENT notifications
From: Andrew Lunn @ 2019-02-18 23:46 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, David Miller, Jakub Kicinski, Jiri Pirko, linux-kernel
In-Reply-To: <c75c70d7b8f5e1b9a3ef6b83c2adaac2b113db31.1550513384.git.mkubecek@suse.cz>
On Mon, Feb 18, 2019 at 07:21:59PM +0100, Michal Kubecek wrote:
> Three types of netlink notifications are introduced:
>
> - ETHA_EVENT_NEWDEV to notify about newly registered network devices
> - ETHA_EVENT_DELDEV to notify about unregistered network devices
> - ETHA_EVENT_RENAMEDEV to notify about renamed network device
>
> The notifications are triggered by NETDEV_REGISTER, NETDEV_UNREGISTER and
> NETDEV_CHANGENAME notifiers.
>
> These notifications are intended for applications and daemons monitoring
> ethtool events to allow updating the list of existing devices without
> having to open another socket for rtnetlink.
Hi Michal
Does ETHA_EVENT_RENAMEDEV actually contain enough information to avoid
needing a rtnetlink lookup? If i understand the code correctly, all
you have is the new name. You don't know the old name?
Having said that, i don't see an easy way to get access to the old
name when handling the NETDEV_CHANGENAME.
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/8] net: thunderx: make CFG_DONE message to run through generic send-ack sequence
From: David Miller @ 2019-02-18 23:33 UTC (permalink / raw)
To: vlomovtsev
Cc: sgoutham, rric, linux-arm-kernel, netdev, linux-kernel, dnelson
In-Reply-To: <20190218095159.3847-4-vlomovtsev@marvell.com>
From: Vadim Lomovtsev <vlomovtsev@marvell.com>
Date: Mon, 18 Feb 2019 09:52:14 +0000
> @@ -169,6 +169,20 @@ static int nicvf_check_pf_ready(struct nicvf *nic)
> return 1;
> }
>
> +static int nicvf_send_cfg_done(struct nicvf *nic)
> +{
> + union nic_mbx mbx = {};
> +
> + mbx.msg.msg = NIC_MBOX_MSG_CFG_DONE;
> + if (nicvf_send_msg_to_pf(nic, &mbx)) {
> + netdev_err(nic->netdev,
> + "PF didn't respond to CFG DONE msg\n");
> + return 0;
> + }
> +
> + return 1;
> +}
...
> @@ -1515,8 +1528,7 @@ int nicvf_open(struct net_device *netdev)
> nicvf_enable_intr(nic, NICVF_INTR_RBDR, qidx);
>
> /* Send VF config done msg to PF */
> - mbx.msg.msg = NIC_MBOX_MSG_CFG_DONE;
> - nicvf_write_to_mbx(nic, &mbx);
> + nicvf_send_cfg_done(nic);
If the one and only call site doesn't even bother to check the return
value, just make it return void.
Thanks.
^ permalink raw reply
* Re: [PATCH bpf 1/2] bpf/test_run: fix unkillable BPF_PROG_TEST_RUN
From: Daniel Borkmann @ 2019-02-18 23:23 UTC (permalink / raw)
To: Stanislav Fomichev; +Cc: Stanislav Fomichev, netdev, davem, ast, syzbot
In-Reply-To: <20190218172934.GD20651@mini-arch>
On 02/18/2019 06:29 PM, Stanislav Fomichev wrote:
> On 02/16, Daniel Borkmann wrote:
>> On 02/13/2019 12:42 AM, Stanislav Fomichev wrote:
>>> Syzbot found out that running BPF_PROG_TEST_RUN with repeat=0xffffffff
>>> makes process unkillable. The problem is that when CONFIG_PREEMPT is
>>> enabled, we never see need_resched() return true. This is due to the
>>> fact that preempt_enable() (which we do in bpf_test_run_one on each
>>> iteration) now handles resched if it's needed.
>>>
>>> Let's disable preemption for the whole run, not per test. In this case
>>> we can properly see whether resched is needed.
>>> Let's also properly return -EINTR to the userspace in case of a signal
>>> interrupt.
>>>
>>> See recent discussion:
>>> http://lore.kernel.org/netdev/CAH3MdRWHr4N8jei8jxDppXjmw-Nw=puNDLbu1dQOFQHxfU2onA@mail.gmail.com
>>>
>>> I'll follow up with the same fix bpf_prog_test_run_flow_dissector in
>>> bpf-next.
>>>
>>> Reported-by: syzbot <syzkaller@googlegroups.com>
>>> Signed-off-by: Stanislav Fomichev <sdf@google.com>
>>> ---
>>> net/bpf/test_run.c | 45 ++++++++++++++++++++++++---------------------
>>> 1 file changed, 24 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
>>> index fa2644d276ef..e31e1b20f7f4 100644
>>> --- a/net/bpf/test_run.c
>>> +++ b/net/bpf/test_run.c
>>> @@ -13,27 +13,13 @@
>>> #include <net/sock.h>
>>> #include <net/tcp.h>
>>>
>>> -static __always_inline u32 bpf_test_run_one(struct bpf_prog *prog, void *ctx,
>>> - struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE])
>>> -{
>>> - u32 ret;
>>> -
>>> - preempt_disable();
>>> - rcu_read_lock();
>>> - bpf_cgroup_storage_set(storage);
>>> - ret = BPF_PROG_RUN(prog, ctx);
>>> - rcu_read_unlock();
>>> - preempt_enable();
>>> -
>>> - return ret;
>>> -}
>>> -
>>> -static int bpf_test_run(struct bpf_prog *prog, void *ctx, u32 repeat, u32 *ret,
>>> - u32 *time)
>>> +static int bpf_test_run(struct bpf_prog *prog, void *ctx, u32 repeat,
>>> + u32 *retval, u32 *time)
>>> {
>>> struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE] = { 0 };
>>> enum bpf_cgroup_storage_type stype;
>>> u64 time_start, time_spent = 0;
>>> + int ret = 0;
>>> u32 i;
>>>
>>> for_each_cgroup_storage_type(stype) {
>>> @@ -48,25 +34,42 @@ static int bpf_test_run(struct bpf_prog *prog, void *ctx, u32 repeat, u32 *ret,
>>>
>>> if (!repeat)
>>> repeat = 1;
>>> +
>>> + rcu_read_lock();
>>> + preempt_disable();
>>> time_start = ktime_get_ns();
>>> for (i = 0; i < repeat; i++) {
>>> - *ret = bpf_test_run_one(prog, ctx, storage);
>>> + bpf_cgroup_storage_set(storage);
>>> + *retval = BPF_PROG_RUN(prog, ctx);
>>> +
>>> + if (signal_pending(current)) {
>>> + ret = -EINTR;
>>> + break;
>>> + }
>>
>> Wouldn't it be enough to just move the signal_pending() test to
>> the above as you did to actually fix the unkillable issue? For
>> CONFIG_PREEMPT the below need_resched() is never triggered as you
>> mention as preempt_enable() handles rescheduling internally in
>> this situation, so moving it only out should suffice.
>>
>> The rationale for disabling preemption for the whole run is imho
>> a bit different, namely that you would not screw up the ktime
>> measurements due to rescheduling happening in between otherwise.
> That's exactly the reason why we need to preempt_disable() the whole
> run; we can't preempt on preempt_enable(), it would screw up our
> ktime estimation.
>
>> But then, once preemption is disabled for the whole run, is there
>> a need to move out the extra signal_pending() test (presumably as
>> need_resched() does not handle TIF_SIGPENDING but only TIF_NEED_RESCHED
>> but we still wouldn't get into a unkillable situation here, no)?
> I'm not sure, they look like two separate flags, it feels safer to handle
> them separately (and we have a precedent in do_check in verifier.c). While
> we do set them both when sending signal, it looks like need_resched is
> for the cases where we wake up a task with a higher priority. So, in
> theory, we can have a signal_pending without need_resched. (Also, with
> CONFIG_PREEMT=y kernel, there is another complication with
> preempt_count()).
Yeah, given there is no separation, it's better to move it out, agree.
Applied both, thanks!
>>> if (need_resched()) {
>>> - if (signal_pending(current))
>>> - break;
>>> time_spent += ktime_get_ns() - time_start;
>>> + preempt_enable();
>>> + rcu_read_unlock();
>>> +
>>> cond_resched();
>>> +
>>> + rcu_read_lock();
>>> + preempt_disable();
>>> time_start = ktime_get_ns();
>>> }
>>> }
>>> time_spent += ktime_get_ns() - time_start;
>>> + preempt_enable();
>>> + rcu_read_unlock();
>>> +
>>> do_div(time_spent, repeat);
>>> *time = time_spent > U32_MAX ? U32_MAX : (u32)time_spent;
>>>
>>> for_each_cgroup_storage_type(stype)
>>> bpf_cgroup_storage_free(storage[stype]);
>>>
>>> - return 0;
>>> + return ret;
>>> }
>>>
>>> static int bpf_test_finish(const union bpf_attr *kattr,
>>>
>>
^ permalink raw reply
* [PATCH 2/2] ipvs: fix warning on unused variable
From: Pablo Neira Ayuso @ 2019-02-18 23:08 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20190218230823.8114-1-pablo@netfilter.org>
From: Andrea Claudi <aclaudi@redhat.com>
When CONFIG_IP_VS_IPV6 is not defined, build produced this warning:
net/netfilter/ipvs/ip_vs_ctl.c:899:6: warning: unused variable ‘ret’ [-Wunused-variable]
int ret = 0;
^~~
Fix this by moving the declaration of 'ret' in the CONFIG_IP_VS_IPV6
section in the same function.
While at it, drop its unneeded initialisation.
Fixes: 098e13f5b21d ("ipvs: fix dependency on nf_defrag_ipv6")
Reported-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/ipvs/ip_vs_ctl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 86afacb07e5f..ac8d848d7624 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -896,12 +896,13 @@ ip_vs_new_dest(struct ip_vs_service *svc, struct ip_vs_dest_user_kern *udest,
{
struct ip_vs_dest *dest;
unsigned int atype, i;
- int ret = 0;
EnterFunction(2);
#ifdef CONFIG_IP_VS_IPV6
if (udest->af == AF_INET6) {
+ int ret;
+
atype = ipv6_addr_type(&udest->addr.in6);
if ((!(atype & IPV6_ADDR_UNICAST) ||
atype & IPV6_ADDR_LINKLOCAL) &&
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: do_csum: implement accelerated scalar version
From: Ard Biesheuvel @ 2019-02-18 23:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: will.deacon, steve.capper, ilias.apalodimas, netdev,
Ard Biesheuvel, huanglingyan (A)
It turns out that the IP checksumming code is still exercised often,
even though one might expect that modern NICs with checksum offload
have no use for it. However, as Lingyan points out, there are
combinations of features where the network stack may still fall back
to software checksumming, and so it makes sense to provide an
optimized implementation in software as well.
So provide an implementation of do_csum() in scalar assembler, which,
unlike C, gives direct access to the carry flag, making the code run
substantially faster. The routine uses overlapping 64 byte loads for
all input size > 64 bytes, in order to reduce the number of branches
and improve performance on cores with deep pipelines.
On Cortex-A57, this implementation is on par with Lingyan's NEON
implementation, and roughly 7x as fast as the generic C code.
Cc: "huanglingyan (A)" <huanglingyan2@huawei.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
Test code after the patch.
arch/arm64/include/asm/checksum.h | 3 +
arch/arm64/lib/Makefile | 2 +-
arch/arm64/lib/csum.S | 127 ++++++++++++++++++++
3 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/checksum.h b/arch/arm64/include/asm/checksum.h
index 0b6f5a7d4027..e906b956c1fc 100644
--- a/arch/arm64/include/asm/checksum.h
+++ b/arch/arm64/include/asm/checksum.h
@@ -46,6 +46,9 @@ static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
}
#define ip_fast_csum ip_fast_csum
+extern unsigned int do_csum(const unsigned char *buff, int len);
+#define do_csum do_csum
+
#include <asm-generic/checksum.h>
#endif /* __ASM_CHECKSUM_H */
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 5540a1638baf..a7606007a749 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -3,7 +3,7 @@ lib-y := clear_user.o delay.o copy_from_user.o \
copy_to_user.o copy_in_user.o copy_page.o \
clear_page.o memchr.o memcpy.o memmove.o memset.o \
memcmp.o strcmp.o strncmp.o strlen.o strnlen.o \
- strchr.o strrchr.o tishift.o
+ strchr.o strrchr.o tishift.o csum.o
ifeq ($(CONFIG_KERNEL_MODE_NEON), y)
obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
diff --git a/arch/arm64/lib/csum.S b/arch/arm64/lib/csum.S
new file mode 100644
index 000000000000..534e2ebdc426
--- /dev/null
+++ b/arch/arm64/lib/csum.S
@@ -0,0 +1,127 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Linaro, Ltd. <ard.biesheuvel@linaro.org>
+ */
+
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+
+ENTRY(do_csum)
+ adds x2, xzr, xzr // clear x2 and C flag
+
+ // 64 bytes at a time
+ lsr x3, x1, #6
+ and x1, x1, #63
+ cbz x3, 1f
+
+ // Eight 64-bit adds per iteration
+0: ldp x4, x5, [x0], #64
+ ldp x6, x7, [x0, #-48]
+ ldp x8, x9, [x0, #-32]
+ ldp x10, x11, [x0, #-16]
+ adcs x2, x2, x4
+ sub x3, x3, #1
+ adcs x2, x2, x5
+ adcs x2, x2, x6
+ adcs x2, x2, x7
+ adcs x2, x2, x8
+ adcs x2, x2, x9
+ adcs x2, x2, x10
+ adcs x2, x2, x11
+ cbnz x3, 0b
+ adc x2, x2, xzr
+
+ cbz x1, 7f
+ bic x3, x1, #1
+ add x12, x0, x1
+ add x0, x0, x3
+ neg x3, x3
+ add x3, x3, #64
+ lsl x3, x3, #3
+
+ // Handle remaining 63 bytes or less using an overlapping 64-byte load
+ // and a branchless code path to complete the calculation
+ ldp x4, x5, [x0, #-64]
+ ldp x6, x7, [x0, #-48]
+ ldp x8, x9, [x0, #-32]
+ ldp x10, x11, [x0, #-16]
+ ldrb w12, [x12, #-1]
+
+ .irp reg, x4, x5, x6, x7, x8, x9, x10, x11
+ cmp x3, #64
+ csel \reg, \reg, xzr, lt
+ ccmp x3, xzr, #0, lt
+ csel x13, x3, xzr, gt
+ sub x3, x3, #64
+CPU_LE( lsr \reg, \reg, x13 )
+CPU_BE( lsl \reg, \reg, x13 )
+ .endr
+
+ adds x2, x2, x4
+ adcs x2, x2, x5
+ adcs x2, x2, x6
+ adcs x2, x2, x7
+ adcs x2, x2, x8
+ adcs x2, x2, x9
+ adcs x2, x2, x10
+ adcs x2, x2, x11
+ adc x2, x2, xzr
+
+CPU_LE( adds x12, x2, x12 )
+CPU_BE( adds x12, x2, x12, lsl #8 )
+ adc x12, x12, xzr
+ tst x1, #1
+ csel x2, x2, x12, eq
+
+7: lsr x1, x2, #32
+ adds w2, w2, w1
+ adc w2, w2, wzr
+
+ lsr w1, w2, #16
+ uxth w2, w2
+ add w2, w2, w1
+
+ lsr w1, w2, #16 // handle the carry by hand
+ add w2, w2, w1
+
+ uxth w0, w2
+ ret
+
+ // Handle 63 bytes or less
+1: tbz x1, #5, 2f
+ ldp x4, x5, [x0], #32
+ ldp x6, x7, [x0, #-16]
+ adds x2, x2, x4
+ adcs x2, x2, x5
+ adcs x2, x2, x6
+ adcs x2, x2, x7
+ adc x2, x2, xzr
+
+2: tbz x1, #4, 3f
+ ldp x4, x5, [x0], #16
+ adds x2, x2, x4
+ adcs x2, x2, x5
+ adc x2, x2, xzr
+
+3: tbz x1, #3, 4f
+ ldr x4, [x0], #8
+ adds x2, x2, x4
+ adc x2, x2, xzr
+
+4: tbz x1, #2, 5f
+ ldr w4, [x0], #4
+ adds x2, x2, x4
+ adc x2, x2, xzr
+
+5: tbz x1, #1, 6f
+ ldrh w4, [x0], #2
+ adds x2, x2, x4
+ adc x2, x2, xzr
+
+6: tbz x1, #0, 7b
+ ldrb w4, [x0]
+CPU_LE( adds x2, x2, x4 )
+CPU_BE( adds x2, x2, x4, lsl #8 )
+ adc x2, x2, xzr
+ b 7b
+ENDPROC(do_csum)
--
2.20.1
diff --git a/lib/checksum.c b/lib/checksum.c
index d3ec93f9e5f3..7711f1186f71 100644
--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -37,7 +37,7 @@
#include <asm/byteorder.h>
-#ifndef do_csum
+#if 1 //ndef do_csum
static inline unsigned short from32to16(unsigned int x)
{
/* add up 16-bit and 16-bit for 16+c bit */
@@ -47,7 +47,7 @@ static inline unsigned short from32to16(unsigned int x)
return x;
}
-static unsigned int do_csum(const unsigned char *buff, int len)
+static unsigned int __do_csum(const unsigned char *buff, int len)
{
int odd;
unsigned int result = 0;
@@ -206,3 +206,23 @@ __wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
}
EXPORT_SYMBOL(csum_tcpudp_nofold);
#endif
+
+extern u8 crypto_ft_tab[];
+
+static int __init do_selftest(void)
+{
+ int i, j;
+ u16 c1, c2;
+
+ for (i = 0; i < 1024; i++) {
+ for (j = i + 1; j <= 1024; j++) {
+ c1 = __do_csum(crypto_ft_tab + i, j - i);
+ c2 = do_csum(crypto_ft_tab + i, j - i);
+
+ if (c1 != c2)
+ pr_err("######### %d %d %x %x\n", i, j, c1, c2);
+ }
+ }
+ return 0;
+}
+late_initcall(do_selftest);
^ permalink raw reply related
* [PATCH 1/2] netfilter: nf_tables: fix flush after rule deletion in the same batch
From: Pablo Neira Ayuso @ 2019-02-18 23:08 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20190218230823.8114-1-pablo@netfilter.org>
Flush after rule deletion bogusly hits -ENOENT. Skip rules that have
been already from nft_delrule_by_chain() which is always called from the
flush path.
Fixes: cf9dc09d0949 ("netfilter: nf_tables: fix missing rules flushing per table")
Reported-by: Phil Sutter <phil@nwl.cc>
Acked-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_tables_api.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 5a92f23f179f..4893f248dfdc 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -313,6 +313,9 @@ static int nft_delrule_by_chain(struct nft_ctx *ctx)
int err;
list_for_each_entry(rule, &ctx->chain->rules, list) {
+ if (!nft_is_active_next(ctx->net, rule))
+ continue;
+
err = nft_delrule(ctx, rule);
if (err < 0)
return err;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] Netfilter/IPVS fixes for net
From: Pablo Neira Ayuso @ 2019-02-18 23:08 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains Netfilter/IPVS fixes for net:
1) Follow up patch to fix a compilation warning in a recent IPVS fix:
098e13f5b21d ("ipvs: fix dependency on nf_defrag_ipv6").
2) Bogus ENOENT error on flush after rule deletion in the same batch,
reported by Phil Sutter.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Thanks!
----------------------------------------------------------------
The following changes since commit f9bcc9f3ee4fbbe8f11dfec76745476f5780517e:
net: ethernet: freescale: set FEC ethtool regs version (2019-02-14 12:45:35 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git HEAD
for you to fetch changes up to c93a49b9769e435990c82297aa0baa31e1538790:
ipvs: fix warning on unused variable (2019-02-16 10:41:42 +0100)
----------------------------------------------------------------
Andrea Claudi (1):
ipvs: fix warning on unused variable
Pablo Neira Ayuso (1):
netfilter: nf_tables: fix flush after rule deletion in the same batch
net/netfilter/ipvs/ip_vs_ctl.c | 3 ++-
net/netfilter/nf_tables_api.c | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH net v4.15..v4.19] net: dsa: Fix NPD checking for br_vlan_enabled()
From: Florian Fainelli @ 2019-02-18 22:30 UTC (permalink / raw)
To: netdev
Cc: davem, frank-w, Florian Fainelli, Andrew Lunn, Vivien Didelot,
open list
It is possible for the DSA slave network device not to be part of a
bridge, yet have an upper device like a VLAN device be part of a bridge.
When that VLAN device is enslaved, since it does not define any
switchdev_ops, we will recurse down to the lower/physical port device,
call switchdev_port_obj_add() with a VLAN, and here we will check
br_vlan_enabled() on a NULL dp->bridge_dev, thus causing a NULL pointer
de-reference.
This is no longer a problem upstream after commit d17d9f5e5143
("switchdev: Replace port obj add/del SDO with a notification").
Fixes: 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
Reported-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
David,
This affects v4.15..v4.19, but not v5.0-rc1 can you still queue this up
for -stable? Thanks!
net/dsa/port.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/dsa/port.c b/net/dsa/port.c
index ed0595459df1..792a13068c50 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,7 +255,7 @@ int dsa_port_vlan_add(struct dsa_port *dp,
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
+ if (dp->bridge_dev && br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
return 0;
@@ -273,7 +273,7 @@ int dsa_port_vlan_del(struct dsa_port *dp,
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
+ if (dp->bridge_dev && br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
return 0;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth
From: Vasily Khoruzhick @ 2019-02-18 22:28 UTC (permalink / raw)
To: Stefan Wahren
Cc: Rob Herring, Mark Rutland, devicetree, Johan Hedberg,
Maxime Ripard, netdev, Marcel Holtmann, linux-bluetooth,
Chen-Yu Tsai, David S. Miller, arm-linux, beagleboard
In-Reply-To: <1245842044.588056.1550527701604@email.ionos.de>
On Mon, Feb 18, 2019 at 2:08 PM Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
> Hi Vasily,
Hi Stefan,
> > Vasily Khoruzhick <anarsoul@gmail.com> hat am 18. Februar 2019 um 22:24 geschrieben:
> >
> >
> > 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
> > >
>
> sorry, i didn't noticed your great series before. David and i working at the same stuff but for the Asus Tinker Board.
>
> I created a similiar yet untested patch version for hci_h5 [1]. Maybe it's useful.
Looks good to me, but you may need to add firmware-postfix.
> Just a comment about the binding. It's really necessary to add the reset-gpio? Can't we use the enable-gpio with inverse polarity for this?
Yes, we can use enable-gpio instead of reset-gpio on pine64 and pinebook.
> Stefan
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth
From: Stefan Wahren @ 2019-02-18 22:10 UTC (permalink / raw)
To: Vasily Khoruzhick, Rob Herring
Cc: Mark Rutland, devicetree, Johan Hedberg, Maxime Ripard, netdev,
Marcel Holtmann, beagleboard, linux-bluetooth, Chen-Yu Tsai,
David S. Miller, arm-linux
In-Reply-To: <1245842044.588056.1550527701604@email.ionos.de>
> Stefan Wahren <stefan.wahren@i2se.com> hat am 18. Februar 2019 um 23:08 geschrieben:
>
>
> Hi Vasily,
>
> > Vasily Khoruzhick <anarsoul@gmail.com> hat am 18. Februar 2019 um 22:24 geschrieben:
> >
> >
> > 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
> > >
>
> sorry, i didn't noticed your great series before. David and i working at the same stuff but for the Asus Tinker Board.
>
> I created a similiar yet untested patch version for hci_h5 [1]. Maybe it's useful.
>
> Just a comment about the binding. It's really necessary to add the reset-gpio? Can't we use the enable-gpio with inverse polarity for this?
>
> Stefan
[1] - https://gist.github.com/lategoodbye/79bac99d4f1158a719a48ea3c45eb7f1
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth
From: Stefan Wahren @ 2019-02-18 22:08 UTC (permalink / raw)
To: Vasily Khoruzhick, Rob Herring
Cc: Mark Rutland, devicetree, Johan Hedberg, Maxime Ripard, netdev,
Marcel Holtmann, linux-bluetooth, Chen-Yu Tsai, David S. Miller,
arm-linux, beagleboard
In-Reply-To: <CA+E=qVdq5GORg-t-vVXM3zBxy3Aq93iCE+zmcGgLFBMcnTDgfw@mail.gmail.com>
Hi Vasily,
> Vasily Khoruzhick <anarsoul@gmail.com> hat am 18. Februar 2019 um 22:24 geschrieben:
>
>
> 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
> >
sorry, i didn't noticed your great series before. David and i working at the same stuff but for the Asus Tinker Board.
I created a similiar yet untested patch version for hci_h5 [1]. Maybe it's useful.
Just a comment about the binding. It's really necessary to add the reset-gpio? Can't we use the enable-gpio with inverse polarity for this?
Stefan
^ 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