Re: [OpenWrt-Devel] [PATCH 0/2] swconfig: Generic support for port speed/link advertisement control
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 of something. Would it be a good idea to have the possibility to shut down a PHY from the swconfig interface? Perhaps with # swconfig dev rtl8366rb port 0 set adv down This way people can save a bit of power on ports that do exist, but are unconnected in their specific configuration. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] correct fair traffic sharing support in qos-scripts
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 scheduler. I also found this through Google: http://lwn.net/Articles/308351/ Note the date, november 2008. It's not the commit, though. Cheers, 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] correct fair traffic sharing support in qos-scripts
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 it missing on my own previous message, and didn't see a CC: on the other recent messages I checked. -- 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] add LD_LIBRARY to cmake.mk
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 understanding why tc rejected it, before I realised it actually didn't say kbps as I read it.) 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/2] (respin) 802.1Q VLAN support for ADM6996M/ADM6996FC
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 can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/2] (respin) 802.1Q VLAN support for ADM6996M/ADM6996FC
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 the same connotation as Are there any problems with the patch that should be looked at first, but shorter. Perhaps even occupying less of your time while reading it. i was actually just in the process of testing your patch and getting it ready for a commit when i received your motivational email ;) Seeing how quick patch submission - commit messages sometimes ping-pong on the list, I got the impression it was a matter of pressing a button, barring any error messages. So I was somewhat surprised at only having a message let me apply it, and not the actual commit message, and was trying to pose an open question whether it did not work out to satisfaction... Miscommunication is the correct word here. Sorry about that. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/2] (respin) 802.1Q VLAN support for ADM6996M/ADM6996FC
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 chip. Since I don't have the FC chip, I cannot test if it all works as you would expect and hope for that chip. I still include a patch enabling its support, but not for inclusion in OpenWRT just now. If other people feel they have sufficiently tested that the driver works, they are free to submit it for inclusion themselves. I will try to offer support, but it's somewhat limited without hardware :). The whole 0/2 mail can be found at https://lists.openwrt.org/pipermail/openwrt-devel/2011-April/010525.html The 2/2 patch is at http://patchwork.midlink.org/patch/899/, but I feel people should test it more first before it should be included in OpenWRT. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/2] (respin) 802.1Q VLAN support for ADM6996M/ADM6996FC
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/2] (respin) 802.1Q VLAN support for ADM6996M/ADM6996FC
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 committer. -- 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 1/2] (respin) 802.1Q VLAN support for ADM6996M/ADM6996FC
This patch adds 802.1Q VLAN support for the ADM6996M chip. The driver is loaded for both the FC and M model. It will detect which of the two chips is connected. The FC model is initialised, but no further functionality is offered. The PHY driver will always report 100 Mbit/s, link up, for both the M and FC models. This reflects the fact that the link between switch chip and Ethernet MAC is always on[1]. Further documentation can be found in the kernel's Documentation/networking/adm6996.txt Changes compared to the original driver: - Don't mask the Version Number (least significant nibble from Chip Identifier 0, register 0xA0) from the matching code. Since I already had trouble telling the FC and M chips apart, both Version Number 3, I included this field in the match again. - Don't handle port 0 as a WAN port because in my opinion it just makes stuff more complicated to understand and explain. At least on the D-Link DSL-G624T and the Ubiquiti RouterStation, it's just a LAN port anyway. - Don't reset port 4. I changed ADM_PHY_PORTS so only ports 0 through 3 are reset. Port 4 is a special port, the datasheet says its most popular use is as a WAN port :), connected to a second MAC. It can also be used as a regular port. But for instance the Ubiquiti RouterStation indeed uses it connected to a second MAC, and the Generic PHY driver on address 20 decimal fits this purpose well. In that case, it should be the Generic PHY driver handling and thus resetting that port, and the ADM6996 driver should just leave it alone. - Match ONLY on PHY addresses 0-10 inclusive instead of all addresses. The ADM6996 has custom registers in that range, so matching there somewhat prevents register corruption by other drivers (specifically the Generic PHY driver). The driver will only offer VLAN functionality when bound as address 0. Note that the ADM6996 exports standard PHY registers (Generic PHY compatible) on addresses 16 through 20 for ports 0 through 4. Especially address 20 is useful. Ports 0 through 3 are always switch ports and never directly connected to the MII bus of a MAC. - The allocation and initialisation of the adm6996_priv structure is now in config_init() instead of probe(). It is only done for PHY address 0, where it is useful. Also, register_switch() is an additional failure point where the structure should be freed. - Added myself to MODULE_AUTHOR [1] 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 then, and it no longer applied. files/Documentation/networking/adm6996.txt | 110 + files/drivers/net/phy/adm6996.c| 616 +++-- files/drivers/net/phy/adm6996.h| 67 ++- patches-2.6.30/620-phy_adm6996.patch |6 patches-2.6.31/620-phy_adm6996.patch |6 patches-2.6.32/620-phy_adm6996.patch |6 patches-2.6.36/620-phy_adm6996.patch |6 patches-2.6.37/720-phy_adm6996.patch |6 patches-2.6.38/720-phy_adm6996.patch |6 patches-2.6.39/720-phy_adm6996.patch |6 10 files changed, 791 insertions(+), 44 deletions(-) Index: target/linux/generic/patches-2.6.36/620-phy_adm6996.patch === --- target/linux/generic/patches-2.6.36/620-phy_adm6996.patch (revision 26717) +++ target/linux/generic/patches-2.6.36/620-phy_adm6996.patch (working copy) @@ -1,13 +1,15 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -93,6 +93,11 @@ config MICREL_PHY +@@ -93,6 +93,13 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. +config ADM6996_PHY + tristate Driver for ADM6996 switches ++ select SWCONFIG + ---help--- -+Currently supports the ADM6996F switch ++Currently supports the ADM6996FC and ADM6996M switches. ++Support for FC is very limited. + config FIXED_PHY bool Driver for MDIO Bus/PHY emulation with fixed speed/link PHYs Index: target/linux/generic/patches-2.6.37/720-phy_adm6996.patch === --- target/linux/generic/patches-2.6.37/720-phy_adm6996.patch (revision 26717) +++ target/linux/generic/patches-2.6.37/720-phy_adm6996.patch (working copy) @@ -1,13 +1,15 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -98,6 +98,11 @@ config MICREL_PHY +@@ -98,6 +98,13 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. +config ADM6996_PHY + tristate Driver for ADM6996 switches ++ select SWCONFIG + ---help--- -+Currently supports the ADM6996F switch ++Currently supports the ADM6996FC and ADM6996M switches. ++Support for FC is very
Re: [OpenWrt-Devel] [PATCH v3 1/2] 802.1Q VLAN support for ADM6996M/ADM6996FC
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 diff'. In between a compile and test :). But I (manually) modified some patch files called: target/linux/generic/patches-2.6.3?/620-phy_adm6996.patch The modifications were done with editdiff (which invokes rediff). These were correct at the time. But some of these moved to 720 instead of 620, and because of this reorganisation of the patches, their context moved as well. If 'svn up'/'svn diff' and manually editing these patch files is not the way to go, please advise. I've sent in a new patch. What is the proper way to label a respin of a patch? 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/2] 802.1Q VLAN support for ADM6996M/ADM6996FC
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 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 0/2] 802.1Q VLAN support for ADM6996M/ADM6996FC
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 if it all works as you would expect and hope for that chip. I still include a patch enabling its support, but not for inclusion in OpenWRT just now. If other people feel they have sufficiently tested that the driver works, they are free to submit it for inclusion themselves. I will try to offer support, but it's somewhat limited without hardware :). Since a lot more people seem to have FC chips than M chips, the driver I'm not actually submitting for inclusion seems to be the most interesting. So be it. It still exists. If it works well, it can then be included. Many, many thanks for all comments and help on this driver. I have learned a lot about PHYs in Linux :). 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 1/2] 802.1Q VLAN support for ADM6996M/ADM6996FC
This patch adds 802.1Q VLAN support for the ADM6996M chip. The driver is loaded for both the FC and M model. It will detect which of the two chips is connected. The FC model is initialised, but no further functionality is offered. The PHY driver will always report 100 Mbit/s, link up, for both the M and FC models. This reflects the fact that the link between switch chip and Ethernet MAC is always on[1]. Further documentation can be found in the kernel's Documentation/networking/adm6996.txt Changes compared to the original driver: - Don't mask the Version Number (least significant nibble from Chip Identifier 0, register 0xA0) from the matching code. Since I already had trouble telling the FC and M chips apart, both Version Number 3, I included this field in the match again. - Don't handle port 0 as a WAN port because in my opinion it just makes stuff more complicated to understand and explain. At least on the D-Link DSL-G624T and the Ubiquiti RouterStation, it's just a LAN port anyway. - Don't reset port 4. I changed ADM_PHY_PORTS so only ports 0 through 3 are reset. Port 4 is a special port, the datasheet says its most popular use is as a WAN port :), connected to a second MAC. It can also be used as a regular port. But for instance the Ubiquiti RouterStation indeed uses it connected to a second MAC, and the Generic PHY driver on address 20 decimal fits this purpose well. In that case, it should be the Generic PHY driver handling and thus resetting that port, and the ADM6996 driver should just leave it alone. - Match ONLY on PHY addresses 0-10 inclusive instead of all addresses. The ADM6996 has custom registers in that range, so matching there somewhat prevents register corruption by other drivers (specifically the Generic PHY driver). The driver will only offer VLAN functionality when bound as address 0. Note that the ADM6996 exports standard PHY registers (Generic PHY compatible) on addresses 16 through 20 for ports 0 through 4. Especially address 20 is useful. Ports 0 through 3 are always switch ports and never directly connected to the MII bus of a MAC. - The allocation and initialisation of the adm6996_priv structure is now in config_init() instead of probe(). It is only done for PHY address 0, where it is useful. Also, register_switch() is an additional failure point where the structure should be freed. - Added myself to MODULE_AUTHOR [1] 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), the changes are: - Detect and tell apart M and FC chip. Thanks everybody! - Handling of PHY addresses as explained above - Added Documentation/networking/adm6996.txt - Don't set PVID of port 0 to ID 1 (handle port 0 as WAN port from above) - Use ADM6996_PHY_PORTS as the number of PHYs of the switch chip to handle instead of the total number of ports (I suppose I initially misunderstood its use, this seems to make more sense) - Additionally define ADM6996_NUM_PORTS to mean the total number of ports - Fixed bug where an apply invocation with enable_vlan = 0 and vlan_enabled = 0 would still set VLAN filters. - Implement reset; the ADM6996 chip doesn't seem to offer a software-initiated reset, see adm6996.txt. - Invoke unregister_switch() in adm6996_remove files/Documentation/networking/adm6996.txt | 110 + files/drivers/net/phy/adm6996.c| 616 +++-- files/drivers/net/phy/adm6996.h| 67 ++- patches-2.6.30/620-phy_adm6996.patch |6 patches-2.6.31/620-phy_adm6996.patch |6 patches-2.6.32/620-phy_adm6996.patch |6 patches-2.6.35/620-phy_adm6996.patch |6 patches-2.6.36/620-phy_adm6996.patch |6 patches-2.6.37/620-phy_adm6996.patch |6 patches-2.6.38/620-phy_adm6996.patch |6 patches-2.6.39/620-phy_adm6996.patch |6 11 files changed, 795 insertions(+), 46 deletions(-) Index: target/linux/generic/patches-2.6.35/620-phy_adm6996.patch === --- target/linux/generic/patches-2.6.35/620-phy_adm6996.patch (revision 26657) +++ target/linux/generic/patches-2.6.35/620-phy_adm6996.patch (working copy) @@ -1,13 +1,15 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -93,6 +93,11 @@ config MICREL_PHY +@@ -93,6 +93,13 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. +config ADM6996_PHY + tristate Driver for ADM6996 switches ++ select SWCONFIG + ---help--- -+Currently supports the ADM6996F switch ++Currently supports the ADM6996FC and ADM6996M switches. ++Support for FC is very limited. + config FIXED_PHY bool Driver for MDIO Bus/PHY emulation with fixed speed/link
[OpenWrt-Devel] [PATCH v3 2/2] 802.1Q VLAN support for ADM6996M/ADM6996FC
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 instead of trunk. /Please do not include this in OpenWRT just yet/ I cannot test the functionality on the FC chip myself. Yeoh Chun Yeow reported it works. He figured out the register bit to set so untagged and tagged memberships both work, albeit not simultaneously on the same switch port. Things that I think should be tested are, for example: - Do all combinations of VLAN table entry and VLAN ID work? I.e., does the vid property of a VLAN entry work and can it be set to anything in the range 0 through 1023 without limitations. Obviously I'm not advocating trying out all sixteen thousand possible combinations :). - Handling of VLAN ID 0, 1 and 1023. These have the possibility to be handled specially on these chips. More in general, VLAN ID 0 is often a default one and Linux even warns you about using VLAN ID 1. I'm not sure about the status of VID 1023, but it might be considered invalid by some or a lot of devices. So it makes sense to scrutinise these three IDs further to see that they don't do unexpected, unwanted stuff. The M chip handles VID 0, 1 and 1023 like any other. AFAIK obviously. - Unexpected VIDs. What happens when a tagged packet comes in for a VLAN ID not configured in the switch? What happens when a tagged packet comes in with a VLAN ID that is in use on the switch, but the incoming port is not member of that VLAN? What happens when an untagged packet comes in and the Primary VLAN ID is set to an unconfigured VLAN or a VLAN of which the port is not a member? In all these cases, the M chip drops the packet (source port filtering). - How is the 802.1p priority field handled? The M chip will pass through the priority field of the incoming packet. If the incoming packet was untagged, the priority is set to 0. - Enabling and disabling VLAN support: its effect on switch behaviour. The two bugs in my original code where related to disabling the VLAN (enable_vlan set to 0). At least I fell in the pit of testing all functionality, and not testing the absence of functionality, in a way. The second bug, where VLAN filters were being set even though enable_vlan = 0, had the potential of corrupting non-VLAN switching behaviour through 'swconfig set vlan X ports' statements that should have no effect with enable_vlan = 0 but did have an effect. I haven't tested it, but I'm fairly sure they would have changed the switch's behaviour. --- files/Documentation/networking/adm6996.txt | 20 +- files/drivers/net/phy/adm6996.c| 87 - patches-2.6.30/620-phy_adm6996.patch |3 - patches-2.6.31/620-phy_adm6996.patch |3 - patches-2.6.32/620-phy_adm6996.patch |3 - patches-2.6.35/620-phy_adm6996.patch |3 - patches-2.6.36/620-phy_adm6996.patch |3 - patches-2.6.37/620-phy_adm6996.patch |3 - patches-2.6.38/620-phy_adm6996.patch |3 - patches-2.6.39/620-phy_adm6996.patch |3 - --- target/linux/generic/patches-2.6.35/620-phy_adm6996.patch (working copy) +++ target/linux/generic/patches-2.6.35/620-phy_adm6996.patch (working copy) @@ -1,6 +1,6 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -93,6 +93,13 @@ config MICREL_PHY +@@ -93,6 +93,12 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. @@ -9,7 +9,6 @@ + select SWCONFIG + ---help--- +Currently supports the ADM6996FC and ADM6996M switches. -+Support for FC is very limited. + config FIXED_PHY bool Driver for MDIO Bus/PHY emulation with fixed speed/link PHYs --- target/linux/generic/patches-2.6.36/620-phy_adm6996.patch (working copy) +++ target/linux/generic/patches-2.6.36/620-phy_adm6996.patch (working copy) @@ -1,6 +1,6 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -93,6 +93,13 @@ config MICREL_PHY +@@ -93,6 +93,12 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. @@ -9,7 +9,6 @@ + select SWCONFIG + ---help--- +Currently supports the ADM6996FC and ADM6996M switches. -+Support for FC is very limited. + config FIXED_PHY bool Driver for MDIO Bus/PHY emulation with fixed speed/link PHYs --- target/linux/generic/patches-2.6.37/620-phy_adm6996.patch (working copy) +++ target/linux/generic/patches-2.6.37/620-phy_adm6996.patch (working copy) @@ -1,6 +1,6 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -92,6 +92,13 @@ config MICREL_PHY +@@ -92,6 +92,12 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. @@ -9,7 +9,6 @@ + select SWCONFIG +
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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, I could have seen that one coming. Fortunately, it's not that my detection code does not work. It's that the driver wishes to be addressed as address 0, and I forgot that your WAN_PHYMASK and LAN_PHYMASK are set differently. I should also add 0x before the 14 and 10, I got confused with decimal for a moment :). It's 16 and 20 decimal. David already gave the vital piece of information: eth0 is connected to port 4 of the switch. I'll send you a different driver soon, which hopefully completely fixes the problem. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
+ default value. But there are a lot of registers in the chip that the driver
+ does not support. If something changed those registers, invoking 'reset' or
+ performing a warm reboot might still leave the chip in a broken state. Only
+ a hardware reset will bring it back in the default state.
+
+2. ADM6996FC specific information
+
+ A port can be:
+- either an untagged member of exactly one VLAN,
+- or a tagged member of one or more VLANs.
+
+ So a mix of untagged and tagged like the M model supports is not possible.
+ When you isssue a 'vlan X set ports' swconfig command, any existing port
+ membership for the ports will be adjusted to meet these constraints. For
+ clarity and your own sanity, I strongly recommend you obey those constraints
+ yourself while defining membership. 'swconfig dev ethX show' will always show
+ the state that will be set once applied, so there it is What You See Is What
+ You Get.
+
+3. Technical details on PHYs and the ADM6996
+
+ From the viewpoint of the Linux kernel, it is common that an Ethernet adapter
+ can be seen as a separate MAC entity and a separate PHY entity. The PHY entity
+ can be queried and set through registers accessible via an MDIO bus. A PHY
+ normally has a single address on that bus, in the range 0 through 31.
+
+ The ADM6996 has special-purpose registers in the range of PHYs 0 through 10.
+ Even though all these registers control a single ADM6996 chip, the Linux
+ kernel treats this as 11 separate PHYs. The driver will bind to these
+ addresses to prevent a different PHY driver from binding and corrupting these
+ registers.
+
+ What Linux sees as the PHY on address 0 is meant for the Ethernet MAC
+ connected to the CPU port of the ADM6996 switch chip (port 5). This is the
+ Ethernet MAC you will use to send and receive data through the switch.
+
+ The PHYs at addresses 16 through 20 map to the PHYs on ports 0 through 4 of
+ the switch chip. These can be accessed with the Generic PHY driver, as the
+ registers have the common layout.
+
+ If a second Ethernet MAC on your board is wired to the port 4 PHY, that MAC
+ needs to bind to PHY address 20 for the port to work correctly.
+
+ The ADM6996 switch driver will reset the ports 0 through 3 on startup and when
+ 'reset' is invoked. This could clash with a different PHY driver if the kernel
+ binds a PHY driver to address 16 through 19.
+
+ If Linux binds a PHY on addresses 1 through 10 to an Ethernet MAC, the ADM6996
+ driver will simply always report a connected 100 Mbit/s full-duplex link for
+ that PHY, and provide no other functionality. This is most likely not what you
+ want. So if you see a message in your log
+
+ ethX: PHY overlaps ADM6996, providing fixed PHY yy.
+
+ This is most likely an indication that ethX will not work properly, and your
+ kernel needs to be configured to attach a different PHY to that Ethernet MAC.
+
+ Controlling the mapping between MACs and PHYs is usually done in platform- or
+ board-specific fixup code. The ADM6996 driver has no influence over this.
Index: target/linux/generic-2.6/files/drivers/net/phy/adm6996.c
===
--- target/linux/generic-2.6/files/drivers/net/phy/adm6996.c (revision 26505)
+++ target/linux/generic-2.6/files/drivers/net/phy/adm6996.c (working copy)
@@ -1,12 +1,17 @@
/*
* 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
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License v2 as published by the
* Free Software Foundation
*/
+
+/*#define DEBUG 1*/
#include linux/kernel.h
#include linux/string.h
#include linux/errno.h
@@ -24,6 +29,7 @@
#include linux/mii.h
#include linux/ethtool.h
#include linux/phy.h
+#include linux/switch.h
#include asm/io.h
#include asm/irq.h
@@ -31,28 +37,59 @@
#include adm6996.h
MODULE_DESCRIPTION(Infineon ADM6996 Switch);
-MODULE_AUTHOR(Felix Fietkau);
+MODULE_AUTHOR(Felix Fietkau, Peter Lebbing pe...@digitalbrains.com);
MODULE_LICENSE(GPL);
+enum adm6996_model {
+ ADM6996FC,
+ ADM6996M
+};
+
+static const char * const adm6996_model_name[] =
+{
+ ADM6996FC,
+ ADM6996M
+};
+
struct adm6996_priv {
+ struct switch_dev dev;
+ struct phy_device *phydev;
+
+ enum adm6996_model model;
+
+ bool enable_vlan;
+ bool vlan_enabled; /* Current hardware state */
+
+#ifdef DEBUG
+ u16 addr; /* Debugging: register address to operate on */
+#endif
+
+ u16 pvid[ADM_NUM_PORTS]; /* Primary VLAN ID */
+
+ u16 vlan_id[ADM_NUM_VLANS];
+ u8 vlan_table[ADM_NUM_VLANS]; /* bitmap, 1 = port is member */
+ u8 vlan_tagged[ADM_NUM_VLANS]; /* bitmap, 1 = tagged member */
+
+ struct mutex reg_mutex;
+
/* use abstraction for regops, we want to add gpio support in the future */
u16 (*read)(struct
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
On 11/04/11 11:08, Yeoh Chun Yeow wrote:
However, even the board is up without Ethernet cable connecting to the LAN
port 1 or port 0, the message eth1: link up (100Mbps/Full duplex) is
already printed there.
Yeah, it's still not completely clear to me how these ports are all connected.
If one of the Ethernet MACs is connected to the switch, and it would not make
sense if that was not the case, then that port will immediately go up.
You can compare this with the case where you have an external switch. The only
difference is that the switch is integrated in your RouterStation, and you can
actually talk to the switch to make it do interesting stuff.
If you would have an external switch, there would be a cable between your
Ethernet device eth1 and the switch. On the switch, there are two more ports,
which are the two sockets on your RouterStation. As soon as eth1 is started, it
will go up, because it is connected to the switch. It does not matter if you
plug any other cables into the switch. If there are no other cables plugged into
the switch, your eth1 is still connected to the switch and the link for eth1 is
up. It's just that any packets you send don't go anywhere because no other
devices are connected to the switch.
You can't even see if any other cables are plugged into the switch without
writing specific support code to check for this, just like you wouldn't see in
your log whether any other cables are plugged into the external switch.
It gets really confusing when the ports you call port 0 and port 1 aren't
numbered the same on the switch chip. Like I mentioned somewhere before, port 0
on my switch chip is connected to the port labeled LAN 4 on my router. Port 1
is LAN 3, 2 is LAN 2, 3 is LAN 1. The only thing you can reasonably expect
is that your CPU is connected on port 5.
So I wrote a kludge that indeed checks the link state of the attached ports.
Could you please use the attached driver and map which sockets on your board
connect to which switch ports? If you do
# swconfig dev eth1 get link_state
It will answer with a list of ports that are up. Please connect and disconnect
cables to the three Ethernet sockets on your board and note the effect on that
link_state list.
I suspect your WAN port might be connected to port 4 of the switch. This is a
bit of a special port on the switch chip.
The attached driver also checks the chip model. I really hope your log says
ADM6996FC PHY detected. Could you send me the whole log of your RouterStation?
It might give me some more clues on how stuff is connected.
HTH,
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
/*
* 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
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License v2 as published by the
* Free Software Foundation
*/
#define DEBUG 1
#include linux/kernel.h
#include linux/string.h
#include linux/errno.h
#include linux/unistd.h
#include linux/slab.h
#include linux/interrupt.h
#include linux/init.h
#include linux/delay.h
#include linux/netdevice.h
#include linux/etherdevice.h
#include linux/skbuff.h
#include linux/spinlock.h
#include linux/mm.h
#include linux/module.h
#include linux/mii.h
#include linux/ethtool.h
#include linux/phy.h
#include linux/switch.h
#include asm/io.h
#include asm/irq.h
#include asm/uaccess.h
#include adm6996.h
MODULE_DESCRIPTION(Infineon ADM6996 Switch);
MODULE_AUTHOR(Felix Fietkau, Peter Lebbing pe...@digitalbrains.com);
MODULE_LICENSE(GPL);
struct adm6996_priv {
struct switch_dev dev;
struct phy_device *phydev;
bool enable_vlan;
bool vlan_enabled; /* Current hardware state */
#ifdef DEBUG
u16 addr; /* Debugging: register address to operate on */
#endif
u16 pvid[ADM_PHY_PORTS]; /* Primary VLAN ID */
u16 vlan_id[ADM_NUM_VLANS];
u8 vlan_table[ADM_NUM_VLANS]; /* bitmap, 1 = port is member */
u8 vlan_tagged[ADM_NUM_VLANS]; /* bitmap, 1 = tagged member */
struct mutex reg_mutex;
/* use abstraction for regops, we want to add gpio support in the future */
u16 (*read)(struct phy_device *phydev, enum admreg reg);
void (*write)(struct phy_device *phydev, enum admreg reg, u16 val);
};
#define to_adm(_dev) container_of(_dev, struct adm6996_priv, dev)
#define phy_to_adm(_phy) ((struct adm6996_priv *) (_phy)-priv)
static inline u16
r16(struct phy_device *pdev, enum admreg reg)
{
return phy_to_adm(pdev)-read(pdev, reg);
}
static inline void
w16(struct phy_device *pdev, enum admreg reg, u16 val)
{
phy_to_adm(pdev)-write(pdev, reg, val);
}
static u16
adm6996_read_mii_reg(struct phy_device *phydev, enum admreg reg)
{
return phydev-bus-read(phydev-bus, PHYADDR(reg
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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 enhanced version of the FC chip. They are very similar, but the M has some functionality the FC doesn't. The F chip seems to be a different chip altogether. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Handling a PHY that spans multiple PHY addresses
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 space: there
are 1024 register addresses spanning this whole space.
But the Linux PHY layer is built on the assumption that the 32 PHY addresses
address distinct, independent devices. It will try to enumerate all attached
PHYs, and is happy to attach a Generic PHY driver inside the address space of
the ADM6996 chip, for instance.
So I'm wondering what is the best way to handle this odd case elegantly, and
prevent corruption of the ADM6996 registers. I can see several ways to handle
stuff, but I'm not sure what is the best way that will work for everybody, or a
least the great majority.
The hardware I'm developing on is based on the TI TNETD7300AZDW, an AR7 device
with two Ethernet MACs. I think they share the MDIO bus. On my device, the
second Ethernet MAC appears not to be connected to anything.
Using the original ADM6996 driver as it is in backfire, this is the kernel log
output:
cpmac-mii: probed
eth%d: ADM6996 PHY driver attached.
cpmac: device eth0 (regs: 08612800, irq: 41, phy: 1:00, mac: 00:17:9a:d6:00:00)
eth%d: ADM6996 PHY driver attached.
cpmac: device eth1 (regs: 0861, irq: 27, phy: 1:1f, mac: 00:17:9a:d6:00:00)
PHY: 1:00 - Link is Up - 100/Full
(It seems the eth* device is not yet fully initialised when the PHY is
initialised. This might explain the %d.)
The problem here is that both MACs are now attached to the switch chip. But it's
the same switch chip. I simply do not touch eth1 as it is not connected anyway.
But you can get the switch chip in some pretty strange states if you start
mucking about with both eth0 and eth1.
To fix it, the ADM6996 driver could simply only provide config_aneg() and
read_status() to any request for a PHY with address 1 through 31. This is how I
currently chose to handle it.
Alternatively, if you change the _fixup routine of the ADM6996 driver to only
match PHY address 0, which initially seems a good way to fix it, you get a
different problem:
adm6996_fixup(struct phy_device *dev)
{
if (dev-addr != 0)
return 0;
...
Now the log reads:
cpmac-mii: probed
eth%d: ADM6996 PHY driver attached.
cpmac: device eth0 (regs: 08612800, irq: 41, phy: 1:00, mac: 00:17:9a:d6:00:00)
cpmac: device eth1 (regs: 0861, irq: 27, phy: 1:1f, mac: 00:17:9a:d6:00:00)
PHY: 1:00 - Link is Up - 100/Full
Note how it still says phy: 1:1f for eth1. And after adding some debugging
statements to the cpmac driver, it turns out it has attached a Generic PHY to
1:1f. This generic driver will happily poke around in standardised registers on
the PHY bus which map to non-standard registers in the ADM6996 and have the
potential to really screw stuff up.
I couldn't find a way to have _fixup() properly prevent the kernel from binding
a Generic PHY driver to other PHY addresses.
I noticed the phy_map array in struct mii_bus, and how it is used in
phy_device_register(). This led me to write the following in adm6996_probe:
adm6996_probe(struct phy_device *pdev)
{
int i;
if (pdev-addr == 0) {
// Place us on addresses 1-31 as well
for (i = 1; i 32; i++) {
if (pdev-bus-phy_map[i] == NULL)
pdev-bus-phy_map[i] = pdev;
else
pr_warning (ADM6996: other PHY found on
conflicting address %d!\n, i);
}
}
...
Now the log reads:
cpmac-mii: probed
eth%d: ADM6996 PHY driver attached.
cpmac: device eth0 (regs: 08612800, irq: 41, phy: 1:00, mac: 00:17:9a:d6:00:00)
PHY 1:1f not found
eth%d: Could not attach to PHY
PHY: 1:00 - Link is Up - 100/Full
eth1 is never initialised. This is fine for me: it is not connected anyway.
But on other hardware, it might make more sense to offer something akin to a
fixed PHY to the Ethernet MAC, simulating a PHY. Unfortunately fixed.c
implements a Fixed MDIO bus rather than a single PHY. I'm not sure how to
interface to that.
So, do you have any ideas on the best way to properly handle this PHY that looks
like 32 PHYs?
Thanks,
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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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. Once you connect port 1 with Ethernet cable, you will only see the message eth1: link up (100Mbps/Full duplex) and the port 0 will function properly. Do you know why? So the two ports 0 and 1 are attached to the switch chip ports with those numbers? It seems to me this is some interesting interaction between the switch chip driver and the drivers for your System-on-Chip containing the Ethernet MACs. Those messages about 10/HALF etcetera are, AFAIK, related to querying the PHYs connected to an Ethernet MAC for link state. But if the ADM6996 switch driver is queried for link state, it will invariably return 100 Mbit/s full duplex and link up (function adm6996_read_status). This was already the case before I implemented VLAN functionality, by the way. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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' config 'switch_vlan' option 'device' 'eth1' option 'vlan' '2' option 'vid' '2' option 'ports' '0t 1 5t' It works for me; I just tried it. But it is a curious setup. Did you do it just to test the functionality? Having untagged membership of two VLANs is a nice corner case that might have some use, but is definitely not normal. Since it does work on the M chip, I left it in for those cases where it might be useful. But if it doesn't work on the FC chip, I would just throw the possibility out in the driver once we can differentiate between the two chips. Working for both VLAN tagged and untagged packet. config 'switch_vlan' option 'device' 'eth1' option 'vlan' '1' option 'vid' '1' option 'ports' '0t 5t' config 'switch_vlan' option 'device' 'eth1' option 'vlan' '2' option 'vid' '2' option 'ports' '1 5t' Good to hear a more usual setup does work. I assume this is with the patch you sent earlier? In that case the common case where a port has both untagged and tagged memberships fails, right? 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 coming in on a port are only accepted if the port is a member of its PVID, and sent out to other members of that VLAN. If a port is not a member of the VLAN that is in its PVID, the packets are dropped (i.e., source port filtering, both for tagged and untagged packets). Note that it doesn't matter if a port is a tagged or untagged member of a VLAN, just if it is a member at all. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 candidates are the Queue Weight/IGMP registers 0x25 to 0x27 - The bits 12 to 15 are read only on the FC, but writable on the M, so a test if they can be modified should tell whether it's a FC. Also the registers default to 0x2000/4000/8000 on the FC, while the default on the M is 0x1000 for all three. Thank you! Now we're really getting somewhere! I must say: they can create 4 billion Chip Identifiers in a 32-bit ID, did ADMtek /really/ have to use the same ID for the two chips? ;) Any chance that you can get a datasheet for the FC chip? It would help implementing FC functionality a lot. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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 coming in on a port are only accepted if the port is a member of its PVID, and sent out to other members of that VLAN. If a port is not a member of the VLAN that is in its PVID, the packets are dropped (i.e., source port filtering, both for tagged and untagged packets). Note that it doesn't matter if a port is a tagged or untagged member of a VLAN, just if it is a member at all. Is this mechanism worked for M chip? Anyone can confirm whether FC chip has such capabilities? It works as I described on the M chip. It was suggested (by Jonas I believe) that the FC might not have the possibility to use both untagged and tagged membership on the same port. With regard to the filtering capabilities, no idea. I plan to implement identification of M and FC chips and having the driver behave differently for the chips. I suggest I initially submit a driver for inclusion in OpenWRT that only works for the M chip. I feel I have sufficiently tested that target that it ought to work for people with an M chip. It is unfortunate that nobody else appears to have it :). And then, I could have the driver support the FC chip in a manner where a port is either member of one or more tagged VLANs or member of exactly one untagged VLAN, since that is a configuration that appears to work for you, with your patch. You could then test that driver. I don't really feel comfortable submitting a driver for inclusion in OpenWRT for a device I do not have myself, but obviously you or someone else is free to submit that version. It's GPL after all :). Apparently there are a lot more people with FC chips. Having this functionality I intend to implement is already a great start, I suppose. Perhaps the FC can be coaxed to do more stuff as well. If somebody has better ideas on how to handle this properly and to everybody's satisfaction, feel free to offer a suggestion. Peter. PS: Not sure on how long it will take me to produce the two versions of the driver. We'll just have to see when it's ready. -- 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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 chose not to set this bit, and it was unneeded for my M chip. Perhaps it means ALWAYS send tagged packets, but I would need to check that, it's just a hunch. I don't have the time right now. The only problem nows is the port 1 is activated after port 0 is plugged with cable. Any idea how to solve this? Could you elaborate a bit? I don't quite understand what you mean with 'activated'. DO you see some message in a log or in the output of some command? One more thing if I try the following /etc/config/network config 'switch' option 'name' 'eth1' option 'reset' '1' option 'enable_vlan' '1' option 'enable' '1' config 'switch_vlan' option 'device' 'eth1' option 'vlan' '1' option 'vid' '1' option 'ports' '0 1 5t' config 'switch_vlan' option 'vlan' '2' option 'vid' '2' option 'ports' '0t 1t 5t The VLAN 2 is not working, any idea why? You forgot option device eth1 in the vlan 2 definition. I assume the missing quote on the end of the last line is a copy-paste mistake. By the way, you don't strictly need to supply vid. The default is that it is the same as the 'vlan' entry. You could decide to include it for robustness against manual tinkering, though. Peter. PS: Accidentally replied only to Yeoh. Yeoh, please throw that one away for thread and reference continuity :). -- 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
could oyu resent the all in one patch to the list so patchwork grabs the
full version, currently only the fix is listed in patchwork
A new version of the patch.
Please note it is a patch on latest backfire. The patch should apply to
trunk, but the directory generic-2.6 was renamed to generic!
This driver implements support for 802.1Q VLANs. It is written for the
ADM6996M switch chip, but there are currently problems with the chip
detection. It also triggers on other ADM6996 models, and before this patch
can be committed, it needs to be figured out how to avoid people getting a
driver autoloaded that is not suitable for their switch hardware.
Please see the mailing list thread that starts at
https://lists.openwrt.org/pipermail/openwrt-devel/2011-January/009100.html
for details.
Changes compared to the original patch submission:
- mutex handling bugfix patch incorporated
- Kconfig 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 +++
patches-2.6.32/620-phy_adm6996.patch |3
3 files changed, 536 insertions(+), 20 deletions(-)
Index: backfire/target/linux/generic-2.6/files/drivers/net/phy/adm6996.c
===
--- backfire/target/linux/generic-2.6/files/drivers/net/phy/adm6996.c
(revision 26437)
+++ backfire/target/linux/generic-2.6/files/drivers/net/phy/adm6996.c
(working copy)
@@ -1,12 +1,18 @@
/*
* 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
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License v2 as published by the
* Free Software Foundation
*/
+
+/*#define DEBUG 1 */
+
#include linux/kernel.h
#include linux/string.h
#include linux/errno.h
@@ -24,6 +30,7 @@
#include linux/mii.h
#include linux/ethtool.h
#include linux/phy.h
+#include linux/switch.h
#include asm/io.h
#include asm/irq.h
@@ -31,28 +38,46 @@
#include adm6996.h
MODULE_DESCRIPTION(Infineon ADM6996 Switch);
-MODULE_AUTHOR(Felix Fietkau);
+MODULE_AUTHOR(Felix Fietkau, Peter Lebbing pe...@digitalbrains.com);
MODULE_LICENSE(GPL);
struct adm6996_priv {
+ struct switch_dev dev;
+ struct phy_device *phydev;
+
+ bool enable_vlan;
+ bool vlan_enabled; /* Current hardware state */
+
+#ifdef DEBUG
+ u16 addr; /* Debugging: register address to operate on */
+#endif
+
+ u16 pvid[ADM_PHY_PORTS];/* Primary VLAN ID */
+
+ u16 vlan_id[ADM_NUM_VLANS];
+ u8 vlan_table[ADM_NUM_VLANS]; /* bitmap, 1 = port is member */
+ u8 vlan_tagged[ADM_NUM_VLANS]; /* bitmap, 1 = tagged member */
+
+ struct mutex reg_mutex;
+
/* use abstraction for regops, we want to add gpio support in the
future */
u16 (*read)(struct phy_device *phydev, enum admreg reg);
void (*write)(struct phy_device *phydev, enum admreg reg, u16 val);
};
-#define to_adm(_phy) ((struct adm6996_priv *) (_phy)-priv)
+#define to_adm(_dev) container_of(_dev, struct adm6996_priv, dev)
+#define phy_to_adm(_phy) ((struct adm6996_priv *) (_phy)-priv)
-
static inline u16
r16(struct phy_device *pdev, enum admreg reg)
{
- return to_adm(pdev)-read(pdev, reg);
+ return phy_to_adm(pdev)-read(pdev, reg);
}
static inline void
w16(struct phy_device *pdev, enum admreg reg, u16 val)
{
- to_adm(pdev)-write(pdev, reg, val);
+ phy_to_adm(pdev)-write(pdev, reg, val);
}
@@ -68,27 +93,474 @@
phydev-bus-write(phydev-bus, PHYADDR(reg), val);
}
+static int
+adm6996_set_enable_vlan(struct switch_dev *dev, const struct switch_attr *attr,
+ struct switch_val *val)
+{
+ struct adm6996_priv *priv = to_adm(dev);
-static int adm6996_config_init(struct phy_device *pdev)
+ if (val-value.i 1)
+ return -EINVAL;
+
+ priv-enable_vlan = val-value.i;
+
+ return 0;
+};
+
+static int
+adm6996_get_enable_vlan(struct switch_dev *dev, const struct switch_attr *attr,
+ struct switch_val *val)
{
+ struct adm6996_priv *priv = to_adm(dev);
+
+ val-value.i = priv-enable_vlan;
+
+ return 0;
+};
+
+#ifdef DEBUG
+
+static int
+adm6996_set_addr(struct switch_dev *dev, const struct switch_attr *attr,
+struct switch_val *val)
+{
+ struct adm6996_priv *priv = to_adm(dev);
+
+ if (val-value.i 1023)
+ return -EINVAL;
+
+ priv-addr = val-value.i;
+
+ return 0;
+};
+
+static int
+adm6996_get_addr(struct switch_dev *dev, const struct switch_attr *attr
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 datasheet has a different content in its Chip ID register (assuming the 32bit register at 0x00 corresponds to the two 16 bit registers). Yeah, that's the whole problem. If I look at the datasheets I can find about the F model, it would seem the chip identification will not match at all. In practice, it turns out people with a chip labeled as FC have a register set very similar to what is in the M datasheet, *including* Chip Identification on A0h/A1h with value 0007:1023h! Read the thread for more details and a good deal of confusion. The Chip ID is read in the _fixup routine, because it is a non-standard method of identification. Normally, PHYs are identified differently. By the way, I didn't write the chip detection. Ironically, it was written to match the F model :). 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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 driver didn't configure VLANs before running the register dumping script. Other than that, I've had a quick look, and it doesn't make me happy. First and foremost, the product ID for the FC and M chips is identical down to the last bit! They reserve a whopping 32 bits for a Chip Identifier and still they both read 0007:1023! So there doesn't seem to be a standard way to tell the chips apart. And they do seem to differ, which makes sense. There is a lot in common. I could really use the datasheet for the -FC variant, but all the so-called datasheets for that chip I've found describe a completely different device. I even get the impression that the values read from your chip aren't the power-on-reset default values. Perhaps there's an EEPROM attached with settings specific to your router. I do see one possibility for hope. Maybe Infineon at some point stopped producing the real FC variant described in those datasheets I found, and from then on simply relabeled their M chip and sold that as the FC variant. Discrepancies in default values could be explained by an EEPROM with router-specific settings. Thanks for your help, 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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 would expect. Okay, perhaps as I would expect. 2. VLAN separation is alright but VLAN tagging is not working. I am using the following: config 'switch' option 'name' 'eth1' option 'reset' '1' This is a point for the documentation to be written: the ADM6996 appears to have no possibility to reset. The reset swconfig option is a no-op. option 'enable_vlan' '1' option 'enable' '1' config 'switch_vlan' option 'device' 'eth1' option 'vlan' '1' option 'vid' '1' option 'ports' '0t 1t 5t' Tag and No Tag on the port, I am still able to PING a host without VLAN tagging. It means that the VLAN tagging is not working. I just did a quick test, and it confirmed my suspicion. At least Windows 7 couldn't care less if incoming packets are VLAN tagged, it processes them equally to untagged packets. I can ping fine from a switch port that only sends tagged packets to the Windows box. Not unexpected, my Linux box is more picky and drops VLAN tagged packets when VLANs aren't configured. So it depends on the OS you use to test. On a Linux box, you can get a lot more info with, for example: # tcpdump -eni eth0 The -e argument says to print the link-level header. Without it, tcpdump won't give an indication that the incoming packet is VLAN tagged. Furthermore, watch out that the numbering printed beneath the ports on your router doesn't necessarily correspond to the numbering in the switch chip. On my router, the port labeled LAN 1 is connected to switch port 3, for example. HTH, 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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 registers into the file named regs. This direct register addressing via the swconfig utility is only compiled in with DEBUG. By the way, you will need to manually select the SWCONFIG item (Switch configuration API) in PHY Device support (...) in the kernel configuration. The fact that the ADM6996 driver depends on this is not included in my initial patch. Obviously this needs to be fixed before the patch can be committed; but the problem with FC versus M models is a show stopper for now anyway. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
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 would be a really impressive one-liner. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 #define DEBUG 1, and run the attached script on your device. It dumps all the MDIO-accessible registers. I'd like to see what it is like on your device. Especially because of the Chip Identifier register, which the driver tries to use to determine if a compatible chip is attached. Perhaps I will even recognise some registers by their initial value. Thanks, 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 (new, larger key created on Nov 12, 2009) #!/bin/sh echo -n regs for x in $(seq 0 1023); do swconfig dev eth0 set addr $x echo $x $(swconfig dev eth0 get data) regs done ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 driver was already written, by Felix Fietkau. Since the M is a completely different chip than the F and L models, it only detects the M model, using the Chip Identification registers. I don't see any reason to interweave code for the M and the F. I see plenty of reason not to. They are wholly different. They deserve spearate drivers. Like I said, seems pretty much the only thing they have in common is part of the name of the chip. 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 (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 some other change? For instance, with backfire 10.03, the MAC driver used by the D-Link DSL-G624T, cpmac.c, would not detect the switch chip at all. In backfire SVN, this has changed; it is now detected correctly. So I basically have it the other way round if I don't patch anything but go from stable to backfire SVN. 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 for the F, FC and L versions. I agree. But the detection code of adm6996.c (named as such) looks for Chip Identification registers that *are* mentioned in the datasheet for the M model, and very much *are not* in the datasheet for the F and L models. And I didn't write the detection nor name the file. Are you sure it is adm6996.c that detects your FC? It seems so odd to me, looking at the datasheets. Perhaps you could add some debug print statements to adm6996.c in the chip detection code to see what it reads and writes from the chip. 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 (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 for the F, FC and L versions. I agree. But the detection code of adm6996.c (named as such) looks for Chip Identification registers that *are* mentioned in the datasheet for the M model, and very much *are not* in the datasheet for the F and L models. And I didn't write the detection nor name the file. Are you sure it is adm6996.c that detects your FC? It seems so odd to me, looking at the datasheets. Perhaps you could add some debug print statements to adm6996.c in the chip detection code to see what it reads and writes from the chip. Well adm6996.c is the only code that I could find that puts out a syslog entry saying it has found an ADM6996 PHY. Yeah, and I see the Kconfig says: config ADM6996_PHY tristate Driver for ADM6996 switches ---help--- Currently supports the ADM6996F switch I'm thinking there's something odd going on here with regard to datasheets. I added Felix Fietkau to the recipients of this message, since he wrote the detection code in adm6996.c. Felix, if I look at the datasheet for the ADM6996F [1], in particular the register descriptions, I don't see the code in adm6996_fixup() matching on that chip. Instead, it matches the datasheet for the ADM6996M/MX [2], with the Chip ID registers at register addresses 0xA0 and 0xA1. I used [2] to implement the VLAN stuff and it works on the ADM6996M. I don't have an F model. Still, the Kconfig says adm6996.c works for the F model. I'm thinking I have the wrong datasheet for the F model. Could you give a pointer to the documentation you used, or possibly help out otherwise in this confusion? Peter. [1] http://www.datasheetcatalog.org/datasheets2/21/2150254_1.pdf [2] http://media.digikey.com/PDF/Data%20Sheets/Infineon%20PDFs/Samurai%206M,MX,%20ADM6996M,MX.pdf -- 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 (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 programmed through the MDIO interface that is also used by regular Ethernet PHYs. It occupies the whole address space, though. Normally, there is 5 bits adressing a particular PHY and 5 bits addressing a register in that PHY. The ADM6996M has a 10-bit register address, which is split between the normal two 5-bit addresses. The M has two chip identifier registers, Chip Identifier 0 and Chip Identifier 1, at addresses 0xA0 and 0xA1 respectively. The lowest four bits of identifier 0 are a version number; 0x3 in the datasheet. The higher bits are a product code, 0x102. Chip Identifier 1 reads back as 0x0007. 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 this, and I do not have equipment with that chip. But the chips don't seem to have an MDIO interface, so that's a very obvious identifying difference. Anyway, at register address 0 the F and L have a Chip Identifier Register. The lowest 4 bits is a version number. The whole register is specified as 0x00071010 for both F and L (!). The M is obviously more advanced that the F and L. Programmatically, the F and L might even be the same. But the difference between the M on the one side and F and L on the other is very large. The only thing they seem to have in common is the chip name. So I'm sorry, but the driver I wrote will not work even one bit for the F and L chips. 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 (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 this, and I do not have equipment with that chip. Scratch that. The specification of the management bus comes after the register description in the datasheet, not before :). I just noticed that. It *is* a sort of MDIO, sorry about that. But they send 32 bits of data instead of the regular 16 of MDIO. Anyway, identification of the F and L chips is at PHY address 0, register 0, and is 0x00071010 as I said. But because they send 32 databits instead of 16, I'm not sure what you would actually see if you just search the MDIO bus from your MAC. Still, it's completely different from the chip ID of the ADM6996M. 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 (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 ADM6996F (mine is actually an FC) datasheet anywhere? It turned up in a web search. Don't know the particulars anymore. But a trick I learned from a friend is to google for part name vcc, without quotes. Because datasheets often mention a supply voltage with the symbol vcc. It often helps to narrow down the list of results quickly. In fact, I think a good datasheet for the ADM6996F is: http://www.datasheetcatalog.org/datasheets2/21/2150254_1.pdf It's actually the first result from https://encrypted.google.com/search?q=adm6996f+vcc I can easily tell it's not compatible with the 6996M with regard to the VLANs, though. Interestingly, the datasheet for the F doesn't mention the FC model, but the datasheet for the M/MX does: 3.5 The Hardware Difference between ADM6996M/MX and ADM6996F ADM6996FC is a power-down version to replace ADM6996F and ADM6996M/MX is advanced function version for new applications. Good luck! 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 (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
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 ADM6996M/MX. I've put my copy on the web[1] if you would like to see the exact version of the datasheet I used. I'd like to remove the PDF in a few weeks as my webspace at the university isn't meant for this :). And the chip that worked with the code is a 6996M in the D-Link DSL-G624T. Peter. [1] http://wwwhome.cs.utwente.nl/~lebbing/Samurai%206M,MX,%20ADM6996M,MX.pdf -- 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 (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
Oops. There was a mutex handling bug in the code I submitted. I tested all
kinds of things, but forgot to enable VLAN, disable it again and /enable it/
/again/. The final step, that I forgot, was of course where it went wrong.
Disabling the VLAN never released the mutex.
Attached patch should fix 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
@@ -431,7 +431,7 @@
if (!priv-enable_vlan priv-vlan_enabled) {
adm6996_disable_vlan(priv);
priv-vlan_enabled = 0;
- return 0;
+ goto out;
} else if (priv-enable_vlan !priv-vlan_enabled) {
adm6996_enable_vlan(priv);
priv-vlan_enabled = 1;
@@ -440,6 +440,7 @@
adm6996_apply_port_pvids (priv);
adm6996_apply_vlan_filters (priv);
+out:
mutex_unlock(priv-reg_mutex);
return 0;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
Hello developers, I have written a switch driver for the Infineon ADM6996 switch chip, which in my case is in a D-Link DSL-G624T modem/router. It implements 802.1Q based VLAN support, via the swconfig interface. Other fancy features of the switch chip are not (yet) implemented. Because the datasheet isn't that well written, it took some experimentation to get the functionality right. The real functionality of the driver is obviously in the setting of the necessary bits in the configuration registers of the chip. Everything else is pretty much boilerplate code, and can easily be changed if something is deemed not to be the best way. So let's move to one such design decision which really is debatable. The switch chip allows 16 VLAN definitions. But any such definition can be for any 12-bits VLAN ID. The swconfig infrastructure seems to unify the concept of an entry in the list of VLAN definitions and it's VLAN ID. This shows strongest in the fact that when you do the following invocation, for example: # swconfig dev eth0 vlan 2 set ports '0 1 2 3t 4t 5t' It will not only invoke the responsible handler set_vlan_ports from the struct switch_dev_ops, but also automatically the handler set_port_pvid from same struct, setting the Primary VLAN ID for the untagged ports 0, 1 and 2 to VLAN ID 2. Mind you, that is the actual 12-bit identifier from 802.1Q, which is independent of the fact that it is entry number 2 in the table of VLAN definitions. This is all fine if all the VLAN IDs we need are 0-15, but it is a perfectly valid use case to have VLAN IDs with much higher numbers. The ADM6996 chip can handle that use case fine, so I did not want to exclude it. I've seen similar things in other switch chips in OpenWRT while browsing, where it was coined 4k VLANs. It wasn't completely clear to me how it was handled there, however. I chose to handle this case as follows: In addition to the standard attributes, vlan in switch_dev_ops has an attribute named vid, which gives the VLAN ID for that entry in the table of VLAN definitions. By default it is set to the number of the entry. So by default it is: # swconfig dev eth0 show ... VLAN 0: vid: 0 ports: VLAN 1: vid: 1 ports: VLAN 2: vid: 2 ports: ... VLAN 15: vid: 15 ports: This means that as long as people don't change the vid, presumably because they don't need more than the 16 lowest VLAN IDs, it all works completely intuitively, and Primary VLAN IDs for the ports are set correctly automatically. Once you change the vid for a vlan, you become responsible for correcting the mistakes the automatic invocation of set_port_pvid makes. But as I said, if there is a more elegant solution, it is easily changed in the code. A change with respect to the original code (which only detected the switch chip, but had almost no functionality), is that I moved allocation of the phy_device-priv structure from adm6996_probe() to adm6996_config_init(). The reason is that config_init() now has a chance to fail (registering swconfig interface), and I wasn't sure about free()ing of the private structure. So I simply copied the behaviour from ar8216.c. Another change is that I changed the number of ports from 5 to 6. The thing is, it has 6 ports, of which number 5 (zero-based counting) is connected to the CPU. You want to be able to config VLANs for that port as well. On the D-Link modem, port number 4 is not connected to anything. The datasheet of the ADM6996 chip suggests using that port as WAN port, and the D-Link does not have an Ethernet WAN port, so it makes sense. The original code sets the Primary VLAN ID of port 0, which it assumes is the WAN port, to 1, and the others to 0. I have left it like this; I also initialize the swconfig Primary VLAN ID to that. But I wonder why this was done; in the original code, it was effectively a no-op, since it would not make a difference unless a bunch of other registers were also changed. Finally, I'd like to make a little personal note. To my great regret, I have very little free time. So it might take a while before I get back to you when you ask something or wish me to make an adjustment or improvement. This is very unfortunate, and obviously I do not ask you to wait for me on anything; I only wish to contribute, not stall. I cannot change my circumstances, and simply have to accept them. Nonetheless, I hope to give the community useful code. Oh, and this is my first code 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 === --- backfire/target/linux/generic-2.6/files/drivers/net/phy/adm6996.c (revision 24930) +++ backfire/target/linux/generic-2.6/files/drivers/net/phy
