Hello Dear.

2018-08-31 Thread michel



With Due Respect,

I know that this mail will come to you as a surprise as we have never met 
before, but need not to worry as I am contacting you independently of my 
investigation and no one is informed of this communication. I need your urgent 
assistance in transferring the sum of $11.3million immediately to your private 
account.The money has been here in our Bank lying dormant for years now without 
anybody coming for the claim of it.

I want to release the money to you as the relative to our deceased customer 
(the account owner) who died a long with his supposed NEXT OF KIN since 16th 
October 2005. The Banking laws here does not allow such money to stay more than 
13 years, because the money will be recalled to the Bank treasury account as 
unclaimed fund.

By indicating your interest I will send you the full details on how the 
business will be executed.

Please respond urgently and delete if you are not interested.

Best Regards,
Mr.Michel Duku.


Re: [GIT PULL] Char/Misc driver patches for 4.19-rc1

2018-08-31 Thread Greg KH
On Fri, Aug 31, 2018 at 01:19:36PM +0200, Pavel Machek wrote:
> Hi!
> 
> > - gnss, finally an in-kernel GPS subsystem to try to tame all of
> >   the crazy out-of-tree drivers that have been floating around
> >   for years, combined with some really hacky userspace
> >   implementations.  This is only for GNSS receivers, but you
> >   have to start somewhere, and this is great to see.
> 
> Yes, it  is labeled as a GPS subsystem, but there's nothing GPS
> specific in there; it does not understand the data, it just passes
> around bytes.
> 
> Which would not be a problem, except that it takes /dev/gnssX
> namespace, so when we need to introduce hardware abstraction for
> GPS, we will not have suitable names available.

Given that no such code seems to be showing up any year soon, that's a
request that we will just have to deal with if it ever shows up.

What we have now in the tree is good enough for now.

greg k-h


Give retouching

2018-08-31 Thread Jimmy Wilson

Hi,

Have you received my email from last week?

I would like to speak with the person who manage your photos for your
company?

We are here to provide you all kinds of imaging editing.

What we can provide you:
Cutting out for photos
Clipping path for photos
Masking for photos
Retouching for your photos
Retouching for the Beauty Model and Portraits.

We have 20 staffs in house and daily basis 1000 images can be processed.

We give testing for your photos.

Thanks,
Jimmy Wilson



[PATCH rdma-next] RDMA/qedr: remove set but not used variable 'ctx'

2018-08-31 Thread YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:

drivers/infiniband/hw/qedr/verbs.c: In function 'qedr_create_srq':
drivers/infiniband/hw/qedr/verbs.c:1450:24: warning:
 variable 'ctx' set but not used [-Wunused-but-set-variable]

Signed-off-by: YueHaibing 
---
 drivers/infiniband/hw/qedr/verbs.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/infiniband/hw/qedr/verbs.c 
b/drivers/infiniband/hw/qedr/verbs.c
index 8cc3df2..9d4d165 100644
--- a/drivers/infiniband/hw/qedr/verbs.c
+++ b/drivers/infiniband/hw/qedr/verbs.c
@@ -1447,7 +1447,6 @@ struct ib_srq *qedr_create_srq(struct ib_pd *ibpd,
u64 pbl_base_addr, phy_prod_pair_addr;
struct ib_ucontext *ib_ctx = NULL;
struct qedr_srq_hwq_info *hw_srq;
-   struct qedr_ucontext *ctx = NULL;
u32 page_cnt, page_size;
struct qedr_srq *srq;
int rc = 0;
@@ -1473,7 +1472,6 @@ struct ib_srq *qedr_create_srq(struct ib_pd *ibpd,
 
if (udata && ibpd->uobject && ibpd->uobject->context) {
ib_ctx = ibpd->uobject->context;
-   ctx = get_qedr_ucontext(ib_ctx);
 
if (ib_copy_from_udata(&ureq, udata, sizeof(ureq))) {
DP_ERR(dev,



[PATCH] x86/fault: Decode page fault OOPSes better

2018-08-31 Thread Andy Lutomirski
One of Linus' favorite hobbies seems to be looking at OOPSes and
decoding the error code in his head.  This is not one of my favorite
hobbies :)

Teach the page fault OOPS hander to decode the error code.  If it's
a !USER fault from user mode, print an explicit note to that effect
and print out the addresses of various tables that might cause such
an error.

Signed-off-by: Andy Lutomirski 
---

This is not the best-tested thing in the world, although it appears to
work.  I think it would have made developing PTI much more pleasant.

 arch/x86/mm/fault.c | 76 +
 1 file changed, 76 insertions(+)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index b9123c497e0a..9381ce880c9d 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -25,6 +25,7 @@
 #include   /* emulate_vsyscall */
 #include   /* struct vm86  */
 #include/* vma_pkey()   */
+#include   /* store_idt(), ... */
 
 #define CREATE_TRACE_POINTS
 #include 
@@ -640,10 +641,43 @@ static int is_f00f_bug(struct pt_regs *regs, unsigned 
long address)
return 0;
 }
 
+static void show_ldttss(const struct desc_ptr *gdt, const char *name, u16 
index)
+{
+   u32 offset = (index >> 3) * sizeof(struct desc_struct);
+   unsigned long addr;
+   struct ldttss_desc desc;
+
+   if (index == 0) {
+   pr_alert("%s: NULL\n", name);
+   return;
+   }
+
+   if (offset + sizeof(struct ldttss_desc) >= gdt->size) {
+   pr_alert("%s: 0x%hx -- out of bounds\n", name, index);
+   return;
+   }
+
+   if (probe_kernel_read(&desc, (void *)(gdt->address + offset),
+ sizeof(struct ldttss_desc))) {
+   pr_alert("%s: 0x%hx -- GDT entry is not readable\n",
+name, index);
+   return;
+   }
+
+   addr = desc.base0 | (desc.base1 << 16) | (desc.base2 << 24);
+#ifdef CONFIG_X86_64
+   addr |= ((u64)desc.base3 << 32);
+#endif
+   pr_alert("%s: 0x%hx -- base=0x%lx limit=0x%x\n",
+name, index, addr, (desc.limit0 | (desc.limit1 << 16)));
+}
+
 static void
 show_fault_oops(struct pt_regs *regs, unsigned long error_code,
unsigned long address)
 {
+   char errcode[64];
+
if (!oops_may_print())
return;
 
@@ -671,6 +705,48 @@ show_fault_oops(struct pt_regs *regs, unsigned long 
error_code,
 address < PAGE_SIZE ? "NULL pointer dereference" : "paging 
request",
 (void *)address);
 
+   errcode[0] = 0;
+#define ERRSTR(x) if (error_code & X86_PF_##x) strcat(errcode, " " #x)
+   ERRSTR(PROT);
+   ERRSTR(WRITE);
+   ERRSTR(USER);
+   ERRSTR(RSVD);
+   ERRSTR(INSTR);
+   ERRSTR(PK);
+#undef ERRSTR
+   pr_alert("HW error: %s\n", errcode[0] ? errcode + 1 :
+"normal kernel read fault");
+   if (!(error_code & X86_PF_USER) && user_mode(regs)) {
+   struct desc_ptr idt, gdt;
+   u16 ldtr, tr;
+
+   pr_alert("This was a system access from user code\n");
+
+   /*
+* This can happen for quite a few reasons.  The more obvious
+* ones are faults accessing the GDT, or LDT.  Perhaps
+* surprisingly, if the CPU tries to deliver a benign or
+* contributory exception from user code and gets a page fault
+* during delivery, the page fault can be delivered as though
+* it originated directly from user code.  This could happen
+* due to wrong permissions on the IDT, GDT, LDT, TSS, or
+* kernel or IST stack.
+*/
+   store_idt(&idt);
+
+   /* Usable even on Xen PV -- it's just slow. */
+   native_store_gdt(&gdt);
+
+   pr_alert("IDT: 0x%lx (limit=0x%hx) GDT: 0x%lx (limit=0x%hx)\n",
+idt.address, idt.size, gdt.address, gdt.size);
+
+   store_ldt(ldtr);
+   show_ldttss(&gdt, "LDTR", ldtr);
+
+   store_tr(tr);
+   show_ldttss(&gdt, "TR", tr);
+   }
+
dump_pagetable(address);
 }
 
-- 
2.17.1



Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

2018-08-31 Thread Andy Lutomirski
(Hi, Florian!)

On Fri, Aug 31, 2018 at 6:59 PM, Matt Rickard  wrote:
> Process clock_gettime(CLOCK_TAI) in vDSO.
> This makes the call about as fast as CLOCK_REALTIME and CLOCK_MONOTONIC:
>
>   nanoseconds
>  before after clockname
> - -
> 23387 CLOCK_TAI
>  9693 CLOCK_REALTIME
>  8887 CLOCK_MONOTONIC

Are you sure you did this right?  With the clocksource set to TSC
(which is the only reasonable choice unless KVM has seriously cleaned
up its act), with retpolines enabled, I get 24ns for CLOCK_MONOTONIC
without your patch and 32ns with your patch.  And there is indeed a
retpoline in the disassembled output:

  e5:   e8 07 00 00 00  callq  f1 <__vdso_clock_gettime+0x31>
  ea:   f3 90   pause
  ec:   0f ae e8lfence
  ef:   eb f9   jmpea <__vdso_clock_gettime+0x2a>
  f1:   48 89 04 24 mov%rax,(%rsp)
  f5:   c3  retq

You're probably going to have to set -fno-jump-tables or do something
clever like adding a whole array of (seconds, nsec) in gtod and
indexing that array by the clock id.

Meanwhile, I wrote the following trivial patch to add a
__vdso_clock_gettime_monotonic export.  It runs in 21ns, and I suspect
that the speedup is even a bit bigger when cache-cold because it
avoids some branches.  What do you all think?  Florian, do you think
glibc would be willing to add some magic to turn
clock_gettime(CLOCK_MONOTONIC, t) into
__vdso_clock_gettime_monotonic(t) when CLOCK_MONOTONIC is a constant?
diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c
index 91ed1bb2a3bb..4f22e9cb97a5 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -319,6 +319,14 @@ notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
 int clock_gettime(clockid_t, struct timespec *)
 	__attribute__((weak, alias("__vdso_clock_gettime")));
 
+notrace int __vdso_clock_gettime_monotonic(struct timespec *ts)
+{
+	if (likely(do_monotonic(ts) != VCLOCK_NONE))
+		return 0;
+
+	return vdso_fallback_gettime(CLOCK_MONOTONIC, ts);
+}
+
 notrace int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz)
 {
 	if (likely(tv != NULL)) {
diff --git a/arch/x86/entry/vdso/vdso.lds.S b/arch/x86/entry/vdso/vdso.lds.S
index d3a2dce4cfa9..28e23cbc02c9 100644
--- a/arch/x86/entry/vdso/vdso.lds.S
+++ b/arch/x86/entry/vdso/vdso.lds.S
@@ -15,6 +15,11 @@
  * This controls what userland symbols we export from the vDSO.
  */
 VERSION {
+	LINUX_4.19 {
+	global:
+		__vdso_clock_gettime_monotonic;
+	};
+
 	LINUX_2.6 {
 	global:
 		clock_gettime;


Re: [PATCH v5 1/2] clk: Add of_clk_get_by_name_optional() function

2018-08-31 Thread Stephen Boyd
Quoting Phil Edworthy (2018-08-31 07:07:22)
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 9ab3db8..4adb99e 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -54,30 +54,29 @@ EXPORT_SYMBOL(of_clk_get);
>  
>  static struct clk *__of_clk_get_by_name(struct device_node *np,
> const char *dev_id,
> -   const char *name)
> +   const char *name,
> +   bool optional)
>  {
> struct clk *clk = ERR_PTR(-ENOENT);
> +   struct device_node *child = np;
> +   int index = 0;
>  
> /* Walk up the tree of devices looking for a clock that matches */
> while (np) {
> -   int index = 0;
>  
> /*
>  * For named clocks, first look up the name in the
>  * "clock-names" property.  If it cannot be found, then
> -* index will be an error code, and of_clk_get() will fail.
> +* index will be an error code.
>  */
> if (name)
> index = of_property_match_string(np, "clock-names", 
> name);
> -   clk = __of_clk_get(np, index, dev_id, name);
> -   if (!IS_ERR(clk)) {
> -   break;
> -   } else if (name && index >= 0) {
> -   if (PTR_ERR(clk) != -EPROBE_DEFER)
> -   pr_err("ERROR: could not get clock 
> %pOF:%s(%i)\n",
> -   np, name ? name : "", index);
> +   if (index >= 0)
> +   clk = __of_clk_get(np, index, dev_id, name);
> +   if (!IS_ERR(clk))

Was this change necessary? It looks like we can leave it all alone and
keep passing a negative number to __of_clk_get() and have that return an
error pointer which we then return immediately as an error. But, if the
clock is optional and we've passed a name here, shouldn't we treat an
error from of_property_match_string() as success too? This is all
looking pretty fragile so maybe it can be better commented and also more
explicit instead of relying on the reader to jump through all the
function calls to figure out what the return value is in some cases.

> return clk;
> -   }
> +   if (name && index >= 0)
> +   break;

And this causes us to duplicate logic down below because we have to
check it again if it's not optional or some other error condition?

>  
> /*
>  * No matching clock found on this node.  If the parent node
> @@ -89,6 +88,16 @@ static struct clk *__of_clk_get_by_name(struct device_node 
> *np,
> break;
> }
>  
> +   /* The clock is not valid, but it could be optional or deferred */
> +   if (optional && PTR_ERR(clk) == -ENOENT) {
> +   clk = NULL;
> +   pr_info("no optional clock %pOF:%s\n", child,
> +   name ? name : "");

Is this intentionally pr_info?

> +   } else if (name && index >= 0 && PTR_ERR(clk) != -EPROBE_DEFER) {
> +   pr_err("ERROR: could not get clock %pOF:%s(%i)\n",
> +   child, name, index);
> +   }
> +
> return clk;
>  }
>  


Re: [PATCH] arm64: dts: ti: k3-am65: Change #address-cells and #size-cells of interconnect to 2

2018-08-31 Thread Nishanth Menon
On 15:56-20180828, Kishon Vijay Abraham I wrote:
[...]
>   cbass_mcu: interconnect@2838 {
>   compatible = "simple-bus";
>   #address-cells = <1>;
>   #size-cells = <1>;
> - ranges = <0x2838 0x2838 0x0388>, /* MCU 
> NAVSS*/
> -  <0x4020 0x4020 0x00900100>, /* First 
> peripheral window */
> -  <0x4204 0x4204 0x03ac2400>, /* WKUP */
> -  <0x4510 0x4510 0x00c24000>, /* MMRs, 
> remaining NAVSS */
> -  <0x4600 0x4600 0x0020>, /* CPSW */
> -  <0x4700 0x4700 0x00068400>; /* OSPI 
> space 1 */
> + ranges = <0x2838 0x00 0x2838 0x0388>, /* 
> MCU NAVSS*/
> +  <0x4020 0x00 0x4020 0x00900100>, /* 
> First peripheral window */
> +  <0x4204 0x00 0x4204 0x03ac2400>, /* 
> WKUP */
> +  <0x4510 0x00 0x4510 0x00c24000>, /* 
> MMRs, remaining NAVSS */
> +  <0x4600 0x00 0x4600 0x0020>, /* 
> CPSW */
> +  <0x4700 0x00 0x4700 0x00068400>; /* 
> OSPI space 1 */
>  


You might need #address-cells and #size-cells as 2 in MCU as
well.. Could you refer to response from Vignesh?
https://marc.info/?l=linux-arm-kernel&m=153572924921895&w=2

-- 
Regards,
Nishanth Menon


Re: [PATCH 2/3] of/fdt: avoid re-parsing '#{address,size}-cells' in of_fdt_limit_memory

2018-08-31 Thread kbuild test robot
Hi Rob,

I love your patch! Perhaps something to improve:

[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.19-rc1 next-20180831]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Rob-Herring/of-root-size-address-cells-clean-ups/20180831-160759
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

>> WARNING: vmlinux.o(.text+0x718907): Section mismatch in reference from the 
>> function of_fdt_limit_memory() to the variable .init.data:dt_root_addr_cells
   The function of_fdt_limit_memory() references
   the variable __initdata dt_root_addr_cells.
   This is often because of_fdt_limit_memory lacks a __initdata
   annotation or the annotation of dt_root_addr_cells is wrong.
--
>> WARNING: vmlinux.o(.text+0x718917): Section mismatch in reference from the 
>> function of_fdt_limit_memory() to the variable .init.data:dt_root_size_cells
   The function of_fdt_limit_memory() references
   the variable __initdata dt_root_size_cells.
   This is often because of_fdt_limit_memory lacks a __initdata
   annotation or the annotation of dt_root_size_cells is wrong.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: REGRESSION: boot stalls on several old dual core Intel CPUs

2018-08-31 Thread Kevin Shanahan
On Thu, Aug 30, 2018 at 03:04:39PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 12:55:30PM +0200, Siegfried Metz wrote:
> > Dear kernel developers,
> > 
> > since mainline kernel 4.18 (up to the latest mainline kernel 4.18.5)
> > Intel Core 2 Duo processors are affected by boot stalling early in the
> > boot process. As it is so early there is no dmesg output (or any log).
> > 
> > A few users in the Arch Linux community used git bisect and tracked the
> > issue down to this the bad commit:
> > 7197e77abcb65a71d0b21d67beb24f153a96055e clocksource: Remove kthread
> 
> I just dug out my core2duo laptop (Lenovo T500) and build a tip/master
> kernel for it (x86_64 debian distro .config).
> 
> Seems to boot just fine.. 3/3 so far.
> 
> Any other clues?

One additional data point, my affected system is a Dell Latitude E6400
laptop which has a P8400 CPU:

  vendor_id : GenuineIntel
  cpu family: 6
  model : 23
  model name: Intel(R) Core(TM)2 Duo CPU P8400  @ 2.26GHz
  stepping  : 6
  microcode : 0x610

Judging from what is being discussed in the Arch forums, it does seem
to related to the CPU having unstable TSC and transitioning to another
clock source.  Workarounds that seem to be reliable are either booting
with clocksource= or with nosmp.

One person did point out that the commit that introduced the kthread
did so to remove a deadlock - is the circular locking dependency
mentioned in that commit still relevant?

commit 01548f4d3e8e94caf323a4f664eb347fd34a34ab
Author: Martin Schwidefsky 
Date:   Tue Aug 18 17:09:42 2009 +0200

clocksource: Avoid clocksource watchdog circular locking dependency

stop_machine from a multithreaded workqueue is not allowed because
of a circular locking dependency between cpu_down and the workqueue
execution. Use a kernel thread to do the clocksource downgrade.

Signed-off-by: Martin Schwidefsky 
Cc: Peter Zijlstra 
Cc: john stultz 
LKML-Reference: <20090818170942.3ab80c91@skybase>
Signed-off-by: Thomas Gleixner 

Thanks,
Kevin.


[GIT PULL] clk fixes for v4.19-rc1

2018-08-31 Thread sboyd
From: Stephen Boyd 

The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git 
tags/clk-fixes-for-linus

for you to fetch changes up to bded6c03e398dc6e862dc8301fb9a60175740653:

  clk: x86: Set default parent to 48Mhz (2018-08-30 14:47:41 -0700)


Two small fixes, one for the x86 Stoney SoC to get a more accurate clk
frequency and the other to fix a bad allocation in the Nuvoton NPCM7XX
driver.


Akshu Agrawal (1):
  clk: x86: Set default parent to 48Mhz

Gustavo A. R. Silva (1):
  clk: npcm7xx: fix memory allocation

 drivers/clk/clk-npcm7xx.c | 4 ++--
 drivers/clk/x86/clk-st.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
Sent by a computer through tubes


[PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

2018-08-31 Thread Matt Rickard
Process clock_gettime(CLOCK_TAI) in vDSO.
This makes the call about as fast as CLOCK_REALTIME and CLOCK_MONOTONIC:

  nanoseconds
 before after clockname
    - -
23387 CLOCK_TAI
 9693 CLOCK_REALTIME
 8887 CLOCK_MONOTONIC

Signed-off-by: Matt Rickard 
---
 arch/x86/entry/vdso/vclock_gettime.c| 25 +
 arch/x86/entry/vsyscall/vsyscall_gtod.c |  2 ++
 arch/x86/include/asm/vgtod.h|  1 +
 3 files changed, 28 insertions(+)

diff --git a/arch/x86/entry/vdso/vclock_gettime.c 
b/arch/x86/entry/vdso/vclock_gettime.c
index f19856d95c60..91ed1bb2a3bb 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -246,6 +246,27 @@ notrace static int __always_inline do_monotonic(struct 
timespec *ts)
return mode;
 }
 
+notrace static int __always_inline do_tai(struct timespec *ts)
+{
+   unsigned long seq;
+   u64 ns;
+   int mode;
+
+   do {
+   seq = gtod_read_begin(gtod);
+   mode = gtod->vclock_mode;
+   ts->tv_sec = gtod->tai_time_sec;
+   ns = gtod->wall_time_snsec;
+   ns += vgetsns(&mode);
+   ns >>= gtod->shift;
+   } while (unlikely(gtod_read_retry(gtod, seq)));
+
+   ts->tv_sec += __iter_div_u64_rem(ns, NSEC_PER_SEC, &ns);
+   ts->tv_nsec = ns;
+
+   return mode;
+}
+
 notrace static void do_realtime_coarse(struct timespec *ts)
 {
unsigned long seq;
@@ -277,6 +298,10 @@ notrace int __vdso_clock_gettime(clockid_t clock, struct 
timespec *ts)
if (do_monotonic(ts) == VCLOCK_NONE)
goto fallback;
break;
+   case CLOCK_TAI:
+   if (do_tai(ts) == VCLOCK_NONE)
+   goto fallback;
+   break;
case CLOCK_REALTIME_COARSE:
do_realtime_coarse(ts);
break;
diff --git a/arch/x86/entry/vsyscall/vsyscall_gtod.c 
b/arch/x86/entry/vsyscall/vsyscall_gtod.c
index e1216dd95c04..d61392fe17f6 100644
--- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
+++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
@@ -53,6 +53,8 @@ void update_vsyscall(struct timekeeper *tk)
vdata->monotonic_time_snsec = tk->tkr_mono.xtime_nsec
+ ((u64)tk->wall_to_monotonic.tv_nsec
<< tk->tkr_mono.shift);
+   vdata->tai_time_sec = tk->xtime_sec
+   + tk->tai_offset;
while (vdata->monotonic_time_snsec >=
(((u64)NSEC_PER_SEC) << 
tk->tkr_mono.shift)) {
vdata->monotonic_time_snsec -=
diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index fb856c9f0449..adc9f7b20b9c 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -32,6 +32,7 @@ struct vsyscall_gtod_data {
gtod_long_t wall_time_coarse_nsec;
gtod_long_t monotonic_time_coarse_sec;
gtod_long_t monotonic_time_coarse_nsec;
+   gtod_long_t tai_time_sec;
 
int tz_minuteswest;
int tz_dsttime;


Re: [PATCH] mm: slowly shrink slabs with a relatively small number of objects

2018-08-31 Thread Rik van Riel
On Fri, 2018-08-31 at 14:31 -0700, Roman Gushchin wrote:
> On Fri, Aug 31, 2018 at 05:15:39PM -0400, Rik van Riel wrote:
> > On Fri, 2018-08-31 at 13:34 -0700, Roman Gushchin wrote:
> > 
> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index fa2c150ab7b9..c910cf6bf606 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -476,6 +476,10 @@ static unsigned long do_shrink_slab(struct
> > > shrink_control *shrinkctl,
> > >   delta = freeable >> priority;
> > >   delta *= 4;
> > >   do_div(delta, shrinker->seeks);
> > > +
> > > + if (delta == 0 && freeable > 0)
> > > + delta = min(freeable, batch_size);
> > > +
> > >   total_scan += delta;
> > >   if (total_scan < 0) {
> > >   pr_err("shrink_slab: %pF negative objects to delete
> > > nr=%ld\n",
> > 
> > I agree that we need to shrink slabs with fewer than
> > 4096 objects, but do we want to put more pressure on
> > a slab the moment it drops below 4096 than we applied
> > when it had just over 4096 objects on it?
> > 
> > With this patch, a slab with 5000 objects on it will
> > get 1 item scanned, while a slab with 4000 objects on
> > it will see shrinker->batch or SHRINK_BATCH objects
> > scanned every time.
> > 
> > I don't know if this would cause any issues, just
> > something to ponder.
> 
> Hm, fair enough. So, basically we can always do
> 
> delta = max(delta, min(freeable, batch_size));
> 
> Does it look better?

Yeah, that looks fine to me.

That will read to small cgroups having small caches
reclaimed relatively more quickly than large caches
getting reclaimed, but small caches should also be
faster to refill once they are needed again, so it
is probably fine.

-- 
All Rights Reversed.


signature.asc
Description: This is a digitally signed message part


Re: [PATCH 1/3] ARM: dts: qcom: Add SPMI PMIC Arbiter nodes for APQ8084 and MSM8974

2018-08-31 Thread Frank Rowand
On 08/31/18 16:01, Bjorn Andersson wrote:
> On Fri 31 Aug 15:46 PDT 2018, Frank Rowand wrote:
>>> +   spmi_bus: spmi@fc4cf000 {
>>> +   compatible = "qcom,spmi-pmic-arb";
>>> +   reg-names = "core", "intr", "cnfg";
>>> +   reg = <0xfc4cf000 0x1000>,
>>> + <0xfc4cb000 0x1000>,
>>> + <0xfc4ca000 0x1000>;
>>> +   interrupt-names = "periph_irq";
>>
>>> +   interrupts = <0 190 0>;
>>
>> The final value in this interrupts property means IRQ_TYPE_NONE.
>>
>> A WARN_ON() was added early this year to complain about use of
>> IRQ_TYPE_NONE: 83a86fbb5b56 "irqchip/gic: Loudly complain about
>> the use of IRQ_TYPE_NONE", resulting in many warnings spewing
>> forth when I boot an APQ8074 Dragonboard.  I am trying to
>> determine whether the warning is overly aggressive, or whether
>> the IRQ TYPE is incorrectly specified for the spmi node.
>>
>> The interrupt-parent for the spmi node is intc: 
>> interrupt-controller@f900,
>> which has compatible = "qcom,msm-qgic2".  I do not know the architecture
>> or implementation of this interrupt controller.  Is an IRQ_TYPE_NONE
>> valid in this case, or should a specific type be provided?
>>
> 
> No, IRQ_TYPE_NONE isn't valid and the WARN_ON() is reasonable.
> 
> Please change it to IRQ_TYPE_LEVEL_HIGH. And while you're at it, replace
> the first 0 with GIC_SPI.
> 
> 
> If you have more of these warnings you can most likely look at e.g.
> msm8916 (arm64) to find the right flags.

Thanks, I'll create a patch.


Re: [PATCH 0/4] of: Convert to using %pOFn for node name printf

2018-08-31 Thread Frank Rowand
On 08/28/18 08:52, Rob Herring wrote:
> This is the DT portion of converting node name printf's to use the 
> %pOFn format specifier rather than device_node.name. Patches for other 
> subsystems are independent and have been sent separately.
> 
> Rob
> 
> Rob Herring (4):
>   of/unittest: remove use of node name pointer in overlay high level
> test
>   of/unittest: add printf tests for node name
>   of: Convert to using %pOFn instead of device_node.name
>   vsprintf: print OF node name using full_name
> 
>  drivers/of/device.c   |  4 ++--
>  drivers/of/of_mdio.c  | 12 ++--
>  drivers/of/of_numa.c  |  4 ++--
>  drivers/of/overlay.c  |  4 ++--
>  drivers/of/platform.c |  8 
>  drivers/of/unittest.c | 26 --
>  lib/vsprintf.c|  9 +++--
>  7 files changed, 39 insertions(+), 28 deletions(-)
> 


Reviewed-by: Frank Rowand 


[PATCH 0/3] regmap: split regmap_config.use_single_rw

2018-08-31 Thread David Frey
This patch series splits regmap_config.use_single_rw into
use_single_read and use_single_write.

Motivation:
When multiple sequential registers need to be read or written, the
author can either choose to call regmap_bulk_read/write() once or call
regmap_read/write() repeatedly. The _bulk option has the advantages of
being more compact since only one function call is needed and more
efficient since multiple registers are read/written at once instead of
having to pay for transaction and addressing overhead of the underlying
transport multiple times.

Many chips don't support bulk access, but it's still convenient to be
able to read/write multiple registers with a single function call. This
is what use_single_rw=true is for. When this option is set, bulk
reads/writes are automatically split into a series of single register
accesses.

Some other chips (for example the Bosch bmi160 IMU) support bulk reads,
but not bulk writes. Currently for chips like this, the author must
choose between convenience or efficiency by setting use_single_rw =
true/false respectively.

Proposal:
In this patch series I split the use_single_rw member of struct
regmap_config into use_single_read and use_single_write. This change is
in line with what is already implemented inside of the internal struct
regmap which is populated from struct regmap_config.

I submitted separate patches for the change that performs the split and
the update to all of the existing clients. I wasn't sure if this is the
preferred method or if it's better to combine those patches.


David Frey (3):
  regmap: fix comment for regmap.use_single_write
  regmap: split up regmap_config.use_single_rw
  regmap: update users of regmap_config.use_single_rw

 drivers/base/regmap/internal.h   |  2 +-
 drivers/base/regmap/regmap.c |  4 ++--
 drivers/edac/altera_edac.c   |  3 ++-
 drivers/hwmon/lm75.c |  3 ++-
 drivers/hwmon/lm95245.c  |  3 ++-
 drivers/hwmon/tmp102.c   |  3 ++-
 drivers/hwmon/tmp108.c   |  3 ++-
 drivers/iio/light/apds9960.c |  3 ++-
 drivers/iio/light/max44000.c | 23 ---
 drivers/iio/temperature/mlx90632.c   |  3 ++-
 drivers/input/touchscreen/tsc200x-core.c |  3 ++-
 drivers/mfd/altera-a10sr.c   |  3 ++-
 drivers/mfd/da9052-spi.c |  3 ++-
 drivers/mfd/mc13xxx-spi.c|  3 ++-
 drivers/mfd/twl6040.c|  3 ++-
 drivers/regulator/ltc3589.c  |  3 ++-
 drivers/regulator/ltc3676.c  |  3 ++-
 include/linux/regmap.h   | 12 
 sound/hda/hdac_regmap.c  |  3 ++-
 sound/soc/codecs/cs35l33.c   |  3 ++-
 sound/soc/codecs/cs35l35.c   |  3 ++-
 sound/soc/codecs/cs43130.c   |  4 +++-
 sound/soc/codecs/es8328.c|  3 ++-
 sound/soc/codecs/rt1305.c|  3 ++-
 sound/soc/codecs/rt5514.c|  3 ++-
 sound/soc/codecs/rt5616.c|  3 ++-
 sound/soc/codecs/rt5640.c|  3 ++-
 sound/soc/codecs/rt5645.c|  9 ++---
 sound/soc/codecs/rt5651.c|  3 ++-
 sound/soc/codecs/rt5660.c|  3 ++-
 sound/soc/codecs/rt5663.c|  9 ++---
 sound/soc/codecs/rt5665.c|  3 ++-
 sound/soc/codecs/rt5668.c|  3 ++-
 sound/soc/codecs/rt5670.c|  3 ++-
 sound/soc/codecs/rt5682.c|  3 ++-
 35 files changed, 94 insertions(+), 53 deletions(-)

-- 
2.11.0



[PATCH 1/3] regmap: fix comment for regmap.use_single_write

2018-08-31 Thread David Frey
Signed-off-by: David Frey 
---
 drivers/base/regmap/internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index a6bf34d6394e..16414ccace96 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -149,7 +149,7 @@ struct regmap {
 
/* if set, converts bulk read to single read */
bool use_single_read;
-   /* if set, converts bulk read to single read */
+   /* if set, converts bulk write to single write */
bool use_single_write;
/* if set, the device supports multi write mode */
bool can_multi_write;
-- 
2.11.0



[PATCH 2/3] regmap: split up regmap_config.use_single_rw

2018-08-31 Thread David Frey
Split regmap_config.use_single_rw into use_single_read and
use_single_write. This change enables drivers of devices which only
support bulk operations in one direction to use the regmap_bulk_*()
functions for both directions and have their bulk operation split into
single operations only when necessary.

Signed-off-by: David Frey 
---
 drivers/base/regmap/regmap.c |  4 ++--
 include/linux/regmap.h   | 12 
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 0360a90ad6b6..78a778c08f92 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -762,8 +762,8 @@ struct regmap *__regmap_init(struct device *dev,
map->reg_stride_order = ilog2(map->reg_stride);
else
map->reg_stride_order = -1;
-   map->use_single_read = config->use_single_rw || !bus || !bus->read;
-   map->use_single_write = config->use_single_rw || !bus || !bus->write;
+   map->use_single_read = config->use_single_read || !bus || !bus->read;
+   map->use_single_write = config->use_single_write || !bus || !bus->write;
map->can_multi_write = config->can_multi_write && bus && bus->write;
if (bus) {
map->max_raw_read = bus->max_raw_read;
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 379505a53722..6ea9bf9377cb 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -315,9 +315,12 @@ typedef void (*regmap_unlock)(void *);
  *   masks are used.
  * @zero_flag_mask: If set, read_flag_mask and write_flag_mask are used even
  *   if they are both empty.
- * @use_single_rw: If set, converts the bulk read and write operations into
- * a series of single read and write operations. This is useful
- * for device that does not support bulk read and write.
+ * @use_single_read: If set, converts the bulk read operation into a series of
+ *   single read operations. This is useful for a device that
+ *   does not support  bulk read.
+ * @use_single_write: If set, converts the bulk write operation into a series 
of
+ *single write operations. This is useful for a device that
+ *does not support bulk write.
  * @can_multi_write: If set, the device supports the multi write mode of bulk
  *   write operations, if clear multi write requests will be
  *   split into individual write operations
@@ -380,7 +383,8 @@ struct regmap_config {
unsigned long write_flag_mask;
bool zero_flag_mask;
 
-   bool use_single_rw;
+   bool use_single_read;
+   bool use_single_write;
bool can_multi_write;
 
enum regmap_endian reg_format_endian;
-- 
2.11.0



[PATCH 3/3] regmap: update users of regmap_config.use_single_rw

2018-08-31 Thread David Frey
Update all struct regmap_config instances where the use_single_rw member
was set to instead set both use_single_read and use_single_write. No
attempt was made to evaluate whether it is possible to set only one of
use_single_read or use_single_write.

Signed-off-by: David Frey 
---
 drivers/edac/altera_edac.c   |  3 ++-
 drivers/hwmon/lm75.c |  3 ++-
 drivers/hwmon/lm95245.c  |  3 ++-
 drivers/hwmon/tmp102.c   |  3 ++-
 drivers/hwmon/tmp108.c   |  3 ++-
 drivers/iio/light/apds9960.c |  3 ++-
 drivers/iio/light/max44000.c | 23 ---
 drivers/iio/temperature/mlx90632.c   |  3 ++-
 drivers/input/touchscreen/tsc200x-core.c |  3 ++-
 drivers/mfd/altera-a10sr.c   |  3 ++-
 drivers/mfd/da9052-spi.c |  3 ++-
 drivers/mfd/mc13xxx-spi.c|  3 ++-
 drivers/mfd/twl6040.c|  3 ++-
 drivers/regulator/ltc3589.c  |  3 ++-
 drivers/regulator/ltc3676.c  |  3 ++-
 sound/hda/hdac_regmap.c  |  3 ++-
 sound/soc/codecs/cs35l33.c   |  3 ++-
 sound/soc/codecs/cs35l35.c   |  3 ++-
 sound/soc/codecs/cs43130.c   |  4 +++-
 sound/soc/codecs/es8328.c|  3 ++-
 sound/soc/codecs/rt1305.c|  3 ++-
 sound/soc/codecs/rt5514.c|  3 ++-
 sound/soc/codecs/rt5616.c|  3 ++-
 sound/soc/codecs/rt5640.c|  3 ++-
 sound/soc/codecs/rt5645.c|  9 ++---
 sound/soc/codecs/rt5651.c|  3 ++-
 sound/soc/codecs/rt5660.c|  3 ++-
 sound/soc/codecs/rt5663.c|  9 ++---
 sound/soc/codecs/rt5665.c|  3 ++-
 sound/soc/codecs/rt5668.c|  3 ++-
 sound/soc/codecs/rt5670.c|  3 ++-
 sound/soc/codecs/rt5682.c|  3 ++-
 32 files changed, 83 insertions(+), 46 deletions(-)

diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 5762c3c383f2..ab7c5a937ab0 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -599,7 +599,8 @@ static const struct regmap_config s10_sdram_regmap_cfg = {
.volatile_reg = s10_sdram_volatile_reg,
.reg_read = s10_protected_reg_read,
.reg_write = s10_protected_reg_write,
-   .use_single_rw = true,
+   .use_single_read = true,
+   .use_single_write = true,
 };
 
 static int altr_s10_sdram_probe(struct platform_device *pdev)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 49f4b33a5685..542dc4058831 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -254,7 +254,8 @@ static const struct regmap_config lm75_regmap_config = {
.volatile_reg = lm75_is_volatile_reg,
.val_format_endian = REGMAP_ENDIAN_BIG,
.cache_type = REGCACHE_RBTREE,
-   .use_single_rw = true,
+   .use_single_read = true,
+   .use_single_write = true,
 };
 
 static void lm75_remove(void *data)
diff --git a/drivers/hwmon/lm95245.c b/drivers/hwmon/lm95245.c
index 27cb06d65594..996b50246175 100644
--- a/drivers/hwmon/lm95245.c
+++ b/drivers/hwmon/lm95245.c
@@ -541,7 +541,8 @@ static const struct regmap_config lm95245_regmap_config = {
.writeable_reg = lm95245_is_writeable_reg,
.volatile_reg = lm95245_is_volatile_reg,
.cache_type = REGCACHE_RBTREE,
-   .use_single_rw = true,
+   .use_single_read = true,
+   .use_single_write = true,
 };
 
 static const u32 lm95245_chip_config[] = {
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index dfc40c740d07..6778283e36f9 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -212,7 +212,8 @@ static const struct regmap_config tmp102_regmap_config = {
.volatile_reg = tmp102_is_volatile_reg,
.val_format_endian = REGMAP_ENDIAN_BIG,
.cache_type = REGCACHE_RBTREE,
-   .use_single_rw = true,
+   .use_single_read = true,
+   .use_single_write = true,
 };
 
 static int tmp102_probe(struct i2c_client *client,
diff --git a/drivers/hwmon/tmp108.c b/drivers/hwmon/tmp108.c
index 91bb94639286..429bfeae4ca8 100644
--- a/drivers/hwmon/tmp108.c
+++ b/drivers/hwmon/tmp108.c
@@ -345,7 +345,8 @@ static const struct regmap_config tmp108_regmap_config = {
.volatile_reg = tmp108_is_volatile_reg,
.val_format_endian = REGMAP_ENDIAN_BIG,
.cache_type = REGCACHE_RBTREE,
-   .use_single_rw = true,
+   .use_single_read = true,
+   .use_single_write = true,
 };
 
 static int tmp108_probe(struct i2c_client *client,
diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c
index 1f112ae15f3c..b09b8b60bd83 100644
--- a/drivers/iio/light/apds9960.c
+++ b/drivers/iio/light/apds9960.c
@@ -206,7 +206,8 @@ static const struct regmap_config apds9960_regmap_config = {
.name = APDS9960_REGMAP_NAME,
.reg_bits = 8,
.val_bits = 8,
-

Re: [PATCH 7/7] Compiler Attributes: use feature checks instead of version checks

2018-08-31 Thread Nick Desaulniers
Overall, pretty happy with this patch.  Still some thoughts for a v3,
thanks for sending it!

On Fri, Aug 31, 2018 at 10:05 AM Miguel Ojeda
 wrote:
>
> Instead of using version checks per-compiler to define (or not)
> each attribute, use __has_attribute to test for them, following
> the cleanup started with commit 815f0ddb346c
> ("include/linux/compiler*.h: make compiler-*.h mutually exclusive").
>
> All the attributes that are fairly common/standard (i.e. those that
> do not require extra logic to define them) have been moved
> to a new file include/linux/compiler_attributes.h.
>
> In an effort to make the file as regular as possible, comments
> stating the purpose of attributes have been removed. Instead,
> links to the compiler docs have been added (i.e. to gcc and,
> if available, to clang as well). In addition, they have been sorted.
>
> Finally, if an attribute is optional (i.e. if it is guarded
> by __has_attribute), the reason has been stated for future reference.
>
> Cc: Eli Friedman 
> Cc: Christopher Li 
> Cc: Kees Cook 
> Cc: Ingo Molnar 
> Cc: Geert Uytterhoeven 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Masahiro Yamada 
> Cc: Joe Perches 
> Cc: Dominique Martinet 
> Cc: Nick Desaulniers 
> Cc: Linus Torvalds 
> Signed-off-by: Miguel Ojeda 
> ---
>  include/linux/compiler-clang.h  |   4 -
>  include/linux/compiler-gcc.h|  51 ---
>  include/linux/compiler-intel.h  |   6 -
>  include/linux/compiler_attributes.h | 226 
>  include/linux/compiler_types.h  |  72 +
>  5 files changed, 232 insertions(+), 127 deletions(-)
>  create mode 100644 include/linux/compiler_attributes.h
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index 0aee694d3ab8..3e7dafb3ea80 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -21,8 +21,6 @@
>  #define __SANITIZE_ADDRESS__
>  #endif
>
> -#define __no_sanitize_address __attribute__((no_sanitize("address")))
> -
>  /*
>   * Not all versions of clang implement the the type-generic versions
>   * of the builtin overflow checkers. Fortunately, clang implements
> @@ -41,5 +39,3 @@
>   * compilers, like ICC.
>   */
>  #define barrier() __asm__ __volatile__("" : : : "memory")
> -#define __assume_aligned(a, ...)   \
> -   __attribute__((assume_aligned(a, ## __VA_ARGS__)))
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 32e6ce06163f..627fa8941436 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -116,9 +116,6 @@
> __builtin_unreachable();\
> } while (0)
>
> -/* Mark a function definition as prohibited from being cloned. */
> -#define __noclone  __attribute__((noclone, optimize("no-tracer")))
> -
>  #if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__)
>  #define __randomize_layout __attribute__((randomize_layout))
>  #define __no_randomize_layout __attribute__((no_randomize_layout))
> @@ -127,32 +124,6 @@
>  #define randomized_struct_fields_end   } __randomize_layout;
>  #endif
>
> -/*
> - * When used with Link Time Optimization, gcc can optimize away C functions 
> or
> - * variables which are referenced only from assembly code.  __visible tells 
> the
> - * optimizer that something else uses this function or variable, thus 
> preventing
> - * this.
> - */
> -#define __visible  __attribute__((externally_visible))
> -
> -/* gcc version specific checks */
> -
> -#if GCC_VERSION >= 40900
> -/*
> - * __assume_aligned(n, k): Tell the optimizer that the returned
> - * pointer can be assumed to be k modulo n. The second argument is
> - * optional (default 0), so we use a variadic macro to make the
> - * shorthand.
> - *
> - * Beware: Do not apply this to functions which may return
> - * ERR_PTRs. Also, it is probably unwise to apply it to functions
> - * returning extra information in the low bits (but in that case the
> - * compiler should see some alignment anyway, when the return value is
> - * massaged by 'flags = ptr & 3; ptr &= ~3;').
> - */
> -#define __assume_aligned(a, ...) __attribute__((assume_aligned(a, ## 
> __VA_ARGS__)))
> -#endif
> -
>  /*
>   * GCC 'asm goto' miscompiles certain code sequences:
>   *
> @@ -184,32 +155,10 @@
>  #define KASAN_ABI_VERSION 3
>  #endif
>
> -#if GCC_VERSION >= 40902
> -/*
> - * Tell the compiler that address safety instrumentation (KASAN)
> - * should not be applied to that function.
> - * Conflicts with inlining: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
> - */
> -#define __no_sanitize_address __attribute__((no_sanitize_address))
> -#endif
> -
>  #if GCC_VERSION >= 50100
> -/*
> - * Mark structures as requiring designated initializers.
> - * https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
> - */
> -#define __designated_init __attribute__((designated_init))
>  #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
>  #endif
>
> -#if !defined(__noclone)
> -#define __no

[PATCH 05/20] staging:rtl8192u: Rename RTL819xU_MODULE_NAME - Style

2018-08-31 Thread John Whitmore
Rename the MACRO RTL819xU_MODULE_NAME to RTL819XU_MODULE_NAME, this
clears the checkpatch issue with CamelCase naming.

This is a coding style change which should have no impact on runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 4dcfcb4d3911..81a7072a6285 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -40,7 +40,7 @@
 #include "ieee80211/ieee80211.h"
 
 #define RTL8192U
-#define RTL819xU_MODULE_NAME "rtl819xU"
+#define RTL819XU_MODULE_NAME "rtl819xU"
 /* HW security */
 #define MAX_KEY_LEN 61
 #define KEY_BUF_SIZE5
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 98bb40c50f40..b3d32ea29fee 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -128,7 +128,7 @@ static void rtl8192_usb_disconnect(struct usb_interface 
*intf);
 
 
 static struct usb_driver rtl8192_usb_driver = {
-   .name   = RTL819xU_MODULE_NAME,   /* Driver name   */
+   .name   = RTL819XU_MODULE_NAME,   /* Driver name   */
.id_table   = rtl8192_usb_id_tbl, /* PCI_ID table  */
.probe  = rtl8192_usb_probe,  /* probe fn  */
.disconnect = rtl8192_usb_disconnect, /* remove fn */
@@ -627,7 +627,7 @@ static int __maybe_unused proc_get_stats_rx(struct seq_file 
*m, void *v)
 static void rtl8192_proc_module_init(void)
 {
RT_TRACE(COMP_INIT, "Initializing proc filesystem");
-   rtl8192_proc = proc_mkdir(RTL819xU_MODULE_NAME, init_net.proc_net);
+   rtl8192_proc = proc_mkdir(RTL819XU_MODULE_NAME, init_net.proc_net);
 }
 
 static void rtl8192_proc_init_one(struct net_device *dev)
-- 
2.18.0



[PATCH 07/20] staging:rtl8192u: Refactor RT_TRACE - Style

2018-08-31 Thread John Whitmore
Refactor the MACRO RT_TRACE to add parentheses around the parameter
'component', this clears the checkpatch warning with respect to
precedence issues.

This is a coding style change which should have no impact on runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index b5ad69af8dac..c613894a6088 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -52,7 +52,7 @@
 extern u32 rt_global_debug_component;
 #define RT_TRACE(component, x, args...) \
do {\
-   if (rt_global_debug_component & component)  \
+   if (rt_global_debug_component & (component))\
pr_debug("RTL8192U: " x "\n", ##args);  \
} while (0)
 
-- 
2.18.0



[PATCH 03/20] staging:rtl8192u: Remove unused functions - Style

2018-08-31 Thread John Whitmore
Remove unused function declarations. This is a coding style change
which should have no impact on runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 10 --
 drivers/staging/rtl8192u/r8192U_core.c |  7 ---
 2 files changed, 17 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 70bbd1fadcca..b3e6ce2acedb 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1103,22 +1103,12 @@ void force_pci_posting(struct net_device *dev);
 
 void rtl8192_rtx_disable(struct net_device *dev);
 void rtl8192_rx_enable(struct net_device *dev);
-void rtl8192_tx_enable(struct net_device *dev);
 
-void rtl8192_disassociate(struct net_device *dev);
-void rtl8185_set_rf_pins_enable(struct net_device *dev, u32 a);
-
-void rtl8192_set_anaparam(struct net_device *dev, u32 a);
-void rtl8185_set_anaparam2(struct net_device *dev, u32 a);
 void rtl8192_update_msr(struct net_device *dev);
 int rtl8192_down(struct net_device *dev);
 int rtl8192_up(struct net_device *dev);
 void rtl8192_commit(struct net_device *dev);
 void rtl8192_set_chan(struct net_device *dev, short ch);
-void write_phy(struct net_device *dev, u8 adr, u8 data);
-void write_phy_cck(struct net_device *dev, u8 adr, u32 data);
-void write_phy_ofdm(struct net_device *dev, u8 adr, u32 data);
-void rtl8185_tx_antenna(struct net_device *dev, u8 ant);
 void rtl8192_set_rxconf(struct net_device *dev);
 void rtl819xusb_beacon_tx(struct net_device *dev, u16 tx_rate);
 
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 12783b88eb58..98bb40c50f40 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -830,13 +830,6 @@ void rtl8192_rx_enable(struct net_device *dev)
rtl8192_rx_initiate(dev);
 }
 
-
-void rtl8192_tx_enable(struct net_device *dev)
-{
-}
-
-
-
 void rtl8192_rtx_disable(struct net_device *dev)
 {
u8 cmd;
-- 
2.18.0



[PATCH 09/20] staging:rtl8192u: Remove RT_DEBUG_DATA - Style

2018-08-31 Thread John Whitmore
Remove the RT_DEBUG_DATA Macro. The macro causes a number of
checkpatch issues, and is not actually used in code, so can simply
be removed without issue.

This is a coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index e65a893fd084..528c50be3894 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -103,28 +103,8 @@ extern u32 rt_global_debug_component;
 #expr, __FILE__, __func__, __LINE__);  \
}   \
} while (0)
-/*
- * Debug out data buf.
- * If you want to print DATA buffer related BA,
- * please set ieee80211_debug_level to DATA|BA
- */
-#define RT_DEBUG_DATA(level, data, datalen) \
-   do {\
-   if ((rt_global_debug_component & (level)) == (level)) { \
-   int i;  \
-   u8 *pdata = (u8 *)data; \
-   pr_debug("RTL8192U: %s()\n", __func__); \
-   for (i = 0; i < (int)(datalen); i++) {  \
-   printk("%2x ", pdata[i]);   \
-   if ((i+1)%16 == 0)  \
-   printk("\n");   \
-   }   \
-   printk("\n");   \
-   }   \
-   } while (0)
 #else
 #define RTL8192U_ASSERT(expr) do {} while (0)
-#define RT_DEBUG_DATA(level, data, datalen) do {} while (0)
 #endif /* RTL8169_DEBUG */
 
 /* Queue Select Value in TxDesc */
-- 
2.18.0



[PATCH 20/20] staging:rtl8192u: Rename OWN - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'OWN' to 'own', this is to comply with the
coding standard, where variables are named in lowercase.

This is a simple coding style change which should have no impact on
runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 68e82b32a88e..f963b664e221 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -165,7 +165,7 @@ struct tx_desc_819x_usb {
u8  last_seg:1;
u8  first_seg:1;
u8  linip:1;
-   u8  OWN:1;
+   u8  own:1;
 
/* DWORD 1 */
u8  TxFWInfoSize;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 911d0214b48a..4d0f70ec31ac 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1558,7 +1558,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
/* DWORD 0 */
tx_desc->first_seg = 1;
tx_desc->last_seg = 1;
-   tx_desc->OWN = 1;
+   tx_desc->own = 1;
 
/* DWORD 2 */
tx_desc->TxBufferSize = (u32)(skb->len - USB_HWDESC_HEADER_LEN);
-- 
2.18.0



[PATCH 02/20] staging:rtl8192u: Remove read_cam() - Style

2018-08-31 Thread John Whitmore
Remove the function read_cam(), as it is unused in code.

Simple style change which should not impact runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 --
 drivers/staging/rtl8192u/r8192U_core.c | 9 -
 2 files changed, 11 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 77324a471de1..70bbd1fadcca 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1091,8 +1091,6 @@ bool init_firmware(struct net_device *dev);
 short rtl819xU_tx_cmd(struct net_device *dev, struct sk_buff *skb);
 short rtl8192_tx(struct net_device *dev, struct sk_buff *skb);
 
-u32 read_cam(struct net_device *dev, u8 addr);
-
 int read_nic_byte(struct net_device *dev, int x, u8 *data);
 int read_nic_byte_E(struct net_device *dev, int x, u8 *data);
 int read_nic_dword(struct net_device *dev, int x, u32 *data);
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index caa618a845df..12783b88eb58 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -237,15 +237,6 @@ static void CamResetAllEntry(struct net_device *dev)
write_nic_dword(dev, RWCAM, ulcommand);
 }
 
-u32 read_cam(struct net_device *dev, u8 addr)
-{
-   u32 data;
-
-   write_nic_dword(dev, RWCAM, 0x8000 | (addr & 0xff));
-   read_nic_dword(dev, 0xa8, &data);
-   return data;
-}
-
 int write_nic_byte_E(struct net_device *dev, int indx, u8 data)
 {
int status;
-- 
2.18.0



[PATCH 01/20] staging:rtl8192u: Remove write_cam() - Style

2018-08-31 Thread John Whitmore
Remove the function write_cam() as it is unused.

Simple style change which should not impact runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 1 -
 drivers/staging/rtl8192u/r8192U_core.c | 7 ---
 2 files changed, 8 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 1b51601df1ee..77324a471de1 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1092,7 +1092,6 @@ short rtl819xU_tx_cmd(struct net_device *dev, struct 
sk_buff *skb);
 short rtl8192_tx(struct net_device *dev, struct sk_buff *skb);
 
 u32 read_cam(struct net_device *dev, u8 addr);
-void write_cam(struct net_device *dev, u8 addr, u32 data);
 
 int read_nic_byte(struct net_device *dev, int x, u8 *data);
 int read_nic_byte_E(struct net_device *dev, int x, u8 *data);
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 6b22aaa40ff9..caa618a845df 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -237,13 +237,6 @@ static void CamResetAllEntry(struct net_device *dev)
write_nic_dword(dev, RWCAM, ulcommand);
 }
 
-
-void write_cam(struct net_device *dev, u8 addr, u32 data)
-{
-   write_nic_dword(dev, WCAMI, data);
-   write_nic_dword(dev, RWCAM, BIT(31) | BIT(16) | (addr & 0xff));
-}
-
 u32 read_cam(struct net_device *dev, u8 addr)
 {
u32 data;
-- 
2.18.0



[PATCH 12/20] staging:rtl8192u: Rename CCK_Table_length - Style

2018-08-31 Thread John Whitmore
Rename the constant CCK_Table_length to CCK_TABLE_LENGTH, this clears
the checkpatch issue with CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h|  2 +-
 drivers/staging/rtl8192u/r8192U_dm.c | 14 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 6edbc8146e82..e86a4b35a1f4 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -153,7 +153,7 @@ extern u32 rt_global_debug_component;
 #definePHY_BEACON_RSSI_SLID_WIN_MAX10
 /* For Tx Power Tracking */
 #defineOFDM_TABLE_LENGTH   19
-#defineCCK_Table_length12
+#defineCCK_TABLE_LENGTH12
 
 /* For rtl819x */
 struct tx_desc_819x_usb {
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 19b3b11c5edb..874da0620936 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -476,7 +476,7 @@ static u32 OFDMSwingTable[OFDM_TABLE_LENGTH] = {
0x1040  /* 18, -12db */
 };
 
-static u8  CCKSwingTable_Ch1_Ch13[CCK_Table_length][8] = {
+static u8  CCKSwingTable_Ch1_Ch13[CCK_TABLE_LENGTH][8] = {
{0x36, 0x35, 0x2e, 0x25, 0x1c, 0x12, 0x09, 0x04},   /* 0, +0db ===> 
CCK40M default */
{0x30, 0x2f, 0x29, 0x21, 0x19, 0x10, 0x08, 0x03},   /* 1, -1db */
{0x2b, 0x2a, 0x25, 0x1e, 0x16, 0x0e, 0x07, 0x03},   /* 2, -2db */
@@ -491,7 +491,7 @@ static u8   CCKSwingTable_Ch1_Ch13[CCK_Table_length][8] = {
{0x0f, 0x0f, 0x0d, 0x0b, 0x08, 0x05, 0x03, 0x01}/* 11, -11db */
 };
 
-static u8  CCKSwingTable_Ch14[CCK_Table_length][8] = {
+static u8  CCKSwingTable_Ch14[CCK_TABLE_LENGTH][8] = {
{0x36, 0x35, 0x2e, 0x1b, 0x00, 0x00, 0x00, 0x00},   /* 0, +0db  
===> CCK40M default */
{0x30, 0x2f, 0x29, 0x18, 0x00, 0x00, 0x00, 0x00},   /* 1, -1db */
{0x2b, 0x2a, 0x25, 0x15, 0x00, 0x00, 0x00, 0x00},   /* 2, -2db */
@@ -682,7 +682,7 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)
 
/* Query CCK default setting From 0xa22 */
TempCCk = rtl8192_QueryBBReg(dev, rCCK0_TxFilter1, bMaskByte2);
-   for (i = 0; i < CCK_Table_length; i++) {
+   for (i = 0; i < CCK_TABLE_LENGTH; i++) {
if (TempCCk == (u32)CCKSwingTable_Ch1_Ch13[i][0]) {
priv->CCK_index = (u8) i;
RT_TRACE(COMP_POWER_TRACKING, "Initial reg0x%x 
= 0x%x, CCK_index=0x%x\n",
@@ -718,10 +718,10 @@ static void 
dm_TXPowerTrackingCallback_ThermalMeter(struct net_device *dev)
tmpCCK40Mindex = tmpCCK20Mindex - 6;
if (tmpOFDMindex >= OFDM_TABLE_LENGTH)
tmpOFDMindex = OFDM_TABLE_LENGTH - 1;
-   if (tmpCCK20Mindex >= CCK_Table_length)
-   tmpCCK20Mindex = CCK_Table_length-1;
-   if (tmpCCK40Mindex >= CCK_Table_length)
-   tmpCCK40Mindex = CCK_Table_length-1;
+   if (tmpCCK20Mindex >= CCK_TABLE_LENGTH)
+   tmpCCK20Mindex = CCK_TABLE_LENGTH - 1;
+   if (tmpCCK40Mindex >= CCK_TABLE_LENGTH)
+   tmpCCK40Mindex = CCK_TABLE_LENGTH - 1;
} else {
tmpval = (u8)tmpRegA - priv->ThermalMeter[0];
 
-- 
2.18.0



[PATCH 16/20] staging:rtl8192u: Rename CmdInit - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'CmdInit, to 'cmd_init', this change
clears the checkpatch issue with CamelCase naming.

This is a simple coding style change which should have no impact on
runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 5d643870a1e3..4d29b7427a0e 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -161,7 +161,7 @@ struct tx_desc_819x_usb {
u16 pkt_size;
u8  offset;
u8  reserved0:3;
-   u8  CmdInit:1;
+   u8  cmd_init:1;
u8  LastSeg:1;
u8  FirstSeg:1;
u8  LINIP:1;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index d4af6cc01fc6..b385c686370b 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1515,7 +1515,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
memset(tx_desc, 0, sizeof(struct tx_desc_819x_usb));
/* DWORD 0 */
tx_desc->LINIP = 0;
-   tx_desc->CmdInit = 1;
+   tx_desc->cmd_init = 1;
tx_desc->offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
tx_desc->pkt_size = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
 
-- 
2.18.0



[PATCH 19/20] staging:rtl8192u: Rename LINIP - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'LINIP' to 'linip', this change is to
conform to the coding style guidelines, member variables in
lowercase.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 66efa59eabf0..68e82b32a88e 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -164,7 +164,7 @@ struct tx_desc_819x_usb {
u8  cmd_init:1;
u8  last_seg:1;
u8  first_seg:1;
-   u8  LINIP:1;
+   u8  linip:1;
u8  OWN:1;
 
/* DWORD 1 */
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index a4d1b55a1117..911d0214b48a 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1514,7 +1514,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
/* Fill Tx descriptor */
memset(tx_desc, 0, sizeof(struct tx_desc_819x_usb));
/* DWORD 0 */
-   tx_desc->LINIP = 0;
+   tx_desc->linip = 0;
tx_desc->cmd_init = 1;
tx_desc->offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
tx_desc->pkt_size = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
-- 
2.18.0



[PATCH 14/20] staging:rtl8192u: Rename Offset - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'Offset' to 'offset', this clears the
checkpatch issue with CamelCase naming.

This is a coding style change which should not impact runtime code
execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 9931ede1524b..8aaea1d8cf50 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -159,7 +159,7 @@ extern u32 rt_global_debug_component;
 struct tx_desc_819x_usb {
/* DWORD 0 */
u16 pkt_size;
-   u8  Offset;
+   u8  offset;
u8  Reserved0:3;
u8  CmdInit:1;
u8  LastSeg:1;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 2a3cb0f1ac07..d4af6cc01fc6 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1516,7 +1516,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
/* DWORD 0 */
tx_desc->LINIP = 0;
tx_desc->CmdInit = 1;
-   tx_desc->Offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
+   tx_desc->offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
tx_desc->pkt_size = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
 
/*DWORD 1*/
-- 
2.18.0



[PATCH 06/20] staging:rtl8192u: Rename Rx_Smooth_Factor - Style

2018-08-31 Thread John Whitmore
Rename the MACRO Rx_Smooth_Factor to RX_SMOOTH_FACTOR, this clears the
checkpatch issue with CamelCase naming.

This is a coding style change which should have no impact on runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  |  2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 20 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 81a7072a6285..b5ad69af8dac 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -45,7 +45,7 @@
 #define MAX_KEY_LEN 61
 #define KEY_BUF_SIZE5
 
-#defineRx_Smooth_Factor20
+#defineRX_SMOOTH_FACTOR20
 #define DMESG(x, a...)
 #define DMESGW(x, a...)
 #define DMESGE(x, a...)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index b3d32ea29fee..dd87cee6604b 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3975,13 +3975,13 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,

pprevious_stats->RxMIMOSignalStrength[rfpath];
if (pprevious_stats->RxMIMOSignalStrength[rfpath]  > 
priv->stats.rx_rssi_percentage[rfpath]) {
priv->stats.rx_rssi_percentage[rfpath] =
-   
((priv->stats.rx_rssi_percentage[rfpath] * (Rx_Smooth_Factor - 1)) +
-
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
+   
((priv->stats.rx_rssi_percentage[rfpath] * (RX_SMOOTH_FACTOR - 1)) +
+
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (RX_SMOOTH_FACTOR);
priv->stats.rx_rssi_percentage[rfpath] = 
priv->stats.rx_rssi_percentage[rfpath]  + 1;
} else {
priv->stats.rx_rssi_percentage[rfpath] =
-   
((priv->stats.rx_rssi_percentage[rfpath] * (Rx_Smooth_Factor - 1)) +
-
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
+   
((priv->stats.rx_rssi_percentage[rfpath] * (RX_SMOOTH_FACTOR - 1)) +
+
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (RX_SMOOTH_FACTOR);
}
RT_TRACE(COMP_DBG,
 "priv->stats.rx_rssi_percentage[rfPath]  = 
%d\n",
@@ -4026,13 +4026,13 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
pprevious_stats->RxPWDBAll;
if (pprevious_stats->RxPWDBAll > 
(u32)priv->undecorated_smoothed_pwdb) {
priv->undecorated_smoothed_pwdb =
-   (((priv->undecorated_smoothed_pwdb) * 
(Rx_Smooth_Factor - 1)) +
-(pprevious_stats->RxPWDBAll)) / 
(Rx_Smooth_Factor);
+   (((priv->undecorated_smoothed_pwdb) * 
(RX_SMOOTH_FACTOR - 1)) +
+(pprevious_stats->RxPWDBAll)) / 
(RX_SMOOTH_FACTOR);
priv->undecorated_smoothed_pwdb = 
priv->undecorated_smoothed_pwdb + 1;
} else {
priv->undecorated_smoothed_pwdb =
-   (((priv->undecorated_smoothed_pwdb) * 
(Rx_Smooth_Factor - 1)) +
-(pprevious_stats->RxPWDBAll)) / 
(Rx_Smooth_Factor);
+   (((priv->undecorated_smoothed_pwdb) * 
(RX_SMOOTH_FACTOR - 1)) +
+(pprevious_stats->RxPWDBAll)) / 
(RX_SMOOTH_FACTOR);
}
}
 
@@ -4075,8 +4075,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
if 
(priv->stats.rx_evm_percentage[nspatial_stream] == 0) /* initialize */

priv->stats.rx_evm_percentage[nspatial_stream] = 
pprevious_stats->RxMIMOSignalQuality[nspatial_stream];

priv->stats.rx_evm_percentage[nspatial_stream] =
-   
((priv->stats.rx_evm_percentage[nspatial_stream] * (Rx_Smooth_Factor - 1)) +
-
(pprevious_stats->RxMIMOSignalQuality[nspatial_stream] * 1)) / 
(Rx_Smooth_Factor);
+   
((priv->stats.rx_evm_percentage[nspatial_stream] * (RX_SMOOTH_FACTOR - 1)) +
+
(pprevious_stats->RxMIMOSignalQuality[nspatial_stream] * 1)) / 
(RX_SMOOTH_FACTOR);
}

[PATCH 04/20] staging:rtl8192u: Add SPDX-License-Identifier - Style

2018-08-31 Thread John Whitmore
Add SPDX-License-Identifier tag to the start of header file. This is
a coding style change which should have no impact on runtime code
execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index b3e6ce2acedb..4dcfcb4d3911 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * This is part of rtl8187 OpenSource driver.
  * Copyright (C) Andrea Merello 2004-2005  
-- 
2.18.0



[PATCH 11/20] staging:rtl8192u: Rename OFDM_Table_Length - Style

2018-08-31 Thread John Whitmore
Rename the defined constant OFDM_Table_Length to OFDM_TABLE_LENGTH,
this clears the checkpatch issue with CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h| 2 +-
 drivers/staging/rtl8192u/r8192U_dm.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 87c1a69b2e1c..6edbc8146e82 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -152,7 +152,7 @@ extern u32 rt_global_debug_component;
 #define IEEE80211_WATCH_DOG_TIME2000
 #definePHY_BEACON_RSSI_SLID_WIN_MAX10
 /* For Tx Power Tracking */
-#defineOFDM_Table_Length   19
+#defineOFDM_TABLE_LENGTH   19
 #defineCCK_Table_length12
 
 /* For rtl819x */
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 5fb5f583f703..19b3b11c5edb 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -454,7 +454,7 @@ static void dm_bandwidth_autoswitch(struct net_device *dev)
 }  /* dm_BandwidthAutoSwitch */
 
 /* OFDM default at 0db, index=6. */
-static u32 OFDMSwingTable[OFDM_Table_Length] = {
+static u32 OFDMSwingTable[OFDM_TABLE_LENGTH] = {
0x7f8001fe, /* 0, +6db */
0x71c001c7, /* 1, +5db */
0x65400195, /* 2, +4db */
@@ -672,7 +672,7 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)
if (!priv->btxpower_trackingInit) {
/* Query OFDM default setting */
tmpRegA = rtl8192_QueryBBReg(dev, rOFDM0_XATxIQImbalance, 
bMaskDWord);
-   for (i = 0; i < OFDM_Table_Length; i++) { /* find the index */
+   for (i = 0; i < OFDM_TABLE_LENGTH; i++) { /* find the index */
if (tmpRegA == OFDMSwingTable[i]) {
priv->OFDM_index = (u8)i;
RT_TRACE(COMP_POWER_TRACKING, "Initial reg0x%x 
= 0x%x, OFDM_index=0x%x\n",
@@ -716,8 +716,8 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)
if (priv->ThermalMeter[0] >= (u8)tmpRegA) { /* lower temperature */
tmpOFDMindex = tmpCCK20Mindex = 
6+(priv->ThermalMeter[0]-(u8)tmpRegA);
tmpCCK40Mindex = tmpCCK20Mindex - 6;
-   if (tmpOFDMindex >= OFDM_Table_Length)
-   tmpOFDMindex = OFDM_Table_Length-1;
+   if (tmpOFDMindex >= OFDM_TABLE_LENGTH)
+   tmpOFDMindex = OFDM_TABLE_LENGTH - 1;
if (tmpCCK20Mindex >= CCK_Table_length)
tmpCCK20Mindex = CCK_Table_length-1;
if (tmpCCK40Mindex >= CCK_Table_length)
-- 
2.18.0



[PATCH 00/20] staging:rtl8192u: r8192U.h cleanup - Style

2018-08-31 Thread John Whitmore
Yet another series of patchs to cleanup and clear some checkpatch
isses, this time the file r8192U.h. These are all simple changes
which are mostly renaming variables. A MACRO has been removed as
it's not used in the code, and added SPDX-License-Identifier.

John Whitmore (20):
  staging:rtl8192u: Remove write_cam() - Style
  staging:rtl8192u: Remove read_cam() - Style
  staging:rtl8192u: Remove unused functions - Style
  staging:rtl8192u: Add SPDX-License-Identifier - Style
  staging:rtl8192u: Rename RTL819xU_MODULE_NAME - Style
  staging:rtl8192u: Rename Rx_Smooth_Factor - Style
  staging:rtl8192u: Refactor RT_TRACE - Style
  staging:rtl8192u: Fix space characters - Style
  staging:rtl8192u: Remove RT_DEBUG_DATA - Style
  staging:rtl8192u: Rename PHY_Beacon_RSSI_SLID_WIN_MAX - Style
  staging:rtl8192u: Rename OFDM_Table_Length - Style
  staging:rtl8192u: Rename CCK_Table_length - Style
  staging:rtl8192u: Rename PktSize Style
  staging:rtl8192u: Rename Offset - Style
  staging:rtl8192u: Rename Reserved... structure members - Style
  staging:rtl8192u: Rename CmdInit - Style
  staging:rtl8192u: Rename LastSeg - Style
  staging:rtl8192u: Rename FirstSeg - Style
  staging:rtl8192u: Rename LINIP - Style
  staging:rtl8192u: Rename OWN - Style

 drivers/staging/rtl8192u/r8192U.h  | 82 --
 drivers/staging/rtl8192u/r8192U_core.c | 67 +++--
 drivers/staging/rtl8192u/r8192U_dm.c   | 22 +++
 3 files changed, 58 insertions(+), 113 deletions(-)

-- 
2.18.0



[PATCH 08/20] staging:rtl8192u: Fix space characters - Style

2018-08-31 Thread John Whitmore
Fix the spacing issues, remove space after cast operation, and replace
spaces at start of line with tab.

These changes are purely coding style changes to resolve checkpatch
issues. There should be no impact on runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index c613894a6088..e65a893fd084 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -112,7 +112,7 @@ extern u32 rt_global_debug_component;
do {\
if ((rt_global_debug_component & (level)) == (level)) { \
int i;  \
-   u8 *pdata = (u8 *) data;\
+   u8 *pdata = (u8 *)data; \
pr_debug("RTL8192U: %s()\n", __func__); \
for (i = 0; i < (int)(datalen); i++) {  \
printk("%2x ", pdata[i]);   \
@@ -877,9 +877,9 @@ typedef struct r8192_priv {
int rx_inx;
 #endif
 
-   struct sk_buff_head rx_queue;
-   struct sk_buff_head skb_queue;
-   struct work_struct qos_activate;
+   struct sk_buff_head rx_queue;
+   struct sk_buff_head skb_queue;
+   struct work_struct qos_activate;
short  tx_urb_index;
atomic_t tx_pending[0x10]; /* UART_PRIORITY + 1 */
 
@@ -1027,7 +1027,7 @@ typedef struct r8192_priv {
u8  nrxAMPDU_aggr_num;
 
/* For gpio */
-bool bHwRadioOff;
+   bool bHwRadioOff;
 
u32 reset_count;
bool bpbc_pressed;
-- 
2.18.0



[PATCH 10/20] staging:rtl8192u: Rename PHY_Beacon_RSSI_SLID_WIN_MAX - Style

2018-08-31 Thread John Whitmore
Rename the Macro PHY_Beacon_RSSI_SLID_WIN_MAX to
PHY_BEACON_RSSI_SLID_WIN_MAX, this clears the checkpatch issue with
CamelCase naming.

This is purely a coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 528c50be3894..87c1a69b2e1c 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -150,7 +150,7 @@ extern u32 rt_global_debug_component;
 #define RTL819X_DEFAULT_RF_TYPE RF_1T2R
 
 #define IEEE80211_WATCH_DOG_TIME2000
-#definePHY_Beacon_RSSI_SLID_WIN_MAX10
+#definePHY_BEACON_RSSI_SLID_WIN_MAX10
 /* For Tx Power Tracking */
 #defineOFDM_Table_Length   19
 #defineCCK_Table_length12
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index dd87cee6604b..4d43176bdb6c 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3997,15 +3997,15 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
 
if (pprevious_stats->bPacketBeacon) {
/* record the beacon pwdb to the sliding window. */
-   if (slide_beacon_adc_pwdb_statistics++ >= 
PHY_Beacon_RSSI_SLID_WIN_MAX) {
-   slide_beacon_adc_pwdb_statistics = 
PHY_Beacon_RSSI_SLID_WIN_MAX;
+   if (slide_beacon_adc_pwdb_statistics++ >= 
PHY_BEACON_RSSI_SLID_WIN_MAX) {
+   slide_beacon_adc_pwdb_statistics = 
PHY_BEACON_RSSI_SLID_WIN_MAX;
last_beacon_adc_pwdb = 
priv->stats.Slide_Beacon_pwdb[slide_beacon_adc_pwdb_index];
priv->stats.Slide_Beacon_Total -= last_beacon_adc_pwdb;
}
priv->stats.Slide_Beacon_Total += pprevious_stats->RxPWDBAll;
priv->stats.Slide_Beacon_pwdb[slide_beacon_adc_pwdb_index] = 
pprevious_stats->RxPWDBAll;
slide_beacon_adc_pwdb_index++;
-   if (slide_beacon_adc_pwdb_index >= PHY_Beacon_RSSI_SLID_WIN_MAX)
+   if (slide_beacon_adc_pwdb_index >= PHY_BEACON_RSSI_SLID_WIN_MAX)
slide_beacon_adc_pwdb_index = 0;
pprevious_stats->RxPWDBAll = priv->stats.Slide_Beacon_Total / 
slide_beacon_adc_pwdb_statistics;
if (pprevious_stats->RxPWDBAll >= 3)
-- 
2.18.0



[PATCH 13/20] staging:rtl8192u: Rename PktSize Style

2018-08-31 Thread John Whitmore
Rename the member variable 'PktSize' to 'pkt_size', this change
clears the checkpatch issue with CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index e86a4b35a1f4..9931ede1524b 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -158,7 +158,7 @@ extern u32 rt_global_debug_component;
 /* For rtl819x */
 struct tx_desc_819x_usb {
/* DWORD 0 */
-   u16 PktSize;
+   u16 pkt_size;
u8  Offset;
u8  Reserved0:3;
u8  CmdInit:1;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 4d43176bdb6c..2a3cb0f1ac07 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1517,7 +1517,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
tx_desc->LINIP = 0;
tx_desc->CmdInit = 1;
tx_desc->Offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
-   tx_desc->PktSize = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
+   tx_desc->pkt_size = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
 
/*DWORD 1*/
tx_desc->SecCAMID = 0;
-- 
2.18.0



[PATCH 17/20] staging:rtl8192u: Rename LastSeg - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'LastSeg' to 'last_seg', this change
clears the checkpatch issue with CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 4d29b7427a0e..672cbfa688f7 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -162,7 +162,7 @@ struct tx_desc_819x_usb {
u8  offset;
u8  reserved0:3;
u8  cmd_init:1;
-   u8  LastSeg:1;
+   u8  last_seg:1;
u8  FirstSeg:1;
u8  LINIP:1;
u8  OWN:1;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index b385c686370b..dfbba1177470 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1557,7 +1557,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
 */
/* DWORD 0 */
tx_desc->FirstSeg = 1;
-   tx_desc->LastSeg = 1;
+   tx_desc->last_seg = 1;
tx_desc->OWN = 1;
 
/* DWORD 2 */
-- 
2.18.0



[PATCH 18/20] staging:rtl8192u: Rename FirstSeg - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'FirstSeg' to 'first_seg', this change
clears the checkpatch issue with CamelCase naming.

This is a simple coding style change and as such should not impact
runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 672cbfa688f7..66efa59eabf0 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -163,7 +163,7 @@ struct tx_desc_819x_usb {
u8  reserved0:3;
u8  cmd_init:1;
u8  last_seg:1;
-   u8  FirstSeg:1;
+   u8  first_seg:1;
u8  LINIP:1;
u8  OWN:1;
 
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index dfbba1177470..a4d1b55a1117 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1556,7 +1556,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
 * all of the descriptors
 */
/* DWORD 0 */
-   tx_desc->FirstSeg = 1;
+   tx_desc->first_seg = 1;
tx_desc->last_seg = 1;
tx_desc->OWN = 1;
 
-- 
2.18.0



[PATCH 15/20] staging:rtl8192u: Rename Reserved... structure members - Style

2018-08-31 Thread John Whitmore
Rename the 'Reserved...' members of the 'tx_desc_819x_usb' structure
to 'reserved...'. This change clears the checkpatch issue with
CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 8aaea1d8cf50..5d643870a1e3 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -160,7 +160,7 @@ struct tx_desc_819x_usb {
/* DWORD 0 */
u16 pkt_size;
u8  offset;
-   u8  Reserved0:3;
+   u8  reserved0:3;
u8  CmdInit:1;
u8  LastSeg:1;
u8  FirstSeg:1;
@@ -177,7 +177,7 @@ struct tx_desc_819x_usb {
u8  PIFS:1;
u8  QueueSelect:5;
u8  NoACM:1;
-   u8  Reserved1:2;
+   u8  reserved1:2;
u8  SecCAMID:5;
u8  SecDescAssign:1;
u8  SecType:2;
@@ -185,13 +185,13 @@ struct tx_desc_819x_usb {
/* DWORD 2 */
u16 TxBufferSize;
u8  ResvForPaddingLen:7;
-   u8  Reserved3:1;
-   u8  Reserved4;
+   u8  reserved3:1;
+   u8  reserved4;
 
/* DWORD 3, 4, 5 */
-   u32 Reserved5;
-   u32 Reserved6;
-   u32 Reserved7;
+   u32 reserved5;
+   u32 reserved6;
+   u32 reserved7;
 };
 
 struct tx_desc_cmd_819x_usb {
-- 
2.18.0



Re: [PATCH 1/3] ARM: dts: qcom: Add SPMI PMIC Arbiter nodes for APQ8084 and MSM8974

2018-08-31 Thread Bjorn Andersson
On Fri 31 Aug 15:46 PDT 2018, Frank Rowand wrote:
> > +   spmi_bus: spmi@fc4cf000 {
> > +   compatible = "qcom,spmi-pmic-arb";
> > +   reg-names = "core", "intr", "cnfg";
> > +   reg = <0xfc4cf000 0x1000>,
> > + <0xfc4cb000 0x1000>,
> > + <0xfc4ca000 0x1000>;
> > +   interrupt-names = "periph_irq";
> 
> > +   interrupts = <0 190 0>;
> 
> The final value in this interrupts property means IRQ_TYPE_NONE.
> 
> A WARN_ON() was added early this year to complain about use of
> IRQ_TYPE_NONE: 83a86fbb5b56 "irqchip/gic: Loudly complain about
> the use of IRQ_TYPE_NONE", resulting in many warnings spewing
> forth when I boot an APQ8074 Dragonboard.  I am trying to
> determine whether the warning is overly aggressive, or whether
> the IRQ TYPE is incorrectly specified for the spmi node.
> 
> The interrupt-parent for the spmi node is intc: interrupt-controller@f900,
> which has compatible = "qcom,msm-qgic2".  I do not know the architecture
> or implementation of this interrupt controller.  Is an IRQ_TYPE_NONE
> valid in this case, or should a specific type be provided?
> 

No, IRQ_TYPE_NONE isn't valid and the WARN_ON() is reasonable.

Please change it to IRQ_TYPE_LEVEL_HIGH. And while you're at it, replace
the first 0 with GIC_SPI.


If you have more of these warnings you can most likely look at e.g.
msm8916 (arm64) to find the right flags.

Regards,
Bjorn


Re: VirtIO console hangs

2018-08-31 Thread Nicholas Piggin
On Fri, 31 Aug 2018 15:17:44 +
Matteo Croce  wrote:

> On Fri, Aug 31, 2018 at 3:49 AM Nicholas Piggin  wrote:
> >
> > On Tue, 28 Aug 2018 15:00:14 +
> > Matteo Croce  wrote:
> >  
> > > On Tue, Aug 28, 2018 at 2:35 PM Nicholas Piggin  
> > > wrote:  
> > > >
> > > > On Tue, 28 Aug 2018 12:54:08 +
> > > > Matteo Croce  wrote:
> > > >  
> > > > > With kernel 4.19.0-rc1 virtio_console hangs very often.
> > > > > I can always trigger the bug by pasting some characters in the
> > > > > terminal window, the console will stop receiving keypresses, but I can
> > > > > still see output from the console.
> > > > > Stangely, logging in the VM via SSH and sending lot of data to hvc0,
> > > > > like 'dmesg >/dev/hvc0' will fix the issue until the next paste.
> > > > >
> > > > > I did a git bisect and I've found that this is the offending commit,
> > > > > reverting it fixes it.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > commit ec97eaad1383ab2500fcf9a07ade6044fbcc67f5
> > > > > Author: Nicholas Piggin 
> > > > > Date:   Tue May 1 00:55:54 2018 +1000
> > > > >
> > > > > tty: hvc: hvc_poll() break hv read loop  
> > > >
> > > > Thanks for the report. I can't immediately see what the problem
> > > > is. Can you try get a stack trace of where it is stuck?
> > > >  
> > >
> > > I tried but didn't get one.
> > >  
> > > > Perhaps try this patch if you have time (it's a bit of a shot
> > > > in the dark).
> > > >  
> > >
> > > Yes it seems to fix. Thanks!  
> >
> > Okay sorry for the delay, I can reproduce it here and found a better
> > fix, if I could trouble you to test again.
> >
> > [PATCH] tty: hvc: hvc_poll() fix read loop hang
> >  
> 
> Hi Nicholas,
> 
> the patch works, but now pasting text inside the terminal is extremely
> slow, it feels worse than a 9600 baud serial line.
> 
> Btw, I had to apply the patch by hand as it was corrupted, some lines
> were collapsed into one.

Oh, when you revert the above commit, does it fix the speed problem as
well? I realise I'm testing with a remote machine that probably is not
connected with much better than 9600 baud... I will set up a local test.

Thanks,
Nick


Re: Make perf script easier to use for itrace

2018-08-31 Thread Kim Phillips
On Fri, 31 Aug 2018 15:01:56 -0700
Andi Kleen  wrote:

> Also available in
> git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git 
> pt/easy-script-2
> 
> v1: Initial post
> v2: Address review comments. Minor fixes to descriptions. Now builds 
> everywhere.

OK, I grabbed the pt/easy-script-2 branch (commit 4c69fd388e17), and
see build failures for a 'make -C perf' build using gcc version 7.3.0
(Ubuntu 18.04):

builtin-script.c: In function ‘parse_output_fields’:
builtin-script.c:2571:22: error: array subscript is above array bounds 
[-Werror=array-bounds]
 output[j].fields &= ~all_output_options[i].field;
  ^~
builtin-script.c:2571:22: error: array subscript is above array bounds 
[-Werror=array-bounds]
 output[j].fields &= ~all_output_options[i].field;
 ~^~~
builtin-script.c:2574:10: error: array subscript is above array bounds 
[-Werror=array-bounds]
output[j].user_set = true;
~~^~~
builtin-script.c:2575:10: error: array subscript is above array bounds 
[-Werror=array-bounds]
output[j].wildcard_set = true;
~~^~~
...
util/cs-etm.c: In function ‘cs_etm__process_auxtrace_info’:
util/cs-etm.c:1436:14: error: ‘struct perf_session’ has no member named 
‘itrace_synth’; did you mean ‘itrace_synth_opts’?
 session->itrace_synth.default_no_sample);
  ^~~~
  itrace_synth_opts

Thanks,

Kim

p.s. FWIW, my make VF=1 output:

Auto-detecting system features:
... dwarf: [ on  ]
...dwarf_getlocations: [ on  ]
... glibc: [ on  ]
...  gtk2: [ on  ]
...  libaudit: [ on  ]
...libbfd: [ on  ]
...libelf: [ on  ]
...   libnuma: [ on  ]
...numa_num_possible_cpus: [ on  ]
...   libperl: [ on  ]
... libpython: [ on  ]
...  libslang: [ on  ]
... libcrypto: [ on  ]
... libunwind: [ on  ]
...libdw-dwarf-unwind: [ on  ]
...  zlib: [ on  ]
...  lzma: [ on  ]
... get_cpuid: [ on  ]
...   bpf: [ on  ]
... backtrace: [ on  ]
...fortify-source: [ on  ]
... sync-compare-and-swap: [ on  ]
...  gtk2-infobar: [ on  ]
... libelf-getphdrnum: [ on  ]
...   libelf-gelf_getnote: [ on  ]
...  libelf-getshdrstrndx: [ on  ]
...   libelf-mmap: [ on  ]
... libpython-version: [ on  ]
... libunwind-x86: [ OFF ]
...  libunwind-x86_64: [ on  ]
... libunwind-arm: [ OFF ]
... libunwind-aarch64: [ OFF ]
...   pthread-attr-setaffinity-np: [ on  ]
...   pthread-barrier: [ on  ]
...stackprotector-all: [ on  ]
...   timerfd: [ on  ]
...  sched_getcpu: [ on  ]
...   sdt: [ on  ]
... setns: [ on  ]
...libopencsd: [ on  ]

...bionic: [ OFF ]
...compile-32: [ OFF ]
...   compile-x32: [ OFF ]
...cplus-demangle: [ on  ]
... hello: [ OFF ]
... libbabeltrace: [ on  ]
...   liberty: [ on  ]
... liberty-z: [ on  ]
... libunwind-debug-frame: [ OFF ]
... libunwind-debug-frame-arm: [ OFF ]
... libunwind-debug-frame-aarch64: [ OFF ]
...   cxx: [ OFF ]
...  llvm: [ OFF ]
...  llvm-version: [ OFF ]
... clang: [ OFF ]
...prefix: /home/kim
...bindir: /home/kim/bin
...libdir: /home/kim/lib64
...sysconfdir: /home/kim/etc
... LIBUNWIND_DIR: 
... LIBDW_DIR: 
...  JDIR: /usr/lib/jvm/java-1.8.0-openjdk-amd64
... DWARF post unwind library: libunwind



[PATCH v2] PCI: qcom: Fix error handling in pm_runtime support

2018-08-31 Thread Bjorn Andersson
The driver does not cope with the fact that probe can fail in a number
of cases after enabling pm_runtime on the device, this results in
warnings about "Unbalanced pm_runtime_enable". Further more if probe
fails after invoking host_init the power-domain will be left referenced.

As it's not possible for the error handling in qcom_pcie_host_init() to
handle errors happening after returning from that function the
pm_runtime_get_sync() is moved to probe() as well.

Fixes: 854b69efbdd2 ("PCI: qcom: add runtime pm support to pcie_port")
Acked-by: Stanimir Varbanov 
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Dropped remove function, as this can't be called
- Handle pm_runtime_get_sync() errors
- Add "Fixes" tag

 drivers/pci/controller/dwc/pcie-qcom.c | 56 ++
 1 file changed, 39 insertions(+), 17 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c 
b/drivers/pci/controller/dwc/pcie-qcom.c
index d2373e4d141c..3bfaad052736 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1117,7 +1117,6 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
struct qcom_pcie *pcie = to_qcom_pcie(pci);
int ret;
 
-   pm_runtime_get_sync(pci->dev);
qcom_ep_reset_assert(pcie);
 
ret = pcie->ops->init(pcie);
@@ -1154,7 +1153,6 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
phy_power_off(pcie->phy);
 err_deinit:
pcie->ops->deinit(pcie);
-   pm_runtime_put(pci->dev);
 
return ret;
 }
@@ -1244,6 +1242,12 @@ static int qcom_pcie_probe(struct platform_device *pdev)
return -ENOMEM;
 
pm_runtime_enable(dev);
+   ret = pm_runtime_get_sync(dev);
+   if (ret < 0) {
+   pm_runtime_disable(dev);
+   return ret;
+   }
+
pci->dev = dev;
pci->ops = &dw_pcie_ops;
pp = &pci->pp;
@@ -1253,44 +1257,56 @@ static int qcom_pcie_probe(struct platform_device *pdev)
pcie->ops = of_device_get_match_data(dev);
 
pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW);
-   if (IS_ERR(pcie->reset))
-   return PTR_ERR(pcie->reset);
+   if (IS_ERR(pcie->reset)) {
+   ret = PTR_ERR(pcie->reset);
+   goto err_pm_runtime_put;
+   }
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "parf");
pcie->parf = devm_ioremap_resource(dev, res);
-   if (IS_ERR(pcie->parf))
-   return PTR_ERR(pcie->parf);
+   if (IS_ERR(pcie->parf)) {
+   ret = PTR_ERR(pcie->parf);
+   goto err_pm_runtime_put;
+   }
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
pci->dbi_base = devm_pci_remap_cfg_resource(dev, res);
-   if (IS_ERR(pci->dbi_base))
-   return PTR_ERR(pci->dbi_base);
+   if (IS_ERR(pci->dbi_base)) {
+   ret = PTR_ERR(pci->dbi_base);
+   goto err_pm_runtime_put;
+   }
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "elbi");
pcie->elbi = devm_ioremap_resource(dev, res);
-   if (IS_ERR(pcie->elbi))
-   return PTR_ERR(pcie->elbi);
+   if (IS_ERR(pcie->elbi)) {
+   ret = PTR_ERR(pcie->elbi);
+   goto err_pm_runtime_put;
+   }
 
pcie->phy = devm_phy_optional_get(dev, "pciephy");
-   if (IS_ERR(pcie->phy))
-   return PTR_ERR(pcie->phy);
+   if (IS_ERR(pcie->phy)) {
+   ret = PTR_ERR(pcie->phy);
+   goto err_pm_runtime_put;
+   }
 
ret = pcie->ops->get_resources(pcie);
if (ret)
-   return ret;
+   goto err_pm_runtime_put;
 
pp->ops = &qcom_pcie_dw_ops;
 
if (IS_ENABLED(CONFIG_PCI_MSI)) {
pp->msi_irq = platform_get_irq_byname(pdev, "msi");
-   if (pp->msi_irq < 0)
-   return pp->msi_irq;
+   if (pp->msi_irq < 0) {
+   ret = pp->msi_irq;
+   goto err_pm_runtime_put;
+   }
}
 
ret = phy_init(pcie->phy);
if (ret) {
pm_runtime_disable(&pdev->dev);
-   return ret;
+   goto err_pm_runtime_put;
}
 
platform_set_drvdata(pdev, pcie);
@@ -1299,10 +1315,16 @@ static int qcom_pcie_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, "cannot initialize host\n");
pm_runtime_disable(&pdev->dev);
-   return ret;
+   goto err_pm_runtime_put;
}
 
return 0;
+
+err_pm_runtime_put:
+   pm_runtime_put(dev);
+   pm_runtime_disable(dev);
+
+   return ret;
 }
 
 static const struct of_device_id qcom_pcie_match[] = {
-- 
2.18.0



Re: VirtIO console hangs

2018-08-31 Thread Nicholas Piggin
On Fri, 31 Aug 2018 15:17:44 +
Matteo Croce  wrote:

> On Fri, Aug 31, 2018 at 3:49 AM Nicholas Piggin  wrote:
> >
> > On Tue, 28 Aug 2018 15:00:14 +
> > Matteo Croce  wrote:
> >  
> > > On Tue, Aug 28, 2018 at 2:35 PM Nicholas Piggin  
> > > wrote:  
> > > >
> > > > On Tue, 28 Aug 2018 12:54:08 +
> > > > Matteo Croce  wrote:
> > > >  
> > > > > With kernel 4.19.0-rc1 virtio_console hangs very often.
> > > > > I can always trigger the bug by pasting some characters in the
> > > > > terminal window, the console will stop receiving keypresses, but I can
> > > > > still see output from the console.
> > > > > Stangely, logging in the VM via SSH and sending lot of data to hvc0,
> > > > > like 'dmesg >/dev/hvc0' will fix the issue until the next paste.
> > > > >
> > > > > I did a git bisect and I've found that this is the offending commit,
> > > > > reverting it fixes it.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > commit ec97eaad1383ab2500fcf9a07ade6044fbcc67f5
> > > > > Author: Nicholas Piggin 
> > > > > Date:   Tue May 1 00:55:54 2018 +1000
> > > > >
> > > > > tty: hvc: hvc_poll() break hv read loop  
> > > >
> > > > Thanks for the report. I can't immediately see what the problem
> > > > is. Can you try get a stack trace of where it is stuck?
> > > >  
> > >
> > > I tried but didn't get one.
> > >  
> > > > Perhaps try this patch if you have time (it's a bit of a shot
> > > > in the dark).
> > > >  
> > >
> > > Yes it seems to fix. Thanks!  
> >
> > Okay sorry for the delay, I can reproduce it here and found a better
> > fix, if I could trouble you to test again.
> >
> > [PATCH] tty: hvc: hvc_poll() fix read loop hang
> >  
> 
> Hi Nicholas,
> 
> the patch works, but now pasting text inside the terminal is extremely
> slow, it feels worse than a 9600 baud serial line.
> 
> Btw, I had to apply the patch by hand as it was corrupted, some lines
> were collapsed into one.

Okay I didn't test a very big paste, I'll work on it.

Thanks,
Nick


Re: [PATCH 1/3] ARM: dts: qcom: Add SPMI PMIC Arbiter nodes for APQ8084 and MSM8974

2018-08-31 Thread Frank Rowand
Hi All,

The email for Ivan is no longer valid.  Can anyone else help me with
my question?

Thanks,

Frank


On 08/31/18 15:46, Frank Rowand wrote:
> Hi Ivan,
> 
> 
> On 02/03/15 04:17, Ivan T. Ivanov wrote:
>> Add SPMI PMIC Arbiter configuration nodes for APQ8084 and MSM8974.
>>
>> Signed-off-by: Ivan T. Ivanov 
>> ---
>>  arch/arm/boot/dts/qcom-apq8084.dtsi | 16 
>>  arch/arm/boot/dts/qcom-msm8974.dtsi | 16 
>>  2 files changed, 32 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
>> b/arch/arm/boot/dts/qcom-apq8084.dtsi
>> index 1f130bc..dbedf64 100644
>> --- a/arch/arm/boot/dts/qcom-apq8084.dtsi
>> +++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
>> @@ -226,5 +226,21 @@
>>  clock-names = "core", "iface";
>>  status = "disabled";
>>  };
>> +
>> +spmi_bus: spmi@fc4cf000 {
>> +compatible = "qcom,spmi-pmic-arb";
>> +reg-names = "core", "intr", "cnfg";
>> +reg = <0xfc4cf000 0x1000>,
>> +  <0xfc4cb000 0x1000>,
>> +  <0xfc4ca000 0x1000>;
>> +interrupt-names = "periph_irq";
>> +interrupts = <0 190 0>;> +  qcom,ee 
>> = <0>;
>> +qcom,channel = <0>;
>> +#address-cells = <2>;
>> +#size-cells = <0>;
>> +interrupt-controller;
>> +#interrupt-cells = <4>;
>> +};
>>  };
>>  };
>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
>> b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> index e265ec1..2d11641 100644
>> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> @@ -247,5 +247,21 @@
>>  #address-cells = <1>;
>>  #size-cells = <0>;
>>  };
>> +
>> +spmi_bus: spmi@fc4cf000 {
>> +compatible = "qcom,spmi-pmic-arb";
>> +reg-names = "core", "intr", "cnfg";
>> +reg = <0xfc4cf000 0x1000>,
>> +  <0xfc4cb000 0x1000>,
>> +  <0xfc4ca000 0x1000>;
>> +interrupt-names = "periph_irq";
> 
>> +interrupts = <0 190 0>;
> 
> The final value in this interrupts property means IRQ_TYPE_NONE.
> 
> A WARN_ON() was added early this year to complain about use of
> IRQ_TYPE_NONE: 83a86fbb5b56 "irqchip/gic: Loudly complain about
> the use of IRQ_TYPE_NONE", resulting in many warnings spewing
> forth when I boot an APQ8074 Dragonboard.  I am trying to
> determine whether the warning is overly aggressive, or whether
> the IRQ TYPE is incorrectly specified for the spmi node.
> 
> The interrupt-parent for the spmi node is intc: interrupt-controller@f900,
> which has compatible = "qcom,msm-qgic2".  I do not know the architecture
> or implementation of this interrupt controller.  Is an IRQ_TYPE_NONE
> valid in this case, or should a specific type be provided?
> 
> Thanks!
> 
> -Frank
> 
> 
>> +qcom,ee = <0>;
>> +qcom,channel = <0>;
>> +#address-cells = <2>;
>> +#size-cells = <0>;
>> +interrupt-controller;
>> +#interrupt-cells = <4>;
>> +};
>>  };
>>  };
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> .
> 



Re: [PATCH 1/3] ARM: dts: qcom: Add SPMI PMIC Arbiter nodes for APQ8084 and MSM8974

2018-08-31 Thread Frank Rowand
Hi Ivan,


On 02/03/15 04:17, Ivan T. Ivanov wrote:
> Add SPMI PMIC Arbiter configuration nodes for APQ8084 and MSM8974.
> 
> Signed-off-by: Ivan T. Ivanov 
> ---
>  arch/arm/boot/dts/qcom-apq8084.dtsi | 16 
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 16 
>  2 files changed, 32 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
> b/arch/arm/boot/dts/qcom-apq8084.dtsi
> index 1f130bc..dbedf64 100644
> --- a/arch/arm/boot/dts/qcom-apq8084.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
> @@ -226,5 +226,21 @@
>   clock-names = "core", "iface";
>   status = "disabled";
>   };
> +
> + spmi_bus: spmi@fc4cf000 {
> + compatible = "qcom,spmi-pmic-arb";
> + reg-names = "core", "intr", "cnfg";
> + reg = <0xfc4cf000 0x1000>,
> +   <0xfc4cb000 0x1000>,
> +   <0xfc4ca000 0x1000>;
> + interrupt-names = "periph_irq";
> + interrupts = <0 190 0>;> +  qcom,ee 
> = <0>;
> + qcom,channel = <0>;
> + #address-cells = <2>;
> + #size-cells = <0>;
> + interrupt-controller;
> + #interrupt-cells = <4>;
> + };
>   };
>  };
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index e265ec1..2d11641 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -247,5 +247,21 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   };
> +
> + spmi_bus: spmi@fc4cf000 {
> + compatible = "qcom,spmi-pmic-arb";
> + reg-names = "core", "intr", "cnfg";
> + reg = <0xfc4cf000 0x1000>,
> +   <0xfc4cb000 0x1000>,
> +   <0xfc4ca000 0x1000>;
> + interrupt-names = "periph_irq";

> + interrupts = <0 190 0>;

The final value in this interrupts property means IRQ_TYPE_NONE.

A WARN_ON() was added early this year to complain about use of
IRQ_TYPE_NONE: 83a86fbb5b56 "irqchip/gic: Loudly complain about
the use of IRQ_TYPE_NONE", resulting in many warnings spewing
forth when I boot an APQ8074 Dragonboard.  I am trying to
determine whether the warning is overly aggressive, or whether
the IRQ TYPE is incorrectly specified for the spmi node.

The interrupt-parent for the spmi node is intc: interrupt-controller@f900,
which has compatible = "qcom,msm-qgic2".  I do not know the architecture
or implementation of this interrupt controller.  Is an IRQ_TYPE_NONE
valid in this case, or should a specific type be provided?

Thanks!

-Frank


> + qcom,ee = <0>;
> + qcom,channel = <0>;
> + #address-cells = <2>;
> + #size-cells = <0>;
> + interrupt-controller;
> + #interrupt-cells = <4>;
> + };
>   };
>  };
> --
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



[PATCH] sched/fair: fix vruntime_normalized for remote non-migration wakeup

2018-08-31 Thread Steve Muckle
When a task which previously ran on a given CPU is remotely queued to
wake up on that same CPU, there is a period where the task's state is
TASK_WAKING and its vruntime is not normalized. This is not accounted
for in vruntime_normalized() which will cause an
error in the task's vruntime if it is switched from the fair class
during this time, for example if it is boosted to RT priority via
rt_mutex_setprio. The rq's min_vruntime will not be subtracted from the
task's vruntime but it will be added again when the task returns to the
fair class. The task's vruntime will have been erroneously doubled and
the effective priority of the task will be reduced.

Note this will also lead to inflation of all vruntimes since the doubled
vruntime value will become the rq's min_vruntime when other tasks leave
the rq. This leads to repeated doubling of the vruntime and priority
penalty.

Fix this by recognizing a WAKING task's vruntime as normalized only if
sched_remote_wakeup is true. This indicates a migration, in which case
the vruntime would have been normalized in migrate_task_rq_fair().

Based on a similar patch from joaod...@google.com.

Suggested-by: Peter Zijlstra 
Signed-off-by: Steve Muckle 
---
 kernel/sched/fair.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b39fb596f6c1..b3b62cf37fb6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9638,7 +9638,8 @@ static inline bool vruntime_normalized(struct task_struct 
*p)
 * - A task which has been woken up by try_to_wake_up() and
 *   waiting for actually being woken up by sched_ttwu_pending().
 */
-   if (!se->sum_exec_runtime || p->state == TASK_WAKING)
+   if (!se->sum_exec_runtime ||
+   (p->state == TASK_WAKING && p->sched_remote_wakeup))
return true;
 
return false;
-- 
2.19.0.rc1.350.ge57e33dbd1-goog



Re: [PATCH 2/7] Compiler Attributes: use the no-underscores syntax

2018-08-31 Thread Miguel Ojeda
On Sat, Sep 1, 2018 at 12:10 AM, Miguel Ojeda
 wrote:
> arch/parisc/boot/compressed/misc.c:#define malloc   malloc_gzip
> include/linux/decompress/mm.h:#define malloc(a) kmalloc(a, GFP_KERNEL)
> lib/inflate.c:#define malloc(a) kmalloc(a, GFP_KERNEL)
> include/linux/compiler_types.h:#define noinline_for_stack noinline
> include/linux/raid/pq.h:#define noinline __attribute__((noinline))
> tools/include/linux/compiler.h:#define noinline
> arch/mips/sgi-ip27/ip27-reset.c:#define noreturn while(1);

A better list, searching for all attributes used anywhere in the kernel:

git grep -E 
'^\s*#define\s+(address_space|alias|aligned|always_inline|assume_aligned|bitwise|bnd_legacy|cold|common|const|constructor|context|deprecated|designated_init|destructor|error|externally_visible|flatten|force|format|format|gnu_inline|hot|hotpatch|indirect_branch|latent_entropy|long_call|malloc|may_alias|mode|model|naked|nocast|noclone|noderef|noinline|no_instrument_function|nonnull|no_randomize_layout|noreturn|no_sanitize_address|optimize|packed|pure|randomize_layout|regparm|require_context|safe|section|syscall_linkage|target|tls_model|unused|used|user|vector_size|visibility|warning|warn_unused_result|weak)(\(|\s|$)'

arch/mips/sgi-ip27/ip27-reset.c:#define noreturn while(1);
 /* Silence gcc.  */
arch/parisc/boot/compressed/misc.c:#define malloc   malloc_gzip
arch/powerpc/xmon/ansidecl.h:#defineconst
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:#define error(fmt,
args...) bioslog(ERROR, fmt, ##args)
include/linux/compiler_attributes.h:#define   noinline
__attribute__((noinline))
include/linux/decompress/mm.h:#define malloc(a) kmalloc(a, GFP_KERNEL)
include/linux/raid/pq.h:#define noinline __attribute__((noinline))
lib/inflate.c:#define malloc(a) kmalloc(a, GFP_KERNEL)
tools/include/linux/compiler-gcc.h:#define  noinline
__attribute__((noinline))
tools/include/linux/compiler.h:#define noinline
tools/testing/selftests/futex/include/logging.h:#define error(message,
err, args...) \

None of these should make a problem. And it would may avoid people
using such common-name-macros in the future ;-)

Cheers,
Miguel


Re: [PATCH 6/7] Compiler Attributes: remove unneeded sparse (__CHECKER__) tests

2018-08-31 Thread Luc Van Oostenryck
On Fri, Aug 31, 2018 at 11:55:51PM +0200, Miguel Ojeda wrote:
> Hi Nick,
> 
> On Fri, Aug 31, 2018 at 11:38 PM, Nick Desaulniers
>  wrote:
> > On Fri, Aug 31, 2018 at 10:05 AM Miguel Ojeda
> >  wrote:
> >>
> >> Sparse knows about a few more attributes now, so we can remove
> >> the __CHECKER__ conditions from them (which, in turn, allow us
> >> to move some of them later on to compiler_attributes.h).
> >>
> >>   * assume_aligned: since sparse's commit ffc860b ("sparse:
> >> ignore __assume_aligned__ attribute"), included in 0.5.1
> >>
> >>   * error: since sparse's commit 0a04210 ("sparse: Add 'error'
> >> to ignored attributes"), included in 0.5.0
> >>
> >>   * hotpatch: since sparse's commit 6043210 ("sparse/parse.c:
> >> ignore hotpatch attribute"), included in 0.5.1
> >>
> >>   * warning: since sparse's commit 977365d ("Avoid "attribute
> >> 'warning': unknown attribute" warning"), included in 0.4.2
> >>
> >> Cc: Eli Friedman 
> >> Cc: Christopher Li 
> >> Cc: Kees Cook 
> >> Cc: Ingo Molnar 
> >> Cc: Geert Uytterhoeven 
> >> Cc: Arnd Bergmann 
> >> Cc: Greg Kroah-Hartman 
> >> Cc: Masahiro Yamada 
> >> Cc: Joe Perches 
> >> Cc: Dominique Martinet 
> >> Cc: Nick Desaulniers 
> >> Cc: Linus Torvalds 
> >> Signed-off-by: Miguel Ojeda 
> >> ---
> >>  include/linux/compiler-gcc.h   | 6 ++
> >>  include/linux/compiler_types.h | 2 +-
> >>  2 files changed, 3 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> >> index fdf2fbe6d544..32e6ce06163f 100644
> >> --- a/include/linux/compiler-gcc.h
> >> +++ b/include/linux/compiler-gcc.h
> >> @@ -84,14 +84,12 @@
> >>
> >>  #define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> >>
> >> -#ifndef __CHECKER__
> >>  #define __compiletime_warning(message) __attribute__((warning(message)))
> >>  #define __compiletime_error(message) __attribute__((error(message)))
> >>
> >> -#ifdef LATENT_ENTROPY_PLUGIN
> >> +#if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__)
> >>  #define __latent_entropy __attribute__((latent_entropy))
> >>  #endif
> >> -#endif /* __CHECKER__ */
> >>
> >>  /*
> >>   * calling noreturn functions, __builtin_unreachable() and 
> >> __builtin_trap()
> >> @@ -139,7 +137,7 @@
> >>
> >>  /* gcc version specific checks */
> >>
> >> -#if GCC_VERSION >= 40900 && !defined(__CHECKER__)
> >> +#if GCC_VERSION >= 40900
> >>  /*
> >>   * __assume_aligned(n, k): Tell the optimizer that the returned
> >>   * pointer can be assumed to be k modulo n. The second argument is
> >> diff --git a/include/linux/compiler_types.h 
> >> b/include/linux/compiler_types.h
> >> index 3662b19599fc..5dddc7e0c607 100644
> >> --- a/include/linux/compiler_types.h
> >> +++ b/include/linux/compiler_types.h
> >> @@ -216,7 +216,7 @@ struct ftrace_likely_data {
> >>  #define __must_check
> >>  #endif
> >>
> >> -#if defined(CC_USING_HOTPATCH) && !defined(__CHECKER__)
> >> +#if defined(CC_USING_HOTPATCH)
> >>  #define notrace__attribute__((hotpatch(0, 0)))
> >>  #else
> >>  #define notrace
> >> __attribute__((no_instrument_function))
> >> --
> >> 2.17.1
> >>
> >
> > Everything looks correct here.  It would be good for the sparse
> > maintainer to triple check the commit sha's (as those are for sparse's
> > code base, not the kernel's) and have their blessing.  If Chris is
> 
> Actually, nowadays it is very easy to check in sparse's
> gcc-attr-list.h file, but since the file was not always there, I tried
> to find out when the support for each attribute was added.

Acked-by: Luc Van Oostenryck 


Re: WARNING in apparmor_secid_to_secctx

2018-08-31 Thread Dmitry Vyukov
On Fri, Aug 31, 2018 at 9:17 AM, Stephen Smalley  wrote:
> On 08/31/2018 12:16 PM, Stephen Smalley wrote:
>>
>> On 08/31/2018 12:07 PM, Paul Moore wrote:
>>>
>>> On Fri, Aug 31, 2018 at 12:01 PM Stephen Smalley 
>>> wrote:

 On 08/29/2018 10:21 PM, Dmitry Vyukov wrote:
>
> On Wed, Aug 29, 2018 at 7:17 PM, syzbot
>  wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support'
>> git tree:   net-next
>> console output:
>> https://syzkaller.appspot.com/x/log.txt?x=1536d29640
>> kernel config:
>> https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
>> dashboard link:
>> https://syzkaller.appspot.com/bug?extid=21016130b0580a9de3b5
>> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the
>> commit:
>> Reported-by: syzbot+21016130b0580a9de...@syzkaller.appspotmail.com
>
>
> Hi John, Tyler,
>
> I've switched syzbot from selinux to apparmor as we discussed on lss:
>
> https://github.com/google/syzkaller/commit/2c6cb254ae6c06f61e3aba21bb89ffb05b5db946


 Sorry, does this mean that you are no longer testing selinux via syzbot?
That seems unfortunate.  SELinux is default-enabled and used in
 Fedora, RHEL and all derivatives (e.g. CentOS), and mandatory in Android
 (and seemingly getting some use in ChromeOS now as well, at least for
 the Android container and possibly wider), so it seems unwise to drop it
 from your testing altogether.  I was under the impression that you were
 just going to add apparmor to your testing matrix, not drop selinux
 altogether.
>>>
>>>
>>> It is also important to note that testing with SELinux enabled but no
>>> policy loaded is not going to be very helpful (last we talked that is
>>> what syzbot is/was doing).  While syzbot did uncover some issues
>>> relating to the enabled-no-policy case, those are much less
>>> interesting and less relevant than the loaded-policy case.
>>
>>
>> I had thought that they had switched over to at least loading a policy but
>> possibly left it in permissive mode because the base distribution didn't
>> properly support SELinux out of the box.  But I may be mistaken.
>> Regardless, the right solution is to migrate to testing with a policy
>> loaded not to stop testing altogether.
>>
>> Optimally, they'd test on at least one distribution/OS where SELinux is in
>> fact supported out of the box, e.g. CentOS, Android, and/or ChromeOS.
>
>
> Or Fedora, of course.

Hi,

Yes, we switched from selinux to apparmor. The thing is that we
effectively did not test selinux lately, so it's more like just
enabling apparmor rather than disabling selinux.

The story goes as follows.
We enabled selinux, but did not have policy and selinux wasn't enabled.
Then Paul (I think) pointer that out. After some debugging I figured
out that our debian wheezy actually has a policy, it's just that
selinux utilities were not installed, so init could not load the
policy.
I installed the tools, and we started loading policy.
But then it turned out that wheezy policy does not allows mounting
cgroup2 fs and maybe some others even in non-enforcing mode. As far as
I understand that's because the policy does not have definition for
the fs, and so loading bails out with an error.
We need cgroup2 both for testing and for better sandboxing (no other
way to restrict e.g. memory consumption). Moreover, we did not test
any actual interesting interactions with selinux (there must be some?
but I don't know what are they).
So I had to uninstall the tool and policy is not loaded again.
I investigated building a newer debian image with debootstrap (which
should have newer policy I guess). But they don't work, some cryptic
errors in init. Other people reported the same.
So that's we are. I don't have any ideas left...


[PATCH] kbuild: modules_install: Warn if System.map file is not found

2018-08-31 Thread Randy Dunlap
From: Randy Dunlap 

If there is no System.map file for "make modules_install",
scripts/depmod.sh will silently exit with success, having done
nothing.  Since this is an unexpected situation, change it to
report a Warning for the missing file.  The behavior is not
changed except for the Warning message.

The (previous) silent success and new Warning can be reproduced
by:
$ make mrproper; make defconfig
$ make modules; make modules_install

and since System.map is produced by "make vmlinux", the steps
above omit producing the System.map file.

Reported-by: Masahiro Yamada 
Cc: Masahiro Yamada 
Signed-off-by: Randy Dunlap 
---
 scripts/depmod.sh |1 +
 1 file changed, 1 insertion(+)

--- lnx-419-rc1.orig/scripts/depmod.sh
+++ lnx-419-rc1/scripts/depmod.sh
@@ -11,6 +11,7 @@ DEPMOD=$1
 KERNELRELEASE=$2
 
 if ! test -r System.map ; then
+   echo "Warning: modules_install: missing 'System.map' file"
exit 0
 fi
 



Re: [PATCH] docs: fix typo in table describing 4.16 development cycle

2018-08-31 Thread Jonathan Corbet
On Sat, 18 Aug 2018 02:33:30 +0900
Akinobu Mita  wrote:

> Fix s/4.17/4.16/ typo.
> 
> Fixes: 8962e40c1993 ("docs: update kernel versions and dates in tables")
> Cc: Tim Bird 
> Cc: Jonathan Corbet 
> Signed-off-by: Akinobu Mita 
> ---
>  Documentation/process/2.Process.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/process/2.Process.rst 
> b/Documentation/process/2.Process.rst
> index 51d0349..ae020d8 100644
> --- a/Documentation/process/2.Process.rst
> +++ b/Documentation/process/2.Process.rst
> @@ -82,7 +82,7 @@ As an example, here is how the 4.16 development cycle went 
> (all dates in
>   March 114.16-rc5
>   March 184.16-rc6
>   March 254.16-rc7
> - April 1 4.17 stable release
> + April 1 4.16 stable release

Oops...  applied, thanks.

jon


Re: [PATCH 01/21] staging:rtl8192u: Rename AdvCoding - Style

2018-08-31 Thread John Whitmore
On Thu, Aug 30, 2018 at 03:34:01PM -0700, Joe Perches wrote:
> On Wed, 2018-08-29 at 22:55 +0100, John Whitmore wrote:
> > On Wed, Aug 29, 2018 at 04:21:54PM -0500, Larry Finger wrote:
> > > On 08/29/2018 04:14 PM, Joe Perches wrote:
> []
> > > > Perhaps support for the chipset could be converted to use
> > > > mac80211 and moved into the directory with the other realtek
> > > > drivers in drivers/net/wireless/realtek/rtl8xxxu/...
> []
> > > All the Realtek USB devices should be added to rtl8xxxu, not merely moved
> > > into that directory. Jes Sorensen created a well-designed driver the is
> > > structured to permit addition of different initialization routines, etc.
> > > That said, the conversion will not be easy. In addition, it will require
> > > having your hands on a real device - a requirement that I cannot meet for
> > > the RTL8192U.
> []
> > > Oops... it probably doesn't look like it, at the moment, but 'actual code
> > changes to this driver' was where I'm hoping to get to. There's a lot of
> > stuff in the header files, including member variables, which are not used
> > in the code. I was hoping to strip these out incrementally to minimise
> > the amount of source code that has to be understood. I'm not familiar
> > with the overall network, or 80211, subsystem architecture, but it's hard
> > to see why this driver has it's own private ieee80211.h file.
> 
> That's true and the reason why this code should
> eventually be deleted if possible and its functionality
> integrated into the existing realtek/rtl8u code.
> 
> > I must try and get my hands on the device in question. 
> 
> That'd be good, though likely this device is obsolete.
> Good luck finding one.
>

Maybe if the whole driver was deleted nobody would notice ;)
Thanks for your help. I'm afraid I carried on in the same vain
cleaning stuff up but I do have to look at realtek/rtl8u, thanks
for pointing out where the goalposts are, miles away ;) 

> > Thank ye for your comments, and sorry for the "somewhat useful" changes
> > to date, but doing these changes is letting me get the hang of this code,
> > which I refuse to comment on because there are probably guidelines on using
> > naughty language on here. ;)
> 
> Feel free.
> 
> The one look I took at any existing multi-platform realtek
> code with all the #ifdefs made me not want look at it again.
> 
> https://github.com/hadess/rtl8723bs/
> 
> I said a naughty under my breath too.


Re: [PATCH] sched/fair: vruntime should normalize when switching from fair

2018-08-31 Thread Steve Muckle

On 08/29/2018 08:33 AM, Dietmar Eggemann wrote:

Yes, this solves the issue for the case I described. Using
'p->sched_remote_wakeup' (WF_MIGRATED) looks more elegant than using
'p->sched_class == &fair_sched_class'.


It's confirmed that this patch solves the original issue we saw (and my 
test case passes for me as well). I will send this version out shortly.


[PATCH 0/3] x86/pti: Get rid of entry trampolines and add some docs

2018-08-31 Thread Andy Lutomirski
This gets rid of entry trampolines.  It's more or less the same as
the RFC version, except that I rebased it to v4.19-rc1 due to
massive conflicts with some perf changes.  I have *not* reverted all
of the perf support for entry trampolines -- I leave that to the
perf crew, if needed.

Andy Lutomirski (3):
  x86/entry/64: Document idtentry
  x86/entry/64: Use the TSS sp2 slot for rsp_scratch
  x86/pti/64: Remove the SYSCALL64 entry trampoline

 arch/x86/entry/entry_64.S | 101 +-
 arch/x86/include/asm/cpu_entry_area.h |   2 -
 arch/x86/include/asm/processor.h  |   6 ++
 arch/x86/include/asm/sections.h   |   1 -
 arch/x86/include/asm/thread_info.h|   1 +
 arch/x86/kernel/asm-offsets.c |   5 +-
 arch/x86/kernel/cpu/common.c  |  11 +--
 arch/x86/kernel/kprobes/core.c|  10 +--
 arch/x86/kernel/process_64.c  |   2 -
 arch/x86/kernel/traps.c   |   4 +
 arch/x86/kernel/vmlinux.lds.S |  10 ---
 arch/x86/mm/cpu_entry_area.c  |  36 -
 arch/x86/mm/pti.c |  33 -
 13 files changed, 83 insertions(+), 139 deletions(-)

-- 
2.17.1



[PATCH 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-08-31 Thread Andy Lutomirski
The SYSCALL64 trampoline has a couple of nice properties:

 - The usual sequence of SWAPGS followed by two GS-relative accesses to
   set up RSP is somewhat slow because the GS-relative accesses need
   to wait for SWAPGS to finish.  The trampoline approach allows
   RIP-relative accesses to set up RSP, which avoids the stall.

 - The trampoline avoids any percpu access before CR3 is set up,
   which means that no percpu memory needs to be mapped in the user
   page tables.  This prevents using Meltdown to read any percpu memory
   outside the cpu_entry_area and prevents using timing leaks
   to directly locate the percpu areas.

The downsides of using a trampoline may outweigh the upsides, however.
It adds an extra non-contiguous I$ cache line to system calls, and it
forces an indirect jump to transfer control back to the normal kernel
text after CR3 is set up.  The latter is because x86 lacks a 64-bit
direct jump instruction that could jump from the trampoline to the entry
text.  With retpolines enabled, the indirect jump is extremely slow.

This patch changes the code to map the percpu TSS into the user page
tables to allow the non-trampoline SYSCALL64 path to work under PTI.
This does not add a new direct information leak, since the TSS is
readable by Meltdown from the cpu_entry_area alias regardless.  It
does allow a timing attack to locate the percpu area, but KASLR is
more or less a lost cause against local attack on CPUs vulnerable to
Meltdown regardless.  As far as I'm concerned, on current hardware,
KASLR is only useful to mitigate remote attacks that try to attack
the kernel without first gaining RCE against a vulnerable user
process.

On Skylake, with CONFIG_RETPOLINE=y and KPTI on, this reduces
syscall overhead from ~237ns to ~228ns.

There is a possible alternative approach: we could instead move the
trampoline within 2G of the entry text and make a separate copy for
each CPU.  Then we could use a direct jump to rejoin the normal
entry path.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/entry_64.S | 66 +--
 arch/x86/include/asm/cpu_entry_area.h |  2 -
 arch/x86/include/asm/sections.h   |  1 -
 arch/x86/kernel/asm-offsets.c |  2 -
 arch/x86/kernel/cpu/common.c  | 11 +
 arch/x86/kernel/kprobes/core.c| 10 +---
 arch/x86/kernel/vmlinux.lds.S | 10 
 arch/x86/mm/cpu_entry_area.c  | 36 ---
 arch/x86/mm/pti.c | 33 +-
 9 files changed, 35 insertions(+), 136 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 1796c42e08af..19927211b175 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -142,67 +142,6 @@ END(native_usergs_sysret64)
  * with them due to bugs in both AMD and Intel CPUs.
  */
 
-   .pushsection .entry_trampoline, "ax"
-
-/*
- * The code in here gets remapped into cpu_entry_area's trampoline.  This means
- * that the assembler and linker have the wrong idea as to where this code
- * lives (and, in fact, it's mapped more than once, so it's not even at a
- * fixed address).  So we can't reference any symbols outside the entry
- * trampoline and expect it to work.
- *
- * Instead, we carefully abuse %rip-relative addressing.
- * _entry_trampoline(%rip) refers to the start of the remapped) entry
- * trampoline.  We can thus find cpu_entry_area with this macro:
- */
-
-#define CPU_ENTRY_AREA \
-   _entry_trampoline - CPU_ENTRY_AREA_entry_trampoline(%rip)
-
-/* The top word of the SYSENTER stack is hot and is usable as scratch space. */
-#define RSP_SCRATCHCPU_ENTRY_AREA_entry_stack + \
-   SIZEOF_entry_stack - 8 + CPU_ENTRY_AREA
-
-ENTRY(entry_SYSCALL_64_trampoline)
-   UNWIND_HINT_EMPTY
-   swapgs
-
-   /* Stash the user RSP. */
-   movq%rsp, RSP_SCRATCH
-
-   /* Note: using %rsp as a scratch reg. */
-   SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp
-
-   /* Load the top of the task stack into RSP */
-   movqCPU_ENTRY_AREA_tss + TSS_sp1 + CPU_ENTRY_AREA, %rsp
-
-   /* Start building the simulated IRET frame. */
-   pushq   $__USER_DS  /* pt_regs->ss */
-   pushq   RSP_SCRATCH /* pt_regs->sp */
-   pushq   %r11/* pt_regs->flags */
-   pushq   $__USER_CS  /* pt_regs->cs */
-   pushq   %rcx/* pt_regs->ip */
-
-   /*
-* x86 lacks a near absolute jump, and we can't jump to the real
-* entry text with a relative jump.  We could push the target
-* address and then use retq, but this destroys the pipeline on
-* many CPUs (wasting over 20 cycles on Sandy Bridge).  Instead,
-* spill RDI and restore it in a second-stage trampoline.
-*/
-   pushq   %rdi
-   movq$entry_SYSCALL_64_stage2, %rdi
-   JMP_NOSPEC %rdi
-END(entry_SYSCALL_64_trampoline)
-

[PATCH 1/3] x86/entry/64: Document idtentry

2018-08-31 Thread Andy Lutomirski
The idtentry macro is complicated and magical.  Document what it
does to help future readers and to allow future patches to adjust
the code and docs at the same time.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/entry_64.S | 35 +++
 arch/x86/kernel/traps.c   |  4 
 2 files changed, 39 insertions(+)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 957dfb693ecc..1796c42e08af 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -900,6 +900,41 @@ apicinterrupt IRQ_WORK_VECTOR  
irq_work_interrupt  smp_irq_work_interrupt
  */
 #define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss_rw) + (TSS_ist + ((x) - 1) * 8)
 
+/**
+ * idtentry - Generate an IDT entry stub
+ * @sym: Name of the generated entry point
+ * @do_sym: C function to be called
+ * @has_error_code: True if this IDT vector has an error code on the stack
+ * @paranoid: non-zero means that this vector may be invoked from kernel
+ *mode with user GSBASE and/or user CR3.  2 is special -- see 
below.
+ * @shift_ist: Set to an IST index if entries from kernel mode should
+ * decrement the IST stack so that nested entries get a fresh
+ * stack.  (This is for #DB, which has a nasty habit of
+ * recursing.)
+ *
+ * idtentry generates an IDT stub that sets up a usable kernel context,
+ * creates struct pt_regs, and calls @do_sym.  The stub has the following
+ * special behaviors:
+ *
+ * On an entry from user mode, the stub switches from the trampoline or
+ * IST stack to the normal thread stack.  On an exit to user mode, the
+ * normal exit-to-usermode path is invoked.
+ *
+ * On an exit to kernel mode, if paranoid == 0, we check for preemption,
+ * whereas we omit the preemption check if @paranoid != 0.  This is purely
+ * because the implementation is simpler this way.  The kernel only needs
+ * to check for asynchronous kernel preemption when IRQ handlers return.
+ *
+ * If @paranoid == 0, then the stub will handle IRET faults by pretending
+ * that the fault came from user mode.  It will handle gs_change faults by
+ * pretending that the fault happened with kernel GSBASE.  Since this handling
+ * is omitted for @paranoid != 0, the #GP, #SS, and #NP stubs must have
+ * @paranoid == 0.  This special handling will do the wrong thing for
+ * espfix-induced #DF on IRET, so #DF must not use @paranoid == 0.
+ *
+ * @paranoid == 2 is special: the stub will never switch stacks.  This is for
+ * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS.
+ */
 .macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
 ENTRY(\sym)
UNWIND_HINT_IRET_REGS offset=\has_error_code*8
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index e6db475164ed..1a90821c0b74 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -383,6 +383,10 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, 
long error_code)
 * we won't enable interupts or schedule before we invoke
 * general_protection, so nothing will clobber the stack
 * frame we just set up.
+*
+* We will enter general_protection with kernel GSBASE,
+* which is what the stub expects, given that the faulting
+* RIP will be the IRET instruction.
 */
regs->ip = (unsigned long)general_protection;
regs->sp = (unsigned long)&gpregs->orig_ax;
-- 
2.17.1



[PATCH 2/3] x86/entry/64: Use the TSS sp2 slot for rsp_scratch

2018-08-31 Thread Andy Lutomirski
In the non-trampoline SYSCALL64 path, we use a percpu variable to
temporarily store the user RSP value.  Instead of a separate
variable, use the otherwise unused sp2 slot in the TSS.  This will
improve cache locality, as the sp1 slot is already used in the same
code to find the kernel stack.  It will also simplify a future
change to make the non-trampoline path work in PTI mode.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/processor.h   | 6 ++
 arch/x86/include/asm/thread_info.h | 1 +
 arch/x86/kernel/asm-offsets.c  | 3 ++-
 arch/x86/kernel/process_64.c   | 2 --
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index c24297268ebc..8433d76bc37b 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -313,7 +313,13 @@ struct x86_hw_tss {
 */
u64 sp1;
 
+   /*
+* Since Linux does not use ring 2, the 'sp2' slot is unused by
+* hardware.  entry_SYSCALL_64 uses it as scratch space to stash
+* the user RSP value.
+*/
u64 sp2;
+
u64 reserved2;
u64 ist[7];
u32 reserved3;
diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index 2ff2a30a264f..9a2f84233e39 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -209,6 +209,7 @@ static inline int arch_within_stack_frames(const void * 
const stack,
 
 #ifdef CONFIG_X86_64
 # define cpu_current_top_of_stack (cpu_tss_rw + TSS_sp1)
+# define rsp_scratch (cpu_tss_rw + TSS_sp2)
 #endif
 
 #endif
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 01de31db300d..fc2e90d3429a 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -105,7 +105,8 @@ void common(void) {
DEFINE(SIZEOF_entry_stack, sizeof(struct entry_stack));
DEFINE(MASK_entry_stack, (~(sizeof(struct entry_stack) - 1)));
 
-   /* Offset for sp0 and sp1 into the tss_struct */
+   /* Offset for fields in tss_struct */
OFFSET(TSS_sp0, tss_struct, x86_tss.sp0);
OFFSET(TSS_sp1, tss_struct, x86_tss.sp1);
+   OFFSET(TSS_sp2, tss_struct, x86_tss.sp2);
 }
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index a451bc374b9b..0fa7aa19f09e 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -59,8 +59,6 @@
 #include 
 #endif
 
-__visible DEFINE_PER_CPU(unsigned long, rsp_scratch);
-
 /* Prints also some state that isn't saved in the pt_regs */
 void __show_regs(struct pt_regs *regs, int all)
 {
-- 
2.17.1



[PATCH v6 3/3] staging: mt7621-mmc: Fix debug macro IRQ_MSG and its usages

2018-08-31 Thread Nishad Kamdar
Replace all usages of IRQ_MSG with with dev_ without __func__
or __LINE__ or current->comm and current->pid. Remove the do {}
while(0) loop for the single statement macro. Drop IRQ_MSG from dbg.h.
Issue found by checkpatch.

Signed-off-by: Nishad Kamdar 
---
Changes in v6:
  - No change
Changes in v5:
  - No change
---
 drivers/staging/mt7621-mmc/dbg.h | 12 ---
 drivers/staging/mt7621-mmc/sd.c  | 36 
 2 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/dbg.h b/drivers/staging/mt7621-mmc/dbg.h
index 79914d98c573..4ab9f10dccc2 100644
--- a/drivers/staging/mt7621-mmc/dbg.h
+++ b/drivers/staging/mt7621-mmc/dbg.h
@@ -102,18 +102,6 @@ do { \
 } while (0)
 #endif /* end of +++ */
 
-#if 1
-//defined CONFIG_MTK_MMC_CD_POLL
-#define IRQ_MSG(fmt, args...)
-#else
-/* PID in ISR in not corrent */
-#define IRQ_MSG(fmt, args...) \
-do { \
-   printk(KERN_ERR TAG"%d -> "fmt" <- %s() : L<%d>\n", \
-  host->id,  ##args, __FUNCTION__, __LINE__);  \
-} while (0);
-#endif
-
 void msdc_debug_proc_init(void);
 
 #if 0 /* --- chhung */
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 7474f9ed7b5b..f3ae19fe0f76 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -279,7 +279,9 @@ static void msdc_tasklet_card(struct work_struct *work)
mmc_detect_change(host->mmc, msecs_to_jiffies(20));
}
 
-   IRQ_MSG("card found<%s>", inserted ? "inserted" : "removed");
+   dev_err(mmc_dev(host->mmc),
+   "%d -> card found<%s>\n",
+   host->id, inserted ? "inserted" : "removed");
 #endif
 
spin_unlock(&host->lock);
@@ -1638,14 +1640,17 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
if (intsts & MSDC_INT_CDSC) {
if (host->mmc->caps & MMC_CAP_NEEDS_POLL)
return IRQ_HANDLED;
-   IRQ_MSG("MSDC_INT_CDSC irq<0x%.8x>", intsts);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> MSDC_INT_CDSC irq<0x%.8x>\n", host->id, intsts);
schedule_delayed_work(&host->card_delaywork, HZ);
/* tuning when plug card ? */
}
 
/* sdio interrupt */
if (intsts & MSDC_INT_SDIOIRQ) {
-   IRQ_MSG("XXX MSDC_INT_SDIOIRQ");  /* seems not sdio irq */
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX MSDC_INT_SDIOIRQ\n",
+   host->id); /* seems not sdio irq */
//mmc_signal_sdio_irq(host->mmc);
}
 
@@ -1663,10 +1668,15 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
msdc_clr_int();
 
if (intsts & MSDC_INT_DATTMO) {
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_DATTMO", 
host->mrq->cmd->opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> MSDC_INT_DATTMO\n",
+   host->id, host->mrq->cmd->opcode);
data->error = -ETIMEDOUT;
} else if (intsts & MSDC_INT_DATCRCERR) {
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_DATCRCERR, 
SDC_DCRC_STS<0x%x>", host->mrq->cmd->opcode, readl(host->base + SDC_DCRC_STS));
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> MSDC_INT_DATCRCERR, 
SDC_DCRC_STS<0x%x>\n",
+   host->id, host->mrq->cmd->opcode,
+   readl(host->base + SDC_DCRC_STS);
data->error = -EIO;
}
 
@@ -1699,15 +1709,23 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
}
} else if ((intsts & MSDC_INT_RSPCRCERR) || (intsts & 
MSDC_INT_ACMDCRCERR)) {
if (intsts & MSDC_INT_ACMDCRCERR)
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_ACMDCRCERR", 
cmd->opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> 
MSDC_INT_ACMDCRCERR\n",
+   host->id, cmd->opcode);
else
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_RSPCRCERR", 
cmd->opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> 
MSDC_INT_RSPCRCERR\n",
+   host->id, cmd->opcode);
cmd->error = -EIO;
} else if ((intsts & MSDC_INT_CMDTMO) || (intsts & 
MSDC_INT_ACMDTMO)) {
if (intsts & MSDC_INT_ACMDTMO)
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_ACMDTMO", 
cmd->opcode);
+   dev_err(mmc_dev(host->mmc),
+

[PATCH v6 2/3] staging: mt7621-mmc: Fix debug macro ERR_MSG and its usages

2018-08-31 Thread Nishad Kamdar
Replace all usages of ERR_MSG with with dev_ without __func__
or __LINE__ or current->comm and current->pid. Remove the do {}
while(0) loop for the single statement macro. Delete commented
ERR_MSG() usage. Drop ERR_MSG from dbg.h. Issue found by checkpatch.

Signed-off-by: Nishad Kamdar 
---
Changes in v6:
  - No change
Changes in v5:
  - Remove commented ERR_MSG() usage.
---
 drivers/staging/mt7621-mmc/dbg.h |   6 --
 drivers/staging/mt7621-mmc/sd.c  | 120 +--
 2 files changed, 81 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/dbg.h b/drivers/staging/mt7621-mmc/dbg.h
index 9152db30a2ed..79914d98c573 100644
--- a/drivers/staging/mt7621-mmc/dbg.h
+++ b/drivers/staging/mt7621-mmc/dbg.h
@@ -102,12 +102,6 @@ do { \
 } while (0)
 #endif /* end of +++ */
 
-#define ERR_MSG(fmt, args...) \
-do { \
-   printk(KERN_ERR TAG"%d -> "fmt" <- %s() : L<%d> PID<%s><0x%x>\n", \
-  host->id,  ##args, __FUNCTION__, __LINE__, current->comm, 
current->pid); \
-} while (0);
-
 #if 1
 //defined CONFIG_MTK_MMC_CD_POLL
 #define IRQ_MSG(fmt, args...)
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 0154117fae15..7474f9ed7b5b 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -322,7 +322,6 @@ static void msdc_set_mclk(struct msdc_host *host, int ddr, 
unsigned int hz)
//u8  clksrc = hw->clk_src;
 
if (!hz) { // set mmc system clock to 0 ?
-   //ERR_MSG("set mclk to 0!!!");
msdc_reset_hw(host);
return;
}
@@ -373,7 +372,7 @@ static void msdc_abort_data(struct msdc_host *host)
 {
struct mmc_command *stop = host->mrq->stop;
 
-   ERR_MSG("Need to Abort.");
+   dev_err(mmc_dev(host->mmc), "%d -> Need to Abort.\n", host->id);
 
msdc_reset_hw(host);
msdc_clr_fifo(host);
@@ -382,7 +381,8 @@ static void msdc_abort_data(struct msdc_host *host)
// need to check FIFO count 0 ?
 
if (stop) {  /* try to stop, but may not success */
-   ERR_MSG("stop when abort CMD<%d>", stop->opcode);
+   dev_err(mmc_dev(host->mmc), "%d -> stop when abort CMD<%d>\n",
+   host->id, stop->opcode);
(void)msdc_do_command(host, stop, 0, CMD_TIMEOUT);
}
 
@@ -523,13 +523,14 @@ static void msdc_pm(pm_message_t state, void *data)
 
} else if (evt == PM_EVENT_RESUME || evt == PM_EVENT_USER_RESUME) {
if (!host->suspend) {
-   //ERR_MSG("warning: already resume");
return;
}
 
/* No PM resume when USR suspend */
if (evt == PM_EVENT_RESUME && host->pm_state.event == 
PM_EVENT_USER_SUSPEND) {
-   ERR_MSG("PM Resume when in USR Suspend");   
/* won't happen. */
+   dev_err(mmc_dev(host->mmc),
+   "%d -> PM Resume when in USR Suspend\n",
+   host->id); /* won't happen. */
return;
}
 
@@ -645,7 +646,9 @@ static unsigned int msdc_command_start(struct msdc_host   
*host,
break;
 
if (time_after(jiffies, tmo)) {
-   ERR_MSG("XXX cmd_busy timeout: before CMD<%d>", 
opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX cmd_busy timeout: before 
CMD<%d>\n",
+   host->id, opcode);
cmd->error = -ETIMEDOUT;
msdc_reset_hw(host);
goto end;
@@ -656,7 +659,9 @@ static unsigned int msdc_command_start(struct msdc_host   
*host,
if (!sdc_is_busy())
break;
if (time_after(jiffies, tmo)) {
-   ERR_MSG("XXX sdc_busy timeout: before CMD<%d>", 
opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX sdc_busy timeout: before 
CMD<%d>\n",
+   host->id, opcode);
cmd->error = -ETIMEDOUT;
msdc_reset_hw(host);
goto end;
@@ -695,7 +700,9 @@ static unsigned int msdc_command_resp(struct msdc_host   
*host,
 
spin_unlock(&host->lock);
if (!wait_for_completion_timeout(&host->cmd_done, 10 * timeout)) {
-   ERR_MSG("XXX CMD<%d> wait_for_completion timeout ARG<0x%.8x>", 
opcode, cmd->arg);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> wait_for_completion timeout 
ARG<0x%.8x>\n",
+   host->id, opcode, cmd->arg);
cmd->error = -ETIMEDOUT;
msdc_rese

[PATCH v6 1/3] staging: mt7621-mmc: Delete N_MSG() and all its users

2018-08-31 Thread Nishad Kamdar
This patch removes N_MSG() and all its users since it is a no-op.

Signed-off-by: Nishad Kamdar 
---
Changes in v6:
  - Delete N_MSG() and all its users.
Changes in v5:
  - Remove commented code for N_MSG()
---
 drivers/staging/mt7621-mmc/dbg.h |  10 --
 drivers/staging/mt7621-mmc/sd.c  | 242 ---
 2 files changed, 252 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/dbg.h b/drivers/staging/mt7621-mmc/dbg.h
index 4d4898a3ab54..9152db30a2ed 100644
--- a/drivers/staging/mt7621-mmc/dbg.h
+++ b/drivers/staging/mt7621-mmc/dbg.h
@@ -102,16 +102,6 @@ do { \
 } while (0)
 #endif /* end of +++ */
 
-#define N_MSG(evt, fmt, args...)
-/*
-do {\
-if ((DBG_EVT_##evt) & sd_debug_zone[host->id]) { \
-printk(KERN_ERR TAG"%d -> "fmt" <- %s() : L<%d> PID<%s><0x%x>\n", \
-host->id,  ##args , __FUNCTION__, __LINE__, current->comm, 
current->pid);  \
-} \
-} while(0)
-*/
-
 #define ERR_MSG(fmt, args...) \
 do { \
printk(KERN_ERR TAG"%d -> "fmt" <- %s() : L<%d> PID<%s><0x%x>\n", \
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 4cd4df4fc75f..0154117fae15 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -230,144 +230,6 @@ static unsigned int msdc_do_command(struct msdc_host   
*host,
 
 static int msdc_tune_cmdrsp(struct msdc_host *host, struct mmc_command *cmd);
 
-#ifdef MT6575_SD_DEBUG
-static void msdc_dump_card_status(struct msdc_host *host, u32 status)
-{
-/* N_MSG is currently a no-op */
-#if 0
-   static char *state[] = {
-   "Idle", /* 0 */
-   "Ready",/* 1 */
-   "Ident",/* 2 */
-   "Stby", /* 3 */
-   "Tran", /* 4 */
-   "Data", /* 5 */
-   "Rcv",  /* 6 */
-   "Prg",  /* 7 */
-   "Dis",  /* 8 */
-   "Reserved", /* 9 */
-   "Reserved", /* 10 */
-   "Reserved", /* 11 */
-   "Reserved", /* 12 */
-   "Reserved", /* 13 */
-   "Reserved", /* 14 */
-   "I/O mode", /* 15 */
-   };
-#endif
-   if (status & R1_OUT_OF_RANGE)
-   N_MSG(RSP, "[CARD_STATUS] Out of Range");
-   if (status & R1_ADDRESS_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Address Error");
-   if (status & R1_BLOCK_LEN_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Block Len Error");
-   if (status & R1_ERASE_SEQ_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Erase Seq Error");
-   if (status & R1_ERASE_PARAM)
-   N_MSG(RSP, "[CARD_STATUS] Erase Param");
-   if (status & R1_WP_VIOLATION)
-   N_MSG(RSP, "[CARD_STATUS] WP Violation");
-   if (status & R1_CARD_IS_LOCKED)
-   N_MSG(RSP, "[CARD_STATUS] Card is Locked");
-   if (status & R1_LOCK_UNLOCK_FAILED)
-   N_MSG(RSP, "[CARD_STATUS] Lock/Unlock Failed");
-   if (status & R1_COM_CRC_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Command CRC Error");
-   if (status & R1_ILLEGAL_COMMAND)
-   N_MSG(RSP, "[CARD_STATUS] Illegal Command");
-   if (status & R1_CARD_ECC_FAILED)
-   N_MSG(RSP, "[CARD_STATUS] Card ECC Failed");
-   if (status & R1_CC_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] CC Error");
-   if (status & R1_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Error");
-   if (status & R1_UNDERRUN)
-   N_MSG(RSP, "[CARD_STATUS] Underrun");
-   if (status & R1_OVERRUN)
-   N_MSG(RSP, "[CARD_STATUS] Overrun");
-   if (status & R1_CID_CSD_OVERWRITE)
-   N_MSG(RSP, "[CARD_STATUS] CID/CSD Overwrite");
-   if (status & R1_WP_ERASE_SKIP)
-   N_MSG(RSP, "[CARD_STATUS] WP Eraser Skip");
-   if (status & R1_CARD_ECC_DISABLED)
-   N_MSG(RSP, "[CARD_STATUS] Card ECC Disabled");
-   if (status & R1_ERASE_RESET)
-   N_MSG(RSP, "[CARD_STATUS] Erase Reset");
-   if (status & R1_READY_FOR_DATA)
-   N_MSG(RSP, "[CARD_STATUS] Ready for Data");
-   if (status & R1_SWITCH_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Switch error");
-   if (status & R1_APP_CMD)
-   N_MSG(RSP, "[CARD_STATUS] App Command");
-
-   N_MSG(RSP, "[CARD_STATUS] '%s' State", state[R1_CURRENT_STATE(status)]);
-}
-
-static void msdc_dump_ocr_reg(struct msdc_host *host, u32 resp)
-{
-   if (resp & (1 << 7))
-   N_MSG(RSP, "[OCR] Low Voltage Range");
-   if (resp & (1 << 15))
-   N_MSG(RSP, "[OCR] 2.7-2.8 volt");
-   if (resp & (1 << 16))
-   N_MSG(RSP, "[OCR] 2.8-2.9 volt");
-   if (resp & (1 << 17))
-   N_MSG(RSP, "[OCR] 2.9-3.0 volt");
-   

Re: [PATCH v2 1/2] compiler-clang.h: Add CLANG_VERSION and __diag macros

2018-08-31 Thread Miguel Ojeda
Hi Nick,

On Fri, Aug 31, 2018 at 11:50 PM, Nick Desaulniers
 wrote:
> + Miguel and Joe
>
> This is the old patch I had sent for detecting Clang version.  If we
> wanted to set a minimal version, this plus the actual version should
> do it.  Probably could drop the diag stuff, as we changed clang to not
> warn in this case, so my solution using _Pragma is obsolete.

Nitpick: do we want to use the CLANG_VERSION notation? In some cases I
think it is easier to simply use directly the original values (like I
did in compiler_attributes.h for gcc).

Consider that we almost never need the patchlevel (and if we do, it is
better to *see* we are explicitly testing for it), and given the
versioning schemes that compilers nowadays use (i.e. only major
versions), I would bet not even the minor (except maybe for GCC in
compiler_attributes.h until we drop gcc < 5).

Cheers,
Miguel


[PATCH v6 0/3] staging: mt7621-mmc: Fix debug macros and their usages

2018-08-31 Thread Nishad Kamdar
This patchset fixes the three debug macros N_MSG, ERR_MSG, and
IRQ_MSG. Each patch fixes one particular macro and its usages.

For N_MSG, deletes the macro and its users as it is a no-op.

For ERR_MSG and IRQ_MSG, replaces printk with dev_ without __func__ or
__LINE__ or current->comm and current->pid. Removes the do {} while(0) loop
for the single statement macro. Further drops the macros and replaces their
usages with dev_. Deletes the commented usages.

Changes in v6:
  - Delete N_MSG() macro and its users as it is a no-op.
  - Patchset reduced to 3 patches as the patch INIT_MSG patch is accepted.

Changes in v5:
  - Remove commented code for N_MSG().
  - Remove commented ERR_MSG() usages.
 
Changes in v4:
  - Create multiple patches, one for each type of macro being
deleted/changed.

Changes in v3:
  - Replace usages of ERR_MSG and IRQ_MSG with dev_err() in code itself.
  - Remove all INIT_MSG usages.
  - Drop ERR_MSG, INIT_MSG and IRQ_MSG from dbg.h.

Changes in v2:
  - Replace printk with dev_.
  - Remove __func__, __LINE__, current->comm, current->pid from arguments.
  - Remove the do {} while(0) loop from these macros.
  - Modify commit message to include other changes.

Nishad Kamdar (3):
  staging: mt7621-mmc: Delete N_MSG() and all its users
  staging: mt7621-mmc: Fix debug macro ERR_MSG and its usages
  staging: mt7621-mmc: Fix debug macro IRQ_MSG and its usages

 drivers/staging/mt7621-mmc/dbg.h |  28 ---
 drivers/staging/mt7621-mmc/sd.c  | 398 +--
 2 files changed, 108 insertions(+), 318 deletions(-)

-- 
2.17.1



Re: [PATCH 2/7] Compiler Attributes: use the no-underscores syntax

2018-08-31 Thread Miguel Ojeda
Hi Ramus,

On Fri, Aug 31, 2018 at 11:49 PM, Rasmus Villemoes
 wrote:
> On 2018-08-31 19:05, Miguel Ojeda wrote:
>> The attribute syntax optionally allows to surround attribute names
>> with "__" in order to avoid collisions with macros of the same name
>> (see https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html).
>>
>> This homogenizes all attributes to use the syntax without underscores.
>
> At the risk of bikeshedding, why not the other way around, exactly
> because of what you write above? We have convenience macros anyway, so
> those verbose leading/trailing underscores would only be in compiler*.h,
> and some of the attribute names are common words that can appear as
> #defines. E.g. error is defined
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c ; if that used a
> BUILD_BUG_ON somewhere, the
>
> #define __compiletime_error(message) __attribute__((error(message)))
>
> would break.

Indeed, if we are afraid of such cases, we should go with the __name__
syntax. I was trying to go first for the "cleanest"/simplest way
first, considering no one should be defining many such macros as
"error" (and in lower case, at that). But indeed, good catch!

Grepping for those in compiler_attributes.h (which, as you point out,
are not all of them) yields:

arch/parisc/boot/compressed/misc.c:#define malloc   malloc_gzip
include/linux/decompress/mm.h:#define malloc(a) kmalloc(a, GFP_KERNEL)
lib/inflate.c:#define malloc(a) kmalloc(a, GFP_KERNEL)
include/linux/compiler_types.h:#define noinline_for_stack noinline
include/linux/raid/pq.h:#define noinline __attribute__((noinline))
tools/include/linux/compiler.h:#define noinline
arch/mips/sgi-ip27/ip27-reset.c:#define noreturn while(1);
 /* Silence gcc.  */

Cheers,
Miguel


[PATCH v2 09/10] tools, perf, script: Add --call-trace and --call-ret-trace

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

Add short cut options to print PT call trace and call-ret-trace,
for calls and call and returns. Roughly corresponds to ftrace
function tracer and function graph tracer.

Just makes these common use cases nicer to use.

% perf record -a -e intel_pt// sleep 1
% perf script --call-trace
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_pmu_enable
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
event_filter_match
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
group_sched_in
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
event_sched_in.isra.107
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_set_state.part.71
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_update_time
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_pmu_disable
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_log_itrace_start
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_update_userpage

% perf script --call-ret-trace
perf   900 [000] 194167.205652203:   tr strt ([unknown])
pt_config
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])pt_config
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])pt_event_add
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])perf_pmu_enable
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])perf_pmu_nop_void
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])event_sched_in.isra.107
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])perf_pmu_nop_int
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])group_sched_in
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])event_filter_match
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])event_filter_match
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])group_sched_in
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])perf_pmu_nop_txn
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])event_sched_in.isra.107
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])perf_event_set_state.part.71

v2: Print errors, power, ptwrite too
Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-script.txt |  7 +++
 tools/perf/builtin-script.c  | 24 
 2 files changed, 31 insertions(+)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index 04a57e0fb3a6..29eb3c3eb93e 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -387,6 +387,13 @@ include::itrace.txt[]
Show instruction stream for intel_pt traces. Requires installing the
xed disassembler.
 
+--call-trace::
+   Show call stream for intel_pt traces. The CPUs are interleaved, but
+   can be filtered with -C.
+
+--call-ret-trace::
+   Show call and return stream for intel_pt traces.
+
 SEE ALSO
 
 linkperf:perf-record[1], linkperf:perf-script-perl[1],
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index bb68b0c8bfab..f5f90ed79eae 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -3098,6 +3098,26 @@ static int parse_insn_trace(const struct option *opt 
__maybe_unused,
return 0;
 }
 
+static int parse_call_trace(const struct option *opt __maybe_unused,
+   const char *str __maybe_unused,
+   int unset __maybe_unused)
+{
+   parse_output_fields(NULL, "-ip,-addr,-event,-period,+callindent", 0);
+   itrace_parse_synth_opts(opt, "cewp", 0);
+   nanosecs = true;
+   return 0;
+}
+
+static int parse_callret_trace(const struct option *opt __maybe

[PATCH v2 04/10] perf, tools, script: Allow sym and dso without ip, addr

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

Currently sym and dso require printing ip and addr because
the print function is tied to those outputs. With callindent
it makes sense to print the symbol or dso without numerical
IP or ADDR. So change the dependency check to only check the
underlying attribute.

This allows to remove a lot of noise in callindent output by
dropping the numerical addresses, which are not all that useful.

Before

% perf script --itrace=cr -F +callindent
 swapper 0 [000] 156546.354971:  1   branches: pt_config
   0 [unknown] ([unknown]) => 81010486 
pt_config ([kernel.kallsyms])
 swapper 0 [000] 156546.354971:  1   branches: 
pt_config81010499 pt_config ([kernel.kallsyms]) => 
8101063e pt_event_add ([kernel.kallsyms])
 swapper 0 [000] 156546.354971:  1   branches: 
pt_event_add 81010635 pt_event_add ([kernel.kallsyms]) 
=> 8115e687 event_sched_in.isra.107 ([kernel.kallsyms])
 swapper 0 [000] 156546.354971:  1   branches: 
perf_pmu_enable  8115e726 event_sched_in.isra.107 
([kernel.kallsyms]) => 811579b0 perf_pmu_enable ([kernel.kallsyms])
 swapper 0 [000] 156546.354971:  1   branches: 
perf_pmu_nop_void81151730 perf_pmu_nop_void 
([kernel.kallsyms]) => 8115e72b event_sched_in.isra.107 
([kernel.kallsyms])
 swapper 0 [000] 156546.354971:  1   branches: 
event_sched_in.isra.107  8115e737 event_sched_in.isra.107 
([kernel.kallsyms]) => 8115e7a5 group_sched_in ([kernel.kallsyms])
 swapper 0 [000] 156546.354971:  1   branches: 
__x86_indirect_thunk_rax 8115e7f6 group_sched_in 
([kernel.kallsyms]) => 81a03000 __x86_indirect_thunk_rax 
([kernel.kallsyms])

After

% perf script --itrace=cr -F +callindent,-ip,-sym,-symoff
   swapper 0 [000] 156546.354971:  1   branches:  pt_config
 swapper 0 [000] 156546.354971:  1   branches:  
pt_config
 swapper 0 [000] 156546.354971:  1   branches:  
pt_event_add
 swapper 0 [000] 156546.354971:  1   branches:   
perf_pmu_enable
 swapper 0 [000] 156546.354971:  1   branches:   
perf_pmu_nop_void
 swapper 0 [000] 156546.354971:  1   branches:   
event_sched_in.isra.107
 swapper 0 [000] 156546.354971:  1   branches:   
__x86_indirect_thunk_rax
 swapper 0 [000] 156546.354971:  1   branches:   
perf_pmu_nop_int
 swapper 0 [000] 156546.354971:  1   branches:   
group_sched_in
 swapper 0 [000] 156546.354971:  1   branches:   
event_filter_match
 swapper 0 [000] 156546.354971:  1   branches:   
event_filter_match
 swapper 0 [000] 156546.354971:  1   branches:   
group_sched_in

Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-script.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 66daa7df68c5..bae960c56763 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -407,9 +407,10 @@ static int perf_evsel__check_attr(struct perf_evsel *evsel,
PERF_OUTPUT_WEIGHT))
return -EINVAL;
 
-   if (PRINT_FIELD(SYM) && !PRINT_FIELD(IP) && !PRINT_FIELD(ADDR)) {
+   if (PRINT_FIELD(SYM) &&
+   !(evsel->attr.sample_type & (PERF_SAMPLE_IP|PERF_SAMPLE_ADDR))) 
{
pr_err("Display of symbols requested but neither sample IP nor "
-  "sample address\nis selected. Hence, no addresses to 
convert "
+  "sample address\navailable. Hence, no addresses to 
convert "
   "to symbols.\n");
return -EINVAL;
}
@@ -418,10 +419,9 @@ static int perf_evsel__check_attr(struct perf_evsel *evsel,
   "selected.\n");
return -EINVAL;
}
-   if (PRINT_FIELD(DSO) && !PRINT_FIELD(IP) && !PRINT_FIELD(ADDR) &&
-   !PRINT_FIELD(BRSTACK) && !PRINT_FIELD(BRSTACKSYM) && 
!PRINT_FIELD(BRSTACKOFF)) {
-   pr_err("Display of DSO requested but no address to convert.  
Select\n"
-  "sample IP, sample address, brstack, brstacksym, or 
brstackoff.\n");
+   if (PRINT_FIELD(DSO) &&
+   !(evsel->attr.sample_type & (PERF_SAMPLE_IP|PERF_SAMPLE_ADDR))) 
{
+   pr_err("Display of DSO requested but no address to convert.\n");
return -EINVAL;
}
if (PRINT_FIELD(SRCLINE) && !PRINT_FIELD(IP)) {
-- 
2.17.1



[PATCH v2 02/10] tools, pager: Support overwriting the pager

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

Add an interface to the auto pager code that allows callers
to overwrite the pager.

Signed-off-by: Andi Kleen 
---
 tools/lib/subcmd/pager.c | 11 ++-
 tools/lib/subcmd/pager.h |  1 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/lib/subcmd/pager.c b/tools/lib/subcmd/pager.c
index 9997a8805a82..e3d47b59b14d 100644
--- a/tools/lib/subcmd/pager.c
+++ b/tools/lib/subcmd/pager.c
@@ -23,6 +23,13 @@ void pager_init(const char *pager_env)
subcmd_config.pager_env = pager_env;
 }
 
+static const char *forced_pager;
+
+void force_pager(const char *pager)
+{
+   forced_pager = pager;
+}
+
 static void pager_preexec(void)
 {
/*
@@ -66,7 +73,9 @@ void setup_pager(void)
const char *pager = getenv(subcmd_config.pager_env);
struct winsize sz;
 
-   if (!isatty(1))
+   if (forced_pager)
+   pager = forced_pager;
+   if (!isatty(1) && !forced_pager)
return;
if (ioctl(1, TIOCGWINSZ, &sz) == 0)
pager_columns = sz.ws_col;
diff --git a/tools/lib/subcmd/pager.h b/tools/lib/subcmd/pager.h
index f1a53cf29880..a818964693ab 100644
--- a/tools/lib/subcmd/pager.h
+++ b/tools/lib/subcmd/pager.h
@@ -7,5 +7,6 @@ extern void pager_init(const char *pager_env);
 extern void setup_pager(void);
 extern int pager_in_use(void);
 extern int pager_get_columns(void);
+extern void force_pager(const char *);
 
 #endif /* __SUBCMD_PAGER_H */
-- 
2.17.1



[PATCH v2 01/10] perf tools: Report itrace options in help

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

I often forget all the options that --itrace accepts. Instead of burying
them in the man page only report them in the normal command line help
too to make them easier accessible.

v2: Align
Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-inject.c |  3 ++-
 tools/perf/builtin-report.c |  2 +-
 tools/perf/builtin-script.c |  2 +-
 tools/perf/util/auxtrace.h  | 19 +++
 4 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index a3b346359ba0..b649a0511ed8 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -803,7 +803,8 @@ int cmd_inject(int argc, const char **argv)
   "kallsyms pathname"),
OPT_BOOLEAN('f', "force", &data.force, "don't complain, do it"),
OPT_CALLBACK_OPTARG(0, "itrace", &inject.itrace_synth_opts,
-   NULL, "opts", "Instruction Tracing options",
+   NULL, "opts", "Instruction Tracing 
options\n"
+   ITRACE_HELP,
itrace_parse_synth_opts),
OPT_BOOLEAN(0, "strip", &inject.strip,
"strip non-synthesized events (use with --itrace)"),
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 02f7a3c27761..d48ea050e95e 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -1105,7 +1105,7 @@ int cmd_report(int argc, const char **argv)
OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
 "how to display percentage of filtered entries", 
parse_filter_percentage),
OPT_CALLBACK_OPTARG(0, "itrace", &itrace_synth_opts, NULL, "opts",
-   "Instruction Tracing options",
+   "Instruction Tracing options\n" ITRACE_HELP,
itrace_parse_synth_opts),
OPT_BOOLEAN(0, "full-source-path", &srcline_full_filename,
"Show full source file name path for source lines"),
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 568ddfac3213..910e0f1f2876 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -3193,7 +3193,7 @@ int cmd_script(int argc, const char **argv)
OPT_BOOLEAN(0, "ns", &nanosecs,
"Use 9 decimal places when displaying time"),
OPT_CALLBACK_OPTARG(0, "itrace", &itrace_synth_opts, NULL, "opts",
-   "Instruction Tracing options",
+   "Instruction Tracing options\n" ITRACE_HELP,
itrace_parse_synth_opts),
OPT_BOOLEAN(0, "full-source-path", &srcline_full_filename,
"Show full source file name path for source lines"),
diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h
index e731f55da072..041ee64a63bc 100644
--- a/tools/perf/util/auxtrace.h
+++ b/tools/perf/util/auxtrace.h
@@ -576,6 +576,23 @@ static inline void auxtrace__free(struct perf_session 
*session)
return session->auxtrace->free(session);
 }
 
+#define ITRACE_HELP \
+"  i:  synthesize instructions 
events\n"   \
+"  b:  synthesize branches 
events\n"   \
+"  c:  synthesize branches 
events (calls only)\n"  \
+"  r:  synthesize branches 
events (returns only)\n" \
+"  x:  synthesize transactions 
events\n"   \
+"  w:  synthesize ptwrite 
events\n"\
+"  p:  synthesize power 
events\n"  \
+"  e:  synthesize error 
events\n"  \
+"  d:  create a debug log\n"   
\
+"  g[len]: synthesize a call chain 
(use with i or x)\n" \
+"  l[len]: synthesize last branch 
entries (use with i or x)\n" \
+"  sNUMBER:skip initial number of 
events\n"\
+"  PERIOD[ns|us|ms|i|t]:   specify period to 
sample stream\n" \
+"  concatenate multiple options. Default is ibxwpe 
or cewp\n"
+
+
 #else
 
 static inline struct auxtrace_record *
@@ -716,6 +733,8 @@ void auxtrace_mmap_params__set_idx(struct 
auxtrace_mmap_params *mp,
   struct perf_evlist *evlist, int idx,
   bool per_cpu);
 
+#define ITRACE_HELP ""
+
 #endif
 
 #endif
-- 
2.17.1



[PATCH v2 08/10] perf, tools, script: Make itrace script default to all calls

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

By default perf script for itrace outputs sampled instructions or
branches. In my experience this is confusing to users because it's
hard to correlate with real program behavior. The sampling makes
sense for tools like report that actually sample to reduce
the run time, but run time is normally not a problem for perf script.
It's better to give an accurate representation of the program flow.

Default perf script to output all calls for itrace. That's a much saner
default. The old behavior can be still requested with
perf script --itrace=ibxwpe10

Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/itrace.txt |  7 ---
 tools/perf/builtin-script.c |  5 -
 tools/perf/util/auxtrace.c  | 17 -
 tools/perf/util/auxtrace.h  |  5 -
 tools/perf/util/cs-etm.c|  3 ++-
 tools/perf/util/intel-bts.c |  3 ++-
 tools/perf/util/intel-pt.c  |  3 ++-
 7 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/tools/perf/Documentation/itrace.txt 
b/tools/perf/Documentation/itrace.txt
index a3abe04c779d..c2182cbabde3 100644
--- a/tools/perf/Documentation/itrace.txt
+++ b/tools/perf/Documentation/itrace.txt
@@ -11,10 +11,11 @@
l   synthesize last branch entries (use with i or x)
s   skip initial number of events
 
-   The default is all events i.e. the same as --itrace=ibxwpe
+   The default is all events i.e. the same as --itrace=ibxwpe,
+   except for perf script where it is --itrace=ce
 
-   In addition, the period (default 10) for instructions events
-   can be specified in units of:
+   In addition, the period (default 10, except for perf script where 
it is 1)
+   for instructions events can be specified in units of:
 
i   instructions
t   ticks
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 0a80ae3aa33e..bb68b0c8bfab 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -3107,7 +3107,10 @@ int cmd_script(int argc, const char **argv)
char *rec_script_path = NULL;
char *rep_script_path = NULL;
struct perf_session *session;
-   struct itrace_synth_opts itrace_synth_opts = { .set = false, };
+   struct itrace_synth_opts itrace_synth_opts = {
+   .set = false,
+   .default_no_sample = true,
+   };
char *script_path = NULL;
const char **__argv;
int i, j, err = 0;
diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index d056447520a2..4baca3a92b23 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -958,16 +958,23 @@ s64 perf_event__process_auxtrace(struct perf_tool *tool,
 #define PERF_ITRACE_DEFAULT_LAST_BRANCH_SZ 64
 #define PERF_ITRACE_MAX_LAST_BRANCH_SZ 1024
 
-void itrace_synth_opts__set_default(struct itrace_synth_opts *synth_opts)
+void itrace_synth_opts__set_default(struct itrace_synth_opts *synth_opts,
+   bool no_sample)
 {
-   synth_opts->instructions = true;
synth_opts->branches = true;
synth_opts->transactions = true;
synth_opts->ptwrites = true;
synth_opts->pwr_events = true;
synth_opts->errors = true;
-   synth_opts->period_type = PERF_ITRACE_DEFAULT_PERIOD_TYPE;
-   synth_opts->period = PERF_ITRACE_DEFAULT_PERIOD;
+   if (no_sample) {
+   synth_opts->period_type = PERF_ITRACE_PERIOD_INSTRUCTIONS;
+   synth_opts->period = 1;
+   synth_opts->calls = true;
+   } else {
+   synth_opts->instructions = true;
+   synth_opts->period_type = PERF_ITRACE_DEFAULT_PERIOD_TYPE;
+   synth_opts->period = PERF_ITRACE_DEFAULT_PERIOD;
+   }
synth_opts->callchain_sz = PERF_ITRACE_DEFAULT_CALLCHAIN_SZ;
synth_opts->last_branch_sz = PERF_ITRACE_DEFAULT_LAST_BRANCH_SZ;
synth_opts->initial_skip = 0;
@@ -995,7 +1002,7 @@ int itrace_parse_synth_opts(const struct option *opt, 
const char *str,
}
 
if (!str) {
-   itrace_synth_opts__set_default(synth_opts);
+   itrace_synth_opts__set_default(synth_opts, false);
return 0;
}
 
diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h
index 041ee64a63bc..71c00bf468a3 100644
--- a/tools/perf/util/auxtrace.h
+++ b/tools/perf/util/auxtrace.h
@@ -55,6 +55,7 @@ enum itrace_period_type {
 /**
  * struct itrace_synth_opts - AUX area tracing synthesis options.
  * @set: indicates whether or not options have been set
+ * @default_no_sample: Default to no sampling.
  * @inject: indicates the event (not just the sample) must be fully synthesized
  *  because 'perf inject' will write it out
  * @instructions: whether to synthesize 'instructions' events
@@ -79,6 +80,7 @@ enum itrace_period_type {
  */
 struct itrace_synth_o

Make perf script easier to use for itrace

2018-08-31 Thread Andi Kleen
Implement a range of improvements to make it easier to look
at itrace traces with perf script. Nothing here couldn't be done
before with some additional scripting, but add simple high 
level options to make it easier to use.

% perf record -e intel_pt//k -a sleep 1

Show function calls:

% perf script --call-trace
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_pmu_enable
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
event_filter_match
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
group_sched_in
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
event_sched_in.isra.107
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_set_state.part.71
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_update_time
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_pmu_disable
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_log_itrace_start
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_update_userpage

Show function calls and returns:

% perf script --call-ret-trace
perf   900 [000] 194167.205652203:   tr strt ([unknown])
pt_config
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])pt_config
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])pt_event_add
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])perf_pmu_enable
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])perf_pmu_nop_void
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])event_sched_in.isra.107
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])perf_pmu_nop_int
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])group_sched_in
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])event_filter_match
perf   900 [000] 194167.205652203:   return  
([kernel.kallsyms])event_filter_match
perf   900 [000] 194167.205652203:   call
([kernel.kallsyms])group_sched_in


Show instruction traces (using XED):

  % perf script --insn-trace
   swapper 0 [000] 117276.429606186:  81010486 pt_config 
([kernel.kallsyms])  nopl  %eax, (%rax,%rax,1)
   swapper 0 [000] 117276.429606186:  8101048b pt_config 
([kernel.kallsyms])  add $0x10, %rsp
   swapper 0 [000] 117276.429606186:  8101048f pt_config 
([kernel.kallsyms])  popq  %rbx
   swapper 0 [000] 117276.429606186:  81010490 pt_config 
([kernel.kallsyms])  popq  %rbp
   swapper 0 [000] 117276.429606186:  81010491 pt_config 
([kernel.kallsyms])  popq  %r12
   swapper 0 [000] 117276.429606186:  81010493 pt_config 
([kernel.kallsyms])  popq  %r13
   swapper 0 [000] 117276.429606186:  81010495 pt_config 
([kernel.kallsyms])  popq  %r14
   swapper 0 [000] 117276.429606186:  81010497 pt_config 
([kernel.kallsyms])  popq  %r15
   swapper 0 [000] 117276.429606186:  81010499 pt_config 
([kernel.kallsyms])  retq


Filter by a ftrace style graph function:

 % perf script --graph-function group_sched_in --call-trace
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
group_sched_in
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
event_sched_in.isra.107
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_set_state.part.71
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_update_time
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_pmu_disable
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  

[PATCH v2 05/10] tools, perf, script: Set user_set/wildcard_set for +- fields in -F

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

The branch target output relies on the user_set flag to determine
if the branch target should be implicitely printed. When
modifying the fields with + or - also set user_set,
so that ADDR can be removed. We also need to set wildcard_set
to make the initial sanity check pass.

Before:

% perf script --itrace=cr -F +callindent,-ip,-sym,-symoff,-addr
 swapper 0 [000]  3377.917072:  1   branches: pt_config 
   => 81010486 ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: pt_config 
   => 8101063e ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
pt_event_add => 8115e687 ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
perf_pmu_enable  => 811579b0 ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
perf_pmu_nop_void=> 8115e72b ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
event_sched_in.isra.107  => 8115e7a5 ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
__x86_indirect_thunk_rax => 81a03000 ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
perf_pmu_nop_int => 8115e7fb ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
group_sched_in   => 811583a8 ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
event_filter_match   => 81153e10 ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
event_filter_match   => 811583d4 ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
group_sched_in   => 8115e738 ([kernel.kallsyms])
 swapper 0 [000]  3377.917072:  1   branches: 
__x86_indirect_thunk_rax => 81a03000 ([kernel.kallsyms])

After:

% perf script --itrace=cr -F +callindent,-ip,-sym,-symoff,-addr

 swapper 0 [000]  3377.917072:  1   branches: pt_config
 swapper 0 [000]  3377.917072:  1   branches: pt_config
 swapper 0 [000]  3377.917072:  1   branches: 
pt_event_add
 swapper 0 [000]  3377.917072:  1   branches: 
perf_pmu_enable
 swapper 0 [000]  3377.917072:  1   branches: 
perf_pmu_nop_void
 swapper 0 [000]  3377.917072:  1   branches: 
event_sched_in.isra.107
 swapper 0 [000]  3377.917072:  1   branches: 
__x86_indirect_thunk_rax
 swapper 0 [000]  3377.917072:  1   branches: 
perf_pmu_nop_int
 swapper 0 [000]  3377.917072:  1   branches: 
group_sched_in
 swapper 0 [000]  3377.917072:  1   branches: 
event_filter_match
 swapper 0 [000]  3377.917072:  1   branches: 
event_filter_match
 swapper 0 [000]  3377.917072:  1   branches: 
group_sched_in

v2: Use correct index for fallback case
Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-script.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index bae960c56763..d7d454d10074 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2490,6 +2490,8 @@ static int parse_output_fields(const struct option *opt 
__maybe_unused,
output[j].fields &= 
~all_output_options[i].field;
else
output[j].fields |= 
all_output_options[i].field;
+   output[j].user_set = true;
+   output[j].wildcard_set = true;
}
}
} else {
@@ -2500,7 +2502,8 @@ static int parse_output_fields(const struct option *opt 
__maybe_unused,
rc = -EINVAL;
goto out;
}
-   output[type].fields |= all_output_options[i].field;
+   output[type].user_set = true;
+   output[type].wildcard_set = true;
}
}
 
-- 
2.17.1



Re: Access to non-RAM pages

2018-08-31 Thread Jiri Kosina
On Wed, 29 Aug 2018, Juergen Gross wrote:

> While being very unlikely I still believe this is possible. Any
> thoughts?

So in theory we should somehow test whether the next page is some form of 
mmio/gart/... mapping, but I guess that by itself would kill the 
performance advantage of the whole load_unaligned_zeropad() trick.

And yes, the sideffects of reading from mmio mapping is a real thing -- 
see for example the issue fixed by 2a3e83c6f9.

If noone has any clever idea how to work this around (I don't), I am 
afraid we'd have to ditch the whole DCACHE_WORD_ACCESS optimization, as 
it's silently dangerous.

Thanks,

-- 
Jiri Kosina
SUSE Labs


[PATCH v2 07/10] perf, tools, script: Print DSO for callindent

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

Now that we don't need to print the IP/ADDR for callindent the DSO
is also not printed. It's useful for some cases, so add an own DSO
printout for callindent for the case when IP/ADDR is not enabled.

Before:

% perf script --itrace=cr -F +callindent,-ip,-sym,-symoff,-addr
 swapper 0 [000]  3377.917072:  1   branches: pt_config
 swapper 0 [000]  3377.917072:  1   branches: pt_config
 swapper 0 [000]  3377.917072:  1   branches: 
pt_event_add
 swapper 0 [000]  3377.917072:  1   branches: 
perf_pmu_enable
 swapper 0 [000]  3377.917072:  1   branches: 
perf_pmu_nop_void
 swapper 0 [000]  3377.917072:  1   branches: 
event_sched_in.isra.107
 swapper 0 [000]  3377.917072:  1   branches: 
__x86_indirect_thunk_rax
 swapper 0 [000]  3377.917072:  1   branches: 
perf_pmu_nop_int
 swapper 0 [000]  3377.917072:  1   branches: 
group_sched_in
 swapper 0 [000]  3377.917072:  1   branches: 
event_filter_match
 swapper 0 [000]  3377.917072:  1   branches: 
event_filter_match
 swapper 0 [000]  3377.917072:  1   branches: 
group_sched_in

After:

 swapper 0 [000]  3377.917072:  1   branches: ([unknown])   
pt_config
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   pt_config
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   pt_event_add
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   perf_pmu_enable
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   perf_pmu_nop_void
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   event_sched_in.isra.107
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   __x86_indirect_thunk_rax
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   perf_pmu_nop_int
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   group_sched_in
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   event_filter_match
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   event_filter_match
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   group_sched_in
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   __x86_indirect_thunk_rax
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   perf_pmu_nop_txn
 swapper 0 [000]  3377.917072:  1   branches: 
([kernel.kallsyms])   event_sched_in.isra.107

(in the kernel case of course it's not very useful, but it's important
with user programs where symbols are not unique)

Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-script.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 129b11404a9c..0a80ae3aa33e 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1116,6 +1116,7 @@ static int perf_sample__fprintf_callindent(struct 
perf_sample *sample,
const char *name = NULL;
static int spacing;
int len = 0;
+   int dlen = 0;
u64 ip = 0;
 
/*
@@ -1142,6 +1143,12 @@ static int perf_sample__fprintf_callindent(struct 
perf_sample *sample,
ip = sample->ip;
}
 
+   if (PRINT_FIELD(DSO) && !(PRINT_FIELD(IP) || PRINT_FIELD(ADDR))) {
+   dlen += fprintf(fp, "(");
+   dlen += map__fprintf_dsoname(al->map, fp);
+   dlen += fprintf(fp, ")\t");
+   }
+
if (name)
len = fprintf(fp, "%*s%s", (int)depth * 4, "", name);
else if (ip)
@@ -1160,7 +1167,7 @@ static int perf_sample__fprintf_callindent(struct 
perf_sample *sample,
if (len < spacing)
len += fprintf(fp, "%*s", spacing - len, "");
 
-   return len;
+   return len + dlen;
 }
 
 static int perf_sample__fprintf_insn(struct perf_sample *sample,
-- 
2.17.1



[PATCH v2 10/10] tools, perf, script: Implement --graph-function

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

Add a ftrace style --graph-function argument to perf script that allows
to print itrace function calls only below a given function. This
makes it easier to find the code of interest in a large trace.

% perf record -e intel_pt//k -a sleep 1
% perf script --graph-function group_sched_in --call-trace
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
group_sched_in
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
event_sched_in.isra.107
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_set_state.part.71
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_update_time
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_pmu_disable
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_log_itrace_start
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_event_update_userpage
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
calc_timer_values
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
sched_clock_cpu
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
arch_perf_update_userpage
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__fentry__
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
using_native_sched_clock
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
sched_clock_stable
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
perf_pmu_enable
perf   900 [000] 194167.205652203: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
group_sched_in
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
event_sched_in.isra.107
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
perf_event_set_state.part.71
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
perf_event_update_time
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
perf_pmu_disable
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
perf_log_itrace_start
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
perf_event_update_userpage
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
calc_timer_values
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
sched_clock_cpu
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
__x86_indirect_thunk_rax
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
arch_perf_update_userpage
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
__fentry__
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
using_native_sched_clock
 swapper 0 [001] 194167.205660693: ([kernel.kallsyms])  
sched_clock_stable

Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-script.txt |  4 +
 tools/perf/builtin-script.c  | 97 +++-
 tools/perf/util/symbol.h |  3 +-
 tools/perf/util/thread.h |  2 +
 4 files changed, 87 insertions(+), 19 deletions(-)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index 29eb3c3eb93e..59fed1adca7f 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -394,6 +394,10 @@ include::itrace.txt[]
 --call-ret-trace::
Show call and return stream for intel_pt traces.
 
+--graph-function::
+   For itrace only show specified functions and their callees for
+   itrace. Multiple functions can be separated by comma.
+
 SEE ALSO
 
 linkperf:perf-record[1], linkperf:perf-script-perl[1],
diff --git a/tools/perf/builtin-script.c 

[PATCH v2 06/10] perf, tools, script: Implement - for typed fields

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

For perf script -F the - removal of fields didn't work for typed
fields, only for untyped. Add the REMOVE case for this variant too.

v2: Use correct index
Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-script.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index d7d454d10074..129b11404a9c 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2502,6 +2502,10 @@ static int parse_output_fields(const struct option *opt 
__maybe_unused,
rc = -EINVAL;
goto out;
}
+   if (change == REMOVE)
+   output[type].fields &= 
~all_output_options[i].field;
+   else
+   output[type].fields |= 
all_output_options[i].field;
output[type].user_set = true;
output[type].wildcard_set = true;
}
-- 
2.17.1



[PATCH v2 03/10] tools, perf, script: Add --insn-trace for instruction decoding

2018-08-31 Thread Andi Kleen
From: Andi Kleen 

Add a --insn-trace short hand option for decoding and disassembling
instruction streams for intel_pt. This automatically pipes the
output into the xed disassembler to generate disassembled instructions.
This just makes this use model much nicer to use

Before

% perf record -e intel_pt// ...
% perf script --itrace=i0ns --ns -F +insn,-event,-period | xed -F insn: -A -64
   swapper 0 [000] 117276.429606186:  81010486 pt_config 
([kernel.kallsyms])  nopl  %eax, (%rax,%rax,1)
   swapper 0 [000] 117276.429606186:  8101048b pt_config 
([kernel.kallsyms])  add $0x10, %rsp
   swapper 0 [000] 117276.429606186:  8101048f pt_config 
([kernel.kallsyms])  popq  %rbx
   swapper 0 [000] 117276.429606186:  81010490 pt_config 
([kernel.kallsyms])  popq  %rbp
   swapper 0 [000] 117276.429606186:  81010491 pt_config 
([kernel.kallsyms])  popq  %r12
   swapper 0 [000] 117276.429606186:  81010493 pt_config 
([kernel.kallsyms])  popq  %r13
   swapper 0 [000] 117276.429606186:  81010495 pt_config 
([kernel.kallsyms])  popq  %r14
   swapper 0 [000] 117276.429606186:  81010497 pt_config 
([kernel.kallsyms])  popq  %r15
   swapper 0 [000] 117276.429606186:  81010499 pt_config 
([kernel.kallsyms])  retq
   swapper 0 [000] 117276.429606186:  8101063e pt_event_add 
([kernel.kallsyms])   cmpl  $0x1, 0x1b0(%rbx)
   swapper 0 [000] 117276.429606186:  81010645 pt_event_add 
([kernel.kallsyms])   mov $0xffea, %eax
   swapper 0 [000] 117276.429606186:  8101064a pt_event_add 
([kernel.kallsyms])   mov $0x0, %edx
   swapper 0 [000] 117276.429606186:  8101064f pt_event_add 
([kernel.kallsyms])   popq  %rbx
   swapper 0 [000] 117276.429606186:  81010650 pt_event_add 
([kernel.kallsyms])   cmovnz %edx, %eax
   swapper 0 [000] 117276.429606186:  81010653 pt_event_add 
([kernel.kallsyms])   jmp 0x81010635
   swapper 0 [000] 117276.429606186:  81010635 pt_event_add 
([kernel.kallsyms])   retq
   swapper 0 [000] 117276.429606186:  8115e687 
event_sched_in.isra.107 ([kernel.kallsyms])test %eax, %eax

Now

% perf record -e intel_pt// ...
% perf script --insn-trace
... same output ...

Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-script.txt |  4 
 tools/perf/builtin-script.c  | 14 ++
 2 files changed, 18 insertions(+)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index afdafe2110a1..04a57e0fb3a6 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -383,6 +383,10 @@ include::itrace.txt[]
will be printed. Each entry has function name and file/line. Enabled by
default, disable with --no-inline.
 
+--insn-trace::
+   Show instruction stream for intel_pt traces. Requires installing the
+   xed disassembler.
+
 SEE ALSO
 
 linkperf:perf-record[1], linkperf:perf-script-perl[1],
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 910e0f1f2876..66daa7df68c5 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sane_ctype.h"
 
@@ -3072,6 +3073,17 @@ static int perf_script__process_auxtrace_info(struct 
perf_tool *tool,
 #define perf_script__process_auxtrace_info 0
 #endif
 
+static int parse_insn_trace(const struct option *opt __maybe_unused,
+   const char *str __maybe_unused,
+   int unset __maybe_unused)
+{
+   parse_output_fields(NULL, "+insn,-event,-period", 0);
+   itrace_parse_synth_opts(opt, "i0ns", 0);
+   nanosecs = true;
+   force_pager("xed -F insn: -A -64 | less");
+   return 0;
+}
+
 int cmd_script(int argc, const char **argv)
 {
bool show_full_info = false;
@@ -3156,6 +3168,8 @@ int cmd_script(int argc, const char **argv)
"system-wide collection from all CPUs"),
OPT_STRING('S', "symbols", &symbol_conf.sym_list_str, 
"symbol[,symbol...]",
   "only consider these symbols"),
+   OPT_CALLBACK_OPTARG(0, "insn-trace", &itrace_synth_opts, NULL, NULL,
+   "Decode instructions from itrace", parse_insn_trace),
OPT_STRING(0, "stop-bt", &symbol_conf.bt_stop_list_str, 
"symbol[,symbol...]",
   "Stop display of callgraph at these symbols"),
OPT_STRING('C', "cpu", &cpu_list, "cpu", "list of cpus to profile"),
-- 
2.17.1



Re: [PATCH 6/7] Compiler Attributes: remove unneeded sparse (__CHECKER__) tests

2018-08-31 Thread Miguel Ojeda
Hi Nick,

On Fri, Aug 31, 2018 at 11:38 PM, Nick Desaulniers
 wrote:
> On Fri, Aug 31, 2018 at 10:05 AM Miguel Ojeda
>  wrote:
>>
>> Sparse knows about a few more attributes now, so we can remove
>> the __CHECKER__ conditions from them (which, in turn, allow us
>> to move some of them later on to compiler_attributes.h).
>>
>>   * assume_aligned: since sparse's commit ffc860b ("sparse:
>> ignore __assume_aligned__ attribute"), included in 0.5.1
>>
>>   * error: since sparse's commit 0a04210 ("sparse: Add 'error'
>> to ignored attributes"), included in 0.5.0
>>
>>   * hotpatch: since sparse's commit 6043210 ("sparse/parse.c:
>> ignore hotpatch attribute"), included in 0.5.1
>>
>>   * warning: since sparse's commit 977365d ("Avoid "attribute
>> 'warning': unknown attribute" warning"), included in 0.4.2
>>
>> Cc: Eli Friedman 
>> Cc: Christopher Li 
>> Cc: Kees Cook 
>> Cc: Ingo Molnar 
>> Cc: Geert Uytterhoeven 
>> Cc: Arnd Bergmann 
>> Cc: Greg Kroah-Hartman 
>> Cc: Masahiro Yamada 
>> Cc: Joe Perches 
>> Cc: Dominique Martinet 
>> Cc: Nick Desaulniers 
>> Cc: Linus Torvalds 
>> Signed-off-by: Miguel Ojeda 
>> ---
>>  include/linux/compiler-gcc.h   | 6 ++
>>  include/linux/compiler_types.h | 2 +-
>>  2 files changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> index fdf2fbe6d544..32e6ce06163f 100644
>> --- a/include/linux/compiler-gcc.h
>> +++ b/include/linux/compiler-gcc.h
>> @@ -84,14 +84,12 @@
>>
>>  #define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>>
>> -#ifndef __CHECKER__
>>  #define __compiletime_warning(message) __attribute__((warning(message)))
>>  #define __compiletime_error(message) __attribute__((error(message)))
>>
>> -#ifdef LATENT_ENTROPY_PLUGIN
>> +#if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__)
>>  #define __latent_entropy __attribute__((latent_entropy))
>>  #endif
>> -#endif /* __CHECKER__ */
>>
>>  /*
>>   * calling noreturn functions, __builtin_unreachable() and __builtin_trap()
>> @@ -139,7 +137,7 @@
>>
>>  /* gcc version specific checks */
>>
>> -#if GCC_VERSION >= 40900 && !defined(__CHECKER__)
>> +#if GCC_VERSION >= 40900
>>  /*
>>   * __assume_aligned(n, k): Tell the optimizer that the returned
>>   * pointer can be assumed to be k modulo n. The second argument is
>> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
>> index 3662b19599fc..5dddc7e0c607 100644
>> --- a/include/linux/compiler_types.h
>> +++ b/include/linux/compiler_types.h
>> @@ -216,7 +216,7 @@ struct ftrace_likely_data {
>>  #define __must_check
>>  #endif
>>
>> -#if defined(CC_USING_HOTPATCH) && !defined(__CHECKER__)
>> +#if defined(CC_USING_HOTPATCH)
>>  #define notrace__attribute__((hotpatch(0, 0)))
>>  #else
>>  #define notrace
>> __attribute__((no_instrument_function))
>> --
>> 2.17.1
>>
>
> Everything looks correct here.  It would be good for the sparse
> maintainer to triple check the commit sha's (as those are for sparse's
> code base, not the kernel's) and have their blessing.  If Chris is

Actually, nowadays it is very easy to check in sparse's
gcc-attr-list.h file, but since the file was not always there, I tried
to find out when the support for each attribute was added.

But indeed, Chris, please let us know. (Should have CC'd you).

> happy with it, then you can add my signoff:
>
> Reviewed-by: Nick Desaulniers 
>
> Also, do you need to put the cc list in the commit message? Some
> people do (hopefully in an automated fashion, because I'd imagine
> manually to be difficult) but don't this it's required.  Doesn't
> matter, just curious.

Hm... I thought it was supposed to be there for all patches,
considering different patches may have to be targeted to different
people. Also, one has to manage anyway the Acked-by and Reviewed-by
per-patch, so you have to manually go through. On top of that, it is
always handy to have in case you discard a patch into a separate
series or in case you send them through a tool that picks the Cc
individually (instead of something more advanced like git-send-email).
So... I guess? Not sure if it is strictly required, though.

Cheers,
Miguel


Re: [PATCH v2 1/2] compiler-clang.h: Add CLANG_VERSION and __diag macros

2018-08-31 Thread Nick Desaulniers
+ Miguel and Joe

This is the old patch I had sent for detecting Clang version.  If we
wanted to set a minimal version, this plus the actual version should
do it.  Probably could drop the diag stuff, as we changed clang to not
warn in this case, so my solution using _Pragma is obsolete.
On Mon, Jul 30, 2018 at 2:34 PM Nick Desaulniers
 wrote:
>
> These are needed for doing proper version checks, though feature
> detection via __has_attribute,  __has_builtin, and __has_feature should
> be preferred, see:
> https://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros
>
> Also adds __diag support, for generating compiler version specific
> _Pragma()'s.
>
> __diag support based on commit 8793bb7f4a9d ("kbuild: add macro for
> controlling warnings to linux/compiler.h")
>
> Cc: sta...@vger.kernel.org # 4.17, 4.14, 4.9, 4.4
> Suggested-by: Nathan Chancellor 
> Signed-off-by: Nick Desaulniers 
> ---
>  include/linux/compiler-clang.h | 19 +++
>  include/linux/compiler_types.h |  4 
>  2 files changed, 23 insertions(+)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index 7087446c24c8..9442e07a361e 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -7,6 +7,10 @@
>   * for Clang compiler
>   */
>
> +#define CLANG_VERSION (__clang_major__ * 1 \
> +  + __clang_minor__ * 100  \
> +  + __clang_patchlevel__)
> +
>  #ifdef uninitialized_var
>  #undef uninitialized_var
>  #define uninitialized_var(x) x = *(&(x))
> @@ -46,3 +50,18 @@
>  __has_builtin(__builtin_sub_overflow)
>  #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
>  #endif
> +
> +#define __diag_str1(s) #s
> +#define __diag_str(s) __diag_str1(s)
> +#define __diag(s) _Pragma(__diag_str(clang diagnostic s))
> +#define __diag_CLANG_ignore ignored
> +#define __diag_CLANG_warn warning
> +#define __diag_CLANG_error error
> +#define __diag_CLANG(version, severity, s) \
> +   __diag_CLANG_ ## version(__diag_CLANG_ ## severity s)
> +
> +#if CLANG_VERSION >= 7
> +#define __diag_CLANG_7(s) __diag(s)
> +#else
> +#define __diag_CLANG_7(s)
> +#endif
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index a8ba6b04152c..a04e6bd63476 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -279,6 +279,10 @@ struct ftrace_likely_data {
>  #define __diag_GCC(version, severity, string)
>  #endif
>
> +#ifndef __diag_CLANG
> +#define __diag_CLANG(version, severity, string)
> +#endif
> +
>  #define __diag_push()  __diag(push)
>  #define __diag_pop()   __diag(pop)
>
> --
> 2.18.0.345.g5c9ce644c3-goog
>


-- 
Thanks,
~Nick Desaulniers


RE: Affinity managed interrupts vs non-managed interrupts

2018-08-31 Thread Kashyap Desai
> >
> > It is not yet finalized, but it can be based on per sdev outstanding,
> > shost_busy etc.
> > We want to use special 16 reply queue for IO acceleration (these
queues are
> > working interrupt coalescing mode. This is a h/w feature)
>
> TBH, this does not make any sense whatsoever. Why are you trying to have
> extra interrupts for coalescing instead of doing the following:

Thomas,

We are using this feature mainly for performance and not for CPU hotplug
issues.
I read your below #1 to #4  points are more of addressing CPU hotplug
stuffs. Right ?  We also want to make sure if we convert megaraid_sas
driver from managed to non-managed interrupt, we can still achieve CPU
hotplug requirement.  If we use " pci_enable_msix_range" and manually set
affinity in driver  using irq_set_affinity_hint, cpu hotplug feature works
as expected.  is able to retain older mapping and whenever
offlined cpu comes back, irqbalancer restore the same old mapping.

If we use all 72 reply queue (all are in interrupt coalescing mode)
without any extra reply queues, we don't have any issue with cpu-msix
mapping and cpu hotplug issues.
Our major problem with that method is latency is very bad on lower QD
and/or single worker case.

To solve that problem we have added extra 16 reply queue (this is a
special h/w feature for performance only) which can be worked in interrupt
coalescing mode vs existing 72 reply queue will work without any interrupt
coalescing.   Best way to map additional 16 reply queue is map it to the
local numa node.

I understand that, it is unique requirement but at the same time we may be
able to do it gracefully (in irq sub system) as you mentioned  "
irq_set_affinity_hint" should be avoided in low level driver.



>
> 1) Allocate 72 reply queues which get nicely spread out to every CPU on
the
>system with affinity spreading.
>
> 2) Have a configuration for your reply queues which allows them to be
>grouped, e.g. by phsyical package.
>
> 3) Have a mechanism to mark a reply queue offline/online and handle that
on
>CPU hotplug. That means on unplug you have to wait for the reply
queue
>which is associated to the outgoing CPU to be empty and no new
requests
>to be queued, which has to be done for the regular per CPU reply
queues
>anyway.
>
> 4) On queueing the request, flag it 'coalescing' which causes the
>hard/firmware to direct the reply to the first online reply queue in
the
>group.
>
> If the last CPU of a group goes offline, then the normal hotplug
mechanism
> takes effect and the whole thing is put 'offline' as well. This works
> nicely for all kind of scenarios even if you have more CPUs than queues.
No
> extras, no magic affinity hints, it just works.
>
> Hmm?
>
> > Yes. We did not used " pci_alloc_irq_vectors_affinity".
> > We used " pci_enable_msix_range" and manually set affinity in driver
using
> > irq_set_affinity_hint.
>
> I still regret the day when I merged that abomination.

Is it possible to have similar mapping in managed interrupt case as below
?

for (i = 0; i < 16 ; i++)
irq_set_affinity_hint (pci_irq_vector(instance->pdev,
cpumask_of_node(local_numa_node));

Currently we always see managed interrupts for pre-vectors are 0-71 and
effective cpu is always 0.
We want some changes in current API which can allow us to  pass flags
(like *local numa affinity*) and cpu-msix mapping are from local numa node
+ effective cpu are spread across local numa node.

>
> Thanks,
>
>   tglx


Re: [PATCH 2/7] Compiler Attributes: use the no-underscores syntax

2018-08-31 Thread Rasmus Villemoes
On 2018-08-31 19:05, Miguel Ojeda wrote:
> The attribute syntax optionally allows to surround attribute names
> with "__" in order to avoid collisions with macros of the same name
> (see https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html).
> 
> This homogenizes all attributes to use the syntax without underscores.

At the risk of bikeshedding, why not the other way around, exactly
because of what you write above? We have convenience macros anyway, so
those verbose leading/trailing underscores would only be in compiler*.h,
and some of the attribute names are common words that can appear as
#defines. E.g. error is defined
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c ; if that used a
BUILD_BUG_ON somewhere, the

#define __compiletime_error(message) __attribute__((error(message)))

would break.

Rasmus


Re: [PATCH 6/7] Compiler Attributes: remove unneeded sparse (__CHECKER__) tests

2018-08-31 Thread Nick Desaulniers
On Fri, Aug 31, 2018 at 10:05 AM Miguel Ojeda
 wrote:
>
> Sparse knows about a few more attributes now, so we can remove
> the __CHECKER__ conditions from them (which, in turn, allow us
> to move some of them later on to compiler_attributes.h).
>
>   * assume_aligned: since sparse's commit ffc860b ("sparse:
> ignore __assume_aligned__ attribute"), included in 0.5.1
>
>   * error: since sparse's commit 0a04210 ("sparse: Add 'error'
> to ignored attributes"), included in 0.5.0
>
>   * hotpatch: since sparse's commit 6043210 ("sparse/parse.c:
> ignore hotpatch attribute"), included in 0.5.1
>
>   * warning: since sparse's commit 977365d ("Avoid "attribute
> 'warning': unknown attribute" warning"), included in 0.4.2
>
> Cc: Eli Friedman 
> Cc: Christopher Li 
> Cc: Kees Cook 
> Cc: Ingo Molnar 
> Cc: Geert Uytterhoeven 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Masahiro Yamada 
> Cc: Joe Perches 
> Cc: Dominique Martinet 
> Cc: Nick Desaulniers 
> Cc: Linus Torvalds 
> Signed-off-by: Miguel Ojeda 
> ---
>  include/linux/compiler-gcc.h   | 6 ++
>  include/linux/compiler_types.h | 2 +-
>  2 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index fdf2fbe6d544..32e6ce06163f 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -84,14 +84,12 @@
>
>  #define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>
> -#ifndef __CHECKER__
>  #define __compiletime_warning(message) __attribute__((warning(message)))
>  #define __compiletime_error(message) __attribute__((error(message)))
>
> -#ifdef LATENT_ENTROPY_PLUGIN
> +#if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__)
>  #define __latent_entropy __attribute__((latent_entropy))
>  #endif
> -#endif /* __CHECKER__ */
>
>  /*
>   * calling noreturn functions, __builtin_unreachable() and __builtin_trap()
> @@ -139,7 +137,7 @@
>
>  /* gcc version specific checks */
>
> -#if GCC_VERSION >= 40900 && !defined(__CHECKER__)
> +#if GCC_VERSION >= 40900
>  /*
>   * __assume_aligned(n, k): Tell the optimizer that the returned
>   * pointer can be assumed to be k modulo n. The second argument is
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index 3662b19599fc..5dddc7e0c607 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -216,7 +216,7 @@ struct ftrace_likely_data {
>  #define __must_check
>  #endif
>
> -#if defined(CC_USING_HOTPATCH) && !defined(__CHECKER__)
> +#if defined(CC_USING_HOTPATCH)
>  #define notrace__attribute__((hotpatch(0, 0)))
>  #else
>  #define notrace
> __attribute__((no_instrument_function))
> --
> 2.17.1
>

Everything looks correct here.  It would be good for the sparse
maintainer to triple check the commit sha's (as those are for sparse's
code base, not the kernel's) and have their blessing.  If Chris is
happy with it, then you can add my signoff:

Reviewed-by: Nick Desaulniers 

Also, do you need to put the cc list in the commit message? Some
people do (hopefully in an automated fashion, because I'd imagine
manually to be difficult) but don't this it's required.  Doesn't
matter, just curious.

-- 
Thanks,
~Nick Desaulniers


Re: [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves

2018-08-31 Thread Dr. Greg
On Fri, Aug 31, 2018 at 10:43:30AM -0700, Sean Christopherson wrote:

Good afternoon to everyone.

> > Sorry I missed this one. To be honest I don't know. I checked the
> > SDM and all I can find is:
> >
> > "On reset, the default value is the digest of Intel's signing key."

> I confirmed the MSRs are reset any time the EPC is lost.  Not sure
> what happens if the MSRs contained a non-Intel value but feature
> control is locked with SGX launch control disabled.  I'll post an
> update when I have an answer.

It was our interpretation from the SDM that the identity modulus
signature MSR's are 'trap-door' registers.  If flexible launch control
(FLC) is enabled the platform has one opportunity to write a new
signature value, after which the registers are locked from
modification until the next platform reset.

>From a security architecture perspective it seemed that an FLC based
SGX implementation would use a modified version of TBOOT to securely
write that register once per platform boot/reset.  The architecture
that is being discussed where there is a need to continually check
whether or not the correct root signing key is loaded sounds a bit
clunky at best.

At worst it has potential security implications since it is the
reponsibility of the enclave launch control infrastructure to control
which enclaves are allowed to have the PROVISION_KEY attribute bit
set.

Have a good weekend.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"Extensive interviews show that not one alcoholic has ever actually seen
 a pink elephant."
-- Yale University
   Center of Alcohol Studies


Re: [PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework

2018-08-31 Thread Frank Rowand
On 08/31/18 13:55, Bjorn Andersson wrote:
> On Fri 31 Aug 13:41 PDT 2018, Frank Rowand wrote:
> 
>> On 08/30/18 21:07, Bjorn Andersson wrote:
>>> On Thu 30 Aug 20:57 PDT 2018, Frank Rowand wrote:
>>>
 Hi Bjorn,


 On 04/19/18 18:17, Bjorn Andersson wrote:
> Attempt to acquire the APCS IPC through the mailbox framework and fall
> back to the old syscon based approach, to allow us to move away from
> using the syscon.
>
> Reviewed-by: Arun Kumar Neelakantam 
> Signed-off-by: Bjorn Andersson 
> ---
>
> Changes since v2:
> - Added comment about mbox_send_message() return value.
>
>  .../devicetree/bindings/soc/qcom/qcom,smd.txt  |  8 ++-
>  drivers/rpmsg/Kconfig  |  1 +
>  drivers/rpmsg/qcom_smd.c   | 67 
> --
>  3 files changed, 56 insertions(+), 20 deletions(-)

 This patch in the mainline Linux kernel as commit 
 ab460a2e72dabecfdabd45eb7e3ee2d73fc876d4
 causes a problem with the APQ8074 Dragonboard.  The mmc device is not set 
 up
 with the patch applied, thus I do not have the block device my root file 
 system
 is located on.

 Testing on v4.18, if I revert this commit the mmc device is available.

 I'll reply to this email with the console messages for 4.18 and for 4.18 
 with
 this commit reverted.

>>>
>>> The mmc device would fail to come up if the regulators didn't come up,
>>> which would be the result of smd not working. But it should fallback to
>>> the old mechanism if no mailbox is specified.
>>>
>>> Can you double check that CONFIG_RPMSG_QCOM_SMD is still set in your
>>> .config after applying and building with this commit included? And if
>>> not, try to enable CONFIG_MAILBOX.
>>
>> Thank you!
>>
>> That is indeed the cause.  ab460a2e72da added a "depends on MAILBOX" to
>> CONFIG_RPMSG_QCOM_SMD, so CONFIG_RPMSG_QCOM_SMD becomes unset since
>> CONFIG_MAILBOX is not enabled in qcom_defconfig and is not otherwise
>> selected for the dragonboard.
>>
> 
> Thanks for verifying this!
> 
>> Is there a config variable that should be selecting MAILBOX for a class
>> of systems that would include the APQ8074 Dragonboard?  For my testing
>> I added the "select MAILBOX" to CONFIG_ARCH_MSM8974, but I do not know
>> what systems that includes, and whether it is appropriate to do the
>> select for all of them.
>>
> 
> We typically don't use the CONFIG_ARCH_* to enable user selectable
> config options, even if they serve a critical role in the system.
> 
> So minimum change would be to add CONFIG_MAILBOX to the qcom_defconfig
> (and multi_v7_defconfig I presume). The fuller solution would be to add
> qcom,msm8974-apcs-kpss-global (.data is 8) to the qcom-apcs-ipc-mailbox
> list of compatibles and replace the syscon currently used, and then
> enable these in the defconfigs.

I would be happy with either solution.  Can I twist your arm to create
the patch?


> 
> Regards,
> Bjorn
> 



Re: [PATCH] mm: slowly shrink slabs with a relatively small number of objects

2018-08-31 Thread Roman Gushchin
On Fri, Aug 31, 2018 at 05:15:39PM -0400, Rik van Riel wrote:
> On Fri, 2018-08-31 at 13:34 -0700, Roman Gushchin wrote:
> 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index fa2c150ab7b9..c910cf6bf606 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -476,6 +476,10 @@ static unsigned long do_shrink_slab(struct
> > shrink_control *shrinkctl,
> > delta = freeable >> priority;
> > delta *= 4;
> > do_div(delta, shrinker->seeks);
> > +
> > +   if (delta == 0 && freeable > 0)
> > +   delta = min(freeable, batch_size);
> > +
> > total_scan += delta;
> > if (total_scan < 0) {
> > pr_err("shrink_slab: %pF negative objects to delete
> > nr=%ld\n",
> 
> I agree that we need to shrink slabs with fewer than
> 4096 objects, but do we want to put more pressure on
> a slab the moment it drops below 4096 than we applied
> when it had just over 4096 objects on it?
> 
> With this patch, a slab with 5000 objects on it will
> get 1 item scanned, while a slab with 4000 objects on
> it will see shrinker->batch or SHRINK_BATCH objects
> scanned every time.
> 
> I don't know if this would cause any issues, just
> something to ponder.

Hm, fair enough. So, basically we can always do

delta = max(delta, min(freeable, batch_size));

Does it look better?


> 
> If nobody things this is a problem, you can give the
> patch my:
> 
> Acked-by: Rik van Riel 
> 

Thanks!


Re: [PATCH] staging: android: ion: check for kref overflow

2018-08-31 Thread Daniel Rosenberg




On 08/31/2018 08:56 AM, Greg Kroah-Hartman wrote:

On Thu, Aug 30, 2018 at 06:36:18PM -0700, Daniel Rosenberg wrote:

The sign off was on the 4.4.y version that I cherry-picked this from.

Ah that wasn't obvious at all.  What is that git commit id?  You need to
give us a hint as to what is going on when you do that :)

b84ec04bae905901("staging: android: ion: check for kref overflow") in 4.4.y

There was a trivial conflict moving it to 4.9, but it did not modify
any changed lines, so I hadn't thought that was worth noting on the
patch. I apologise if leaving the signed-off-by was incorrect here.

Why did I only apply this to 4.4 and not 4.9 when the original patch was
submitted?  That seems odd.

thanks,

greg k-h
I don't know. I had included it in the range of kernel versions it 
should be applied to in the original patch, and noted the minor conflict 
for later kernel versions. You added it in 3.18 and 4.4, and I assumed 
not 4.9 because of the conflict in applying the patch, so I sent this 
version.


b1fa6d8acb50c8e9 ("staging: android: ion: Pull out ion ioctls to a 
separate file") is the patch that causes the minor conflict in applying 
the original patch.
4c23cbff073f3b9b ("staging: android: ion: Remove import interface") is 
the patch that removes the affected code altogether in later kernels 
versions.


Re: [rfc] leds: add TI LMU backlight driver

2018-08-31 Thread Pavel Machek
Hi!

> > Aha. I did not realize that was for same hardware... I should have
> > cc-ed you, I guess.
> 
> No worries Jacek cc'd me.

Good.

> >> I do not like this driver.
> >> I don't like that it smashes numerous devices into some structure with 
> >> varying register maps.
> >>
> > 
> > Can you elaborate? The chips are similar enough that single driver
> > makes sense, and we certainly want to maintain one driver, not 6
> > drivers differing only in .. what exactly?
> 
> Well I think it is justified to have independent drivers as each device has 
> different features from
> this basic LED driver.  If we are just looking for basic support then yes 
> this driver is fine.

> But here is where a single driver will start getting messy and support 
> difficult
> 
> LM3533 has ALS and an ADC for an ALS analog sensor
> LM3631 has no ALS functionality
> LM3632 has strobe functionality and no ramp support
> LM3633 has indicator support coupled with the hvled support
> LM3695 does not even appear to be available publicly
> LM3697 is the only device that that this driver could be used for as is.

Ok, so ... yes, I'm really interested in basic support. But drivers
seem to have a lot in common, voltage limits, for example. 

> In addition if I wanted to only support a single device I have to pull in the 
> full data
> file that defines all the other devices.  That is pretty bad to increase the 
> size of the kernel
> image to have support for devices that are not even on the target product.  
> The ti-lmu data file
> alone is ~15k, the ti-lmu code does not even build with this patch (So this 
> is a nack on the patch as it is.)
> but commenting out the offending code gives me at least ~23k more data on top
> of the ti-lmu MFD framework which is ~33k.  That is ~71k of code just to 
> support 1 LED device
> that is 3x what we have now.  That is not good for IoT devices.

> The LM3697 is 22k without ramp support.

Well, I don't think object file size is huge problem. First,
"distribution" kernel with support for 6 different chips will be ~71k,
while your proposal will result in ~136k. Second, yes, we could put
ifdefs into ti-lmu data file to make it smaller.

Anyway, clean source code and easy maintainance is more important.

> 
> And I will continue. TI LMU really means nothing unless you know what LMU 
> stands for.  But this
> also now implies support for all of TI's lighting products which will confuse 
> the heck out of
> customers and TI support staff.  We have a similar issue in our SoC sound 
> CODECs code that we are
> attempting to clean up.  We have a generic driver that is supposed to support 
> a common set of features
> but when extending support for other features the code gets very complicated 
> and it is almost more
> beneficial to re-write and create a new driver.
> 
> I would be OK with creating a ti-lmu framework that commonizes the 
> functionality and create children that
> register to that framework but even that is over kill.
>

I believe there's quite a lot of code that could be shared. 

> >> Not only that but it appears that you just pulled this driver from a repo 
> >> and posted it without clean up.
> >>
> > 
> > a) No I did not, feel free to generate a diff.
> > 
> 
> No I looked at this driver before and determined a re-write was a waste of 
> time.
> If you look that the LM3697 driver I submitted it configures the banks via 
> the config file.
> 
> Only the ramp code is missing and the code is much simpler in nature.  We 
> could adopt that
> code to extend out to the other devices as well and base the register map 
> deltas on the 
> device configuration file.  I am already using the fwnode calls and setting 
> up the banks.

Well, you may know that hardware better than I do. But if you generate
a diff...

> > b) Even if I did, why would that be a problem?
> 
> So what you are saying is all I have to do is look for other peoples work 
> pull it in to a branch
> slap a new copyright on it, push to a list and claim support?

...you'll see I did quite some changes.

> I don't think you checked with the original author on pushing it upstream.  
> Milo has not updated
> his email with a public one unless you sent him a private email and received 
> and ack on pushing
>

Tony Lindgren asked me to get support merged, and that's what I'm
trying to do. I have Milo's sign off, that means he is/was ok with
upstreaming that code; no, I did not have reason to contact him.

> > Well all 6 chips this driver supports seem to be similar enough, so
> > that single driver makes sense.
> 
> See above on device differentiation. So in my opinion a single driver that 
> supports
> basic functionality is good but when adding additional support this driver 
> will get very
> complicated as to only allow different features for different devices.

Well, the devices seem to have quite a lot in common. Yes, single
driver for all of them will be somehow complex; but I believe that's
still better than copy&pasting co

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

2018-08-31 Thread Scott Branden

Hi Olof/Ard,


On 18-08-30 09:23 AM, Ard Biesheuvel wrote:

On 30 August 2018 at 17:06, Olof Johansson  wrote:

On Wed, Aug 29, 2018 at 10:54 PM, Ard Biesheuvel
 wrote:

On 29 August 2018 at 20:59, Scott Branden  wrote:

Hi Olof,


On 18-08-29 11:44 AM, Olof Johansson wrote:

Hi,

On Wed, Aug 29, 2018 at 10:21 AM, Scott Branden
 wrote:

Enable EFI_ARMSTUB_DTB_LOADER to add support for the dtb= command line
parameter to function with efi loader.

Required to boot on existing bootloaders that do not support devicetree
provided by the platform or by the bootloader.

Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option for the
DTB loader")
Signed-off-by: Scott Branden 

Why did Ard create an option for this if it's just going be turned on
in default configs? Doesn't make sense to me.

It would help to know what firmware still is crippled and how common
it is, since it's been a few years that this has been a requirement by
now.

Broadcom NS2 and Stingray in current development and production need this
option in the kernel enabled in order to boot.

And these production systems run mainline kernels in a defconfig configuration?

The simply reality is that the DTB loader has been deprecated for a
good reason: it was only ever intended as a development hack anyway,
and if we need to treat the EFI stub provided DTB as a first class
citizen, there are things we need to fix to make things works as
expected. For instance, GRUB will put a property in the /chosen node
for the initramfs which will get dropped if you boot with dtb=.

Don't be surprised if some future enhancements of the EFI stub code
depend on !EFI_ARMSTUB_DTB_LOADER. On UEFI systems, DTBs [or ACPI
tables] are used by the firmware to describe itself and the underlying
platform to the OS, and the practice of booting with DTB file images
(taken from the kernel build as well) conflicts with that view. Note
that GRUB still permits you to load DTBs from files (and supports more
sources than just the file system the kernel Image was loaded from).

Ard,

Maybe a WARN() splat would be more useful as a phasing-out method than
removing functionality for them that needs to be reinstated through
changing the config?


We don't have any of that in the stub, and inventing new ways to pass
such information between the stub and the kernel proper seems like a
cart-before-horse kind of thing to me. The EFI stub diagnostic
messages you get on the serial console are not recorded in the kernel
log buffer, so they only appear if you actually look at the serial
output.


Once the stub and the boot method is there, it's hard to undo as we
can see here. Being loud and warn might be more useful, and set a
timeline for hard removal (12 months?).


The dtb= handling is still there, it is just not enabled by default.
We can keep it around if people are still using it. But as I pointed
out, we may decide to make new functionality available only if it is
disabled, and at that point, we'll have to choose between one or the
other in defconfig, which is annoying.

dtb= handling does need to be enabled in the only defconfig
upstreamed though.  ARM64 maintainers have mandated a single
defconfig upstreamed up this point.  If another incompatible
efistub is needed in the future then 2 kernel images would need
to be built to support booting on all platforms.



Scott; an alternative for you is to do a boot wrapper that bundles a
DT and kernel, and boot that instead of the kernel image (outside of
the kernel tree). Some 32-bit platforms from Marvell use that. That
way the kernel will just see it as a normally passed in DT.

The EFI stub is the boot wrapper?  Everything works perfectly today
with the upstream kernel (with the defconfig fix of the efistub regression).
We support a single kernel image booting with multiple DTs
(selected in UEFI and passed in via dtb= on command line).



Or use GRUB. It comes wired up in all the distros, and let's you load
a DT binary from anywhere you can imagine, as opposed to the EFI stub
which can only load it if it happens to reside in the same file system
(or even directory - I can't remember) as the kernel image. Note that
the same reservations apply to doing that - the firmware is no longer
able to describe itself to the OS via the DT, which is really the only
conduit it has available on an arm64 system..

Ard, GRUB is not a requirement to boot the kernel.  But, it sounds like
using GRUB may be a solution to your problem?  You could use GRUB
and leave the efistub alone then (or at least leave dtb= in the upstream
defconfg).

Regards,
 Scott



Re: [PATCH 1/7] Compiler Attributes: remove unused attributes

2018-08-31 Thread Nick Desaulniers
On Fri, Aug 31, 2018 at 1:23 PM Miguel Ojeda
 wrote:
>
> On Fri, Aug 31, 2018 at 8:43 PM, Nick Desaulniers
>  wrote:
> > On Fri, Aug 31, 2018 at 10:28 AM Joe Perches  wrote:
> >>
> >> On Fri, 2018-08-31 at 19:05 +0200, Miguel Ojeda wrote:
> >> > __optimize and __deprecate_for_modules are unused in
> >> > the whole kernel tree. Simply drop them.
> >>
> >> Nice series, thanks Miguel.
> >>
> >> It'd be good to have a cover letter for the series.
> >>
> >> And I believe there should be the equivalent of:
> >>
> >> #if GCC_VERSION < 40600
> >> # error Sorry, your compiler is too old - please upgrade it.
> >> #endif
> >>
> >> for compiler-intel.h and compiler-clang.h so that
> >> each supported compiler minimum version is checked.
> >>
> >> Is it clang > 13 and icc > 3 ?
> >
> > Eh, I'm not sure I want to commit yet to a specific minimal version of
> > Clang.  Right now, we're fixing things so depending on arch's and
> > configs, the answer might be Top of Tree clang builds.  For Pixel, we
> > shipped with Clang-4, but pretty quickly we needed Clang-5.
> > https://lkml.org/lkml/2017/11/22/943
> >
> > I had sent patches previously for detecting clang version from the C
> > preprocessor, maybe I should dust those off, then commit to clang 5.
>
> In my opinion, even if you require clang 7, that is fine, as long as
> we get a working build mainlined.

Clang 7 is aggressive.  I need to think more about how to call out
when a specific set of configs for a given arch requires a compiler
upgrade, without ending up with combinatoral explosion.  I don't want
to cross that bridge with this patch set.

>
> By the way, I am testing the series with clang 8 (2018-08-14) (after
> reverting e501ce957a78), and it seems to work. Hopefully that makes
> you happy! ;-)

That makes me very happy.  It indeed does produce a run-able
executable, for some subset of configs, but can't be relied upon until
we complete our implementation (WIP).  CC me on any bugs you find for
your configs.  I'm also trying to keep a handle on things in
https://github.com/ClangBuiltLinux/linux/issues.

>
> >
> > I don't think minimal supported versions are required for these clean
> > ups, and would not block these patches from landing on that.
> >
> > Also, haven't found anyone using ICC yet to comment on minimal version
> > requirements.
>
> For clang, by the way, __naked should go out of -gcc.h.

Yep, Arnd's note in the other thread was a valuable insight and I agree with it.

> I guess that
> is breaking ARM clang builds at the moment (didn't check)?

Huh?


> I will
> include the move for v3.
>
> Cheers,
> Miguel



-- 
Thanks,
~Nick Desaulniers


Re: [PATCH v2] gpio: brcmstb: allow 0 width GPIO banks

2018-08-31 Thread Gregory Fong
On Fri, Aug 17, 2018 at 4:48 PM  wrote:
>
> From: Justin Chen 
>
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
> incrementing the bank and number of GPIOs, but not initializing them.
> This will mean a call into the non-existent GPIOs will return an error.

This is clearer now; thanks for rewording!

>
> Also remove "GPIO registered" dev print. This information is misleading
> since the incremented banks and gpio_base do not reflect the actual GPIOs
> that get initialized. We leave this information out since it is already
> printed with dev_dbg.
>
> Signed-off-by: Justin Chen 

Looks like I'm a bit late on the response, but in case you feel like
adding it Linus:

Acked-by: Gregory Fong 


Re: [PATCH 05/23] selftest: vm: add unlikely() to BUG_ON()

2018-08-31 Thread Igor Stoppa

Hi Dmitry,

On 31/08/18 02:04, Dmitry Safonov wrote:


Probably, the one from "tools/include/linux/compiler.h" can be used in
tools directory.


Thank you for the advice. It seems to work now.

--
igor


[PATCH] selftest: vm: add unlikely() to BUG_ON()

2018-08-31 Thread Igor Stoppa
BUG_ON() is unlikely() to BUG()

For unlikely(), borrow the definition from tools/include/linux/compiler.h

Signed-off-by: Igor Stoppa 
Cc: Dmitry Safonov 
Cc: Shuah Khan 
Cc: linux-kselft...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 tools/testing/selftests/vm/map_populate.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/vm/map_populate.c 
b/tools/testing/selftests/vm/map_populate.c
index 6b8aeaa0bf7a..1bf8ff068dcd 100644
--- a/tools/testing/selftests/vm/map_populate.c
+++ b/tools/testing/selftests/vm/map_populate.c
@@ -21,9 +21,13 @@
 #define MMAP_SZ4096
 #endif
 
+#ifndef unlikely
+# define unlikely(x)   __builtin_expect(!!(x), 0)
+#endif
+
 #define BUG_ON(condition, description) \
do {\
-   if (condition) {\
+   if (unlikely(condition)) {  \
fprintf(stderr, "[FAIL]\t%s:%d\t%s:%s\n", __func__, \
__LINE__, (description), strerror(errno)); \
exit(1);\
-- 
2.17.1



[PATCH] clk: fix clk_calc_subtree compute duplications

2018-08-31 Thread Derek Basehore
clk_calc_subtree was called at every step up the clk tree in
clk_calc_new_rates. Since it recursively calls itself for its
children, this means it would be called once on each clk for each
step above the top clk is.

This is fixed by adding a non-recursive function called at every
step in clk_calc_new_rates that fills in new_rate, new_parent, etc.
Since the clks not called directly for clk_calc_new_rates can only
change their rate, we only set new_rate in clk_calc_subtree.
clk_calc_subtree is also only called on the top clk after it's found
via clk_calc_new_rates to remove the duplicate recursive calls.

Signed-off-by: Derek Basehore 
---
 drivers/clk/clk.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index d31055ae6ec6..52032fb1a8a2 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1609,11 +1609,18 @@ static int __clk_speculate_rates(struct clk_core *core,
return ret;
 }
 
-static void clk_calc_subtree(struct clk_core *core, unsigned long new_rate,
-struct clk_core *new_parent, u8 p_index)
+static void clk_calc_subtree(struct clk_core *core, unsigned long new_rate)
 {
struct clk_core *child;
 
+   core->new_rate = new_rate;
+   hlist_for_each_entry(child, &core->children, child_node)
+   clk_calc_subtree(child, clk_recalc(child, new_rate));
+}
+
+static void clk_set_change(struct clk_core *core, unsigned long new_rate,
+  struct clk_core *new_parent, u8 p_index)
+{
core->new_rate = new_rate;
core->new_parent = new_parent;
core->new_parent_index = p_index;
@@ -1621,11 +1628,6 @@ static void clk_calc_subtree(struct clk_core *core, 
unsigned long new_rate,
core->new_child = NULL;
if (new_parent && new_parent != core->parent)
new_parent->new_child = core;
-
-   hlist_for_each_entry(child, &core->children, child_node) {
-   child->new_rate = clk_recalc(child, new_rate);
-   clk_calc_subtree(child, child->new_rate, NULL, 0);
-   }
 }
 
 /*
@@ -1709,7 +1711,7 @@ static struct clk_core *clk_calc_new_rates(struct 
clk_core *core,
top = clk_calc_new_rates(parent, best_parent_rate);
 
 out:
-   clk_calc_subtree(core, new_rate, parent, p_index);
+   clk_set_change(core, new_rate, parent, p_index);
 
return top;
 }
@@ -1910,6 +1912,8 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (ret)
return ret;
 
+   clk_calc_subtree(top, top->new_rate);
+
/* notify that we are about to change rates */
fail_clk = clk_propagate_rate_change(top, PRE_RATE_CHANGE);
if (fail_clk) {
-- 
2.19.0.rc1.350.ge57e33dbd1-goog



Cutting out

2018-08-31 Thread Jimmy Wilson

Hi,

Have you received my email from last week?

I would like to speak with the person who manage your photos for your
company?

We are here to provide you all kinds of imaging editing.

What we can provide you:
Cutting out for photos
Clipping path for photos
Masking for photos
Retouching for your photos
Retouching for the Beauty Model and Portraits.

We have 20 staffs in house and daily basis 1000 images can be processed.

We give testing for your photos.

Thanks,
Jimmy Wilson



Re: [PATCH RESEND] mips: switch to NO_BOOTMEM

2018-08-31 Thread Mike Rapoport
Hi Paul,

On Thu, Aug 30, 2018 at 02:48:57PM -0700, Paul Burton wrote:
> Hi Mike,
> 
> On Mon, Aug 27, 2018 at 10:59:35AM +0300, Mike Rapoport wrote:
> > MIPS already has memblock support and all the memory is already registered
> > with it.
> > 
> > This patch replaces bootmem memory reservations with memblock ones and
> > removes the bootmem initialization.
> > 
> > Signed-off-by: Mike Rapoport 
> > ---
> > 
> >  arch/mips/Kconfig  |  1 +
> >  arch/mips/kernel/setup.c   | 89 
> > +-
> >  arch/mips/loongson64/loongson-3/numa.c | 34 ++---
> >  arch/mips/sgi-ip27/ip27-memory.c   | 11 ++---
> >  4 files changed, 33 insertions(+), 102 deletions(-)
> 
> Thanks for working on this. Unfortunately it breaks boot for at least a
> 32r6el_defconfig kernel on QEMU:
> 
>   $ qemu-system-mips64el \
> -M boston \
> -kernel arch/mips/boot/vmlinux.gz.itb \
> -serial stdio \
> -append "earlycon=uart8250,mmio32,0x17ffe000,115200 console=ttyS0,115200 
> debug memblock=debug mminit_loglevel=4"
>   [0.00] Linux version 4.19.0-rc1-8-g82d0f342eecd 
> (pburton@pburton-laptop) (gcc version 8.1.0 (GCC)) #23 SMP Thu Aug 30 
> 14:38:06 PDT 2018
>   [0.00] CPU0 revision is: 0001a900 (MIPS I6400)
>   [0.00] FPU revision is: 20f30300
>   [0.00] MSA revision is: 0300
>   [0.00] MIPS: machine is img,boston
>   [0.00] Determined physical RAM map:
>   [0.00]  memory: 1000 @  (usable)
>   [0.00]  memory: 3000 @ 9000 (usable)
>   [0.00] earlycon: uart8250 at MMIO32 0x17ffe000 (options '115200')
>   [0.00] bootconsole [uart8250] enabled
>   [0.00] memblock_reserve: [0x-0x009a8fff] 
> setup_arch+0x224/0x718
>   [0.00] memblock_reserve: [0x0136-0x01361ca7] 
> setup_arch+0x3d8/0x718
>   [0.00] Initrd not found or empty - disabling initrd
>   [0.00] memblock_virt_alloc_try_nid: 7336 bytes align=0x40 nid=-1 
> from=0x max_addr=0x early_init_dt_alloc_memory_arch+0x20/0x2c
>   [0.00] memblock_reserve: [0xbfffe340-0xbfe7] 
> memblock_virt_alloc_internal+0x120/0x1ec
>   
> 
> It looks like we took a TLB store exception after calling memset() with
> a bogus address from memblock_virt_alloc_try_nid() or something inlined
> into it.

Memblock tries to allocate from the top and the resulting address ends up
in the high memory. 

With the hunk below I was able to get to "VFS: Cannot open root device"

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 4114d3c..4a9b0f7 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -577,6 +577,8 @@ static void __init bootmem_init(void)
 * Reserve initrd memory if needed.
 */
finalize_initrd();
+
+   memblock_set_bottom_up(true);
 }
 
 #endif /* CONFIG_SGI_IP27 */
 
> This was with your patch applied atop the mips-next branch from [1],
> which is currently at commit 35d017947401 ("MIPS: ralink: Add rt3352
> SPI_CS1 pinmux").
> 
> Thanks,
> Paul
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git
> 

-- 
Sincerely yours,
Mike.



Re: [PATCH 5/8] RISC-V: Rename im_okay_therefore_i_am to found_boot_cpu

2018-08-31 Thread Atish Patra

On 8/30/18 10:54 PM, Christoph Hellwig wrote:

On Thu, Aug 30, 2018 at 09:11:11AM -0700, Atish Patra wrote:

On 8/30/18 7:41 AM, Christoph Hellwig wrote:

struct device_node *dn = NULL;
-   int hart, im_okay_therefore_i_am = 0;
+   int hart, found_boot_cpu = 0;


If you rename this anyway please switch to use a bool.



I can address the comment on this patch and fold it in my series to avoid
unnecessary conflict.

@Palmer: You can drop this patch.


If Palmer is ok with it how about you include a respin of his whole
series?  There are some overlaps I think and having a single person
in charge might be helpful.



Sure. I am fine with it. Palmer ?


Btw, I've found your series in my linux-kernel folder, but it did
not make it to linux-riscv or my personal inbox despite the CC.



Thanks for the review.
I checked my scripts. I couldn't figure out what went wrong.
Not sure if there was some issue with infradead.org at that time.

Anyways, sorry again for the mess. I will keep a watch on this next time.

Regards,
Atish


Re: [PATCH 4/7] Compiler Attributes: homogenize __must_be_array

2018-08-31 Thread Nick Desaulniers
On Fri, Aug 31, 2018 at 10:05 AM Miguel Ojeda
 wrote:
>
> Different definitions of __must_be_array:
>
>   * gcc: disabled for __CHECKER__
>
>   * clang: same definition as gcc's, but without __CHECKER__
>
>   * intel: the comment claims __builtin_types_compatible_p()
> is unsupported; but icc seems to support it since 13.0.1
> (released in 2012). See https://godbolt.org/z/S0l6QQ

Indeed.  It seems that if we can't find a contact for ICC, then 13.0.1
(the oldest version supported by godbolt) is a best effort, IMO.  If
we end up adding patches for minimal compiler versions, maybe v13.0.1
is a good minimal for ICC.  But I would really defer to someone who
has an install of ICC (not me).

>
> Therefore, we can remove all of them and have a single definition
> in compiler.h
>
> Cc: Eli Friedman 
> Cc: Christopher Li 
> Cc: Kees Cook 
> Cc: Ingo Molnar 
> Cc: Geert Uytterhoeven 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Masahiro Yamada 
> Cc: Joe Perches 
> Cc: Dominique Martinet 
> Cc: Nick Desaulniers 
> Cc: Linus Torvalds 
> Signed-off-by: Miguel Ojeda 
> ---
>  include/linux/compiler-clang.h | 1 -
>  include/linux/compiler-gcc.h   | 7 ---
>  include/linux/compiler-intel.h | 3 ---
>  include/linux/compiler.h   | 7 +++
>  4 files changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index efda74f4eeba..0aee694d3ab8 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -41,6 +41,5 @@
>   * compilers, like ICC.
>   */
>  #define barrier() __asm__ __volatile__("" : : : "memory")
> -#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
>  #define __assume_aligned(a, ...)   \
> __attribute__((assume_aligned(a, ## __VA_ARGS__)))
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index dbfbecf703f8..66e1eb8822d9 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -68,13 +68,6 @@
>   */
>  #define uninitialized_var(x) x = x
>
> -#ifdef __CHECKER__
> -#define __must_be_array(a) 0
> -#else
> -/* &a[0] degrades to a pointer: a different type from an array */
> -#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> -#endif
> -
>  #ifdef RETPOLINE
>  #define __noretpoline __attribute__((indirect_branch("keep")))
>  #endif
> diff --git a/include/linux/compiler-intel.h b/include/linux/compiler-intel.h
> index 4c7f9befa9f6..18bd4362deaa 100644
> --- a/include/linux/compiler-intel.h
> +++ b/include/linux/compiler-intel.h
> @@ -29,9 +29,6 @@
>   */
>  #define OPTIMIZER_HIDE_VAR(var) barrier()
>
> -/* Intel ECC compiler doesn't support __builtin_types_compatible_p() */
> -#define __must_be_array(a) 0
> -
>  #endif
>
>  /* icc has this, but it's called _bswap16 */
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index e0e55eb3f242..e4a702f99e50 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -357,4 +357,11 @@ static inline void *offset_to_ptr(const int *off)
> compiletime_assert(__native_word(t),\
> "Need native word sized stores/loads for atomicity.")
>
> +#ifdef __CHECKER__
> +#define __must_be_array(a) 0
> +#else
> +/* &a[0] degrades to a pointer: a different type from an array */
> +#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> +#endif
> +
>  #endif /* __LINUX_COMPILER_H */
> --
> 2.17.1
>

Reviewed-by: Nick Desaulniers 

-- 
Thanks,
~Nick Desaulniers


Re: [PATCH] mm: slowly shrink slabs with a relatively small number of objects

2018-08-31 Thread Rik van Riel
On Fri, 2018-08-31 at 13:34 -0700, Roman Gushchin wrote:

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fa2c150ab7b9..c910cf6bf606 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -476,6 +476,10 @@ static unsigned long do_shrink_slab(struct
> shrink_control *shrinkctl,
>   delta = freeable >> priority;
>   delta *= 4;
>   do_div(delta, shrinker->seeks);
> +
> + if (delta == 0 && freeable > 0)
> + delta = min(freeable, batch_size);
> +
>   total_scan += delta;
>   if (total_scan < 0) {
>   pr_err("shrink_slab: %pF negative objects to delete
> nr=%ld\n",

I agree that we need to shrink slabs with fewer than
4096 objects, but do we want to put more pressure on
a slab the moment it drops below 4096 than we applied
when it had just over 4096 objects on it?

With this patch, a slab with 5000 objects on it will
get 1 item scanned, while a slab with 4000 objects on
it will see shrinker->batch or SHRINK_BATCH objects
scanned every time.

I don't know if this would cause any issues, just
something to ponder.

If nobody things this is a problem, you can give the
patch my:

Acked-by: Rik van Riel 

-- 
All Rights Reversed.


signature.asc
Description: This is a digitally signed message part


Re: [PATCH 3/7] Compiler Attributes: remove unneeded tests

2018-08-31 Thread Nick Desaulniers
On Fri, Aug 31, 2018 at 10:05 AM Miguel Ojeda
 wrote:
>
> Attributes const and always_inline have tests around them
> which are unneeded, since they are supported by gcc >= 4.6,
> clang >= 3 and icc >= 13. See https://godbolt.org/z/no0OZH
>
> In the case of gnu_inline, we do not need to test for
> __GNUC_STDC_INLINE__ because, regardless of the current
> inlining behavior, we can simply always force the old
> GCC inlining behavior by using the attribute in all cases.
>
> Cc: Eli Friedman 
> Cc: Christopher Li 
> Cc: Kees Cook 
> Cc: Ingo Molnar 
> Cc: Geert Uytterhoeven 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Masahiro Yamada 
> Cc: Joe Perches 
> Cc: Dominique Martinet 
> Cc: Nick Desaulniers 
> Cc: Linus Torvalds 
> Signed-off-by: Miguel Ojeda 
> ---
>  include/linux/compiler_types.h | 19 ++-
>  1 file changed, 2 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index 7cd958360ead..3662b19599fc 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -158,10 +158,6 @@ struct ftrace_likely_data {
> (sizeof(t) == sizeof(char) || sizeof(t) == sizeof(short) || \
>  sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long))
>
> -#ifndef __attribute_const__
> -#define __attribute_const____attribute__((const))
> -#endif
> -

If there's a v2, you could order this before the patch that removed
the underscores so that patch is smaller.  Doesn't really matter
though.

>  #ifndef __noclone
>  #define __noclone
>  #endif
> @@ -196,6 +192,7 @@ struct ftrace_likely_data {
>   * [...]
>   */
>  #define __pure __attribute__((pure))
> +#define __const__attribute__((const))
>  #define __aligned(x)   __attribute__((aligned(x)))
>  #define __aligned_largest  __attribute__((aligned))
>  #define __printf(a, b) __attribute__((format(printf, a, b)))
> @@ -227,17 +224,7 @@ struct ftrace_likely_data {
>
>  #define __compiler_offsetof(a, b)  __builtin_offsetof(a, b)
>
> -/*
> - * Feature detection for gnu_inline (gnu89 extern inline semantics). Either
> - * __GNUC_STDC_INLINE__ is defined (not using gnu89 extern inline semantics,
> - * and we opt in to the gnu89 semantics), or __GNUC_STDC_INLINE__ is not
> - * defined so the gnu89 semantics are the default.
> - */
> -#ifdef __GNUC_STDC_INLINE__
> -# define __gnu_inline  __attribute__((gnu_inline))
> -#else
> -# define __gnu_inline
> -#endif
> +#define __gnu_inline   __attribute__((gnu_inline))

Can this be moved into the block above with all the rest of required attributes?

>
>  /*
>   * Force always-inline if the user requests it so via the .config.
> @@ -263,9 +250,7 @@ struct ftrace_likely_data {
>  #define __inline inline
>  #define noinline   __attribute__((noinline))
>
> -#ifndef __always_inline
>  #define __always_inline inline __attribute__((always_inline))
> -#endif

Ditto.

>
>  /*
>   * Rather then using noinline to prevent stack consumption, use
> --
> 2.17.1
>

With the requested changes,
Reviewed-by: Nick Desaulniers 

-- 
Thanks,
~Nick Desaulniers


  1   2   3   4   5   >