All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: Huang Changming <Chang-Ming.Huang@freescale.com>,
	Liu Dave <DaveLiu@freescale.com>,
	linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support
Date: Thu, 8 Jan 2009 22:10:21 +0300	[thread overview]
Message-ID: <20090108191021.GA10008@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <C65915E8-6544-4229-9ED2-D2BB936D537C@kernel.crashing.org>

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

  reply	other threads:[~2009-01-08 19:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-08  1:30 [PATCH v5 0/2] MPC83xx PCI-E support Anton Vorontsov
2009-01-08  1:31 ` [PATCH 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support Anton Vorontsov
2009-01-08  6:50   ` Kumar Gala
2009-01-08 19:10     ` Anton Vorontsov [this message]
2009-01-08 19:24       ` Kumar Gala
2009-01-08 21:55         ` [PATCH v6 " Anton Vorontsov
2009-01-09  0:17           ` Kumar Gala
2009-01-08  7:27   ` [PATCH 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC modesupport Liu Dave
2009-01-08 20:59     ` Anton Vorontsov
2009-01-08  1:31 ` [PATCH 2/2] powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E Anton Vorontsov
2009-01-09  0:17   ` Kumar Gala
  -- strict thread matches above, loose matches on Subject: below --
2009-01-05 17:40 [PATCH v4 0/2] MPC83xx PCI-E support Anton Vorontsov
2009-01-05 17:41 ` [PATCH 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support Anton Vorontsov

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=20090108191021.GA10008@oksana.dev.rtsoft.ru \
    --to=avorontsov@ru.mvista.com \
    --cc=Chang-Ming.Huang@freescale.com \
    --cc=DaveLiu@freescale.com \
    --cc=galak@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    /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.