work based on further testing and suggestions from ivecera
>
> Fixes: a3b658cfb664 ("bonding: allow xfrm offload setup post-module-load")
> Reported-by: Ivan Vecera
> Suggested-by: Ivan Vecera
> Cc: Jay Vosburgh
> Cc: Veaceslav Falico
> Cc: Andy Gospodarek
>
On Sun, 22 Nov 2020 22:17:16 -0500
Jarod Wilson wrote:
> Have run into a case where bond_option_mode_set() gets called before
> hw_features has been filled in, and very bad things happen when
> netdev_change_features() then gets called, because the empty hw_features
> wipes out almost all feature
mrp_ring_state; /* MRP_RING_STATE */
> #endif
> } u;
> };
Acked-by: Ivan Vecera
On Fri, 30 Aug 2019 08:13:27 +0200
Jiri Pirko wrote:
> Thu, Aug 29, 2019 at 04:37:32PM CEST, and...@lunn.ch wrote:
> >> Wait, I believe there has been some misundestanding. Promisc mode
> >> is NOT about getting packets to the cpu. It's about setting hw
> >> filters in a way that no rx packet is
On Fri, 30 Aug 2019 08:36:24 +0200
Jiri Pirko wrote:
> Fri, Aug 30, 2019 at 08:02:33AM CEST, da...@davemloft.net wrote:
> >From: Jiri Pirko
> >Date: Fri, 30 Aug 2019 07:39:40 +0200
> >
> >> Because the "promisc mode" would gain another meaning. Now how the
> >> driver should guess which meanin
On Thu, 29 Aug 2019 15:15:43 +0200
Andrew Lunn wrote:
> The problem with this is, the driver only gets called when promisc
> goes from 0 to !0. So, the port is added to the bridge. Promisc goes
> 0->1, and the driver gets called. We can evaluate as you said above,
> and leave the port filtering f
On Thu, 29 Aug 2019 14:44:14 +0200
Horatiu Vultur wrote:
> When a port is added to a bridge, then the port gets in promisc mode.
> But in our case the HW has bridge capabilities so it is not required
> to set the port in promisc mode.
> But if someone else requires the port to be in promisc mode
--) {
> + status = be_cmd_link_status_query(adapter, NULL,
> &link_status,
> + 0);
> + if (status) {
> + test->flags |= ETH_TEST_FL_FAILED;
> + data[4] = -1;
> + break;
> + }
> +
> + if (link_status)
> + break;
> +
> + msleep_interruptible(500);
> }
> }
>
LGTM
Reviewed-by: Ivan Vecera
On Wed, 19 Jun 2019 13:52:31 +0200
Petr Oros wrote:
> Certain cards in conjunction with certain switches need a little more
> time for link setup that results in ethtool link test failure after
> offline test. Patch adds a loop that waits for a link setup finish.
>
> Signed-off-by: Petr Oros
M
Signed-off-by: Ivan Vecera
---
drivers/net/ethernet/emulex/benet/be_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c
b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 4c218341c51b..6e635debc7fd 100644
--- a/drive
- Stanislav Fomichev wrote:
> On 03/15, Ivan Vecera wrote:
> > On 15. 03. 19 21:08, Stanislav Fomichev wrote:
> > > On 03/15, Ivan Vecera wrote:
> > > > After some experiences I found that urandom_read does not need to be
> > > > linked statically
On 23.10.2018 20:03, David Miller wrote:
> From: Ivan Vecera
> Date: Tue, 23 Oct 2018 16:40:26 +0200
>
>> The mentioned commit needs to be reverted because we cannot pass
>> string allocated on stack to request_irq(). This function stores
>> uses this pointer for later
e(...); <- return value can be negative
...
if (len > 0) <- true here in this case
*ppos += len;
...
Fixes: b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file")
Signed-off-by: Ivan Vecera
---
fs/kernfs/file.c | 2 +-
1 file changed, 1 insertion
Hayes,
the firmware files should be sent to linux-firmw...@kernel.org
Ivan
On 12.9.2014 08:54, Hayes Wang wrote:
File: rtl_nic/rtl8168h-1.fw
Version: 0.0.1
File: rtl_nic/rtl8168h-2.fw
Version: 0.0.1
File: rtl_nic/rtl8107e-1.fw
Version: 0.0.1
File: rtl_nic/rtl8107e-2.fw
Version: 0.0.1
Signed-
On 10.9.2014 11:25, Hayes Wang wrote:
From: Ivan Vecera [mailto:ivec...@redhat.com]
Sent: Tuesday, September 09, 2014 8:19 PM
[...]
Thanks Hayes,
have you got any idea when do you update them?
If all are fine, I would release them this week.
Best Regards,
Hayes
Great, thanks Hayes
On 9.9.2014 07:50, Hayes Wang wrote:
From: Ivan Vecera [mailto:ivec...@redhat.com]
Sent: Monday, September 08, 2014 9:01 PM
To: Hau; net...@vger.kernel.org
Cc: nic_swsd; linux-kernel@vger.kernel.org; rom...@fr.zoreil.com
Subject: Re: [PATCH net-next v2] r8169:add support for
RTL8168H and
On 19.8.2014 19:54, Chun-Hao Lin wrote:
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 91652e7..c8375f6 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -52,6 +52,10 @@
#define FIRMWARE_8106E_2
On 01/19/2013 03:23 AM, Craig Hada wrote:
This patch sets the coherent DMA mask to 64-bit after the be2net driver
has been acknowledged that the system is 64-bit DMA capable. The coherent
DMA mask is examined by the Intel IOMMU driver to determine whether to
allow pass through context mapping for
On 03/29/2013 02:01 PM, Eric Dumazet wrote:
CPU0 will see rx_handler set and yet, rx_handler_data nulled. Write
>barrier in rcu_assign_pointer() might prevent this reorder from happening.
>Therefore I suggest:
>
>diff --git a/net/core/dev.c b/net/core/dev.c
>index 0caa38e..c16b829 100644
>--- a/n
On 09/28/2012 04:19 AM, David Miller wrote:
> From: Stephen Rothwell
> Date: Fri, 28 Sep 2012 11:43:35 +1000
>
>> Hi all,
>>
>> After merging the net-next tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> drivers/net/ethernet/emulex/benet/be_main.c: In function '
20 matches
Mail list logo
