Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/am335x-bone.dts between commit 97238b35d5bb ("usb:
musb: dsps: use proper child nodes") from the tree and commit
63f6b2550aa0 ("ARM: dts: AM33XX: don't redefine OCP bus and device
nodes") from the arm-soc tree.
I fixed it up (probably incorrectly - see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwell [email protected]
diff --cc arch/arm/boot/dts/am335x-bone.dts
index a8907b5,d99be03..0000000
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@@ -24,132 -24,6 +24,24 @@@
reg = <0x80000000 0x10000000>; /* 256 MB */
};
- am33xx_pinmux: pinmux@44e10800 {
- pinctrl-names = "default";
- pinctrl-0 = <&clkout2_pin>;
-
- user_leds_s0: user_leds_s0 {
- pinctrl-single,pins = <
- 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a5.gpio1_21 */
- 0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_a6.gpio1_22 */
- 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a7.gpio1_23 */
- 0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_a8.gpio1_24 */
- >;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins = <
- 0x188 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c0_sda.i2c0_sda */
- 0x18c (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c0_scl.i2c0_scl */
- >;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- 0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /* uart0_rxd.uart0_rxd */
- 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */
- >;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins = <
- 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* xdma_event_intr1.clkout2 */
- >;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins = <
- /* Slave 1 */
- 0x110 (PIN_INPUT_PULLUP | MUX_MODE0) /* mii1_rxerr.mii1_rxerr */
- 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txen.mii1_txen */
- 0x118 (PIN_INPUT_PULLUP | MUX_MODE0) /* mii1_rxdv.mii1_rxdv */
- 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd3.mii1_txd3 */
- 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd2.mii1_txd2 */
- 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd1.mii1_txd1 */
- 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd0.mii1_txd0 */
- 0x12c (PIN_INPUT_PULLUP | MUX_MODE0) /* mii1_txclk.mii1_txclk */
- 0x130 (PIN_INPUT_PULLUP | MUX_MODE0) /* mii1_rxclk.mii1_rxclk */
- 0x134 (PIN_INPUT_PULLUP | MUX_MODE0) /* mii1_rxd3.mii1_rxd3 */
- 0x138 (PIN_INPUT_PULLUP | MUX_MODE0) /* mii1_rxd2.mii1_rxd2 */
- 0x13c (PIN_INPUT_PULLUP | MUX_MODE0) /* mii1_rxd1.mii1_rxd1 */
- 0x140 (PIN_INPUT_PULLUP | MUX_MODE0) /* mii1_rxd0.mii1_rxd0 */
- >;
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins = <
- /* Slave 1 reset value */
- 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- >;
- };
-
- davinci_mdio_default: davinci_mdio_default {
- pinctrl-single,pins = <
- /* MDIO */
- 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0) /* mdio_data.mdio_data */
- 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_clk.mdio_clk */
- >;
- };
-
- davinci_mdio_sleep: davinci_mdio_sleep {
- pinctrl-single,pins = <
- /* MDIO reset value */
- 0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
- >;
- };
- };
-
+ ocp {
- uart0: serial@44e09000 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-
- status = "okay";
- };
-
+ musb: usb@47400000 {
+ status = "okay";
+
+ control@44e10000 {
+ status = "okay";
+ };
+
+ phy@47401300 {
+ status = "okay";
+ };
+
+ usb@47401000 {
+ status = "okay";
+ };
+ };
-
- i2c0: i2c@44e0b000 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
-
- status = "okay";
- clock-frequency = <400000>;
-
- tps: tps@24 {
- reg = <0x24>;
- };
-
- };
+ };
+
leds {
pinctrl-names = "default";
pinctrl-0 = <&user_leds_s0>;
On 08/27/2013 10:13 AM, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/boot/dts/am335x-bone.dts between commit 97238b35d5bb
> ("usb: musb: dsps: use proper child nodes") from the tree and
> commit 63f6b2550aa0 ("ARM: dts: AM33XX: don't redefine OCP bus and
> device nodes") from the arm-soc tree.
>
> I fixed it up (probably incorrectly - see below) and can carry the
> fix as necessary (no action is required).
You added the OCP node back and the USB nodes as I had them which
should be fine.
How do we solve the conflict for the merge window? Is it possible for
the ARM-SOC tree to create a topic branch for this commit?
Greg: I do have a pending pull / patches [0] which also change the dts
nodes according to the latest feedback + enabling an additional USB
port in bone.
If you take this in I could update the nodes later (with the topic
branch merged) accordingly to the way it has been done in the ARM-SOC
tree - unless you have other preferences.
[0] http://www.spinics.net/lists/linux-usb/msg92595.html
Sebastian
[cc'ing Benoit Cousson (OMAP DT maintainer)]
On Tue, Aug 27, 2013 at 10:54 AM, Sebastian Andrzej Siewior
<[email protected]> wrote:
> On 08/27/2013 10:13 AM, Stephen Rothwell wrote:
>
>> Today's linux-next merge of the arm-soc tree got a conflict in
>> arch/arm/boot/dts/am335x-bone.dts between commit 97238b35d5bb
>> ("usb: musb: dsps: use proper child nodes") from the tree and
>> commit 63f6b2550aa0 ("ARM: dts: AM33XX: don't redefine OCP bus and
>> device nodes") from the arm-soc tree.
>>
>> I fixed it up (probably incorrectly - see below) and can carry the
>> fix as necessary (no action is required).
>
> You added the OCP node back and the USB nodes as I had them which
> should be fine.
>
> How do we solve the conflict for the merge window? Is it possible for
> the ARM-SOC tree to create a topic branch for this commit?
>
> Greg: I do have a pending pull / patches [0] which also change the dts
> nodes according to the latest feedback + enabling an additional USB
> port in bone.
> If you take this in I could update the nodes later (with the topic
> branch merged) accordingly to the way it has been done in the ARM-SOC
> tree - unless you have other preferences.
>
I think that the proper way to handle this is to split the patch-set
in two and merge all the OMAP DT related changes
(arch/arm/boot/dts/am*) through Benoit's tree and the USB changes
(drivers/usb/*) through Greg tree to prevent these kind of merge
conflicts.
Thanks a lot and best regards,
Javier
> [0] http://www.spinics.net/lists/linux-usb/msg92595.html
>
> Sebastian
>
Hi Sebatian,
On 27/08/2013 15:02, Javier Martinez Canillas wrote:
> [cc'ing Benoit Cousson (OMAP DT maintainer)]
>
> On Tue, Aug 27, 2013 at 10:54 AM, Sebastian Andrzej Siewior
> <[email protected]> wrote:
>> On 08/27/2013 10:13 AM, Stephen Rothwell wrote:
>>
>>> Today's linux-next merge of the arm-soc tree got a conflict in
>>> arch/arm/boot/dts/am335x-bone.dts between commit 97238b35d5bb
>>> ("usb: musb: dsps: use proper child nodes") from the tree and
>>> commit 63f6b2550aa0 ("ARM: dts: AM33XX: don't redefine OCP bus and
>>> device nodes") from the arm-soc tree.
>>>
>>> I fixed it up (probably incorrectly - see below) and can carry the
>>> fix as necessary (no action is required).
>>
>> You added the OCP node back and the USB nodes as I had them which
>> should be fine.
>>
>> How do we solve the conflict for the merge window? Is it possible for
>> the ARM-SOC tree to create a topic branch for this commit?
>>
>> Greg: I do have a pending pull / patches [0] which also change the dts
>> nodes according to the latest feedback + enabling an additional USB
>> port in bone.
>> If you take this in I could update the nodes later (with the topic
>> branch merged) accordingly to the way it has been done in the ARM-SOC
>> tree - unless you have other preferences.
>>
>
> I think that the proper way to handle this is to split the patch-set
> in two and merge all the OMAP DT related changes
> (arch/arm/boot/dts/am*) through Benoit's tree and the USB changes
> (drivers/usb/*) through Greg tree to prevent these kind of merge
> conflicts.
Yes. DT patches are an endless source of merge conflicts if they are
merge throught different trees.
What was discussed with Olof and Arnd during Connect is that we should
avoid merging DT patches outside arm-soc tree to avoid that kind of
situation.
Regards,
Benoit
On 08/27/2013 03:24 PM, Benoit Cousson wrote:
> Hi Sebatian,
Hi Benoit,
> Yes. DT patches are an endless source of merge conflicts if they are
> merge throught different trees.
Usually there are small conflicts because two people added / changed a
node nearby. This patch turned the .dts file almost upside down.
> What was discussed with Olof and Arnd during Connect is that we should
> avoid merging DT patches outside arm-soc tree to avoid that kind of
> situation.
I am aware of this now. However these changes belonged together because
a) they belonged together and b) would break the driver until the .dts
changes and driver code is in-sync.
In future I am going to ask you for a topic branch so I can get my
changes in one piece without breaking stuff in the middle.
What do we do now?
> Regards,
> Benoit
Sebastian
+ Kevin,
On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
> On 08/27/2013 03:24 PM, Benoit Cousson wrote:
>> Hi Sebatian,
>
> Hi Benoit,
>
>> Yes. DT patches are an endless source of merge conflicts if they are
>> merge throught different trees.
>
> Usually there are small conflicts because two people added / changed a
> node nearby. This patch turned the .dts file almost upside down.
Yes, that's true.
>> What was discussed with Olof and Arnd during Connect is that we should
>> avoid merging DT patches outside arm-soc tree to avoid that kind of
>> situation.
>
> I am aware of this now. However these changes belonged together because
> a) they belonged together and b) would break the driver until the .dts
> changes and driver code is in-sync.
> In future I am going to ask you for a topic branch so I can get my
> changes in one piece without breaking stuff in the middle.
>
> What do we do now?
Cannot you just merge the stable arm-soc/dt branch into your branch
before applying your patches?
Regards
Benoit
On 08/27/2013 03:57 PM, Benoit Cousson wrote:
> + Kevin,
>
> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
>> What do we do now?
>
> Cannot you just merge the stable arm-soc/dt branch into your branch
> before applying your patches?
That is up to Greg. This changes sat in his usb-next tree for a while
now. And before they hit Greg they were in Felipe's tree for a while.
To be exact, last .dts change via USB was:
Author: Sebastian Andrzej Siewior <[email protected]>
AuthorDate: Thu Jun 20 12:13:04 2013 +0200
Commit: Felipe Balbi <[email protected]>
CommitDate: Fri Aug 9 17:40:16 2013 +0300
usb: musb dma: add cppi41 dma driver
> Regards
> Benoit
Sebastian
On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
> On 08/27/2013 03:57 PM, Benoit Cousson wrote:
>> + Kevin,
>>
>> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
>>> What do we do now?
>>
>> Cannot you just merge the stable arm-soc/dt branch into your branch
>> before applying your patches?
>
> That is up to Greg. This changes sat in his usb-next tree for a while
> now. And before they hit Greg they were in Felipe's tree for a while.
>
> To be exact, last .dts change via USB was:
>
> Author: Sebastian Andrzej Siewior <[email protected]>
> AuthorDate: Thu Jun 20 12:13:04 2013 +0200
> Commit: Felipe Balbi <[email protected]>
> CommitDate: Fri Aug 9 17:40:16 2013 +0300
>
> usb: musb dma: add cppi41 dma driver
Mmm, if that branch is supposed to be stable, I'm not sure it will be
doable...
Maybe we should do the other way around? And merge usb-next into arm-soc/dt.
Kevin, Olof?
Regards,
Benoit
On 08/27/2013 04:05 PM, Benoit Cousson wrote:
> On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
>> On 08/27/2013 03:57 PM, Benoit Cousson wrote:
>>> + Kevin,
>>>
>>> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
>>>> What do we do now?
>>>
>>> Cannot you just merge the stable arm-soc/dt branch into your branch
>>> before applying your patches?
>>
>> That is up to Greg. This changes sat in his usb-next tree for a while
>> now. And before they hit Greg they were in Felipe's tree for a while.
>>
>> To be exact, last .dts change via USB was:
>>
>> Author: Sebastian Andrzej Siewior <[email protected]>
>> AuthorDate: Thu Jun 20 12:13:04 2013 +0200
>> Commit: Felipe Balbi <[email protected]>
>> CommitDate: Fri Aug 9 17:40:16 2013 +0300
>>
>> usb: musb dma: add cppi41 dma driver
>
> Mmm, if that branch is supposed to be stable, I'm not sure it will be
> doable...
>
> Maybe we should do the other way around? And merge usb-next into
> arm-soc/dt.
>
> Kevin, Olof?
Please be aware that I have no response so far regarding [0] from Greg.
[0] http://www.spinics.net/lists/linux-usb/msg92595.html
> Regards,
> Benoit
Sebastian
Benoit Cousson <[email protected]> writes:
> + Kevin,
>
> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
>> On 08/27/2013 03:24 PM, Benoit Cousson wrote:
>>> Hi Sebatian,
>>
>> Hi Benoit,
>>
>>> Yes. DT patches are an endless source of merge conflicts if they are
>>> merge throught different trees.
>>
>> Usually there are small conflicts because two people added / changed a
>> node nearby. This patch turned the .dts file almost upside down.
>
> Yes, that's true.
>
>>> What was discussed with Olof and Arnd during Connect is that we should
>>> avoid merging DT patches outside arm-soc tree to avoid that kind of
>>> situation.
>>
>> I am aware of this now. However these changes belonged together because
>> a) they belonged together and b) would break the driver until the .dts
>> changes and driver code is in-sync.
>> In future I am going to ask you for a topic branch so I can get my
>> changes in one piece without breaking stuff in the middle.
>>
>> What do we do now?
>
> Cannot you just merge the stable arm-soc/dt branch into your branch
> before applying your patches?
Unfortunately, the next/dt branch of arm-soc is not necessarily stable
so should *not* be merged. In fact none of the arm-soc branches should
be considered stable.
As was already mentioned, this should be split up into driver changes
and DTS changes through arm-soc. They'll both merge for v3.12.
BTW, how did this patch get merged without a signoff/ack from the OMAP
DT maintainer in the first place? Hmm, looks like Benoit was not copied
nor was linux-omap or linux-arm-kernel copied in the original mails.
Kevin
On 08/27/2013 05:01 PM, Kevin Hilman wrote:
>>> What do we do now?
>>
>> Cannot you just merge the stable arm-soc/dt branch into your branch
>> before applying your patches?
>
> Unfortunately, the next/dt branch of arm-soc is not necessarily stable
> so should *not* be merged. In fact none of the arm-soc branches should
> be considered stable.
>
> As was already mentioned, this should be split up into driver changes
> and DTS changes through arm-soc. They'll both merge for v3.12.
But splitting will break the driver until .dts & code is in sync again.
> BTW, how did this patch get merged without a signoff/ack from the OMAP
> DT maintainer in the first place? Hmm, looks like Benoit was not copied
> nor was linux-omap or linux-arm-kernel copied in the original mails.
Hmm. I had Benoit's okay [0] to do the change "as long as Felipe is
fine with it". I indeed forgot to Cc Benoit on the dts changes.
For the phy-rename Felipe pinged you and we did the topic-branch, here
I forgot.
>
> Kevin
[0] http://www.spinics.net/lists/linux-usb/msg88423.html
Sebastian
On Tue, Aug 27, 2013 at 05:25:23PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/27/2013 05:01 PM, Kevin Hilman wrote:
> >>> What do we do now?
> >>
> >> Cannot you just merge the stable arm-soc/dt branch into your branch
> >> before applying your patches?
> >
> > Unfortunately, the next/dt branch of arm-soc is not necessarily stable
> > so should *not* be merged. In fact none of the arm-soc branches should
> > be considered stable.
> >
> > As was already mentioned, this should be split up into driver changes
> > and DTS changes through arm-soc. They'll both merge for v3.12.
>
> But splitting will break the driver until .dts & code is in sync again.
>
> > BTW, how did this patch get merged without a signoff/ack from the OMAP
> > DT maintainer in the first place? Hmm, looks like Benoit was not copied
> > nor was linux-omap or linux-arm-kernel copied in the original mails.
>
> Hmm. I had Benoit's okay [0] to do the change "as long as Felipe is
> fine with it". I indeed forgot to Cc Benoit on the dts changes.
> For the phy-rename Felipe pinged you and we did the topic-branch, here
> I forgot.
No. Read that email again. What Benoit said was that if Felipe was fine
with the change _HE_ would take it. Huge difference, and one that would have
avoided this situation.
The only way to solve these things in the future is to make the driver handle
both the new and the old binding. Bindings are not supposed to change in
incompatible ways any more, unless for special circumstances and/or when the
old binding was completely broken.
The only way forward here, since Greg runs a stable tree that he doesn't
rebase, is for us to rebuild without the OMAP DT branch, and ask Benoit to take
out the conflicting changes.
Benoit, I know this is none of your fault, but would you mind preparing a new
copy of the DT branch without the conflicting patches, and hold those to 3.13?
I haven't looked to see how many those were.
-Olof
On 08/27/2013 06:12 PM, Olof Johansson wrote:
> No. Read that email again. What Benoit said was that if Felipe was fine
> with the change _HE_ would take it. Huge difference, and one that would have
> avoided this situation.
Yes, I'm sorry.
> The only way to solve these things in the future is to make the driver handle
> both the new and the old binding. Bindings are not supposed to change in
> incompatible ways any more, unless for special circumstances and/or when the
> old binding was completely broken.
The old bindings were completly broken.
> -Olof
Sebastian
On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/27/2013 04:05 PM, Benoit Cousson wrote:
> > On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
> >> On 08/27/2013 03:57 PM, Benoit Cousson wrote:
> >>> + Kevin,
> >>>
> >>> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
> >>>> What do we do now?
> >>>
> >>> Cannot you just merge the stable arm-soc/dt branch into your branch
> >>> before applying your patches?
> >>
> >> That is up to Greg. This changes sat in his usb-next tree for a while
> >> now. And before they hit Greg they were in Felipe's tree for a while.
> >>
> >> To be exact, last .dts change via USB was:
> >>
> >> Author: Sebastian Andrzej Siewior <[email protected]>
> >> AuthorDate: Thu Jun 20 12:13:04 2013 +0200
> >> Commit: Felipe Balbi <[email protected]>
> >> CommitDate: Fri Aug 9 17:40:16 2013 +0300
> >>
> >> usb: musb dma: add cppi41 dma driver
> >
> > Mmm, if that branch is supposed to be stable, I'm not sure it will be
> > doable...
> >
> > Maybe we should do the other way around? And merge usb-next into
> > arm-soc/dt.
> >
> > Kevin, Olof?
>
> Please be aware that I have no response so far regarding [0] from Greg.
>
> [0] http://www.spinics.net/lists/linux-usb/msg92595.html
Nor will you, given that I am not the one to take these patches, Felipe
is. I noticed now that you said "please route around Felipe", but
sorry, no, I'm not going to do that unless there's a really good reason.
Felipe seems to be around at the moment, please work with him on this.
sorry,
greg k-h
Hi,
On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote:
> On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote:
> > On 08/27/2013 04:05 PM, Benoit Cousson wrote:
> > > On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
> > >> On 08/27/2013 03:57 PM, Benoit Cousson wrote:
> > >>> + Kevin,
> > >>>
> > >>> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
> > >>>> What do we do now?
> > >>>
> > >>> Cannot you just merge the stable arm-soc/dt branch into your branch
> > >>> before applying your patches?
> > >>
> > >> That is up to Greg. This changes sat in his usb-next tree for a while
> > >> now. And before they hit Greg they were in Felipe's tree for a while.
> > >>
> > >> To be exact, last .dts change via USB was:
> > >>
> > >> Author: Sebastian Andrzej Siewior <[email protected]>
> > >> AuthorDate: Thu Jun 20 12:13:04 2013 +0200
> > >> Commit: Felipe Balbi <[email protected]>
> > >> CommitDate: Fri Aug 9 17:40:16 2013 +0300
> > >>
> > >> usb: musb dma: add cppi41 dma driver
> > >
> > > Mmm, if that branch is supposed to be stable, I'm not sure it will be
> > > doable...
> > >
> > > Maybe we should do the other way around? And merge usb-next into
> > > arm-soc/dt.
> > >
> > > Kevin, Olof?
> >
> > Please be aware that I have no response so far regarding [0] from Greg.
> >
> > [0] http://www.spinics.net/lists/linux-usb/msg92595.html
>
> Nor will you, given that I am not the one to take these patches, Felipe
> is. I noticed now that you said "please route around Felipe", but
> sorry, no, I'm not going to do that unless there's a really good reason.
> Felipe seems to be around at the moment, please work with him on this.
If you will still take a 'part2' pull request from me, I can send you
urgent bugfixes by friday. If I have some time left, I can even try to
get that sorted out by tomorrow.
cheers
--
balbi
On 08/27/2013 07:37 PM, Greg KH wrote:
> Nor will you, given that I am not the one to take these patches, Felipe
> is. I noticed now that you said "please route around Felipe", but
> sorry, no, I'm not going to do that unless there's a really good reason.
> Felipe seems to be around at the moment, please work with him on this.
I said that if you prefer to leave this up to Felipe once he gets back,
then it is okay, too. Letting me know would be nice. By the time of
writting I did not know when he gets back but knew that I won't be
around once -rc1 is out to re-ping if necessary.
Now that he is back, I can work with him.
>
> sorry,
>
> greg k-h
Sebastian
On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote:
> > On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 08/27/2013 04:05 PM, Benoit Cousson wrote:
> > > > On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
> > > >> On 08/27/2013 03:57 PM, Benoit Cousson wrote:
> > > >>> + Kevin,
> > > >>>
> > > >>> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
> > > >>>> What do we do now?
> > > >>>
> > > >>> Cannot you just merge the stable arm-soc/dt branch into your branch
> > > >>> before applying your patches?
> > > >>
> > > >> That is up to Greg. This changes sat in his usb-next tree for a while
> > > >> now. And before they hit Greg they were in Felipe's tree for a while.
> > > >>
> > > >> To be exact, last .dts change via USB was:
> > > >>
> > > >> Author: Sebastian Andrzej Siewior <[email protected]>
> > > >> AuthorDate: Thu Jun 20 12:13:04 2013 +0200
> > > >> Commit: Felipe Balbi <[email protected]>
> > > >> CommitDate: Fri Aug 9 17:40:16 2013 +0300
> > > >>
> > > >> usb: musb dma: add cppi41 dma driver
> > > >
> > > > Mmm, if that branch is supposed to be stable, I'm not sure it will be
> > > > doable...
> > > >
> > > > Maybe we should do the other way around? And merge usb-next into
> > > > arm-soc/dt.
> > > >
> > > > Kevin, Olof?
> > >
> > > Please be aware that I have no response so far regarding [0] from Greg.
> > >
> > > [0] http://www.spinics.net/lists/linux-usb/msg92595.html
> >
> > Nor will you, given that I am not the one to take these patches, Felipe
> > is. I noticed now that you said "please route around Felipe", but
> > sorry, no, I'm not going to do that unless there's a really good reason.
> > Felipe seems to be around at the moment, please work with him on this.
>
> If you will still take a 'part2' pull request from me, I can send you
> urgent bugfixes by friday. If I have some time left, I can even try to
> get that sorted out by tomorrow.
For 3.12 stuff, like "fixes", sure, I can take them this week, that
should give us a week or so for linux-next testing, right?
thanks,
greg k-h
Hi,
On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote:
> On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote:
> > > On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote:
> > > > On 08/27/2013 04:05 PM, Benoit Cousson wrote:
> > > > > On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
> > > > >> On 08/27/2013 03:57 PM, Benoit Cousson wrote:
> > > > >>> + Kevin,
> > > > >>>
> > > > >>> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
> > > > >>>> What do we do now?
> > > > >>>
> > > > >>> Cannot you just merge the stable arm-soc/dt branch into your branch
> > > > >>> before applying your patches?
> > > > >>
> > > > >> That is up to Greg. This changes sat in his usb-next tree for a while
> > > > >> now. And before they hit Greg they were in Felipe's tree for a while.
> > > > >>
> > > > >> To be exact, last .dts change via USB was:
> > > > >>
> > > > >> Author: Sebastian Andrzej Siewior <[email protected]>
> > > > >> AuthorDate: Thu Jun 20 12:13:04 2013 +0200
> > > > >> Commit: Felipe Balbi <[email protected]>
> > > > >> CommitDate: Fri Aug 9 17:40:16 2013 +0300
> > > > >>
> > > > >> usb: musb dma: add cppi41 dma driver
> > > > >
> > > > > Mmm, if that branch is supposed to be stable, I'm not sure it will be
> > > > > doable...
> > > > >
> > > > > Maybe we should do the other way around? And merge usb-next into
> > > > > arm-soc/dt.
> > > > >
> > > > > Kevin, Olof?
> > > >
> > > > Please be aware that I have no response so far regarding [0] from Greg.
> > > >
> > > > [0] http://www.spinics.net/lists/linux-usb/msg92595.html
> > >
> > > Nor will you, given that I am not the one to take these patches, Felipe
> > > is. I noticed now that you said "please route around Felipe", but
> > > sorry, no, I'm not going to do that unless there's a really good reason.
> > > Felipe seems to be around at the moment, please work with him on this.
> >
> > If you will still take a 'part2' pull request from me, I can send you
> > urgent bugfixes by friday. If I have some time left, I can even try to
> > get that sorted out by tomorrow.
>
> For 3.12 stuff, like "fixes", sure, I can take them this week, that
> should give us a week or so for linux-next testing, right?
that's correct. I have most of them already queued up, let me just go
over my linux-usb maildir again and make sure I got all the important
stuff in.
cheers, thanks for opening this 'window'.
--
balbi
Hi Olof,
On 27/08/2013 18:12, Olof Johansson wrote:
> On Tue, Aug 27, 2013 at 05:25:23PM +0200, Sebastian Andrzej Siewior wrote:
>> On 08/27/2013 05:01 PM, Kevin Hilman wrote:
>>>>> What do we do now?
>>>>
>>>> Cannot you just merge the stable arm-soc/dt branch into your branch
>>>> before applying your patches?
>>>
>>> Unfortunately, the next/dt branch of arm-soc is not necessarily stable
>>> so should *not* be merged. In fact none of the arm-soc branches should
>>> be considered stable.
>>>
>>> As was already mentioned, this should be split up into driver changes
>>> and DTS changes through arm-soc. They'll both merge for v3.12.
>>
>> But splitting will break the driver until .dts & code is in sync again.
>>
>>> BTW, how did this patch get merged without a signoff/ack from the OMAP
>>> DT maintainer in the first place? Hmm, looks like Benoit was not copied
>>> nor was linux-omap or linux-arm-kernel copied in the original mails.
>>
>> Hmm. I had Benoit's okay [0] to do the change "as long as Felipe is
>> fine with it". I indeed forgot to Cc Benoit on the dts changes.
>> For the phy-rename Felipe pinged you and we did the topic-branch, here
>> I forgot.
>
> No. Read that email again. What Benoit said was that if Felipe was fine
> with the change _HE_ would take it. Huge difference, and one that would have
> avoided this situation.
>
> The only way to solve these things in the future is to make the driver handle
> both the new and the old binding. Bindings are not supposed to change in
> incompatible ways any more, unless for special circumstances and/or when the
> old binding was completely broken.
>
>
> The only way forward here, since Greg runs a stable tree that he doesn't
> rebase, is for us to rebuild without the OMAP DT branch, and ask Benoit to take
> out the conflicting changes.
>
> Benoit, I know this is none of your fault, but would you mind preparing a new
> copy of the DT branch without the conflicting patches, and hold those to 3.13?
> I haven't looked to see how many those were.
OK, I'll do that ASAP and check how many should be removed to avoid a
conflict with usb-next.
Regards,
Benoit
Hi Felipe
On 27/08/2013 21:56, Felipe Balbi wrote:
> Hi,
>
> On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote:
>> On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote:
>>>> On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote:
>>>>> On 08/27/2013 04:05 PM, Benoit Cousson wrote:
>>>>>> On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
>>>>>>> On 08/27/2013 03:57 PM, Benoit Cousson wrote:
>>>>>>>> + Kevin,
>>>>>>>>
>>>>>>>> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
>>>>>>>>> What do we do now?
>>>>>>>>
>>>>>>>> Cannot you just merge the stable arm-soc/dt branch into your branch
>>>>>>>> before applying your patches?
>>>>>>>
>>>>>>> That is up to Greg. This changes sat in his usb-next tree for a while
>>>>>>> now. And before they hit Greg they were in Felipe's tree for a while.
>>>>>>>
>>>>>>> To be exact, last .dts change via USB was:
>>>>>>>
>>>>>>> Author: Sebastian Andrzej Siewior <[email protected]>
>>>>>>> AuthorDate: Thu Jun 20 12:13:04 2013 +0200
>>>>>>> Commit: Felipe Balbi <[email protected]>
>>>>>>> CommitDate: Fri Aug 9 17:40:16 2013 +0300
>>>>>>>
>>>>>>> usb: musb dma: add cppi41 dma driver
>>>>>>
>>>>>> Mmm, if that branch is supposed to be stable, I'm not sure it will be
>>>>>> doable...
>>>>>>
>>>>>> Maybe we should do the other way around? And merge usb-next into
>>>>>> arm-soc/dt.
>>>>>>
>>>>>> Kevin, Olof?
>>>>>
>>>>> Please be aware that I have no response so far regarding [0] from Greg.
>>>>>
>>>>> [0] http://www.spinics.net/lists/linux-usb/msg92595.html
>>>>
>>>> Nor will you, given that I am not the one to take these patches, Felipe
>>>> is. I noticed now that you said "please route around Felipe", but
>>>> sorry, no, I'm not going to do that unless there's a really good reason.
>>>> Felipe seems to be around at the moment, please work with him on this.
>>>
>>> If you will still take a 'part2' pull request from me, I can send you
>>> urgent bugfixes by friday. If I have some time left, I can even try to
>>> get that sorted out by tomorrow.
>>
>> For 3.12 stuff, like "fixes", sure, I can take them this week, that
>> should give us a week or so for linux-next testing, right?
>
> that's correct. I have most of them already queued up, let me just go
> over my linux-usb maildir again and make sure I got all the important
> stuff in.
>
> cheers, thanks for opening this 'window'.
There are two patches in my DTS tree that conflict with the usb-next.
I will remove that one (ARM: dts: AM33XX: don't redefine OCP bus and
device nodes) , as suggested by Olof, since it is the biggest source of
conflict from my tree.
The second one is easily fixable, and Stephen already did it, but it
will be even better it you could take it in your tree.
This is the patch you did that I just slightly renamed (ARM: OMAP5: dts:
fix reg property size).
Regards,
Benoit
On Thu, Aug 29, 2013 at 12:06 PM, Benoit Cousson <[email protected]> wrote:
> Hi Felipe
>
>
> On 27/08/2013 21:56, Felipe Balbi wrote:
>>
>> Hi,
>>
>> On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote:
>>>
>>> On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote:
>>>>>
>>>>> On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior
>>>>> wrote:
>>>>>>
>>>>>> On 08/27/2013 04:05 PM, Benoit Cousson wrote:
>>>>>>>
>>>>>>> On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
>>>>>>>>
>>>>>>>> On 08/27/2013 03:57 PM, Benoit Cousson wrote:
>>>>>>>>>
>>>>>>>>> + Kevin,
>>>>>>>>>
>>>>>>>>> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
>>>>>>>>>>
>>>>>>>>>> What do we do now?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cannot you just merge the stable arm-soc/dt branch into your branch
>>>>>>>>> before applying your patches?
>>>>>>>>
>>>>>>>>
>>>>>>>> That is up to Greg. This changes sat in his usb-next tree for a
>>>>>>>> while
>>>>>>>> now. And before they hit Greg they were in Felipe's tree for a
>>>>>>>> while.
>>>>>>>>
>>>>>>>> To be exact, last .dts change via USB was:
>>>>>>>>
>>>>>>>> Author: Sebastian Andrzej Siewior <[email protected]>
>>>>>>>> AuthorDate: Thu Jun 20 12:13:04 2013 +0200
>>>>>>>> Commit: Felipe Balbi <[email protected]>
>>>>>>>> CommitDate: Fri Aug 9 17:40:16 2013 +0300
>>>>>>>>
>>>>>>>> usb: musb dma: add cppi41 dma driver
>>>>>>>
>>>>>>>
>>>>>>> Mmm, if that branch is supposed to be stable, I'm not sure it will be
>>>>>>> doable...
>>>>>>>
>>>>>>> Maybe we should do the other way around? And merge usb-next into
>>>>>>> arm-soc/dt.
>>>>>>>
>>>>>>> Kevin, Olof?
>>>>>>
>>>>>>
>>>>>> Please be aware that I have no response so far regarding [0] from
>>>>>> Greg.
>>>>>>
>>>>>> [0] http://www.spinics.net/lists/linux-usb/msg92595.html
>>>>>
>>>>>
>>>>> Nor will you, given that I am not the one to take these patches, Felipe
>>>>> is. I noticed now that you said "please route around Felipe", but
>>>>> sorry, no, I'm not going to do that unless there's a really good
>>>>> reason.
>>>>> Felipe seems to be around at the moment, please work with him on this.
>>>>
>>>>
>>>> If you will still take a 'part2' pull request from me, I can send you
>>>> urgent bugfixes by friday. If I have some time left, I can even try to
>>>> get that sorted out by tomorrow.
>>>
>>>
>>> For 3.12 stuff, like "fixes", sure, I can take them this week, that
>>> should give us a week or so for linux-next testing, right?
>>
>>
>> that's correct. I have most of them already queued up, let me just go
>> over my linux-usb maildir again and make sure I got all the important
>> stuff in.
>>
>> cheers, thanks for opening this 'window'.
>
>
> There are two patches in my DTS tree that conflict with the usb-next.
>
> I will remove that one (ARM: dts: AM33XX: don't redefine OCP bus and device
> nodes) , as suggested by Olof, since it is the biggest source of conflict
> from my tree.
>
Hi Benoit,
Should I re-post this patch for 3.13 or do you think that the clean-up
is not worth it due the high probability to lead to a merge conflict?
I know is an intrusive change but a needed cleanup IMHO. People keep
doing copy & paste with current am33xx DT and keep duplicating device
nodes already existing in the included .dtsi file. I reviewed at least
2 new DTS that had the same issue.
Also, this shouldn't had happened if all the OMAP DT patches went
through your tree...
> The second one is easily fixable, and Stephen already did it, but it will be
> even better it you could take it in your tree.
> This is the patch you did that I just slightly renamed (ARM: OMAP5: dts: fix
> reg property size).
>
> Regards,
> Benoit
>
Best regards,
Javier
On Thu, Aug 29, 2013 at 12:06:32PM +0200, Benoit Cousson wrote:
> Hi Felipe
>
> On 27/08/2013 21:56, Felipe Balbi wrote:
> >Hi,
> >
> >On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote:
> >>On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote:
> >>>Hi,
> >>>
> >>>On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote:
> >>>>On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote:
> >>>>>On 08/27/2013 04:05 PM, Benoit Cousson wrote:
> >>>>>>On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
> >>>>>>>On 08/27/2013 03:57 PM, Benoit Cousson wrote:
> >>>>>>>>+ Kevin,
> >>>>>>>>
> >>>>>>>>On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
> >>>>>>>>>What do we do now?
> >>>>>>>>
> >>>>>>>>Cannot you just merge the stable arm-soc/dt branch into your branch
> >>>>>>>>before applying your patches?
> >>>>>>>
> >>>>>>>That is up to Greg. This changes sat in his usb-next tree for a while
> >>>>>>>now. And before they hit Greg they were in Felipe's tree for a while.
> >>>>>>>
> >>>>>>>To be exact, last .dts change via USB was:
> >>>>>>>
> >>>>>>>Author: Sebastian Andrzej Siewior <[email protected]>
> >>>>>>>AuthorDate: Thu Jun 20 12:13:04 2013 +0200
> >>>>>>>Commit: Felipe Balbi <[email protected]>
> >>>>>>>CommitDate: Fri Aug 9 17:40:16 2013 +0300
> >>>>>>>
> >>>>>>> usb: musb dma: add cppi41 dma driver
> >>>>>>
> >>>>>>Mmm, if that branch is supposed to be stable, I'm not sure it will be
> >>>>>>doable...
> >>>>>>
> >>>>>>Maybe we should do the other way around? And merge usb-next into
> >>>>>>arm-soc/dt.
> >>>>>>
> >>>>>>Kevin, Olof?
> >>>>>
> >>>>>Please be aware that I have no response so far regarding [0] from Greg.
> >>>>>
> >>>>>[0] http://www.spinics.net/lists/linux-usb/msg92595.html
> >>>>
> >>>>Nor will you, given that I am not the one to take these patches, Felipe
> >>>>is. I noticed now that you said "please route around Felipe", but
> >>>>sorry, no, I'm not going to do that unless there's a really good reason.
> >>>>Felipe seems to be around at the moment, please work with him on this.
> >>>
> >>>If you will still take a 'part2' pull request from me, I can send you
> >>>urgent bugfixes by friday. If I have some time left, I can even try to
> >>>get that sorted out by tomorrow.
> >>
> >>For 3.12 stuff, like "fixes", sure, I can take them this week, that
> >>should give us a week or so for linux-next testing, right?
> >
> >that's correct. I have most of them already queued up, let me just go
> >over my linux-usb maildir again and make sure I got all the important
> >stuff in.
> >
> >cheers, thanks for opening this 'window'.
>
> There are two patches in my DTS tree that conflict with the usb-next.
>
> I will remove that one (ARM: dts: AM33XX: don't redefine OCP bus and
> device nodes) , as suggested by Olof, since it is the biggest source
> of conflict from my tree.
>
> The second one is easily fixable, and Stephen already did it, but it
> will be even better it you could take it in your tree.
> This is the patch you did that I just slightly renamed (ARM: OMAP5:
> dts: fix reg property size).
I'm done with Pull requests for Greg. If the conflict is easy to solve,
what's the problem in having the conflict to start with ?
--
balbi
On 29/08/2013 16:23, Felipe Balbi wrote:
> On Thu, Aug 29, 2013 at 12:06:32PM +0200, Benoit Cousson wrote:
>> Hi Felipe
>>
>> On 27/08/2013 21:56, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote:
>>>> On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote:
>>>>>> On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote:
>>>>>>> On 08/27/2013 04:05 PM, Benoit Cousson wrote:
>>>>>>>> On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote:
>>>>>>>>> On 08/27/2013 03:57 PM, Benoit Cousson wrote:
>>>>>>>>>> + Kevin,
>>>>>>>>>>
>>>>>>>>>> On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote:
>>>>>>>>>>> What do we do now?
>>>>>>>>>>
>>>>>>>>>> Cannot you just merge the stable arm-soc/dt branch into your branch
>>>>>>>>>> before applying your patches?
>>>>>>>>>
>>>>>>>>> That is up to Greg. This changes sat in his usb-next tree for a while
>>>>>>>>> now. And before they hit Greg they were in Felipe's tree for a while.
>>>>>>>>>
>>>>>>>>> To be exact, last .dts change via USB was:
>>>>>>>>>
>>>>>>>>> Author: Sebastian Andrzej Siewior <[email protected]>
>>>>>>>>> AuthorDate: Thu Jun 20 12:13:04 2013 +0200
>>>>>>>>> Commit: Felipe Balbi <[email protected]>
>>>>>>>>> CommitDate: Fri Aug 9 17:40:16 2013 +0300
>>>>>>>>>
>>>>>>>>> usb: musb dma: add cppi41 dma driver
>>>>>>>>
>>>>>>>> Mmm, if that branch is supposed to be stable, I'm not sure it will be
>>>>>>>> doable...
>>>>>>>>
>>>>>>>> Maybe we should do the other way around? And merge usb-next into
>>>>>>>> arm-soc/dt.
>>>>>>>>
>>>>>>>> Kevin, Olof?
>>>>>>>
>>>>>>> Please be aware that I have no response so far regarding [0] from Greg.
>>>>>>>
>>>>>>> [0] http://www.spinics.net/lists/linux-usb/msg92595.html
>>>>>>
>>>>>> Nor will you, given that I am not the one to take these patches, Felipe
>>>>>> is. I noticed now that you said "please route around Felipe", but
>>>>>> sorry, no, I'm not going to do that unless there's a really good reason.
>>>>>> Felipe seems to be around at the moment, please work with him on this.
>>>>>
>>>>> If you will still take a 'part2' pull request from me, I can send you
>>>>> urgent bugfixes by friday. If I have some time left, I can even try to
>>>>> get that sorted out by tomorrow.
>>>>
>>>> For 3.12 stuff, like "fixes", sure, I can take them this week, that
>>>> should give us a week or so for linux-next testing, right?
>>>
>>> that's correct. I have most of them already queued up, let me just go
>>> over my linux-usb maildir again and make sure I got all the important
>>> stuff in.
>>>
>>> cheers, thanks for opening this 'window'.
>>
>> There are two patches in my DTS tree that conflict with the usb-next.
>>
>> I will remove that one (ARM: dts: AM33XX: don't redefine OCP bus and
>> device nodes) , as suggested by Olof, since it is the biggest source
>> of conflict from my tree.
>>
>> The second one is easily fixable, and Stephen already did it, but it
>> will be even better it you could take it in your tree.
>> This is the patch you did that I just slightly renamed (ARM: OMAP5:
>> dts: fix reg property size).
>
> I'm done with Pull requests for Greg. If the conflict is easy to solve,
> what's the problem in having the conflict to start with ?
Well, it is mainly the other one that is a pain to fix. Since I was
about to send another pull-request, I was wondering if you'll be OK to
take it.
Regards,
Benoit