h adds the macb_is_gem() checks back to the code
(in macb_mac_config() & macb_mac_link_up()), so that the GEM register
bits are not accessed in this case any more.
Fixes: 7897b071ac3b ("net: macb: convert to phylink")
Signed-off-by: Stefan Roese
Cc: Reto Schneider
Cc: Alexandre Be
Rename the NEXT_RX_DESP_IDX macro to NEXT_DESP_IDX, so that it better
can be used for TX ops as well. This will be used in the upcoming
MT7628/88 support (same functionality for RX and TX in this macro).
Signed-off-by: Stefan Roese
Cc: René van Dorst
Cc: Daniel Golle
Cc: Sean Wang
Cc: John
This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA (only PDMA).
Signed-off-by: Stefan Roese
Cc: René van Dorst
Cc: Daniel Golle
Cc: Sean Wang
Cc: John
Currently all QDMA registers are named "MTK_QDMA_foo" in this driver
with one exception: MTK_QMTK_INT_STATUS. This patch renames
MTK_QMTK_INT_STATUS to MTK_QDMA_INT_STATUS so that all macros follow
this rule.
Signed-off-by: Stefan Roese
Cc: René van Dorst
Cc: Daniel Golle
Cc: Sea
Add compatible for the ethernet IP core on MT7628/88 SoCs. Its
compatible with the older Ralink Rt5350F SoC. And OpenWrt already
uses this compatible string for the MT76x8.
Signed-off-by: Stefan Roese
Cc: René van Dorst
Cc: Daniel Golle
Cc: Sean Wang
Cc: John Crispin
Cc: devicet
Hi Rene,
On 14.08.19 15:08, René van Dorst wrote:
Quoting Stefan Roese :
Hi Rene,
On 14.08.19 11:26, René van Dorst wrote:
Great, Thanks for addressing this issue.
I hope we can collaborate to also support mt76x8 in my PHYLINK
patches [0][1].
I am close to posting V2 of the patches but
This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA (only PDMA).
Signed-off-by: Stefan Roese
Cc: René van Dorst
Cc: Daniel Golle
Cc: Sean Wang
Cc: John
Currently all QDMA registers are named "MTK_QDMA_foo" in this driver
with one exception: MTK_QMTK_INT_STATUS. This patch renames
MTK_QMTK_INT_STATUS to MTK_QDMA_INT_STATUS so that all macros follow
this rule.
Signed-off-by: Stefan Roese
Cc: René van Dorst
Cc: Daniel Golle
Cc: Sea
Rename the NEXT_RX_DESP_IDX macro to NEXT_DESP_IDX, so that it better
can be used for TX ops as well. This will be used in the upcoming
MT7628/88 support (same functionality for RX and TX in this macro).
Signed-off-by: Stefan Roese
Cc: René van Dorst
Cc: Daniel Golle
Cc: Sean Wang
Cc: John
Add compatible for the ethernet IP core on MT7628/88 SoCs. Its
compatible with the older Ralink Rt5350F SoC. And OpenWrt already
uses this compatible string for the MT76x8.
Signed-off-by: Stefan Roese
Cc: René van Dorst
Cc: Daniel Golle
Cc: Sean Wang
Cc: John Crispin
Cc: devicet
Hi Rene,
On 14.08.19 11:26, René van Dorst wrote:
Hi Stefan,
Quoting Stefan Roese :
Hi Rene,
On 17.07.19 14:53, René van Dorst wrote:
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -39,7 +39,8 @@
NETIF_F_SG | NETIF_F_TSO
Hi Rene,
On 17.07.19 14:53, René van Dorst wrote:
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -39,7 +39,8 @@
NETIF_F_SG | NETIF_F_TSO | \
NETIF_F_TSO6 | \
NETIF_F_IPV6_CSUM)
-#define NE
On 17.07.19 14:15, Daniel Golle wrote:
On Wed, Jul 17, 2019 at 01:02:43PM +0200, Stefan Roese wrote:
This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA
On 17.07.19 14:15, Daniel Golle wrote:
On Wed, Jul 17, 2019 at 01:02:43PM +0200, Stefan Roese wrote:
This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA
This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA (only PDMA).
Signed-off-by: Stefan Roese
Cc: René van Dorst
Cc: Sean Wang
Cc: Felix Fietkau
Cc: John
Add code to select SGMII-to-copper mode upon SGMII interface selection.
Signed-off-by: Stefan Roese
Cc: Andrew Lunn
Cc: Florian Fainelli
Cc: David S. Miller
---
drivers/net/phy/marvell.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/drivers
With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/n
On Wednesday 06 February 2008, Jeff Garzik wrote:
> > Jeff, any chance this can get into .25 soon? I have another patch
> > queued up behind this one that requires it, and I don't see it in any
> > of your trees or branches.
> >
> > Or, if you aren't opposed, I can take it through Paul's tree with
On Wednesday 16 January 2008, Josh Boyer wrote:
> On Wed, 16 Jan 2008 20:53:59 +1100
>
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> > > With the removal the the "rgmii-interface" device_typ
With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/rgmii.c |1 -
1 files changed, 0 insertions
0GX). This enables
an MTU of 9000 instead 4080.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index cb06280
0GX). This enables
an MTU of 9000 instead 4080.
Tested on Kilauea (405EX) with GigE link -> jumbo frames enabled.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_emac/ibm_emac_core.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/d
On Tuesday 15 January 2008, Eugene Surovegin wrote:
> > OK. But how do we detect GigE support? Seems like GigE enabled devices
> > have CONFIG_IBM_EMAC4 defined. If nobody objects I'll fix up another
> > version tomorrow.
>
> Look couple of lines down where I set MTU changing hook. If you cannot
>
On Tuesday 15 January 2008, Eugene Surovegin wrote:
> On Tue, Jan 15, 2008 at 01:40:09PM +0100, Stefan Roese wrote:
> > Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> > xmit. This routine doesn't check if the frame length exceeds the max.
> >
enables an
MTU of 9000 instead 4080.
Tested on Kilauea (405EX) with gbit link -> jumbo frames enabled.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
Eugene & Ben, do you see any problems with this patch? If not, then I'll
send another version for the newemac driver too.
Th
On Friday 11 January 2008, Benjamin Herrenschmidt wrote:
> On Fri, 2008-01-11 at 09:48 -0800, Eugene Surovegin wrote:
> > On Sat, Jan 05, 2008 at 01:38:17PM +0100, Stefan Roese wrote:
> > > On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> > > > On Sat, 200
On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > Performance tests done by AMCC have shown that 256 buffer increase the
> > performance of the Linux EMAC driver. So let's update the default
> >
Performance tests done by AMCC have shown that 256 buffer increase the
performance of the Linux EMAC driver. So let's update the default
values to match this setup.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/Kconfig |4 ++--
1 files changed, 2
ose them (since their registers
> are present in the MMIO space) but with an "unused" property in them.
>
> Signed-off-by: Hugh Blemings <[EMAIL PROTECTED]>
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
On Monday 05 November 2007, Benjamin Herrenschmidt wrote:
> > So how exactly do you want me to handle this (I'm still new to this
> > device
> > tree stuff, so please bear with me)? Like this?
> >
> > RGMII0: [EMAIL PROTECTED] {
> > device_typ
On Sunday 04 November 2007, Benjamin Herrenschmidt wrote:
> > Isn't this the case where there should really be device tree properties
> > instead? If you had an "ibm,emac-has-axon-stacr" property in the device
> > node, then you don't have to modify the driver for every new board out
> > there. Sam
This patch adds support for the 405EX to the new EMAC driver. Some as on
AXON, the 405EX handles the MDIO via the RGMII bridge.
Tested on AMCC Kilauea.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |3 ++-
drivers/net/ibm_newemac/rgmii.c
On Thursday 01 November 2007, Josh Boyer wrote:
> > > - if (dev->type != RGMII_AXON)
> > > - return;
> > > -
> > > mutex_lock(&dev->lock);
> >
> > That will break 440GX boards that need to use the RGMII for data and the
> > ZMII for MDIO.
> >
> > You may want to change the name RGMII_AXON
This patch adds support for the 405EX to the new EMAC driver.
Tested on AMCC Kilauea.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |3 ++-
drivers/net/ibm_newemac/rgmii.c |6 --
2 files changed, 2 insertions(+), 7 deletions(-)
diff -
On Wednesday 16 May 2007, Eugene Surovegin wrote:
> On Wed, May 16, 2007 at 01:00:08PM +0200, Stefan Roese wrote:
> > This patch fixes a bug where the link speed change was not
> > detected correctly. This occured on a 440SPe (EMAC4) system
> > where the old link speed was 100
This patch fixes a bug where the link speed change was not
detected correctly. This occured on a 440SPe (EMAC4) system
where the old link speed was 100Mbps and the new link speed
is 1000Mbps.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
commit 1e2a6085bbb6bd384e0812b6e9c62d18d14e1c0
Hi all,
I'm in the stage of integrating an IEEE1588 PTP driver for the AMCC 405EZ PPC
and looking for the correct location to place this driver in the Linux source
tree. The driver is a character-driver that enables the user space
applications to configure the time stamping unit and to read/wri
On Saturday 24 December 2005 17:36, Marc Singer wrote:
> > > It most likely is the same code. Currently it's version 2.0. This
> > > version is available under a special Intel license
> > > (http://www.intel.com/design/network/products/npfamily/ixp425swr1.htm)
> > > and under the BSD license (when
On Saturday 24 December 2005 15:07, Deepak Saxena wrote:
> On Dec 21 2005, at 15:48, Stefan Roese was caught saying:
> > Hi Lennert,
> >
> > On Wednesday 21 December 2005 14:52, Lennert Buytenhek wrote:
> > > On Wed, Dec 21, 2005 at 01:00:34PM +0100, Stefan Roese wrot
Hi Lennert,
On Wednesday 21 December 2005 14:52, Lennert Buytenhek wrote:
> On Wed, Dec 21, 2005 at 01:00:34PM +0100, Stefan Roese wrote:
> > The main question I have is, where should the IXP4xx access-library
> > be located in the kernel directory structure?
>
> Maybe you ca
I am trying to integrate the IXP4xx NPE ethernet support into the linux kernel
(2.6).
Before you start, I know of the license problems with the IXP4xx software. We
have a version of the Intel IXP4xx access-library licensed under the revised
BSD license. So we should (hopefully) be able to integ
41 matches
Mail list logo
