mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
To: "Richard Purdie" <rpurdie@rpsys.net>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [patch 6/6] Move per-device data out of backlight_properties
Date: Fri, 11 Aug 2006 08:27:19 -0400	[thread overview]
Message-ID: <d120d5000608110527q142a727ex5c2223a9aed5aeaa@mail.gmail.com> (raw)
In-Reply-To: <1155283327.6354.6.camel@localhost.localdomain>

On 8/11/06, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Fri, 2006-08-11 at 01:03 -0400, Dmitry Torokhov wrote:
> > plain text document attachment (backlight-move-data.patch)
> > Backlight: move per-device data out of backlight_properties
> >
> > Data such as current brightness belongs to a device and should not
> > be part of a structure shared between several devices.
>
> I agree there's an issue to address here. Looking at this patch very
> quickly, it breaks all the existing backlight drivers as they know about
> the variables in struct backlight_properties and all their references
> need to be updated e.g.: corgi_bl.c:
>
> if (bd->props->power != FB_BLANK_UNBLANK)
> intensity = 0;
> if (bd->props->fb_blank != FB_BLANK_UNBLANK)
> intensity = 0;
>

Oops, I had them all updated but apparently lost that change. I'll fix
it and resend.

> Thinking about this, ideally, struct backlight_properties would be left
> containing the backlight properties in but become part of struct
> backlight_device (and allocated with it).

Why would you want to separate properties into a structure? You don't
normally pass a set of properties around so I am not sure why would we
need this...

-- 
Dmitry

  reply	other threads:[~2006-08-11 12:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-11  5:03 [patch 0/6] Backlight & lcd fixes/cleanups Dmitry Torokhov
2006-08-11  5:03 ` [patch 1/6] Convert to use default class device attributes Dmitry Torokhov
2006-08-11  5:03 ` [patch 2/6] Fix error handling when registering new device Dmitry Torokhov
2006-08-11  5:03 ` [patch 3/6] Get rid of excessive amount of likely()s Dmitry Torokhov
2006-08-11  5:03 ` [patch 4/6] Remove "owner" from backlight_properties structure Dmitry Torokhov
2006-08-11  5:03 ` [patch 5/6] Convert to use mutexes instead of semaphores Dmitry Torokhov
2006-08-11 12:58   ` Dmitry Torokhov
2006-08-11 13:16     ` Richard Purdie
2006-08-11 13:34       ` Dmitry Torokhov
2006-08-11 13:42         ` Michael Hanselmann
2006-08-11 14:07           ` Dmitry Torokhov
2006-08-11 16:45             ` Richard Purdie
2006-08-11 17:20               ` Dmitry Torokhov
2006-08-29 20:54               ` Michael Hanselmann
2006-08-11  5:03 ` [patch 6/6] Move per-device data out of backlight_properties Dmitry Torokhov
2006-08-11  8:02   ` Richard Purdie
2006-08-11 12:27     ` Dmitry Torokhov [this message]
2006-08-11 12:55       ` Richard Purdie
2006-08-11 13:10         ` Dmitry Torokhov

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=d120d5000608110527q142a727ex5c2223a9aed5aeaa@mail.gmail.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpurdie@rpsys.net \
    /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

all inboxes | Powered by JetHome®