> -Original Message-
> From: Intel-wired-lan On Behalf
> Of Stanislav Fomichev
> Sent: Tuesday, June 10, 2025 7:15 PM
> To: net...@vger.kernel.org
> Cc: da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; skall...@marvell.com; mani...@
> -Original Message-
> From: Intel-wired-lan On Behalf
> Of Stanislav Fomichev
> Sent: Monday, June 9, 2025 6:26 PM
> To: net...@vger.kernel.org
> Cc: da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; skall...@marvell.com; mani...@marv
> From: Brelinski, TonyX [mailto:tonyx.brelin...@intel.com]
> Sent: Tuesday, April 20, 2021 9:26 PM
>
> > From: Intel-wired-lan On Behalf Of
> > Salil Mehta
> > Sent: Tuesday, April 13, 2021 3:45 PM
> > To: da...@davemloft.net; k...@kernel.org
>
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Salil Mehta
> Sent: Tuesday, April 13, 2021 3:45 PM
> To: da...@davemloft.net; k...@kernel.org
> Cc: salil.me...@huawei.com; linux...@openeuler.org;
> net...@vger.kernel.org; linux...@huawei.com; linux-
>
>On 4/10/21 2:12 AM, Kubalewski, Arkadiusz wrote:
>>> -Original Message-
>>> From: Intel-wired-lan On Behalf Of
>>> xiao33...@qq.com
>>> Sent: piątek, 9 kwietnia 2021 11:18
>>> To: Brandeburg, Jesse ; Nguyen, Anthony L
>>>
>&
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>xiao33...@qq.com
>Sent: piątek, 9 kwietnia 2021 11:18
>To: Brandeburg, Jesse ; Nguyen, Anthony L
>
>Cc: net...@vger.kernel.org; xiaolinkui ;
>linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.or
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Colin King
> Sent: Wednesday, March 31, 2021 7:46 AM
> To: Brandeburg, Jesse ; Nguyen, Anthony L
> ; David S . Miller ;
> Jakub Kicinski ; Cao, Chinh T ;
> intel-wired-...@lists.osuosl.org; net...@vger
Hi Johan,
On 2021-04-05 19:03, Johan Jonker wrote:
>
> Hi Tianling,
>
> On 4/5/21 11:34 AM, Tianling Shen wrote:
> > From: David Bauer
> >
> > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > This is required for the USB3 attached LAN port to work
On Mon, Apr 5, 2021 at 7:03 PM Johan Jonker wrote:
>
> Hi Tianling,
>
> On 4/5/21 11:34 AM, Tianling Shen wrote:
> > From: David Bauer
> >
> > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > This is required for the USB3 attached LAN port to work
Hi Tianling,
On 4/5/21 11:34 AM, Tianling Shen wrote:
> From: David Bauer
>
> Enable the USB3 port on the FriendlyARM NanoPi R2S.
> This is required for the USB3 attached LAN port to work.
>
> Signed-off-by: David Bauer
> [added device node for USB Ethernet contro
From: David Bauer
Enable the USB3 port on the FriendlyARM NanoPi R2S.
This is required for the USB3 attached LAN port to work.
Signed-off-by: David Bauer
[added device node for USB Ethernet controller]
Signed-off-by: Tianling Shen
---
.../boot/dts/rockchip/rk3328-nanopi-r2s.dts | 32
; > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > > This is required for the USB3 attached LAN port to work.
> > >
> > > Signed-off-by: David Bauer
> > > Signed-off-by: Tianling Shen
> > > ---
> > > .../boot/dts/rockchip/rk3328-
Hi Chen-Yu,
On 2021-04-05 16:14, Chen-Yu Tsai wrote:
>
> Hi,
>
> On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen wrote:
> >
> > From: David Bauer
> >
> > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > This is required for the USB3 attached LAN
Hi,
On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen wrote:
>
> From: David Bauer
>
> Enable the USB3 port on the FriendlyARM NanoPi R2S.
> This is required for the USB3 attached LAN port to work.
>
> Signed-off-by: David Bauer
> Signed-off-by: Tianling Shen
> ---
>
From: David Bauer
Enable the USB3 port on the FriendlyARM NanoPi R2S.
This is required for the USB3 attached LAN port to work.
Signed-off-by: David Bauer
Signed-off-by: Tianling Shen
---
.../boot/dts/rockchip/rk3328-nanopi-r2s.dts | 23 +++
1 file changed, 23 insertions
On 3/17/21 15:10, Jann Horn wrote:
> On Wed, Mar 17, 2021 at 9:04 PM Gustavo A. R. Silva
> wrote:
>> On 3/17/21 13:57, Jann Horn wrote:
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
>> index 62ddb452f862..bff3dc
On 3/17/21 13:57, Jann Horn wrote:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 62ddb452f862..bff3dc1af702 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/in
On Wed, Mar 17, 2021 at 9:04 PM Gustavo A. R. Silva
wrote:
> On 3/17/21 13:57, Jann Horn wrote:
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> index 62ddb452f862..bff3dc1af702 100644
> --- a/drivers/net/ethe
On Wed, Mar 17, 2021 at 7:27 PM Gustavo A. R. Silva
wrote:
> On 3/17/21 12:11, Jann Horn wrote:
> > On Wed, Mar 17, 2021 at 8:43 AM Gustavo A. R. Silva
> > wrote:
> >> Fix the following out-of-bounds warning by replacing the one-element
> >> array in an anonymous union with a pointer:
> >>
> >>
Hi Jann,
Please, see my comments below...
On 3/17/21 12:11, Jann Horn wrote:
> On Wed, Mar 17, 2021 at 8:43 AM Gustavo A. R. Silva
> wrote:
>> Fix the following out-of-bounds warning by replacing the one-element
>> array in an anonymous union with a pointer:
>>
>> CC [M] drivers/net/ethernet/
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Paul Menzel
> Sent: Friday, March 5, 2021 1:04 AM
> To: Gustavo A. R. Silva ; Brandeburg, Jesse
> ; Nguyen, Anthony L
> ; David S. Miller ;
> Jakub Kicinski
> Cc: net...@vger.kernel.org; intel-wired-
On 28/02/2021 11:44, Dinghao Liu wrote:
There is one e1e_wphy() call in e1000_set_d0_lplu_state_82571
that we have caught its return value but lack further handling.
Check and terminate the execution flow just like other e1e_wphy()
in this function.
Signed-off-by: Dinghao Liu
---
drivers/net/
On 2/28/2021 11:44, Dinghao Liu wrote:
There is one e1e_wphy() call in e1000_set_d0_lplu_state_82571
that we have caught its return value but lack further handling.
Check and terminate the execution flow just like other e1e_wphy()
in this function.
Signed-off-by: Dinghao Liu
---
drivers/net/e
Dear Gustavo,
Thank you for working on that.
Am 05.03.21 um 09:52 schrieb Gustavo A. R. Silva:
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.
It would be nice to h
From: Brett Creeley
[ Upstream commit 943b881e35829403da638fcb34a959125deafef3 ]
Currently users could create more channels than LAN MSI-X available.
This is happening because there is no check against pf->num_lan_msix
when checking the max allowed channels and will cause performance issues
On Thu, 2021-01-14 at 09:57 +, Jankowski, Konrad0 wrote:
> > -Original Message-
> > From: Intel-wired-lan On Behalf Of Wei
> > Xu
[]
> > Use the ARRAY_SIZE macro to calculate the size of an array.
> > This code was detected with the help of Coccinelle.
[
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Wei Xu
> Sent: środa, 9 września 2020 10:51
> To: net...@vger.kernel.org
> Cc: salil.me...@huawei.com; jiny...@hisilicon.com;
> tangkuns...@huawei.com; huangda...@hisilicon.com;
> john.ga...@
> Dear Dinghao,
>
>
> Am 03.01.21 um 09:08 schrieb Dinghao Liu:
> > When ixgbe_fdir_write_perfect_filter_82599() fails,
> > input allocated by kzalloc() has not been freed,
> > which leads to memleak.
>
> Nice find. Thank you for your patches. Out of curiosity, do you use an
> analysis tool to
Dear Dinghao,
Am 03.01.21 um 09:08 schrieb Dinghao Liu:
When ixgbe_fdir_write_perfect_filter_82599() fails,
input allocated by kzalloc() has not been freed,
which leads to memleak.
Nice find. Thank you for your patches. Out of curiosity, do you use an
analysis tool to find these issues?
S
Dear Michael,
Thank you for the patch.
Maybe the summary could be more specific:
> PCI: Fix Intel i210 by avoiding overlapping of BARs
Am 30.12.20 um 18:28 schrieb Michael Walle:
The Intel i210 doesn't work if the Expansion ROM BAR overlaps with
another BAR. Networking won't work at all and
Hi Xiaohui,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tnguy-next-queue/dev-queue]
[also build test WARNING on linus/master sparc-next/master v5.10-rc7
next-20201208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitti
On 12/2/2020 09:50, Kai-Heng Feng wrote:
Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
when device is runtime suspended"), if we try to read speed and duplex
sysfs while the device is runtime suspeneded, igc will complain and
stops working:
[ 123.449883] igc :03:0
On Wed, 25 Nov 2020, Nick Desaulniers wrote:
> On Wed, Nov 25, 2020 at 1:33 PM Finn Thain wrote:
> >
> > Or do you think that a codebase can somehow satisfy multiple checkers
> > and their divergent interpretations of the language spec?
>
> Have we found any cases yet that are divergent? I d
On Wed, 25 Nov 2020, Nick Desaulniers wrote:
> On Wed, Nov 25, 2020 at 1:33 PM Finn Thain
> wrote:
> >
> > Or do you think that a codebase can somehow satisfy multiple checkers
> > and their divergent interpretations of the language spec?
>
> Have we found any cases yet that are divergent? I d
On Wed, Nov 25, 2020 at 1:33 PM Finn Thain wrote:
>
> Or do you think that a codebase can somehow satisfy multiple checkers and
> their divergent interpretations of the language spec?
Have we found any cases yet that are divergent? I don't think so. It
sounds to me like GCC's cases it warns for
On Wed, Nov 25, 2020 at 8:24 AM Jakub Kicinski wrote:
>
> Applying a real patch set and then getting a few follow ups the next day
> for trivial coding things like fallthrough missing or static missing,
> just because I didn't have the full range of compilers to check with
> before applying makes
On Wed, 25 Nov 2020, Nick Desaulniers wrote:
> So developers and distributions using Clang can't have
> -Wimplicit-fallthrough enabled because GCC is less strict (which has
> been shown in this thread to lead to bugs)? We'd like to have nice
> things too, you know.
>
Apparently the GCC devel
On Tue, Nov 24, 2020 at 11:05:35PM -0800, James Bottomley wrote:
> Now, what we have seems to be about 6 cases (at least what's been shown
> in this thread) where a missing break would cause potentially user
> visible issues. That means the value of this isn't zero, but it's not
> a no-brainer mas
On Wed, Nov 25, 2020 at 5:24 PM Jakub Kicinski wrote:
>
> And just to spell it out,
>
> case ENUM_VALUE1:
> bla();
> break;
> case ENUM_VALUE2:
> bla();
> default:
> break;
>
> is a fairly idiomatic way of indicating that not all values of the enum
> are expected to
On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the r
Hi Paul,
On Tue, Nov 24, 2020 at 04:47:30PM +0100, Paul Menzel wrote:
> Dear Chen,
>
>
> Thank you for the patch.
>
Thanks for reviewing this change.
> Am 24.11.20 um 16:32 schrieb Chen Yu:
> > The NIC is put in runtime suspend status when there is no wire connected.
> > As a result, it is safe
On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge. I
On Wed, Nov 25, 2020 at 12:53 AM Finn Thain wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)
Making the kernel strictly conforming is a ship that s
On Wed, 25 Nov 2020, Miguel Ojeda wrote:
>
> The C standard has nothing to do with this. We use compiler extensions
> of several kinds, for many years. Even discounting those extensions, the
> kernel is not even conforming to C due to e.g. strict aliasing. I am not
> sure what you are trying
On Tue, Nov 24, 2020 at 11:24 PM Finn Thain wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.
There is no "language spec" the kernel adheres to. Even if it did,
kernel co
On Tue, 24 Nov 2020, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at
> > all ... we really shouldn't be wasting maintainer time with it because
> > it has a cost to merge. I'm not sure
On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge. I'm not sure we understand where the balance
> lies in value
Dear Chen,
Thank you for the patch.
Am 24.11.20 um 16:32 schrieb Chen Yu:
The NIC is put in runtime suspend status when there is no wire connected.
As a result, it is safe to keep this NIC in runtime suspended during s2ram
because the system does not rely on the NIC plug event nor WOL to wake
On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe P
On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottoml
> From: Intel-wired-lan On Behalf Of
> Mario Limonciello
> Sent: Sunday, September 27, 2020 9:40 PM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org
> Cc: perry.y...@dell.com; yijun.s...@dell.com; linux-kernel@vger.kernel.org;
> Mario Limonciello
> S
> -Original Message-
> From: Brown, Aaron F
> Sent: Wednesday, October 7, 2020 8:22 AM
> To: Limonciello, Mario; Kirsher, Jeffrey T; intel-wired-...@lists.osuosl.org
> Cc: Yuan, Perry; Shen, Yijun; linux-kernel@vger.kernel.org
> Subject: RE: [Intel-wired-lan] [PATCH 3/3
> -Original Message-
> From: Limonciello, Mario
> Sent: Wednesday, October 7, 2020 8:30 AM
> To: Brown, Aaron F; Kirsher, Jeffrey T; intel-wired-...@lists.osuosl.org
> Cc: Yuan, Perry; Shen, Yijun; linux-kernel@vger.kernel.org
> Subject: RE: [Intel-wired-lan] [PATC
> From: Intel-wired-lan On Behalf Of
> Christophe JAILLET
> Sent: Saturday, July 18, 2020 4:56 AM
> To: k...@kernel.org; da...@davemloft.net; Kirsher, Jeffrey T
>
> Cc: net...@vger.kernel.org; kernel-janit...@vger.kernel.org; Christophe
> JAILLET ; intel-wired-...@list
On Mon, 2020-10-12 at 08:16 -0700, Jakub Kicinski wrote:
> On Mon, 12 Oct 2020 14:20:16 +0200 Bartosz Golaszewski wrote:
> > On Mon, Sep 28, 2020 at 9:17 AM Bartosz Golaszewski
> > wrote:
> > >
> > > From: Bartosz Golaszewski
> > >
> > > It's a valid use-case for ixgbe_mii_bus_init() to return
> > From: Intel-wired-lan On Behalf Of
> > Mario Limonciello
> > Sent: Sunday, September 27, 2020 9:40 PM
> > To: Kirsher, Jeffrey T ; intel-wired-
> > l...@lists.osuosl.org
> > Cc: perry.y...@dell.com; yijun.s...@dell.com; linux-kernel@vger.kernel.org
> From: Intel-wired-lan On Behalf Of
> Mario Limonciello
> Sent: Sunday, September 27, 2020 9:40 PM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org
> Cc: perry.y...@dell.com; yijun.s...@dell.com; linux-
> ker...@vger.kernel.org; Mario Limonciello
> S
> From: Intel-wired-lan On Behalf Of
> Mario Limonciello
> Sent: Sunday, September 27, 2020 9:40 PM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org
> Cc: perry.y...@dell.com; yijun.s...@dell.com; linux-kernel@vger.kernel.org;
> Mario Limonciello
> S
Hi Vitaly,
> On Sep 30, 2020, at 14:54, Vitaly Lifshits wrote:
>
> On 9/29/2020 18:08, Kai-Heng Feng wrote:
>
> Hello Kai-Heng,
>>> On Sep 29, 2020, at 21:46, Neftin, Sasha wrote:
>>>
>>> Hello Kai-Heng,
>>> On 9/29/2020 16:31, Kai-Heng Feng wrote:
Hi Sasha,
> On Sep 29, 2020, at 21:
Dear Tong,
Am 01.10.20 um 09:03 schrieb Paul Menzel:
Am 08.09.20 um 18:22 schrieb Tong Zhang:
length may be corrupted in rx_desc
How can that be?
and lead to panic, so check the sanity before passing it to skb_put
[ 167.667701] skbuff: skb_over_panic: text:b1e32cc1 len:60224
pu
Dear Tong,
Thank you for your patch.
Am 08.09.20 um 18:22 schrieb Tong Zhang:
length may be corrupted in rx_desc
How can that be?
and lead to panic, so check the sanity before passing it to skb_put
[ 167.667701] skbuff: skb_over_panic: text:b1e32cc1 len:60224
put:60224 head:
> From: Intel-wired-lan On Behalf Of Tong
> Zhang
> Sent: Tuesday, September 8, 2020 9:23 AM
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Jakub Kicinski ; intel-wired-
> l...@lists.osuosl.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: ztong0...@gmail.com
&g
> From: Intel-wired-lan On Behalf Of Tong
> Zhang
> Sent: Tuesday, September 8, 2020 9:23 AM
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Jakub Kicinski ; intel-wired-
> l...@lists.osuosl.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: ztong0...@gmail.com
&g
On 9/29/2020 18:08, Kai-Heng Feng wrote:
Hello Kai-Heng,
On Sep 29, 2020, at 21:46, Neftin, Sasha wrote:
Hello Kai-Heng,
On 9/29/2020 16:31, Kai-Heng Feng wrote:
Hi Sasha,
On Sep 29, 2020, at 21:08, Neftin, Sasha wrote:
On 9/28/2020 11:36, Kai-Heng Feng wrote:
We are seeing the followi
> On Sep 29, 2020, at 23:11, David Laight wrote:
>
>> Hope we finally have proper ME support under Linux?
>
> How about a way to disable it.
This will do, too :)
Kai-Heng
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Regist
> Hope we finally have proper ME support under Linux?
How about a way to disable it.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
> On Sep 29, 2020, at 21:46, Neftin, Sasha wrote:
>
> Hello Kai-Heng,
> On 9/29/2020 16:31, Kai-Heng Feng wrote:
>> Hi Sasha,
>>> On Sep 29, 2020, at 21:08, Neftin, Sasha wrote:
>>>
>>> On 9/28/2020 11:36, Kai-Heng Feng wrote:
We are seeing the following error after S3 resume:
[ 7
Hello Kai-Heng,
On 9/29/2020 16:31, Kai-Heng Feng wrote:
Hi Sasha,
On Sep 29, 2020, at 21:08, Neftin, Sasha wrote:
On 9/28/2020 11:36, Kai-Heng Feng wrote:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e 00
Hi Sasha,
> On Sep 29, 2020, at 21:08, Neftin, Sasha wrote:
>
> On 9/28/2020 11:36, Kai-Heng Feng wrote:
>> We are seeing the following error after S3 resume:
>> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
>> [ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
>>
On 9/28/2020 11:36, Kai-Heng Feng wrote:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
[ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.903075]
er the duplicates still
utterly confuse switches/bridges, ICMPv6 duplicate address detection and
neighbor discovery and therefore leads to long delays before being able
to establish TCP connections, for instance. And it also leads to the Linux
bridge printing messages like:
"br-lan: received packet o
er the duplicates still
utterly confuse switches/bridges, ICMPv6 duplicate address detection and
neighbor discovery and therefore leads to long delays before being able
to establish TCP connections, for instance. And it also leads to the Linux
bridge printing messages like:
"br-lan: received packet o
From: Dan Murphy
Date: Mon, 28 Sep 2020 09:47:24 -0500
> Hello
>
> On 9/28/20 9:46 AM, Dan Murphy wrote:
>> This adds WoL support on TI DP83869 for magic, magic secure, unicast
>> and
>> broadcast.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v5 - Fixed 0-day warning for u16
>>
>> arch/arm/co
On Mon, Sep 28, 2020 at 09:51:34AM -0500, Dan Murphy wrote:
> This adds WoL support on TI DP83869 for magic, magic secure, unicast and
> broadcast.
>
> Signed-off-by: Dan Murphy
Reviewed-by: Andrew Lunn
Andrew
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
v5 - Fixed 0-day warning for u16, removed defconfig
drivers/net/phy/dp83869.c | 176 ++
1 file changed, 176 insertions(+)
diff --git a/drivers/
Hello
On 9/28/20 9:46 AM, Dan Murphy wrote:
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
v5 - Fixed 0-day warning for u16
arch/arm/configs/ti_sdk_omap2_debug_defconfig | 2335 +
I have to repost this patc
SYNOPSYS=n
+CONFIG_NET_VENDOR_TEHUTI=n
+CONFIG_NET_VENDOR_VIA=n
+CONFIG_NET_VENDOR_WIZNET=n
+#Wireless LAN
+CONFIG_WLCORE=m
+CONFIG_WLCORE_SDIO=m
+CONFIG_WL18XX=m
+CONFIG_NL80211_TESTMODE=y
+CONFIG_MAC80211_MESH=y
+
+#MDIO phys
+CONFIG_MARVELL_PHY=y
+CONFIG_MICREL_PHY=y
+# unused P
Hi Dan,
url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/DP83869-WoL-and-Speed-optimization/20200925-002844
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
3fc826f121d89c5aa4afd7b3408b07e0ff59466b
config: x86_64-randconfig-m001-20200925 (attached as .conf
Dear Kai-Heng,
Thank you for patch version 3.
Am 24.09.20 um 18:45 schrieb Kai-Heng Feng:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
[ 704.902817] e1000e 00
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
v4 - Added checking error on phy_read
drivers/net/phy/dp83869.c | 176 ++
1 file changed, 176 insertions(+)
diff --git a/drivers/net/phy/dp8386
On Thu, Sep 24, 2020 at 05:32:12PM +0200, Paul Menzel wrote:
> Dear Kai-Heng,
>
>
> Thank you for sending version 2.
>
> Am 24.09.20 um 17:09 schrieb Kai-Heng Feng:
> > We are seeing the following error after S3 resume:
>
> I’d be great if you added the system and used hardware, you are seeing
Dear Kai-Heng,
Thank you for sending version 2.
Am 24.09.20 um 17:09 schrieb Kai-Heng Feng:
We are seeing the following error after S3 resume:
I’d be great if you added the system and used hardware, you are seeing
this with.
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[
Dear Andrew,
Am 23.09.20 um 21:28 schrieb Andrew Lunn:
How much does this increase the resume time?
Define resume time? Until you get the display manager unlock screen?
Or do you need working networking?
Until network is functional again. Currently, the speed negotiation
alone takes three(
> > > How much does this increase the resume time?
Define resume time? Until you get the display manager unlock screen?
Or do you need working networking?
It takes around 1.5 seconds for auto negotiation to get a link. I know
it takes me longer than that to move my fingers to the keyboard and
typ
Dear Kai-Heng,
Am 23.09.20 um 16:46 schrieb Kai-Heng Feng:
On Sep 23, 2020, at 21:28, Paul Menzel wrote:
Am 23.09.20 um 09:47 schrieb Kai-Heng Feng:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e :00
Hi Paul,
> On Sep 23, 2020, at 21:28, Paul Menzel wrote:
>
> Dear Kai-Heng,
>
>
> Am 23.09.20 um 09:47 schrieb Kai-Heng Feng:
>> We are seeing the following error after S3 resume:
>> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
>> [ 704.844232] e1000e :00:1f.6 eno1: MDI Wr
Dear Kai-Heng,
Am 23.09.20 um 09:47 schrieb Kai-Heng Feng:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
[ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x
Andrew
On 9/10/20 1:02 PM, Andrew Lunn wrote:
static int dp83869_config_port_mirroring(struct phy_device *phydev)
{
struct dp83869_private *dp83869 = phydev->priv;
Overall this code looks quite similar to dp83867, is there no way to
factor this out?
Factor what out? Yes the DP83
> > > static int dp83869_config_port_mirroring(struct phy_device *phydev)
> > > {
> > > struct dp83869_private *dp83869 = phydev->priv;
> > Overall this code looks quite similar to dp83867, is there no way to
> > factor this out?
>
> Factor what out? Yes the DP83867 and DP83869 are
Jakub
Thanks for the review
On 9/5/20 1:34 PM, Jakub Kicinski wrote:
On Thu, 3 Sep 2020 06:42:58 -0500 Dan Murphy wrote:
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
drivers/net/phy/dp83869.c | 128 +++
On Thu, 3 Sep 2020 06:42:58 -0500 Dan Murphy wrote:
> This adds WoL support on TI DP83869 for magic, magic secure, unicast and
> broadcast.
>
> Signed-off-by: Dan Murphy
> ---
> drivers/net/phy/dp83869.c | 128 ++
> 1 file changed, 128 insertions(+)
>
> diff
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
drivers/net/phy/dp83869.c | 128 ++
1 file changed, 128 insertions(+)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index 48
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
drivers/net/phy/dp83869.c | 128 ++
1 file changed, 128 insertions(+)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index 48
On Mon, Aug 31, 2020 at 09:35:19PM -0400, wrote:
> On Mon, Aug 31, 2020 at 10:35:12AM -0700, Jesse Brandeburg wrote:
> > Thanks for the report Lennart, I understand your frustration, as this
> > should probably work without user configuration.
> >
> > However, please give this command a try:
> >
It is necessary to manage the Wake-on-LAN clock to turn on the
appropriate blocks for MPD or CFP-based packet matching to work
otherwise we will not be able to reliably match packets during suspend.
Reported-by: Blair Prescott
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/broadcom
On Mon, Aug 31, 2020 at 10:35:12AM -0700, Jesse Brandeburg wrote:
> Thanks for the report Lennart, I understand your frustration, as this
> should probably work without user configuration.
>
> However, please give this command a try:
> ethtool --set-priv-flags ethX disable-source-pruning on
Hmm,
Lennart Sorensen wrote:
> On Thu, Aug 27, 2020 at 02:30:39PM -0400, Lennart Sorensen wrote:
> > I have hit a new problem with the X722 chipset (Intel R1304WFT server).
> > VRRP simply does not work.
> >
> > When keepalived registers a vmac interface, and starts transmitting
> > multicast packets
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Suraj Upadhyay
> Sent: Tuesday, July 14, 2020 12:42 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net;
> k...@kernel.org
> Cc: net...@vger.kernel.org; kernel-janit...@vger.kernel.org; intel-wired-
> l...
> From: Intel-wired-lan On Behalf Of
> Francesco Ruggeri
> Sent: Thursday, July 2, 2020 3:39 PM
> To: linux-kernel@vger.kernel.org; net...@vger.kernel.org; intel-wired-
> l...@lists.osuosl.org; k...@kernel.org; da...@davemloft.net; Kirsher, Jeffrey
> T ; frugg...@arista.com
> From: Intel-wired-lan On Behalf Of
> Aaron Ma
> Sent: Wednesday, June 17, 2020 11:55 PM
> To: k...@kernel.org; Kirsher, Jeffrey T ;
> da...@davemloft.net; intel-wired-...@lists.osuosl.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Lifshits, Vitaly
> ; kai.he
1 - 100 of 872 matches
Mail list logo
