Re: [PATCH 2/2] mips: generic: allow not building DTB in

[James Hogan]

On Wed, Apr 25, 2018 at 11:16:07PM +0200, Alexandre Belloni wrote:
> Allow not building any DTB in the generic kernel so it gets smaller. This
> is necessary for ocelot because it can be built as a legacy platform that
> needs a built-in DTB and it can also handle a separate DTB once it is
> updated with a more modern bootloader. In the latter case, it is preferable
> to not include any DTB in the kernel image so it is smaller.

Since bootloaders can modify DTs before passing them to the kernel (e.g.
to add cmdline args or memory nodes), that would seem to make it
impossible to have a kernel supporting both legacy bootloader, and a
u-boot which might do that DT tweaking.

Or perhaps its not important for this platform.

> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 5e9fce076ab6..3d3554c13710 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -404,7 +404,7 @@ endif
>  CLEAN_FILES += vmlinux.32 vmlinux.64
>  
>  # device-trees
> -core-$(CONFIG_BUILTIN_DTB) += arch/mips/boot/dts/
> +core-y += arch/mips/boot/dts/

Won't that result in DTBs being built unnecessarily on other platforms
which support BUILTIN_DTB but don't have it enabled?

I suppose the alternative is another Kconfig symbol for when building of
DTBs is needed, selected by BUILTIN_DTB and MIPS_GENERIC.

>  
>  %.dtb %.dtb.S %.dtb.o: | scripts
>   $(Q)$(MAKE) $(build)=arch/mips/boot/dts arch/mips/boot/dts/$@
> diff --git a/arch/mips/boot/dts/mscc/Makefile 
> b/arch/mips/boot/dts/mscc/Makefile
> index 8982b19504a3..437ec65ec14a 100644
> --- a/arch/mips/boot/dts/mscc/Makefile
> +++ b/arch/mips/boot/dts/mscc/Makefile
> @@ -1,3 +1,3 @@
>  dtb-$(CONFIG_MSCC_OCELOT)+= ocelot_pcb123.dtb
>  
> -obj-y+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
> +obj-($CONFIG_BUILTIN_DTB)+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))

(This part is already merged in 4.18-rc1 in commit fca3aa166422 ("MIPS:
dts: Avoid unneeded built-in.a in DTS dirs"))

> diff --git a/arch/mips/generic/Kconfig b/arch/mips/generic/Kconfig
> index 6564f18b2012..012f283f99c4 100644
> --- a/arch/mips/generic/Kconfig
> +++ b/arch/mips/generic/Kconfig
> @@ -3,6 +3,7 @@ if MIPS_GENERIC
>  
>  config LEGACY_BOARDS
>   bool
> + select BUILTIN_DTB
>   help
> Select this from your board if the board must use a legacy, non-UHI,
> boot protocol. This will cause the kernel to scan through the list of
> diff --git a/arch/mips/generic/vmlinux.its.S b/arch/mips/generic/vmlinux.its.S
> index 1a08438fd893..9c954f2ae561 100644
> --- a/arch/mips/generic/vmlinux.its.S
> +++ b/arch/mips/generic/vmlinux.its.S
> @@ -21,6 +21,7 @@
>   };
>   };
>  
> +#if IS_ENABLED(CONFIG_BUILTIN_DTB)

An #ifdef would do, but no matter if it works. Though shouldn't that be
if !IS_ENABLED (or #ifndef)?

A comment would be great here too to mention why its helpful.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH 2/2] mips: generic: allow not building DTB in

[James Hogan]

On Wed, Apr 25, 2018 at 11:16:07PM +0200, Alexandre Belloni wrote:
> Allow not building any DTB in the generic kernel so it gets smaller. This
> is necessary for ocelot because it can be built as a legacy platform that
> needs a built-in DTB and it can also handle a separate DTB once it is
> updated with a more modern bootloader. In the latter case, it is preferable
> to not include any DTB in the kernel image so it is smaller.

Since bootloaders can modify DTs before passing them to the kernel (e.g.
to add cmdline args or memory nodes), that would seem to make it
impossible to have a kernel supporting both legacy bootloader, and a
u-boot which might do that DT tweaking.

Or perhaps its not important for this platform.

> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 5e9fce076ab6..3d3554c13710 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -404,7 +404,7 @@ endif
>  CLEAN_FILES += vmlinux.32 vmlinux.64
>  
>  # device-trees
> -core-$(CONFIG_BUILTIN_DTB) += arch/mips/boot/dts/
> +core-y += arch/mips/boot/dts/

Won't that result in DTBs being built unnecessarily on other platforms
which support BUILTIN_DTB but don't have it enabled?

I suppose the alternative is another Kconfig symbol for when building of
DTBs is needed, selected by BUILTIN_DTB and MIPS_GENERIC.

>  
>  %.dtb %.dtb.S %.dtb.o: | scripts
>   $(Q)$(MAKE) $(build)=arch/mips/boot/dts arch/mips/boot/dts/$@
> diff --git a/arch/mips/boot/dts/mscc/Makefile 
> b/arch/mips/boot/dts/mscc/Makefile
> index 8982b19504a3..437ec65ec14a 100644
> --- a/arch/mips/boot/dts/mscc/Makefile
> +++ b/arch/mips/boot/dts/mscc/Makefile
> @@ -1,3 +1,3 @@
>  dtb-$(CONFIG_MSCC_OCELOT)+= ocelot_pcb123.dtb
>  
> -obj-y+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
> +obj-($CONFIG_BUILTIN_DTB)+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))

(This part is already merged in 4.18-rc1 in commit fca3aa166422 ("MIPS:
dts: Avoid unneeded built-in.a in DTS dirs"))

> diff --git a/arch/mips/generic/Kconfig b/arch/mips/generic/Kconfig
> index 6564f18b2012..012f283f99c4 100644
> --- a/arch/mips/generic/Kconfig
> +++ b/arch/mips/generic/Kconfig
> @@ -3,6 +3,7 @@ if MIPS_GENERIC
>  
>  config LEGACY_BOARDS
>   bool
> + select BUILTIN_DTB
>   help
> Select this from your board if the board must use a legacy, non-UHI,
> boot protocol. This will cause the kernel to scan through the list of
> diff --git a/arch/mips/generic/vmlinux.its.S b/arch/mips/generic/vmlinux.its.S
> index 1a08438fd893..9c954f2ae561 100644
> --- a/arch/mips/generic/vmlinux.its.S
> +++ b/arch/mips/generic/vmlinux.its.S
> @@ -21,6 +21,7 @@
>   };
>   };
>  
> +#if IS_ENABLED(CONFIG_BUILTIN_DTB)

An #ifdef would do, but no matter if it works. Though shouldn't that be
if !IS_ENABLED (or #ifndef)?

A comment would be great here too to mention why its helpful.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH 1/2] mips: mscc: build FIT image for Ocelot

[James Hogan]

On Wed, Apr 25, 2018 at 11:16:06PM +0200, Alexandre Belloni wrote:
> +config FIT_IMAGE_FDT_OCELOT_PCB123
> + bool "Include FDT for Microsemi Ocelot PCB123"
> + select MSCC_OCELOT
> + help
> +   Enable this to include the FDT for the Ocelot PCB123 platform
> +   from Microsemi in the FIT kernel image.
> +   This require u-boot on the platform.

nit: s/require/requires/

Reviewed-by: James Hogan 

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH 1/2] mips: mscc: build FIT image for Ocelot

[James Hogan]

On Wed, Apr 25, 2018 at 11:16:06PM +0200, Alexandre Belloni wrote:
> +config FIT_IMAGE_FDT_OCELOT_PCB123
> + bool "Include FDT for Microsemi Ocelot PCB123"
> + select MSCC_OCELOT
> + help
> +   Enable this to include the FDT for the Ocelot PCB123 platform
> +   from Microsemi in the FIT kernel image.
> +   This require u-boot on the platform.

nit: s/require/requires/

Reviewed-by: James Hogan 

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v2] nds32: Fix build error caused by configuration flag rename

[James Hogan]

On Fri, Jun 15, 2018 at 02:12:58PM +0800, Greentime Hu wrote:
> Thank you James and Guenter.
> Should I pick it in my tree? It will be ok to put in your tree. :)
> 
> Acked-by: Greentime Hu 

I think your tree makes most sense for this patch, since it only touches
nds32 code and it was nds32 that got broken (and I haven't actually
build tested it for nds32).

Though it'd have to be based on that MIPS merge I mentioned or 4.18-rc1
when it is released.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v2] nds32: Fix build error caused by configuration flag rename

[James Hogan]

On Fri, Jun 15, 2018 at 02:12:58PM +0800, Greentime Hu wrote:
> Thank you James and Guenter.
> Should I pick it in my tree? It will be ok to put in your tree. :)
> 
> Acked-by: Greentime Hu 

I think your tree makes most sense for this patch, since it only touches
nds32 code and it was nds32 that got broken (and I haven't actually
build tested it for nds32).

Though it'd have to be based on that MIPS merge I mentioned or 4.18-rc1
when it is released.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH 4/4] rseq/selftests: Implement MIPS support

[James Hogan]

On Thu, Jun 14, 2018 at 04:52:10PM -0700, Paul Burton wrote:
> +#define __RSEQ_ASM_DEFINE_TABLE(version, flags,  start_ip,   
> \

Nit: technically all these \'s are on 81st column...

> +#define __RSEQ_ASM_DEFINE_ABORT(table_label, label, teardown,
> \
> + abort_label, version, flags,
> \
> + start_ip, post_commit_offset, abort_ip) 
> \
> + ".balign 32\n\t"
> \

ARM doesn't do this for DEFINE_ABORT. Is it intentional that we do for
MIPS?

Otherwise this whole series looks reasonable to me, so feel free to add
my rb on the whole series if you do apply youself:

Reviewed-by: James Hogan 

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH 4/4] rseq/selftests: Implement MIPS support

[James Hogan]

On Thu, Jun 14, 2018 at 04:52:10PM -0700, Paul Burton wrote:
> +#define __RSEQ_ASM_DEFINE_TABLE(version, flags,  start_ip,   
> \

Nit: technically all these \'s are on 81st column...

> +#define __RSEQ_ASM_DEFINE_ABORT(table_label, label, teardown,
> \
> + abort_label, version, flags,
> \
> + start_ip, post_commit_offset, abort_ip) 
> \
> + ".balign 32\n\t"
> \

ARM doesn't do this for DEFINE_ABORT. Is it intentional that we do for
MIPS?

Otherwise this whole series looks reasonable to me, so feel free to add
my rb on the whole series if you do apply youself:

Reviewed-by: James Hogan 

Thanks
James


signature.asc
Description: PGP signature

[PATCH v2] nds32: Fix build error caused by configuration flag rename

[James Hogan]

From: Guenter Roeck 

Fix build error on nds32 due to the merge of commit e3d5980568f ("lib:
Rename compiler intrinsic selects to GENERIC_LIB_*") during the 4.18
merge window which renames Kconfig symbols. This had raced with commit
aeaa7af744fa ("nds32: lib: To use generic lib instead of libgcc to
prevent the symbol undefined issue.") merged late in the 4.17 cycle,
which added selects to nds32 using the original Kconfig symbol names.

When they came together in merge commit 763f96944c95 ("Merge tag
'mips_4.18' of
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux") this resulted
in the following build errors:

nds32le-linux-ld: kernel/time/timekeeping.o: in function `timekeeping_init':
timekeeping.c:(.init.text+0x140): undefined reference to `__ashldi3'
nds32le-linux-ld: timekeeping.c:(.init.text+0x144): undefined reference to 
`__ashldi3'
nds32le-linux-ld: timekeeping.c:(.init.text+0x17e): undefined reference to 
`__lshrdi3'
nds32le-linux-ld: timekeeping.c:(.init.text+0x182): undefined reference to 
`__lshrdi3'
nds32le-linux-ld: drivers/clocksource/mmio.o: in function 
`clocksource_mmio_init':
mmio.c:(.init.text+0x54): undefined reference to `__lshrdi3'
nds32le-linux-ld: mmio.c:(.init.text+0x58): undefined reference to `__lshrdi3'

Rename all 6 selects in nds32 and adjust the ordering accordingly to be
alphabetical.

Fixes: 763f96944c95 ("Merge tag 'mips_4.18' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux")
Signed-off-by: Guenter Roeck 
[jho...@kernel.org: Rename all 6 symbols, sort, update commit message]
Signed-off-by: James Hogan 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Matt Redfearn 
Cc: Palmer Dabbelt 
---
Changes in v2:
 - Rename all 6 symbols, not just the 3 that caused build failures.
 - Sort selects.
 - Update commit message.
---
 arch/nds32/Kconfig | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index 6aed974276d8..34f7222c5efe 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -12,17 +12,17 @@ config NDS32
select CLONE_BACKWARDS
select COMMON_CLK
select DMA_NONCOHERENT_OPS
-   select GENERIC_ASHLDI3
-   select GENERIC_ASHRDI3
-   select GENERIC_LSHRDI3
-   select GENERIC_CMPDI2
-   select GENERIC_MULDI3
-   select GENERIC_UCMPDI2
select GENERIC_ATOMIC64
select GENERIC_CPU_DEVICES
select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
+   select GENERIC_LIB_ASHLDI3
+   select GENERIC_LIB_ASHRDI3
+   select GENERIC_LIB_CMPDI2
+   select GENERIC_LIB_LSHRDI3
+   select GENERIC_LIB_MULDI3
+   select GENERIC_LIB_UCMPDI2
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select GENERIC_TIME_VSYSCALL
-- 
2.17.1

[PATCH v2] nds32: Fix build error caused by configuration flag rename

[James Hogan]

From: Guenter Roeck 

Fix build error on nds32 due to the merge of commit e3d5980568f ("lib:
Rename compiler intrinsic selects to GENERIC_LIB_*") during the 4.18
merge window which renames Kconfig symbols. This had raced with commit
aeaa7af744fa ("nds32: lib: To use generic lib instead of libgcc to
prevent the symbol undefined issue.") merged late in the 4.17 cycle,
which added selects to nds32 using the original Kconfig symbol names.

When they came together in merge commit 763f96944c95 ("Merge tag
'mips_4.18' of
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux") this resulted
in the following build errors:

nds32le-linux-ld: kernel/time/timekeeping.o: in function `timekeeping_init':
timekeeping.c:(.init.text+0x140): undefined reference to `__ashldi3'
nds32le-linux-ld: timekeeping.c:(.init.text+0x144): undefined reference to 
`__ashldi3'
nds32le-linux-ld: timekeeping.c:(.init.text+0x17e): undefined reference to 
`__lshrdi3'
nds32le-linux-ld: timekeeping.c:(.init.text+0x182): undefined reference to 
`__lshrdi3'
nds32le-linux-ld: drivers/clocksource/mmio.o: in function 
`clocksource_mmio_init':
mmio.c:(.init.text+0x54): undefined reference to `__lshrdi3'
nds32le-linux-ld: mmio.c:(.init.text+0x58): undefined reference to `__lshrdi3'

Rename all 6 selects in nds32 and adjust the ordering accordingly to be
alphabetical.

Fixes: 763f96944c95 ("Merge tag 'mips_4.18' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux")
Signed-off-by: Guenter Roeck 
[jho...@kernel.org: Rename all 6 symbols, sort, update commit message]
Signed-off-by: James Hogan 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Matt Redfearn 
Cc: Palmer Dabbelt 
---
Changes in v2:
 - Rename all 6 symbols, not just the 3 that caused build failures.
 - Sort selects.
 - Update commit message.
---
 arch/nds32/Kconfig | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index 6aed974276d8..34f7222c5efe 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -12,17 +12,17 @@ config NDS32
select CLONE_BACKWARDS
select COMMON_CLK
select DMA_NONCOHERENT_OPS
-   select GENERIC_ASHLDI3
-   select GENERIC_ASHRDI3
-   select GENERIC_LSHRDI3
-   select GENERIC_CMPDI2
-   select GENERIC_MULDI3
-   select GENERIC_UCMPDI2
select GENERIC_ATOMIC64
select GENERIC_CPU_DEVICES
select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
+   select GENERIC_LIB_ASHLDI3
+   select GENERIC_LIB_ASHRDI3
+   select GENERIC_LIB_CMPDI2
+   select GENERIC_LIB_LSHRDI3
+   select GENERIC_LIB_MULDI3
+   select GENERIC_LIB_UCMPDI2
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select GENERIC_TIME_VSYSCALL
-- 
2.17.1

Re: [PATCH] nds32: Fix build error caused by incomplete configuration flag rename

[James Hogan]

On Wed, Jun 13, 2018 at 02:28:08PM -0700, Guenter Roeck wrote:
> On Wed, Jun 13, 2018 at 10:06:13PM +0100, James Hogan wrote:
> > Thanks Guenter,
> > 
> > On Wed, Jun 13, 2018 at 12:43:52PM -0700, Guenter Roeck wrote:
> > > GENERIC_ASHLDI3, GENERIC_ASHRDI3, and GENERIC_LSHRDI3 were renamed to
> > > GENERIC_LIB_ASHLDI3, GENERIC_LIB_ASHRDI3, and GENERIC_LIB_LSHRDI3
> > > without making the matching changes in arch/nds32.
> > 
> > Well, thats a little misleading. The commit in question was applied
> > based on 4.17-rc2 a month *before* commit aeaa7af744fa ("nds32: lib: To
> > use generic lib instead of libgcc to prevent the symbol undefined
> > issue.") raced and overtook it and was merged in time for final 4.17, so
> > technically it was only when the two recently came together in merge
> > commit 763f96944c95 ("Merge tag 'mips_4.18' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux") that it was a
> > problem.
> > 
> > Incidentally, is anybody building linux-next for nds32? (I could have
> > asked Linus to fix this up in the merge commit had I known).
> > 
> 
> Yes, me, and I had mentioned the failure a while ago in some e-mail exchange
> talking about testing on -next. I did not have time to bisect, though.

My appologies if I was cc'd and missed it.

> Also, I rarely report problems in -next anymore after some less than friendly
> reactions. One always risks something like "You should have checked branch 
> of repository  before bugging me with this report", which is especially
> annoying if the branch in question is not pulled into -next. People can always

Thats a pity, but fair enough!

> check http://kerneltests.org/builders if they are interested in the status
> of various branches.

Thanks for the link. For the record i'm always interested in -next
issues you might become aware of related to patches I've applied (which
is hard to tell at a glance on the webpage in this case unfortunately).

> 
> > > Fixes: e3d5980568f ("lib: Rename compiler intrinsic selects to 
> > > GENERIC_LIB_*")
> > 
> > Perhaps this would be more accurate?:
> > Fixes: 763f96944c95 ("Merge tag 'mips_4.18' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux")
> > 
> > > - select GENERIC_ASHLDI3
> > > - select GENERIC_ASHRDI3
> > > - select GENERIC_LSHRDI3
> > > + select GENERIC_LIB_ASHLDI3
> > > + select GENERIC_LIB_ASHRDI3
> > > + select GENERIC_LIB_LSHRDI3
> > >   select GENERIC_CMPDI2
> > >   select GENERIC_MULDI3
> > >   select GENERIC_UCMPDI2
> > 
> > These 3 were renamed also.
> > 
> 
> Good point. Maybe someone else can take it from here to find a more
> politically correct wording of the patch description ?

happy to tomorrow if rds32 folk don't want to.

Thanks again,
James

Re: [PATCH] nds32: Fix build error caused by incomplete configuration flag rename

[James Hogan]

On Wed, Jun 13, 2018 at 02:28:08PM -0700, Guenter Roeck wrote:
> On Wed, Jun 13, 2018 at 10:06:13PM +0100, James Hogan wrote:
> > Thanks Guenter,
> > 
> > On Wed, Jun 13, 2018 at 12:43:52PM -0700, Guenter Roeck wrote:
> > > GENERIC_ASHLDI3, GENERIC_ASHRDI3, and GENERIC_LSHRDI3 were renamed to
> > > GENERIC_LIB_ASHLDI3, GENERIC_LIB_ASHRDI3, and GENERIC_LIB_LSHRDI3
> > > without making the matching changes in arch/nds32.
> > 
> > Well, thats a little misleading. The commit in question was applied
> > based on 4.17-rc2 a month *before* commit aeaa7af744fa ("nds32: lib: To
> > use generic lib instead of libgcc to prevent the symbol undefined
> > issue.") raced and overtook it and was merged in time for final 4.17, so
> > technically it was only when the two recently came together in merge
> > commit 763f96944c95 ("Merge tag 'mips_4.18' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux") that it was a
> > problem.
> > 
> > Incidentally, is anybody building linux-next for nds32? (I could have
> > asked Linus to fix this up in the merge commit had I known).
> > 
> 
> Yes, me, and I had mentioned the failure a while ago in some e-mail exchange
> talking about testing on -next. I did not have time to bisect, though.

My appologies if I was cc'd and missed it.

> Also, I rarely report problems in -next anymore after some less than friendly
> reactions. One always risks something like "You should have checked branch 
> of repository  before bugging me with this report", which is especially
> annoying if the branch in question is not pulled into -next. People can always

Thats a pity, but fair enough!

> check http://kerneltests.org/builders if they are interested in the status
> of various branches.

Thanks for the link. For the record i'm always interested in -next
issues you might become aware of related to patches I've applied (which
is hard to tell at a glance on the webpage in this case unfortunately).

> 
> > > Fixes: e3d5980568f ("lib: Rename compiler intrinsic selects to 
> > > GENERIC_LIB_*")
> > 
> > Perhaps this would be more accurate?:
> > Fixes: 763f96944c95 ("Merge tag 'mips_4.18' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux")
> > 
> > > - select GENERIC_ASHLDI3
> > > - select GENERIC_ASHRDI3
> > > - select GENERIC_LSHRDI3
> > > + select GENERIC_LIB_ASHLDI3
> > > + select GENERIC_LIB_ASHRDI3
> > > + select GENERIC_LIB_LSHRDI3
> > >   select GENERIC_CMPDI2
> > >   select GENERIC_MULDI3
> > >   select GENERIC_UCMPDI2
> > 
> > These 3 were renamed also.
> > 
> 
> Good point. Maybe someone else can take it from here to find a more
> politically correct wording of the patch description ?

happy to tomorrow if rds32 folk don't want to.

Thanks again,
James

Re: [PATCH] nds32: Fix build error caused by incomplete configuration flag rename

[James Hogan]

Thanks Guenter,

On Wed, Jun 13, 2018 at 12:43:52PM -0700, Guenter Roeck wrote:
> GENERIC_ASHLDI3, GENERIC_ASHRDI3, and GENERIC_LSHRDI3 were renamed to
> GENERIC_LIB_ASHLDI3, GENERIC_LIB_ASHRDI3, and GENERIC_LIB_LSHRDI3
> without making the matching changes in arch/nds32.

Well, thats a little misleading. The commit in question was applied
based on 4.17-rc2 a month *before* commit aeaa7af744fa ("nds32: lib: To
use generic lib instead of libgcc to prevent the symbol undefined
issue.") raced and overtook it and was merged in time for final 4.17, so
technically it was only when the two recently came together in merge
commit 763f96944c95 ("Merge tag 'mips_4.18' of
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux") that it was a
problem.

Incidentally, is anybody building linux-next for nds32? (I could have
asked Linus to fix this up in the merge commit had I known).

> Fixes: e3d5980568f ("lib: Rename compiler intrinsic selects to GENERIC_LIB_*")

Perhaps this would be more accurate?:
Fixes: 763f96944c95 ("Merge tag 'mips_4.18' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux")

> - select GENERIC_ASHLDI3
> - select GENERIC_ASHRDI3
> - select GENERIC_LSHRDI3
> + select GENERIC_LIB_ASHLDI3
> + select GENERIC_LIB_ASHRDI3
> + select GENERIC_LIB_LSHRDI3
>   select GENERIC_CMPDI2
>   select GENERIC_MULDI3
>   select GENERIC_UCMPDI2

These 3 were renamed also.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] nds32: Fix build error caused by incomplete configuration flag rename

[James Hogan]

Thanks Guenter,

On Wed, Jun 13, 2018 at 12:43:52PM -0700, Guenter Roeck wrote:
> GENERIC_ASHLDI3, GENERIC_ASHRDI3, and GENERIC_LSHRDI3 were renamed to
> GENERIC_LIB_ASHLDI3, GENERIC_LIB_ASHRDI3, and GENERIC_LIB_LSHRDI3
> without making the matching changes in arch/nds32.

Well, thats a little misleading. The commit in question was applied
based on 4.17-rc2 a month *before* commit aeaa7af744fa ("nds32: lib: To
use generic lib instead of libgcc to prevent the symbol undefined
issue.") raced and overtook it and was merged in time for final 4.17, so
technically it was only when the two recently came together in merge
commit 763f96944c95 ("Merge tag 'mips_4.18' of
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux") that it was a
problem.

Incidentally, is anybody building linux-next for nds32? (I could have
asked Linus to fix this up in the merge commit had I known).

> Fixes: e3d5980568f ("lib: Rename compiler intrinsic selects to GENERIC_LIB_*")

Perhaps this would be more accurate?:
Fixes: 763f96944c95 ("Merge tag 'mips_4.18' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux")

> - select GENERIC_ASHLDI3
> - select GENERIC_ASHRDI3
> - select GENERIC_LSHRDI3
> + select GENERIC_LIB_ASHLDI3
> + select GENERIC_LIB_ASHRDI3
> + select GENERIC_LIB_LSHRDI3
>   select GENERIC_CMPDI2
>   select GENERIC_MULDI3
>   select GENERIC_UCMPDI2

These 3 were renamed also.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH 3/7] MIPS: intel: Add initial support for Intel MIPS SoCs

[James Hogan]

Hi,

Good to see this patch!

On Tue, Jun 12, 2018 at 01:40:30PM +0800, Songjun Wu wrote:
> diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
> index ac7ad54f984f..bcd647060f3e 100644
> --- a/arch/mips/Kbuild.platforms
> +++ b/arch/mips/Kbuild.platforms
> @@ -12,6 +12,7 @@ platforms += cobalt
>  platforms += dec
>  platforms += emma
>  platforms += generic
> +platforms += intel-mips

What are the main things preventing this from moving to the generic
platform? Is it mainly the use of EVA (which generic doesn't yet
support)?

> diff --git a/arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h 
> b/arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h
> new file mode 100644
> index ..3893855b60c6
> --- /dev/null
> +++ b/arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h
...
> + /*
> +  * Get Config.K0 value and use it to program
> +  * the segmentation registers

Please can you describe (maybe with a table) the segment layout in human
readable terms so the reader doesn't need to decode the SegCtl registers
to understand where everything is in the virtual address space?

> diff --git a/arch/mips/boot/dts/intel-mips/Makefile 
> b/arch/mips/boot/dts/intel-mips/Makefile
> new file mode 100644
> index ..b16c0081639c
> --- /dev/null
> +++ b/arch/mips/boot/dts/intel-mips/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_DTB_INTEL_MIPS_GRX500)  += easy350_anywan.dtb
> +obj-y+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))

This needs updating to obj-$(CONFIG_BUILTIN_DTB) as per commit
fca3aa166422 ("MIPS: dts: Avoid unneeded built-in.a in DTS dirs") in
linux-next.

> diff --git a/arch/mips/intel-mips/Makefile b/arch/mips/intel-mips/Makefile
> new file mode 100644
> index ..9f272d06eecd
> --- /dev/null
> +++ b/arch/mips/intel-mips/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_INTEL_MIPS) += prom.o irq.o time.o

You can use obj-y, since this Makefile is only included if
CONFIG_INTEL_MIPS=y (i.e. via the platform-$(CONFIG_INTEL_MIPS) below).

Also please split each file onto separate "obj-y += whatever.o" lines.

> diff --git a/arch/mips/intel-mips/Platform b/arch/mips/intel-mips/Platform
> new file mode 100644
> index ..b34750eeaeb0
> --- /dev/null
> +++ b/arch/mips/intel-mips/Platform
> @@ -0,0 +1,11 @@
> +#
> +# MIPs SoC platform
> +#
> +
> +platform-$(CONFIG_INTEL_MIPS)+= intel-mips/

^^^ (this is what ensures the Makefile is only included for this
platform)

> diff --git a/arch/mips/intel-mips/irq.c b/arch/mips/intel-mips/irq.c
> new file mode 100644
> index ..00637a5cdd20
> --- /dev/null
> +++ b/arch/mips/intel-mips/irq.c
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2016 Intel Corporation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +void __init arch_init_irq(void)
> +{
> + struct device_node *intc_node;
> +
> + pr_info("EIC is %s\n", cpu_has_veic ? "on" : "off");
> + pr_info("VINT is %s\n", cpu_has_vint ? "on" : "off");
> +
> + intc_node = of_find_compatible_node(NULL, NULL,
> + "mti,cpu-interrupt-controller");
> + if (!cpu_has_veic && !intc_node)
> + mips_cpu_irq_init();
> +
> + irqchip_init();
> +}
> +
> +int get_c0_perfcount_int(void)
> +{
> + return gic_get_c0_perfcount_int();
> +}
> +EXPORT_SYMBOL_GPL(get_c0_perfcount_int);
> +
> +unsigned int get_c0_compare_int(void)
> +{
> + return gic_get_c0_compare_int();
> +}

Worth having get_c0_fdc_int() too for the "Fast Debug Channel"?

> diff --git a/arch/mips/intel-mips/prom.c b/arch/mips/intel-mips/prom.c
> new file mode 100644
> index ..9407858ddc94
> --- /dev/null
> +++ b/arch/mips/intel-mips/prom.c
> @@ -0,0 +1,184 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2014 Lei Chuanhua 
> + * Copyright (C) 2016 Intel Corporation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IOPORT_RESOURCE_START   0x1000
> +#define IOPORT_RESOURCE_END 0x
> +#define IOMEM_RESOURCE_START0x1000
> +#define IOMEM_RESOURCE_END  0x

The _END ones seem to be unused?

> +static void __init prom_init_cmdline(void)
> +{
> + int i;
> + int argc;
> + char **argv;
> +
> + /*
> +  * If u-boot pass parameters, it is ok, however, if without u-boot
> +  * JTAG or other tool has to reset all register value before it goes
> +  * emulation most likely belongs to this category
> +  */
> + if (fw_arg0 == 0 || fw_arg1 == 0)
> + return;
> +
> + argc = fw_arg0;
> + argv = (char **)KSEG1ADDR(fw_arg1);
> +
> + arcs_cmdline[0] = '\0';
> +
> + for (i = 0; i < argc; i++) {
> + char *p = (char 

Re: [PATCH 3/7] MIPS: intel: Add initial support for Intel MIPS SoCs

[James Hogan]

Hi,

Good to see this patch!

On Tue, Jun 12, 2018 at 01:40:30PM +0800, Songjun Wu wrote:
> diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
> index ac7ad54f984f..bcd647060f3e 100644
> --- a/arch/mips/Kbuild.platforms
> +++ b/arch/mips/Kbuild.platforms
> @@ -12,6 +12,7 @@ platforms += cobalt
>  platforms += dec
>  platforms += emma
>  platforms += generic
> +platforms += intel-mips

What are the main things preventing this from moving to the generic
platform? Is it mainly the use of EVA (which generic doesn't yet
support)?

> diff --git a/arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h 
> b/arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h
> new file mode 100644
> index ..3893855b60c6
> --- /dev/null
> +++ b/arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h
...
> + /*
> +  * Get Config.K0 value and use it to program
> +  * the segmentation registers

Please can you describe (maybe with a table) the segment layout in human
readable terms so the reader doesn't need to decode the SegCtl registers
to understand where everything is in the virtual address space?

> diff --git a/arch/mips/boot/dts/intel-mips/Makefile 
> b/arch/mips/boot/dts/intel-mips/Makefile
> new file mode 100644
> index ..b16c0081639c
> --- /dev/null
> +++ b/arch/mips/boot/dts/intel-mips/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_DTB_INTEL_MIPS_GRX500)  += easy350_anywan.dtb
> +obj-y+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))

This needs updating to obj-$(CONFIG_BUILTIN_DTB) as per commit
fca3aa166422 ("MIPS: dts: Avoid unneeded built-in.a in DTS dirs") in
linux-next.

> diff --git a/arch/mips/intel-mips/Makefile b/arch/mips/intel-mips/Makefile
> new file mode 100644
> index ..9f272d06eecd
> --- /dev/null
> +++ b/arch/mips/intel-mips/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_INTEL_MIPS) += prom.o irq.o time.o

You can use obj-y, since this Makefile is only included if
CONFIG_INTEL_MIPS=y (i.e. via the platform-$(CONFIG_INTEL_MIPS) below).

Also please split each file onto separate "obj-y += whatever.o" lines.

> diff --git a/arch/mips/intel-mips/Platform b/arch/mips/intel-mips/Platform
> new file mode 100644
> index ..b34750eeaeb0
> --- /dev/null
> +++ b/arch/mips/intel-mips/Platform
> @@ -0,0 +1,11 @@
> +#
> +# MIPs SoC platform
> +#
> +
> +platform-$(CONFIG_INTEL_MIPS)+= intel-mips/

^^^ (this is what ensures the Makefile is only included for this
platform)

> diff --git a/arch/mips/intel-mips/irq.c b/arch/mips/intel-mips/irq.c
> new file mode 100644
> index ..00637a5cdd20
> --- /dev/null
> +++ b/arch/mips/intel-mips/irq.c
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2016 Intel Corporation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +void __init arch_init_irq(void)
> +{
> + struct device_node *intc_node;
> +
> + pr_info("EIC is %s\n", cpu_has_veic ? "on" : "off");
> + pr_info("VINT is %s\n", cpu_has_vint ? "on" : "off");
> +
> + intc_node = of_find_compatible_node(NULL, NULL,
> + "mti,cpu-interrupt-controller");
> + if (!cpu_has_veic && !intc_node)
> + mips_cpu_irq_init();
> +
> + irqchip_init();
> +}
> +
> +int get_c0_perfcount_int(void)
> +{
> + return gic_get_c0_perfcount_int();
> +}
> +EXPORT_SYMBOL_GPL(get_c0_perfcount_int);
> +
> +unsigned int get_c0_compare_int(void)
> +{
> + return gic_get_c0_compare_int();
> +}

Worth having get_c0_fdc_int() too for the "Fast Debug Channel"?

> diff --git a/arch/mips/intel-mips/prom.c b/arch/mips/intel-mips/prom.c
> new file mode 100644
> index ..9407858ddc94
> --- /dev/null
> +++ b/arch/mips/intel-mips/prom.c
> @@ -0,0 +1,184 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2014 Lei Chuanhua 
> + * Copyright (C) 2016 Intel Corporation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IOPORT_RESOURCE_START   0x1000
> +#define IOPORT_RESOURCE_END 0x
> +#define IOMEM_RESOURCE_START0x1000
> +#define IOMEM_RESOURCE_END  0x

The _END ones seem to be unused?

> +static void __init prom_init_cmdline(void)
> +{
> + int i;
> + int argc;
> + char **argv;
> +
> + /*
> +  * If u-boot pass parameters, it is ok, however, if without u-boot
> +  * JTAG or other tool has to reset all register value before it goes
> +  * emulation most likely belongs to this category
> +  */
> + if (fw_arg0 == 0 || fw_arg1 == 0)
> + return;
> +
> + argc = fw_arg0;
> + argv = (char **)KSEG1ADDR(fw_arg1);
> +
> + arcs_cmdline[0] = '\0';
> +
> + for (i = 0; i < argc; i++) {
> + char *p = (char 

Re: [PATCH] MIPS: ptrace: Make FPU context layout comments match reality

[James Hogan]

On Tue, May 15, 2018 at 11:03:09PM +0100, Maciej W. Rozycki wrote:
> Correct comments across ptrace(2) handlers about an FPU register context
> layout discrepancy between MIPS I and later ISAs, which was fixed with
> `linux-mips.org' (LMO) commit 42533948caac ("Major pile of FP emulator
> changes."), the fix corrected with LMO commit 849fa7a50dff ("R3k FPU
> ptrace() handling fixes."), and then broken and fixed over and over
> again, until last time fixed with commit 80cbfad79096 ("MIPS: Correct
> MIPS I FP context layout").
> 
> NB running the GDB test suite for the relevant ABI/ISA and watching out 
> for regressions is advisable when poking around ptrace(2).
> 
> Signed-off-by: Maciej W. Rozycki 

Thanks, applied for 4.18.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: ptrace: Make FPU context layout comments match reality

[James Hogan]

On Tue, May 15, 2018 at 11:03:09PM +0100, Maciej W. Rozycki wrote:
> Correct comments across ptrace(2) handlers about an FPU register context
> layout discrepancy between MIPS I and later ISAs, which was fixed with
> `linux-mips.org' (LMO) commit 42533948caac ("Major pile of FP emulator
> changes."), the fix corrected with LMO commit 849fa7a50dff ("R3k FPU
> ptrace() handling fixes."), and then broken and fixed over and over
> again, until last time fixed with commit 80cbfad79096 ("MIPS: Correct
> MIPS I FP context layout").
> 
> NB running the GDB test suite for the relevant ABI/ISA and watching out 
> for regressions is advisable when poking around ptrace(2).
> 
> Signed-off-by: Maciej W. Rozycki 

Thanks, applied for 4.18.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs

[James Hogan]

On Wed, May 16, 2018 at 04:39:58PM +0100, Maciej W. Rozycki wrote:
> Use 64-bit accesses for 64-bit floating-point general registers with 
> PTRACE_PEEKUSR, removing the truncation of their upper halves in the 
> FR=1 mode, caused by commit bbd426f542cb ("MIPS: Simplify FP context 
> access"), which inadvertently switched them to using 32-bit accesses.
> 
> The PTRACE_POKEUSR side is fine as it's never been broken and continues 
> using 64-bit accesses.
> 
> Cc:  # 3.19+
> Fixes: bbd426f542cb ("MIPS: Simplify FP context access")
> Signed-off-by: Maciej W. Rozycki 
> ---
> Hi,
> 
>  Here's another one, spotted in the course of GDB PR gdb/22286 regression 
> testing with the n64 ABI.  Please apply.
> 
>   Maciej

Thanks, applied to mips-fixes, hopefully for 4.17 (but if it misses
tomorrows linux-next it may have to wait 'til 4.18).

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs

[James Hogan]

On Wed, May 16, 2018 at 04:39:58PM +0100, Maciej W. Rozycki wrote:
> Use 64-bit accesses for 64-bit floating-point general registers with 
> PTRACE_PEEKUSR, removing the truncation of their upper halves in the 
> FR=1 mode, caused by commit bbd426f542cb ("MIPS: Simplify FP context 
> access"), which inadvertently switched them to using 32-bit accesses.
> 
> The PTRACE_POKEUSR side is fine as it's never been broken and continues 
> using 64-bit accesses.
> 
> Cc:  # 3.19+
> Fixes: bbd426f542cb ("MIPS: Simplify FP context access")
> Signed-off-by: Maciej W. Rozycki 
> ---
> Hi,
> 
>  Here's another one, spotted in the course of GDB PR gdb/22286 regression 
> testing with the n64 ABI.  Please apply.
> 
>   Maciej

Thanks, applied to mips-fixes, hopefully for 4.17 (but if it misses
tomorrows linux-next it may have to wait 'til 4.18).

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests

[James Hogan]

On Tue, May 15, 2018 at 11:04:44PM +0100, Maciej W. Rozycki wrote:
> Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e. 
> Status.FR) is not supported as the lone purpose of Config5.FRE is to 
> emulate Status.FR=0 handling on FPU hardware that has Status.FR=1 
> hardwired[1][2].  Also we do not handle this case elsewhere, and assume 
> throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot 
> be set both at once for a task, leading to inconsistent behaviour if 
> this does happen.
> 
> Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting 
> PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear.  This corresponds to 
> modes allowed by `mips_set_personality_fp'.
> 
> References:
> 
> [1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32
> Privileged Resource Architecture", Imagination Technologies,
> Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69 
> "Config5 Register Field Descriptions", p. 262
> 
> [2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64 
> Privileged Resource Architecture", Imagination Technologies, 
> Document Number: MD00091, Revision 6.03, December 22, 2015, Table 
> 9.72 "Config5 Register Field Descriptions", p. 288
> 
> Cc: sta...@vger.kernel.org # 4.0+
> Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for 
> MIPS")
> Signed-off-by: Maciej W. Rozycki 

Thanks, applied to mips-fixes, hopefully for 4.17 (but if it misses
tomorrows linux-next it may have to wait 'til 4.18).

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests

[James Hogan]

On Tue, May 15, 2018 at 11:04:44PM +0100, Maciej W. Rozycki wrote:
> Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e. 
> Status.FR) is not supported as the lone purpose of Config5.FRE is to 
> emulate Status.FR=0 handling on FPU hardware that has Status.FR=1 
> hardwired[1][2].  Also we do not handle this case elsewhere, and assume 
> throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot 
> be set both at once for a task, leading to inconsistent behaviour if 
> this does happen.
> 
> Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting 
> PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear.  This corresponds to 
> modes allowed by `mips_set_personality_fp'.
> 
> References:
> 
> [1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32
> Privileged Resource Architecture", Imagination Technologies,
> Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69 
> "Config5 Register Field Descriptions", p. 262
> 
> [2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64 
> Privileged Resource Architecture", Imagination Technologies, 
> Document Number: MD00091, Revision 6.03, December 22, 2015, Table 
> 9.72 "Config5 Register Field Descriptions", p. 288
> 
> Cc: sta...@vger.kernel.org # 4.0+
> Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for 
> MIPS")
> Signed-off-by: Maciej W. Rozycki 

Thanks, applied to mips-fixes, hopefully for 4.17 (but if it misses
tomorrows linux-next it may have to wait 'til 4.18).

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs

[James Hogan]

On Wed, May 16, 2018 at 04:39:58PM +0100, Maciej W. Rozycki wrote:
> Use 64-bit accesses for 64-bit floating-point general registers with 
> PTRACE_PEEKUSR, removing the truncation of their upper halves in the 
> FR=1 mode, caused by commit bbd426f542cb ("MIPS: Simplify FP context 
> access"), which inadvertently switched them to using 32-bit accesses.
> 
> The PTRACE_POKEUSR side is fine as it's never been broken and continues 
> using 64-bit accesses.
> 
> Cc:  # 3.19+

should that be 3.15+?

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs

[James Hogan]

On Wed, May 16, 2018 at 04:39:58PM +0100, Maciej W. Rozycki wrote:
> Use 64-bit accesses for 64-bit floating-point general registers with 
> PTRACE_PEEKUSR, removing the truncation of their upper halves in the 
> FR=1 mode, caused by commit bbd426f542cb ("MIPS: Simplify FP context 
> access"), which inadvertently switched them to using 32-bit accesses.
> 
> The PTRACE_POKEUSR side is fine as it's never been broken and continues 
> using 64-bit accesses.
> 
> Cc:  # 3.19+

should that be 3.15+?

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: lantiq: gphy: Drop reboot/remove reset asserts

[James Hogan]

On Mon, May 21, 2018 at 05:39:32PM +0100, James Hogan wrote:
> On Sun, Apr 08, 2018 at 10:30:03AM +0200, Mathias Kresin wrote:
> > While doing a global software reset, these bits are not cleared and let
> > some bootloader fail to initialise the GPHYs. The bootloader don't
> > expect the GPHYs in reset, as they aren't during power on.
> > 
> > The asserts were a workaround for a wrong syscon-reboot mask. With a
> > mask set which includes the GPHY resets, these resets aren't required
> > any more.
> > 
> > Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU 
> > syscon-mfd")
> > Cc: sta...@vger.kernel.org # 4.14+
> > Signed-off-by: Mathias Kresin <d...@kresin.me>
> 
> Applied for 4.17. Thanks for the acks/reviews folk!

drivers/soc/lantiq/gphy.c: In function ‘xway_gphy_remove’:
drivers/soc/lantiq/gphy.c:198:6: warning: unused variable ‘ret’ 
[-Wunused-variable]
  int ret;
  ^~~
drivers/soc/lantiq/gphy.c:196:17: warning: unused variable ‘dev’ 
[-Wunused-variable]
  struct device *dev = >dev;
 ^~~

Easily fixed, I can drop those two lines:

diff --git a/drivers/soc/lantiq/gphy.c b/drivers/soc/lantiq/gphy.c
index 8c31ae750987..feeb17cebc25 100644
--- a/drivers/soc/lantiq/gphy.c
+++ b/drivers/soc/lantiq/gphy.c
@@ -193,9 +193,7 @@ static int xway_gphy_probe(struct platform_device *pdev)

 static int xway_gphy_remove(struct platform_device *pdev)
 {
-   struct device *dev = >dev;
struct xway_gphy_priv *priv = platform_get_drvdata(pdev);
-   int ret;

iowrite32be(0, priv->membase);

However it does raise the question, it sounds like a fix, but was this
patch tested and the warning just overlooked?

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: lantiq: gphy: Drop reboot/remove reset asserts

[James Hogan]

On Mon, May 21, 2018 at 05:39:32PM +0100, James Hogan wrote:
> On Sun, Apr 08, 2018 at 10:30:03AM +0200, Mathias Kresin wrote:
> > While doing a global software reset, these bits are not cleared and let
> > some bootloader fail to initialise the GPHYs. The bootloader don't
> > expect the GPHYs in reset, as they aren't during power on.
> > 
> > The asserts were a workaround for a wrong syscon-reboot mask. With a
> > mask set which includes the GPHY resets, these resets aren't required
> > any more.
> > 
> > Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU 
> > syscon-mfd")
> > Cc: sta...@vger.kernel.org # 4.14+
> > Signed-off-by: Mathias Kresin 
> 
> Applied for 4.17. Thanks for the acks/reviews folk!

drivers/soc/lantiq/gphy.c: In function ‘xway_gphy_remove’:
drivers/soc/lantiq/gphy.c:198:6: warning: unused variable ‘ret’ 
[-Wunused-variable]
  int ret;
  ^~~
drivers/soc/lantiq/gphy.c:196:17: warning: unused variable ‘dev’ 
[-Wunused-variable]
  struct device *dev = >dev;
 ^~~

Easily fixed, I can drop those two lines:

diff --git a/drivers/soc/lantiq/gphy.c b/drivers/soc/lantiq/gphy.c
index 8c31ae750987..feeb17cebc25 100644
--- a/drivers/soc/lantiq/gphy.c
+++ b/drivers/soc/lantiq/gphy.c
@@ -193,9 +193,7 @@ static int xway_gphy_probe(struct platform_device *pdev)

 static int xway_gphy_remove(struct platform_device *pdev)
 {
-   struct device *dev = >dev;
struct xway_gphy_priv *priv = platform_get_drvdata(pdev);
-   int ret;

iowrite32be(0, priv->membase);

However it does raise the question, it sounds like a fix, but was this
patch tested and the warning just overlooked?

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v1] MIPS: PCI: Use dev_printk() when possible

[James Hogan]

On Tue, May 22, 2018 at 08:11:42AM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas <bhelg...@google.com>
> 
> Use the pci_info() and pci_err() wrappers for dev_printk() when possible.
> 
> Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
> ---
>  arch/mips/pci/pci-legacy.c |7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/mips/pci/pci-legacy.c b/arch/mips/pci/pci-legacy.c
> index 0c65c38e05d6..73643e80f02d 100644
> --- a/arch/mips/pci/pci-legacy.c
> +++ b/arch/mips/pci/pci-legacy.c
> @@ -263,9 +263,7 @@ static int pcibios_enable_resources(struct pci_dev *dev, 
> int mask)
>   (!(r->flags & IORESOURCE_ROM_ENABLE)))
>   continue;
>   if (!r->start && r->end) {
> - printk(KERN_ERR "PCI: Device %s not available "
> -"because of resource collisions\n",
> -pci_name(dev));
> + pci_err(dev, "can't enable device: resource 
> collisions\n");

The pedantic side of me wants to point out that you could wrap that line
after the comma to keep it within 80 columns.

Either way though:
Acked-by: James Hogan <jho...@kernel.org>

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v1] MIPS: PCI: Use dev_printk() when possible

[James Hogan]

On Tue, May 22, 2018 at 08:11:42AM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas 
> 
> Use the pci_info() and pci_err() wrappers for dev_printk() when possible.
> 
> Signed-off-by: Bjorn Helgaas 
> ---
>  arch/mips/pci/pci-legacy.c |7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/mips/pci/pci-legacy.c b/arch/mips/pci/pci-legacy.c
> index 0c65c38e05d6..73643e80f02d 100644
> --- a/arch/mips/pci/pci-legacy.c
> +++ b/arch/mips/pci/pci-legacy.c
> @@ -263,9 +263,7 @@ static int pcibios_enable_resources(struct pci_dev *dev, 
> int mask)
>   (!(r->flags & IORESOURCE_ROM_ENABLE)))
>   continue;
>   if (!r->start && r->end) {
> - printk(KERN_ERR "PCI: Device %s not available "
> -"because of resource collisions\n",
> -pci_name(dev));
> + pci_err(dev, "can't enable device: resource 
> collisions\n");

The pedantic side of me wants to point out that you could wrap that line
after the comma to keep it within 80 columns.

Either way though:
Acked-by: James Hogan 

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: lantiq: gphy: Drop reboot/remove reset asserts

[James Hogan]

On Sun, Apr 08, 2018 at 10:30:03AM +0200, Mathias Kresin wrote:
> While doing a global software reset, these bits are not cleared and let
> some bootloader fail to initialise the GPHYs. The bootloader don't
> expect the GPHYs in reset, as they aren't during power on.
> 
> The asserts were a workaround for a wrong syscon-reboot mask. With a
> mask set which includes the GPHY resets, these resets aren't required
> any more.
> 
> Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU 
> syscon-mfd")
> Cc: sta...@vger.kernel.org # 4.14+
> Signed-off-by: Mathias Kresin 

Applied for 4.17. Thanks for the acks/reviews folk!

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: lantiq: gphy: Drop reboot/remove reset asserts

[James Hogan]

On Sun, Apr 08, 2018 at 10:30:03AM +0200, Mathias Kresin wrote:
> While doing a global software reset, these bits are not cleared and let
> some bootloader fail to initialise the GPHYs. The bootloader don't
> expect the GPHYs in reset, as they aren't during power on.
> 
> The asserts were a workaround for a wrong syscon-reboot mask. With a
> mask set which includes the GPHY resets, these resets aren't required
> any more.
> 
> Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU 
> syscon-mfd")
> Cc: sta...@vger.kernel.org # 4.14+
> Signed-off-by: Mathias Kresin 

Applied for 4.17. Thanks for the acks/reviews folk!

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v2 4/4] MIPS: memset.S: Add comments to fault fixup handlers

[James Hogan]

On Tue, Apr 17, 2018 at 04:40:03PM +0100, Matt Redfearn wrote:
> diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S
> index 1cc306520a55..a06dabe99d4b 100644
> --- a/arch/mips/lib/memset.S
> +++ b/arch/mips/lib/memset.S
> @@ -231,16 +231,25 @@
>  
>  #ifdef CONFIG_CPU_MIPSR6
>  .Lbyte_fixup\@:
> + /*
> +  * unset_bytes = current_addr + 1
> +  *  a2 =  t0  + 1

The code looks more like a2 = 1 - t0 to me:

> +  */
>   PTR_SUBUa2, $0, t0
>   jr  ra
>PTR_ADDIU  a2, 1

I.e. t0 counts up to 1 and then stops.

Anyway I've applied patch 3 for 4.18.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v2 4/4] MIPS: memset.S: Add comments to fault fixup handlers

[James Hogan]

On Tue, Apr 17, 2018 at 04:40:03PM +0100, Matt Redfearn wrote:
> diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S
> index 1cc306520a55..a06dabe99d4b 100644
> --- a/arch/mips/lib/memset.S
> +++ b/arch/mips/lib/memset.S
> @@ -231,16 +231,25 @@
>  
>  #ifdef CONFIG_CPU_MIPSR6
>  .Lbyte_fixup\@:
> + /*
> +  * unset_bytes = current_addr + 1
> +  *  a2 =  t0  + 1

The code looks more like a2 = 1 - t0 to me:

> +  */
>   PTR_SUBUa2, $0, t0
>   jr  ra
>PTR_ADDIU  a2, 1

I.e. t0 counts up to 1 and then stops.

Anyway I've applied patch 3 for 4.18.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH 7/7] aio: implement io_pgetevents

[James Hogan]

Given this:

On Wed, May 02, 2018 at 11:14:48PM +0200, Christoph Hellwig wrote:
> +struct __aio_sigset {
> + sigset_t __user *sigmask;
> + size_t  sigsetsize;
> +};

and:

> +asmlinkage long sys_io_pgetevents(aio_context_t ctx_id,
> + long min_nr,
> + long nr,
> + struct io_event __user *events,
> + struct timespec __user *timeout,
> + const struct __aio_sigset *sig);

The following paragraph in the commit message would appear to be
misleading since __aio_sigset contains a size:

> Note that unlike many other signal related calls we do not pass a sigmask
> size, as that would get us to 7 arguments, which aren't easily supported
> by the syscall infrastructure.  It seems a lot less painful to just add a
> new syscall variant in the unlikely case we're going to increase the
> sigset size.

Is it possible to correct it before this gets merged?

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH 7/7] aio: implement io_pgetevents

[James Hogan]

Given this:

On Wed, May 02, 2018 at 11:14:48PM +0200, Christoph Hellwig wrote:
> +struct __aio_sigset {
> + sigset_t __user *sigmask;
> + size_t  sigsetsize;
> +};

and:

> +asmlinkage long sys_io_pgetevents(aio_context_t ctx_id,
> + long min_nr,
> + long nr,
> + struct io_event __user *events,
> + struct timespec __user *timeout,
> + const struct __aio_sigset *sig);

The following paragraph in the commit message would appear to be
misleading since __aio_sigset contains a size:

> Note that unlike many other signal related calls we do not pass a sigmask
> size, as that would get us to 7 arguments, which aren't easily supported
> by the syscall infrastructure.  It seems a lot less painful to just add a
> new syscall variant in the unlikely case we're going to increase the
> sigset size.

Is it possible to correct it before this gets merged?

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH 1/6] MIPS: Move ehb() to barrier.h

[James Hogan]

On Fri, Jan 05, 2018 at 10:31:05AM +, Matt Redfearn wrote:
> The current location of ehb() in mipsmtregs.h does not make sense, since
> it is not strictly related to multi-threading, and may be used in code
> which does not include mipsmtregs.h

>  arch/mips/include/asm/barrier.h| 13 +
>  arch/mips/include/asm/mipsmtregs.h |  8 

But ehb isn't really a memory barrier like the other barriers in
barrier.h, its an execution hazard barrier, as used when available by
the hazard macros in hazards.h, and in fact there is already an _ehb()
there.

I suspect the intention was that most MIPS arch code using ehb would do
so using the appropriate hazard abstractions, which would do the right
number of NOPs on hardware without the EHB instruction. Code that is
specific to certain arch revisions (like the MIPS MT code and MIPS KVM)
can get away with using _ehb/ehb, but should use the abstractions where
they exist to make intentions clear.

None of the specific hazards in hazards.h really match the case in patch
2, I suppose you could have a new sync_mfc0_hazard() macro, but its so
specific and EHB should be guaranteed to exist there, so perhaps _ehb()
should just be used instead of ehb() there? (with a comment to describe
what operations are being protected from what hazards).

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH 1/6] MIPS: Move ehb() to barrier.h

[James Hogan]

On Fri, Jan 05, 2018 at 10:31:05AM +, Matt Redfearn wrote:
> The current location of ehb() in mipsmtregs.h does not make sense, since
> it is not strictly related to multi-threading, and may be used in code
> which does not include mipsmtregs.h

>  arch/mips/include/asm/barrier.h| 13 +
>  arch/mips/include/asm/mipsmtregs.h |  8 

But ehb isn't really a memory barrier like the other barriers in
barrier.h, its an execution hazard barrier, as used when available by
the hazard macros in hazards.h, and in fact there is already an _ehb()
there.

I suspect the intention was that most MIPS arch code using ehb would do
so using the appropriate hazard abstractions, which would do the right
number of NOPs on hardware without the EHB instruction. Code that is
specific to certain arch revisions (like the MIPS MT code and MIPS KVM)
can get away with using _ehb/ehb, but should use the abstractions where
they exist to make intentions clear.

None of the specific hazards in hazards.h really match the case in patch
2, I suppose you could have a new sync_mfc0_hazard() macro, but its so
specific and EHB should be guaranteed to exist there, so perhaps _ehb()
should just be used instead of ehb() there? (with a comment to describe
what operations are being protected from what hazards).

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v3 5/7] MIPS: perf: Allocate per-core counters on demand

[James Hogan]

On Fri, Apr 20, 2018 at 11:23:07AM +0100, Matt Redfearn wrote:
> Previously when performance counters are per-core, rather than
> per-thread, the number available were divided by 2 on detection, and the
> counters used by each thread in a core were "swizzled" to ensure
> separation. However, this solution is suboptimal since it relies on a
> couple of assumptions:
> a) Always having 2 VPEs / core (number of counters was divided by 2)
> b) Always having a number of counters implemented in the core that is
>divisible by 2. For instance if an SoC implementation had a single
>counter and 2 VPEs per core, then this logic would fail and no
>performance counters would be available.
> The mechanism also does not allow for one VPE in a core using more than
> it's allocation of the per-core counters to count multiple events even
> though other VPEs may not be using them.
> 
> Fix this situation by instead allocating (and releasing) per-core
> performance counters when they are requested. This approach removes the
> above assumptions and fixes the shortcomings.
> 
> In order to do this:
> Add additional logic to mipsxx_pmu_alloc_counter() to detect if a
> sibling is using a per-core counter, and to allocate a per-core counter
> in all sibling CPUs.
> Similarly, add a mipsxx_pmu_free_counter() function to release a
> per-core counter in all sibling CPUs when it is finished with.
> A new spinlock, core_counters_lock, is introduced to ensure exclusivity
> when allocating and releasing per-core counters.
> Since counters are now allocated per-core on demand, rather than being
> reserved per-thread at boot, all of the "swizzling" of counters is
> removed.
> 
> The upshot is that in an SoC with 2 counters / thread, counters are
> reported as:
> Performance counters: mips/interAptiv PMU enabled, 2 32-bit counters
> available to each CPU, irq 18
> 
> Running an instance of a test program on each of 2 threads in a
> core, both threads can use their 2 counters to count 2 events:
> 
> taskset 4 perf stat -e instructions:u,branches:u ./test_prog & taskset 8
> perf stat -e instructions:u,branches:u ./test_prog
> 
>  Performance counter stats for './test_prog':
> 
>  30002  instructions:u
>  1  branches:u
> 
>0.005164264 seconds time elapsed
>  Performance counter stats for './test_prog':
> 
>  30002  instructions:u
>  1  branches:u
> 
>0.006139975 seconds time elapsed
> 
> In an SoC with 2 counters / core (which can be forced by setting
> cpu_has_mipsmt_pertccounters = 0), counters are reported as:
> Performance counters: mips/interAptiv PMU enabled, 2 32-bit counters
> available to each core, irq 18
> 
> Running an instance of a test program on each of 2 threads in a
> core, now only one thread manages to secure the performance counters to
> count 2 events. The other thread does not get any counters.
> 
> taskset 4 perf stat -e instructions:u,branches:u ./test_prog & taskset 8
> perf stat -e instructions:u,branches:u ./test_prog
> 
>  Performance counter stats for './test_prog':
> 
> instructions:u
> branches:u
> 
>0.005179533 seconds time elapsed
> 
>  Performance counter stats for './test_prog':
> 
>  30002  instructions:u
>  1  branches:u
> 
>0.005179467 seconds time elapsed
> 
> Signed-off-by: Matt Redfearn 

While this sounds like an improvement in practice, being able to use
more counters on single threaded stuff than otherwise, I'm a little
concerned what would happen if a task was migrated to a different CPU
and the perf counters couldn't be obtained on the new CPU due to
counters already being in use. Would the values be incorrectly small?

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v3 5/7] MIPS: perf: Allocate per-core counters on demand

[James Hogan]

On Fri, Apr 20, 2018 at 11:23:07AM +0100, Matt Redfearn wrote:
> Previously when performance counters are per-core, rather than
> per-thread, the number available were divided by 2 on detection, and the
> counters used by each thread in a core were "swizzled" to ensure
> separation. However, this solution is suboptimal since it relies on a
> couple of assumptions:
> a) Always having 2 VPEs / core (number of counters was divided by 2)
> b) Always having a number of counters implemented in the core that is
>divisible by 2. For instance if an SoC implementation had a single
>counter and 2 VPEs per core, then this logic would fail and no
>performance counters would be available.
> The mechanism also does not allow for one VPE in a core using more than
> it's allocation of the per-core counters to count multiple events even
> though other VPEs may not be using them.
> 
> Fix this situation by instead allocating (and releasing) per-core
> performance counters when they are requested. This approach removes the
> above assumptions and fixes the shortcomings.
> 
> In order to do this:
> Add additional logic to mipsxx_pmu_alloc_counter() to detect if a
> sibling is using a per-core counter, and to allocate a per-core counter
> in all sibling CPUs.
> Similarly, add a mipsxx_pmu_free_counter() function to release a
> per-core counter in all sibling CPUs when it is finished with.
> A new spinlock, core_counters_lock, is introduced to ensure exclusivity
> when allocating and releasing per-core counters.
> Since counters are now allocated per-core on demand, rather than being
> reserved per-thread at boot, all of the "swizzling" of counters is
> removed.
> 
> The upshot is that in an SoC with 2 counters / thread, counters are
> reported as:
> Performance counters: mips/interAptiv PMU enabled, 2 32-bit counters
> available to each CPU, irq 18
> 
> Running an instance of a test program on each of 2 threads in a
> core, both threads can use their 2 counters to count 2 events:
> 
> taskset 4 perf stat -e instructions:u,branches:u ./test_prog & taskset 8
> perf stat -e instructions:u,branches:u ./test_prog
> 
>  Performance counter stats for './test_prog':
> 
>  30002  instructions:u
>  1  branches:u
> 
>0.005164264 seconds time elapsed
>  Performance counter stats for './test_prog':
> 
>  30002  instructions:u
>  1  branches:u
> 
>0.006139975 seconds time elapsed
> 
> In an SoC with 2 counters / core (which can be forced by setting
> cpu_has_mipsmt_pertccounters = 0), counters are reported as:
> Performance counters: mips/interAptiv PMU enabled, 2 32-bit counters
> available to each core, irq 18
> 
> Running an instance of a test program on each of 2 threads in a
> core, now only one thread manages to secure the performance counters to
> count 2 events. The other thread does not get any counters.
> 
> taskset 4 perf stat -e instructions:u,branches:u ./test_prog & taskset 8
> perf stat -e instructions:u,branches:u ./test_prog
> 
>  Performance counter stats for './test_prog':
> 
> instructions:u
> branches:u
> 
>0.005179533 seconds time elapsed
> 
>  Performance counter stats for './test_prog':
> 
>  30002  instructions:u
>  1  branches:u
> 
>0.005179467 seconds time elapsed
> 
> Signed-off-by: Matt Redfearn 

While this sounds like an improvement in practice, being able to use
more counters on single threaded stuff than otherwise, I'm a little
concerned what would happen if a task was migrated to a different CPU
and the perf counters couldn't be obtained on the new CPU due to
counters already being in use. Would the values be incorrectly small?

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v3 4/7] MIPS: perf: Fix perf with MT counting other threads

[James Hogan]

On Fri, Apr 20, 2018 at 11:23:06AM +0100, Matt Redfearn wrote:
> diff --git a/arch/mips/kernel/perf_event_mipsxx.c 
> b/arch/mips/kernel/perf_event_mipsxx.c
> index 7e2b7d38a774..fe50986e83c6 100644
> --- a/arch/mips/kernel/perf_event_mipsxx.c
> +++ b/arch/mips/kernel/perf_event_mipsxx.c
> @@ -323,7 +323,11 @@ static int mipsxx_pmu_alloc_counter(struct cpu_hw_events 
> *cpuc,
>  
>  static void mipsxx_pmu_enable_event(struct hw_perf_event *evt, int idx)
>  {
> + struct perf_event *event = container_of(evt, struct perf_event, hw);
>   struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
> +#ifdef CONFIG_MIPS_MT_SMP
> + unsigned int range = evt->event_base >> 24;
> +#endif /* CONFIG_MIPS_MT_SMP */
>  
>   WARN_ON(idx < 0 || idx >= mipspmu.num_counters);
>  
> @@ -331,11 +335,37 @@ static void mipsxx_pmu_enable_event(struct 
> hw_perf_event *evt, int idx)
>   (evt->config_base & M_PERFCTL_CONFIG_MASK) |
>   /* Make sure interrupt enabled. */
>   MIPS_PERFCTRL_IE;
> - if (IS_ENABLED(CONFIG_CPU_BMIPS5000))
> +
> +#ifdef CONFIG_CPU_BMIPS5000
> + {
>   /* enable the counter for the calling thread */
>   cpuc->saved_ctrl[idx] |=
>   (1 << (12 + vpe_id())) | BRCM_PERFCTRL_TC;
> + }
> +#else
> +#ifdef CONFIG_MIPS_MT_SMP
> + if (range > V) {
> + /* The counter is processor wide. Set it up to count all TCs. */
> + pr_debug("Enabling perf counter for all TCs\n");
> + cpuc->saved_ctrl[idx] |= M_TC_EN_ALL;
> + } else
> +#endif /* CONFIG_MIPS_MT_SMP */
> + {
> + unsigned int cpu, ctrl;
>  
> + /*
> +  * Set up the counter for a particular CPU when event->cpu is
> +  * a valid CPU number. Otherwise set up the counter for the CPU
> +  * scheduling this thread.
> +  */
> + cpu = (event->cpu >= 0) ? event->cpu : smp_processor_id();
> +
> + ctrl = M_PERFCTL_VPEID(cpu_vpe_id(_data[cpu]));
> + ctrl |= M_TC_EN_VPE;
> + cpuc->saved_ctrl[idx] |= ctrl;
> + pr_debug("Enabling perf counter for CPU%d\n", cpu);
> + }
> +#endif /* CONFIG_CPU_BMIPS5000 */

I'm not a huge fan of the ifdefery tbh, I don't think it makes it very
easy to read having a combination of ifs and #ifdefs. I reckon
IF_ENABLED would be better, perhaps with having the BMIPS5000 case
return to avoid too much nesting.

Otherwise the patch looks okay to me.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v3 4/7] MIPS: perf: Fix perf with MT counting other threads

[James Hogan]

On Fri, Apr 20, 2018 at 11:23:06AM +0100, Matt Redfearn wrote:
> diff --git a/arch/mips/kernel/perf_event_mipsxx.c 
> b/arch/mips/kernel/perf_event_mipsxx.c
> index 7e2b7d38a774..fe50986e83c6 100644
> --- a/arch/mips/kernel/perf_event_mipsxx.c
> +++ b/arch/mips/kernel/perf_event_mipsxx.c
> @@ -323,7 +323,11 @@ static int mipsxx_pmu_alloc_counter(struct cpu_hw_events 
> *cpuc,
>  
>  static void mipsxx_pmu_enable_event(struct hw_perf_event *evt, int idx)
>  {
> + struct perf_event *event = container_of(evt, struct perf_event, hw);
>   struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
> +#ifdef CONFIG_MIPS_MT_SMP
> + unsigned int range = evt->event_base >> 24;
> +#endif /* CONFIG_MIPS_MT_SMP */
>  
>   WARN_ON(idx < 0 || idx >= mipspmu.num_counters);
>  
> @@ -331,11 +335,37 @@ static void mipsxx_pmu_enable_event(struct 
> hw_perf_event *evt, int idx)
>   (evt->config_base & M_PERFCTL_CONFIG_MASK) |
>   /* Make sure interrupt enabled. */
>   MIPS_PERFCTRL_IE;
> - if (IS_ENABLED(CONFIG_CPU_BMIPS5000))
> +
> +#ifdef CONFIG_CPU_BMIPS5000
> + {
>   /* enable the counter for the calling thread */
>   cpuc->saved_ctrl[idx] |=
>   (1 << (12 + vpe_id())) | BRCM_PERFCTRL_TC;
> + }
> +#else
> +#ifdef CONFIG_MIPS_MT_SMP
> + if (range > V) {
> + /* The counter is processor wide. Set it up to count all TCs. */
> + pr_debug("Enabling perf counter for all TCs\n");
> + cpuc->saved_ctrl[idx] |= M_TC_EN_ALL;
> + } else
> +#endif /* CONFIG_MIPS_MT_SMP */
> + {
> + unsigned int cpu, ctrl;
>  
> + /*
> +  * Set up the counter for a particular CPU when event->cpu is
> +  * a valid CPU number. Otherwise set up the counter for the CPU
> +  * scheduling this thread.
> +  */
> + cpu = (event->cpu >= 0) ? event->cpu : smp_processor_id();
> +
> + ctrl = M_PERFCTL_VPEID(cpu_vpe_id(_data[cpu]));
> + ctrl |= M_TC_EN_VPE;
> + cpuc->saved_ctrl[idx] |= ctrl;
> + pr_debug("Enabling perf counter for CPU%d\n", cpu);
> + }
> +#endif /* CONFIG_CPU_BMIPS5000 */

I'm not a huge fan of the ifdefery tbh, I don't think it makes it very
easy to read having a combination of ifs and #ifdefs. I reckon
IF_ENABLED would be better, perhaps with having the BMIPS5000 case
return to avoid too much nesting.

Otherwise the patch looks okay to me.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs

[James Hogan]

On Mon, May 14, 2018 at 04:49:43PM +0100, Maciej W. Rozycki wrote:
> Check the TIF_32BIT_FPREGS task setting of the tracee rather than the 
> tracer in determining the layout of floating-point general registers in 
> the floating-point context, correcting access to odd-numbered registers 
> for o32 tracees where the setting disagrees between the two processes.
> 
> Cc: sta...@vger.kernel.org # 3.14+
> Fixes: 597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries")
> Signed-off-by: Maciej W. Rozycki 
> ---
> Hi,
> 
>  These are not the usual requests used by GDB to access the floating-point 
> context, which is likely why it went unnoticed so long.  They are only 
> used as a fallback in the case where PTRACE_GETFPREGS and PTRACE_SETFPREGS 
> requests are not supported, i.e. with ancient kernels.
> 
>  However to verify an unrelated GDB bug fix I have tweaked GDB to always 
> use PTRACE_PEEKUSR and PTRACE_POKEUSR, and then discovered this issue in 
> native GDB regression testing, as it showed regressions from corrupt FGR 
> contents across numerous tests compared to the usual results.  This fix 
> removed those regressions then.
> 
>  Not being typically used does not mean we ought to keep the interface 
> broken.  Therefore please apply.

Looks good. Applied to fixes branch for 4.17.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs

[James Hogan]

On Mon, May 14, 2018 at 04:49:43PM +0100, Maciej W. Rozycki wrote:
> Check the TIF_32BIT_FPREGS task setting of the tracee rather than the 
> tracer in determining the layout of floating-point general registers in 
> the floating-point context, correcting access to odd-numbered registers 
> for o32 tracees where the setting disagrees between the two processes.
> 
> Cc: sta...@vger.kernel.org # 3.14+
> Fixes: 597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries")
> Signed-off-by: Maciej W. Rozycki 
> ---
> Hi,
> 
>  These are not the usual requests used by GDB to access the floating-point 
> context, which is likely why it went unnoticed so long.  They are only 
> used as a fallback in the case where PTRACE_GETFPREGS and PTRACE_SETFPREGS 
> requests are not supported, i.e. with ancient kernels.
> 
>  However to verify an unrelated GDB bug fix I have tweaked GDB to always 
> use PTRACE_PEEKUSR and PTRACE_POKEUSR, and then discovered this issue in 
> native GDB regression testing, as it showed regressions from corrupt FGR 
> contents across numerous tests compared to the usual results.  This fix 
> removed those regressions then.
> 
>  Not being typically used does not mean we ought to keep the interface 
> broken.  Therefore please apply.

Looks good. Applied to fixes branch for 4.17.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH 1/2] mips: xilfpga: stop generating useless dtb.o

[James Hogan]

On Wed, Apr 25, 2018 at 11:10:35PM +0200, Alexandre Belloni wrote:
> a dtb.o is generated from nexys4ddr.dts but this is never used since it has
> been moved to mips/generic with commit b35565bb16a5 ("MIPS: generic: Add 
> support
> for MIPSfpga")
> 
> Signed-off-by: Alexandre Belloni 

Both applied for 4.17, with fixes and stable tag (4.15+).

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH 1/2] mips: xilfpga: stop generating useless dtb.o

[James Hogan]

On Wed, Apr 25, 2018 at 11:10:35PM +0200, Alexandre Belloni wrote:
> a dtb.o is generated from nexys4ddr.dts but this is never used since it has
> been moved to mips/generic with commit b35565bb16a5 ("MIPS: generic: Add 
> support
> for MIPSfpga")
> 
> Signed-off-by: Alexandre Belloni 

Both applied for 4.17, with fixes and stable tag (4.15+).

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH] KVM: fix spelling mistake: "cop_unsuable" -> "cop_unusable"

[James Hogan]

On Mon, May 14, 2018 at 06:23:50PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in debugfs_entries text
> 
> Signed-off-by: Colin Ian King 

Adding KVM folk. Its a fairly trivial change so I'll just take it as a
fix via the MIPS tree unless anybody objects.

This does change the name of one of the stats counters debugfs files
though (which I have no doubt isn't relied upon by anything), so I've
added:

Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
Cc:  # 3.10+

Thanks
James

> ---
>  arch/mips/kvm/mips.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index 2549fdd27ee1..0f725e9cee8f 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -45,7 +45,7 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>   { "cache",VCPU_STAT(cache_exits),KVM_STAT_VCPU },
>   { "signal",   VCPU_STAT(signal_exits),   KVM_STAT_VCPU },
>   { "interrupt",VCPU_STAT(int_exits),  KVM_STAT_VCPU },
> - { "cop_unsuable", VCPU_STAT(cop_unusable_exits), KVM_STAT_VCPU },
> + { "cop_unusable", VCPU_STAT(cop_unusable_exits), KVM_STAT_VCPU },
>   { "tlbmod",   VCPU_STAT(tlbmod_exits),   KVM_STAT_VCPU },
>   { "tlbmiss_ld",   VCPU_STAT(tlbmiss_ld_exits),   KVM_STAT_VCPU },
>   { "tlbmiss_st",   VCPU_STAT(tlbmiss_st_exits),   KVM_STAT_VCPU },
> -- 
> 2.17.0
> 


signature.asc
Description: PGP signature

Re: [PATCH] KVM: fix spelling mistake: "cop_unsuable" -> "cop_unusable"

[James Hogan]

On Mon, May 14, 2018 at 06:23:50PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in debugfs_entries text
> 
> Signed-off-by: Colin Ian King 

Adding KVM folk. Its a fairly trivial change so I'll just take it as a
fix via the MIPS tree unless anybody objects.

This does change the name of one of the stats counters debugfs files
though (which I have no doubt isn't relied upon by anything), so I've
added:

Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
Cc:  # 3.10+

Thanks
James

> ---
>  arch/mips/kvm/mips.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index 2549fdd27ee1..0f725e9cee8f 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -45,7 +45,7 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>   { "cache",VCPU_STAT(cache_exits),KVM_STAT_VCPU },
>   { "signal",   VCPU_STAT(signal_exits),   KVM_STAT_VCPU },
>   { "interrupt",VCPU_STAT(int_exits),  KVM_STAT_VCPU },
> - { "cop_unsuable", VCPU_STAT(cop_unusable_exits), KVM_STAT_VCPU },
> + { "cop_unusable", VCPU_STAT(cop_unusable_exits), KVM_STAT_VCPU },
>   { "tlbmod",   VCPU_STAT(tlbmod_exits),   KVM_STAT_VCPU },
>   { "tlbmiss_ld",   VCPU_STAT(tlbmiss_ld_exits),   KVM_STAT_VCPU },
>   { "tlbmiss_st",   VCPU_STAT(tlbmiss_st_exits),   KVM_STAT_VCPU },
> -- 
> 2.17.0
> 


signature.asc
Description: PGP signature

Re: [PATCH net-next v3 0/7] Microsemi Ocelot Ethernet switch support

[James Hogan]

On Mon, May 14, 2018 at 10:58:44PM +0200, Andrew Lunn wrote:
> Hi Alexandre
> > 
> > The ocelot dts changes are here for reference and should probably go
> > through the MIPS tree once the bindings are accepted.
> 
> For your next version, you probably want to drop those patches, so
> that David can apply the network patches to net-next.

Since it sounds like the net patches are ready now, I'll apply the MIPS
DTS ones for 4.18.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH net-next v3 0/7] Microsemi Ocelot Ethernet switch support

[James Hogan]

On Mon, May 14, 2018 at 10:58:44PM +0200, Andrew Lunn wrote:
> Hi Alexandre
> > 
> > The ocelot dts changes are here for reference and should probably go
> > through the MIPS tree once the bindings are accepted.
> 
> For your next version, you probably want to drop those patches, so
> that David can apply the network patches to net-next.

Since it sounds like the net patches are ready now, I'll apply the MIPS
DTS ones for 4.18.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

[James Hogan]

On Mon, May 14, 2018 at 11:37:20PM +0200, Wolfram Sang wrote:
> > diff --git a/arch/mips/alchemy/board-gpr.c b/arch/mips/alchemy/board-gpr.c
> > index 4e79dbd54a33..fa75d75b5ba9 100644
> > --- a/arch/mips/alchemy/board-gpr.c
> > +++ b/arch/mips/alchemy/board-gpr.c
> > @@ -29,7 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 

Acked-by: James Hogan <jho...@kernel.org>

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

[James Hogan]

On Mon, May 14, 2018 at 11:37:20PM +0200, Wolfram Sang wrote:
> > diff --git a/arch/mips/alchemy/board-gpr.c b/arch/mips/alchemy/board-gpr.c
> > index 4e79dbd54a33..fa75d75b5ba9 100644
> > --- a/arch/mips/alchemy/board-gpr.c
> > +++ b/arch/mips/alchemy/board-gpr.c
> > @@ -29,7 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 

Acked-by: James Hogan 

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v2] MIPS: c-r4k: fix data corruption related to cache coherence.

[James Hogan]

On Tue, May 08, 2018 at 11:22:36AM +1000, NeilBrown wrote:
> On Mon, May 07 2018, James Hogan wrote:
> 
> > On Mon, May 07, 2018 at 07:40:49AM +1000, NeilBrown wrote:
> >> 
> >> Hi James,
> >>  this hasn't appear in linux-next yet, or in any branch
> >>  of
> >>git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git
> >> 
> >>  Should I expect it to?
> >
> > Sorry Neil, I haven't applied it yet. I'm planning to get a few fixes
> > sorted this week, at which point it would land in the mips-fixes branch
> > at the above repo.
> 
> Cool, thanks.  I just wanted to be sure it hadn't got lost somehow.

Now pushed.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v2] MIPS: c-r4k: fix data corruption related to cache coherence.

[James Hogan]

On Tue, May 08, 2018 at 11:22:36AM +1000, NeilBrown wrote:
> On Mon, May 07 2018, James Hogan wrote:
> 
> > On Mon, May 07, 2018 at 07:40:49AM +1000, NeilBrown wrote:
> >> 
> >> Hi James,
> >>  this hasn't appear in linux-next yet, or in any branch
> >>  of
> >>git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git
> >> 
> >>  Should I expect it to?
> >
> > Sorry Neil, I haven't applied it yet. I'm planning to get a few fixes
> > sorted this week, at which point it would land in the mips-fixes branch
> > at the above repo.
> 
> Cool, thanks.  I just wanted to be sure it hadn't got lost somehow.

Now pushed.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v2] MIPS: Fix build with DEBUG_ZBOOT and MACH_JZ4770

[James Hogan]

On Wed, Mar 28, 2018 at 05:38:12PM +0200, Paul Cercueil wrote:
> The debug definitions were missing for MACH_JZ4770, resulting in a build
> failure when DEBUG_ZBOOT was set.
> 
> Since the UART addresses are the same across all Ingenic SoCs, we just
> use a #ifdef CONFIG_MACH_INGENIC instead of checking for individual
> Ingenic SoCs.
> 
> Additionally, I added a #define for the UART0 address in-code and dropped
> the  include, for the reason that this include
> file is slowly being phased out as the whole platform is being moved to
> devicetree.
> 
> Signed-off-by: Paul Cercueil 

Applied for 4.17 with fixes tag and 4.16 stable tag.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v2] MIPS: Fix build with DEBUG_ZBOOT and MACH_JZ4770

[James Hogan]

On Wed, Mar 28, 2018 at 05:38:12PM +0200, Paul Cercueil wrote:
> The debug definitions were missing for MACH_JZ4770, resulting in a build
> failure when DEBUG_ZBOOT was set.
> 
> Since the UART addresses are the same across all Ingenic SoCs, we just
> use a #ifdef CONFIG_MACH_INGENIC instead of checking for individual
> Ingenic SoCs.
> 
> Additionally, I added a #define for the UART0 address in-code and dropped
> the  include, for the reason that this include
> file is slowly being phased out as the whole platform is being moved to
> devicetree.
> 
> Signed-off-by: Paul Cercueil 

Applied for 4.17 with fixes tag and 4.16 stable tag.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

[James Hogan]

On Fri, May 11, 2018 at 02:14:16PM -0700, Guenter Roeck wrote:
> On Fri, May 11, 2018 at 09:54:14PM +0100, James Hogan wrote:
> > On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote:
> > > Le 11 mai 2018 11:52, James Hogan <jho...@kernel.org> a écrit :
> > > > Otherwise 
> > > > Acked-by: James Hogan <jho...@kernel.org> 
> > > >
> > > > I'm happy to apply for 4.18 with that change if you want it to go 
> > > > through the MIPS tree. 
> > > 
> > > Yes please!
> > 
> > Done
> > 
> Does that include the watchdog changes ? No problem with it, just asking to 
> make
> sure that those don't get lost.

Yes, I suppose I was taking your reviewed-by as an ack.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

[James Hogan]

On Fri, May 11, 2018 at 02:14:16PM -0700, Guenter Roeck wrote:
> On Fri, May 11, 2018 at 09:54:14PM +0100, James Hogan wrote:
> > On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote:
> > > Le 11 mai 2018 11:52, James Hogan  a écrit :
> > > > Otherwise 
> > > > Acked-by: James Hogan  
> > > >
> > > > I'm happy to apply for 4.18 with that change if you want it to go 
> > > > through the MIPS tree. 
> > > 
> > > Yes please!
> > 
> > Done
> > 
> Does that include the watchdog changes ? No problem with it, just asking to 
> make
> sure that those don't get lost.

Yes, I suppose I was taking your reviewed-by as an ack.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

[James Hogan]

On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote:
> Le 11 mai 2018 11:52, James Hogan <jho...@kernel.org> a écrit :
> > Otherwise 
> > Acked-by: James Hogan <jho...@kernel.org> 
> >
> > I'm happy to apply for 4.18 with that change if you want it to go 
> > through the MIPS tree. 
> 
> Yes please!

Done

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

[James Hogan]

On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote:
> Le 11 mai 2018 11:52, James Hogan  a écrit :
> > Otherwise 
> > Acked-by: James Hogan  
> >
> > I'm happy to apply for 4.18 with that change if you want it to go 
> > through the MIPS tree. 
> 
> Yes please!

Done

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

[James Hogan]

On Thu, May 10, 2018 at 08:47:48PM +0200, Paul Cercueil wrote:
> Also remove the watchdog platform_device from platform.c, since it
> wasn't used anywhere anyway.

Nit: it'd be slightly nicer IMO if the patch body was a superset of the
subject line. It's fine to repeat what the subject says since thats
meant to summarise the body.

> -struct platform_device jz4740_wdt_device = {

There's an extern in arch/mips/include/asm/mach-jz4740/platform.h that
should perhaps be removed also?

Otherwise
Acked-by: James Hogan <jho...@kernel.org>

I'm happy to apply for 4.18 with that change if you want it to go
through the MIPS tree.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

[James Hogan]

On Thu, May 10, 2018 at 08:47:48PM +0200, Paul Cercueil wrote:
> Also remove the watchdog platform_device from platform.c, since it
> wasn't used anywhere anyway.

Nit: it'd be slightly nicer IMO if the patch body was a superset of the
subject line. It's fine to repeat what the subject says since thats
meant to summarise the body.

> -struct platform_device jz4740_wdt_device = {

There's an extern in arch/mips/include/asm/mach-jz4740/platform.h that
should perhaps be removed also?

Otherwise
Acked-by: James Hogan 

I'm happy to apply for 4.18 with that change if you want it to go
through the MIPS tree.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: VPE: fix spelling mistake: "uneeded" -> "unneeded"

[James Hogan]

On Thu, May 10, 2018 at 05:59:00PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in pr_warn message text
> 
> Signed-off-by: Colin Ian King 

> - pr_warn("VPE loader: elf size too big. Perhaps strip uneeded 
> symbols\n");
> + pr_warn("VPE loader: elf size too big. Perhaps strip unneeded 
> symbols\n");

Applied for 4.18

thanks
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: VPE: fix spelling mistake: "uneeded" -> "unneeded"

[James Hogan]

On Thu, May 10, 2018 at 05:59:00PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in pr_warn message text
> 
> Signed-off-by: Colin Ian King 

> - pr_warn("VPE loader: elf size too big. Perhaps strip uneeded 
> symbols\n");
> + pr_warn("VPE loader: elf size too big. Perhaps strip unneeded 
> symbols\n");

Applied for 4.18

thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] MIPS: Convert read_persistent_clock() to read_persistent_clock64()

[James Hogan]

On Mon, May 07, 2018 at 05:28:27PM +0800, Baolin Wang wrote:
> Since struct timespec is not y2038 safe on 32bit machines, this patch
> converts read_persistent_clock() to read_persistent_clock64() using
> struct timespec64, as well as converting mktime() to mktime64().
> 
> Signed-off-by: Baolin Wang 

Thanks, both applied for 4.18

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] MIPS: Convert read_persistent_clock() to read_persistent_clock64()

[James Hogan]

On Mon, May 07, 2018 at 05:28:27PM +0800, Baolin Wang wrote:
> Since struct timespec is not y2038 safe on 32bit machines, this patch
> converts read_persistent_clock() to read_persistent_clock64() using
> struct timespec64, as well as converting mktime() to mktime64().
> 
> Signed-off-by: Baolin Wang 

Thanks, both applied for 4.18

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: sni: Remove the read_persistent_clock()

[James Hogan]

On Thu, Apr 19, 2018 at 03:21:06PM +0800, Baolin Wang wrote:
> The dummy read_persistent_clock() uses a timespec, which is not year 2038
> safe on 32bit systems. Thus remove this obsolete interface.
> 
> Signed-off-by: Baolin Wang 

Thanks, Applied for 4.18

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH] MIPS: sni: Remove the read_persistent_clock()

[James Hogan]

On Thu, Apr 19, 2018 at 03:21:06PM +0800, Baolin Wang wrote:
> The dummy read_persistent_clock() uses a timespec, which is not year 2038
> safe on 32bit systems. Thus remove this obsolete interface.
> 
> Signed-off-by: Baolin Wang 

Thanks, Applied for 4.18

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v2] MIPS: c-r4k: fix data corruption related to cache coherence.

[James Hogan]

On Mon, May 07, 2018 at 07:40:49AM +1000, NeilBrown wrote:
> 
> Hi James,
>  this hasn't appear in linux-next yet, or in any branch
>  of
>git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git
> 
>  Should I expect it to?

Sorry Neil, I haven't applied it yet. I'm planning to get a few fixes
sorted this week, at which point it would land in the mips-fixes branch
at the above repo.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v2] MIPS: c-r4k: fix data corruption related to cache coherence.

[James Hogan]

On Mon, May 07, 2018 at 07:40:49AM +1000, NeilBrown wrote:
> 
> Hi James,
>  this hasn't appear in linux-next yet, or in any branch
>  of
>git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git
> 
>  Should I expect it to?

Sorry Neil, I haven't applied it yet. I'm planning to get a few fixes
sorted this week, at which point it would land in the mips-fixes branch
at the above repo.

Cheers
James


signature.asc
Description: PGP signature

Re: [PATCH v3 1/3] alpha: Use OPTIMIZE_INLINING instead of asm/compiler.h

[James Hogan]

On Sun, May 06, 2018 at 12:33:21PM -0700, Matt Turner wrote:
> On Tue, Apr 17, 2018 at 3:11 AM, James Hogan <jho...@kernel.org> wrote:
> > Use CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING and CONFIG_OPTIMIZE_INLINING
> > instead of undefining the inline macros in the alpha specific
> > asm/compiler.h. This is to allow asm/compiler.h to become a general
> > header that can be used for overriding linux/compiler*.h.
> >
> > A build of alpha's defconfig on GCC 7.3 before and after this series
> > (i.e. this commit and "compiler.h: Allow arch-specific overrides" which
> > includes asm/compiler.h from linux/compiler_types.h) results in the
> > following size differences, which appear harmless to me:
> >
> > $ ./scripts/bloat-o-meter vmlinux.1 vmlinux.2
> > add/remove: 1/1 grow/shrink: 3/0 up/down: 264/-348 (-84)
> > Function old new   delta
> > cap_bprm_set_creds  14961664+168
> > cap_issubset   -  68 +68
> > flex_array_put   328 344 +16
> > cap_capset   488 500 +12
> > nonroot_raised_pE.constprop  348   --348
> > Total: Before=5823709, After=5823625, chg -0.00%
> >
> > Suggested-by: Arnd Bergmann <a...@arndb.de>
> > Signed-off-by: James Hogan <jho...@kernel.org>
> > Cc: Richard Henderson <r...@twiddle.net>
> > Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
> > Cc: Matt Turner <matts...@gmail.com>
> > Cc: linux-al...@vger.kernel.org
> 
> Looks fine to me.
> 
> Acked-by: Matt Turner <matts...@gmail.com>

Thanks

> 
> Should I take it through the alpha tree?

I'll take all 3 through the MIPS tree if thats okay with you, as its a
prerequisite to allowing MIPS to override stuff in linux/compiler-gcc.h
using asm/compiler.h, which is needed to fix build breakage in 4.17.

Thanks
James


signature.asc
Description: PGP signature

Re: [PATCH v3 1/3] alpha: Use OPTIMIZE_INLINING instead of asm/compiler.h

[James Hogan]

On Sun, May 06, 2018 at 12:33:21PM -0700, Matt Turner wrote:
> On Tue, Apr 17, 2018 at 3:11 AM, James Hogan  wrote:
> > Use CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING and CONFIG_OPTIMIZE_INLINING
> > instead of undefining the inline macros in the alpha specific
> > asm/compiler.h. This is to allow asm/compiler.h to become a general
> > header that can be used for overriding linux/compiler*.h.
> >
> > A build of alpha's defconfig on GCC 7.3 before and after this series
> > (i.e. this commit and "compiler.h: Allow arch-specific overrides" which
> > includes asm/compiler.h from linux/compiler_types.h) results in the
> > following size differences, which appear harmless to me:
> >
> > $ ./scripts/bloat-o-meter vmlinux.1 vmlinux.2
> > add/remove: 1/1 grow/shrink: 3/0 up/down: 264/-348 (-84)
> > Function old new   delta
> > cap_bprm_set_creds  14961664+168
> > cap_issubset   -  68 +68
> > flex_array_put   328 344 +16
> > cap_capset   488 500 +12
> > nonroot_raised_pE.constprop  348   -    -348
> > Total: Before=5823709, After=5823625, chg -0.00%
> >
> > Suggested-by: Arnd Bergmann 
> > Signed-off-by: James Hogan 
> > Cc: Richard Henderson 
> > Cc: Ivan Kokshaysky 
> > Cc: Matt Turner 
> > Cc: linux-al...@vger.kernel.org
> 
> Looks fine to me.
> 
> Acked-by: Matt Turner 

Thanks

> 
> Should I take it through the alpha tree?

I'll take all 3 through the MIPS tree if thats okay with you, as its a
prerequisite to allowing MIPS to override stuff in linux/compiler-gcc.h
using asm/compiler.h, which is needed to fix build breakage in 4.17.

Thanks
James


signature.asc
Description: PGP signature

Re: Introducing a nanoMIPS port for Linux

[James Hogan]

On Thu, May 03, 2018 at 06:40:07PM -0400, Arnd Bergmann wrote:
> On Wed, May 2, 2018 at 5:51 PM, James Hogan <jho...@kernel.org> wrote:
> 
> > Due to the binary incompatibility between previous MIPS architecture
> > generations and nanoMIPS, and the significantly revamped compiler ABI,
> > where for the first time, a single Linux kernel would not be expected to
> > handle both old and new ABIs, we have decided to also take the
> > opportunity to modernise the Linux user ABI for nanoMIPS, making as much
> > use of generic interfaces as possible and modernising the true
> > architecture specific parts.
> >
> > This is similar to what a whole new kernel architecture would be
> > expected to adopt, but has been done within the existing MIPS
> > architecture port to allow reuse of the existing MIPS code, most of
> > which does not depend on these ABI specifics. Details of the proposed
> > Linux user ABI changes for nanoMIPS can be found here:
> 
> While I haven't looked at the individual changes, I wonder whether
> it would be useful to make this new ABI use 64-bit time_t from
> the start, using the new system calls that Deepa and I have been
> posting recently.

Personally I'm all for squeezing as much API cleanup in as possible
before its merged, though obviously there'll be a point when the ABI may
need to be frozen, at which point we'll mostly have to accept what we
have within reason.

> There are still a few things to be worked out:
> only the first of four sets of syscall patches is merged so far,
> and we have a couple of areas that will require further ABI changes
> (sound, sockets, media and maybe a couple of smaller drivers),
> so it depends on the overall timing. If you would otherwise merge
> the patches quickly, then it may be better to just follow the existing
> 32-bit architectures and add the 64-bit entry points when we do it
> for everyone.

I think it'll likely be a couple of cycles before it gets merged anyway.
There's still work to do, and limited resources.

Cheers
James


signature.asc
Description: PGP signature

Re: Introducing a nanoMIPS port for Linux

[James Hogan]

On Thu, May 03, 2018 at 06:40:07PM -0400, Arnd Bergmann wrote:
> On Wed, May 2, 2018 at 5:51 PM, James Hogan  wrote:
> 
> > Due to the binary incompatibility between previous MIPS architecture
> > generations and nanoMIPS, and the significantly revamped compiler ABI,
> > where for the first time, a single Linux kernel would not be expected to
> > handle both old and new ABIs, we have decided to also take the
> > opportunity to modernise the Linux user ABI for nanoMIPS, making as much
> > use of generic interfaces as possible and modernising the true
> > architecture specific parts.
> >
> > This is similar to what a whole new kernel architecture would be
> > expected to adopt, but has been done within the existing MIPS
> > architecture port to allow reuse of the existing MIPS code, most of
> > which does not depend on these ABI specifics. Details of the proposed
> > Linux user ABI changes for nanoMIPS can be found here:
> 
> While I haven't looked at the individual changes, I wonder whether
> it would be useful to make this new ABI use 64-bit time_t from
> the start, using the new system calls that Deepa and I have been
> posting recently.

Personally I'm all for squeezing as much API cleanup in as possible
before its merged, though obviously there'll be a point when the ABI may
need to be frozen, at which point we'll mostly have to accept what we
have within reason.

> There are still a few things to be worked out:
> only the first of four sets of syscall patches is merged so far,
> and we have a couple of areas that will require further ABI changes
> (sound, sockets, media and maybe a couple of smaller drivers),
> so it depends on the overall timing. If you would otherwise merge
> the patches quickly, then it may be better to just follow the existing
> 32-bit architectures and add the 64-bit entry points when we do it
> for everyone.

I think it'll likely be a couple of cycles before it gets merged anyway.
There's still work to do, and limited resources.

Cheers
James


signature.asc
Description: PGP signature

Introducing a nanoMIPS port for Linux

[James Hogan]

 into the wild, but is of course not intended to be
submitted or merged upstream as is. This work will be prepared &
submitted as series of smaller patches.

Due to the binary incompatibility between previous MIPS architecture
generations and nanoMIPS, and the significantly revamped compiler ABI,
where for the first time, a single Linux kernel would not be expected to
handle both old and new ABIs, we have decided to also take the
opportunity to modernise the Linux user ABI for nanoMIPS, making as much
use of generic interfaces as possible and modernising the true
architecture specific parts.

This is similar to what a whole new kernel architecture would be
expected to adopt, but has been done within the existing MIPS
architecture port to allow reuse of the existing MIPS code, most of
which does not depend on these ABI specifics. Details of the proposed
Linux user ABI changes for nanoMIPS can be found here:

  https://www.linux-mips.org/wiki/P32_Linux_ABI

Contributors:
  Paul Burton, James Hogan, Matt Redfearn, Marcin Nowakowski

[1] 
https://www.mips.com/press/new-mips-i7200-processor-core-delivers-unmatched-performance-and-efficiency-for-advanced-lte5g-communications-and-networking-ic-designs/


signature.asc
Description: Digital signature

Introducing a nanoMIPS port for Linux

[James Hogan]

 into the wild, but is of course not intended to be
submitted or merged upstream as is. This work will be prepared &
submitted as series of smaller patches.

Due to the binary incompatibility between previous MIPS architecture
generations and nanoMIPS, and the significantly revamped compiler ABI,
where for the first time, a single Linux kernel would not be expected to
handle both old and new ABIs, we have decided to also take the
opportunity to modernise the Linux user ABI for nanoMIPS, making as much
use of generic interfaces as possible and modernising the true
architecture specific parts.

This is similar to what a whole new kernel architecture would be
expected to adopt, but has been done within the existing MIPS
architecture port to allow reuse of the existing MIPS code, most of
which does not depend on these ABI specifics. Details of the proposed
Linux user ABI changes for nanoMIPS can be found here:

  https://www.linux-mips.org/wiki/P32_Linux_ABI

Contributors:
  Paul Burton, James Hogan, Matt Redfearn, Marcin Nowakowski

[1] 
https://www.mips.com/press/new-mips-i7200-processor-core-delivers-unmatched-performance-and-efficiency-for-advanced-lte5g-communications-and-networking-ic-designs/


signature.asc
Description: Digital signature

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

[James Hogan]

On Thu, Apr 26, 2018 at 08:00:18AM +1000, NeilBrown wrote:
> On Wed, Apr 25 2018, James Hogan wrote:
> > So I'm thinking "!mips_cm_present()" should probably be replaced with
> > "!r4k_op_needs_ipi(R4K_INDEX)" (and the comment updated to mention that
> > IPI calls aren't implemented here).
> 
> That makes sense.  I tried ipi calls at one stage.  Synchronous ones
> cannot be used because this code is called with interrupts disabled, and
> async ones cannot provide the required guarantees.

Okay. I thought something like that might be the case.

> 
> I'll update the patch, test that it still works, and resend, in the next
> day or so.

Thanks. It wouldn't hurt to also mention why IPIs can't be used in the
code comments, if its fresh in your mind, just for the benefit of next
person to attempt it.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

[James Hogan]

On Thu, Apr 26, 2018 at 08:00:18AM +1000, NeilBrown wrote:
> On Wed, Apr 25 2018, James Hogan wrote:
> > So I'm thinking "!mips_cm_present()" should probably be replaced with
> > "!r4k_op_needs_ipi(R4K_INDEX)" (and the comment updated to mention that
> > IPI calls aren't implemented here).
> 
> That makes sense.  I tried ipi calls at one stage.  Synchronous ones
> cannot be used because this code is called with interrupts disabled, and
> async ones cannot provide the required guarantees.

Okay. I thought something like that might be the case.

> 
> I'll update the patch, test that it still works, and resend, in the next
> day or so.

Thanks. It wouldn't hurt to also mention why IPIs can't be used in the
code comments, if its fresh in your mind, just for the benefit of next
person to attempt it.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

[James Hogan]

Hi NeilBrown,

On Wed, Apr 25, 2018 at 02:08:15PM +1000, NeilBrown wrote:
> Cc: sta...@vger.kernel.org (v4.8)

FYI my preferred form of this is:

Cc:  # 4.8+

>   /*
>* Either no secondary cache or the available caches don't have the
>* subset property so we have to flush the primary caches
> -  * explicitly
> +  * explicitly.
> +  * As Index type operations are not globalized by CM, we must
> +  * use the HIT type when CM is present.

I don't think Index type operations *can* be sensibly globalised to
separate primary caches, since they directly index the lines in the
cache rather than any particular physical or virtual address, so this
fundamental issue doesn't sound specific to the CM.

I'm not entirely clear OTOH whether there are any non-CM r4k-like SMP
capable cores that don't have coherent IO or inclusive caches.
- Octeon doesn't use c-r4k and has coherent IO
- Netlogic appear to have coherent IO 
- Loongson64 have inclusive caches
- bmips, only bmips5000 appears to have multicore (not just multi-thread
  with I presume shared dcaches), and that has inclusive caches

So I suppose that does just leave non-multicore and CM systems as
potentially reaching these bits of code...

>*/
> - if (size >= dcache_size) {
> + if (!mips_cm_present() && size >= dcache_size) {

... but even for CM systems its only if there are foreign CPUs running
(i.e. not just threads on the same core sharing the same dcache) that it
actually matters.

So I'm thinking "!mips_cm_present()" should probably be replaced with
"!r4k_op_needs_ipi(R4K_INDEX)" (and the comment updated to mention that
IPI calls aren't implemented here).

That effectively means:
!CONFIG_SMP || cpumask_empty(_foreign_map[0])

Otherwise the patch looks spot on. Thanks for spotting this!

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

[James Hogan]

Hi NeilBrown,

On Wed, Apr 25, 2018 at 02:08:15PM +1000, NeilBrown wrote:
> Cc: sta...@vger.kernel.org (v4.8)

FYI my preferred form of this is:

Cc:  # 4.8+

>   /*
>* Either no secondary cache or the available caches don't have the
>* subset property so we have to flush the primary caches
> -  * explicitly
> +  * explicitly.
> +  * As Index type operations are not globalized by CM, we must
> +  * use the HIT type when CM is present.

I don't think Index type operations *can* be sensibly globalised to
separate primary caches, since they directly index the lines in the
cache rather than any particular physical or virtual address, so this
fundamental issue doesn't sound specific to the CM.

I'm not entirely clear OTOH whether there are any non-CM r4k-like SMP
capable cores that don't have coherent IO or inclusive caches.
- Octeon doesn't use c-r4k and has coherent IO
- Netlogic appear to have coherent IO 
- Loongson64 have inclusive caches
- bmips, only bmips5000 appears to have multicore (not just multi-thread
  with I presume shared dcaches), and that has inclusive caches

So I suppose that does just leave non-multicore and CM systems as
potentially reaching these bits of code...

>*/
> - if (size >= dcache_size) {
> + if (!mips_cm_present() && size >= dcache_size) {

... but even for CM systems its only if there are foreign CPUs running
(i.e. not just threads on the same core sharing the same dcache) that it
actually matters.

So I'm thinking "!mips_cm_present()" should probably be replaced with
"!r4k_op_needs_ipi(R4K_INDEX)" (and the comment updated to mention that
IPI calls aren't implemented here).

That effectively means:
!CONFIG_SMP || cpumask_empty(_foreign_map[0])

Otherwise the patch looks spot on. Thanks for spotting this!

Cheers
James


signature.asc
Description: Digital signature

Re: [RFC PATCH] MIPS: Oprofile: Drop support

[James Hogan]

On Tue, Apr 24, 2018 at 01:55:54PM +0100, Matt Redfearn wrote:
> Since it appears that MIPS oprofile support is currently broken, core
> oprofile is not getting many updates and not as many architectures
> implement support for it compared to perf, remove the MIPS support.

That sounds reasonable to me. Any idea how long its been broken?

I'll let it sit on the list for a bit in case anybody does object and
wants to fix it instead.

Thanks
James


signature.asc
Description: Digital signature

Re: [RFC PATCH] MIPS: Oprofile: Drop support

[James Hogan]

On Tue, Apr 24, 2018 at 01:55:54PM +0100, Matt Redfearn wrote:
> Since it appears that MIPS oprofile support is currently broken, core
> oprofile is not getting many updates and not as many architectures
> implement support for it compared to perf, remove the MIPS support.

That sounds reasonable to me. Any idea how long its been broken?

I'll let it sit on the list for a bit in case anybody does object and
wants to fix it instead.

Thanks
James


signature.asc
Description: Digital signature

Re: [PATCH v2 1/4] MIPS: memset.S: Fix clobber of v1 in last_fixup

[James Hogan]

On Tue, Apr 17, 2018 at 04:40:00PM +0100, Matt Redfearn wrote:
> The label .Llast_fixup\@ is jumped to on page fault within the final
> byte set loop of memset (on < MIPSR6 architectures). For some reason, in
> this fault handler, the v1 register is randomly set to a2 & STORMASK.
> This clobbers v1 for the calling function. This can be observed with the
> following test code:
> 
> static int __init __attribute__((optimize("O0"))) test_clear_user(void)
> {
>   register int t asm("v1");
>   char *test;
>   int j, k;
> 
>   pr_info("\n\n\nTesting clear_user\n");
>   test = vmalloc(PAGE_SIZE);
> 
>   for (j = 256; j < 512; j++) {
> t = 0xa5a5a5a5;
> if ((k = clear_user(test + PAGE_SIZE - 256, j)) != j - 256) {
> pr_err("clear_user (%px %d) returned %d\n", test + PAGE_SIZE - 256, 
> j, k);
> }
> if (t != 0xa5a5a5a5) {
>pr_err("v1 was clobbered to 0x%x!\n", t);
> }
>   }
> 
>   return 0;
> }
> late_initcall(test_clear_user);
> 
> Which demonstrates that v1 is indeed clobbered (MIPS64):
> 
> Testing clear_user
> v1 was clobbered to 0x1!
> v1 was clobbered to 0x2!
> v1 was clobbered to 0x3!
> v1 was clobbered to 0x4!
> v1 was clobbered to 0x5!
> v1 was clobbered to 0x6!
> v1 was clobbered to 0x7!
> 
> Since the number of bytes that could not be set is already contained in
> a2, the andi placing a value in v1 is not necessary and actively
> harmful in clobbering v1.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: sta...@vger.kernel.org
> Reported-by: James Hogan <jho...@kernel.org>
> Signed-off-by: Matt Redfearn <matt.redfe...@mips.com>

Thanks, Patches 1 & 2 applied to my fixes branch.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH v2 1/4] MIPS: memset.S: Fix clobber of v1 in last_fixup

[James Hogan]

On Tue, Apr 17, 2018 at 04:40:00PM +0100, Matt Redfearn wrote:
> The label .Llast_fixup\@ is jumped to on page fault within the final
> byte set loop of memset (on < MIPSR6 architectures). For some reason, in
> this fault handler, the v1 register is randomly set to a2 & STORMASK.
> This clobbers v1 for the calling function. This can be observed with the
> following test code:
> 
> static int __init __attribute__((optimize("O0"))) test_clear_user(void)
> {
>   register int t asm("v1");
>   char *test;
>   int j, k;
> 
>   pr_info("\n\n\nTesting clear_user\n");
>   test = vmalloc(PAGE_SIZE);
> 
>   for (j = 256; j < 512; j++) {
> t = 0xa5a5a5a5;
> if ((k = clear_user(test + PAGE_SIZE - 256, j)) != j - 256) {
> pr_err("clear_user (%px %d) returned %d\n", test + PAGE_SIZE - 256, 
> j, k);
> }
> if (t != 0xa5a5a5a5) {
>pr_err("v1 was clobbered to 0x%x!\n", t);
> }
>   }
> 
>   return 0;
> }
> late_initcall(test_clear_user);
> 
> Which demonstrates that v1 is indeed clobbered (MIPS64):
> 
> Testing clear_user
> v1 was clobbered to 0x1!
> v1 was clobbered to 0x2!
> v1 was clobbered to 0x3!
> v1 was clobbered to 0x4!
> v1 was clobbered to 0x5!
> v1 was clobbered to 0x6!
> v1 was clobbered to 0x7!
> 
> Since the number of bytes that could not be set is already contained in
> a2, the andi placing a value in v1 is not necessary and actively
> harmful in clobbering v1.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: sta...@vger.kernel.org
> Reported-by: James Hogan 
> Signed-off-by: Matt Redfearn 

Thanks, Patches 1 & 2 applied to my fixes branch.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH v2 1/6] MIPS: perf: More robustly probe for the presence of per-tc counters

[James Hogan]

On Thu, Apr 12, 2018 at 10:36:21AM +0100, Matt Redfearn wrote:
> Processors implementing the MIPS MT ASE may have performance counters
> implemented per core or per TC. Processors implemented by MIPS
> Technologies signify presence per TC through a bit in the implementation
> specific Config7 register. Currently the code which probes for their
> presence blindly reads a magic number corresponding to this bit, despite
> it potentially having a different meaning in the CPU implementation.
> 
> The test of Config7.PTC was previously enabled when CONFIG_BMIPS5000 was
> enabled. However, according to [florian], the BMIPS5000 manual does not
> define this bit, so we can assume it is 0 and the feature is not
> supported.
> 
> Introduce probe_mipsmt_pertccounters() to probe for the presence of per
> TC counters. This detects the ases implemented in the CPU, and reads any
> implementation specific bit flagging their presence. In the case of MIPS
> implementations, this bit is Config7.PTC. A definition of this bit is
> added in mipsregs.h for MIPS Technologies. No other implementations
> support this feature.
> 
> Signed-off-by: Matt Redfearn 
> ---
> 
> Changes in v2: None
> 
>  arch/mips/include/asm/mipsregs.h |  5 +
>  arch/mips/kernel/perf_event_mipsxx.c | 29 -
>  2 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/mips/include/asm/mipsregs.h 
> b/arch/mips/include/asm/mipsregs.h
> index 858752dac337..a4b02bc8 100644
> --- a/arch/mips/include/asm/mipsregs.h
> +++ b/arch/mips/include/asm/mipsregs.h
> @@ -684,6 +684,11 @@
>  #define MIPS_CONF7_IAR   (_ULCAST_(1) << 10)
>  #define MIPS_CONF7_AR(_ULCAST_(1) << 16)
>  
> +/* Config7 Bits specific to MIPS Technologies. */
> +
> +/* Performance counters implemented Per TC */
> +#define MTI_CONF7_PTC(_ULCAST_(1) << 19)
> +
>  /* WatchLo* register definitions */
>  #define MIPS_WATCHLO_IRW (_ULCAST_(0x7) << 0)
>  
> diff --git a/arch/mips/kernel/perf_event_mipsxx.c 
> b/arch/mips/kernel/perf_event_mipsxx.c
> index 6668f67a61c3..f3ec4a36921d 100644
> --- a/arch/mips/kernel/perf_event_mipsxx.c
> +++ b/arch/mips/kernel/perf_event_mipsxx.c
> @@ -1708,6 +1708,33 @@ static const struct mips_perf_event 
> *xlp_pmu_map_raw_event(u64 config)
>   return _event;
>  }
>  
> +#ifdef CONFIG_MIPS_PERF_SHARED_TC_COUNTERS
> +/*
> + * The MIPS MT ASE specifies that performance counters may be implemented
> + * per core or per TC. If implemented per TC then all Linux CPUs have their
> + * own unique counters. If implemented per core, then VPEs in the core must
> + * treat the counters as a shared resource.
> + * Probe for the presence of per-TC counters
> + */
> +static int probe_mipsmt_pertccounters(void)
> +{
> + struct cpuinfo_mips *c = _cpu_data;
> +
> + /* Non-MT cores by definition cannot implement per-TC counters */
> + if (!cpu_has_mipsmt)
> + return 0;
> +
> + switch (c->processor_id & PRID_COMP_MASK) {
> + case PRID_COMP_MIPS:
> + /* MTI implementations use CONFIG7.PTC to signify presence */
> + return read_c0_config7() & MTI_CONF7_PTC;
> + default:
> + break;
> + }
> + return 0;
> +}
> +#endif /* CONFIG_MIPS_PERF_SHARED_TC_COUNTERS */
> +
>  static int __init
>  init_hw_perf_events(void)
>  {
> @@ -1723,7 +1750,7 @@ init_hw_perf_events(void)
>   }
>  
>  #ifdef CONFIG_MIPS_PERF_SHARED_TC_COUNTERS
> - cpu_has_mipsmt_pertccounters = read_c0_config7() & (1<<19);
> + cpu_has_mipsmt_pertccounters = probe_mipsmt_pertccounters();

Similar code also exists in arch/mips/oprofile/op_model_mipsxx.c.
Perhaps it is time to unify it into more standard places, i.e.
asm/cpu-features.h and cpu-probe.c.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH v2 1/6] MIPS: perf: More robustly probe for the presence of per-tc counters

[James Hogan]

On Thu, Apr 12, 2018 at 10:36:21AM +0100, Matt Redfearn wrote:
> Processors implementing the MIPS MT ASE may have performance counters
> implemented per core or per TC. Processors implemented by MIPS
> Technologies signify presence per TC through a bit in the implementation
> specific Config7 register. Currently the code which probes for their
> presence blindly reads a magic number corresponding to this bit, despite
> it potentially having a different meaning in the CPU implementation.
> 
> The test of Config7.PTC was previously enabled when CONFIG_BMIPS5000 was
> enabled. However, according to [florian], the BMIPS5000 manual does not
> define this bit, so we can assume it is 0 and the feature is not
> supported.
> 
> Introduce probe_mipsmt_pertccounters() to probe for the presence of per
> TC counters. This detects the ases implemented in the CPU, and reads any
> implementation specific bit flagging their presence. In the case of MIPS
> implementations, this bit is Config7.PTC. A definition of this bit is
> added in mipsregs.h for MIPS Technologies. No other implementations
> support this feature.
> 
> Signed-off-by: Matt Redfearn 
> ---
> 
> Changes in v2: None
> 
>  arch/mips/include/asm/mipsregs.h |  5 +
>  arch/mips/kernel/perf_event_mipsxx.c | 29 -
>  2 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/mips/include/asm/mipsregs.h 
> b/arch/mips/include/asm/mipsregs.h
> index 858752dac337..a4b02bc8 100644
> --- a/arch/mips/include/asm/mipsregs.h
> +++ b/arch/mips/include/asm/mipsregs.h
> @@ -684,6 +684,11 @@
>  #define MIPS_CONF7_IAR   (_ULCAST_(1) << 10)
>  #define MIPS_CONF7_AR(_ULCAST_(1) << 16)
>  
> +/* Config7 Bits specific to MIPS Technologies. */
> +
> +/* Performance counters implemented Per TC */
> +#define MTI_CONF7_PTC(_ULCAST_(1) << 19)
> +
>  /* WatchLo* register definitions */
>  #define MIPS_WATCHLO_IRW (_ULCAST_(0x7) << 0)
>  
> diff --git a/arch/mips/kernel/perf_event_mipsxx.c 
> b/arch/mips/kernel/perf_event_mipsxx.c
> index 6668f67a61c3..f3ec4a36921d 100644
> --- a/arch/mips/kernel/perf_event_mipsxx.c
> +++ b/arch/mips/kernel/perf_event_mipsxx.c
> @@ -1708,6 +1708,33 @@ static const struct mips_perf_event 
> *xlp_pmu_map_raw_event(u64 config)
>   return _event;
>  }
>  
> +#ifdef CONFIG_MIPS_PERF_SHARED_TC_COUNTERS
> +/*
> + * The MIPS MT ASE specifies that performance counters may be implemented
> + * per core or per TC. If implemented per TC then all Linux CPUs have their
> + * own unique counters. If implemented per core, then VPEs in the core must
> + * treat the counters as a shared resource.
> + * Probe for the presence of per-TC counters
> + */
> +static int probe_mipsmt_pertccounters(void)
> +{
> + struct cpuinfo_mips *c = _cpu_data;
> +
> + /* Non-MT cores by definition cannot implement per-TC counters */
> + if (!cpu_has_mipsmt)
> + return 0;
> +
> + switch (c->processor_id & PRID_COMP_MASK) {
> + case PRID_COMP_MIPS:
> + /* MTI implementations use CONFIG7.PTC to signify presence */
> + return read_c0_config7() & MTI_CONF7_PTC;
> + default:
> + break;
> + }
> + return 0;
> +}
> +#endif /* CONFIG_MIPS_PERF_SHARED_TC_COUNTERS */
> +
>  static int __init
>  init_hw_perf_events(void)
>  {
> @@ -1723,7 +1750,7 @@ init_hw_perf_events(void)
>   }
>  
>  #ifdef CONFIG_MIPS_PERF_SHARED_TC_COUNTERS
> - cpu_has_mipsmt_pertccounters = read_c0_config7() & (1<<19);
> + cpu_has_mipsmt_pertccounters = probe_mipsmt_pertccounters();

Similar code also exists in arch/mips/oprofile/op_model_mipsxx.c.
Perhaps it is time to unify it into more standard places, i.e.
asm/cpu-features.h and cpu-probe.c.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH 1/2] MIPS: BCM47XX: Add support for Netgear WNR1000 V3

[James Hogan]

On Sun, Apr 08, 2018 at 10:57:32PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This adds support for detecting this model board and registers some LEDs
> and buttons.
> 
> There are two uncommon things regarding this device:
> 1) It can use two different "board_id" ID values.
>Unit I have uses "U12H139T00_NETGEAR" value. This magic is also used
>in firmware file header. There are two reports (one from an OpenWrt
>user) of a different "U12H139T50_NETGEAR" magic though.
> 2) Power LEDs share GPIOs with buttons.
>Amber one seems to share GPIO 2 with WPS button and green one seems
>to share GPIO 3 with reset button. It remains unknown how to support
>them and handle buttons at the same time. For that reason they aren't
>added to the list of supported LEDs.
> 
> Signed-off-by: Rafał Miłecki 

Thanks, both applied for 4.18.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH 1/2] MIPS: BCM47XX: Add support for Netgear WNR1000 V3

[James Hogan]

On Sun, Apr 08, 2018 at 10:57:32PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This adds support for detecting this model board and registers some LEDs
> and buttons.
> 
> There are two uncommon things regarding this device:
> 1) It can use two different "board_id" ID values.
>Unit I have uses "U12H139T00_NETGEAR" value. This magic is also used
>in firmware file header. There are two reports (one from an OpenWrt
>user) of a different "U12H139T50_NETGEAR" magic though.
> 2) Power LEDs share GPIOs with buttons.
>Amber one seems to share GPIO 2 with WPS button and green one seems
>to share GPIO 3 with reset button. It remains unknown how to support
>them and handle buttons at the same time. For that reason they aren't
>added to the list of supported LEDs.
> 
> Signed-off-by: Rafał Miłecki 

Thanks, both applied for 4.18.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH v6 3/4] MIPS: vmlinuz: Use generic ashldi3

[James Hogan]

On Wed, Apr 11, 2018 at 08:50:18AM +0100, Matt Redfearn wrote:
> diff --git a/arch/mips/boot/compressed/Makefile 
> b/arch/mips/boot/compressed/Makefile
> index adce180f3ee4..e03f522c33ac 100644
> --- a/arch/mips/boot/compressed/Makefile
> +++ b/arch/mips/boot/compressed/Makefile
> @@ -46,9 +46,12 @@ $(obj)/uart-ath79.c: 
> $(srctree)/arch/mips/ath79/early_printk.c
>  
>  vmlinuzobjs-$(CONFIG_KERNEL_XZ) += $(obj)/ashldi3.o $(obj)/bswapsi.o
>  
> -extra-y += ashldi3.c bswapsi.c
> -$(obj)/ashldi3.o $(obj)/bswapsi.o: KBUILD_CFLAGS += 
> -I$(srctree)/arch/mips/lib
> -$(obj)/ashldi3.c $(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c
> +extra-y += ashldi3.c
> +$(obj)/ashldi3.c: $(obj)/%.c: $(srctree)/lib/%.c
> + $(call cmd,shipped)
> +
> +extra-y += bswapsi.c
> +$(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c
>   $(call cmd,shipped)

ci20_defconfig:

arch/mips/boot/compressed/ashldi3.c:4:10: fatal error: libgcc.h: No such file 
or directory
 #include "libgcc.h"
   ^~

It looks like it had already copied ashldi3.c from arch/mips/lib/ when
building an older commit, and it hasn't been regenerated from lib/ since
the Makefile changed, so its still using the old version.

I think it should be using FORCE and if_changed like this:

diff --git a/arch/mips/boot/compressed/Makefile 
b/arch/mips/boot/compressed/Makefile
index e03f522c33ac..abe77add8789 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -47,12 +47,12 @@ $(obj)/uart-ath79.c: 
$(srctree)/arch/mips/ath79/early_printk.c
 vmlinuzobjs-$(CONFIG_KERNEL_XZ) += $(obj)/ashldi3.o $(obj)/bswapsi.o
 
 extra-y += ashldi3.c
-$(obj)/ashldi3.c: $(obj)/%.c: $(srctree)/lib/%.c
-   $(call cmd,shipped)
+$(obj)/ashldi3.c: $(obj)/%.c: $(srctree)/lib/%.c FORCE
+   $(call if_changed,shipped)
 
 extra-y += bswapsi.c
-$(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c
-   $(call cmd,shipped)
+$(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c FORCE
+   $(call if_changed,shipped)
 
 targets := $(notdir $(vmlinuzobjs-y))
 
That resolves the build failures when checking out old -> new without
cleaning, since the .ashldi3.c.cmd is missing so it gets rebuilt.

It should also resolve issues if the path it copies from is updated in
future since the .ashldi3.c.cmd will get updated.

If you checkout new -> old without cleaning, the now removed
arch/mips/lib/ashldi3.c will get added which will trigger regeneration,
so it won't error.

However if you do new -> old -> new then the .ashldi3.cmd file isn't
updated while at old, so you get the same error as above. I'm not sure
there's much we can practically do about that, aside perhaps avoiding
the issue in future by somehow auto-deleting stale .*.cmd files.

Cc'ing kbuild folk in case they have any bright ideas.

At least the straightforward old->new upgrade will work with the above
fixup though. If you're okay with it I'm happy to apply as a fixup.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH v6 3/4] MIPS: vmlinuz: Use generic ashldi3

[James Hogan]

On Wed, Apr 11, 2018 at 08:50:18AM +0100, Matt Redfearn wrote:
> diff --git a/arch/mips/boot/compressed/Makefile 
> b/arch/mips/boot/compressed/Makefile
> index adce180f3ee4..e03f522c33ac 100644
> --- a/arch/mips/boot/compressed/Makefile
> +++ b/arch/mips/boot/compressed/Makefile
> @@ -46,9 +46,12 @@ $(obj)/uart-ath79.c: 
> $(srctree)/arch/mips/ath79/early_printk.c
>  
>  vmlinuzobjs-$(CONFIG_KERNEL_XZ) += $(obj)/ashldi3.o $(obj)/bswapsi.o
>  
> -extra-y += ashldi3.c bswapsi.c
> -$(obj)/ashldi3.o $(obj)/bswapsi.o: KBUILD_CFLAGS += 
> -I$(srctree)/arch/mips/lib
> -$(obj)/ashldi3.c $(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c
> +extra-y += ashldi3.c
> +$(obj)/ashldi3.c: $(obj)/%.c: $(srctree)/lib/%.c
> + $(call cmd,shipped)
> +
> +extra-y += bswapsi.c
> +$(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c
>   $(call cmd,shipped)

ci20_defconfig:

arch/mips/boot/compressed/ashldi3.c:4:10: fatal error: libgcc.h: No such file 
or directory
 #include "libgcc.h"
   ^~

It looks like it had already copied ashldi3.c from arch/mips/lib/ when
building an older commit, and it hasn't been regenerated from lib/ since
the Makefile changed, so its still using the old version.

I think it should be using FORCE and if_changed like this:

diff --git a/arch/mips/boot/compressed/Makefile 
b/arch/mips/boot/compressed/Makefile
index e03f522c33ac..abe77add8789 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -47,12 +47,12 @@ $(obj)/uart-ath79.c: 
$(srctree)/arch/mips/ath79/early_printk.c
 vmlinuzobjs-$(CONFIG_KERNEL_XZ) += $(obj)/ashldi3.o $(obj)/bswapsi.o
 
 extra-y += ashldi3.c
-$(obj)/ashldi3.c: $(obj)/%.c: $(srctree)/lib/%.c
-   $(call cmd,shipped)
+$(obj)/ashldi3.c: $(obj)/%.c: $(srctree)/lib/%.c FORCE
+   $(call if_changed,shipped)
 
 extra-y += bswapsi.c
-$(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c
-   $(call cmd,shipped)
+$(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c FORCE
+   $(call if_changed,shipped)
 
 targets := $(notdir $(vmlinuzobjs-y))
 
That resolves the build failures when checking out old -> new without
cleaning, since the .ashldi3.c.cmd is missing so it gets rebuilt.

It should also resolve issues if the path it copies from is updated in
future since the .ashldi3.c.cmd will get updated.

If you checkout new -> old without cleaning, the now removed
arch/mips/lib/ashldi3.c will get added which will trigger regeneration,
so it won't error.

However if you do new -> old -> new then the .ashldi3.cmd file isn't
updated while at old, so you get the same error as above. I'm not sure
there's much we can practically do about that, aside perhaps avoiding
the issue in future by somehow auto-deleting stale .*.cmd files.

Cc'ing kbuild folk in case they have any bright ideas.

At least the straightforward old->new upgrade will work with the above
fixup though. If you're okay with it I'm happy to apply as a fixup.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH] MIPS: dts: avoid unneeded built-in.a creation in vendor DTS directories

[James Hogan]

On Tue, Apr 17, 2018 at 12:41:30AM +0900, Masahiro Yamada wrote:
> arch/mips/boot/dts/Makefile collects objects from sub-directories
> into built-in.a only when CONFIG_BUILTIN_DTB is enabled.  Reflect
> it also to the sub-directory Makefiles.  This suppresses unneeded
> built-in.a creation in arch/mips/boot/dts/*/ directories.
> 
> While I am here, I replaced $(patsubst %.dtb, %.dtb.o, $(dtb-y))
> with $(addsuffix .o, $(dtb-y)) to simplify the code a little bit.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/mips/boot/dts/brcm/Makefile  | 2 +-
>  arch/mips/boot/dts/cavium-octeon/Makefile | 2 +-
>  arch/mips/boot/dts/ingenic/Makefile   | 2 +-
>  arch/mips/boot/dts/lantiq/Makefile| 2 +-
>  arch/mips/boot/dts/mscc/Makefile  | 2 +-
>  arch/mips/boot/dts/mti/Makefile   | 2 +-
>  arch/mips/boot/dts/netlogic/Makefile  | 2 +-
>  arch/mips/boot/dts/pic32/Makefile | 2 +-
>  arch/mips/boot/dts/ralink/Makefile| 2 +-
>  arch/mips/boot/dts/xilfpga/Makefile   | 2 +-
>  10 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/mips/boot/dts/brcm/Makefile 
> b/arch/mips/boot/dts/brcm/Makefile
> index d8787c9..d85f446 100644
> --- a/arch/mips/boot/dts/brcm/Makefile
> +++ b/arch/mips/boot/dts/brcm/Makefile
> @@ -34,4 +34,4 @@ dtb-$(CONFIG_DT_NONE) += \
>   bcm97425svmb.dtb \
>   bcm97435svmb.dtb
>  
> -obj-y+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
> +obj-$(CONFIG_BUILTIN_DTB)+= $(addsuffix .o, $(dtb-y))

I like this. I had also spotted the .o files being unnecessarily
generated when building the dtbs target with bmips and CONFIG_DT_NONE=y.
I'll apply for 4.18.

Thanks
James


signature.asc
Description: Digital signature

Re: [PATCH] MIPS: dts: avoid unneeded built-in.a creation in vendor DTS directories

[James Hogan]

On Tue, Apr 17, 2018 at 12:41:30AM +0900, Masahiro Yamada wrote:
> arch/mips/boot/dts/Makefile collects objects from sub-directories
> into built-in.a only when CONFIG_BUILTIN_DTB is enabled.  Reflect
> it also to the sub-directory Makefiles.  This suppresses unneeded
> built-in.a creation in arch/mips/boot/dts/*/ directories.
> 
> While I am here, I replaced $(patsubst %.dtb, %.dtb.o, $(dtb-y))
> with $(addsuffix .o, $(dtb-y)) to simplify the code a little bit.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/mips/boot/dts/brcm/Makefile  | 2 +-
>  arch/mips/boot/dts/cavium-octeon/Makefile | 2 +-
>  arch/mips/boot/dts/ingenic/Makefile   | 2 +-
>  arch/mips/boot/dts/lantiq/Makefile| 2 +-
>  arch/mips/boot/dts/mscc/Makefile  | 2 +-
>  arch/mips/boot/dts/mti/Makefile   | 2 +-
>  arch/mips/boot/dts/netlogic/Makefile  | 2 +-
>  arch/mips/boot/dts/pic32/Makefile | 2 +-
>  arch/mips/boot/dts/ralink/Makefile| 2 +-
>  arch/mips/boot/dts/xilfpga/Makefile   | 2 +-
>  10 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/mips/boot/dts/brcm/Makefile 
> b/arch/mips/boot/dts/brcm/Makefile
> index d8787c9..d85f446 100644
> --- a/arch/mips/boot/dts/brcm/Makefile
> +++ b/arch/mips/boot/dts/brcm/Makefile
> @@ -34,4 +34,4 @@ dtb-$(CONFIG_DT_NONE) += \
>   bcm97425svmb.dtb \
>   bcm97435svmb.dtb
>  
> -obj-y+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
> +obj-$(CONFIG_BUILTIN_DTB)+= $(addsuffix .o, $(dtb-y))

I like this. I had also spotted the .o files being unnecessarily
generated when building the dtbs target with bmips and CONFIG_DT_NONE=y.
I'll apply for 4.18.

Thanks
James


signature.asc
Description: Digital signature

Re: [PATCH v3 2/3] compiler.h: Allow arch-specific overrides

[James Hogan]

Hi kbuild test robot,

On Wed, Apr 18, 2018 at 03:19:47AM +0800, kbuild test robot wrote:
>In file included from ./arch/x86/include/generated/asm/compiler.h:1:0,
> from include/linux/compiler_types.h:58,
> from :0:
> >> include/asm-generic/compiler.h:2:2: error: #error "Please don't include 
> >>  directly, include  instead."
> #error "Please don't include  directly, include 
>  instead."

Whoops, I love your bug report.

I'll change asm-generic/compiler.h to look for __LINUX_COMPILER_TYPES_H
instead of __LINUX_COMPILER_H and resend soon.

Thanks!
James



signature.asc
Description: Digital signature

Re: [PATCH v3 2/3] compiler.h: Allow arch-specific overrides

[James Hogan]

Hi kbuild test robot,

On Wed, Apr 18, 2018 at 03:19:47AM +0800, kbuild test robot wrote:
>In file included from ./arch/x86/include/generated/asm/compiler.h:1:0,
> from include/linux/compiler_types.h:58,
> from :0:
> >> include/asm-generic/compiler.h:2:2: error: #error "Please don't include 
> >>  directly, include  instead."
> #error "Please don't include  directly, include 
>  instead."

Whoops, I love your bug report.

I'll change asm-generic/compiler.h to look for __LINUX_COMPILER_TYPES_H
instead of __LINUX_COMPILER_H and resend soon.

Thanks!
James



signature.asc
Description: Digital signature

Re: [PATCH v3] MIPS: memset.S: Fix return of __clear_user from Lpartial_fixup

[James Hogan]

On Tue, Apr 17, 2018 at 03:52:21PM +0100, Matt Redfearn wrote:
> The __clear_user function is defined to return the number of bytes that
> could not be cleared. From the underlying memset / bzero implementation
> this means setting register a2 to that number on return. Currently if a
> page fault is triggered within the memset_partial block, the value
> loaded into a2 on return is meaningless.
> 
> The label .Lpartial_fixup\@ is jumped to on page fault. In order to work
> out how many bytes failed to copy, the exception handler should find how
> many bytes left in the partial block (andi a2, STORMASK), add that to
> the partial block end address (a2), and subtract the faulting address to
> get the remainder. Currently it incorrectly subtracts the partial block
> start address (t1), which has additionally has been clobbered to
> generate a jump target in memset_partial. Fix this by adding the block
> end address instead.
> 
> This issue was found with the following test code:
>   int j, k;
>   for (j = 0; j < 512; j++) {
> if ((k = clear_user(NULL, j)) != j) {
>pr_err("clear_user (NULL %d) returned %d\n", j, k);
> }
>   }
> Which now passes on Creator Ci40 (MIPS32) and Cavium Octeon II (MIPS64).
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: sta...@vger.kernel.org
> Suggested-by: James Hogan <jho...@kernel.org>
> Signed-off-by: Matt Redfearn <matt.redfe...@mips.com>

Applied, thanks
James


signature.asc
Description: Digital signature

Re: [PATCH v3] MIPS: memset.S: Fix return of __clear_user from Lpartial_fixup

[James Hogan]

On Tue, Apr 17, 2018 at 03:52:21PM +0100, Matt Redfearn wrote:
> The __clear_user function is defined to return the number of bytes that
> could not be cleared. From the underlying memset / bzero implementation
> this means setting register a2 to that number on return. Currently if a
> page fault is triggered within the memset_partial block, the value
> loaded into a2 on return is meaningless.
> 
> The label .Lpartial_fixup\@ is jumped to on page fault. In order to work
> out how many bytes failed to copy, the exception handler should find how
> many bytes left in the partial block (andi a2, STORMASK), add that to
> the partial block end address (a2), and subtract the faulting address to
> get the remainder. Currently it incorrectly subtracts the partial block
> start address (t1), which has additionally has been clobbered to
> generate a jump target in memset_partial. Fix this by adding the block
> end address instead.
> 
> This issue was found with the following test code:
>   int j, k;
>   for (j = 0; j < 512; j++) {
> if ((k = clear_user(NULL, j)) != j) {
>pr_err("clear_user (NULL %d) returned %d\n", j, k);
> }
>   }
> Which now passes on Creator Ci40 (MIPS32) and Cavium Octeon II (MIPS64).
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: sta...@vger.kernel.org
> Suggested-by: James Hogan 
> Signed-off-by: Matt Redfearn 

Applied, thanks
James


signature.asc
Description: Digital signature

[PATCH v3 0/3] MIPS: Override barrier_before_unreachable() to fix microMIPS

[James Hogan]

This series overrides barrier_before_unreachable() for MIPS to add an
.insn assembler directive.

Due to the subsequent __builtin_unreachable(), the assembler can't tell
that a label on the empty inline asm is code rather than data, so any
microMIPS branches targetting it (which sadly can't be removed) raise
errors due to the mismatching ISA mode, Adding the .insn in patch 3
tells the assembler that it should be treated as code.

To do this we add a new standard asm/compiler.h for architecture
overrides in patch 2. There are a few existing asm/compiler.h files
already existing, most of which are fairly simple and don't include
anything else (arm, arm64, mips). Unfortunately the alpha one includes
linux/compiler.h though, so it can undefine some inline macros. On
Arnd's suggestion this is converted to use OPTIMIZE_INLINING instead in
patch 1. A build of alpha's defconfig on GCC 7.3 before and after this
series results in the following size differences, which appear harmless
to me:

$ ./scripts/bloat-o-meter vmlinux.1 vmlinux.2
add/remove: 1/1 grow/shrink: 3/0 up/down: 264/-348 (-84)
Function old new   delta
cap_bprm_set_creds  14961664+168
cap_issubset   -  68 +68
flex_array_put   328 344 +16
cap_capset   488 500 +12
nonroot_raised_pE.constprop  348   --348
Total: Before=5823709, After=5823625, chg -0.00%

Cc: Arnd Bergmann <a...@arndb.de>
Cc: Richard Henderson <r...@twiddle.net>
Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
Cc: Matt Turner <matts...@gmail.com>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: Paul Burton <paul.bur...@mips.com>
Cc: Matthew Fortune <matthew.fort...@mips.com>
Cc: Robert Suchanek <robert.sucha...@mips.com>
Cc: linux-al...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-a...@vger.kernel.org

James Hogan (1):
  alpha: Use OPTIMIZE_INLINING instead of asm/compiler.h

Paul Burton (2):
  compiler.h: Allow arch-specific overrides
  MIPS: Workaround GCC __builtin_unreachable reordering bug

 arch/alpha/Kconfig |  6 ++
 arch/alpha/include/asm/compiler.h  | 11 ---
 arch/arc/include/asm/Kbuild|  1 +
 arch/c6x/include/asm/Kbuild|  1 +
 arch/h8300/include/asm/Kbuild  |  1 +
 arch/hexagon/include/asm/Kbuild|  1 +
 arch/ia64/include/asm/Kbuild   |  1 +
 arch/m68k/include/asm/Kbuild   |  1 +
 arch/microblaze/include/asm/Kbuild |  1 +
 arch/mips/include/asm/compiler.h   | 23 +++
 arch/nds32/include/asm/Kbuild  |  1 +
 arch/nios2/include/asm/Kbuild  |  1 +
 arch/openrisc/include/asm/Kbuild   |  1 +
 arch/parisc/include/asm/Kbuild |  1 +
 arch/powerpc/include/asm/Kbuild|  1 +
 arch/riscv/include/asm/Kbuild  |  1 +
 arch/s390/include/asm/Kbuild   |  1 +
 arch/sh/include/asm/Kbuild |  1 +
 arch/sparc/include/asm/Kbuild  |  1 +
 arch/um/include/asm/Kbuild |  1 +
 arch/unicore32/include/asm/Kbuild  |  1 +
 arch/x86/include/asm/Kbuild|  1 +
 arch/xtensa/include/asm/Kbuild |  1 +
 include/asm-generic/compiler.h |  8 
 include/linux/compiler-gcc.h   |  2 ++
 include/linux/compiler_types.h |  3 +++
 26 files changed, 62 insertions(+), 11 deletions(-)
 create mode 100644 include/asm-generic/compiler.h

base-commit: b284d4d5a6785f8cd07eda2646a95782373cd01e
-- 
git-series 0.9.1

[PATCH v3 0/3] MIPS: Override barrier_before_unreachable() to fix microMIPS

[James Hogan]

This series overrides barrier_before_unreachable() for MIPS to add an
.insn assembler directive.

Due to the subsequent __builtin_unreachable(), the assembler can't tell
that a label on the empty inline asm is code rather than data, so any
microMIPS branches targetting it (which sadly can't be removed) raise
errors due to the mismatching ISA mode, Adding the .insn in patch 3
tells the assembler that it should be treated as code.

To do this we add a new standard asm/compiler.h for architecture
overrides in patch 2. There are a few existing asm/compiler.h files
already existing, most of which are fairly simple and don't include
anything else (arm, arm64, mips). Unfortunately the alpha one includes
linux/compiler.h though, so it can undefine some inline macros. On
Arnd's suggestion this is converted to use OPTIMIZE_INLINING instead in
patch 1. A build of alpha's defconfig on GCC 7.3 before and after this
series results in the following size differences, which appear harmless
to me:

$ ./scripts/bloat-o-meter vmlinux.1 vmlinux.2
add/remove: 1/1 grow/shrink: 3/0 up/down: 264/-348 (-84)
Function old new   delta
cap_bprm_set_creds  14961664+168
cap_issubset   -  68 +68
flex_array_put   328 344 +16
cap_capset   488 500 +12
nonroot_raised_pE.constprop  348   --348
Total: Before=5823709, After=5823625, chg -0.00%

Cc: Arnd Bergmann 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: Matthew Fortune 
Cc: Robert Suchanek 
Cc: linux-al...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-a...@vger.kernel.org

James Hogan (1):
  alpha: Use OPTIMIZE_INLINING instead of asm/compiler.h

Paul Burton (2):
  compiler.h: Allow arch-specific overrides
  MIPS: Workaround GCC __builtin_unreachable reordering bug

 arch/alpha/Kconfig |  6 ++
 arch/alpha/include/asm/compiler.h  | 11 ---
 arch/arc/include/asm/Kbuild|  1 +
 arch/c6x/include/asm/Kbuild|  1 +
 arch/h8300/include/asm/Kbuild  |  1 +
 arch/hexagon/include/asm/Kbuild|  1 +
 arch/ia64/include/asm/Kbuild   |  1 +
 arch/m68k/include/asm/Kbuild   |  1 +
 arch/microblaze/include/asm/Kbuild |  1 +
 arch/mips/include/asm/compiler.h   | 23 +++
 arch/nds32/include/asm/Kbuild  |  1 +
 arch/nios2/include/asm/Kbuild  |  1 +
 arch/openrisc/include/asm/Kbuild   |  1 +
 arch/parisc/include/asm/Kbuild |  1 +
 arch/powerpc/include/asm/Kbuild|  1 +
 arch/riscv/include/asm/Kbuild  |  1 +
 arch/s390/include/asm/Kbuild   |  1 +
 arch/sh/include/asm/Kbuild |  1 +
 arch/sparc/include/asm/Kbuild  |  1 +
 arch/um/include/asm/Kbuild |  1 +
 arch/unicore32/include/asm/Kbuild  |  1 +
 arch/x86/include/asm/Kbuild|  1 +
 arch/xtensa/include/asm/Kbuild |  1 +
 include/asm-generic/compiler.h |  8 
 include/linux/compiler-gcc.h   |  2 ++
 include/linux/compiler_types.h |  3 +++
 26 files changed, 62 insertions(+), 11 deletions(-)
 create mode 100644 include/asm-generic/compiler.h

base-commit: b284d4d5a6785f8cd07eda2646a95782373cd01e
-- 
git-series 0.9.1

[PATCH v3 3/3] MIPS: Workaround GCC __builtin_unreachable reordering bug

[James Hogan]

From: Paul Burton <paul.bur...@mips.com>

Older versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.

See this potential GCC fix for details:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html

This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call. This was actually done for other reasons by
commit 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()"), but
without the MIPS specific .insn, which broke microMIPS builds on newer
GCC 7.2 toolchains with errors like the following:

arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA 
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA 
mode

The original bug affects at least a maltasmvp_defconfig kernel built
from the v4.4 tag using GCC 4.9.2 (from a Codescape SDK 2015.06-05
toolchain), with the result being an address exception taken after log
messages about the L1 caches (during probe of the L2 cache):

Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes


This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms.

Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Signed-off-by: Paul Burton <paul.bur...@mips.com>
[jho...@kernel.org: Forward port and use asm/compiler.h instead of
 asm/compiler-gcc.h]
Signed-off-by: James Hogan <jho...@kernel.org>
Reviewed-by: Paul Burton <paul.bur...@mips.com>
Cc: Matthew Fortune <matthew.fort...@mips.com>
Cc: Robert Suchanek <robert.sucha...@mips.com>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: linux-m...@linux-mips.org
---
This is an alternative approach to this earlier patch which seems to
have been rejected:

https://patchwork.linux-mips.org/patch/12556/
https://marc.info/?l=linux-mips=14921408274=2

Changes in v3 (James):
- Forward port to v4.17-rc and update commit message.
- Drop stable tag for now.

Changes in v2 (Paul):
- Remove generic-y entry.
---
 arch/mips/include/asm/compiler.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/mips/include/asm/compiler.h b/arch/mips/include/asm/compiler.h
index e081a265f422..ff2a412899d4 100644
--- a/arch/mips/include/asm/compiler.h
+++ b/arch/mips/include/asm/compiler.h
@@ -8,6 +8,29 @@
 #ifndef _ASM_COMPILER_H
 #define _ASM_COMPILER_H
 
+/*
+ * With GCC v4.5 onwards can use __builtin_unreachable to indicate to the
+ * compiler that a particular code path will never be hit. This allows it to be
+ * optimised out of the generated binary.
+ *
+ * Unfortunately GCC from at least v4.9.2 to current head of tree as of May
+ * 2016 suffer from a bug that can lead to instructions from beyond an
+ * unreachable statement being incorrectly reordered into earlier delay slots
+ * if the unreachable statement is the only content of a case in a switch
+ * statement. This can lead to seemingly random behaviour, such as invalid
+ * memory accesses from incorrectly reordered loads or stores. See this
+ * potential GCC fix for details:
+ *
+ *   https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
+ *
+ * We work around this by placing a volatile asm statement, which GCC is
+ * prevented from reordering past, prior to the __builtin_unreachable call. The
+ * .insn statement is required to ensure that any branches to the statement,
+ * which sadly must be kept due to the asm statement, are known to be branches
+ * to code and satisfy linker requirements for microMIPS kernels.
+ */
+#define barrier_before_unreachable() asm volatile(".insn")
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)
 #define GCC_IMM_ASM() "n"
 #define GCC_REG_ACCUM "$0"
-- 
git-series 0.9.1

[PATCH v3 3/3] MIPS: Workaround GCC __builtin_unreachable reordering bug

[James Hogan]

From: Paul Burton 

Older versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.

See this potential GCC fix for details:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html

This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call. This was actually done for other reasons by
commit 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()"), but
without the MIPS specific .insn, which broke microMIPS builds on newer
GCC 7.2 toolchains with errors like the following:

arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA 
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA 
mode

The original bug affects at least a maltasmvp_defconfig kernel built
from the v4.4 tag using GCC 4.9.2 (from a Codescape SDK 2015.06-05
toolchain), with the result being an address exception taken after log
messages about the L1 caches (during probe of the L2 cache):

Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes


This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms.

Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Signed-off-by: Paul Burton 
[jho...@kernel.org: Forward port and use asm/compiler.h instead of
 asm/compiler-gcc.h]
Signed-off-by: James Hogan 
Reviewed-by: Paul Burton 
Cc: Matthew Fortune 
Cc: Robert Suchanek 
Cc: Ralf Baechle 
Cc: Arnd Bergmann 
Cc: linux-m...@linux-mips.org
---
This is an alternative approach to this earlier patch which seems to
have been rejected:

https://patchwork.linux-mips.org/patch/12556/
https://marc.info/?l=linux-mips=14921408274=2

Changes in v3 (James):
- Forward port to v4.17-rc and update commit message.
- Drop stable tag for now.

Changes in v2 (Paul):
- Remove generic-y entry.
---
 arch/mips/include/asm/compiler.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/mips/include/asm/compiler.h b/arch/mips/include/asm/compiler.h
index e081a265f422..ff2a412899d4 100644
--- a/arch/mips/include/asm/compiler.h
+++ b/arch/mips/include/asm/compiler.h
@@ -8,6 +8,29 @@
 #ifndef _ASM_COMPILER_H
 #define _ASM_COMPILER_H
 
+/*
+ * With GCC v4.5 onwards can use __builtin_unreachable to indicate to the
+ * compiler that a particular code path will never be hit. This allows it to be
+ * optimised out of the generated binary.
+ *
+ * Unfortunately GCC from at least v4.9.2 to current head of tree as of May
+ * 2016 suffer from a bug that can lead to instructions from beyond an
+ * unreachable statement being incorrectly reordered into earlier delay slots
+ * if the unreachable statement is the only content of a case in a switch
+ * statement. This can lead to seemingly random behaviour, such as invalid
+ * memory accesses from incorrectly reordered loads or stores. See this
+ * potential GCC fix for details:
+ *
+ *   https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
+ *
+ * We work around this by placing a volatile asm statement, which GCC is
+ * prevented from reordering past, prior to the __builtin_unreachable call. The
+ * .insn statement is required to ensure that any branches to the statement,
+ * which sadly must be kept due to the asm statement, are known to be branches
+ * to code and satisfy linker requirements for microMIPS kernels.
+ */
+#define barrier_before_unreachable() asm volatile(".insn")
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)
 #define GCC_IMM_ASM() "n"
 #define GCC_REG_ACCUM "$0"
-- 
git-series 0.9.1

[PATCH v3 1/3] alpha: Use OPTIMIZE_INLINING instead of asm/compiler.h

[James Hogan]

Use CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING and CONFIG_OPTIMIZE_INLINING
instead of undefining the inline macros in the alpha specific
asm/compiler.h. This is to allow asm/compiler.h to become a general
header that can be used for overriding linux/compiler*.h.

A build of alpha's defconfig on GCC 7.3 before and after this series
(i.e. this commit and "compiler.h: Allow arch-specific overrides" which
includes asm/compiler.h from linux/compiler_types.h) results in the
following size differences, which appear harmless to me:

$ ./scripts/bloat-o-meter vmlinux.1 vmlinux.2
add/remove: 1/1 grow/shrink: 3/0 up/down: 264/-348 (-84)
Function old new   delta
cap_bprm_set_creds  14961664+168
cap_issubset   -  68 +68
flex_array_put   328 344 +16
cap_capset   488 500 +12
nonroot_raised_pE.constprop  348   --348
Total: Before=5823709, After=5823625, chg -0.00%

Suggested-by: Arnd Bergmann <a...@arndb.de>
Signed-off-by: James Hogan <jho...@kernel.org>
Cc: Richard Henderson <r...@twiddle.net>
Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
Cc: Matt Turner <matts...@gmail.com>
Cc: linux-al...@vger.kernel.org
---
Changes in v3 (James):
- New patch in v3.
---
 arch/alpha/Kconfig|  6 ++
 arch/alpha/include/asm/compiler.h | 11 ---
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index b2022885ced8..b296ba9bd8b7 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -81,6 +81,12 @@ config PGTABLE_LEVELS
int
default 3
 
+config ARCH_SUPPORTS_OPTIMIZED_INLINING
+   def_bool y
+
+config OPTIMIZE_INLINING
+   def_bool y
+
 source "init/Kconfig"
 source "kernel/Kconfig.freezer"
 
diff --git a/arch/alpha/include/asm/compiler.h 
b/arch/alpha/include/asm/compiler.h
index 5159ba259d65..ae645959018a 100644
--- a/arch/alpha/include/asm/compiler.h
+++ b/arch/alpha/include/asm/compiler.h
@@ -4,15 +4,4 @@
 
 #include 
 
-/* Some idiots over in  thought inline should imply
-   always_inline.  This breaks stuff.  We'll include this file whenever
-   we run into such problems.  */
-
-#include 
-#undef inline
-#undef __inline__
-#undef __inline
-#undef __always_inline
-#define __always_inlineinline __attribute__((always_inline))
-
 #endif /* __ALPHA_COMPILER_H */
-- 
git-series 0.9.1

[PATCH v3 2/3] compiler.h: Allow arch-specific overrides

[James Hogan]

From: Paul Burton <paul.bur...@mips.com>

Include an arch-specific asm/compiler.h and allow for it to define a
custom version of barrier_before_unreachable(), which is needed to
workaround several issues on the MIPS architecture.

This patch includes an effectively empty asm-generic implementation of
asm/compiler.h for all architectures except alpha, arm, arm64, and mips
(which already have an asm/compiler.h) and leaves the architecture
specifics to a further patch.

Signed-off-by: Paul Burton <paul.bur...@mips.com>
[jho...@kernel.org: Forward port and use asm/compiler.h instead of
 asm/compiler-gcc.h]
Signed-off-by: James Hogan <jho...@kernel.org>
Reviewed-by: Paul Burton <paul.bur...@mips.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: linux-a...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
Changes in v3 (James):
- Rebase after 4.17 arch removal.
- Use asm/compiler.h instead of compiler-gcc.h (Arnd).
- Drop stable tag for now.

Changes in v2 (Paul):
- Add generic-y entries to arch Kbuild files. Oops!
---
 arch/arc/include/asm/Kbuild| 1 +
 arch/c6x/include/asm/Kbuild| 1 +
 arch/h8300/include/asm/Kbuild  | 1 +
 arch/hexagon/include/asm/Kbuild| 1 +
 arch/ia64/include/asm/Kbuild   | 1 +
 arch/m68k/include/asm/Kbuild   | 1 +
 arch/microblaze/include/asm/Kbuild | 1 +
 arch/nds32/include/asm/Kbuild  | 1 +
 arch/nios2/include/asm/Kbuild  | 1 +
 arch/openrisc/include/asm/Kbuild   | 1 +
 arch/parisc/include/asm/Kbuild | 1 +
 arch/powerpc/include/asm/Kbuild| 1 +
 arch/riscv/include/asm/Kbuild  | 1 +
 arch/s390/include/asm/Kbuild   | 1 +
 arch/sh/include/asm/Kbuild | 1 +
 arch/sparc/include/asm/Kbuild  | 1 +
 arch/um/include/asm/Kbuild | 1 +
 arch/unicore32/include/asm/Kbuild  | 1 +
 arch/x86/include/asm/Kbuild| 1 +
 arch/xtensa/include/asm/Kbuild | 1 +
 include/asm-generic/compiler.h | 8 
 include/linux/compiler-gcc.h   | 2 ++
 include/linux/compiler_types.h | 3 +++
 23 files changed, 33 insertions(+)
 create mode 100644 include/asm-generic/compiler.h

diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index 4bd5d4369e05..61ba443ad252 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 generic-y += bugs.h
+generic-y += compiler.h
 generic-y += device.h
 generic-y += div64.h
 generic-y += emergency-restart.h
diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild
index fd4c840de837..ddfa28f80955 100644
--- a/arch/c6x/include/asm/Kbuild
+++ b/arch/c6x/include/asm/Kbuild
@@ -1,6 +1,7 @@
 generic-y += atomic.h
 generic-y += barrier.h
 generic-y += bugs.h
+generic-y += compiler.h
 generic-y += current.h
 generic-y += device.h
 generic-y += div64.h
diff --git a/arch/h8300/include/asm/Kbuild b/arch/h8300/include/asm/Kbuild
index 14bac06b7116..bf06091a6034 100644
--- a/arch/h8300/include/asm/Kbuild
+++ b/arch/h8300/include/asm/Kbuild
@@ -3,6 +3,7 @@ generic-y += barrier.h
 generic-y += bugs.h
 generic-y += cacheflush.h
 generic-y += checksum.h
+generic-y += compiler.h
 generic-y += current.h
 generic-y += delay.h
 generic-y += device.h
diff --git a/arch/hexagon/include/asm/Kbuild b/arch/hexagon/include/asm/Kbuild
index e9743f689fb8..dccedfd7559e 100644
--- a/arch/hexagon/include/asm/Kbuild
+++ b/arch/hexagon/include/asm/Kbuild
@@ -2,6 +2,7 @@
 generic-y += barrier.h
 generic-y += bug.h
 generic-y += bugs.h
+generic-y += compiler.h
 generic-y += current.h
 generic-y += device.h
 generic-y += div64.h
diff --git a/arch/ia64/include/asm/Kbuild b/arch/ia64/include/asm/Kbuild
index 6dd867873364..886bae7b001f 100644
--- a/arch/ia64/include/asm/Kbuild
+++ b/arch/ia64/include/asm/Kbuild
@@ -1,3 +1,4 @@
+generic-y += compiler.h
 generic-y += exec.h
 generic-y += irq_work.h
 generic-y += mcs_spinlock.h
diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild
index 88a9d27df1ac..089cd9b3c9fd 100644
--- a/arch/m68k/include/asm/Kbuild
+++ b/arch/m68k/include/asm/Kbuild
@@ -1,4 +1,5 @@
 generic-y += barrier.h
+generic-y += compiler.h
 generic-y += device.h
 generic-y += emergency-restart.h
 generic-y += exec.h
diff --git a/arch/microblaze/include/asm/Kbuild 
b/arch/microblaze/include/asm/Kbuild
index 3c80a5a308ed..920ee0afc627 100644
--- a/arch/microblaze/include/asm/Kbuild
+++ b/arch/microblaze/include/asm/Kbuild
@@ -2,6 +2,7 @@ generic-y += barrier.h
 generic-y += bitops.h
 generic-y += bug.h
 generic-y += bugs.h
+generic-y += compiler.h
 generic-y += device.h
 generic-y += div64.h
 generic-y += emergency-restart.h
diff --git a/arch/nds32/include/asm/Kbuild b/arch/nds32/include/asm/Kbuild
index 06bdf8167f5a..5536db1084f4 100644
--- a/arch/nds32/include/asm/Kbuild
+++ b/arch/nds32/include/asm/Kbuild
@@ -9,6 +9,7 @@ generic-y += checksum.h
 generic-y += clkdev.h
 generic-y += cmpxchg.h
 generic-y += cmpxchg-local.h
+generic-y +