Re: [PATCH/RFC 3/9] perf symbols: Discard symbols in kallsyms for loaded modules

[Namhyung Kim]

On Fri, Jun 23, 2017 at 10:51:05AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 23, 2017 at 02:48:21PM +0900, Namhyung Kim escreveu:
> > If a module is already loaded, it should have symbols and no need to
> > load new symbols from kallsyms.  Actually kallsyms can have different
> > addresses if the module was reloaded.
> 
> Well, if it is loaded, then it should match what is in kallsyms, no?

No, the perf.data was recorded with a module, and then the module was
modified and reloaded at the same address.

Maybe the word "loaded" can be confusing - if perf.data file has
symbols in the module v1 but kallsyms has symbols in the module v2.
So it needs to read symbols from the module v1 (in the build-id cache).

>  
> > Current code just discards the first symbols only, but it should do the
> > same for all symbols in the module.  Note that the kernel doesn't set
> > the dso->loaded bit so simply checking it would do the job IMHO.
> 
> The kernel sets dso->loaded? Can you rephrase this part? And if this
> procedure doesn't set dso->loaded how can simply checking it do the job?
> 
> Can you clarify the above sentence? Please elaborate the scenario more
> fully.

Oh, I made it confusing, sorry..  I mean that it's in the middle of
the dso__load() so the (kernel) dso->loaded bit was not set yet.

Thanks,
Namhyung


> 
> - Arnaldo
>  
> > Cc: Adrian Hunter 
> > Cc: Wang Nan 
> > Signed-off-by: Namhyung Kim 
> > ---
> >  tools/perf/util/symbol.c | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index e7a98dbd2aed..74078ba595b3 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -787,11 +787,12 @@ static int dso__split_kallsyms(struct dso *dso, 
> > struct map *map, u64 delta)
> > curr_map = map;
> > goto discard_symbol;
> > }
> > -
> > -   if (curr_map->dso->loaded &&
> > -   !machine__is_default_guest(machine))
> > -   goto discard_symbol;
> > }
> > +
> > +   if (curr_map->dso->loaded &&
> > +   !machine__is_default_guest(machine))
> > +   goto discard_symbol;
> > +
> > /*
> >  * So that we look just like we get from .ko files,
> >  * i.e. not prelinked, relative to map->start.
> > -- 
> > 2.13.1

[PATCH] stm32-dcmi: fix semicolon.cocci warnings

[kbuild test robot]

drivers/media/platform/stm32/stm32-dcmi.c:808:2-3: Unneeded semicolon
drivers/media/platform/stm32/stm32-dcmi.c:562:2-3: Unneeded semicolon
drivers/media/platform/stm32/stm32-dcmi.c:762:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: a8a270dedb25 ("stm32-dcmi: crop sensor image to match user resolution")
CC: Hugues Fruchet 
Signed-off-by: Fengguang Wu 
---

 stm32-dcmi.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -559,7 +559,7 @@ static int dcmi_start_streaming(struct v
 
/* Enable crop */
val |= CR_CROP;
-   };
+   }
 
reg_write(dcmi->regs, DCMI_CR, val);
 
@@ -759,7 +759,7 @@ static int dcmi_try_fmt(struct stm32_dcm
/* Restore width/height */
pixfmt->width = width;
pixfmt->height = height;
-   };
+   }
 
pixfmt->field = V4L2_FIELD_NONE;
pixfmt->bytesperline = pixfmt->width * dcmi_fmt->bpp;
@@ -805,7 +805,7 @@ static int dcmi_set_fmt(struct stm32_dcm
mf->width, mf->height,
dcmi->crop.width, dcmi->crop.height,
dcmi->crop.left, dcmi->crop.top);
-   };
+   }
 
dcmi->fmt = *f;
dcmi->current_fmt = current_fmt;

[PATCH] soc/qman: Change a comment for an entry check insid drain_mr_fqrni function

[Karim Eshapa]

Change the comment for an entry check inside function
drain_mr_fqrni() with sleep for sufficient period
of time instead of long time proccessor cycles.

Signed-off-by: Karim Eshapa 
---
 drivers/soc/fsl/qbman/qman.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 18d391e..636a7d7 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1071,18 +1071,19 @@ static int drain_mr_fqrni(struct qm_portal *p)
msg = qm_mr_current(p);
if (!msg) {
/*
-* if MR was full and h/w had other FQRNI entries to produce, we
-* need to allow it time to produce those entries once the
-* existing entries are consumed. A worst-case situation
-* (fully-loaded system) means h/w sequencers may have to do 3-4
-* other things before servicing the portal's MR pump, each of
-* which (if slow) may take ~50 qman cycles (which is ~200
-* processor cycles). So rounding up and then multiplying this
-* worst-case estimate by a factor of 10, just to be
-* ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
-* one entry at a time, so h/w has an opportunity to produce new
-* entries well before the ring has been fully consumed, so
-* we're being *really* paranoid here.
+* if MR was full and h/w had other FQRNI entries to
+* produce, we need to allow it time to produce those
+* entries once the existing entries are consumed.
+* A worst-case situation (fully-loaded system) means
+* h/w sequencers may have to do 3-4 other things
+* before servicing the portal's MR pump, each of
+* which (if slow) may take ~50 qman cycles
+* (which is ~200 processor cycles). So sleep with
+* 1 ms would be very sufficient, after this period
+* we can check if there is something produced.
+* NB, we consume one entry at a time, so h/w has
+* an opportunity to produce new entries well before
+* the ring has been fully consumed.
 */
msleep(1);
msg = qm_mr_current(p);
-- 
2.7.4

[PATCH] modsign: add markers to endif-statements in certs/Makefile

[Jarkko Sakkinen]

It's a bit hard for eye to track certs/Makefile if you are not
accustomed to it. This commit adds comments to key endif statements in
order to help to keep the context while reading this file.

Signed-off-by: Jarkko Sakkinen 
---
 certs/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/certs/Makefile b/certs/Makefile
index 4119bb376ea1..847361ce14d1 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -26,7 +26,7 @@ quiet_cmd_extract_certs  = EXTRACT_CERTS   $(patsubst 
"%",%,$(2))
 targets += x509_certificate_list
 $(obj)/x509_certificate_list: scripts/extract-cert 
$(SYSTEM_TRUSTED_KEYS_SRCPREFIX)$(SYSTEM_TRUSTED_KEYS_FILENAME) FORCE
$(call 
if_changed,extract_certs,$(SYSTEM_TRUSTED_KEYS_SRCPREFIX)$(CONFIG_SYSTEM_TRUSTED_KEYS))
-endif
+endif # CONFIG_SYSTEM_TRUSTED_KEYRING
 
 clean-files := x509_certificate_list .x509.list
 
@@ -87,7 +87,7 @@ $(obj)/x509.genkey:
@echo >>$@ "keyUsage=digitalSignature"
@echo >>$@ "subjectKeyIdentifier=hash"
@echo >>$@ "authorityKeyIdentifier=keyid"
-endif
+endif # CONFIG_MODULE_SIG_KEY
 
 $(eval $(call config_filename,MODULE_SIG_KEY))
 
@@ -102,4 +102,4 @@ $(obj)/system_certificates.o: $(obj)/signing_key.x509
 targets += signing_key.x509
 $(obj)/signing_key.x509: scripts/extract-cert $(X509_DEP) FORCE
$(call 
if_changed,extract_certs,$(MODULE_SIG_KEY_SRCPREFIX)$(CONFIG_MODULE_SIG_KEY))
-endif
+endif # CONFIG_MODULE_SIG
-- 
2.11.0

[PATCH 03/10] x86/hyper-v: make hv_do_hypercall() inline

[kys]

From: Vitaly Kuznetsov 

We have only three call sites for hv_do_hypercall() and we're going to
change HVCALL_SIGNAL_EVENT to doing fast hypercall so we can inline this
function for optimization.

Hyper-V top level functional specification states that r9-r11 registers
and flags may be clobbered by the hypervisor during hypercall and with
inlining this is somewhat important, add the clobbers.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Andy Shevchenko 
Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/hyperv/hv_init.c   |   54 +++---
 arch/x86/include/asm/mshyperv.h |   39 
 drivers/hv/connection.c |2 +
 include/linux/hyperv.h  |1 -
 4 files changed, 46 insertions(+), 50 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 5b882cc..691603e 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -75,7 +75,8 @@ static u64 read_hv_clock_msr(struct clocksource *arg)
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-static void *hypercall_pg;
+void *hv_hypercall_pg;
+EXPORT_SYMBOL_GPL(hv_hypercall_pg);
 struct clocksource *hyperv_cs;
 EXPORT_SYMBOL_GPL(hyperv_cs);
 
@@ -102,15 +103,15 @@ void hyperv_init(void)
guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
 
-   hypercall_pg  = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
-   if (hypercall_pg == NULL) {
+   hv_hypercall_pg  = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
+   if (hv_hypercall_pg == NULL) {
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
return;
}
 
rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
hypercall_msr.enable = 1;
-   hypercall_msr.guest_physical_address = vmalloc_to_pfn(hypercall_pg);
+   hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
 
/*
@@ -170,51 +171,6 @@ void hyperv_cleanup(void)
 }
 EXPORT_SYMBOL_GPL(hyperv_cleanup);
 
-/*
- * hv_do_hypercall- Invoke the specified hypercall
- */
-u64 hv_do_hypercall(u64 control, void *input, void *output)
-{
-   u64 input_address = (input) ? virt_to_phys(input) : 0;
-   u64 output_address = (output) ? virt_to_phys(output) : 0;
-#ifdef CONFIG_X86_64
-   u64 hv_status = 0;
-
-   if (!hypercall_pg)
-   return (u64)ULLONG_MAX;
-
-   __asm__ __volatile__("mov %0, %%r8" : : "r" (output_address) : "r8");
-   __asm__ __volatile__("call *%3" : "=a" (hv_status) :
-"c" (control), "d" (input_address),
-"m" (hypercall_pg));
-
-   return hv_status;
-
-#else
-
-   u32 control_hi = control >> 32;
-   u32 control_lo = control & 0x;
-   u32 hv_status_hi = 1;
-   u32 hv_status_lo = 1;
-   u32 input_address_hi = input_address >> 32;
-   u32 input_address_lo = input_address & 0x;
-   u32 output_address_hi = output_address >> 32;
-   u32 output_address_lo = output_address & 0x;
-
-   if (!hypercall_pg)
-   return (u64)ULLONG_MAX;
-
-   __asm__ __volatile__ ("call *%8" : "=d"(hv_status_hi),
- "=a"(hv_status_lo) : "d" (control_hi),
- "a" (control_lo), "b" (input_address_hi),
- "c" (input_address_lo), "D"(output_address_hi),
- "S"(output_address_lo), "m" (hypercall_pg));
-
-   return hv_status_lo | ((u64)hv_status_hi << 32);
-#endif /* !x86_64 */
-}
-EXPORT_SYMBOL_GPL(hv_do_hypercall);
-
 void hyperv_report_panic(struct pt_regs *regs)
 {
static bool panic_reported;
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 115a0e2..a004b3b 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -171,6 +171,45 @@ static inline void vmbus_signal_eom(struct hv_message 
*msg, u32 old_msg_type)
 
 #if IS_ENABLED(CONFIG_HYPERV)
 extern struct clocksource *hyperv_cs;
+extern void *hv_hypercall_pg;
+
+static inline u64 hv_do_hypercall(u64 control, void *input, void *output)
+{
+   u64 input_address = input ? virt_to_phys(input) : 0;
+   u64 output_address = output ? virt_to_phys(output) : 0;
+   u64 hv_status;
+   register void *__sp asm(_ASM_SP);
+
+#ifdef CONFIG_X86_64
+   if (!hv_hypercall_pg)
+   return U64_MAX;
+
+   __asm__ __volatile__("mov %4, %%r8\n"
+"call *%5"
+: "=a" (hv_status), "+r" (__sp),
+  "+c" (control), "+d" (input_address)
+:  "r" (output_address), "m" (hv_hypercall_pg)
+: "cc", "memory", "r8", "r9", "r10", "r11");

[PATCH 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

[kys]

From: Vitaly Kuznetsov 

Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others().
Tracing is done the same way we do xen_mmu_flush_tlb_others().

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 MAINTAINERS |1 +
 arch/x86/hyperv/mmu.c   |7 ++
 arch/x86/include/asm/trace/hyperv.h |   38 +++
 3 files changed, 46 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/include/asm/trace/hyperv.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e7c834..a0967d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6169,6 +6169,7 @@ M:Stephen Hemminger 
 L: de...@linuxdriverproject.org
 S: Maintained
 F: arch/x86/include/asm/mshyperv.h
+F: arch/x86/include/asm/trace/hyperv.h
 F: arch/x86/include/uapi/asm/hyperv.h
 F: arch/x86/kernel/cpu/mshyperv.c
 F: arch/x86/hyperv
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index 0712111..cb35453 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -8,6 +8,9 @@
 #include 
 #include 
 
+#define CREATE_TRACE_POINTS
+#include 
+
 /* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
 struct hv_flush_pcpu {
u64 address_space;
@@ -103,6 +106,8 @@ static void hyperv_flush_tlb_others(const struct cpumask 
*cpus,
u64 status = U64_MAX;
unsigned long flags;
 
+   trace_hyperv_mmu_flush_tlb_others(cpus, mm, start, end);
+
if (!pcpu_flush || !hv_hypercall_pg)
goto do_native;
 
@@ -172,6 +177,8 @@ static void hyperv_flush_tlb_others_ex(const struct cpumask 
*cpus,
u64 status = U64_MAX;
unsigned long flags;
 
+   trace_hyperv_mmu_flush_tlb_others(cpus, mm, start, end);
+
if (!pcpu_flush_ex || !hv_hypercall_pg)
goto do_native;
 
diff --git a/arch/x86/include/asm/trace/hyperv.h 
b/arch/x86/include/asm/trace/hyperv.h
new file mode 100644
index 000..e44ece1
--- /dev/null
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -0,0 +1,38 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM hyperv
+
+#if !defined(_TRACE_HYPERV_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_HYPERV_H
+
+#include 
+
+#if IS_ENABLED(CONFIG_HYPERV)
+
+TRACE_EVENT(hyperv_mmu_flush_tlb_others,
+   TP_PROTO(const struct cpumask *cpus, struct mm_struct *mm,
+unsigned long addr, unsigned long end),
+   TP_ARGS(cpus, mm, addr, end),
+   TP_STRUCT__entry(
+   __field(unsigned int, ncpus)
+   __field(struct mm_struct *, mm)
+   __field(unsigned long, addr)
+   __field(unsigned long, end)
+   ),
+   TP_fast_assign(__entry->ncpus = cpumask_weight(cpus);
+  __entry->mm = mm;
+  __entry->addr = addr,
+  __entry->end = end),
+   TP_printk("ncpus %d mm %p addr %lx, end %lx",
+ __entry->ncpus, __entry->mm, __entry->addr, __entry->end)
+   );
+
+#endif /* CONFIG_HYPERV */
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH asm/trace/
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE hyperv
+#endif /* _TRACE_HYPERV_H */
+
+/* This part must be outside protection */
+#include 
-- 
1.7.1

[PATCH 09/10] x86/hyper-v: support extended CPU ranges for TLB flush hypercalls

[kys]

From: Vitaly Kuznetsov 

Hyper-V hosts may support more than 64 vCPUs, we need to use
HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX/LIST_EX hypercalls in this
case.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/hyperv/mmu.c  |  130 +++-
 arch/x86/include/uapi/asm/hyperv.h |   10 +++
 2 files changed, 138 insertions(+), 2 deletions(-)

diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index fe87ffe..0712111 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -16,11 +16,25 @@ struct hv_flush_pcpu {
u64 gva_list[];
 };
 
+/* HvFlushVirtualAddressSpaceEx, HvFlushVirtualAddressListEx hypercalls */
+struct hv_flush_pcpu_ex {
+   u64 address_space;
+   u64 flags;
+   struct {
+   u64 format;
+   u64 valid_bank_mask;
+   u64 bank_contents[];
+   } hv_vp_set;
+   u64 gva_list[];
+};
+
 /* Each gva in gva_list encodes up to 4096 pages to flush */
 #define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
 
 static struct hv_flush_pcpu __percpu *pcpu_flush;
 
+static struct hv_flush_pcpu_ex __percpu *pcpu_flush_ex;
+
 /*
  * Fills in gva_list starting from offset. Returns the number of items filled
  * in gva_list (including offset)
@@ -52,6 +66,34 @@ static inline int fill_gva_list(u64 gva_list[], int offset,
return gva_n;
 }
 
+/* Return the number of banks in the resulting vp_set */
+static inline int cpumask_to_vp_set(struct hv_flush_pcpu_ex *flush,
+   const struct cpumask *cpus)
+{
+   int cpu, vcpu, vcpu_bank, vcpu_offset, nr_bank = 1;
+
+   /*
+* Some banks may end up being empty but this is acceptable.
+*/
+   for_each_cpu(cpu, cpus) {
+   vcpu = hv_cpu_number_to_vp_number(cpu);
+   vcpu_bank = vcpu / 64;
+   vcpu_offset = vcpu % 64;
+
+   /* valid_bank_mask can represent up to 64 banks */
+   if (vcpu_bank >= 64)
+   return 0;
+
+   __set_bit(vcpu_offset, (unsigned long *)
+ >hv_vp_set.bank_contents[vcpu_bank]);
+   if (vcpu_bank >= nr_bank)
+   nr_bank = vcpu_bank + 1;
+   }
+   flush->hv_vp_set.valid_bank_mask = GENMASK_ULL(nr_bank - 1, 0);
+
+   return nr_bank;
+}
+
 static void hyperv_flush_tlb_others(const struct cpumask *cpus,
struct mm_struct *mm, unsigned long start,
unsigned long end)
@@ -120,16 +162,100 @@ static void hyperv_flush_tlb_others(const struct cpumask 
*cpus,
native_flush_tlb_others(cpus, mm, start, end);
 }
 
+static void hyperv_flush_tlb_others_ex(const struct cpumask *cpus,
+  struct mm_struct *mm,
+  unsigned long start,
+  unsigned long end)
+{
+   int nr_bank = 0, max_gvas, gva_n;
+   struct hv_flush_pcpu_ex *flush;
+   u64 status = U64_MAX;
+   unsigned long flags;
+
+   if (!pcpu_flush_ex || !hv_hypercall_pg)
+   goto do_native;
+
+   if (cpumask_empty(cpus))
+   return;
+
+   local_irq_save(flags);
+
+   flush = this_cpu_ptr(pcpu_flush_ex);
+
+   if (mm) {
+   flush->address_space = virt_to_phys(mm->pgd);
+   flush->flags = 0;
+   } else {
+   flush->address_space = 0;
+   flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
+   }
+
+   flush->hv_vp_set.valid_bank_mask = 0;
+
+   if (!cpumask_equal(cpus, cpu_present_mask)) {
+   flush->hv_vp_set.format = HV_GENERIC_SET_SPARCE_4K;
+   nr_bank = cpumask_to_vp_set(flush, cpus);
+   }
+
+   if (!nr_bank) {
+   flush->hv_vp_set.format = HV_GENERIC_SET_ALL;
+   flush->flags |= HV_FLUSH_ALL_PROCESSORS;
+   }
+
+   /*
+* We can flush not more than max_gvas with one hypercall. Flush the
+* whole address space if we were asked to do more.
+*/
+   max_gvas =
+   (PAGE_SIZE - sizeof(*flush) - nr_bank *
+sizeof(flush->hv_vp_set.bank_contents[0])) /
+   sizeof(flush->gva_list[0]);
+
+   if (end == TLB_FLUSH_ALL) {
+   flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
+   status = hv_do_rep_hypercall(
+   HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX,
+   0, nr_bank + 2, flush, NULL);
+   } else if (end && ((end - start)/HV_TLB_FLUSH_UNIT) > max_gvas) {
+   status = hv_do_rep_hypercall(
+   HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX,
+   0, nr_bank + 2, flush, NULL);
+   } else {
+   gva_n = fill_gva_list(flush->gva_list, nr_bank, start, end);
+   

[PATCH 08/10] x86/hyper-v: use hypercall for remote TLB flush

[kys]

From: Vitaly Kuznetsov 

Hyper-V host can suggest us to use hypercall for doing remote TLB flush,
this is supposed to work faster than IPIs.

Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls
we need to put the input somewhere in memory and we don't really want to
have memory allocation on each call so we pre-allocate per cpu memory areas
on boot.

pv_ops patching is happening very early so we need to separate
hyperv_setup_mmu_ops() and hyper_alloc_mmu().

It is possible and easy to implement local TLB flushing too and there is
even a hint for that. However, I don't see a room for optimization on the
host side as both hypercall and native tlb flush will result in vmexit. The
hint is also not set on modern Hyper-V versions.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/hyperv/Makefile   |2 +-
 arch/x86/hyperv/hv_init.c  |2 +
 arch/x86/hyperv/mmu.c  |  135 
 arch/x86/include/asm/mshyperv.h|4 +
 arch/x86/include/uapi/asm/hyperv.h |7 ++
 arch/x86/kernel/cpu/mshyperv.c |1 +
 6 files changed, 150 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/hyperv/mmu.c

diff --git a/arch/x86/hyperv/Makefile b/arch/x86/hyperv/Makefile
index 171ae09..367a820 100644
--- a/arch/x86/hyperv/Makefile
+++ b/arch/x86/hyperv/Makefile
@@ -1 +1 @@
-obj-y  := hv_init.o
+obj-y  := hv_init.o mmu.o
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index e93b9a0..1a8eb55 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -140,6 +140,8 @@ void hyperv_init(void)
hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
 
+   hyper_alloc_mmu();
+
/*
 * Register Hyper-V specific clocksource.
 */
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
new file mode 100644
index 000..fe87ffe
--- /dev/null
+++ b/arch/x86/hyperv/mmu.c
@@ -0,0 +1,135 @@
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
+struct hv_flush_pcpu {
+   u64 address_space;
+   u64 flags;
+   u64 processor_mask;
+   u64 gva_list[];
+};
+
+/* Each gva in gva_list encodes up to 4096 pages to flush */
+#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
+
+static struct hv_flush_pcpu __percpu *pcpu_flush;
+
+/*
+ * Fills in gva_list starting from offset. Returns the number of items filled
+ * in gva_list (including offset)
+ */
+static inline int fill_gva_list(u64 gva_list[], int offset,
+   unsigned long start, unsigned long end)
+{
+   int gva_n = offset;
+   unsigned long cur = start, diff;
+
+   do {
+   diff = end > cur ? end - cur : 0;
+
+   gva_list[gva_n] = cur & PAGE_MASK;
+   /*
+* Lower 12 bits encode the number of additional
+* pages to flush (in addition to the 'cur' page).
+*/
+   if (diff >= HV_TLB_FLUSH_UNIT)
+   gva_list[gva_n] |= ~PAGE_MASK;
+   else if (diff)
+   gva_list[gva_n] |= (diff - 1) >> PAGE_SHIFT;
+
+   cur += HV_TLB_FLUSH_UNIT;
+   gva_n++;
+
+   } while (cur < end);
+
+   return gva_n;
+}
+
+static void hyperv_flush_tlb_others(const struct cpumask *cpus,
+   struct mm_struct *mm, unsigned long start,
+   unsigned long end)
+{
+   int cpu, vcpu, gva_n, max_gvas;
+   struct hv_flush_pcpu *flush;
+   u64 status = U64_MAX;
+   unsigned long flags;
+
+   if (!pcpu_flush || !hv_hypercall_pg)
+   goto do_native;
+
+   if (cpumask_empty(cpus))
+   return;
+
+   local_irq_save(flags);
+
+   flush = this_cpu_ptr(pcpu_flush);
+
+   if (mm) {
+   flush->address_space = virt_to_phys(mm->pgd);
+   flush->flags = 0;
+   } else {
+   flush->address_space = 0;
+   flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
+   }
+
+   flush->processor_mask = 0;
+   if (cpumask_equal(cpus, cpu_present_mask)) {
+   flush->flags |= HV_FLUSH_ALL_PROCESSORS;
+   } else {
+   for_each_cpu(cpu, cpus) {
+   vcpu = hv_cpu_number_to_vp_number(cpu);
+   if (vcpu < 64)
+   __set_bit(vcpu, (unsigned long *)
+ >processor_mask);
+   else
+   goto do_native;
+   }
+   }
+
+   /*
+* We can flush not more than max_gvas with one hypercall. Flush the
+* whole 

[PATCH 06/10] x86/hyper-v: implement rep hypercalls

[kys]

From: Vitaly Kuznetsov 

Rep hypercalls are normal hypercalls which perform multiple actions at
once. Hyper-V guarantees to return exectution to the caller in not more
than 50us and the caller needs to use hypercall continuation. Touch NMI
watchdog between hypercall invocations.

This is going to be used for HvFlushVirtualAddressList hypercall for
remote TLB flushing.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Andy Shevchenko 
Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/include/asm/mshyperv.h |   39 +++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index f3bedb4..ed8107d 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -211,7 +212,13 @@ static inline u64 hv_do_hypercall(u64 control, void 
*input, void *output)
return hv_status;
 }
 
+#define HV_HYPERCALL_RESULT_MASK   GENMASK_ULL(15, 0)
 #define HV_HYPERCALL_FAST_BIT  BIT(16)
+#define HV_HYPERCALL_VARHEAD_OFFSET17
+#define HV_HYPERCALL_REP_COMP_OFFSET   32
+#define HV_HYPERCALL_REP_COMP_MASK GENMASK_ULL(43, 32)
+#define HV_HYPERCALL_REP_START_OFFSET  48
+#define HV_HYPERCALL_REP_START_MASKGENMASK_ULL(59, 48)
 
 /* Fast hypercall with 8 bytes of input and no output */
 static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
@@ -245,6 +252,38 @@ static inline u64 hv_do_fast_hypercall8(u16 code, u64 
input1)
return hv_status;
 }
 
+/*
+ * Rep hypercalls. Callers of this functions are supposed to ensure that
+ * rep_count and varhead_size comply with Hyper-V hypercall definition.
+ */
+static inline u64 hv_do_rep_hypercall(u16 code, u16 rep_count, u16 
varhead_size,
+ void *input, void *output)
+{
+   u64 control = code;
+   u64 status;
+   u16 rep_comp;
+
+   control |= (u64)varhead_size << HV_HYPERCALL_VARHEAD_OFFSET;
+   control |= (u64)rep_count << HV_HYPERCALL_REP_COMP_OFFSET;
+
+   do {
+   status = hv_do_hypercall(control, input, output);
+   if ((status & HV_HYPERCALL_RESULT_MASK) != HV_STATUS_SUCCESS)
+   return status;
+
+   /* Bits 32-43 of status have 'Reps completed' data. */
+   rep_comp = (status & HV_HYPERCALL_REP_COMP_MASK) >>
+   HV_HYPERCALL_REP_COMP_OFFSET;
+
+   control &= ~HV_HYPERCALL_REP_START_MASK;
+   control |= (u64)rep_comp << HV_HYPERCALL_REP_START_OFFSET;
+
+   touch_nmi_watchdog();
+   } while (rep_comp < rep_count);
+
+   return status;
+}
+
 void hyperv_init(void);
 void hyperv_report_panic(struct pt_regs *regs);
 bool hv_is_hypercall_page_setup(void);
-- 
1.7.1

[PATCH 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[kys]

From: K. Y. Srinivasan 

Hyper-V supports hypercalls for doing local and remote TLB flushing and
gives its guests hints when using hypercall is preferred. While doing
hypercalls for local TLB flushes is probably not practical (and is not
being suggested by modern Hyper-V versions) remote TLB flush with a
hypercall brings significant improvement.

To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
was creating 32 threads which were doing 10 mmap/munmaps each on
some
big file. Here are the results:

Before:
# time ./pthread_mmap ./randfile 
real3m33.118s
user0m3.698s
sys 3m16.624s

After:
# time ./pthread_mmap ./randfile 
real2m19.920s
user0m2.662s
sys 2m9.948s

This series brings a number of small improvements along the way: fast
hypercall implementation and using it for event signaling, rep
hypercalls
implementation, hyperv tracing subsystem (which only traces the newly
added
remote TLB flush for now).

Vitaly Kuznetsov (10):
  x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set
  x86/hyper-v: stash the max number of virtual/logical processor
  x86/hyper-v: make hv_do_hypercall() inline
  x86/hyper-v: fast hypercall implementation
  hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT
  x86/hyper-v: implement rep hypercalls
  hyper-v: globalize vp_index
  x86/hyper-v: use hypercall for remote TLB flush
  x86/hyper-v: support extended CPU ranges for TLB flush hypercalls
  tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

 MAINTAINERS |1 +
 arch/x86/Kbuild |2 +-
 arch/x86/hyperv/Makefile|2 +-
 arch/x86/hyperv/hv_init.c   |   90 +---
 arch/x86/hyperv/mmu.c   |  268 +++
 arch/x86/include/asm/mshyperv.h |  149 +++-
 arch/x86/include/asm/trace/hyperv.h |   38 +
 arch/x86/include/uapi/asm/hyperv.h  |   17 +++
 arch/x86/kernel/cpu/mshyperv.c  |   13 ++-
 drivers/hv/channel_mgmt.c   |   20 +--
 drivers/hv/connection.c |7 +-
 drivers/hv/hv.c |9 --
 drivers/hv/hyperv_vmbus.h   |   11 --
 drivers/hv/vmbus_drv.c  |   17 ---
 drivers/pci/host/pci-hyperv.c   |   10 +-
 include/linux/hyperv.h  |   17 +--
 16 files changed, 540 insertions(+), 131 deletions(-)
 create mode 100644 arch/x86/hyperv/mmu.c
 create mode 100644 arch/x86/include/asm/trace/hyperv.h

Re: [PATCH] staging: android: ion: Use DEFINE_DEBUGFS_ATTRIBUTE

[Greg Kroah-Hartman]

On Sun, Jun 25, 2017 at 08:22:06AM -0400, Tommy Nguyen wrote:
> Running coccicheck indicates that DEFINE_DEBUGFS_ATTRIBUTE
> and debugfs_create_file_unsafe should be used instead.

Why use the _unsafe version?  Are you sure it will work properly?  What
benifit does it offer?

> 
> Signed-off-by: Tommy Nguyen 
> ---
>  drivers/staging/android/ion/ion.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 03d3a4f..8f96b38 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -544,8 +544,8 @@ static int debug_shrink_get(void *data, u64 *val)
>   return 0;
>  }
>  
> -DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
> - debug_shrink_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
> +  debug_shrink_set, "%llu\n");

Are you sure this works?

thanks,

greg k-h

Re: [RFC] memory corruption caused by efi driver?

[Xishi Qiu]

On 2017/6/24 19:12, Greg KH wrote:

> On Sat, Jun 24, 2017 at 05:52:23PM +0800, Yisheng Xie wrote:
>> hi all,
>>
>> I met an Oops problem with linux-3.10. The RIP is sysfs_open_file+0x46/0x2b0 
>> (I will and the full
>> crash log in the end of this mail).
> 
> 3.10 is _very_ old and obsolete, can you duplicate this on a modern
> kernel, like 4.11?
> 
> thanks,
> 
> greg k-h
> 
> .
> 

Hi, if I disable CONFIG_EFI_VARS, it seems OK now.

And I cann't reproduce the problem on mainline(v4.12).

Here is my test, run some stress test, then
cat /sys/firmware/efi/efivars/*
or
cat /sys/firmware/efi/vars/*/*

1) 3.10, get warning
CONFIG_EFI_VARS=y
CONFIG_EFIVAR_FS=y

2) 3.10, get warning
CONFIG_EFI_VARS=y
CONFIG_EFIVAR_FS=n

3) 3.10, ok
CONFIG_EFI_VARS=n
CONFIG_EFIVAR_FS=y

4) mainline, ok
CONFIG_EFI_VARS=y
CONFIG_EFIVAR_FS=y

log:
[78872.389117] WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x222/0x2b0()
[78872.389118] missing sysfs attribute operations for kobject: (null)
[78872.389177] Modules linked in: gen_timer(OVE) tun zram(C) ext4 jbd2 mbcache 
loop regmap_i2c binfmt_misc scsi_transport_iscsi cfg80211 ip6t_rpfilter 
ip6t_REJECT ipt_REJECT xt_conntrack rfk
ill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables 
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle 
ip6table_security ip6table_raw ip6table_filter
 ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat 
nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter 
ip_tables sg iTCO_wdt ipmi_devintf iTCO_ve
ndor_support vfat fat intel_powerclamp coretemp kvm_intel kvm nfsd 
crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ipmi_ssif 
aesni_intel lrw gf128mul auth_rpcgss glue_helper a
blk_helper i7core_edac nfs_acl cryptd lpc_ich pcspkr
[78872.389197]  ipmi_si i2c_i801 edac_core shpchp mfd_core lockd 
ipmi_msghandler acpi_cpufreq grace sunrpc uinput xfs libcrc32c sd_mod sr_mod 
crc_t10dif cdrom crct10dif_common ixgbe igb ahci
 mdio libahci ptp i2c_algo_bit pps_core libata i2c_core megaraid_sas dca 
dm_mirror dm_region_hash dm_log dm_mod [last unloaded: gen_timer]
[78872.389202] CPU: 52 PID: 28434 Comm: cat Tainted: GWC OE  
V---   3.10.0-327.55.58.81.x86_64 #2
[78872.389204] Hardware name: HUAWEI TECHNOLOGIES CO.,LTD. Tecal RH5885 
V2/CH91RGPUC, BIOS RGPUC-BIOS-V058 06/23/2013
[78872.389207]  88200a61fc10 df10e27d 88200a61fbc8 
8163ed14
[78872.389208]  88200a61fc00 8107b300 fff3 
88103f6473a0
[78872.389209]  8880236cb700 88103f6473a0 8860281d8838 
88200a61fc68
[78872.389210] Call Trace:
[78872.389224]  [] dump_stack+0x19/0x1b
[78872.389233]  [] warn_slowpath_common+0x70/0xb0
[78872.389234]  [] warn_slowpath_fmt+0x5c/0x80
[78872.389236]  [] sysfs_open_file+0x222/0x2b0
[78872.389242]  [] do_dentry_open+0x1a7/0x2e0
[78872.389244]  [] ? sysfs_schedule_callback+0x1c0/0x1c0
[78872.389245]  [] vfs_open+0x39/0x70
[78872.389251]  [] do_last+0x1ed/0x12a0
[78872.389259]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
[78872.389261]  [] path_openat+0xc2/0x490
[78872.389267]  [] ? call_rcu_sched+0x1d/0x20
[78872.389275]  [] ? shmem_destroy_inode+0x2d/0x40
[78872.389281]  [] ? evict+0x106/0x170
[78872.389283]  [] do_filp_open+0x4b/0xb0
[78872.389286]  [] ? __alloc_fd+0xa7/0x130
[78872.389290]  [] do_sys_open+0xf3/0x1f0
[78872.389291]  [] SyS_open+0x1e/0x20
[78872.389297]  [] system_call_fastpath+0x16/0x1b
[78872.389298] ---[ end trace cbe34632be0fdedf ]---
[78872.390067] [ cut here ]

Re: [PATCH] ARM: dts: exynos: Exynos5422 Odroid-XU* incomplete thermal-zones definition

[Krzysztof Kozlowski]

On Sun, Jun 25, 2017 at 06:53:24PM +0530, Anand Moon wrote:
> Hi Willy,
> 
> On 24 June 2017 at 02:39, Willy Wolff  wrote:
> > Odroid XU*-familly boards has thermal sensors per A15 cores, but the actual
> >  thermal-zones define only cooling-maps action for cpu0.
> >
> > If the application is running on all cores but core4 (first core of the A15
> >  cluster), the CPU can reach high temperature without any proper cooling
> >  action.
> >
> > As already discus in prior mail, and on IRC, it's a quit big code
> > duplication, but I don't found the write way to express that in a better
> >  way.
> >
> > The situation for this board is that we have multiple sensors, but
> >  matching cooling devices for these sensors act for the same physical
> >  device (FAN and A15 cluster, as each core of the cluster share the same
> >  frequency).
> > In fact, of-thermal.c:473:thermal_zone_of_sensor_register() can't use
> > multiple sensors for one single thermal zone.
> > This patch follow the path taken in arch/arm/boot/dts/qcom-apq8084.dtsi:97
> >
> > I'm interested to extending the thermal driver, but it will takes time.
> >  So this is a workaround before refactoring the driver.
> > If somebody knows how to write it better, any advice and suggestions
> > are more than welcome.
> >
> > Also, the comment for cpu_alert4 in cooling-maps definition is not
> > accurate, 11 steps for A15 correspond to 700MHz, not 600MHz.
> >
> 
> [snip]
> 
> Few point to from my side.
> 
> 1: We should also increase the trip points temperature so that it can
> throttle at high temperature.

It is not related to this problem. If you wish to address different
problem related to non-optimal choice of temperature, then please send a
separate patch explaining chosen values.

> 2: We should also increase the tips from 4 to 8 to support different
> cluster of cpu's.

There are 4 CPU thermal zones on Exynos5422. What do you want to expand?

> 3: To avoid duplication of cooling-maps we can make tmu sensor work
> differently for cluster of cpu's
>   tmu_cpu0: handle pwm-fan control.
>   tmu_cpu1: handle cpu[0-3] cpufreq mapping.
>   tmu_cpu2: handle cpu[4-7] cpufreq mapping.

I miss the point behind this. Why fan should work only when CPU4
(tmu_cpu0) is heated and not CPU5-7 (rest of cpu tmu's)?

Best regards,
Krzysztof


>   tmu_gpu: handle gpu (mali) cpu throttle.
> 
> Please share your thought on this new approach.
> 
> I generally test using linaro's pm-qa and most of the time the test case fails
>   # git clone git://git.linaro.org/tools/pm-qa.git
>   # make -C thermal check
> 
> -Best Regards
> -Anand Moon

Re: [RFC] memory corruption caused by efi driver?

[Greg KH]

On Sun, Jun 25, 2017 at 09:06:58PM +0800, Xishi Qiu wrote:
> On 2017/6/24 19:12, Greg KH wrote:
> 
> > On Sat, Jun 24, 2017 at 05:52:23PM +0800, Yisheng Xie wrote:
> >> hi all,
> >>
> >> I met an Oops problem with linux-3.10. The RIP is 
> >> sysfs_open_file+0x46/0x2b0 (I will and the full
> >> crash log in the end of this mail).
> > 
> > 3.10 is _very_ old and obsolete, can you duplicate this on a modern
> > kernel, like 4.11?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > .
> > 
> 
> Hi, if I disable CONFIG_EFI_VARS, it seems OK now.
> 
> And I cann't reproduce the problem on mainline(v4.12).
> 
> Here is my test, run some stress test, then
> cat /sys/firmware/efi/efivars/*
> or
> cat /sys/firmware/efi/vars/*/*
> 
> 1) 3.10, get warning
> CONFIG_EFI_VARS=y
> CONFIG_EFIVAR_FS=y
> 
> 2) 3.10, get warning
> CONFIG_EFI_VARS=y
> CONFIG_EFIVAR_FS=n
> 
> 3) 3.10, ok
> CONFIG_EFI_VARS=n
> CONFIG_EFIVAR_FS=y
> 
> 4) mainline, ok
> CONFIG_EFI_VARS=y
> CONFIG_EFIVAR_FS=y

Then use mainline :)

[PATCH] ov9650: fix semicolon.cocci warnings

[kbuild test robot]

drivers/media/i2c/ov9650.c:2034:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: 5ffa34fa8f2e ("ov9650: add support of OV9655 variant")
CC: Hugues Fruchet 
Signed-off-by: Fengguang Wu 
---

 ov9650.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -2031,7 +2031,7 @@ static int ov965x_probe(struct i2c_clien
ov965x->formats = ov9655_formats;
ov965x->nb_of_formats = ARRAY_SIZE(ov9655_formats);
ov965x->set_params = ov965x_set_frame_size;
-   };
+   }
 
ov965x->frame_size = >framesizes[0];
ov965x_get_default_format(ov965x, >format);

Re: [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant

[kbuild test robot]

Hi Hugues,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.12-rc6 next-20170623]
[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/Hugues-Fruchet/Add-support-of-OV9655-camera/20170625-201153
base:   git://linuxtv.org/media_tree.git master


coccinelle warnings: (new ones prefixed by >>)

>> drivers/media/i2c/ov9650.c:2034:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

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

Re: [PATCH v5 0/4] USB Audio Gadget refactoring

[Jassi Brar]

On Sun, Jun 18, 2017 at 6:53 PM, Ruslan Bilovol
 wrote:
> Hi Felipe,
>
> This is v5 of audio gadget refactoring.
> Note, that legacy f_uac1 function is broken since v4.10
> by commit 7e4da3fcf7c9 ("usb: gadget: composite: Test
> get_alt() presence instead of set_alt()"). The fact that
> at v4.12-rc5 time nobody cares about may be a good sign
> that number of users is small if any. Thus making it
> legacy makes sence.
>
> This series depends on legacy f_uac1 fix I posted before:
> http://www.spinics.net/lists/linux-usb/msg158373.html
> Without this fix it's not possible to check that refactoring
> didn't break legacy f_uac1 functionality
>
> 
>
> I came to this patch series when wanted to do two things:
>  - use UAC1 as virtual ALSA sound card on gadget side,
>just like UAC2 is used so it's possible to do rate
>resampling
>  - have both playback/capture support in UAC1
>
> Since I wanted to have same behavior for both UAC1/UAC2,
> obviously I've got an utility part (u_audio.c) for
> virtual ALSA sound card handling like we have
> for ethernet(u_ether) or serial(u_serial) functions.
> Function-specific parts (f_uac1/f_uac2) became almost
> as storage for class-specific USB descriptors, some
> boilerplate for configfs, binding and few USB
> config request handling.
>
> Originally in RFC [1] I've posted before, there was
> major change to f_uac1 after that it couldn't do
> direct play to existing ALSA sound card anymore,
> representing audio on gadget side as virtual
> ALSA sound card where audio streams are simply
> sinked to and sourced from it, so it may break
> current usecase for some people (and that's why
> it was RFC).
>
> During RFC discussion, it was agreed to not touch
> existing f_uac1 implementation and create new one
> instead. At v4 patchet discussion another approach
> was agreed - current f_uac1.c gets renamed to
> f_uac1_legacy.c and introduced a *new* f_uac1.c
> instead that is done in current patchset (v5)
>
> Now, it's possible to use existing user-space
> applications for audio routing between Audio Gadget
> and real sound card. I personally use alsaloop tool
> from alsautils and have ability to create PCM
> loopback between two different ALSA cards using
> rate resampling, which was not possible with previous
> "direct play to ALSA card" approach in f_uac1.
>
> While here, also dropped redundant platform
> driver/device creation in f_uac2 driver (as well as
> didn't add "never implemented" volume/mute functionality
> in f_uac1_legacy to f_uac1) that made this work even
> easier to do.
>
> This series is tested with both legacy g_audio.ko and
> modern configfs approaches under Ubuntu 14.04 (UAC1 and
> UAC2) and under Windows7 x64 (UAC1 only) having
> perfect results in all cases.
>
> Comments, testing are welcome.
>
> v5 changes:
>  - after discussion with Felipe, switched to another
>approach with making current f_uac1 legacy and
>introducing a new f_uac1.c instead
>  - addressed Jassi's copyright comments
>
> v4 changes:
>  - renamed f_uac1_newapi to f_uac1_acard that is
>more meaningful
>  - rebased on top of balbi/next
>
> v3 changes:
>  - renamed u_audio exported symbols so they don't
>conflict with old f_uac1 if both are built-in.
>
> v2 changes:
>  - do not touch f_uac1, instead created f_uac1_newapi
>  - added documentation for f_uac1_newapi
>  - rebased on top of v4.8-rc1
>
> [1] https://lkml.org/lkml/2016/5/23/649
>
> Ruslan Bilovol (4):
>   usb: gadget: f_uac2: remove platform driver/device creation
>   usb: gadget: f_uac2: split out audio core
>   usb: gadget: function: make current f_uac1 implementation legacy
>   usb: gadget: add f_uac1 variant based on a new u_audio api
>
>  Documentation/ABI/testing/configfs-usb-gadget-uac1 |   18 +-
>  .../ABI/testing/configfs-usb-gadget-uac1_legacy|   12 +
>  Documentation/usb/gadget-testing.txt   |   53 +-
>  drivers/usb/gadget/Kconfig |   29 +-
>  drivers/usb/gadget/function/Makefile   |5 +-
>  drivers/usb/gadget/function/f_uac1.c   |  906 +++--
>  drivers/usb/gadget/function/f_uac1_legacy.c| 1021 
> 
>  drivers/usb/gadget/function/f_uac2.c   |  795 ++-
>  drivers/usb/gadget/function/u_audio.c  |  662 +
>  drivers/usb/gadget/function/u_audio.h  |   95 ++
>  drivers/usb/gadget/function/u_uac1.h   |   87 +-
>  .../gadget/function/{u_uac1.c => u_uac1_legacy.c}  |7 +-
>  drivers/usb/gadget/function/u_uac1_legacy.h|   82 ++
>  drivers/usb/gadget/legacy/Kconfig  |   15 +-
>  drivers/usb/gadget/legacy/audio.c  |   55 +-
>  15 files changed, 2494 insertions(+), 1348 deletions(-)
>  create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-uac1_legacy
>  create mode 100644 drivers/usb/gadget/function/f_uac1_legacy.c
>  create 

Re: [PATCH v2] rtc: ds3232: add temperature support

[Andy Shevchenko]

On Thu, Jun 22, 2017 at 7:58 PM, Kirill Esipov  wrote:
> DS3232/DS3234 has the temperature registers with a resolution of 0.25
> degree celsius. This enables to get the value through hwmon.
>
> # cat /sys/class/hwmon/hwmon0/temp1_input
> 37250

> +config RTC_DRV_DS3232_HWMON
> +   bool "HWMON support for Dallas/Maxim DS3232/DS3234"

> +   depends on RTC_DRV_DS3232 && HWMON
> +   depends on !(RTC_DRV_DS3232=y && HWMON=m)

Perhaps it might be squeezed into one line (something like that logic
has been required by I2C related PMIC IIRC)

> +   default y

Is it really sane default?

> +#ifdef CONFIG_RTC_DRV_DS3232_HWMON

IS_BUILTIN() ?

> +static int ds3232_hwmon_read_temp(struct device *dev, long int *mC)
> +{
> +   struct ds3232 *ds3232 = dev_get_drvdata(dev);
> +   u8 temp_buf[2];
> +   s16 temp;
> +   int ret;
> +
> +   ret = regmap_bulk_read(ds3232->regmap, DS3232_REG_TEMPERATURE, 
> temp_buf,
> +   sizeof(temp_buf));

> +

Remove.

> +   if (ret < 0)
> +   return ret;

> +static umode_t ds3232_hwmon_is_visible(const void *data,
> +enum hwmon_sensor_types type,
> +u32 attr, int channel)
> +{
> +   if (type != hwmon_temp)
> +   return 0;
> +
> +   switch (attr) {
> +   case hwmon_temp_input:
> +   return 0444;
> +   default:
> +   return 0;
> +   }
> +}
> +
> +static int ds3232_hwmon_read(struct device *dev,
> +  enum hwmon_sensor_types type,
> +  u32 attr, int channel, long *temp)
> +{
> +   int err;
> +
> +   switch (attr) {
> +   case hwmon_temp_input:
> +   ds3232_hwmon_read_temp(dev, temp);
> +   err = 0;
> +   break;
> +   default:
> +   return -EOPNOTSUPP;
> +   }
> +
> +   return err;

You may do as in previous function. Or what did you mean here by
introducing an err variable?

> +}

> +
> +

Remove one of them.

> +static void ds3232_hwmon_register(struct device *dev, const char *name)
> +{
> +   struct ds3232 *ds3232 = dev_get_drvdata(dev);
> +   struct device *hwmon_dev;
> +
> +   hwmon_dev = devm_hwmon_device_register_with_info(dev, name, ds3232,
> +   
> _hwmon_chip_info,
> +   NULL);

> +

Remove.

> +   if (IS_ERR(hwmon_dev)) {
> +   dev_warn(dev, "unable to register hwmon device %ld\n",
> +PTR_ERR(hwmon_dev));
> +   }
> +}
> +

> +#else

I dunno which style is preferred, though you may use
if (IS_BUILTIN(...))
 return;

at the beginning of the function and allow gcc optimizer to take care
of everything else.

> +
> +static void ds3232_hwmon_register(struct device *dev, const char *name)
> +{
> +}
> +
> +#endif

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] ARM: dts: exynos: Exynos5422 Odroid-XU* incomplete thermal-zones definition

[Anand Moon]

Hi Krzysztof

On 25 June 2017 at 20:59, Krzysztof Kozlowski  wrote:
> On Sun, Jun 25, 2017 at 08:48:13PM +0530, Anand Moon wrote:
>> Hi Krzystof,
>> >> 2: We should also increase the tips from 4 to 8 to support different
>> >> cluster of cpu's.
>> >
>> > There are 4 CPU thermal zones on Exynos5422. What do you want to expand?
>>
>> What I meant was to support more trip point to address below.
>> [2.776320] exynos-tmu 100a.tmu: More trip points than
>> supported by this TMU.
>> [2.782370] exynos-tmu 100a.tmu: 2 trip points should be
>> configured in polling mode.
>>
>
> I do not understand what you want to achieve. I added 2 trip points in
> polling mode for the CPU cooling mode. Just describe the problem and
> send the patch - it is the best way to explain one's thought...
>
>> >> 3: To avoid duplication of cooling-maps we can make tmu sensor work
>> >> differently for cluster of cpu's
>> >>   tmu_cpu0: handle pwm-fan control.
>> >>   tmu_cpu1: handle cpu[0-3] cpufreq mapping.
>> >>   tmu_cpu2: handle cpu[4-7] cpufreq mapping.
>> >
>> > I miss the point behind this. Why fan should work only when CPU4
>> > (tmu_cpu0) is heated and not CPU5-7 (rest of cpu tmu's)?
>>
>> Ok fan should work on all the thermal zone. To avoid thermal shutdown.
>>
>> But I want to avoid scaling down of all the cores of cpu to low freq
>> as cooling-maps cross the alert temperature. For below example.
>> 
>>  map3 {
>>   trip = <_alert3>;
>>   cooling-device = < 0 2>;
>>  };
>>  map4 {
>>   trip = <_alert3>;
>>   cooling-device = < 0 2>;
>>  };
>>
>>  map5 {
>>   trip = <_alert4>;
>>   cooling-device = < 3 7>;
>>  };
>>  map6 {
>>  trip = <_alert4>;
>>  cooling-device = < 3 12>;
>>  };
>>
>> What I want to configure thermal zone as.
>>
>> cpu0_thermal: cpu0-thermal {
>>  configure cluster of cpu[0-3]
>>  {
>> tips
>>  }
>>  cooling map
>>  {
>>  device handle cpu[0-3] with frequency scaling at particular
>> alert temperature.
>>  }
>> }
>
> cpu0_thermal is attached to tmu_cpu0 which is the temperature of CPU4
> (first big core). I do not see reason behind connecting thermal zone
> (thus temperature) of CPU4 with frequency of LITTLE cluster (CPU0-3). In
> case of busy CPU4, you will scale down CPU0-3. Does not make sense.
>

Both the cpu cluster are independent and have different cpu-freqency scaling.
that is the reason to for my changes.

>> cpu1_thermal: cpu1-thermal {
>>  configure cluster of cpu[4-7]
>>  {
>> tips
>>  }
>>  cooling map
>>  {
>>  device handle cpu[4-7] with frequency scaling at particular
>> alert temperature.
>>  }
>> }
>>
>> We can chose to configure rest of the thermal-zone on this approach.
>> Please share your thoughts.
>
> I am sorry, I do not understand the idea, the problem nor the solution.
>
> Best regards,
> Krzysztof
>

Sorry for not able to express my self in technical terms.
my changes are based on exynos5433-tmu at this moment.
Just attaching small patch to share my point.

Best Regards
-Anand Moon


tmu.patch
Description: Binary data

[PATCH 1/3] include: usb: audio: specify exact endiannes of descriptors

[Ruslan Bilovol]

USB spec says that multiple byte fields are stored in
little-endian order (see chapter 8.1 of USB2.0 spec and
chapter 7.1 of USB3.0 spec), thus mark such fields as LE
for UAC1 and UAC2 headers

Signed-off-by: Ruslan Bilovol 
---
 include/linux/usb/audio-v2.h   | 14 +++---
 include/uapi/linux/usb/audio.h |  6 +++---
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/linux/usb/audio-v2.h b/include/linux/usb/audio-v2.h
index c5f2158..fd73bc0 100644
--- a/include/linux/usb/audio-v2.h
+++ b/include/linux/usb/audio-v2.h
@@ -115,13 +115,13 @@ struct uac2_input_terminal_descriptor {
__u8 bDescriptorType;
__u8 bDescriptorSubtype;
__u8 bTerminalID;
-   __u16 wTerminalType;
+   __le16 wTerminalType;
__u8 bAssocTerminal;
__u8 bCSourceID;
__u8 bNrChannels;
-   __u32 bmChannelConfig;
+   __le32 bmChannelConfig;
__u8 iChannelNames;
-   __u16 bmControls;
+   __le16 bmControls;
__u8 iTerminal;
 } __attribute__((packed));
 
@@ -132,11 +132,11 @@ struct uac2_output_terminal_descriptor {
__u8 bDescriptorType;
__u8 bDescriptorSubtype;
__u8 bTerminalID;
-   __u16 wTerminalType;
+   __le16 wTerminalType;
__u8 bAssocTerminal;
__u8 bSourceID;
__u8 bCSourceID;
-   __u16 bmControls;
+   __le16 bmControls;
__u8 iTerminal;
 } __attribute__((packed));
 
@@ -164,9 +164,9 @@ struct uac2_as_header_descriptor {
__u8 bTerminalLink;
__u8 bmControls;
__u8 bFormatType;
-   __u32 bmFormats;
+   __le32 bmFormats;
__u8 bNrChannels;
-   __u32 bmChannelConfig;
+   __le32 bmChannelConfig;
__u8 iChannelNames;
 } __attribute__((packed));
 
diff --git a/include/uapi/linux/usb/audio.h b/include/uapi/linux/usb/audio.h
index d2314be..a4680a5 100644
--- a/include/uapi/linux/usb/audio.h
+++ b/include/uapi/linux/usb/audio.h
@@ -333,7 +333,7 @@ struct uac_processing_unit_descriptor {
__u8 bDescriptorType;
__u8 bDescriptorSubtype;
__u8 bUnitID;
-   __u16 wProcessType;
+   __le16 wProcessType;
__u8 bNrInPins;
__u8 baSourceID[];
 } __attribute__ ((packed));
@@ -491,8 +491,8 @@ struct uac_format_type_ii_ext_descriptor {
__u8 bDescriptorType;
__u8 bDescriptorSubtype;
__u8 bFormatType;
-   __u16 wMaxBitRate;
-   __u16 wSamplesPerFrame;
+   __le16 wMaxBitRate;
+   __le16 wSamplesPerFrame;
__u8 bHeaderLength;
__u8 bSideBandProtocol;
 } __attribute__((packed));
-- 
1.9.1

Re: [PATCH] ARM: dts: exynos: Exynos5422 Odroid-XU* incomplete thermal-zones definition

[Anand Moon]

Hi Willy,

On 24 June 2017 at 02:39, Willy Wolff  wrote:
> Odroid XU*-familly boards has thermal sensors per A15 cores, but the actual
>  thermal-zones define only cooling-maps action for cpu0.
>
> If the application is running on all cores but core4 (first core of the A15
>  cluster), the CPU can reach high temperature without any proper cooling
>  action.
>
> As already discus in prior mail, and on IRC, it's a quit big code
> duplication, but I don't found the write way to express that in a better
>  way.
>
> The situation for this board is that we have multiple sensors, but
>  matching cooling devices for these sensors act for the same physical
>  device (FAN and A15 cluster, as each core of the cluster share the same
>  frequency).
> In fact, of-thermal.c:473:thermal_zone_of_sensor_register() can't use
> multiple sensors for one single thermal zone.
> This patch follow the path taken in arch/arm/boot/dts/qcom-apq8084.dtsi:97
>
> I'm interested to extending the thermal driver, but it will takes time.
>  So this is a workaround before refactoring the driver.
> If somebody knows how to write it better, any advice and suggestions
> are more than welcome.
>
> Also, the comment for cpu_alert4 in cooling-maps definition is not
> accurate, 11 steps for A15 correspond to 700MHz, not 600MHz.
>

[snip]

Few point to from my side.

1: We should also increase the trip points temperature so that it can
throttle at high temperature.
2: We should also increase the tips from 4 to 8 to support different
cluster of cpu's.
3: To avoid duplication of cooling-maps we can make tmu sensor work
differently for cluster of cpu's
  tmu_cpu0: handle pwm-fan control.
  tmu_cpu1: handle cpu[0-3] cpufreq mapping.
  tmu_cpu2: handle cpu[4-7] cpufreq mapping.
  tmu_gpu: handle gpu (mali) cpu throttle.

Please share your thought on this new approach.

I generally test using linaro's pm-qa and most of the time the test case fails
  # git clone git://git.linaro.org/tools/pm-qa.git
  # make -C thermal check

-Best Regards
-Anand Moon

[PATCH 0/3] USB Audio gadget endianness fixes

[Ruslan Bilovol]

Audio gadget refactoring patches touched few function
files and triggered kbuild test robot verification
who found some endianness issues by sparse tool.

Since most of these issues existed from beginning
in f_uac2 and f_uac1_legacy drivers (and were inherited
be f_uac1), it seems nobody run audio gadgets
on big-endian systems.

I fixed only f_uac1/f_uac2 issues leaving leagacy uac1
driver untouched. USB audio headers also were updated.

I tested patches only on LE system because I have no
big-endian hardware. Also there is no anymore
endianness warnings from sparse during kernel build.

For big endian case tested only build which also
doesn't produce sparse warnings anymore.

Ruslan Bilovol (3):
  include: usb: audio: specify exact endiannes of descriptors
  usb: gadget: f_uac1: endianness fixes.
  usb: gadget: f_uac2: endianness fixes.

 drivers/usb/gadget/function/f_uac1.c | 20 ++--
 drivers/usb/gadget/function/f_uac2.c | 25 ++---
 include/linux/usb/audio-v2.h | 14 +++---
 include/uapi/linux/usb/audio.h   |  6 +++---
 4 files changed, 34 insertions(+), 31 deletions(-)

-- 
1.9.1

[PATCH 2/3] usb: gadget: f_uac1: endianness fixes.

[Ruslan Bilovol]

As per USB spec, multiple-bytes fields are stored
in little-endian order. Use CPU<->LE helpers for
such fields.

Signed-off-by: Ruslan Bilovol 
---
 drivers/usb/gadget/function/f_uac1.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uac1.c 
b/drivers/usb/gadget/function/f_uac1.c
index 8656f84..29efbed 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -92,9 +92,9 @@ static inline struct f_uac1 *func_to_uac1(struct usb_function 
*f)
.bDescriptorType =  USB_DT_CS_INTERFACE,
.bDescriptorSubtype =   UAC_INPUT_TERMINAL,
.bTerminalID =  USB_OUT_IT_ID,
-   .wTerminalType =UAC_TERMINAL_STREAMING,
+   .wTerminalType =cpu_to_le16(UAC_TERMINAL_STREAMING),
.bAssocTerminal =   0,
-   .wChannelConfig =   0x3,
+   .wChannelConfig =   cpu_to_le16(0x3),
 };
 
 #define IO_OUT_OT_ID   2
@@ -103,7 +103,7 @@ static inline struct f_uac1 *func_to_uac1(struct 
usb_function *f)
.bDescriptorType= USB_DT_CS_INTERFACE,
.bDescriptorSubtype = UAC_OUTPUT_TERMINAL,
.bTerminalID= IO_OUT_OT_ID,
-   .wTerminalType  = UAC_OUTPUT_TERMINAL_SPEAKER,
+   .wTerminalType  = cpu_to_le16(UAC_OUTPUT_TERMINAL_SPEAKER),
.bAssocTerminal = 0,
.bSourceID  = USB_OUT_IT_ID,
 };
@@ -114,9 +114,9 @@ static inline struct f_uac1 *func_to_uac1(struct 
usb_function *f)
.bDescriptorType= USB_DT_CS_INTERFACE,
.bDescriptorSubtype = UAC_INPUT_TERMINAL,
.bTerminalID= IO_IN_IT_ID,
-   .wTerminalType  = UAC_INPUT_TERMINAL_MICROPHONE,
+   .wTerminalType  = cpu_to_le16(UAC_INPUT_TERMINAL_MICROPHONE),
.bAssocTerminal = 0,
-   .wChannelConfig = 0x3,
+   .wChannelConfig = cpu_to_le16(0x3),
 };
 
 #define USB_IN_OT_ID   4
@@ -125,7 +125,7 @@ static inline struct f_uac1 *func_to_uac1(struct 
usb_function *f)
.bDescriptorType =  USB_DT_CS_INTERFACE,
.bDescriptorSubtype =   UAC_OUTPUT_TERMINAL,
.bTerminalID =  USB_IN_OT_ID,
-   .wTerminalType =UAC_TERMINAL_STREAMING,
+   .wTerminalType =cpu_to_le16(UAC_TERMINAL_STREAMING),
.bAssocTerminal =   0,
.bSourceID =IO_IN_IT_ID,
 };
@@ -174,7 +174,7 @@ static inline struct f_uac1 *func_to_uac1(struct 
usb_function *f)
.bDescriptorSubtype =   UAC_AS_GENERAL,
.bTerminalLink =USB_OUT_IT_ID,
.bDelay =   1,
-   .wFormatTag =   UAC_FORMAT_TYPE_I_PCM,
+   .wFormatTag =   cpu_to_le16(UAC_FORMAT_TYPE_I_PCM),
 };
 
 static struct uac1_as_header_descriptor as_in_header_desc = {
@@ -183,7 +183,7 @@ static inline struct f_uac1 *func_to_uac1(struct 
usb_function *f)
.bDescriptorSubtype =   UAC_AS_GENERAL,
.bTerminalLink =USB_IN_OT_ID,
.bDelay =   1,
-   .wFormatTag =   UAC_FORMAT_TYPE_I_PCM,
+   .wFormatTag =   cpu_to_le16(UAC_FORMAT_TYPE_I_PCM),
 };
 
 DECLARE_UAC_FORMAT_TYPE_I_DISCRETE_DESC(1);
@@ -606,8 +606,8 @@ static int f_audio_bind(struct usb_configuration *c, struct 
usb_function *f)
if (status)
goto fail;
 
-   audio->out_ep_maxpsize = as_out_ep_desc.wMaxPacketSize;
-   audio->in_ep_maxpsize = as_in_ep_desc.wMaxPacketSize;
+   audio->out_ep_maxpsize = le16_to_cpu(as_out_ep_desc.wMaxPacketSize);
+   audio->in_ep_maxpsize = le16_to_cpu(as_in_ep_desc.wMaxPacketSize);
audio->params.c_chmask = audio_opts->c_chmask;
audio->params.c_srate = audio_opts->c_srate;
audio->params.c_ssize = audio_opts->c_ssize;
-- 
1.9.1

[PATCH 3/3] usb: gadget: f_uac2: endianness fixes.

[Ruslan Bilovol]

As per USB spec, multiple-bytes fields are stored
in little-endian order. Use CPU<->LE helpers for
such fields.

Signed-off-by: Ruslan Bilovol 
---
 drivers/usb/gadget/function/f_uac2.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uac2.c 
b/drivers/usb/gadget/function/f_uac2.c
index 9082ce2..f05c3f3 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -168,7 +168,7 @@ enum {
.bAssocTerminal = 0,
.bCSourceID = USB_OUT_CLK_ID,
.iChannelNames = 0,
-   .bmControls = (CONTROL_RDWR << COPY_CTRL),
+   .bmControls = cpu_to_le16(CONTROL_RDWR << COPY_CTRL),
 };
 
 /* Input Terminal for I/O-In */
@@ -182,7 +182,7 @@ enum {
.bAssocTerminal = 0,
.bCSourceID = USB_IN_CLK_ID,
.iChannelNames = 0,
-   .bmControls = (CONTROL_RDWR << COPY_CTRL),
+   .bmControls = cpu_to_le16(CONTROL_RDWR << COPY_CTRL),
 };
 
 /* Ouput Terminal for USB_IN */
@@ -196,7 +196,7 @@ enum {
.bAssocTerminal = 0,
.bSourceID = IO_IN_IT_ID,
.bCSourceID = USB_IN_CLK_ID,
-   .bmControls = (CONTROL_RDWR << COPY_CTRL),
+   .bmControls = cpu_to_le16(CONTROL_RDWR << COPY_CTRL),
 };
 
 /* Ouput Terminal for I/O-Out */
@@ -210,7 +210,7 @@ enum {
.bAssocTerminal = 0,
.bSourceID = USB_OUT_IT_ID,
.bCSourceID = USB_OUT_CLK_ID,
-   .bmControls = (CONTROL_RDWR << COPY_CTRL),
+   .bmControls = cpu_to_le16(CONTROL_RDWR << COPY_CTRL),
 };
 
 static struct uac2_ac_header_descriptor ac_hdr_desc = {
@@ -220,9 +220,10 @@ enum {
.bDescriptorSubtype = UAC_MS_HEADER,
.bcdADC = cpu_to_le16(0x200),
.bCategory = UAC2_FUNCTION_IO_BOX,
-   .wTotalLength = sizeof in_clk_src_desc + sizeof out_clk_src_desc
-+ sizeof usb_out_it_desc + sizeof io_in_it_desc
-   + sizeof usb_in_ot_desc + sizeof io_out_ot_desc,
+   .wTotalLength = cpu_to_le16(sizeof in_clk_src_desc
+   + sizeof out_clk_src_desc + sizeof usb_out_it_desc
+   + sizeof io_in_it_desc + sizeof usb_in_ot_desc
+   + sizeof io_out_ot_desc),
.bmControls = 0,
 };
 
@@ -569,10 +570,12 @@ static void set_ep_max_packet_size(const struct 
f_uac2_opts *uac2_opts,
return ret;
}
 
-   agdev->in_ep_maxpsize = max(fs_epin_desc.wMaxPacketSize,
-   hs_epin_desc.wMaxPacketSize);
-   agdev->out_ep_maxpsize = max(fs_epout_desc.wMaxPacketSize,
-   hs_epout_desc.wMaxPacketSize);
+   agdev->in_ep_maxpsize = max_t(u16,
+   le16_to_cpu(fs_epin_desc.wMaxPacketSize),
+   le16_to_cpu(hs_epin_desc.wMaxPacketSize));
+   agdev->out_ep_maxpsize = max_t(u16,
+   le16_to_cpu(fs_epout_desc.wMaxPacketSize),
+   le16_to_cpu(hs_epout_desc.wMaxPacketSize));
 
hs_epout_desc.bEndpointAddress = fs_epout_desc.bEndpointAddress;
hs_epin_desc.bEndpointAddress = fs_epin_desc.bEndpointAddress;
-- 
1.9.1

printk + errno texts

[Enrico Weigelt, metux IT consult]

Hi folks,


I'd like to introduce a new printk() conversion which prints out
errno values as readable text.

Where are these things defined ?

I'd guess the actual translation must be somewhere in lib/vsprintf.c,
but where are the format string checks defined ?


thx
--mtx

Re: [PATCH 1/2] staging: sm750fb: avoid conflicting vesafb

[Sudip Mukherjee]

On Sun, Jun 25, 2017 at 02:54:51PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Jun 25, 2017 at 01:43:34PM +0100, Sudip Mukherjee wrote:
> > On Mon, Jun 19, 2017 at 09:32:57PM +0100, Sudip Mukherjee wrote:
> > > From: Teddy Wang 
> > > 
> > > If vesafb is enabled in the config then /dev/fb0 is created by vesa
> > > and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to
> > > effectively work with xorg.
> > > So if it has been alloted fb1, then try to remove the other fb0.
> > > 
> > > Signed-off-by: Teddy Wang 
> > > Signed-off-by: Sudip Mukherjee 
> > > ---
> > 
> > Hi Greg,
> > You applied the second patch but not this one. Did I miss any review
> > comments from you about this one?
> 
> All of the other complaints about this patch were not sufficient for me
> to justify ignoring it?  Why would I not listen to them?

This patch is doing what all the drm drivers are doing. So you want
us to do something completely new rather than following the established
practice of a drm driver?

--
Regards
Sudip

Re: [PATCH/RFC 6/9] perf symbols: Use already loaded module dso when loading kcore

[Namhyung Kim]

On Fri, Jun 23, 2017 at 10:55:47AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 23, 2017 at 02:48:24PM +0900, Namhyung Kim escreveu:
> > Even every module has loaded onto same addresses, some modules can be
> > changed and reloaded.
> 
> Can you rephrase the above statement?
> 
> You mean even if a module is reloaded at the same address it can have a
> different symtab and thus misresolve symbols if we get a sample for one
> module version and try to resolve symbols using a symtab for another
> module version?

Right, as I said in other thread, the module can be unloaded, modified
and reloaded between "perf record" and "perf report".


> 
> > In that case it needs to access to the old module
> > in the build-id cache.
> 
> Right, we need to make sure that during a 'perf record' session a módule
> isn't reloaded, because at 'perf record' exit we will record that module
> build-id in a perf.data header and grab a copy (or a hardlink, if
> possible) into the ~/.debug build-id cache, then, at 'perf report' time
> we will read that build-id perf.data table and lookup in the build-id
> cache to get the matching symtab (and full elf .ko file to do things
> like annotation).

That's the desired behavior.  But "perf report" didn't use modules in
the build-id cache when it used kcore (and kallsyms).

Thanks,
Namhyung


>  
> > Cc: Adrian Hunter 
> > Cc: Wang Nan 
> > Signed-off-by: Namhyung Kim 
> > ---
> >  tools/perf/util/symbol.c | 45 +++--
> >  1 file changed, 23 insertions(+), 22 deletions(-)
> > 
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index ce79a51f25bf..fe46eb782297 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -1155,6 +1155,7 @@ static int dso__load_kcore(struct dso *dso, struct 
> > map *map,
> > int err, fd;
> > char kcore_filename[PATH_MAX];
> > struct symbol *sym;
> > +   struct map_groups old_mg;
> >  
> > if (!kmaps)
> > return -EINVAL;
> > @@ -1196,15 +1197,8 @@ static int dso__load_kcore(struct dso *dso, struct 
> > map *map,
> > goto out_err;
> > }
> >  
> > -   /* Remove old maps */
> > -   old_map = map_groups__first(kmaps, map->type);
> > -   while (old_map) {
> > -   struct map *next = map_groups__next(old_map);
> > -
> > -   if (old_map != map)
> > -   map_groups__remove(kmaps, old_map);
> > -   old_map = next;
> > -   }
> > +   old_mg = *kmaps;
> > +   kmaps->maps[map->type].entries = RB_ROOT;
> >  
> > /* Find the kernel map using the first symbol */
> > sym = dso__first_symbol(dso, map->type);
> > @@ -1223,24 +1217,31 @@ static int dso__load_kcore(struct dso *dso, struct 
> > map *map,
> > while (!list_empty()) {
> > new_map = list_entry(md.maps.next, struct map, node);
> > list_del_init(_map->node);
> > -   if (new_map == replacement_map) {
> > -   map->start  = new_map->start;
> > -   map->end= new_map->end;
> > -   map->pgoff  = new_map->pgoff;
> > -   map->map_ip = new_map->map_ip;
> > -   map->unmap_ip   = new_map->unmap_ip;
> > -   /* Ensure maps are correctly ordered */
> > -   map__get(map);
> > -   map_groups__remove(kmaps, map);
> > -   map_groups__insert(kmaps, map);
> > -   map__put(map);
> > -   } else {
> > -   map_groups__insert(kmaps, new_map);
> > +
> > +   map_groups__insert(kmaps, new_map);
> > +
> > +   if (new_map != replacement_map) {
> > +   old_map = map_groups__find(_mg, new_map->type, 
> > new_map->start);
> > +   if (old_map && dso__loaded(old_map->dso, 
> > old_map->type)) {
> > +   new_map->pgoff = old_map->pgoff;
> > +
> > +   dso__put(new_map->dso);
> > +   new_map->dso = dso__get(old_map->dso);
> > +   }
> > }
> >  
> > map__put(new_map);
> > }
> >  
> > +   /* Remove old maps */
> > +   old_map = map_groups__first(_mg, map->type);
> > +   while (old_map) {
> > +   struct map *next = map_groups__next(old_map);
> > +
> > +   map_groups__remove(_mg, old_map);
> > +   old_map = next;
> > +   }
> > +
> > /*
> >  * Set the data type and long name so that kcore can be read via
> >  * dso__data_read_addr().
> > -- 
> > 2.13.1

Re: [PATCH/RFC 5/9] perf symbols: Fixup the end address of kernel map properly

[Namhyung Kim]

On Fri, Jun 23, 2017 at 11:27:25AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 23, 2017 at 02:48:23PM +0900, Namhyung Kim escreveu:
> > When /proc/kallsyms is used for kernel address, addresses in module can
> > be changed when the module is reloaded.  So if one did perf record with
> > some module and then for some reason reload the module.  Then perf
> > report might see a different address for the module and the output can
> > show incorrect symbols.
> 
> If we, as mentioned in another message, make sure that no module reload
> is performed while perf record is running, and then refuse to use
> kallsyms if the buildid for the running module is different from the one
> in the perf.data build id header, then this is solved, no?

No.  This can happen when a (same) module is reload at a different
address.  Even if we refuse the symbols of the module in
dso__split_kallsyms(), the last symbols in the kernel dso was already
fixed up with a different address and then the map end address would
be invalid.  This can make the module map overlapped to the kernel
map, so invisible when it finds maps for samples.

Thanks,
Namhyung


>  
> > For example, let a module XXX was loaded at 0x8a00, the
> > /proc/kallsyms might show following:
> > 
> >   ...
> >   0x81234560 t last_symbol_in_vmlinux
> >   0x8a00 t first_symbol_in_XXX
> >   ...
> > 
> > As kallsyms fixs up the symbol and map address by using next address,
> > the end address of last_symbol and kernel map would be start address of
> > XXX (0x8a00).  And samples in 0x8a001234 can be
> > found in a map for XXX module.
> > 
> > But later, XXX was reloaded at 0x8a007000, slightly higher than
> > before.  Now reading /proc/kallsyms tells that the end address of last
> > symbol would be 0xfff8a007000 and so kernel map is same.  Now
> > samples in 0x8a001234 - formerly in the XXX module - would go to
> > the kernel map and show no symbols.
> > 
> > In this case, perf can know the address of map of XXX from mmap event in
> > perf.data so it can adjust kernel map address using the address of XXX
> > map.  To do that, replace map__fixup_end() by __map_groups__fixup_end().
> > This still have incorrect end address of last symbol in the kernel map
> > but it's ok since samples in that address wouldn't go to the kernel map
> > anyway.
> > 
> > Cc: Adrian Hunter 
> > Cc: Wang Nan 
> > Signed-off-by: Namhyung Kim 
> > ---
> >  tools/perf/util/symbol.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index 74078ba595b3..ce79a51f25bf 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -1832,7 +1832,7 @@ static int dso__load_kernel_sym(struct dso *dso, 
> > struct map *map)
> > dso->binary_type = DSO_BINARY_TYPE__KALLSYMS;
> > dso__set_long_name(dso, DSO__NAME_KALLSYMS, false);
> > map__fixup_start(map);
> > -   map__fixup_end(map);
> > +   __map_groups__fixup_end(map->groups, map->type);
> > }
> >  
> > return err;
> > @@ -1880,7 +1880,7 @@ static int dso__load_guest_kernel_sym(struct dso 
> > *dso, struct map *map)
> > machine__mmap_name(machine, path, sizeof(path));
> > dso__set_long_name(dso, strdup(path), true);
> > map__fixup_start(map);
> > -   map__fixup_end(map);
> > +   __map_groups__fixup_end(map->groups, map->type);
> > }
> >  
> > return err;
> > -- 
> > 2.13.1

[PATCH v2] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis.

[Srishti Sharma]

Fixed alignment so that it matched open parenthesis.

Signed-off-by: Srishti Sharma 
---
Changes in v2:
 -Fix all checks of the type "alignment should match open parenthesis" for a 
file in the same patch.

 .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c  | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
index f484bb0..ce8ab36 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
@@ -105,7 +105,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_ctl_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+  struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int changed = 0;
@@ -185,7 +185,7 @@ static struct snd_kcontrol_new snd_bcm2835_ctl[] = {
 };

 static int snd_bcm2835_spdif_default_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+ struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -193,7 +193,7 @@ static int snd_bcm2835_spdif_default_info(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_default_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -210,7 +210,7 @@ static int snd_bcm2835_spdif_default_get(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_default_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
@@ -230,7 +230,7 @@ static int snd_bcm2835_spdif_default_put(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+  struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -238,7 +238,7 @@ static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+ struct snd_ctl_elem_value *ucontrol)
 {
/*
 * bcm2835 supports only consumer mode and sets all other format flags
@@ -249,7 +249,7 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_spdif_stream_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -257,7 +257,7 @@ static int snd_bcm2835_spdif_stream_info(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -274,7 +274,7 @@ static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_spdif_stream_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
--
2.7.4

Re: [PATCH 3/4] btrfs: Add zstd support

[kbuild test robot]

Hi Nick,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc6 next-20170623]
[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/Nick-Terrell/lib-Add-xxhash-module/20170625-214344
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All error/warnings (new ones prefixed by >>):

   lib//zstd/fse_compress.c: In function 'FSE_buildCTable_wksp':
>> lib//zstd/fse_compress.c:181:1: warning: the frame size of 1036 bytes is 
>> larger than 1024 bytes [-Wframe-larger-than=]
}
^
   lib//zstd/fse_compress.c: In function 'FSE_compress_wksp':
   lib//zstd/fse_compress.c:857:1: warning: the frame size of 1552 bytes is 
larger than 1024 bytes [-Wframe-larger-than=]
}
^
--
   lib//zstd/compress.c: In function 'ZSTD_compressBlock_lazy':
>> lib//zstd/compress.c:2036:1: error: unable to find a register to spill in 
>> class 'CCREGS'
static void ZSTD_compressBlock_lazy(ZSTD_CCtx *ctx, const void *src, size_t 
srcSize) { ZSTD_compressBlock_lazy_generic(ctx, src, srcSize, 0, 1); }
^~
>> lib//zstd/compress.c:2036:1: error: this is the insn:
   (insn 213 11 1172 9 (set (reg:BI 1429)
   (eq:BI (reg/v:SI 62 [ mls ])
   (const_int 5 [0x5]))) lib//zstd/compress.c:1855 118 {compare_eq}
(nil))
   lib//zstd/compress.c:2036: confused by earlier errors, bailing out
--
   lib//zstd/huf_decompress.c: In function 'HUF_readDTableX4':
>> lib//zstd/huf_decompress.c:556:1: warning: the frame size of 1636 bytes is 
>> larger than 1024 bytes [-Wframe-larger-than=]
}
^

vim +/CCREGS +2036 lib//zstd/compress.c

87a5643e Nick Terrell 2017-06-22  2020  /* Save reps for next block */
87a5643e Nick Terrell 2017-06-22  2021  ctx->repToConfirm[0] = offset_1 
? offset_1 : savedOffset;
87a5643e Nick Terrell 2017-06-22  2022  ctx->repToConfirm[1] = offset_2 
? offset_2 : savedOffset;
87a5643e Nick Terrell 2017-06-22  2023  
87a5643e Nick Terrell 2017-06-22  2024  /* Last Literals */
87a5643e Nick Terrell 2017-06-22  2025  {
87a5643e Nick Terrell 2017-06-22  2026  size_t const lastLLSize 
= iend - anchor;
87a5643e Nick Terrell 2017-06-22  2027  
memcpy(seqStorePtr->lit, anchor, lastLLSize);
87a5643e Nick Terrell 2017-06-22  2028  seqStorePtr->lit += 
lastLLSize;
87a5643e Nick Terrell 2017-06-22  2029  }
87a5643e Nick Terrell 2017-06-22  2030  }
87a5643e Nick Terrell 2017-06-22  2031  
87a5643e Nick Terrell 2017-06-22  2032  static void 
ZSTD_compressBlock_btlazy2(ZSTD_CCtx *ctx, const void *src, size_t srcSize) { 
ZSTD_compressBlock_lazy_generic(ctx, src, srcSize, 1, 2); }
87a5643e Nick Terrell 2017-06-22  2033  
87a5643e Nick Terrell 2017-06-22  2034  static void 
ZSTD_compressBlock_lazy2(ZSTD_CCtx *ctx, const void *src, size_t srcSize) { 
ZSTD_compressBlock_lazy_generic(ctx, src, srcSize, 0, 2); }
87a5643e Nick Terrell 2017-06-22  2035  
87a5643e Nick Terrell 2017-06-22 @2036  static void 
ZSTD_compressBlock_lazy(ZSTD_CCtx *ctx, const void *src, size_t srcSize) { 
ZSTD_compressBlock_lazy_generic(ctx, src, srcSize, 0, 1); }
87a5643e Nick Terrell 2017-06-22  2037  
87a5643e Nick Terrell 2017-06-22  2038  static void 
ZSTD_compressBlock_greedy(ZSTD_CCtx *ctx, const void *src, size_t srcSize) { 
ZSTD_compressBlock_lazy_generic(ctx, src, srcSize, 0, 0); }
87a5643e Nick Terrell 2017-06-22  2039  
87a5643e Nick Terrell 2017-06-22  2040  FORCE_INLINE
87a5643e Nick Terrell 2017-06-22  2041  void 
ZSTD_compressBlock_lazy_extDict_generic(ZSTD_CCtx *ctx, const void *src, size_t 
srcSize, const U32 searchMethod, const U32 depth)
87a5643e Nick Terrell 2017-06-22  2042  {
87a5643e Nick Terrell 2017-06-22  2043  seqStore_t *seqStorePtr = 
&(ctx->seqStore);
87a5643e Nick Terrell 2017-06-22  2044  const BYTE *const istart = 
(const BYTE *)src;

:: The code at line 2036 was first introduced by commit
:: 87a5643e3b02e4cb9fb83bf8f6da13be18677883 lib: Add zstd modules

:: TO: Nick Terrell <terre...@fb.com>
:: CC: 0day robot <fengguang...@intel.com>

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


.config.gz
Description: application/gzip

[PATCH] soc/qman: Sleep instead of stuck hacking jiffies.

[Karim Eshapa]

Use msleep() instead of stucking with
long delay will be more efficient.

Signed-off-by: Karim Eshapa 
---
 drivers/soc/fsl/qbman/qman.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 3d891db..18d391e 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1084,11 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
 * entries well before the ring has been fully consumed, so
 * we're being *really* paranoid here.
 */
-   u64 now, then = jiffies;
-
-   do {
-   now = jiffies;
-   } while ((then + 1) > now);
+   msleep(1);
msg = qm_mr_current(p);
if (!msg)
return 0;
-- 
2.7.4

Re: [PATCH] ARM: dts: exynos: Exynos5422 Odroid-XU* incomplete thermal-zones definition

[Krzysztof Kozlowski]

On Sun, Jun 25, 2017 at 08:48:13PM +0530, Anand Moon wrote:
> Hi Krzystof,
> >> 2: We should also increase the tips from 4 to 8 to support different
> >> cluster of cpu's.
> >
> > There are 4 CPU thermal zones on Exynos5422. What do you want to expand?
> 
> What I meant was to support more trip point to address below.
> [2.776320] exynos-tmu 100a.tmu: More trip points than
> supported by this TMU.
> [2.782370] exynos-tmu 100a.tmu: 2 trip points should be
> configured in polling mode.
> 

I do not understand what you want to achieve. I added 2 trip points in
polling mode for the CPU cooling mode. Just describe the problem and
send the patch - it is the best way to explain one's thought...

> >> 3: To avoid duplication of cooling-maps we can make tmu sensor work
> >> differently for cluster of cpu's
> >>   tmu_cpu0: handle pwm-fan control.
> >>   tmu_cpu1: handle cpu[0-3] cpufreq mapping.
> >>   tmu_cpu2: handle cpu[4-7] cpufreq mapping.
> >
> > I miss the point behind this. Why fan should work only when CPU4
> > (tmu_cpu0) is heated and not CPU5-7 (rest of cpu tmu's)?
> 
> Ok fan should work on all the thermal zone. To avoid thermal shutdown.
> 
> But I want to avoid scaling down of all the cores of cpu to low freq
> as cooling-maps cross the alert temperature. For below example.
> 
>  map3 {
>   trip = <_alert3>;
>   cooling-device = < 0 2>;
>  };
>  map4 {
>   trip = <_alert3>;
>   cooling-device = < 0 2>;
>  };
> 
>  map5 {
>   trip = <_alert4>;
>   cooling-device = < 3 7>;
>  };
>  map6 {
>  trip = <_alert4>;
>  cooling-device = < 3 12>;
>  };
> 
> What I want to configure thermal zone as.
> 
> cpu0_thermal: cpu0-thermal {
>  configure cluster of cpu[0-3]
>  {
> tips
>  }
>  cooling map
>  {
>  device handle cpu[0-3] with frequency scaling at particular
> alert temperature.
>  }
> }

cpu0_thermal is attached to tmu_cpu0 which is the temperature of CPU4
(first big core). I do not see reason behind connecting thermal zone
(thus temperature) of CPU4 with frequency of LITTLE cluster (CPU0-3). In
case of busy CPU4, you will scale down CPU0-3. Does not make sense.

> cpu1_thermal: cpu1-thermal {
>  configure cluster of cpu[4-7]
>  {
> tips
>  }
>  cooling map
>  {
>  device handle cpu[4-7] with frequency scaling at particular
> alert temperature.
>  }
> }
> 
> We can chose to configure rest of the thermal-zone on this approach.
> Please share your thoughts.

I am sorry, I do not understand the idea, the problem nor the solution.

Best regards,
Krzysztof

Re: [PATCH] net/icmp: restore source address if packet is NATed

[David Miller]

From: "Jason A. Donenfeld" 
Date: Sat, 24 Jun 2017 04:17:27 +0200

> The ICMP routines use the source address for two reasons:
> 
> 1. Rate-limiting ICMP transmissions based on source address, so
>that one source address cannot provoke a flood of replies. If
>the source address is wrong, the rate limiting will be
>incorrectly applied.
> 
> 2. Choosing the interface and hence new source address of the
>generated ICMP packet. If the original packet source address
>is wrong, ICMP replies will be sent from the wrong source
>address, resulting in either a misdelivery, infoleak, or just
>general network admin confusion.
> 
> Most of the time, the icmp_send and icmpv6_send routines can just reach
> down into the skb's IP header to determine the saddr. However, if
> icmp_send or icmpv6_send is being called from a network device driver --
> there are a few in the tree -- then it's possible that by the time
> icmp_send or icmpv6_send looks at the packet, the packet's source
> address has already been transformed by SNAT or MASQUERADE or some other
> transformation that CONNTRACK knows about. In this case, the packet's
> source address is most certainly the *wrong* source address to be used
> for the purpose of ICMP replies.
> 
> Rather, the source address we want to use for ICMP replies is the
> original one, from before the transformation occurred.
> 
> Fortunately, it's very easy to just ask CONNTRACK if it knows about this
> packet, and if so, how to fix it up. The saddr is the only field in the
> header we need to fix up, for the purposes of the subsequent processing
> in the icmp_send and icmpv6_send functions, so we do the lookup very
> early on, so that the rest of the ICMP machinery can progress as usual.
> In my tests, this setup works very well.
> 
> Signed-off-by: Jason A. Donenfeld 

This violates things on so many levels.

I think this kind of thing need to be hidden inside of netfilter,
it can do the rate limiting and stuff like that in the spot
where it makes the transformation and knows all of the original
addressing and ports.

You definitely can't just rewrite header fields here either.  The
SKB could be shared, for example.

I'm definitely not applying this, sorry.

Re: [PATCH net-next] net: add netlink_ext_ack support to rtnl_link_ops

[David Miller]

From: Matthias Schiffer 
Date: Sat, 24 Jun 2017 13:35:17 +0200

> The following functions are extended with a netlink_ext_ack argument to
> allow extended error reporting:
> 
> * validate
> * newlink
> * changelink
> * slave_validate
> * slave_changelink
> 
> Signed-off-by: Matthias Schiffer 

Like David Ahern, I think you should split this patch up.

Thanks.

[PATCH] lib: vsprintf: add printf format conversion %M for errno strings

[Enrico Weigelt, metux IT consult]

Adding a new format conversion for *printf() and friends.

If CONFIG_ERRNO_PRINTF_VERBOSE is enabled, prints human-readable
strerror()-like texts, otherwise just the number.
---
 lib/Kconfig|  19 +++
 lib/vsprintf.c | 172 -
 2 files changed, 189 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index 0c8b78a9ae2e..b28ab2162435 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -7,6 +7,25 @@ config BINARY_PRINTF
 
 menu "Library routines"
 
+config ERRNO_PRINTF
+   bool "printf conversion %M for errno codes"
+   default n
+   help
+ This option adds an %M modifier for *printf() for errno values.
+ (and callers like printk() etc)
+
+ In conjunction with ERRNO_PRINTF_VERBOSE, it prints human readable
+ strerror()-like textsm, otherwise just numeric values
+
+config ERRNO_PRINTF_VERBOSE
+   bool "Verbose errno strings"
+   default y
+   depends on ERRNO_PRINTF
+   help
+ Enable verbose error strings for ERRNO_PRINTF.
+
+ Small embedded systems might disable it for reducing kernel size.
+
 config RAID6_PQ
tristate
 
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 2d41de3f98a1..9778e17fc178 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -382,7 +382,8 @@ enum format_type {
FORMAT_TYPE_UINT,
FORMAT_TYPE_INT,
FORMAT_TYPE_SIZE_T,
-   FORMAT_TYPE_PTRDIFF
+   FORMAT_TYPE_PTRDIFF,
+   FORMAT_TYPE_ERRNO,
 };
 
 struct printf_spec {
@@ -600,6 +601,164 @@ char *string(char *buf, char *end, const char *s, struct 
printf_spec spec)
return widen_string(buf, len, end, spec);
 }
 
+#if IS_ENABLED(CONFIG_ERRNO_PRINTF_VERBOSE)
+static noinline_for_stack
+const char *errno_to_str(int no)
+{
+   switch (no) {
+   case 0: return "Success";
+   case EPERM: return "Operation not permitted";
+   case ENOENT:return "No such file or directory";
+   case ESRCH: return "No such process";
+   case EINTR: return "Interrupted system call";
+   case EIO:   return "I/O error";
+   case ENXIO: return "No such device or address";
+   case E2BIG: return "Argument list too long";
+   case ENOEXEC:   return "Exec format error";
+   case EBADF: return "Bad file number";
+   case ECHILD:return "No child processes";
+   case EAGAIN:return "Try again";
+   case ENOMEM:return "Out of memory";
+   case EACCES:return "Permission denied";
+   case EFAULT:return "Bad address";
+   case ENOTBLK:   return "Block device required";
+   case EBUSY: return "Device or resource busy";
+   case EEXIST:return "File exists";
+   case EXDEV: return "Cross-device link";
+   case ENODEV:return "No such device";
+   case ENOTDIR:   return "Not a directory";
+   case EISDIR:return "Is a directory";
+   case EINVAL:return "Invalid argument";
+   case ENFILE:return "File table overflow";
+   case EMFILE:return "Too many open files";
+   case ENOTTY:return "Not a typewriter";
+   case ETXTBSY:   return "Text file busy";
+   case EFBIG: return "File too large";
+   case ENOSPC:return "No space left on device";
+   case ESPIPE:return "Illegal seek";
+   case EROFS: return "Read-only file system";
+   case EMLINK:return "Too many links";
+   case EPIPE: return "Broken pipe";
+   case EDOM:  return "Math argument out of domain of func";
+   case ERANGE:return "Math result not representable";
+   case EDEADLK:   return "Resource deadlock would occur";
+   case ENAMETOOLONG:  return "File name too long";
+   case ENOLCK:return "No record locks available";
+   case ENOSYS:return "Invalid system call number";
+   case ENOTEMPTY: return "Directory not empty";
+   case ELOOP: return "Too many symbolic links encountered";
+   case ENOMSG:return "No message of desired type";
+   case EIDRM: return "Identifier removed";
+   case ECHRNG:return "Channel number out of range";
+   case EL2NSYNC:  return "Level 2 not synchronized";
+   case EL3HLT:return "Level 3 halted";
+   case EL3RST:return "Level 3 reset";
+   case ELNRNG:return "Link number out of range";
+   case EUNATCH:   return "Protocol driver not attached";
+   case ENOCSI:return "No CSI structure available";
+   case EL2HLT:return "Level 2 halted";
+ 

Re: [PATCH] android: Update maintainer's e-mail in TODO

[Greg Kroah-Hartman]

On Sun, Jun 25, 2017 at 08:17:23AM -0400, Tommy Nguyen wrote:
> See https://lkml.org/lkml/2012/1/31/505

What does a 5 year old email have to do with anything?

> Changes dead e-mail to maintainer's current e-mail.

Since when is my email address "dead"?

Sorry, but this patch makes no sense at all...

greg k-h

Re: [PATCH 1/2] staging: sm750fb: avoid conflicting vesafb

[Greg Kroah-Hartman]

On Sun, Jun 25, 2017 at 02:54:29PM +0100, Sudip Mukherjee wrote:
> On Sun, Jun 25, 2017 at 02:54:51PM +0200, Greg Kroah-Hartman wrote:
> > On Sun, Jun 25, 2017 at 01:43:34PM +0100, Sudip Mukherjee wrote:
> > > On Mon, Jun 19, 2017 at 09:32:57PM +0100, Sudip Mukherjee wrote:
> > > > From: Teddy Wang 
> > > > 
> > > > If vesafb is enabled in the config then /dev/fb0 is created by vesa
> > > > and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to
> > > > effectively work with xorg.
> > > > So if it has been alloted fb1, then try to remove the other fb0.
> > > > 
> > > > Signed-off-by: Teddy Wang 
> > > > Signed-off-by: Sudip Mukherjee 
> > > > ---
> > > 
> > > Hi Greg,
> > > You applied the second patch but not this one. Did I miss any review
> > > comments from you about this one?
> > 
> > All of the other complaints about this patch were not sufficient for me
> > to justify ignoring it?  Why would I not listen to them?
> 
> This patch is doing what all the drm drivers are doing. So you want
> us to do something completely new rather than following the established
> practice of a drm driver?

I despise cargo-cult programming.  You could not answer the "why", so
why would I accept such a patch?

greg k-h

Re: [PATCH] staging: wlan-ng: Fix sparse warning: incorrect type in assignment This patch fixes the following sparse warning

[Greg KH]

On Fri, Jun 23, 2017 at 04:21:54AM +0200, AbdAllah-MEZITI wrote:
> drivers/staging/wlan-ng/prism2mgmt.c:188:25: warning: incorrect type in 
> assignment (different base types)
> drivers/staging/wlan-ng/prism2mgmt.c:188:25:expected unsigned short 
> [unsigned] [addressable] [usertype] tx_rate
> drivers/staging/wlan-ng/prism2mgmt.c:188:25:got restricted __le16 
> [usertype] 
> drivers/staging/wlan-ng/prism2mgmt.c:200:30: warning: incorrect type in 
> assignment (different base types)
> drivers/staging/wlan-ng/prism2mgmt.c:200:30:expected unsigned short 
> [unsigned] [addressable] [usertype] channel_list
> drivers/staging/wlan-ng/prism2mgmt.c:200:30:got restricted __le16 
> [usertype] 
> drivers/staging/wlan-ng/prism2mgmt.c:203:26: warning: incorrect type in 
> assignment (different base types)
> drivers/staging/wlan-ng/prism2mgmt.c:203:26:expected unsigned short 
> [unsigned] [addressable] [usertype] len
> drivers/staging/wlan-ng/prism2mgmt.c:203:26:got restricted __le16 
> [usertype] 
> drivers/staging/wlan-ng/prism2mgmt.c:232:28: warning: incorrect type in 
> assignment (different base types)
> drivers/staging/wlan-ng/prism2mgmt.c:232:28:expected unsigned short 
> [unsigned] [short] 
> drivers/staging/wlan-ng/prism2mgmt.c:232:28:got restricted __le16 
> [usertype] 
> 
> Signed-off-by: AbdAllah-MEZITI 
> ---
>  drivers/staging/wlan-ng/hfa384x.h| 6 +++---
>  drivers/staging/wlan-ng/prism2mgmt.c | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)

Does not apply to my staging-next branch at all :(

Re: PM / wakeirq: Convert to SRCU

[Paul E. McKenney]

On Sun, Jun 25, 2017 at 11:11:57AM +0200, Thomas Gleixner wrote:
> On Sat, 24 Jun 2017, Paul E. McKenney wrote:
> > On Sat, Jun 24, 2017 at 11:56:11AM +0200, Thomas Gleixner wrote:
> > >  static DECLARE_WAIT_QUEUE_HEAD(wakeup_count_wait_queue);
> > > 
> > > +static struct srcu_struct wakeup_srcu;
> > 
> > I suggest this to avoid the need for boot-time init_srcu_struct():
> > 
> > DEFINE_STATIC_SRCU(wakeup_srcu);
> 
> Now I know why I had this nagging feeling, that should stay away from
> computers yesterday morning.

Believe me, I know that feeling well!

> > >  static struct wakeup_source deleted_ws = {
> > >   .name = "deleted",
> > >   .lock =  __SPIN_LOCK_UNLOCKED(deleted_ws.lock),
> > > @@ -198,7 +200,7 @@ void wakeup_source_remove(struct wakeup_
> > >   spin_lock_irqsave(_lock, flags);
> > >   list_del_rcu(>entry);
> > >   spin_unlock_irqrestore(_lock, flags);
> > > - synchronize_rcu();
> > > + synchronize_srcu(_srcu);
> > >  }
> > >  EXPORT_SYMBOL_GPL(wakeup_source_remove);
> > 
> > The uses of RCU in device_wakeup_arm_wake_irqs() and
> > device_wakeup_disarm_wake_irqs() are unrelated and thus do not
> > need to be converted?  Or am I looking at the wrong version of
> > the kernel?  (Looking at f65013d655ac ("Merge branch 'for-linus' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace")
> > in Linus's tree.)
> 
> No, you are looking at the result of heat induced brain melt. Will send a
> proper one soon.

And if anything, I know that feeling even better.  Looking forward to
seeing the new patch.

Thanx, Paul

Re: [PATCH v1 3/5] [media] stm32-dcmi: crop sensor image to match user resolution

[kbuild test robot]

Hi Hugues,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on next-20170623]
[cannot apply to v4.12-rc6]
[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/Hugues-Fruchet/Camera-support-on-STM32F746G-DISCO-board/20170625-204425
base:   git://linuxtv.org/media_tree.git master


coccinelle warnings: (new ones prefixed by >>)

>> drivers/media/platform/stm32/stm32-dcmi.c:808:2-3: Unneeded semicolon
   drivers/media/platform/stm32/stm32-dcmi.c:562:2-3: Unneeded semicolon
   drivers/media/platform/stm32/stm32-dcmi.c:762:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

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

Re: [PATCH v2 2/2] i2c: Add Spreadtrum I2C controller driver

[Andy Shevchenko]

On Wed, Jun 21, 2017 at 10:23 AM, Baolin Wang
 wrote:
> This patch adds the I2C controller driver for Spreadtrum platform.

Needs more work.
See my comments below.



> +#include 

> +#include 

Since your answer to the comment about arch_initcall you perhaps need
to get rid of tristate (use bool) and drop module.h here and all
leftovers like MODULE_*() calls.

> +#include 

Should we include this still explicitly (after kernel.h)?

> +
> +#define I2C_CTL0x0
> +#define I2C_ADDR_CFG   0x4
> +#define I2C_COUNT  0x8
> +#define I2C_RX 0xC
> +#define I2C_TX 0x10
> +#define I2C_STATUS 0x14
> +#define I2C_HSMODE_CFG 0x18
> +#define I2C_VERSION0x1C
> +#define ADDR_DVD0  0x20
> +#define ADDR_DVD1  0x24
> +#define ADDR_STA0_DVD  0x28
> +#define ADDR_RST   0x2C

1. Please, use fixed sized values
0x00 and so on.
2. Please, low case.

> +#define SPRD_I2C_TIMEOUT   (msecs_to_jiffies(1000))

Redundant parens.

> +static void sprd_i2c_dump_reg(struct sprd_i2c *i2c_dev)

If you switch your driver to regmap API, you may drop this function completely.

> +   writel(tmp & (~STP_EN), i2c_dev->base + I2C_CTL);

Redundant parens.
Also pay attention to other similar places.


> +static void sprd_i2c_write_bytes(struct sprd_i2c *i2c_dev, u8 *buf, u32 len)

So, isn't better to provide a writesb(), readsb() to ia64 instead of
doing below?

> +{
> +   u32 i = 0;
> +
> +   for (i = 0; i < len; i++) {
> +   writel(buf[i], i2c_dev->base + I2C_TX);

> +   dev_dbg(_dev->adap.dev, "write bytes[%d] = %x\n", i, 
> buf[i]);

Moreover, don't waste lines in the kernel log buffer by doing this.
Choose either

%*ph (up to 64 bytes)

or

print_hex_dump()

(Same for _read_bytes() below)

> +   }
> +}

> +static void sprd_i2c_set_full_thld(struct sprd_i2c *i2c_dev, u32 full_thld)
> +{
> +   unsigned int tmp = readl(i2c_dev->base + I2C_CTL);
> +
> +   tmp &= ~(0xf << FIFO_AF_LVL);

Magic.
Define it using GENMASK()

> +   tmp |= (full_thld << FIFO_AF_LVL);

Redundant parens.

> +   tmp &= ~(0xf << FIFO_AE_LVL);
> +   tmp |= (empty_thld << FIFO_AE_LVL);

Same.

> +static void sprd_i2c_opt_mode(struct sprd_i2c *i2c_dev, int rw)
> +{
> +   unsigned int cmd = readl(i2c_dev->base + I2C_CTL) & (~I2C_MODE);

Redundant parens.

> +   writel((cmd | rw << 3), i2c_dev->base + I2C_CTL);

Ditto.

It's a C, and not a LISP :-)

> +}

> +static void sprd_i2c_data_transfer(struct sprd_i2c *i2c_dev)
> +{

> +   if ((msg->flags & I2C_M_RD)) {

Redundant parens.

> +   /* Reset rx/tx fifos */

Noise.

> +   /* Set device address */

Ditto.

> +   /* Set I2C read or write bytes count */

Ditto.

> +   if ((msg->flags & I2C_M_RD)) {
> +   /* Set read operation */
> +   sprd_i2c_opt_mode(i2c_dev, 1);
> +   /* Last byte transmission should excute stop operation */
> +   sprd_i2c_send_stop(i2c_dev, 1);

Same comments as above.

> +   } else {

> +   /* Set write operation */

Noise.

> +   /* Last byte transmission should excute stop operation */
> +   if (is_last_msg)
> +   sprd_i2c_send_stop(i2c_dev, 1);
> +   else
> +   sprd_i2c_send_stop(i2c_dev, 0);

sprd_i2c_send_stop(i2c_dev, !!is_last_msg);

Though, consider to make is_last_msg boolean.

> +static int sprd_i2c_master_xfer(struct i2c_adapter *i2c_adap,
> +   struct i2c_msg *msgs, int num)
> +{
> +   struct sprd_i2c *i2c_dev = i2c_adap->algo_data;
> +   int im, ret;
> +
> +   ret = pm_runtime_get_sync(i2c_dev->dev);
> +   if (ret < 0)
> +   return ret;
> +

> +   for (im = 0; im != num; im++)

im < num - 1, and...

ret = sprd_i2c_handle_msg(i2c_adap, [im], 0);
... ret = sprd_i2c_handle_msg(i2c_adap, [im++], 1);

...and we clearly see that you have messed up with returned code on
each itteration here

> +   pm_runtime_mark_last_busy(i2c_dev->dev);
> +   pm_runtime_put_autosuspend(i2c_dev->dev);


> +   return (ret >= 0) ? im : ret;

Usual pattern is
ret < 0 ? ret : im;


> +static void sprd_i2c_set_clk(struct sprd_i2c *i2c_dev, unsigned int freq)
> +{
> +   u32 apb_clk = i2c_dev->src_clk;
> +   u32 i2c_dvd = apb_clk / (4 * freq) - 1;
> +   u32 high = ((i2c_dvd << 1) * 2) / 5;
> +   u32 low = ((i2c_dvd << 1) * 3) / 5;

> +   u32 div0 = (high & 0x) << 16 | (low & 0x);
> +   u32 div1 =  (high & 0x) | ((low & 0x) >> 16);

Magic masks all over.

Also it needs a comment what formula is used and how.

> +
> +   writel(div0, i2c_dev->base + ADDR_DVD0);
> +   writel(div1, i2c_dev->base + ADDR_DVD1);
> +

> +   if (freq == 40)
> +   writel((6 * apb_clk) / 

Re: [PATCH 1/2] staging: sm750fb: avoid conflicting vesafb

[Sudip Mukherjee]

On Sun, Jun 25, 2017 at 04:27:23PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Jun 25, 2017 at 02:54:29PM +0100, Sudip Mukherjee wrote:
> > On Sun, Jun 25, 2017 at 02:54:51PM +0200, Greg Kroah-Hartman wrote:
> > > On Sun, Jun 25, 2017 at 01:43:34PM +0100, Sudip Mukherjee wrote:
> > > > On Mon, Jun 19, 2017 at 09:32:57PM +0100, Sudip Mukherjee wrote:
> > > > > From: Teddy Wang 
> > > > > 
> > > > > If vesafb is enabled in the config then /dev/fb0 is created by vesa
> > > > > and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to
> > > > > effectively work with xorg.
> > > > > So if it has been alloted fb1, then try to remove the other fb0.
> > > > > 
> > > > > Signed-off-by: Teddy Wang 
> > > > > Signed-off-by: Sudip Mukherjee 
> > > > > ---
> > > > 
> > > > Hi Greg,
> > > > You applied the second patch but not this one. Did I miss any review
> > > > comments from you about this one?
> > > 
> > > All of the other complaints about this patch were not sufficient for me
> > > to justify ignoring it?  Why would I not listen to them?
> > 
> > This patch is doing what all the drm drivers are doing. So you want
> > us to do something completely new rather than following the established
> > practice of a drm driver?
> 
> I despise cargo-cult programming.  You could not answer the "why", so
> why would I accept such a patch?

Did a quick research into "why".
The patch d8801e4df91e ("x86/PCI: Set IORESOURCE_ROM_SHADOW only for the
default VGA device") has started setting IORESOURCE_ROM_SHADOW in flags
for a default VGA device and that is being done only for x86.
And so, we will need that #ifdef to check IORESOURCE_ROM_SHADOW as that
needs to be checked only for a x86 and not for other arch.

--
Regards
Sudip

Re: [PATCH] ARM: dts: exynos: Exynos5422 Odroid-XU* incomplete thermal-zones definition

[Anand Moon]

Hi Krzystof,

On 25 June 2017 at 19:01, Krzysztof Kozlowski  wrote:
> On Sun, Jun 25, 2017 at 06:53:24PM +0530, Anand Moon wrote:
>> Hi Willy,
>>
>> On 24 June 2017 at 02:39, Willy Wolff  wrote:
>> > Odroid XU*-familly boards has thermal sensors per A15 cores, but the actual
>> >  thermal-zones define only cooling-maps action for cpu0.
>> >
>> > If the application is running on all cores but core4 (first core of the A15
>> >  cluster), the CPU can reach high temperature without any proper cooling
>> >  action.
>> >
>> > As already discus in prior mail, and on IRC, it's a quit big code
>> > duplication, but I don't found the write way to express that in a better
>> >  way.
>> >
>> > The situation for this board is that we have multiple sensors, but
>> >  matching cooling devices for these sensors act for the same physical
>> >  device (FAN and A15 cluster, as each core of the cluster share the same
>> >  frequency).
>> > In fact, of-thermal.c:473:thermal_zone_of_sensor_register() can't use
>> > multiple sensors for one single thermal zone.
>> > This patch follow the path taken in arch/arm/boot/dts/qcom-apq8084.dtsi:97
>> >
>> > I'm interested to extending the thermal driver, but it will takes time.
>> >  So this is a workaround before refactoring the driver.
>> > If somebody knows how to write it better, any advice and suggestions
>> > are more than welcome.
>> >
>> > Also, the comment for cpu_alert4 in cooling-maps definition is not
>> > accurate, 11 steps for A15 correspond to 700MHz, not 600MHz.
>> >
>>
>> [snip]
>>
>> Few point to from my side.
>>
>> 1: We should also increase the trip points temperature so that it can
>> throttle at high temperature.
>
> It is not related to this problem. If you wish to address different
> problem related to non-optimal choice of temperature, then please send a
> separate patch explaining chosen values.

Certain task  tends to run slow in current thermal zone setting.
If needed I will send a patch for this.

>> 2: We should also increase the tips from 4 to 8 to support different
>> cluster of cpu's.
>
> There are 4 CPU thermal zones on Exynos5422. What do you want to expand?

What I meant was to support more trip point to address below.
[2.776320] exynos-tmu 100a.tmu: More trip points than
supported by this TMU.
[2.782370] exynos-tmu 100a.tmu: 2 trip points should be
configured in polling mode.

>> 3: To avoid duplication of cooling-maps we can make tmu sensor work
>> differently for cluster of cpu's
>>   tmu_cpu0: handle pwm-fan control.
>>   tmu_cpu1: handle cpu[0-3] cpufreq mapping.
>>   tmu_cpu2: handle cpu[4-7] cpufreq mapping.
>
> I miss the point behind this. Why fan should work only when CPU4
> (tmu_cpu0) is heated and not CPU5-7 (rest of cpu tmu's)?

Ok fan should work on all the thermal zone. To avoid thermal shutdown.

But I want to avoid scaling down of all the cores of cpu to low freq
as cooling-maps cross the alert temperature. For below example.

 map3 {
  trip = <_alert3>;
  cooling-device = < 0 2>;
 };
 map4 {
  trip = <_alert3>;
  cooling-device = < 0 2>;
 };

 map5 {
  trip = <_alert4>;
  cooling-device = < 3 7>;
 };
 map6 {
 trip = <_alert4>;
 cooling-device = < 3 12>;
 };

What I want to configure thermal zone as.

cpu0_thermal: cpu0-thermal {
 configure cluster of cpu[0-3]
 {
tips
 }
 cooling map
 {
 device handle cpu[0-3] with frequency scaling at particular
alert temperature.
 }
}

cpu1_thermal: cpu1-thermal {
 configure cluster of cpu[4-7]
 {
tips
 }
 cooling map
 {
 device handle cpu[4-7] with frequency scaling at particular
alert temperature.
 }
}

We can chose to configure rest of the thermal-zone on this approach.
Please share your thoughts.

Best Regards
-Anand Moon

[PATCH] powerpc/perf: Fix branch event code for power9

[Madhavan Srinivasan]

Correct "branch" event code of Power9 is "r4d05e".
Replace the current "branch" event code with "r4d05e"
and add a hack to use "r10012" as event code for
power9 dd1.

Fixes: d89f473ff6f8 ("powerpc/perf: Fix PM_BRU_CMPL event code for power9")
Reported-by: Anton Blanchard 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power9-events-list.h | 4 +++-
 arch/powerpc/perf/power9-pmu.c | 8 +++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/perf/power9-events-list.h 
b/arch/powerpc/perf/power9-events-list.h
index 71a6bfee5c02..80204e064362 100644
--- a/arch/powerpc/perf/power9-events-list.h
+++ b/arch/powerpc/perf/power9-events-list.h
@@ -16,7 +16,7 @@ EVENT(PM_CYC, 0x0001e)
 EVENT(PM_ICT_NOSLOT_CYC,   0x100f8)
 EVENT(PM_CMPLU_STALL,  0x1e054)
 EVENT(PM_INST_CMPL,0x2)
-EVENT(PM_BRU_CMPL, 0x10012)
+EVENT(PM_BRU_CMPL, 0x4d05e)
 EVENT(PM_BR_MPRED_CMPL,0x400f6)
 
 /* All L1 D cache load references counted at finish, gated by reject */
@@ -56,3 +56,5 @@ EVENT(PM_RUN_CYC, 0x600f4)
 /* Instruction Dispatched */
 EVENT(PM_INST_DISP,0x200f2)
 EVENT(PM_INST_DISP_ALT,0x300f2)
+/* Alternate Branch event code */
+EVENT(PM_BR_CMPL_ALT,  0x10012)
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index bb28e1a41257..f17435e4a489 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -231,7 +231,7 @@ static int power9_generic_events_dd1[] = {
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] =   PM_ICT_NOSLOT_CYC,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] =PM_CMPLU_STALL,
[PERF_COUNT_HW_INSTRUCTIONS] =  PM_INST_DISP,
-   [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] =   PM_BRU_CMPL,
+   [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] =   PM_BR_CMPL_ALT,
[PERF_COUNT_HW_BRANCH_MISSES] = PM_BR_MPRED_CMPL,
[PERF_COUNT_HW_CACHE_REFERENCES] =  PM_LD_REF_L1,
[PERF_COUNT_HW_CACHE_MISSES] =  PM_LD_MISS_L1_FIN,
@@ -453,6 +453,12 @@ static int __init init_power9_pmu(void)
 * sampling scenarios in power9 DD1, instead use PM_INST_DISP.
 */
EVENT_VAR(PM_INST_CMPL, _g).id = PM_INST_DISP;
+   /*
+* Power9 DD1 should use PM_BR_CMPL_ALT event code for
+* "branches" to provide correct counter value.
+*/
+   EVENT_VAR(PM_BRU_CMPL, _g).id = PM_BR_CMPL_ALT;
+   EVENT_VAR(PM_BRU_CMPL, _c).id = PM_BR_CMPL_ALT;
rc = register_power_pmu(_isa207_pmu);
} else {
rc = register_power_pmu(_pmu);
-- 
2.7.4

[PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

[Shanker Donthineni]

The NUMA node information is visible to ITS driver but not being used
other than handling errata. This patch allocates the memory for ITS
tables from the corresponding NUMA node using the appropriate NUMA
aware functions.

Signed-off-by: Shanker Donthineni 
---
 drivers/irqchip/irq-gic-v3-its.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index fed99c5..e45add2 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -860,8 +860,8 @@ static int its_setup_baser(struct its_node *its, struct 
its_baser *baser,
u64 val = its_read_baser(its, baser);
u64 esz = GITS_BASER_ENTRY_SIZE(val);
u64 type = GITS_BASER_TYPE(val);
+   struct page *page;
u32 alloc_pages;
-   void *base;
u64 tmp;
 
 retry_alloc_baser:
@@ -874,12 +874,12 @@ static int its_setup_baser(struct its_node *its, struct 
its_baser *baser,
order = get_order(GITS_BASER_PAGES_MAX * psz);
}
 
-   base = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
-   if (!base)
+   page = alloc_pages_node(its->numa_node, GFP_KERNEL | __GFP_ZERO, order);
+   if (!page)
return -ENOMEM;
 
 retry_baser:
-   val = (virt_to_phys(base)|
+   val = (page_to_phys(page)|
(type << GITS_BASER_TYPE_SHIFT)  |
((esz - 1) << GITS_BASER_ENTRY_SIZE_SHIFT)   |
((alloc_pages - 1) << GITS_BASER_PAGES_SHIFT)|
@@ -915,7 +915,8 @@ static int its_setup_baser(struct its_node *its, struct 
its_baser *baser,
shr = tmp & GITS_BASER_SHAREABILITY_MASK;
if (!shr) {
cache = GITS_BASER_nC;
-   gic_flush_dcache_to_poc(base, 
PAGE_ORDER_TO_SIZE(order));
+   gic_flush_dcache_to_poc(page_to_virt(page),
+   PAGE_ORDER_TO_SIZE(order));
}
goto retry_baser;
}
@@ -926,7 +927,7 @@ static int its_setup_baser(struct its_node *its, struct 
its_baser *baser,
 * size and retry. If we reach 4K, then
 * something is horribly wrong...
 */
-   free_pages((unsigned long)base, order);
+   __free_pages(page, order);
baser->base = NULL;
 
switch (psz) {
@@ -943,19 +944,19 @@ static int its_setup_baser(struct its_node *its, struct 
its_baser *baser,
pr_err("ITS@%pa: %s doesn't stick: %llx %llx\n",
   >phys_base, its_base_type_string[type],
   val, tmp);
-   free_pages((unsigned long)base, order);
+   __free_pages(page, order);
return -ENXIO;
}
 
baser->order = order;
-   baser->base = base;
+   baser->base = page_to_virt(page);
baser->psz = psz;
tmp = indirect ? GITS_LVL1_ENTRY_SIZE : esz;
 
pr_info("ITS@%pa: allocated %d %s @%lx (%s, esz %d, psz %dK, shr %d)\n",
>phys_base, (int)(PAGE_ORDER_TO_SIZE(order) / (int)tmp),
its_base_type_string[type],
-   (unsigned long)virt_to_phys(base),
+   (unsigned long)page_to_phys(page),
indirect ? "indirect" : "flat", (int)esz,
psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT);
 
@@ -1019,7 +1020,7 @@ static void its_free_tables(struct its_node *its)
 
for (i = 0; i < GITS_BASER_NR_REGS; i++) {
if (its->tables[i].base) {
-   free_pages((unsigned long)its->tables[i].base,
+   __free_pages(virt_to_page(its->tables[i].base),
   its->tables[i].order);
its->tables[i].base = NULL;
}
@@ -1286,7 +1287,8 @@ static bool its_alloc_device_table(struct its_node *its, 
u32 dev_id)
 
/* Allocate memory for 2nd level table */
if (!table[idx]) {
-   page = alloc_pages(GFP_KERNEL | __GFP_ZERO, 
get_order(baser->psz));
+   page = alloc_pages_node(its->numa_node, GFP_KERNEL | __GFP_ZERO,
+   get_order(baser->psz));
if (!page)
return false;
 
@@ -1332,7 +1334,7 @@ static struct its_device *its_create_device(struct 
its_node *its, u32 dev_id,
nr_ites = max(2UL, roundup_pow_of_two(nvecs));
sz = nr_ites * its->ite_size;
sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
-   itt = kzalloc(sz, GFP_KERNEL);
+   itt = kzalloc_node(sz, GFP_KERNEL, its->numa_node);
lpi_map = its_lpi_alloc_chunks(nvecs, _base, _lpis);
if (lpi_map)
col_map = 

Re: [PATCH V4] acpi: acpica: fix acpi parse and parseext cache leaks

[Andy Shevchenko]

On Fri, Jun 23, 2017 at 12:36 PM, Seunghun Han  wrote:
> I'm Seunghun Han, and I work for National Security Research Institute of
> South Korea.


> -   /* Clean up */
> -   do {
> -   if (op) {
> -   status2 =
> -   
> acpi_ps_complete_this_op
> -   (walk_state, op);
> -   if (ACPI_FAILURE
> -   (status2)) {
> -   
> return_ACPI_STATUS
> -   (status2);
> -   }
> -   }
> -
> -   acpi_ps_pop_scope(&
> - 
> (walk_state->
> -  
> parser_state),
> - ,
> - 
> _state->
> - arg_types,
> - 
> _state->
> - arg_count);
> -
> -   } while (op);

I didn't get, do you send an incremental patch as a new version?!

-- 
With Best Regards,
Andy Shevchenko

[PATCH 1/5] clk: mb86s7x: Suppress build

[Andreas Färber]

It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:

  drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such 
file or directory
   #include 
^~~
  compilation terminated.

And when commenting out that line, we get:

  drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
  drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 
'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
  ^~~
  drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' 
undeclared (first use in this function)
ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
  ^~~
  drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported 
only once for each function it appears in
  drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
  drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' 
undeclared (first use in this function)
 code = CMD_PERI_CLOCK_RATE_SET_REQ;
^~~
  drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' 
undeclared (first use in this function); did you mean 
'CMD_PERI_CLOCK_RATE_SET_REQ'?
 code = CMD_PERI_CLOCK_RATE_GET_REQ;
^~~
CMD_PERI_CLOCK_RATE_SET_REQ
  drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
  drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' 
undeclared (first use in this function)
 code = CMD_CPU_CLOCK_RATE_GET_REQ;
^~
  drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' 
undeclared (first use in this function); did you mean 
'CMD_CPU_CLOCK_RATE_GET_REQ'?
 code = CMD_CPU_CLOCK_RATE_SET_REQ;
^~
CMD_CPU_CLOCK_RATE_GET_REQ
  cc1: some warnings being treated as errors
  scripts/Makefile.build:302: recipe for target
  'drivers/clk/clk-mb86s7x.o' failed
  make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1

Comment it out in the Makefile for now.

Signed-off-by: Andreas Färber 
---
 drivers/clk/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4f6a812342ed..0f0ab6f03ccd 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_ARCH_EFM32)  += clk-efm32gg.o
 obj-$(CONFIG_COMMON_CLK_GEMINI)+= clk-gemini.o
 obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)  += clk-max77686.o
-obj-$(CONFIG_ARCH_MB86S7X) += clk-mb86s7x.o
+#obj-$(CONFIG_ARCH_MB86S7X)+= clk-mb86s7x.o
 obj-$(CONFIG_ARCH_MOXART)  += clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
 obj-$(CONFIG_ARCH_NSPIRE)  += clk-nspire.o
-- 
2.12.3

[PATCH 5/5] ARM: dts: mb86s71-f-cue: Add fake UART0 clock

[Andreas Färber]

As long as the clk driver is not building, use a fixed-clock for the UART.

Signed-off-by: Andreas Färber 
---
 arch/arm/boot/dts/mb86s71-f-cue.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/mb86s71-f-cue.dts 
b/arch/arm/boot/dts/mb86s71-f-cue.dts
index 148d1aee11a6..726bf189e8e7 100644
--- a/arch/arm/boot/dts/mb86s71-f-cue.dts
+++ b/arch/arm/boot/dts/mb86s71-f-cue.dts
@@ -27,6 +27,12 @@
device_type = "memory";
reg = <0x8000 0x8000>;
};
+
+   uart0_clk: uart0-clk {
+   compatible = "fixed-clock";
+   clock-frequency = <7813000>;
+   #clock-cells = <0>;
+   };
 };
 
 _timer {
@@ -35,4 +41,6 @@
 
  {
status = "okay";
+   clocks = <_clk>;
+   clock-names = "apb_pclk";
 };
-- 
2.12.3

[PATCH 2/5] ARM: Prepare Socionext MB86S71

[Andreas Färber]

Introduce CONFIG_ARCH_MB86S7X, which was already being used.

Signed-off-by: Andreas Färber 
---
 arch/arm/Kconfig   |  2 ++
 arch/arm/Makefile  |  1 +
 arch/arm/mach-mb86s7x/Kconfig  | 10 ++
 arch/arm/mach-mb86s7x/Makefile |  1 +
 4 files changed, 14 insertions(+)
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f77c77556..cbf56aa0a9e5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -763,6 +763,8 @@ source "arch/arm/mach-keystone/Kconfig"
 
 source "arch/arm/mach-ks8695/Kconfig"
 
+source "arch/arm/mach-mb86s7x/Kconfig"
+
 source "arch/arm/mach-meson/Kconfig"
 
 source "arch/arm/mach-moxart/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..d728548e0e59 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -180,6 +180,7 @@ machine-$(CONFIG_ARCH_KEYSTONE) += keystone
 machine-$(CONFIG_ARCH_KS8695)  += ks8695
 machine-$(CONFIG_ARCH_LPC18XX) += lpc18xx
 machine-$(CONFIG_ARCH_LPC32XX) += lpc32xx
+machine-$(CONFIG_ARCH_MB86S7X) += mb86s7x
 machine-$(CONFIG_ARCH_MESON)   += meson
 machine-$(CONFIG_ARCH_MMP) += mmp
 machine-$(CONFIG_ARCH_MPS2)+= vexpress
diff --git a/arch/arm/mach-mb86s7x/Kconfig b/arch/arm/mach-mb86s7x/Kconfig
new file mode 100644
index ..8fe81bb7da0d
--- /dev/null
+++ b/arch/arm/mach-mb86s7x/Kconfig
@@ -0,0 +1,10 @@
+config ARCH_MB86S7X
+   bool "Socionext MB86S7x SoCs"
+   depends on ARCH_MULTI_V7
+   select ARM_AMBA
+   select ARM_GLOBAL_TIMER
+   select ARM_GIC
+   select HAVE_ARM_SCU
+   select HAVE_ARM_TWD if SMP
+   help
+ Support for MB86S71 SoC family developed by Socionext Inc.
diff --git a/arch/arm/mach-mb86s7x/Makefile b/arch/arm/mach-mb86s7x/Makefile
new file mode 100644
index ..6bea3d3a2dd7
--- /dev/null
+++ b/arch/arm/mach-mb86s7x/Makefile
@@ -0,0 +1 @@
+obj- += dummy.o
-- 
2.12.3

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
socionext.txt.

Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/arm/socionext.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt

diff --git a/Documentation/devicetree/bindings/arm/socionext.txt 
b/Documentation/devicetree/bindings/arm/socionext.txt
new file mode 100644
index ..63227fe7b773
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/socionext.txt
@@ -0,0 +1,17 @@
+Socionext platforms device tree bindings
+
+
+
+MB86S7x SoC
+===
+
+Required root node properties:
+
+ - compatible :  must contain "fujitsu,mb86s71" for MB86S71
+
+
+Boards:
+
+Root node property compatible must contain, depending on board:
+
+ - Fujitsu F-Cue: "fujitsu,f-cue"
-- 
2.12.3

[PATCH 0/5] ARM: Socionext MB86S71 and Fujitsu F-Cue enablement

[Andreas Färber]

Hello,

This mini-series adds initial Device Trees for the Socionext MB86S71 SoC and
the Fujitsu F-Cue board. A clk driver and a gpio driver are already merged,
although the clk driver does not build for lack of an scb mailbox driver.
I am not familiar with the circumstances of those older efforts.

My proposal is to disable the build of the clk driver for now. This allows
to introduce the Kconfig symbol without breaking the build.

With the Device Tree added here it is possible to boot into an initrd,
with one CPU core up.

Cf. https://en.opensuse.org/HCL:F-Cue

More experimental patches at:
https://github.com/afaerber/linux/commits/f-cue-next

Have a lot of fun!

Cheers,
Andreas

Cc: Masahiro Yamada 
Cc: Satoru OKAMOTO 
Cc: devicet...@vger.kernel.org

Cc: Jassi Brar 
Cc: Andy Green 
Cc: Vincent Yang 
Cc: Tetsuya Nuriya 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: Linus Walleij 

Andreas Färber (5):
  clk: mb86s7x: Suppress build
  ARM: Prepare Socionext MB86S71
  dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: mb86s71-f-cue: Add fake UART0 clock

 .../devicetree/bindings/arm/socionext.txt  |  17 ++
 arch/arm/Kconfig   |   2 +
 arch/arm/Makefile  |   1 +
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/mb86s71-f-cue.dts|  46 ++
 arch/arm/boot/dts/mb86s71.dtsi | 178 +
 arch/arm/mach-mb86s7x/Kconfig  |  10 ++
 arch/arm/mach-mb86s7x/Makefile |   1 +
 drivers/clk/Makefile   |   2 +-
 9 files changed, 258 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
 create mode 100644 arch/arm/boot/dts/mb86s71-f-cue.dts
 create mode 100644 arch/arm/boot/dts/mb86s71.dtsi
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile

-- 
2.12.3

[PATCH 4/5] ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Add Device Trees for Socionext MB86S71 SoC and Fujitsu F-Cue board.

Signed-off-by: Andreas Färber 
---
 arch/arm/boot/dts/Makefile  |   2 +
 arch/arm/boot/dts/mb86s71-f-cue.dts |  38 
 arch/arm/boot/dts/mb86s71.dtsi  | 178 
 3 files changed, 218 insertions(+)
 create mode 100644 arch/arm/boot/dts/mb86s71-f-cue.dts
 create mode 100644 arch/arm/boot/dts/mb86s71.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4b17f35dc9a7..48dda2de0a3d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -526,6 +526,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
imx28-m28evk.dtb \
imx28-sps1.dtb \
imx28-tx28.dtb
+dtb-$(CONFIG_ARCH_MB86S7X) += \
+   mb86s71-f-cue.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
ste-nomadik-s8815.dtb \
ste-nomadik-nhk15.dtb
diff --git a/arch/arm/boot/dts/mb86s71-f-cue.dts 
b/arch/arm/boot/dts/mb86s71-f-cue.dts
new file mode 100644
index ..148d1aee11a6
--- /dev/null
+++ b/arch/arm/boot/dts/mb86s71-f-cue.dts
@@ -0,0 +1,38 @@
+/*
+ * Fujitsu F-Cue board
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "mb86s71.dtsi"
+
+/ {
+   compatible = "fujitsu,f-cue", "fujitsu,mb86s71";
+   model = "Fujitsu F-Cue";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   /* vendor U-Boot looks for /memory */
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x8000>;
+   };
+};
+
+_timer {
+   clock-frequency = <12500>;
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/mb86s71.dtsi b/arch/arm/boot/dts/mb86s71.dtsi
new file mode 100644
index ..154f1ab89f0a
--- /dev/null
+++ b/arch/arm/boot/dts/mb86s71.dtsi
@@ -0,0 +1,178 @@
+/*
+ * Socionext MB86S71 SoC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include 
+
+/ {
+   compatible = "fujitsu,mb86s71";
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0x0>;
+   cci-control-port = <_control4>;
+   next-level-cache = <_big>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0x1>;
+   cci-control-port = <_control4>;
+   next-level-cache = <_big>;
+   };
+
+   cpu2: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x100>;
+   cci-control-port = <_control3>;
+   next-level-cache = <_little>;
+   };
+
+   cpu3: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x101>;
+   cci-control-port = <_control3>;
+   next-level-cache = <_little>;
+   };
+
+   l2_big: l2-cache-big {
+   compatible = "cache";
+   };
+
+   l2_little: l2-cache-little {
+   compatible = "cache";
+   };
+   };
+
+   arch_timer: timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+;
+   };
+
+   pmu-big {
+   compatible = "arm,cortex-a15-pmu";
+   interrupts = ,
+;
+   interrupt-affinity = <>, <>;
+   };
+
+   pmu-little {
+   compatible = "arm,cortex-a7-pmu";
+   interrupts = ,
+;
+   interrupt-affinity = <>, <>;
+   };
+
+   cci@2c09 {
+   compatible = "arm,cci-400";
+   reg = <0x2c09 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x2c09 0x1>;
+
+   cci_control0: slave-if@1000 {
+   compatible = "arm,cci-400-ctrl-if";
+   reg = <0x1000 0x1000>;
+   interface-type = "ace-lite";
+   };
+
+   cci_control1: slave-if@2000 {
+   compatible = "arm,cci-400-ctrl-if";
+   reg = <0x2000 0x1000>;
+   interface-type = "ace-lite";
+   };
+
+   

[PATCH 07/10] hyper-v: globalize vp_index

[kys]

From: Vitaly Kuznetsov 

To support implementing remote TLB flushing on Hyper-V with a hypercall
we need to make vp_index available outside of vmbus module. Rename and
globalize.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Andy Shevchenko 
Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/hyperv/hv_init.c   |   34 +-
 arch/x86/include/asm/mshyperv.h |   24 
 drivers/hv/channel_mgmt.c   |7 +++
 drivers/hv/connection.c |3 ++-
 drivers/hv/hv.c |9 -
 drivers/hv/hyperv_vmbus.h   |   11 ---
 drivers/hv/vmbus_drv.c  |   17 -
 drivers/pci/host/pci-hyperv.c   |   10 +-
 include/linux/hyperv.h  |1 -
 9 files changed, 67 insertions(+), 49 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 691603e..e93b9a0 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_HYPERV_TSCPAGE
 
@@ -80,6 +82,20 @@ static u64 read_hv_clock_msr(struct clocksource *arg)
 struct clocksource *hyperv_cs;
 EXPORT_SYMBOL_GPL(hyperv_cs);
 
+u32 *hv_vp_index;
+EXPORT_SYMBOL_GPL(hv_vp_index);
+
+static int hv_cpu_init(unsigned int cpu)
+{
+   u64 msr_vp_index;
+
+   hv_get_vp_index(msr_vp_index);
+
+   hv_vp_index[smp_processor_id()] = msr_vp_index;
+
+   return 0;
+}
+
 /*
  * This function is to be invoked early in the boot sequence after the
  * hypervisor has been detected.
@@ -95,6 +111,16 @@ void hyperv_init(void)
if (x86_hyper != _hyper_ms_hyperv)
return;
 
+   /* Allocate percpu VP index */
+   hv_vp_index = kmalloc_array(num_possible_cpus(), sizeof(*hv_vp_index),
+   GFP_KERNEL);
+   if (!hv_vp_index)
+   return;
+
+   if (cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/hyperv_init:online",
+ hv_cpu_init, NULL) < 0)
+   goto free_vp_index;
+
/*
 * Setup the hypercall page and enable hypercalls.
 * 1. Register the guest ID
@@ -106,7 +132,7 @@ void hyperv_init(void)
hv_hypercall_pg  = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
if (hv_hypercall_pg == NULL) {
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
-   return;
+   goto free_vp_index;
}
 
rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
@@ -149,6 +175,12 @@ void hyperv_init(void)
hyperv_cs = _cs_msr;
if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
clocksource_register_hz(_cs_msr, NSEC_PER_SEC/100);
+
+   return;
+
+free_vp_index:
+   kfree(hv_vp_index);
+   hv_vp_index = NULL;
 }
 
 /*
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index ed8107d..7581251 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -284,6 +284,30 @@ static inline u64 hv_do_rep_hypercall(u16 code, u16 
rep_count, u16 varhead_size,
return status;
 }
 
+/*
+ * Hypervisor's notion of virtual processor ID is different from
+ * Linux' notion of CPU ID. This information can only be retrieved
+ * in the context of the calling CPU. Setup a map for easy access
+ * to this information.
+ */
+extern u32 *hv_vp_index;
+
+/**
+ * hv_cpu_number_to_vp_number() - Map CPU to VP.
+ * @cpu_number: CPU number in Linux terms
+ *
+ * This function returns the mapping between the Linux processor
+ * number and the hypervisor's virtual processor number, useful
+ * in making hypercalls and such that talk about specific
+ * processors.
+ *
+ * Return: Virtual processor number in Hyper-V terms
+ */
+static inline int hv_cpu_number_to_vp_number(int cpu_number)
+{
+   return hv_vp_index[cpu_number];
+}
+
 void hyperv_init(void);
 void hyperv_report_panic(struct pt_regs *regs);
 bool hv_is_hypercall_page_setup(void);
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index f501ce1..331b314 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -600,7 +600,7 @@ static void init_vp_index(struct vmbus_channel *channel, 
u16 dev_type)
 */
channel->numa_node = 0;
channel->target_cpu = 0;
-   channel->target_vp = hv_context.vp_index[0];
+   channel->target_vp = hv_cpu_number_to_vp_number(0);
return;
}
 
@@ -684,7 +684,7 @@ static void init_vp_index(struct vmbus_channel *channel, 
u16 dev_type)
}
 
channel->target_cpu = cur_cpu;
-   channel->target_vp = hv_context.vp_index[cur_cpu];
+   channel->target_vp = hv_cpu_number_to_vp_number(cur_cpu);
 }
 
 static void vmbus_wait_for_unload(void)
@@ -1220,8 +1220,7 @@ struct vmbus_channel 

[PATCH 05/10] hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT

[kys]

From: Vitaly Kuznetsov 

We need to pass only 8 bytes of input for HvSignalEvent which makes it a
perfect fit for fast hypercall. hv_input_signal_event_buffer is not needed
any more and hv_input_signal_event is converted to union for convenience.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Andy Shevchenko 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/channel_mgmt.c |   13 ++---
 drivers/hv/connection.c   |2 +-
 include/linux/hyperv.h|   15 +--
 3 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 0fabd41..f501ce1 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -806,21 +806,12 @@ static void vmbus_onoffer(struct 
vmbus_channel_message_header *hdr)
/*
 * Setup state for signalling the host.
 */
-   newchannel->sig_event = (struct hv_input_signal_event *)
-   (ALIGN((unsigned long)
-   >sig_buf,
-   HV_HYPERCALL_PARAM_ALIGN));
-
-   newchannel->sig_event->connectionid.asu32 = 0;
-   newchannel->sig_event->connectionid.u.id = VMBUS_EVENT_CONNECTION_ID;
-   newchannel->sig_event->flag_number = 0;
-   newchannel->sig_event->rsvdz = 0;
+   newchannel->sig_event = VMBUS_EVENT_CONNECTION_ID;
 
if (vmbus_proto_version != VERSION_WS2008) {
newchannel->is_dedicated_interrupt =
(offer->is_dedicated_interrupt != 0);
-   newchannel->sig_event->connectionid.u.id =
-   offer->connection_id;
+   newchannel->sig_event = offer->connection_id;
}
 
memcpy(>offermsg, offer,
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 45e806e..37ecf51 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -408,6 +408,6 @@ void vmbus_set_event(struct vmbus_channel *channel)
if (!channel->is_dedicated_interrupt)
vmbus_send_interrupt(child_relid);
 
-   hv_do_hypercall(HVCALL_SIGNAL_EVENT, channel->sig_event, NULL);
+   hv_do_fast_hypercall8(HVCALL_SIGNAL_EVENT, channel->sig_event);
 }
 EXPORT_SYMBOL_GPL(vmbus_set_event);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index d1ae02d..2c9a2c8 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -677,18 +677,6 @@ struct vmbus_close_msg {
} u;
 };
 
-/* Definition of the hv_signal_event hypercall input structure. */
-struct hv_input_signal_event {
-   union hv_connection_id connectionid;
-   u16 flag_number;
-   u16 rsvdz;
-};
-
-struct hv_input_signal_event_buffer {
-   u64 align8;
-   struct hv_input_signal_event event;
-};
-
 enum hv_numa_policy {
HV_BALANCED = 0,
HV_LOCALIZED,
@@ -771,8 +759,7 @@ struct vmbus_channel {
} callback_mode;
 
bool is_dedicated_interrupt;
-   struct hv_input_signal_event_buffer sig_buf;
-   struct hv_input_signal_event *sig_event;
+   u64 sig_event;
 
/*
 * Starting with win8, this field will be used to specify
-- 
1.7.1

[PATCH 01/10] x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set

[kys]

From: Vitaly Kuznetsov 

Code is arch/x86/hyperv/ is only needed when CONFIG_HYPERV is set, the
'basic' support and detection lives in arch/x86/kernel/cpu/mshyperv.c
which is included when CONFIG_HYPERVISOR_GUEST is set.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Andy Shevchenko 
Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/Kbuild |2 +-
 arch/x86/include/asm/mshyperv.h |7 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 586b786..3e6f640 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -8,7 +8,7 @@ obj-$(CONFIG_KVM) += kvm/
 obj-$(CONFIG_XEN) += xen/
 
 # Hyper-V paravirtualization support
-obj-$(CONFIG_HYPERVISOR_GUEST) += hyperv/
+obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
 
 # lguest paravirtualization support
 obj-$(CONFIG_LGUEST_GUEST) += lguest/
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 18325dc..66f9f2a 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -174,7 +174,12 @@ static inline void vmbus_signal_eom(struct hv_message 
*msg, u32 old_msg_type)
 void hyperv_report_panic(struct pt_regs *regs);
 bool hv_is_hypercall_page_setup(void);
 void hyperv_cleanup(void);
-#endif
+#else /* CONFIG_HYPERV */
+static inline void hyperv_init(void) {}
+static inline bool hv_is_hypercall_page_setup(void) { return false; }
+static inline hyperv_cleanup(void) {}
+#endif /* CONFIG_HYPERV */
+
 #ifdef CONFIG_HYPERV_TSCPAGE
 struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
 static inline u64 hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg)
-- 
1.7.1

[PATCH 02/10] x86/hyper-v: stash the max number of virtual/logical processor

[kys]

From: Vitaly Kuznetsov 

Max virtual processor will be needed for 'extended' hypercalls supporting
more than 64 vCPUs. While on it, unify on 'Hyper-V' in mshyperv.c as we
currently have a mix, report acquired misc features as well.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Andy Shevchenko 
Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/include/asm/mshyperv.h |2 ++
 arch/x86/kernel/cpu/mshyperv.c  |   12 +---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 66f9f2a..115a0e2 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -29,6 +29,8 @@ struct ms_hyperv_info {
u32 features;
u32 misc_features;
u32 hints;
+   u32 max_vp_index;
+   u32 max_lp_index;
 };
 
 extern struct ms_hyperv_info ms_hyperv;
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 04cb8d3..f259e01 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -175,9 +175,15 @@ static void __init ms_hyperv_init_platform(void)
ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
ms_hyperv.hints= cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
 
-   pr_info("HyperV: features 0x%x, hints 0x%x\n",
+   pr_info("Hyper-V: features 0x%x, hints 0x%x\n",
ms_hyperv.features, ms_hyperv.hints);
 
+   ms_hyperv.max_vp_index = cpuid_eax(HVCPUID_IMPLEMENTATION_LIMITS);
+   ms_hyperv.max_lp_index = cpuid_ebx(HVCPUID_IMPLEMENTATION_LIMITS);
+
+   pr_debug("Hyper-V: max %u virtual processors, %u logical processors\n",
+ms_hyperv.max_vp_index, ms_hyperv.max_lp_index);
+
/*
 * Extract host information.
 */
@@ -203,7 +209,7 @@ static void __init ms_hyperv_init_platform(void)
rdmsrl(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
hv_lapic_frequency = div_u64(hv_lapic_frequency, HZ);
lapic_timer_frequency = hv_lapic_frequency;
-   pr_info("HyperV: LAPIC Timer Frequency: %#x\n",
+   pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n",
lapic_timer_frequency);
}
 
@@ -237,7 +243,7 @@ static void __init ms_hyperv_init_platform(void)
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
-   .name   = "Microsoft HyperV",
+   .name   = "Microsoft Hyper-V",
.detect = ms_hyperv_platform,
.init_platform  = ms_hyperv_init_platform,
 };
-- 
1.7.1

[PATCH 04/10] x86/hyper-v: fast hypercall implementation

[kys]

From: Vitaly Kuznetsov 

Hyper-V supports 'fast' hypercalls when all parameters are passed through
registers. Implement an inline version of a simpliest of these calls:
hypercall with one 8-byte input and no output.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Andy Shevchenko 
Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/include/asm/mshyperv.h |   34 ++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index a004b3b..f3bedb4 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -211,6 +211,40 @@ static inline u64 hv_do_hypercall(u64 control, void 
*input, void *output)
return hv_status;
 }
 
+#define HV_HYPERCALL_FAST_BIT  BIT(16)
+
+/* Fast hypercall with 8 bytes of input and no output */
+static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
+{
+   u64 hv_status, control = (u64)code | HV_HYPERCALL_FAST_BIT;
+   register void *__sp asm(_ASM_SP);
+
+#ifdef CONFIG_X86_64
+   {
+   __asm__ __volatile__("call *%4"
+: "=a" (hv_status), "+r" (__sp),
+  "+c" (control), "+d" (input1)
+: "m" (hv_hypercall_pg)
+: "cc", "r8", "r9", "r10", "r11");
+   }
+#else
+   {
+   u32 input1_hi = upper_32_bits(input1);
+   u32 input1_lo = lower_32_bits(input1);
+
+   __asm__ __volatile__ ("call *%5"
+ : "=A"(hv_status),
+   "+c"(input1_lo),
+   "+r"(__sp)
+ : "A" (control),
+   "b" (input1_hi),
+   "m" (hv_hypercall_pg)
+ : "cc", "edi", "esi");
+   }
+#endif
+   return hv_status;
+}
+
 void hyperv_init(void);
 void hyperv_report_panic(struct pt_regs *regs);
 bool hv_is_hypercall_page_setup(void);
-- 
1.7.1

Re: [PATCH 1/2] staging: sm750fb: avoid conflicting vesafb

[Greg Kroah-Hartman]

On Sun, Jun 25, 2017 at 01:43:34PM +0100, Sudip Mukherjee wrote:
> On Mon, Jun 19, 2017 at 09:32:57PM +0100, Sudip Mukherjee wrote:
> > From: Teddy Wang 
> > 
> > If vesafb is enabled in the config then /dev/fb0 is created by vesa
> > and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to
> > effectively work with xorg.
> > So if it has been alloted fb1, then try to remove the other fb0.
> > 
> > Signed-off-by: Teddy Wang 
> > Signed-off-by: Sudip Mukherjee 
> > ---
> 
> Hi Greg,
> You applied the second patch but not this one. Did I miss any review
> comments from you about this one?

All of the other complaints about this patch were not sufficient for me
to justify ignoring it?  Why would I not listen to them?

Please fix and resend if you want it applied.

thanks,

greg k-h

Re: [PATCH/RFC 4/9] perf symbols: Load kernel module symbols ASAP

[Namhyung Kim]

On Fri, Jun 23, 2017 at 11:26:04AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 23, 2017 at 02:48:22PM +0900, Namhyung Kim escreveu:
> > When loading kernel symbols from /proc/kallsyms, it might have different
> > addresses for modules.  We should honor the mmap event recorded in a
> > perf.data so load the module symbols when it sees the event so that it
> > cannot be overridden by symbols in /proc/kallsyms later.
>  
> > Cc: Adrian Hunter 
> > Cc: Wang Nan 
> > Signed-off-by: Namhyung Kim 
> > ---
> >  tools/perf/util/machine.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> > index d838f893e639..799efe920f0c 100644
> > --- a/tools/perf/util/machine.c
> > +++ b/tools/perf/util/machine.c
> > @@ -656,6 +656,9 @@ struct map *machine__findnew_module_map(struct machine 
> > *machine, u64 start,
> >  
> > map_groups__insert(>kmaps, map);
> >  
> > +   if (dso->has_build_id)
> > +   map__load(map);
> 
> How could this be set at this point? I just tried processing a
> PERF_RECORD_MMAP event for a kernel module and at this point it is set
> to false :-\
> 
> Humm, but I did it for video.ko, that has no hits in this case, so this
> must be coming from reading the perf.data build-id table... /me tries
> that...  yeah, when processing the buildid table in perf.data we
> populate the machine->dsos list and set the dso->has_build_id flag:
> 
> [root@jouet ~]# perf buildid-list | grep .ko
> 57a47c2f0d85ef5726b80e8f55403c3f508a4eac 
> /lib/modules/4.12.0-rc4+/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko
> [root@jouet ~]# 
> (gdb) bt
> #0  machine__findnew_module_map (machine=0x21c6c78, 
> start=18446744072647282688, filename=0x7fd8fc057a00 
> "/lib/modules/4.12.0-rc4+/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko")
> at util/machine.c:650
> #1  0x005094a3 in machine__process_kernel_mmap_event 
> (machine=0x21c6c78, event=0x7fd8fc0579d8) at util/machine.c:1274
> #2  0x005099de in machine__process_mmap_event (machine=0x21c6c78, 
> event=0x7fd8fc0579d8, sample=0x7fffbef0) at util/machine.c:1433
> #3  0x004cc021 in perf_event__process_mmap (tool=0x7fffc440, 
> event=0x7fd8fc0579d8, sample=0x7fffbef0, machine=0x21c6c78) at 
> util/event.c:1265
> #4  0x00512686 in machines__deliver_event (machines=0x21c6c78, 
> evlist=0x21c6f30, event=0x7fd8fc0579d8, sample=0x7fffbef0, 
> tool=0x7fffc440, file_offset=10712)
> at util/session.c:1250
> #5  0x005129ce in perf_session__deliver_event (session=0x21c6b90, 
> event=0x7fd8fc0579d8, sample=0x7fffbef0, tool=0x7fffc440, 
> file_offset=10712) at util/session.c:1310
> #6  0x00513255 in perf_session__process_event (session=0x21c6b90, 
> event=0x7fd8fc0579d8, file_offset=10712) at util/session.c:1490
> #7  0x00513ff4 in __perf_session__process_events (session=0x21c6b90, 
> data_offset=232, data_size=23120, file_size=23352) at util/session.c:1867
> #8  0x005141f2 in perf_session__process_events (session=0x21c6b90) at 
> util/session.c:1921
> #9  0x004427c9 in __cmd_report (rep=0x7fffc440) at 
> builtin-report.c:575
> #10 0x0044427c in cmd_report (argc=0, argv=0x7fffe160) at 
> builtin-report.c:1054
> #11 0x004bad91 in run_builtin (p=0xa28fd0 , argc=2, 
> argv=0x7fffe160) at perf.c:296
> #12 0x004baffe in handle_internal_command (argc=2, 
> argv=0x7fffe160) at perf.c:348
> #13 0x004bb150 in run_argv (argcp=0x7fffdfbc, 
> argv=0x7fffdfb0) at perf.c:392
> #14 0x004bb52a in main (argc=2, argv=0x7fffe160) at perf.c:530
> (gdb) p dso
> $127 = (struct dso *) 0x21c7dc0
> (gdb) p dso->has_build_id
> $128 = 1 '\001'
> (gdb) 
> 
> So what you're doing is to load it here... perhaps we should not do
> that, and instead in the kallsyms loading code, when processing the
> symbols for this specific module, discard them and leave its symbol
> table unpopulated, then, later, when resolving a sample in this module,
> it will see that it is not loaded, will see that it has a build-id and
> will use that, and _refuse_ to get it from anywhere else than an ELF
> file with that build-id.
> 
> I.e. in general, when we have a build-id for a given DSO, we should not
> read it from kallsyms or any other file that don't have a matching
> build-id.
> 
> The only possibility would be: hey, I have a build id, and reading the
> currently loaded module (/sys/module/e1000e/notes/.note.gnu.build-id) I
> see it _still_ has that same build-id, ok, I can read it from kallsyms.
> 
> What do you think?

I'm ok with that, will change to compare build-id before loading
symbols.

Thanks,
Namhyung

Re: [PATCH v2] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis.

[Greg KH]

On Sat, Jun 24, 2017 at 08:58:10AM +0530, srishti sharma wrote:
> Fixed alignment so that it matched open parenthesis.
> 
> Signed-off-by: srishti sharma 

Does your legal name not have capital letters?  Please fix and resend.

thanks,

greg k-h

Re: [PATCH v2] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis.

[Srishti Sharma]

On Sun, Jun 25, 2017 at 8:01 PM, Greg KH  wrote:
> On Sat, Jun 24, 2017 at 08:58:10AM +0530, srishti sharma wrote:
>> Fixed alignment so that it matched open parenthesis.
>>
>> Signed-off-by: srishti sharma 
>
> Does your legal name not have capital letters?  Please fix and resend.

 Sorry , yes ! I have re-sent it .
>
> thanks,
>
> greg k-h

Thanks ,
Srishti

Re: [PATCH/RFC 9/9] perf record: Add --module-dir option

[Namhyung Kim]

On Fri, Jun 23, 2017 at 11:45:24AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 23, 2017 at 02:48:27PM +0900, Namhyung Kim escreveu:
> > Currently perf only searches module binaries on the canonical
> > directory (/lib/modules/`uname -r`).  But sometimes user needs to load
> > local modules.  These cannot be copied to the build-id cache since long
> > name (i.e. real path) of DSOs was not set.
>  
> > This patch fixes the problem by adding a new --module-dir option so that
> > perf can record modules in the directory.
>  
> > +++ b/tools/perf/Documentation/perf-record.txt
> > @@ -480,6 +480,9 @@ Implies --tail-synthesize.
> > +--module-dir=PATH::
> > +Directory name where extra modules are located.
> 
> > +++ b/tools/perf/builtin-record.c
> > @@ -1671,6 +1671,8 @@ static struct option __record_options[] = {
> > "Parse options then exit"),
> > OPT_BOOLEAN(0, "use-kcore", _conf.use_kcore,
> > "Use /proc/kcore for object code"),
> > +   OPT_STRING(0, "module-dir", _conf.extra_module_path, "path",
> > +  "directory name where extra modules are located"),
> > OPT_END()
> >  };
> >  
> > +++ b/tools/perf/util/machine.c
> > @@ -1117,7 +1118,19 @@ static int machine__set_modules_path(struct machine 
> > *machine)
> >  machine->root_dir, version);
> > free(version);
> >  
> > -   return map_groups__set_modules_path_dir(>kmaps, modules_path, 
> > 0);
> > +   ret = map_groups__set_modules_path_dir(>kmaps, modules_path, 
> > 0);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   if (symbol_conf.extra_module_path) {
> > +   snprintf(modules_path, sizeof(modules_path), "%s/%s",
> > +machine->root_dir, symbol_conf.extra_module_path);
> > +
> > +   ret = map_groups__set_modules_path_dir(>kmaps,
> > +  modules_path, 0);
> 
> What if we have samples in a module that is in the canonical dir _and_
> samples in a module in this extra_module_path? Shouldn't we have
> something like vmlinux_path, but for modules? Where you can add entries
> in that path?
> 
> I'm ok with adding entries to where module files are looked up, with
> semantics similar to $PATH in a shell, i.e. entries added via
> --module-path (rename of your --module-dir) will take precedence over
> the canonical dir (/lib/modules/`uname -r`).

I think we can check the build-id in sysfs and binaries in both
directories.  If the sysfs is not avaiable (i.e. the module is
unloaded in the meantime), the precedence can be used IMHO.

Thanks,
Namhyung


> 
> But for the future I think we should try to get a PERF_RECORD_MMAP that
> will allow reloading modules during a 'perf record' session when a
> module gets reloaded, I thought about using existing tracepoints, but...
> 
> [root@jouet ~]# cat 
> /sys/kernel/debug/tracing/events/module/module_load/format 
> name: module_load
> ID: 370
> format:
>   field:unsigned short common_type;   offset:0;   size:2; 
> signed:0;
>   field:unsigned char common_flags;   offset:2;   size:1; 
> signed:0;
>   field:unsigned char common_preempt_count;   offset:3;   size:1; 
> signed:0;
>   field:int common_pid;   offset:4;   size:4; signed:1;
> 
>   field:unsigned int taints;  offset:8;   size:4; signed:0;
>   field:__data_loc char[] name;   offset:12;  size:4; signed:1;
> 
> print fmt: "%s %s", __get_str(name), __print_flags(REC->taints, "", { (1UL << 
> 0), "P" }, { (1UL << 12), "O" }, { (1UL << 1), "F" }, { (1UL << 10), "C" }, { 
> (1UL << 13), "E" })
> [root@jouet ~]# perf trace --no-syscalls --event module:module_load modprobe 
> ppp
> modprobe: FATAL: Module ppp not found in directory /lib/modules/4.12.0-rc4+
> [root@jouet ~]# perf trace --no-syscalls --event module:module_load modprobe 
> e1000
>  0.000 module:module_load:e1000 )
> [root@jouet ~]#
> 
> It just gets us the module name, not the file from what it is loaded, bummer 
> :-\
> 
> Something like:
> 
> diff --git a/kernel/module.c b/kernel/module.c
> index 4a3665f8f837..50e9718a141d 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3739,6 +3739,7 @@ static int load_module(struct load_info *info, const 
> char __user *uargs,
>  
>   /* Done! */
>   trace_module_load(mod);
> + perf_event_mmap_mod(mod);
>  
>   return do_init_module(mod);
>  
>  --
> 
> struct module *mod has:
> 
>   mod->name:  "e1000"
>   mod->debug->filename: 
> /lib/modules/4.11.0-rc8+/kernel/drivers/net/ethernet/intel/e1000/e1000.ko
> 
> and at that point we also have load_info, htat has ELF headers where we could 
> extract the build-id
> and insert it in a field in a new PERF_RECORD_MMAP3 record :-)
> 
>   perf_event_mmap_mod() would be modelled after perf_event_mmap(vma), but 
> getting what
>   it needs not from the vma present in a sys_mmap() but from struct module 
> and load_info.
> 
> - Arnaldo
> 
> > +   }
> > +
> > +  

Re: [PATCH v2 1/7] staging: ccree: fix hash import/export

[Gilad Ben-Yossef]

On Thu, Jun 22, 2017 at 4:58 PM, Dan Carpenter  wrote:
> On Thu, Jun 22, 2017 at 04:36:55PM +0300, Gilad Ben-Yossef wrote:
>>  static int ssi_ahash_export(struct ahash_request *req, void *out)
>>  {
>>   struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
>>   struct ssi_hash_ctx *ctx = crypto_ahash_ctx(ahash);
>> + struct device *dev = >drvdata->plat_dev->dev;
>> + struct ahash_req_ctx *state = ahash_request_ctx(req);
>> + u8 *curr_buff = state->buff_index ? state->buff1 : state->buff0;
>> + u32 curr_buff_cnt = state->buff_index ? state->buff1_cnt :
>> + state->buff0_cnt;
>> + const u32 tmp = CC_EXPORT_MAGIC;
>> +
>> + CHECK_AND_RETURN_UPON_FIPS_ERROR();
>>
>> - return ssi_hash_export(ctx, out);
>> + memcpy(out, , sizeof(u32));
>> + out += sizeof(u32);
>> +
>> + dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
>> + ctx->inter_digestsize, DMA_BIDIRECTIONAL);
>> + memcpy(out, state->digest_buff, ctx->inter_digestsize);
>> + out += ctx->inter_digestsize;
>> +
>> + if (state->digest_bytes_len_dma_addr) {
>> + dma_sync_single_for_cpu(dev, state->digest_bytes_len_dma_addr,
>> + HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
>> + memcpy(out, state->digest_bytes_len, HASH_LEN_SIZE);
>> + }
>> + out += HASH_LEN_SIZE;
>
> I'm sorry to ask this question now instead of on my first review.  I was
> waiting for my other computer to get ready so I could look up how this
> is called.  But now that I've looked at it, I'm still not sure how this
> is called.

No reason to be sorry. I value every review I get, no matter the timing :-)

>
> Anyway, my question is, is out zeroed memory?  Should we have something
> like:
> } else {
> memset(out, 0, HASH_LEN_SIZE);
> }
> out += HASH_LEN_SIZE;
>

The export/import function serialize internal hash state into/from a
user supplied
buffer, which may or may not be zeroed.

The import/output is an opaque struct to the user, and in these
specific circumstances
that field (location in hashed data) is simply not used.

After thinking about it, I think the correct thing to do here is to
poison the unused field,
rather than zero it to make it easier to debug cases where someone
passes to export
an import of a different hash/parameters.

Thanks for pointing it out.


> The ->import() function has a similar snippet.

That one is easier as the internal data that is being imported is
simply not allocated
in this scenario at all.

Thanks!
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

[GIT pull] x86/urgent

[Thomas Gleixner]

Linus,

please pull the latest x86-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-urgent-for-linus

A single fix to unbreak the vdso32 build for 64bit kernels caused by excess
#includes in the mshyperv header.

Thanks,

tglx

-->
Thomas Gleixner (1):
  x86/mshyperv: Remove excess #includes from mshyperv.h


 arch/x86/include/asm/mshyperv.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index fba100713924..d5acc27ed1cc 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -2,8 +2,7 @@
 #define _ASM_X86_MSHYPER_H
 
 #include 
-#include 
-#include 
+#include 
 #include 
 
 /*

Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3

[Al Viro]

On Sun, Jun 25, 2017 at 10:53:58AM +0100, Al Viro wrote:
> On Sat, Jun 24, 2017 at 12:29:23PM -0500, Larry Finger wrote:
> 
> > I made a break through. If I turn off inline copy to/from users for 32-bit
> > ppc with the following patch, then the system boots:
> 
> OK...  So it's 4.6.3 miscompiling something - it is hardware-independent,
> reproduced in qemu.  I'd like to get more self-contained example of
> miscompile, though; should be done by tonight...

OK, it's the call in rw_copy_check_uvector(); with INLINE_COPY_FROM_USER
it's miscompiled by 4.6.3.  I hadn't looked through the generated code
yet; will do that after I grab some sleep.

Re: [PATCH] ARM: dts: exynos: Exynos5422 Odroid-XU* incomplete thermal-zones definition

[Krzysztof Kozlowski]

On Fri, Jun 23, 2017 at 10:09:14PM +0100, Willy Wolff wrote:
> Odroid XU*-familly boards has thermal sensors per A15 cores, but the actual
>  thermal-zones define only cooling-maps action for cpu0.
> 
> If the application is running on all cores but core4 (first core of the A15
>  cluster), the CPU can reach high temperature without any proper cooling
>  action.

Commit msg has weird paragraph indentation. Please write it as regular
commit, like others.

> 
> As already discus in prior mail, and on IRC, it's a quit big code
> duplication, but I don't found the write way to express that in a better
>  way.
> 
> The situation for this board is that we have multiple sensors, but
>  matching cooling devices for these sensors act for the same physical
>  device (FAN and A15 cluster, as each core of the cluster share the same
>  frequency).
> In fact, of-thermal.c:473:thermal_zone_of_sensor_register() can't use
> multiple sensors for one single thermal zone.
> This patch follow the path taken in arch/arm/boot/dts/qcom-apq8084.dtsi:97
> 
> I'm interested to extending the thermal driver, but it will takes time.
>  So this is a workaround before refactoring the driver.
> If somebody knows how to write it better, any advice and suggestions
> are more than welcome.

Skip all data irrelevant to the issue (like what is your interest,
discussions made on LKML or IRC). Just describe exactly what is the
problem (and maybe how it can be reproduced) and what is the solution.
You can mention what could be the optimal solution and why we cannot use
it now.

> 
> Also, the comment for cpu_alert4 in cooling-maps definition is not
> accurate, 11 steps for A15 correspond to 700MHz, not 600MHz.
> 
> Signed-off-by: Willy Wolff 
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 249 
> +++--
>  1 file changed, 231 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 05b9afdd6757..0759cc0812fb 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -64,22 +64,22 @@
>   polling-delay-passive = <250>;
>   polling-delay = <0>;
>   trips {
> - cpu_alert0: cpu-alert-0 {
> + cpu0_alert0: cpu-alert-0 {
>   temperature = <5>; /* millicelsius 
> */
>   hysteresis = <5000>; /* millicelsius */
>   type = "active";
>   };
> - cpu_alert1: cpu-alert-1 {
> + cpu0_alert1: cpu-alert-1 {
>   temperature = <6>; /* millicelsius 
> */
>   hysteresis = <5000>; /* millicelsius */
>   type = "active";
>   };
> - cpu_alert2: cpu-alert-2 {
> + cpu0_alert2: cpu-alert-2 {
>   temperature = <7>; /* millicelsius 
> */
>   hysteresis = <5000>; /* millicelsius */
>   type = "active";
>   };
> - cpu_crit0: cpu-crit-0 {
> + cpu0_crit0: cpu-crit-0 {
>   temperature = <12>; /* millicelsius 
> */
>   hysteresis = <0>; /* millicelsius */
>   type = "critical";
> @@ -88,14 +88,14 @@
>* Exynos542x supports only 4 trip-points
>* so for these polling mode is required.
>* Start polling at temperature level of last
> -  * interrupt-driven trip: cpu_alert2
> +  * interrupt-driven trip: cpu0_alert2
>*/
> - cpu_alert3: cpu-alert-3 {
> + cpu0_alert3: cpu-alert-3 {
>   temperature = <7>; /* millicelsius 
> */
>   hysteresis = <1>; /* millicelsius */
>   type = "passive";
>   };
> - cpu_alert4: cpu-alert-4 {
> + cpu0_alert4: cpu-alert-4 {
>   temperature = <85000>; /* millicelsius 
> */
>   hysteresis = <1>; /* millicelsius */
>   type = "passive";
> @@ -104,43 +104,256 @@
>   };
>   

[PATCH] android: Update maintainer's e-mail in TODO

[Tommy Nguyen]

See https://lkml.org/lkml/2012/1/31/505

Changes dead e-mail to maintainer's current e-mail.

Signed-off-by: Tommy Nguyen 
---
 drivers/staging/android/TODO | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 5f14247..60fbedf 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -12,5 +12,5 @@ ion/
  - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
  - Better test framework (integration with VGEM was suggested)
 
-Please send patches to Greg Kroah-Hartman  and Cc:
+Please send patches to Greg Kroah-Hartman  and Cc:
 Arve Hjønnevåg  and Riley Andrews 
-- 
2.9.4

[GIT pull] irq fix for 4.12

[Thomas Gleixner]

Linus,

please pull the latest irq-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
irq-urgent-for-linus

A single fix for the MIPS GIC to prevent ftrace recursion.

Thanks,

tglx

-->
Marcin Nowakowski (1):
  irqchip/mips-gic: Mark count and compare accessors notrace


 drivers/irqchip/irq-mips-gic.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index eb7fbe159963..929f8558bf1c 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -140,7 +140,7 @@ static inline void gic_map_to_vpe(unsigned int intr, 
unsigned int vpe)
 }
 
 #ifdef CONFIG_CLKSRC_MIPS_GIC
-u64 gic_read_count(void)
+u64 notrace gic_read_count(void)
 {
unsigned int hi, hi2, lo;
 
@@ -167,7 +167,7 @@ unsigned int gic_get_count_width(void)
return bits;
 }
 
-void gic_write_compare(u64 cnt)
+void notrace gic_write_compare(u64 cnt)
 {
if (mips_cm_is64) {
gic_write(GIC_REG(VPE_LOCAL, GIC_VPE_COMPARE), cnt);
@@ -179,7 +179,7 @@ void gic_write_compare(u64 cnt)
}
 }
 
-void gic_write_cpu_compare(u64 cnt, int cpu)
+void notrace gic_write_cpu_compare(u64 cnt, int cpu)
 {
unsigned long flags;
 

[GIT pull] timer fixes for 4.12

[Thomas Gleixner]

Linus,

please pull the latest timers-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
timers-urgent-for-linus

A few fixes for timekeeping and timers:

  - Plug a subtle race due to a missing READ_ONCE() in the timekeeping code
where reloading of a pointer results in an inconsistent callback
argument being supplied to the clocksource->read function.

  - Correct the CLOCK_MONOTONIC_RAW sub-nanosecond accounting in the time
keeping core code, to prevent a possible discontuity.

  - Apply a similar fix to the arm64 vdso clock_gettime() implementation

  - Add missing includes to clocksource drivers, which relied on indirect
includes which fails in certain configs.

  - Use the proper iomem pointer for read/iounmap in a probe function.

Thanks,

tglx

-->
Frank Rowand (1):
  clocksource/drivers/arm_arch_timer: Fix read and iounmap of incorrect 
variable

John Stultz (2):
  time: Fix clock->read(clock) race around clocksource changes
  time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting

Stephen Rothwell (1):
  clocksource: Explicitly include linux/clocksource.h when needed

Will Deacon (1):
  arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW


 arch/arm64/kernel/vdso.c|  5 ++-
 arch/arm64/kernel/vdso/gettimeofday.S   |  1 -
 drivers/clocksource/arm_arch_timer.c|  4 +-
 drivers/clocksource/cadence_ttc_timer.c |  1 +
 drivers/clocksource/timer-sun5i.c   |  1 +
 include/linux/timekeeper_internal.h |  5 +--
 kernel/time/timekeeping.c   | 71 +
 7 files changed, 55 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 41b6e31f8f55..d0cb007fa482 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -221,10 +221,11 @@ void update_vsyscall(struct timekeeper *tk)
/* tkr_mono.cycle_last == tkr_raw.cycle_last */
vdso_data->cs_cycle_last= tk->tkr_mono.cycle_last;
vdso_data->raw_time_sec = tk->raw_time.tv_sec;
-   vdso_data->raw_time_nsec= tk->raw_time.tv_nsec;
+   vdso_data->raw_time_nsec= (tk->raw_time.tv_nsec <<
+  tk->tkr_raw.shift) +
+ tk->tkr_raw.xtime_nsec;
vdso_data->xtime_clock_sec  = tk->xtime_sec;
vdso_data->xtime_clock_nsec = tk->tkr_mono.xtime_nsec;
-   /* tkr_raw.xtime_nsec == 0 */
vdso_data->cs_mono_mult = tk->tkr_mono.mult;
vdso_data->cs_raw_mult  = tk->tkr_raw.mult;
/* tkr_mono.shift == tkr_raw.shift */
diff --git a/arch/arm64/kernel/vdso/gettimeofday.S 
b/arch/arm64/kernel/vdso/gettimeofday.S
index e00b4671bd7c..76320e920965 100644
--- a/arch/arm64/kernel/vdso/gettimeofday.S
+++ b/arch/arm64/kernel/vdso/gettimeofday.S
@@ -256,7 +256,6 @@ monotonic_raw:
seqcnt_check fail=monotonic_raw
 
/* All computations are done with left-shifted nsecs. */
-   lsl x14, x14, x12
get_nsec_per_sec res=x9
lsl x9, x9, x12
 
diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 4bed671e490e..8b5c30062d99 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1209,9 +1209,9 @@ arch_timer_mem_frame_get_cntfrq(struct 
arch_timer_mem_frame *frame)
return 0;
}
 
-   rate = readl_relaxed(frame + CNTFRQ);
+   rate = readl_relaxed(base + CNTFRQ);
 
-   iounmap(frame);
+   iounmap(base);
 
return rate;
 }
diff --git a/drivers/clocksource/cadence_ttc_timer.c 
b/drivers/clocksource/cadence_ttc_timer.c
index 44e5e951583b..8e64b8460f11 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/clocksource/timer-sun5i.c 
b/drivers/clocksource/timer-sun5i.c
index 2e9c830ae1cd..c4656c4d44a6 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/timekeeper_internal.h 
b/include/linux/timekeeper_internal.h
index 110f4532188c..f7043ccca81c 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -29,7 +29,6 @@
  */
 struct tk_read_base {
struct clocksource  *clock;
-   u64 (*read)(struct clocksource *cs);
u64 mask;
u64 cycle_last;
u32 mult;
@@ -58,7 +57,7 @@ struct tk_read_base {
  * interval.
  * @xtime_remainder:   Shifted nano seconds left 

[PATCH] Documentation: ABI: mtd: describe "offset" more precisely

[Rafał Miłecki]

From: Rafał Miłecki 

So far Linux supported only two levels of MTD devices so we didn't need
a very precise description for this sysfs file. With commit
97519dc52b44a ("mtd: partitions: add support for subpartitions") there
is support for a tree structure so we should have more precise
description. Using "parent" and "flash device" makes it more accurate.

Signed-off-by: Rafał Miłecki 
---
 Documentation/ABI/testing/sysfs-class-mtd | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-mtd 
b/Documentation/ABI/testing/sysfs-class-mtd
index 3b5c3bca9186..f34e592301d1 100644
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ b/Documentation/ABI/testing/sysfs-class-mtd
@@ -229,6 +229,6 @@ KernelVersion:  4.1
 Contact:   linux-...@lists.infradead.org
 Description:
For a partition, the offset of that partition from the start
-   of the master device in bytes. This attribute is absent on
-   main devices, so it can be used to distinguish between
-   partitions and devices that aren't partitions.
+   of the parent (another partition or a flash device) in bytes.
+   This attribute is absent on flash devices, so it can be used
+   to distinguish them from partitions.
-- 
2.11.0

Re: [PATCH 1/2] staging: sm750fb: avoid conflicting vesafb

[Sudip Mukherjee]

On Mon, Jun 19, 2017 at 09:32:57PM +0100, Sudip Mukherjee wrote:
> From: Teddy Wang 
> 
> If vesafb is enabled in the config then /dev/fb0 is created by vesa
> and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to
> effectively work with xorg.
> So if it has been alloted fb1, then try to remove the other fb0.
> 
> Signed-off-by: Teddy Wang 
> Signed-off-by: Sudip Mukherjee 
> ---

Hi Greg,
You applied the second patch but not this one. Did I miss any review
comments from you about this one?

--
Regards
Sudip

RE: [EXT] Re: [PATCH 4/6] irqchip: irq-mvebu-icu: new driver for Marvell ICU

[Yehuda Yitschak]

> -Original Message-
> From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
> Sent: Tuesday, May 30, 2017 15:06
> To: Marc Zyngier
> Cc: Thomas Gleixner; Jason Cooper; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Rob Herring; Ian Campbell; Pawel Moll; Mark
> Rutland; Kumar Gala; Andrew Lunn; Sebastian Hesselbarth; Gregory
> Clement; linux-arm-ker...@lists.infradead.org; Nadav Haklai; Hanna Hawa;
> Yehuda Yitschak; Antoine Tenart
> Subject: [EXT] Re: [PATCH 4/6] irqchip: irq-mvebu-icu: new driver for Marvell
> ICU
> 
> External Email
> 
> --
> Hello,
> 
> On Tue, 30 May 2017 12:10:29 +0100, Marc Zyngier wrote:
> 
> > Thanks for that, looks pretty interesting. A couple of comments below.
> 
> Thanks again for the review!
> 
> > > +/* GICP registers */
> > > +#define GICP_SETSPI_NSR_OFFSET   0x0
> > > +#define GICP_CLRSPI_NSR_OFFSET   0x8
> >
> > Shouldn't that live in some gicp-specific include file?
> 
> Would drivers/irqchip/irq-mvebu-gicp.h, included by both irq-mvebu-gicp.c
> and irq-mvebu-icu.c be fine for you?
> 
> > > +/* ICU definitions */
> > > +#define ICU_MAX_IRQS 207
> > > +#define IRQS_PER_ICU 64
> > > +#define ICU_MAX_SPI_IRQ_IN_GIC   (2 * IRQS_PER_ICU)
> >
> > What's the relationship between ICU_MAX_IRQS and
> > IRQS_PER_ICU/ICU_MAX_SPI_IRQ_IN_GIC, if any? Is there only a single
> ICU?
> > Or can you have multiple ones?
> 
> There is one ICU per CP. The Armada 7K SoC has one CP, the Armada 8K SoC
> has two CPs. Therefore on Armada 8K, you have two ICUs, one per CP.
> 
> But I see your point: there is in fact no direct relation between the number 
> of
> GICP SPI interrupts reserved and the number of ICUs and interrupts per ICU.
> 
> The number of GICP SPI interrupts (128) should be moved into irq-mvebu-
> gicp.h, together with the GICP register offsets.
> 
> > > +#define ICU_GIC_SPI_BASE064
> > > +#define ICU_GIC_SPI_BASE1288
> >
> > My own gut feeling is that there will be another version of this IP
> > one of these days, with different bases. Should we bite the bullet
> > right away and put those in DT?
> 
> Where should these properties go? Under the gicp DT node, or under the
> ICU DT node?
> 
> > > +static DEFINE_SPINLOCK(icu_lock);
> > > +static DECLARE_BITMAP(icu_irq_alloc, ICU_MAX_SPI_IRQ_IN_GIC);
> > > +
> > > +static unsigned int
> > > +mvebu_icu_icuidx_to_gicspi(unsigned int icuidx) {
> > > + if (icuidx < ICU_GIC_SPI_BASE0)
> > > + return ICU_GIC_SPI_BASE0 + icuidx;
> > > + else
> > > + return ICU_GIC_SPI_BASE1 + (icuidx - IRQS_PER_ICU);
> >
> > A small comment on how ICU indexes and GIC SPIs map would be good.
> 
> ACK.
> 
> > Correct me if I'm wrong, but it really looks like you're dealing with
> > two devices here, each with their own SPI window.
> 
> We in fact don't really care about how many ICUs we have here. We have
> 128 GICP SPI interrupts available, in ranges:
> 
>  - ICU_GIC_SPI_BASE0 ; ICU_GIC_SPI_BASE0 + 64
> 
>  - ICU_GIC_SPI_BASE1 ; ICU_GIC_SPI_BASE1 + 64
> 
> The icu_irq_alloc bitmap is a global one, which allows to allocate one GICP 
> SPI
> interrupts amongst the available 128 interrupts, and this function simply
> allows to map the index in this bitmap (from 0 to 127) to the corresponding
> GICP SPI interrupt.
> 
> > > + writel(icu_int, icu->base + ICU_INT_CFG(hwirq));
> >
> > You can use a writel_relaxed here.
> 
> ACK.
> 
> > > + /*
> > > +  * The SATA unit has 2 ports, and a dedicated ICU entry per
> > > +  * port. The ahci sata driver supports only one irq interrupt
> > > +  * per SATA unit. To solve this conflict, we configure the 2
> > > +  * SATA wired interrupts in the south bridge into 1 GIC
> > > +  * interrupt in the north bridge. Even if only a single port
> > > +  * is enabled, if sata node is enabled, both interrupts are
> > > +  * configured (regardless of which port is actually in use).
> > > +  * The ICU index of SATA0 = 107, SATA1 = 109
> >
> > You can drop that last comment about the indexes, the #defines are
> > good enough.
> 
> Agreed.
> 
> > > +  */
> > > + if (hwirq == ICU_SATA0_IRQ_INT || hwirq == ICU_SATA1_IRQ_INT) {
> > > + writel(icu_int, icu->base +
> ICU_INT_CFG(ICU_SATA0_IRQ_INT));
> > > + writel(icu_int, icu->base +
> ICU_INT_CFG(ICU_SATA1_IRQ_INT));
> > > + }
> >
> > Aren't you wasting an SPI here?
> 
> No: we allocate a single SPI, icu_int. What we're doing here is that we have
> two different wired interrupts in the CP that are "connected" to the same
> GICP SPI interrupt.
> 
> > If you configure SATA0 first, then SATA1, SATA0's allocated SPI will
> > be wasted (not to mention the corresponding Linux interrupt too).
> > Can't this be worked around at the AHCI level? It is not like we don't
> > have any quirk there already...
> 
> This is something I wanted to look at, but at a follow-up work, as I believe 
> the
> proposed work around is reasonable, 

[PATCH v3 1/6] staging: ccree: fix hash import/export

[Gilad Ben-Yossef]

Hash import and export was saving and restoring the wrong context
and therefore disabled. Fix it by restoring intermediate digest
and additional state needed.

The hash and mac transform now pass testmgr partial hash tests.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 143 +++
 drivers/staging/ccree/ssi_hash.h |   2 +
 2 files changed, 101 insertions(+), 44 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index ed1c672..ffe8e1a 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -976,22 +976,6 @@ static int ssi_hash_init(struct ahash_req_ctx *state, 
struct ssi_hash_ctx *ctx)
return 0;
 }
 
-#ifdef EXPORT_FIXED
-static int ssi_hash_export(struct ssi_hash_ctx *ctx, void *out)
-{
-   CHECK_AND_RETURN_UPON_FIPS_ERROR();
-   memcpy(out, ctx, sizeof(struct ssi_hash_ctx));
-   return 0;
-}
-
-static int ssi_hash_import(struct ssi_hash_ctx *ctx, const void *in)
-{
-   CHECK_AND_RETURN_UPON_FIPS_ERROR();
-   memcpy(ctx, in, sizeof(struct ssi_hash_ctx));
-   return 0;
-}
-#endif
-
 static int ssi_hash_setkey(void *hash,
   const u8 *key,
   unsigned int keylen,
@@ -1782,23 +1766,107 @@ static int ssi_ahash_init(struct ahash_request *req)
return ssi_hash_init(state, ctx);
 }
 
-#ifdef EXPORT_FIXED
 static int ssi_ahash_export(struct ahash_request *req, void *out)
 {
struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
struct ssi_hash_ctx *ctx = crypto_ahash_ctx(ahash);
+   struct device *dev = >drvdata->plat_dev->dev;
+   struct ahash_req_ctx *state = ahash_request_ctx(req);
+   u8 *curr_buff = state->buff_index ? state->buff1 : state->buff0;
+   u32 curr_buff_cnt = state->buff_index ? state->buff1_cnt :
+   state->buff0_cnt;
+   const u32 tmp = CC_EXPORT_MAGIC;
+
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
-   return ssi_hash_export(ctx, out);
+   memcpy(out, , sizeof(u32));
+   out += sizeof(u32);
+
+   dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
+   ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+   memcpy(out, state->digest_buff, ctx->inter_digestsize);
+   out += ctx->inter_digestsize;
+
+   if (state->digest_bytes_len_dma_addr) {
+   dma_sync_single_for_cpu(dev, state->digest_bytes_len_dma_addr,
+   HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
+   memcpy(out, state->digest_bytes_len, HASH_LEN_SIZE);
+   } else {
+   /* Poison the unused exported digest len field. */
+   memset(out, 0x5F, HASH_LEN_SIZE);
+   }
+   out += HASH_LEN_SIZE;
+
+   memcpy(out, _buff_cnt, sizeof(u32));
+   out += sizeof(u32);
+
+   memcpy(out, curr_buff, curr_buff_cnt);
+
+   /* No sync for device ineeded since we did not change the data,
+* we only copy it
+*/
+
+   return 0;
 }
 
 static int ssi_ahash_import(struct ahash_request *req, const void *in)
 {
struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
struct ssi_hash_ctx *ctx = crypto_ahash_ctx(ahash);
+   struct device *dev = >drvdata->plat_dev->dev;
+   struct ahash_req_ctx *state = ahash_request_ctx(req);
+   u32 tmp;
+   int rc;
+
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
-   return ssi_hash_import(ctx, in);
+   memcpy(, in, sizeof(u32));
+   if (tmp != CC_EXPORT_MAGIC) {
+   rc = -EINVAL;
+   goto out;
+   }
+   in += sizeof(u32);
+
+   rc = ssi_hash_init(state, ctx);
+   if (rc)
+   goto out;
+
+   dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
+   ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+   memcpy(state->digest_buff, in, ctx->inter_digestsize);
+   in += ctx->inter_digestsize;
+
+   if (state->digest_bytes_len_dma_addr) {
+   dma_sync_single_for_cpu(dev, state->digest_bytes_len_dma_addr,
+   HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
+   memcpy(state->digest_bytes_len, in, HASH_LEN_SIZE);
+   }
+   in += HASH_LEN_SIZE;
+
+   dma_sync_single_for_device(dev, state->digest_buff_dma_addr,
+  ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+
+   if (state->digest_bytes_len_dma_addr)
+   dma_sync_single_for_device(dev,
+  state->digest_bytes_len_dma_addr,
+  HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
+
+   state->buff_index = 0;
+
+   /* Sanity check the data as much as possible */
+   memcpy(, in, sizeof(u32));
+   if (tmp > SSI_MAX_HASH_BLCK_SIZE) {
+   rc = -EINVAL;
+   goto out;
+   }
+   in 

[PATCH v3 6/6] staging: ccree: use signal safe completion wait

[Gilad Ben-Yossef]

We were waiting for a completion notification of HW DMA
operation using an interruptible wait which can result
in data corruption if a signal interrupted us while
DMA was not yet completed.

Fix this by moving to uninterrupted wait.

Fixes: abefd6741d ("staging: ccree: introduce CryptoCell HW driver").

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_request_mgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index 7c2d88a..2c6937a 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -382,7 +382,8 @@ int send_request(
/* Wait upon sequence completion.
 *  Return "0" -Operation done successfully.
 */
-   return wait_for_completion_interruptible(_req->seq_compl);
+   wait_for_completion(_req->seq_compl);
+   return 0;
} else {
/* Operation still in process */
return -EINPROGRESS;
-- 
2.1.4

[PATCH v3 5/6] staging: ccree: add DT bus coherency detection

[Gilad Ben-Yossef]

The ccree driver has build time configurable support
to work on top of coherent (e.g. ACP) vs. none coherent bus
connections. Turn it to run-time configurable option
based on device tree.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig  |  9 -
 drivers/staging/ccree/ssi_buffer_mgr.c | 37 ++
 drivers/staging/ccree/ssi_config.h | 20 --
 drivers/staging/ccree/ssi_driver.c | 12 ---
 drivers/staging/ccree/ssi_driver.h |  3 +++
 5 files changed, 32 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 4be87f5..ec3749d 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -32,12 +32,3 @@ config CCREE_FIPS_SUPPORT
  Say 'Y' to enable support for FIPS compliant mode by the
  CCREE driver.
  If unsure say N.
-
-config CCREE_DISABLE_COHERENT_DMA_OPS
-   bool "Disable Coherent DMA operations for the CCREE driver"
-   depends on CRYPTO_DEV_CCREE
-   default n
-   help
- Say 'Y' to disable the use of coherent DMA operations by the
- CCREE driver for debugging purposes.  
- If unsure say N.
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 88ebda8..4373d1d 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -627,6 +627,7 @@ void ssi_buffer_mgr_unmap_aead_request(
struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
unsigned int hw_iv_size = areq_ctx->hw_iv_size;
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
+   struct ssi_drvdata *drvdata = dev_get_drvdata(dev);
u32 dummy;
bool chained;
u32 size_to_unmap = 0;
@@ -700,8 +701,8 @@ void ssi_buffer_mgr_unmap_aead_request(
dma_unmap_sg(dev, req->dst, 
ssi_buffer_mgr_get_sgl_nents(req->dst,size_to_unmap,,),
DMA_BIDIRECTIONAL);
}
-#if DX_HAS_ACP
-   if ((areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
+   if (drvdata->coherent &&
+   (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
likely(req->src == req->dst))
{
u32 size_to_skip = req->assoclen;
@@ -716,7 +717,6 @@ void ssi_buffer_mgr_unmap_aead_request(
size_to_skip+ req->cryptlen - areq_ctx->req_authsize,
size_to_skip+ req->cryptlen, SSI_SG_FROM_BUF);
}
-#endif
 }
 
 static inline int ssi_buffer_mgr_get_aead_icv_nents(
@@ -981,20 +981,24 @@ static inline int ssi_buffer_mgr_prepare_aead_data_mlli(
 * MAC verification upon request completion
 */
if (direct == DRV_CRYPTO_DIRECTION_DECRYPT) {
-#if !DX_HAS_ACP
-   /* In ACP platform we already copying ICV
-* for any INPLACE-DECRYPT operation, hence
+   if (!drvdata->coherent) {
+   /* In coherent platforms (e.g. ACP)
+* already copying ICV for any
+* INPLACE-DECRYPT operation, hence
 * we must neglect this code.
 */
-   u32 size_to_skip = req->assoclen;
-   if (areq_ctx->is_gcm4543) {
-   size_to_skip += crypto_aead_ivsize(tfm);
+   u32 skip = req->assoclen;
+
+   if (areq_ctx->is_gcm4543)
+   skip += crypto_aead_ivsize(tfm);
+
+   ssi_buffer_mgr_copy_scatterlist_portion(
+   areq_ctx->backup_mac, req->src,
+   (skip + req->cryptlen -
+areq_ctx->req_authsize),
+   skip + req->cryptlen,
+   SSI_SG_TO_BUF);
}
-   ssi_buffer_mgr_copy_scatterlist_portion(
-   areq_ctx->backup_mac, req->src,
-   size_to_skip+ req->cryptlen - 
areq_ctx->req_authsize,
-   size_to_skip+ req->cryptlen, 
SSI_SG_TO_BUF);
-#endif
areq_ctx->icv_virt_addr = areq_ctx->backup_mac;
} else {
areq_ctx->icv_virt_addr = areq_ctx->mac_buf;
@@ -1281,8 +1285,8 @@ int ssi_buffer_mgr_map_aead_request(
mlli_params->curr_pool = NULL;
sg_data.num_of_buffers = 0;
 
-#if DX_HAS_ACP
-  

[PATCH v3 4/6] staging: ccree: add clock management support

[Gilad Ben-Yossef]

Some SoC which implement CryptoCell have a dedicated clock
tied to it, some do not. Implement clock support if exists
based on device tree data and tie power management to it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Makefile |  2 +-
 drivers/staging/ccree/ssi_driver.c | 43 +++
 drivers/staging/ccree/ssi_driver.h |  5 +++-
 drivers/staging/ccree/ssi_pm.c | 13 +
 drivers/staging/ccree/ssi_pm_ext.c | 60 --
 drivers/staging/ccree/ssi_pm_ext.h | 33 -
 6 files changed, 50 insertions(+), 106 deletions(-)
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.c
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.h

diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 44f3e3e..318c2b3 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o
 ccree-$(CCREE_FIPS_SUPPORT) += ssi_fips.o ssi_fips_ll.o ssi_fips_ext.o 
ssi_fips_local.o
diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index b9d0dd27..c516675 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ssi_config.h"
 #include "ssi_driver.h"
@@ -219,6 +220,8 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
void __iomem *cc_base = NULL;
bool irq_registered = false;
struct ssi_drvdata *new_drvdata = kzalloc(sizeof(struct ssi_drvdata), 
GFP_KERNEL);
+   struct device *dev = _dev->dev;
+   struct device_node *np = dev->of_node;
u32 signature_val;
int rc = 0;
 
@@ -228,6 +231,8 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
goto init_cc_res_err;
}
 
+   new_drvdata->clk = of_clk_get(np, 0);
+
/*Initialize inflight counter used in dx_ablkcipher_secure_complete 
used for count of BYSPASS blocks operations*/
new_drvdata->inflight_counter = 0;
 
@@ -286,6 +291,10 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
 
new_drvdata->plat_dev = plat_dev;
 
+   rc = cc_clk_on(new_drvdata);
+   if (rc)
+   goto init_cc_res_err;
+
if(new_drvdata->plat_dev->dev.dma_mask == NULL)
{
new_drvdata->plat_dev->dev.dma_mask = & 
new_drvdata->plat_dev->dev.coherent_dma_mask;
@@ -450,14 +459,11 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
ssi_sysfs_fini();
 #endif
 
-   /* Mask all interrupts */
-   WRITE_REGISTER(drvdata->cc_base + CC_REG_OFFSET(HOST_RGF, HOST_IMR),
-   0x);
+   fini_cc_regs(drvdata);
+   cc_clk_off(drvdata);
free_irq(drvdata->res_irq->start, drvdata);
drvdata->res_irq = NULL;
 
-   fini_cc_regs(drvdata);
-
if (drvdata->cc_base != NULL) {
iounmap(drvdata->cc_base);
release_mem_region(drvdata->res_mem->start,
@@ -470,6 +476,33 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
dev_set_drvdata(_dev->dev, NULL);
 }
 
+int cc_clk_on(struct ssi_drvdata *drvdata)
+{
+   struct clk *clk = drvdata->clk;
+   int rc;
+
+   if (IS_ERR(clk))
+   /* Not all devices have a clock associated with CCREE  */
+   return 0;
+
+   rc = clk_prepare_enable(clk);
+   if (rc)
+   return rc;
+
+   return 0;
+}
+
+void cc_clk_off(struct ssi_drvdata *drvdata)
+{
+   struct clk *clk = drvdata->clk;
+
+   if (IS_ERR(clk))
+   /* Not all devices have a clock associated with CCREE */
+   return;
+
+   clk_disable_unprepare(clk);
+}
+
 static int cc7x_probe(struct platform_device *plat_dev)
 {
int rc;
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 78a327a..faf47b1 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Registers definitions from shared/hw/ree_include */
 #include "dx_reg_base_host.h"
@@ -148,7 +149,7 @@ struct ssi_drvdata {
void *ivgen_handle;
void *sram_mgr_handle;
u32 inflight_counter;
-
+   struct clk *clk;
 };
 
 struct ssi_crypto_alg {
@@ -193,6 +194,8 @@ void dump_byte_array(const char *name, const u8 *the_array, 
unsigned long size);
 
 int init_cc_regs(struct ssi_drvdata *drvdata, bool is_probe);
 void fini_cc_regs(struct ssi_drvdata *drvdata);
+int cc_clk_on(struct 

[PATCH v3 2/6] staging: ccree: register setkey for none hash macs

[Gilad Ben-Yossef]

The original ccree driver was registering a useless setkey
method even for non-MAC hash transformations. Somewhere
around v4.9 a check was added that failed hash operations
if a setkey method was registered but was not called,
so during the initial upstream port code was added to
only register the setkey method for MAC type hash transform.

Unfortunately, the ccree driver also registers non-hash based
MAC transforms and the code had a logic error that stopped
it registering a setkey callback even for those, thus rendering
them useless.

This commit fixes the logic mistake, thus correctly registering
a setkey method only for MAC transformations, leaving it out
for non-MAC ones, whether they are hash based on not.

Fixes: 50cfbbb7e627 ("staging: ccree: add ahash support").

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 83 
 1 file changed, 42 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index ffe8e1a..bfe2bec 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -1877,8 +1877,8 @@ static int ssi_ahash_setkey(struct crypto_ahash *ahash,
 struct ssi_hash_template {
char name[CRYPTO_MAX_ALG_NAME];
char driver_name[CRYPTO_MAX_ALG_NAME];
-   char hmac_name[CRYPTO_MAX_ALG_NAME];
-   char hmac_driver_name[CRYPTO_MAX_ALG_NAME];
+   char mac_name[CRYPTO_MAX_ALG_NAME];
+   char mac_driver_name[CRYPTO_MAX_ALG_NAME];
unsigned int blocksize;
bool synchronize;
struct ahash_alg template_ahash;
@@ -1897,8 +1897,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha1",
.driver_name = "sha1-dx",
-   .hmac_name = "hmac(sha1)",
-   .hmac_driver_name = "hmac-sha1-dx",
+   .mac_name = "hmac(sha1)",
+   .mac_driver_name = "hmac-sha1-dx",
.blocksize = SHA1_BLOCK_SIZE,
.synchronize = false,
.template_ahash = {
@@ -1922,8 +1922,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha256",
.driver_name = "sha256-dx",
-   .hmac_name = "hmac(sha256)",
-   .hmac_driver_name = "hmac-sha256-dx",
+   .mac_name = "hmac(sha256)",
+   .mac_driver_name = "hmac-sha256-dx",
.blocksize = SHA256_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -1946,8 +1946,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha224",
.driver_name = "sha224-dx",
-   .hmac_name = "hmac(sha224)",
-   .hmac_driver_name = "hmac-sha224-dx",
+   .mac_name = "hmac(sha224)",
+   .mac_driver_name = "hmac-sha224-dx",
.blocksize = SHA224_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -1971,8 +1971,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha384",
.driver_name = "sha384-dx",
-   .hmac_name = "hmac(sha384)",
-   .hmac_driver_name = "hmac-sha384-dx",
+   .mac_name = "hmac(sha384)",
+   .mac_driver_name = "hmac-sha384-dx",
.blocksize = SHA384_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -1995,8 +1995,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha512",
.driver_name = "sha512-dx",
-   .hmac_name = "hmac(sha512)",
-   .hmac_driver_name = "hmac-sha512-dx",
+   .mac_name = "hmac(sha512)",
+   .mac_driver_name = "hmac-sha512-dx",
.blocksize = SHA512_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2020,8 +2020,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "md5",
.driver_name = "md5-dx",
-   .hmac_name = "hmac(md5)",
-   .hmac_driver_name = "hmac-md5-dx",
+   .mac_name = "hmac(md5)",
+   .mac_driver_name = "hmac-md5-dx",
.blocksize = MD5_HMAC_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2042,8 +2042,8 @@ static struct ssi_hash_template driver_hash[] = {
.inter_digestsize = MD5_DIGEST_SIZE,
},
{
-   .name = "xcbc(aes)",
-   .driver_name = "xcbc-aes-dx",
+   .mac_name = "xcbc(aes)",
+   .mac_driver_name = "xcbc-aes-dx",
.blocksize = AES_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2065,8 

[PATCH v3 3/6] staging: ccree: remove unused function

[Gilad Ben-Yossef]

The function set_ack_last was not used anywhere. Remove it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_hw_queue_defs.h | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h 
b/drivers/staging/ccree/cc_hw_queue_defs.h
index aaa56c8..f11487a 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -226,18 +226,6 @@ static inline void set_queue_last_ind(struct cc_hw_desc 
*pdesc)
 }
 
 /*
- * Signs the end of HW descriptors flow by asking for completion ack,
- * and release the HW engines
- *
- * @pdesc: pointer HW descriptor struct
- */
-static inline void set_ack_last(struct cc_hw_desc *pdesc)
-{
-   pdesc->word[3] |= FIELD_PREP(WORD3_QUEUE_LAST_IND, 1);
-   pdesc->word[4] |= FIELD_PREP(WORD4_ACK_NEEDED, 1);
-}
-
-/*
  * Set the DIN field of a HW descriptors
  *
  * @pdesc: pointer HW descriptor struct
-- 
2.1.4

[PATCH v3 0/6] staging: ccree: bug fixes and TODO items for 4.13

[Gilad Ben-Yossef]

An assortment of bug fixes and staging TODO items.
Highlights includes the driver passing crypto testmgr boot tests
and relying on device tree for various HW config options as
opposed to build time configuration.

CC: Dan Carpenter 

Gilad Ben-Yossef (6):
  staging: ccree: fix hash import/export
  staging: ccree: register setkey for none hash macs
  staging: ccree: remove unused function
  staging: ccree: add clock management support
  staging: ccree: add DT bus coherency detection
  staging: ccree: use signal safe completion wait

Changes from v2:
- Rebased on latest staging-next.
- Added poison of unused hash import field based
  on review discussions with Dan Carpenter.
- Dropped older HW support patches for staging
  at GregKH request.
- Rewrote for clarity hash setkey fix commit
  message.
- Added now no longer needed KConfig option to
  code dropped by bus coherency being set by DT
  patch.

Changes from v1:
- Rebased on top of latest patches sent to mailing
  list but not yet marged for same driver.
- Address Dan Carpenter style review comments
- Fix clk de-init being called on clk init failure
  error path pointed out by Dan Carpenter.

 drivers/staging/ccree/Kconfig|   9 --
 drivers/staging/ccree/Makefile   |   2 +-
 drivers/staging/ccree/cc_hw_queue_defs.h |  12 --
 drivers/staging/ccree/ssi_buffer_mgr.c   |  37 ++---
 drivers/staging/ccree/ssi_config.h   |  20 ---
 drivers/staging/ccree/ssi_driver.c   |  55 ++--
 drivers/staging/ccree/ssi_driver.h   |   8 +-
 drivers/staging/ccree/ssi_hash.c | 226 +++
 drivers/staging/ccree/ssi_hash.h |   2 +
 drivers/staging/ccree/ssi_pm.c   |  13 +-
 drivers/staging/ccree/ssi_pm_ext.c   |  60 
 drivers/staging/ccree/ssi_pm_ext.h   |  33 -
 drivers/staging/ccree/ssi_request_mgr.c  |   3 +-
 13 files changed, 227 insertions(+), 253 deletions(-)
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.c
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.h

-- 
2.1.4

Re: PM / wakeirq: Convert to SRCU

[Thomas Gleixner]

On Sat, 24 Jun 2017, Paul E. McKenney wrote:
> On Sat, Jun 24, 2017 at 11:56:11AM +0200, Thomas Gleixner wrote:
> >  static DECLARE_WAIT_QUEUE_HEAD(wakeup_count_wait_queue);
> > 
> > +static struct srcu_struct wakeup_srcu;
> 
> I suggest this to avoid the need for boot-time init_srcu_struct():
> 
> DEFINE_STATIC_SRCU(wakeup_srcu);

Now I know why I had this nagging feeling, that should stay away from
computers yesterday morning.

> >  static struct wakeup_source deleted_ws = {
> > .name = "deleted",
> > .lock =  __SPIN_LOCK_UNLOCKED(deleted_ws.lock),
> > @@ -198,7 +200,7 @@ void wakeup_source_remove(struct wakeup_
> > spin_lock_irqsave(_lock, flags);
> > list_del_rcu(>entry);
> > spin_unlock_irqrestore(_lock, flags);
> > -   synchronize_rcu();
> > +   synchronize_srcu(_srcu);
> >  }
> >  EXPORT_SYMBOL_GPL(wakeup_source_remove);
> 
> The uses of RCU in device_wakeup_arm_wake_irqs() and
> device_wakeup_disarm_wake_irqs() are unrelated and thus do not
> need to be converted?  Or am I looking at the wrong version of
> the kernel?  (Looking at f65013d655ac ("Merge branch 'for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace")
> in Linus's tree.)

No, you are looking at the result of heat induced brain melt. Will send a
proper one soon.

Thanks,

tglx

[GIT pull] perf fixes for 4.12

[Thomas Gleixner]

Linus,

please pull the latest perf-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
perf-urgent-for-linus

Three fixlets for perf:

  - Return the proper error code if aux buffers for a event are not
supported.

  - Calculate the probe offset for inlined functions correctly

  - Update the Skylake DTLB load/store miss event so it can count 1G TLB
entries as well.

Thanks,

tglx

-->
Björn Töpel (1):
  perf probe: Fix probe definition for inlined functions

Hendrik Brueckner (1):
  perf/aux: Correct return code of rb_alloc_aux() if !has_aux(ev)

Kan Liang (1):
  perf/x86/intel: Add 1G DTLB load/store miss support for SKL


 arch/x86/events/intel/core.c  | 4 ++--
 kernel/events/ring_buffer.c   | 2 +-
 tools/perf/util/probe-event.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index a6d91d4e37a1..110ce8238466 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -431,11 +431,11 @@ static __initconst const u64 skl_hw_cache_event_ids
  [ C(DTLB) ] = {
[ C(OP_READ) ] = {
[ C(RESULT_ACCESS) ] = 0x81d0,  /* MEM_INST_RETIRED.ALL_LOADS */
-   [ C(RESULT_MISS)   ] = 0x608,   /* 
DTLB_LOAD_MISSES.WALK_COMPLETED */
+   [ C(RESULT_MISS)   ] = 0xe08,   /* 
DTLB_LOAD_MISSES.WALK_COMPLETED */
},
[ C(OP_WRITE) ] = {
[ C(RESULT_ACCESS) ] = 0x82d0,  /* MEM_INST_RETIRED.ALL_STORES 
*/
-   [ C(RESULT_MISS)   ] = 0x649,   /* 
DTLB_STORE_MISSES.WALK_COMPLETED */
+   [ C(RESULT_MISS)   ] = 0xe49,   /* 
DTLB_STORE_MISSES.WALK_COMPLETED */
},
[ C(OP_PREFETCH) ] = {
[ C(RESULT_ACCESS) ] = 0x0,
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index 2831480c63a2..ee97196bb151 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -580,7 +580,7 @@ int rb_alloc_aux(struct ring_buffer *rb, struct perf_event 
*event,
int ret = -ENOMEM, max_order = 0;
 
if (!has_aux(event))
-   return -ENOTSUPP;
+   return -EOPNOTSUPP;
 
if (event->pmu->capabilities & PERF_PMU_CAP_AUX_NO_SG) {
/*
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 84e7e698411e..a2670e9d652d 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -619,7 +619,7 @@ static int post_process_probe_trace_point(struct 
probe_trace_point *tp,
   struct map *map, unsigned long offs)
 {
struct symbol *sym;
-   u64 addr = tp->address + tp->offset - offs;
+   u64 addr = tp->address - offs;
 
sym = map__find_symbol(map, addr);
if (!sym)

Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3

[Al Viro]

On Sat, Jun 24, 2017 at 12:29:23PM -0500, Larry Finger wrote:

> I made a break through. If I turn off inline copy to/from users for 32-bit
> ppc with the following patch, then the system boots:

OK...  So it's 4.6.3 miscompiling something - it is hardware-independent,
reproduced in qemu.  I'd like to get more self-contained example of
miscompile, though; should be done by tonight...

Re: [PATCH v2 08/15] [media] cxd2880: Add top level of the driver

[Mauro Carvalho Chehab]

Em Fri, 23 Jun 2017 10:02:39 -0300
Mauro Carvalho Chehab  escreveu:

> Em Mon, 19 Jun 2017 16:56:13 +0900
> "Takiguchi, Yasunari"  escreveu:
> 
> > >> +static int cxd2880_get_frontend_t(struct dvb_frontend *fe,
> > >> +struct dtv_frontend_properties *c)
> > >> +{
> > >> +enum cxd2880_ret ret = CXD2880_RESULT_OK;
> > >> +int result = 0;
> > >> +struct cxd2880_priv *priv = NULL;
> > >> +enum cxd2880_dvbt_mode mode = CXD2880_DVBT_MODE_2K;
> > >> +enum cxd2880_dvbt_guard guard = CXD2880_DVBT_GUARD_1_32;
> > >> +struct cxd2880_dvbt_tpsinfo tps;
> > >> +enum cxd2880_tnrdmd_spectrum_sense sense;
> > >> +u16 snr = 0;
> > >> +int strength = 0;
> > >> +u32 pre_bit_err = 0, pre_bit_count = 0;
> > >> +u32 post_bit_err = 0, post_bit_count = 0;
> > >> +u32 block_err = 0, block_count = 0;
> > >> +
> > >> +if ((!fe) || (!c)) {
> > >> +pr_err("%s: invalid arg\n", __func__);
> > >> +return -EINVAL;
> > >> +}
> > >> +
> > >> +priv = (struct cxd2880_priv *)fe->demodulator_priv;
> > >> +
> > >> +mutex_lock(priv->spi_mutex);
> > >> +ret = cxd2880_tnrdmd_dvbt_mon_mode_guard(>tnrdmd,
> > >> + , );
> > >> +mutex_unlock(priv->spi_mutex);
> > >> +if (ret == CXD2880_RESULT_OK) {
> > >> +switch (mode) {
> > >> +case CXD2880_DVBT_MODE_2K:
> > >> +c->transmission_mode = TRANSMISSION_MODE_2K;
> > >> +break;
> > >> +case CXD2880_DVBT_MODE_8K:
> > >> +c->transmission_mode = TRANSMISSION_MODE_8K;
> > >> +break;
> > >> +default:
> > >> +c->transmission_mode = TRANSMISSION_MODE_2K;
> > >> +dev_err(>spi->dev, "%s: get invalid mode 
> > >> %d\n",
> > >> +__func__, mode);
> > >> +break;
> > >> +}
> > >> +switch (guard) {
> > >> +case CXD2880_DVBT_GUARD_1_32:
> > >> +c->guard_interval = GUARD_INTERVAL_1_32;
> > >> +break;
> > >> +case CXD2880_DVBT_GUARD_1_16:
> > >> +c->guard_interval = GUARD_INTERVAL_1_16;
> > >> +break;
> > >> +case CXD2880_DVBT_GUARD_1_8:
> > >> +c->guard_interval = GUARD_INTERVAL_1_8;
> > >> +break;
> > >> +case CXD2880_DVBT_GUARD_1_4:
> > >> +c->guard_interval = GUARD_INTERVAL_1_4;
> > >> +break;
> > >> +default:
> > >> +c->guard_interval = GUARD_INTERVAL_1_32;
> > >> +dev_err(>spi->dev, "%s: get invalid guard 
> > >> %d\n",
> > >> +__func__, guard);
> > >> +break;
> > >> +}
> > >> +} else {
> > >> +c->transmission_mode = TRANSMISSION_MODE_2K;
> > >> +c->guard_interval = GUARD_INTERVAL_1_32;
> > >> +dev_dbg(>spi->dev,
> > >> +"%s: ModeGuard err %d\n", __func__, ret);
> > >> +}
> > >> +
> > >> +mutex_lock(priv->spi_mutex);
> > >> +ret = cxd2880_tnrdmd_dvbt_mon_tps_info(>tnrdmd, );
> > >> +mutex_unlock(priv->spi_mutex);
> > >> +if (ret == CXD2880_RESULT_OK) {
> > >> +switch (tps.hierarchy) {
> > >> +case CXD2880_DVBT_HIERARCHY_NON:
> > >> +c->hierarchy = HIERARCHY_NONE;
> > >> +break;
> > >> +case CXD2880_DVBT_HIERARCHY_1:
> > >> +c->hierarchy = HIERARCHY_1;
> > >> +break;
> > >> +case CXD2880_DVBT_HIERARCHY_2:
> > >> +c->hierarchy = HIERARCHY_2;
> > >> +break;
> > >> +case CXD2880_DVBT_HIERARCHY_4:
> > >> +c->hierarchy = HIERARCHY_4;
> > >> +break;
> > >> +default:
> > >> +c->hierarchy = HIERARCHY_NONE;
> > >> +dev_err(>spi->dev,
> > >> +"%s: TPSInfo hierarchy invalid %d\n",
> > >> +__func__, tps.hierarchy);
> > >> +break;
> > >> +}
> > >> +
> > >> +switch (tps.rate_hp) {
> > >> +case CXD2880_DVBT_CODERATE_1_2:
> > >> +c->code_rate_HP = FEC_1_2;
> > >> +break;
> > >> +case 

[PATCH] [PATCH v7] USB hub_probe: rework ugly goto-into-compound-statement

[Eugene Korenevsky]

Rework smelling code (goto inside compound statement). Perhaps this is
legacy. Anyway such code is not appropriate for Linux kernel.

Signed-off-by: Eugene Korenevsky 
---
Changes in v7: rename hub_check_descriptor_sanity -> hub_descriptor_is_sane
Changes in v6: more pedantic conversion from `int` to `bool`; fix comment
Changes in v5: make `bool` a return type of `hub_check_descriptor_sanity()`
Changes in v4: fix typo
Changes in v3: extract the code to static function
Changes in v2: fix spaces instead of tab, add missing 'Signed-off-by'

 drivers/usb/core/hub.c | 38 +-
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b8bb20d7acdb..0484cd348156 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1661,10 +1661,28 @@ static void hub_disconnect(struct usb_interface *intf)
kref_put(>kref, hub_release);
 }
 
+static bool hub_descriptor_is_sane(struct usb_host_interface *desc)
+{
+   /* Some hubs have a subclass of 1, which AFAICT according to the */
+   /*  specs is not defined, but it works */
+   if (desc->desc.bInterfaceSubClass != 0 &&
+   desc->desc.bInterfaceSubClass != 1)
+   return false;
+
+   /* Multiple endpoints? What kind of mutant ninja-hub is this? */
+   if (desc->desc.bNumEndpoints != 1)
+   return false;
+
+   /* If the first endpoint is not interrupt IN, we'd better punt! */
+   if (!usb_endpoint_is_int_in(>endpoint[0].desc))
+   return false;
+
+return true;
+}
+
 static int hub_probe(struct usb_interface *intf, const struct usb_device_id 
*id)
 {
struct usb_host_interface *desc;
-   struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
 
@@ -1739,25 +1757,11 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
}
 #endif
 
-   /* Some hubs have a subclass of 1, which AFAICT according to the */
-   /*  specs is not defined, but it works */
-   if ((desc->desc.bInterfaceSubClass != 0) &&
-   (desc->desc.bInterfaceSubClass != 1)) {
-descriptor_error:
+   if (!hub_descriptor_is_sane(desc)) {
dev_err(>dev, "bad descriptor, ignoring hub\n");
return -EIO;
}
 
-   /* Multiple endpoints? What kind of mutant ninja-hub is this? */
-   if (desc->desc.bNumEndpoints != 1)
-   goto descriptor_error;
-
-   endpoint = >endpoint[0].desc;
-
-   /* If it's not an interrupt in endpoint, we'd better punt! */
-   if (!usb_endpoint_is_int_in(endpoint))
-   goto descriptor_error;
-
/* We found a hub */
dev_info(>dev, "USB hub found\n");
 
@@ -1784,7 +1788,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
 
-   if (hub_configure(hub, endpoint) >= 0)
+   if (hub_configure(hub, >endpoint[0].desc) >= 0)
return 0;
 
hub_disconnect(intf);
-- 
2.13.1

[PATCH] staging: android: ion: Use DEFINE_DEBUGFS_ATTRIBUTE

[Tommy Nguyen]

Running coccicheck indicates that DEFINE_DEBUGFS_ATTRIBUTE
and debugfs_create_file_unsafe should be used instead.

Signed-off-by: Tommy Nguyen 
---
 drivers/staging/android/ion/ion.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 03d3a4f..8f96b38 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -544,8 +544,8 @@ static int debug_shrink_get(void *data, u64 *val)
return 0;
 }
 
-DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
-   debug_shrink_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
+debug_shrink_set, "%llu\n");
 
 void ion_device_add_heap(struct ion_heap *heap)
 {
@@ -579,7 +579,7 @@ void ion_device_add_heap(struct ion_heap *heap)
char debug_name[64];
 
snprintf(debug_name, 64, "%s_shrink", heap->name);
-   debug_file = debugfs_create_file(
+   debug_file = debugfs_create_file_unsafe(
debug_name, 0644, dev->debug_root, heap,
_shrink_fops);
if (!debug_file) {
-- 
2.9.4

Re: [PATCH v1 5/6] [media] ov9650: add multiple variant support

[kbuild test robot]

Hi Hugues,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.12-rc6 next-20170623]
[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/Hugues-Fruchet/Add-support-of-OV9655-camera/20170625-201153
base:   git://linuxtv.org/media_tree.git master
config: i386-randconfig-x079-06251032 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/media//i2c/ov9650.c: In function 'ov965x_probe':
>> drivers/media//i2c/ov9650.c:1617:2: warning: this 'if' clause does not 
>> guard... [-Wmisleading-indentation]
 if (ov965x->initialize_controls)
 ^~
   drivers/media//i2c/ov9650.c:1619:3: note: ...this statement, but the latter 
is misleadingly indented as if it is guarded by the 'if'
  if (ret < 0)
  ^~
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
   Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata
   Cyclomatic Complexity 1 include/asm-generic/gpio.h:gpio_is_valid
   Cyclomatic Complexity 1 include/linux/i2c.h:i2c_get_clientdata
   Cyclomatic Complexity 1 include/media/media-entity.h:media_entity_cleanup
   Cyclomatic Complexity 1 include/media/v4l2-subdev.h:v4l2_get_subdevdata
   Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ctrl_to_sd
   Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:to_ov965x
   Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ov965x_get_default_format
   Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_enum_mbus_code
   Cyclomatic Complexity 4 drivers/media//i2c/ov9650.c:ov965x_enum_frame_sizes
   Cyclomatic Complexity 6 drivers/media//i2c/ov9650.c:__ov965x_try_frame_size
   Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ov965x_i2c_driver_init
   Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ov965x_remove
   Cyclomatic Complexity 8 
drivers/media//i2c/ov9650.c:__ov965x_set_frame_interval
   Cyclomatic Complexity 5 drivers/media//i2c/ov9650.c:ov965x_read
   Cyclomatic Complexity 11 drivers/media//i2c/ov9650.c:__g_volatile_ctrl
   Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_write
   Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_write_array
   Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_set_frame_size
   Cyclomatic Complexity 3 
drivers/media//i2c/ov9650.c:ov965x_set_default_gamma_curve
   Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_color_matrix
   Cyclomatic Complexity 5 drivers/media//i2c/ov9650.c:ov965x_set_white_balance
   Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_brightness
   Cyclomatic Complexity 12 drivers/media//i2c/ov9650.c:ov965x_set_gain
   Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_flip
   Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_saturation
   Cyclomatic Complexity 6 drivers/media//i2c/ov9650.c:ov965x_set_sharpness
   Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_test_pattern
   Cyclomatic Complexity 7 drivers/media//i2c/ov9650.c:ov965x_set_banding_filter
   Cyclomatic Complexity 10 drivers/media//i2c/ov9650.c:__ov965x_set_params
   Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
   Cyclomatic Complexity 1 include/media/v4l2-ctrls.h:v4l2_ctrl_lock
   Cyclomatic Complexity 1 include/media/v4l2-ctrls.h:v4l2_ctrl_unlock
   Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_g_volatile_ctrl
   Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_s_frame_interval
   Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_g_frame_interval
   Cyclomatic Complexity 1 include/media/v4l2-ctrls.h:v4l2_ctrl_modify_range
   Cyclomatic Complexity 7 
drivers/media//i2c/ov9650.c:ov965x_update_exposure_ctrl
   Cyclomatic Complexity 3 
drivers/media//i2c/ov9650.c:ov965x_initialize_controls
   Cyclomatic Complexity 10 drivers/media//i2c/ov9650.c:ov965x_set_exposure
   Cyclomatic Complexity 12 drivers/media//i2c/ov9650.c:ov965x_s_ctrl
   Cyclomatic Complexity 1 
include/media/v4l2-subdev.h:v4l2_subdev_get_try_format
   Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ov965x_open
   Cyclomatic Complexity 11 drivers/media//i2c/ov9650.c:ov965x_set_fmt
   Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_get_fmt
   Cyclomatic Complexity 13 drivers/media//i2c/ov9650.c:ov965x_s_stream
   Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_gpio_set
   Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:__ov965x_set_power
   Cyclomatic Complexity 7 drivers/media//i2c/ov9650.c:ov965x_s_power
   Cyclomatic Complexity 4 drivers/media//i2c/ov9650.c:ov965x_detect_sensor
   Cyclomatic Complexity 1 include/linux/device.h:devm_kzalloc
   Cyclomatic Complexity 1 include/asm-generic/gpio.h:__gpio_set_value
  

Re: [PATCH 6/6] rtc: s3c: Handle clock enable failures

[Krzysztof Kozlowski]

On Sat, Jun 24, 2017 at 10:55 PM, Alexandre Belloni
 wrote:
> Hi,
>
> On 16/06/2017 at 21:28:07 +0200, Krzysztof Kozlowski wrote:
>> clk_enable() can fail so handle such case.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  drivers/rtc/rtc-s3c.c | 72 
>> ---
>>  1 file changed, 57 insertions(+), 15 deletions(-)
>>
>
> I've applied the whole series. However, quite often, on a platform,
> clk_prepare/enable are ensured to never fail and I find that the added
> complexity to handle failures is not worth it.

Indeed, the platform clocks usually cannot fail (although not always,
e.g. some PLLs might return ETIMEDOUT on sync timeout) but in this
case one of the clocks is an I2C-controlled clock from PMIC. Its
clk_prepare() can fail. It does not implement clk_enable() but this
might change in the future so to avoid unexpected issues, it is better
just to handle this properly.

Best regards,
Krzysztof

omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

[Pavel Machek]

Hi!

> * unfortunately we still get no image :(
> 
> The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image 
> Signal Processor) which
> we were not yet able to solve. Oscilloscoping signals on the interface 
> indicated that signals and
> sync are correct. But we do not know since mplayer only shows a green screen.

What mplayer command line do you use? How did you set up the pipeline
with media-ctl?

On kernel.org, I have tree called camera-fw5-6 , where camera works
for me on n900. On gitlab, there's modifed fcam-dev, which can be used
for testing.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 0/5] g_NCR5380: PDMA fixes and cleanup

[Ondrej Zary]

On Saturday 24 June 2017 08:37:36 Finn Thain wrote:
> Ondrej, would you please test this new series?
>
> Changed since v1:
> - PDMA transfer residual is calculated earlier.
> - End of DMA flag check is now polled (if there is any residual).
>
>
> Finn Thain (2):
>   g_NCR5380: Limit sg_tablesize to avoid PDMA read overruns on DTC436
>   g_NCR5380: Cleanup comments and whitespace
>
> Ondrej Zary (3):
>   g_NCR5380: Fix PDMA transfer size
>   g_NCR5380: End PDMA transfer correctly on target disconnection
>   g_NCR5380: Re-work PDMA loops
>
>  drivers/scsi/g_NCR5380.c | 231
> ++- 1 file changed, 107
> insertions(+), 124 deletions(-)

It mostly works, but there are some problems:

It's not reliable - we continue the data transfer after poll_politely2
returns zero but we don't know if it returned because of host buffer
being ready of because of an IRQ. So if a device disconnects during write,
we continue to fill the buffer and only then find out that wait for
53c80 registers timed out. Then PDMA gets disabled:
[ 3458.774251] sd 2:0:1:0: [sdb] tag#0 53c80 registers not accessible, device 
will be reset
[ 3458.774251] sd 2:0:1:0: [sdb] tag#0 switching to slow handshake

We can just reset and continue with a new PDMA transfer. Found no problems
with reads. But when this happens during a write, we might have lost some
data buffers that we need to transfer again. The chip's PDMA block counter
does not seem to be very helpful here - testing shows that either one buffer
is missing in the file or is duplicated.

That's why my code had separate host buffer ready and IRQ checks. Host
buffer first - if it's ready, transfer the data. If not, check for IRQ - 
if it was an error, rollback 2 buffers (the same if the host buffer is not
ready in time).



There's also a performance regression on DTC436 - the sg_tablesize limit
affects performance badly.
Before:
# hdparm -t --direct /dev/sdb

/dev/sdb:
 Timing O_DIRECT disk reads:   4 MB in  3.21 seconds =   1.25 MB/sec

Now:
# hdparm -t --direct /dev/sdb

/dev/sdb:
 Timing O_DIRECT disk reads:   4 MB in  4.89 seconds = 837.69 kB/sec

We should limit the transfer size instead:
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -45,7 +45,8 @@
int c400_blk_cnt; \
int c400_host_buf; \
int io_width; \
-   int pdma_residual
+   int pdma_residual; \
+   int board;

 #define NCR5380_dma_xfer_lengeneric_NCR5380_dma_xfer_len
 #define NCR5380_dma_recv_setup  generic_NCR5380_pread
@@ -247,7 +248,6 @@ static int generic_NCR5380_init_one(struct 
scsi_host_template *tpnt,
case BOARD_DTC3181E:
ports = dtc_3181e_ports;
magic = ncr_53c400a_magic;
-   tpnt->sg_tablesize = 1;
break;
}

@@ -317,6 +317,7 @@ static int generic_NCR5380_init_one(struct 
scsi_host_template *tpnt,
}
hostdata = shost_priv(instance);

+   hostdata->board = board;
hostdata->io = iomem;
hostdata->region_size = region_size;

@@ -625,6 +626,9 @@ static int generic_NCR5380_dma_xfer_len(struct 
NCR5380_hostdata *hostdata,
/* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */
if (transfersize % 128)
transfersize = 0;
+   /* Limit transfers to 512B to prevent random write corruption on DTC */
+   if (hostdata->board == BOARD_DTC3181E && transfersize > 512)
+   transfersize = 512;

return min(transfersize, DMA_MAX_SIZE);
 }


No data corruption and no performance regression:
# hdparm -t --direct /dev/sdb

/dev/sdb:
 Timing O_DIRECT disk reads:   4 MB in  3.25 seconds =   1.23 MB/sec

As the data corruption affects only writes, we could keep transfersize
unlimited for reads:
+   /* Limit write transfers to 512B to prevent random corruption on DTC */
+   if (hostdata->board == BOARD_DTC3181E &&
+   cmd->sc_data_direction == DMA_TO_DEVICE && transfersize > 512)
+   transfersize = 512;

So we can get some performance gain at least for reads:
# hdparm -t --direct /dev/sdb

/dev/sdb:
 Timing O_DIRECT disk reads:   6 MB in  4.17 seconds =   1.44 MB/sec


-- 
Ondrej Zary

[PATCH] ocfs2: free 'dummy_sc' in sc_fop_release() in case of memory leak

[piaojun]

'sd->dbg_sock' is malloc in sc_common_open(), but not freed at the end
of sc_fop_release().

Signed-off-by: Jun Piao 
---
 fs/ocfs2/cluster/netdebug.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ocfs2/cluster/netdebug.c b/fs/ocfs2/cluster/netdebug.c
index 564c504..74a21f6 100644
--- a/fs/ocfs2/cluster/netdebug.c
+++ b/fs/ocfs2/cluster/netdebug.c
@@ -426,6 +426,7 @@ static int sc_fop_release(struct inode *inode, struct file 
*file)
struct o2net_sock_container *dummy_sc = sd->dbg_sock;

o2net_debug_del_sc(dummy_sc);
+   kfree(dummy_sc);
return seq_release_private(inode, file);
 }

-- 

[PATCH] staging: lustre: replace kmalloc with kmalloc_array

[Denis Petrovic]

This patch fixes the following checkpatch.pl warning:

WARNING: Prefer kmalloc_array over kmalloc with multiply

Signed-off-by: Denis Petrovic 
---
 drivers/staging/lustre/lnet/libcfs/linux/linux-tracefile.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-tracefile.c 
b/drivers/staging/lustre/lnet/libcfs/linux/linux-tracefile.c
index 75eb84e7f0f8..a5a94788f11f 100644
--- a/drivers/staging/lustre/lnet/libcfs/linux/linux-tracefile.c
+++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-tracefile.c
@@ -57,8 +57,9 @@ int cfs_tracefile_init_arch(void)
memset(cfs_trace_data, 0, sizeof(cfs_trace_data));
for (i = 0; i < CFS_TCD_TYPE_MAX; i++) {
cfs_trace_data[i] =
-   kmalloc(sizeof(union cfs_trace_data_union) *
-   num_possible_cpus(), GFP_KERNEL);
+   kmalloc_array(num_possible_cpus(),
+ sizeof(union cfs_trace_data_union),
+ GFP_KERNEL);
if (!cfs_trace_data[i])
goto out;
}
-- 
2.11.0

Re: [PATCH] ARM: dts: exynos: Exynos5422 Odroid-XU* incomplete thermal-zones definition

[Anand Moon]

Hi Krzysztof,

On 25 June 2017 at 22:49, Krzysztof Kozlowski  wrote:
> On Sun, Jun 25, 2017 at 10:25:32PM +0530, Anand Moon wrote:
>> Hi Krzysztof
>>
>> On 25 June 2017 at 20:59, Krzysztof Kozlowski  wrote:
>> > On Sun, Jun 25, 2017 at 08:48:13PM +0530, Anand Moon wrote:
>> >> Hi Krzystof,
>> >> >> 2: We should also increase the tips from 4 to 8 to support different
>> >> >> cluster of cpu's.
>> >> >
>> >> > There are 4 CPU thermal zones on Exynos5422. What do you want to expand?
>> >>
>> >> What I meant was to support more trip point to address below.
>> >> [2.776320] exynos-tmu 100a.tmu: More trip points than
>> >> supported by this TMU.
>> >> [2.782370] exynos-tmu 100a.tmu: 2 trip points should be
>> >> configured in polling mode.
>> >>
>> >
>> > I do not understand what you want to achieve. I added 2 trip points in
>> > polling mode for the CPU cooling mode. Just describe the problem and
>> > send the patch - it is the best way to explain one's thought...
>> >
>> >> >> 3: To avoid duplication of cooling-maps we can make tmu sensor work
>> >> >> differently for cluster of cpu's
>> >> >>   tmu_cpu0: handle pwm-fan control.
>> >> >>   tmu_cpu1: handle cpu[0-3] cpufreq mapping.
>> >> >>   tmu_cpu2: handle cpu[4-7] cpufreq mapping.
>> >> >
>> >> > I miss the point behind this. Why fan should work only when CPU4
>> >> > (tmu_cpu0) is heated and not CPU5-7 (rest of cpu tmu's)?
>> >>
>> >> Ok fan should work on all the thermal zone. To avoid thermal shutdown.
>> >>
>> >> But I want to avoid scaling down of all the cores of cpu to low freq
>> >> as cooling-maps cross the alert temperature. For below example.
>> >> 
>> >>  map3 {
>> >>   trip = <_alert3>;
>> >>   cooling-device = < 0 2>;
>> >>  };
>> >>  map4 {
>> >>   trip = <_alert3>;
>> >>   cooling-device = < 0 2>;
>> >>  };
>> >>
>> >>  map5 {
>> >>   trip = <_alert4>;
>> >>   cooling-device = < 3 7>;
>> >>  };
>> >>  map6 {
>> >>  trip = <_alert4>;
>> >>  cooling-device = < 3 12>;
>> >>  };
>> >>
>> >> What I want to configure thermal zone as.
>> >>
>> >> cpu0_thermal: cpu0-thermal {
>> >>  configure cluster of cpu[0-3]
>> >>  {
>> >> tips
>> >>  }
>> >>  cooling map
>> >>  {
>> >>  device handle cpu[0-3] with frequency scaling at particular
>> >> alert temperature.
>> >>  }
>> >> }
>> >
>> > cpu0_thermal is attached to tmu_cpu0 which is the temperature of CPU4
>> > (first big core). I do not see reason behind connecting thermal zone
>> > (thus temperature) of CPU4 with frequency of LITTLE cluster (CPU0-3). In
>> > case of busy CPU4, you will scale down CPU0-3. Does not make sense.
>> >
>>
>> Both the cpu cluster are independent and have different cpu-freqency scaling.
>> that is the reason to for my changes.
>
> Still does not make sense. Big is busy, LITTLE is doing nothing and you
> want to scale down LITTLE. No reason.
>
>>
>> >> cpu1_thermal: cpu1-thermal {
>> >>  configure cluster of cpu[4-7]
>> >>  {
>> >> tips
>> >>  }
>> >>  cooling map
>> >>  {
>> >>  device handle cpu[4-7] with frequency scaling at particular
>> >> alert temperature.
>> >>  }
>> >> }
>> >>
>> >> We can chose to configure rest of the thermal-zone on this approach.
>> >> Please share your thoughts.
>> >
>> > I am sorry, I do not understand the idea, the problem nor the solution.
>> >
>> > Best regards,
>> > Krzysztof
>> >
>>
>> Sorry for not able to express my self in technical terms.
>> my changes are based on exynos5433-tmu at this moment.
>> Just attaching small patch to share my point.
>
> On Odroid XU3-family, all TMU interrupt-driven configureable trip points
> are configured. Why are you referring to Exynos5433?

Because both these ARCH are big.Little.

Best Regards
-Anand

RE: [PATCH 0/6] Drivers: hv: vmbus: Ringbuffer cleanup and optimizations

[KY Srinivasan]

> -Original Message-
> From: k...@exchange.microsoft.com [mailto:k...@exchange.microsoft.com]
> Sent: Sunday, June 25, 2017 11:28 AM
> To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com; jasow...@redhat.com;
> leann.ogasaw...@canonical.com; marcelo.ce...@canonical.com; Stephen
> Hemminger 
> Cc: KY Srinivasan 
> Subject: [PATCH 0/6] Drivers: hv: vmbus: Ringbuffer cleanup and
> optimizations
> 
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> 
> From: K. Y. Srinivasan 
> 
> This removes unused bits from vmbus internals, and also does some
> optimization to the host signalling part of ring buffer logic.
> 
> Stephen Hemminger (6):
>   vmbus: simplify hv_ringbuffer_read
>   vmbus: drop unused ring_buffer_info elements
>   vmbus: refactor hv_signal_on_read
>   vmbus: eliminate duplicate cached index
>   vmbus: more host signalling avoidance
>   vmbus: add prefetch to ring buffer iterator
> 
>  drivers/hv/ring_buffer.c |  169 -
>  include/linux/hyperv.h   |   65 --
>  2 files changed, 60 insertions(+), 174 deletions(-)
Greg,

Please drop this; I am going to resend shortly.

K. Y

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

[Enrico Weigelt, metux IT consult]

On 25.06.2017 19:27, Joe Perches wrote:

> Every use of %M is going to cause gcc when using __printf to emit
> a warning like:
> 
> unknown conversion type character ‘M’ in format [-Wformat=]

Yeah, that's still an open problem. Actually, I still haven't found out,
how it's done w/ all the other kernel-internal conversions. I was under
the impression, there was some magic to tell the compiler which letters
correspond to which types - unfortunately, didn't find anything like
that. Is that really hardcoded in gcc ?

> Beyond that, why is this useful?

Use that instead of %d where errno values are printed/logged.

> There can't possibly be any fast-path use.

I'm using it eg. for driver development - always having to look up the
numbers is quite ugly and time consuming.

> Why not just create a function that does errno/string conversions?

Already was about to do so. Shall I call it strerror() ?


--mtx

--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287

Re: [PATCH] rpmsg: Release rpmsg devices in backends

[Bjorn Andersson]

On Fri 02 Jun 17:28 PDT 2017, Suman Anna wrote:

> Hi Bjorn,
> 
> On 06/02/2017 05:07 AM, Henri Roosen wrote:
> > My suggestion would be to additionally change/fix
> > rpmsg_register_device() so it will not overwrite the release callback.
[..]
> FWIW, I didn't run into any rpmsg device memory leaks even without this
> patch with booting and shutting down of remoteproc devices. The
> virtio_rpmsg_channel structure inherits the struct rpmsg_device and is
> the one that gets allocated, and the release function plugged in
> rpmsg_release_device is operating on the rpmsg_device pointer, but both
> are actually the same pointer.
> 
> Did you run into any memory leaks that required you to have this patch?
> 

I did not see any memory leaks, because it happens that the pointers are
the same in all current cases.

But the code is wrong and should be fixed, thanks for pointing this out
Henri!

Regards,
Bjorn

Re: [PATCH v2 1/2] DT: pinctrl: Add binding documentation for Spreadtrum pin controller

[Linus Walleij]

On Wed, Jun 21, 2017 at 10:10 AM, Baolin Wang  wrote:
> On 20 June 2017 at 17:31, Linus Walleij  wrote:
>> On Tue, Jun 13, 2017 at 5:15 AM, Baolin Wang  
>> wrote:
>>
>>> I forgot one most important reason why we can not use the "sleep" state. As 
>>> I explained
>>> above, the sleep related configuration will bind with the pin's sleep mode. 
>>> If we set the
>>> pin's sleep mode as AP_SLEEP, then we can select "sleep" state when AP 
>>> system goes into
>>> deep sleep mode by issuing "pinctrl_force_sleep()" in pinctrl suspend 
>>> function.
>>>
>>> But if we set the pin's sleep mode as PUBCP_SLEEP and pubcp system doesn't 
>>> run linux kernel
>>> (it run another thread OS), then we can not select "sleep" state since the 
>>> AP system does
>>> not go into deep sleep mode (AP system run linux kernel OS).
>>
>> Allright yes it makes sense, and also there are systems that just go into
>> "hardware sleep" and just put the pin into some pre-programmed mode.
>>
>> I'm a bit back-and-forth. I didn't mean that some code would actually
>> switch the state to "sleep" when we go to sleep, I meant that when
>> the system configures "default" mode it should also look up and
>> program the "sleep" mode, but this approach with a special property
>> is just another way of achieveing the same thing.
>>
>> But then we should add a whole slew of sleep states.
>>
>> I was thinking whether we could avoid having a special DT property
>> by parsing ahead to states we do not currently use and programming
>> that into the sleep mode registers.
>
> Yes, for most scenarios, it can work with the "sleep" state to set
> sleep-related config. But for our Spreadtrum platform scenario (I do
> not know if there are other platforms need this feature), we can not
> select the "sleep" state when pubcp system goes into deep sleep mode
> but ap system does not go into deep sleep mode. So I think we still
> need these "sleep-bias-pull-up", "sleep-bias-pull-down",
> "sleep-input-enable" and "sleep-output-enable" properties.

I don't really mean you should select the "sleep" state.

I meant, as part of setting the "default" state or even the "init"
state, we would inspect the "sleep" state, use those settings, and
program them into the registers at this early point.

Then never touch the registers again, and never really go to the
sleep state by software, just by hardware.

Yours,
Linus Walleij

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

[Joe Perches]

On Sun, 2017-06-25 at 19:12 +0200, Enrico Weigelt, metux IT consult
wrote:
> Adding a new format conversion for *printf() and friends.

Every use of %M is going to cause gcc when using __printf to emit
a warning like:

unknown conversion type character ‘M’ in format [-Wformat=]

Beyond that, why is this useful?
There can't possibly be any fast-path use.
Why not just create a function that does errno/string conversions?

Re: [PATCH v4] Input: mousedev - fix implicit conversion warning

[Dmitry Torokhov]

Hi Nick,

On Mon, May 29, 2017 at 10:41:51PM -0700, Nick Desaulniers wrote:
> Clang warns:
> 
> drivers/input/mousedev.c:653:63: error: implicit conversion from 'int'
> to 'signed char' changes value from 200 to -56
> [-Wconstant-conversion]
>   client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
> ~ ^~~
> 
> As far as I can tell, from
> 
> http://www.computer-engineering.org/ps2mouse/
> 
> Under "Command Set" > "0xE9 (Status Request)"
> 
> the value 200 is a valid sample rate. Using unsigned char [], rather than
> signed char [], for client->ps2 silences this warning.
> 
> Also moves some reused logic into a helper function.
> 
> Signed-off-by: Nick Desaulniers 
> ---
> What's new in v4:
> * replace mousedev_limit_delta() with update_clamped() that also updates
>   the ps2_data and delta values. The use of the temporary val should
>   avoid integral conversion and promotion issues.
> 
>  drivers/input/mousedev.c | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
> index 0e0ff84088fd..e645b8c6f2cb 100644
> --- a/drivers/input/mousedev.c
> +++ b/drivers/input/mousedev.c
> @@ -103,7 +103,7 @@ struct mousedev_client {
>   spinlock_t packet_lock;
>   int pos_x, pos_y;
>  
> - signed char ps2[6];
> + unsigned char ps2[6];
>   unsigned char ready, buffer, bufsiz;
>   unsigned char imexseq, impsseq;
>   enum mousedev_emul mode;
> @@ -571,27 +571,27 @@ static int mousedev_open(struct inode *inode, struct 
> file *file)
>   return error;
>  }
>  
> -static inline int mousedev_limit_delta(int delta, int limit)
> +static inline void
> +update_clamped(unsigned char *ps2_data, int *delta, int limit)
>  {
> - return delta > limit ? limit : (delta < -limit ? -limit : delta);
> + int val = *delta > limit ? limit : (*delta < -limit ? -limit : *delta);
> + *ps2_data = (unsigned char) val;
> + *delta -= val;

Since the time the code was written we got nice helpers to clamp the
values. Does the following work for you or it still leaves clang
unhappy?

Thanks.

-- 
Dmitry


Input: mousedev - fix implicit conversion warning

From: Nick Desaulniers 

Clang warns:

drivers/input/mousedev.c:653:63: error: implicit conversion from 'int'
to 'signed char' changes value from 200 to -56
[-Wconstant-conversion]
  client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
~ ^~~
As the PS2 data is really a stream of bytes, let's switch to using u8 type
for it, which silences this warning.

Signed-off-by: Nick Desaulniers 
Patchwork-Id: 9753771
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/mousedev.c |   60 +-
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
index 0e0ff84088fd..6ef0c5314f69 100644
--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -15,6 +15,7 @@
 #define MOUSEDEV_MINORS31
 #define MOUSEDEV_MIX   63
 
+#include 
 #include 
 #include 
 #include 
@@ -103,7 +104,7 @@ struct mousedev_client {
spinlock_t packet_lock;
int pos_x, pos_y;
 
-   signed char ps2[6];
+   u8 ps2[6];
unsigned char ready, buffer, bufsiz;
unsigned char imexseq, impsseq;
enum mousedev_emul mode;
@@ -291,11 +292,10 @@ static void mousedev_notify_readers(struct mousedev 
*mousedev,
}
 
client->pos_x += packet->dx;
-   client->pos_x = client->pos_x < 0 ?
-   0 : (client->pos_x >= xres ? xres : client->pos_x);
+   client->pos_x = clamp_val(client->pos_x, 0, xres);
+
client->pos_y += packet->dy;
-   client->pos_y = client->pos_y < 0 ?
-   0 : (client->pos_y >= yres ? yres : client->pos_y);
+   client->pos_y = clamp_val(client->pos_y, 0, yres);
 
p->dx += packet->dx;
p->dy += packet->dy;
@@ -571,44 +571,48 @@ static int mousedev_open(struct inode *inode, struct file 
*file)
return error;
 }
 
-static inline int mousedev_limit_delta(int delta, int limit)
-{
-   return delta > limit ? limit : (delta < -limit ? -limit : delta);
-}
-
-static void mousedev_packet(struct mousedev_client *client,
-   signed char *ps2_data)
+static void mousedev_packet(struct mousedev_client *client, u8 *ps2_data)
 {
struct mousedev_motion *p = >packets[client->tail];
+   s8 dx, dy, dz;
+
+   dx = clamp_val(p->dx, -127, 127);
+   p->dx -= dx;
+
+   dy = clamp_val(p->dy, -127, 127);
+   p->dy -= dy;
 
-   ps2_data[0] = 0x08 |
-   ((p->dx < 0) << 4) | 

4.12.0-rc6+: WQ_MEM_RECLAIM hci0:hci_power_off is flushing !WQ_MEM_RECLAIM events:btusb_work

[Dominik Brodowski]

Hi!

On my Dell XPS 13 9343 (x86_64), the following warning was logged right
after a resume from suspend-to-mem (not on *every* resume, though, so it
might be hard to reproduce). The kernel is v4.12.0-rc6+ as of 94a6df251dd0,
and I don't really use bluetooth, though the drivers are loaded:

PM: Finishing wakeup.
OOM killer enabled.
Restarting tasks ... done.
Bluetooth: hci0: read Intel version: 370710018002030d00
Bluetooth: hci0: Intel Bluetooth firmware file: 
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated
... 
workqueue: WQ_MEM_RECLAIM hci0:hci_power_off is flushing !WQ_MEM_RECLAIM 
events:btusb_work
[ cut here ]
WARNING: CPU: 2 PID: 14231 at 
/home/brodo/local/kernel/git/linux/kernel/workqueue.c:2423 
check_flush_dependency+0xb3/0x100
Modules linked in:
CPU: 2 PID: 14231 Comm: kworker/u9:4 Not tainted 4.12.0-rc6+ #3
Hardware name: Dell Inc. XPS 13 9343/0TM99H, BIOS A11 12/08/2016
Workqueue: hci0 hci_power_off
task: 9432dad58000 task.stack: 986d4379
RIP: 0010:check_flush_dependency+0xb3/0x100
RSP: 0018:986d43793c90 EFLAGS: 00010086
RAX: 005a RBX: 943316810820 RCX: 
RDX:  RSI: 0096 RDI: 0001
RBP: 986d43793cb0 R08: 0775 R09: 85bdd5c0
R10: 0040 R11:  R12: 84d596e0
R13: 9432dad58000 R14: 94321c640320 R15: 9432dad58000
FS:  () GS:94331f50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7b8bca242000 CR3: 00014f60a000 CR4: 003406e0
Call Trace:
 flush_work+0x8a/0x1c0
 ? flush_work+0x184/0x1c0
 ? skb_free_head+0x21/0x30
 __cancel_work_timer+0x124/0x1b0
 ? hci_dev_do_close+0x2a4/0x4d0
 cancel_work_sync+0x10/0x20
 btusb_close+0x23/0x100
 hci_dev_do_close+0x2ca/0x4d0
 hci_power_off+0x1e/0x50
 process_one_work+0x184/0x3e0
 worker_thread+0x4a/0x3a0
 ? preempt_count_sub+0x9b/0x100
 ? preempt_count_sub+0x9b/0x100
 kthread+0x125/0x140
 ? process_one_work+0x3e0/0x3e0
 ? __kthread_create_on_node+0x1a0/0x1a0
 ? do_syscall_64+0x58/0xd0
 ret_from_fork+0x27/0x40
Code: 00 75 bf 49 8b 56 18 48 8d 8b b0 00 00 00 48 81 c6 b0 00 00 00 4d 89 e0 
48 c7 c7 20 23 6b 85 c6 05 83 cd 31 01 01 e8 bf c4 0c 00 <0f> ff eb 93 80 3d 74 
cd 31 01 00 75 a5 65 48 8b 04 25 00 c5 00 
---[ end trace b88fd2f77754bfec ]---


Best
Dominik

Re: pull-request: wireless-drivers-next 2017-06-25

[David Miller]

From: Kalle Valo 
Date: Sun, 25 Jun 2017 20:48:36 +0300

> yet another pull request to net-next for 4.13, more info in the signed
> tag below. While doing a test merge on net-next I noticed git doing
> quite a lot of auto-merging, maybe because of mac80211 API changes, but
> luckily no conflicts. But please do let me know if you have any
> problems.

Pulled, thanks Kalle.

> Patchwork shows me that I have over 100 patches still pending for review
> so quite a lot still coming towards you some time next week.

Have fun with that :)