<feed xmlns='http://www.w3.org/2005/Atom'>
<title>svn-archive/archive/target/linux/generic/files/drivers/net/phy/b53, branch master</title>
<subtitle>OpenWrt SVN history</subtitle>
<id>https://git.openwrt.org/openwrt/svn-archive/archive/atom?h=master</id>
<link rel='self' href='https://git.openwrt.org/openwrt/svn-archive/archive/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/'/>
<updated>2016-02-03T09:33:56Z</updated>
<entry>
<title>b53: support setting port link</title>
<updated>2016-02-03T09:33:56Z</updated>
<author>
<name>Rafał Miłecki</name>
</author>
<published>2016-02-03T09:33:56Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=83b0ce2b3fdeb7a79dceaaa9e06704da924a86c1'/>
<id>urn:sha1:83b0ce2b3fdeb7a79dceaaa9e06704da924a86c1</id>
<content type='text'>
When dealing with Broadcom hardware we can simply use swconfig's generic
helper, we just need to do some validation of requested state.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;

SVN-Revision: 48623
</content>
</entry>
<entry>
<title>b53: provide PHY access to swconfig</title>
<updated>2016-02-03T09:33:50Z</updated>
<author>
<name>Rafał Miłecki</name>
</author>
<published>2016-02-03T09:33:50Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=9a3f163c1be1e47bad49a057935fe5e606dd6a3c'/>
<id>urn:sha1:9a3f163c1be1e47bad49a057935fe5e606dd6a3c</id>
<content type='text'>
Thanks to this change swconfig can access port PHYs e.g. when setting
port link state with a generic helper.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;

SVN-Revision: 48622
</content>
</entry>
<entry>
<title>b53: update header register difinitions</title>
<updated>2016-01-18T10:46:47Z</updated>
<author>
<name>Jonas Gorski</name>
</author>
<published>2016-01-18T10:46:47Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=14d464456fd699fcdd96fa5d698973c2048de3f5'/>
<id>urn:sha1:14d464456fd699fcdd96fa5d698973c2048de3f5</id>
<content type='text'>
BCM531x5 has two pontential cpu ports, and header mode can be enabled
independently on both.

Signed-off-by: Jonas Gorski &lt;jogo@openwrt.org&gt;

SVN-Revision: 48302
</content>
</entry>
<entry>
<title>kernel: b53: fix build with brcm47xx</title>
<updated>2015-07-03T23:27:21Z</updated>
<author>
<name>Hauke Mehrtens</name>
</author>
<published>2015-07-03T23:27:21Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=d23e5ece28347beb91b08c09bff9d2a9553bf778'/>
<id>urn:sha1:d23e5ece28347beb91b08c09bff9d2a9553bf778</id>
<content type='text'>
The position of the nvram header file on brcm47xx changed with kernel 
version 4.1.

Signed-off-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;


SVN-Revision: 46170
</content>
</entry>
<entry>
<title>b53: Allow using all 8 ports on BCM53011</title>
<updated>2015-06-21T21:06:09Z</updated>
<author>
<name>Rafał Miłecki</name>
</author>
<published>2015-06-21T21:06:09Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=a8e0ad15ff990b2e34ec44c212e37edb02ffab02'/>
<id>urn:sha1:a8e0ad15ff990b2e34ec44c212e37edb02ffab02</id>
<content type='text'>
On two tested devices: Netgear R6250 (BCM53011 rev 2) and Luxul XWC-1000
(BCM53011 rev 3) it was possible to use port 7 and eth1 (instead of port
5 and eth0). It seems BCM53011 just like BCM53012 has 8 ports and
usually 3 of them are connected to the SoC.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;

SVN-Revision: 46104
</content>
</entry>
<entry>
<title>b53: fix memory out of bounds access on 64 bit targets</title>
<updated>2015-06-10T09:21:36Z</updated>
<author>
<name>Jonas Gorski</name>
</author>
<published>2015-06-10T09:21:36Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=3f11edc2c35c3c9c0ab11cfff0b37658215bd377'/>
<id>urn:sha1:3f11edc2c35c3c9c0ab11cfff0b37658215bd377</id>
<content type='text'>
On device reset the sizes for the vlan and port tables were wrongly
calculated based on the pointer size instead of the struct size. This
causes buffer overruns on 64 bit targets, resulting in panics.

Fix this by dereferencing the pointers.

Reported-by: Fedor Konstantinov &lt;blmink@mink.su&gt;
Signed-off-by: Jonas Gorski &lt;jogo@openwrt.org&gt;

SVN-Revision: 45938
</content>
</entry>
<entry>
<title>b53: widen stp state mask to 3 bits (instead of 2)</title>
<updated>2015-06-10T09:21:31Z</updated>
<author>
<name>Jonas Gorski</name>
</author>
<published>2015-06-10T09:21:31Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=9532a74bc533a538daabe209131c66277adb7f4b'/>
<id>urn:sha1:9532a74bc533a538daabe209131c66277adb7f4b</id>
<content type='text'>
At least on my b53 chip, the mask is 3 bits wide, and because
of this some STP states are not set properly and discarded when read.

Maybe for some other chips it makes sense to have just 2 bits width,
but I don't have other versions around to test/validate.

If that's the case then maybe we could add another STP state mask.

Signed-off-by: Alexandru Ardelean &lt;ardeleanalex@gmail.com&gt;
Signed-off-by: Jonas Gorski &lt;jogo@openwrt.org&gt;

SVN-Revision: 45937
</content>
</entry>
<entry>
<title>b53: Allow using all ports on BCM53012</title>
<updated>2015-05-12T13:18:53Z</updated>
<author>
<name>Rafał Miłecki</name>
</author>
<published>2015-05-12T13:18:53Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=ebf914b040b720862bfedc1ec8ddada70e4d5ba8'/>
<id>urn:sha1:ebf914b040b720862bfedc1ec8ddada70e4d5ba8</id>
<content type='text'>
This chipset has at least 8 usable ports, e.g. Netgear R8000 has ports
5, 7 and 8 connected to Ethernet interfaces:
vlan1ports=0 1 2 3 5 7 8*
vlan2ports=4 8u
Port 6 seems to be always disabled.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Acked-by: Jonas Gorski &lt;jogo@openwrt.org&gt;

SVN-Revision: 45676
</content>
</entry>
<entry>
<title>b53: improve overriding CPU port state on BCM5301X</title>
<updated>2015-04-12T20:00:42Z</updated>
<author>
<name>Rafał Miłecki</name>
</author>
<published>2015-04-12T20:00:42Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=42409e178c1c2900537644be67cd7967345ce0e8'/>
<id>urn:sha1:42409e178c1c2900537644be67cd7967345ce0e8</id>
<content type='text'>
On BCM5301X there are two different cases to handle: CPU port 8 vs. any
other one. Support for CPU port 8 was already partially implemented but
it lacked setting some extra bit for 2G speed. It also will need to be
extended to implement "SMP dual core 3 GMAC setup". That's the reason
for handling it in separated code block.
This patch also adds overriding CPU port state for port other than 8. It
requires using recently defined GMII_PORT registers.
It was tested for regressions on BCM53011 revs 2 &amp; 3. It was also
confirmed to fix switch on some internal Broadcom board.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Acked-by: Jonas Gorski &lt;jogo@openwrt.org&gt;

SVN-Revision: 45402
</content>
</entry>
<entry>
<title>b53: clean up code to match kernel style better</title>
<updated>2015-04-10T10:29:04Z</updated>
<author>
<name>Jonas Gorski</name>
</author>
<published>2015-04-10T10:29:04Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/svn-archive/archive/commit/?id=ac3a88867877cec592e6634eb84644f657334f9a'/>
<id>urn:sha1:ac3a88867877cec592e6634eb84644f657334f9a</id>
<content type='text'>
* properly enclose macro arguments in paranthesis on use
* remove trailing white space
* convert C99 // comments
* add missing blank lines after declaration
* remove braces from single statement blocks
* split lines &gt; 80 chars (except for one)

Signed-off-by: Jonas Gorski &lt;jogo@openwrt.org&gt;

SVN-Revision: 45356
</content>
</entry>
</feed>
