From: Jamie Iles <jamie@jamieiles.com>
To: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
"avictor.za@gmail.com" <avictor.za@gmail.com>,
Jamie Iles <jamie@jamieiles.com>,
plagnioj@jcrosoft.com, linux-arm-kernel@lists.infradead.org,
nicolas.ferre@atmel.com, netdev@vger.kernel.org
Subject: Re: [PATCHv2 3/9] macb: unify at91 and avr32 platform data
Date: Thu, 17 Mar 2011 09:34:03 +0000 [thread overview]
Message-ID: <20110317093403.GA15396@pulham.picochip.com> (raw)
In-Reply-To: <87wrjyksnm.fsf@macbook.be.48ers.dk>
On Thu, Mar 17, 2011 at 10:22:53AM +0100, Peter Korsgaard wrote:
> >>>>> "Russell" == Russell King <- ARM Linux <linux@arm.linux.org.uk>> writes:
>
> Hi,
>
> >> That should probably be cleaned up as well then. Sharing platform_data
> >> structures between unrelated drivers seems like quite a mess to me.
>
> Russell> Why should every driver have a separate platform data structure?
> Russell> Is it right to end up with thousands of unique data structures each
> Russell> specific to a particular driver? To me, that sounds like a headache
> Russell> waiting to happen.
>
> Well, the point of the platform data is to provide driver specific
> (E.G. not generic) data to the driver, so in general it will be
> different for different hardware.
>
> The current situation with 2 different structure defination depending on
> arch, macro magic and 1 of these structures also used for a 2nd driver
> isn't optimal.
>
> But ok, I don't feel strongly about struct macb_platform_data also being
> used for the old at91_ether driver, but it shouldn't be called
> eth_platform_data as it isn't really a generic structure.
Ok, I'll rename to macb_platform_data and update at91_ether to use that
with a comment describing that we're sharing the platform data with
macb. At least that gets rid of the preprocessor stuff in board.h for
at91 too.
Jamie
next prev parent reply other threads:[~2011-03-17 9:34 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-15 10:14 [PATCHv2 0/9] macb: add support for Cadence GEM Jamie Iles
2011-03-15 10:14 ` [PATCHv2 1/9] at91: provide macb clks with "pclk" and "hclk" name Jamie Iles
2011-03-15 12:35 ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-15 12:44 ` Jamie Iles
2011-03-16 6:53 ` avictor.za
2011-03-16 8:38 ` Russell King - ARM Linux
2011-03-17 9:22 ` Andrew Victor
2011-03-17 10:00 ` Russell King - ARM Linux
2011-03-17 10:09 ` Jamie Iles
2011-03-15 10:14 ` [PATCHv2 2/9] macb: remove conditional clk handling Jamie Iles
2011-03-15 10:14 ` [PATCHv2 3/9] macb: unify at91 and avr32 platform data Jamie Iles
2011-03-15 11:14 ` Peter Korsgaard
2011-03-15 11:34 ` Jamie Iles
2011-03-15 12:36 ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-17 8:43 ` avictor.za
2011-03-17 8:48 ` Peter Korsgaard
2011-03-17 8:58 ` Russell King - ARM Linux
2011-03-17 9:22 ` Peter Korsgaard
2011-03-17 9:34 ` Jamie Iles [this message]
2011-03-17 21:51 ` Jamie Iles
2011-03-18 15:41 ` Russell King - ARM Linux
2011-03-18 15:48 ` Jamie Iles
2011-03-18 15:54 ` Russell King - ARM Linux
2011-03-19 15:49 ` Nicolas Ferre
2011-04-23 5:48 ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-15 10:14 ` [PATCHv2 4/9] macb: convert printk to netdev_ and friends Jamie Iles
2011-03-15 12:36 ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-15 10:14 ` [PATCHv2 5/9] macb: initial support for Cadence GEM Jamie Iles
2011-03-15 10:14 ` [PATCHv2 6/9] macb: support higher rate GEM MDIO clock divisors Jamie Iles
2011-03-15 10:14 ` [PATCHv2 7/9] macb: support statistics for GEM devices Jamie Iles
2011-03-15 10:14 ` [PATCHv2 8/9] macb: support DMA bus widths > 32 bits Jamie Iles
2011-03-15 10:14 ` [PATCHv2 9/9] macb: allow GEM to have configurable receive buffer size Jamie Iles
2011-03-16 20:17 ` [PATCHv2 0/9] macb: add support for Cadence GEM David Miller
2011-03-21 6:38 ` Nicolas Ferre
2011-03-21 11:18 ` Jamie Iles
2011-03-22 16:18 ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-22 16:39 ` Jamie Iles
2011-03-22 17:55 ` Jamie Iles
2011-03-24 16:25 ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-31 9:40 ` Jamie Iles
2011-04-05 10:28 ` Jean-Christophe PLAGNIOL-VILLARD
2011-04-05 10:49 ` Jamie Iles
2011-04-05 11:21 ` Jean-Christophe PLAGNIOL-VILLARD
2011-04-05 11:47 ` Jamie Iles
2011-04-05 11:57 ` Jean-Christophe PLAGNIOL-VILLARD
2011-04-05 11:12 ` Peter Korsgaard
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=20110317093403.GA15396@pulham.picochip.com \
--to=jamie@jamieiles.com \
--cc=avictor.za@gmail.com \
--cc=jacmet@sunsite.dk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@atmel.com \
--cc=plagnioj@jcrosoft.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).