On Fri, May 17, 2019 at 09:58:46AM -0700, Alexander Duyck wrote:
> > I don't think you can say because the checksum is valid that all data
> > contained
> > inside is also valid. You can have a valid checksum , and someone screwed
> > up the
> > data prior to the checksum getting computed.
>
> I
On Fri, May 17, 2019 at 08:16:34AM -0700, Alexander Duyck wrote:
> On Thu, May 16, 2019 at 6:48 PM Florian Fainelli wrote:
> >
> >
> >
> > On 5/16/2019 6:03 PM, Daniel Walker wrote:
> > > On Thu, May 16, 2019 at 03:02:18PM -0700, Florian Fainelli wrote:
>
On Thu, May 16, 2019 at 03:02:18PM -0700, Florian Fainelli wrote:
> On 5/16/19 12:55 PM, Nikunj Kela (nkela) wrote:
> >
> >
> > On 5/16/19, 12:35 PM, "Jeff Kirsher" wrote:
> >
> > On Wed, 2019-05-08 at 23:14 +, Nikunj Kela wrote:
> >>> Some of the broken NICs don't have EEPROM progr
On Thu, Oct 18, 2018 at 04:49:26PM +, Claudiu Manoil wrote:
>
> I can only advise you to check whether the MACCFG2 register settings are
> consistent
> at this point, when ping fails. You should check the I/F Mode bits (22-23)
> and the
> Full Duplex bit (31), in big-endian format. If the
On Thu, Oct 18, 2018 at 04:49:26PM +, Claudiu Manoil wrote:
> I can only advise you to check whether the MACCFG2 register settings are
> consistent
> at this point, when ping fails. You should check the I/F Mode bits (22-23)
> and the
> Full Duplex bit (31), in big-endian format. If these
On Thu, Oct 18, 2018 at 12:16:06PM +, Claudiu Manoil wrote:
> Hi,
>
> Sorry but I never heard about the phy you're quoting, this m88e1101, what is
> it?
> Link mode? (SGMII, RGMII, ?)
> Our boards (the ones I know) have Vitesse or Atheros phys.
> If the maccfg2 setting you're mentioning reall
On Thu, Oct 18, 2018 at 12:16:06PM +, Claudiu Manoil wrote:
> Hi,
>
> Sorry but I never heard about the phy you're quoting, this m88e1101, what is
> it?
> Link mode? (SGMII, RGMII, ?)
> Our boards (the ones I know) have Vitesse or Atheros phys.
> If the maccfg2 setting you're mentioning reall
On Tue, Oct 16, 2018 at 03:03:07PM -0700, Florian Fainelli wrote:
> On 10/16/2018 02:36 PM, Daniel Walker wrote:
> > Hi,
> >
> > I would like to report an issue in the gianfar driver. The issue is as
> > follows.
> >
> > We have a P2020 board that
Hi,
I would like to report an issue in the gianfar driver. The issue is as follows.
We have a P2020 board that uses the gianfar driver, and we have a m88e1101
PHY connect. When the interface is initially brought up traffic flows as
normal. If you take the interface down then bring it back up tra
On 09/25/2018 10:42 PM, Harini Katakam wrote:
Hi,
On Tue, Sep 25, 2018 at 11:00 PM Harini Katakam wrote:
Hi Daniel,
On Tue, Sep 25, 2018 at 9:10 PM Andrew Lunn wrote:
I hope this this thread isn't too old to bring back to life. So it seems
that Harini found that m88e did not need this
On 04/18/2017 07:04 AM, Andrew Lunn wrote:
On Tue, Apr 18, 2017 at 06:16:33AM -0700, Daniel Walker wrote:
Hi,
Cisco is using a Marvell 88E1112 phy. It seems to be fairly similar
to the 88E which Harini added a fix for.
Hi Daniel
If you look at Marvell reference drive, DSDT, they are
On 12/13/2017 12:35 PM, Andrew Lunn wrote:
On Wed, Dec 13, 2017 at 10:46:02AM -0800, Daniel Walker wrote:
Hi,
https://sjc-apl-grt32.cisco.com:8081/gitweb?p=xe-linux/kernel.git;a=commit;h=87aa9f9c61ad56d505641681812e92ad976f8608
Hi Daniel
This is a 4 year old patch, so i'm kind of surp
Hi,
https://sjc-apl-grt32.cisco.com:8081/gitweb?p=xe-linux/kernel.git;a=commit;h=87aa9f9c61ad56d505641681812e92ad976f8608
I've got a machine with an Marvell 88EE1112 , and it seems this patch
causes a problem. When the reset happens under this code this phy always
returns -ETIMEDOUT from insi
Hi,
It seems like commit cd0f0b is trying to add back these two errors
values into ip_route_input_slow(). However, if you follow the code path
further down you get to the two exit points of this function,
in net/ipv4/route.c:ip_route_input_slow()
if (rt_cache_valid(rth)) {
skb_dst_s
On 05/22/2017 04:28 PM, Andrew Lunn wrote:
The 88m1101 has an errata when configuring autoneg. However, it was
being applied to many other Marvell PHYs as well. Limit its scope to
just the 88m1101.
Fixes: 76884679c644 ("phylib: Add support for Marvell 88eS and 88e1145")
Reported-
On 04/18/2017 07:04 AM, Andrew Lunn wrote:
On Tue, Apr 18, 2017 at 06:16:33AM -0700, Daniel Walker wrote:
Hi,
Cisco is using a Marvell 88E1112 phy. It seems to be fairly similar
to the 88E which Harini added a fix for.
Hi Daniel
If you look at Marvell reference drive, DSDT, they are
On 04/18/2017 07:41 AM, Harini Katakam wrote:
Hi Daniel,
-Original Message-
From: Daniel Walker [mailto:danie...@cisco.com]
Sent: Tuesday, April 18, 2017 8:05 PM
To: Harini Katakam ; Andrew Lunn
Cc: Florian Fainelli ; Andy Fleming
; netdev@vger.kernel.org; HEMANT RAMDASI
; Julius
On 04/18/2017 07:31 AM, Harini Katakam wrote:
Hi Daniel,
-Original Message-
From: Daniel Walker [mailto:danie...@cisco.com]
Sent: Tuesday, April 18, 2017 7:48 PM
To: Andrew Lunn
Cc: Florian Fainelli ; Andy Fleming
; Harini Katakam ;
netdev@vger.kernel.org; HEMANT RAMDASI ; Julius
On 04/18/2017 07:04 AM, Andrew Lunn wrote:
On Tue, Apr 18, 2017 at 06:16:33AM -0700, Daniel Walker wrote:
Hi,
Cisco is using a Marvell 88E1112 phy. It seems to be fairly similar
to the 88E which Harini added a fix for.
Hi Daniel
If you look at Marvell reference drive, DSDT, they are
Hi,
Cisco is using a Marvell 88E1112 phy. It seems to be fairly similar to
the 88E which Harini added a fix for. In Harini's commit message for ,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/phy/marvell.c?id=3ec0a0f10ceb
"This function has a seque
On 09/07/2016 01:48 PM, Richard Cochran wrote:
On Wed, Sep 07, 2016 at 01:40:59PM -0700, Daniel Walker wrote:
There is a test (below) , which prevents negative nanosecond updates. The
code below would force a negative update to always return more than
NSEC_PER_SEC. It should be using abs
call would not fail with -EOPNOTSUPP.
e1000_set_spd_dplx should not automatically turn autoneg back on for forced
1000 Mbps full duplex settings for non-copper media.
Cc: xe-ker...@external.cisco.com
Cc: Daniel Walker
Signed-off-by: Steve Shih
---
drivers/net/ethernet/intel/e1000e/ethtool.c
On 04/03/2016 07:23 AM, Ruinskiy, Dima wrote:
I have a couple of comments (sorry for not getting to it a bit sooner).
For fiber media, e1000_get_settings should return ETH_TP_MDI_INVALID for
eth_tp_mdix_ctrl instead of ETH_TP_MDI_AUTO so subsequent e1000_set_settings
call would not fail with -E
So Intel maintainers (Jeff, Jesse, Shannon, Carolyn, Don, Bruce, and John)
I'm assuming no comments means this patch is acceptable , and I will
resubmit it without the RFC. Is that acceptable ?
On 03/25/2016 02:58 PM, Daniel Walker wrote:
From: Steve Shih
This patch fixes the issue
From: Steve Shih
This patch fixes the issues for disabling auto-negotiation and forcing
speed and duplex settings for the fiber media.
For fiber media, e1000_get_settings should return ETH_TP_MDI_INVALID for
eth_tp_mdix_ctrl instead of ETH_TP_MDI_AUTO so subsequent e1000_set_settings
call would
On Fri, 2007-05-04 at 14:09 -0400, Mike Snitzer wrote:
> On 5/4/07, Daniel Walker <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-05-04 at 17:38 +0200, Peter Zijlstra wrote:
> > > >
> > > > This is kind of a lot of patches all at once .. Have you release any of
On Fri, 2007-05-04 at 17:38 +0200, Peter Zijlstra wrote:
> >
> > This is kind of a lot of patches all at once .. Have you release any of
> > these patch sets prior to this release ?
>
> Like the -v12 suggests, this is the 12th posting of this patch set.
> Some is the same, some has changed.
I c
On Fri, 2007-05-04 at 12:26 +0200, Peter Zijlstra wrote:
> 1) introduce the memory reserve and make the SLAB allocator play nice with it.
>patches 01-10
>
> 2) add some needed infrastructure to the network code
>patches 11-13
>
> 3) implement the idea outlined above
>patches 14-20
>
On Thu, 2006-08-03 at 16:56 -0700, David Miller wrote:
> From: Theodore Tso <[EMAIL PROTECTED]>
> Date: Thu, 3 Aug 2006 19:53:26 -0400
>
> > Any suggestions on how I could figure out what was really going on and
> > what would be a better fix would be greatly appreciated.
>
> As Michael explained
On Thu, 2006-08-03 at 12:32 -0400, Theodore Tso wrote:
> This only shows up with the real-time kernel where timer softirq's run
> in their own processes, and a high priority process preempts the timer
> softirq. I don't really consider this a networking bug, or even
> driver bug, although it does
integer constant is too large for 'long' type
drivers/net/dl2k.c:1813: warning: integer constant is too large for 'long' type
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
Index: linux-2.6.16/drivers/net/dl2k.c
==
31 matches
Mail list logo
