* Re: [net-next PATCH] net: phy: mdio-mvusb: select MDIO_DEVRES in Kconfig
From: Andrew Lunn @ 2020-08-02 13:44 UTC (permalink / raw)
To: Bartosz Golaszewski, g
Cc: Florian Fainelli, Heiner Kallweit, Russell King, David S . Miller,
Jakub Kicinski, netdev, linux-kernel, Bartosz Golaszewski,
kernel test robot
In-Reply-To: <20200802074953.1529-1-brgl@bgdev.pl>
On Sun, Aug 02, 2020 at 09:49:53AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> PHYLIB is not selected by the mvusb driver but it uses mdio devres
> helpers. Explicitly select MDIO_DEVRES in this driver's Kconfig entry.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Fixes: 1814cff26739 ("net: phy: add a Kconfig option for mdio_devres")
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 1/2 v2 net-next] 8390: Miscellaneous cleanups
From: Andrew Lunn @ 2020-08-02 13:49 UTC (permalink / raw)
To: Armin Wolf; +Cc: Jakub Kicinski, netdev
In-Reply-To: <20200802131452.GA2321@mx-linux-amd>
> Did you apply patch 2/2 of the patchset?
> Because version-printing (and the need for a version string) was removed
> from lib8390.c in patch 2/2 to allow the replacement of said
> version-string with MODULE_* macros in 8390.c, and failing to do so whould result
> in the exact same error.
Hi Armin
We require that there be no break in buildability. The kernel must
always build. Otherwise git bisect becomes much more difficult to use.
Andrew
^ permalink raw reply
* [PATCH] net: sgi: ioc3-eth: Fix the size used in some 'dma_free_coherent()' calls
From: Christophe JAILLET @ 2020-08-02 13:52 UTC (permalink / raw)
To: ralf, davem, kuba, tbogendoerfer
Cc: linux-mips, netdev, linux-kernel, kernel-janitors,
Christophe JAILLET
Update the size used in 'dma_free_coherent()' in order to match the one
used in the corresponding 'dma_alloc_coherent()'.
Fixes: 369a782af0f1 ("net: sgi: ioc3-eth: ensure tx ring is 16k aligned.")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/ethernet/sgi/ioc3-eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sgi/ioc3-eth.c b/drivers/net/ethernet/sgi/ioc3-eth.c
index 6646eba9f57f..6eef0f45b133 100644
--- a/drivers/net/ethernet/sgi/ioc3-eth.c
+++ b/drivers/net/ethernet/sgi/ioc3-eth.c
@@ -951,7 +951,7 @@ static int ioc3eth_probe(struct platform_device *pdev)
dma_free_coherent(ip->dma_dev, RX_RING_SIZE, ip->rxr,
ip->rxr_dma);
if (ip->tx_ring)
- dma_free_coherent(ip->dma_dev, TX_RING_SIZE, ip->tx_ring,
+ dma_free_coherent(ip->dma_dev, TX_RING_SIZE + SZ_16K - 1, ip->tx_ring,
ip->txr_dma);
out_free:
free_netdev(dev);
@@ -964,7 +964,7 @@ static int ioc3eth_remove(struct platform_device *pdev)
struct ioc3_private *ip = netdev_priv(dev);
dma_free_coherent(ip->dma_dev, RX_RING_SIZE, ip->rxr, ip->rxr_dma);
- dma_free_coherent(ip->dma_dev, TX_RING_SIZE, ip->tx_ring, ip->txr_dma);
+ dma_free_coherent(ip->dma_dev, TX_RING_SIZE + SZ_16K - 1, ip->tx_ring, ip->txr_dma);
unregister_netdev(dev);
del_timer_sync(&ip->ioc3_timer);
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] net: spider_net: Fix the size used in a 'dma_free_coherent()' call
From: Christophe JAILLET @ 2020-08-02 13:53 UTC (permalink / raw)
To: kou.ishizaki, davem, kuba, linas
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
Update the size used in 'dma_free_coherent()' in order to match the one
used in the corresponding 'dma_alloc_coherent()', in
'spider_net_init_chain()'.
Fixes: d4ed8f8d1fb7 ("Spidernet DMA coalescing")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
NOT compile tested, because I don't have the configuration for that
---
drivers/net/ethernet/toshiba/spider_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/toshiba/spider_net.c b/drivers/net/ethernet/toshiba/spider_net.c
index 3902b3aeb0c2..2d61400144a2 100644
--- a/drivers/net/ethernet/toshiba/spider_net.c
+++ b/drivers/net/ethernet/toshiba/spider_net.c
@@ -283,8 +283,8 @@ spider_net_free_chain(struct spider_net_card *card,
descr = descr->next;
} while (descr != chain->ring);
- dma_free_coherent(&card->pdev->dev, chain->num_desc,
- chain->hwring, chain->dma_addr);
+ dma_free_coherent(&card->pdev->dev, chain->num_desc * sizeof(struct spider_net_hw_descr),
+ chain->hwring, chain->dma_addr);
}
/**
--
2.25.1
^ permalink raw reply related
* [PATCH 2/2] net: spider_net: Remove a useless memset
From: Christophe JAILLET @ 2020-08-02 13:53 UTC (permalink / raw)
To: kou.ishizaki, davem, kuba, linas
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
Avoid a memset after a call to 'dma_alloc_coherent()'.
This is useless since
commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
NOT compile tested, because I don't have the configuration for that
---
drivers/net/ethernet/toshiba/spider_net.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/spider_net.c b/drivers/net/ethernet/toshiba/spider_net.c
index 2d61400144a2..e1a2057fbf21 100644
--- a/drivers/net/ethernet/toshiba/spider_net.c
+++ b/drivers/net/ethernet/toshiba/spider_net.c
@@ -314,8 +314,6 @@ spider_net_init_chain(struct spider_net_card *card,
if (!chain->hwring)
return -ENOMEM;
- memset(chain->ring, 0, chain->num_desc * sizeof(struct spider_net_descr));
-
/* Set up the hardware pointers in each descriptor */
descr = chain->ring;
hwdescr = chain->hwring;
--
2.25.1
^ permalink raw reply related
* [PATCH] gve: Fix the size used in a 'dma_free_coherent()' call
From: Christophe JAILLET @ 2020-08-02 14:15 UTC (permalink / raw)
To: csully, sagis, jonolson, davem, kuba, lrizzo
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
Update the size used in 'dma_free_coherent()' in order to match the one
used in the corresponding 'dma_alloc_coherent()'.
Fixes: 893ce44df5 ("gve: Add basic driver framework for Compute Engine Virtual NIC")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/ethernet/google/gve/gve_adminq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/google/gve/gve_adminq.c b/drivers/net/ethernet/google/gve/gve_adminq.c
index c3ba7baf0107..883e173f5ca0 100644
--- a/drivers/net/ethernet/google/gve/gve_adminq.c
+++ b/drivers/net/ethernet/google/gve/gve_adminq.c
@@ -322,7 +322,7 @@ int gve_adminq_describe_device(struct gve_priv *priv)
priv->default_num_queues = be16_to_cpu(descriptor->default_num_queues);
free_device_descriptor:
- dma_free_coherent(&priv->pdev->dev, sizeof(*descriptor), descriptor,
+ dma_free_coherent(&priv->pdev->dev, PAGE_SIZE, descriptor,
descriptor_bus);
return err;
}
--
2.25.1
^ permalink raw reply related
* [PATCH] ieee802154/adf7242: check status of adf7242_read_reg
From: trix @ 2020-08-02 14:23 UTC (permalink / raw)
To: michael.hennerich, alex.aring, stefan, davem, kuba, marcel
Cc: linux-wpan, netdev, linux-kernel, Tom Rix
From: Tom Rix <trix@redhat.com>
Clang static analysis reports this error
adf7242.c:887:6: warning: Assigned value is garbage or undefined
len = len_u8;
^ ~~~~~~
len_u8 is set in
adf7242_read_reg(lp, 0, &len_u8);
When this call fails, len_u8 is not set.
So check the return code.
Fixes: 7302b9d90117 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154")
Signed-off-by: Tom Rix <trix@redhat.com>
---
drivers/net/ieee802154/adf7242.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index c11f32f644db..7db9cbd0f5de 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -882,7 +882,9 @@ static int adf7242_rx(struct adf7242_local *lp)
int ret;
u8 lqi, len_u8, *data;
- adf7242_read_reg(lp, 0, &len_u8);
+ ret = adf7242_read_reg(lp, 0, &len_u8);
+ if (ret)
+ return ret;
len = len_u8;
--
2.18.1
^ permalink raw reply related
* [BUG] net: rocker: accessing the data mapped to streaming DMA
From: Jia-Ju Bai @ 2020-08-02 14:26 UTC (permalink / raw)
To: jiri, davem, kuba; +Cc: netdev, linux-kernel
In rocker_dma_test_offset(), "buf" is mapped to streaming DMA on line 203:
dma_handle = pci_map_single(..., buf, ...);
Then, "buf" is accessed on line 229:
expect[i] = ~buf[i];
This access may cause data inconsistency between CPU cache and hardware.
I am not sure how to properly fix this problem, and thus I only report it.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH] net: add support for threaded NAPI polling
From: Sebastian Gottschall @ 2020-08-02 14:27 UTC (permalink / raw)
To: Eric Dumazet, Felix Fietkau, netdev; +Cc: Hillf Danton
In-Reply-To: <b88836ef-7db4-9cd5-a36f-e20855de0304@gmail.com>
Am 31.07.2020 um 18:36 schrieb Eric Dumazet:
>
> On 7/30/20 10:21 AM, Sebastian Gottschall wrote:
>> Am 30.07.2020 um 18:08 schrieb Eric Dumazet:
>>> On 7/30/20 7:30 AM, Sebastian Gottschall wrote:
>>>> Am 29.07.2020 um 19:44 schrieb Eric Dumazet:
>>>>> On 7/29/20 9:50 AM, Felix Fietkau wrote:
>>>>>> For some drivers (especially 802.11 drivers), doing a lot of work in the NAPI
>>>>>> poll function does not perform well. Since NAPI poll is bound to the CPU it
>>>>>> was scheduled from, we can easily end up with a few very busy CPUs spending
>>>>>> most of their time in softirq/ksoftirqd and some idle ones.
>>>>>>
>>>>>> Introduce threaded NAPI for such drivers based on a workqueue. The API is the
>>>>>> same except for using netif_threaded_napi_add instead of netif_napi_add.
>>>>>>
>>>>>> In my tests with mt76 on MT7621 using threaded NAPI + a thread for tx scheduling
>>>>>> improves LAN->WLAN bridging throughput by 10-50%. Throughput without threaded
>>>>>> NAPI is wildly inconsistent, depending on the CPU that runs the tx scheduling
>>>>>> thread.
>>>>>>
>>>>>> With threaded NAPI, throughput seems stable and consistent (and higher than
>>>>>> the best results I got without it).
>>>>>>
>>>>>> Based on a patch by Hillf Danton
>>>>>>
>>>>>> Cc: Hillf Danton <hdanton@sina.com>
>>>>>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>>>>>> ---
>>>>>> Changes since RFC v2:
>>>>>> - fix unused but set variable reported by kbuild test robot
>>>>>>
>>>>>> Changes since RFC:
>>>>>> - disable softirq around threaded poll functions
>>>>>> - reuse most parts of napi_poll()
>>>>>> - fix re-schedule condition
>>>>>>
>>>>>> include/linux/netdevice.h | 23 ++++++
>>>>>> net/core/dev.c | 162 ++++++++++++++++++++++++++------------
>>>>>> 2 files changed, 133 insertions(+), 52 deletions(-)
>>>>>>
>>>>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>>>>> index ac2cd3f49aba..3a39211c7598 100644
>>>>>> --- a/include/linux/netdevice.h
>>>>>> +++ b/include/linux/netdevice.h
>>>>>> @@ -347,6 +347,7 @@ struct napi_struct {
>>>>>> struct list_head dev_list;
>>>>>> struct hlist_node napi_hash_node;
>>>>>> unsigned int napi_id;
>>>>>> + struct work_struct work;
>>>>>> };
>>>>>> enum {
>>>>>> @@ -357,6 +358,7 @@ enum {
>>>>>> NAPI_STATE_HASHED, /* In NAPI hash (busy polling possible) */
>>>>>> NAPI_STATE_NO_BUSY_POLL,/* Do not add in napi_hash, no busy polling */
>>>>>> NAPI_STATE_IN_BUSY_POLL,/* sk_busy_loop() owns this NAPI */
>>>>>> + NAPI_STATE_THREADED, /* Use threaded NAPI */
>>>>>> };
>>>>>> enum {
>>>>>> @@ -367,6 +369,7 @@ enum {
>>>>>> NAPIF_STATE_HASHED = BIT(NAPI_STATE_HASHED),
>>>>>> NAPIF_STATE_NO_BUSY_POLL = BIT(NAPI_STATE_NO_BUSY_POLL),
>>>>>> NAPIF_STATE_IN_BUSY_POLL = BIT(NAPI_STATE_IN_BUSY_POLL),
>>>>>> + NAPIF_STATE_THREADED = BIT(NAPI_STATE_THREADED),
>>>>>> };
>>>>>> enum gro_result {
>>>>>> @@ -2315,6 +2318,26 @@ static inline void *netdev_priv(const struct net_device *dev)
>>>>>> void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>>>>>> int (*poll)(struct napi_struct *, int), int weight);
>>>>>> +/**
>>>>>> + * netif_threaded_napi_add - initialize a NAPI context
>>>>>> + * @dev: network device
>>>>>> + * @napi: NAPI context
>>>>>> + * @poll: polling function
>>>>>> + * @weight: default weight
>>>>>> + *
>>>>>> + * This variant of netif_napi_add() should be used from drivers using NAPI
>>>>>> + * with CPU intensive poll functions.
>>>>>> + * This will schedule polling from a high priority workqueue that
>>>>>> + */
>>>>>> +static inline void netif_threaded_napi_add(struct net_device *dev,
>>>>>> + struct napi_struct *napi,
>>>>>> + int (*poll)(struct napi_struct *, int),
>>>>>> + int weight)
>>>>>> +{
>>>>>> + set_bit(NAPI_STATE_THREADED, &napi->state);
>>>>>> + netif_napi_add(dev, napi, poll, weight);
>>>>>> +}
>>>>>> +
>>>>>> /**
>>>>>> * netif_tx_napi_add - initialize a NAPI context
>>>>>> * @dev: network device
>>>>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>>>>> index 19f1abc26fcd..11b027f3a2b9 100644
>>>>>> --- a/net/core/dev.c
>>>>>> +++ b/net/core/dev.c
>>>>>> @@ -158,6 +158,7 @@ static DEFINE_SPINLOCK(offload_lock);
>>>>>> struct list_head ptype_base[PTYPE_HASH_SIZE] __read_mostly;
>>>>>> struct list_head ptype_all __read_mostly; /* Taps */
>>>>>> static struct list_head offload_base __read_mostly;
>>>>>> +static struct workqueue_struct *napi_workq __read_mostly;
>>>>>> static int netif_rx_internal(struct sk_buff *skb);
>>>>>> static int call_netdevice_notifiers_info(unsigned long val,
>>>>>> @@ -6286,6 +6287,11 @@ void __napi_schedule(struct napi_struct *n)
>>>>>> {
>>>>>> unsigned long flags;
>>>>>> + if (test_bit(NAPI_STATE_THREADED, &n->state)) {
>>>>>> + queue_work(napi_workq, &n->work);
>>>>>> + return;
>>>>>> + }
>>>>>> +
>>>>> Where is the corresponding cancel_work_sync() or flush_work() at device dismantle ?
>>>>>
>>>>> Just hoping the thread will eventually run seems optimistic to me.
>>>>>
>>>>>
>>>>> Quite frankly, I do believe this STATE_THREADED status should be a generic NAPI attribute
>>>>> that can be changed dynamically, at admin request, instead of having to change/recompile
>>>>> a driver.
>>>> thats not that easy. wifi devices do use dummy netdev devices. they are not visible to sysfs and other administrative options.
>>>> so changing it would just be possible if a special mac80211 based control would be implemented for these drivers.
>>>> for standard netdev devices it isnt a big thing to implement a administrative control by sysfs (if you are talking about such a feature)
>>> We do not want to add code in fast path only for one device. We need something truly generic.
>>>
>>> I am not saying only the admin can chose, it is fine if a driver does not give the choice
>>> and will simply call netif_threaded_napi_add()
>> what could make sense if the feature can be disabled / enabled, but it will only affect drivers using the netif_threaded_napi_add call, but it should not affect drivers
>> using the old api in any way since not all drivers will work with this feature.
>
> If we provide something in core NAPI stack, we want to make sure we can test/use it with other drivers.
>
> ethtool, or a /sys/class/net/ethXXX entry could be used.
but this doesnt work for wifi drivers. since wifi drivers are using
dummy netdev devices. we are running in circles here
i mean a sane way could be also that dummy netdev devices are present in
sysfs too which is not the case right now.
so changing the api, so the driver is forced to set sane virtual dummy
netdev name (like the driver name for instance). so it can be accessed
by sysfs.
>
> The argument about not affecting other drivers is misleading, since the patch adds another conditional test in
> standard NAPI layer.
>
> Lets keep NAPI generic please.
>
> Lets make sure syzbot will find bugs without having to attach a specific mac80211 hardware.
the patch is not mac80211 specific. i tested it already with network
drivers. it is generic.
>
> Another concern I have with this patch is that we no longer can contain NIC processing is done
> on a selected set of cpus (as commanded in /proc/irq/XXX/smp_affinity).
> Or can we ?
i had this discussion already with felix in a phonecall last week.
kthread vs. workq. his oppinion is that workq works more effective than
kthread's
since kthreads required application support for good balancing like
irqbalance. personally i have no real oppinion here. the good point on
kthreads is
that i'm able to track the system load per thread with simple process
watching. and its possible to force the thread on a specific cpuset.
the good thing on workq is, its more simple to implement and usually
more risc free, even if i havent seen any problems with kthreads.
maybe felix should say something here about this. the background of this
patch is simply performance. especially on embedded devices.
it started with a ath10k patch which was introducing napi threading for
a specific chipset which leaded to some research on my side until i found
a historic napi kthread patch from 2016 which you have denied at that
time. i tested that patch and saw heavy performance boost for ath10k.
which leaded to this workq patch at the end
see also this discussion here. (you may remember this discussion since
you where involved in it)
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1142611.html
Sebastian
>
>
^ permalink raw reply
* Re: 答复: [PATCH] can current ECMP implementation support consistent hashing for next hop?
From: Ido Schimmel @ 2020-08-02 14:49 UTC (permalink / raw)
To: David Ahern
Cc: Yi Yang (杨燚)-云服务集团,
netdev@vger.kernel.org, nikolay@cumulusnetworks.com
In-Reply-To: <8da839b3-5b5d-b663-7d9c-0bc8351980dd@gmail.com>
On Thu, Jun 11, 2020 at 10:36:59PM -0600, David Ahern wrote:
> On 6/11/20 6:32 PM, Yi Yang (杨燚)-云服务集团 wrote:
> > David, thank you so much for confirming it can't, I did read your cumulus document before, resilient hashing is ok for next hop remove, but it still has the same issue there if add new next hop. I know most of kernel code in Cumulus Linux has been in upstream kernel, I'm wondering why you didn't push resilient hashing to upstream kernel.
> >
> > I think consistent hashing is must-have for a commercial load balancing solution, otherwise it is basically nonsense , do you Cumulus Linux have consistent hashing solution?
> >
> > Is "- replacing nexthop entries as LB's come and go" ithe stuff https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Equal-Cost-Multipath-Load-Sharing-Hardware-ECMP/#resilient-hashing is showing? It can't ensure the flow is distributed to the right backend server if a new next hop is added.
>
> I do not believe it is a problem to be solved in the kernel.
>
> If you follow the *intent* of the Cumulus document: what is the maximum
> number of load balancers you expect to have? 16? 32? 64? Define an ECMP
> route with that number of nexthops and fill in the weighting that meets
> your needs. When an LB is added or removed, you decide what the new set
> of paths is that maintains N-total paths with the distribution that
> meets your needs.
I recently started looking into consistent hashing and I wonder if it
can be done with the new nexthop API while keeping all the logic in user
space (e.g., FRR).
The only extension that might be required from the kernel is a new
nexthop attribute that indicates when a nexthop was last recently used.
User space can then use it to understand which nexthops to replace when
a new nexthop is added and when to perform the replacement. In case the
nexthops are offloaded, it is possible for the driver to periodically
update the nexthop code about their activity.
Below is a script that demonstrates the concept with the example in the
Cumulus documentation. I chose to replace the individual nexthops
instead of creating new ones and then replacing the group.
It is obviously possible to create larger groups to reduce the impact on
existing flows when a new nexthop is added.
WDYT?
```
#!/bin/bash
### Setup ####
IP="ip -n testns"
ip netns add testns
$IP link add name dummy_a up type dummy
$IP link add name dummy_b up type dummy
$IP link add name dummy_c up type dummy
$IP link add name dummy_d up type dummy
$IP link add name dummy_e up type dummy
$IP route add 1.1.1.0/24 dev dummy_a
$IP route add 2.2.2.0/24 dev dummy_b
$IP route add 3.3.3.0/24 dev dummy_c
$IP route add 4.4.4.0/24 dev dummy_d
$IP route add 5.5.5.0/24 dev dummy_e
### Initial nexthop configuration ####
# According to:
# https://docs.cumulusnetworks.com/cumulus-linux-42/Layer-3/Equal-Cost-Multipath-Load-Sharing-Hardware-ECMP/#resilient-hash-buckets
$IP nexthop replace id 1 via 1.1.1.1 dev dummy_a
$IP nexthop replace id 2 via 2.2.2.2 dev dummy_b
$IP nexthop replace id 3 via 3.3.3.3 dev dummy_c
$IP nexthop replace id 4 via 4.4.4.4 dev dummy_d
$IP nexthop replace id 5 via 1.1.1.1 dev dummy_a
$IP nexthop replace id 6 via 2.2.2.2 dev dummy_b
$IP nexthop replace id 7 via 3.3.3.3 dev dummy_c
$IP nexthop replace id 8 via 4.4.4.4 dev dummy_d
$IP nexthop replace id 9 via 1.1.1.1 dev dummy_a
$IP nexthop replace id 10 via 2.2.2.2 dev dummy_b
$IP nexthop replace id 11 via 3.3.3.3 dev dummy_c
$IP nexthop replace id 12 via 4.4.4.4 dev dummy_d
$IP nexthop replace id 10000 group 1/2/3/4/5/6/7/8/9/10/11/12
echo
echo "Initial state:"
echo
$IP nexthop show
### Nexthop B is removed ###
# According to:
# https://docs.cumulusnetworks.com/cumulus-linux-42/Layer-3/Equal-Cost-Multipath-Load-Sharing-Hardware-ECMP/#remove-next-hops
$IP nexthop replace id 2 via 1.1.1.1 dev dummy_a
$IP nexthop replace id 6 via 3.3.3.3 dev dummy_c
$IP nexthop replace id 10 via 4.4.4.4 dev dummy_d
echo
echo "After nexthop B was removed:"
echo
$IP nexthop show
### Initial state restored ####
$IP nexthop replace id 2 via 2.2.2.2 dev dummy_b
$IP nexthop replace id 6 via 2.2.2.2 dev dummy_b
$IP nexthop replace id 10 via 2.2.2.2 dev dummy_b
echo
echo "After intial state was restored:"
echo
$IP nexthop show
### Nexthop E is added ####
# According to:
# https://docs.cumulusnetworks.com/cumulus-linux-42/Layer-3/Equal-Cost-Multipath-Load-Sharing-Hardware-ECMP/#add-next-hops
# Nexthop 2, 5, 8 are active. Replace in a way that minimizes
# interruptions.
$IP nexthop replace id 1 via 2.2.2.2 dev dummy_b
$IP nexthop replace id 2 via 3.3.3.3 dev dummy_c
$IP nexthop replace id 3 via 4.4.4.4 dev dummy_d
$IP nexthop replace id 4 via 5.5.5.5 dev dummy_e
# Nexthop 5 remains the same
# Nexthop 6 remains the same
# Nexthop 7 remains the same
# Nexthop 8 remains the same
$IP nexthop replace id 9 via 5.5.5.5 dev dummy_e
$IP nexthop replace id 10 via 1.1.1.1 dev dummy_a
$IP nexthop replace id 11 via 2.2.2.2 dev dummy_b
$IP nexthop replace id 12 via 3.3.3.3 dev dummy_c
echo
echo "After nexthop E was added:"
echo
$IP nexthop show
ip netns del testns
```
>
> I just sent patches for active-backup nexthops that allows an automatic
> fallback when one is removed to address the redistribution problem, but
> it still requires userspace to decide what the active-backup pairs are
> as well as the maximum number of paths.
^ permalink raw reply
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
From: Tom Rix @ 2020-08-02 14:53 UTC (permalink / raw)
To: Borislav Petkov, Saheed O. Bolarinwa
Cc: helgaas, Kalle Valo, David S. Miller, Jakub Kicinski,
Wolfgang Grandegger, Marc Kleine-Budde, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, Joerg Roedel, bjorn,
skhan, linux-kernel-mentees, linux-pci, linux-kernel,
linux-wireless, netdev, linux-mtd, iommu, linux-rdma, linux-ide,
linux-i2c, linux-hwmon, dri-devel, intel-gfx, linux-gpio,
linux-fpga, linux-edac, dmaengine, linux-crypto,
linux-atm-general
In-Reply-To: <20200801125657.GA25391@nazgul.tnic>
On 8/1/20 5:56 AM, Borislav Petkov wrote:
> On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote:
>> The return value of pci_read_config_*() may not indicate a device error.
>> However, the value read by these functions is more likely to indicate
>> this kind of error. This presents two overlapping ways of reporting
>> errors and complicates error checking.
> So why isn't the *value check done in the pci_read_config_* functions
> instead of touching gazillion callers?
>
> For example, pci_conf{1,2}_read() could check whether the u32 *value it
> just read depending on the access method, whether that value is ~0 and
> return proper PCIBIOS_ error in that case.
>
> The check you're replicating
>
> if (val32 == (u32)~0)
>
> everywhere, instead, is just ugly and tests a naked value ~0 which
> doesn't mean anything...
>
I agree, if there is a change, it should be in the pci_read_* functions.
Anything returning void should not fail and likely future users of the proposed change will not do the extra checks.
Tom
^ permalink raw reply
* Re: [PATCH] rtlwifi: btcoex: remove redundant initialization of variables ant_num and single_ant_path
From: Kalle Valo @ 2020-08-02 14:54 UTC (permalink / raw)
To: Colin King
Cc: Ping-Ke Shih, David S . Miller, Jakub Kicinski, linux-wireless,
netdev, kernel-janitors, linux-kernel
In-Reply-To: <20200723163214.995226-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The variables ant_num and single_ant_path are being initialized with a
> value that is never read and are being updated later with a new value.
> The initializations are redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
56b06d4da812 rtlwifi: btcoex: remove redundant initialization of variables ant_num and single_ant_path
--
https://patchwork.kernel.org/patch/11681295/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: 11n_rxreorder: Remove unnecessary cast in kfree()
From: Kalle Valo @ 2020-08-02 14:56 UTC (permalink / raw)
To: Xu Wang
Cc: amitkarwar, ganapathi.bhat, huxinming820, davem, kuba,
linux-wireless, netdev, linux-kernel, Xu Wang
In-Reply-To: <20200727020405.8476-1-vulab@iscas.ac.cn>
Xu Wang <vulab@iscas.ac.cn> wrote:
> Remove unnecassary casts in the argument to kfree.
>
> Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
Patch applied to wireless-drivers-next.git, thanks.
614946480f8f mwifiex: 11n_rxreorder: Remove unnecessary cast in kfree()
--
https://patchwork.kernel.org/patch/11686265/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] p54: switch from 'pci_' to 'dma_' API
From: Kalle Valo @ 2020-08-02 14:57 UTC (permalink / raw)
To: Christophe JAILLET
Cc: chunkeey, davem, kuba, linux-wireless, netdev, linux-kernel,
kernel-janitors, Christophe JAILLET
In-Reply-To: <20200722102707.27486-1-christophe.jaillet@wanadoo.fr>
Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote:
> The wrappers in include/linux/pci-dma-compat.h should go away.
>
> The patch has been generated with the coccinelle script below and has been
> hand modified to replace GFP_ with a correct flag.
> It has been compile tested.
>
> When memory is allocated in 'p54p_probe()', GFP_KERNEL can be used because
> it is the probe function and no spin_lock is taken in the between.
>
>
> @@
> @@
> - PCI_DMA_BIDIRECTIONAL
> + DMA_BIDIRECTIONAL
>
> @@
> @@
> - PCI_DMA_TODEVICE
> + DMA_TO_DEVICE
>
> @@
> @@
> - PCI_DMA_FROMDEVICE
> + DMA_FROM_DEVICE
>
> @@
> @@
> - PCI_DMA_NONE
> + DMA_NONE
>
> @@
> expression e1, e2, e3;
> @@
> - pci_alloc_consistent(e1, e2, e3)
> + dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
>
> @@
> expression e1, e2, e3;
> @@
> - pci_zalloc_consistent(e1, e2, e3)
> + dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_free_consistent(e1, e2, e3, e4)
> + dma_free_coherent(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_map_single(e1, e2, e3, e4)
> + dma_map_single(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_unmap_single(e1, e2, e3, e4)
> + dma_unmap_single(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4, e5;
> @@
> - pci_map_page(e1, e2, e3, e4, e5)
> + dma_map_page(&e1->dev, e2, e3, e4, e5)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_unmap_page(e1, e2, e3, e4)
> + dma_unmap_page(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_map_sg(e1, e2, e3, e4)
> + dma_map_sg(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_unmap_sg(e1, e2, e3, e4)
> + dma_unmap_sg(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
> + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_dma_sync_single_for_device(e1, e2, e3, e4)
> + dma_sync_single_for_device(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
> + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_dma_sync_sg_for_device(e1, e2, e3, e4)
> + dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2;
> @@
> - pci_dma_mapping_error(e1, e2)
> + dma_mapping_error(&e1->dev, e2)
>
> @@
> expression e1, e2;
> @@
> - pci_set_dma_mask(e1, e2)
> + dma_set_mask(&e1->dev, e2)
>
> @@
> expression e1, e2;
> @@
> - pci_set_consistent_dma_mask(e1, e2)
> + dma_set_coherent_mask(&e1->dev, e2)
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Patch applied to wireless-drivers-next.git, thanks.
ba78405ecaac p54: switch from 'pci_' to 'dma_' API
--
https://patchwork.kernel.org/patch/11678115/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: WARNING: refcount bug in do_enable_set
From: syzbot @ 2020-08-02 14:58 UTC (permalink / raw)
To: davem, hdanton, johan.hedberg, kuba, linux-bluetooth,
linux-kernel, marcel, netdev, syzkaller-bugs
In-Reply-To: <0000000000008b9e0705a38afe52@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: ac3a0c84 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1194935c900000
kernel config: https://syzkaller.appspot.com/x/.config?x=e59ee776d5aa8d55
dashboard link: https://syzkaller.appspot.com/bug?extid=2e9900a1e1b3c9c96a77
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10b7ddca900000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=126dcf6c900000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2e9900a1e1b3c9c96a77@syzkaller.appspotmail.com
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 1 PID: 2540 at lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 2540 Comm: kworker/1:8 Not tainted 5.8.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events do_enable_set
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1f0/0x31e lib/dump_stack.c:118
panic+0x264/0x7a0 kernel/panic.c:231
__warn+0x227/0x250 kernel/panic.c:600
report_bug+0x1b1/0x2e0 lib/bug.c:198
handle_bug+0x42/0x80 arch/x86/kernel/traps.c:235
exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:255
asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:540
RIP: 0010:refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28
Code: c7 8a af 14 89 31 c0 e8 b3 f2 a8 fd 0f 0b eb 85 e8 2a 32 d7 fd c6 05 a4 d9 eb 05 01 48 c7 c7 b6 af 14 89 31 c0 e8 95 f2 a8 fd <0f> 0b e9 64 ff ff ff e8 09 32 d7 fd c6 05 84 d9 eb 05 01 48 c7 c7
RSP: 0018:ffffc90007d27c48 EFLAGS: 00010246
RAX: adb9104953f59b00 RBX: 0000000000000003 RCX: ffff8880a02d0540
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 0000000000000003 R08: ffffffff815dd389 R09: ffffed1015d262c0
R10: ffffed1015d262c0 R11: 0000000000000000 R12: dffffc0000000000
R13: ffff8880a0259118 R14: dffffc0000000000 R15: ffff8880ae9350c0
do_enable_set+0x66e/0x900 net/bluetooth/6lowpan.c:1083
process_one_work+0x789/0xfc0 kernel/workqueue.c:2269
worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415
kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [PATCH for v5.9] prism54: Replace HTTP links with HTTPS ones
From: Kalle Valo @ 2020-08-02 14:58 UTC (permalink / raw)
To: Alexander A. Klimov
Cc: mcgrof, davem, kuba, gustavoars, linux-wireless, netdev,
linux-kernel, Alexander A. Klimov
In-Reply-To: <20200719121224.58581-1-grandmaster@al2klimov.de>
"Alexander A. Klimov" <grandmaster@al2klimov.de> wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Patch applied to wireless-drivers-next.git, thanks.
87b589a19901 prism54: Replace HTTP links with HTTPS ones
--
https://patchwork.kernel.org/patch/11672435/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v1] prism54: islpci_hotplug: use generic power management
From: Kalle Valo @ 2020-08-02 14:59 UTC (permalink / raw)
To: Vaibhav Gupta
Cc: Bjorn Helgaas, Bjorn Helgaas, Bjorn Helgaas, Vaibhav Gupta,
David S. Miller, Jakub Kicinski, Luis Chamberlain, Vaibhav Gupta,
linux-kernel, linux-kernel-mentees, Shuah Khan, netdev,
linux-wireless
In-Reply-To: <20200721125514.145607-1-vaibhavgupta40@gmail.com>
Vaibhav Gupta <vaibhavgupta40@gmail.com> wrote:
> Drivers using legacy power management .suspen()/.resume() callbacks
> have to manage PCI states and device's PM states themselves. They also
> need to take care of standard configuration registers.
>
> Switch to generic power management framework using a single
> "struct dev_pm_ops" variable to take the unnecessary load from the driver.
> This also avoids the need for the driver to directly call most of the PCI
> helper functions and device power state control functions as through
> the generic framework, PCI Core takes care of the necessary operations,
> and drivers are required to do only device-specific jobs.
>
> Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
81cf72b74671 prism54: islpci_hotplug: use generic power management
--
https://patchwork.kernel.org/patch/11675653/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] prism54: switch from 'pci_' to 'dma_' API
From: Kalle Valo @ 2020-08-02 14:59 UTC (permalink / raw)
To: Christophe JAILLET
Cc: mcgrof, davem, kuba, linux-wireless, netdev, linux-kernel,
kernel-janitors, Christophe JAILLET
In-Reply-To: <20200722104534.30760-1-christophe.jaillet@wanadoo.fr>
Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote:
> The wrappers in include/linux/pci-dma-compat.h should go away.
>
> The patch has been generated with the coccinelle script below and has been
> hand modified to replace GFP_ with a correct flag.
> It has been compile tested.
>
> When memory is allocated in 'islpci_alloc_memory()' (islpci_dev.c),
> GFP_KERNEL can be used because it is only called from a probe function
> and no spin_lock is taken in the between.
>
> The call chain is:
> prism54_probe (probe function, in 'islpci_hotplug.c')
> --> islpci_setup (in 'islpci_dev.c')
> --> islpci_alloc_memory (in 'islpci_dev.c')
>
> @@
> @@
> - PCI_DMA_BIDIRECTIONAL
> + DMA_BIDIRECTIONAL
>
> @@
> @@
> - PCI_DMA_TODEVICE
> + DMA_TO_DEVICE
>
> @@
> @@
> - PCI_DMA_FROMDEVICE
> + DMA_FROM_DEVICE
>
> @@
> @@
> - PCI_DMA_NONE
> + DMA_NONE
>
> @@
> expression e1, e2, e3;
> @@
> - pci_alloc_consistent(e1, e2, e3)
> + dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
>
> @@
> expression e1, e2, e3;
> @@
> - pci_zalloc_consistent(e1, e2, e3)
> + dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_free_consistent(e1, e2, e3, e4)
> + dma_free_coherent(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_map_single(e1, e2, e3, e4)
> + dma_map_single(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_unmap_single(e1, e2, e3, e4)
> + dma_unmap_single(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4, e5;
> @@
> - pci_map_page(e1, e2, e3, e4, e5)
> + dma_map_page(&e1->dev, e2, e3, e4, e5)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_unmap_page(e1, e2, e3, e4)
> + dma_unmap_page(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_map_sg(e1, e2, e3, e4)
> + dma_map_sg(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_unmap_sg(e1, e2, e3, e4)
> + dma_unmap_sg(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
> + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_dma_sync_single_for_device(e1, e2, e3, e4)
> + dma_sync_single_for_device(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
> + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> - pci_dma_sync_sg_for_device(e1, e2, e3, e4)
> + dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2;
> @@
> - pci_dma_mapping_error(e1, e2)
> + dma_mapping_error(&e1->dev, e2)
>
> @@
> expression e1, e2;
> @@
> - pci_set_dma_mask(e1, e2)
> + dma_set_mask(&e1->dev, e2)
>
> @@
> expression e1, e2;
> @@
> - pci_set_consistent_dma_mask(e1, e2)
> + dma_set_coherent_mask(&e1->dev, e2)
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Patch applied to wireless-drivers-next.git, thanks.
84d47961a02c prism54: switch from 'pci_' to 'dma_' API
--
https://patchwork.kernel.org/patch/11678187/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC PATCH] iwlwifi: yoyo: don't print failure if debug firmware is missing
From: Kalle Valo @ 2020-08-02 15:08 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-wireless, Wolfram Sang, Johannes Berg, Emmanuel Grumbach,
Luca Coelho, Intel Linux Wireless, David S. Miller,
Jakub Kicinski, netdev, linux-kernel
In-Reply-To: <20200625165210.14904-1-wsa@kernel.org>
Wolfram Sang <wsa@kernel.org> wrote:
> Missing this firmware is not fatal, my wifi card still works. Even more,
> I couldn't find any documentation what it is or where to get it. So, I
> don't think the users should be notified if it is missing. If you browse
> the net, you see the message is present is in quite some logs. Better
> remove it.
>
> Signed-off-by: Wolfram Sang <wsa@kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
3f4600de8c93 iwlwifi: yoyo: don't print failure if debug firmware is missing
--
https://patchwork.kernel.org/patch/11625759/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mt7601u: add missing release on skb in mt7601u_mcu_msg_send
From: Kalle Valo @ 2020-08-02 15:11 UTC (permalink / raw)
To: Navid Emamdoost
Cc: Jakub Kicinski, David S. Miller, Matthias Brugger, linux-wireless,
netdev, linux-arm-kernel, linux-mediatek, linux-kernel, emamd001,
Navid Emamdoost
In-Reply-To: <20200718052630.11032-1-navid.emamdoost@gmail.com>
Navid Emamdoost <navid.emamdoost@gmail.com> wrote:
> In the implementation of mt7601u_mcu_msg_send(), skb is supposed to be
> consumed on all execution paths. Release skb before returning if
> test_bit() fails.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> Acked-by: Jakub Kicinski <kubakici@wp.pl>
Patch applied to wireless-drivers-next.git, thanks.
880e21490be6 mt7601u: add missing release on skb in mt7601u_mcu_msg_send
--
https://patchwork.kernel.org/patch/11671657/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 1/9] ptp: Add generic ptp v2 header parsing function
From: Richard Cochran @ 2020-08-02 15:13 UTC (permalink / raw)
To: Kurt Kanzenbach
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller,
Jakub Kicinski, Jiri Pirko, Ido Schimmel, Heiner Kallweit,
Russell King, Grygorii Strashko, Ivan Khoronzhuk, Samuel Zou,
netdev, Petr Machata, Russell King
In-Reply-To: <20200730080048.32553-2-kurt@linutronix.de>
On Thu, Jul 30, 2020 at 10:00:40AM +0200, Kurt Kanzenbach wrote:
> Reason: A lot of the ptp drivers - which implement hardware time stamping - need
> specific fields such as the sequence id from the ptp v2 header. Currently all
> drivers implement that themselves.
>
> Introduce a generic function to retrieve a pointer to the start of the ptp v2
> header.
>
> Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
Reviewed-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* Re: [PATCH v1] rt2x00: pci: use generic power management
From: Kalle Valo @ 2020-08-02 15:14 UTC (permalink / raw)
To: Vaibhav Gupta
Cc: Bjorn Helgaas, Bjorn Helgaas, Bjorn Helgaas, Vaibhav Gupta,
David S. Miller, Jakub Kicinski, Stanislaw Gruszka, Helmut Schaa,
Vaibhav Gupta, linux-wireless, netdev, linux-kernel,
linux-kernel-mentees, Shuah Khan
In-Reply-To: <20200717110928.454867-1-vaibhavgupta40@gmail.com>
Vaibhav Gupta <vaibhavgupta40@gmail.com> wrote:
> Drivers using legacy PM have to manage PCI states and device's PM states
> themselves. They also need to take care of configuration registers.
>
> With improved and powerful support of generic PM, PCI Core takes care of
> above mentioned, device-independent, jobs.
>
> The callbacks make use of PCI helper functions like
> pci_save/restore_state(), pci_enable/disable_device() and
> pci_set_power_state() to do required operations. In generic mode, they are
> no longer needed.
>
> Change function parameter in both .suspend() and .resume() to
> "struct device*" type. Use dev_get_drvdata() to get drv data.
>
> The .suspend() callback is invoking rt2x00lib_suspend() which needs to be
> modified as generic rt2x00pci_suspend() has no pm_message_t type argument,
> passed to it, which is required by it according to its declaration.
> Although this variable remained unused in the function body. Hence, remove
> it from the function definition & declaration.
>
> rt2x00lib_suspend() is also invoked by rt2x00usb_suspend() and
> rt2x00soc_suspend(). Thus, modify the functional call accordingly in their
> function body.
>
> Earlier, .suspend() & .resume() were exported and were used by the
> following drivers:
> - drivers/net/wireless/ralink/rt2x00/rt2400pci.c
> - drivers/net/wireless/ralink/rt2x00/rt2500pci.c
> - drivers/net/wireless/ralink/rt2x00/rt2800pci.c
> - drivers/net/wireless/ralink/rt2x00/rt61pci.c
>
> Now, we only need to bind "struct dev_pm_ops" variable to
> "struct pci_driver". Thus, make the callbacks static. Declare an
> "extern const struct dev_pm_ops" variable and bind PM callbacks to it. Now,
> export the variable instead and use it in respective drivers.
>
> Compile-tested only.
>
> Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
560a218d1ce6 rt2x00: pci: use generic power management
--
https://patchwork.kernel.org/patch/11669881/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ipw2x00: Replace HTTP links with HTTPS ones
From: Kalle Valo @ 2020-08-02 15:16 UTC (permalink / raw)
To: Alexander A. Klimov
Cc: stas.yakovlev, davem, kuba, corbet, linux-wireless, netdev,
linux-doc, linux-kernel, Alexander A. Klimov
In-Reply-To: <20200718100240.98593-1-grandmaster@al2klimov.de>
"Alexander A. Klimov" <grandmaster@al2klimov.de> wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Patch applied to wireless-drivers-next.git, thanks.
348cb5dc4d70 ipw2x00: Replace HTTP links with HTTPS ones
--
https://patchwork.kernel.org/patch/11671879/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH for v5.9] b43: Replace HTTP links with HTTPS ones
From: Kalle Valo @ 2020-08-02 15:16 UTC (permalink / raw)
To: Alexander A. Klimov
Cc: davem, kuba, saurav.girepunje, Larry.Finger, yanaijie, masahiroy,
linux-wireless, b43-dev, netdev, linux-kernel,
Alexander A. Klimov
In-Reply-To: <20200719110115.58085-1-grandmaster@al2klimov.de>
"Alexander A. Klimov" <grandmaster@al2klimov.de> wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Patch applied to wireless-drivers-next.git, thanks.
2d96c1ed4bab b43: Replace HTTP links with HTTPS ones
--
https://patchwork.kernel.org/patch/11672421/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH for v5.9] b43legacy: Replace HTTP links with HTTPS ones
From: Kalle Valo @ 2020-08-02 15:17 UTC (permalink / raw)
To: Alexander A. Klimov
Cc: Larry.Finger, davem, kuba, linux-wireless, b43-dev, netdev,
linux-kernel, Alexander A. Klimov
In-Reply-To: <20200719111124.58167-1-grandmaster@al2klimov.de>
"Alexander A. Klimov" <grandmaster@al2klimov.de> wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Patch applied to wireless-drivers-next.git, thanks.
140c6026167b b43legacy: Replace HTTP links with HTTPS ones
--
https://patchwork.kernel.org/patch/11672427/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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