From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Johan Hovold <johan@kernel.org>
Cc: linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH 1/2] device.h: pack struct dev_links_info
Date: Thu, 28 Feb 2019 09:35:34 +0100 [thread overview]
Message-ID: <20190228083534.GA16271@kroah.com> (raw)
In-Reply-To: <20190227133226.GQ4747@localhost>
On Wed, Feb 27, 2019 at 02:32:26PM +0100, Johan Hovold wrote:
> On Wed, Feb 27, 2019 at 01:06:45PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 27, 2019 at 11:59:51AM +0100, Johan Hovold wrote:
>
> > Yeah, that is a good point, normally we use packed to keep padding from
> > the middle of the structure from happening.
> >
> > I just don't like that 4 bytes sitting there doing nothing :)
>
> You could perhaps put them directly in struct device if the
> dev_links_info struct is just used a separator there and this really
> bothers you. :)
True :)
> > But, in thinking about this, there is no real reason that I can see that
> > this structure even is in struct device. It should be able to be in the
> > private "internal" structure.
> >
> > The patch below moves it out of struct device entirely. Overall there
> > is no memory savings, but it could give us the chance to only create
> > this structure if we really need it later on, as very few things use
> > links at this point in time.
> >
> > Rafael, there is one logic change below, the link structure is not
> > initialized until device_add() happens, instead of device_initialize().
> > Will that affect anything that you can think of? Does anyone do
> > anything with links before device_add() is called?
>
> I think device_add() may be too late.
>
> The earliest point in time when device links can be added is
> after :c:func:`device_add()` has been called for the supplier
> and :c:func:`device_initialize()` has been called for the
> consumer.
That is true today due to the way the code is set up, but it would be
good to figure out if anyone actually does call it this early.
thanks,
greg k-h
next prev parent reply other threads:[~2019-02-28 8:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-26 14:41 [PATCH 1/2] device.h: pack struct dev_links_info Greg Kroah-Hartman
2019-02-26 14:41 ` [PATCH 2/2] device.h: reorganize struct device Greg Kroah-Hartman
2019-02-26 15:40 ` [PATCH 1/2] device.h: pack struct dev_links_info Rafael J. Wysocki
2019-02-27 9:23 ` Johan Hovold
2019-02-27 9:31 ` Greg Kroah-Hartman
2019-02-27 9:40 ` Johan Hovold
2019-02-27 9:54 ` Greg Kroah-Hartman
2019-02-27 10:59 ` Johan Hovold
2019-02-27 12:06 ` Greg Kroah-Hartman
2019-02-27 13:32 ` Johan Hovold
2019-02-28 8:35 ` Greg Kroah-Hartman [this message]
2019-02-28 23:43 ` Rafael J. Wysocki
2019-02-28 13:58 ` [PATCH v2] device.h: reorganize struct device Greg Kroah-Hartman
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=20190228083534.GA16271@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.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