Re: [PATCH v10 0/9] support ROHM BD70528 PMIC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 25 Mar 2019, Matti Vaittinen wrote:

> Hello again Lee & all,
> 
> On Thu, Feb 28, 2019 at 10:22:48AM +0200, Matti Vaittinen wrote:
> > On Thu, Feb 28, 2019 at 08:10:55AM +0000, Lee Jones wrote:
> > > On Thu, 28 Feb 2019, Matti Vaittinen wrote:
> > > 
> > > > Hello Lee and Mark,
> > > > 
> > > > On Thu, Feb 14, 2019 at 03:02:37PM +0200, Matti Vaittinen wrote:
> > > > > Patch series introducing support for ROHM BD70528 PMIC
> 
> //snip
> 
> > > > 
> > > > The MFD part depends on the regmap-irq changes and I think that most
> > > > other subsystems want to have the MFD changes in before taking rest of
> > > > the driver in their trees. So it will be a while untill all the changes
> > > > are in. It would really be nice to have the drive in-tree sooner - hence
> > > > I ask if theres a way. (I don't want to push, just ask if it is possible :])
> > > 
> > > It's possible, so long as there aren't any build-time dependencies
> > > between the subsystems.  Immediate acceptance however isn't possible
> > > due to the impending merge-window which opens in 3 days.
> > 
> > Thanks for reply Lee. So merge-window is opening - meaning the 5.1 is
> > being baked now(?) 
> > 
> > Anyays to make it clear - there is build time dependency between MFD and
> > regmap-irq changes. MFD part won't compile without the changes in regmap
> > tree. And theres no new Kconfig to depend on or other compile time
> > checks. So REGMAP changes are required for this MFD portion to compile.
> 
> //snip
> 
> > Rest of the subsystems (regulator, clk, watchdog, gpio) do all depend on
> > MFD - but they should have 'depends on' KConfig to MFD meaning they
> > won't be built without MFD.
> 
> I see the 5.1-rc1 and 5.1-rc2 are out. Those contain the regmap-irq
> changes the BD70528 MFD driver depends on. Would you like me to rebase
> the series to some other tree (which tree/branch? I don't see updated
> for-mfd-next branch in kernel.org yet) and resend it? Original patch
> series was created on top of the regulator tree.

If you could rebase and resend, that would be great.

You should (very nearly) always base on an upstream tag, so v5.1-rc2
would be best in this case.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux