All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-iio@vger.kernel.org, Michael.Hennerich@analog.com
Subject: Re: [RFC PATCH] IIO: break out const elements of iio_dev configuration
Date: Fri, 29 Apr 2011 13:42:40 +0100	[thread overview]
Message-ID: <4DBAB240.80108@cam.ac.uk> (raw)
In-Reply-To: <4DB830CB.8060905@cam.ac.uk>

Bump.  All: Yes or no to this?  It'll have to be one mass change patch.
Arnd is in favour. I can see the long term advantages.

We could push this in before chan_spec introduction then add the new
stuff to it as we go.  Or I can leave it at the top of my tree after
all the changes that are queued up as one mass change patch.

Either is fine with me - perhaps even push this on to Greg very late
indeed so any new drivers for the next merge window are moved over as well?


On 04/27/11 16:05, Jonathan Cameron wrote:
> On 04/27/11 14:58, Arnd Bergmann wrote:
>> On Wednesday 27 April 2011, Jonathan Cameron wrote:
>>> In conclusion max1363 gets bigger in all ways if we break this
>>> stuff out.  That is just down to the large number of devices supported.
>>> lis3l02dq which supports only one part gets smaller.
>>>
>>> So not a clear descision either way as far as I am concerned, but
>>> putting the channel_spec into this structure is pretty costly for
>>> typical multipart drivers.
>>>
>>> So the upshot of this RFC to my mind is: Is the clarity gained
>>> a good idea?
>>>
>>> What do people think?
>>
>> I suggested this initially, so it shouldn't surprise that I like
>> the patch.
>>
>> For the increase in size, that seems to be purely because of the
>> change in one data structure from bool to pointer, right?
>> If you reorder the members of max1363_chip_info to remove the
>> padding, I think you can make up for that.
> Changes in there were a bit more than that, but I take your point.
> The difference is pretty minor.  The size argument was more one
> for avoiding putting chan_spec structures in the iio_info struct.
> That meant a lot more variants of the iio_info structs were needed
> in that driver.  It was kind of obvious from the lines of code that
> would need to be added as well, but I had the size numbers too hand.
> 
> For reference, reordering max1363_chip_info gets us:
> 
> 26571   drivers/staging/iio/adc/max1363.ko
> and
> max1363                15884  0
> 
> So not a great saving - but the difference are pretty trivial anyway
> and there are sure to be numerous other ways of making minor savings
> in that driver! (can get to 15748 merely by making num_modes a u8)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

      reply	other threads:[~2011-04-29 12:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27 10:09 [RFC PATCH] IIO: break out const elements of iio_dev configuration Jonathan Cameron
2011-04-27 13:58 ` Arnd Bergmann
2011-04-27 15:05   ` Jonathan Cameron
2011-04-29 12:42     ` Jonathan Cameron [this message]

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=4DBAB240.80108@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=Michael.Hennerich@analog.com \
    --cc=arnd@arndb.de \
    --cc=linux-iio@vger.kernel.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.