Re: [PATCH v2] powerpc: Add POWER9 architected mode to cputable

[Michael Ellerman]

Russell Currey  writes:
> On Fri, 2017-02-17 at 21:26 +1100, Michael Ellerman wrote:
>> Russell Currey  writes:
>> > diff --git a/arch/powerpc/kernel/cputable.c 
>> > b/arch/powerpc/kernel/cputable.c
>> > index 6a82ef039c50..d23a54b09436 100644
>> > --- a/arch/powerpc/kernel/cputable.c
>> > +++ b/arch/powerpc/kernel/cputable.c
>> > @@ -386,6 +386,25 @@ static struct cpu_spec __initdata cpu_specs[] = {
>> >    .machine_check_early=
>> > __machine_check_early_realmode_p8,
>> >    .platform   = "power8",
>> >    },
>> > +  {   /* 3.00-compliant processor, i.e. Power9 "architected"
>> > mode */
>> > +  .pvr_mask   = 0x,
>> > +  .pvr_value  = 0x0f05,
>> > +  .cpu_name   = "POWER9 (architected)",
>> > +  .cpu_features   = CPU_FTRS_POWER9,
>> > +  .cpu_user_features  = COMMON_USER_POWER9,
>> > +  .cpu_user_features2 = COMMON_USER2_POWER9,
>> > +  .mmu_features   = MMU_FTRS_POWER9,
>> > +  .icache_bsize   = 128,
>> > +  .dcache_bsize   = 128,
>> > +  .num_pmcs   = 6,
>> 
>> It's important *not* to set num_pmcs for the architected PVRs.
...
>
> Oh and also, do you want me to respin or are you happy to drop it on your end?

I fixed it up:

commit 6ae3f8ad2017079292cb49c8959b527bcbcbefed
Author: Russell Currey 
AuthorDate: Fri Feb 17 13:01:35 2017 +1100
Commit: Michael Ellerman 
CommitDate: Fri Feb 17 21:48:56 2017 +1100

powerpc: Add POWER9 architected mode to cputable

PVR value of 0x0F05 means we are arch v3.00 compliant (i.e. POWER9).

Acked-by: Michael Neuling 
Signed-off-by: Russell Currey 
[mpe: Don't set num_pmcs, so we keep the PMU fields from the raw entry]
Signed-off-by: Michael Ellerman 

diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 6a82ef039c50..bb7a1890aeb7 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -386,6 +386,23 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check_early= __machine_check_early_realmode_p8,
.platform   = "power8",
},
+   {   /* 3.00-compliant processor, i.e. Power9 "architected" mode */
+   .pvr_mask   = 0x,
+   .pvr_value  = 0x0f05,
+   .cpu_name   = "POWER9 (architected)",
+   .cpu_features   = CPU_FTRS_POWER9,
+   .cpu_user_features  = COMMON_USER_POWER9,
+   .cpu_user_features2 = COMMON_USER2_POWER9,
+   .mmu_features   = MMU_FTRS_POWER9,
+   .icache_bsize   = 128,
+   .dcache_bsize   = 128,
+   .oprofile_type  = PPC_OPROFILE_INVALID,
+   .oprofile_cpu_type  = "ppc64/ibm-compat-v1",
+   .cpu_setup  = __setup_cpu_power9,
+   .cpu_restore= __restore_cpu_power9,
+   .flush_tlb  = __flush_tlb_power9,
+   .platform   = "power9",
+   },
{   /* Power7 */
.pvr_mask   = 0x,
.pvr_value  = 0x003f,


cheers

Re: [PATCH] powerpc: implement clear_bit_unlock_is_negative_byte()

[Michael Ellerman]

Nicholas Piggin  writes:

> Commit b91e1302ad9b8 ("mm: optimize PageWaiters bit use for
> unlock_page()") added a special bitop function to speed up
> unlock_page(). Implement this for powerpc.

I know you wrote this to work on 32 and 64-bit, but I don't have a good
way to test it on 32-bit at the moment as my 32-bit box is blowing
chunks.

So I've taken this but made it 64-bit only for now.

cheers

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Joe Perches]

On Fri, 2017-02-17 at 15:57 -0800, Nicolin Chen wrote:
> On Fri, Feb 17, 2017 at 11:48:54PM +, Mark Brown wrote:
> > On Fri, Feb 17, 2017 at 12:28:44PM -0800, Nicolin Chen wrote:
> > > On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> > > > To enable eventual removal of pr_warning
> > > > 
> > > > This makes pr_warn use consistent for sound/soc
> > > > 
> > > > Prior to this patch, there were 5 uses of pr_warning and
> > > > 10 uses of pr_warn in sound/soc
> > > > 
> > > > Signed-off-by: Joe Perches 
> > > 
> > > For imx-audmux.c,
> > 
> > I don't have this patch, perhaps it got caught in a spam filter or
> > perhaps it got deleted because as ever you're not using subject lines
> > reflecting the style for the subsystem.
> 
> My bad that I didn't pay attention to the subject.
> 
> Joe, please fix it in v2. Thanks.
> 
> ASoC: Convert remaining uses of pr_warning to pr_warn

This is a treewide scripted patch which is
basically just a sed.

If or when you apply it, you should
fix it up to suit.

$ git log -1000 --pretty=oneline --no-merges sound/soc | \
  cut -f2- -d" " | cut -f1 -d":" |sort | uniq
ALSA
AsoC
ASoc
ASoC
ASOC
ASoC fix up SND_SOC_WM8985 dependency
drm/i915/dp
kthread
lib/vsprintf.c
scripts/spelling.txt
sgtl5000
SoC
sound/soc
treewide

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Mark Brown]

On Fri, Feb 17, 2017 at 12:28:44PM -0800, Nicolin Chen wrote:
> On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> > To enable eventual removal of pr_warning
> > 
> > This makes pr_warn use consistent for sound/soc
> > 
> > Prior to this patch, there were 5 uses of pr_warning and
> > 10 uses of pr_warn in sound/soc
> > 
> > Signed-off-by: Joe Perches 
> 
> For imx-audmux.c,

I don't have this patch, perhaps it got caught in a spam filter or
perhaps it got deleted because as ever you're not using subject lines
reflecting the style for the subsystem.


signature.asc
Description: PGP signature

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Nicolin Chen]

On Fri, Feb 17, 2017 at 11:48:54PM +, Mark Brown wrote:
> On Fri, Feb 17, 2017 at 12:28:44PM -0800, Nicolin Chen wrote:
> > On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> > > To enable eventual removal of pr_warning
> > > 
> > > This makes pr_warn use consistent for sound/soc
> > > 
> > > Prior to this patch, there were 5 uses of pr_warning and
> > > 10 uses of pr_warn in sound/soc
> > > 
> > > Signed-off-by: Joe Perches 
> > 
> > For imx-audmux.c,
> 
> I don't have this patch, perhaps it got caught in a spam filter or
> perhaps it got deleted because as ever you're not using subject lines
> reflecting the style for the subsystem.

My bad that I didn't pay attention to the subject.

Joe, please fix it in v2. Thanks.

ASoC: Convert remaining uses of pr_warning to pr_warn

PowerMac G5 Quad Strage lspci

[luigi burdo]

Hi all devs,

from 4.10 i have on G5 Quad this strange lspci

with this 0001:01:01.0 Non-VGA unclassified device: Device 0800:0002 (rev 08)

some one know if it a bug or a new feature of the kernel.


Thanks!


My complete

lspci
:00:0b.0 PCI bridge: Apple Inc. CPC945 PCIe Bridge
:0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Whistler LE [Radeon HD 6610M/7610M]
:0a:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Turks HDMI 
Audio [Radeon HD 6500/6600 / 6700M Series]
0001:00:00.0 Host bridge: Apple Inc. U4 HT Bridge
0001:00:01.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-X bridge (rev a3)
0001:00:02.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-X bridge (rev a3)
0001:00:03.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-Express Bridge (rev a3)
0001:00:04.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-Express Bridge (rev a3)
0001:00:05.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-Express Bridge (rev a3)
0001:00:06.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-Express Bridge (rev a3)
0001:00:07.0 PCI bridge: Apple Inc. Shasta PCI Bridge
0001:00:08.0 PCI bridge: Apple Inc. Shasta PCI Bridge
0001:00:09.0 PCI bridge: Apple Inc. Shasta PCI Bridge
0001:01:01.0 Non-VGA unclassified device: Device 0800:0002 (rev 08)
0001:01:07.0 Unassigned class [ff00]: Apple Inc. Shasta Mac I/O
0001:01:0b.0 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:01:0b.1 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:01:0b.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 
04)
0001:03:0c.0 IDE interface: Broadcom K2 SATA
0001:03:0d.0 Unassigned class [ff00]: Apple Inc. Shasta IDE
0001:03:0e.0 FireWire (IEEE 1394): Apple Inc. Shasta Firewire
0001:05:04.0 Ethernet controller: Broadcom Limited NetXtreme BCM5780 Gigabit 
Ethernet (rev 03)
0001:05:04.1 Ethernet controller: Broadcom Limited NetXtreme BCM5780 Gigabit 
Ethernet (rev 03)
0001:06:00.0 VGA compatible controller: NVIDIA Corporation G70GL [Quadro FX 
4500] (rev a1)

Luigi

[PATCH] tty: hvc: don't allocate a buffer for console print on stack

[Jan Dakinevich]

The buffer is used by virtio console driver as DMA buffer. Since v4.9
(if VMAP_STACK is enabled) we shouldn't use the stack for DMA.

Signed-off-by: Jan Dakinevich 
---
 drivers/tty/hvc/hvc_console.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 9b5c0fb..1ce6aaf 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -143,10 +143,15 @@ static struct hvc_struct *hvc_get_by_index(int index)
 static void hvc_console_print(struct console *co, const char *b,
  unsigned count)
 {
-   char c[N_OUTBUF] __ALIGNED__;
unsigned i = 0, n = 0;
int r, donecr = 0, index = co->index;
 
+   /*
+* Access to the buffer is serialized by console_sem in caller code from
+* kernel/printk/printk.c
+*/
+   static char c[N_OUTBUF] __ALIGNED__;
+
/* Console access attempt outside of acceptable console range. */
if (index >= MAX_NR_HVC_CONSOLES)
return;
-- 
1.9.1

RE: [PATCHv3 4/4] MAINTAINERS: Remove powerpc's opal match

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: linux-block-ow...@vger.kernel.org [mailto:linux-block-
> ow...@vger.kernel.org] On Behalf Of Jon Derrick
> Sent: Thursday, February 16, 2017 10:15 AM
> To: Michael Ellerman 
> Cc: Jens Axboe ; Rafael Antognolli
> ; Greg Kroah-Hartman
> ; linux-ker...@vger.kernel.org; linux-
> bl...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Christoph Hellwig
> ; Scott Bauer 
> Subject: Re: [PATCHv3 4/4] MAINTAINERS: Remove powerpc's opal match
> 
> Thanks everyone. Sorry about the mess :)
> 
> On 02/15/2017 10:23 PM, Michael Ellerman wrote:
> > Jon Derrick  writes:
> >
> >> PPC's 'opal' match pattern also matches block/sed-opal.c, where it looks
> >> like the 'arch/powerpc' file pattern should be enough to match powerpc
> >> opal code by itself. Remove the opal regex pattern from powerpc.
> >
> > We thought of it first.
> >
> > Can't you just rename your driver, Opal Storage Specification, so "oss",
> > that should be pretty unique?
> >
> > ... :)

The library could easily be used for devices supporting the Opalite and Pyrite 
SSCs, not just the Opal SSC. With some effort, I suspect that Enterprise SSC
could also be supported.  So, a broader name might indeed be useful.

The full names of the specifications are:
TCG Storage Security Subsystem Class: Opal
TCG Storage Security Subsystem Class: Opalite
TCG Storage Security Subsystem Class: Pyrite
TCG Storage Security Subsystem Class: Enterprise

---
Robert Elliott, HPE Persistent Memory

Re: [PATCH 0/2] powerpc: kretprobe updates

[Arnaldo Carvalho de Melo]

Em Fri, Feb 17, 2017 at 07:44:33PM +0900, Masami Hiramatsu escreveu:
> On Thu, 16 Feb 2017 13:47:37 +0530
> "Naveen N. Rao"  wrote:
> 
> > I am posting the powerpc bits in the same thread so as to keep these
> > changes together. I am not sure how this should be taken upstream as
> > there are atleast three different trees involved: one for the core
> > kprobes infrastructure, one for powerpc and one for perf.

> Hmm, could you make these (and other related) patches and
> other series in one series? Or wait for the other series
> are merged correctly.

Well, patches like these should be done in a way that the tooling parts
can deal with kernels with or without the kernel changes, so that older
tools work with new kernels and new tools work with older kernels.

"work" as in the previous behaviour is kept when a new tool deals with
an older kernel and an older tool would warn the user that what it needs
is not present in that kernel.

Is this the case? I just looked briefly at the patch commit logs.

If it is, then I can pick the tool ones, and the others can be submitted
to the relevant trees, at some point all will be in, kernels eventually
gets updated everywhere, ditto for the tooling, all gets well.

Regards,

- Arnaldo


 
> Thank you,
> 
> > 
> > Thanks,
> > Naveen
> > 
> > Naveen N. Rao (2):
> >   powerpc: kretprobes: override default function entry offset
> >   perf: powerpc: choose LEP with kretprobes
> > 
> >  arch/powerpc/kernel/kprobes.c   | 9 +
> >  tools/perf/arch/powerpc/util/sym-handling.c | 5 +
> >  2 files changed, 10 insertions(+), 4 deletions(-)
> > 
> > -- 
> > 2.11.0
> > 
> 
> 
> -- 
> Masami Hiramatsu 

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Nicolin Chen]

On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> To enable eventual removal of pr_warning
> 
> This makes pr_warn use consistent for sound/soc
> 
> Prior to this patch, there were 5 uses of pr_warning and
> 10 uses of pr_warn in sound/soc
> 
> Signed-off-by: Joe Perches 

For imx-audmux.c,

Acked-by: Nicolin Chen 

> ---
>  sound/soc/fsl/imx-audmux.c | 6 +++---
>  sound/soc/samsung/s3c-i2s-v2.c | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/sound/soc/fsl/imx-audmux.c b/sound/soc/fsl/imx-audmux.c
> index fc57da341d61..41e877d2b400 100644
> --- a/sound/soc/fsl/imx-audmux.c
> +++ b/sound/soc/fsl/imx-audmux.c
> @@ -152,7 +152,7 @@ static void audmux_debugfs_init(void)
>  
>   audmux_debugfs_root = debugfs_create_dir("audmux", NULL);
>   if (!audmux_debugfs_root) {
> - pr_warning("Failed to create AUDMUX debugfs root\n");
> + pr_warn("Failed to create AUDMUX debugfs root\n");
>   return;
>   }
>  
> @@ -160,8 +160,8 @@ static void audmux_debugfs_init(void)
>   snprintf(buf, sizeof(buf), "ssi%lu", i);
>   if (!debugfs_create_file(buf, 0444, audmux_debugfs_root,
>(void *)i, _debugfs_fops))
> - pr_warning("Failed to create AUDMUX port %lu debugfs 
> file\n",
> -i);
> + pr_warn("Failed to create AUDMUX port %lu debugfs 
> file\n",
> + i);
>   }
>  }
>  
> diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c
> index 644f186fd35c..7423e4257a1b 100644
> --- a/sound/soc/samsung/s3c-i2s-v2.c
> +++ b/sound/soc/samsung/s3c-i2s-v2.c
> @@ -669,13 +669,13 @@ static int s3c2412_i2s_suspend(struct snd_soc_dai *dai)
>   iismod = readl(i2s->regs + S3C2412_IISMOD);
>  
>   if (iismod & S3C2412_IISCON_RXDMA_ACTIVE)
> - pr_warning("%s: RXDMA active?\n", __func__);
> + pr_warn("%s: RXDMA active?\n", __func__);
>  
>   if (iismod & S3C2412_IISCON_TXDMA_ACTIVE)
> - pr_warning("%s: TXDMA active?\n", __func__);
> + pr_warn("%s: TXDMA active?\n", __func__);
>  
>   if (iismod & S3C2412_IISCON_IIS_ACTIVE)
> - pr_warning("%s: IIS active\n", __func__);
> + pr_warn("%s: IIS active\n", __func__);
>   }
>  
>   return 0;
> -- 
> 2.10.0.rc2.1.g053435c
> 

Re: [PATCH] net/wan: add MODULE_LICENSE for fsl_ucc_hdlc

[David Miller]

From: Valentin Longchamp 
Date: Fri, 17 Feb 2017 11:31:22 +0100

> It is required to build it as a module.
> 
> Signed-off-by: Valentin Longchamp 

Applied to net-next.

Re: [RFC PATCH] powerpc: Fix dubious r0 usage

[Segher Boessenkool]

On Fri, Feb 17, 2017 at 11:51:25PM +1030, Alan Modra wrote:
> On Fri, Feb 17, 2017 at 11:08:53PM +1100, Michael Ellerman wrote:
> > Bleeding edge binutils no longer accepts r0 in places where the CPU
> > interprets the value as a literal 0.
> 
> Wow!  That was quite some cleanup.  I think I'd better turn the error
> into a warning..

It also catches programming errors, not just syntax errors.


Segher

Re: [RFC PATCH] powerpc: Fix dubious r0 usage

[Alan Modra]

On Fri, Feb 17, 2017 at 11:08:53PM +1100, Michael Ellerman wrote:
> Bleeding edge binutils no longer accepts r0 in places where the CPU
> interprets the value as a literal 0.

Wow!  That was quite some cleanup.  I think I'd better turn the error
into a warning..

> --- a/arch/powerpc/purgatory/trampoline.S
> +++ b/arch/powerpc/purgatory/trampoline.S
> @@ -67,7 +67,7 @@ master:
>   mr  %r16,%r3/* save dt address in reg16 */
>   li  %r4,20
>   LWZX_BE %r6,%r3,%r4 /* fetch __be32 version number at byte 20 */
> - cmpwi   %r0,%r6,2   /* v2 or later? */
> + cmpwi   0,%r6,2 /* v2 or later? */
>   blt 1f
>   li  %r4,28
>   STWX_BE %r17,%r3,%r4/* Store my cpu as __be32 at byte 28 */

With this one, it would probably be better to omit the zero (BF
field).

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

[Laurentiu Tudor]

On 02/17/2017 02:18 PM, Aneesh Kumar K.V wrote:
> laurentiu.tu...@nxp.com writes:
>
>> From: Laurentiu Tudor 
>>
>> On 32-bit book-e machines, hugepd_ok() does not take
>> into account null hugepd values, causing this crash at boot:
>>
>> Unable to handle kernel paging request for data at address 0x8000
>> Faulting instruction address: 0xc00182a8
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=24
>> CoreNet Generic
>> Modules linked in:
>> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   
>> 4.10.0-rc8-00016-g69b1f87 #11
>> task: e505 task.stack: e5058000
>> NIP: c00182a8 LR: c001829c CTR: 7ffe
>> REGS: e5059c50 TRAP: 0300   Tainted: GW
>> (4.10.0-rc8-00016-g69b1f87)
>> MSR: 00021002 
>>CR: 88428e82  XER: 
>> DEAR: 8000 ESR: 
>> GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08 
>> 2017
>> GPR08:     28428e82  c00027d0 
>> 
>> GPR16:   88a28e82 2000 48422e82  88a28e84 
>> dd004000
>> GPR24: e5059e38   bff1 dd004000 0001 00029002 
>> bff1
>> NIP [c00182a8] follow_huge_addr+0x38/0xf0
>> LR [c001829c] follow_huge_addr+0x2c/0xf0
>> Call Trace:
>> [e5059d00] [e5059d00] 0xe5059d00 (unreliable)
>> [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0
>> [e5059d80] [c0107958] __get_user_pages+0xc8/0x420
>> [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230
>> [e5059e30] [c013f170] copy_strings+0x110/0x3a0
>> [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50
>> [e5059ec0] [c0141324] do_execveat_common+0x474/0x620
>> [e5059f10] [c01414fc] do_execve+0x2c/0x40
>> [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
>> [e5059f30] [c000289c] kernel_init+0xcc/0x120
>> [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64
>> Instruction dump:
>> bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008
>> 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea 2f89
>> ---[ end trace 4bf94e15fd9fa824 ]---
>
>
> Which code path is that. That null should be filtered by the if
> (pmd_none(pmd)) check in find_linux_pte_or_hugepte right ?
>

I haven't characterized the issue in detail as i wanted to get the patch 
out ASAP.
I only noticed that the previous check, that is:

"signed hpd_val > 0"

vs the new one, that is:

"unsigned hpd_val & PD_HUGE == 0"

evaluate differently for a value of zero: old expression evaluates
to false and the new one to true.

---
Best Regards, Laurentiu

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

[Geert Uytterhoeven]

Hi Rafael,

On Fri, Feb 17, 2017 at 1:27 PM, Rafael J. Wysocki  wrote:
> On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches  wrote:
>> There are ~4300 uses of pr_warn and ~250 uses of the older
>> pr_warning in the kernel source tree.
>>
>> Make the use of pr_warn consistent across all kernel files.
>>
>> This excludes all files in tools/ as there is a separate
>> define pr_warning for that directory tree and pr_warn is
>> not used in tools/.
>>
>> Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
>
> Sorry about asking if that has been asked already.
>
> Wouldn't it be slightly less intrusive to simply redefined
> pr_warning() as a synonym for pr_warn()?

That's already the case.

This series cleans up the cruft, so we can catch all users with
"git grep -w pr_warn".

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

[Rafael J. Wysocki]

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches  wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning for that directory tree and pr_warn is
> not used in tools/.
>
> Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.

Sorry about asking if that has been asked already.

Wouldn't it be slightly less intrusive to simply redefined
pr_warning() as a synonym for pr_warn()?

Thanks,
Rafael

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

[Guilherme G. Piccoli]

On 02/17/2017 07:30 AM, Pan Xinhui wrote:
> 
> 
> 在 2017/2/17 14:05, Michael Ellerman 写道:
>> Pan Xinhui  writes:
>>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>>> index 9c0e17c..f6e5c3d 100644
>>> --- a/arch/powerpc/xmon/xmon.c
>>> +++ b/arch/powerpc/xmon/xmon.c
>>> @@ -76,6 +76,7 @@ static int xmon_gate;
>>>   #endif /* CONFIG_SMP */
>>>
>>>   static unsigned long in_xmon __read_mostly = 0;
>>> +static int xmon_off = !IS_ENABLED(CONFIG_XMON_DEFAULT);
>>
>> I think the logic would probably clearer if we invert this to become
>> xmon_on.
>>
> yep, make sense.
> 
>>> @@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void)
>>>   __initcall(setup_xmon_sysrq);
>>>   #endif /* CONFIG_MAGIC_SYSRQ */
>>>
>>> -static int __initdata xmon_early, xmon_off;
>>> +static int __initdata xmon_early;
>>>
>>>   static int __init early_parse_xmon(char *p)
>>>   {
>>> if (!p || strncmp(p, "early", 5) == 0) {
>>> /* just "xmon" is equivalent to "xmon=early" */
>>> -   xmon_init(1);
>>> xmon_early = 1;
>>> +   xmon_off = 0;
>>> } else if (strncmp(p, "on", 2) == 0)
>>> -   xmon_init(1);
>>> +   xmon_off = 0;
>>
>> You've just changed the timing of when xmon gets enabled for the above
>> two cases, from here which is called very early, to xmon_setup() which
>> is called much later in boot.
>>
>> That effectively disables xmon for most of the boot, which we do not
>> want to do.
>>
> Although it is not often that kernel got stucked during boot. Yes, the 
> behavior changed anyway. Will fix that in v3.

Pan/Michael, I'm working my patches on top of Pan's. So, I sent his V2
on my series, as patch #1.

Guess the workflow is better/easier if we can work the patches on the
series exclusively, since each time Pan's patch is changed, I need to
refactor my patches.

Pan, if possible send your V3 to me, I'll refactor my series on top of
it and send again on the list. Or if you or Michael have better
suggestions of workflow, let me know.

Thanks,


Guilherme

> 
>> cheers
>>
> 

[GIT PULL] Please pull powerpc/linux.git powerpc-4.10-5 tag

[Michael Ellerman]

Hi Linus,

Please pull one last powerpc fix for 4.10. This is actually tagged for
stable, so it's not the end of the world if you'd rather not pull it
this late.

cheers


The following changes since commit f83e6862047e1e371bdc5d512dd6cabe8a3965b8:

  powerpc/powernv: Properly set "host-ipi" on IPIs (2017-02-09 15:51:21 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.10-5

for you to fetch changes up to 3f91a89d424a79f8082525db5a375e438887bb3e:

  powerpc/64: Disable use of radix under a hypervisor (2017-02-16 14:01:42 
+1100)


powerpc fixes for 4.10 #5

One fix from Paul, we can not use the radix MMU under a hypervisor for now.
Although the current code checks if the processor supports radix, that is not
sufficient.


Paul Mackerras (1):
  powerpc/64: Disable use of radix under a hypervisor

 arch/powerpc/mm/init_64.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


signature.asc
Description: PGP signature

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

[Aneesh Kumar K.V]

laurentiu.tu...@nxp.com writes:

> From: Laurentiu Tudor 
>
> On 32-bit book-e machines, hugepd_ok() does not take
> into account null hugepd values, causing this crash at boot:
>
> Unable to handle kernel paging request for data at address 0x8000
> Faulting instruction address: 0xc00182a8
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=24
> CoreNet Generic
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   
> 4.10.0-rc8-00016-g69b1f87 #11
> task: e505 task.stack: e5058000
> NIP: c00182a8 LR: c001829c CTR: 7ffe
> REGS: e5059c50 TRAP: 0300   Tainted: GW
> (4.10.0-rc8-00016-g69b1f87)
> MSR: 00021002 
>   CR: 88428e82  XER: 
> DEAR: 8000 ESR: 
> GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08 2017
> GPR08:     28428e82  c00027d0 
> GPR16:   88a28e82 2000 48422e82  88a28e84 dd004000
> GPR24: e5059e38   bff1 dd004000 0001 00029002 bff1
> NIP [c00182a8] follow_huge_addr+0x38/0xf0
> LR [c001829c] follow_huge_addr+0x2c/0xf0
> Call Trace:
> [e5059d00] [e5059d00] 0xe5059d00 (unreliable)
> [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0
> [e5059d80] [c0107958] __get_user_pages+0xc8/0x420
> [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230
> [e5059e30] [c013f170] copy_strings+0x110/0x3a0
> [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50
> [e5059ec0] [c0141324] do_execveat_common+0x474/0x620
> [e5059f10] [c01414fc] do_execve+0x2c/0x40
> [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
> [e5059f30] [c000289c] kernel_init+0xcc/0x120
> [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008
> 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea 2f89
> ---[ end trace 4bf94e15fd9fa824 ]---


Which code path is that. That null should be filtered by the if
(pmd_none(pmd)) check in find_linux_pte_or_hugepte right ?

>
> This impacts all nxp (ex-freescale) 32-bit booke platforms.
>
> Fixes: 20717e1ff526 ("powerpc/mm: Fix little-endian 4K hugetlb")
>
> Reported-by: Madalin-Cristian Bucur 
> Signed-off-by: Laurentiu Tudor 
> ---
>  arch/powerpc/include/asm/nohash/pgtable.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/nohash/pgtable.h 
> b/arch/powerpc/include/asm/nohash/pgtable.h
> index 0cd8a38..e5805ad 100644
> --- a/arch/powerpc/include/asm/nohash/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/pgtable.h
> @@ -230,7 +230,7 @@ static inline int hugepd_ok(hugepd_t hpd)
>   return ((hpd_val(hpd) & 0x4) != 0);
>  #else
>   /* We clear the top bit to indicate hugepd */
> - return ((hpd_val(hpd) & PD_HUGE) ==  0);
> + return (hpd_val(hpd) && (hpd_val(hpd) & PD_HUGE) == 0);
>  #endif
>  }
>
> -- 
> 1.8.3.1

[RFC PATCH] powerpc: Fix dubious r0 usage

[Michael Ellerman]

Bleeding edge binutils no longer accepts r0 in places where the CPU
interprets the value as a literal 0.

This fixes the cases caught by a vanilla 64-bit and 32-bit build. There
may be others that are hidden behind other CONFIG options.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/ppc_asm.h  |  2 +-
 arch/powerpc/kernel/l2cr_6xx.S  |  4 +--
 arch/powerpc/lib/copypage_power7.S  | 14 
 arch/powerpc/lib/copyuser_power7.S  | 66 ++---
 arch/powerpc/lib/memcpy_power7.S| 66 ++---
 arch/powerpc/lib/string_64.S|  2 +-
 arch/powerpc/purgatory/trampoline.S |  2 +-
 7 files changed, 78 insertions(+), 78 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index 025833b8df9f..c98324addc08 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -439,7 +439,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
 .machine push ;\
 .machine "power4" ;\
lis scratch,0x6000@h;   \
-   dcbtr0,scratch,0b01010; \
+   dcbt0,scratch,0b01010;  \
 .machine pop
 
 /*
diff --git a/arch/powerpc/kernel/l2cr_6xx.S b/arch/powerpc/kernel/l2cr_6xx.S
index 97ec8557f974..6408f09dbbd9 100644
--- a/arch/powerpc/kernel/l2cr_6xx.S
+++ b/arch/powerpc/kernel/l2cr_6xx.S
@@ -181,7 +181,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_SPEC7450)
mtctr   r4
li  r4,0
 1:
-   lwzxr0,r0,r4
+   lwzxr0,0,r4
addir4,r4,32/* Go to start of next cache line */
bdnz1b
isync
@@ -328,7 +328,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_L3CR)
mtctr   r4
li  r4,0
 1:
-   lwzxr0,r0,r4
+   lwzxr0,0,r4
dcbf0,r4
addir4,r4,32/* Go to start of next cache line */
bdnz1b
diff --git a/arch/powerpc/lib/copypage_power7.S 
b/arch/powerpc/lib/copypage_power7.S
index a84d333ecb09..ca5fc8fa7efc 100644
--- a/arch/powerpc/lib/copypage_power7.S
+++ b/arch/powerpc/lib/copypage_power7.S
@@ -45,13 +45,13 @@ _GLOBAL(copypage_power7)
 .machine push
 .machine "power4"
/* setup read stream 0  */
-   dcbtr0,r4,0b01000   /* addr from */
-   dcbtr0,r7,0b01010   /* length and depth from */
+   dcbt0,r4,0b01000/* addr from */
+   dcbt0,r7,0b01010   /* length and depth from */
/* setup write stream 1 */
-   dcbtst  r0,r9,0b01000   /* addr to */
-   dcbtst  r0,r10,0b01010  /* length and depth to */
+   dcbtst  0,r9,0b01000   /* addr to */
+   dcbtst  0,r10,0b01010  /* length and depth to */
eieio
-   dcbtr0,r8,0b01010   /* all streams GO */
+   dcbt0,r8,0b01010/* all streams GO */
 .machine pop
 
 #ifdef CONFIG_ALTIVEC
@@ -83,7 +83,7 @@ _GLOBAL(copypage_power7)
li  r12,112
 
.align  5
-1: lvx v7,r0,r4
+1: lvx v7,0,r4
lvx v6,r4,r6
lvx v5,r4,r7
lvx v4,r4,r8
@@ -92,7 +92,7 @@ _GLOBAL(copypage_power7)
lvx v1,r4,r11
lvx v0,r4,r12
addir4,r4,128
-   stvxv7,r0,r3
+   stvxv7,0,r3
stvxv6,r3,r6
stvxv5,r3,r7
stvxv4,r3,r8
diff --git a/arch/powerpc/lib/copyuser_power7.S 
b/arch/powerpc/lib/copyuser_power7.S
index a24b4039352c..a95fef3bed10 100644
--- a/arch/powerpc/lib/copyuser_power7.S
+++ b/arch/powerpc/lib/copyuser_power7.S
@@ -315,13 +315,13 @@ err1; stb r0,0(r3)
 .machine push
 .machine "power4"
/* setup read stream 0 */
-   dcbtr0,r6,0b01000   /* addr from */
-   dcbtr0,r7,0b01010   /* length and depth from */
+   dcbt0,r6,0b01000   /* addr from */
+   dcbt0,r7,0b01010   /* length and depth from */
/* setup write stream 1 */
-   dcbtst  r0,r9,0b01000   /* addr to */
-   dcbtst  r0,r10,0b01010  /* length and depth to */
+   dcbtst  0,r9,0b01000   /* addr to */
+   dcbtst  0,r10,0b01010  /* length and depth to */
eieio
-   dcbtr0,r8,0b01010   /* all streams GO */
+   dcbt0,r8,0b01010/* all streams GO */
 .machine pop
 
beq cr1,.Lunwind_stack_nonvmx_copy
@@ -376,26 +376,26 @@ err3; std r0,0(r3)
li  r11,48
 
bf  cr7*4+3,5f
-err3;  lvx v1,r0,r4
+err3;  lvx v1,0,r4
addir4,r4,16
-err3;  stvxv1,r0,r3
+err3;  stvxv1,0,r3
addir3,r3,16
 
 5: bf  cr7*4+2,6f
-err3;  lvx v1,r0,r4
+err3;  lvx v1,0,r4
 err3;  lvx v0,r4,r9
addir4,r4,32
-err3;  stvxv1,r0,r3
+err3;  stvxv1,0,r3
 err3;  stvxv0,r3,r9
addir3,r3,32
 
 6: bf  cr7*4+1,7f
-err3;  lvx v3,r0,r4
+err3;  lvx v3,0,r4
 err3;  lvx v2,r4,r9
 err3;  lvx v1,r4,r10
 err3;  lvx v0,r4,r11

Re: [PATCH v2] powerpc: Add POWER9 architected mode to cputable

[Russell Currey]

On Fri, 2017-02-17 at 21:26 +1100, Michael Ellerman wrote:
> Russell Currey  writes:
> 
> > diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> > index 6a82ef039c50..d23a54b09436 100644
> > --- a/arch/powerpc/kernel/cputable.c
> > +++ b/arch/powerpc/kernel/cputable.c
> > @@ -386,6 +386,25 @@ static struct cpu_spec __initdata cpu_specs[] = {
> >     .machine_check_early=
> > __machine_check_early_realmode_p8,
> >     .platform   = "power8",
> >     },
> > +   {   /* 3.00-compliant processor, i.e. Power9 "architected"
> > mode */
> > +   .pvr_mask   = 0x,
> > +   .pvr_value  = 0x0f05,
> > +   .cpu_name   = "POWER9 (architected)",
> > +   .cpu_features   = CPU_FTRS_POWER9,
> > +   .cpu_user_features  = COMMON_USER_POWER9,
> > +   .cpu_user_features2 = COMMON_USER2_POWER9,
> > +   .mmu_features   = MMU_FTRS_POWER9,
> > +   .icache_bsize   = 128,
> > +   .dcache_bsize   = 128,
> > +   .num_pmcs   = 6,
> 
> It's important *not* to set num_pmcs for the architected PVRs.
> 
> See the comment in setup_cpu_spec():
> 
>   /*
>* If we are overriding a previous value derived from the real
>* PVR with a new value obtained using a logical PVR value,
>* don't modify the performance monitor fields.
>*/
>   if (old.num_pmcs && !s->num_pmcs) {
>   t->num_pmcs = old.num_pmcs;
>   t->pmc_type = old.pmc_type;
> 
> I realise that having that requirement in the code is serious foot gun
> material on our part, but c'est la vie.
> 
> The reason we do that is there's no "compat mode" for the PMU. So if you
> boot on a Power9, and then the logical PVR says "actually pretend you're
> on a Power8", we flip most of the cpu_spec to have the Power8 values,
> but *not* the PMU fields. That way the Power9 PMU code will still detect
> that it's on a Power9 and work correctly.
> 
> Possibly now that oprofile is more or less dead we can rip all that crap
> out, and have perf just look at the PVR directly.

Oh and also, do you want me to respin or are you happy to drop it on your end?

- Russell

> 
> cheers

Re: [PATCH v2] powerpc: Add POWER9 architected mode to cputable

[Russell Currey]

On Fri, 2017-02-17 at 21:26 +1100, Michael Ellerman wrote:
> Russell Currey  writes:
> 
> > diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> > index 6a82ef039c50..d23a54b09436 100644
> > --- a/arch/powerpc/kernel/cputable.c
> > +++ b/arch/powerpc/kernel/cputable.c
> > @@ -386,6 +386,25 @@ static struct cpu_spec __initdata cpu_specs[] = {
> >     .machine_check_early=
> > __machine_check_early_realmode_p8,
> >     .platform   = "power8",
> >     },
> > +   {   /* 3.00-compliant processor, i.e. Power9 "architected"
> > mode */
> > +   .pvr_mask   = 0x,
> > +   .pvr_value  = 0x0f05,
> > +   .cpu_name   = "POWER9 (architected)",
> > +   .cpu_features   = CPU_FTRS_POWER9,
> > +   .cpu_user_features  = COMMON_USER_POWER9,
> > +   .cpu_user_features2 = COMMON_USER2_POWER9,
> > +   .mmu_features   = MMU_FTRS_POWER9,
> > +   .icache_bsize   = 128,
> > +   .dcache_bsize   = 128,
> > +   .num_pmcs   = 6,
> 
> It's important *not* to set num_pmcs for the architected PVRs.
> 
> See the comment in setup_cpu_spec():
> 
>   /*
>* If we are overriding a previous value derived from the real
>* PVR with a new value obtained using a logical PVR value,
>* don't modify the performance monitor fields.
>*/
>   if (old.num_pmcs && !s->num_pmcs) {
>   t->num_pmcs = old.num_pmcs;
>   t->pmc_type = old.pmc_type;
> 
> I realise that having that requirement in the code is serious foot gun
> material on our part, but c'est la vie.
> 
> The reason we do that is there's no "compat mode" for the PMU. So if you
> boot on a Power9, and then the logical PVR says "actually pretend you're
> on a Power8", we flip most of the cpu_spec to have the Power8 values,
> but *not* the PMU fields. That way the Power9 PMU code will still detect
> that it's on a Power9 and work correctly.
> 
> Possibly now that oprofile is more or less dead we can rip all that crap
> out, and have perf just look at the PVR directly.

Thanks a lot for explaining, that's interesting.  I thought it might just have
been an accidental omission in the architected entries but I should've dug
deeper.

> 
> cheers

Re: [PATCH 0/3] pci/hotplug/pnv-php: More bug fixes

[Michael Ellerman]

Bjorn Helgaas  writes:

> On Fri, Feb 17, 2017 at 09:38:08AM +1100, Gavin Shan wrote:
>> On Thu, Feb 16, 2017 at 08:09:26AM -0600, Bjorn Helgaas wrote:
>> >On Thu, Feb 16, 2017 at 10:22:31AM +1100, Gavin Shan wrote:
>> >> This series bases on the series: 
>> >> https://patchwork.ozlabs.org/patch/713513.
>> >> This series fixes couple of issues:
>> >> 
>> >>* Remove WARN_ON() in pnv_php_put_slot(). The parent slot's refcount
>> >>  is decreased when releasing PCI slot. The parent slot can be NULL
>> >>  and no need to give a warning.
>> >>* The MSI (or MSIx) could be enabled prior to load pnv-php.ko. A
>> >>  backtrace is thrown when phv-php.ko attempts to enable MSI again.
>> >>  PATCH[2/3] skips enabling surprise hotplug if MSI has been enabled
>> >>  by other driver.
>> >>* PATCH[3/3] doesn't disable MSI that was enabled by other dirver.
>> >>  Also, the upstream port of the PCI slot is disabled when it's
>> >>  destroyed.
>> >> 
>> >> Gavin Shan (3):
>> >>   pci/hotplug/pnv-php: Remove WARN_ON() in pnv_php_put_slot()
>> >>   pci/hotplug/pnv-php: Disable surprise hotplug capability on conflicts
>> >>   pci/hotplug/pnv-php: Disable MSI and PCI device properly
>> >
>> >Since this is specific to pnv_php.c and depends on a previous series
>> >applied by Michael, I assume he'll handle this series as well.
>> 
>> Bjorn, yes, I think Michael will take care of this series and all
>> changes to pnv_php.c in future, as we all agreed previously. I was
>> asked by Michael to copy linux-pci@ and you when posting patches for
>> this component.
>
> Thanks, I appreciate at least seeing the changes!  If you mention in
> the cover letter that you expect Michael to merge it, then I will
> immediately know to ignore it unless I object for some reason.

Thanks Bjorn.

I guess I'll plan to merge all small to medium changes to this driver,
unless you object to them.

If there's something big or that looks like it interacts more than usual
with the PCI code I'll ping you for an ack.

cheers

Re: Pull request: scottwood/linux.git next

[Scott Wood]

On Fri, 2017-01-27 at 17:53 -0600, Scott Wood wrote:
> Highlights include 8xx breakpoints and perf, t1042rdb display support,
> and board updates.
> 
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
> 
>   Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
> 
> for you to fetch changes up to 75b824727680a9d12c34d78096a5ac642e53f5d0:
> 
>   powerpc/8xx: Perf events on PPC 8xx (2017-01-26 17:49:34 -0600)
> 
> 
> Christophe Leroy (4):
>   powerpc/32: Enable HW_BREAKPOINT on BOOK3S
>   powerpc/8xx: Implement hw_breakpoint
>   powerpc/32: Remove FIX_SRR1
>   powerpc/8xx: Perf events on PPC 8xx
> 
> Jason Jin (1):
>   powerpc/85xx: Enable display support for t1042rdb
> 
> Valentin Longchamp (3):
>   powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
>   powerpc/85xx: remove the kmp204x_defconfig
>   powerpc/corenet: add support for the kmcent2 board

ping?

-Scott

Re: [PATCH 0/2] powerpc: kretprobe updates

[Masami Hiramatsu]

On Thu, 16 Feb 2017 13:47:37 +0530
"Naveen N. Rao"  wrote:

> I am posting the powerpc bits in the same thread so as to keep these
> changes together. I am not sure how this should be taken upstream as
> there are atleast three different trees involved: one for the core
> kprobes infrastructure, one for powerpc and one for perf.

Hmm, could you make these (and other related) patches and
other series in one series? Or wait for the other series
are merged correctly.

Thank you,

> 
> Thanks,
> Naveen
> 
> Naveen N. Rao (2):
>   powerpc: kretprobes: override default function entry offset
>   perf: powerpc: choose LEP with kretprobes
> 
>  arch/powerpc/kernel/kprobes.c   | 9 +
>  tools/perf/arch/powerpc/util/sym-handling.c | 5 +
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> -- 
> 2.11.0
> 


-- 
Masami Hiramatsu 

[PATCH] net/wan: add MODULE_LICENSE for fsl_ucc_hdlc

[Valentin Longchamp]

It is required to build it as a module.

Signed-off-by: Valentin Longchamp 
---
 drivers/net/wan/fsl_ucc_hdlc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index e38ce4d..1f38c06 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -1175,3 +1175,4 @@ static int ucc_hdlc_remove(struct platform_device *pdev)
 };
 
 module_platform_driver(ucc_hdlc_driver);
+MODULE_LICENSE("GPL");
-- 
1.8.3.1

[PATCH 1/3] soc/fsl/qe: round brg_freq to 1kHz granularity

[Valentin Longchamp]

Because of integer computation rounding in u-boot (that sets the QE
brg-frequency DTS prop), the clk value is  Hz even though it is
100 MHz.

When setting brg clks that are exact divisors of 100 MHz, this small
differnce plays a role and can result in lower clks to be output (for
instance 20 MHz - divide by 5 - results in 16.666 MHz - divide by 6).

This patch fixes that by "forcing" the brg_clk to the nearest kHz when
the difference is below 2 integer rouding errors (i.e. 4).

Signed-off-by: Valentin Longchamp 
---
 drivers/soc/fsl/qe/qe.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index ade168f..03874df 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -163,11 +163,15 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, 
u32 cmd_input)
  */
 static unsigned int brg_clk = 0;
 
+#define CLK_GRAN   (1000)
+#define CLK_GRAN_LIMIT (5)
+
 unsigned int qe_get_brg_clk(void)
 {
struct device_node *qe;
int size;
const u32 *prop;
+   unsigned int mod;
 
if (brg_clk)
return brg_clk;
@@ -185,6 +189,15 @@ unsigned int qe_get_brg_clk(void)
 
of_node_put(qe);
 
+   /* round this if near to a multiple of CLK_GRAN */
+   mod = brg_clk % CLK_GRAN;
+   if (mod) {
+   if (mod < CLK_GRAN_LIMIT)
+   brg_clk -= mod;
+   else if (mod > (CLK_GRAN - CLK_GRAN_LIMIT))
+   brg_clk += CLK_GRAN - mod;
+   }
+
return brg_clk;
 }
 EXPORT_SYMBOL(qe_get_brg_clk);
-- 
1.8.3.1

[PATCH 0/3] soc/fsl: various fixes for QE support

[Valentin Longchamp]

Testing the QE's UCC for our HDLC bus I noticed a few odd things and I have
fixed these in these 3 patches.

Valentin Longchamp (3):
  soc/fsl/qe: round brg_freq to 1kHz granularity
  soc/fsl/qe: only apply QE_General4 workaround on affected SoCs
  soc/fsl/qe: add EXPORT_SYMBOL for the 2 qe_tdm functions

 drivers/soc/fsl/qe/qe.c | 21 +++--
 drivers/soc/fsl/qe/qe_tdm.c |  2 ++
 2 files changed, 21 insertions(+), 2 deletions(-)

-- 
1.8.3.1

[PATCH 2/3] soc/fsl/qe: only apply QE_General4 workaround on affected SoCs

[Valentin Longchamp]

The QE_General4 workaround is only valid for the MPC832x and MPC836x
SoCs. The other SoCs that embed a QUICC engine are not affected by this
hardware bug and thus can use the computed divisors (this was
successfully tested on the T1040).

Similalry to what was done in commit 8ce795cb0c6b ("i2c: mpc: assign the
correct prescaler from SVR") in order to avoid changes in
the device tree nodes of the QE (with maybe a variant of the compatible
property), the PVR reg is read out to find out if the workaround must be
applied or not.

Signed-off-by: Valentin Longchamp 
---
 drivers/soc/fsl/qe/qe.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 03874df..b66157fc 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -202,6 +202,9 @@ unsigned int qe_get_brg_clk(void)
 }
 EXPORT_SYMBOL(qe_get_brg_clk);
 
+#define PVR_VER_836x   0x8083
+#define PVR_VER_832x   0x8084
+
 /* Program the BRG to the given sampling rate and multiplier
  *
  * @brg: the BRG, QE_BRG1 - QE_BRG16
@@ -228,8 +231,9 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate, 
unsigned int multiplier)
/* Errata QE_General4, which affects some MPC832x and MPC836x SOCs, says
   that the BRG divisor must be even if you're not using divide-by-16
   mode. */
-   if (!div16 && (divisor & 1) && (divisor > 3))
-   divisor++;
+   if (pvr_version_is(PVR_VER_836x) || pvr_version_is(PVR_VER_832x))
+   if (!div16 && (divisor & 1) && (divisor > 3))
+   divisor++;
 
tempval = ((divisor - 1) << QE_BRGC_DIVISOR_SHIFT) |
QE_BRGC_ENABLE | div16;
-- 
1.8.3.1

[PATCH 3/3] soc/fsl/qe: add EXPORT_SYMBOL for the 2 qe_tdm functions

[Valentin Longchamp]

This allows to build the fsl_ucc_hdlc driver as a module.

Signed-off-by: Valentin Longchamp 
---
 drivers/soc/fsl/qe/qe_tdm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/soc/fsl/qe/qe_tdm.c b/drivers/soc/fsl/qe/qe_tdm.c
index a1048b4..f744c21 100644
--- a/drivers/soc/fsl/qe/qe_tdm.c
+++ b/drivers/soc/fsl/qe/qe_tdm.c
@@ -177,6 +177,7 @@ int ucc_of_parse_tdm(struct device_node *np, struct ucc_tdm 
*utdm,
devm_iounmap(>dev, utdm->si_regs);
return ret;
 }
+EXPORT_SYMBOL(ucc_of_parse_tdm);
 
 void ucc_tdm_init(struct ucc_tdm *utdm, struct ucc_tdm_info *ut_info)
 {
@@ -274,3 +275,4 @@ void ucc_tdm_init(struct ucc_tdm *utdm, struct ucc_tdm_info 
*ut_info)
break;
}
 }
+EXPORT_SYMBOL(ucc_tdm_init);
-- 
1.8.3.1

Re: [PATCH v2] powerpc: Add POWER9 architected mode to cputable

[Michael Ellerman]

Russell Currey  writes:

> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> index 6a82ef039c50..d23a54b09436 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -386,6 +386,25 @@ static struct cpu_spec __initdata cpu_specs[] = {
>   .machine_check_early= __machine_check_early_realmode_p8,
>   .platform   = "power8",
>   },
> + {   /* 3.00-compliant processor, i.e. Power9 "architected" mode */
> + .pvr_mask   = 0x,
> + .pvr_value  = 0x0f05,
> + .cpu_name   = "POWER9 (architected)",
> + .cpu_features   = CPU_FTRS_POWER9,
> + .cpu_user_features  = COMMON_USER_POWER9,
> + .cpu_user_features2 = COMMON_USER2_POWER9,
> + .mmu_features   = MMU_FTRS_POWER9,
> + .icache_bsize   = 128,
> + .dcache_bsize   = 128,
> + .num_pmcs   = 6,

It's important *not* to set num_pmcs for the architected PVRs.

See the comment in setup_cpu_spec():

/*
 * If we are overriding a previous value derived from the real
 * PVR with a new value obtained using a logical PVR value,
 * don't modify the performance monitor fields.
 */
if (old.num_pmcs && !s->num_pmcs) {
t->num_pmcs = old.num_pmcs;
t->pmc_type = old.pmc_type;

I realise that having that requirement in the code is serious foot gun
material on our part, but c'est la vie.

The reason we do that is there's no "compat mode" for the PMU. So if you
boot on a Power9, and then the logical PVR says "actually pretend you're
on a Power8", we flip most of the cpu_spec to have the Power8 values,
but *not* the PMU fields. That way the Power9 PMU code will still detect
that it's on a Power9 and work correctly.

Possibly now that oprofile is more or less dead we can rip all that crap
out, and have perf just look at the PVR directly.

cheers

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

[Laurentiu Tudor]

On 02/17/2017 12:08 PM, Scott Wood wrote:
> On Thu, 2017-02-16 at 09:11 -0600, laurentiu.tu...@nxp.com wrote:
>> From: Laurentiu Tudor 
>>
>> On 32-bit book-e machines, hugepd_ok() does not take
>> into account null hugepd values, causing this crash at boot:
>
> Why only 32-bit?

I wanted to get this patch out as quick as possible so i didn't had
time to investigate in depth. I just tested on 64-bit that the
kernel boots ok.

>> diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
>> b/arch/powerpc/include/asm/nohash/pgtable.h
>> index 0cd8a38..e5805ad 100644
>> --- a/arch/powerpc/include/asm/nohash/pgtable.h
>> +++ b/arch/powerpc/include/asm/nohash/pgtable.h
>> @@ -230,7 +230,7 @@ static inline int hugepd_ok(hugepd_t hpd)
>>  return ((hpd_val(hpd) & 0x4) != 0);
>>   #else
>>  /* We clear the top bit to indicate hugepd */
>> -return ((hpd_val(hpd) & PD_HUGE) ==  0);
>> +return (hpd_val(hpd) && (hpd_val(hpd) & PD_HUGE) == 0);
>>   #endif
>>   }
>>
>
> Any reason why this can't go back to being "hpd_val(hpd) > 0"?  Why was nohash
> changed to begin with?  I don't expect nohash (or at least fsl-book3e) will
> ever have a pagetable that is not native-endian, and "> 0" is consistent with
> what the TLB miss code is doing.

The patch that introduced the brokenness changes "hugepd_t.pd" from 
"signed long" to "unsigned long" so as a consequence "> 0" was replaced
with the bitwise op.

---
Best Regards, Laurentiu

Re: [PATCH v2] powerpc: Add POWER9 architected mode to cputable

[Michael Ellerman]

Daniel Axtens  writes:

> Hi Russell,
>
> This seems to go Power8, Power9, Power7 - is that intentional?
>
> Regards,
> Daniel
>
>>  .platform   = "power8",
> ...
>> +.platform   = "power9",
> ...
>>  {   /* Power7 */

It's because we have the architected PVRs and the raw ones, and the
ordering is a bit odd:

$ grep -n -e '(architected)' -e '(raw)' arch/powerpc/kernel/cputable.c
323:.cpu_name   = "POWER6 (raw)",
343:.cpu_name   = "POWER6 (architected)",
356:.cpu_name   = "POWER7 (architected)",
374:.cpu_name   = "POWER8 (architected)",
392:.cpu_name   = "POWER9 (architected)",
411:.cpu_name   = "POWER7 (raw)",
431:.cpu_name   = "POWER7+ (raw)",
451:.cpu_name   = "POWER8E (raw)",
471:.cpu_name   = "POWER8NVL (raw)",
491:.cpu_name   = "POWER8 (raw)",
511:.cpu_name   = "POWER8 (raw)",
531:.cpu_name   = "POWER9 (raw)",
550:.cpu_name   = "POWER9 (raw)",

But I don't think it matters in practice. The architected entries use a
pvr_mask of 0x so it has to be an exact match.

cheers

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

[Scott Wood]

On Thu, 2017-02-16 at 09:11 -0600, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor 
> 
> On 32-bit book-e machines, hugepd_ok() does not take
> into account null hugepd values, causing this crash at boot:

Why only 32-bit?

> diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
> b/arch/powerpc/include/asm/nohash/pgtable.h
> index 0cd8a38..e5805ad 100644
> --- a/arch/powerpc/include/asm/nohash/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/pgtable.h
> @@ -230,7 +230,7 @@ static inline int hugepd_ok(hugepd_t hpd)
>   return ((hpd_val(hpd) & 0x4) != 0);
>  #else
>   /* We clear the top bit to indicate hugepd */
> - return ((hpd_val(hpd) & PD_HUGE) ==  0);
> + return (hpd_val(hpd) && (hpd_val(hpd) & PD_HUGE) == 0);
>  #endif
>  }
>  

Any reason why this can't go back to being "hpd_val(hpd) > 0"?  Why was nohash
changed to begin with?  I don't expect nohash (or at least fsl-book3e) will
ever have a pagetable that is not native-endian, and "> 0" is consistent with
what the TLB miss code is doing.

Also, the patch that broke this was tagged for stable (which again raises the
question of why an extraneous change was made) so this patch needs to be as
well.

-Scott

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

[Pan Xinhui]

在 2017/2/17 14:05, Michael Ellerman 写道:

Pan Xinhui  writes:

diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 9c0e17c..f6e5c3d 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -76,6 +76,7 @@ static int xmon_gate;
  #endif /* CONFIG_SMP */

  static unsigned long in_xmon __read_mostly = 0;
+static int xmon_off = !IS_ENABLED(CONFIG_XMON_DEFAULT);


I think the logic would probably clearer if we invert this to become
xmon_on.


yep, make sense.


@@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void)
  __initcall(setup_xmon_sysrq);
  #endif /* CONFIG_MAGIC_SYSRQ */

-static int __initdata xmon_early, xmon_off;
+static int __initdata xmon_early;

  static int __init early_parse_xmon(char *p)
  {
if (!p || strncmp(p, "early", 5) == 0) {
/* just "xmon" is equivalent to "xmon=early" */
-   xmon_init(1);
xmon_early = 1;
+   xmon_off = 0;
} else if (strncmp(p, "on", 2) == 0)
-   xmon_init(1);
+   xmon_off = 0;


You've just changed the timing of when xmon gets enabled for the above
two cases, from here which is called very early, to xmon_setup() which
is called much later in boot.

That effectively disables xmon for most of the boot, which we do not
want to do.


Although it is not often that kernel got stucked during boot. Yes, the behavior 
changed anyway. Will fix that in v3.


cheers

Re: [PATCH v5 00/15] livepatch: hybrid consistency model

[Miroslav Benes]

On Mon, 13 Feb 2017, Josh Poimboeuf wrote:

> Here's v5 of the consistency model, targeted for 4.12.  Only a few minor
> changes this time.
> 
> v5:
> - return -EINVAL in __save_stack_trace_reliable()
> - only call show_stack() once
> - add save_stack_trace_tsk_reliable() define for !CONFIG_STACKTRACE
> - update kernel version and date in ABI doc
> - make suggested improvements to livepatch.txt
> - update barrier comments
> - remove klp_try_complete_transition() call from klp_start_transition()
> - move end of klp_try_complete_transition() into klp_complete_transition()
> - fix __klp_enable_patch() error path
> - check for transition in klp_module_going()

All the changes since v4 look good to me (except for module_put() in 
__klp_enable_patch() mentioned elsewhere).

Thanks,
Miroslav

Re: [PATCH v5 13/15] livepatch: change to a per-task consistency model

[Miroslav Benes]

On Thu, 16 Feb 2017, Josh Poimboeuf wrote:

> On Thu, Feb 16, 2017 at 03:33:26PM +0100, Miroslav Benes wrote:
> > 
> > > @@ -347,22 +356,36 @@ static int __klp_enable_patch(struct klp_patch 
> > > *patch)
> > >  
> > >   pr_notice("enabling patch '%s'\n", patch->mod->name);
> > >  
> > > + klp_init_transition(patch, KLP_PATCHED);
> > > +
> > > + /*
> > > +  * Enforce the order of the func->transition writes in
> > > +  * klp_init_transition() and the ops->func_stack writes in
> > > +  * klp_patch_object(), so that klp_ftrace_handler() will see the
> > > +  * func->transition updates before the handler is registered and the
> > > +  * new funcs become visible to the handler.
> > > +  */
> > > + smp_wmb();
> > > +
> > >   klp_for_each_object(patch, obj) {
> > >   if (!klp_is_object_loaded(obj))
> > >   continue;
> > >  
> > >   ret = klp_patch_object(obj);
> > > - if (ret)
> > > - goto unregister;
> > > + if (ret) {
> > > + pr_warn("failed to enable patch '%s'\n",
> > > + patch->mod->name);
> > > +
> > > + klp_cancel_transition();
> > > + return ret;
> > > + }
> > 
> > [...]
> > 
> > > +static void klp_complete_transition(void)
> > > +{
> > > + struct klp_object *obj;
> > > + struct klp_func *func;
> > > + struct task_struct *g, *task;
> > > + unsigned int cpu;
> > > +
> > > + if (klp_target_state == KLP_UNPATCHED) {
> > > + /*
> > > +  * All tasks have transitioned to KLP_UNPATCHED so we can now
> > > +  * remove the new functions from the func_stack.
> > > +  */
> > > + klp_unpatch_objects(klp_transition_patch);
> > > +
> > > + /*
> > > +  * Make sure klp_ftrace_handler() can no longer see functions
> > > +  * from this patch on the ops->func_stack.  Otherwise, after
> > > +  * func->transition gets cleared, the handler may choose a
> > > +  * removed function.
> > > +  */
> > > + synchronize_rcu();
> > > + }
> > > +
> > > + if (klp_transition_patch->immediate)
> > > + goto done;
> > > +
> > > + klp_for_each_object(klp_transition_patch, obj)
> > > + klp_for_each_func(obj, func)
> > > + func->transition = false;
> > > +
> > > + /* Prevent klp_ftrace_handler() from seeing KLP_UNDEFINED state */
> > > + if (klp_target_state == KLP_PATCHED)
> > > + synchronize_rcu();
> > > +
> > > + read_lock(_lock);
> > > + for_each_process_thread(g, task) {
> > > + WARN_ON_ONCE(test_tsk_thread_flag(task, TIF_PATCH_PENDING));
> > > + task->patch_state = KLP_UNDEFINED;
> > > + }
> > > + read_unlock(_lock);
> > > +
> > > + for_each_possible_cpu(cpu) {
> > > + task = idle_task(cpu);
> > > + WARN_ON_ONCE(test_tsk_thread_flag(task, TIF_PATCH_PENDING));
> > > + task->patch_state = KLP_UNDEFINED;
> > > + }
> > > +
> > > +done:
> > > + klp_target_state = KLP_UNDEFINED;
> > > + klp_transition_patch = NULL;
> > > +}
> > > +
> > > +/*
> > > + * This is called in the error path, to cancel a transition before it has
> > > + * started, i.e. klp_init_transition() has been called but
> > > + * klp_start_transition() hasn't.  If the transition *has* been started,
> > > + * klp_reverse_transition() should be used instead.
> > > + */
> > > +void klp_cancel_transition(void)
> > > +{
> > > + klp_target_state = !klp_target_state;
> > > + klp_complete_transition();
> > > +}
> > 
> > If we fail to enable patch in __klp_enable_patch(), we call 
> > klp_cancel_transition() and get to klp_complete_transition(). If the patch 
> > has immediate set to true, the module would not be allowed to go (the 
> > changes are in the last patch unfortunately, but my remark is closely 
> > related to klp_cancel_transition() and __klp_enable_patch()). This could 
> > annoy a user if it was due to a trivial reason. So we could call  
> > module_put() in this case. It should be safe as no task could be in a new 
> > function thanks to klp_ftrace_handler() logic.
> > 
> > Pity I have not spotted this earlier.
> > 
> > Putting module_put(patch->mod) right after klp_cancel_transition() call in 
> > __klp_enable_patch() would be the simplest fix (as a part of 15/15 patch). 
> > Maybe with a comment that it is safe to do it there.
> > 
> > What do you think?
> 
> Good catch.  I agree that 15/15 should have something like that.
> 
> Also, the module_put() will be needed for non-immediate patches which
> have a func->immediate set.

Right. This further complicates it.
 
> What do you think about the following?  I tried to put the logic in
> klp_complete_transition(), so the module_put()'s would be in one place.
> But it was too messy, so I put it in klp_cancel_transition() instead.
>
> diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
> index e96346e..bd1c1fd 100644
> --- a/kernel/livepatch/transition.c
> +++ 

Re: [PATCH v2] powerpc: Add POWER9 architected mode to cputable

[Daniel Axtens]

Hi Russell,

This seems to go Power8, Power9, Power7 - is that intentional?

Regards,
Daniel

>   .platform   = "power8",
...
> + .platform   = "power9",
...
>   {   /* Power7 */