Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423267AbXBHTh0 (ORCPT ); Thu, 8 Feb 2007 14:37:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1423280AbXBHTh0 (ORCPT ); Thu, 8 Feb 2007 14:37:26 -0500 Received: from tim.rpsys.net ([194.106.48.114]:38987 "EHLO tim.rpsys.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423278AbXBHThZ (ORCPT ); Thu, 8 Feb 2007 14:37:25 -0500 Subject: Re: Git backlight subsystem tree From: Richard Purdie To: James Simmons Cc: LKML , akpm , Marcin Juszkiewicz , Greg KH In-Reply-To: References: <1170901826.5859.2.camel@localhost.localdomain> <1170957595.5849.11.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 08 Feb 2007 19:37:06 +0000 Message-Id: <1170963426.5849.23.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1412 Lines: 35 On Thu, 2007-02-08 at 18:32 +0000, James Simmons wrote: > On Thu, 8 Feb 2007, Richard Purdie wrote: > > > On Thu, 2007-02-08 at 15:28 +0000, James Simmons wrote: > > > I have some patches that move the backlight away from using the class > > > stuff. The only problem is the patch requires all backlight devices > > > to be linked to a real struct device. Right now the acpi backligths are > > > not. > > > > Why would you want to do that? [...] > > I CC Greg to explain. The backlight class didn't go away. The way it is > handled is different. >From the changelog and a quick skim though the patch it looked like you were just removing the class functionality and using the struct device directly but I see what you're trying to do now. I'm not sure I agree with it though as it results in two devices for each backlight user as almost all users have an existing struct device. The current approach allows you to attach the class to an existing device and also means you can attach multiple classes to a given device which gives more flexibility. So the above question stills stands, why would you want to do this (apart from removing some code)? Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/