LKML Archive on
help / color / mirror / Atom feed
From: Richard Purdie <>
To: Greg KH <>
Cc: James Simmons <>,
	LKML <>,
	akpm <>,
	Marcin Juszkiewicz <>
Subject: Re: Git backlight subsystem tree
Date: Thu, 08 Feb 2007 23:50:23 +0000	[thread overview]
Message-ID: <1170978623.5849.63.camel@localhost.localdomain> (raw)
In-Reply-To: <>

Hi Greg,

On Thu, 2007-02-08 at 13:23 -0800, Greg KH wrote:
> On Thu, Feb 08, 2007 at 06:32:02PM +0000, James Simmons wrote:
> > I CC Greg to explain. The backlight class didn't go away. The way it is 
> > handled is different.
> Have a pointer to the patch so I can help explain better?

You've been cc'd on the proposed patch a couple of times in this thread
so it should be in your mailbox now.

> As a short summary, 'struct class_device' is going away.  Using a
> 'struct device' in its place is what the conversion should have just
> done, no functionality change otherwise.

The backlight class is drivers/video/backlight/backlight.c and if I
understand things correctly what shows up in sysfs changes.

At the moment (as I understand the code which could be wrong), the
backlight functionality is tagged onto an existing device. Taking
drivers/video/backlight/corgi_bl.c as an example, the corgi_bl device
exists under /sys/devices/platform/corgi_bl with an associated struct
device. The backlight code then appends some magic to this to link in
some class attributes that show up under /sys/class/backlight. There is
only ever one device.

By replacing class_device_register() with device_create(), the proposed
patch appears to generate a second struct device with the original as
its parent. I'm not sure where it appears in /sys/devices? Having
another full blown struct device around makes me uneasy as wherever it
appears, we only have one device, not two.

If I had some kind of platform device which had an LED, backlight and
say battery component and registered with the three appropriate classes
would that mean four struct devices? Where under /sys/devices do they
each appear?

Also, it was mentioned that a parent struct device is a requirement and
this isn't the case for all backlight users. I think this constraint on
device_create has been removed in more recent code though? 


  parent reply	other threads:[~2007-02-08 23:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08  2:30 Richard Purdie
2007-02-08  3:01 ` Andrew Morton
2007-02-08 15:28 ` James Simmons
2007-02-08 17:59   ` Richard Purdie
2007-02-08 18:32     ` James Simmons
2007-02-08 19:37       ` Richard Purdie
2007-02-08 21:23       ` Greg KH
2007-02-08 21:54         ` James Simmons
2007-02-08 23:41           ` Greg KH
2007-02-08 23:50         ` Richard Purdie [this message]
2007-02-09  0:23           ` Greg KH

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1170978623.5849.63.camel@localhost.localdomain \ \ \ \ \ \ \
    --subject='Re: Git backlight subsystem tree' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).