From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] drivers/base: add bus for System-on-Chip devices
Date: Mon, 17 Oct 2011 20:03:42 +0200 [thread overview]
Message-ID: <2152965.Ns7xt0yLIG@wuerfel> (raw)
In-Reply-To: <20111017161616.GA5108@suse.de>
On Monday 17 October 2011 09:16:16 Greg KH wrote:
> On Mon, Oct 17, 2011 at 12:52:54PM +0100, Lee Jones wrote:
> > +static ssize_t soc_info_get(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf);
> > +
> > +static DEVICE_ATTR(machine, S_IRUGO, soc_info_get, NULL);
> > +static DEVICE_ATTR(family, S_IRUGO, soc_info_get, NULL);
> > +static DEVICE_ATTR(soc_id, S_IRUGO, soc_info_get, NULL);
> > +static DEVICE_ATTR(revision, S_IRUGO, soc_info_get, NULL);
> > +
> > +static ssize_t soc_info_get(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct soc_device *soc_dev =
> > + container_of(dev, struct soc_device, dev);
> > +
> > + if (attr == &dev_attr_machine)
> > + return sprintf(buf, "%s\n", soc_dev->attr->machine);
> > + if (attr == &dev_attr_family)
> > + return sprintf(buf, "%s\n", soc_dev->attr->family);
> > + if (attr == &dev_attr_revision)
> > + return sprintf(buf, "%s\n", soc_dev->attr->revision);
> > + if (attr == &dev_attr_soc_id)
> > + return sprintf(buf, "%s\n", soc_dev->attr->soc_id);
> > +
> > + return -EINVAL;
> > +
> > +}
>
> If you move around things a bit here, you can save 4 lines of code,
> please do so.
I don't think that works: the DEVICE_ATTR definitions require a prototype
for the function, and the function compares the device attribute.
An earlier version of this patch avoided the forward declaration by doing
a more expensive strcmp instead of the pointer comparison, which avoided
this problem, and I recommended against that.
> > +
> > +struct soc_device {
> > + struct device dev;
> > + struct soc_device_attribute *attr;
> > +};
>
> Why is this needed to be defined here? It should be in the .c file as
> no external code needs to know what it looks like.
You also commented that the argument to soc_device_unregister should
be a soc_device (as, consequently, the return type of soc_device_register).
Agree with that comment, but it means that the definition of struct
soc_device needs to remain visible in order to be used as the parent
for other devices.
Arnd
next prev parent reply other threads:[~2011-10-17 18:03 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 11:52 [PATCH 0/6] ux500: Export SoC information and some platform clean-up Lee Jones
2011-10-17 11:52 ` [PATCH 1/6] mach-ux500: pass parent pointer to each platform device Lee Jones
2011-10-17 11:52 ` [PATCH 2/6] drivers/base: add bus for System-on-Chip devices Lee Jones
2011-10-17 12:13 ` Jamie Iles
2011-10-17 16:16 ` Greg KH
2011-10-17 18:03 ` Arnd Bergmann [this message]
2011-10-17 18:25 ` Greg KH
2011-10-18 14:00 ` Arnd Bergmann
2011-10-18 14:44 ` Greg KH
2011-10-18 11:12 ` Lee Jones
2011-10-18 14:14 ` Arnd Bergmann
2011-10-18 14:41 ` Greg KH
2011-10-18 14:43 ` Greg KH
2011-10-17 16:18 ` Greg KH
2011-10-18 11:14 ` Lee Jones
2011-10-18 14:05 ` Arnd Bergmann
2011-10-18 14:15 ` Jamie Iles
2011-10-18 14:38 ` Greg KH
2011-10-18 14:53 ` Arnd Bergmann
2011-10-18 14:56 ` Jamie Iles
2011-10-17 11:52 ` [PATCH 3/6] Documentation: add information for new sysfs soc bus functionality Lee Jones
2011-10-17 11:52 ` [PATCH 4/6] mach-ux500: export System-on-Chip information ux500 via sysfs Lee Jones
2011-10-17 11:52 ` [PATCH 5/6] mach-ux500: move top level platform devices in sysfs to /sys/devices/socX Lee Jones
2011-10-17 11:52 ` [PATCH 6/6] mach-ux500: remove intermediary add_platform_device* functions Lee Jones
2011-10-17 11:59 ` Jamie Iles
2011-10-19 14:43 ` Lee Jones
2011-10-19 14:45 ` Jamie Iles
-- strict thread matches above, loose matches on Subject: below --
2012-01-20 16:10 [PATCH 0/6] ux500: Export SoC information and some platform clean-up Lee Jones
2012-01-20 16:10 ` [PATCH 2/6] drivers/base: add bus for System-on-Chip devices Lee Jones
2012-01-20 16:36 ` Greg KH
[not found] ` <CANmRt2gZe7dfRe5T8fS-1LGkeQXOBzcrbzL8xU+J9M7X4ZuDrA@mail.gmail.com>
2012-01-20 18:20 ` Greg KH
2012-01-20 16:39 ` Greg KH
[not found] ` <CANmRt2j4woAAg3dEtyQG4rjxRQ5Sx+4OW84Mathk4_YrFTjChQ@mail.gmail.com>
2012-01-20 18:10 ` Greg KH
2012-01-21 17:08 [PATCH 0/6] ux500: Export SoC information and some platform clean-up Lee Jones
2012-01-21 17:08 ` [PATCH 2/6] drivers/base: add bus for System-on-Chip devices Lee Jones
2012-01-28 1:05 ` Greg KH
2012-01-30 17:58 ` Arnd Bergmann
2012-01-30 18:34 ` Greg KH
2012-02-01 9:23 [PATCH 0/6] ux500: Export SoC information and some platform clean-up Lee Jones
2012-02-01 9:23 ` [PATCH 2/6] drivers/base: add bus for System-on-Chip devices Lee Jones
2012-02-01 15:52 ` Jamie Iles
2012-02-01 16:55 ` Arnd Bergmann
2012-02-06 19:22 [PATCH 0/6] ux500: Export SoC information and some platform clean-up Lee Jones
2012-02-06 19:22 ` [PATCH 2/6] drivers/base: add bus for System-on-Chip devices Lee Jones
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=2152965.Ns7xt0yLIG@wuerfel \
--to=arnd@arndb.de \
--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