Re: [PATCH] gianfar: Add gfar_change_carrier()

On Fri, 2018-12-07 at 15:15 +0100, Andrew Lunn wrote: > > > > Been a bit busy today but now I have played with dormant using ip link and > > got some odd results: > > # > ifconfig eth0 > > eth0: flags=4163 mtu 1500 > > inet 172.20.0.246 netmask 255.255.0.0 broadcast 172.20.255.255 >

Re: [PATCH] gianfar: Add gfar_change_carrier()

On Thu, 2018-12-06 at 20:43 +0100, Andrew Lunn wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > I can have a look at using dormant, but what is

Re: [PATCH] gianfar: Add gfar_change_carrier()

On Thu, 2018-12-06 at 17:54 +0100, Andrew Lunn wrote: > > > I wish I had a proper DSA/Switchdev driver in place but I don't :( > > Adding one is not impossible but then a lot of our user space app needs > > fixing so all > > in all it it a fairly big project. > > Anyhow, these carrier additions

Re: [PATCH] gianfar: Add gfar_change_carrier()

On Thu, 2018-12-06 at 17:21 +0100, Andrew Lunn wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > > Hi Joakim > > > > > > Please could you explain the use

Re: [PATCH] gianfar: Add gfar_change_carrier()

On Thu, 2018-12-06 at 16:47 +0100, Andrew Lunn wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On Thu, Dec 06, 2018 at 04:31:25PM +0100

[PATCH] dpaa_eth: Add dpaa_change_carrier()

This allows to control carrier from /sys/class/net/ethX/carrier Signed-off-by: Joakim Tjernlund --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale

[PATCH] ucc_geth: Add ucc_geth_change_carrier()

This allows to control carrier from /sys/class/net/ethX/carrier Signed-off-by: Joakim Tjernlund --- drivers/net/ethernet/freescale/ucc_geth.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c

[PATCH] gianfar: Add gfar_change_carrier()

This allows to control carrier from /sys/class/net/ethX/carrier Signed-off-by: Joakim Tjernlund --- drivers/net/ethernet/freescale/gianfar.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c

Re: ethernet "bus" number in DTS ?

On Tue, 2018-10-23 at 11:20 -0700, Florian Fainelli wrote: > > On 10/23/18 11:02 AM, Joakim Tjernlund wrote: > > On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote: > > > > > > > > > On 10/23/18 9:49 AM, Joakim Tjernlund wrote: > > > &

Re: ethernet "bus" number in DTS ?

On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On 10/23/18 9:49 AM, Joakim Tjernl

Re: [RFC] managing PHY carrier from user space

On Tue, 2018-09-11 at 09:56 -0700, Florian Fainelli wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On 09/11/2018 09:41 AM, Joakim Tjernlu

[RFC] managing PHY carrier from user space

I am looking for a way to induce carrier state from user space, primarily for Fixed PHYs as these are always up. ifplugd/dhcp etc. does not behave properly if the link is up when it really isn't. I came up with a new 'phy_carrier' attribute in /sys/class/net/eth0/phydev where I can induce

Fixed PHYs and link up/down from user space ?

I am looking for a way to set physical link state from user space for a Fixed PHY. Found the /sys/class/net/eth1/carrier I/F but that didn't work and I cannot find something else. I want to make ifplugd/dhcp function as if there were a real cable there(or not) Jocke

[PATCH v2] ucc_geth: Add BQL support

Signed-off-by: Joakim Tjernlund --- v2 - Reoder varibles according to Dave Add call to netdev_reset_queue(dev) open/close drivers/net/ethernet/freescale/ucc_geth.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b

Re: [PATCH] ucc_geth: Add BQL support

c chip or devboard this runs on? This driver is for MPC83xx family SOCs(possibly others as well) on our custom boards, used in our telecom product. You are actually the reason I impl. this :) Jocke > > On Tue, Jun 19, 2018 at 11:24 AM, Li Yang wrote: > > On Tue, Jun 19, 2018

[PATCH] ucc_geth: Add BQL support

Signed-off-by: Joakim Tjernlund --- drivers/net/ethernet/freescale/ucc_geth.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c index f77ba9fa257b..6c99a9af6647 100644 --- a/drivers/net

Re: [PATCH 0/5] DPAA Ethernet fixes

On Wed, 2018-03-14 at 08:37 -0500, Madalin Bucur wrote: > Hi, > > This patch set is addressing several issues in the DPAA Ethernet > driver suite: > > - module unload crash caused by wrong reference to device being left >in the cleanup code after the DSA related changes > - scheduling wile

Re: DPAA Ethernet traffice troubles with Linux kernel

On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > > commit 4d8ee1935bcd666360311dfdadeee235d682d69a > > >

Re: DPAA Ethernet traffice troubles with Linux kernel

On Thu, 1970-01-01 at 00:00 +, Madalin-cristian Bucur wrote: > > > -Original Message- > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com] > > Sent: Tuesday, January 16, 2018 7:58 PM > > To: and...@lunn.ch > > Subject: Re: DPAA Ethernet tr

Re: DPAA Ethernet traffice troubles with Linux kernel

On Thu, 1970-01-01 at 00:00 +, Joakim Tjernlund wrote: > On Thu, 1970-01-01 at 00:00 +, Madalin-cristian Bucur wrote: > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know

Re: DPAA Ethernet traffice troubles with Linux kernel

On Thu, 1970-01-01 at 00:00 +, Madalin-cristian Bucur wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > -Original Message-

Re: DPAA Ethernet traffice troubles with Linux kernel

On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > > You appear to be using an old kernel. Take a look at: > >

Re: DPAA Ethernet traffice troubles with Linux kernel

ll patch I just wrote for mdio bus, o > > idea > > if it is relevant but here goes: > > > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001 > > From: Joakim Tjernlund <joakim.tjernl...@infinera.com> > > Date: Sun, 14 Jan 2018 21:27:20

Re: DPAA Ethernet traffice troubles with Linux kernel

back 2 back to a known good machine and determine what is broken - Rx/Tx? > Is there another software version that does work on these machines? Hi, just saw this and thought of a small patch I just wrote for mdio bus, o idea if it is relevant but here goes: From fe0b98d54a79779482700676331

Re: DSA vs. SWTICHDEV ?

On Wed, 2016-11-30 at 10:10 -0800, Florian Fainelli wrote: > On 11/30/2016 09:44 AM, Joakim Tjernlund wrote: > > On Wed, 2016-11-30 at 17:55 +0100, Andrew Lunn wrote: > > > > This is an embedded system with several boards in a subrack. > > > > Each board

Re: DSA vs. SWTICHDEV ?

On Wed, 2016-11-30 at 17:55 +0100, Andrew Lunn wrote: > > This is an embedded system with several boards in a subrack. > > Each board has eth I/F connected to a switch to communicate with each other. > > One of the board will also house the actual switch device and manage the > > switch. > > Then

Re: DSA vs. SWTICHDEV ?

On Wed, 2016-11-30 at 16:25 +0100, Andrew Lunn wrote: > On Wed, Nov 30, 2016 at 02:30:43PM +0000, Joakim Tjernlund wrote: > > On Wed, 2016-11-30 at 14:52 +0100, Andrew Lunn wrote: > > > On Wed, Nov 30, 2016 at 08:50:34AM +, Joakim Tjernlund wrote: > > > > I am

Re: DSA vs. SWTICHDEV ?

On Wed, 2016-11-30 at 14:52 +0100, Andrew Lunn wrote: > On Wed, Nov 30, 2016 at 08:50:34AM +0000, Joakim Tjernlund wrote: > > I am trying to wrap my head around these two "devices" and have a hard time > > telling them apart. > > We are looking att adding a faily

DSA vs. SWTICHDEV ?

I am trying to wrap my head around these two "devices" and have a hard time telling them apart. We are looking att adding a faily large switch(over PCIe) to our board and from what I can tell switchdev is the new way to do it but DSA is still there. Is it possible to just list how they differ?

Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet

IQ platforms. Nice to see DPAA support soon entering the kernel(not a day too early:) I would like to see BQL supported from day one though, if possible.  Regards           Joakim Tjernlund

Re: [Patch v2 5/5] drivers/net: support hdlc function for QE-UCC

On Thu, 2016-06-02 at 09:45 +0800, Zhao Qiang wrote: > The driver add hdlc support for Freescale QUICC Engine. > It support NMSI and TSA mode. > > Signed-off-by: Zhao Qiang > --- > Changes for v2: > - remove useless code. > - remove Unnecessary casts > -

Re: [PATCH 4/5] fsl/qe: Add QE TDM lib

On Wed, 2016-03-30 at 16:50 +0800, Zhao Qiang wrote: > QE has module to support TDM, some other protocols > supported by QE are based on TDM. > add a qe-tdm lib, this lib provides functions to the protocols > using TDM to configurate QE-TDM. > > Signed-off-by: Zhao Qiang >

Re: [net-next v4 2/8] dpaa_eth: add support for DPAA Ethernet

On Mon, 2015-11-02 at 19:31 +0200, Madalin Bucur wrote: > + if (unlikely(fd_status & FM_FD_STAT_RX_ERRORS) != 0) { > + if (net_ratelimit()) > + netif_warn(priv, hw, net_dev, "FD status = 0x%08x\n", > + fd_status &

Re: [net-next v4 2/8] dpaa_eth: add support for DPAA Ethernet

On Tue, 2015-11-03 at 09:37 +, Madalin-Cristian Bucur wrote: > > -Original Message- > > From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] > > > > On Mon, 2015-11-02 at 19:31 +0200, Madalin Bucur wrote: > > > + if (unlikely(fd_st

Re: [PATCH 02/10] dpaa_eth: add support for DPAA Ethernet

On Wed, 2015-07-22 at 19:16 +0300, Madalin Bucur wrote: This introduces the Freescale Data Path Acceleration Architecture (DPAA) Ethernet driver (dpaa_eth) that builds upon the DPAA QMan, BMan, PAMU and FMan drivers to deliver Ethernet connectivity on the Freescale DPAA QorIQ platforms.

Re: [RFC,v3,12/12] fsl/fman: Add FMan MAC driver

On Mon, 2015-07-20 at 13:33 +, Madalin-Cristian Bucur wrote: -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Monday, July 20, 2015 3:57 PM To: netdev@vger.kernel.org; Liberman Igal-B31950; Bucur Madalin-Cristian- B32716 Cc: linuxppc

Re: [PATCH RFC 02/10] dpaa_eth: add support for DPAA Ethernet

On Wed, 2015-04-01 at 19:19 +0300, Madalin Bucur wrote: This introduces the Freescale Data Path Acceleration Architecture (DPAA) Ethernet driver (dpaa_eth) that builds upon the DPAA QMan, BMan, PAMU and FMan drivers to deliver Ethernet connectivity on the Freescale DPAA QorIQ platforms.

Re: [PATCH RFC 02/10] dpaa_eth: add support for DPAA Ethernet

On Mon, 2015-07-20 at 09:54 +0200, Joakim Tjernlund wrote: On Wed, 2015-04-01 at 19:19 +0300, Madalin Bucur wrote: This introduces the Freescale Data Path Acceleration Architecture (DPAA) Ethernet driver (dpaa_eth) that builds upon the DPAA QMan, BMan, PAMU and FMan drivers to deliver

Re: [RFC,v3,12/12] fsl/fman: Add FMan MAC driver

On Mon, 2015-07-20 at 12:28 +, Madalin-Cristian Bucur wrote: Hi Joakim, It seems we just need to align to the API introduced by Thomas Petazzoni in 3be2a49e. Madalin So it seems, any idea when the next spin will be ready? Could you also push it onto

Re: [RFC,v3,12/12] fsl/fman: Add FMan MAC driver

On Wed, 2015-04-29 at 12:29 +0300, Igal.Liberman wrote: From: Igal Liberman igal.liber...@freescale.com This patch adds the Ethernet MAC driver support. Signed-off-by: Igal Liberman igal.liber...@freescale.com --- drivers/net/ethernet/freescale/fman/inc/mac.h | 125 +

Re: [PATCH RFC 02/10] dpaa_eth: add support for DPAA Ethernet

On Mon, 2015-07-20 at 12:18 +, Madalin-Cristian Bucur wrote: Hi Joakim -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Monday, July 20, 2015 10:57 AM To: linuxppc-...@lists.ozlabs.org; netdev@vger.kernel.org; Bucur Madalin- Cristian

[PATCHv3] pppoe: Lacks DST MAC address check

From: Joakim Tjernlund joakim.tjernl...@transmode.se A pppoe session is identified by its session ID and MAC address. Currently pppoe does not check if the received pkg has the correct MAC address. This is a problem when the eth I/F is in promisc mode as then any DST MAC address is accepted

Re: [PATCH v2] pppoe: Lacks DST MAC address check

On Mon, 2015-04-20 at 14:11 -0400, David Miller wrote: From: Joakim Tjernlund joakim.tjernl...@transmode.se Date: Sat, 18 Apr 2015 11:53:14 +0200 A pppoe session is identified by its session ID and MAC address. Currently pppoe does not check if the received pkg has the correct MAC

[PATCH v2] pppoe: Lacks DST MAC address check

A pppoe session is identified by its session ID and MAC address. Currently pppoe does not check if the received pkg has the correct MAC address. This is a problem when the eth I/F is in promisc mode as then any DST MAC address is accepted. --- v2 - The MAC address check should encompass all pppoe

[PATCH] pppoe: Lacks DST MAC address check

A pppoe session is identified by its session ID and MAC address. Currently pppoe does not check if the received pkg has the correct MAC address. This is a problem when the eth I/F is in promisc mode as then any DST MAC address is accepted. Signed-off-by: Joakim Tjernlund joakim.tjernl

pppoe relay and MAC address filtering

I have create pppoe session over a pppoe relay socket: A B and C are Linux nodes, B impl. a relay socket so that A and B can create a pppoe session: A ifA-ifB0 B ifB1--ifC C Now I noticed that if ifB0 is in promisc mode it picks up other pppoe pkgs which are meant for some other

RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms

On Fri, 2008-01-18 at 17:28 +0530, Aggrwal Poonam wrote: Hello All The TDM driver just now does not have a proper framework. Probably the interface cannot be generalised as such. Hence we could not decide whether it would be right to think of a TDM framework. Infact the interface this TDM

RE: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layerfunctionality

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] abs.org] On Behalf Of Vitaly Bordug Sent: den 6 december 2007 23:51 To: Paul Mackerras Cc: netdev@vger.kernel.org; linuxppc-dev Subject: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY

RE: [PATCH] Increase virtual FIFOs in ucc_geth.

On Tue, 2007-12-11 at 19:51 +0800, Li Yang wrote: -Original Message- From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 6:58 PM To: Li Yang Cc: netdev@vger.kernel.org Subject: RE: [PATCH] Increase virtual FIFOs in ucc_geth. On Tue, 2007

RE: [PATCH] Increase virtual FIFOs in ucc_geth.

On Tue, 2007-12-11 at 17:49 +0800, Li Yang wrote: -Original Message- From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 2:46 AM To: Li Yang-r58472 [EMAIL PROTECTED] Netdev Cc: Joakim Tjernlund Subject: [PATCH] Increase virtual FIFOs in ucc_geth

RE: [PATCH] Increase virtual FIFOs in ucc_geth.

On Tue, 2007-12-11 at 11:11 +0100, Joakim Tjernlund wrote: On Tue, 2007-12-11 at 17:49 +0800, Li Yang wrote: -Original Message- From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 2:46 AM To: Li Yang-r58472 [EMAIL PROTECTED] Netdev Cc: Joakim

RE: [PATCH] Increase virtual FIFOs in ucc_geth.

On Tue, 2007-12-11 at 19:51 +0800, Li Yang wrote: -Original Message- From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 6:58 PM To: Li Yang Cc: netdev@vger.kernel.org Subject: RE: [PATCH] Increase virtual FIFOs in ucc_geth. On Tue, 2007

ucc_geth 10 Mbit/s locks up CPU even though NAPI is enabled

Injecting a 10 MBit/s stream with 64 bytes pkgs locks up my MPC832x CPU even though I got NAPI enabled. Kernel 2.6.23 Any ideas? Jocke -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at

RE: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHYlayer functionality

[SNIP] ^^ the correct solution is to implement arch_initcall function which will create fixed PHYs, and then leave only snprintf(fpi-bus_id, 16, PHY_ID_FMT, 0, *data); part in the fs_enet's find_phy(). Try add something like this to the fsl_soc.c (compile untested): - - - - static int

Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property

On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote: On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote: On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote: fixed-link says: register new Fixed/emulated PHY, i.e. PHY that not connected to the real MDIO bus

Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar forfixed-link property

On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote: fixed-link says: register new Fixed/emulated PHY, i.e. PHY that not connected to the real MDIO bus. Signed-off-by: Vitaly Bordug [EMAIL PROTECTED] Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] ---

RE: [PATCH] Fix ethernet multicast for ucc_geth.

-Original Message- From: Li Yang-r58472 [mailto:[EMAIL PROTECTED] Sent: den 18 oktober 2007 16:24 To: [EMAIL PROTECTED]; Netdev; [EMAIL PROTECTED] Subject: RE: [PATCH] Fix ethernet multicast for ucc_geth. -Original Message- From: Joakim Tjernlund [mailto:[EMAIL

how to set pppoe source mac address?

I have several pppoe i/f's over one eth i/f and I want to set the source mac address used by each pppoe i/f to a unique mac address from user space. Is this possible? If so, how do I do that? Jocke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to

RE: how to set pppoe source mac address?

-Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] Sent: den 21 oktober 2007 19:51 To: Joakim Tjernlund Cc: netdev@vger.kernel.org Subject: Re: how to set pppoe source mac address? Joakim Tjernlund wrote: I have several pppoe i/f's over one eth i/f and I want

[PATCH] Fix ethernet multicast for ucc_geth.

From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17 00:00:00 2001 From: Joakim Tjernlund [EMAIL PROTECTED] Date: Wed, 17 Oct 2007 11:01:44 +0200 Subject: [PATCH] Fix ethernet multicast for ucc_geth. hw_add_addr_in_hash() already swaps byte order, don't do it in ucc_geth_set_multi() too

Multicast problem

I can't get my PowerPC 83xx(eth driver ucc_qeth) board to reply on a multcast ping: ping -t 1 -c 2 224.0.0.1 unless I do ifconfig eth1 promisc and echo 0 /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts I guess I am missing something, but what? Kernel: 2.6.23 Jocke - To unsubscribe from this

RE: Multicast problem

-Original Message- From: David Stevens [mailto:[EMAIL PROTECTED] Sent: den 16 oktober 2007 19:05 To: [EMAIL PROTECTED] Cc: Netdev Subject: Re: Multicast problem If you have icmp_echo_ignore_broadcasts set to 1, it won't respond to multicasts. That should be all you need to do

RE: Multicast problem

-Original Message- From: David Stevens [mailto:[EMAIL PROTECTED] Sent: den 16 oktober 2007 19:05 To: [EMAIL PROTECTED] Cc: Netdev Subject: Re: Multicast problem If you have icmp_echo_ignore_broadcasts set to 1, it won't respond to multicasts. That should be all you need to do

RE: Multicast problem

-Original Message- From: David Stevens [mailto:[EMAIL PROTECTED] Sent: den 16 oktober 2007 21:46 To: Joakim Tjernlund Cc: 'Netdev'; [EMAIL PROTECTED] Subject: RE: Multicast problem dev_mcast and igmp looks: [EMAIL PROTECTED]:/proc/net# m dev_mcast 1eth01

RE: Multicast problem

-Original Message- From: Stephen Hemminger [mailto:[EMAIL PROTECTED] Sent: den 16 oktober 2007 22:13 On Tue, 16 Oct 2007 22:07:35 +0200 Joakim Tjernlund [EMAIL PROTECTED] wrote: -Original Message- From: David Stevens [mailto:[EMAIL PROTECTED] Sent: den 16

RE: Multicast problem

OK, so from all this and earlier mail I think that the device driver don't receive multicast pkgs. Tomorrow I will try the real OSPF test case with promisc mode enabled, se if that works. If so, it means there is a bug in the drivers(ucc_geth.c) set_multicast_list()

RE: raw PF_PACKET protocol selection

-Original Message- From: Herbert Xu [mailto:[EMAIL PROTECTED] Sent: den 9 oktober 2007 05:17 To: [EMAIL PROTECTED] Cc: netdev@vger.kernel.org Subject: Re: raw PF_PACKET protocol selection Joakim Tjernlund [EMAIL PROTECTED] wrote: I trying to open my own raw PF_PACKET

Re: raw PF_PACKET protocol selection

On Tue, 2007-10-09 at 11:13 +0400, Evgeniy Polyakov wrote: On Tue, Oct 09, 2007 at 08:08:22AM +0200, Joakim Tjernlund ([EMAIL PROTECTED]) wrote: Your program works fine here. You did run it as root, right? Yes and ETH_P_ALL is the only protocol that prints anything I am on 2.6.22

Re: raw PF_PACKET protocol selection

On Tue, 2007-10-09 at 11:34 +0400, Evgeniy Polyakov wrote: On Tue, Oct 09, 2007 at 09:27:38AM +0200, Joakim Tjernlund ([EMAIL PROTECTED]) wrote: Did you change eth_type_trans() to catch your proto? Just fond out something: if I redirect my prog like so: ./sniff log and press

Re: raw PF_PACKET protocol selection

On Tue, 2007-10-09 at 12:17 +0400, Evgeniy Polyakov wrote: On Tue, Oct 09, 2007 at 09:51:25AM +0200, Joakim Tjernlund ([EMAIL PROTECTED]) wrote: On Tue, 2007-10-09 at 11:34 +0400, Evgeniy Polyakov wrote: On Tue, Oct 09, 2007 at 09:27:38AM +0200, Joakim Tjernlund ([EMAIL PROTECTED

raw PF_PACKET protocol selection

Hi List I trying to open my own raw PF_PACKET socket to receive pkgs sent to this socket. I can only make ETH_P_ALL protocol work, but then I receive all pkgs and I want pkgs with a specific protocol type. I have tried lots of ETH_P types and none of them work. Naturally I make sure the sender

RE: Fixed PHY regression

-Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: den 9 oktober 2007 01:57 To: David Miller Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org Subject: Re: Fixed PHY regression David Miller wrote: From: Joakim Tjernlund [EMAIL PROTECTED] Date: Mon, 8 Oct 2007

RE: [PATCH] ucc_geth.c, make PHY device optional.

On Tue, 2007-07-03 at 19:38 +0800, Li Yang-r58472 wrote: -Original Message- From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 7:20 PM To: Li Yang-r58472 Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming Subject: RE: [PATCH] ucc_geth.c, make

Re: [PATCH] ucc_geth.c, make PHY device optional.

On Wed, 2007-07-04 at 15:32 +0200, Segher Boessenkool wrote: How about separate autoneg to a property dumb-phy, which indicates the PHY/switch doesn't provide MII register interface. Something like that I suppose. But don't call it dumb phy, nor fake phy, nor anything similar -- there

RE: [PATCH] ucc_geth.c, make PHY device optional.

On Tue, 2007-07-03 at 16:22 +0800, Li Yang-r58472 wrote: -Original Message- From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 3:21 PM To: Li Yang-r58472 Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming Subject: RE: [PATCH] ucc_geth.c, make

[PATCH] ucc_geth.c, make PHY device optional.

This patch makes the PHY optional for ucc_geth.c ethernet driver. This is useful to support a direct mii to mii connection to, for example, a onboard swicth. Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED] [SNIP patch sent last Friday] Since this is my last week before vacation, I

[PATCH] ucc_geth.c, make PHY device optional.

This patch makes the PHY optional for ucc_geth.c ethernet driver. This is useful to support a direct mii to mii connection to, for example, a onboard swicth. Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED] diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index 32bb748..8630294

Re: [PATCH] PHY fixed driver: rework release path and updatephy_id notation

On Sat, 2007-06-09 at 20:21 +0400, Vitaly Bordug wrote: device_bind_driver() error code returning has been fixed. release() function has been written, so that to free resources in correct way; the release path is now clean. Before the rework, it used to cause Device '[EMAIL PROTECTED]:1'

[PATCH]ip_auto_config bug in 2.6.20-rc6

On Thu, 2007-02-01 at 12:26 +0100, Joakim Tjernlund wrote: The following commandline: root=/dev/mtdblock6 rw rootfstype=jffs2 ip=192.168.1.10:::255.255.255.0:localhost.localdomain:eth1:off console=ttyS0,115200 makes ip_auto_config fall back to DHCP and complain IP-Config: Incomplete

RE: [PATCH]ip_auto_config bug in 2.6.20-rc6

-Original Message- From: Thomas Bogendoerfer [mailto:[EMAIL PROTECTED] Sent: 02 February 2007 16:18 To: Jan Engelhardt Cc: Joakim Tjernlund; Netdev; Linux-Kernel Subject: Re: [PATCH]ip_auto_config bug in 2.6.20-rc6 On Fri, Feb 02, 2007 at 02:27:29PM +0100, Jan Engelhardt wrote

ip_auto_config bug in 2.6.20-rc6

The following commandline: root=/dev/mtdblock6 rw rootfstype=jffs2 ip=192.168.1.10:::255.255.255.0:localhost.localdomain:eth1:off console=ttyS0,115200 makes ip_auto_config fall back to DHCP and complain IP-Config: Incomplete network configuration information. depending on if CONFIG_IP_PNP_DHCP

OOPS, bug in geth.c ?

Someone just looped the ethernet in the lab and this happend in my 2.6.19-rc5 when booting. After 180 seconds the system tried to restart but that resulted in another OOPS and so on. Jocke NETDEV WATCHDOG: eth0: transmit timed out Badness in free_irq at kernel/irq/manage.c:353 Call Trace:

latest linux git doesn't compile ucc_geth_phy.c and ucc_geth.c

drivers/net/ucc_geth.c:4083:45: macro INIT_WORK passed 3 arguments, but takes just 2 drivers/net/ucc_geth.c: In function `ucc_geth_open': drivers/net/ucc_geth.c:4083: error: `INIT_WORK' undeclared (first use in this function) drivers/net/ucc_geth.c:4083: error: (Each undeclared identifier is

RE: [PATCH] changes to ucc_geth driver as a result of qe_lib changesand bugfixes

changes due to qe_lib changes include: o removed platform_device code, replaced with of_device o removed typedefs o uint - u32 conversions o removed following defines: QE_SIZEOF_BD, BD_BUFFER_ARG, BD_BUFFER_CLEAR, BD_BUFFER, BD_STATUS_AND_LENGTH_SET, BD_STATUS_AND_LENGTH, and