From: Tony Lindgren <tony@atomide.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>, Joe Woodward <jw@terrafix.co.uk>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: OMAP3: clockdomain: fix accidental duplicate registration
Date: Thu, 19 Jul 2012 04:52:16 -0700 [thread overview]
Message-ID: <20120719115216.GP6522@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1207180341001.16772@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [120718 02:58]:
> Hi
>
> On Mon, 16 Jul 2012, Tony Lindgren wrote:
>
> > Hmm well it seems that we should apply this fix into arm-soc next/cleanup
> > branch if that's where the mismerge happened? It seems the same mismerge
> > is there even without 16e5e2c4?
>
> The arm-soc next/cleanup copy of mach-omap2/clockdomains3xxx_data.c is
> correct. The problem that my patch was designed to fix doesn't exist in
> that version of the file (868c157df9721675c19729eed2c96bac6c3f1d01).
OK
> > You patch applies into arm-soc next/cleanup with fuzz:
> >
> > patching file arch/arm/mach-omap2/clockdomain.c
> > patching file arch/arm/mach-omap2/clockdomain.h
> > Hunk #1 succeeded at 82 (offset -4 lines).
> > patching file arch/arm/mach-omap2/clockdomains3xxx_data.c
> > Hunk #1 succeeded at 347 with fuzz 2 (offset -107 lines).
> >
> > So that's why I'm wondering if it needs some changes.
>
> OK, I understand why you're asking.
>
> I went back and researched it. The patch that I sent is only needed
> because the conflict resolution in merge commit
> 3dd50d0545bd5a8ad83d4339f07935cd3e883271 ("Merge tag
> 'omap-cleanup-for-v3.6' into tmp-merge") adds &mpu_3xxx_clkdm back into
> the clockdomains_common list. The previous commit on that file
> 16e5e2c471ab889f838bfe1c44032d0481c115e1 removed &mpu_3xxx_clkdm from the
> common list, because the AM35xx chips needed to use a different MPU
> clockdomain structure from the OMAP3xxx chips.
>
> Or, put differently: Before 16e5e2c471ab889f838bfe1c44032d0481c115e1, it
> was correct to have &mpu_3xxx_clkdm in the common list. That's
> what's in arm-soc next/cleanup and that data is correct.
>
> After 16e5e2c471ab889f838bfe1c44032d0481c115e1, it's incorrect to have
> &mpu_3xxx_clkdm in the common list.
>
> Hope this isn't even more confusing :-)
Well I'm still a bit confused :)
Which branch in arm-soc tree should this fix be applied then?
Or do we actually need two fixes into arm-soc tree?
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP3: clockdomain: fix accidental duplicate registration
Date: Thu, 19 Jul 2012 04:52:16 -0700 [thread overview]
Message-ID: <20120719115216.GP6522@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1207180341001.16772@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [120718 02:58]:
> Hi
>
> On Mon, 16 Jul 2012, Tony Lindgren wrote:
>
> > Hmm well it seems that we should apply this fix into arm-soc next/cleanup
> > branch if that's where the mismerge happened? It seems the same mismerge
> > is there even without 16e5e2c4?
>
> The arm-soc next/cleanup copy of mach-omap2/clockdomains3xxx_data.c is
> correct. The problem that my patch was designed to fix doesn't exist in
> that version of the file (868c157df9721675c19729eed2c96bac6c3f1d01).
OK
> > You patch applies into arm-soc next/cleanup with fuzz:
> >
> > patching file arch/arm/mach-omap2/clockdomain.c
> > patching file arch/arm/mach-omap2/clockdomain.h
> > Hunk #1 succeeded at 82 (offset -4 lines).
> > patching file arch/arm/mach-omap2/clockdomains3xxx_data.c
> > Hunk #1 succeeded at 347 with fuzz 2 (offset -107 lines).
> >
> > So that's why I'm wondering if it needs some changes.
>
> OK, I understand why you're asking.
>
> I went back and researched it. The patch that I sent is only needed
> because the conflict resolution in merge commit
> 3dd50d0545bd5a8ad83d4339f07935cd3e883271 ("Merge tag
> 'omap-cleanup-for-v3.6' into tmp-merge") adds &mpu_3xxx_clkdm back into
> the clockdomains_common list. The previous commit on that file
> 16e5e2c471ab889f838bfe1c44032d0481c115e1 removed &mpu_3xxx_clkdm from the
> common list, because the AM35xx chips needed to use a different MPU
> clockdomain structure from the OMAP3xxx chips.
>
> Or, put differently: Before 16e5e2c471ab889f838bfe1c44032d0481c115e1, it
> was correct to have &mpu_3xxx_clkdm in the common list. That's
> what's in arm-soc next/cleanup and that data is correct.
>
> After 16e5e2c471ab889f838bfe1c44032d0481c115e1, it's incorrect to have
> &mpu_3xxx_clkdm in the common list.
>
> Hope this isn't even more confusing :-)
Well I'm still a bit confused :)
Which branch in arm-soc tree should this fix be applied then?
Or do we actually need two fixes into arm-soc tree?
Regards,
Tony
next prev parent reply other threads:[~2012-07-19 11:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 10:54 [PATCH] ARM: OMAP3: clockdomain: fix accidental duplicate registration Paul Walmsley
2012-07-12 10:54 ` Paul Walmsley
2012-07-12 17:50 ` Kevin Hilman
2012-07-12 17:50 ` Kevin Hilman
2012-07-13 6:47 ` Tony Lindgren
2012-07-13 6:47 ` Tony Lindgren
2012-07-14 8:52 ` Tony Lindgren
2012-07-14 8:52 ` Tony Lindgren
2012-07-14 17:54 ` Paul Walmsley
2012-07-14 17:54 ` Paul Walmsley
2012-07-16 8:36 ` Tony Lindgren
2012-07-16 8:36 ` Tony Lindgren
2012-07-18 9:53 ` Paul Walmsley
2012-07-18 9:53 ` Paul Walmsley
2012-07-19 11:52 ` Tony Lindgren [this message]
2012-07-19 11:52 ` Tony Lindgren
2012-07-19 19:12 ` Paul Walmsley
2012-07-19 19:12 ` Paul Walmsley
2012-07-24 8:16 ` Tony Lindgren
2012-07-24 8:16 ` Tony Lindgren
2012-07-24 20:52 ` Paul Walmsley
2012-07-24 20:52 ` Paul Walmsley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120719115216.GP6522@atomide.com \
--to=tony@atomide.com \
--cc=jw@terrafix.co.uk \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.