date:20151031

On Sat, Oct 31, 2015 at 11:03:00PM +0100, Bogicevic Sasa wrote:
> This fixes increment of pos int to be more readable
> Lines qcb->csr[index].srcport_lo = ((buf[pos++]<<8)&0xff00);
>   qcb->csr[index].srcport_lo += buf[pos++];
> become
>   qcb->csr[index].srcport_lo = get_unaligned_le16([pos]);
>   pos += 2;
> 
> Signed-off-by: Bogicevic Sasa 
> ---
>  drivers/staging/gdm72xx/gdm_qos.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

I'm totally confused, please resend all of these patches, numbered in
order, so I have a chance to know how to apply them.  Also please always
 cc: the proper mailing lists for staging patches (hint, not lkml).

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers:staging:gdm724x Fix Blank lines aren't necessary after an open brace '{'

On Fri, Oct 30, 2015 at 03:30:56PM +0100, Bogicevic Sasa wrote:
> This fixes "Blank lines aren't necessary after an open brace '{'"
> message from checkpatch.pl
> 
> Signed-off-by: Bogicevic Sasa 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch did not apply to any known trees that Greg is in control
  of.  Possibly this is because you made it against Linus's tree, not
  the linux-next tree, which is where all of the development for the
  next version of the kernel is at.  Please refresh your patch against
  the linux-next tree, or even better yet, the development tree
  specified in the MAINTAINERS file for the subsystem you are submitting
  a patch for, and resend it.

- You sent multiple patches, yet no indication of which ones should be
  applied in which order.  Greg could just guess, but if you are
  receiving this email, he guessed wrong and the patches didn't apply.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/SubmittingPatches for a description of how
  to do this so that Greg has a chance to apply these correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] drivers:staging:gdm724x Fix comparison to NULL coding style

On Thu, Oct 29, 2015 at 09:23:09PM +0100, Bogicevic Sasa wrote:
> This fixes "comparison to NULL could be written..." messages from
> checkpatch.pl script
> 
> Signed-off-by: Bogicevic Sasa 

Where is patch 1/4, 2/4, and 3/4?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] drivers:staging:gdm724x Fix spaces preferred around + -

On Thu, Oct 29, 2015 at 09:19:44PM +0100, Bogicevic Sasa wrote:
> This fixes two spacing coding style violations around - and + signs
> 
> Signed-off-by: Bogicevic Sasa 

Where is patch 1/3 and 2/3?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the arm64 tree with Linus' tree

2015-10-31 Thread Stephen Rothwell

Hi Catalin,

Today's linux-next merge of the arm64 tree got a conflict in:

  arch/arm64/kernel/suspend.c

between commit:

  e13d918a19a7 ("arm64: kernel: fix tcr_el1.t0sz restore on systems with 
extended idmap")

from Linus' tree and commit:

  8e63d3887669 ("arm64: flush: use local TLB and I-cache invalidation")

from the arm64 tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm64/kernel/suspend.c
index 44ca4143b013,3c5e4e6dcf68..
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@@ -80,21 -80,17 +80,21 @@@ int cpu_suspend(unsigned long arg, int 
if (ret == 0) {
/*
 * We are resuming from reset with TTBR0_EL1 set to the
 -   * idmap to enable the MMU; restore the active_mm mappings in
 -   * TTBR0_EL1 unless the active_mm == _mm, in which case
 -   * the thread entered cpu_suspend with TTBR0_EL1 set to
 -   * reserved TTBR0 page tables and should be restored as such.
 +   * idmap to enable the MMU; set the TTBR0 to the reserved
 +   * page tables to prevent speculative TLB allocations, flush
 +   * the local tlb and set the default tcr_el1.t0sz so that
 +   * the TTBR0 address space set-up is properly restored.
 +   * If the current active_mm != _mm we entered cpu_suspend
 +   * with mappings in TTBR0 that must be restored, so we switch
 +   * them back to complete the address space configuration
 +   * restoration before returning.
 */
 -  if (mm == _mm)
 -  cpu_set_reserved_ttbr0();
 -  else
 -  cpu_switch_mm(mm->pgd, mm);
 -
 +  cpu_set_reserved_ttbr0();
-   flush_tlb_all();
+   local_flush_tlb_all();
 +  cpu_set_default_tcr_t0sz();
 +
 +  if (mm != _mm)
 +  cpu_switch_mm(mm->pgd, mm);
  
/*
 * Restore per-cpu offset before any kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the mvebu tree with the arm-soc tree

2015-10-31 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the mvebu tree got a conflict in:

  arch/arm/mach-mvebu/pmsu.c

between commit:

  9d2ea95a599a ("ARM: mvebu: add broken-idle option")

from the arm-soc tree and commit:

  da6ee32a42c0 ("ARM: mvebu: add broken-idle option")

from the mvebu tree.

I fixed it up (looks like 2 version of the same thing (though different)
so I just used the version from the arm-doc tree) and can carry the fix
as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ATTN:

2015-10-31 Thread michael

two million dollars donated to you, contact donor on (michaeldun...@yeah.net) 
via email.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arc: dts - remove default value if CONFIG_ARC_BUILTIN_DTB_NAME is blank

2015-10-31 Thread Alexey Brodkin

As of today default .dtb will be built (and subsequently will be built-in
kernel binary) even if CONFIG_ARC_BUILTIN_DTB_NAME is not set.

But it is possible we're going to use external .dtb and so we don't want to
have .dtb built-in kernel binary.

For example that could be the case with:
 a) U-Boot which loads .dtb in DDR and passes its address to the kernel
 b) OpenWRT which embeds .dtb in existing kernel binary

This change excludes .dtb building if CONFIG_ARC_BUILTIN_DTB_NAME is
blank.

Signed-off-by: Alexey Brodkin 
Cc: Vineet Gupta 
---
 arch/arc/Makefile  | 2 ++
 arch/arc/boot/dts/Makefile | 6 ++
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 8a27a48..b0cb6de 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -94,7 +94,9 @@ head-y:= arch/arc/kernel/head.o
 core-y += arch/arc/
 
 # w/o this dtb won't embed into kernel binary
+ifneq ($(CONFIG_ARC_BUILTIN_DTB_NAME),"")
 core-y += arch/arc/boot/dts/
+endif
 
 core-$(CONFIG_ARC_PLAT_SIM)+= arch/arc/plat-sim/
 core-$(CONFIG_ARC_PLAT_TB10X)  += arch/arc/plat-tb10x/
diff --git a/arch/arc/boot/dts/Makefile b/arch/arc/boot/dts/Makefile
index b0e3f19..4dcab5b 100644
--- a/arch/arc/boot/dts/Makefile
+++ b/arch/arc/boot/dts/Makefile
@@ -1,13 +1,11 @@
 # Built-in dtb
-builtindtb-y   := nsim_700
 
 ifneq ($(CONFIG_ARC_BUILTIN_DTB_NAME),"")
builtindtb-y:= $(patsubst "%",%,$(CONFIG_ARC_BUILTIN_DTB_NAME))
+   obj-y   += $(builtindtb-y).dtb.o
+   targets += $(builtindtb-y).dtb
 endif
 
-obj-y   += $(builtindtb-y).dtb.o
-targets += $(builtindtb-y).dtb
-
 .SECONDARY: $(obj)/$(builtindtb-y).dtb.S
 
 dtbs:  $(addprefix  $(obj)/, $(builtindtb-y).dtb)
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 04/10] x86, amd: add accessor for number of cores per compute unit


On 10/30/2015 02:56 AM, Huang Rui wrote:

Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit. In multiple CPUs, they always have
the same number of cores per compute unit.

In a subsequent patch, we will use this function in fam15h_power
driver.

Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 


This patch will require an Acked-by: from an x86 maintainer.

Thanks,
Guenter


---
  arch/x86/include/asm/processor.h |  1 +
  arch/x86/kernel/cpu/amd.c| 19 +--
  2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 19577dd..831ad682 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -810,6 +810,7 @@ static inline int mpx_disable_management(void)

  extern u16 amd_get_nb_id(int cpu);
  extern u32 amd_get_nodes_per_socket(void);
+extern u32 amd_get_cores_per_cu(void);

  static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
  {
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 4a70fc6..a914b1b 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -27,6 +27,9 @@
   */
  static u32 nodes_per_socket = 1;

+/* cores_per_cu: stores the number of cores per compute unit */
+static u32 cores_per_cu = 1;
+
  static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
  {
u32 gprs[8] = { 0 };
@@ -299,7 +302,6 @@ static int nearby_node(int apicid)
  #ifdef CONFIG_SMP
  static void amd_get_topology(struct cpuinfo_x86 *c)
  {
-   u32 cores_per_cu = 1;
u8 node_id;
int cpu = smp_processor_id();

@@ -314,7 +316,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
/* get compute unit information */
smp_num_siblings = ((ebx >> 8) & 3) + 1;
c->compute_unit_id = ebx & 0xff;
-   cores_per_cu += ((ebx >> 8) & 3);
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
u64 value;

@@ -380,6 +381,13 @@ u32 amd_get_nodes_per_socket(void)
  }
  EXPORT_SYMBOL_GPL(amd_get_nodes_per_socket);

+/* this function returns the number of cores per compute unit */
+u32 amd_get_cores_per_cu(void)
+{
+   return cores_per_cu;
+}
+EXPORT_SYMBOL_GPL(amd_get_cores_per_cu);
+
  static void srat_detect_node(struct cpuinfo_x86 *c)
  {
  #ifdef CONFIG_NUMA
@@ -510,6 +518,13 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)

if (cpu_has(c, X86_FEATURE_MWAITX))
use_mwaitx_delay();
+
+   if (cpu_has_topoext) {
+   u32 cpuid;
+
+   cpuid = cpuid_ebx(0x801e);
+   cores_per_cu += ((cpuid >> 8) & 3);
+   }
  }

  static void early_init_amd(struct cpuinfo_x86 *c)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 03/10] hwmon: (fam15h_power) Add max compute unit accumulated power

On 10/30/2015 02:56 AM, Huang Rui wrote:

This patch adds a member in fam15h_power_data which specifies the
maximum accumulated power in a compute unit.

Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 

Applied to -next.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 02/10] hwmon: (fam15h_power) Enable power1_input on AMD Carrizo

On 10/30/2015 02:56 AM, Huang Rui wrote:

This patch enables power1_input attribute for Carrizo platform.

Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 

Applied to -next.

On a side note, your Cc: list is a bit large. You might want to cut it down a 
bit.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 01/10] hwmon: (fam15h_power) Refactor attributes for dynamically added


On 10/30/2015 02:56 AM, Huang Rui wrote:

Attributes depend on the CPU model the driver gets loaded on.
Therefore, add those attributes dynamically at init time. This is more
flexible to control the different attributes on different platforms.

Suggested-by: Borislav Petkov 
Signed-off-by: Huang Rui 


Applied.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the tip tree with the arm64 tree

2015-10-31 Thread Stephen Rothwell

Hi Catalin,

On Thu, 22 Oct 2015 16:32:01 +0100 Catalin Marinas  
wrote:
>
> On Thu, Oct 22, 2015 at 01:06:03PM +0100, Suzuki K. Poulose wrote:
> > On Thu, Oct 22, 2015 at 01:26:52PM +1100, Stephen Rothwell wrote:  
> > > Today's linux-next merge of the tip tree got a conflict in:
> > > 
> > >   arch/arm64/kernel/cpufeature.c
> > > 
> > > between commit:
> > > 
> > >   da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")
> > > 
> > > from the arm64 tree and commit:
> > > 
> > >   963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before 
> > > enabling ARM64_HAS_SYSREG_GIC_CPUIF")
> > > 
> > > from the tip tree.
> > > 
> > > I fixed it up (I have no idea here, so I just used the arm64 tree version)
> > > and can carry the fix as necessary (no action is required).  
> > 
> > We need the following patch applied to fix the conflict correctly
> > on top of the -next tree.  
> 
> Or, if it's easier, the combined diff resolution for the conflicting
> code:
> 
> 8<
> diff --cc arch/arm64/kernel/cpufeature.c
> index d0d607452e1d,305f30dc9e63..ec552cf9e12d
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> 
> [...]
> 
>   
> + static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities 
> *entry)
> + {
> + bool has_sre;
> + 
>  -if (!has_id_aa64pfr0_feature(entry))
> ++if (!has_cpuid_feature(entry))
> + return false;
> + 
> + has_sre = gic_enable_sre();
> + if (!has_sre)
> + pr_warn_once("%s present but disabled by higher exception 
> level\n",
> +  entry->desc);
> + 
> + return has_sre;
> + }
> + 
>   static const struct arm64_cpu_capabilities arm64_features[] = {
>   {
>   .desc = "GIC system register CPU interface",
>   .capability = ARM64_HAS_SYSREG_GIC_CPUIF,
> - .matches = has_cpuid_feature,
> + .matches = has_useable_gicv3_cpuif,
>  -.field_pos = 24,
>  +.sys_reg = SYS_ID_AA64PFR0_EL1,
>  +.field_pos = ID_AA64PFR0_GIC_SHIFT,
>   .min_field_value = 1,
>   },
>   #ifdef CONFIG_ARM64_PAN

OK, I have updated my merge resolution.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fixed the coding style according to `checkpath.pl'

2015-10-31 Thread Egor Uleyskiy

From: Egor Uleyskiy 

Signed-off-by: Egor Uleyskiy 
---
 drivers/staging/vme/devices/vme_pio2.h  | 87 ++---
 drivers/staging/vme/devices/vme_pio2_cntr.c |  2 +-
 drivers/staging/vme/devices/vme_pio2_core.c | 20 +++
 drivers/staging/vme/devices/vme_pio2_gpio.c | 32 +--
 drivers/staging/vme/devices/vme_user.h  |  2 -
 5 files changed, 68 insertions(+), 75 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_pio2.h 
b/drivers/staging/vme/devices/vme_pio2.h
index d5d94c4..c911952 100644
--- a/drivers/staging/vme/devices/vme_pio2.h
+++ b/drivers/staging/vme/devices/vme_pio2.h
@@ -1,6 +1,8 @@
 #ifndef _VME_PIO2_H_
 #define _VME_PIO2_H_
 
+#include 
+
 #define PIO2_CARDS_MAX 32
 
 #define PIO2_VARIANT_LENGTH5
@@ -48,8 +50,6 @@ static const int PIO2_REGS_INT_MASK[8] = { 
PIO2_REGS_INT_MASK0,
PIO2_REGS_INT_MASK6,
PIO2_REGS_INT_MASK7 };
 
-
-
 #define PIO2_REGS_CTRL 0x18
 #define PIO2_REGS_VME_VECTOR   0x19
 #define PIO2_REGS_CNTR00x20
@@ -63,7 +63,6 @@ static const int PIO2_REGS_INT_MASK[8] = { 
PIO2_REGS_INT_MASK0,
 
 #define PIO2_REGS_ID   0x30
 
-
 /* PIO2_REGS_DATAx (0x0 - 0x3) */
 
 static const int PIO2_CHANNEL_BANK[32] = { 0, 0, 0, 0, 0, 0, 0, 0,
@@ -71,38 +70,38 @@ static const int PIO2_CHANNEL_BANK[32] = { 0, 0, 0, 0, 0, 
0, 0, 0,
2, 2, 2, 2, 2, 2, 2, 2,
3, 3, 3, 3, 3, 3, 3, 3 };
 
-#define PIO2_CHANNEL0_BIT  (1 << 0)
-#define PIO2_CHANNEL1_BIT  (1 << 1)
-#define PIO2_CHANNEL2_BIT  (1 << 2)
-#define PIO2_CHANNEL3_BIT  (1 << 3)
-#define PIO2_CHANNEL4_BIT  (1 << 4)
-#define PIO2_CHANNEL5_BIT  (1 << 5)
-#define PIO2_CHANNEL6_BIT  (1 << 6)
-#define PIO2_CHANNEL7_BIT  (1 << 7)
-#define PIO2_CHANNEL8_BIT  (1 << 0)
-#define PIO2_CHANNEL9_BIT  (1 << 1)
-#define PIO2_CHANNEL10_BIT (1 << 2)
-#define PIO2_CHANNEL11_BIT (1 << 3)
-#define PIO2_CHANNEL12_BIT (1 << 4)
-#define PIO2_CHANNEL13_BIT (1 << 5)
-#define PIO2_CHANNEL14_BIT (1 << 6)
-#define PIO2_CHANNEL15_BIT (1 << 7)
-#define PIO2_CHANNEL16_BIT (1 << 0)
-#define PIO2_CHANNEL17_BIT (1 << 1)
-#define PIO2_CHANNEL18_BIT (1 << 2)
-#define PIO2_CHANNEL19_BIT (1 << 3)
-#define PIO2_CHANNEL20_BIT (1 << 4)
-#define PIO2_CHANNEL21_BIT (1 << 5)
-#define PIO2_CHANNEL22_BIT (1 << 6)
-#define PIO2_CHANNEL23_BIT (1 << 7)
-#define PIO2_CHANNEL24_BIT (1 << 0)
-#define PIO2_CHANNEL25_BIT (1 << 1)
-#define PIO2_CHANNEL26_BIT (1 << 2)
-#define PIO2_CHANNEL27_BIT (1 << 3)
-#define PIO2_CHANNEL28_BIT (1 << 4)
-#define PIO2_CHANNEL29_BIT (1 << 5)
-#define PIO2_CHANNEL30_BIT (1 << 6)
-#define PIO2_CHANNEL31_BIT (1 << 7)
+#define PIO2_CHANNEL0_BIT  BIT(0)
+#define PIO2_CHANNEL1_BIT  BIT(1)
+#define PIO2_CHANNEL2_BIT  BIT(2)
+#define PIO2_CHANNEL3_BIT  BIT(3)
+#define PIO2_CHANNEL4_BIT  BIT(4)
+#define PIO2_CHANNEL5_BIT  BIT(5)
+#define PIO2_CHANNEL6_BIT  BIT(6)
+#define PIO2_CHANNEL7_BIT  BIT(7)
+#define PIO2_CHANNEL8_BIT  BIT(0)
+#define PIO2_CHANNEL9_BIT  BIT(1)
+#define PIO2_CHANNEL10_BIT BIT(2)
+#define PIO2_CHANNEL11_BIT BIT(3)
+#define PIO2_CHANNEL12_BIT BIT(4)
+#define PIO2_CHANNEL13_BIT BIT(5)
+#define PIO2_CHANNEL14_BIT BIT(6)
+#define PIO2_CHANNEL15_BIT BIT(7)
+#define PIO2_CHANNEL16_BIT BIT(0)
+#define PIO2_CHANNEL17_BIT BIT(1)
+#define PIO2_CHANNEL18_BIT BIT(2)
+#define PIO2_CHANNEL19_BIT BIT(3)
+#define PIO2_CHANNEL20_BIT BIT(4)
+#define PIO2_CHANNEL21_BIT BIT(5)
+#define PIO2_CHANNEL22_BIT BIT(6)
+#define PIO2_CHANNEL23_BIT BIT(7)
+#define PIO2_CHANNEL24_BIT BIT(0)
+#define PIO2_CHANNEL25_BIT BIT(1)
+#define PIO2_CHANNEL26_BIT BIT(2)
+#define PIO2_CHANNEL27_BIT BIT(3)
+#define PIO2_CHANNEL28_BIT BIT(4)
+#define PIO2_CHANNEL29_BIT BIT(5)
+#define PIO2_CHANNEL30_BIT BIT(6)
+#define PIO2_CHANNEL31_BIT BIT(7)
 
 static const int PIO2_CHANNEL_BIT[32] = { PIO2_CHANNEL0_BIT, PIO2_CHANNEL1_BIT,
PIO2_CHANNEL2_BIT, PIO2_CHANNEL3_BIT,
@@ -123,12 +122,12 @@ static const int PIO2_CHANNEL_BIT[32] = { 
PIO2_CHANNEL0_BIT, PIO2_CHANNEL1_BIT,
};
 
 /*

[PATCH] drivers:staging:gdm72xx Fix increment in a loop

This fixes increment of pos int to be more readable
Lines   qcb->csr[index].srcport_lo = ((buf[pos++]<<8)&0xff00);
qcb->csr[index].srcport_lo += buf[pos++];
become
qcb->csr[index].srcport_lo = get_unaligned_le16([pos]);
pos += 2;

Signed-off-by: Bogicevic Sasa 
---
 drivers/staging/gdm72xx/gdm_qos.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
b/drivers/staging/gdm72xx/gdm_qos.c
index 44d04bd..132789c 100644
--- a/drivers/staging/gdm72xx/gdm_qos.c
+++ b/drivers/staging/gdm72xx/gdm_qos.c
@@ -406,14 +406,14 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
size)
qcb->csr[index].ipdst_addr[1] = buf[pos++];
qcb->csr[index].ipdst_addr[2] = buf[pos++];
qcb->csr[index].ipdst_addr[3] = buf[pos++];
-   qcb->csr[index].srcport_lo = ((buf[pos++] << 8) & 0xff00);
-   qcb->csr[index].srcport_lo += buf[pos++];
-   qcb->csr[index].srcport_hi = ((buf[pos++] << 8) & 0xff00);
-   qcb->csr[index].srcport_hi += buf[pos++];
-   qcb->csr[index].dstport_lo = ((buf[pos++] << 8) & 0xff00);
-   qcb->csr[index].dstport_lo += buf[pos++];
-   qcb->csr[index].dstport_hi = ((buf[pos++] << 8) & 0xff00);
-   qcb->csr[index].dstport_hi += buf[pos++];
+   qcb->csr[index].srcport_lo = get_unaligned_le16([pos]);
+   pos += 2;
+   qcb->csr[index].srcport_hi = get_unaligned_le16([pos]);
+   pos += 2;
+   qcb->csr[index].dstport_lo = get_unaligned_le16([pos]);
+   pos += 2;
+   qcb->csr[index].dstport_hi = get_unaligned_le16([pos]);
+   pos += 2;
 
qcb->qos_limit_size = 254 / qcb->qos_list_cnt;
spin_unlock_irqrestore(>qos_lock, flags);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v5 5/7] PCI: irqdomain: Look up IRQ domain by fwnode_handle

2015-10-31 Thread Jake Oshins

> -Original Message-
> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> Sent: Friday, October 30, 2015 2:44 PM
> To: Jake Oshins 
> Cc: Greg Kroah-Hartman ; KY Srinivasan
> ; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; Robo Bot
> ; Vitaly Kuznetsov ;
> t...@redhat.com; Haiyang Zhang ;
> marc.zyng...@arm.com; Bjorn Helgaas ; linux-
> p...@vger.kernel.org
> Subject: Re: [PATCH v5 5/7] PCI: irqdomain: Look up IRQ domain by
> fwnode_handle
> 
> On Fri, Oct 30, 2015 at 11:11 PM,   wrote:
> > From: Jake Oshins 
> >
> > This patch adds a second way of finding an IRQ domain associated with
> > a root PCI bus.  After looking to see if one can be found through
> > the OF tree, it attempts to look up the IRQ domain through an
> > fwnode_handle stored in the pci_sysdata struct.
> >
> > Signed-off-by: Jake Oshins 
> > ---
> >  arch/x86/include/asm/pci.h |  4 +++-
> >  drivers/pci/probe.c| 11 +++
> >  include/asm-generic/pci.h  |  4 
> >  3 files changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> > index 10213a1..fb74453 100644
> > --- a/arch/x86/include/asm/pci.h
> > +++ b/arch/x86/include/asm/pci.h
> > @@ -45,11 +45,13 @@ static inline int pci_proc_domain(struct pci_bus
> *bus)
> >  #endif
> >
> >  #ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
> > -static inline void *pci_fwnode(struct pci_bus *bus)
> > +static inline void *_pci_root_bus_fwnode(struct pci_bus *bus)
> 
> I'm sorry what is the point to rename?
> 

I renamed it only because Gerry asked me to rename it.  And then I regenerated 
the patch series with that rename still in the queue, which was a mistake.  The 
whole thing is introduced in the previous patch.  pci_fwnode() doesn't exist 
without this patch series.  I'll straighten that out.


> >  {
> > struct pci_sysdata *sd = bus->sysdata;
> > return sd->fwnode;
> >  }
> > +
> > +#define pci_root_bus_fwnode_pci_root_bus_fwnode
> >  #endif
> >
> >  /* Can be used to override the logic in pci_scan_bus for skipping
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index f441d1b..60e50a8 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -671,6 +671,17 @@ static struct irq_domain
> *pci_host_bridge_msi_domain(struct pci_bus *bus)
> >  */
> > d = pci_host_bridge_of_msi_domain(bus);
> >
> > +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
> > +   /*
> > +* If no IRQ domain was found via the OF tree, try looking it up
> > +* directly through the fwnode_handle.
> > +*/
> > +   if (!d && pci_root_bus_fwnode(bus)) {
> > +   d = irq_find_matching_fwnode(pci_root_bus_fwnode(bus),
> > +DOMAIN_BUS_PCI_MSI);
> 
> Gave a second glance and now noticed that you call
> pci_root_bus_fwnode() twice. So, it actually might be more readable
> like your first but modified variant:
> 
> if (!d) {
>   void *fwnode = pci_fwnode(bus);
> 
>   if (fwnode)
> d = irq_find_matching_fwnode(fwnode, DOMAIN_BUS_PCI_MSI);
> }
> 
> > +   }
> > +#endif
> > +
> > return d;
> >  }
> 
> 
> With Best Regards,
> Andy Shevchenko

Sure.  No problem.  I'll resend.

-- Jake

Re: timer code oops when calling mod_delayed_work

2015-10-31 Thread Jeff Layton

On Sat, 31 Oct 2015 17:31:07 -0400
Tejun Heo  wrote:

> Hello, Jeff.
> 
> On Sat, Oct 31, 2015 at 07:34:00AM -0400, Jeff Layton wrote:
> > > Heh, this one is tricky.  Yeah, try_to_grab_pending() missing PENDING
> > > would explain the failure but I can't see how it'd leak at the moment.
> > 
> > Thanks Tejun. Yeah, I realized that after sending the response above.
> > 
> > If you successfully delete the timer the timer then the PENDING bit
> > should already be set. Might be worth throwing in something like this,
> > just before the return 1:
> > 
> > WARN_ON(!test_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work)))
> >
> > ...but I doubt it would fire. I think it's likely that the bug is
> > elsewhere.
> 
> I doubt that'd trigger either but it'd still be a good idea to throw
> that in just in case.
> 
> > The other thing is that we've had this code in place for a couple of
> > years now, and this is the first time I've seen an oops like this. I
> > suspect that this may be a recent regression, but I don't know that for
> > sure.
> 
> I can't think of any recent changes which could affect this.  This
> part of code has remained unchanged for years at least from the
> workqueue side.
> 
> > I have asked Chris and Michael to see if they can bisect it down, but
> > it may be a bit before they can get that done. Any insight you might
> > have in the meantime would helpful.
> 
> Yeah, I'd love to find out how reproducible the issue is.  If the
> problem is rarely reproducible, it might make sense to try
> instrumentation before trying bisection as it *could* be a latent bug
> which has been there all along and bisecting to the commit introducing
> the code wouldn't help us too much.
> 

It seems fairly reproducible, at least on v4.3-rc7 kernels:

This came about when I asked them to perf test some nfsd patches that I
have queued up. I patched a Fedora 4.3-rc7 kernel and wanted to see
what the perf delta was (with NFSv3, fwiw):

Patched kernels here: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=11598089

Unpatched kernels here: 
http://koji.fedoraproject.org/koji/buildinfo?buildID=694377

Michael was using the SPEC SFS VDI workload to test, and was able to
get the same panic on both kernels. So it does seem to be reproducible.
It might even be possible to tune the VM to make the shrinker fire more
often, which may help tickle this more.

In any case, I've asked them to try something v4.2-ish and see if it's
reproducible there, and then try v4.1 if it is. I figure anything
earlier is probably not worth testing if it still fails on v4.1. If it
turns out not to be reproducible on those earlier kernels then we can
bisect from there to track it down.

Thanks again!
-- 
Jeff Layton 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

2015-10-31 Thread Christian König


On 31.10.2015 21:13, Pavel Machek wrote:

Hi!

4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But
my monitor is native 1920x1080, so that mode looks pretty ugly on
screen. If I go to 1920x1080, I see colored horizontal lines (often
black) as soon as there's graphics activity.

pavel@half:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
axis) 478mm x 268mm
1920x1080 60.00*+
   1600x1200 60.00
  1680x1050 59.95
1280x1024 75.0260.02
   1440x900  59.89
  1024x768  75.0860.00
 800x600   75.0060.32
640x480   75.0060.00
   720x400   70.08
  pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
  pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
  pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200


This is Acer notebook,

01:00.0 VGA compatible controller: Advanced Micro Devices,
Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]

Ouch, and power consumption seems to be 8W too high. (25W instead of
17W), I believe it started when I added radeon firmware, but will
check. It does not go lower even when I switch to text console.

Any ideas?


Alex probably knows more about this, but it sounds like problems with 
switching the memory clocks on 3D load.


Try to disable power management completely with radeon.dpm=0 on the 
kernel command line or nailing the hardware at a specific power level 
using sysfs.


Power consumption would be totally awkward, but it should help nailing 
down the problem.


Regards,
Christian.



Pavel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Andy Shevchenko  writes:

 +   nb8800_writel(priv, NB8800_MDIO_CMD, val | MDIO_CMD_GO);
 +
 +   if (!nb8800_mdio_wait(bus))
 +   return -ETIMEDOUT;
 +
 +   val = nb8800_readl(priv, NB8800_MDIO_STS);
 +   if (val & MDIO_STS_ERR)
 +   return 0x;
>>>
>>> Can we return an error here?
>>
>> That breaks the bus scanning in phylib.
>
> You mean this is non-fatal error?

It's what you get if nothing responded to the address.

 +
 +   rx_buf = >rx_bufs[next];
 +   rx = >rx_descs[next];
>>>
 +   report = rx->report;
>>>
>>> Maybe you can use rx->report directly below.
>>
>> It's in uncached memory, so didn't want to have gcc accidentally doing
>> more reads than necessary.
>
> How it would not be possible without ACCESS_ONCE() or similar?

True, it probably doesn't make a difference.  Sometimes copying a value
to a local variable prevents re-reads due to potential pointer aliasing,
but I don't think that's an issue here.

 +static int nb8800_xmit(struct sk_buff *skb, struct net_device *dev)
 +{
 +   struct nb8800_priv *priv = netdev_priv(dev);
 +   struct tx_skb_data *skb_data;
 +   struct tx_buf *tx_buf;
 +   dma_addr_t dma_addr;
 +   unsigned int dma_len;
 +   int cpsz, next;
 +   int frags;
 +
 +   if (atomic_read(>tx_free) <= NB8800_DESC_LOW) {
 +   netif_stop_queue(dev);
 +   return NETDEV_TX_BUSY;
 +   }
 +
 +   cpsz = (8 - (uintptr_t)skb->data) & 7;
>>>
>>> So, cast to uintptr_t looks strange in this driver, since used only
>>> twice in such expression, why not to use plain unsigned int * ?
>>
>> Because it's not the same thing.  uintptr_t is an integer type the same
>> size as a pointer.  I need to check if the data pointer is 8-byte
>> aligned as required by the DMA.
>
> Yes, I understand why you're doing this. But since you use lowest
> bits, I think result will be the same even without casting.

You can't do that kind of arithmetic on pointer values.  They have to be
cast to an integer type first.

 +   nb8800_writeb(priv, NB8800_RANDOM_SEED, 0x08);
 +
 +   /* TX single deferral params */
 +   nb8800_writeb(priv, NB8800_TX_SDP, 0xc);
 +
 +   /* Threshold for partial full */
 +   nb8800_writeb(priv, NB8800_PF_THRESHOLD, 0xff);
 +
 +   /* Pause Quanta */
 +   nb8800_writeb(priv, NB8800_PQ1, 0xff);
 +   nb8800_writeb(priv, NB8800_PQ2, 0xff);
>>>
>>> Lot of magic numbers above and below.
>>
>> Those are from the original driver.  Some of them disagree with the
>> documentation, and the "correct" values don't work.
>
> It would be nice to somehow describe them if possible.

I'll see what I can do.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: timer code oops when calling mod_delayed_work

2015-10-31 Thread Tejun Heo

Hello, Jeff.

On Sat, Oct 31, 2015 at 07:34:00AM -0400, Jeff Layton wrote:
> > Heh, this one is tricky.  Yeah, try_to_grab_pending() missing PENDING
> > would explain the failure but I can't see how it'd leak at the moment.
> 
> Thanks Tejun. Yeah, I realized that after sending the response above.
> 
> If you successfully delete the timer the timer then the PENDING bit
> should already be set. Might be worth throwing in something like this,
> just before the return 1:
> 
> WARN_ON(!test_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work)))
>
> ...but I doubt it would fire. I think it's likely that the bug is
> elsewhere.

I doubt that'd trigger either but it'd still be a good idea to throw
that in just in case.

> The other thing is that we've had this code in place for a couple of
> years now, and this is the first time I've seen an oops like this. I
> suspect that this may be a recent regression, but I don't know that for
> sure.

I can't think of any recent changes which could affect this.  This
part of code has remained unchanged for years at least from the
workqueue side.

> I have asked Chris and Michael to see if they can bisect it down, but
> it may be a bit before they can get that done. Any insight you might
> have in the meantime would helpful.

Yeah, I'd love to find out how reproducible the issue is.  If the
problem is rarely reproducible, it might make sense to try
instrumentation before trying bisection as it *could* be a latent bug
which has been there all along and bisecting to the commit introducing
the code wouldn't help us too much.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

2015-10-31 Thread Pavel Machek

Hi!

> >4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But
> >my monitor is native 1920x1080, so that mode looks pretty ugly on
> >screen. If I go to 1920x1080, I see colored horizontal lines (often
> >black) as soon as there's graphics activity.
> >
> >pavel@half:~$ xrandr
> >Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
> >VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
> >axis) 478mm x 268mm
> >1920x1080 60.00*+
> >   1600x1200 60.00
> >  1680x1050 59.95
> > 1280x1024 75.0260.02
> >1440x900  59.89
> >   1024x768  75.0860.00
> >  800x600   75.0060.32
> > 640x480   75.0060.00
> >720x400   70.08
> >  pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
> >  pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
> >  pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
> > 
> >
> >This is Acer notebook,
> >
> >01:00.0 VGA compatible controller: Advanced Micro Devices,
> >Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]

> >Any ideas?
> 
> Alex probably knows more about this, but it sounds like problems with
> switching the memory clocks on 3D load.

> Try to disable power management completely with radeon.dpm=0 on the kernel
> command line or nailing the hardware at a specific power level using
> sysfs.

I tried that, but it still flickers.

pavel@half:~/misc/fgfs$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0

> Power consumption would be totally awkward, but it should help nailing down
> the problem.

It seems chromium makes the flicker way worse.. even when running on
different virtual desktop. I'm not sure which sysfs settings I should
tweak (or if I should be tweaking them with .dpm=0). But sysfs says:
pavel@half:/sys/bus/pci/drivers/radeon/:01:00.0$ ls
backlight drm
irq
resource
boot_vga  enable local_cpulist  resource0
broken_parity_statusfirmware_node  local_cpus   resource0_wc
class graphics
modalias  resource1
config
 i2c-0   msi_busresource2
 consistent_dma_mask_bits  i2c-1 power  rom
 d3cold_allowedi2c-2
 power_method  subsystem
 device
 i2c-3   power_profile  subsystem_device
 dma_mask_bitsi2c-4  remove
 subsystem_vendor
 driver   i2c-5  rescan uevent
 driver_override   i2c-6 reset
 vendor
 pavel@half:/sys/bus/pci/drivers/radeon/:01:00.0$ grep . *
 grep: backlight: Is a directory
 boot_vga:1
 broken_parity_status:0
 class:0x03
 Binary file config matches
 consistent_dma_mask_bits:40
 d3cold_allowed:1
 device:0x9553
 dma_mask_bits:40
 grep: driver: Is a directory
 driver_override:(null)
 grep: drm: Is a directory
 enable:1
 grep: firmware_node: Is a directory
 grep: graphics: Is a directory
 grep: i2c-0: Is a directory
 grep: i2c-1: Is a directory
 grep: i2c-2: Is a directory
 grep: i2c-3: Is a directory
 grep: i2c-4: Is a directory
 grep: i2c-5: Is a directory
 grep: i2c-6: Is a directory
 irq:16
 local_cpulist:0-3
 local_cpus:f
 modalias:pci:v1002d9553sv1025sd0212bc03sc00i00
 msi_bus:1
 grep: power: Is a directory
 power_method:profile
 power_profile:default
 grep: remove: Permission denied
 grep: rescan: Permission denied
 grep: reset: Permission denied
 resource:0xc000 0xcfff 0x00042208
 resource:0x5000 0x50ff 0x00040101
 resource:0xd620 0xd620 0x00040200
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0xd622 0xd623 0x00046202
 grep: resource0: Permission denied
 grep: resource0_wc: Permission denied
 grep: resource1: Permission denied
 grep: resource2: Permission denied
 grep: rom: Permission denied
 grep: subsystem: Is a directory
 subsystem_device:0x0212
 subsystem_vendor:0x1025
 uevent:DRIVER=radeon
 uevent:PCI_CLASS=3
 uevent:PCI_ID=1002:9553
 uevent:PCI_SUBSYS_ID=1025:0212
 uevent:PCI_SLOT_NAME=:01:00.0
 uevent:MODALIAS=pci:v1002d9553sv1025sd0212bc03sc00i00
 vendor:0x1002

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line

Re: [PATCH] pinctrl: zynq: fix UTF-8 errors

On Fri, Oct 30, 2015 at 6:07 PM, Sören Brinkmann
 wrote:
> On Fri, 2015-10-30 at 10:03AM -0700, Sören Brinkmann wrote:
>> Hi Linux,
>
> Linus, of course...

After screwing up your name like that I kind of deserve it...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] gpio: ath79: Make the driver removable

On Fri, Oct 30, 2015 at 11:36 AM, Alban Bedel  wrote:

> As we now allow the driver to be built as a module it should be
> removable.
>
> Signed-off-by: Alban Bedel 

Looks good but needs rebasing on top of the rebased 2/3.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] gpio: ath79: Move to the generic GPIO driver

On Fri, Oct 30, 2015 at 11:36 AM, Alban Bedel  wrote:

> Turn the ath79 driver into a true driver supporting multiple
> instances while dropping most of the code in favor of the generic
> MMIO GPIO driver.
>
> As the driver now depend on CONFIG_GPIO_GENERIC also add a Kconfig
> entry to make the driver optional.
>
> Signed-off-by: Alban Bedel 

This patch looks nice but sadly does not apply to my "devel" branch in
the GPIO tree:
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel

Please rebase it on this branch or wait until after the merge window.

> +config GPIO_ATH79
> +   tristate "Atheros AR71XX/AR724X/AR913X GPIO support"
> +   default y if ATH79
> +   depends on ATH79 || COMPILE_TEST

I think the build robot is complaining because of COMPILE_TEST. This
driver doesn't really compile on anything else than ATH79 does it?
Noone else has asm/mach-ath79/ar71xx_regs.h

So I suggest dropping the compile test until this is fixed (e.g. by moving
the GPIO register offsets into the driver, what do I know).

> +   select GPIO_GENERIC

This is very very nice.

And works out nice, as we can see.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] MAINTAINERS: Add an entry for the ATH79 GPIO driver

On Fri, Oct 30, 2015 at 11:36 AM, Alban Bedel  wrote:

> Add an entry for the ATH79 GPIO driver with myself as maintainer.
>
> Signed-off-by: Alban Bedel 

Applied, but:

> +M: "Alban Bedel "

I unquoted that. I didn't see anyone quote all including the mail
address before.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 00/61] PCI: Resource allocation cleanup for v4.4

2015-10-31 Thread Benjamin Herrenschmidt

On Sat, 2015-10-31 at 14:51 -0400, David Miller wrote:
> This is the way OF seems to work.
> 
> It maps all of the ROMs essentially to the same address range, but
> only enables one at a time as it inspects the ROMs and builds the
> device tree during power-on.
> 
> Then it makes sure all of them are disabled, and can therefore use
> some of that address range for mapping other BARs.
> 
> So if ROMs are disabled, you cannot put the address of such ROMs BAR
> in the kernel's assigned PCI address resource list.
> 
> I hope that is what you are doing?

I've seen that sort of stuff on x86 as well. Possibly on POWER, I don't
remember for sure.

I've also seen the VBIOS  of some cards manually remap the ROM BAR to
cover BAR 0, extract stuff from it, then disable it.

I think the ROM BAR must be treated as "special". It should probably
done in a separate pass from all the other BARs of all the other
adapters to be honest, and remapped if there's any conflict.

Cheers,
Ben

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/11] Input: synaptics-rmi4: various fixes for the existing rmi4 branch

On Thu, Jul 23, 2015 at 7:10 PM, Benjamin Tissoires
 wrote:

> Dmitry, the Sony guys are currently working on upstreaming their work.
> Their Xperia are using a Synaptics I2C touchscreen. They are able to
> boot with an upstream kernel a lot of parts now, and they will
> eventually need the upstream touch controller.

I have a Synaptics touchscreen thing since 2010 waiting in
drivers/staging/ste_rmi4.

Is there *anything* I can do to help further this?

It just seems like a massive body of code that doesn't get the
right love, Benjamin have you considered just merging this into
drivers/staging so it is simple for everyone to participate, or are there
infrastructural blockers?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

2015-10-31 Thread Pavel Machek

Hi!

4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But
my monitor is native 1920x1080, so that mode looks pretty ugly on
screen. If I go to 1920x1080, I see colored horizontal lines (often
black) as soon as there's graphics activity.

pavel@half:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
axis) 478mm x 268mm
   1920x1080 60.00*+
  1600x1200 60.00
 1680x1050 59.95
1280x1024 75.0260.02
   1440x900  59.89
  1024x768  75.0860.00
 800x600   75.0060.32
640x480   75.0060.00
   720x400   70.08
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
 pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
   

This is Acer notebook,

01:00.0 VGA compatible controller: Advanced Micro Devices,
Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]

Ouch, and power consumption seems to be 8W too high. (25W instead of
17W), I believe it started when I added radeon firmware, but will
check. It does not go lower even when I switch to text console.

Any ideas?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

2015-10-31 Thread Andy Shevchenko

On Sat, Oct 31, 2015 at 8:41 PM, Måns Rullgård  wrote:
> Andy Shevchenko  writes:
>
>>> +static int nb8800_mdio_read(struct mii_bus *bus, int phy_id, int reg)
>>> +{
>>> +   struct nb8800_priv *priv = bus->priv;
>>> +   int val;
>>> +
>>> +   if (!nb8800_mdio_wait(bus))
>>> +   return -ETIMEDOUT;
>>> +
>>> +   val = MIIAR_ADDR(phy_id) | MIIAR_REG(reg);
>>> +
>>> +   nb8800_writel(priv, NB8800_MDIO_CMD, val);
>>> +   udelay(10);
>>
>> Why 10? Perhaps add a comment line.
>
> Because it works.  The documentation doesn't mention a delay, but it
> works unreliably without one.

/* Put delay here, otherwise it works unreliably */

>
>>> +   nb8800_writel(priv, NB8800_MDIO_CMD, val | MDIO_CMD_GO);
>>> +
>>> +   if (!nb8800_mdio_wait(bus))
>>> +   return -ETIMEDOUT;
>>> +
>>> +   val = nb8800_readl(priv, NB8800_MDIO_STS);
>>> +   if (val & MDIO_STS_ERR)
>>> +   return 0x;
>>
>> Can we return an error here?
>
> That breaks the bus scanning in phylib.

You mean this is non-fatal error?

>>> +static int nb8800_poll(struct napi_struct *napi, int budget)
>>> +{
>>> +   struct net_device *dev = napi->dev;
>>> +   struct nb8800_priv *priv = netdev_priv(dev);
>>> +   struct nb8800_dma_desc *rx;
>>> +   int work = 0;
>>> +   int last = priv->rx_eoc;
>>> +   int next;
>>> +
>>> +   while (work < budget) {
>>> +   struct rx_buf *rx_buf;
>>> +   u32 report;
>>> +   int len;
>>> +
>>> +   next = (last + 1) & (RX_DESC_COUNT - 1);
>>
>> Maybe (last + 1) % RX_DESC_COUNT ? It will not prevent to use
>> non-power-of-two numbers.
>
> We don't want to be doing divisions anyway, but I can certainly change
> it to % if that's preferred.

I'm pretty sure the result for power-of-two numbers will be the
similar (right shift).

>
>>> +
>>> +   rx_buf = >rx_bufs[next];
>>> +   rx = >rx_descs[next];
>>
>>> +   report = rx->report;
>>
>> Maybe you can use rx->report directly below.
>
> It's in uncached memory, so didn't want to have gcc accidentally doing
> more reads than necessary.

How it would not be possible without ACCESS_ONCE() or similar?

>
>>> +static int nb8800_xmit(struct sk_buff *skb, struct net_device *dev)
>>> +{
>>> +   struct nb8800_priv *priv = netdev_priv(dev);
>>> +   struct tx_skb_data *skb_data;
>>> +   struct tx_buf *tx_buf;
>>> +   dma_addr_t dma_addr;
>>> +   unsigned int dma_len;
>>> +   int cpsz, next;
>>> +   int frags;
>>> +
>>> +   if (atomic_read(>tx_free) <= NB8800_DESC_LOW) {
>>> +   netif_stop_queue(dev);
>>> +   return NETDEV_TX_BUSY;
>>> +   }
>>> +
>>> +   cpsz = (8 - (uintptr_t)skb->data) & 7;
>>
>> So, cast to uintptr_t looks strange in this driver, since used only
>> twice in such expression, why not to use plain unsigned int * ?
>
> Because it's not the same thing.  uintptr_t is an integer type the same
> size as a pointer.  I need to check if the data pointer is 8-byte
> aligned as required by the DMA.

Yes, I understand why you're doing this. But since you use lowest
bits, I think result will be the same even without casting.

>>> +   nb8800_writeb(priv, NB8800_RANDOM_SEED, 0x08);
>>> +
>>> +   /* TX single deferral params */
>>> +   nb8800_writeb(priv, NB8800_TX_SDP, 0xc);
>>> +
>>> +   /* Threshold for partial full */
>>> +   nb8800_writeb(priv, NB8800_PF_THRESHOLD, 0xff);
>>> +
>>> +   /* Pause Quanta */
>>> +   nb8800_writeb(priv, NB8800_PQ1, 0xff);
>>> +   nb8800_writeb(priv, NB8800_PQ2, 0xff);
>>
>> Lot of magic numbers above and below.
>
> Those are from the original driver.  Some of them disagree with the
> documentation, and the "correct" values don't work.

It would be nice to somehow describe them if possible.

>>> +static int nb8800_probe(struct platform_device *pdev)
>>> +{
>>> +   const struct of_device_id *match;
>>> +   const struct nb8800_ops *ops = NULL;
>>> +   struct nb8800_priv *priv;
>>> +   struct resource *res;
>>> +   struct net_device *dev;
>>> +   struct mii_bus *bus;
>>> +   const unsigned char *mac;
>>> +   void __iomem *base;
>>> +   int irq;
>>> +   int ret;
>>> +
>>> +   match = of_match_device(nb8800_dt_ids, >dev);
>>> +   if (match)
>>> +   ops = match->data;
>>> +
>>> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +   if (!res) {
>>> +   dev_err(>dev, "No MMIO base\n");
>>> +   return -EINVAL;
>>> +   }
>>
>> Move platform_get_resource() just before devm_ioremap_resource() and
>> remove redundant condition with the message.
>>
>>> +   bus = devm_mdiobus_alloc(>dev);
>>> +   if (!bus) {
>>> +   ret = -ENOMEM;
>>> +   goto err_disable_clk;
>>> +   }
>>> +
>>> +   bus->name = "nb8800-mii";
>>> +   bus->read = nb8800_mdio_read;
>>> +

Re: [PATCH 0/3] KVM: x86: simplify RSM into 64-bit protected mode

2015-10-31 Thread Laszlo Ersek

On 10/30/15 16:36, Radim Krčmář wrote:
> This series bases on "KVM: x86: fix RSM into 64-bit protected mode,
> round 2" and reverts it in [3/3].  To avoid regressions after doing so,
> [1/2] introduces a helper that is used in [2/2] to hopefully get the
> same behavior.
> 
> I'll set up test environment next week, unless a random act of kindness
> allows me not to.
> 
> 
> Radim Krčmář (3):
>   KVM: x86: add read_phys to x86_emulate_ops
>   KVM: x86: handle SMBASE as physical address in RSM
>   KVM: x86: simplify RSM into 64-bit protected mode
> 
>  arch/x86/include/asm/kvm_emulate.h | 10 +
>  arch/x86/kvm/emulate.c | 44 
> +-
>  arch/x86/kvm/x86.c | 10 +
>  3 files changed, 30 insertions(+), 34 deletions(-)
> 

Tested-by: Laszlo Ersek 

Thanks, Radim.
Laszlo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH ] Fix perf_install build when a separate output directory (O=) is used

2015-10-31 Thread Martin Habets

Before this patch
 make tools/perf_install
would fail as it was wrongly trying to check for directory
 $(O)/tools/perf/tools/perf/

As the original patch states, the perf build does not follow the descend
function setup, so it needs invoking it via it's own make rule.
This is also true for the install build target of perf.

Fixes: 16671c1 ("tools build: Fix Makefile(s) to properly invoke tools build")
Signed-off-by: Martin Habets 
---
 tools/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index d6f307d..6f88a13 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -77,13 +77,16 @@ tmon: FORCE
 freefall: FORCE
$(call descend,laptop/$@)
 
+perf_install: FORCE
+   $(Q)$(MAKE) --no-print-directory -C perf O=$(PERF_O) subdir= install
+
 acpi_install:
$(call descend,power/$(@:_install=),install)
 
 cpupower_install:
$(call descend,power/$(@:_install=),install)
 
-cgroup_install firewire_install hv_install lguest_install perf_install 
usb_install virtio_install vm_install net_install:
+cgroup_install firewire_install hv_install lguest_install usb_install 
virtio_install vm_install net_install:
$(call descend,$(@:_install=),install)
 
 selftests_install:
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipc/msg: Implement lockless pipelined wakeups

2015-10-31 Thread Davidlohr Bueso


On Sat, 31 Oct 2015, Bueso wrote:


Yes, and this confirms that we still rely on the implicit barrier
from the cmpxchg as tglx mentioned. As such, we also need to keep
the pairing when reading 'r_msg' in do_msgrcv(), instead of dropping
the comments.


Hmm having r_msg as volatile seems even less needed now, we should
drop it. I imagine it was there initially for the busy-wait on the variable
becoming non-nil, but we had cpu_relax _anyway_, so ...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] bpf: convert hashtab lock to raw lock

2015-10-31 Thread Daniel Borkmann


On 10/31/2015 02:47 PM, Steven Rostedt wrote:

On Fri, 30 Oct 2015 17:03:58 -0700
Alexei Starovoitov  wrote:

On Fri, Oct 30, 2015 at 03:16:26PM -0700, Yang Shi wrote:

When running bpf samples on rt kernel, it reports the below warning:

BUG: sleeping function called from invalid context at 
kernel/locking/rtmutex.c:917
in_atomic(): 1, irqs_disabled(): 128, pid: 477, name: ping
Preemption disabled at:[] kprobe_perf_func+0x30/0x228

...

diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 83c209d..972b76b 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -17,7 +17,7 @@
  struct bpf_htab {
struct bpf_map map;
struct hlist_head *buckets;
-   spinlock_t lock;
+   raw_spinlock_t lock;


How do we address such things in general?
I bet there are tons of places around the kernel that
call spin_lock from atomic.
I'd hate to lose the benefits of lockdep of non-raw spin_lock
just to make rt happy.


You wont lose any benefits of lockdep. Lockdep still checks
raw_spin_lock(). The only difference between raw_spin_lock and
spin_lock is that in -rt spin_lock turns into an rt_mutex() and
raw_spin_lock stays a spin lock.


( Btw, Yang, would have been nice if your commit description would have
  already included such info, not only that you convert it, but also why
  it's okay to do so. )


The error is that in -rt, you called a mutex and not a spin lock while
atomic.


You are right, I think this happens due to the preempt_disable() in the
trace_call_bpf() handler. So, I think the patch seems okay. The dep_map
is btw union'ed in the struct spinlock case to the same offset of the
dep_map from raw_spinlock.

It's a bit inconvenient, though, when we add other library code as maps
in future, f.e. things like rhashtable as they would first need to be
converted to raw_spinlock_t as well, but judging from the git log, it
looks like common practice.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sched: Update task->on_rq when tasks are moving between runqueues

2015-10-31 Thread Peter Zijlstra

On Wed, Oct 28, 2015 at 05:57:10PM -0700, Olav Haugan wrote:
> On 15-10-25 11:09:24, Peter Zijlstra wrote:
> > On Sat, Oct 24, 2015 at 11:01:02AM -0700, Olav Haugan wrote:
> > > Task->on_rq has three states:
> > >   0 - Task is not on runqueue (rq)
> > >   1 (TASK_ON_RQ_QUEUED) - Task is on rq
> > >   2 (TASK_ON_RQ_MIGRATING) - Task is on rq but in the process of being
> > >   migrated to another rq
> > > 
> > > When a task is moving between rqs task->on_rq state should be
> > > TASK_ON_RQ_MIGRATING
> > 
> > Only when not holding both rq locks..
> 
> IMHO I think we should keep the state of p->on_rq updated with the correct 
> state
> all the time unless I am incorrect in what p->on_rq represent. The task
> is moving between rq's and is on the rq so the state should be
> TASK_ON_RQ_MIGRATING right? I do realize that the code is currently not
> broken. However, in the future someone might come along and change
> set_task_cpu() and the code change might rely on an accurate p->on_rq value. 
> It
> would be good design to keep this value correct.

At the same time; we should also provide lean and fast code. Is it
better to add assertions about required state than to add superfluous
code for just in case scenarios.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipc/msg: Implement lockless pipelined wakeups

2015-10-31 Thread Davidlohr Bueso


On Sat, 31 Oct 2015, George Spelvin wrote:


Don't we need to keep that NULL init? I might be missing something.


I wondered the same thing, but on reading it, the cleanup is that he's
gotten rid of the need for the entire thing.  Previously, there was a
mechanism for detecting "wakeup not quite finished" that used a NULL
value, but it's no longer needed.

The resultant busy-waiting on the part of the woken-up task was the
entire problem this patch aims to fix.  So it gets rid of a whole lot
of code and barriers.  And, as you noticed, the comments explaining them.

As the old code explained, the issue is that a task may exit as
soon as r_msg is set, so the wakeup procedure has to be:
- Ensure r_msg is set to NULL (special-case flag)
- Do the wake up
- Set r_msg to the final value

The woken-up task has to spin as long as r_msg is NULL.  Ick.


I agree this is a nice cleanup. It is similar to what we did
with posix mqueues, but this one gets rid of even more code afaict.


However, a wake_q keeps a reference to a task, so exiting is
not a danger.  As long as wake_q_add precedes setting r_msg,
all is well.


Yes, and this confirms that we still rely on the implicit barrier
from the cmpxchg as tglx mentioned. As such, we also need to keep
the pairing when reading 'r_msg' in do_msgrcv(), instead of dropping
the comments.

Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 00/61] PCI: Resource allocation cleanup for v4.4

2015-10-31 Thread David Miller

From: Yinghai Lu 
Date: Fri, 30 Oct 2015 18:53:23 -0700

> On Fri, Oct 30, 2015 at 2:47 PM, Khalid Aziz  wrote:
>>
>> I applied patches 1-8 and 11-16 to 4.3.0-rc7 to test on sparc platforms. I
>> am seeing a "can't claim BAR" message on a T4:
>>
>> pci :04:00.0: can't claim BAR 6 [mem 0x840-0x840]:
>> address conflict with :04:00.0 [mem 0x840-0x840007f]
> 
> PCI: scan_bus[/pci@400/pci@1/pci@0/pci@0/pci@0] bus no 4
>   * /pci@400/pci@1/pci@0/pci@0/pci@0/display@0
> create device, devfn: 0, type: display
> class: 0x3 device name: :04:00.0
> parse addresses (80 bytes) @ fff8001fffe34f40
>   start: 840, end: 840007f, i: 10
>   start: 8400080, end: 8400081, i: 14
>   start: 851, end: 851007f, i: 18
>   start: 840, end: 840, i: 30
> 
> so the BAR 6 the ROM bar is overlapping with BAR0.
> and the ROM bar get rejected.

This is the way OF seems to work.

It maps all of the ROMs essentially to the same address range, but
only enables one at a time as it inspects the ROMs and builds the
device tree during power-on.

Then it makes sure all of them are disabled, and can therefore use
some of that address range for mapping other BARs.

So if ROMs are disabled, you cannot put the address of such ROMs BAR
in the kernel's assigned PCI address resource list.

I hope that is what you are doing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers:staging:gdm72xx Fix line over 80 characters


On 10/31, Joe Perches wrote:

On Sat, 2015-10-31 at 18:14 +0100, Bogicevic Sasa wrote:

On 10/31, Joe Perches wrote:
>On Sat, 2015-10-31 at 17:38 +0100, Bogicevic Sasa wrote:
>> This fixes line over 80 character messages from checkpatch.pl
>[]
>> diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
b/drivers/staging/gdm72xx/gdm_qos.c
>[]
>> @@ -382,7 +382,7 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
size)
>>
>>spin_lock_irqsave(>qos_lock, flags);
>>qcb->csr[index].sfid = sfid;
>> -  qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) & 
0xff00);
>> +  qcb->csr[index].classifier_rule_en = (buf[pos++] << 8) & 
0xff00;
>>qcb->csr[index].classifier_rule_en += buf[pos++];
>>if (qcb->csr[index].classifier_rule_en == 0)
>>qcb->qos_null_idx = index;
>
>If you do this one, please do all of them in the
>same block.
>
>qcb->csr[index].srcport_lo = ((buf[pos++]<<8)&0xff00);
>qcb->csr[index].srcport_lo += buf[pos++];
>qcb->csr[index].srcport_hi = ((buf[pos++]<<8)&0xff00);
>qcb->csr[index].srcport_hi += buf[pos++];
>qcb->csr[index].dstport_lo = ((buf[pos++]<<8)&0xff00);
>qcb->csr[index].dstport_lo += buf[pos++];
>qcb->csr[index].dstport_hi = ((buf[pos++]<<8)&0xff00);
>
>It'd probably be nicer to use a temporary for
>qcb->csr[index] too.
>
>Also, the += is kind of odd.  These are really a
>le16_to_cpu conversion, so it might be nicer to use
>that mechanism.
>
>csr->srcport_lo = get_unaligned_le16([pos]);
>pos += 2;
>
>
It is not a problem to remove unnecesarry brackets but bear in mind I am
new to bitwise stuff.


No worries, it's not that obvious.


 So how it should be, like this?

qcb->csr[index].srcport_lo = get_unaligned_le16([pos]);
pos += 2;
qcb->csr[index].srcport_lo = buf[pos];


No, it'd be:

csr->srcport_lo = get_unaligned_le16([pos]);
pos += 2;
csr->srcport_hi = get_unaligned_le16([pos]);
pos += 2;
csr->dstport_lo = get_unaligned_le16([pos]);
pos += 2;
csr->dstport_hi = get_unaligned_le16([pos]);
pos += 2;



Ah ok Ill do it like that than and resend
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Francois Romieu  writes:

> Måns Rullgård  :
>> Francois Romieu  writes:
> [...]
>> > It looks like it receives, then tries to allocate new resources. If so
>> > it may deplete the ring and you should instead consider allocating new
>> > resources first, then receive data if alloc + map suceeded.
>> 
>> The hardware receives a frame and stores it in the provided DMA buffer,
>> then raises an interrupt and moves on to the next buffer.  When a buffer
>> is handed over to the network stack, a new one has to take its place in
>> the DMA queue.  I'm not sure how you're suggesting this be done
>> differently.
>
> - The hardware raises an interrupt and moves on to the next packet
> - The driver allocates a new buffer - call it Bob - and maps it.
>   - If it succeeds
> - The driver unmaps the received packet
> - The driver hands the received packet to the network stack
> - The driver hands Bob to the hardware
>   - It it fails
> - The driver updates the dropped packet stats
> - The driver recycles the received - yet non-unmapped - packet to the
>   hardware

Oh, I see.  That's better.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] Documentation: afe4404: Add DT bindings for the AFE4404 heart monitor

2015-10-31 Thread Rob Herring

gmail thinks this is spam BTW.

On Sat, Oct 31, 2015 at 11:31 AM, Andrew F. Davis  wrote:
> Add the TI afe4404 heart monitor DT bindings documentation.
> Create health directory created under iio.
>
> Signed-off-by: Andrew F. Davis 
> ---
>  .../devicetree/bindings/iio/health/afe4404.txt | 27 
> ++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/health/afe4404.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/health/afe4404.txt 
> b/Documentation/devicetree/bindings/iio/health/afe4404.txt
> new file mode 100644
> index 000..d377033
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/health/afe4404.txt
> @@ -0,0 +1,27 @@
> +* Texas Instruments AFE4404 Heart rate and Pulse Oximeter
> +
> +Required properties:
> + - compatible  : Should be "ti,afe4404".
> + - reg : I2C address of the device.
> + - led-supply  : Regulator supply to the device.

Is led correct name or copy-n-paste? The datasheet has tx_sup and
rx_sup for supplies.

> + - interrupt-parent: Phandle to he parent interrupt controller.
> + - interrupts  : The interrupt line the device ADC_RDY pin is 
> connected to.
> +
> +Optional properties:
> + - reset-gpios : GPIO used to reset the device.
> +
> +Example:
> +
> + {
> +   heart_mon@58 {
> +   compatible = "ti,afe4404";
> +   reg = <0x58>;
> +
> +   led-supply = <>;
> +
> +   interrupt-parent = <>;
> +   interrupts = <28 IRQ_TYPE_EDGE_RISING>;
> +
> +   reset-gpios = < 16 GPIO_ACTIVE_LOW>;
> +   };
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers:staging:gdm72xx Fix line over 80 characters

2015-10-31 Thread Joe Perches

On Sat, 2015-10-31 at 18:14 +0100, Bogicevic Sasa wrote:
> On 10/31, Joe Perches wrote:
> >On Sat, 2015-10-31 at 17:38 +0100, Bogicevic Sasa wrote:
> >> This fixes line over 80 character messages from checkpatch.pl
> >[]
> >> diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
> >> b/drivers/staging/gdm72xx/gdm_qos.c
> >[]
> >> @@ -382,7 +382,7 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, 
> >> int size)
> >>
> >>spin_lock_irqsave(>qos_lock, flags);
> >>qcb->csr[index].sfid = sfid;
> >> -  qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) & 
> >> 0xff00);
> >> +  qcb->csr[index].classifier_rule_en = (buf[pos++] << 8) & 0xff00;
> >>qcb->csr[index].classifier_rule_en += buf[pos++];
> >>if (qcb->csr[index].classifier_rule_en == 0)
> >>qcb->qos_null_idx = index;
> >
> >If you do this one, please do all of them in the
> >same block.
> >
> > qcb->csr[index].srcport_lo = ((buf[pos++]<<8)&0xff00);
> > qcb->csr[index].srcport_lo += buf[pos++];
> > qcb->csr[index].srcport_hi = ((buf[pos++]<<8)&0xff00);
> > qcb->csr[index].srcport_hi += buf[pos++];
> > qcb->csr[index].dstport_lo = ((buf[pos++]<<8)&0xff00);
> > qcb->csr[index].dstport_lo += buf[pos++];
> > qcb->csr[index].dstport_hi = ((buf[pos++]<<8)&0xff00);
> >
> >It'd probably be nicer to use a temporary for
> >qcb->csr[index] too.
> >
> >Also, the += is kind of odd.  These are really a
> >le16_to_cpu conversion, so it might be nicer to use
> >that mechanism.
> >
> > csr->srcport_lo = get_unaligned_le16([pos]);
> > pos += 2;
> >
> >
> It is not a problem to remove unnecesarry brackets but bear in mind I am
> new to bitwise stuff.

No worries, it's not that obvious.

>  So how it should be, like this?
> 
>   qcb->csr[index].srcport_lo = get_unaligned_le16([pos]);
>   pos += 2;
>   qcb->csr[index].srcport_lo = buf[pos];

No, it'd be:

csr->srcport_lo = get_unaligned_le16([pos]);
pos += 2;
csr->srcport_hi = get_unaligned_le16([pos]);
pos += 2;
csr->dstport_lo = get_unaligned_le16([pos]);
pos += 2;
csr->dstport_hi = get_unaligned_le16([pos]);
pos += 2;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Andy Shevchenko  writes:

>> +static int nb8800_mdio_read(struct mii_bus *bus, int phy_id, int reg)
>> +{
>> +   struct nb8800_priv *priv = bus->priv;
>> +   int val;
>> +
>> +   if (!nb8800_mdio_wait(bus))
>> +   return -ETIMEDOUT;
>> +
>> +   val = MIIAR_ADDR(phy_id) | MIIAR_REG(reg);
>> +
>> +   nb8800_writel(priv, NB8800_MDIO_CMD, val);
>> +   udelay(10);
>
> Why 10? Perhaps add a comment line.

Because it works.  The documentation doesn't mention a delay, but it
works unreliably without one.

>> +   nb8800_writel(priv, NB8800_MDIO_CMD, val | MDIO_CMD_GO);
>> +
>> +   if (!nb8800_mdio_wait(bus))
>> +   return -ETIMEDOUT;
>> +
>> +   val = nb8800_readl(priv, NB8800_MDIO_STS);
>> +   if (val & MDIO_STS_ERR)
>> +   return 0x;
>
> Can we return an error here?

That breaks the bus scanning in phylib.

>> +
>> +   return val & 0x;
>> +}

[...]

>> +static int nb8800_poll(struct napi_struct *napi, int budget)
>> +{
>> +   struct net_device *dev = napi->dev;
>> +   struct nb8800_priv *priv = netdev_priv(dev);
>> +   struct nb8800_dma_desc *rx;
>> +   int work = 0;
>> +   int last = priv->rx_eoc;
>> +   int next;
>> +
>> +   while (work < budget) {
>> +   struct rx_buf *rx_buf;
>> +   u32 report;
>> +   int len;
>> +
>> +   next = (last + 1) & (RX_DESC_COUNT - 1);
>
> Maybe (last + 1) % RX_DESC_COUNT ? It will not prevent to use
> non-power-of-two numbers.

We don't want to be doing divisions anyway, but I can certainly change
it to % if that's preferred.

>> +
>> +   rx_buf = >rx_bufs[next];
>> +   rx = >rx_descs[next];
>
>> +   report = rx->report;
>
> Maybe you can use rx->report directly below.

It's in uncached memory, so didn't want to have gcc accidentally doing
more reads than necessary.

>> +static int nb8800_xmit(struct sk_buff *skb, struct net_device *dev)
>> +{
>> +   struct nb8800_priv *priv = netdev_priv(dev);
>> +   struct tx_skb_data *skb_data;
>> +   struct tx_buf *tx_buf;
>> +   dma_addr_t dma_addr;
>> +   unsigned int dma_len;
>> +   int cpsz, next;
>> +   int frags;
>> +
>> +   if (atomic_read(>tx_free) <= NB8800_DESC_LOW) {
>> +   netif_stop_queue(dev);
>> +   return NETDEV_TX_BUSY;
>> +   }
>> +
>> +   cpsz = (8 - (uintptr_t)skb->data) & 7;
>
> So, cast to uintptr_t looks strange in this driver, since used only
> twice in such expression, why not to use plain unsigned int * ?

Because it's not the same thing.  uintptr_t is an integer type the same
size as a pointer.  I need to check if the data pointer is 8-byte
aligned as required by the DMA.

>> +static void nb8800_set_rx_mode(struct net_device *dev)
>> +{
>> +   struct nb8800_priv *priv = netdev_priv(dev);
>> +   struct netdev_hw_addr *ha;
>> +   bool af_en;
>> +   int i;
>> +
>> +   if (dev->flags & (IFF_PROMISC | IFF_ALLMULTI))
>> +   af_en = false;
>> +   else
>> +   af_en = true;
>> +
>> +   nb8800_mac_af(dev, af_en);
>> +
>> +   if (!af_en)
>> +   return;
>
> Would it be
>
> if (dev->flags & (IFF_PROMISC | IFF_ALLMULTI)) {
>   nb8800_mac_af(dev, false);
>   return;
> }
>
> nb8800_mac_af(dev, true);
>
> ?

Looks equivalent.  Maybe that's clearer.

>> +static int nb8800_hw_init(struct net_device *dev)
>> +{
>> +   struct nb8800_priv *priv = netdev_priv(dev);
>
>> +   unsigned int val = 0;
>
> Useless assignment.

Indeed.  Why didn't gcc warn about that?

>> +
>> +   nb8800_writeb(priv, NB8800_RANDOM_SEED, 0x08);
>> +
>> +   /* TX single deferral params */
>> +   nb8800_writeb(priv, NB8800_TX_SDP, 0xc);
>> +
>> +   /* Threshold for partial full */
>> +   nb8800_writeb(priv, NB8800_PF_THRESHOLD, 0xff);
>> +
>> +   /* Pause Quanta */
>> +   nb8800_writeb(priv, NB8800_PQ1, 0xff);
>> +   nb8800_writeb(priv, NB8800_PQ2, 0xff);
>
> Lot of magic numbers above and below.

Those are from the original driver.  Some of them disagree with the
documentation, and the "correct" values don't work.

>> +
>> +   /* configure TX DMA Channels */
>> +   val = nb8800_readl(priv, NB8800_TXC_CR);
>> +   val &= TCR_LE;
>> +   val |= TCR_DM | TCR_RS | TCR_TFI(1) | TCR_BTS(2);
>> +   nb8800_writel(priv, NB8800_TXC_CR, val);
>> +
>> +   /* TX Interrupt Time Register */
>> +   nb8800_writel(priv, NB8800_TX_ITR, 1);
>> +
>> +   /* configure RX DMA Channels */
>> +   val = nb8800_readl(priv, NB8800_RXC_CR);
>> +   val &= RCR_LE;
>> +   val |= RCR_DM | RCR_RS | RCR_RFI(7) | RCR_BTS(2) | RCR_FL;
>> +   nb8800_writel(priv, NB8800_RXC_CR, val);
>> +
>> +   /* RX Interrupt Time Register */
>> +   nb8800_writel(priv, NB8800_RX_ITR, 1);
>> +
>> +   val = TX_RETRY_EN | TX_PAD_EN | TX_APPEND_FCS;
>> +   nb8800_writeb(priv, NB8800_TX_CTL1, val);

Re: [PATCH 1/2] devicetree: i2c: add binding for Sigma Designs SMP8642 I2C master

2015-10-31 Thread Rob Herring

On Sat, Oct 31, 2015 at 12:35 PM, Mans Rullgard  wrote:
> This adds a binding for the Sigma Designs SMP8642 built-in I2C master
> controller.
>
> Signed-off-by: Mans Rullgard 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/i2c/sigma,smp8642-i2c.txt  | 24 
> ++
>  1 file changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/i2c/sigma,smp8642-i2c.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/sigma,smp8642-i2c.txt 
> b/Documentation/devicetree/bindings/i2c/sigma,smp8642-i2c.txt
> new file mode 100644
> index 000..117fc8b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/sigma,smp8642-i2c.txt
> @@ -0,0 +1,24 @@
> +Sigma Designs SMP8642 I2C master
> +
> +Required properties:
> +- compatible: should be "sigma,smp8642-i2c"
> +- reg: physical address space of the device
> +- interrupts: the interrupt of the device
> +- clocks: phandle of the clock for the device
> +- #address-cells: should be <1>
> +- #size-cells: should be <0>
> +
> +Optional properties:
> +- clock-frequency: frequency of bus clock in Hz, default 100kHz
> +
> +Example:
> +
> +i2c@10480 {
> +   compatible = "sigma,smp8642-i2c";
> +   reg = <0x10480 0x2c>;
> +   interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
> +   clocks = <_clk>;
> +   clock-frequency = <10>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +};
> --
> 2.6.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 09/17] dt-bindings: add document for rockchip variant of analogix_dp

2015-10-31 Thread Rob Herring

On Sat, Oct 31, 2015 at 1:42 AM, Yakir Yang  wrote:
> Rockchip DP driver is a helper driver of analogix_dp coder driver,
> so most of the DT property should be descriped in analogix_dp document.
>
> Reviewed-by: Heiko Stuebner 
> Signed-off-by: Yakir Yang 

Acked-by: Rob Herring 

> ---
> Changes in v10:
> - Removed the duplicated signed-of.
>
> Changes in v9:
> - Document more details for 'ports' property.
>
> Changes in v8:
> - Modify the commit subject name. (Heiko)
>
> Changes in v7: None
> Changes in v6: None
> Changes in v5:
> - Split binding doc's from driver changes. (Rob)
> - Add eDP hotplug pinctrl property. (Heiko)
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  .../display/rockchip/analogix_dp-rockchip.txt  | 91 
> ++
>  1 file changed, 91 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> new file mode 100644
> index 000..dae86c4
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> @@ -0,0 +1,91 @@
> +Rockchip RK3288 specific extensions to the Analogix Display Port
> +
> +
> +Required properties:
> +- compatible: "rockchip,rk3288-edp";
> +
> +- reg: physical base address of the controller and length
> +
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +
> +- clock-names: from common clock binding:
> +  Required elements: "dp" "pclk"
> +
> +- resets: Must contain an entry for each entry in reset-names.
> + See ../reset/reset.txt for details.
> +
> +- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
> +- pinctrl-0: pin-control mode. should be <_hpd>
> +
> +- reset-names: Must include the name "dp"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +
> +- ports: there are 2 port nodes with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +Port 0: contained 2 endpoints, connecting to the ouput of vop.
> +Port 1: contained 1 endpoint, connecting to the input of panel.
> +
> +For the below properties, please refer to Analogix DP binding document:
> + * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> +- phys (required)
> +- phy-names (required)
> +- hpd-gpios (optional)
> +---
> +
> +Example:
> +   dp-controller: dp@ff97 {
> +   compatible = "rockchip,rk3288-dp";
> +   reg = <0xff97 0x4000>;
> +   interrupts = ;
> +   clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
> +   clock-names = "dp", "pclk";
> +   phys = <_phy>;
> +   phy-names = "dp";
> +
> +   rockchip,grf = <>;
> +   resets = < 111>;
> +   reset-names = "dp";
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_hpd>;
> +
> +   status = "disabled";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   edp_in: port@0 {
> +   reg = <0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   edp_in_vopb: endpoint@0 {
> +   reg = <0>;
> +   remote-endpoint = <_out_edp>;
> +   };
> +   edp_in_vopl: endpoint@1 {
> +   reg = <1>;
> +   remote-endpoint = <_out_edp>;
> +   };
> +   };
> +
> +   edp_out: port@1 {
> +   reg = <1>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   edp_out_panel: endpoint {
> +   reg = <0>;
> +   remote-endpoint = <_in_edp>
> +   };
> +   };
> +   };
> +   };
> +
> +   pinctrl {
> +   edp {
> +   edp_hpd: edp-hpd {
> +   rockchip,pins = <7 11 RK_FUNC_2 
> _pull_none>;
> +   };
> +   };
> +   };
> --
> 1.9.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at

Re: [GIT] Networking

2015-10-31 Thread David Miller

From: David Miller 
Date: Thu, 29 Oct 2015 08:19:41 -0700 (PDT)

> This is the same as the previous pull request, with the ipv6 overflow
> fix redone.  The merge conflict is therefore gone too.
 ...
> Please pull, thanks a lot.
> 
> The following changes since commit 1099f86044111e9a7807f09523e42d4c9d0fb781:
> 
>   Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-10-19 
> 09:55:40 -0700)

Ping?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

2015-10-31 Thread Francois Romieu

Måns Rullgård  :
> Francois Romieu  writes:
[...]
> > It looks like it receives, then tries to allocate new resources. If so
> > it may deplete the ring and you should instead consider allocating new
> > resources first, then receive data if alloc + map suceeded.
> 
> The hardware receives a frame and stores it in the provided DMA buffer,
> then raises an interrupt and moves on to the next buffer.  When a buffer
> is handed over to the network stack, a new one has to take its place in
> the DMA queue.  I'm not sure how you're suggesting this be done
> differently.

- The hardware raises an interrupt and moves on to the next packet
- The driver allocates a new buffer - call it Bob - and maps it.
  - If it succeeds
- The driver unmaps the received packet
- The driver hands the received packet to the network stack
- The driver hands Bob to the hardware
  - It it fails
- The driver updates the dropped packet stats
- The driver recycles the received - yet non-unmapped - packet to the
  hardware

-- 
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/hugetlbfs Fix bugs in fallocate hole punch of areas with holes

2015-10-31 Thread Mike Kravetz

On 10/30/2015 10:07 PM, Hillf Danton wrote:
>>
>> Hugh Dickins pointed out problems with the new hugetlbfs fallocate
>> hole punch code.  These problems are in the routine remove_inode_hugepages
>> and mostly occur in the case where there are holes in the range of
>> pages to be removed.  These holes could be the result of a previous hole
>> punch or simply sparse allocation.
>>
>> remove_inode_hugepages handles both hole punch and truncate operations.
>> Page index handling was fixed/cleaned up so that holes are properly
>> handled.  In addition, code was changed to ensure multiple passes of the
>> address range only happens in the truncate case.  More comments were added
>> to explain the different actions in each case.  A cond_resched() was added
>> after removing up to PAGEVEC_SIZE pages.
>>
>> Some totally unnecessary code in hugetlbfs_fallocate() that remained from
>> early development was also removed.
>>
>> Signed-off-by: Mike Kravetz 
>> ---
>>  fs/hugetlbfs/inode.c | 44 +---
>>  1 file changed, 29 insertions(+), 15 deletions(-)
>>
>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>> index 316adb9..30cf534 100644
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -368,10 +368,25 @@ static void remove_inode_hugepages(struct inode 
>> *inode, loff_t lstart,
>>  lookup_nr = end - next;
>>
>>  /*
>> - * This pagevec_lookup() may return pages past 'end',
>> - * so we must check for page->index > end.
>> + * When no more pages are found, take different action for
>> + * hole punch and truncate.
>> + *
>> + * For hole punch, this indicates we have removed each page
>> + * within the range and are done.  Note that pages may have
>> + * been faulted in after being removed in the hole punch case.
>> + * This is OK as long as each page in the range was removed
>> + * once.
>> + *
>> + * For truncate, we need to make sure all pages within the
>> + * range are removed when exiting this routine.  We could
>> + * have raced with a fault that brought in a page after it
>> + * was first removed.  Check the range again until no pages
>> + * are found.
>>   */
>>  if (!pagevec_lookup(, mapping, next, lookup_nr)) {
>> +if (!truncate_op)
>> +break;
>> +
>>  if (next == start)
>>  break;
>>  next = start;
>> @@ -382,19 +397,23 @@ static void remove_inode_hugepages(struct inode 
>> *inode, loff_t lstart,
>>  struct page *page = pvec.pages[i];
>>  u32 hash;
>>
>> +/*
>> + * The page (index) could be beyond end.  This is
>> + * only possible in the punch hole case as end is
>> + * LLONG_MAX for truncate.
>> + */
>> +if (page->index >= end) {
>> +next = end; /* we are done */
>> +break;
>> +}
>> +next = page->index;
>> +
>>  hash = hugetlb_fault_mutex_hash(h, current->mm,
>>  _vma,
>>  mapping, next, 0);
>>  mutex_lock(_fault_mutex_table[hash]);
>>
>>  lock_page(page);
>> -if (page->index >= end) {
>> -unlock_page(page);
>> -mutex_unlock(_fault_mutex_table[hash]);
>> -next = end; /* we are done */
>> -break;
>> -}
>> -
>>  /*
>>   * If page is mapped, it was faulted in after being
>>   * unmapped.  Do nothing in this race case.  In the
>> @@ -423,15 +442,13 @@ static void remove_inode_hugepages(struct inode 
>> *inode, loff_t lstart,
>>  }
>>  }
>>
>> -if (page->index > next)
>> -next = page->index;
>> -
>>  ++next;
>>  unlock_page(page);
>>
>>  mutex_unlock(_fault_mutex_table[hash]);
>>  }
>>  huge_pagevec_release();
>> +cond_resched();
>>  }
>>
>>  if (truncate_op)
>> @@ -647,9 +664,6 @@ static long hugetlbfs_fallocate(struct file *file, int 
>> mode, loff_t offset,
> 
> This hunk is already in the next tree, see below please.
> 

Ah, the whole series to add shmem like code to handle hole punch/fault
races is in the next tree.  It has been determined that most of this
series

[PATCH 1/2] devicetree: i2c: add binding for Sigma Designs SMP8642 I2C master

2015-10-31 Thread Mans Rullgard

This adds a binding for the Sigma Designs SMP8642 built-in I2C master
controller.

Signed-off-by: Mans Rullgard 
---
 .../devicetree/bindings/i2c/sigma,smp8642-i2c.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/sigma,smp8642-i2c.txt

diff --git a/Documentation/devicetree/bindings/i2c/sigma,smp8642-i2c.txt 
b/Documentation/devicetree/bindings/i2c/sigma,smp8642-i2c.txt
new file mode 100644
index 000..117fc8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/sigma,smp8642-i2c.txt
@@ -0,0 +1,24 @@
+Sigma Designs SMP8642 I2C master
+
+Required properties:
+- compatible: should be "sigma,smp8642-i2c"
+- reg: physical address space of the device
+- interrupts: the interrupt of the device
+- clocks: phandle of the clock for the device
+- #address-cells: should be <1>
+- #size-cells: should be <0>
+
+Optional properties:
+- clock-frequency: frequency of bus clock in Hz, default 100kHz
+
+Example:
+
+i2c@10480 {
+   compatible = "sigma,smp8642-i2c";
+   reg = <0x10480 0x2c>;
+   interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clk>;
+   clock-frequency = <10>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+};
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] i2c: add driver for Sigma Designs SMP8642 I2C master

2015-10-31 Thread Mans Rullgard

This adds a driver for the Sigma Designs SMP8642 built-in I2C master
controller.  The hardware is very similar to the I2C controller in the
Ralink RT3050 chip with the addition of interrupt generation and an
inverted busy/idle status bit.  There are typically two controllers with
a shared IRQ.

Signed-off-by: Mans Rullgard 
---
 drivers/i2c/busses/Kconfig  |   8 +
 drivers/i2c/busses/Makefile |   1 +
 drivers/i2c/busses/i2c-tangox.c | 330 
 3 files changed, 339 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-tangox.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 08b8617..f764e3a 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -974,6 +974,14 @@ config I2C_RCAR
  This driver can also be built as a module.  If so, the module
  will be called i2c-rcar.
 
+config I2C_TANGOX
+   tristate "SMP86xx I2C master support"
+   depends on ARCH_TANGOX
+   help
+ This driver supports the Sigma Designs SMP86xx built-in I2c master.
+
+ If built as a module, it will be called i2c-tangox.
+
 comment "External I2C/SMBus adapter drivers"
 
 config I2C_DIOLAN_U2C
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 6df3b30..d7a9f94 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_I2C_XILINX)  += i2c-xiic.o
 obj-$(CONFIG_I2C_XLR)  += i2c-xlr.o
 obj-$(CONFIG_I2C_XLP9XX)   += i2c-xlp9xx.o
 obj-$(CONFIG_I2C_RCAR) += i2c-rcar.o
+obj-$(CONFIG_I2C_TANGOX)   += i2c-tangox.o
 
 # External I2C/SMBus adapter drivers
 obj-$(CONFIG_I2C_DIOLAN_U2C)   += i2c-diolan-u2c.o
diff --git a/drivers/i2c/busses/i2c-tangox.c b/drivers/i2c/busses/i2c-tangox.c
new file mode 100644
index 000..586b3cb
--- /dev/null
+++ b/drivers/i2c/busses/i2c-tangox.c
@@ -0,0 +1,330 @@
+/*
+ * Copyright (C) 2015 Mans Rullgard 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TANGOX_I2C_CONFIG  0x00
+#define TANGOX_I2C_CLKDIV  0x04
+#define TANGOX_I2C_DEVADDR 0x08
+#define TANGOX_I2C_ADDR0x0c
+#define TANGOX_I2C_DATAOUT 0x10
+#define TANGOX_I2C_DATAIN  0x14
+#define TANGOX_I2C_STATUS  0x18
+#define TANGOX_I2C_STARTXFER   0x1c
+#define TANGOX_I2C_BYTECNT 0x20
+#define TANGOX_I2C_INT_EN  0x24
+#define TANGOX_I2C_INT_STAT0x28
+
+#define TANGOX_I2C_CFG_EN  (1 << 8)
+#define TANGOX_I2C_CFG_ADDRLEN(x)  ((x) << 5)
+#define TANGOX_I2C_CFG_DEVADLEN(x) ((x) << 2)
+#define TANGOX_I2C_CFG_ADDRDIS (1 << 1)
+#define TANGOX_I2C_CFG_DEVADDIS(1 << 0)
+
+#define TANGOX_I2C_STATUS_IDLE (1 << 0)
+#define TANGOX_I2C_STATUS_SDOEMPTY (1 << 1)
+#define TANGOX_I2C_STATUS_DATARDY  (1 << 2)
+#define TANGOX_I2C_STATUS_ACKERR   (1 << 3)
+#define TANGOX_I2C_STATUS_STARTERR (1 << 4)
+
+#define TANGOX_I2C_XFER_WR 0
+#define TANGOX_I2C_XFER_RD 1
+#define TANGOX_I2C_XFER_NODATA 2
+
+#define TANGOX_I2C_CFG_WR  0x1f8
+#define TANGOX_I2C_CFG_RD  0x1fa
+
+#define TANGOX_I2C_TIMEOUT(len)msecs_to_jiffies(10 * len)
+
+struct tangox_i2c {
+   struct i2c_adapter adap;
+   void __iomem *base;
+   struct i2c_msg *msg;
+   int pos;
+   wait_queue_head_t wait;
+   struct clk *clk;
+};
+
+static int tangox_i2c_idle(struct tangox_i2c *ti2c)
+{
+   return readl(ti2c->base + TANGOX_I2C_STATUS) & TANGOX_I2C_STATUS_IDLE;
+}
+
+static int tangox_i2c_wait(struct tangox_i2c *ti2c, unsigned long timeout)
+{
+   int status;
+   int t;
+
+   t = wait_event_timeout(ti2c->wait, tangox_i2c_idle(ti2c), timeout);
+   if (!t)
+   return -ETIMEDOUT;
+
+   status = readl(ti2c->base + TANGOX_I2C_STATUS);
+
+   return status & TANGOX_I2C_STATUS_ACKERR ? -EIO : 0;
+}
+
+static void tangox_i2c_tx_irq(struct tangox_i2c *ti2c, u32 status)
+{
+   struct i2c_msg *msg = ti2c->msg;
+
+   if (status & TANGOX_I2C_STATUS_SDOEMPTY)
+   writel(msg->buf[ti2c->pos++], ti2c->base + TANGOX_I2C_DATAOUT);
+}
+
+static void tangox_i2c_rx_irq(struct tangox_i2c *ti2c, u32 status)
+{
+   struct i2c_msg *msg = ti2c->msg;
+
+   if (status & TANGOX_I2C_STATUS_DATARDY)
+   msg->buf[ti2c->pos++] = readl(ti2c->base + TANGOX_I2C_DATAIN);
+}
+
+static irqreturn_t tangox_i2c_irq(int irq, void *dev_id)
+{
+   struct tangox_i2c *ti2c = dev_id;
+   struct i2c_msg *msg = ti2c->msg;
+

Re: [PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver

2015-10-31 Thread Sinan Kaya

On 10/30/2015 11:33 PM, Jon Masters wrote:

Hi Andy,

On 10/30/2015 04:15 PM, Andy Shevchenko wrote:

On Fri, Oct 30, 2015 at 10:08 PM, Al Stone wrote:

On 10/30/2015 01:01 PM, Mark Rutland wrote:

On Fri, Oct 30, 2015 at 02:48:06PM -0400, Sinan Kaya wrote:

The CSRT is listed under "Want", not "Never" or "Don't Care", so Linaro
have certainly not said that CSRT will not be supported. If anything,
they have stated that the table should be supported.

"Want" means interesting, and probably useful, but no clear indication that
anyone actually needs it. At one point, we thought we might use the CSRT
for describing DMA, but it turns out we have not needed to.

Then you are going to have either 1 or 0 DMAC for slave devices, right?

I believe what Al means is that such hardware has not appeared
(publicly) until this time and so such situation was theoretical and
thus not covered by the Linaro wiki. Linaro had not prioritized CSRT
because it didn't seem that the need to support it would arise soon.

The CSRT, unfortunately, the only way how to enumerate DMAC to be used
by slave devices.
You may look into drivers/dma/acpi-dma.c for usage in Linux.

Yes, I know about _DSD, but I don't think it will provide soon any
other official mechanisms to what we have now. Better to ask Rafael
and Mika.

Thanks for the feedback. I agree that generally the plan is to use
existing tables from x86 on arm64 when possible. Please see below.

However, let's make sure we're saying the same thing: the CSRT table is
properly defined in the kernel include/acpi/actbl2.h file so one can read
such a table and use it if they so choose. Nothing that we have done at
Linaro in the arm64 part of the kernel relies on any of the content from
the CSRT, nor does it preclude someone relying on that content. So, the
CSRT is defined, and is usable, but is just not being used -- by Linaro --
at present.

This sounds clear.

If that needs to change, let me know; no one has asked us to use the CSRT
for a DMA engine, and we have not been provided any hardware that requires
it.

See above.

Here's, what I believe to be the summary:

1). QCOM are not implementing slave device support in their current
HIDMA hardware, therefore the requirement for CSRT does not exist *at
present* for this specific driver to be merged and the discussion in
this sub-thread pertains only to a situation not affecting HIDMA.

2). A requirement upon the CSRT should be clarified in the various
specifications. The SBBR[0] currently "recommends" CSRT but does not
necessarily provide guidance about what kinds of system resources would
be covered by that, and so there is a potential for this to be missed.

As one of the lead authors of certain ARM server specifications, I will
contact those involved in such and ensure that this is addressed with a
clarification in a future release.

Thanks for raising the concern,

Jon.

[0]
http://infocenter.arm.com/help/topic/com.arm.doc.den0044a/Server_Base_Boot_Requirements.pdf

Apologies for creating confusion.

I tried using the dma-acpi.c implementation at the beginning. It didn't
quite play well with what I was trying to do with HIDMA. Since the file
header said Intel, I assumed it was an Intel specific implementation.

To confirm my suspicion, I looked at the Linaro wiki. I haven't seen
CSRT in MUST tables.

I considered WANT meaning some spec work required similar to DMAR vs.
IORT table.

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH v9 2/9] Input: goodix - reset device at init

2015-10-31 Thread Dmitry Torokhov

On Fri, Oct 30, 2015 at 09:33:28AM -0700, Dmitry Torokhov wrote:
> On Mon, Oct 19, 2015 at 05:52:39PM +0300, mika.westerb...@linux.intel.com 
> wrote:
> > On Mon, Oct 19, 2015 at 02:32:24PM +, Tirdea, Irina wrote:
> > > 
> > > 
> > > > -Original Message-
> > > > From: linux-input-ow...@vger.kernel.org 
> > > > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of
> > > > mika.westerb...@linux.intel.com
> > > > Sent: 14 October, 2015 16:44
> > > > To: Dmitry Torokhov
> > > > Cc: Tirdea, Irina; Bastien Nocera; Aleksei Mamlin; Karsten Merker; 
> > > > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > > > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > > > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
> > > > 
> > > > On Wed, Oct 14, 2015 at 02:18:20PM +0300, 
> > > > mika.westerb...@linux.intel.com wrote:
> > > > > On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote:
> > > > > > I understand why one might use acpi_dev_add_driver_gpios() to 
> > > > > > augment
> > > > > > data in ACPI, however here we have completely different issue: 
> > > > > > driver
> > > > > > that expects named gpios gets returned gpio that has nothing to do 
> > > > > > with
> > > > > > what it requested, because gpiolib acpi code always falls back to
> > > > > > unnamed gpio if it does not find named gpio. That can be acceptable 
> > > > > > if
> > > > > > driver uses the same con_id for all requests to gpiolib, but is not
> > > > > > working when driver supplies different con_ids.
> > > > >
> > > > > Right, the ACPI fallback ignores con_id completely and uses only the
> > > > > index.
> > > > >
> > > > > AFAIK there is only one driver using ACPI _CRS index method:
> > > > > sdhci-[acpi|pci].c. If we can convert that to use 
> > > > > acpi_dev_add_driver_gpios()
> > > > > to feed names for card detection GPIOs, I think we can remove the
> > > > > fallback alltogether in favor of named GPIOs for ACPI.
> > > > 
> > > > Nah, there seems to be several drivers relying on this already :-/
> > > 
> > > Would it be possible to add an optional parameter to the GPIO API
> > > to specify whether we want to fall back to indexed GPIOs for ACPI?
> > 
> > I don't think it's a good idea to add ACPI specifics to generic APIs.
> > 
> > I went through ACPI enabled drivers calling GPIO APIs and majority of
> > them are doing this:
> > 
> > static int stk8312_gpio_probe(struct i2c_client *client)
> > {
> > struct device *dev;
> > struct gpio_desc *gpio;
> > int ret;
> > 
> > if (!client)
> > return -EINVAL;
> > 
> > dev = >dev;
> > 
> > /* data ready gpio interrupt pin */
> > gpio = devm_gpiod_get_index(dev, STK8312_GPIO, 0, GPIOD_IN);
> > if (IS_ERR(gpio)) {
> > dev_err(dev, "acpi gpio get index failed\n");
> > return PTR_ERR(gpio);
> > }
> > 
> > ret = gpiod_to_irq(gpio);
> > dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), 
> > ret);
> > 
> > return ret;
> > }
> > 
> > We can drop all this because I2C core already handles GpioInt -> interrupt
> > number translation.
> > 
> > Few drivers are doing something more complex but I think we can still 
> > convert
> > them to use acpi_dev_add_driver_gpios() and eventually get rid of the whole
> > _CRS index lookup.
> 
> cpi_dev_add_driver_gpios() does not really help with generic drivers
> (unless we keep adding more and more board specific data to them). How
> about we keep track of names used and only allow conversion for the
> first name used, like in the patch below?
> 
> -- 
> Dmitry
> 
> gpiolib: tighten up ACPI legacy gpio lookups
> 
> From: Dmitry Torokhov 
> 
> We should not fall back to the legacy unnamed gpio lookup style if the
> driver requests gpios with different names, because we'll give out the same
> gpio twice. Let's keep track of the names that were used for the device and
> only do the fallback for the first name used.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/gpio/gpiolib.c |   42 +-
>  1 file changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 5db3445..4ae5447 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1738,6 +1738,45 @@ static struct gpio_desc *of_find_gpio(struct device 
> *dev, const char *con_id,
>   return desc;
>  }
>  
> +struct acpi_gpio_lookup {
> + struct list_head node;
> + struct device *dev;
> + const char *con_id;
> +};
> +
> +static DEFINE_MUTEX(acpi_gpio_lookup_lock);
> +static LIST_HEAD(acpi_gpio_lookup_list);
> +
> +static bool acpi_can_fallback_crs(struct device *dev, const char *con_id)
> +{
> + struct acpi_gpio_lookup *l, *lookup = NULL;
> +
> + mutex_lock(_gpio_lookup_lock);
> +
> + list_for_each_entry(l, _gpio_lookup_list, node) {
> + if (l->dev ==

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

2015-10-31 Thread Andy Shevchenko

On Thu, Oct 29, 2015 at 6:48 PM, Mans Rullgard  wrote:
> This adds a driver for the Aurora VLSI NB8800 Ethernet controller.
> It is an almost complete rewrite of a driver originally found in
> a Sigma Designs 2.6.22 tree.
>
> Signed-off-by: Mans Rullgard 


> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -0,0 +1,1146 @@

> +#define nb8800_set_bits(sz, priv, reg, bits) do {  \
> +   u32 __o = nb8800_read##sz(priv, reg);   \
> +   u32 __n = __o | (bits); \
> +   if (__n != __o) \
> +   nb8800_write##sz(priv, reg, __n);   \
> +   } while (0)
> +
> +#define nb8800_clear_bits(sz, priv, reg, bits) do {\
> +   u32 __o = nb8800_read##sz(priv, reg);   \
> +   u32 __n = __o & ~(bits);\
> +   if (__n != __o) \
> +   nb8800_write##sz(priv, reg, __n);   \
> +   } while (0)
> +
> +#define MDIO_TIMEOUT   1000
> +
> +static int nb8800_mdio_wait(struct mii_bus *bus)
> +{
> +   struct nb8800_priv *priv = bus->priv;
> +   int tmo = MDIO_TIMEOUT;
> +
> +   while (--tmo) {
> +   if (!(nb8800_readl(priv, NB8800_MDIO_CMD) & MDIO_CMD_GO))
> +   break;
> +   udelay(1);

Can you use cpu_relax() or readx_poll_timeout() ?

> +   }
> +
> +   return tmo;
> +}
> +
> +static int nb8800_mdio_read(struct mii_bus *bus, int phy_id, int reg)
> +{
> +   struct nb8800_priv *priv = bus->priv;
> +   int val;
> +
> +   if (!nb8800_mdio_wait(bus))
> +   return -ETIMEDOUT;
> +
> +   val = MIIAR_ADDR(phy_id) | MIIAR_REG(reg);
> +
> +   nb8800_writel(priv, NB8800_MDIO_CMD, val);
> +   udelay(10);

Why 10? Perhaps add a comment line.

> +   nb8800_writel(priv, NB8800_MDIO_CMD, val | MDIO_CMD_GO);
> +
> +   if (!nb8800_mdio_wait(bus))
> +   return -ETIMEDOUT;
> +
> +   val = nb8800_readl(priv, NB8800_MDIO_STS);
> +   if (val & MDIO_STS_ERR)
> +   return 0x;

Can we return an error here?

> +
> +   return val & 0x;
> +}
> +
> +static int nb8800_mdio_write(struct mii_bus *bus, int phy_id, int reg, u16 
> val)
> +{
> +   struct nb8800_priv *priv = bus->priv;
> +   int tmp;
> +
> +   if (!nb8800_mdio_wait(bus))
> +   return -ETIMEDOUT;
> +
> +   tmp = MIIAR_DATA(val) | MIIAR_ADDR(phy_id) | MIIAR_REG(reg) |
> +   MDIO_CMD_WR;
> +
> +   nb8800_writel(priv, NB8800_MDIO_CMD, tmp);
> +   udelay(10);
> +   nb8800_writel(priv, NB8800_MDIO_CMD, tmp | MDIO_CMD_GO);
> +
> +   if (!nb8800_mdio_wait(bus))
> +   return -ETIMEDOUT;
> +
> +   return 0;
> +}
> +
> +static void nb8800_mac_tx(struct net_device *dev, bool enable)
> +{
> +   struct nb8800_priv *priv = netdev_priv(dev);
> +
> +   while (nb8800_readl(priv, NB8800_TXC_CR) & TCR_EN)
> +   cpu_relax();
> +
> +   if (enable)
> +   nb8800_set_bits(b, priv, NB8800_TX_CTL1, TX_EN);
> +   else
> +   nb8800_clear_bits(b, priv, NB8800_TX_CTL1, TX_EN);
> +}
> +
> +static void nb8800_mac_rx(struct net_device *dev, bool enable)
> +{
> +   struct nb8800_priv *priv = netdev_priv(dev);
> +
> +   if (enable)
> +   nb8800_set_bits(b, priv, NB8800_RX_CTL, RX_EN);
> +   else
> +   nb8800_clear_bits(b, priv, NB8800_RX_CTL, RX_EN);
> +}
> +
> +static void nb8800_mac_af(struct net_device *dev, bool enable)
> +{
> +   struct nb8800_priv *priv = netdev_priv(dev);
> +
> +   if (enable)
> +   nb8800_set_bits(b, priv, NB8800_RX_CTL, RX_AF_EN);
> +   else
> +   nb8800_clear_bits(b, priv, NB8800_RX_CTL, RX_AF_EN);
> +}
> +
> +static void nb8800_stop_rx(struct net_device *dev)
> +{
> +   struct nb8800_priv *priv = netdev_priv(dev);
> +   int i;
> +
> +   for (i = 0; i < RX_DESC_COUNT; i++)
> +   priv->rx_descs[i].config |= DESC_EOC;
> +
> +   while (nb8800_readl(priv, NB8800_RXC_CR) & RCR_EN)
> +   usleep_range(1000, 1);

Here is a busy loop without timeout limitation.

> +}
> +
> +static void nb8800_start_rx(struct net_device *dev)
> +{
> +   struct nb8800_priv *priv = netdev_priv(dev);
> +
> +   nb8800_set_bits(l, priv, NB8800_RXC_CR, RCR_EN);
> +}
> +
> +static int nb8800_alloc_rx(struct net_device *dev, int i, bool napi)
> +{
> +   struct nb8800_priv *priv = netdev_priv(dev);
> +   struct nb8800_dma_desc *rx = >rx_descs[i];
> +   struct rx_buf *buf = >rx_bufs[i];
> +   int size = L1_CACHE_ALIGN(RX_BUF_SIZE);
> +   void *data;
> +
> +   data = napi ? napi_alloc_frag(size) : netdev_alloc_frag(size);
> +   if (!data) {
> +   buf->page = NULL;
> +

Re: [PATCH] drivers:staging:gdm72xx Fix line over 80 characters


On 10/31, Joe Perches wrote:

On Sat, 2015-10-31 at 17:38 +0100, Bogicevic Sasa wrote:

This fixes line over 80 character messages from checkpatch.pl

[]

diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
b/drivers/staging/gdm72xx/gdm_qos.c

[]

@@ -382,7 +382,7 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
size)

spin_lock_irqsave(>qos_lock, flags);
qcb->csr[index].sfid = sfid;
-   qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) & 
0xff00);
+   qcb->csr[index].classifier_rule_en = (buf[pos++] << 8) & 0xff00;
qcb->csr[index].classifier_rule_en += buf[pos++];
if (qcb->csr[index].classifier_rule_en == 0)
qcb->qos_null_idx = index;


If you do this one, please do all of them in the
same block.

qcb->csr[index].srcport_lo = ((buf[pos++]<<8)&0xff00);
qcb->csr[index].srcport_lo += buf[pos++];
qcb->csr[index].srcport_hi = ((buf[pos++]<<8)&0xff00);
qcb->csr[index].srcport_hi += buf[pos++];
qcb->csr[index].dstport_lo = ((buf[pos++]<<8)&0xff00);
qcb->csr[index].dstport_lo += buf[pos++];
qcb->csr[index].dstport_hi = ((buf[pos++]<<8)&0xff00);

It'd probably be nicer to use a temporary for
qcb->csr[index] too.

Also, the += is kind of odd.  These are really a
le16_to_cpu conversion, so it might be nicer to use
that mechanism.

csr->srcport_lo = get_unaligned_le16([pos]);
pos += 2;



It is not a problem to remove unnecesarry brackets but bear in mind I am
new to bitwise stuff. So how it should be, like this?

qcb->csr[index].srcport_lo = get_unaligned_le16([pos]);
pos += 2;
qcb->csr[index].srcport_lo = buf[pos];
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver

2015-10-31 Thread Sinan Kaya




On 10/30/2015 11:00 AM, Mark Rutland wrote:

On Thu, Oct 29, 2015 at 11:08:12PM -0400, Sinan Kaya wrote:

The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design. The management
driver is executed in hypervisor context and is the main
managment for all channels provided by the device. The
channel driver is exected in the guest OS context.

Signed-off-by: Sinan Kaya 
---
  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  42 +
  drivers/dma/Kconfig|  11 +
  drivers/dma/Makefile   |   1 +
  drivers/dma/qcom_hidma_mgmt.c  | 868 +
  4 files changed, 922 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
  create mode 100644 drivers/dma/qcom_hidma_mgmt.c

diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt 
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..81674ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,42 @@
+Qualcomm Technologies HIDMA Management interface
+
+Required properties:
+- compatible: must contain "qcom,hidma_mgmt"


s/_/-/ in property names and compatible strings.


done


Per your rationale for splitting the device nodes, surely the
relationship between the two needs to be described?


I changed the commit message to make it more clear. I also added
the same message to the device binding document for reference.


The GIC has a similar split, yet we use a single node, with the
hypervisor portions being optional.

What if there were multiple instances?

The driver already supports multiple instances. It has been tested 
against 4 instances. I ended up having 4 management device entities 
managing 6 different channels each.




+- reg: Address range for DMA device
+- interrupts: Should contain the one interrupt shared by all channels
+- nr-channels: Number of channels supported by this DMA controller.
+- max-write: Maximum write burst in bytes. A memcpy requested is
+  fragmented to multiples of this amount.
+- max-read: Maximum read burst in bytes. A memcpy request is
+  fragmented to multiples of this amount.


Thse would be better named as max-read-burst-bytes and
min-read-burst-bytes.


ok




+- max-wxactions: Maximum write transactions to perform in a burst
+- max-rdactions: Maximum read transactions to perform in a burst


max-{write,read}-transactions

ok



+- max-memset-limit: Maximum memset limit


I have no idea what this is meant to mean.


old stuff. no memset support anymore. will remove it.


+- ch-priority-#n: Priority of the channel
+- ch-weight-#n: Round robin weight of the channel


These need better descriptions. They sound like configuration options.


ok.


[...]


+#if IS_ENABLED(CONFIG_ACPI)
+static const struct acpi_device_id qcom_hidma_mgmt_acpi_ids[] = {
+   {"QCOM8060"},
+   {},
+};
+#endif


How do DMA engines work with ACPI?

How are client relationships defined?

THanks,
Mark.



--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers:staging:gdm72xx Fix line over 80 characters

2015-10-31 Thread Joe Perches

On Sat, 2015-10-31 at 17:38 +0100, Bogicevic Sasa wrote:
> This fixes line over 80 character messages from checkpatch.pl
[]
> diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
> b/drivers/staging/gdm72xx/gdm_qos.c
[]
> @@ -382,7 +382,7 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
> size)
>  
>   spin_lock_irqsave(>qos_lock, flags);
>   qcb->csr[index].sfid = sfid;
> - qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) & 
> 0xff00);
> + qcb->csr[index].classifier_rule_en = (buf[pos++] << 8) & 0xff00;
>   qcb->csr[index].classifier_rule_en += buf[pos++];
>   if (qcb->csr[index].classifier_rule_en == 0)
>   qcb->qos_null_idx = index;

If you do this one, please do all of them in the
same block.

qcb->csr[index].srcport_lo = ((buf[pos++]<<8)&0xff00);
qcb->csr[index].srcport_lo += buf[pos++];
qcb->csr[index].srcport_hi = ((buf[pos++]<<8)&0xff00);
qcb->csr[index].srcport_hi += buf[pos++];
qcb->csr[index].dstport_lo = ((buf[pos++]<<8)&0xff00);
qcb->csr[index].dstport_lo += buf[pos++];
qcb->csr[index].dstport_hi = ((buf[pos++]<<8)&0xff00);

It'd probably be nicer to use a temporary for
qcb->csr[index] too.

Also, the += is kind of odd.  These are really a
le16_to_cpu conversion, so it might be nicer to use
that mechanism.

csr->srcport_lo = get_unaligned_le16([pos]);
pos += 2;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] drivers:staging:gdm72xx Fix line over 80 characters


On 10/31, Joe Perches wrote:

On Sat, 2015-10-31 at 15:00 +0100, Bogicevic Sasa wrote:

This fixes line over 80 characters message from checkpatch.pl

[]

diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
b/drivers/staging/gdm72xx/gdm_qos.c

[]

@@ -382,7 +382,8 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
size)

spin_lock_irqsave(>qos_lock, flags);
qcb->csr[index].sfid = sfid;
-   qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) & 
0xff00);
+   qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) &
+   0xff00);


Probably better to remove the unnecessary parentheses instead

qcb->csr[index].classifier_rule_en = (buf[pos++] << 8) & 0xff00;




You're right, I just sent a new patch.

Thanks, 
Sasa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers:staging:gdm72xx Fix line over 80 characters

This fixes line over 80 character messages from checkpatch.pl

Signed-off-by: Bogicevic Sasa 
---
 drivers/staging/gdm72xx/gdm_qos.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
b/drivers/staging/gdm72xx/gdm_qos.c
index c03204b..44d04bd 100644
--- a/drivers/staging/gdm72xx/gdm_qos.c
+++ b/drivers/staging/gdm72xx/gdm_qos.c
@@ -382,7 +382,7 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
size)
 
spin_lock_irqsave(>qos_lock, flags);
qcb->csr[index].sfid = sfid;
-   qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) & 
0xff00);
+   qcb->csr[index].classifier_rule_en = (buf[pos++] << 8) & 0xff00;
qcb->csr[index].classifier_rule_en += buf[pos++];
if (qcb->csr[index].classifier_rule_en == 0)
qcb->qos_null_idx = index;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 5/5] perf report: Fix segfault on -g fractral with --stdio

2015-10-31 Thread Jiri Olsa

On Sat, Oct 31, 2015 at 02:15:38AM +0900, Namhyung Kim wrote:

SNIP

>  
>   if (!rem_sq_bracket)
>   return ret;
>  
> + if (callchain_param.value == CCVAL_COUNT) {
> + rem_node.count = child->parent->children_count - 
> cumul_count;
> + if (rem_node.count <= 0)
> + return ret;
> + }
> +
>   new_depth_mask &= ~(1 << (depth - 1));
> - ret += ipchain__fprintf_graph(fp, NULL, _hits, depth,
> + ret += ipchain__fprintf_graph(fp, _node, _hits, depth,
> new_depth_mask, 0, total_samples,
> left_margin);

this looks like being introduced within your patchset in patch:
  perf callchain: Abstract callchain print function

shouldn't it get fixed in there?

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Francois Romieu  writes:

>> +static int nb8800_poll(struct napi_struct *napi, int budget)
>> +{
>> +struct net_device *dev = napi->dev;
>> +struct nb8800_priv *priv = netdev_priv(dev);
>> +struct nb8800_dma_desc *rx;
>> +int work = 0;
>> +int last = priv->rx_eoc;
>> +int next;
>> +
>> +while (work < budget) {
>> +struct rx_buf *rx_buf;
>> +u32 report;
>> +int len;
>> +
>> +next = (last + 1) & (RX_DESC_COUNT - 1);
>> +
>> +rx_buf = >rx_bufs[next];
>> +rx = >rx_descs[next];
>> +report = rx->report;
>> +
>> +if (!report)
>> +break;
>> +
>> +if (IS_RX_ERROR(report)) {
>> +nb8800_rx_error(dev, report);
>> +} else if (likely(rx_buf->page)) {
>> +len = RX_BYTES_TRANSFERRED(report);
>> +nb8800_receive(dev, next, len);
>> +}
>> +
>> +rx->report = 0;
>> +if (!rx_buf->page)
>> +nb8800_alloc_rx(dev, next, true);
>
> It looks like it receives, then tries to allocate new resources. If so
> it may deplete the ring and you should instead consider allocating new
> resources first, then receive data if alloc + map suceeded.

The hardware receives a frame and stores it in the provided DMA buffer,
then raises an interrupt and moves on to the next buffer.  When a buffer
is handed over to the network stack, a new one has to take its place in
the DMA queue.  I'm not sure how you're suggesting this be done
differently.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer

2015-10-31 Thread Alan Stern

On Sat, 31 Oct 2015, Rafael J. Wysocki wrote:

> Runtime PM uses a freezable workqueue, allocated in pm_start_workqueue().
> 
> That's because we don't want async runtime PM to happen during system
> suspend/resume and for good reasons, so if you want to remove the freezing
> mechanism, you need to stop that workqueue at the beginning of dpm_prepare
> and start it again at the end of dpm_complete().

The same sort of thing is true for the USB hub driver's workqueue.  
Since it registers new devices (as a result of hotplugs), it must stop
running at the beginning of the dpm_prepare stage.  Of course, that's
also a workqueue and not a kthread.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] drivers:staging:gdm72xx Fix line over 80 characters

2015-10-31 Thread Joe Perches

On Sat, 2015-10-31 at 15:00 +0100, Bogicevic Sasa wrote:
> This fixes line over 80 characters message from checkpatch.pl
[]
> diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
> b/drivers/staging/gdm72xx/gdm_qos.c
[]
> @@ -382,7 +382,8 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
> size)
>  
>   spin_lock_irqsave(>qos_lock, flags);
>   qcb->csr[index].sfid = sfid;
> - qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) & 
> 0xff00);
> + qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) &
> + 0xff00);

Probably better to remove the unnecessary parentheses instead

qcb->csr[index].classifier_rule_en = (buf[pos++] << 8) & 0xff00;



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer

2015-10-31 Thread Alan Stern

On Fri, 30 Oct 2015, Jiri Kosina wrote:

> On Fri, 30 Oct 2015, Alan Stern wrote:
> 
> > > > > I would say instead "no I/O is allowed from now on".  Maybe that's an 
> > > > > overstatement, but I think it comes closer to the truth.
> > > 
> > > But that's what PM callbacks are for.
> > 
> > Why are PM callbacks any more suitable than the freezer?  
> 
> Once the PM callback triggers, you know that you are really actually 
> undergoing suspend and have to do whatever is necessary.
> 
> OTOH, try_to_freeze() is a kind of "are we there yet?" polling, and the 
> whole state needs to be prepared pro-actively for suspend already when you 
> call it, each and every time, even if you are not going through suspend at 
> all.
> 
> That's sub-optimal, and very easy to get wrong over gradual code changes.

I think we are talking at cross purposes.  Your view of how a kthread 
works appears to be very different from mine.

Here's how I see it: A kthread performs some service, generally in a
big loop.  At certain points in that loop (perhaps only at the head),
the kthread will be in a suitable state for suspend: sufficiently
quiescent, no locks held, no I/O in progress, and so on.  At other
points, the kthread is not ready for suspend.

Therefore the fact that a PM callback tells you exactly when a supsend 
is about to occur is of no use.  The kthread can't act on that 
information directly, because most of the time it isn't ready for a 
suspend.  Only when it reaches one of its quiescent points will it be 
ready to do whatever is necessary -- which usually is nothing at all.

Given this picture, I don't see any alternative to a polling approach
of one kind or another.  At various quiescent points the kthread checks
to see if a suspend is imminent before moving forward.  At other times
the kthread can't handle suspend anyway, so it ignores the issue.  
This approach is exactly what try_to_freeze and friends support.

> > The most natural implementation would be for the callback routine to set 
> > a flag; at various strategic points the kthread would check the flag and 
> > if it was set, call a routine that sits around and waits for the suspend 
> > to be over.  
> 
> Could you name at least some existing kthreads that would actually *need* 
> such complex handling, instead of just waiting in schedule() until 
> suspend-resume cycle is over, given that PM callbacks do all the necessary 
> cleanup (putting HW to sleep, cancelling timers, etc) anyway?

Out of all the kthreads you modified in your patch 2/3, the only one
I'm familiar with is the one in f_mass_storage.c (the USB mass-storage
gadget driver).  That's kind of a special case, and I don't mind you
ripping out all the freezer stuff from it because its approach was
almost completely arbitrary all along.  AFAIK, we have never settled on
the right way for a USB gadget to handle system sleep.

Other cases I don't know about.  My argument is based on the general
analysis given above.  But consider one point: You said "instead of
just waiting in schedule() until suspend-resume cycle is over".  What
if, at the time of the PM callback, the kthread happens to be holding a
mutex that some driver needs to acquire while suspending?  If the
kthread just hops into schedule() and waits there, the suspend will
fail or deadlock.  This example shows that the situation is more
complicated than you make it appear.

> PM callback can always explicitly do kthread_stop() on a particular 
> kthread if really necessary.

Don't kthreads have to poll to find out when they need to stop?  How is 
that different from (or better than) polling to see when they need to 
freeze?

> > Also, you never replied to my question about suspend vs. hibernation.
> 
> The main point of freezer is to reach quiescent state wrt. filesystems 
> (metadata in memory need to be absolutely in sync with what's on disk). 
> That's no different between hibernation and s2ram, is it?

That was my point.  Since there's no difference, why did your patch 
talk about hibernation only, and not s2ram?

(Of course, some people like Len Brown have been arguing that for 
s2ram, the metadata in memory does _not_ need to be in sync with what's 
on disk.  I'm ignoring that for now, but such things would have to be 
taken into account when the final patch is written.)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RFC] tpm: seal with a policy

2015-10-31 Thread Jarkko Sakkinen

Support for sealing with a policy.

Two new options for trusted keys:

* 'policydigest=': provide a policydigest for the seal operation.
* 'policyhandle=': provide handle for a policy session for unsealing.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/Kconfig|  1 +
 drivers/char/tpm/tpm2-cmd.c | 20 +---
 include/keys/trusted-type.h |  3 +++
 security/keys/trusted.c | 26 --
 4 files changed, 45 insertions(+), 5 deletions(-)

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 3b84a8b..bd86261 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -6,6 +6,7 @@ menuconfig TCG_TPM
tristate "TPM Hardware Support"
depends on HAS_IOMEM
select SECURITYFS
+   select CRYPTO_HASH_INFO
---help---
  If you have a TPM security chip in your system, which
  implements the Trusted Computing Group's specification,
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index b08a0b4..6f567c3 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -463,6 +463,9 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
return -EINVAL;
}
 
+   if (options->policydigest_len > hash_digest_size[options->hash])
+   return -EINVAL;
+
rc = tpm_buf_init(, TPM2_ST_SESSIONS, TPM2_CC_CREATE);
if (rc)
return rc;
@@ -488,8 +491,17 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
 
tpm_buf_append_u16(, TPM2_ALG_KEYEDHASH);
tpm_buf_append_u16(, hash);
-   tpm_buf_append_u32(, TPM2_ATTR_USER_WITH_AUTH);
-   tpm_buf_append_u16(, 0); /* policy digest size */
+
+   if (options->policydigest_len) {
+   tpm_buf_append_u32(, 0);
+   tpm_buf_append_u16(, options->policydigest_len);
+   tpm_buf_append(, options->policydigest,
+  options->policydigest_len);
+   } else {
+   tpm_buf_append_u32(, TPM2_ATTR_USER_WITH_AUTH);
+   tpm_buf_append_u16(, 0);
+   }
+
tpm_buf_append_u16(, TPM2_ALG_NULL);
tpm_buf_append_u16(, 0);
 
@@ -617,7 +629,9 @@ static int tpm2_unseal(struct tpm_chip *chip,
return rc;
 
tpm_buf_append_u32(, blob_handle);
-   tpm2_buf_append_auth(, TPM2_RS_PW,
+   tpm2_buf_append_auth(,
+options->policyhandle ?
+options->policyhandle : TPM2_RS_PW,
 NULL /* nonce */, 0,
 0 /* session_attributes */,
 options->blobauth /* hmac */,
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index a6a1008..e4beeca 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -37,6 +37,9 @@ struct trusted_key_options {
unsigned char pcrinfo[MAX_PCRINFO_SIZE];
int pcrlock;
uint32_t hash;
+   uint32_t policydigest_len;
+   unsigned char *policydigest;
+   uint32_t policyhandle;
 };
 
 extern struct key_type key_type_trusted;
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index 7a87bcd..ea043ff 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -713,6 +713,8 @@ enum {
Opt_keyhandle, Opt_keyauth, Opt_blobauth,
Opt_pcrinfo, Opt_pcrlock, Opt_migratable,
Opt_hash,
+   Opt_policydigest,
+   Opt_policyhandle,
 };
 
 static const match_table_t key_tokens = {
@@ -726,6 +728,8 @@ static const match_table_t key_tokens = {
{Opt_pcrlock, "pcrlock=%s"},
{Opt_migratable, "migratable=%s"},
{Opt_hash, "hash=%s"},
+   {Opt_policydigest, "policydigest=%s"},
+   {Opt_policyhandle, "policyhandle=%s"},
{Opt_err, NULL}
 };
 
@@ -804,6 +808,17 @@ static int getoptions(char *c, struct trusted_key_payload 
*pay,
if (i == HASH_ALGO__LAST ||
(!res && i != HASH_ALGO_SHA1))
return -EINVAL;
+   case Opt_policydigest:
+   opt->policydigest_len = strlen(args[0].from);
+   opt->policydigest = kstrdup(args[0].from, GFP_KERNEL);
+   if (!opt->policydigest)
+   return -ENOMEM;
+   break;
+   case Opt_policyhandle:
+   res = kstrtoul(args[0].from, 16, );
+   if (res < 0)
+   return -EINVAL;
+   opt->policyhandle = handle;
break;
default:
return -EINVAL;
@@ -897,6 +912,13 @@ static struct trusted_key_options 
*trusted_options_alloc(void)
return options;
 }
 
+static void trusted_options_free(struct trusted_key_options *options)
+{
+   if (options->policydigest)
+

[PATCH 1/2] efi-pstore: fix kernel-doc argument name

2015-10-31 Thread Geliang Tang

The first argument name in the kernel-doc argument list for
efi_pstore_scan_sysfs_enter() was slightly off. Fix it for the
kernel doc.

Signed-off-by: Geliang Tang 
---
 drivers/firmware/efi/efi-pstore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/efi-pstore.c 
b/drivers/firmware/efi/efi-pstore.c
index c8d794c..eac76a7 100644
--- a/drivers/firmware/efi/efi-pstore.c
+++ b/drivers/firmware/efi/efi-pstore.c
@@ -103,7 +103,7 @@ static int efi_pstore_read_func(struct efivar_entry *entry, 
void *data)
 
 /**
  * efi_pstore_scan_sysfs_enter
- * @entry: scanning entry
+ * @pos: scanning entry
  * @next: next entry
  * @head: list head
  */
-- 
2.4.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] pstore: fix code comment to match code

2015-10-31 Thread Geliang Tang

Fix code comment about kmsg_dump register so it matches the code.

Signed-off-by: Geliang Tang 
---
 fs/pstore/platform.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 0aab920..588461b 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -361,6 +361,9 @@ static struct kmsg_dumper pstore_dumper = {
.dump = pstore_dump,
 };
 
+/*
+ * Register with kmsg_dump to save last part of console log on panic.
+ */
 static void pstore_register_kmsg(void)
 {
kmsg_dump_register(_dumper);
@@ -434,8 +437,6 @@ static int pstore_write_compat(enum pstore_type_id type,
  * read function right away to populate the file system. If not
  * then the pstore mount code will call us later to fill out
  * the file system.
- *
- * Register with kmsg_dump to save last part of console log on panic.
  */
 int pstore_register(struct pstore_info *psi)
 {
-- 
2.4.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 09/11] mtd: drop unnecessary partition parser data

2015-10-31 Thread Marek Vasut

On Saturday, October 31, 2015 at 04:33:28 AM, Brian Norris wrote:
> We should assign the MTD dev.of_node instead of the parser data field.
> This gets us the equivalent partition parser behavior with fewer special
> fields and parameter passing.
> 
> Also convert several of these to mtd_device_register(), since we don't
> need the 2nd and 3rd parameters anymore.
> 
> Signed-off-by: Brian Norris 

[...]

> diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
> index e46b4e983666..b78265688075 100644
> --- a/drivers/mtd/maps/physmap_of.c
> +++ b/drivers/mtd/maps/physmap_of.c
> @@ -166,7 +166,6 @@ static int of_flash_probe(struct platform_device *dev)
>   int reg_tuple_size;
>   struct mtd_info **mtd_list = NULL;
>   resource_size_t res_size;
> - struct mtd_part_parser_data ppdata;
>   bool map_indirect;
>   const char *mtd_name = NULL;
> 
> @@ -310,13 +309,13 @@ static int of_flash_probe(struct platform_device
> *dev) if (err)
>   goto err_out;
> 
> - ppdata.of_node = dp;
> + mtd_set_of_node(info->cmtd, dp);
>   part_probe_types = of_get_probes(dp);
>   if (!part_probe_types) {
>   err = -ENOMEM;
>   goto err_out;
>   }
> - mtd_device_parse_register(info->cmtd, part_probe_types, ,
> + mtd_device_parse_register(info->cmtd, part_probe_types, NULL,

Did you miss this one ?

>   NULL, 0);
>   of_free_probes(part_probe_types);
> 


This is really good, I like to see the ppdata nonsense finally going away.

Reviewed-by: Marek Vasut 

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] x86/signal/64: Add a comment about sigcontext->fs and gs

2015-10-31 Thread Stas Sergeev


26.10.2015 04:25, Andy Lutomirski пишет:

These fields have a strange history.  This tries to document it.

This borrows from 9a036b93a344 ("x86/signal/64: Remove 'fs' and 'gs'
from sigcontext"), which was reverted by ed596cde9425 ("Revert x86
sigcontext cleanups").

Signed-off-by: Andy Lutomirski 

Now the strategy about SS is to always save it to the sigcontext.
This is good because the syscall can clobber it, so the app had
to be very careful in the past trying to save it by hands.
How about saving also fs and gs? (without restoring yet)
If you do, you'll save dosemu a headache of doing any "pre-syscall"
work. Pre-syscall work is very nasty.
I haven't checked if the syscall clobber also these or only SS,
but perhaps saving them by the kernel won't hurt?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] v4.1.10-rt11

2015-10-31 Thread Thomas Gleixner

Dear RT folks!

I'm pleased to announce the v4.1.10-rt11 patch set.

Changes since v4.1.10-rt11:

  Eric Dumazet (1):
  inet: fix potential deadlock in reqsk_queue_unlink()

  Josh Cartwright (1):
  net: Make synchronize_rcu_expedited() conditional on !RT_FULL

  Mathieu Desnoyers (1):
  latency_hist: Update sched_wakeup probe

  Peter Zijlstra (1):
  sched: Introduce the trace_sched_waking tracepoint

  Thomas Gleixner (2):
  softirq: Sanitize local_bh_[en|dis]able for RT
  v4.1.10-rt11

  Yang Shi (1):
  trace: Add missing tracer macros

Known issues:

  - bcache stays disabled

  - CPU hotplug is not better than before

  - The netlink_release() OOPS, reported by Clark, is still on the
list, but unsolved due to lack of information

The delta patch against 4.1.10-rt10 is appended below and can be found here:


https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.1/incr/patch-4.1.10-rt10-rt11.patch.xz

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git 
v4.1.10-rt11

The RT patch against 4.1.10 can be found here:


https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.1/patch-4.1.10-rt11.patch.xz

The split quilt queue is available at:


https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.1/patches-4.1.10-rt11.tar.xz

Enjoy!

tglx

---

diff --git a/include/linux/bottom_half.h b/include/linux/bottom_half.h
index 8ca9389352f2..d3c0c02acc97 100644
--- a/include/linux/bottom_half.h
+++ b/include/linux/bottom_half.h
@@ -6,12 +6,34 @@
 
 #ifdef CONFIG_PREEMPT_RT_FULL
 
-extern void local_bh_disable(void);
+extern void __local_bh_disable(void);
 extern void _local_bh_enable(void);
-extern void local_bh_enable(void);
-extern void local_bh_enable_ip(unsigned long ip);
-extern void __local_bh_disable_ip(unsigned long ip, unsigned int cnt);
-extern void __local_bh_enable_ip(unsigned long ip, unsigned int cnt);
+extern void __local_bh_enable(void);
+
+static inline void local_bh_disable(void)
+{
+   __local_bh_disable();
+}
+
+static inline void __local_bh_disable_ip(unsigned long ip, unsigned int cnt)
+{
+   __local_bh_disable();
+}
+
+static inline void local_bh_enable(void)
+{
+   __local_bh_enable();
+}
+
+static inline void __local_bh_enable_ip(unsigned long ip, unsigned int cnt)
+{
+   __local_bh_enable();
+}
+
+static inline void local_bh_enable_ip(unsigned long ip)
+{
+   __local_bh_enable();
+}
 
 #else
 
diff --git a/include/trace/events/hist.h b/include/trace/events/hist.h
index 6122e4286177..37f6eb8c9dc2 100644
--- a/include/trace/events/hist.h
+++ b/include/trace/events/hist.h
@@ -9,6 +9,7 @@
 
 #if !defined(CONFIG_PREEMPT_OFF_HIST) && !defined(CONFIG_INTERRUPT_OFF_HIST)
 #define trace_preemptirqsoff_hist(a, b)
+#define trace_preemptirqsoff_hist_rcuidle(a, b)
 #else
 TRACE_EVENT(preemptirqsoff_hist,
 
@@ -33,6 +34,7 @@ TRACE_EVENT(preemptirqsoff_hist,
 
 #ifndef CONFIG_MISSED_TIMER_OFFSETS_HIST
 #define trace_hrtimer_interrupt(a, b, c, d)
+#define trace_hrtimer_interrupt_rcuidle(a, b, c, d)
 #else
 TRACE_EVENT(hrtimer_interrupt,
 
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 30fedaf3e56a..3b63828390a6 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -55,9 +55,9 @@ TRACE_EVENT(sched_kthread_stop_ret,
  */
 DECLARE_EVENT_CLASS(sched_wakeup_template,
 
-   TP_PROTO(struct task_struct *p, int success),
+   TP_PROTO(struct task_struct *p),
 
-   TP_ARGS(__perf_task(p), success),
+   TP_ARGS(__perf_task(p)),
 
TP_STRUCT__entry(
__array(char,   comm,   TASK_COMM_LEN   )
@@ -71,25 +71,37 @@ DECLARE_EVENT_CLASS(sched_wakeup_template,
memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid= p->pid;
__entry->prio   = p->prio;
-   __entry->success= success;
+   __entry->success= 1; /* rudiment, kill when possible */
__entry->target_cpu = task_cpu(p);
),
 
-   TP_printk("comm=%s pid=%d prio=%d success=%d target_cpu=%03d",
+   TP_printk("comm=%s pid=%d prio=%d target_cpu=%03d",
  __entry->comm, __entry->pid, __entry->prio,
- __entry->success, __entry->target_cpu)
+ __entry->target_cpu)
 );
 
+/*
+ * Tracepoint called when waking a task; this tracepoint is guaranteed to be
+ * called from the waking context.
+ */
+DEFINE_EVENT(sched_wakeup_template, sched_waking,
+TP_PROTO(struct task_struct *p),
+TP_ARGS(p));
+
+/*
+ * Tracepoint called when the task is actually woken; p->state == TASK_RUNNNG.
+ * It it not always called from the waking context.
+ */
 DEFINE_EVENT(sched_wakeup_template, sched_wakeup,
-TP_PROTO(struct task_struct *p, int success),
-TP_ARGS(p, success));
+TP_PROTO(struct task_struct *p),
+

Re: [RFD] Functional dependencies between devices

2015-10-31 Thread Alan Stern

On Sat, 31 Oct 2015, Rafael J. Wysocki wrote:

> > One possible approach is to have a "wait_for_driver" flag, along with a
> > timeout value (or perhaps using a fixed timeout value).  When a
> > dependency gets registered with this flag set, the function call
> > wouldn't return until the target device is bound to a driver or the
> > timeout has elapsed.
> > 
> > This would make it easy to insert dependencies at probe time without 
> > relying on deferred probing.
> 
> I'm not sure about this to be honest.  It seems like implementing it might
> be sort of tricky.

Well, clearly it wouldn't work if probes were serialized and one driver
was dependent on another that was going to be probed later.  But if
probes are asynchronous then it ought to be okay (unless there is a
dependency cycle, in which case the situation is hopeless anyway).

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 04/11] mtd: nand: convert to nand_set_flash_node()

2015-10-31 Thread Marek Vasut

On Saturday, October 31, 2015 at 04:33:23 AM, Brian Norris wrote:
> Used semantic patch with 'make coccicheck MODE=patch COCCI=script.cocci':
> 
> ---8<
> virtual patch
> 
> @@
> struct nand_chip *c;
> struct device_node *d;
> @@
> -(c)->flash_node = (d)
> +nand_set_flash_node(c, d)
> ---8<
> 
> Signed-off-by: Brian Norris 

Thanks for the educational commit message!

Patch is
Reviewed-by: Marek Vasut 

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

2015-10-31 Thread Stas Sergeev


26.10.2015 04:25, Andy Lutomirski пишет:

This is a second attempt to make the improvements from c6f2062935c8
("x86/signal/64: Fix SS handling for signals delivered to 64-bit
programs"), which was reverted by 51adbfbba5c6 ("x86/signal/64: Add
support for SS in the 64-bit signal context").

This adds two new uc_flags flags.  UC_SIGCONTEXT_SS will be set for
all 64-bit signals (including x32).  It indicates that the saved SS
field is valid and that the kernel supports the new behavior.

The goal is to fix a problems with signal handling in 64-bit tasks:
SS wasn't saved in the 64-bit signal context, making it awkward to
determine what SS was at the time of signal delivery and making it
impossible to return to a non-flat SS (as calling sigreturn clobbers
SS).

This also made it extremely difficult for 64-bit tasks to return to
fully-defined 16-bit contexts, because only the kernel can easily do
espfix64, but sigreturn was unable to load or even restore SS:ESP.
(DOSEMU has a monstrous hack to partially work around this.)

If we could go back in time, the correct fix would be to make 64-bit
signals work just like 32-bit signals with respect to SS: save it
in signal context, reset it when delivering a signal, and restore
it in sigreturn.

Unfortunately, doing that (as I tried originally) breaks DOSEMU:
DOSEMU wouldn't reset the signal context's SS when clearing the LDT
and changing the saved CS to 64-bit mode, since it predates the SS
context field existing in the first place.

This patch is a bit more complicated, and it tries to balance a
bunch of goals.  It makes signal delivery due to a bogus SS reliable
without having to set any flags (64-bit signals will always be
delivered to a valid SS), and it makes most cases of changing
ucontext->ss during signal handling work as expected.

I do this by special-casing the interesting case.  On sigreturn,
ucontext->ss will be honored by default, unless the ucontext was
created from scratch by an old program and had a 64-bit CS
(unfortunately, CRIU can do this) or was the result of changing a
32-bit signal context to 64-bit without resetting SS (as DOSEMU
does).

For the benefit of new 64-bit software that uses segmentation (new
versions of DOSEMU might), the new behavior can be detected with a
new ucontext flag UC_SIGCONTEXT_SS.

To avoid compilation issues, __pad0 is left as an alias for ss in
ucontext.

The nitty-gritty details are documented in the header file.

Cc: Stas Sergeev 
Cc: Linus Torvalds 
Cc: Cyrill Gorcunov 
Cc: Pavel Emelyanov 
Signed-off-by: Andy Lutomirski 

Tested-by: Stas Sergeev 

Both dosemu2 and 1 work fine.
Still as this approach seems very risky, I'd appreciate if some
of the explanations from this msg:
https://lkml.org/lkml/2015/10/14/726
go into the code comments.
What I find especially useful are your notes about
siglongjmp(), threads, and the fact that running with bad
SS is now impossible on the recent kernels. Without this
info at hands, no one can trust this code perhaps.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipc/msg: Implement lockless pipelined wakeups

2015-10-31 Thread Thomas Gleixner

On Sat, 31 Oct 2015, George Spelvin wrote:
> > Don't we need to keep that NULL init? I might be missing something.
> 
> I wondered the same thing, but on reading it, the cleanup is that he's
> gotten rid of the need for the entire thing.  Previously, there was a
> mechanism for detecting "wakeup not quite finished" that used a NULL
> value, but it's no longer needed.
> 
> The resultant busy-waiting on the part of the woken-up task was the
> entire problem this patch aims to fix.  So it gets rid of a whole lot
> of code and barriers.  And, as you noticed, the comments explaining them.
> 
> As the old code explained, the issue is that a task may exit as
> soon as r_msg is set, so the wakeup procedure has to be:
> - Ensure r_msg is set to NULL (special-case flag)
> - Do the wake up
> - Set r_msg to the final value
> 
> The woken-up task has to spin as long as r_msg is NULL.  Ick.
> 
> However, a wake_q keeps a reference to a task, so exiting is
> not a danger.  As long as wake_q_add precedes setting r_msg,
> all is well.

Right. I figured that after staring some more into it. Though it would
be nice if exactly that explanation is in the code.

Thanks,

tglx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: of: removing two variables min_uV and max_uV

2015-10-31 Thread Saurabh Sengar

replacing the of_get_property function with of_property_read_u32 function
as its help removing two variables.
also the check for min_uV and max_uV is not required, even if they are
zero and equal we should set apply_uV as true

Signed-off-by: Saurabh Sengar 
---
 drivers/regulator/of_regulator.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 250700c..e419789 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -28,7 +28,6 @@ static void of_get_regulation_constraints(struct device_node 
*np,
struct regulator_init_data **init_data,
const struct regulator_desc *desc)
 {
-   const __be32 *min_uV, *max_uV;
struct regulation_constraints *constraints = &(*init_data)->constraints;
struct regulator_state *suspend_state;
struct device_node *suspend_np;
@@ -37,18 +36,16 @@ static void of_get_regulation_constraints(struct 
device_node *np,
 
constraints->name = of_get_property(np, "regulator-name", NULL);
 
-   min_uV = of_get_property(np, "regulator-min-microvolt", NULL);
-   if (min_uV)
-   constraints->min_uV = be32_to_cpu(*min_uV);
-   max_uV = of_get_property(np, "regulator-max-microvolt", NULL);
-   if (max_uV)
-   constraints->max_uV = be32_to_cpu(*max_uV);
+   if (!of_property_read_u32(np, "regulator-min-microvolt", ))
+   constraints->min_uV = pval;
+   if (!of_property_read_u32(np, "regulator-max-microvolt", ))
+   constraints->max_uV = pval;
 
/* Voltage change possible? */
if (constraints->min_uV != constraints->max_uV)
constraints->valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE;
/* Only one voltage?  Then make sure it's set. */
-   if (min_uV && max_uV && constraints->min_uV == constraints->max_uV)
+   if (constraints->min_uV == constraints->max_uV)
constraints->apply_uV = true;
 
if (!of_property_read_u32(np, "regulator-microvolt-offset", ))
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/3] USB: serial: cp210x: Workaround cp2108 GET_LINE_CTL bug

2015-10-31 Thread Konstantin Shkolnyy

On Sat, Oct 31, 2015 at 7:16 AM, Johan Hovold  wrote:
> [ Please avoid top-posting. ]
>
> On Thu, Oct 29, 2015 at 08:39:04AM -0500, Konstantin Shkolnyy wrote:
>> I tested it on cp2102, cp2105 and cp2108.
>> I'm a little worried about that extra PURGE command, so I did several
>> manual tests on each with a standard PC serial port on the other end
>> of the cable.
>> - run several open/write/close iteration (the test that used to break
>> cp2108), observe data on the other end;
>> - open minicom and see that cp210x can still receive data from the other end.
>
> Sounds good.
>
> If this turns out to cause any problems, we can always enable this based
> on chip type, right? I saw something about a vendor request for that in
> your (silabs') vendor driver.

Yes, there is a register with the chip type.

[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] zram: move init_done check to the beginning of disksize_store

2015-10-31 Thread Geliang Tang

If we set disksize when disksize has been set, we will get the following
error report: "write error: Cannot allocate memory". This is because
disksize_store fails at zram_meta_alloc. This is not what we expect.
To solve this problem, this patch moves init_done check to the beginning
of disksize_store.

Signed-off-by: Geliang Tang 
---
 drivers/block/zram/zram_drv.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 81a557c..609fc2b 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1028,6 +1028,14 @@ static ssize_t disksize_store(struct device *dev,
struct zram *zram = dev_to_zram(dev);
int err;
 
+   down_read(>init_lock);
+   if (init_done(zram)) {
+   up_read(>init_lock);
+   pr_info("Cannot change disksize for initialized device\n");
+   return -EBUSY;
+   }
+   up_read(>init_lock);
+
disksize = memparse(buf, NULL);
if (!disksize)
return -EINVAL;
@@ -1046,12 +1054,6 @@ static ssize_t disksize_store(struct device *dev,
}
 
down_write(>init_lock);
-   if (init_done(zram)) {
-   pr_info("Cannot change disksize for initialized device\n");
-   err = -EBUSY;
-   goto out_destroy_comp;
-   }
-
init_waitqueue_head(>io_done);
atomic_set(>refcount, 1);
zram->meta = meta;
@@ -1069,9 +1071,6 @@ static ssize_t disksize_store(struct device *dev,
 
return len;
 
-out_destroy_comp:
-   up_write(>init_lock);
-   zcomp_destroy(comp);
 out_free_meta:
zram_meta_free(meta, disksize);
return err;
-- 
2.4.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] drivers:staging:gdm72xx Fix line over 80 characters

This fixes line over 80 characters message from checkpatch.pl

Signed-off-by: Bogicevic Sasa 
---
 drivers/staging/gdm72xx/gdm_qos.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
b/drivers/staging/gdm72xx/gdm_qos.c
index c03204b..0625a54 100644
--- a/drivers/staging/gdm72xx/gdm_qos.c
+++ b/drivers/staging/gdm72xx/gdm_qos.c
@@ -382,7 +382,8 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
size)
 
spin_lock_irqsave(>qos_lock, flags);
qcb->csr[index].sfid = sfid;
-   qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) & 
0xff00);
+   qcb->csr[index].classifier_rule_en = ((buf[pos++] << 8) &
+   0xff00);
qcb->csr[index].classifier_rule_en += buf[pos++];
if (qcb->csr[index].classifier_rule_en == 0)
qcb->qos_null_idx = index;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers:staging:gdm72xx Fix spaces preferred around...

This fixes all messages "spaces preferred around..." from
checkpatch.pl script

Signed-off-by: Bogicevic Sasa 
---
 drivers/staging/gdm72xx/gdm_qos.c | 54 +++
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
b/drivers/staging/gdm72xx/gdm_qos.c
index 81feffa..c03204b 100644
--- a/drivers/staging/gdm72xx/gdm_qos.c
+++ b/drivers/staging/gdm72xx/gdm_qos.c
@@ -101,7 +101,7 @@ void gdm_qos_init(void *nic_ptr)
}
 
qcb->qos_list_cnt = 0;
-   qcb->qos_null_idx = QOS_MAX-1;
+   qcb->qos_null_idx = QOS_MAX - 1;
qcb->qos_limit_size = 255;
 
spin_lock_init(>qos_lock);
@@ -128,7 +128,7 @@ void gdm_qos_release_list(void *nic_ptr)
}
 
qcb->qos_list_cnt = 0;
-   qcb->qos_null_idx = QOS_MAX-1;
+   qcb->qos_null_idx = QOS_MAX - 1;
 
for (i = 0; i < QOS_MAX; i++) {
list_for_each_entry_safe(entry, n, >qos_list[i], list) {
@@ -143,18 +143,18 @@ static int chk_ipv4_rule(struct gdm_wimax_csr_s *csr, u8 
*stream, u8 *port)
 {
int i;
 
-   if (csr->classifier_rule_en) {
+   if (csr->classifier_rule_en & IPTYPEOFSERVICE) {
if (((stream[1] & csr->ip2s_mask) < csr->ip2s_lo) ||
((stream[1] & csr->ip2s_mask) > csr->ip2s_hi))
return 1;
}
 
-   if (csr->classifier_rule_en) {
+   if (csr->classifier_rule_en & PROTOCOL) {
if (stream[9] != csr->protocol)
return 1;
}
 
-   if (csr->classifier_rule_en) {
+   if (csr->classifier_rule_en & IPMASKEDSRCADDRESS) {
for (i = 0; i < 4; i++) {
if ((stream[12 + i] & csr->ipsrc_addrmask[i]) !=
(csr->ipsrc_addr[i] & csr->ipsrc_addrmask[i]))
@@ -162,7 +162,7 @@ static int chk_ipv4_rule(struct gdm_wimax_csr_s *csr, u8 
*stream, u8 *port)
}
}
 
-   if (csr->classifier_rule_en) {
+   if (csr->classifier_rule_en & IPMASKEDDSTADDRESS) {
for (i = 0; i < 4; i++) {
if ((stream[16 + i] & csr->ipdst_addrmask[i]) !=
(csr->ipdst_addr[i] & csr->ipdst_addrmask[i]))
@@ -170,14 +170,14 @@ static int chk_ipv4_rule(struct gdm_wimax_csr_s *csr, u8 
*stream, u8 *port)
}
}
 
-   if (csr->classifier_rule_en) {
-   i = ((port[0]<<8)&0xff00)+port[1];
+   if (csr->classifier_rule_en & PROTOCOLSRCPORTRANGE) {
+   i = ((port[0] << 8) & 0xff00) + port[1];
if ((i < csr->srcport_lo) || (i > csr->srcport_hi))
return 1;
}
 
-   if (csr->classifier_rule_en) {
-   i = ((port[2]<<8)&0xff00)+port[3];
+   if (csr->classifier_rule_en & PROTOCOLDSTPORTRANGE) {
+   i = ((port[2] << 8) & 0xff00) + port[3];
if ((i < csr->dstport_lo) || (i > csr->dstport_hi))
return 1;
}
@@ -193,7 +193,7 @@ static int get_qos_index(struct nic *nic, u8 *iph, u8 
*tcpudph)
if (!iph || !tcpudph)
return -1;
 
-   ip_ver = (iph[0]>>4)&0xf;
+   ip_ver = (iph[0] >> 4) & 0xf;
 
if (ip_ver != 4)
return -1;
@@ -261,7 +261,7 @@ int gdm_qos_send_hci_pkt(struct sk_buff *skb, struct 
net_device *dev)
struct list_head send_list;
int ret = 0;
 
-   tcph = (struct tcphdr *)iph + iph->ihl*4;
+   tcph = (struct tcphdr *)iph + iph->ihl * 4;
 
if (ethh->h_proto == cpu_to_be16(ETH_P_IP)) {
if (qcb->qos_list_cnt && !qos_free_list.cnt) {
@@ -342,17 +342,17 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
size)
if (sub_cmd_evt == QOS_REPORT) {
spin_lock_irqsave(>qos_lock, flags);
for (i = 0; i < qcb->qos_list_cnt; i++) {
-   sfid = ((buf[(i*5)+6]<<24)&0xff00);
-   sfid += ((buf[(i*5)+7]<<16)&0xff);
-   sfid += ((buf[(i*5)+8]<<8)&0xff00);
-   sfid += (buf[(i*5)+9]);
+   sfid = ((buf[(i * 5) + 6] << 24) & 0xff00);
+   sfid += ((buf[(i * 5) + 7] << 16) & 0xff);
+   sfid += ((buf[(i * 5) + 8] << 8) & 0xff00);
+   sfid += (buf[(i * 5) + 9]);
index = get_csr(qcb, sfid, 0);
if (index == -1) {
spin_unlock_irqrestore(>qos_lock, flags);
netdev_err(nic->netdev, "QoS ERROR: No SF\n");
return;
}
-   qcb->csr[index].qos_buf_count = buf[(i*5)+10];
+   qcb->csr[index].qos_buf_count = buf[(i * 5) + 10];
}
 
extract_qos_list(nic, _list);
@@ -363,9 +363,9 @@ void gdm_recv_qos_hci_packet(void

Re: [PATCH] bpf: convert hashtab lock to raw lock

2015-10-31 Thread Steven Rostedt

On Fri, 30 Oct 2015 17:03:58 -0700
Alexei Starovoitov  wrote:

> On Fri, Oct 30, 2015 at 03:16:26PM -0700, Yang Shi wrote:
> > When running bpf samples on rt kernel, it reports the below warning:
> > 
> > BUG: sleeping function called from invalid context at 
> > kernel/locking/rtmutex.c:917
> > in_atomic(): 1, irqs_disabled(): 128, pid: 477, name: ping
> > Preemption disabled at:[] kprobe_perf_func+0x30/0x228  
> ...
> > diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> > index 83c209d..972b76b 100644
> > --- a/kernel/bpf/hashtab.c
> > +++ b/kernel/bpf/hashtab.c
> > @@ -17,7 +17,7 @@
> >  struct bpf_htab {
> > struct bpf_map map;
> > struct hlist_head *buckets;
> > -   spinlock_t lock;
> > +   raw_spinlock_t lock;  
> 
> How do we address such things in general?
> I bet there are tons of places around the kernel that
> call spin_lock from atomic.
> I'd hate to lose the benefits of lockdep of non-raw spin_lock
> just to make rt happy.

You wont lose any benefits of lockdep. Lockdep still checks
raw_spin_lock(). The only difference between raw_spin_lock and
spin_lock is that in -rt spin_lock turns into an rt_mutex() and
raw_spin_lock stays a spin lock.

The error is that in -rt, you called a mutex and not a spin lock while
atomic.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 20/20] ARC: Add eznps platform to Kconfig and Makefile

From: Noam Camus 

This commit should be left last since only now eznps platform
is in state which one can actually use.
Signed-off-by: Noam Camus 
---
 arch/arc/Kconfig  |1 +
 arch/arc/Makefile |9 +
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 689ccb3..8153b79 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -91,6 +91,7 @@ source "arch/arc/plat-sim/Kconfig"
 source "arch/arc/plat-tb10x/Kconfig"
 source "arch/arc/plat-axs10x/Kconfig"
 #New platform adds here
+source "arch/arc/plat-eznps/Kconfig"
 
 endmenu
 
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 8a27a48..9e5928f 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -99,6 +99,15 @@ core-y   += arch/arc/boot/dts/
 core-$(CONFIG_ARC_PLAT_SIM)+= arch/arc/plat-sim/
 core-$(CONFIG_ARC_PLAT_TB10X)  += arch/arc/plat-tb10x/
 core-$(CONFIG_ARC_PLAT_AXS10X) += arch/arc/plat-axs10x/
+core-$(CONFIG_ARC_PLAT_EZNPS)  += arch/arc/plat-eznps/
+
+ifdef CONFIG_ARC_PLAT_EZNPS
+ifeq ($(KBUILD_SRC),)
+KBUILD_CPPFLAGS += -Iarch/arc/plat-eznps/include
+else
+KBUILD_CPPFLAGS += -I$(srctree)/arch/arc/plat-eznps/include
+endif
+endif
 
 drivers-$(CONFIG_OPROFILE) += arch/arc/oprofile/
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 19/20] ARC: [plat-eznps] replace sync with proper cpu barrier

From: Tal Zilcer 

In SMT system like we have the generic "sync" is not working with
HW threads. The replacement is "schd.rw" instruction that is served
as cpu barrier for HW threads.
Signed-off-by: Noam Camus 
---
 arch/arc/kernel/ctx_sw.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arc/kernel/ctx_sw.c b/arch/arc/kernel/ctx_sw.c
index 92e2e82..2a2f50e 100644
--- a/arch/arc/kernel/ctx_sw.c
+++ b/arch/arc/kernel/ctx_sw.c
@@ -61,7 +61,11 @@ __switch_to(struct task_struct *prev_task, struct 
task_struct *next_task)
"st  sp, [r24]   \n\t"
 #endif
 
+#ifdef CONFIG_EZNPS_MTM_EXT
+   ".word %5   \n\t"
+#else
"sync   \n\t"
+#endif
 
/*
 * setup _current_task with incoming tsk.
@@ -122,6 +126,9 @@ __switch_to(struct task_struct *prev_task, struct 
task_struct *next_task)
 #ifdef CONFIG_ARC_PLAT_EZNPS
, "i"(CTOP_AUX_LOGIC_GLOBAL_ID)
 #endif
+#ifdef CONFIG_EZNPS_MTM_EXT
+   , "i"(CTOP_INST_SCHD_RW)
+#endif
: "blink"
);
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 18/20] ARC: [plat-eznps] define IPI_IRQ

From: Noam Camus 

We add IPI irq definition to be used later by any
irqchip such NPS400 IC.

Signed-off-by: Noam Camus 
---
 arch/arc/include/asm/irq.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arc/include/asm/irq.h b/arch/arc/include/asm/irq.h
index 4fd7d62..c5f8f0f 100644
--- a/arch/arc/include/asm/irq.h
+++ b/arch/arc/include/asm/irq.h
@@ -16,7 +16,11 @@
 #ifdef CONFIG_ISA_ARCOMPACT
 #define TIMER0_IRQ  3
 #define TIMER1_IRQ  4
+#if defined(CONFIG_SMP) && defined(CONFIG_ARC_PLAT_EZNPS)
+#define IPI_IRQ 5
+#else
 #define IPI_IRQ(NR_CPU_IRQS-1) /* dummy to enable SMP build 
for up hardware */
+#endif
 #else
 #define TIMER0_IRQ  16
 #define TIMER1_IRQ  17
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 17/20] ARC: [plat-eznps] Use dedicated COMMAND_LINE_SIZE

From: Noam Camus 

The default 256 bytes sometimes is just not enough.
We usually provide earlycon=... and console=... and ip=...
All this and more may need more room.

Signed-off-by: Noam Camus 
Acked-by: Vineet Gupta 
---
 arch/arc/include/asm/setup.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arc/include/asm/setup.h b/arch/arc/include/asm/setup.h
index 3078466..48b37c6 100644
--- a/arch/arc/include/asm/setup.h
+++ b/arch/arc/include/asm/setup.h
@@ -12,7 +12,11 @@
 #include 
 #include 
 
+#ifdef CONFIG_ARC_PLAT_EZNPS
+#define COMMAND_LINE_SIZE 2048
+#else
 #define COMMAND_LINE_SIZE 256
+#endif
 
 /*
  * Data structure to map a ID to string
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 16/20] ARC: [plat-eznps] Use dedicated cpu_relax()

From: Tal Zilcer 

Since the CTOP is SMT hardware multi-threaded, we need to hint
the HW that now will be a very good time to do a hardware
thread context switching. This is done by issuing the schd.rw
instruction (binary coded here so as to not require specific
revision of GCC to build the kernel).
sched.rw means that Thread becomes eligible for execution by
the threads scheduler after all pending read/write
transactions were completed.

Signed-off-by: Noam Camus 
Cc: Peter Zijlstra 
---
 arch/arc/include/asm/processor.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h
index 7266ede..f1a51a6 100644
--- a/arch/arc/include/asm/processor.h
+++ b/arch/arc/include/asm/processor.h
@@ -58,7 +58,12 @@ struct task_struct;
  * get optimised away by gcc
  */
 #ifdef CONFIG_SMP
+#ifdef CONFIG_EZNPS_MTM_EXT
+#define cpu_relax() \
+   __asm__ __volatile__ (".word %0" : : "i"(CTOP_INST_SCHD_RW) : "memory")
+#else
 #define cpu_relax()__asm__ __volatile__ ("" : : : "memory")
+#endif
 #else
 #define cpu_relax()do { } while (0)
 #endif
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 14/20] ARC: [plat-eznps] Use dedicated SMP barriers

From: Noam Camus 

NPS device got 256 cores and each got 16 HW threads (SMT).
We use EZchip dedicated ISA to trigger HW scheduler of the
core that current HW thread belongs to.
This scheduling makes sure that data beyond barrier is available
to all HW threads in core and by that to all in device (4K).

Signed-off-by: Noam Camus 
Cc: Peter Zijlstra 
---
 arch/arc/include/asm/barrier.h |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arc/include/asm/barrier.h b/arch/arc/include/asm/barrier.h
index a720998..c8229b8 100644
--- a/arch/arc/include/asm/barrier.h
+++ b/arch/arc/include/asm/barrier.h
@@ -34,6 +34,12 @@
 
 #ifdef CONFIG_ISA_ARCOMPACT
 
+#ifdef CONFIG_ARC_PLAT_EZNPS
+#include 
+#define mb()   asm volatile (".word %0" : : "i"(CTOP_INST_SCHD_RW) : "memory")
+#define rmb()  asm volatile (".word %0" : : "i"(CTOP_INST_SCHD_RD) : "memory")
+#else
+
 /*
  * ARCompact based cores (ARC700) only have SYNC instruction which is super
  * heavy weight as it flushes the pipeline as well.
@@ -41,6 +47,8 @@
  */
 
 #define mb()   asm volatile("sync\n" : : : "memory")
+#endif /* CONFIG_ARC_PLAT_EZNPS */
+
 #endif
 
 #include 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 15/20] ARC: [plat-eznps] Use dedicated identity auxiliary register.

From: Noam Camus 

With generic "identity" num of CPUs is limited to 256 (8 bit).
We use our alternative AUX register GLOBAL_ID (12 bit).
Now we can support up to 4096 CPUs.

Signed-off-by: Noam Camus 
---
 arch/arc/include/asm/entry-compact.h |8 
 arch/arc/kernel/ctx_sw.c |   13 +
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arc/include/asm/entry-compact.h 
b/arch/arc/include/asm/entry-compact.h
index 1aff3be..bf9a6a1 100644
--- a/arch/arc/include/asm/entry-compact.h
+++ b/arch/arc/include/asm/entry-compact.h
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include/* For THREAD_SIZE */
+#include 
 
 /*--
  * Switch to Kernel Mode stack if SP points to User Mode stack
@@ -298,9 +299,16 @@
 
 /* Get CPU-ID of this core */
 .macro  GET_CPU_ID  reg
+#ifdef CONFIG_ARC_PLAT_EZNPS
+   lr  \reg, [CTOP_AUX_LOGIC_GLOBAL_ID]
+#ifndef CONFIG_EZNPS_MTM_EXT
+   lsr \reg, \reg, 4
+#endif
+#else
lr  \reg, [identity]
lsr \reg, \reg, 8
bmsk \reg, \reg, 7
+#endif
 .endm
 
 #endif  /* __ASM_ARC_ENTRY_COMPACT_H */
diff --git a/arch/arc/kernel/ctx_sw.c b/arch/arc/kernel/ctx_sw.c
index c14a5be..92e2e82 100644
--- a/arch/arc/kernel/ctx_sw.c
+++ b/arch/arc/kernel/ctx_sw.c
@@ -16,6 +16,9 @@
 
 #include 
 #include 
+#ifdef CONFIG_ARC_PLAT_EZNPS
+#include 
+#endif
 
 #define KSP_WORD_OFF   ((TASK_THREAD + THREAD_KSP) / 4)
 
@@ -69,9 +72,16 @@ __switch_to(struct task_struct *prev_task, struct 
task_struct *next_task)
 #ifndef CONFIG_SMP
"st  %2, [@_current_task]   \n\t"
 #else
+#ifdef CONFIG_ARC_PLAT_EZNPS
+   "lr   r24, [%4] \n\t"
+#ifndef CONFIG_EZNPS_MTM_EXT
+   "lsr  r24, r24, 4   \n\t"
+#endif
+#else
"lr   r24, [identity]   \n\t"
"lsr  r24, r24, 8   \n\t"
"bmsk r24, r24, 7   \n\t"
+#endif
"add2 r24, @_current_task, r24  \n\t"
"st   %2,  [r24]\n\t"
 #endif
@@ -109,6 +119,9 @@ __switch_to(struct task_struct *prev_task, struct 
task_struct *next_task)
 
: "=r"(tmp)
: "n"(KSP_WORD_OFF), "r"(next), "r"(prev)
+#ifdef CONFIG_ARC_PLAT_EZNPS
+   , "i"(CTOP_AUX_LOGIC_GLOBAL_ID)
+#endif
: "blink"
);
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 13/20] ARC: [plat-eznps] Use dedicated bitops/atomic/cmpxchg

From: Noam Camus 

We need our own implementaions since we lack of LLSC.
Our extended ISA provided with optimized solution for all 32bit
operations we see in those three headers.
Signed-off-by: Noam Camus 
---
 arch/arc/include/asm/atomic.h   |   69 +++
 arch/arc/include/asm/bitops.h   |   49 ++
 arch/arc/include/asm/cmpxchg.h  |   49 ++
 arch/arc/plat-eznps/include/plat/ctop.h |1 +
 4 files changed, 168 insertions(+), 0 deletions(-)

diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index c3ecda0..ca318c2 100644
--- a/arch/arc/include/asm/atomic.h
+++ b/arch/arc/include/asm/atomic.h
@@ -17,6 +17,74 @@
 #include 
 #include 
 
+#ifdef CONFIG_ARC_PLAT_EZNPS
+static inline int atomic_read(const atomic_t *v)
+{
+   int temp;
+
+   __asm__ __volatile__(
+   "   ld.di %0, [%1]"
+   : "=r"(temp)
+   : "r"(>counter)
+   : "memory");
+   return temp;
+}
+
+static inline void atomic_set(atomic_t *v, int i)
+{
+   __asm__ __volatile__(
+   "   st.di %0,[%1]"
+   :
+   : "r"(i), "r"(>counter)
+   : "memory");
+}
+
+#define ATOMIC_OP(op, c_op, asm_op)\
+static inline void atomic_##op(int i, atomic_t *v) \
+{  \
+   __asm__ __volatile__(   \
+   "   mov r2, %0\n"   \
+   "   mov r3, %1\n"   \
+   "   .word %2\n" \
+   :   \
+   : "r"(i), "r"(>counter), "i"(asm_op) \
+   : "r2", "r3", "memory");\
+}  \
+
+#define ATOMIC_OP_RETURN(op, c_op, asm_op) \
+static inline int atomic_##op##_return(int i, atomic_t *v) \
+{  \
+   unsigned int temp = i;  \
+   \
+   __asm__ __volatile__(   \
+   "   mov r2, %0\n"   \
+   "   mov r3, %1\n"   \
+   "   .word %2\n" \
+   "   mov %0, r2" \
+   : "+r"(temp)\
+   : "r"(>counter), "i"(asm_op) \
+   : "r2", "r3", "memory");\
+   \
+   return v->counter;  \
+}
+
+#define ATOMIC_OPS(op, c_op, asm_op)   \
+   ATOMIC_OP(op, c_op, asm_op) \
+   ATOMIC_OP_RETURN(op, c_op, asm_op)
+
+ATOMIC_OPS(add, +=, CTOP_INST_AADD_DI_R2_R2_R3)
+#define atomic_sub(i, v) atomic_add(-(i), (v))
+#define atomic_sub_return(i, v) atomic_add_return(-(i), (v))
+
+ATOMIC_OP(and, &=, CTOP_INST_AAND_DI_R2_R2_R3)
+#define atomic_andnot(mask, v) atomic_and(~(mask), (v))
+ATOMIC_OP(or, |=, CTOP_INST_AOR_DI_R2_R2_R3)
+ATOMIC_OP(xor, ^=, CTOP_INST_AXOR_DI_R2_R2_R3)
+
+#undef ATOMIC_OPS
+#undef ATOMIC_OP_RETURN
+#undef ATOMIC_OP
+#else /* CONFIG_ARC_PLAT_EZNPS */
 #define atomic_read(v)  ((v)->counter)
 
 #ifdef CONFIG_ARC_HAS_LLSC
@@ -186,6 +254,7 @@ ATOMIC_OP(xor, ^=, xor)
 #undef SCOND_FAIL_RETRY_VAR_DEF
 #undef SCOND_FAIL_RETRY_ASM
 #undef SCOND_FAIL_RETRY_VARS
+#endif /* CONFIG_ARC_PLAT_EZNPS */
 
 /**
  * __atomic_add_unless - add unless the number is a given value
diff --git a/arch/arc/include/asm/bitops.h b/arch/arc/include/asm/bitops.h
index 57c1f33..54ecbe4 100644
--- a/arch/arc/include/asm/bitops.h
+++ b/arch/arc/include/asm/bitops.h
@@ -22,6 +22,48 @@
 #include 
 #endif
 
+#ifdef CONFIG_ARC_PLAT_EZNPS
+#define BIT_OP(op, c_op, asm_op)   \
+static inline void op##_bit(unsigned long nr, volatile unsigned long *m)\
+{  \
+   m += nr >> 5;   \
+   \
+   nr = (1UL << (nr & 0x1f));  \
+   if (asm_op == CTOP_INST_AAND_DI_R2_R2_R3)   \
+   nr = ~nr;   \
+

[PATCH v1 11/20] ARC: [plat-eznps] Add eznps platform

From: Noam Camus 

This platform include boards:
Hardware Emulator (HE)
Simulator based upon nSIM.

Signed-off-by: Noam Camus 
---
 MAINTAINERS |6 +
 arch/arc/plat-eznps/Kconfig |   34 
 arch/arc/plat-eznps/Makefile|7 +
 arch/arc/plat-eznps/entry.S |   76 +
 arch/arc/plat-eznps/include/plat/ctop.h |  264 +++
 arch/arc/plat-eznps/include/plat/mtm.h  |   60 +++
 arch/arc/plat-eznps/include/plat/smp.h  |   27 +++
 arch/arc/plat-eznps/mtm.c   |  152 ++
 arch/arc/plat-eznps/platform.c  |   40 +
 arch/arc/plat-eznps/smp.c   |  160 +++
 10 files changed, 826 insertions(+), 0 deletions(-)
 create mode 100644 arch/arc/plat-eznps/Kconfig
 create mode 100644 arch/arc/plat-eznps/Makefile
 create mode 100644 arch/arc/plat-eznps/entry.S
 create mode 100644 arch/arc/plat-eznps/include/plat/ctop.h
 create mode 100644 arch/arc/plat-eznps/include/plat/mtm.h
 create mode 100644 arch/arc/plat-eznps/include/plat/smp.h
 create mode 100644 arch/arc/plat-eznps/mtm.c
 create mode 100644 arch/arc/plat-eznps/platform.c
 create mode 100644 arch/arc/plat-eznps/smp.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 08adb4a..c63ca18 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4171,6 +4171,12 @@ S:   Maintained
 F: drivers/video/fbdev/exynos/exynos_mipi*
 F: include/video/exynos_mipi*
 
+EZchip NPS platform support
+M: Noam Camus 
+S: Supported
+F: arch/arc/plat-eznps
+F: arch/arc/boot/dts/eznps.dts
+
 F71805F HARDWARE MONITORING DRIVER
 M: Jean Delvare 
 L: lm-sens...@lm-sensors.org
diff --git a/arch/arc/plat-eznps/Kconfig b/arch/arc/plat-eznps/Kconfig
new file mode 100644
index 000..510354f
--- /dev/null
+++ b/arch/arc/plat-eznps/Kconfig
@@ -0,0 +1,34 @@
+#
+# For a description of the syntax of this configuration file,
+# see Documentation/kbuild/kconfig-language.txt.
+#
+
+menuconfig ARC_PLAT_EZNPS
+   bool "\"EZchip\" ARC dev platform"
+   select ARC_HAS_COH_CACHES if SMP
+   select CPU_BIG_ENDIAN
+   select CLKSRC_OF
+   select EZCHIP_NPS_MANAGEMENT_ENET if ETHERNET
+   help
+ Support for EZchip development platforms,
+ based on ARC700 cores.
+ We handle few flavours:
+   - Hardware Emulator AKA HE which is FPGA based chasis
+   - Simulator based on MetaWare nSIM
+   - NPS400 chip based on ASIC
+
+config EZNPS_MTM_EXT
+   bool "ARC-EZchip MTM Extensions"
+   select CPUMASK_OFFSTACK
+   depends on ARC_PLAT_EZNPS && SMP
+   default y
+   help
+ Here we add new hierarchy for CPUs topology.
+ We got:
+   Core
+   Thread
+ At the new thread level each CPU represent one HW thread.
+ At highest hierarchy each core contain 16 threads,
+ any of them seem like CPU from Linux point of view.
+ All threads within same core share the execution unit of the
+ core and HW scheduler round robin between them.
diff --git a/arch/arc/plat-eznps/Makefile b/arch/arc/plat-eznps/Makefile
new file mode 100644
index 000..21091b1
--- /dev/null
+++ b/arch/arc/plat-eznps/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for the linux kernel.
+#
+
+obj-y := entry.o platform.o
+obj-$(CONFIG_SMP) += smp.o
+obj-$(CONFIG_EZNPS_MTM_EXT) += mtm.o
diff --git a/arch/arc/plat-eznps/entry.S b/arch/arc/plat-eznps/entry.S
new file mode 100644
index 000..a3dec3e
--- /dev/null
+++ b/arch/arc/plat-eznps/entry.S
@@ -0,0 +1,76 @@
+/***
+
+  EZNPS CPU startup Code
+  Copyright(c) 2012 EZchip Technologies.
+
+  This program is free software; you can redistribute it and/or modify it
+  under the terms and conditions of the GNU General Public License,
+  version 2, as published by the Free Software Foundation.
+
+  This program is distributed in the hope it will be useful, but WITHOUT
+  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+  more details.
+
+  The full GNU General Public License is included in this distribution in
+  the file called "COPYING".
+
+***/
+#include 
+#include 
+#include 
+#include 
+
+   .cpu A7
+
+   .section .text, "ax",@progbits
+   .align 1024 ; HW requierment for restart first PC
+
+ENTRY(res_service)
+#ifdef CONFIG_EZNPS_MTM_EXT
+   ; For HW thread != 0 there is no work.
+   lr  r3, [CTOP_AUX_THREAD_ID]
+   cmp r3, 0
+   jne _stext
+#endif
+
+#ifdef CONFIG_ARC_HAS_DCACHE
+   ; We do not have cache coherency mechanism,
+   ; so D$ need to be used very carefully.
+   ; Address space:
+   ; 0G-2G: We disable CONFIG_ARC_CACHE_PAGES.
+   ; 2G-3G:

[PATCH v1 12/20] ARC: [plat-eznps] Use dedicated user stack top

From: Noam Camus 

NPS use special mapping right below TASK_SIZE.
Hence we need to lower STACK_TOP so that user stack won't
overlap NPS special mapping.

Signed-off-by: Noam Camus 
Acked-by: Vineet Gupta 
---
 arch/arc/include/asm/processor.h |   17 +
 arch/arc/mm/tlb.c|6 ++
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h
index a603301..7266ede 100644
--- a/arch/arc/include/asm/processor.h
+++ b/arch/arc/include/asm/processor.h
@@ -126,7 +126,24 @@ extern unsigned int get_wchan(struct task_struct *p);
 
 #define USER_KERNEL_GUTTER(VMALLOC_START - TASK_SIZE)
 
+#ifdef CONFIG_ARC_PLAT_EZNPS
+/* NPS architecture defines special window of 129M in user address space for
+ * special memory areas, when accessing this window the MMU do not use TLB.
+ * Instead MMU direct the access to:
+ * 0x57f0:0x57ff -- 1M of closely coupled memory (aka CMEM)
+ * 0x5800:0x5fff -- 16 huge pages, 8M each, with fixed map (aka FMTs)
+ *
+ * CMEM - is the fastest memory we got and its size is 16K.
+ * FMT  - is used to map either to internal/external memory.
+ * Internal memory is the second fast memory and its size is 16M
+ * External memory is the biggest memory (16G) and also the slowest.
+ *
+ * STACK_TOP need to be PMD align (21bit) that is why we supply 0x57e0.
+ */
+#define STACK_TOP   0x57e0
+#else /* CONFIG_ARC_PLAT_EZNPS */
 #define STACK_TOP   TASK_SIZE
+#endif /* CONFIG_ARC_PLAT_EZNPS */
 #define STACK_TOP_MAX   STACK_TOP
 
 /* This decides where the kernel will search for a free chunk of vm
diff --git a/arch/arc/mm/tlb.c b/arch/arc/mm/tlb.c
index 0c75a27..306ee4c 100644
--- a/arch/arc/mm/tlb.c
+++ b/arch/arc/mm/tlb.c
@@ -820,6 +820,12 @@ void arc_mmu_init(void)
 */
BUILD_BUG_ON(!IS_ALIGNED((CONFIG_ARC_VMALLOC_SIZE << 20), PMD_SIZE));
 
+   /*
+* stack top size sanity check,
+* Can't be done in processor.h due to header include depenedencies
+*/
+   BUILD_BUG_ON(!IS_ALIGNED(STACK_TOP, PMD_SIZE));
+
/* For efficiency sake, kernel is compile time built for a MMU ver
 * This must match the hardware it is running on.
 * Linux built for MMU V2, if run on MMU V1 will break down because V1
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 10/20] ARC: [plat-eznps] Add eznps board defconfig and dts

From: Noam Camus 

Adding default configuration file and DTS file

Signed-off-by: Noam Camus 
---
 arch/arc/boot/dts/eznps.dts|   76 +++
 arch/arc/configs/nps_defconfig |   85 
 2 files changed, 161 insertions(+), 0 deletions(-)
 create mode 100644 arch/arc/boot/dts/eznps.dts
 create mode 100644 arch/arc/configs/nps_defconfig

diff --git a/arch/arc/boot/dts/eznps.dts b/arch/arc/boot/dts/eznps.dts
new file mode 100644
index 000..4d4832a
--- /dev/null
+++ b/arch/arc/boot/dts/eznps.dts
@@ -0,0 +1,76 @@
+/*
+ * Copyright(c) 2015 EZchip Technologies.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ */
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+   compatible = "ezchip,arc-nps";
+   clock-frequency = <8333>;   /* 83.33 MHZ */
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <>;
+   present-cpus = "0-1,16-17";
+   possible-cpus = "0-4095";
+
+   chosen {
+   bootargs = "earlycon=uart8250,mmio32be,0xf7209000,115200n8 
console=ttyS0,115200n8";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x 0x2000>;  /* 512M */
+   };
+
+   fpga {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* child and parent address space 1:1 mapped */
+   ranges;
+
+   intc: interrupt-controller {
+   compatible = "ezchip,nps400-ic";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
+
+   timer {
+   compatible = "ezchip,nps400-timer";
+   };
+
+   uart@f7209000 {
+   compatible = "snps,dw-apb-uart";
+   device_type = "serial";
+   reg = <0xf7209000 0x100>;
+   interrupts = <6>;
+   clock-frequency = <8333>;
+   baud = <115200>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   native-endian;
+   };
+
+   ethernet@f747 {
+   compatible = "ezchip,nps-mgt-enet";
+   reg = <0xf747 0x1940>;
+   interrupts = <7>;
+   mac-address = [ 00 C0 00 F0 04 03 ];
+   };
+   };
+};
diff --git a/arch/arc/configs/nps_defconfig b/arch/arc/configs/nps_defconfig
new file mode 100644
index 000..13a67ac
--- /dev/null
+++ b/arch/arc/configs/nps_defconfig
@@ -0,0 +1,85 @@
+CONFIG_CROSS_COMPILE="arceb-linux-"
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_SYSCTL_SYSCALL=y
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_TIMERFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_KPROBES=y
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARC_PLAT_EZNPS=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=4096
+CONFIG_ARC_CACHE_LINE_SHIFT=5
+# CONFIG_ARC_CACHE_PAGES is not set
+# CONFIG_ARC_HAS_LLSC is not set
+CONFIG_ARC_VMALLOC_SIZE=192
+CONFIG_ARC_EMUL_UNALIGNED=y
+CONFIG_ARC_UBOOT_SUPPORT=y
+CONFIG_PREEMPT=y
+CONFIG_NET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=1
+CONFIG_BLK_DEV_RAM_SIZE=2048
+CONFIG_NETDEVICES=y
+CONFIG_NETCONSOLE=y
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+#

[PATCH v1 07/20] ARC: mm: use generic macros _BITUL()

From: Noam Camus 

PGDIR_SIZE() cannot use "1UL" since it is called from mm/tlbex.S
by VMALLOC_START. _BITUL() solves this build error.

Signed-off-by: Noam Camus 
---
 arch/arc/include/asm/pgtable.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
index 57af2f0..372a282 100644
--- a/arch/arc/include/asm/pgtable.h
+++ b/arch/arc/include/asm/pgtable.h
@@ -210,7 +210,7 @@
 #define BITS_FOR_PGD   (32 - BITS_FOR_PTE - BITS_IN_PAGE)
 
 #define PGDIR_SHIFT(32 - BITS_FOR_PGD)
-#define PGDIR_SIZE (1UL << PGDIR_SHIFT)/* vaddr span, not PDG sz */
+#define PGDIR_SIZE _BITUL(PGDIR_SHIFT) /* vaddr span, not PDG sz */
 #define PGDIR_MASK (~(PGDIR_SIZE-1))
 
 #definePTRS_PER_PTE_BITUL(BITS_FOR_PTE)
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 08/20] ARC: Use res_service as entry point for secondaries

From: Tal Zilcer 

At cpu_kick() we call res_service which can be implement by each
platform and override gerneric weak definition.

Signed-off-by: Noam Camus 
---
 arch/arc/include/asm/smp.h |2 +-
 arch/arc/kernel/smp.c  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/include/asm/smp.h b/arch/arc/include/asm/smp.h
index 133c867..db05793 100644
--- a/arch/arc/include/asm/smp.h
+++ b/arch/arc/include/asm/smp.h
@@ -30,7 +30,7 @@ extern void arch_send_call_function_ipi_mask(const struct 
cpumask *mask);
  * APIs provided by arch SMP code to rest of arch code
  */
 extern void __init smp_init_cpus(void);
-extern void first_lines_of_secondary(void);
+extern void res_service(void);
 extern const char *arc_platform_smp_cpuinfo(void);
 
 /*
diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c
index 946109f..546079f 100644
--- a/arch/arc/kernel/smp.c
+++ b/arch/arc/kernel/smp.c
@@ -167,7 +167,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 
if (plat_smp_ops.cpu_kick)
plat_smp_ops.cpu_kick(cpu,
-   (unsigned long)first_lines_of_secondary);
+   (unsigned long)res_service);
else
arc_default_smp_cpu_kick(cpu, (unsigned long)NULL);
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 09/20] ARC: add CONFIG_CLKSRC_OF support to time_init()