All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 15 Aug 2006 11:44:05 +0200	[thread overview]
Message-ID: <44E19765.7030301@de.ibm.com> (raw)
In-Reply-To: <1155600499.9047.13.camel@localhost.localdomain>

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.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.
> 
> 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. </2c>
> 
> 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

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: Tue, 15 Aug 2006 11:44:05 +0200	[thread overview]
Message-ID: <44E19765.7030301@de.ibm.com> (raw)
In-Reply-To: <1155600499.9047.13.camel@localhost.localdomain>

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.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.
> 
> 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. </2c>
> 
> 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


  reply	other threads:[~2006-08-15 10:23 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
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 [this message]
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=44E19765.7030301@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.