From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from buildserver.ru.mvista.com (unknown [85.21.88.6]) by ozlabs.org (Postfix) with ESMTP id 25FB0474C2 for ; Fri, 9 Jan 2009 06:10:25 +1100 (EST) Date: Thu, 8 Jan 2009 22:10:21 +0300 From: Anton Vorontsov To: Kumar Gala Subject: Re: [PATCH 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support Message-ID: <20090108191021.GA10008@oksana.dev.rtsoft.ru> References: <20090108013006.GA31653@oksana.dev.rtsoft.ru> <20090108013110.GA11165@oksana.dev.rtsoft.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 In-Reply-To: Cc: Huang Changming , Liu Dave , linuxppc-dev@ozlabs.org Reply-To: avorontsov@ru.mvista.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Jan 08, 2009 at 12:50:22AM -0600, Kumar Gala wrote: >> >> +struct mpc83xx_pcie_priv { >> + void __iomem *cfg_map; >> + u32 dev_base; >> +}; > > So was thinking about this and was wondering about doing the following: > > hose->cfg_addr /* use instead of dev_base to cache pci bus/dev/fn */ > hose->cfg_data /* should be the outbound window used for pci cfg cycles > */ > hose->dn->data /* for IMMR regs to tweak window */ > > thoughts? I don't quite like the casts that we'll need to do this. > Doing this means we should be able to get rid of struct > mpc83xx_pcie_priv Not sure what benefits this would bring? Saving few bytes of code and data at the cost of losing clean, cast-less, self documented code?.. I was actually thinking of getting rid of hose->cfg_data usage, and replacing it with mpc83xx_pci_priv->cfg_type0 (and rename mpc83xx_pci_priv->cfg_map to cfg_type1). OTOH, I can surely do that what you described, but to me it doesn't look like a great idea (i.e. using irrelevant struct members for hooking our data)... -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2