[U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel

[Ajay kumar]

On Thu, Oct 3, 2013 at 9:14 PM, Albert ARIBAUD <albert.u.boot at aribaud.net>wrote:

> Hi Ajay,
>
> On Thu, 3 Oct 2013 14:49:49 +0530, Ajay kumar <ajaynumb at gmail.com>
> wrote:
>
> > Hi Albert,
> >
> >
> > On Thu, Oct 3, 2013 at 2:28 PM, Albert ARIBAUD <
> albert.u.boot at aribaud.net>wrote:
> >
> > > Hi Ajay,
> > >
> > > On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar
> > > <ajaykumar.rs at samsung.com> wrote:
> > >
> > > > Add infrasturcture to cleanup any of those architecture related
> settings
> > > > done for u-boot, if they can cause problem during kernel boot.
> > > >
> > > > Signed-off-by: Ajay Kumar <ajaykumar.rs at samsung.com>
> > > > ---
> > >
> > > Regardless to ma question re fixing the issue in U-Boot or Linux: does
> > > something prevent using the already existing cleanup_before_linux()
> > > function, and if not, what made you choose to create another one
> > > instead?
> > >
>
> (fixed quote glitch here that put the start of your reply inside mine.)
>
> > cleanup_before_linux() generally cleans up things specific to the
> > processor.
> > I thought of introducing a cleanup function which would allow us to
> cleanup
> > things which are SOC specific(all SOC under armv7 as per the patch).
> > And, used the same function to cleanup some exynos specific stuff before
> > booting linux.
> > May be, I should have used a different name instead of
> > arch_cleanup_before_linux?
>
> Well, if it is *SoC* specific, then it is not *arch* specific, so yes,
> the name should be changed. Now, we don't really have a concept of
> 'SoC-specific' in U-Boot, so board-specific, as suggested by Simon, is
> the 'next not-too-worst thing'.
>
> Still, don't rush to provide a new patch. According to Simon, the Linux
> panic was solved and might just not have hit mainline yet; if that is
> confirmed, then renaming arch_cleanup_before_linux() becomes moot.
>
> Ok. I found the kernel patch:
http://permalink.gmane.org/gmane.comp.video.dri.devel/78840
So, this patch is not needed.

Thanks and Regards,
Ajay Kumar