All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
	Lee Jones <lee.jones@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Cory Maccarrone <darkstar6262@gmail.com>,
	David Dajun Chen <dchen@diasemi.com>,
	Dong Aisheng <dong.aisheng@linaro.org>,
	Eric Miao <eric.miao@marvell.com>,
	Graeme Gregory <gg@slimlogic.co.uk>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	Haojian Zhuang <haojian.zhuang@marvell.com>,
	jinyoungp@nvidia.com,
	Jorge Eduardo Candelaria <jedu@slimlogic.co.uk>,
	Laxman Dewangan <ldewangan@nvidia.com>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Mattias NILSSON <mattias.i.nilsson@stericsson.com>,
	Michael Hennerich <michael.hennerich@analog.com>,
	Mike Rapoport <mike@compulab.co.il>
Subject: Re: [PATCH v2 00/22] mfd: demodularization of non-modular drivers
Date: Wed, 5 Dec 2018 13:40:16 +0000	[thread overview]
Message-ID: <20181205134016.GE16508@imbe.wolfsonmicro.main> (raw)
In-Reply-To: <CACRpkdZs0uSrsY66X67=h=BPy=P_5korWVM8kDbzTXrhrvKvcQ@mail.gmail.com>

On Wed, Dec 05, 2018 at 12:48:47PM +0100, Linus Walleij wrote:
> On Wed, Dec 5, 2018 at 12:36 PM Charles Keepax
> <ckeepax@opensource.cirrus.com> wrote:
> > On Sun, Dec 02, 2018 at 11:23:07PM -0500, Paul Gortmaker wrote:
> > > The solution to #4 is similar - we delete the ".remove" function and
> > > the binding into the platform_driver struct.  However, since the same
> > > ".remove" function could also be triggered by an "unbind" (such as for
> > > pass-through of a device to a guest instance)  - so we also explicitly
> > > disable any unbind for the driver.
> > >
> > > The unbind mask allows us to ensure we will see if there was some odd
> > > corner case out there that was relying on it.  Typically it would be a
> > > multi-port ethernet card passing a port through to a guest, so a
> > > sensible use case in MFD drivers seems highly unlikely.  This same
> > > solution has already been used in multiple other mainline subsystems.
> > >
> >
> > I guess if this is a general direction thing, but it does seem
> > that module unload is not the only reason one might ever unbind a
> > driver. So are we sure we want to remove the option to unbind
> > these drivers? Certainly for testing it is sometimes useful.
> 
> I personally never understood why these attributes are even
> present on non-modular drivers.
> 
> If testing is about exercising unbind/bind to reintialize
> the code through a new call to .probe(), why would the developer
> not take it all the way through and make it a module?
> It just looks like a half-measure.
> 

Well I guess in someways it is a half-measure. I vaguely seem to
remember some dependency nightmare that can make it really hard
to have the MFD allowed as a module in some cases, I can't
remember the exact details but probably why some of these are not
modules.

I certainly don't strongly object to removing the ability to
unbind these drivers, just wanted to make sure everyone is
aligned that it's a good thing to do. Does kinda remove a couple
of debugging options (debugging things like drivers interfering
with each other) and the last chance restart the driver and see
if that helps rescue something.

Thanks,
Charles

  reply	other threads:[~2018-12-05 13:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-03  4:23 [PATCH v2 00/22] mfd: demodularization of non-modular drivers Paul Gortmaker
2018-12-03  4:23 ` [PATCH 15/22] mfd: tps65910: Make it explicitly non-modular Paul Gortmaker
2018-12-05 11:35 ` [PATCH v2 00/22] mfd: demodularization of non-modular drivers Charles Keepax
2018-12-05 11:48   ` Linus Walleij
2018-12-05 13:40     ` Charles Keepax [this message]
2018-12-05 11:50 ` Linus Walleij
2018-12-05 12:01 ` Steve Twiss
2018-12-05 12:12   ` Steve Twiss
2018-12-05 18:08   ` Paul Gortmaker

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=20181205134016.GE16508@imbe.wolfsonmicro.main \
    --to=ckeepax@opensource.cirrus.com \
    --cc=arnd@arndb.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=darkstar6262@gmail.com \
    --cc=dchen@diasemi.com \
    --cc=dong.aisheng@linaro.org \
    --cc=eric.miao@marvell.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=gg@slimlogic.co.uk \
    --cc=haojian.zhuang@marvell.com \
    --cc=jedu@slimlogic.co.uk \
    --cc=jinyoungp@nvidia.com \
    --cc=ldewangan@nvidia.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mattias.i.nilsson@stericsson.com \
    --cc=michael.hennerich@analog.com \
    --cc=mike@compulab.co.il \
    --cc=paul.gortmaker@windriver.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 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.