From: Grant Likely <grant.likely@secretlab.ca> To: Greg KH <gregkh@suse.de> Cc: Andres Salomon <dilinger@queued.net>, Samuel Ortiz <sameo@linux.intel.com>, linux-kernel@vger.kernel.org, Mark Brown <broonie@opensource.wolfsonmicro.com>, khali@linux-fr.org, ben-linux@fluff.org, Peter Korsgaard <jacmet@sunsite.dk>, Mauro Carvalho Chehab <mchehab@infradead.org>, David Brownell <dbrownell@users.sourceforge.net>, linux-i2c@vger.kernel.org, linux-media@vger.kernel.org, netdev@vger.kernel.org, spi-devel-general@lists.sourceforge.net, Mocean Laboratories <info@mocean-labs.com> Subject: Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers Date: Thu, 7 Apr 2011 01:04:04 -0700 [thread overview] Message-ID: <20110407080404.GF6427@angua.secretlab.ca> (raw) In-Reply-To: <20110406183854.GA10058@suse.de> On Wed, Apr 06, 2011 at 11:38:54AM -0700, Greg KH wrote: > On Wed, Apr 06, 2011 at 11:25:57AM -0700, Andres Salomon wrote: > > > > We've been faced with the problem of being able to pass both MFD > > > > related data and a platform_data pointer to some of those drivers. > > > > Squeezing the MFD bits in the sub driver platform_data pointer > > > > doesn't work for drivers that know nothing about MFDs. It also adds > > > > an additional dependency on the MFD API to all MFD sub drivers. > > > > That prevents any of those drivers to eventually be used as plain > > > > platform device drivers. > > > > > > Then they shouldn't be "plain" platform drivers, that should only be > > > reserved for drivers that are the "lowest" type. Just make them MFD > > > devices and go from there. > > > > > > The problem is of mixing "plain" platform devices and MFD devices. > > Then don't do that. >From my perspective, MFD devices are little more than a bag of platform_devices, with the MFD layer provides infrastructure for managing it. It isn't that there are 'plain' platform device and 'mfd' devices. There are only platform_devices, but some of the drivers use additional data stored in a struct mfd. Personally, I'm not thrilled with the approach of using struct mfd, or more specifically making it available to drivers, but on the ugly scale it isn't very high. However, the changes on how struct mfd is passed that were merged in 2.6.39 were actively dangerous and are going to be reverted. Yet a method is still needed to pass the struct mfd in a safe way. I don't have a problem with adding the mfd pointer to struct platform_device, even if it should just be a stop gap to something better. Independently, I have been experimenting with typesafe methods for attaching data to devices which may very well be the long term approach, but for the short term I see no problem with adding the mfd pointer, particularly because it is by far safer than any of the other immediately available options. g.
WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> To: Greg KH <gregkh-l3A5Bk7waGM@public.gmane.org> Cc: Andres Salomon <dilinger-pFFUokh25LWsTnJN9+BGXg@public.gmane.org>, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>, khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org, ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, Peter Korsgaard <jacmet-OfajU3CKLf1/SzgSGea1oA@public.gmane.org>, Mauro Carvalho Chehab <mchehab-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, David Brownell <dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Mocean Laboratories <info-l7gf1WXxx3uGw+nKnLezzg@public.gmane.org> Subject: Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers Date: Thu, 7 Apr 2011 01:04:04 -0700 [thread overview] Message-ID: <20110407080404.GF6427@angua.secretlab.ca> (raw) In-Reply-To: <20110406183854.GA10058-l3A5Bk7waGM@public.gmane.org> On Wed, Apr 06, 2011 at 11:38:54AM -0700, Greg KH wrote: > On Wed, Apr 06, 2011 at 11:25:57AM -0700, Andres Salomon wrote: > > > > We've been faced with the problem of being able to pass both MFD > > > > related data and a platform_data pointer to some of those drivers. > > > > Squeezing the MFD bits in the sub driver platform_data pointer > > > > doesn't work for drivers that know nothing about MFDs. It also adds > > > > an additional dependency on the MFD API to all MFD sub drivers. > > > > That prevents any of those drivers to eventually be used as plain > > > > platform device drivers. > > > > > > Then they shouldn't be "plain" platform drivers, that should only be > > > reserved for drivers that are the "lowest" type. Just make them MFD > > > devices and go from there. > > > > > > The problem is of mixing "plain" platform devices and MFD devices. > > Then don't do that. >From my perspective, MFD devices are little more than a bag of platform_devices, with the MFD layer provides infrastructure for managing it. It isn't that there are 'plain' platform device and 'mfd' devices. There are only platform_devices, but some of the drivers use additional data stored in a struct mfd. Personally, I'm not thrilled with the approach of using struct mfd, or more specifically making it available to drivers, but on the ugly scale it isn't very high. However, the changes on how struct mfd is passed that were merged in 2.6.39 were actively dangerous and are going to be reverted. Yet a method is still needed to pass the struct mfd in a safe way. I don't have a problem with adding the mfd pointer to struct platform_device, even if it should just be a stop gap to something better. Independently, I have been experimenting with typesafe methods for attaching data to devices which may very well be the long term approach, but for the short term I see no problem with adding the mfd pointer, particularly because it is by far safer than any of the other immediately available options. g.
next prev parent reply other threads:[~2011-04-07 8:04 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-02-03 3:54 [RFC] [PATCH 0/19] mfd sharing support Andres Salomon 2011-02-03 3:55 ` [PATCH 01/19] mfd-core: unconditionally add mfd_cell to every platform_device Andres Salomon 2011-02-03 3:58 ` [PATCH 02/19] jz4740: mfd_cell is now implicitly available to drivers Andres Salomon 2011-02-03 3:58 ` [lm-sensors] [PATCH 02/19] jz4740: mfd_cell is now implicitly Andres Salomon 2011-02-03 8:09 ` [PATCH 02/19] jz4740: mfd_cell is now implicitly available to drivers Jean Delvare 2011-02-03 8:09 ` [lm-sensors] [PATCH 02/19] jz4740: mfd_cell is now implicitly Jean Delvare 2011-02-03 4:01 ` [PATCH 03/19] ab3550: mfd_cell is now implicitly available to drivers Andres Salomon 2011-02-03 4:01 ` Andres Salomon 2011-02-04 8:20 ` Mattias Wallin 2011-02-04 8:20 ` Mattias Wallin 2011-02-03 4:03 ` [PATCH 04/19] ab3100: " Andres Salomon 2011-02-03 4:03 ` Andres Salomon 2011-02-03 12:52 ` Linus Walleij 2011-02-03 12:52 ` Linus Walleij 2011-02-03 4:04 ` [PATCH 05/19] asic3: " Andres Salomon 2011-02-03 4:05 ` [PATCH 06/19] htc-pasic3: " Andres Salomon 2011-02-03 4:08 ` [PATCH 07/19] timberdale: " Andres Salomon 2011-02-03 4:08 ` Andres Salomon 2011-03-31 23:05 ` Grant Likely 2011-04-01 11:20 ` Samuel Ortiz 2011-04-01 11:20 ` Samuel Ortiz 2011-04-01 17:47 ` Andres Salomon 2011-04-01 17:47 ` Andres Salomon 2011-04-01 17:56 ` Grant Likely 2011-04-01 17:56 ` Grant Likely 2011-04-01 18:00 ` Grant Likely 2011-04-01 23:52 ` Samuel Ortiz 2011-04-01 23:52 ` Samuel Ortiz 2011-04-01 23:58 ` Grant Likely 2011-04-01 23:58 ` Grant Likely 2011-04-02 0:10 ` Andres Salomon 2011-04-02 0:10 ` Andres Salomon 2011-04-04 10:03 ` Samuel Ortiz 2011-04-04 10:03 ` Samuel Ortiz 2011-04-05 3:04 ` Grant Likely 2011-04-06 15:23 ` Samuel Ortiz 2011-04-06 15:58 ` Greg KH 2011-04-06 15:58 ` Greg KH 2011-04-06 17:05 ` Samuel Ortiz 2011-04-06 17:16 ` Ben Hutchings 2011-04-06 17:51 ` Samuel Ortiz 2011-04-06 17:51 ` Samuel Ortiz 2011-04-06 18:07 ` Ben Hutchings 2011-04-06 18:07 ` Ben Hutchings 2011-04-06 17:56 ` Greg KH 2011-04-06 18:25 ` Andres Salomon 2011-04-06 18:38 ` Greg KH 2011-04-06 18:38 ` Greg KH 2011-04-07 8:04 ` Grant Likely [this message] 2011-04-07 8:04 ` Grant Likely 2011-04-06 18:47 ` Samuel Ortiz 2011-04-06 18:59 ` Felipe Balbi 2011-04-06 18:59 ` Felipe Balbi 2011-04-06 22:09 ` Greg KH 2011-04-06 22:09 ` Greg KH 2011-04-07 8:09 ` Felipe Balbi 2011-04-07 13:40 ` Samuel Ortiz 2011-04-07 13:40 ` Samuel Ortiz 2011-04-07 14:35 ` Grant Likely 2011-04-07 15:03 ` Samuel Ortiz 2011-04-07 15:03 ` Samuel Ortiz 2011-04-07 18:06 ` Grant Likely 2011-04-07 18:06 ` Grant Likely 2011-04-07 16:24 ` Grant Likely 2011-04-01 18:26 ` Samuel Ortiz 2011-02-03 4:09 ` [PATCH 08/19] t7166xb: " Andres Salomon 2011-02-03 4:11 ` [PATCH 09/19] wl1273: " Andres Salomon 2011-02-03 4:12 ` [PATCH 10/19] sh_mobile_sdhi: " Andres Salomon 2011-02-03 4:13 ` [PATCH 11/19] tc6393xb: " Andres Salomon 2011-02-03 4:15 ` [PATCH 12/19] twl4030: " Andres Salomon 2011-02-03 6:05 ` Dmitry Torokhov 2011-02-03 6:39 ` Andres Salomon 2011-02-03 6:53 ` Dmitry Torokhov 2011-02-03 7:03 ` Andres Salomon 2011-02-03 7:03 ` Andres Salomon 2011-02-03 9:31 ` Mark Brown 2011-02-03 9:31 ` Mark Brown 2011-02-05 2:39 ` Andres Salomon 2011-02-05 3:25 ` Andres Salomon 2011-02-03 12:23 ` Peter Ujfalusi 2011-02-03 12:23 ` Peter Ujfalusi 2011-02-04 10:41 ` Uwe Kleine-König 2011-02-03 4:16 ` [PATCH 13/19] tc6387xb: " Andres Salomon 2011-02-03 4:17 ` [PATCH 14/19] janz: " Andres Salomon 2011-02-03 4:20 ` [PATCH 15/19] mc13xxx: " Andres Salomon 2011-02-03 4:20 ` Andres Salomon 2011-02-04 9:34 ` Uwe Kleine-König 2011-02-04 9:34 ` Uwe Kleine-König 2011-02-04 10:13 ` Uwe Kleine-König 2011-02-04 10:13 ` Uwe Kleine-König 2011-02-04 10:16 ` Andres Salomon 2011-02-04 10:16 ` Andres Salomon 2011-02-03 4:21 ` [PATCH 16/19] mfd-core: drop platform_data/data_size from core mfd_cell struct Andres Salomon 2011-02-03 4:22 ` [PATCH 17/19] mfd-core: add refcounting support to mfd_cells Andres Salomon 2011-02-03 4:23 ` [PATCH 18/19] mfd-core: add platform_device sharing support for mfd Andres Salomon 2011-02-03 4:26 ` [PATCH 19/19] cs5535-mfd: add sharing for acpi/pms cells Andres Salomon
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=20110407080404.GF6427@angua.secretlab.ca \ --to=grant.likely@secretlab.ca \ --cc=ben-linux@fluff.org \ --cc=broonie@opensource.wolfsonmicro.com \ --cc=dbrownell@users.sourceforge.net \ --cc=dilinger@queued.net \ --cc=gregkh@suse.de \ --cc=info@mocean-labs.com \ --cc=jacmet@sunsite.dk \ --cc=khali@linux-fr.org \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=mchehab@infradead.org \ --cc=netdev@vger.kernel.org \ --cc=sameo@linux.intel.com \ --cc=spi-devel-general@lists.sourceforge.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: linkBe 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.