Hi Jeff,
Please take a look at these 2 patches for Blackfin EMAC driver
Thanks
-Bryan
From: Sonic Zhang <[email protected]>
Signed-off-by: Sonic Zhang <[email protected]>
Signed-off-by: Bryan Wu <[email protected]>
---
drivers/net/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9a18270..6b1eb43 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -830,7 +830,7 @@ config ULTRA32
config BFIN_MAC
tristate "Blackfin on-chip MAC support"
- depends on NET_ETHERNET && (BF526 || BF527 || BF536 || BF537)
+ depends on NET_ETHERNET && (BF516 || BF518 || BF526 || BF527 || BF536 || BF537)
select CRC32
select MII
select PHYLIB
--
1.5.6
From: Graf Yang <[email protected]>
Fill EMAC_VLAN1 with 0x8100 to admit 1522 long bytes frames. EMAC_VLAN2
seems need not use for now.
Signed-off-by: Graf Yang <[email protected]>
Signed-off-by: Bryan Wu <[email protected]>
---
drivers/net/bfin_mac.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index 78e31aa..15d7e62 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -517,6 +517,14 @@ void setup_system_regs(struct net_device *dev)
bfin_write_EMAC_MMC_CTL(RSTC | CROLL);
+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
+#define VLAN_ETHER_TYPE 0x8100
+ /* The legal length of the frame is increased to 1522 bytes */
+ bfin_write_EMAC_VLAN1(VLAN_ETHER_TYPE);
+ /* The legal length of the frame is increased to 1538 bytes */
+ /*bfin_write_EMAC_VLAN2(VLAN_ETHER_TYPE);*/
+#endif
+
/* Initialize the TX DMA channel registers */
bfin_write_DMA2_X_COUNT(0);
bfin_write_DMA2_X_MODIFY(4);
--
1.5.6
From: Bryan Wu <[email protected]>
Date: Thu, 8 Jan 2009 00:14:38 +0800
> Signed-off-by: Sonic Zhang <[email protected]>
> Signed-off-by: Bryan Wu <[email protected]>
Applied.
From: Bryan Wu <[email protected]>
Date: Thu, 8 Jan 2009 00:14:39 +0800
> +#define VLAN_ETHER_TYPE 0x8100
Please use ETH_P_8021Q from linux/if_ether.h instead of inventing
your own definition.
> + /* The legal length of the frame is increased to 1538 bytes */
> + /*bfin_write_EMAC_VLAN2(VLAN_ETHER_TYPE);*/
Please do not add code that is just going to be commented
out and not used.
Also, I disagree with the:
+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
conditional. Probably this part of the chip should be programmed
unconditionally.
We can get VLAN packets received and sent, using AF_PACKET
sockets, for example. The chip should still respect those
even if VLAN proper is not being utilized.
On Thu, Jan 8, 2009 at 13:55, David Miller <[email protected]> wrote:
> From: Bryan Wu <[email protected]>
>> +#define VLAN_ETHER_TYPE 0x8100
>
> Please use ETH_P_8021Q from linux/if_ether.h instead of inventing
> your own definition.
was a copy & paste due to not finding a better definition (3c59x.c)
>> + /* The legal length of the frame is increased to 1538 bytes */
>> + /*bfin_write_EMAC_VLAN2(VLAN_ETHER_TYPE);*/
>
> Please do not add code that is just going to be commented
> out and not used.
>
> Also, I disagree with the:
>
> +#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
>
> conditional. Probably this part of the chip should be programmed
> unconditionally.
again, more of a copy & paste ... this is how a bunch of drivers are
doing it now ...
> We can get VLAN packets received and sent, using AF_PACKET
> sockets, for example. The chip should still respect those
> even if VLAN proper is not being utilized.
any tips on doing that ?
thanks for reviewing!
-mike
On Thu, Jan 8, 2009 at 14:01, Mike Frysinger wrote:
> On Thu, Jan 8, 2009 at 13:55, David Miller wrote:
>> We can get VLAN packets received and sent, using AF_PACKET
>> sockets, for example. The chip should still respect those
>> even if VLAN proper is not being utilized.
>
> any tips on doing that ?
or rather, is there a driver or you two you can point out that is
doing this correctly ? the ones i looked at seemed to be doing it
like the patch we posted ...
-mike
From: "Mike Frysinger" <[email protected]>
Date: Thu, 8 Jan 2009 14:01:49 -0500
> > We can get VLAN packets received and sent, using AF_PACKET
> > sockets, for example. The chip should still respect those
> > even if VLAN proper is not being utilized.
>
> any tips on doing that ?
No, sorry.
From: "Mike Frysinger" <[email protected]>
Date: Thu, 8 Jan 2009 14:05:33 -0500
> On Thu, Jan 8, 2009 at 14:01, Mike Frysinger wrote:
> > On Thu, Jan 8, 2009 at 13:55, David Miller wrote:
> >> We can get VLAN packets received and sent, using AF_PACKET
> >> sockets, for example. The chip should still respect those
> >> even if VLAN proper is not being utilized.
> >
> > any tips on doing that ?
>
> or rather, is there a driver or you two you can point out that is
> doing this correctly ? the ones i looked at seemed to be doing it
> like the patch we posted ...
And I disagree with how those drivers are doing it :-)
At least the programming of the chip to accept all packet
types properly, VLAN or not, regardless of kernel config,
is definitely IMHO the way to go.
On Thu, Jan 8, 2009 at 14:30, David Miller wrote:
> From: "Mike Frysinger" <vapier
>> On Thu, Jan 8, 2009 at 14:01, Mike Frysinger wrote:
>> > On Thu, Jan 8, 2009 at 13:55, David Miller wrote:
>> >> We can get VLAN packets received and sent, using AF_PACKET
>> >> sockets, for example. The chip should still respect those
>> >> even if VLAN proper is not being utilized.
>> >
>> > any tips on doing that ?
>>
>> or rather, is there a driver or you two you can point out that is
>> doing this correctly ? the ones i looked at seemed to be doing it
>> like the patch we posted ...
>
> And I disagree with how those drivers are doing it :-)
>
> At least the programming of the chip to accept all packet
> types properly, VLAN or not, regardless of kernel config,
> is definitely IMHO the way to go.
i know on our side we all agree with you, we just didnt (dont) know
any better ;)
-mike