All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] mach-ux500: export System-on-Chip information via sysfs
Date: Wed, 13 Jul 2011 22:51:48 +0200	[thread overview]
Message-ID: <201107132251.48606.arnd@arndb.de> (raw)
In-Reply-To: <20110713203226.GA23055@suse.de>

On Wednesday 13 July 2011 22:32:26 Greg KH wrote:
> On Wed, Jul 13, 2011 at 09:40:35AM -0700, Saravana Kannan wrote:
> > On 07/13/2011 12:55 AM, Lee Jones wrote:
> > >On 12/07/11 17:29, Saravana Kannan wrote:
> > >I initially had it all as part of soc_device_register, but Arnd told me
> > >to remove it in this patch-set.
> > >
> > >See here:
> > >
> > >On 17/04/11 19:36, Arnd Bergmann wrote:
> > >>For the nonstandard attributes, I would recommend having the individual
> > >>drivers call device_create_file, in order to discourage the use of
> > >>device specific attribute names.
> > 
> > Arnd,
> > 
> > I don't think forcing individual driver to call device_create_file()
> > is really going to be much of a discouragement.
> 
> Yes it is as calling that is broken and wrong and userspace will race
> with the kernel and bad things will happen on the wrong phase of the
> moon.
> 
> But again, I never saw the original series to explain why...

This is about attributes to the main device that acts as a parent for all
devices on the SoC, so there is no user space at the time.

IIRC, the original patch was documenting a set of standard attributes and
letting the SoC specific driver pass a set of static attributes in the
hope that they do whatever is documented.

In one of my review comments, I asked this to be changed to pass a data
structure with the actual contents of those attributes and to make
the implementation common to the soc independent code, in order to
reduce the amount of code needed in each soc implementation, to enforce
consistent behavior, and to make it more obvious (and painful) when an
soc implementation adds a nonstandard attribute.

It seems the final outcome was to have a data structure of function
pointers to get the attribute contents, which is less nice but still
acceptable IMHO.

	Arnd

  reply	other threads:[~2011-07-13 20:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-12 13:08 [PATCH 1/3] Framework for exporting System-on-Chip information via sysfs Lee Jones
2011-07-12 13:08 ` [PATCH 2/3] mach-ux500: export " Lee Jones
2011-07-12 16:29   ` Saravana Kannan
2011-07-13  7:55     ` Lee Jones
2011-07-13 16:40       ` Saravana Kannan
2011-07-13 20:32         ` Greg KH
2011-07-13 20:51           ` Arnd Bergmann [this message]
2011-07-14  6:42             ` Lee Jones
2011-07-14 12:58               ` Arnd Bergmann
2011-07-14 13:04                 ` Lee Jones
2011-07-14 17:25             ` Saravana Kannan
2011-07-15  6:27               ` Lee Jones
2011-07-12 16:47   ` Arnd Bergmann
2011-07-13  8:10     ` Lee Jones
2011-07-13 13:42       ` Arnd Bergmann
2011-07-13 14:31         ` Lee Jones
2011-07-13 16:20           ` Arnd Bergmann
2011-07-12 13:08 ` [PATCH 3/3] Add documenation for new sysfs devices/soc functionallity Lee Jones
2011-07-12 14:13 ` [PATCH 1/3] Framework for exporting System-on-Chip information via sysfs Baruch Siach
2011-07-12 16:08   ` Greg KH
2011-07-13  7:16     ` Lee Jones
2011-07-13  7:53       ` Greg KH
2011-07-13  8:27         ` Lee Jones
2011-07-15 14:02 ` Arnd Bergmann
  -- strict thread matches above, loose matches on Subject: below --
2011-04-14 14:49 [PATCH 0/3] Export valuable System-on-Chip information to user-space " Lee Jones
2011-04-14 14:49 ` [PATCH 2/3] mach-ux500: export System-on-Chip information " Lee Jones
2011-04-17 18:40   ` Arnd Bergmann
2011-04-11 18:01 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=201107132251.48606.arnd@arndb.de \
    --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 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.