RE: [PATCH 4/6] ehea: header files
On Tue, 2006-08-15 at 13:07 +0200, Christoph Raisch wrote: > > "Jenkins, Clive" wrote on 15.08.2006 12:53:05: > > > > > You mean the eHEA has its own concept of page size? Separate from > > the > > > > page size used by the MMU? > > > > > > > > > > yes, the eHEA currently supports only 4K pages for queues > > > > In that case, I suggest use the kernel's page size, but add a > > compile-time > > check, and quit with an error message if driver does not support it. > > eHEA does support other page sizes than 4k, but the HW interface expects to > see 4k pages > The adaption is done in the device driver, therefore we have a seperate 4k > define. Fair enough. You seem to only use it in drivers/net/ehea/ehea_qmr.c, if so put the definition in there, that way someone is less likely to use the EHEA_PAGESIZE definition where they really need PAGE_SIZE. cheers -- Michael Ellerman IBM OzLabs wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
RE: [PATCH 4/6] ehea: header files
"Jenkins, Clive" wrote on 15.08.2006 12:53:05: > > > You mean the eHEA has its own concept of page size? Separate from > the > > > page size used by the MMU? > > > > > > > yes, the eHEA currently supports only 4K pages for queues > > In that case, I suggest use the kernel's page size, but add a > compile-time > check, and quit with an error message if driver does not support it. eHEA does support other page sizes than 4k, but the HW interface expects to see 4k pages The adaption is done in the device driver, therefore we have a seperate 4k define. Regards . . . Christoph R. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] ehea: header files
> > You mean the eHEA has its own concept of page size? Separate from the > > page size used by the MMU? > > > > yes, the eHEA currently supports only 4K pages for queues In that case, I suggest use the kernel's page size, but add a compile-time check, and quit with an error message if driver does not support it. Regards, Clive - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ehea: header files
Michael Ellerman wrote:
On Mon, 2006-08-14 at 14:53 +0200, Jan-Bernd Themann wrote:
Michael Ellerman wrote:
--- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
16:00:00.0 -0800
+++ kernel/drivers/net/ehea/ehea.h 2006-08-08 23:59:39.927452928 -0700
+
+#define EHEA_PAGESHIFT 12
+#define EHEA_PAGESIZE 4096UL
+#define EHEA_CACHE_LINE 128
This looks like a very bad idea, what happens if you're running on a
machine with 64K pages?
The EHEA_PAGESIZE define is needed for queue management to hardware side.
You mean the eHEA has its own concept of page size? Separate from the
page size used by the MMU?
yes, the eHEA currently supports only 4K pages for queues
+/*
+ * h_galpa:
+ * for pSeries this is a 64bit memory address where
+ * I/O memory is mapped into CPU address space
+ */
+
+struct h_galpa {
+ u64 fw_handle;
+};
What is a h_galpa? And why does it need a struct if it's just a u64?
The eHEA chip is not PCI attached but directly connected to a proprietary
bus. Currently, we can access it by a simple 64 bit address, but this is not
true in all cases. Having a struct here allows us to encapsulate the chip
register access and to respond to changes to system hardware.
We'll change the name to h_epa meaning "ehea physical address"
Hmm, I'm not convinced. Having the struct doesn't really encapsulate
much, because most of the places where you use the h_galpa struct just
pull out the fw_handle anyway. So if you change the layout of the struct
you're going to have to change most of the code anyway. And in the
meantime it makes the code a lot less readable, most people understand
what "u64 addr" is about, whereas "struct h_galpa" is much less
meaningful.
cheers
We already use the h_galpa struct for simulation purposes where we use
this encapsulation to add further required fields to be able to access
the registers (h_galpa has been renamed to h_epa). The name of the
fw_handle element will be changed. Instead of fw_handle, we'll call it
ebus_addr which will make it more readable.
Regards,
Jan-Bernd
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ehea: header files
On Mon, 2006-08-14 at 14:53 +0200, Jan-Bernd Themann wrote:
> Michael Ellerman wrote:
> >> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
> >> 16:00:00.0 -0800
> >> +++ kernel/drivers/net/ehea/ehea.h 2006-08-08 23:59:39.927452928 -0700
> >> +
> >> +#define EHEA_PAGESHIFT 12
> >> +#define EHEA_PAGESIZE 4096UL
> >> +#define EHEA_CACHE_LINE 128
> >
> > This looks like a very bad idea, what happens if you're running on a
> > machine with 64K pages?
> >
>
> The EHEA_PAGESIZE define is needed for queue management to hardware side.
You mean the eHEA has its own concept of page size? Separate from the
page size used by the MMU?
> >> +/*
> >> + * h_galpa:
> >> + * for pSeries this is a 64bit memory address where
> >> + * I/O memory is mapped into CPU address space
> >> + */
> >> +
> >> +struct h_galpa {
> >> + u64 fw_handle;
> >> +};
> >
> > What is a h_galpa? And why does it need a struct if it's just a u64?
> >
>
> The eHEA chip is not PCI attached but directly connected to a proprietary
> bus. Currently, we can access it by a simple 64 bit address, but this is not
> true in all cases. Having a struct here allows us to encapsulate the chip
> register access and to respond to changes to system hardware.
>
> We'll change the name to h_epa meaning "ehea physical address"
Hmm, I'm not convinced. Having the struct doesn't really encapsulate
much, because most of the places where you use the h_galpa struct just
pull out the fw_handle anyway. So if you change the layout of the struct
you're going to have to change most of the code anyway. And in the
meantime it makes the code a lot less readable, most people understand
what "u64 addr" is about, whereas "struct h_galpa" is much less
meaningful.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 4/6] ehea: header files
Michael Ellerman wrote:
--- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
16:00:00.0 -0800
+++ kernel/drivers/net/ehea/ehea.h 2006-08-08 23:59:39.927452928 -0700
+
+#define EHEA_PAGESHIFT 12
+#define EHEA_PAGESIZE 4096UL
+#define EHEA_CACHE_LINE 128
This looks like a very bad idea, what happens if you're running on a
machine with 64K pages?
The EHEA_PAGESIZE define is needed for queue management to hardware side.
+
+#define EHEA_ENABLE1
+#define EHEA_DISABLE 0
Do you really need hash defines for 0 and 1 ? They're fairly well
understood in C as meaning true and false.
removed
+
+/*
+ * h_galpa:
+ * for pSeries this is a 64bit memory address where
+ * I/O memory is mapped into CPU address space
+ */
+
+struct h_galpa {
+ u64 fw_handle;
+};
What is a h_galpa? And why does it need a struct if it's just a u64?
The eHEA chip is not PCI attached but directly connected to a proprietary
bus. Currently, we can access it by a simple 64 bit address, but this is not
true in all cases. Having a struct here allows us to encapsulate the chip
register access and to respond to changes to system hardware.
We'll change the name to h_epa meaning "ehea physical address"
+
+struct h_galpas {
+ struct h_galpa kernel; /* kernel space accessible resource,
+ set to 0 if unused */
+ struct h_galpa user;/* user space accessible resource
+ set to 0 if unused */
+ u32 pid;/* PID of userspace galpa checking */
+};
+
+struct port_res_cfg {
+ int max_entries_rcq;
+ int max_entries_scq;
+ int max_entries_sq;
+ int max_entries_rq1;
+ int max_entries_rq2;
+ int max_entries_rq3;
+};
Enormous structs with no comments.
changed
Regards,
Jan-Bernd
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ehea: header files
Michael Ellerman wrote: On Sat, 2006-08-12 at 07:40 +1000, Anton Blanchard wrote: Hi, drivers/net/ehea/ehea.h| 452 +#define EHEA_DRIVER_NAME "IBM eHEA" You are using this for ethtool get_drvinfo. Im not sure if it should match the module name, and I worry about having a space in the name. Any ideas on what we should be doing here? I believe it must match the module name. It also might be nice to call it "DRV_NAME" like most other network drivers do. cheers We rename EHEA_DRIVER_NAME to DRV_NAME (and EHEA_DRIVER_VERSION to DRV_VERSION) and assign "ehea" to it Jan-Bernd - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ehea: header files
On Sat, 2006-08-12 at 07:40 +1000, Anton Blanchard wrote: > Hi, > > > drivers/net/ehea/ehea.h| 452 > > > +#define EHEA_DRIVER_NAME "IBM eHEA" > > You are using this for ethtool get_drvinfo. Im not sure if it should > match the module name, and I worry about having a space in the name. Any > ideas on what we should be doing here? I believe it must match the module name. It also might be nice to call it "DRV_NAME" like most other network drivers do. cheers -- Michael Ellerman IBM OzLabs wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: [PATCH 4/6] ehea: header files
Anton Blanchard wrote: --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31 +extern void exit(int); Should be able to remove that prototype :) Anton Indeed :-) It's gone. Thomas - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ehea: header files
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31 > +extern void exit(int); Should be able to remove that prototype :) Anton - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ehea: header files
Hi, > drivers/net/ehea/ehea.h| 452 > +#define EHEA_DRIVER_NAME "IBM eHEA" You are using this for ethtool get_drvinfo. Im not sure if it should match the module name, and I worry about having a space in the name. Any ideas on what we should be doing here? > +#define NET_IP_ALIGN 0 Shouldnt override this in your driver. > +#define EDEB_P_GENERIC(level, idstring, format, args...) \ > +#define EDEB_P_GENERIC(level,idstring,format,args...) \ > +#define EDEB(level, format, args...) \ > +#define EDEB_ERR(level, format, args...) \ > +#define EDEB_EN(level, format, args...) \ > +#define EDEB_EX(level, format, args...) \ > +#define EDEB_DMP(level, adr, len, format, args...) \ There are a lot of debug statements in the driver. When doing a review I stripped them all out to make it easier to read. As suggested by others, using the standard debug macros (where still required) would be a good idea. Anton - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ehea: header files
Hi Jan-Bernd,
I haven't read all of this, but a few things caught my eye ...
cheers
On Wed, 2006-08-09 at 10:39 +0200, Jan-Bernd Themann wrote:
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
>
>
> drivers/net/ehea/ehea.h| 452
> +
> drivers/net/ehea/ehea_hw.h | 319 +++
> 2 files changed, 771 insertions(+)
>
>
>
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
> 16:00:00.0 -0800
> +++ kernel/drivers/net/ehea/ehea.h2006-08-08 23:59:39.927452928 -0700
> @@ -0,0 +1,452 @@
> +/*
> + * linux/drivers/net/ehea/ehea.h
> + *
> + * eHEA ethernet device driver for IBM eServer System p
> + *
> + * (C) Copyright IBM Corp. 2006
> + *
> + * Authors:
> + * Christoph Raisch <[EMAIL PROTECTED]>
> + * Jan-Bernd Themann <[EMAIL PROTECTED]>
> + * Heiko-Joerg Schick <[EMAIL PROTECTED]>
> + * Thomas Klein <[EMAIL PROTECTED]>
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2, or (at your option)
> + * any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#ifndef __EHEA_H__
> +#define __EHEA_H__
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define EHEA_DRIVER_NAME "IBM eHEA"
> +#define EHEA_DRIVER_VERSION "EHEA_0015"
> +
> +#define NET_IP_ALIGN 0
> +#define EHEA_NUM_TX_QP 1
> +#ifdef EHEA_SMALL_QUEUES
> +#define EHEA_MAX_CQE_COUNT 1020
> +#define EHEA_MAX_ENTRIES_SQ1020
> +#define EHEA_MAX_ENTRIES_RQ1 4080
> +#define EHEA_MAX_ENTRIES_RQ2 1020
> +#define EHEA_MAX_ENTRIES_RQ3 1020
> +#define EHEA_SWQE_REFILL_TH 100
> +#else
> +#define EHEA_MAX_CQE_COUNT32000
> +#define EHEA_MAX_ENTRIES_SQ 16000
> +#define EHEA_MAX_ENTRIES_RQ1 32080
> +#define EHEA_MAX_ENTRIES_RQ2 4020
> +#define EHEA_MAX_ENTRIES_RQ3 4020
> +#define EHEA_SWQE_REFILL_TH1000
> +#endif
> +
> +#define EHEA_MAX_ENTRIES_EQ 20
> +
> +#define EHEA_SG_SQ 2
> +#define EHEA_SG_RQ1 1
> +#define EHEA_SG_RQ2 0
> +#define EHEA_SG_RQ3 0
> +
> +#define EHEA_MAX_PACKET_SIZE9022 /* for jumbo frame */
> +#define EHEA_RQ2_PKT_SIZE 1522
> +#define EHEA_LL_PKT_SIZE 256
> +
> +/* Send completion signaling */
> +#define EHEA_SIG_IV 1000
> +#define EHEA_SIG_IV_LONG 4
> +
> +/* Protection Domain Identifier */
> +#define EHEA_PD_ID0xaabcdeff
> +
> +#define EHEA_RQ2_THRESHOLD 1
> +/* use RQ3 threshold of 1522 bytes */
> +#define EHEA_RQ3_THRESHOLD 9
> +
> +#define EHEA_SPEED_10G 1
> +#define EHEA_SPEED_1G 1000
> +#define EHEA_SPEED_100M 100
> +#define EHEA_SPEED_10M10
> +
> +/* Broadcast/Multicast registration types */
> +#define EHEA_BCMC_SCOPE_ALL 0x08
> +#define EHEA_BCMC_SCOPE_SINGLE 0x00
> +#define EHEA_BCMC_MULTICAST 0x04
> +#define EHEA_BCMC_BROADCAST 0x00
> +#define EHEA_BCMC_UNTAGGED 0x02
> +#define EHEA_BCMC_TAGGED 0x00
> +#define EHEA_BCMC_VLANID_ALL 0x01
> +#define EHEA_BCMC_VLANID_SINGLE 0x00
> +
> +/* Use this define to kmallocate PHYP control blocks */
> +#define H_CB_ALIGNMENT 4096
> +
> +#define EHEA_PAGESHIFT 12
> +#define EHEA_PAGESIZE 4096UL
> +#define EHEA_CACHE_LINE 128
This looks like a very bad idea, what happens if you're running on a
machine with 64K pages?
> +
> +#define EHEA_ENABLE 1
> +#define EHEA_DISABLE 0
Do you really need hash defines for 0 and 1 ? They're fairly well
understood in C as meaning true and false.
> +
> +/* Memory Regions */
> +#define EHEA_MR_MAX_TX_PAGES 20
> +#define EHEA_MR_TX_DATA_PN 3
> +#define EHEA_MR_ACC_CTRL 0x0080
> +#define EHEA_RWQES_PER_MR_RQ2 10
> +#define EHEA_RWQES_PER_MR_RQ3 10
> +
> +
> +void ehea_set_ethtool_ops(struct net_device *netdev);
> +
> +#ifndef KEEP_EDEBS_BELOW
> +#define KEEP_EDEBS_BELOW 8
> +#endif
> +
> +extern int ehea_trace_level;
> +
> +#ifdef EHEA_NO_EDEB
> +#define EDEB_P_GENERIC(level, idstring, format, args...) \
> + while (0 == 1) { \
> + if(unlikely (level <= ehea_trace_level)) { \
> + printk("%s " idstring " "format "\n", \
> + __func__, ##args); \
> + } \
> + } \
> +
Re: [PATCH 4/6] ehea: header files
On Wednesday 09 August 2006 10:39, Jan-Bernd Themann wrote:
> +extern int ehea_trace_level;
> +
> +#ifdef EHEA_NO_EDEB
> +#define EDEB_P_GENERIC(level, idstring, format, args...) \
> + while (0 == 1) { \
> + if(unlikely (level <= ehea_trace_level)) { \
> + printk("%s " idstring " "format "\n", \
> + __func__, ##args); \
> + } \
> + } \
> +
> +#else
> +
> +#define EDEB_P_GENERIC(level,idstring,format,args...) \
> +if (level < KEEP_EDEBS_BELOW) { \
> + do { \
> + if(unlikely (level <= ehea_trace_level)) { \
> + printk("%s " idstring " "format "\n", \
> + __func__, ##args); \
> + } \
> + } while (1 == 0); \
> +}
> +#endif
> +
> +#define EDEB(level, format, args...) \
> + EDEB_P_GENERIC(level, "", format, ##args)
> +
> +#define EDEB_ERR(level, format, args...) \
> + EDEB_P_GENERIC(level, "EHEA_ERROR", format, ##args)
> +
> +#define EDEB_EN(level, format, args...) \
> + EDEB_P_GENERIC(level, ">>>", format, ##args)
> +
> +#define EDEB_EX(level, format, args...) \
> + EDEB_P_GENERIC(level, "<<<", format, ##args)
Please don't invent your own debugging macros. You can either use the
pr_debug/pr_info facility from or get rid of those
completely. The latter is probably preferred for most of your calls.
Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ehea: header files
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
drivers/net/ehea/ehea.h| 452 +
drivers/net/ehea/ehea_hw.h | 319 +++
2 files changed, 771 insertions(+)
--- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
16:00:00.0 -0800
+++ kernel/drivers/net/ehea/ehea.h 2006-08-08 23:59:39.927452928 -0700
@@ -0,0 +1,452 @@
+/*
+ * linux/drivers/net/ehea/ehea.h
+ *
+ * eHEA ethernet device driver for IBM eServer System p
+ *
+ * (C) Copyright IBM Corp. 2006
+ *
+ * Authors:
+ * Christoph Raisch <[EMAIL PROTECTED]>
+ * Jan-Bernd Themann <[EMAIL PROTECTED]>
+ * Heiko-Joerg Schick <[EMAIL PROTECTED]>
+ * Thomas Klein <[EMAIL PROTECTED]>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __EHEA_H__
+#define __EHEA_H__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EHEA_DRIVER_NAME "IBM eHEA"
+#define EHEA_DRIVER_VERSION"EHEA_0015"
+
+#define NET_IP_ALIGN 0
+#define EHEA_NUM_TX_QP 1
+#ifdef EHEA_SMALL_QUEUES
+#define EHEA_MAX_CQE_COUNT 1020
+#define EHEA_MAX_ENTRIES_SQ1020
+#define EHEA_MAX_ENTRIES_RQ1 4080
+#define EHEA_MAX_ENTRIES_RQ2 1020
+#define EHEA_MAX_ENTRIES_RQ3 1020
+#define EHEA_SWQE_REFILL_TH 100
+#else
+#define EHEA_MAX_CQE_COUNT32000
+#define EHEA_MAX_ENTRIES_SQ 16000
+#define EHEA_MAX_ENTRIES_RQ1 32080
+#define EHEA_MAX_ENTRIES_RQ2 4020
+#define EHEA_MAX_ENTRIES_RQ3 4020
+#define EHEA_SWQE_REFILL_TH1000
+#endif
+
+#define EHEA_MAX_ENTRIES_EQ 20
+
+#define EHEA_SG_SQ 2
+#define EHEA_SG_RQ1 1
+#define EHEA_SG_RQ2 0
+#define EHEA_SG_RQ3 0
+
+#define EHEA_MAX_PACKET_SIZE9022 /* for jumbo frame */
+#define EHEA_RQ2_PKT_SIZE 1522
+#define EHEA_LL_PKT_SIZE 256
+
+/* Send completion signaling */
+#define EHEA_SIG_IV 1000
+#define EHEA_SIG_IV_LONG 4
+
+/* Protection Domain Identifier */
+#define EHEA_PD_ID0xaabcdeff
+
+#define EHEA_RQ2_THRESHOLD 1
+/* use RQ3 threshold of 1522 bytes */
+#define EHEA_RQ3_THRESHOLD 9
+
+#define EHEA_SPEED_10G 1
+#define EHEA_SPEED_1G 1000
+#define EHEA_SPEED_100M 100
+#define EHEA_SPEED_10M10
+
+/* Broadcast/Multicast registration types */
+#define EHEA_BCMC_SCOPE_ALL0x08
+#define EHEA_BCMC_SCOPE_SINGLE 0x00
+#define EHEA_BCMC_MULTICAST0x04
+#define EHEA_BCMC_BROADCAST0x00
+#define EHEA_BCMC_UNTAGGED 0x02
+#define EHEA_BCMC_TAGGED 0x00
+#define EHEA_BCMC_VLANID_ALL 0x01
+#define EHEA_BCMC_VLANID_SINGLE0x00
+
+/* Use this define to kmallocate PHYP control blocks */
+#define H_CB_ALIGNMENT 4096
+
+#define EHEA_PAGESHIFT 12
+#define EHEA_PAGESIZE 4096UL
+#define EHEA_CACHE_LINE 128
+
+#define EHEA_ENABLE1
+#define EHEA_DISABLE 0
+
+/* Memory Regions */
+#define EHEA_MR_MAX_TX_PAGES 20
+#define EHEA_MR_TX_DATA_PN 3
+#define EHEA_MR_ACC_CTRL 0x0080
+#define EHEA_RWQES_PER_MR_RQ2 10
+#define EHEA_RWQES_PER_MR_RQ3 10
+
+
+void ehea_set_ethtool_ops(struct net_device *netdev);
+
+#ifndef KEEP_EDEBS_BELOW
+#define KEEP_EDEBS_BELOW 8
+#endif
+
+extern int ehea_trace_level;
+
+#ifdef EHEA_NO_EDEB
+#define EDEB_P_GENERIC(level, idstring, format, args...) \
+ while (0 == 1) { \
+ if(unlikely (level <= ehea_trace_level)) { \
+ printk("%s " idstring " "format "\n", \
+ __func__, ##args); \
+ } \
+ } \
+
+#else
+
+#define EDEB_P_GENERIC(level,idstring,format,args...) \
+if (level < KEEP_EDEBS_BELOW) { \
+ do { \
+ if(unlikely (level <= ehea_trace_level)) { \
+ printk("%s " idstring " "format "\n", \
+ __func__, ##args); \
+ } \
+ } while (1 == 0); \
+}
+#endif
+
+#define EDEB(level, format, args...) \
+EDEB_P_GENERIC(level, "", format, ##args)
+
+#define EDEB_ERR(level, format, args...) \
+EDEB_P_GENERIC(level, "EHEA_ERROR", format, ##args)
+
+#define EDEB_EN(level, format, args...) \
+EDEB_P_GENERIC(level, ">>>", format, ##args)
+
+#d
