public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jean Delvare <khali@linux-fr.org>
Cc: Luciano Coelho <coelho@ti.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	matti.j.aaltonen@nokia.com, johannes@sipsolutions.net,
	linux-kernel@vger.kernel.org, sameo@linux.intel.com,
	mchehab@infradead.org, linux-media@vger.kernel.org,
	linux-omap@vger.kernel.org, Tony Lindgren <tony@atomide.com>,
	Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE
Date: Fri, 2 Sep 2011 17:49:10 +0200	[thread overview]
Message-ID: <201109021749.10638.arnd@arndb.de> (raw)
In-Reply-To: <20110902143713.307bbebe@endymion.delvare>

On Friday 02 September 2011, Jean Delvare wrote:
> > Doing this is a good idea, but incidentally I have just spent some time
> > with the same problem and ended up with a solution that I like better,
> > which is removing CONFIG_MFD_SUPPORT altogether.
> > 
> > The point is that there is no use enabling MFD_CORE if you don't also
> > enable any of the specific drivers.
> 
> Same holds for pretty much every subsystem, right?

I think not: MFD is a bit different from other subsystems in that it does
not have a user space interface by itself. It's also different from bus
drivers in that it is not specific to some particular class of hardware,
since it only abstracts devices that do multiple things independent of
how they do them.

It is similar to MISC_DEVICES (drivers/misc) in some regards, and I
would also like to turn that one back from menuconfig into menu for
the same reasons.

> > MFD_SUPPORT was added as a 'menuconfig'
> > before we had Kconfig warn about broken dependencies, so everything was
> > fine. Since Kconfig now issues the warnings, I think it would be better
> > to just turn the MFD menu into a plain 'menu' and remove all the
> > 'depends on MFD_SUPPORT' and 'select MFD_SUPPORT' lines from the other
> > Kconfig files.
> 
> This would make it impossible to turn off all MFD drivers at once. I
> think this is considered a feature, at least I find it very convenient
> to be able to "kill" a subsystem completely. And in the past few years
> many subsystems were turned from menu to menuconfig for this reason.
> But maybe MFD is a special case here.

I agree that it's convenient for a lot of subsystems to be able to
turn them off entirely, but in case of MFD and MISC, I cannot see a clear
use case for that.

> Anyway, if you want your patch to be applied, you'll have to send it
> for review first, as at this point all we have is Luciano's proposal.

Ok. I had actually meant to send this mail out before the patches, but
apparently it got stuck in my mail client.

	Arnd

  parent reply	other threads:[~2011-09-02 15:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-29 17:02 Kconfig unmet dependency with RADIO_WL1273 Luciano Coelho
2011-08-29 17:27 ` Randy Dunlap
2011-08-29 18:41   ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Luciano Coelho
2011-08-29 18:54     ` Grant Likely
2011-08-31 16:18     ` Jean Delvare
2011-08-31 16:49     ` Arnd Bergmann
2011-09-02 11:54       ` Luciano Coelho
2011-09-02 12:37       ` Jean Delvare
2011-09-02 14:43         ` [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES Arnd Bergmann
2011-09-05 12:41           ` Jean Delvare
2011-09-05 14:19             ` Arnd Bergmann
2011-09-05 14:27               ` Jean Delvare
2011-09-18 15:11               ` Randy Dunlap
2011-09-18 15:28                 ` Greg KH
2011-09-18 18:45                   ` Randy Dunlap
2011-09-19  8:47                     ` Arnd Bergmann
2011-09-19 13:07                       ` Greg KH
2011-09-19 15:14                         ` Arnd Bergmann
2011-09-02 14:43         ` [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT Arnd Bergmann
2011-09-05 13:09           ` Jean Delvare
2011-09-15 15:46           ` Samuel Ortiz
2011-09-02 15:49         ` Arnd Bergmann [this message]
2011-09-15 17:16     ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Grant Likely
2011-09-19 15:06       ` Arnd Bergmann

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=201109021749.10638.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=coelho@ti.com \
    --cc=grant.likely@secretlab.ca \
    --cc=johannes@sipsolutions.net \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=matti.j.aaltonen@nokia.com \
    --cc=mchehab@infradead.org \
    --cc=rdunlap@xenotime.net \
    --cc=sameo@linux.intel.com \
    --cc=tony@atomide.com \
    /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