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: Wed, 28 Nov 2018 09:35:24 +0000 [thread overview]
Message-ID: <20181128093524.GD4272@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.
>
> 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.
Just send them all.
I'm going to have to review them all at one time or another.
--
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-28 9:35 UTC|newest]
Thread overview: 23+ 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 ` 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
2018-11-27 15:03 ` Paul Gortmaker
2018-11-28 9:35 ` Lee Jones [this message]
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 4:32 ` 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=20181128093524.GD4272@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 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.