Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 27 Nov 2018 13:07:11 +0000
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
Message-ID: <20181127130711.GL4272@dell>
References: <1542861179-8941-3-git-send-email-paul.gortmaker@windriver.com>
 <201811231036.wIjm7GBh%fengguang.wu@intel.com>
 <20181123031456.GD14659@windriver.com>
 <20181123144328.GE14659@windriver.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20181123144328.GE14659@windriver.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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