[PATCH] ARM: OMAP3: clockdomain: fix accidental duplicate registration

Tony Lindgren tony at atomide.com
Thu Jul 19 07:52:16 EDT 2012


* Paul Walmsley <paul at 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



More information about the linux-arm-kernel mailing list