diff mbox

[v2,1/2] arm64: dts: zx: Fix gic GICR property

Message ID 1476361881-19685-2-git-send-email-jun.nie@linaro.org (mailing list archive)
State New, archived
Headers show

Commit Message

Jun Nie Oct. 13, 2016, 12:31 p.m. UTC
GICR for multiple CPU can be described with start address and stride,
or with multiple address. Current multiple address and stride are
both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:
[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5

Signed-off-by: Jun Nie <jun.nie@linaro.org>
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

Comments

Olof Johansson Oct. 17, 2016, 8:49 p.m. UTC | #1
On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
> GICR for multiple CPU can be described with start address and stride,
> or with multiple address. Current multiple address and stride are
> both used. Fix it.
> 
> vmalloc patch 727a7f5a9 triggered this bug:
> [    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> [    0.097150] pgd = ffff000008602000
> [    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> [    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> [    0.097170] Modules linked in:
> [    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> [    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> [    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> [    0.097197] PC is at gic_populate_rdist+0x74/0x15c
> [    0.097202] LR is at gic_starting_cpu+0xc/0x20
> [    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> 
> Signed-off-by: Jun Nie <jun.nie@linaro.org>

A Fixes: tag would be useful on a patch like this, to tell what patch
introduced the problem. Please consider using them in the future.

I've applied this one to fixes now.


-Olof
Arnd Bergmann Nov. 25, 2016, 10:03 p.m. UTC | #2
On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
> > GICR for multiple CPU can be described with start address and stride,
> > or with multiple address. Current multiple address and stride are
> > both used. Fix it.
> > 
> > vmalloc patch 727a7f5a9 triggered this bug:
> > [    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> > [    0.097150] pgd = ffff000008602000
> > [    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> > [    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > [    0.097170] Modules linked in:
> > [    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> > [    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> > [    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> > [    0.097197] PC is at gic_populate_rdist+0x74/0x15c
> > [    0.097202] LR is at gic_starting_cpu+0xc/0x20
> > [    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> > 
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> 
> A Fixes: tag would be useful on a patch like this, to tell what patch
> introduced the problem. Please consider using them in the future.
> 
> I've applied this one to fixes now.

Hi Olof,

I happened to still have this one in my todo folder as I must have
missed your reply, and I stumbled over it while looking for things
that may have gone missing.

I don't see it in v4.9-rc6, did it get dropped accidentally?

	Arnd
Shawn Guo Nov. 28, 2016, 2:08 p.m. UTC | #3
On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
>> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
>> > GICR for multiple CPU can be described with start address and stride,
>> > or with multiple address. Current multiple address and stride are
>> > both used. Fix it.
>> >
>> > vmalloc patch 727a7f5a9 triggered this bug:
>> > [    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
>> > [    0.097150] pgd = ffff000008602000
>> > [    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
>> > [    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
>> > [    0.097170] Modules linked in:
>> > [    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
>> > [    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
>> > [    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
>> > [    0.097197] PC is at gic_populate_rdist+0x74/0x15c
>> > [    0.097202] LR is at gic_starting_cpu+0xc/0x20
>> > [    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
>> >
>> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
>>
>> A Fixes: tag would be useful on a patch like this, to tell what patch
>> introduced the problem. Please consider using them in the future.
>>
>> I've applied this one to fixes now.
>
> Hi Olof,
>
> I happened to still have this one in my todo folder as I must have
> missed your reply, and I stumbled over it while looking for things
> that may have gone missing.
>
> I don't see it in v4.9-rc6, did it get dropped accidentally?

Please help get this into v4.9 if possible, as it is required to get
v4.9 kernel boot up on ZTE ZX296718 SoC.  Thanks.

Shawn
Arnd Bergmann Dec. 2, 2016, 4:38 p.m. UTC | #4
On Monday, November 28, 2016 10:08:18 PM CET Shawn Guo wrote:
> On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
> >> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
> >> > GICR for multiple CPU can be described with start address and stride,
> >> > or with multiple address. Current multiple address and stride are
> >> > both used. Fix it.
> >> >
> >> > vmalloc patch 727a7f5a9 triggered this bug:
> >> > [    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> >> > [    0.097150] pgd = ffff000008602000
> >> > [    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> >> > [    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> >> > [    0.097170] Modules linked in:
> >> > [    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> >> > [    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> >> > [    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> >> > [    0.097197] PC is at gic_populate_rdist+0x74/0x15c
> >> > [    0.097202] LR is at gic_starting_cpu+0xc/0x20
> >> > [    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> >> >
> >> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> >>
> >> A Fixes: tag would be useful on a patch like this, to tell what patch
> >> introduced the problem. Please consider using them in the future.
> >>
> >> I've applied this one to fixes now.
> >
> > Hi Olof,
> >
> > I happened to still have this one in my todo folder as I must have
> > missed your reply, and I stumbled over it while looking for things
> > that may have gone missing.
> >
> > I don't see it in v4.9-rc6, did it get dropped accidentally?
> 
> Please help get this into v4.9 if possible, as it is required to get
> v4.9 kernel boot up on ZTE ZX296718 SoC.  Thanks.
> 
> Shawn
> 

Ok, applied both. Thanks,

	Arnd
Marc Zyngier Dec. 2, 2016, 5:02 p.m. UTC | #5
Just noticed this.

On 13/10/16 13:31, Jun Nie wrote:
> GICR for multiple CPU can be described with start address and stride,
> or with multiple address. Current multiple address and stride are
> both used. Fix it.
> 
> vmalloc patch 727a7f5a9 triggered this bug:
> [    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> [    0.097150] pgd = ffff000008602000
> [    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> [    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> [    0.097170] Modules linked in:
> [    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> [    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> [    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> [    0.097197] PC is at gic_populate_rdist+0x74/0x15c
> [    0.097202] LR is at gic_starting_cpu+0xc/0x20
> [    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> 
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
>  arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> index a223066..6b239a3 100644
> --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> @@ -239,16 +239,11 @@
>  		compatible = "arm,gic-v3";
>  		#interrupt-cells = <3>;
>  		#address-cells = <0>;
> -		#redistributor-regions = <6>;
> -		redistributor-stride = <0x0 0x40000>;
> +		#redistributor-regions = <1>;
> +		redistributor-stride = <0x20000>;

Why is that stride specified? Is the GIC implementation so busted that
the GICR_TYPER do not report a GICv3 redistributor, which implies a
128kB stride?

Thanks,

	M.
Arnd Bergmann Dec. 2, 2016, 8:28 p.m. UTC | #6
On Friday, December 2, 2016 5:02:28 PM CET Marc Zyngier wrote:
> On 13/10/16 13:31, Jun Nie wrote:
> > GICR for multiple CPU can be described with start address and stride,
> > or with multiple address. Current multiple address and stride are
> > both used. Fix it.
> > 
> > vmalloc patch 727a7f5a9 triggered this bug:
> > [    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> > [    0.097150] pgd = ffff000008602000
> > [    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> > [    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > [    0.097170] Modules linked in:
> > [    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> > [    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> > [    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> > [    0.097197] PC is at gic_populate_rdist+0x74/0x15c
> > [    0.097202] LR is at gic_starting_cpu+0xc/0x20
> > [    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> > 
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > ---
> >  arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
> >  1 file changed, 3 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> > index a223066..6b239a3 100644
> > --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> > +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> > @@ -239,16 +239,11 @@
> >               compatible = "arm,gic-v3";
> >               #interrupt-cells = <3>;
> >               #address-cells = <0>;
> > -             #redistributor-regions = <6>;
> > -             redistributor-stride = <0x0 0x40000>;
> > +             #redistributor-regions = <1>;
> > +             redistributor-stride = <0x20000>;
> 
> Why is that stride specified? Is the GIC implementation so busted that
> the GICR_TYPER do not report a GICv3 redistributor, which implies a
> 128kB stride?

Given that there is any concern about the patch now, and the merge
window is almost open, I'm moving both patches to the
next/fixes-non-critical branch and will merge it for v4.10 instead
of sending it for v4.9.

If you end up deciding that the patch is wrong, please follow up
with a fix on top. Once the situation is resolved and the patch
merged upstream, feel free to ask stable@vger.kernel.org for a
backport to stable kernels to get it into v4.9.x.

	Arnd
Shawn Guo Dec. 3, 2016, 9:22 a.m. UTC | #7
On Fri, Dec 02, 2016 at 05:02:28PM +0000, Marc Zyngier wrote:
> Just noticed this.
> 
> On 13/10/16 13:31, Jun Nie wrote:
> > GICR for multiple CPU can be described with start address and stride,
> > or with multiple address. Current multiple address and stride are
> > both used. Fix it.
> > 
> > vmalloc patch 727a7f5a9 triggered this bug:
> > [    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> > [    0.097150] pgd = ffff000008602000
> > [    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> > [    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > [    0.097170] Modules linked in:
> > [    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> > [    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> > [    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> > [    0.097197] PC is at gic_populate_rdist+0x74/0x15c
> > [    0.097202] LR is at gic_starting_cpu+0xc/0x20
> > [    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> > 
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > ---
> >  arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
> >  1 file changed, 3 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> > index a223066..6b239a3 100644
> > --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> > +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> > @@ -239,16 +239,11 @@
> >  		compatible = "arm,gic-v3";
> >  		#interrupt-cells = <3>;
> >  		#address-cells = <0>;
> > -		#redistributor-regions = <6>;
> > -		redistributor-stride = <0x0 0x40000>;
> > +		#redistributor-regions = <1>;
> > +		redistributor-stride = <0x20000>;
> 
> Why is that stride specified? Is the GIC implementation so busted that
> the GICR_TYPER do not report a GICv3 redistributor, which implies a
> 128kB stride?

No, it's not required per my testing.  I guess it's there for
documentation purpose to make the stride setting explicit.  Are you
suggesting that we simply drop it?

Also, it seems that #redistributor-regions can also be saved, since
bindings doc tells that it's only required if more than one such region
is present?

Shawn
Marc Zyngier Dec. 3, 2016, 10:11 a.m. UTC | #8
On Sat, Dec 03 2016 at 09:22:55 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> On Fri, Dec 02, 2016 at 05:02:28PM +0000, Marc Zyngier wrote:
>> Just noticed this.
>> 
>> On 13/10/16 13:31, Jun Nie wrote:
>> > GICR for multiple CPU can be described with start address and stride,
>> > or with multiple address. Current multiple address and stride are
>> > both used. Fix it.
>> > 
>> > vmalloc patch 727a7f5a9 triggered this bug:
>> > [    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
>> > [    0.097150] pgd = ffff000008602000
>> > [    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
>> > [    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
>> > [    0.097170] Modules linked in:
>> > [    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
>> > [    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
>> > [    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
>> > [    0.097197] PC is at gic_populate_rdist+0x74/0x15c
>> > [    0.097202] LR is at gic_starting_cpu+0xc/0x20
>> > [    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
>> > 
>> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
>> > ---
>> >  arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
>> >  1 file changed, 3 insertions(+), 8 deletions(-)
>> > 
>> > diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
>> > index a223066..6b239a3 100644
>> > --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
>> > +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
>> > @@ -239,16 +239,11 @@
>> >  		compatible = "arm,gic-v3";
>> >  		#interrupt-cells = <3>;
>> >  		#address-cells = <0>;
>> > -		#redistributor-regions = <6>;
>> > -		redistributor-stride = <0x0 0x40000>;
>> > +		#redistributor-regions = <1>;
>> > +		redistributor-stride = <0x20000>;
>> 
>> Why is that stride specified? Is the GIC implementation so busted that
>> the GICR_TYPER do not report a GICv3 redistributor, which implies a
>> 128kB stride?
>
> No, it's not required per my testing.  I guess it's there for
> documentation purpose to make the stride setting explicit.  Are you
> suggesting that we simply drop it?

Indeed. This is only meant as a workaround for some of the most
braindead platforms out there which have a redistributor stride that
deviates from what the architecture defines (128kB for GICv3, 256kB for
GICv4). It is good to know that this implementation is not broken.

> Also, it seems that #redistributor-regions can also be saved, since
> bindings doc tells that it's only required if more than one such region
> is present?

This could be removed as well.

Thanks,

        M.
Shawn Guo Dec. 3, 2016, 10:55 a.m. UTC | #9
On Fri, Dec 02, 2016 at 05:38:01PM +0100, Arnd Bergmann wrote:
> On Monday, November 28, 2016 10:08:18 PM CET Shawn Guo wrote:
> > On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
> > >> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
> > >> > GICR for multiple CPU can be described with start address and stride,
> > >> > or with multiple address. Current multiple address and stride are
> > >> > both used. Fix it.
> > >> >
> > >> > vmalloc patch 727a7f5a9 triggered this bug:
> > >> > [    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> > >> > [    0.097150] pgd = ffff000008602000
> > >> > [    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> > >> > [    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > >> > [    0.097170] Modules linked in:
> > >> > [    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> > >> > [    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> > >> > [    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> > >> > [    0.097197] PC is at gic_populate_rdist+0x74/0x15c
> > >> > [    0.097202] LR is at gic_starting_cpu+0xc/0x20
> > >> > [    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> > >> >
> > >> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > >>
> > >> A Fixes: tag would be useful on a patch like this, to tell what patch
> > >> introduced the problem. Please consider using them in the future.
> > >>
> > >> I've applied this one to fixes now.
> > >
> > > Hi Olof,
> > >
> > > I happened to still have this one in my todo folder as I must have
> > > missed your reply, and I stumbled over it while looking for things
> > > that may have gone missing.
> > >
> > > I don't see it in v4.9-rc6, did it get dropped accidentally?
> > 
> > Please help get this into v4.9 if possible, as it is required to get
> > v4.9 kernel boot up on ZTE ZX296718 SoC.  Thanks.
> > 
> > Shawn
> > 
> 
> Ok, applied both. Thanks,

Patch 2/2 already went to you in the pull request[1]:

[GIT PULL] ZTE arm64 device tree updates for 4.10

Shawn

[1] http://www.spinics.net/lists/arm-kernel/msg545640.html
Shawn Guo Dec. 5, 2016, 2:24 a.m. UTC | #10
Hi Arnd,

On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:
> Given that there is any concern about the patch now, and the merge
> window is almost open, I'm moving both patches to the
> next/fixes-non-critical branch and will merge it for v4.10 instead
> of sending it for v4.9.
> 
> If you end up deciding that the patch is wrong, please follow up
> with a fix on top. Once the situation is resolved and the patch
> merged upstream, feel free to ask stable@vger.kernel.org for a
> backport to stable kernels to get it into v4.9.x.

The patch is correct, though it can be cleaned up a bit further per
Marc's suggestion.  Since we now have 4.9-rc8, I'm wondering if we can
still get this into 4.9 to save the stable kernel backport.

I sent you a cleanup patch on top of this one yesterday.  If you like,
I can quickly resend the patch with the cleanup squashed.

Thanks,
Shawn
Olof Johansson Dec. 6, 2016, 12:55 a.m. UTC | #11
Hi Shawn,

On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> Hi Arnd,
>
> On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:
>> Given that there is any concern about the patch now, and the merge
>> window is almost open, I'm moving both patches to the
>> next/fixes-non-critical branch and will merge it for v4.10 instead
>> of sending it for v4.9.
>>
>> If you end up deciding that the patch is wrong, please follow up
>> with a fix on top. Once the situation is resolved and the patch
>> merged upstream, feel free to ask stable@vger.kernel.org for a
>> backport to stable kernels to get it into v4.9.x.
>
> The patch is correct, though it can be cleaned up a bit further per
> Marc's suggestion.  Since we now have 4.9-rc8, I'm wondering if we can
> still get this into 4.9 to save the stable kernel backport.
>
> I sent you a cleanup patch on top of this one yesterday.  If you like,
> I can quickly resend the patch with the cleanup squashed.

Since the patches have already been applied, an incremental patch to
apply on top would work best here.


Thanks!


-Olof
Shawn Guo Dec. 6, 2016, 1:12 a.m. UTC | #12
Hi Olof,

On Mon, Dec 05, 2016 at 04:55:02PM -0800, Olof Johansson wrote:
> Hi Shawn,
> 
> On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> > Hi Arnd,
> >
> > On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:
> >> Given that there is any concern about the patch now, and the merge
> >> window is almost open, I'm moving both patches to the
> >> next/fixes-non-critical branch and will merge it for v4.10 instead
> >> of sending it for v4.9.
> >>
> >> If you end up deciding that the patch is wrong, please follow up
> >> with a fix on top. Once the situation is resolved and the patch
> >> merged upstream, feel free to ask stable@vger.kernel.org for a
> >> backport to stable kernels to get it into v4.9.x.
> >
> > The patch is correct, though it can be cleaned up a bit further per
> > Marc's suggestion.  Since we now have 4.9-rc8, I'm wondering if we can
> > still get this into 4.9 to save the stable kernel backport.
> >
> > I sent you a cleanup patch on top of this one yesterday.  If you like,
> > I can quickly resend the patch with the cleanup squashed.
> 
> Since the patches have already been applied, an incremental patch to
> apply on top would work best here.

No problem.  So would you please apply the incremental patch [1] to the
same branch?  Or I can send it to you later during -rc cycles.  Just let
me know your preference.

Shawn

[1] https://www.spinics.net/lists/arm-kernel/msg546957.html
Olof Johansson Dec. 7, 2016, 8:34 p.m. UTC | #13
On Tue, Dec 06, 2016 at 09:12:46AM +0800, Shawn Guo wrote:
> Hi Olof,
> 
> On Mon, Dec 05, 2016 at 04:55:02PM -0800, Olof Johansson wrote:
> > Hi Shawn,
> > 
> > On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> > > Hi Arnd,
> > >
> > > On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:
> > >> Given that there is any concern about the patch now, and the merge
> > >> window is almost open, I'm moving both patches to the
> > >> next/fixes-non-critical branch and will merge it for v4.10 instead
> > >> of sending it for v4.9.
> > >>
> > >> If you end up deciding that the patch is wrong, please follow up
> > >> with a fix on top. Once the situation is resolved and the patch
> > >> merged upstream, feel free to ask stable@vger.kernel.org for a
> > >> backport to stable kernels to get it into v4.9.x.
> > >
> > > The patch is correct, though it can be cleaned up a bit further per
> > > Marc's suggestion.  Since we now have 4.9-rc8, I'm wondering if we can
> > > still get this into 4.9 to save the stable kernel backport.
> > >
> > > I sent you a cleanup patch on top of this one yesterday.  If you like,
> > > I can quickly resend the patch with the cleanup squashed.
> > 
> > Since the patches have already been applied, an incremental patch to
> > apply on top would work best here.
> 
> No problem.  So would you please apply the incremental patch [1] to the
> same branch?  Or I can send it to you later during -rc cycles.  Just let
> me know your preference.
> 
> Shawn
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg546957.html

So, it seems that Arnd didn't apply the old patch to fixes-non-critical, or
at least didn't push out after doing it. So, I've done that now, as well as
applied the fixup you have above.


-Olof
diff mbox

Patch

diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index a223066..6b239a3 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -239,16 +239,11 @@ 
 		compatible = "arm,gic-v3";
 		#interrupt-cells = <3>;
 		#address-cells = <0>;
-		#redistributor-regions = <6>;
-		redistributor-stride = <0x0 0x40000>;
+		#redistributor-regions = <1>;
+		redistributor-stride = <0x20000>;
 		interrupt-controller;
 		reg = <0x02a00000 0x10000>,
-		      <0x02b00000 0x20000>,
-		      <0x02b20000 0x20000>,
-		      <0x02b40000 0x20000>,
-		      <0x02b60000 0x20000>,
-		      <0x02b80000 0x20000>,
-		      <0x02ba0000 0x20000>;
+		      <0x02b00000 0xc0000>;
 		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
 	};