Hi Samuel,
Today's linux-next merge of the mfd tree got a conflict in
drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
mfd tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
diff --cc drivers/mfd/Kconfig
index b6bb6d5,2f3ce18..0000000
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@@ -977,68 -920,38 +920,51 @@@ config MFD_WL1273_COR
driver connects the radio-wl1273 V4L2 module and the wl1273
audio codec.
+config MFD_SI476X_CORE
+ tristate "Support for Silicon Laboratories 4761/64/68 AM/FM radio."
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ This is the core driver for the SI476x series of AM/FM
+ radio. This MFD driver connects the radio-si476x V4L2 module
+ and the si476x audio codec.
+
+ To compile this driver as a module, choose M here: the
+ module will be called si476x-core.
+
- config MFD_OMAP_USB_HOST
- bool "Support OMAP USBHS core and TLL driver"
- depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
- default y
- help
- This is the core driver for the OAMP EHCI and OHCI drivers.
- This MFD driver does the required setup functionalities for
- OMAP USB Host drivers.
-
- config MFD_PM8XXX
- tristate
-
- config MFD_PM8921_CORE
- tristate "Qualcomm PM8921 PMIC chip"
- depends on MSM_SSBI
+ config MFD_LM3533
+ tristate "TI/National Semiconductor LM3533 Lighting Power chip"
+ depends on I2C
select MFD_CORE
- select MFD_PM8XXX
+ select REGMAP_I2C
+ depends on GENERIC_HARDIRQS
help
- If you say yes to this option, support will be included for the
- built-in PM8921 PMIC chip.
-
- This is required if your board has a PM8921 and uses its features,
- such as: MPPs, GPIOs, regulators, interrupts, and PWM.
-
- Say M here if you want to include support for PM8921 chip as a module.
- This will build a module called "pm8921-core".
+ Say yes here to enable support for National Semiconductor / TI
+ LM3533 Lighting Power chips.
- config MFD_PM8XXX_IRQ
- bool "Support for Qualcomm PM8xxx IRQ features"
- depends on MFD_PM8XXX
- default y if MFD_PM8XXX
- help
- This is the IRQ driver for Qualcomm PM 8xxx PMIC chips.
+ This driver provides common support for accessing the device;
+ additional drivers must be enabled in order to use the LED,
+ backlight or ambient-light-sensor functionality of the device.
- This is required to use certain other PM 8xxx features, such as GPIO
- and MPP.
+ config MFD_TIMBERDALE
+ tristate "Timberdale FPGA"
+ select MFD_CORE
+ depends on PCI && GPIOLIB
+ ---help---
+ This is the core driver for the timberdale FPGA. This device is a
+ multifunction device which exposes numerous platform devices.
- config TPS65911_COMPARATOR
- tristate
+ The timberdale FPGA can be found on the Intel Atom development board
+ for in-vehicle infontainment, called Russellville.
- config MFD_TPS65090
- bool "TPS65090 Power Management chips"
+ config MFD_TC3589X
+ bool "Toshiba TC35892 and variants"
depends on I2C=y && GENERIC_HARDIRQS
select MFD_CORE
- select REGMAP_I2C
- select REGMAP_IRQ
help
- If you say yes here you get support for the TPS65090 series of
- Power Management chips.
+ Support for the Toshiba TC35892 and variants I/O Expander.
+
This driver provides common support for accessing the device,
additional drivers must be enabled in order to use the
functionality of the device.
--
Cheers,
Stephen Rothwell [email protected]
Hi Stephen,
On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:
> Hi Samuel,
>
> Today's linux-next merge of the mfd tree got a conflict in
> drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
> files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
> commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
> mfd tree.
I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
ACKed it. I was planning to take the MFD bits of it and provide Mauro a branch
to pull from (Including the mfd/Kconfig change).
Mauro, could we please go that way instead ? This conflict does not look
pretty to me.
Cheers,
Samuel.
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
>
> diff --cc drivers/mfd/Kconfig
> index b6bb6d5,2f3ce18..0000000
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@@ -977,68 -920,38 +920,51 @@@ config MFD_WL1273_COR
> driver connects the radio-wl1273 V4L2 module and the wl1273
> audio codec.
>
> +config MFD_SI476X_CORE
> + tristate "Support for Silicon Laboratories 4761/64/68 AM/FM radio."
> + depends on I2C
> + select MFD_CORE
> + select REGMAP_I2C
> + help
> + This is the core driver for the SI476x series of AM/FM
> + radio. This MFD driver connects the radio-si476x V4L2 module
> + and the si476x audio codec.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called si476x-core.
> +
> - config MFD_OMAP_USB_HOST
> - bool "Support OMAP USBHS core and TLL driver"
> - depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
> - default y
> - help
> - This is the core driver for the OAMP EHCI and OHCI drivers.
> - This MFD driver does the required setup functionalities for
> - OMAP USB Host drivers.
> -
> - config MFD_PM8XXX
> - tristate
> -
> - config MFD_PM8921_CORE
> - tristate "Qualcomm PM8921 PMIC chip"
> - depends on MSM_SSBI
> + config MFD_LM3533
> + tristate "TI/National Semiconductor LM3533 Lighting Power chip"
> + depends on I2C
> select MFD_CORE
> - select MFD_PM8XXX
> + select REGMAP_I2C
> + depends on GENERIC_HARDIRQS
> help
> - If you say yes to this option, support will be included for the
> - built-in PM8921 PMIC chip.
> -
> - This is required if your board has a PM8921 and uses its features,
> - such as: MPPs, GPIOs, regulators, interrupts, and PWM.
> -
> - Say M here if you want to include support for PM8921 chip as a module.
> - This will build a module called "pm8921-core".
> + Say yes here to enable support for National Semiconductor / TI
> + LM3533 Lighting Power chips.
>
> - config MFD_PM8XXX_IRQ
> - bool "Support for Qualcomm PM8xxx IRQ features"
> - depends on MFD_PM8XXX
> - default y if MFD_PM8XXX
> - help
> - This is the IRQ driver for Qualcomm PM 8xxx PMIC chips.
> + This driver provides common support for accessing the device;
> + additional drivers must be enabled in order to use the LED,
> + backlight or ambient-light-sensor functionality of the device.
>
> - This is required to use certain other PM 8xxx features, such as GPIO
> - and MPP.
> + config MFD_TIMBERDALE
> + tristate "Timberdale FPGA"
> + select MFD_CORE
> + depends on PCI && GPIOLIB
> + ---help---
> + This is the core driver for the timberdale FPGA. This device is a
> + multifunction device which exposes numerous platform devices.
>
> - config TPS65911_COMPARATOR
> - tristate
> + The timberdale FPGA can be found on the Intel Atom development board
> + for in-vehicle infontainment, called Russellville.
>
> - config MFD_TPS65090
> - bool "TPS65090 Power Management chips"
> + config MFD_TC3589X
> + bool "Toshiba TC35892 and variants"
> depends on I2C=y && GENERIC_HARDIRQS
> select MFD_CORE
> - select REGMAP_I2C
> - select REGMAP_IRQ
> help
> - If you say yes here you get support for the TPS65090 series of
> - Power Management chips.
> + Support for the Toshiba TC35892 and variants I/O Expander.
> +
> This driver provides common support for accessing the device,
> additional drivers must be enabled in order to use the
> functionality of the device.
>
> --
> Cheers,
> Stephen Rothwell [email protected]
--
Intel Open Source Technology Centre
http://oss.intel.com/
Em Wed, 10 Apr 2013 08:42:53 +0200
Samuel Ortiz <[email protected]> escreveu:
> Hi Stephen,
>
> On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:
> > Hi Samuel,
> >
> > Today's linux-next merge of the mfd tree got a conflict in
> > drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
> > files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
> > commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
> > mfd tree.
> I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
> ACKed it.
Sorry. Not sure why I understood that you gave your ack. Perhaps I miss-read
one of the comments of that thread.
> I was planning to take the MFD bits of it and provide Mauro a branch
> to pull from (Including the mfd/Kconfig change).
> Mauro, could we please go that way instead ? This conflict does not look
> pretty to me.
Sure. Do you have such branch already? As the patches are on my main
tree[1], I'll need to either revert them or to do a merge from your
branch. The latter is likely a little cleaner, but I'm ok with either ways.
Regards,
Mauro
[1] Currently, we're not using topic branches yet. I'm planning to do it
for 3.11. So, once a patch got merged, I can't remove it, as I don't
rebase my tree.
Regards,
Mauro
Hi Mauro,
On Wed, Apr 10, 2013 at 06:48:28AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 10 Apr 2013 08:42:53 +0200
> Samuel Ortiz <[email protected]> escreveu:
>
> > Hi Stephen,
> >
> > On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:
> > > Hi Samuel,
> > >
> > > Today's linux-next merge of the mfd tree got a conflict in
> > > drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
> > > files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
> > > commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
> > > mfd tree.
> > I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
> > ACKed it.
>
> Sorry. Not sure why I understood that you gave your ack. Perhaps I miss-read
> one of the comments of that thread.
No worries, really. This has been a long thread...
> > I was planning to take the MFD bits of it and provide Mauro a branch
> > to pull from (Including the mfd/Kconfig change).
> > Mauro, could we please go that way instead ? This conflict does not look
> > pretty to me.
>
> Sure. Do you have such branch already? As the patches are on my main
> tree[1],
I don't have it yet. I asked Andrei to add a header to one of the MFD patches
because his patchset is currently not bisectable (The MFD patches include a
media/ header that is created later in the patchset). Once he has that done,
I'll create a branch for you to merge. I'll let you know when that's ready.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
Hi Mauro,
On Wed, Apr 10, 2013 at 06:48:28AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 10 Apr 2013 08:42:53 +0200
> Samuel Ortiz <[email protected]> escreveu:
>
> > Hi Stephen,
> >
> > On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:
> > > Hi Samuel,
> > >
> > > Today's linux-next merge of the mfd tree got a conflict in
> > > drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
> > > files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
> > > commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
> > > mfd tree.
> > I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
> > ACKed it.
>
> Sorry. Not sure why I understood that you gave your ack. Perhaps I miss-read
> one of the comments of that thread.
I haven't heard back from Andrey yet. If I don't get anything from him on
Wednesday, would you mind reverting this patchset ? I have not ACKed it
because it breaks bisectability, and it conflicts with mfd-next.
Andrey, any plans to adress my comments from last week ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
Em 16-04-2013 10:51, Samuel Ortiz escreveu:
> Hi Mauro,
>
> On Wed, Apr 10, 2013 at 06:48:28AM -0300, Mauro Carvalho Chehab wrote:
>> Em Wed, 10 Apr 2013 08:42:53 +0200
>> Samuel Ortiz <[email protected]> escreveu:
>>
>>> Hi Stephen,
>>>
>>> On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:
>>>> Hi Samuel,
>>>>
>>>> Today's linux-next merge of the mfd tree got a conflict in
>>>> drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
>>>> files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
>>>> commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
>>>> mfd tree.
>>> I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
>>> ACKed it.
>>
>> Sorry. Not sure why I understood that you gave your ack. Perhaps I miss-read
>> one of the comments of that thread.
> I haven't heard back from Andrey yet. If I don't get anything from him on
> Wednesday, would you mind reverting this patchset ? I have not ACKed it
> because it breaks bisectability, and it conflicts with mfd-next.
Sure. Just ping me and I'll revert it.
>
> Andrey, any plans to adress my comments from last week ?
>
> Cheers,
> Samuel.
>
Regards,
Mauro
On Tue, Apr 16, 2013 at 6:51 AM, Samuel Ortiz <[email protected]> wrote:
> Hi Mauro,
>
> On Wed, Apr 10, 2013 at 06:48:28AM -0300, Mauro Carvalho Chehab wrote:
>> Em Wed, 10 Apr 2013 08:42:53 +0200
>> Samuel Ortiz <[email protected]> escreveu:
>>
>> > Hi Stephen,
>> >
>> > On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:
>> > > Hi Samuel,
>> > >
>> > > Today's linux-next merge of the mfd tree got a conflict in
>> > > drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
>> > > files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
>> > > commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
>> > > mfd tree.
>> > I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
>> > ACKed it.
>>
>> Sorry. Not sure why I understood that you gave your ack. Perhaps I miss-read
>> one of the comments of that thread.
> I haven't heard back from Andrey yet. If I don't get anything from him on
> Wednesday, would you mind reverting this patchset ? I have not ACKed it
> because it breaks bisectability, and it conflicts with mfd-next.
>
> Andrey, any plans to adress my comments from last week ?
I have a new version of a patchset that addresses your comments and
incorporates a couple of other patches with bugfixes. Unfortunately I
haven't had a chance to run it on the test HW I have. I'll try to do
and post the patches this week, but I am not sure if I'll have time to
do it before Wednesday.
As far as I understand all the MFD patches will go through the "mfd"
tree which doesn't have any version of the SI476X related patches and
I don't have to worry about making incremental patches. This, however,
is not the case for "media_tree" this patch here
http://git.linuxtv.org/media_tree.git/commit/30bac9110455402fa8888740c6819dd3daa2666f
would be affected and I think that making the need changes
incrementally as a separate patch would break the bisectability also.
Right now what I have is a new version of said patch produced by
editing the history(rebase and squash). Would that work for you,
Mauro, or do you want an incremental patch on top of the original one?
>
> Cheers,
> Samuel.
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
On Tue, Apr 16, 2013 at 09:25:45AM -0700, Andrey Smirnov wrote:
> On Tue, Apr 16, 2013 at 6:51 AM, Samuel Ortiz <[email protected]> wrote:
> > Hi Mauro,
> >
> > On Wed, Apr 10, 2013 at 06:48:28AM -0300, Mauro Carvalho Chehab wrote:
> >> Em Wed, 10 Apr 2013 08:42:53 +0200
> >> Samuel Ortiz <[email protected]> escreveu:
> >>
> >> > Hi Stephen,
> >> >
> >> > On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:
> >> > > Hi Samuel,
> >> > >
> >> > > Today's linux-next merge of the mfd tree got a conflict in
> >> > > drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
> >> > > files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
> >> > > commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
> >> > > mfd tree.
> >> > I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
> >> > ACKed it.
> >>
> >> Sorry. Not sure why I understood that you gave your ack. Perhaps I miss-read
> >> one of the comments of that thread.
> > I haven't heard back from Andrey yet. If I don't get anything from him on
> > Wednesday, would you mind reverting this patchset ? I have not ACKed it
> > because it breaks bisectability, and it conflicts with mfd-next.
> >
> > Andrey, any plans to adress my comments from last week ?
>
> I have a new version of a patchset that addresses your comments and
> incorporates a couple of other patches with bugfixes. Unfortunately I
> haven't had a chance to run it on the test HW I have. I'll try to do
> and post the patches this week, but I am not sure if I'll have time to
> do it before Wednesday.
Linus will most likely tag 3.9 on Sunday or so, I won't take any patches after
that (And probably no patches after Friday...)
> As far as I understand all the MFD patches will go through the "mfd"
> tree which doesn't have any version of the SI476X related patches and
> I don't have to worry about making incremental patches. This, however,
> is not the case for "media_tree" this patch here
> http://git.linuxtv.org/media_tree.git/commit/30bac9110455402fa8888740c6819dd3daa2666f
> would be affected and I think that making the need changes
> incrementally as a separate patch would break the bisectability also.
> Right now what I have is a new version of said patch produced by
> editing the history(rebase and squash). Would that work for you,
> Mauro, or do you want an incremental patch on top of the original one?
If you manage to send the patches on time, here is what I propose: I create a
stable branch with all your mfd patches and merge it on my master branch.
Mauro can then also merge it and then apply the rest of your patchset (which
is all v4l and media related, iirc). Before doing so, Mauro would have to
revert the last patchset from you, that's currently sitting in his tree.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
Em Tue, 16 Apr 2013 21:23:59 +0200
Samuel Ortiz <[email protected]> escreveu:
> On Tue, Apr 16, 2013 at 09:25:45AM -0700, Andrey Smirnov wrote:
> > On Tue, Apr 16, 2013 at 6:51 AM, Samuel Ortiz <[email protected]> wrote:
> > > Hi Mauro,
> > >
> > > On Wed, Apr 10, 2013 at 06:48:28AM -0300, Mauro Carvalho Chehab wrote:
> > >> Em Wed, 10 Apr 2013 08:42:53 +0200
> > >> Samuel Ortiz <[email protected]> escreveu:
> > >>
> > >> > Hi Stephen,
> > >> >
> > >> > On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:
> > >> > > Hi Samuel,
> > >> > >
> > >> > > Today's linux-next merge of the mfd tree got a conflict in
> > >> > > drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
> > >> > > files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
> > >> > > commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
> > >> > > mfd tree.
> > >> > I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
> > >> > ACKed it.
> > >>
> > >> Sorry. Not sure why I understood that you gave your ack. Perhaps I miss-read
> > >> one of the comments of that thread.
> > > I haven't heard back from Andrey yet. If I don't get anything from him on
> > > Wednesday, would you mind reverting this patchset ? I have not ACKed it
> > > because it breaks bisectability, and it conflicts with mfd-next.
> > >
> > > Andrey, any plans to adress my comments from last week ?
> >
> > I have a new version of a patchset that addresses your comments and
> > incorporates a couple of other patches with bugfixes. Unfortunately I
> > haven't had a chance to run it on the test HW I have. I'll try to do
> > and post the patches this week, but I am not sure if I'll have time to
> > do it before Wednesday.
> Linus will most likely tag 3.9 on Sunday or so, I won't take any patches after
> that (And probably no patches after Friday...)
>
>
> > As far as I understand all the MFD patches will go through the "mfd"
> > tree which doesn't have any version of the SI476X related patches and
> > I don't have to worry about making incremental patches. This, however,
> > is not the case for "media_tree" this patch here
> > http://git.linuxtv.org/media_tree.git/commit/30bac9110455402fa8888740c6819dd3daa2666f
> > would be affected and I think that making the need changes
> > incrementally as a separate patch would break the bisectability also.
> > Right now what I have is a new version of said patch produced by
> > editing the history(rebase and squash). Would that work for you,
> > Mauro, or do you want an incremental patch on top of the original one?
> If you manage to send the patches on time, here is what I propose: I create a
> stable branch with all your mfd patches and merge it on my master branch.
> Mauro can then also merge it and then apply the rest of your patchset (which
> is all v4l and media related, iirc). Before doing so, Mauro would have to
> revert the last patchset from you, that's currently sitting in his tree.
Ok, reverted both changesets 3f8ec5df11aa and 30bac9110455402f:
http://git.linuxtv.org/media_tree.git/commit/82cd0b278fddc1c0bc7e187ff82fd0e273520233
http://git.linuxtv.org/media_tree.git/commit/33a31edd4a4b7d26b962b32decfd8ea2377eaa0d
By reverting first 30bac9110455402f, I avoided breaking git bisect.
Regards,
Mauro