From: Jan-Bernd Themann <ossthema@de.ibm.com>
To: michael@ellerman.id.au
Cc: Thomas Klein <tklein@de.ibm.com>, netdev <netdev@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Christoph Raisch <raisch@de.ibm.com>,
Marcus Eder <meder@de.ibm.com>
Subject: Re: [PATCH 4/6] ehea: header files
Date: Mon, 14 Aug 2006 14:53:59 +0200 [thread overview]
Message-ID: <44E07267.7070007@de.ibm.com> (raw)
In-Reply-To: <1155190921.9801.43.camel@localhost.localdomain>
Michael Ellerman wrote:
>> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31 16:00:00.000000000 -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_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.
>
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
WARNING: multiple messages have this Message-ID (diff)
From: Jan-Bernd Themann <ossthema@de.ibm.com>
To: michael@ellerman.id.au
Cc: netdev <netdev@vger.kernel.org>, Thomas Klein <tklein@de.ibm.com>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Christoph Raisch <raisch@de.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Marcus Eder <meder@de.ibm.com>
Subject: Re: [PATCH 4/6] ehea: header files
Date: Mon, 14 Aug 2006 14:53:59 +0200 [thread overview]
Message-ID: <44E07267.7070007@de.ibm.com> (raw)
In-Reply-To: <1155190921.9801.43.camel@localhost.localdomain>
Michael Ellerman wrote:
>> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31 16:00:00.000000000 -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_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.
>
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
next prev parent reply other threads:[~2006-08-14 13:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-09 8:39 [PATCH 4/6] ehea: header files Jan-Bernd Themann
2006-08-09 8:39 ` Jan-Bernd Themann
2006-08-09 13:17 ` Arnd Bergmann
2006-08-09 13:17 ` Arnd Bergmann
2006-08-10 6:22 ` Michael Ellerman
2006-08-10 6:22 ` Michael Ellerman
2006-08-14 12:53 ` Jan-Bernd Themann [this message]
2006-08-14 12:53 ` Jan-Bernd Themann
2006-08-15 0:08 ` Michael Ellerman
2006-08-15 0:08 ` Michael Ellerman
2006-08-15 9:44 ` Jan-Bernd Themann
2006-08-15 9:44 ` Jan-Bernd Themann
2006-08-15 10:53 ` Jenkins, Clive
2006-08-15 10:53 ` Jenkins, Clive
2006-08-15 11:07 ` Christoph Raisch
2006-08-15 11:07 ` Christoph Raisch
2006-08-15 11:09 ` edlk4.0 ppc_85xx gdb problems emre kara
2006-08-15 11:46 ` Jenkins, Clive
2006-08-16 0:58 ` [PATCH 4/6] ehea: header files Michael Ellerman
2006-08-16 0:58 ` Michael Ellerman
2006-08-11 21:40 ` Anton Blanchard
2006-08-11 21:40 ` Anton Blanchard
2006-08-14 3:20 ` Michael Ellerman
2006-08-14 3:20 ` Michael Ellerman
2006-08-14 6:19 ` Jan-Bernd Themann
2006-08-14 6:19 ` Jan-Bernd Themann
2006-08-11 22:07 ` Anton Blanchard
2006-08-11 22:07 ` Anton Blanchard
2006-08-12 16:40 ` Thomas Klein
2006-08-12 16:40 ` Thomas Klein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44E07267.7070007@de.ibm.com \
--to=ossthema@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=meder@de.ibm.com \
--cc=michael@ellerman.id.au \
--cc=netdev@vger.kernel.org \
--cc=raisch@de.ibm.com \
--cc=tklein@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.