On 25/08/12 21:37, Tobias Diedrich wrote:
This patchset contains a first cut at adding generic support for
port speed/link advertisement control.
A few days after you posted this patch series, you posted a patch to power
down unconnected ports to save power on the Carambola.
I suddenly thought
On 02/07/11 17:51, Dave Taht wrote:
I note also that SFB and DRR are new schedulers in the 2.6.39 kernels
that may be of interest.
DRR is a lot older than that. I can't directly find when it was added, but I had
vanilla 2.6.31 sources lying around on my hard drive and it contained the DRR
On 02/07/11 21:51, Peter Lebbing wrote:
DRR is a lot older than that. I can't directly find when it was added
Found it. 2.6.29.
http://kernelnewbies.org/Linux_2_6_29
Under Networking.
Peter.
PS: At the risk of a Well duh, didn't you know, does the mailing list strip
CC:'s from mails? I noticed
On 20/05/11 18:06, Jan Willies wrote:
Otherwise cmake programs try to link with host ld.so
+ -DDL_LIBRARY=$(STAGING_DIR) \
Typo alert? It says DL_LIBRARY not LD_LIBRARY which sounds more logical
to me.
(Meanwhile, I've been looking at kpbs for quite a while today, not
On 06/05/11 15:16, John Crispin wrote:
On 06/05/11 15:13, Peter Lebbing wrote:
So, can someone please commit my patch,
http://patchwork.midlink.org/patch/906/ ?
patch looks ok, let me apply it
Problems?
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You
On 09/05/11 16:10, John Crispin wrote:
On 09/05/11 16:01, Peter Lebbing wrote:
Problems?
apart from not liking this rather impolite single word style of
(mis-)communication i think there are no problems.
Oh, I'm very sorry. It was in no way meant to be impolite. It was simply
meant to have
On 09/05/11 17:22, John Crispin wrote:
a very silly question is therer a 2/2 to go with this 1/2 patch ?
That is a patch that I posted to have it available to people, but not for
inclusion in OpenWRT yet.
From my 0/2 mail:
I am submitting for inclusion in OpenWRT the driver for the M
On 09/05/11 17:24, John Crispin wrote:
applied in r26865, thx !
Thanks, great!
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt
Luka Perkov wrote:
Patch tested on D-Link 584T DSL router with ADM6996M chip. Works.
Please commit.
Can I please ask why my patch isn't committed?
Also, what is the Recommended Nag Interval for asking about this? ;P
Peter.
PS: CC'd Felix as the original author of the driver, and possible
] The switch chip can set the link state to down using a custom register bit.
I suppose this is for power-saving, but it is not implemented in the driver.
Signed-off-by: Peter Lebbing pe...@digitalbrains.com
---
This is a respin of my April 14 submission. Trunk has moved on since
On -10/01/37 20:59, Luka Perkov wrote:
I can confirm that the patch here provided is functional. I'm using it
on D-Link 584T DSL router which has ADM6996M chip. Unfortunately the
patch does not apply to the trunk and I made an ugly hack to make the
patch apply.
I did an 'svn up' and then 'svn
Oh, forgot to ask this in my effort to fix the patch:
Is there a reason why the patch has not been applied yet, or is it simply a case
of either hadn't gotten round to it or oops, overlooked it?
If there's a reason why it can't be applied, I'd like to know, so I might fix
it.
Peter.
--
I use
These patches add support for 802.1Q VLANs on ADM6996M and ADM6996FC. It is
called version 3; version 2 wasn't explicitly called as such, but the version I
sent April 3 would be it.
I am submitting for inclusion in OpenWRT the driver for the M chip. Since I
don't have the FC chip, I cannot test
] The switch chip can set the link state to down using a custom register bit.
I suppose this is for power-saving, but it is not implemented in the driver.
Signed-off-by: Peter Lebbing pe...@digitalbrains.com
---
Compared to version 2 of April 3 (which wasn't explicitly called version 2
This patch, when applied on top of [PATCH v3 1/2], will enable VLAN support for
the ADM6996FC. It updates the whole to be identical to the patch I sent in on
April 12, though that patch also includes a board fix for the Ubiquiti
RouterStation PHY masks that is not here. And it was against backfire
On 12/04/11 09:15, Yeoh Chun Yeow wrote:
Unfortunately, the driver that you provided not able to detect the
switch correctly ADM6996FC PHY detected.
I have observed the following:
eth0: PHY overlaps ADM6996, providing fixed PHY 14.
eth1: PHY overlaps ADM6996, providing fixed PHY 10.
Okay,
switch driver
*
+ * swconfig interface based on ar8216.c
+ *
* Copyright (c) 2008 Felix Fietkau n...@openwrt.org
+ * VLAN support Copyright (c) 2010, 2011 Peter Lebbing pe...@digitalbrains.com
*
* This program is free software; you can redistribute it and/or modify it
* under the terms
privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt
/*
* ADM6996 switch driver
*
* swconfig interface based on ar8216.c
*
* Copyright (c) 2008 Felix Fietkau n...@openwrt.org
* VLAN support Copyright (c) 2010, 2011 Peter Lebbing pe...@digitalbrains.com
On 08/04/11 03:20, Yeoh Chun Yeow wrote:
You have any clue which datasheet for FC chip should be referred to. For
me, it seems that it is not similar to F chip or not totally same with M
chip.
I'd love to have a datasheet for the FC chip, but I can't find it.
It would appear the M is an
Hi guys,
Normally, when you access an Ethernet PHY through an MDIO bus, you specify a
5-bit PHY address that selects one of the PHYs attached to the bus, and a 5-bit
register address that addresses a register inside that PHY.
The ADM6996FC and ADM6996M switch chips occupy this full address
On 06/04/11 16:18, Yeoh Chun Yeow wrote:
UBNT RS has two ports connected to eth1, port 0 and port 1. If you
connect your Ethernet cable to port 0 without first connecting Ethernet
cable to port 1, it won't work. You will see a lot of messages Trying
100/FULL, Trying 10/HALF, Trying 10/HALF.
On 05/04/11 08:52, Yeoh Chun Yeow wrote:
Untagged packet receive by port 1 is drop. But VLAN 1 and VLAN 2 tagged
packet for port 0 is working perfertly.
config 'switch_vlan'
option 'device' 'eth1'
option 'vlan' '1'
option 'vid' '1'
option 'ports' '0t 1 5t'
Hi Jonas,
On 06/04/11 13:34, Jonas Gorski wrote:
On 5 April 2011 14:00, Jonas Gorski jonas.gorski+open...@gmail.com wrote:
Probably you should dump the (default) register values of the FC and the M
and compare them and try to find a difference (best if it's some RO
register).
Good
Watch out for the primary VLAN ID; pvid property of the port. swconfig
dev eth1 show is your friend. The PVID might not always be what you
expect. Seeing where untagged packets go is something that needs to be
tested for the FC chip. The M chip is configured such that untagged packets
On 04/04/11 12:59, Yeoh Chun Yeow wrote:
Hi, Peter and David,
I add the following patch and VLAN tagging working fine for UBNT RS:
Interesting find, thanks! Can the port still send *untagged* packets as well, if
you configure untagged membership? When I wrote the driver, I think I explicitly
now declares the dependency on SWCONFIG
- Added copyright message to adm6996.h
- Added myself to MODULE_AUTHOR
Signed-off-by: Peter Lebbing pe...@digitalbrains.com
---
files/drivers/net/phy/adm6996.c | 497 +--
files/drivers/net/phy/adm6996.h | 56
Hi,
On 03/04/11 14:37, Jonas Gorski wrote:
Looking at the datasheet, the chip seems to have Chip ID registers at
A0/A1 (p. 161). You can try to read them in the adm6996_probe and use
them to verify the chip is an ADM6996M (or do chip identification
based on them). At least the ADM6996F
On 01/04/11 03:27, Yeoh Chun Yeow wrote:
Ok I found the script.
read-all-adm output attach.
Thanks very much. It's not vital, but if you still have the setup ready, could
you remove the VLAN related config from your /etc/config/network and run the
script again? It would be helpful if the
On -10/01/37 20:59, Yeoh Chun Yeow wrote:
It seems that ADM6996FC is different from ADM6996M. How to ensure the
port get tagged? Is this by simply modifying Configuration register Bit 4?
It's a lot more involved on the M model. A whole bunch of bits need to be
changed before it works as one
On 31/03/11 17:08, Yeoh Chun Yeow wrote:
Yes, I will do that. By the way, what should I check with debug info?
Nothing needs to be checked. But the read-all-adm script uses a facility in the
driver that is only compiled in when DEBUG is enabled.
It reads the contents of all addressable
On -10/01/37 20:59, John Crispin wrote:
can you post a link to the patch ?
Also using pointers about patchwork use recently posted here, I unearthed my
patch:
http://patchwork.midlink.org/patch/574/
Apparently patchwork thought that my one-line fix superseded a 666-line patch
file :). That
I suppose we need to figure out this chip identification/detection before the
patch can be accepted.
So, David:
- Have you tried using the driver, the VLANs? Did it happen to work, did it fail
catastrophically, dit it just do nothing? :)
- Could you perhaps compile the ADM6996 driver with
On 11/01/11 14:30, David Goodenough wrote:
OK, so does your code check to see if this is an M, or do we need to add that?
Do you think we should have two different drivers, one for the M the other for
the F and L, or can we interweave the code?
The detection and initialization part of the
On 12/01/11 13:19, David Goodenough wrote:
The odd thing is that the current code (before your patch) detects my
ADM6996FC. It does not do much with it, but it detects it.
That is very odd indeed. I did not change the detection. Are you sure it is my
patch that changes the behaviour, and not
On 12/01/11 13:43, David Goodenough wrote:
On Wednesday 12 January 2011, Peter Lebbing wrote:
On 12/01/11 13:19, David Goodenough wrote:
Given that they are do different, perhaps your driver should be named
as the adm6996m.c rather than just adm6996.c, and then we can have
an adm6996fl.c
On 10/01/11 20:32, David Goodenough wrote:
Perhaps I should restate my question, that is unclear. Are there any register
values or other way programatically to tell which of the ADM6996 chips is
being used as the PHY on a particular system?
ADM6996F and ADM6996M are very different. The M is
On 11/01/11 12:49, Peter Lebbing wrote:
The ADM6996F and ADM6996L are accessed through an SPI interface, it seems, the
same bus where the serial config EEPROM is located. I'm not 100% sure of the
protocol used to access the switch chip from the CPU, the datasheet isn't very
definitive
On -10/01/37 20:59, David Goodenough wrote:
http://wwwhome.cs.utwente.nl/~lebbing/Samurai%206M,MX,%20ADM6996M,MX.pdf
Can I ask where you got this datasheet. The only ones I have managed to find
are only viewable through a dreadful web interface. In particular do you
know if there is an
Hello,
On 09/01/11 07:41, Scott Nicholas wrote:
My machine also uses an ADM6996, but there are at least two very
different ones. 6996F and 6996M are two which I came across. Can you
tell me which this is for?
Silly of me to forget to mention this. The datasheet I consulted was for the
that.
Signed-Off by: Peter Lebbing pe...@digitalbrains.com
---
--- backfire/target/linux/generic-2.6/files/drivers/net/phy/adm6996.c.old
2011-01-09 11:18:18.631976648 +0100
+++ backfire/target/linux/generic-2.6/files/drivers/net/phy/adm6996.c
2011-01-09 11:18:51.035975864 +0100
contribution to a community project. Do not
hesitate to point out what I should do differently, if I got something wrong.
Thank you for OpenWRT!
Signed-off-by: Peter Lebbing pe...@digitalbrains.com
---
Index: backfire/target/linux/generic-2.6/files/drivers/net/phy/adm6996.c
41 matches
Mail list logo
