All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
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 10:08:19 +1000	[thread overview]
Message-ID: <1155600499.9047.13.camel@localhost.localdomain> (raw)
In-Reply-To: <44E07267.7070007@de.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

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?

> >> +/*
> >> + *  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

-- 
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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
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 10:08:19 +1000	[thread overview]
Message-ID: <1155600499.9047.13.camel@localhost.localdomain> (raw)
In-Reply-To: <44E07267.7070007@de.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

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?

> >> +/*
> >> + *  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

-- 
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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

  reply	other threads:[~2006-08-15  0:08 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 [this message]
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=1155600499.9047.13.camel@localhost.localdomain \
    --to=michael@ellerman.id.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=meder@de.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=ossthema@de.ibm.com \
    --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.