From: Lee Jones <lee.jones@linaro.org>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: kbuild test robot <lkp@intel.com>,
kbuild-all@01.org, linux-kernel@vger.kernel.org,
David Dajun Chen <dchen@diasemi.com>,
Support Opensource <support.opensource@diasemi.com>
Subject: Re: [PATCH 02/11] mfd: da9055-core: make it explicitly non-modular
Date: Tue, 27 Nov 2018 13:07:11 +0000 [thread overview]
Message-ID: <20181127130711.GL4272@dell> (raw)
In-Reply-To: <20181123144328.GE14659@windriver.com>
On Fri, 23 Nov 2018, Paul Gortmaker wrote:
> [Re: [PATCH 02/11] mfd: da9055-core: make it explicitly non-modular] On 22/11/2018 (Thu 22:14) Paul Gortmaker wrote:
>
> > [Re: [PATCH 02/11] mfd: da9055-core: make it explicitly non-modular] On 23/11/2018 (Fri 10:21) kbuild test robot wrote:
> >
>
> [...]
>
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > > drivers/mfd/da9055-i2c.o: In function `da9055_i2c_remove':
> > > >> drivers/mfd/da9055-i2c.c:53: undefined reference to `da9055_device_exit'
> >
> > Thanks for the report -- I'll look into what causes it, why my testing
> > didn't see it, and get an update to Lee as soon as possible.
>
> OK, mystery solved. I chose this smaller subset of MFD "simple" patches
> from my pending queue of MFD patches - to create a reasonable sized
> maintainer-friendly send, based on patches with zero runtime changes.
>
> My other pending MFD patches have a trivial runtime behavior change;
> deleting a ".remove" field/function - that will never be used for a
> non-module case, but in theory could be (pointlessly) triggered by
> forcing a driver unbind. (see mainline 98b72b94def9 as an example)
> Patches like this were left behind for a future send batch.
What about when .remove() is invoked during shutdown?
> Unfortunately that allowed me to overlook the fact that patch #2 link
> depended on the below ".remove" patch (not sent) to be applied 1st.
>
> Lee, what would you like to have happen? I can resend the queue with
> this patch, or I can resend with #2 being temporarily deferred until
> a future patch batch that has the below da9055-i2c in it, or ...
>
> Whatever is easiest for you - let me know.
>
> Paul.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2018-11-27 13:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-22 4:32 [PATCH 00/11] mfd: simple demodularization of non-modular drivers Paul Gortmaker
2018-11-22 4:32 ` [PATCH 01/11] mfd: as3711: Make it explicitly non-modular Paul Gortmaker
2018-11-22 4:32 ` [PATCH 02/11] mfd: da9055-core: make " Paul Gortmaker
[not found] ` <201811231036.wIjm7GBh%fengguang.wu@intel.com>
2018-11-23 3:14 ` Paul Gortmaker
2018-11-23 14:43 ` Paul Gortmaker
2018-11-27 13:07 ` Lee Jones [this message]
2018-11-27 15:03 ` Paul Gortmaker
2018-11-28 9:35 ` Lee Jones
2018-11-22 4:32 ` [PATCH 03/11] mfd: db8500-prcmu: drop unused MODULE_ tags from non-modular code Paul Gortmaker
2018-11-30 22:19 ` Linus Walleij
2018-11-22 4:32 ` [PATCH 04/11] mfd: htc-i2cpld: Make it explicitly non-modular Paul Gortmaker
2018-11-22 4:32 ` [PATCH 05/11] mfd: max8925-core: drop unused MODULE_ tags from non-modular code Paul Gortmaker
2018-11-22 4:32 ` [PATCH 06/11] mfd: rc5t583: Make it explicitly non-modular Paul Gortmaker
2018-11-22 4:32 ` [PATCH 07/11] mfd: sta2x11: drop unused MODULE_ tags from non-modular code Paul Gortmaker
2018-11-22 4:32 ` [PATCH 08/11] mfd: syscon: Make it explicitly non-modular Paul Gortmaker
2018-11-22 4:32 ` [PATCH 09/11] mfd: tps65910: " Paul Gortmaker
2018-11-22 8:56 ` Graeme Gregory
2018-11-22 4:32 ` [PATCH 10/11] mfd: wm831x-core: drop unused MODULE_ tags from non-modular code Paul Gortmaker
2018-11-22 9:28 ` Charles Keepax
2018-11-22 4:32 ` [PATCH 11/11] mfd: wm8400-core: Make it explicitly non-modular Paul Gortmaker
2018-11-22 9:29 ` Charles Keepax
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=20181127130711.GL4272@dell \
--to=lee.jones@linaro.org \
--cc=dchen@diasemi.com \
--cc=kbuild-all@01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=paul.gortmaker@windriver.com \
--cc=support.opensource@diasemi.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