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
next prev parent 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.