ARM: l2c: prima2: only call l2x0_of_init() on matching nodes

Message ID 1398644860-22973-1-git-send-email-mporter@linaro.org
State New
Headers show

Commit Message

Matt Porter April 28, 2014, 12:27 a.m.
l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
platform to fail boot since they have their own pre l2x0 init sequence
that is required. Fix this by checking that a matching OF ID is present
before calling l2x0_of_init().

Reported-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Matt Porter <mporter@linaro.org>
---
Applies against next-20140424 to fix the issue introduced in
50655e6 ARM: l2c: prima2: remove cache size override

 arch/arm/mach-prima2/l2x0.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

Comments

Russell King - ARM Linux April 28, 2014, 9:15 a.m. | #1
On Sun, Apr 27, 2014 at 08:27:40PM -0400, Matt Porter wrote:
> l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
> early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
> platform to fail boot since they have their own pre l2x0 init sequence
> that is required. Fix this by checking that a matching OF ID is present
> before calling l2x0_of_init().
> 
> Reported-by: Kevin Hilman <khilman@linaro.org>
> Signed-off-by: Matt Porter <mporter@linaro.org>
> ---
> Applies against next-20140424 to fix the issue introduced in
> 50655e6 ARM: l2c: prima2: remove cache size override

Err, this only "fixes" it because it effectively disables the L2 cache
_entirely_ - in the above commit, I kill your private compatible strings.

This doesn't make sense.  If the cache is already enabled, then the L2C
code won't try to enable it again.
Matt Porter April 28, 2014, 1:40 p.m. | #2
On Mon, Apr 28, 2014 at 10:15:33AM +0100, Russell King wrote:
> On Sun, Apr 27, 2014 at 08:27:40PM -0400, Matt Porter wrote:
> > l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
> > early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
> > platform to fail boot since they have their own pre l2x0 init sequence
> > that is required. Fix this by checking that a matching OF ID is present
> > before calling l2x0_of_init().
> > 
> > Reported-by: Kevin Hilman <khilman@linaro.org>
> > Signed-off-by: Matt Porter <mporter@linaro.org>
> > ---
> > Applies against next-20140424 to fix the issue introduced in
> > 50655e6 ARM: l2c: prima2: remove cache size override
> 
> Err, this only "fixes" it because it effectively disables the L2 cache
> _entirely_ - in the above commit, I kill your private compatible strings.
>
> This doesn't make sense.  If the cache is already enabled, then the L2C
> code won't try to enable it again.

Ok, please suggest an alternative. You merged this commit..it looks like
it had no ack from the platform maintainer..and I don't have hardware.
The commit is wrong, we can't have every platform executing sirfsoc's
l2x0_of_init() call/parameters by having this stuff in an early initcall
like that.

It would be pretty straightforward to add those private compatibles
back so the approach works. If not, we need to move this to
.init_machine where it's guaranteed to only run on sirfsoc.

-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Felipe Balbi April 28, 2014, 2:29 p.m. | #3
On Sun, Apr 27, 2014 at 08:27:40PM -0400, Matt Porter wrote:
> l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
> early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
> platform to fail boot since they have their own pre l2x0 init sequence
> that is required. Fix this by checking that a matching OF ID is present
> before calling l2x0_of_init().
> 
> Reported-by: Kevin Hilman <khilman@linaro.org>
> Signed-off-by: Matt Porter <mporter@linaro.org>
> ---
> Applies against next-20140424 to fix the issue introduced in
> 50655e6 ARM: l2c: prima2: remove cache size override
> 
>  arch/arm/mach-prima2/l2x0.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-prima2/l2x0.c b/arch/arm/mach-prima2/l2x0.c
> index 09f68f0..1c2ed15 100644
> --- a/arch/arm/mach-prima2/l2x0.c
> +++ b/arch/arm/mach-prima2/l2x0.c
> @@ -8,10 +8,24 @@
>  
>  #include <linux/init.h>
>  #include <linux/kernel.h>
> +#include <linux/of.h>
>  #include <asm/hardware/cache-l2x0.h>
>  
> +static const struct of_device_id sirf_l2x0_ids[] __initconst = {
> +	{ .compatible = "sirf,prima2-pl310-cache" },
> +	{ .compatible = "sirf,marco-pl310-cache" },

that same commit removed these two from DTS, did you test with old DTS,
btw any chance ?
Matt Porter April 28, 2014, 2:37 p.m. | #4
On Mon, Apr 28, 2014 at 09:29:51AM -0500, Felipe Balbi wrote:
> On Sun, Apr 27, 2014 at 08:27:40PM -0400, Matt Porter wrote:
> > l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
> > early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
> > platform to fail boot since they have their own pre l2x0 init sequence
> > that is required. Fix this by checking that a matching OF ID is present
> > before calling l2x0_of_init().
> > 
> > Reported-by: Kevin Hilman <khilman@linaro.org>
> > Signed-off-by: Matt Porter <mporter@linaro.org>
> > ---
> > Applies against next-20140424 to fix the issue introduced in
> > 50655e6 ARM: l2c: prima2: remove cache size override
> > 
> >  arch/arm/mach-prima2/l2x0.c | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-prima2/l2x0.c b/arch/arm/mach-prima2/l2x0.c
> > index 09f68f0..1c2ed15 100644
> > --- a/arch/arm/mach-prima2/l2x0.c
> > +++ b/arch/arm/mach-prima2/l2x0.c
> > @@ -8,10 +8,24 @@
> >  
> >  #include <linux/init.h>
> >  #include <linux/kernel.h>
> > +#include <linux/of.h>
> >  #include <asm/hardware/cache-l2x0.h>
> >  
> > +static const struct of_device_id sirf_l2x0_ids[] __initconst = {
> > +	{ .compatible = "sirf,prima2-pl310-cache" },
> > +	{ .compatible = "sirf,marco-pl310-cache" },
> 
> that same commit removed these two from DTS, did you test with old DTS,
> btw any chance ?

The "fix" is tested against bcm281xx and bcm21664 as that is what the
l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
so this first attempt at a fix also breaks their platform. It can be
addressed by adding those platform specific compatibles back to the dts,
of course.

I'd much prefer that the sirfsoc folks fix this...it's going to break
other platforms in a multi v7 build.

-Matt
Russell King - ARM Linux April 28, 2014, 2:52 p.m. | #5
On Mon, Apr 28, 2014 at 10:37:09AM -0400, Matt Porter wrote:
> The "fix" is tested against bcm281xx and bcm21664 as that is what the
> l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
> so this first attempt at a fix also breaks their platform. It can be
> addressed by adding those platform specific compatibles back to the dts,
> of course.
> 
> I'd much prefer that the sirfsoc folks fix this...it's going to break
> other platforms in a multi v7 build.

Well, it's about time we got rid of this from platform specific code
anyway, taking it away from platform maintainers to mess around with.
So that's what I'm doing.

It's worth noting that if you build a single zImage with exynos also
enabled, then you also end up with an unconditional call from that
code to l2x0_of_init() with it's own magic numbers - and that applies
before my changes.

So let's fix this properly and yank this crap from platform maintainers
fingers.
Barry Song April 29, 2014, 3:05 p.m. | #6
2014-04-28 22:52 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Apr 28, 2014 at 10:37:09AM -0400, Matt Porter wrote:
>> The "fix" is tested against bcm281xx and bcm21664 as that is what the
>> l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
>> so this first attempt at a fix also breaks their platform. It can be
>> addressed by adding those platform specific compatibles back to the dts,
>> of course.
>>
>> I'd much prefer that the sirfsoc folks fix this...it's going to break
>> other platforms in a multi v7 build.
>
> Well, it's about time we got rid of this from platform specific code
> anyway, taking it away from platform maintainers to mess around with.
> So that's what I'm doing.
>
> It's worth noting that if you build a single zImage with exynos also
> enabled, then you also end up with an unconditional call from that
> code to l2x0_of_init() with it's own magic numbers - and that applies
> before my changes.
>
> So let's fix this properly and yank this crap from platform maintainers
> fingers.

i mentioned dropping specific dts compatible prop will break non-csr
platforms in the mail thread "ARM: prima2: remove L2 cache size
override" and i said i was going to send v2. you said you need it
before rc6. now it has been sent, but i am sorry it is not against
next-20140424.

>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Barry Song April 29, 2014, 3:10 p.m. | #7
2014-04-28 21:40 GMT+08:00 Matt Porter <mporter@linaro.org>:
> On Mon, Apr 28, 2014 at 10:15:33AM +0100, Russell King wrote:
>> On Sun, Apr 27, 2014 at 08:27:40PM -0400, Matt Porter wrote:
>> > l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
>> > early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
>> > platform to fail boot since they have their own pre l2x0 init sequence
>> > that is required. Fix this by checking that a matching OF ID is present
>> > before calling l2x0_of_init().
>> >
>> > Reported-by: Kevin Hilman <khilman@linaro.org>
>> > Signed-off-by: Matt Porter <mporter@linaro.org>
>> > ---
>> > Applies against next-20140424 to fix the issue introduced in
>> > 50655e6 ARM: l2c: prima2: remove cache size override
>>
>> Err, this only "fixes" it because it effectively disables the L2 cache
>> _entirely_ - in the above commit, I kill your private compatible strings.
>>
>> This doesn't make sense.  If the cache is already enabled, then the L2C
>> code won't try to enable it again.
>
> Ok, please suggest an alternative. You merged this commit..it looks like
> it had no ack from the platform maintainer..and I don't have hardware.
> The commit is wrong, we can't have every platform executing sirfsoc's
> l2x0_of_init() call/parameters by having this stuff in an early initcall
> like that.
>
> It would be pretty straightforward to add those private compatibles
> back so the approach works. If not, we need to move this to
> .init_machine where it's guaranteed to only run on sirfsoc.

these has been one V1 patch at
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/316312
my v2 has moved to init_irq() as Russell's suggestion.

>
> -Matt

-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Russell King - ARM Linux April 29, 2014, 3:14 p.m. | #8
On Tue, Apr 29, 2014 at 11:05:06PM +0800, Barry Song wrote:
> 2014-04-28 22:52 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Mon, Apr 28, 2014 at 10:37:09AM -0400, Matt Porter wrote:
> >> The "fix" is tested against bcm281xx and bcm21664 as that is what the
> >> l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
> >> so this first attempt at a fix also breaks their platform. It can be
> >> addressed by adding those platform specific compatibles back to the dts,
> >> of course.
> >>
> >> I'd much prefer that the sirfsoc folks fix this...it's going to break
> >> other platforms in a multi v7 build.
> >
> > Well, it's about time we got rid of this from platform specific code
> > anyway, taking it away from platform maintainers to mess around with.
> > So that's what I'm doing.
> >
> > It's worth noting that if you build a single zImage with exynos also
> > enabled, then you also end up with an unconditional call from that
> > code to l2x0_of_init() with it's own magic numbers - and that applies
> > before my changes.
> >
> > So let's fix this properly and yank this crap from platform maintainers
> > fingers.
> 
> i mentioned dropping specific dts compatible prop will break non-csr
> platforms in the mail thread "ARM: prima2: remove L2 cache size
> override" and i said i was going to send v2. you said you need it
> before rc6. now it has been sent, but i am sorry it is not against
> next-20140424.

FFS.  IT HASN'T BEEN SENT.  All that I did was drop it into linux-next
so that more people would get off their fat backsides and test this
fscking patch set - something which hasn't happened because no one
pays attention to emails sent to mailing lists.

I also told you that this was what I was going to do.  But... is it
really on to hold up such a large patch set which impacts virtually
everyone because _you_ don't have time to sort out your small special
requirements - no it is not, that's just fscking selfish.

Anyway, I've had it with dealing with platform maintainers, I've yanked
this patch set, and I'm no longer planning to do anything with it -
platform maintainers have destroyed my will to get any of this series
into the kernel.

So, the L2 cache code is going to remain in its current state, and it's
going to rot because it's _FAR_ too much effort dealing with slow people
like yourselves, or people who want the series split up, or people who
whinge that there aren't any acks there (WELL GET OFF YOUR FAT BACKSIDES
AND SEND ME SOME IF YOU CARE ABOUT THIS - no, don't, I'm no longer pushing
this series.)

This is the last time I'm going to ever try cleaning up any core ARM code.
Core ARM maintanence is impossible in this environment with arm-soc split
from core ARM stuff, because core ARM stuff /always/ impacts on SoC
specific code.  You can't get away from that.

My position in this community has been made impossible and obsolete by
Linaro.  I'm at the point of walking away from this crap.
Barry Song April 29, 2014, 3:40 p.m. | #9
2014-04-29 23:14 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Tue, Apr 29, 2014 at 11:05:06PM +0800, Barry Song wrote:
>> 2014-04-28 22:52 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> > On Mon, Apr 28, 2014 at 10:37:09AM -0400, Matt Porter wrote:
>> >> The "fix" is tested against bcm281xx and bcm21664 as that is what the
>> >> l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
>> >> so this first attempt at a fix also breaks their platform. It can be
>> >> addressed by adding those platform specific compatibles back to the dts,
>> >> of course.
>> >>
>> >> I'd much prefer that the sirfsoc folks fix this...it's going to break
>> >> other platforms in a multi v7 build.
>> >
>> > Well, it's about time we got rid of this from platform specific code
>> > anyway, taking it away from platform maintainers to mess around with.
>> > So that's what I'm doing.
>> >
>> > It's worth noting that if you build a single zImage with exynos also
>> > enabled, then you also end up with an unconditional call from that
>> > code to l2x0_of_init() with it's own magic numbers - and that applies
>> > before my changes.
>> >
>> > So let's fix this properly and yank this crap from platform maintainers
>> > fingers.
>>
>> i mentioned dropping specific dts compatible prop will break non-csr
>> platforms in the mail thread "ARM: prima2: remove L2 cache size
>> override" and i said i was going to send v2. you said you need it
>> before rc6. now it has been sent, but i am sorry it is not against
>> next-20140424.
>
> FFS.  IT HASN'T BEEN SENT.  All that I did was drop it into linux-next
> so that more people would get off their fat backsides and test this
> fscking patch set - something which hasn't happened because no one
> pays attention to emails sent to mailing lists.

so your point is people don't pay attention to your mails? or you are
ignored? i think that is 100% not real. i think your opinions and
mails are always respected as you are the chief arm linux expert.

>
> I also told you that this was what I was going to do.  But... is it
> really on to hold up such a large patch set which impacts virtually
> everyone because _you_ don't have time to sort out your small special
> requirements - no it is not, that's just fscking selfish.
>
> Anyway, I've had it with dealing with platform maintainers, I've yanked
> this patch set, and I'm no longer planning to do anything with it -
> platform maintainers have destroyed my will to get any of this series
> into the kernel.

no, i am trying to follow your suggestion to make patch set merged and
l2 codes cleaned.
i have been trying to follow your will until now, and from the beginning.

>
> So, the L2 cache code is going to remain in its current state, and it's
> going to rot because it's _FAR_ too much effort dealing with slow people
> like yourselves, or people who want the series split up, or people who
> whinge that there aren't any acks there (WELL GET OFF YOUR FAT BACKSIDES
> AND SEND ME SOME IF YOU CARE ABOUT THIS - no, don't, I'm no longer pushing
> this series.)

people might be "selfish", but people might have some reasons to
response slowly, like holiday or family issue.
how about taking it easy? it doesn't prove you are not respected by
platform maintainers.

>
> This is the last time I'm going to ever try cleaning up any core ARM code.
> Core ARM maintanence is impossible in this environment with arm-soc split
> from core ARM stuff, because core ARM stuff /always/ impacts on SoC
> specific code.  You can't get away from that.
>
> My position in this community has been made impossible and obsolete by
> Linaro.  I'm at the point of walking away from this crap.

just fix the relationship and communication, that is good enough. you
have done things so well, there is no reason to give up.

>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Russell King - ARM Linux May 22, 2014, 9:33 a.m. | #10
On Tue, Apr 29, 2014 at 11:40:33PM +0800, Barry Song wrote:
> 2014-04-29 23:14 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Tue, Apr 29, 2014 at 11:05:06PM +0800, Barry Song wrote:
> >> 2014-04-28 22:52 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> >> > On Mon, Apr 28, 2014 at 10:37:09AM -0400, Matt Porter wrote:
> >> >> The "fix" is tested against bcm281xx and bcm21664 as that is what the
> >> >> l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
> >> >> so this first attempt at a fix also breaks their platform. It can be
> >> >> addressed by adding those platform specific compatibles back to the dts,
> >> >> of course.
> >> >>
> >> >> I'd much prefer that the sirfsoc folks fix this...it's going to break
> >> >> other platforms in a multi v7 build.
> >> >
> >> > Well, it's about time we got rid of this from platform specific code
> >> > anyway, taking it away from platform maintainers to mess around with.
> >> > So that's what I'm doing.
> >> >
> >> > It's worth noting that if you build a single zImage with exynos also
> >> > enabled, then you also end up with an unconditional call from that
> >> > code to l2x0_of_init() with it's own magic numbers - and that applies
> >> > before my changes.
> >> >
> >> > So let's fix this properly and yank this crap from platform maintainers
> >> > fingers.
> >>
> >> i mentioned dropping specific dts compatible prop will break non-csr
> >> platforms in the mail thread "ARM: prima2: remove L2 cache size
> >> override" and i said i was going to send v2. you said you need it
> >> before rc6. now it has been sent, but i am sorry it is not against
> >> next-20140424.
> >
> > FFS.  IT HASN'T BEEN SENT.  All that I did was drop it into linux-next
> > so that more people would get off their fat backsides and test this
> > fscking patch set - something which hasn't happened because no one
> > pays attention to emails sent to mailing lists.
> 
> so your point is people don't pay attention to your mails? or you are
> ignored? i think that is 100% not real. i think your opinions and
> mails are always respected as you are the chief arm linux expert.
> 
> >
> > I also told you that this was what I was going to do.  But... is it
> > really on to hold up such a large patch set which impacts virtually
> > everyone because _you_ don't have time to sort out your small special
> > requirements - no it is not, that's just fscking selfish.
> >
> > Anyway, I've had it with dealing with platform maintainers, I've yanked
> > this patch set, and I'm no longer planning to do anything with it -
> > platform maintainers have destroyed my will to get any of this series
> > into the kernel.
> 
> no, i am trying to follow your suggestion to make patch set merged and
> l2 codes cleaned.
> i have been trying to follow your will until now, and from the beginning.
> 
> >
> > So, the L2 cache code is going to remain in its current state, and it's
> > going to rot because it's _FAR_ too much effort dealing with slow people
> > like yourselves, or people who want the series split up, or people who
> > whinge that there aren't any acks there (WELL GET OFF YOUR FAT BACKSIDES
> > AND SEND ME SOME IF YOU CARE ABOUT THIS - no, don't, I'm no longer pushing
> > this series.)
> 
> people might be "selfish", but people might have some reasons to
> response slowly, like holiday or family issue.
> how about taking it easy? it doesn't prove you are not respected by
> platform maintainers.
> 
> >
> > This is the last time I'm going to ever try cleaning up any core ARM code.
> > Core ARM maintanence is impossible in this environment with arm-soc split
> > from core ARM stuff, because core ARM stuff /always/ impacts on SoC
> > specific code.  You can't get away from that.
> >
> > My position in this community has been made impossible and obsolete by
> > Linaro.  I'm at the point of walking away from this crap.
> 
> just fix the relationship and communication, that is good enough. you
> have done things so well, there is no reason to give up.

So, just as I thought...

-rc6 has now been released, and YOU have done NOTHING to resolve any of
the issues you have with this patch set - which is precisely on track
with how you have behaved towards this set of changes on the past - where
you promised imformation/patches and never delivered.

Well, right now I'm just not going to *care* one bit about Prima2.  If
this patch set breaks it, tough.  You've had plenty of opportunity to
deal with this, but instead you've chosen to just whinge about it and
then do precisely nothing to assist.

So, Prima2 *is* going to get *broken*.  No platform or SoC is important
enough to stand in the way of core ARM changes beneficial to the rest of
the community.

We've lost around 4 weeks testing time in linux-next because of this...
frankly I don't give a damn right now, all I care about is getting these
patches out of my tree and into mainline during the next merge window.
Any issues that come up can be debugged and fixed afterwards - and the
debugging *has* to be done by the SoC people because I don't have any
way to test and debug it on individual SoCs.  (And Olof's test farm is
not sufficient for diagnosis.)
Barry Song May 22, 2014, 11:04 a.m. | #11
2014-05-22 17:33 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Tue, Apr 29, 2014 at 11:40:33PM +0800, Barry Song wrote:
>> 2014-04-29 23:14 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> > On Tue, Apr 29, 2014 at 11:05:06PM +0800, Barry Song wrote:
>> >> 2014-04-28 22:52 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> >> > On Mon, Apr 28, 2014 at 10:37:09AM -0400, Matt Porter wrote:
>> >> >> The "fix" is tested against bcm281xx and bcm21664 as that is what the
>> >> >> l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
>> >> >> so this first attempt at a fix also breaks their platform. It can be
>> >> >> addressed by adding those platform specific compatibles back to the dts,
>> >> >> of course.
>> >> >>
>> >> >> I'd much prefer that the sirfsoc folks fix this...it's going to break
>> >> >> other platforms in a multi v7 build.
>> >> >
>> >> > Well, it's about time we got rid of this from platform specific code
>> >> > anyway, taking it away from platform maintainers to mess around with.
>> >> > So that's what I'm doing.
>> >> >
>> >> > It's worth noting that if you build a single zImage with exynos also
>> >> > enabled, then you also end up with an unconditional call from that
>> >> > code to l2x0_of_init() with it's own magic numbers - and that applies
>> >> > before my changes.
>> >> >
>> >> > So let's fix this properly and yank this crap from platform maintainers
>> >> > fingers.
>> >>
>> >> i mentioned dropping specific dts compatible prop will break non-csr
>> >> platforms in the mail thread "ARM: prima2: remove L2 cache size
>> >> override" and i said i was going to send v2. you said you need it
>> >> before rc6. now it has been sent, but i am sorry it is not against
>> >> next-20140424.
>> >
>> > FFS.  IT HASN'T BEEN SENT.  All that I did was drop it into linux-next
>> > so that more people would get off their fat backsides and test this
>> > fscking patch set - something which hasn't happened because no one
>> > pays attention to emails sent to mailing lists.
>>
>> so your point is people don't pay attention to your mails? or you are
>> ignored? i think that is 100% not real. i think your opinions and
>> mails are always respected as you are the chief arm linux expert.
>>
>> >
>> > I also told you that this was what I was going to do.  But... is it
>> > really on to hold up such a large patch set which impacts virtually
>> > everyone because _you_ don't have time to sort out your small special
>> > requirements - no it is not, that's just fscking selfish.
>> >
>> > Anyway, I've had it with dealing with platform maintainers, I've yanked
>> > this patch set, and I'm no longer planning to do anything with it -
>> > platform maintainers have destroyed my will to get any of this series
>> > into the kernel.
>>
>> no, i am trying to follow your suggestion to make patch set merged and
>> l2 codes cleaned.
>> i have been trying to follow your will until now, and from the beginning.
>>
>> >
>> > So, the L2 cache code is going to remain in its current state, and it's
>> > going to rot because it's _FAR_ too much effort dealing with slow people
>> > like yourselves, or people who want the series split up, or people who
>> > whinge that there aren't any acks there (WELL GET OFF YOUR FAT BACKSIDES
>> > AND SEND ME SOME IF YOU CARE ABOUT THIS - no, don't, I'm no longer pushing
>> > this series.)
>>
>> people might be "selfish", but people might have some reasons to
>> response slowly, like holiday or family issue.
>> how about taking it easy? it doesn't prove you are not respected by
>> platform maintainers.
>>
>> >
>> > This is the last time I'm going to ever try cleaning up any core ARM code.
>> > Core ARM maintanence is impossible in this environment with arm-soc split
>> > from core ARM stuff, because core ARM stuff /always/ impacts on SoC
>> > specific code.  You can't get away from that.
>> >
>> > My position in this community has been made impossible and obsolete by
>> > Linaro.  I'm at the point of walking away from this crap.
>>
>> just fix the relationship and communication, that is good enough. you
>> have done things so well, there is no reason to give up.
>
> So, just as I thought...
>
> -rc6 has now been released, and YOU have done NOTHING to resolve any of
> the issues you have with this patch set - which is precisely on track
> with how you have behaved towards this set of changes on the past - where
> you promised imformation/patches and never delivered.
>
> Well, right now I'm just not going to *care* one bit about Prima2.  If
> this patch set breaks it, tough.  You've had plenty of opportunity to
> deal with this, but instead you've chosen to just whinge about it and
> then do precisely nothing to assist.

i have no idea why you are saying this. if you checked the email, i
have sent a patch in last month.

http://www.spinics.net/lists/arm-kernel/msg327151.html

but i got no reply and you said you will not handle l2....

>
> So, Prima2 *is* going to get *broken*.  No platform or SoC is important
> enough to stand in the way of core ARM changes beneficial to the rest of
> the community.
>
> We've lost around 4 weeks testing time in linux-next because of this...
> frankly I don't give a damn right now, all I care about is getting these
> patches out of my tree and into mainline during the next merge window.
> Any issues that come up can be debugged and fixed afterwards - and the
> debugging *has* to be done by the SoC people because I don't have any
> way to test and debug it on individual SoCs.  (And Olof's test farm is
> not sufficient for diagnosis.)
>


-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Russell King - ARM Linux May 22, 2014, 11:27 a.m. | #12
On Thu, May 22, 2014 at 07:04:14PM +0800, Barry Song wrote:
> 2014-05-22 17:33 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Tue, Apr 29, 2014 at 11:40:33PM +0800, Barry Song wrote:
> >> 2014-04-29 23:14 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> >> > On Tue, Apr 29, 2014 at 11:05:06PM +0800, Barry Song wrote:
> >> >> 2014-04-28 22:52 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> >> >> > On Mon, Apr 28, 2014 at 10:37:09AM -0400, Matt Porter wrote:
> >> >> >> The "fix" is tested against bcm281xx and bcm21664 as that is what the
> >> >> >> l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
> >> >> >> so this first attempt at a fix also breaks their platform. It can be
> >> >> >> addressed by adding those platform specific compatibles back to the dts,
> >> >> >> of course.
> >> >> >>
> >> >> >> I'd much prefer that the sirfsoc folks fix this...it's going to break
> >> >> >> other platforms in a multi v7 build.
> >> >> >
> >> >> > Well, it's about time we got rid of this from platform specific code
> >> >> > anyway, taking it away from platform maintainers to mess around with.
> >> >> > So that's what I'm doing.
> >> >> >
> >> >> > It's worth noting that if you build a single zImage with exynos also
> >> >> > enabled, then you also end up with an unconditional call from that
> >> >> > code to l2x0_of_init() with it's own magic numbers - and that applies
> >> >> > before my changes.
> >> >> >
> >> >> > So let's fix this properly and yank this crap from platform maintainers
> >> >> > fingers.
> >> >>
> >> >> i mentioned dropping specific dts compatible prop will break non-csr
> >> >> platforms in the mail thread "ARM: prima2: remove L2 cache size
> >> >> override" and i said i was going to send v2. you said you need it
> >> >> before rc6. now it has been sent, but i am sorry it is not against
> >> >> next-20140424.
> >> >
> >> > FFS.  IT HASN'T BEEN SENT.  All that I did was drop it into linux-next
> >> > so that more people would get off their fat backsides and test this
> >> > fscking patch set - something which hasn't happened because no one
> >> > pays attention to emails sent to mailing lists.
> >>
> >> so your point is people don't pay attention to your mails? or you are
> >> ignored? i think that is 100% not real. i think your opinions and
> >> mails are always respected as you are the chief arm linux expert.
> >>
> >> >
> >> > I also told you that this was what I was going to do.  But... is it
> >> > really on to hold up such a large patch set which impacts virtually
> >> > everyone because _you_ don't have time to sort out your small special
> >> > requirements - no it is not, that's just fscking selfish.
> >> >
> >> > Anyway, I've had it with dealing with platform maintainers, I've yanked
> >> > this patch set, and I'm no longer planning to do anything with it -
> >> > platform maintainers have destroyed my will to get any of this series
> >> > into the kernel.
> >>
> >> no, i am trying to follow your suggestion to make patch set merged and
> >> l2 codes cleaned.
> >> i have been trying to follow your will until now, and from the beginning.
> >>
> >> >
> >> > So, the L2 cache code is going to remain in its current state, and it's
> >> > going to rot because it's _FAR_ too much effort dealing with slow people
> >> > like yourselves, or people who want the series split up, or people who
> >> > whinge that there aren't any acks there (WELL GET OFF YOUR FAT BACKSIDES
> >> > AND SEND ME SOME IF YOU CARE ABOUT THIS - no, don't, I'm no longer pushing
> >> > this series.)
> >>
> >> people might be "selfish", but people might have some reasons to
> >> response slowly, like holiday or family issue.
> >> how about taking it easy? it doesn't prove you are not respected by
> >> platform maintainers.
> >>
> >> >
> >> > This is the last time I'm going to ever try cleaning up any core ARM code.
> >> > Core ARM maintanence is impossible in this environment with arm-soc split
> >> > from core ARM stuff, because core ARM stuff /always/ impacts on SoC
> >> > specific code.  You can't get away from that.
> >> >
> >> > My position in this community has been made impossible and obsolete by
> >> > Linaro.  I'm at the point of walking away from this crap.
> >>
> >> just fix the relationship and communication, that is good enough. you
> >> have done things so well, there is no reason to give up.
> >
> > So, just as I thought...
> >
> > -rc6 has now been released, and YOU have done NOTHING to resolve any of
> > the issues you have with this patch set - which is precisely on track
> > with how you have behaved towards this set of changes on the past - where
> > you promised imformation/patches and never delivered.
> >
> > Well, right now I'm just not going to *care* one bit about Prima2.  If
> > this patch set breaks it, tough.  You've had plenty of opportunity to
> > deal with this, but instead you've chosen to just whinge about it and
> > then do precisely nothing to assist.
> 
> i have no idea why you are saying this. if you checked the email, i
> have sent a patch in last month.
> 
> http://www.spinics.net/lists/arm-kernel/msg327151.html
> 
> but i got no reply and you said you will not handle l2....

I said I won't deal with this patch set anymore because I got *thoroughly*
frustrated with you and the lack of cooperation from many of the SoC people.
It seems that the only way to get things done around here is to railroad
them into linux-next and wait for people to notice the changes.  That's
really not an acceptable way of doing development, but it's the *only*
one which gets people's attention.  Sending emails does not work, because
people ignore them.

Moreover, your patch is a total rewrite of several of my patches, and is
not an incremental set of changes.  Given that my patch set which was last
posted has the SoC changes done incrementally amongst the other changes,
this is just not an acceptable approach, so frankly the patch is useless
to me.
Barry Song May 22, 2014, 11:39 a.m. | #13
2014-05-22 19:27 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Thu, May 22, 2014 at 07:04:14PM +0800, Barry Song wrote:
>> 2014-05-22 17:33 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> > On Tue, Apr 29, 2014 at 11:40:33PM +0800, Barry Song wrote:
>> >> 2014-04-29 23:14 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> >> > On Tue, Apr 29, 2014 at 11:05:06PM +0800, Barry Song wrote:
>> >> >> 2014-04-28 22:52 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> >> >> > On Mon, Apr 28, 2014 at 10:37:09AM -0400, Matt Porter wrote:
>> >> >> >> The "fix" is tested against bcm281xx and bcm21664 as that is what the
>> >> >> >> l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
>> >> >> >> so this first attempt at a fix also breaks their platform. It can be
>> >> >> >> addressed by adding those platform specific compatibles back to the dts,
>> >> >> >> of course.
>> >> >> >>
>> >> >> >> I'd much prefer that the sirfsoc folks fix this...it's going to break
>> >> >> >> other platforms in a multi v7 build.
>> >> >> >
>> >> >> > Well, it's about time we got rid of this from platform specific code
>> >> >> > anyway, taking it away from platform maintainers to mess around with.
>> >> >> > So that's what I'm doing.
>> >> >> >
>> >> >> > It's worth noting that if you build a single zImage with exynos also
>> >> >> > enabled, then you also end up with an unconditional call from that
>> >> >> > code to l2x0_of_init() with it's own magic numbers - and that applies
>> >> >> > before my changes.
>> >> >> >
>> >> >> > So let's fix this properly and yank this crap from platform maintainers
>> >> >> > fingers.
>> >> >>
>> >> >> i mentioned dropping specific dts compatible prop will break non-csr
>> >> >> platforms in the mail thread "ARM: prima2: remove L2 cache size
>> >> >> override" and i said i was going to send v2. you said you need it
>> >> >> before rc6. now it has been sent, but i am sorry it is not against
>> >> >> next-20140424.
>> >> >
>> >> > FFS.  IT HASN'T BEEN SENT.  All that I did was drop it into linux-next
>> >> > so that more people would get off their fat backsides and test this
>> >> > fscking patch set - something which hasn't happened because no one
>> >> > pays attention to emails sent to mailing lists.
>> >>
>> >> so your point is people don't pay attention to your mails? or you are
>> >> ignored? i think that is 100% not real. i think your opinions and
>> >> mails are always respected as you are the chief arm linux expert.
>> >>
>> >> >
>> >> > I also told you that this was what I was going to do.  But... is it
>> >> > really on to hold up such a large patch set which impacts virtually
>> >> > everyone because _you_ don't have time to sort out your small special
>> >> > requirements - no it is not, that's just fscking selfish.
>> >> >
>> >> > Anyway, I've had it with dealing with platform maintainers, I've yanked
>> >> > this patch set, and I'm no longer planning to do anything with it -
>> >> > platform maintainers have destroyed my will to get any of this series
>> >> > into the kernel.
>> >>
>> >> no, i am trying to follow your suggestion to make patch set merged and
>> >> l2 codes cleaned.
>> >> i have been trying to follow your will until now, and from the beginning.
>> >>
>> >> >
>> >> > So, the L2 cache code is going to remain in its current state, and it's
>> >> > going to rot because it's _FAR_ too much effort dealing with slow people
>> >> > like yourselves, or people who want the series split up, or people who
>> >> > whinge that there aren't any acks there (WELL GET OFF YOUR FAT BACKSIDES
>> >> > AND SEND ME SOME IF YOU CARE ABOUT THIS - no, don't, I'm no longer pushing
>> >> > this series.)
>> >>
>> >> people might be "selfish", but people might have some reasons to
>> >> response slowly, like holiday or family issue.
>> >> how about taking it easy? it doesn't prove you are not respected by
>> >> platform maintainers.
>> >>
>> >> >
>> >> > This is the last time I'm going to ever try cleaning up any core ARM code.
>> >> > Core ARM maintanence is impossible in this environment with arm-soc split
>> >> > from core ARM stuff, because core ARM stuff /always/ impacts on SoC
>> >> > specific code.  You can't get away from that.
>> >> >
>> >> > My position in this community has been made impossible and obsolete by
>> >> > Linaro.  I'm at the point of walking away from this crap.
>> >>
>> >> just fix the relationship and communication, that is good enough. you
>> >> have done things so well, there is no reason to give up.
>> >
>> > So, just as I thought...
>> >
>> > -rc6 has now been released, and YOU have done NOTHING to resolve any of
>> > the issues you have with this patch set - which is precisely on track
>> > with how you have behaved towards this set of changes on the past - where
>> > you promised imformation/patches and never delivered.
>> >
>> > Well, right now I'm just not going to *care* one bit about Prima2.  If
>> > this patch set breaks it, tough.  You've had plenty of opportunity to
>> > deal with this, but instead you've chosen to just whinge about it and
>> > then do precisely nothing to assist.
>>
>> i have no idea why you are saying this. if you checked the email, i
>> have sent a patch in last month.
>>
>> http://www.spinics.net/lists/arm-kernel/msg327151.html
>>
>> but i got no reply and you said you will not handle l2....
>
> I said I won't deal with this patch set anymore because I got *thoroughly*
> frustrated with you and the lack of cooperation from many of the SoC people.
> It seems that the only way to get things done around here is to railroad
> them into linux-next and wait for people to notice the changes.  That's
> really not an acceptable way of doing development, but it's the *only*
> one which gets people's attention.  Sending emails does not work, because
> people ignore them.
>
> Moreover, your patch is a total rewrite of several of my patches, and is
> not an incremental set of changes.  Given that my patch set which was last
> posted has the SoC changes done incrementally amongst the other changes,
> this is just not an acceptable approach, so frankly the patch is useless
> to me.

in v1, you suggested me moving l2x0_init to init_irq, right? so this
was done five days after your suggestion. but you choiced to ignore it
and didn't say your real intention to me. i am a completely stupid man
and i can't figure out what is your final choice if you didn't say
anything and just complained stupid man like me didn't assist you.

if the information you wanted from me is

+       .l2c_aux_val
+       .l2c_aux_mask

it is clear that my v1 and v2 have exposed enought information for
that. why are you saying i didn't provide information to you?

i have no idea what has been happening for the whole thing. i was
asked to one thing in one way, then after one month, i was told it is
useless.  i am totally confused.

>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch

diff --git a/arch/arm/mach-prima2/l2x0.c b/arch/arm/mach-prima2/l2x0.c
index 09f68f0..1c2ed15 100644
--- a/arch/arm/mach-prima2/l2x0.c
+++ b/arch/arm/mach-prima2/l2x0.c
@@ -8,10 +8,24 @@ 
 
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/of.h>
 #include <asm/hardware/cache-l2x0.h>
 
+static const struct of_device_id sirf_l2x0_ids[] __initconst = {
+	{ .compatible = "sirf,prima2-pl310-cache" },
+	{ .compatible = "sirf,marco-pl310-cache" },
+	{},
+};
+
 static int __init sirfsoc_l2x0_init(void)
 {
-	return l2x0_of_init(0, ~0);
+	struct device_node *np;
+	int ret = -EINVAL;
+
+	np = of_find_matching_node(NULL, sirf_l2x0_ids);
+	if (np)
+		ret = l2x0_of_init(0, ~0);
+
+	return ret;
 }
 early_initcall(sirfsoc_l2x0_init);