Messages in this thread | | | Date | Wed, 28 Nov 2018 09:35:24 +0000 | From | Lee Jones <> | Subject | Re: [PATCH 02/11] mfd: da9055-core: make it explicitly non-modular |
| |
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
| |