From: Tony Lindgren <tony@atomide.com>
To: Nishanth Menon <nm@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
santosh shilimkar <santosh.shilimkar@oracle.com>,
lkml <linux-kernel@vger.kernel.org>,
Stefan Hengelein <stefan.hengelein@fau.de>,
linux-omap <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
Date: Tue, 17 Mar 2015 10:10:00 -0700 [thread overview]
Message-ID: <20150317171000.GD31346@atomide.com> (raw)
In-Reply-To: <CAGo_u6oHk9MXPGQv1rCpvW_oegzEzFTu3sZ_4j_6HFEivnXZXg@mail.gmail.com>
* Nishanth Menon <nm@ti.com> [150317 09:57]:
> On Tue, Mar 17, 2015 at 11:34 AM, Tony Lindgren <tony@atomide.com> wrote:
> >> On 03/17/2015 11:26 AM, santosh shilimkar wrote:
> >> >
> >> >
> >> > On 3/16/2015 4:30 PM, Tony Lindgren wrote:
> >> >> * Stefan Hengelein <stefan.hengelein@fau.de> [150225 10:48]:
> >> >>> The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a
> >> >>> contradiction in it's dependencies.
> >> >>> The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an
> >> >>> enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be
> >> >>> enabled. These options inherit a dependency from an enclosing menu,
> >> >>> that requires ARCH_MULTIPLATFORM to be 'enabled'.
> >> >>> This is a contradiction and made this option also unavailable for
> >> >>> non-multiplatform configurations.
> >> >>>
> >> >>> Since there are no selects on OMAP4_ERRATA_I688, which would ignore
> >> >>> dependencies, the code related to that option is dead and can be
> >> >>> removed.
> >> >>>
> >> >>> This (logical) defect has been found with the undertaker tool.
> >> >>> (https://undertaker.cs.fau.de)
> >> >>>
> >> >>> Signed-off-by: Stefan Hengelein <stefan.hengelein@fau.de>
> >> >>>
> >> >>> ---
> >> >>> Tony Lindgren suggested to remove the code since nobody complained for
> >> >>> a few years and Santosh Shilimkar agreed.
> >> >>> https://lkml.org/lkml/2015/2/25/449
> >> >>> ---
> >> >>> As far as I see, this should remove all the code related to
> >> >>> OMAP4_ERRATA_I688, I hope I didn't remove too much.
> >> >>
> >> >> Seems to boot fine, so applying into omap-for-v4.1/fixes-not-urgent.
> >> >>
> >> > Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
> >>
> >> We no longer need i688? I do understand the need to cleanup the macros
> >> for multi-arch etc.. but loosing a bug workaround for a real silicon
> >> bug is really an invitation for hard to debug issues IMHO.
> >
> > Well that code has not been selectable for a few years now. Naturally
> > we can add it back when it actually does something with multiarch.
> >
>
> I suppose we are sure that downstream kernels that actually try stuff
> out never went ahead and enabled this.. we do have non multi-platform
> builds as well... I am just saying... having been around during the
> discovery of i688, I kinda know how much pain it takes to find the
> damn thing in the first place. a simple boot was not ever an easy
> enough test for it. I do suggest at least adding a print for omap4
> saying that i688 is disabled..
Yes that's a good point and adding a printk is a good idea. Care to
crank out a separate patch for that?
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: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
Date: Tue, 17 Mar 2015 10:10:00 -0700 [thread overview]
Message-ID: <20150317171000.GD31346@atomide.com> (raw)
In-Reply-To: <CAGo_u6oHk9MXPGQv1rCpvW_oegzEzFTu3sZ_4j_6HFEivnXZXg@mail.gmail.com>
* Nishanth Menon <nm@ti.com> [150317 09:57]:
> On Tue, Mar 17, 2015 at 11:34 AM, Tony Lindgren <tony@atomide.com> wrote:
> >> On 03/17/2015 11:26 AM, santosh shilimkar wrote:
> >> >
> >> >
> >> > On 3/16/2015 4:30 PM, Tony Lindgren wrote:
> >> >> * Stefan Hengelein <stefan.hengelein@fau.de> [150225 10:48]:
> >> >>> The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a
> >> >>> contradiction in it's dependencies.
> >> >>> The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an
> >> >>> enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be
> >> >>> enabled. These options inherit a dependency from an enclosing menu,
> >> >>> that requires ARCH_MULTIPLATFORM to be 'enabled'.
> >> >>> This is a contradiction and made this option also unavailable for
> >> >>> non-multiplatform configurations.
> >> >>>
> >> >>> Since there are no selects on OMAP4_ERRATA_I688, which would ignore
> >> >>> dependencies, the code related to that option is dead and can be
> >> >>> removed.
> >> >>>
> >> >>> This (logical) defect has been found with the undertaker tool.
> >> >>> (https://undertaker.cs.fau.de)
> >> >>>
> >> >>> Signed-off-by: Stefan Hengelein <stefan.hengelein@fau.de>
> >> >>>
> >> >>> ---
> >> >>> Tony Lindgren suggested to remove the code since nobody complained for
> >> >>> a few years and Santosh Shilimkar agreed.
> >> >>> https://lkml.org/lkml/2015/2/25/449
> >> >>> ---
> >> >>> As far as I see, this should remove all the code related to
> >> >>> OMAP4_ERRATA_I688, I hope I didn't remove too much.
> >> >>
> >> >> Seems to boot fine, so applying into omap-for-v4.1/fixes-not-urgent.
> >> >>
> >> > Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
> >>
> >> We no longer need i688? I do understand the need to cleanup the macros
> >> for multi-arch etc.. but loosing a bug workaround for a real silicon
> >> bug is really an invitation for hard to debug issues IMHO.
> >
> > Well that code has not been selectable for a few years now. Naturally
> > we can add it back when it actually does something with multiarch.
> >
>
> I suppose we are sure that downstream kernels that actually try stuff
> out never went ahead and enabled this.. we do have non multi-platform
> builds as well... I am just saying... having been around during the
> discovery of i688, I kinda know how much pain it takes to find the
> damn thing in the first place. a simple boot was not ever an easy
> enough test for it. I do suggest at least adding a print for omap4
> saying that i688 is disabled..
Yes that's a good point and adding a printk is a good idea. Care to
crank out a separate patch for that?
Regards,
Tony
next prev parent reply other threads:[~2015-03-17 17:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-25 18:44 [PATCH] ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688 Stefan Hengelein
2015-02-25 18:44 ` Stefan Hengelein
2015-03-16 23:30 ` Tony Lindgren
2015-03-16 23:30 ` Tony Lindgren
2015-03-17 16:26 ` santosh shilimkar
2015-03-17 16:26 ` santosh shilimkar
2015-03-17 16:31 ` Nishanth Menon
2015-03-17 16:31 ` Nishanth Menon
2015-03-17 16:31 ` Nishanth Menon
2015-03-17 16:34 ` Tony Lindgren
2015-03-17 16:34 ` Tony Lindgren
2015-03-17 16:57 ` Nishanth Menon
2015-03-17 16:57 ` Nishanth Menon
2015-03-17 17:10 ` Tony Lindgren [this message]
2015-03-17 17:10 ` Tony Lindgren
2015-03-17 17:18 ` Nishanth Menon
2015-03-17 17:18 ` Nishanth Menon
2015-03-17 17:27 ` Tony Lindgren
2015-03-17 17:27 ` Tony Lindgren
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=20150317171000.GD31346@atomide.com \
--to=tony@atomide.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nm@ti.com \
--cc=santosh.shilimkar@oracle.com \
--cc=stefan.hengelein@fau.de \
/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.