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 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 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
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 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
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 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 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 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 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
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
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,
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 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 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 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
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 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 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 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
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
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
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
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
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 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: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: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
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
==
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
31 matches
Mail list logo
