linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 09/10] MCDE: Add build files and bus
Date: Tue, 30 Nov 2010 22:05:50 +0000	[thread overview]
Message-ID: <20101130220550.GD8521@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20101130184834.GA16055@kroah.com>

On Tue, Nov 30, 2010 at 10:48:34AM -0800, Greg KH wrote:
> On Tue, Nov 30, 2010 at 06:40:49PM +0000, Russell King - ARM Linux wrote:
> > There's lots of static devices, not only platform devices, in the ARM
> > tree.  It's going to be a hell of a lot of work to fix this all up
> > properly.
> 
> I agree, it's been abused for many years this way :(

I don't agree that it is abuse - it was something explicitly allowed by
the original device model design by Patrick, with the condition that
such a device was never unregistered.  That's exactly the way we treat
these devices.

What I'm slightly concerned about is that this is going to needlessly
bloat the kernel - we're going to have to find some other way to store
this information, and create devices from that - which means additional
code to do the creation, and data structures for it to create these from.
There will be additional wastage from kmalloc as kmalloc doesn't allocate
just the size you ask for, but normally a power of two which will contain
the size.

That could potentially mean that as the device structure is 216 bytes,
kmalloc will use the 256 byte allocation size, which means a wastage of
40 bytes per device structure.  On top of that goes the size of
resources with the allocation slop on top for that, and then there's
another allocation for the platform data.

Has anyone considered these implications before making this choice?

  reply	other threads:[~2010-11-30 22:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <F45880696056844FA6A73F415B568C6953604E802E@EXDCVYMBSTM006.EQ1STM.local>
2010-11-25 12:25 ` [PATCH 09/10] MCDE: Add build files and bus Marcus LORENTZON
2010-11-25 16:47   ` Arnd Bergmann
2010-11-25 18:00     ` Marcus LORENTZON
2010-11-26 11:24       ` Arnd Bergmann
2010-11-30 14:18         ` Linus Walleij
2010-11-30 15:21           ` Arnd Bergmann
2010-11-30 16:24             ` Greg KH
2010-11-30 18:40             ` Russell King - ARM Linux
2010-11-30 18:48               ` Greg KH
2010-11-30 22:05                 ` Russell King - ARM Linux [this message]
2010-11-30 23:05                   ` Greg KH
2010-11-30 23:42                     ` Russell King - ARM Linux
2010-11-30 23:49                       ` Greg KH
2010-12-01 12:53                       ` Peter Stuge
2010-12-01 13:02                         ` Russell King - ARM Linux
2010-12-01 15:39                       ` Arnd Bergmann
2010-12-04  6:52         ` Dave Airlie
2010-12-04 21:34         ` Alex Deucher
2010-12-05 11:28           ` Daniel Vetter
2011-03-12 15:59             ` Rob Clark
2011-03-14 14:03               ` Marcus Lorentzon
2011-03-14 20:35                 ` Rob Clark
2010-12-16 18:26         ` Marcus Lorentzon
2010-12-17 11:22           ` Arnd Bergmann
2010-12-17 12:02             ` Marcus Lorentzon
2010-11-10 12:04 [PATCH 00/10] MCDE: Add frame buffer device driver Jimmy Rubin
2010-11-10 12:04 ` [PATCH 01/10] MCDE: Add hardware abstraction layer Jimmy Rubin
2010-11-10 12:04   ` [PATCH 02/10] MCDE: Add configuration registers Jimmy Rubin
2010-11-10 12:04     ` [PATCH 03/10] MCDE: Add pixel processing registers Jimmy Rubin
2010-11-10 12:04       ` [PATCH 04/10] MCDE: Add formatter registers Jimmy Rubin
2010-11-10 12:04         ` [PATCH 05/10] MCDE: Add dsi link registers Jimmy Rubin
2010-11-10 12:04           ` [PATCH 06/10] MCDE: Add generic display Jimmy Rubin
2010-11-10 12:04             ` [PATCH 07/10] MCDE: Add display subsystem framework Jimmy Rubin
2010-11-10 12:04               ` [PATCH 08/10] MCDE: Add frame buffer device Jimmy Rubin
2010-11-10 12:04                 ` [PATCH 09/10] MCDE: Add build files and bus Jimmy Rubin
2010-11-12 16:23                   ` Arnd Bergmann

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=20101130220550.GD8521@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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 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).