Re: [PATCH v5 1/2] arm64: kvm: allows kvm cpu hotplug

2015-10-15 Thread AKASHI Takahiro

James,

I reproduced the problem on Hikey board, but

On 10/13/2015 07:43 PM, James Morse wrote:

Hi,

On 13/10/15 06:38, AKASHI Takahiro wrote:

On 10/12/2015 10:28 PM, James Morse wrote:

On 29/05/15 06:38, AKASHI Takahiro wrote:

The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents, especially, kexec from rebooting the system on a boot
core in EL2.

This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need arm64-specific cpu hotplug hook any more.


I think we do... on platforms where cpuidle uses psci to temporarily turn
off cores that aren't in use, we lose the el2 state. This hotplug hook
restores the state, even if there a no vms running.


I've just noticed there are two cpu notifiers - we may be referring to
different ones. (hyp_init_cpu_pm_nb and hyp_init_cpu_nb)



If I understand you correctly, with or without my patch, kvm doesn't work
  under cpuidle anyway. Right?


It works with, and without, v4.
This patch v5 causes the problem.



If so, saving/restoring cpu states (or at least, kicking cpu hotplug hooks)
is cpuidle driver's responsibility, isn't it?


Yes - but with v5, (at least one of) the hotplug hooks isn't having the
same effect as before:

Before v5, cpu_init_hyp_mode() is called via cpu_notify() each time
cpu_suspend() suspends/wakes-up the core.

Logically it should be the 'pm' notifier that does this work:

if (cmd == CPU_PM_EXIT &&
__hyp_get_vectors() == hyp_default_vectors) {
cpu_init_hyp_mode(NULL);
return NOTIFY_OK;



With v5, kvm_arch_hardware_enable() isn't called each time cpu_suspend()
cycles the core.


Right. I misunderstood kvm_arm_get_running_vcpu().


The problem appears to be this hunk, affecting the above code:

-   if (cmd == CPU_PM_EXIT &&
-   __hyp_get_vectors() == hyp_default_vectors) {
-   cpu_init_hyp_mode(NULL);
+   if (cmd == CPU_PM_EXIT && kvm_arm_get_running_vcpu()) {
+   kvm_arch_hardware_enable();


Changing this to just rename cpu_init_hyp_mode() to
kvm_arch_hardware_enable() solves the problem.


The change that you suggested won't work well because kvm needs to maintain
cpu state with 'kvm_usage_count' using kvm_arch_hardware_enable/disable().
With this changed applied, you won't be able to do kexec.

I'm going to try more generic PM hook.

Thanks,
-Takahiro AKASHI


Presumably kvm_arm_get_running_vcpu() evaluates to false before the first
vm is started, meaning no vms can be started if pm events occur before
starting the first vm.

Sorry I blamed the wrong cpu notifier hook - I didn't realise there were two!


Thanks,

James



This patch prevents me from running vms on such a platform, qemu gives:

kvm [1500]: Unsupported exception type: 6264688KVM internal error.

Suberror: 0

kvmtool goes with a more dramatic:

KVM exit reason: 17 ("KVM_EXIT_INTERNAL_ERROR")


Disabling CONFIG_ARM_CPUIDLE solves this problem.


(Sorry to revive an old thread - I've been using v4 of this patch for the
hibernate/suspend-to-disk series).



Since this patch modifies common part of code between arm and arm64, one
stub definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compiling errors.

Signed-off-by: AKASHI Takahiro 



diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index fd085ec..afe6263 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -1136,6 +1136,11 @@ ENTRY(kvm_call_hyp)
   ret
   ENDPROC(kvm_call_hyp)

+ENTRY(kvm_call_reset)
+hvc#HVC_RESET
+ret
+ENDPROC(kvm_call_reset)
+
   .macro invalid_vectorlabel, target
   .align2
   \label:
@@ -1179,10 +1184,27 @@ el1_sync:// Guest trapped
into EL2
   cmpx18, #HVC_GET_VECTORS
   b.ne1f
   mrsx0, vbar_el2
-b2f
-
-1:/* Default to HVC_CALL_HYP. */
+bdo_eret

+/* jump into trampoline code */
+1:cmpx18, #HVC_RESET
+b.ne2f
+/*
+ * Entry point is:
+ *TRAMPOLINE_VA
+ *+ (__kvm_hyp_reset - (__hyp_idmap_text_start & PAGE_MASK))
+ */
+adrpx2, __kvm_hyp_reset
+addx2, x2, #:lo12:__kvm_hyp_reset
+adrpx3, __hyp_idmap_text_start
+addx3, x3, #:lo12:__hyp_idmap_text_start
+andx3, x3, PAGE_MASK
+subx2, x2, x3
+ldrx3, =TRAMPOLINE_VA
+addx2, x2, x3
+brx2// no return
+
+2:/* Default to HVC_CALL_HYP. */


What was the reason not to use kvm_call_hyp(__kvm_hyp_reset, ...)?
(You mentioned you wanted to at [0] - I can't find the details in the
archive)


Thanks,

James


[0] http://lists.infradead.org/pipermail/kexec/2015-April/335533.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" 

Re: [PATCH v3 09/24] arm64: Keep track of CPU feature registers

2015-10-15 Thread Catalin Marinas
Hi Suzuki,

Some minor comments below.

On Tue, Oct 13, 2015 at 06:22:17PM +0100, Suzuki K. Poulose wrote:
> This patch adds an infrastructure to keep track of the CPU feature
> registers on the system. For each register, the infrastructure keeps
> track of the system wide safe value of the feature bits. Also, tracks
> the which fields of a register should be matched strictly across all
> the CPUs on the system for the SANITY check infrastructure.
> 
> The feature bits are classified as one of SCALAR_MIN, SCALAR_MAX and DISCRETE
> depending on the implication of the possible values. This information
> is used to decide the safe value for a feature.
> 
> LOWER_SAFE  - The smaller value is safer
> HIGHER_SAFE - The bigger value is safer
> EXACT   - We can't decide between the two, so a predefined safe_value is 
> used.

The "SCALAR..." etc. in the comment needs updating.

> +#define FTR_STRICT   true
> +#define FTR_NONSTRICTfalse

Please add a comment on what STRICT/NONSTRICT mean.

> +static inline u64 ftr_mask(struct arm64_ftr_bits *ftrp)
> +{
> + return (u64)GENMASK(ftrp->shift + ftrp->width - 1, ftrp->shift);
> +}
> +
> +static inline s64 arm64_ftr_value(struct arm64_ftr_bits *ftrp, u64 val)
> +{
> + return cpuid_feature_extract_field_width(val, ftrp->shift, ftrp->width);
> +}

Slightly inconsistent naming: since you are prefixing everything with
arm64_, do the same for ftr_mask.

> +static struct arm64_ftr_reg arm64_ftr_regs[] = {
> +
> + /* This array should be always kept in the ascending order of id  */

Do we have a sanity check somewhere? You could also call sort() on this
array and we wouldn't have to worry.

> +/*
> + * get_arm64_sys_reg - Lookup a feature register entry using its
> + * sys_reg() encoding. With the array arm64_ftr_regs sorted in the
> + * ascending order, we use binary search to find a matching entry.
> + *
> + * returns - Upon success,  matching ftr_reg entry for id.
> + * - NULL on failure. It is upto the caller to decide
> + *the impact of a failure.
> + */
> +static struct arm64_ftr_reg* get_arm64_sys_reg(u32 sys_id)

Nitpick: the * near the function name.

Also rename it to get_arm64_ftr_reg() to match the actual return type.

-- 
Catalin
--
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 tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

2015-10-15 Thread Will Deacon
Dammit guys, it's never simple is it?

On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> To that end, the herd tool can make a diagram of what it thought
> happened, and I have attached it.  I used this diagram to try and force
> this scenario at https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html#PPC,
> and succeeded.  Here is the sequence of events:
> 
> o Commit P0's write.  The model offers to propagate this write
>   to the coherence point and to P1, but don't do so yet.
> 
> o Commit P1's write.  Similar offers, but don't take them up yet.
> 
> o Commit P0's lwsync.
> 
> o Execute P0's lwarx, which reads a=0.  Then commit it.
> 
> o Commit P0's stwcx. as successful.  This stores a=1.

On arm64, this is a conditional-store-*release* and therefore cannot be
observed before the initial write to x...

> o Commit P0's branch (not taken).
> 
> o Commit P0's final register-to-register move.
> 
> o Commit P1's sync instruction.
> 
> o There is now nothing that can happen in either processor.
>   P0 is done, and P1 is waiting for its sync.  Therefore,
>   propagate P1's a=2 write to the coherence point and to
>   the other thread.

... therefore this is illegal, because you haven't yet propagated that
prior write...

> 
> o There is still nothing that can happen in either processor.
>   So pick the barrier propagate, then the acknowledge sync.
> 
> o P1 can now execute its read from x.  Because P0's write to
>   x is still waiting to propagate to P1, this still reads
>   x=0.  Execute and commit, and we now have both r3 registers
>   equal to zero and the final value a=2.

... and P1 would have to read x == 1.

So arm64 is ok. Doesn't lwsync order store->store observability for PPC?

Will
--
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: [PATCHv3 08/11] arm64: Check for selected granule support

2015-10-15 Thread Mark Rutland
On Wed, Oct 14, 2015 at 04:13:47PM -0500, Jeremy Linton wrote:
> On 10/14/2015 06:20 AM, Suzuki K. Poulose wrote:
> 
> >+ * Checks if the selected granule size is supported by the CPU.
> >+ * If it doesn't park the CPU
> 
> The problem is when you park the boot CPU.
> 
> I think for EFI there is a slightly better error mechanism. This
> tweak will print an error and return to the EFI boot manager rather
> than hanging the machine without any notification. Now it prints:
> 
> EFI stub: Booting Linux Kernel...
> EFI stub: ERROR: 16K granule not supported by this machine
> EFI stub: ERROR: Failed to relocate kernel
> FS4:\>

Neat. We should definitely have checks like this in the stub.

However, we still need checks in head.S, given !EFI systems, SMP, and
kexec, so this is a complementary mechanism.

Thanks,
Mark.

> Signed-off-by: Jeremy Linton 
> ---
>  arch/arm64/kernel/efi-stub.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
> index 816120e..90fb868 100644
> --- a/arch/arm64/kernel/efi-stub.c
> +++ b/arch/arm64/kernel/efi-stub.c
> @@ -25,6 +25,20 @@ efi_status_t __init
> handle_kernel_image(efi_system_table_t *sys_table_arg,
> unsigned long kernel_size, kernel_memsize = 0;
> unsigned long nr_pages;
> void *old_image_addr = (void *)*image_addr;
> +   u32 aa64mmfr0_el1;
> +
> +#ifdef CONFIG_ARM64_16K_PAGES
> +   /*
> +* check to see if this kernel image is
> +* compatible with the current system
> +*/
> +   asm volatile("mrs %0, ID_AA64MMFR0_EL1" : "=r" (aa64mmfr0_el1));
> +   aa64mmfr0_el1 >>= ID_AA64MMFR0_TGRAN16_SHIFT;
> +   if ((aa64mmfr0_el1 & ID_AA64MMFR0_TGRAN4_ON) == 0) {
> +   pr_efi_err(sys_table_arg, "16K granule not supported
> by this machine\n");
> +   return EFI_UNSUPPORTED;
> +   }
> +#endif
> 
> /* Relocate the image, if required. */
> kernel_size = _edata - _text;
> -- 
> 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/


futex timeout not working? (bisected)

2015-10-15 Thread Heiko Carstens
Hi Thomas,

I received a bug report from Stefan Liebler that certain futex timeouts
do not work anymore at least on s390 (see test case below).

I did a quick bisect which ended at this commit:

868a3e915f7f5eba8f8cb4f7da2276760807c51c is the first bad commit
commit 868a3e915f7f5eba8f8cb4f7da2276760807c51c
Author: Thomas Gleixner 
Date:   Tue Apr 14 21:08:37 2015 +

hrtimer: Make offset update smarter

On every tick/hrtimer interrupt we update the offset variables of the
clock bases. That's silly because these offsets change very seldom.

Add a sequence counter to the time keeping code which keeps track of
the offset updates (clock_was_set()). Have a sequence cache in the
hrtimer cpu bases to evaluate whether the offsets must be updated or
not. This allows us later to avoid pointless cacheline pollution.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Preeti U Murthy 
Acked-by: Peter Zijlstra 
Cc: Viresh Kumar 
Cc: Marcelo Tosatti 
Cc: Frederic Weisbecker 
Cc: John Stultz 
Link: http://lkml.kernel.org/r/20150414203501.132820...@linutronix.de
Signed-off-by: Thomas Gleixner 
Cc: John Stultz 

Before that commit the testcase below failed after 0.5s, like expected. With
that commit the timer doesn't seem to expire. See also /proc/timer_list which
I added below when running kernel version 4.3.0-rc5.

Do you have an idea what's wrong here?

Thanks,
Heiko

Test program:

//CFLAGS=
//LDFLAGS=
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

int
main (void)
{
  int futex_word = 0;
#define FUTEX_PRIVATE 0
  int op = FUTEX_WAIT_BITSET | FUTEX_CLOCK_REALTIME | FUTEX_PRIVATE;
  int expected = 0;
  struct timespec ts;
  struct timeval tv;
  int ret;

  if (gettimeofday (, NULL) != 0)
{
  puts ("gettimeofday failed");
  return 1;
}

  TIMEVAL_TO_TIMESPEC (, );

  /* We wait for half a second.  */
  ts.tv_nsec += 5;
  if (ts.tv_nsec >= 10)
{
  ++ts.tv_sec;
  ts.tv_nsec -= 10;
}

  ret = syscall (__NR_futex, _word, op, expected, ts, NULL, 
FUTEX_BITSET_MATCH_ANY);
  if (ret == -1)
{
  perror ("futex-syscall returned with an error:");
}
  printf ("ret = %d\n", ret);
  return EXIT_SUCCESS;
}


Output of /proc/timer_list (a.out is the process in question).

Timer List Version: v0.8
HRTIMER_MAX_CLOCK_BASES: 4
now at 5669154446189 nsecs

cpu: 0
 clock 0:
  .base:   3e784b40
  .index:  0
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset: 0 nsecs
active timers:
 #0: <3e784fc8>, tick_sched_timer, S:01, tick_nohz_restart, swapper/0/0
 # expires at 5669155904652-5669155904652 nsecs [in 1458463 to 1458463 nsecs]
 #1: <39b4ef00>, timerfd_tmrproc, S:01, do_timerfd_settime, 
systemd-logind/355
 # expires at 5670131137000-5670131137000 nsecs [in 976690811 to 976690811 
nsecs]
 #2: <39b9ba28>, hrtimer_wakeup, S:01, 
schedule_hrtimeout_range_clock.part.6, gmain/371
 # expires at 567240022-5672004036021 nsecs [in 2845593833 to 2849589832 
nsecs]
 #3: <39b43a28>, hrtimer_wakeup, S:01, 
schedule_hrtimeout_range_clock.part.6, rpcbind/353
 # expires at 5679106011014-5679136011013 nsecs [in 9951564825 to 9981564824 
nsecs]
 #4: <3b6d7e60>, hrtimer_wakeup, S:01, do_nanosleep, crond/360
 # expires at 5679505850152-5679505900152 nsecs [in 10351403963 to 10351453963 
nsecs]
 #5: <3c0c3400>, timerfd_tmrproc, S:01, do_timerfd_settime, 
systemd-journal/123
 # expires at 5679631137000-5679631137000 nsecs [in 10476690811 to 10476690811 
nsecs]
 #6: <3c0a9600>, timerfd_tmrproc, S:01, do_timerfd_settime, 
systemd-network/354
 # expires at 5680131137000-5680131137000 nsecs [in 10976690811 to 10976690811 
nsecs]
 #7: <3c0c0200>, timerfd_tmrproc, S:01, do_timerfd_settime, 
systemd-journal/123
 # expires at 5690131137000-5690131137000 nsecs [in 20976690811 to 20976690811 
nsecs]
 #8: <3c089100>, timerfd_tmrproc, S:01, do_timerfd_settime, systemd/1
 # expires at 5690381137000-5690381137000 nsecs [in 21226690811 to 21226690811 
nsecs]
 #9: <39d2be60>, hrtimer_wakeup, S:01, do_nanosleep, sleep/23893
 # expires at 5703965950486-5703966000486 nsecs [in 34811504297 to 34811554297 
nsecs]
 #10: <38b8fa28>, hrtimer_wakeup, S:01, 
schedule_hrtimeout_range_clock.part.6, NetworkManager/338
 # expires at 5704000462109-5704060386108 nsecs [in 34846015920 to 34905939919 
nsecs]
 #11: <39f37e60>, hrtimer_wakeup, S:01, do_nanosleep, atd/361
 # expires at 7203318466583-7203318516583 nsecs [in 1534164020394 to 
1534164070394 nsecs]
 clock 1:
  .base:   3e784b80
  .index:  1
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:   

Re: [PATCH v3 09/24] arm64: Keep track of CPU feature registers

2015-10-15 Thread Suzuki K. Poulose

On 15/10/15 11:36, Catalin Marinas wrote:

Hi Suzuki,

Some minor comments below.



The feature bits are classified as one of SCALAR_MIN, SCALAR_MAX and DISCRETE
depending on the implication of the possible values. This information
is used to decide the safe value for a feature.



The "SCALAR..." etc. in the comment needs updating.


Sorry about that. Will fix it.




+#define FTR_STRICT true
+#define FTR_NONSTRICT  false


Please add a comment on what STRICT/NONSTRICT mean.



Sure


+static inline u64 ftr_mask(struct arm64_ftr_bits *ftrp)
+{
+   return (u64)GENMASK(ftrp->shift + ftrp->width - 1, ftrp->shift);
+}
+
+static inline s64 arm64_ftr_value(struct arm64_ftr_bits *ftrp, u64 val)
+{
+   return cpuid_feature_extract_field_width(val, ftrp->shift, ftrp->width);
+}


Slightly inconsistent naming: since you are prefixing everything with
arm64_, do the same for ftr_mask.


OK, will add it.




+static struct arm64_ftr_reg arm64_ftr_regs[] = {
+
+   /* This array should be always kept in the ascending order of id  */


Do we have a sanity check somewhere? You could also call sort() on this
array and we wouldn't have to worry.


No we don't have a sanity check. I will take a look.




+/*
+ * get_arm64_sys_reg - Lookup a feature register entry using its
+ * sys_reg() encoding. With the array arm64_ftr_regs sorted in the
+ * ascending order, we use binary search to find a matching entry.
+ *
+ * returns - Upon success,  matching ftr_reg entry for id.
+ * - NULL on failure. It is upto the caller to decide
+ *  the impact of a failure.
+ */
+static struct arm64_ftr_reg* get_arm64_sys_reg(u32 sys_id)


Nitpick: the * near the function name.

Also rename it to get_arm64_ftr_reg() to match the actual return type.



Sure, will fix all of these. Thanks for the detailed look



--
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/


Loan Offer

2015-10-15 Thread Loan

Contact us as we offer our finance service at a low and affordable interest 
rate for long and short cash term. Interested applicant should contact us for 
further acquisition procedures. Thanks as we remain obliged to render service 
to you; worldtrading1...@gmail.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/


[PATCH 2/3] ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit

2015-10-15 Thread Javier Martinez Canillas
The Exynos5420 Peach Pit Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Signed-off-by: Javier Martinez Canillas 
---

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f032ed7..293bf6a76a16 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -690,7 +690,7 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
mmc-hs200-1_8v;
cap-mmc-highspeed;
non-removable;
-- 
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/


[RFT PATCH 3/3] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common

2015-10-15 Thread Javier Martinez Canillas
The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408824d8..bf27957fd660 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -520,7 +520,7 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
-- 
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 0/3] ARM: dts: Mark SDIO as non-removable for Exynos Chromebooks

2015-10-15 Thread Javier Martinez Canillas
Hello,

The Exynos based Chromebooks have a Marvell WiFi SDIO chip which is always
present and cannot be detected. The mmc device node is marked as broken-cd
since that property is used in the vendor tree instead of non-removable.

This causes the device to be removed when the system enteres into a suspend
gettings the following warning when the system is resumed:

[  181.944636] mmc2: error -2 during resume (card was removed?)

The rationale for that is explained in commit [0] and it was that using the
non-removable property caused issues with the driver whose reset logic used
the mmc_{remove,add}_host() functions.

But the reset logic in the mwifiex mainline driver has changed and this is
longer the case so it's safe to use non-removable. This series changes the
Snow, Peach Pi and Peach Pit boards to use the correct DT property.

To test, I've cherry picked commit [1] from the vendor tree that adds a
debugfs entry to force a card reset and after the reset, WiFi rescanning works
the card gets connected to an AP and works correctly:

$ echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset

I don't have access to a Snow anymore so testing patch 3/3 on that board will
be appreciated.

[0]: 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad348e1e2381
[1]: 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5995363523de

Best regards,
Javier


Javier Martinez Canillas (3):
  ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
  ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
  ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts| 2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
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 1/3] ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi

2015-10-15 Thread Javier Martinez Canillas
The Exynos5800 Peach Pi Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Signed-off-by: Javier Martinez Canillas 
---

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43e5ac2..2866ac8e3ad0 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -672,7 +672,7 @@
 _1 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
card-detect-delay = <200>;
-- 
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 2/7] includes: dt-bindings: Add STM32F429 pinctrl DT bindings

2015-10-15 Thread Maxime Coquelin
2015-10-15 13:14 GMT+02:00 Daniel Thompson :
> On 14/10/15 21:07, Maxime Coquelin wrote:
>>
>> Signed-off-by: Maxime Coquelin 
>> ---
>>   include/dt-bindings/pinctrl/pinctrl-stm32.h |   12 +
>>   include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1241
>> +++
>>   2 files changed, 1253 insertions(+)
>>   create mode 100644 include/dt-bindings/pinctrl/pinctrl-stm32.h
>>   create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h
>>
>> diff --git a/include/dt-bindings/pinctrl/pinctrl-stm32.h
>> b/include/dt-bindings/pinctrl/pinctrl-stm32.h
>> new file mode 100644
>> index 000..a2e7222
>> --- /dev/null
>> +++ b/include/dt-bindings/pinctrl/pinctrl-stm32.h
>> @@ -0,0 +1,12 @@
>> +#ifndef _DT_BINDINGS_PINCTRL_STM32_H
>> +#define _DT_BINDINGS_PINCTRL_STM32_H
>> +
>> +#define STM32_PIN_NO(x) ((x) << 8)
>> +#define STM32_GET_PIN_NO(x) ((x) >> 8)
>> +#define STM32_GET_PIN_FUNC(x) ((x) & 0xff)
>> +
>> +#define STM32_PIN_GPIO 0
>> +#define STM32_PIN_AF(x)((x) + 1)
>> +#define STM32_PIN_ANALOG   (STM32_PIN_AF(15) + 1)
>> +
>> +#endif /* _DT_BINDINGS_PINCTRL_STM32_H */
>> diff --git a/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
>> b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
>> new file mode 100644
>> index 000..979e4eb
>> --- /dev/null
>> +++ b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
>> @@ -0,0 +1,1241 @@
>> +#ifndef _DT_BINDINGS_STM32F429_PINFUNC_H
>> +#define _DT_BINDINGS_STM32F429_PINFUNC_H
>> +
>> +#include 
>> +
>> +#define STM32F429_PA0_FUNC_GPIO (STM32_PIN_NO(0) | STM32_PIN_GPIO)
>> +#define STM32F429_PA0_FUNC_TIM2_CH1 TIM2_ETR (STM32_PIN_NO(0) |
>> STM32_PIN_AF(1))
>
>
> For the clock driver I was advised to get rid of this sort of "heroics" and
> expose raw numbers from the datasheet directly to DT bindings users.
>
> Should the same logic apply to this *huge* collection of macros?

I'm open to change, I just took example on the Mediatek implementation.
Advantage is that checkpatch will be more silent, drawback is that it
will be a little harder to understand how these values are generated.
If we decide to change to raw values, then the DT Bindings
documentation will need to be more verbose on the way these values are
generated.

Note that it will not be painful, as I can generate them from a script.

Regards,
Maxime
--
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: [PATCHv3 03/11] arm64: Introduce helpers for page table levels

2015-10-15 Thread Christoffer Dall
On Thu, Oct 15, 2015 at 10:35:38AM +0100, Suzuki K. Poulose wrote:
> On 14/10/15 18:07, Mark Rutland wrote:
> >On Wed, Oct 14, 2015 at 12:20:26PM +0100, Suzuki K. Poulose wrote:
> 
> >>+ * Number of page-table levels required to address 'va_bits' wide
> >>+ * address, without section mapping. We resolve the top (va_bits - 
> >>PAGE_SHIFT)
> >>+ * bits with (PAGE_SHIFT - 3) bits at each page table level. Hence:
> >>+ *
> >>+ *  levels = DIV_ROUND_UP((va_bits - PAGE_SHIFT), (PAGE_SHIFT - 3))
> >>+ *
> >>+ * We cannot include linux/kernel.h which defines DIV_ROUND_UP here
> >>+ * due to build issues. So we use the following magic formula.
> >>+ */
> >>+#define ARM64_HW_PGTABLE_LEVELS(va_bits) (((va_bits) - 4) / (PAGE_SHIFT - 
> >>3))
> >
> >I think I failed the interview question [1]. :(
> >
> >I read the comment to mean this was a brand-new piece of magic, as
> >opposed to a constant-folded copy of DIV_ROUND_UP. So it seems there's
> >still some scope for confusion, even if that only includes me.
> >
> 
> Wouldn't it be better to modify the comment to say, we open coded the 
> DIV_ROUND_UP ?
> We could potentially end up in a conflict if somebody else does 
> __DIV_ROUND_UP.
> I have seen similar issues with the CPU feature series, where if I include one
> particular header file in another, kernel build breaks without giving you a 
> clue,
> what caused the error. Usually due to the multiple definitions (e.g 
> NSEC_PER_SEC)
> and other conflicts. Given that this header file gets included with 
> asm/page.h and
> hence would be used included for people outside arch/arm64, I would prefer, 
> not to
> head there, instead update the comment, something like this :
> 
> 
> /*
>  * Number of page-table levels required to address 'va_bits' wide
>  * address, without section mapping. We resolve the top (va_bits - PAGE_SHIFT)
>  * bits with (PAGE_SHIFT - 3) bits at each page table level. Hence:
>  *
>  *  levels = DIV_ROUND_UP((va_bits - PAGE_SHIFT), (PAGE_SHIFT - 3))
>  *
>  * where DIV_ROUND_UP (n, d) = > ((n) + (d) - 1) / (d)
>  *
>  * We cannot include linux/kernel.h which defines DIV_ROUND_UP here
>  * due to build issues. So we open code the DIV_ROUND_UP and hence
>  * we get :
>  *  ((va_bits - PAGE_SHIFT) + (PAGE_SHIFT - 3) -1) / (PAGE_SHIFT - 3)
>  *
>  * which gets simplified as :
>  *  (((va_bits) - 4) / (PAGE_SHIFT - 3))
>  *
>  */
> 
> Let me know if you are happy with that ?
> 

I preferred Mark's suggestion, but I don't have the experience with
breaking builds with kernel header includes, so I guess we'll do with
this.

Thanks for adding the comments!
-Christoffer
--
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/4] mmc: mediatek: Add tune support

2015-10-15 Thread Chaotian Jing
On Thu, 2015-10-15 at 11:17 +0200, Ulf Hansson wrote:
> [...]
> 
> >> >
> >> > struct clk *src_clk;/* msdc source clock */
> >> > +   struct clk *src_clk_parent; /* src_clk's parent */
> >> > +   struct clk *hs400_src;  /* 400Mhz source clock */
> >>
> >> Hmm, so you need to control the upper level clocks. Can you elaborate
> >> on why this is needed?
> >>
> > hs400 is DDR200, in our host design, if the mode is DDR(HS400), if want
> > to get 200Mhz mmc bus clock frequency, the minimum source clock is
> > double of the mmc bus clock, So, we need it for HS400 mode with 200Mhz
> > bus clock.
> 
> Thanks for clarifying.
> 
> [...]
> 
>  > flags = readl(host->base + MSDC_INTEN);
> >> > sdr_clr_bits(host->base + MSDC_INTEN, flags);
> >> > -   if (ddr) { /* may need to modify later */
> >> > -   mode = 0x2; /* ddr mode and use divisor */
> >> > +   sdr_clr_bits(host->base + MSDC_CFG, MSDC_CFG_HS400_CK_MODE);
> >> > +   if (timing == MMC_TIMING_UHS_DDR50 ||
> >> > +   timing == MMC_TIMING_MMC_DDR52 ||
> >>
> >> So, no support for HS200?
> >>
> > HS200 is the same with other SDR modes, so it will be handled at else..
> 
> Okay, nice!
> 
> So, your the driver currently supports HS200, but without need for tuning!?
> 

It support and need tuning for HS200, but do not support tuning for
HS400, that's why we fixed the hs400_ds_delay by project.

> [...]
> 
> >> > +static struct msdc_delay_phase get_best_delay(u32 delay)
> >> > +{
> >> > +   int start = 0, len = 0;
> >> > +   int start_final = 0, len_final = 0;
> >> > +   u8 final_phase = 0xff;
> >> > +   struct msdc_delay_phase delay_phase;
> >> > +
> >> > +   if (delay == 0) {
> >> > +   pr_err("phase error: [map:%x]\n", delay);
> >>
> >> Please use dev_err|warn|dbg|info instead.
> >>
> > As you know, this function is just only parse the argument "u32 delay",
> > it do not bind with any device.
> 
> You may just add a msdc_host * as a parameter to the function, that
> would solve this.
> 

Ok, will do it.

> [...]
> 
> >> > +static int msdc_send_tuning(struct mmc_host *host, u32 opcode, int 
> >> > *cmd_error)
> >>
> >> I think you can remove this function and use mmc_send_tuning() instead.
> > Hmm, I also noticed that there was a mmc_send_tuning, but, I need to get
> > the cmd_error when tune cmd response, in this case, do not care the data
> > error.
> 
> Well, if you need to extend the mmc_send_tuning() API to suite your
> needs, let's do that instead of duplicating code.
> 

OK, will extend the mmc_send_tuning, but it need change other vendor's
MMC driver, because it already use the mmc_send_tuning()

> >>
> >> > +{
> >> > +   struct mmc_request mrq = {NULL};
> >> > +   struct mmc_command cmd = {0};
> >> > +   struct mmc_data data = {0};
> >> > +   struct scatterlist sg;
> >> > +   struct mmc_ios *ios = >ios;
> >> > +   int size, err = 0;
> >> > +   u8 *data_buf;
> >> > +
> >> > +   if (ios->bus_width == MMC_BUS_WIDTH_8)
> >> > +   size = 128;
> >> > +   else if (ios->bus_width == MMC_BUS_WIDTH_4)
> >> > +   size = 64;
> >> > +   else
> >> > +   return -EINVAL;
> >> > +
> >> > +   data_buf = kzalloc(size, GFP_KERNEL);
> >> > +   if (!data_buf)
> >> > +   return -ENOMEM;
> >> > +
> >> > +   mrq.cmd = 
> >> > +   mrq.data = 
> >> > +
> >> > +   cmd.opcode = opcode;
> >> > +   cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
> >> > +
> >> > +   data.blksz = size;
> >> > +   data.blocks = 1;
> >> > +   data.flags = MMC_DATA_READ;
> >> > +
> >> > +   /*
> >> > +* According to the tuning specs, Tuning process
> >> > +* is normally shorter 40 executions of CMD19,
> >> > +* and timeout value should be shorter than 150 ms
> >> > +*/
> >> > +   data.timeout_ns = 150 * NSEC_PER_MSEC;
> >> > +
> >> > +   data.sg = 
> >> > +   data.sg_len = 1;
> >> > +   sg_init_one(, data_buf, size);
> >> > +
> >> > +   mmc_wait_for_req(host, );
> >> > +
> >> > +   if (cmd_error)
> >> > +   *cmd_error = cmd.error;
> >> > +
> >> > +   if (cmd.error) {
> >> > +   err = cmd.error;
> >> > +   goto out;
> >> > +   }
> >> > +
> >> > +   if (data.error) {
> >> > +   err = data.error;
> >> > +   goto out;
> >> > +   }
> >> > +
> >> > +out:
> >> > +   kfree(data_buf);
> >> > +   return err;
> >> > +}
> >> > +
> 
> [...]
> 
> >> > +   host->src_clk_parent = clk_get_parent(host->src_clk);
> >>
> >> Don't you need to check the return value here?
> >>
> > will check it.
> >> > +   host->hs400_src = devm_clk_get(>dev, "400mhz");
> >>
> >> That's a really weird conid for a clock. If it's not too late to
> >> change, please do that!
> >>
> >> > +   if (IS_ERR(host->hs400_src)) {
> >> > +   dev_dbg(>dev, "Cannot find 400mhz at 

Re: [PATCH v3] i2c: s3c2410: enable RuntimePM before registering to the core

2015-10-15 Thread Wolfram Sang
On Sat, Oct 10, 2015 at 08:24:23AM +0100, Wolfram Sang wrote:
> From: Wolfram Sang 
> 
> The core may register clients attached to this master which may use
> funtionality from the master. So, RuntimePM must be enabled before, otherwise
> this will fail. While here, move drvdata, too.
> 
> Signed-off-by: Wolfram Sang 

Applied to for-current, thanks!



signature.asc
Description: Digital signature


Re: [PATCH v2 2/4] i2c: rcar: enable RuntimePM before registering to the core

2015-10-15 Thread Wolfram Sang
On Fri, Oct 09, 2015 at 10:39:25AM +0100, Wolfram Sang wrote:
> From: Wolfram Sang 
> 
> The core may register clients attached to this master which may use
> funtionality from the master. So, RuntimePM must be enabled before, otherwise
> this will fail. While here, move drvdata, too.
> 
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Wolfram Sang 

Applied to for-current, thanks!



signature.asc
Description: Digital signature


[PATCH v3 1/4] dt-bindings: Document the STM32 DMA bindings

2015-10-15 Thread M'boumba Cedric Madianga
This patch adds documentation of device tree bindings for the STM32 dma
controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 .../devicetree/bindings/dma/stm32-dma.txt  | 82 ++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt

diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt 
b/Documentation/devicetree/bindings/dma/stm32-dma.txt
new file mode 100644
index 000..54d0326
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt
@@ -0,0 +1,82 @@
+* STMicroelectronics STM32 DMA controller
+
+The STM32 DMA is a general-purpose direct memory access controller capable of
+supporting 8 independent DMA channels. Each channel can have up to 8 requests.
+
+Required properties:
+- compatible: Should be "st,stm32-dma"
+- reg: Should contain DMA registers location and length. This should include
+  all of the per-channel registers.
+- interrupts: Should contain all of the per-channel DMA interrupts ordering by
+  channel index.
+- clocks: Should contain the input clock of the DMA instance.
+- #dma-cells : Must be <4>. See DMA client paragraph for more details.
+
+Optional properties:
+- resets: Reference to a reset controller asserting the DMA controller
+- st,mem2mem: boolean; if defined, it indicates that the controller supports
+  memory-to-memory transfer
+
+Example:
+
+   dma2: dma-controller@40026400 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026400 0x400>;
+   interrupts = <56>,
+<57>,
+<58>,
+<59>,
+<60>,
+<68>,
+<69>,
+<70>;
+   clocks = <_hclk>;
+   #dma-cells = <4>;
+   st,mem2mem;
+   resets = < 150>;
+   };
+
+* DMA client
+
+DMA clients connected to the STM32 DMA controller must use the format
+described in the dma.txt file, using a five-cell specifier for each
+channel: a phandle plus four integer cells.
+The four cells in order are:
+
+1. The channel id
+2. The request line number
+3. A 32bit mask specifying the DMA channel configuration which are device
+   dependent:
+  -bit 9: Peripheral Increment Address
+   0x0: no address increment between transfers
+   0x1: increment address between transfers
+ -bit 10: Memory Increment Address
+   0x0: no address increment between transfers
+   0x1: increment address between transfers
+ -bit 15: Peripheral Increment Offset Size
+   0x0: offset size is linked to the peripheral bus width
+   0x1: offset size is fixed to 4 (32-bit alignment)
+ -bit 16-17: Priority level
+   0x0: low
+   0x1: medium
+   0x2: high
+   0x3: very high
+5. A 32bit mask specifying the DMA FIFO threshold configuration which are 
device
+   dependent:
+ -bit 0-1: Fifo threshold
+   0x0: 1/4 full FIFO
+   0x1: 1/2 full FIFO
+   0x2: 3/4 full FIFO
+   0x3: full FIFO
+
+Example:
+
+   usart1: serial@40011000 {
+   compatible = "st,stm32-usart", "st,stm32-uart";
+   reg = <0x40011000 0x400>;
+   interrupts = <37>;
+   clocks = <_pclk2>;
+   dmas = < 2 4 0x10400 0x3>,
+  < 7 5 0x10200 0x3>;
+   dma-names = "rx", "tx";
+   };
-- 
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/


[PATCH v3 2/4] dmaengine: Add STM32 DMA driver

2015-10-15 Thread M'boumba Cedric Madianga
This patch adds support for the STM32 DMA controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/dma/Kconfig |   12 +
 drivers/dma/Makefile|1 +
 drivers/dma/stm32-dma.c | 1148 +++
 3 files changed, 1161 insertions(+)
 create mode 100644 drivers/dma/stm32-dma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index af81a7a..b1a071b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -431,6 +431,18 @@ config STE_DMA40
help
  Support for ST-Ericsson DMA40 controller
 
+config STM32_DMA
+   bool "STMicroelectronics STM32 DMA support"
+   depends on ARCH_STM32
+   select DMA_ENGINE
+   select DMA_OF
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for the on-chip DMA controller on STMicroelectronics
+ STM32 MCUs.
+ If you have a board based on such a MCU and wish to use DMA say Y or M
+ here.
+
 config S3C24XX_DMAC
tristate "Samsung S3C24XX DMA support"
depends on ARCH_S3C24XX
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index ef9c099..2dd0a067 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
 obj-$(CONFIG_RENESAS_DMA) += sh/
 obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
 obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
+obj-$(CONFIG_STM32_DMA) += stm32-dma.o
 obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o
 obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
 obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
new file mode 100644
index 000..a047484
--- /dev/null
+++ b/drivers/dma/stm32-dma.c
@@ -0,0 +1,1148 @@
+/*
+ * Driver for STM32 DMA controller
+ *
+ * Inspired by dma-jz4740.c and tegra20-apb-dma.c
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2015
+ * Author: M'boumba Cedric Madianga 
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "virt-dma.h"
+
+#define STM32_DMA_LISR 0x /* DMA Low Int Status Reg */
+#define STM32_DMA_HISR 0x0004 /* DMA High Int Status Reg */
+#define STM32_DMA_LIFCR0x0008 /* DMA Low Int Flag 
Clear Reg */
+#define STM32_DMA_HIFCR0x000c /* DMA High Int Flag 
Clear Reg */
+#define STM32_DMA_TCI  BIT(5) /* Transfer Complete Interrupt */
+#define STM32_DMA_HTI  BIT(4) /* Half Transfer Interrupt */
+#define STM32_DMA_TEI  BIT(3) /* Transfer Error Interrupt */
+#define STM32_DMA_DMEI BIT(2) /* Direct Mode Error Interrupt */
+#define STM32_DMA_FEI  BIT(0) /* FIFO Error Interrupt */
+
+/* DMA Stream x Configuration Register */
+#define STM32_DMA_SCR(x)   (0x0010 + 0x18 * (x)) /* x = 0..7 */
+#define STM32_DMA_SCR_REQ(n)   ((n & 0x7) << 25)
+#define STM32_DMA_SCR_MBURST_MASK  GENMASK(24, 23)
+#define STM32_DMA_SCR_MBURST(n)((n & 0x3) << 23)
+#define STM32_DMA_SCR_PBURST_MASK  GENMASK(22, 21)
+#define STM32_DMA_SCR_PBURST(n)((n & 0x3) << 21)
+#define STM32_DMA_SCR_PL_MASK  GENMASK(17, 16)
+#define STM32_DMA_SCR_PL(n)((n & 0x3) << 16)
+#define STM32_DMA_SCR_MSIZE_MASK   GENMASK(14, 13)
+#define STM32_DMA_SCR_MSIZE(n) ((n & 0x3) << 13)
+#define STM32_DMA_SCR_PSIZE_MASK   GENMASK(12, 11)
+#define STM32_DMA_SCR_PSIZE(n) ((n & 0x3) << 11)
+#define STM32_DMA_SCR_PSIZE_GET(n) ((n & STM32_DMA_SCR_PSIZE_MASK) >> 11)
+#define STM32_DMA_SCR_DIR_MASK GENMASK(7, 6)
+#define STM32_DMA_SCR_DIR(n)   ((n & 0x3) << 6)
+#define STM32_DMA_SCR_CT   BIT(19) /* Target in double buffer */
+#define STM32_DMA_SCR_DBM  BIT(18) /* Double Buffer Mode */
+#define STM32_DMA_SCR_PINCOS   BIT(15) /* Peripheral inc offset size */
+#define STM32_DMA_SCR_MINC BIT(10) /* Memory increment mode */
+#define STM32_DMA_SCR_PINC BIT(9) /* Peripheral increment mode */
+#define STM32_DMA_SCR_CIRC BIT(8) /* Circular mode */
+#define STM32_DMA_SCR_PFCTRL   BIT(5) /* Peripheral Flow Controller */
+#define STM32_DMA_SCR_TCIE BIT(4) /* Transfer Cplete Int Enable*/
+#define STM32_DMA_SCR_HTIE BIT(3) /* Halft Transfer Int Enable*/
+#define STM32_DMA_SCR_TEIE BIT(2) /* Transfer Error Int Enable */
+#define STM32_DMA_SCR_DMEIEBIT(1) /* Direct Mode Err Int Enable */
+#define STM32_DMA_SCR_EN   BIT(0) /* Stream Enable */
+#define STM32_DMA_SCR_CFG_MASK (STM32_DMA_SCR_PINC \
+   | STM32_DMA_SCR_MINC \
+   

[PATCH v3 0/4] Add support for STM32 DMA

2015-10-15 Thread M'boumba Cedric Madianga
This patchset adds support for the STM32 DMA controller.
This controller provides 8 channels dedicated to managing memory access
request from one or more peripherals.
Each stream can have up to 8 requests in total.

Changes since v2:
- remove interrupt configuration management from DT
- remove FIFO configuration management from DT except threshold as it is very
  hard to handle it in the driver due to many possible combinations according
  to burst and bus width
- update DMA client message in DT documentation file
- specify the order to be used to set per-channel DMA interrupts in the DT
- remove unused enumerations for channel and request ids
- keep as soon as possible 80 lines char for more readability
- replace unsigned int by u32
- return error if burst is not supported in stm32_dma_get_burst()
- return error if bus_width is not supported in stm32_dma_get_width()
- add FIFO configuration management inside the driver except for threshold
- add interrupt configuration management inside the driver
- rework stm32_dma_chan_irq() to handle error interrupt in one way
- rework stm32_dma_set_xfer_param() to be easier to read
- update stm32_dma_tx_status() to always return status from dma_cookie_status()
- disable clk if we don't manage to stop the DMA channel during channel
  resources allocation
- set driver as built-in as DMA will be required by other built-in driver

Changes since v1:
 - remove dmamux boolean as it is not needed
 - replace dma by DMA in Kconfig
 - add default return value in stm32_dma_get_width()
 - add defalut return value in stm32_dma_get_burst()
 - use lower case for constant hexadecimal values


M'boumba Cedric Madianga (4):
  dt-bindings: Document the STM32 DMA bindings
  dmaengine: Add STM32 DMA driver
  ARM: dts: Add STM32 DMA support for STM32F429 MCU
  ARM: configs: Add STM32 DMA support in STM32 defconfig

 .../devicetree/bindings/dma/stm32-dma.txt  |   82 ++
 arch/arm/boot/dts/stm32f429.dtsi   |   31 +
 arch/arm/configs/stm32_defconfig   |2 +
 drivers/dma/Kconfig|   12 +
 drivers/dma/Makefile   |1 +
 drivers/dma/stm32-dma.c| 1148 
 6 files changed, 1276 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt
 create mode 100644 drivers/dma/stm32-dma.c

-- 
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] ASoC: bcm2835-i2s: Fix module autoload for OF platform drivers

2015-10-15 Thread Luis de Bethencourt
On Wed, Oct 14, 2015 at 05:44:46PM -0700, Eric Anholt wrote:
> Luis de Bethencourt  writes:
> 
> > These platform drivers have a OF device ID table but the OF module
> > alias information is not created so module autoloading won't work.
> >
> > Signed-off-by: Luis de Bethencourt 
> > ---
> >  sound/soc/bcm/bcm2835-i2s.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/sound/soc/bcm/bcm2835-i2s.c b/sound/soc/bcm/bcm2835-i2s.c
> > index 03fa1cb..8c435be 100644
> > --- a/sound/soc/bcm/bcm2835-i2s.c
> > +++ b/sound/soc/bcm/bcm2835-i2s.c
> > @@ -862,6 +862,8 @@ static const struct of_device_id bcm2835_i2s_of_match[] 
> > = {
> > {},
> >  };
> >  
> > +MODULE_DEVICE_TABLE(of, bcm2835_i2s_of_match);
> > +
> >  static struct platform_driver bcm2835_i2s_driver = {
> > .probe  = bcm2835_i2s_probe,
> > .driver = {
> > -- 
> 
> It looks like this should go through the asoc tree, but I don't see it
> in there.
> 
> FWIW, it is also:
> 
> Acked-by: Eric Anholt 

Hi Eric,

Should I resend adding somebody from the asoc tree to the CC?

Thanks for the review,
Luis
--
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 net-next] net: hisilicon: fixes a bug when using ethtool -S

2015-10-15 Thread David Miller
From: yankejian 
Date: Thu, 15 Oct 2015 12:40:34 +0800

> From: lipeng 
> 
> this patch fixes a bug in hns driver. when we want to get statistic info
> by using ethtool -S, it shows us there are 3 wrong counters info. because
> the strings related to the registers are wrong. it needs to modify the
> strings which give us wrong info.
> 
> Signed-off-by: lipeng 
> Signed-off-by: yankejian 
> Signed-off-by: Yisen Zhuang 

Applied.
--
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] arm64: ftrace: function_graph: dump real return addr in call trace

2015-10-15 Thread Arnd Bergmann
On Thursday 15 October 2015 20:12:35 Li Bin wrote:
> 
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> +static void print_ftrace_graph_addr(unsigned long addr,
> +   struct task_struct *tsk,
> +   unsigned long sp, int *graph)
> +{
> +   unsigned long ret_addr;
> +   int index = tsk->curr_ret_stack;
> +
> +   if (addr != ((unsigned long)return_to_handler - 4))
> +   return;
> +
> +   if (!tsk->ret_stack || index < *graph)
> 

I think it would be nicer to remove the #ifdef and write this as

static void print_ftrace_graph_addr(unsigned long addr,
struct task_struct *tsk,
unsigned long sp, int *graph)
{
   unsigned long ret_addr;
   int index = tsk->curr_ret_stack;

   if (!IS_ENABLED(CONFIG_FUNCTION_GRAPH_TRACER))
return;

   if (addr != ((unsigned long)return_to_handler - 4))
   return;

--
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/


[GIT PULL] ext4 Kconfig description fixup

2015-10-15 Thread Jan Kara
  Hello Linus,

  could you please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_linus

to get a small fixup in description of EXT4_USE_FOR_EXT2 config option.

Top of the tree is d4eb6dee4712. The full shortlog is:

Jean Delvare (1):
  ext4: Update EXT4_USE_FOR_EXT2 description

The diffstat is

 fs/ext4/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Thanks
Honza

-- 
Jan Kara 
SUSE Labs, CR
--
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] iio: mma8452: support either of the available interrupt pins

2015-10-15 Thread Mark Rutland
On Thu, Oct 15, 2015 at 11:32:59AM +0200, Martin Kepplinger wrote:
> Am 2015-10-14 um 17:12 schrieb Lars-Peter Clausen:
> > On 10/14/2015 03:15 PM, Martin Kepplinger wrote:
> > [...]
> >> +  if (irq1 > 0)
> >> +  client->irq = irq1;
> > 
> > You must not overwrite client->irq, that field is manged by the I2C core and
> > is supposed to be read only for device drivers.
> >
> 
> I thought about it again and before I implement it, let me show you:
> 
> since interrupt-names would be "invented" anyways ("INT1", "INT2"),
> here's an idea for the bindings doc that would be a more long-term
> solution to implement:
> 
>   - interrupts: interrupt mapping for GPIO IRQ
> 
> These devices have two interrupt pins called INT1 and INT2 they
> can route their different interrupt sources to:

This being the case, the binding should only talk about INT1 and INT2.
The names might be "invented", but they describe the physical pins on
the device, and thus describe a physical property of the device.

> IRQ NameInterrupt SourceWired Pin
> -
> DATA_READY_1data ready  INT1
> DATA_READY_2INT2
> MOTION_1motion events   INT1
> MOTION_2INT2
> INT1all INT1
> INT2INT2
> 
>   - interrupt-names: should contain IRQ Names in the order in which they
>  were supplied in the interrupts property.
> 
>  Depending on how your chip is wired and what
>  interrupt sources should be handled by the driver,
>  choose one IRQ Name per Interrupt source, or
>  INT1/INT2 for all sources to one pin here.

The configuration of logical interrupts to those physical pins is a
choice that can be made at runtime, and should not live in the DT. It is
not a property of the hardware.

Thanks,
Mark.
--
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 13/24] arm64: Populate cpuinfo after notify_cpu_starting

2015-10-15 Thread Catalin Marinas
On Tue, Oct 13, 2015 at 06:22:21PM +0100, Suzuki K. Poulose wrote:
> This patch delays populating the cpuinfo for a new (hotplugged)
> CPU until the notifiers have executed. This will enable us to verify
> if the new (hotplugged) CPU has all the capabilities which the system
> already has. If it doesn't, we could prevent it from turning online and
> also modifying the system wide feature register status.

Just a question here: do we expect the notifiers to enable certain
features that we check later? AFAICT, the checking is done on the
feature registers which don't change after notifiers, so we could as
well block the booting before any notifier is run.

-- 
Catalin
--
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: [Xen-devel] [PATCH v4 29/79] gntalloc.h: use __u16, __u32 and __u64 from linux/types.h

2015-10-15 Thread David Vrabel
On 15/10/15 06:56, Mikko Rapeli wrote:
> Fixes userspace compilation errors like:
> 
> xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’

Applied to for-linus-4.4, thanks.

David
--
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 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h

2015-10-15 Thread Sowmini Varadhan
On (10/15/15 07:56), Mikko Rapeli wrote:
> Date: Thu, 15 Oct 2015 07:56:01 +0200
> From: Mikko Rapeli 
> To: linux-kernel@vger.kernel.org
> Cc: mikko.rap...@iki.fi, "David S. Miller" , Sowmini
>  Varadhan , linux-...@vger.kernel.org
> Subject: [PATCH v4 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64
>  from linux/types.h
> X-Mailer: git-send-email 2.6.1
> 
> Fixes userspace compilation errors like:
> 
> linux/rds.h:96:2: error: unknown type name ‘uint8_t’

Can't you just include  in linux/rds.h? (similar to the
fix for linux/rds)? It would reduce the deltas significantly, 
and portable applications are likely to expect uint8_t etc anyway.

--Sowmini
--
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] ARM: edma: special case slot limit workaround

2015-10-15 Thread Peter Ujfalusi
On 10/15/2015 01:48 PM, John Ogness wrote:
> Currently drivers are limited to 19 slots for cyclic transfers.
> However, if the DMA burst size is the same as the period size,
> the period size can be changed to the full buffer size and
> intermediate interrupts activated. Since intermediate interrupts
> will trigger for each burst and the burst size is the same as
> the period size, the driver will get interrupts each period as
> expected. This has the benefit of allowing the functionality of
> many more slots, but only uses 2 slots.
> 
> This workaround is only active if more than 19 slots are needed
> and the burst size matches the period size.

To: Vinod
CC: l-o, Sekhar at least

> 
> Signed-off-by: John Ogness 
> ---
>  drivers/dma/edma.c |   25 ++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 493c774..16bd193 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -585,6 +585,7 @@ static struct dma_async_tx_descriptor 
> *edma_prep_dma_cyclic(
>   struct edma_desc *edesc;
>   dma_addr_t src_addr, dst_addr;
>   enum dma_slave_buswidth dev_width;
> + bool use_intermediate = false;
>   u32 burst;
>   int i, ret, nslots;
>  
> @@ -626,8 +627,21 @@ static struct dma_async_tx_descriptor 
> *edma_prep_dma_cyclic(
>* but the synchronization is difficult to achieve with Cyclic and
>* cannot be guaranteed, so we error out early.
>*/
> - if (nslots > MAX_NR_SG)
> - return NULL;
> + if (nslots > MAX_NR_SG) {
> + /*
> +  * If the burst and period sizes are the same, we can put
> +  * the full buffer into a single period and activate
> +  * intermediate interrupts. This will produce interrupts
> +  * after each burst, which is also after each desired period.
> +  */
> + if (burst == period_len) {
> + period_len = buf_len;
> + nslots = 2;
> + use_intermediate = true;
> + } else {
> + return NULL;
> + }
> + }
>  
>   edesc = kzalloc(sizeof(*edesc) + nslots *
>   sizeof(edesc->pset[0]), GFP_ATOMIC);
> @@ -706,8 +720,13 @@ static struct dma_async_tx_descriptor 
> *edma_prep_dma_cyclic(
>   /*
>* Enable period interrupt only if it is requested
>*/
> - if (tx_flags & DMA_PREP_INTERRUPT)
> + if (tx_flags & DMA_PREP_INTERRUPT) {
>   edesc->pset[i].param.opt |= TCINTEN;
> +
> + /* Also enable intermediate interrupts if necessary */
> + if (use_intermediate)
> + edesc->pset[i].param.opt |= ITCINTEN;
> + }
>   }

The workaround looks fine, but please rebase it on the latest edma code from
linux-next.

-- 
Péter
--
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: [PATCHv3 03/11] arm64: Introduce helpers for page table levels

2015-10-15 Thread Christoffer Dall
On Wed, Oct 14, 2015 at 12:20:26PM +0100, Suzuki K. Poulose wrote:
> Introduce helpers for finding the number of page table
> levels required for a given VA width, shift for a particular
> page table level.
> 
> Convert the existing users to the new helpers. More users
> to follow.
> 
> Cc: Ard Biesheuvel 
> Cc: Mark Rutland 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Marc Zyngier 
> Signed-off-by: Suzuki K. Poulose 
> 
> ---
> Changes since V2:
>   - Add comments around the macros
>   - Change ARM64_HW_PGTABLE_LEVEL_SHIFT to accept pagetable level as
> described by ARM ARM
> ---
>  arch/arm64/include/asm/pgtable-hwdef.h |   25 ++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
> b/arch/arm64/include/asm/pgtable-hwdef.h
> index 95c1ec0..c6194ab 100644
> --- a/arch/arm64/include/asm/pgtable-hwdef.h
> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> @@ -16,13 +16,31 @@
>  #ifndef __ASM_PGTABLE_HWDEF_H
>  #define __ASM_PGTABLE_HWDEF_H
>  
> +/*
> + * Number of page-table levels required to address 'va_bits' wide
> + * address, without section mapping. We resolve the top (va_bits - 
> PAGE_SHIFT)
> + * bits with (PAGE_SHIFT - 3) bits at each page table level. Hence:
> + *
> + *  levels = DIV_ROUND_UP((va_bits - PAGE_SHIFT), (PAGE_SHIFT - 3))
> + *
> + * We cannot include linux/kernel.h which defines DIV_ROUND_UP here
> + * due to build issues. So we use the following magic formula.
> + */
> +#define ARM64_HW_PGTABLE_LEVELS(va_bits) (((va_bits) - 4) / (PAGE_SHIFT - 3))
> +
> +/*
> + * Size mapped by an entry at level n
> + * We map PAGE_SHIFT - 3 at all levels, except the PAGE_SHIFT bits at the 
> last level
> + */
> +#define ARM64_HW_PGTABLE_LEVEL_SHIFT(n)  ((PAGE_SHIFT - 3) * (4 - (n)) + 
> 3)

I feel like I'm partially failing the interview question again, in that
I don't fully understand the '+ 3' in the end?

Also the comment could be expanded to explain the (4 - (n)), but I
couldn't easily come up with good language for explaining that you have
a maximum of 4 levels and you subtract the 'n' levels that your are not
accounting for...

That said, this still looks functionally correct to me.

-Christoffer


> +
>  #define PTRS_PER_PTE (1 << (PAGE_SHIFT - 3))
>  
>  /*
>   * PMD_SHIFT determines the size a level 2 page table entry can map.
>   */
>  #if CONFIG_PGTABLE_LEVELS > 2
> -#define PMD_SHIFT((PAGE_SHIFT - 3) * 2 + 3)
> +#define PMD_SHIFTARM64_HW_PGTABLE_LEVEL_SHIFT(2)
>  #define PMD_SIZE (_AC(1, UL) << PMD_SHIFT)
>  #define PMD_MASK (~(PMD_SIZE-1))
>  #define PTRS_PER_PMD PTRS_PER_PTE
> @@ -32,7 +50,7 @@
>   * PUD_SHIFT determines the size a level 1 page table entry can map.
>   */
>  #if CONFIG_PGTABLE_LEVELS > 3
> -#define PUD_SHIFT((PAGE_SHIFT - 3) * 3 + 3)
> +#define PUD_SHIFTARM64_HW_PGTABLE_LEVEL_SHIFT(1)
>  #define PUD_SIZE (_AC(1, UL) << PUD_SHIFT)
>  #define PUD_MASK (~(PUD_SIZE-1))
>  #define PTRS_PER_PUD PTRS_PER_PTE
> @@ -42,7 +60,8 @@
>   * PGDIR_SHIFT determines the size a top-level page table entry can map
>   * (depending on the configuration, this level can be 0, 1 or 2).
>   */
> -#define PGDIR_SHIFT  ((PAGE_SHIFT - 3) * CONFIG_PGTABLE_LEVELS + 3)
> +#define PGDIR_SHIFT  \
> + ARM64_HW_PGTABLE_LEVEL_SHIFT(4 - CONFIG_PGTABLE_LEVELS)
>  #define PGDIR_SIZE   (_AC(1, UL) << PGDIR_SHIFT)
>  #define PGDIR_MASK   (~(PGDIR_SIZE-1))
>  #define PTRS_PER_PGD (1 << (VA_BITS - PGDIR_SHIFT))
> -- 
> 1.7.9.5
> 
--
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] i2c: return probe deferred status on dev_pm_domain_attach

2015-10-15 Thread Wolfram Sang
On Mon, Oct 12, 2015 at 09:54:43PM +0100, Kieran Bingham wrote:
> A change of return status was introduced in commit 3fffd1283927
> ("i2c: allow specifying separate wakeup interrupt in device tree")
> 
> The commit prevents the defer status being passed up the call stack
> appropriately when dev_pm_domain_attach returns -EPROBE_DEFER.
> 
> Catch the PROBE_DEFER and clear up the IRQ wakeup status
> 
> Signed-off-by: Kieran Bingham 
> Fixes: 3fffd1283927 ("i2c: allow specifying separate wakeup
> interrupt in device tree")
> 

Applied to for-current, thanks!



signature.asc
Description: Digital signature


Re: [PATCH V15 00/11] x86: Intel Cache Allocation Technology Support

2015-10-15 Thread Peter Zijlstra
On Tue, Oct 13, 2015 at 07:40:58PM -0300, Marcelo Tosatti wrote:
> How can you fix the issue of sockets with different reserved cache
> regions with hw in the cgroup interface?

No idea what you're referring to. But IOCTLs blow.
--
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: build failure after merge of the mfd tree

2015-10-15 Thread Christoph Hellwig
On Thu, Oct 15, 2015 at 10:59:32AM +0200, Arnd Bergmann wrote:
> The patch looks good, should we do something to prevent that from
> becoming a problem when Linus pulls our branches?
> 
> This commit is at the bottom of my asm-generic git tree, so Lee could merge
> that one commit into his tree and fix up the merge correctly.
> 
> However, I also now see that 
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
> has the same problem, so maybe it's better to add a temporary file
> with the old name containing "#include ",
> which I will remove in the following merge window or as a follow-up.

I guess we really need that.  Do you want to do a quick fixup or should I send
a patch?
--
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] VFIO: platform: AMD xgbe reset module

2015-10-15 Thread Christoffer Dall
On Thu, Oct 15, 2015 at 01:21:55PM +0200, Arnd Bergmann wrote:
> On Thursday 15 October 2015 10:08:02 Eric Auger wrote:
> > Hi Arnd,
> > On 10/14/2015 05:38 PM, Arnd Bergmann wrote:
> > > On Wednesday 14 October 2015 15:33:12 Eric Auger wrote:
> > >> --- a/drivers/vfio/platform/vfio_platform_common.c
> > >> +++ b/drivers/vfio/platform/vfio_platform_common.c
> > >> @@ -31,6 +31,11 @@ static const struct vfio_platform_reset_combo 
> > >> reset_lookup_table[] = {
> > >> .reset_function_name = 
> > >> "vfio_platform_calxedaxgmac_reset",
> > >> .module_name = "vfio-platform-calxedaxgmac",
> > >> },
> > >> +   {
> > >> +   .compat = "amd,xgbe-seattle-v1a",
> > >> +   .reset_function_name = "vfio_platform_amdxgbe_reset",
> > >> +   .module_name = "vfio-platform-amdxgbe",
> > >> +   },
> > >>  };
> > >>  
> > >>  static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
> > >>
> > > 
> > > This is causing build errors for me when CONFIG_MODULES is disabled.
> > Sorry about that and thanks for reporting the issue
> > > 
> > > Could this please be restructured so vfio_platform_get_reset does
> > > not attempt to call __symbol_get() but instead has the drivers
> > > register themselves properly to a subsystem?
> > OK
> > 
> > Could you elaborate about "has the drivers register themselves properly
> > to a subsystem".
> > 
> > My first proposal when coping with this problematic of being able to add
> > reset plugins to the vfio-platform driver was to create new drivers per
> > device requiring reset. but this was considered painful for end-users,
> > who needed to be aware of the right driver to bind - and I think that
> > makes sense - (https://lkml.org/lkml/2015/4/17/568) .
> 
> Having multiple drivers indeed sucks, but your current approach isn't
> that much better, as you still have two modules that are used to driver
> the same hardware.
> 
> I would expect that the same driver that is used for the normal
> operation and that it calls a function to register itself to vfio
> by passing a structure with the device and reset function pointer.
> 
> > A naive question I dare to ask, wouldn't it be acceptable to make
> > vfio_platform depend on CONFIG_MODULES? Don't we disable modules for
> > security purpose? In that context would we use VFIO?
> 
> I think a lot of embedded systems turn off modules to save a little
> memory, speed up boot time and simplify their user space.
> 
> Aside from that, the current method is highly unusual and looks a bit
> fragile to me, as you are relying on internals of the module loader
> code. It's also a layering violation as the generic code needs to be
> patched for each device specific module that is added, and we try
> to avoid that.
> 
> A possible solution could be something inside the xgbe driver like
> 
> 
> static void xgbe_init_module(void)
> {
>   int ret = 0;
> 
>   if (IS_ENABLED(CONFIG_AMD_XGBE_ETHERNET)
>   ret = platform_driver_register(_driver);
>   if (ret)
>   return ret;
> 
>   if (IS_ENABLED(CONFIG_VFIO_PLATFORM))
>   ret = vfio_platform_register_reset(_of_match, 
> xgbe_platform_reset);
> 
>   return ret; 
> }
> 
> This way you have exactly one driver module that gets loaded for the
> device and you can use it either with the platform_driver or through
> vfio.
> 
> A nicer way that would be a little more work would be to integrate
> the reset infrastructure into 'struct platform_driver' framework,
> by adding another callback to the it for doing the interaction with
> vfio, something like
> 
> enum vfio_platform_op {
>   VFIO_PLATFORM_BIND,
>   VFIO_PLATFORM_UNBIND,
>   VFIO_PLATFORM_RESET,
> };
> 
> struct platform_driver {
> int (*probe)(struct platform_device *);
> int (*remove)(struct platform_device *);
>   ...
>   int (*vfio_manage)(struct platform_device *, enum vfio_platform_op);
> struct device_driver driver;
> };
> 
> This would integrate much more closely into the platform driver framework,
> just like the regular vfio driver integrates into the PCI framework.
> Unlike PCI however, you can't just use the generic driver framework to
> unbind the driver, because you still need device specific code.
> 
Thanks for these suggestions, really helpful.

What I don't understand in the latter example is how VFIO knows which
struct platform_driver to interact with?

Also, just so I'm sure I understand correctly, VFIO_PLATFORM_UNBIND is
then called by VFIO before the VFIO driver unbinds from the device
(unbinding the platform driver from the device being a completely
separate thing)?

Thanks,
-Christoffer
--
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] xen/arm: correct comment in enlighten.c

2015-10-15 Thread Juergen Gross

David or Stefano,

On 09/14/2015 03:39 PM, Stefano Stabellini wrote:

On Mon, 14 Sep 2015, Juergen Gross wrote:

Correct a comment in arch/arm/xen/enlighten.c referencing a wrong
source file.

Signed-off-by: Juergen Gross 


Acked-by: Stefano Stabellini 


does one of you plan to take this patch?


Juergen





  arch/arm/xen/enlighten.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eeeab07..5421706 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -284,7 +284,7 @@ void xen_arch_resume(void) { }
  void xen_arch_suspend(void) { }


-/* In the hypervisor.S file. */
+/* In the hypercall.S file. */
  EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
  EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
  EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
--
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/



--
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 1/6] block: cleanup blkdev_ioctl

2015-10-15 Thread Christoph Hellwig
Split out helpers for all non-trivial ioctls to make this function simpler,
and also start passing around a pointer version of the argument, as that's
what most ioctl handlers actually need.

Signed-off-by: Christoph Hellwig 
---
 block/ioctl.c | 227 --
 1 file changed, 127 insertions(+), 100 deletions(-)

diff --git a/block/ioctl.c b/block/ioctl.c
index 8061eba..df62b47 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -193,10 +193,20 @@ int blkdev_reread_part(struct block_device *bdev)
 }
 EXPORT_SYMBOL(blkdev_reread_part);
 
-static int blk_ioctl_discard(struct block_device *bdev, uint64_t start,
-uint64_t len, int secure)
+static int blk_ioctl_discard(struct block_device *bdev, fmode_t mode,
+   unsigned long arg, unsigned long flags)
 {
-   unsigned long flags = 0;
+   uint64_t range[2];
+   uint64_t start, len;
+
+   if (!(mode & FMODE_WRITE))
+   return -EBADF;
+
+   if (copy_from_user(range, (void __user *)arg, sizeof(range)))
+   return -EFAULT;
+
+   start = range[0];
+   len = range[1];
 
if (start & 511)
return -EINVAL;
@@ -207,14 +217,24 @@ static int blk_ioctl_discard(struct block_device *bdev, 
uint64_t start,
 
if (start + len > (i_size_read(bdev->bd_inode) >> 9))
return -EINVAL;
-   if (secure)
-   flags |= BLKDEV_DISCARD_SECURE;
return blkdev_issue_discard(bdev, start, len, GFP_KERNEL, flags);
 }
 
-static int blk_ioctl_zeroout(struct block_device *bdev, uint64_t start,
-uint64_t len)
+static int blk_ioctl_zeroout(struct block_device *bdev, fmode_t mode,
+   unsigned long arg)
 {
+   uint64_t range[2];
+   uint64_t start, len;
+
+   if (!(mode & FMODE_WRITE))
+   return -EBADF;
+
+   if (copy_from_user(range, (void __user *)arg, sizeof(range)))
+   return -EFAULT;
+
+   start = range[0];
+   len = range[1];
+
if (start & 511)
return -EINVAL;
if (len & 511)
@@ -295,89 +315,115 @@ static inline int is_unrecognized_ioctl(int ret)
ret == -ENOIOCTLCMD;
 }
 
-/*
- * always keep this in sync with compat_blkdev_ioctl()
- */
-int blkdev_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,
-   unsigned long arg)
+static int blkdev_flushbuf(struct block_device *bdev, fmode_t mode,
+   unsigned cmd, unsigned long arg)
 {
-   struct gendisk *disk = bdev->bd_disk;
-   struct backing_dev_info *bdi;
-   loff_t size;
-   int ret, n;
-   unsigned int max_sectors;
+   int ret;
 
-   switch(cmd) {
-   case BLKFLSBUF:
-   if (!capable(CAP_SYS_ADMIN))
-   return -EACCES;
-
-   ret = __blkdev_driver_ioctl(bdev, mode, cmd, arg);
-   if (!is_unrecognized_ioctl(ret))
-   return ret;
+   if (!capable(CAP_SYS_ADMIN))
+   return -EACCES;
 
-   fsync_bdev(bdev);
-   invalidate_bdev(bdev);
-   return 0;
+   ret = __blkdev_driver_ioctl(bdev, mode, cmd, arg);
+   if (!is_unrecognized_ioctl(ret))
+   return ret;
 
-   case BLKROSET:
-   ret = __blkdev_driver_ioctl(bdev, mode, cmd, arg);
-   if (!is_unrecognized_ioctl(ret))
-   return ret;
-   if (!capable(CAP_SYS_ADMIN))
-   return -EACCES;
-   if (get_user(n, (int __user *)(arg)))
-   return -EFAULT;
-   set_device_ro(bdev, n);
-   return 0;
+   fsync_bdev(bdev);
+   invalidate_bdev(bdev);
+   return 0;
+}
 
-   case BLKDISCARD:
-   case BLKSECDISCARD: {
-   uint64_t range[2];
+static int blkdev_roset(struct block_device *bdev, fmode_t mode,
+   unsigned cmd, unsigned long arg)
+{
+   int ret, n;
 
-   if (!(mode & FMODE_WRITE))
-   return -EBADF;
+   ret = __blkdev_driver_ioctl(bdev, mode, cmd, arg);
+   if (!is_unrecognized_ioctl(ret))
+   return ret;
+   if (!capable(CAP_SYS_ADMIN))
+   return -EACCES;
+   if (get_user(n, (int __user *)arg))
+   return -EFAULT;
+   set_device_ro(bdev, n);
+   return 0;
+}
 
-   if (copy_from_user(range, (void __user *)arg, sizeof(range)))
-   return -EFAULT;
+static int blkdev_getgeo(struct block_device *bdev,
+   struct hd_geometry __user *argp)
+{
+   struct gendisk *disk = bdev->bd_disk;
+   struct hd_geometry geo;
+   int ret;
 
-   return blk_ioctl_discard(bdev, range[0], range[1],
-cmd == BLKSECDISCARD);
-   }
-   case BLKZEROOUT: {
-   uint64_t 

Re: [PATCH] x86: setup: extend low identity map to cover whole kernel range

2015-10-15 Thread H. Peter Anvin
On October 14, 2015 2:39:58 PM PDT, Andy Lutomirski  wrote:
>On Wed, Oct 14, 2015 at 2:00 PM, Matt Fleming
> wrote:
>> On Wed, 14 Oct, at 09:22:03AM, Andy Lutomirski wrote:
>>> On Wed, Oct 14, 2015 at 6:52 AM, Matt Fleming
> wrote:
>>> > (Pulling in luto for low-level x86 fu)
>>> >
>>> > On Wed, 14 Oct, at 01:30:45PM, Paolo Bonzini wrote:
>>> >> On 32-bit systems, the initial_page_table is reused by
>>> >> efi_call_phys_prolog as an identity map to call
>>> >> SetVirtualAddressMap.  efi_call_phys_prolog takes care of
>>> >> converting the current CPU's GDT to a physical address too.
>>> >>
>>> >> For PAE kernels the identity mapping is achieved by aliasing the
>>> >> first PDPE for the kernel memory mapping into the first PDPE
>>> >> of initial_page_table.  This makes the EFI stub's trick "just
>work".
>>> >>
>>> >> However, for non-PAE kernels there is no guarantee that the
>identity
>>> >> mapping in the initial_page_table extends as far as the GDT; in
>this
>>> >> case, accesses to the GDT will cause a page fault (which quickly
>becomes
>>> >> a triple fault).  Fix this by copying the kernel mappings from
>>> >> swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET
>and at
>>> >> identity mapping.
>>> >
>>> > Oops, good catch guys. This is clearly a bug, but...
>>> >
>>> >> For some reason, this is only reproducible with QEMU's dynamic
>translation
>>> >> mode, and not for example with KVM.  However, even under KVM one
>can clearly
>>> >> see that the page table is bogus:
>>>
>>> I haven't looked at the code, but it wouldn't surprise me if this is
>>> some kind of TLB issue.  With the hardware TLB (which is in use on
>>> KVM), it seems quite likely that the GDT is pretty much always in
>the
>>> TLB and, if nothing flushes global mappings, then it'll probably
>stick
>>> around.
>>
>> From some quick experiments it appears that you can skate past this
>> issue if you don't receive any interrupts while the bogus GDT pointer
>> is loaded, or if you avoid reloading the segment registers in
>general.
>> Which is interesting because I assumed that writing to GDTR took
>> immediate effect.
>
>Trivia for your amusement:
>
>AFAICT it's entirely permissible for the GDTR and/or LDT descriptor to
>point to unmapped memory.  Any attempt to use them (segment loads,
>interrupts, IRET, etc) will try to access that memory as if the access
>came from CPL 0 and, if the access fails, will generate a valid page
>fault with CR2 pointing into the GDT or LDT.
>
>Xen is nuts^Wclever and actually uses this.
>
>Of course, if your #PF vector references a GDT or LDT descriptor and
>trying to load that descriptor results in a page fault, you get a
>double fault.
>
>I learned this while trying to puzzle out why v1 of my LDT
>synchronization patch caused random faults on Xen.
>
>--Andy

There is no "if"... you can't get to an interrupt vector without going through 
the GDT or LDT.  That being said, the GDT or LDT can be partially mapped.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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 net-next 0/4] net: dsa: mv88e6xxx: fix hardware bridging

2015-10-15 Thread Vivien Didelot
On Oct. Wednesday 14 (42) 06:44 PM, Florian Fainelli wrote:
> On 14/10/15 18:28, Vivien Didelot wrote:
> > On Oct. Thursday 15 (42) 12:46 AM, Andrew Lunn wrote:
> >> On Sun, Oct 11, 2015 at 06:08:34PM -0400, Vivien Didelot wrote:
> >>> DSA and its drivers currently hook the NETDEV_CHANGEUPPER net_device 
> >>> event in
> >>> order to configure the VLAN map of every port.
> >>>
> >>> This VLAN map is a feature of these switch chips to hardcode and restrict 
> >>> which
> >>> output ports a given input port can egress frames to.
> >>>
> >>> A Linux bridge is a simple untagged VLAN propagated by the bridge code 
> >>> itself.
> >>> With a proper 802.1Q support, a driver does not need this hook anymore, 
> >>> and
> >>> will simply program the related VLAN object.
> >>>
> >>> This patchset improves the hardware bridging code in the mv88e6xxx driver 
> >>> with
> >>> a strict 802.1Q mode.
> >>
> >> Hi Vivien
> >>
> >> I just tested this as part of net-next/master, and found a problem
> >>
> >> If i do:
> >>
> >> ip link set lan0 up
> >> ip addr add 192.168.10.2/24 dev lan0
> >>
> >> It will not ping. Looking in sys/kernel/debug/dsa0/stats i see
> >> broadcast packets, probably ARP, being received at the port.
> >> But they are not being forwarded out the CPU port.
> >>
> >> If however i do
> >>
> >> brctl addbr br0
> >> brctl addif br0 lan0
> >> ip addr add 192.168.10.2/24 dev br0
> >> ip link set br0 up
> >>
> >> i can ping.
> >>
> >> So it looks like we are too restrictive by default. You should be able
> >> to use interfaces as they are, without a bridge.
> > 
> > Correct, if the ports are not in a VLAN by default, they cannot talk.
> 
> The expectation for DSA devices, if no bridge device is configured is to
> have each port be able to talk to the CPU port only, but this has to
> work out of the box.

OK, I might have forgotten this requirement. I also just noticed that
you mentioned it in Documentation/networking/dsa/dsa.txt. Thanks for the
reminder.

> > 
> > If you want to, I think the special VLAN 0 can be used for that
> > purpose. IIRC, in a given configuration, Linux add the interfaces
> > (thus programs the hardware) with VLAN 0. I'm not sure when, maybe
> > when the .ndo_vlan_rx_add_vid is implemented, I need to give it a
> > shot.
> 
> But if you do that, won't that put all DSA ports into VLAN 0? Would
> not that break isolation between each ports as expected for a DSA
> switch?

You're correct, then VLAN 0 is not an option. I have something else in
mind, fix coming soon.

> > 
> > Otherwise, I can send you a patch configuring the VLAN 0 on switch
> > setup if this is the behavior we want.

Thanks,
-v
--
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: [PATCHv3] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ

2015-10-15 Thread Will Deacon
On Thu, Oct 15, 2015 at 02:12:41PM +0200, Szabolcs Nagy wrote:
> * Will Deacon  [2015-10-09 11:33:52 +0100]:
> 
> > On Fri, Oct 09, 2015 at 03:59:40PM +0530, Manjeet Pawar wrote:
> > > MINSIGSTKSZ and SIGSTKSZ for ARM64 are not correctly set in latest kernel.
> > > This patch fixes this issue.
> > > 
> > > This issue is reported in LTP (testcase: sigaltstack02.c).
> > > Testcase failed when sigaltstack() called with stack size "MINSIGSTKSZ - 
> > > 1"
> > > Since in Glibc-2.22, MINSIGSTKSZ is set to 5120 but in kernel
> > > it is set to 2048 so testcase gets failed.
> > > 
> > > Testcase Output:
> > > sigaltstack02 1  TPASS  :  stgaltstack() fails, Invalid Flag 
> > > value,errno:22
> > > sigaltstack02 2  TFAIL  :  sigaltstack() returned 0, expected -1,errno:12
> > 
> > I'm still unable to reproduce this failure. Is this with defconfig?
> > 
> > > Reported Issue in Glibc Bugzilla:
> > > Bugfix in Glibc-2.22: [Bug 16850]
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=16850
> > > 
> > > Signed-off-by: Akhilesh Kumar 
> > > Signed-off-by: Manjeet Pawar 
> > > Signed-off-by: Rohit Thapliyal 
> > > ---
> > > v1 -> Changes in uapi overall header
> > > v2 -> Changes done in arm64 headers
> > > v3 -> Changes done in both uapi & arm64 headers
> > > 
> > >  arch/arm64/include/uapi/asm/signal.h |3 +++
> > >  include/uapi/asm-generic/signal.h|2 ++
> > >  2 files changed, 5 insertions(+)
> > 
> > Acked-by: Will Deacon 
> > 
> > Arnd: are you planning to take this via asm-generic, or shall I queue it
> > on the arm64 fixes branch?
> > 
> 
> i just noticed this and wanted to note that an old
> glibc can fail on a new kernel with this patch if
> an application uses MINSIGSTKSZ altstack.

I was worried about that (which was also why I didn't Cc stable on this,
because we shouldn't pretend that glibc and the kernel are synchronised),
but the value *is* incorrect and glibc has already been updated. In
other words, not merging this patch is also problematic, because we're
advertising a size that's significantly too small.

Would you rather we kept the old incorrect value in the kernel headers?

Will
--
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] staging: rtl8192u: simplify conditional statement

2015-10-15 Thread Dan Carpenter
On Thu, Oct 15, 2015 at 01:33:14PM +0100, Luis de Bethencourt wrote:
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c 
> b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> index c443e2e..1c2d1a4 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> @@ -466,10 +466,7 @@ void ieee80211_softmac_scan_syncro(struct 
> ieee80211_device *ieee)
>   /* this prevent excessive time wait when we
>* need to wait for a syncro scan to end..
>*/
> - if(ieee->state < IEEE80211_LINKED)
> - ;
> - else
> - if (ieee->sync_scan_hurryup)
> + if(!ieee->state > IEEE80211_LINKED && ieee->sync_scan_hurryup)

The precedence is wrong here.  What you wrote is equivalent to:

if ((!ieee->state) > IEEE80211_LINKED)
goto out;

Which can never be true.  Also use checkpatch.pl on your patches before
sending.

regards,
dan carpenter

--
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: Runtime PM causes oops on next-20151015

2015-10-15 Thread Michael Ellerman
On Thu, 2015-10-15 at 11:22 +0200, Thierry Reding wrote:
> Hi Rafael, Wonhong,
> 
> Todays linux-next breaks rather spectacularly for drivers using runtime
> PM. The culprit seems to be this commit:
> 
>   commit 7d24068e144adc03b805806645d732cf79488717
>   Author: Wonhong Kwon <wonhongk...@gmail.com>
>   Date:   Tue Oct 6 10:10:20 2015 +0900
> 
>   PM / hibernate: Move pm_init/pm_disk_init to late_initcall_sync
> 
>   pm_init is being invoked by core_initcall and 
> hibernate_image_size_init
>   calculates preferred image size (image_size) based on total pages
>   (totalram_pages). This totalram_pages can be modified during various
>   initcall-s phase and this can cause miscalculated image_size.
> 
>   For example, when CMA is being used, init_cma_reserved_pageblock 
> tries
>   to change the totalram_pages and this job is done during 
> core_initcall.
>   In order words, the totalram_pages doesn't take CMA reserved pages 
> into
>   account when image_size is calculated and it can be too small.
> 
>   Move pm_init and pm_disk_init to late_initcall_sync so that it 
> happens
>   after all other initcall-s change the totalram_pages.
> 
>   Reported-by: Sangseok Lee <sangseok@lge.com>
>   Signed-off-by: Wonhong Kwon <wonhong.k...@lge.com>
>   Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> 

I'm seeing one too on powerpc:

Unable to handle kernel paging request for data at address 0x0030
Faulting instruction address: 0xc02e4094
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 5 PID: 1 Comm: swapper/0 Not tainted 
4.3.0-rc5-next-20151015-50217-ge2be40d-dirty #37
task: c001fefc ti: c001fb00 task.ti: c001fb00
NIP: c000002e4094 LR: c0c79dd4 CTR: c0c79d90
REGS: c001fb003900 TRAP: 0300   Not tainted  
(4.3.0-rc5-next-20151015-50217-ge2be40d-dirty)
MSR: 80019032 <SF,EE,ME,IR,DR,RI>  CR: 28000882  XER: 2000
CFAR: c00d117c DAR: 0030 DSISR: 4000 SOFTE: 1 
GPR00: c000b074 c001fb003b80 c0e93800  
GPR04: c0d15c80  0001ff15 0026 
GPR08: c0d0f748 c0f41a10 c0d0f8e8 c0abc59d 
GPR12: c0b42400 cfdc1680 c000b960  
GPR16:     
GPR20:     
GPR24:  c0de0360 c0c45d28  
GPR28: c0deca80 c0d103c0 c001fbc905c0 c0d103c0 
NIP [c02e4094] .sysfs_create_file_ns+0x4/0x50
LR [c0c79dd4] .__machine_initcall_pseries_apo_pm_init+0x44/0x60
Call Trace:
[c001fb003b80] [c04852cc] .kasprintf+0x2c/0x40 (unreliable)
[c001fb003bf0] [c000b074] .do_one_initcall+0xc4/0x250
[c001fb003ce0] [c0c64560] .kernel_init_freeable+0x268/0x348
[c001fb003db0] [c000b97c] .kernel_init+0x1c/0x140
[c001fb003e30] [c00095ac] .ret_from_kernel_thread+0x58/0xac
Instruction dump:
419e001c 3ce2ffa8 38e7be60 4bfffea4 3ce2ffa8 38e7bea8 4bfffe9c 3ce2ffa8 
38e7bea8 4bfffe8c 6000 2c23  41820028 2fa3 419e0020 
---[ end trace d2a742ce359651dd ]---

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b


Which starts at:

  static int __init apo_pm_init(void)
  {
return (sysfs_create_file(power_kobj, _poweron_attr.attr));
  }
  machine_device_initcall(pseries, apo_pm_init);

And seems to be caused by power_kobj being NULL:

  0:mon> d $power_kobj
  c0f41a10    ||


cheers


--
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] compiler, READ_ONCE: Fix build failure with some older GCC

2015-10-15 Thread Andrey Ryabinin
Some old versions of GCC doesn't handle __alias (or maybe a combination
of 'static __always_inline __alias') right.

GCC creates outline and unused copy of __read_once_size_check()
function in the object file which references memcpy and causes
the build failure:
arch/x86/entry/vdso/vclock_gettime.o: In function 
`__read_once_size_check':
vclock_gettime.c:(.text+0x5f): undefined reference to `memcpy'
arch/x86/entry/vdso/vgetcpu.o: In function `__read_once_size_check':
vgetcpu.c:(.text+0x2f): undefined reference to `memcpy'

We could avoid using alias to work around this problem.

Reported-by: Stephen Rothwell 
Signed-off-by: Andrey Ryabinin 
---
 include/linux/compiler.h | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index aa2ae4c..3436a4c 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -231,8 +231,11 @@ void __read_once_size_nocheck(const volatile void *p, void 
*res, int size)
__READ_ONCE_SIZE;
 }
 #else
-static __always_inline __alias(__read_once_size_check)
-void __read_once_size_nocheck(const volatile void *p, void *res, int size);
+static __always_inline
+void __read_once_size_nocheck(const volatile void *p, void *res, int size)
+{
+   __READ_ONCE_SIZE;
+}
 #endif
 
 static __always_inline void __write_once_size(volatile void *p, void *res, int 
size)
-- 
2.4.9

--
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] iio: mma8452: support either of the available interrupt pins

2015-10-15 Thread Mark Rutland
On Wed, Oct 14, 2015 at 05:12:32PM +0200, Lars-Peter Clausen wrote:
> On 10/14/2015 03:15 PM, Martin Kepplinger wrote:
> [...]
> > +   if (irq1 > 0)
> > +   client->irq = irq1;
> 
> You must not overwrite client->irq, that field is manged by the I2C core and
> is supposed to be read only for device drivers.

Ok.

I think for the moment the simlpest thing to do would be to check which
of INT1 and INT2 match client->irq, and use that.

Thanks,
Mark.
--
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 2/3] irqchip: irq-mips-gic: Provide function to map GIC user section

2015-10-15 Thread Thomas Gleixner
On Thu, 15 Oct 2015, Qais Yousef wrote:
> It could be refactored but the DT binding already specifies the GIC timer as a
> subnode of GIC. Exposing this usermode register is the only thing left in the
> register set that GIC driver wasn't dealing with.
> 
> Little gain in changing all of this now I think?

Well, the not so little gain is clear separation and a sane design.

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 5/5] KVM: x86: MMU: Eliminate an extra memory slot search in mapping_level()

2015-10-15 Thread Takuya Yoshikawa
Calling kvm_vcpu_gfn_to_memslot() twice in mapping_level() should be
avoided since getting a slot by binary search may not be negligible,
especially for virtual machines with many memory slots.

Signed-off-by: Takuya Yoshikawa 
---
 arch/x86/kvm/mmu.c |   17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 78a3d08..8d285dc 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -818,14 +818,11 @@ static void unaccount_shadowed(struct kvm *kvm, struct 
kvm_mmu_page *sp)
kvm->arch.indirect_shadow_pages--;
 }
 
-static int has_wrprotected_page(struct kvm_vcpu *vcpu,
-   gfn_t gfn,
-   int level)
+static int __has_wrprotected_page(gfn_t gfn, int level,
+ struct kvm_memory_slot *slot)
 {
-   struct kvm_memory_slot *slot;
struct kvm_lpage_info *linfo;
 
-   slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
if (slot) {
linfo = lpage_info_slot(gfn, slot, level);
return linfo->write_count;
@@ -834,6 +831,14 @@ static int has_wrprotected_page(struct kvm_vcpu *vcpu,
return 1;
 }
 
+static int has_wrprotected_page(struct kvm_vcpu *vcpu, gfn_t gfn, int level)
+{
+   struct kvm_memory_slot *slot;
+
+   slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
+   return __has_wrprotected_page(gfn, level, slot);
+}
+
 static int host_mapping_level(struct kvm *kvm, gfn_t gfn)
 {
unsigned long page_size;
@@ -893,7 +898,7 @@ static int mapping_level(struct kvm_vcpu *vcpu, gfn_t 
large_gfn,
max_level = min(kvm_x86_ops->get_lpage_level(), host_level);
 
for (level = PT_DIRECTORY_LEVEL; level <= max_level; ++level)
-   if (has_wrprotected_page(vcpu, large_gfn, level))
+   if (__has_wrprotected_page(large_gfn, level, slot))
break;
 
return level - 1;
-- 
1.7.9.5

--
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] ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board

2015-10-15 Thread Masahiro Yamada
2015-10-15 17:58 GMT+09:00 Masahiro Yamada :
> The IRQ signal from external devices on this board is connected to
> the XIRQ1 pin of the SoC.  The IRQ number should be 51, not 50.
>
> Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b 
> SoC/board support")
> Signed-off-by: Masahiro Yamada 
> ---
>
> Hi Olof and Arnd,
>
> Could you apply this simple fix for Linux 4.13, please?
> (if it is troublesome, I can wait until Linux 4.14-rc1.)
>
> Thanks
>


This patch turned out wrong.
I retract this one and will send v2 later.

Sorry.




-- 
Best Regards
Masahiro Yamada
--
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 1/3] sched: introduce a new migration flag to task_struct

2015-10-15 Thread Peter Zijlstra
On Thu, Oct 15, 2015 at 06:01:14PM +0900, byungchul.p...@lge.com wrote:
> From: Byungchul Park 
> 
> This patch removes a weird coupling between se->avg.last_update_time and
> the condition checking for migration, and introduce a new migration flag.
> Now, scheduler can use the flag instead of se->avg.last_update_time to
> check if migration already happened or not.

Was there a problem with that coupling? This does not explain.

> Signed-off-by: Byungchul Park 
> ---
>  include/linux/sched.h |3 +++
>  kernel/sched/core.c   |1 +
>  kernel/sched/fair.c   |   22 --
>  kernel/sched/sched.h  |1 +
>  4 files changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 699228b..a104c72 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1379,6 +1379,9 @@ struct task_struct {
>  #endif
>   int on_rq;
>  
> + /* For indicating if a migration has happened. */
> + int migrated;

You just created another 4 byte hole instead of filling one.

>   int prio, static_prio, normal_prio;
>   unsigned int rt_priority;
>   const struct sched_class *sched_class;

> +++ b/kernel/sched/fair.c
> @@ -2771,14 +2771,15 @@ static void detach_entity_load_avg(struct cfs_rq 
> *cfs_rq, struct sched_entity *s
>  
>  /* Add the load generated by se into cfs_rq's load average */
>  static inline void
> -enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
> +enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se, int 
> flags)
>  {
>   struct sched_avg *sa = >avg;
>   u64 now = cfs_rq_clock_task(cfs_rq);
> - int migrated, decayed;
> + int decayed;
> + int migrated = flags & ENQUEUE_MIGRATED;
> + int created = !sa->last_update_time;
>  
> - migrated = !sa->last_update_time;
> - if (!migrated) {
> + if (!migrated && !created) {
>   __update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
>   se->on_rq * scale_load_down(se->load.weight),
>   cfs_rq->curr == se, NULL);
> @@ -2789,10 +2790,10 @@ enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> sched_entity *se)
>   cfs_rq->runnable_load_avg += sa->load_avg;
>   cfs_rq->runnable_load_sum += sa->load_sum;
>  
> - if (migrated)
> + if (migrated || created)
>   attach_entity_load_avg(cfs_rq, se);
>  
> - if (decayed || migrated)
> + if (decayed || migrated || created)
>   update_tg_load_avg(cfs_rq, 0);
>  }

How much extra code gets generated for this? These _are_ hot paths.

> @@ -4136,6 +4137,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>   struct cfs_rq *cfs_rq;
>   struct sched_entity *se = >se;
>  
> + flags = flags | (xchg(>migrated, 0) ? ENQUEUE_MIGRATED : 0);

Yeah, no way. xchg() is an absurdly expensive instruction, we do not
place that unconditionally in the enqueue path.

> @@ -5021,7 +5023,7 @@ static void migrate_task_rq_fair(struct task_struct *p, 
> int next_cpu)
>   remove_entity_load_avg(>se);
>  
>   /* Tell new CPU we are migrated */
> - p->se.avg.last_update_time = 0;
> + p->migrated = 1;
>  
>   /* We have migrated, no longer consider this task hot */
>   p->se.exec_start = 0;
> @@ -8082,7 +8084,7 @@ static void task_move_group_fair(struct task_struct *p)
>   set_task_rq(p, task_cpu(p));
>  
>  #ifdef CONFIG_SMP
> - /* Tell se's cfs_rq has been changed -- migrated */
> + /* Tell se's cfs_rq has been changed */
>   p->se.avg.last_update_time = 0;
>  #endif
>   attach_task_cfs_rq(p);

So my tiny little patch removed more code than it added, and simplified
a few things, like the above. Now we have 2 states to worry about.

How is this making things better?

> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index af6f252..66d0552 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1158,6 +1158,7 @@ static const u32 prio_to_wmult[40] = {
>  #define ENQUEUE_WAKING   0
>  #endif
>  #define ENQUEUE_REPLENISH8
> +#define ENQUEUE_MIGRATED 16

Won't actually apply that..
--
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: [PATCHv3 08/11] arm64: Check for selected granule support

2015-10-15 Thread Suzuki K. Poulose
On Thu, Oct 15, 2015 at 11:45:15AM +0100, Mark Rutland wrote:
> On Wed, Oct 14, 2015 at 04:13:47PM -0500, Jeremy Linton wrote:
> > On 10/14/2015 06:20 AM, Suzuki K. Poulose wrote:
> > 
> > >+ * Checks if the selected granule size is supported by the CPU.
> > >+ * If it doesn't park the CPU
> > 
> > The problem is when you park the boot CPU.
> > 
> > I think for EFI there is a slightly better error mechanism. This
> > tweak will print an error and return to the EFI boot manager rather
> > than hanging the machine without any notification. Now it prints:
> > 
> > EFI stub: Booting Linux Kernel...
> > EFI stub: ERROR: 16K granule not supported by this machine
> > EFI stub: ERROR: Failed to relocate kernel
> > FS4:\>
> 
> Neat. We should definitely have checks like this in the stub.
> 
> However, we still need checks in head.S, given !EFI systems, SMP, and
> kexec, so this is a complementary mechanism.

Indeed. I meant to add the above check. The updated patch looks like :

8>

Author: Suzuki K. Poulose 
Date:   Wed Oct 14 11:25:16 2015 +0100

arm64: Check for selected granule support

Ensure that the selected page size is supported by the CPU(s). If it isn't
park the CPU. A check is added to the EFI stub to detect if the boot CPU
supports the page size, failing which, we fail the boot gracefully, with
an error message.

Signed-off-by: Suzuki K. Poulose 
[ Added a check to EFI stub ]
Signed-off-by: Jeremy Linton 

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index a7f3d4b..72d814c 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -44,6 +44,26 @@
 #define SET_PSTATE_PAN(x) __inst_arm(0xd500 | REG_PSTATE_PAN_IMM |\
 (!!x)<<8 | 0x1f)
 
+
+#define ID_AA64MMFR0_TGRAN4_SHIFT  28
+#define ID_AA64MMFR0_TGRAN64_SHIFT 24
+#define ID_AA64MMFR0_TGRAN16_SHIFT 20
+
+#define ID_AA64MMFR0_TGRAN4_NI 0xf
+#define ID_AA64MMFR0_TGRAN4_ON 0x0
+#define ID_AA64MMFR0_TGRAN64_NI0xf
+#define ID_AA64MMFR0_TGRAN64_ON0x0
+#define ID_AA64MMFR0_TGRAN16_NI0x0
+#define ID_AA64MMFR0_TGRAN16_ON0x1
+
+#if defined(CONFIG_ARM64_4K_PAGES)
+#define ID_AA64MMFR0_TGRAN_SHIFT   ID_AA64MMFR0_TGRAN4_SHIFT
+#define ID_AA64MMFR0_TGRAN_SUPPORTED   ID_AA64MMFR0_TGRAN4_ON
+#else
+#define ID_AA64MMFR0_TGRAN_SHIFT   ID_AA64MMFR0_TGRAN64_SHIFT
+#define ID_AA64MMFR0_TGRAN_SUPPORTED   ID_AA64MMFR0_TGRAN64_ON
+#endif
+
 #ifdef __ASSEMBLY__
 
.irp
num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30
diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
index 816120e..77d7de1 100644
--- a/arch/arm64/kernel/efi-stub.c
+++ b/arch/arm64/kernel/efi-stub.c
@@ -11,8 +11,15 @@
  */
 #include 
 #include 
+#include 
 #include 
 
+#if defined(CONFIG_ARM64_4K_PAGES)
+#define PAGE_SIZE_STR  "4K"
+#elif defined(CONFIG_ARM64_64K_PAGES)
+#define PAGE_SIZE_STR  "64K"
+#endif
+
 efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
unsigned long *image_addr,
unsigned long *image_size,
@@ -25,6 +32,17 @@ efi_status_t __init handle_kernel_image(efi_system_table_t 
*sys_table_arg,
unsigned long kernel_size, kernel_memsize = 0;
unsigned long nr_pages;
void *old_image_addr = (void *)*image_addr;
+   u64 aa64mmfr0_el1;
+
+   /*
+* Check to see if the CPU supports the requested pagesize
+*/
+   asm volatile("mrs %0, ID_AA64MMFR0_EL1" : "=r" (aa64mmfr0_el1));
+   aa64mmfr0_el1 >>= ID_AA64MMFR0_TGRAN_SHIFT;
+   if ((aa64mmfr0_el1 & 0xf) != ID_AA64MMFR0_TGRAN_SUPPORTED) {
+   pr_efi_err(sys_table_arg, PAGE_SIZE_STR" granule not supported 
by the CPU\n");
+   return EFI_UNSUPPORTED;
+   }
 
/* Relocate the image, if required. */
kernel_size = _edata - _text;
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 7ace955..514c1cc 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -31,10 +31,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #define __PHYS_OFFSET  (KERNEL_START - TEXT_OFFSET)
@@ -613,10 +614,17 @@ ENDPROC(__secondary_switched)
  *  x0  = SCTLR_EL1 value for turning on the MMU.
  *  x27 = *virtual* address to jump to upon completion
  *
- * other registers depend on the function called upon completion
+ * Other registers depend on the function called upon completion.
+ *
+ * Checks if the selected granule size is supported by the CPU.
+ * If it isn't, park the CPU
  */
.section".idmap.text", "ax"
 __enable_mmu:
+   mrs x1, ID_AA64MMFR0_EL1
+   ubfxx2, x1, 

Re: [PATCH v3 1/4] mtd: nand: allow compile test of MTD_NAND_PXA3xx

2015-10-15 Thread Antoine Tenart
Hi Arnd,

On Thu, Oct 15, 2015 at 01:44:19PM +0200, Arnd Bergmann wrote:
> On Thursday 15 October 2015 17:12:18 kbuild test robot wrote:
> >drivers/mtd/nand/pxa3xx_nand.c: In function 'drain_fifo':
> > >> drivers/mtd/nand/pxa3xx_nand.c:507:4: error: implicit declaration of 
> > >> function 'readsl' [-Werror=implicit-function-declaration]
> >readsl(info->mmio_base + NDDB, data, 8);
> >^
> 
> It should be easy to fix this by changing the code to use ioread32_rep() 
> instead
> of readsl(). They behave the same way on pointers returned from ioremap() etc,
> and the other one is available on all architectures.

Sure, I can add a patch fixing this prior to the one allowing to compile
test the pxa3xx nand driver.

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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: [RESEND PATCH v2] pwm-backlight: Avoid backlight flicker when probed from DT

2015-10-15 Thread Christian Gmeiner
2015-10-14 15:25 GMT+02:00 Philipp Zabel :
> If the driver is probed from the device tree, and there is a phandle
> property set on it, and the enable GPIO is already configured as output,
> and the backlight is currently disabled, keep it disabled.
> If all these conditions are met, assume there will be some other driver
> that can enable the backlight at the appropriate time.
>
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v1:
>  - Also check if the regulator is enabled. If the power supply is disabled,
>and a phandle points to it, the backlight should stay powered down.
> ---
>  drivers/video/backlight/pwm_bl.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/drivers/video/backlight/pwm_bl.c 
> b/drivers/video/backlight/pwm_bl.c
> index eff379b..31afd6d 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -199,6 +199,8 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
> struct backlight_properties props;
> struct backlight_device *bl;
> struct pwm_bl_data *pb;
> +   int initial_blank = FB_BLANK_UNBLANK;
> +   bool phandle;
> int ret;
>
> if (!data) {
> @@ -264,12 +266,32 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
> pb->enable_gpio = gpio_to_desc(data->enable_gpio);
> }
>
> +   phandle = of_find_property(pdev->dev.of_node, "phandle", NULL) != 
> NULL;
> +
> +   if (pb->enable_gpio) {
> +   /*
> +* If the driver is probed from the device tree and there is a
> +* phandle link pointing to the backlight node, it is safe to
> +* assume that another driver will enable the backlight at the
> +* appropriate time. Therefore, if it is disabled, keep it so.
> +*/
> +   if (phandle &&
> +   gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_OUT &&
> +   gpiod_get_value(pb->enable_gpio) == 0)
> +   initial_blank = FB_BLANK_POWERDOWN;
> +   else
> +   gpiod_direction_output(pb->enable_gpio, 1);
> +   }
> +
> pb->power_supply = devm_regulator_get(>dev, "power");
> if (IS_ERR(pb->power_supply)) {
> ret = PTR_ERR(pb->power_supply);
> goto err_alloc;
> }
>
> +   if (phandle && !regulator_is_enabled(pb->power_supply))
> +   initial_blank = FB_BLANK_POWERDOWN;
> +
> pb->pwm = devm_pwm_get(>dev, NULL);
> if (IS_ERR(pb->pwm)) {
> ret = PTR_ERR(pb->pwm);
> @@ -321,6 +343,7 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
> }
>
> bl->props.brightness = data->dft_brightness;
> +   bl->props.power = initial_blank;
> backlight_update_status(bl);
>
> platform_set_drvdata(pdev, bl);
> --
> 2.6.1
>

Reviewed-by: Christian Gmeiner 
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
--
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/4] Enable Ethernet on StiH407 family boards

2015-10-15 Thread Maxime Coquelin



On 10/01/2015 05:56 PM, Maxime Coquelin wrote:

This series enables Ethernet support on STiH407 family reference design
boards.

These boards use the RTL8367 Switch as PHY.
As it is previously configured by the bootloader, we declare it as a fixed
link.

Maxime Coquelin (4):
   ARM: dts: Fix RGMII pinctrl timings
   ARM: dts: Add Ethernet node to STiH407 family
   ARM: dts: Enable Ethernet on STi's B2120 boards
   ARM: dts: Enable Ethernet on STi's B2199 board

  arch/arm/boot/dts/stih407-b2120.dts|  1 +
  arch/arm/boot/dts/stih407-family.dtsi  | 27 +++
  arch/arm/boot/dts/stih407-pinctrl.dtsi |  4 ++--
  arch/arm/boot/dts/stih410-b2120.dts|  1 +
  arch/arm/boot/dts/stih418-b2199.dts|  8 
  arch/arm/boot/dts/stihxxx-b2120.dtsi   |  6 ++
  6 files changed, 45 insertions(+), 2 deletions(-)


Series applied.

Maxime
--
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] ARM: DT: STi: STiH418: Fix mmc0 clock configuration

2015-10-15 Thread Maxime Coquelin



On 08/24/2015 04:23 PM, Gabriel Fernandez wrote:

This patch configure correctly the MMC-0 clock for STiH418 platform.

Signed-off-by: Gabriel Fernandez 
Acked-by: Maxime Coquelin 
---
  arch/arm/boot/dts/stih418.dtsi | 6 ++
  1 file changed, 6 insertions(+)



Applied, thanks.

Maxime
--
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] scsi: advansys needs ISA dma api for ISA support

2015-10-15 Thread Hannes Reinecke
On 10/15/2015 02:06 PM, Hannes Reinecke wrote:
> On 10/12/2015 05:10 PM, Arnd Bergmann wrote:
>> The advansys drvier uses the request_dma function that is used on ISA
>> machines for the internal DMA controller, which causes build errors
>> on platforms that have ISA slots but do not provide the ISA DMA API:
>>
>> drivers/scsi/advansys.c: In function 'advansys_board_found':
>> drivers/scsi/advansys.c:11300:10: error: implicit declaration of function 
>> 'request_dma' [-Werror=implicit-function-declaration]
>>
>> The problem now showed up in ARM randconfig builds after commit
>> 6571fb3f8b7f ("advansys: Update to version 3.5 and remove compilation
>> warning") made it possible to build on platforms that have neither
>> VIRT_TO_BUS nor ISA_DMA_API but that do have ISA.
>>
>> This adds the missing dependency.
>>
>> Signed-off-by: Arnd Bergmann 
>>
>> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
>> index d2f480b04a52..d4aa6a1a806c 100644
>> --- a/drivers/scsi/Kconfig
>> +++ b/drivers/scsi/Kconfig
>> @@ -499,6 +499,7 @@ config SCSI_ADVANSYS
>>  tristate "AdvanSys SCSI support"
>>  depends on SCSI
>>  depends on ISA || EISA || PCI
>> +depends on ISA_DMA_API || !ISA
>>  help
>>This is a driver for all SCSI host adapters manufactured by
>>AdvanSys. It is documented in the kernel source in
>>
> Sorry to chime in again, but wouldn't this allow to build on platforms
> which have neither ISA_DMA_API nor ISA, like oldish sparc systems with
> proprietary S-BUS?
> 
> Why not ISA_DMA_API || EISA || PCI ?
> 
Gnaa. Ignore this.

Mailer got confused about which mails are more recent than others :-(

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 1/3] sched: introduce a new migration flag to task_struct

2015-10-15 Thread Byungchul Park
On Thu, Oct 15, 2015 at 01:18:13PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 15, 2015 at 06:01:14PM +0900, byungchul.p...@lge.com wrote:
> > From: Byungchul Park 
> > 
> > This patch removes a weird coupling between se->avg.last_update_time and
> > the condition checking for migration, and introduce a new migration flag.
> > Now, scheduler can use the flag instead of se->avg.last_update_time to
> > check if migration already happened or not.
> 
> Was there a problem with that coupling? This does not explain.

The reason why i introduce the new flag is that 3/3 patch makes
se->avg.last_update_time non-zero consistently, so we cannot use the
condition "se->avg.last_update_time == 0" to check if migration has
happened.

> > +++ b/kernel/sched/fair.c
> > @@ -2771,14 +2771,15 @@ static void detach_entity_load_avg(struct cfs_rq 
> > *cfs_rq, struct sched_entity *s
> >  
> >  /* Add the load generated by se into cfs_rq's load average */
> >  static inline void
> > -enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > +enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se, 
> > int flags)
> >  {
> > struct sched_avg *sa = >avg;
> > u64 now = cfs_rq_clock_task(cfs_rq);
> > -   int migrated, decayed;
> > +   int decayed;
> > +   int migrated = flags & ENQUEUE_MIGRATED;
> > +   int created = !sa->last_update_time;
> >  
> > -   migrated = !sa->last_update_time;
> > -   if (!migrated) {
> > +   if (!migrated && !created) {
> > __update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
> > se->on_rq * scale_load_down(se->load.weight),
> > cfs_rq->curr == se, NULL);
> > @@ -2789,10 +2790,10 @@ enqueue_entity_load_avg(struct cfs_rq *cfs_rq, 
> > struct sched_entity *se)
> > cfs_rq->runnable_load_avg += sa->load_avg;
> > cfs_rq->runnable_load_sum += sa->load_sum;
> >  
> > -   if (migrated)
> > +   if (migrated || created)
> > attach_entity_load_avg(cfs_rq, se);
> >  
> > -   if (decayed || migrated)
> > +   if (decayed || migrated || created)
> > update_tg_load_avg(cfs_rq, 0);
> >  }
> 
> How much extra code gets generated for this? These _are_ hot paths.

Okay, you are right. It's a hot path.

> 
> > @@ -4136,6 +4137,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct 
> > *p, int flags)
> > struct cfs_rq *cfs_rq;
> > struct sched_entity *se = >se;
> >  
> > +   flags = flags | (xchg(>migrated, 0) ? ENQUEUE_MIGRATED : 0);
> 
> Yeah, no way. xchg() is an absurdly expensive instruction, we do not
> place that unconditionally in the enqueue path.

Okay.

> 
> > @@ -5021,7 +5023,7 @@ static void migrate_task_rq_fair(struct task_struct 
> > *p, int next_cpu)
> > remove_entity_load_avg(>se);
> >  
> > /* Tell new CPU we are migrated */
> > -   p->se.avg.last_update_time = 0;
> > +   p->migrated = 1;
> >  
> > /* We have migrated, no longer consider this task hot */
> > p->se.exec_start = 0;
> > @@ -8082,7 +8084,7 @@ static void task_move_group_fair(struct task_struct 
> > *p)
> > set_task_rq(p, task_cpu(p));
> >  
> >  #ifdef CONFIG_SMP
> > -   /* Tell se's cfs_rq has been changed -- migrated */
> > +   /* Tell se's cfs_rq has been changed */
> > p->se.avg.last_update_time = 0;
> >  #endif
> > attach_task_cfs_rq(p);
> 
> So my tiny little patch removed more code than it added, and simplified
> a few things, like the above. Now we have 2 states to worry about.
> 
> How is this making things better?

As I said, this patch is mainly for 3/3 patch. But if you worry about
regression by this 1/3 patch, I will think more about another way.

> 
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index af6f252..66d0552 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -1158,6 +1158,7 @@ static const u32 prio_to_wmult[40] = {
> >  #define ENQUEUE_WAKING 0
> >  #endif
> >  #define ENQUEUE_REPLENISH  8
> > +#define ENQUEUE_MIGRATED   16
> 
> Won't actually apply that..

Okay, I got your concern, let me think more..

By the way, what do you think about the approach of 3/3 patch?

Thanks,
Byungchul

> --
> 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/
--
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] i2c: designware-platdrv: enable RuntimePM before registering to the core

2015-10-15 Thread Mika Westerberg
On Thu, Oct 15, 2015 at 01:49:25PM +0200, Wolfram Sang wrote:
> On Fri, Oct 09, 2015 at 10:39:24AM +0100, Wolfram Sang wrote:
> > From: Wolfram Sang 
> > 
> > The core may register clients attached to this master which may use
> > funtionality from the master. So, RuntimePM must be enabled before, 
> > otherwise
> > this will fail.
> > 
> > Signed-off-by: Wolfram Sang 
> 
> No feedback here, but for the other two drivers the same principle was
> acked. CCing Mika, just in case.

Looks good to me :-)

> 
> Applied to for-current, thanks!
> 
> > ---
> >  drivers/i2c/busses/i2c-designware-platdrv.c | 13 +++--
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
> > b/drivers/i2c/busses/i2c-designware-platdrv.c
> > index 3dd2de31a2f8d3..73d58415bbc100 100644
> > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > @@ -253,12 +253,6 @@ static int dw_i2c_probe(struct platform_device *pdev)
> > adap->dev.parent = >dev;
> > adap->dev.of_node = pdev->dev.of_node;
> >  
> > -   r = i2c_add_numbered_adapter(adap);
> > -   if (r) {
> > -   dev_err(>dev, "failure adding adapter\n");
> > -   return r;
> > -   }
> > -
> > if (dev->pm_runtime_disabled) {
> > pm_runtime_forbid(>dev);
> > } else {
> > @@ -268,6 +262,13 @@ static int dw_i2c_probe(struct platform_device *pdev)
> > pm_runtime_enable(>dev);
> > }
> >  
> > +   r = i2c_add_numbered_adapter(adap);
> > +   if (r) {
> > +   dev_err(>dev, "failure adding adapter\n");
> > +   pm_runtime_disable(>dev);
> > +   return r;
> > +   }
> > +
> > return 0;
> >  }
> >  
> > -- 
> > 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: [Xen-devel] [PATCH] xen/arm: correct comment in enlighten.c

2015-10-15 Thread David Vrabel
On 14/09/15 14:20, Juergen Gross wrote:
> Correct a comment in arch/arm/xen/enlighten.c referencing a wrong
> source file.

Applied to for-linus-4.4, thanks.

Sorry for the delay.

David
--
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: [alsa-devel] [RFC PATCH] ASoC: Modify check condition of multiple bindings of components

2015-10-15 Thread Koro Chen
On Thu, 2015-10-15 at 13:10 +0100, Mark Brown wrote:
> On Wed, Oct 14, 2015 at 11:00:01AM +0200, Lars-Peter Clausen wrote:
> 
> > It was never intended that it is possible to bind a component to multiple
> > cards. That it was possible was a bug that was overlooked and some people
> > tried to do it which caused apparently random crashes later on, caused by
> > the data structure corruption. This is why we added the check to catch this
> > kind of mistake early and to avoid the crashes.
> 
> This is true, but I do think it's something that we should have some
> story on supporting for some of this hardware that has a bunch of
> channels in one IP block that can't really interact with each other.
> It's going to make it a lot easier for people to think about the
> hardware and how to describe it.
Yes, and if in some cases we must use multiple cards, it seems the only
option left is to separate an ASoC platform driver into multiple
drivers. It does not make sense to me since there is only one HW block.


--
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] bnx2fc: Modify supported product numbers in MODULE_DESCRIPTION

2015-10-15 Thread Masanari Iida
Currently bnx2fc driver support not only BMC57710,
but also BCM57711, BCM57712, BCM57800, BCM57810 and BCM57840.
It is better to modify from "BCM57710" to "BCM5771x/BCM578xx"

Signed-off-by: Masanari Iida 
---
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index d5cdc47..565764c 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -32,7 +32,7 @@ static char version[] =
 
 
 MODULE_AUTHOR("Bhanu Prakash Gollapudi ");
-MODULE_DESCRIPTION("QLogic NetXtreme II BCM57710 FCoE Driver");
+MODULE_DESCRIPTION("QLogic NetXtreme II BCM5771x/BCM578xx FCoE Driver");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(DRV_MODULE_VERSION);
 
-- 
2.6.1.133.gf5b6079

--
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: build problems (Was: [PATCH v3 1/2] Provide READ_ONCE_NOCHECK())

2015-10-15 Thread Andrey Ryabinin
On 10/15/2015 12:18 PM, Stephen Rothwell wrote:
> Hi Andrey,
> 
> On Tue, 13 Oct 2015 18:28:07 +0300 Andrey Ryabinin  
> wrote:
>>
>> Some code may perform racy by design memory reads. This could be harmless,
>> yet such code may produce KASAN warnings.
>>
>> To hide such accesses from KASAN this patch introduces READ_ONCE_NOCHECK()
>> macro. KASAN will not check the memory accessed by READ_ONCE_NOCHECK().
>>
>> This patch creates __read_once_size_nocheck() a clone of
>> __read_once_size_check() (renamed __read_once_size()).
>> The only difference between them is 'no_sanitized_address' attribute
>> appended to '*_nocheck' function. This attribute tells the compiler that
>> instrumentation of memory accesses should not be applied to that function.
>> We declare it as static '__maybe_unsed' because GCC is not capable to
>> inline such function: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
>>
>> With KASAN=n READ_ONCE_NOCHECK() is just a clone of READ_ONCE().
>>
>> Signed-off-by: Andrey Ryabinin 
>> ---
>>  include/linux/compiler-gcc.h | 13 ++
>>  include/linux/compiler.h | 60 
>> ++--
>>  2 files changed, 60 insertions(+), 13 deletions(-)
> 
> I am pretty sure that this patch is causing quite a bit of compile
> breakage in linux-next today.  During the day I compile with gcc 4.9.0
> and did not see any problems with c86_64 allmodconfig, or i386
> defconfig etc, but overnight we compile with older compilers (gcc 4.6.3
> in particular) and are getting quite a few errors:
> 

Looks like that older GCC doesn't like __alias (or combination of static 
__always_inline __alias).
It creates outline and unused copy of __read_once_size_check() function in the 
object file.
Should be easy to work around this.

> From an i386 allnoconfig build:
> 
> arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
> /home/kisskb/slave/src/arch/x86/entry/vdso/Makefile:154: recipe for target 
> 'arch/x86/entry/vdso/vdso32.so.dbg' failed
> 
> From an x86_64 allnoconfig build:
> 
> arch/x86/entry/vdso/vclock_gettime.o: In function `__read_once_size_check':
> vclock_gettime.c:(.text+0x5f): undefined reference to `memcpy'
> arch/x86/entry/vdso/vgetcpu.o: In function `__read_once_size_check':
> vgetcpu.c:(.text+0x2f): undefined reference to `memcpy'
> 
> and several others ...
> 
--
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/5] x86/setup/crash: Check memblock_reserve() retval

2015-10-15 Thread Borislav Petkov
On Thu, Oct 15, 2015 at 05:18:26PM +0800, Dave Young wrote:
> Seems there's no checking for other callback to memblock_reserve in setup.c
> Need another cleanup?

True story. It sure does.

> BTW, a further cleanup is reasonable to me, there's a lot of below patter:
> memblock_find_in_range
> error checking
> memblock_reserve
> error checking
> 
> So a new function memblock_reserve_in_range is reasonable.

Well, in some of the callsites, the first "error checking" issues
a specific message, depending on the subsystem. The following
memblock_reserve() is mostly unchecked though. At least that should be
fixed...

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
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] staging: netlogic: xlr_net.h: fixedcoding stly warnings

2015-10-15 Thread Mike Rapoport
On Wed, Oct 14, 2015 at 07:29:30PM +0530, Sakshi Bansal wrote:
> Fixed block comments usage of * on subsequent lines
> 
> Signed-off-by: Sakshi Bansal 
> ---
>  drivers/staging/netlogic/xlr_net.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Please fix the patch subject. There's a space missing in "fixed coding"
and "stly" should have been "style"
 
> diff --git a/drivers/staging/netlogic/xlr_net.h 
> b/drivers/staging/netlogic/xlr_net.h
> index 2f65ec5..7ae8874 100644
> --- a/drivers/staging/netlogic/xlr_net.h
> +++ b/drivers/staging/netlogic/xlr_net.h
> @@ -999,7 +999,8 @@
>  #define MAC_CRC_LEN 4
>  #define MAX_NUM_MSGRNG_STN_CC   128
>  #define MAX_MSG_SND_ATTEMPTS 100 /* 13 stns x 4 entry msg/stn +
> -headroom */
> +  * headroom
> +  */
>  
>  #define MAC_FRIN_TO_BE_SENT_THRESHOLD   16
>  
> -- 
> 2.1.0
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
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 1/5] KVM: x86: MMU: Make force_pt_level bool

2015-10-15 Thread Takuya Yoshikawa
This will be passed to a function later.

Signed-off-by: Takuya Yoshikawa 
---
 arch/x86/kvm/mmu.c |8 
 arch/x86/kvm/paging_tmpl.h |4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index b8482c0..2262728 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2962,7 +2962,7 @@ static int nonpaging_map(struct kvm_vcpu *vcpu, gva_t v, 
u32 error_code,
 {
int r;
int level;
-   int force_pt_level;
+   bool force_pt_level;
pfn_t pfn;
unsigned long mmu_seq;
bool map_writable, write = error_code & PFERR_WRITE_MASK;
@@ -3476,7 +3476,7 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t 
gpa, u32 error_code,
pfn_t pfn;
int r;
int level;
-   int force_pt_level;
+   bool force_pt_level;
gfn_t gfn = gpa >> PAGE_SHIFT;
unsigned long mmu_seq;
int write = error_code & PFERR_WRITE_MASK;
@@ -3497,9 +3497,9 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t 
gpa, u32 error_code,
 
if (mapping_level_dirty_bitmap(vcpu, gfn) ||
!check_hugepage_cache_consistency(vcpu, gfn, PT_DIRECTORY_LEVEL))
-   force_pt_level = 1;
+   force_pt_level = true;
else
-   force_pt_level = 0;
+   force_pt_level = false;
 
if (likely(!force_pt_level)) {
level = mapping_level(vcpu, gfn);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 736e6ab..07f1a4e 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -698,7 +698,7 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t 
addr, u32 error_code,
int r;
pfn_t pfn;
int level = PT_PAGE_TABLE_LEVEL;
-   int force_pt_level;
+   bool force_pt_level;
unsigned long mmu_seq;
bool map_writable, is_self_change_mapping;
 
@@ -747,7 +747,7 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t 
addr, u32 error_code,
force_pt_level = mapping_level_dirty_bitmap(vcpu, walker.gfn)
   || is_self_change_mapping;
else
-   force_pt_level = 1;
+   force_pt_level = true;
if (!force_pt_level) {
level = min(walker.level, mapping_level(vcpu, walker.gfn));
walker.gfn = walker.gfn & ~(KVM_PAGES_PER_HPAGE(level) - 1);
-- 
1.7.9.5

--
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/5] KVM: x86: MMU: Simplify force_pt_level calculation code in FNAME(page_fault)()

2015-10-15 Thread Takuya Yoshikawa
As a bonus, an extra memory slot search can be eliminated when
is_self_change_mapping is true.

Signed-off-by: Takuya Yoshikawa 
---
 arch/x86/kvm/paging_tmpl.h |   15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 07f1a4e..8ebc3a5 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -743,15 +743,14 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t 
addr, u32 error_code,
is_self_change_mapping = FNAME(is_self_change_mapping)(vcpu,
  , user_fault, >arch.write_fault_to_shadow_pgtable);
 
-   if (walker.level >= PT_DIRECTORY_LEVEL)
-   force_pt_level = mapping_level_dirty_bitmap(vcpu, walker.gfn)
-  || is_self_change_mapping;
-   else
+   if (walker.level >= PT_DIRECTORY_LEVEL && !is_self_change_mapping) {
+   force_pt_level = mapping_level_dirty_bitmap(vcpu, walker.gfn);
+   if (!force_pt_level) {
+   level = min(walker.level, mapping_level(vcpu, 
walker.gfn));
+   walker.gfn = walker.gfn & ~(KVM_PAGES_PER_HPAGE(level) 
- 1);
+   }
+   } else
force_pt_level = true;
-   if (!force_pt_level) {
-   level = min(walker.level, mapping_level(vcpu, walker.gfn));
-   walker.gfn = walker.gfn & ~(KVM_PAGES_PER_HPAGE(level) - 1);
-   }
 
mmu_seq = vcpu->kvm->mmu_notifier_seq;
smp_rmb();
-- 
1.7.9.5

--
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 3/5] KVM: x86: MMU: Merge mapping_level_dirty_bitmap() into mapping_level()

2015-10-15 Thread Takuya Yoshikawa
This is necessary to eliminate an extra memory slot search later.

Signed-off-by: Takuya Yoshikawa 
---
 arch/x86/kvm/mmu.c |   29 ++---
 arch/x86/kvm/paging_tmpl.h |6 +++---
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2262728..890cd69 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -870,10 +870,16 @@ static bool mapping_level_dirty_bitmap(struct kvm_vcpu 
*vcpu, gfn_t large_gfn)
return !gfn_to_memslot_dirty_bitmap(vcpu, large_gfn, true);
 }
 
-static int mapping_level(struct kvm_vcpu *vcpu, gfn_t large_gfn)
+static int mapping_level(struct kvm_vcpu *vcpu, gfn_t large_gfn,
+bool *force_pt_level)
 {
int host_level, level, max_level;
 
+   if (likely(!*force_pt_level))
+   *force_pt_level = mapping_level_dirty_bitmap(vcpu, large_gfn);
+   if (unlikely(*force_pt_level))
+   return PT_PAGE_TABLE_LEVEL;
+
host_level = host_mapping_level(vcpu->kvm, large_gfn);
 
if (host_level == PT_PAGE_TABLE_LEVEL)
@@ -2962,14 +2968,13 @@ static int nonpaging_map(struct kvm_vcpu *vcpu, gva_t 
v, u32 error_code,
 {
int r;
int level;
-   bool force_pt_level;
+   bool force_pt_level = false;
pfn_t pfn;
unsigned long mmu_seq;
bool map_writable, write = error_code & PFERR_WRITE_MASK;
 
-   force_pt_level = mapping_level_dirty_bitmap(vcpu, gfn);
+   level = mapping_level(vcpu, gfn, _pt_level);
if (likely(!force_pt_level)) {
-   level = mapping_level(vcpu, gfn);
/*
 * This path builds a PAE pagetable - so we can map
 * 2mb pages at maximum. Therefore check if the level
@@ -2979,8 +2984,7 @@ static int nonpaging_map(struct kvm_vcpu *vcpu, gva_t v, 
u32 error_code,
level = PT_DIRECTORY_LEVEL;
 
gfn &= ~(KVM_PAGES_PER_HPAGE(level) - 1);
-   } else
-   level = PT_PAGE_TABLE_LEVEL;
+   }
 
if (fast_page_fault(vcpu, v, level, error_code))
return 0;
@@ -3495,20 +3499,15 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t 
gpa, u32 error_code,
if (r)
return r;
 
-   if (mapping_level_dirty_bitmap(vcpu, gfn) ||
-   !check_hugepage_cache_consistency(vcpu, gfn, PT_DIRECTORY_LEVEL))
-   force_pt_level = true;
-   else
-   force_pt_level = false;
-
+   force_pt_level = !check_hugepage_cache_consistency(vcpu, gfn,
+  PT_DIRECTORY_LEVEL);
+   level = mapping_level(vcpu, gfn, _pt_level);
if (likely(!force_pt_level)) {
-   level = mapping_level(vcpu, gfn);
if (level > PT_DIRECTORY_LEVEL &&
!check_hugepage_cache_consistency(vcpu, gfn, level))
level = PT_DIRECTORY_LEVEL;
gfn &= ~(KVM_PAGES_PER_HPAGE(level) - 1);
-   } else
-   level = PT_PAGE_TABLE_LEVEL;
+   }
 
if (fast_page_fault(vcpu, gpa, level, error_code))
return 0;
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 8ebc3a5..bf39d0f 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -744,9 +744,9 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t 
addr, u32 error_code,
  , user_fault, >arch.write_fault_to_shadow_pgtable);
 
if (walker.level >= PT_DIRECTORY_LEVEL && !is_self_change_mapping) {
-   force_pt_level = mapping_level_dirty_bitmap(vcpu, walker.gfn);
-   if (!force_pt_level) {
-   level = min(walker.level, mapping_level(vcpu, 
walker.gfn));
+   level = mapping_level(vcpu, walker.gfn, _pt_level);
+   if (likely(!force_pt_level)) {
+   level = min(walker.level, level);
walker.gfn = walker.gfn & ~(KVM_PAGES_PER_HPAGE(level) 
- 1);
}
} else
-- 
1.7.9.5

--
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 0/5] KVM: x86: MMU: Eliminate extra memory slot searches in page fault handlers

2015-10-15 Thread Takuya Yoshikawa
In page fault handlers, both mapping_level_dirty_bitmap() and mapping_level()
do a memory slot search, binary search, through kvm_vcpu_gfn_to_memslot(), which
may not be negligible especially for virtual machines with many memory slots.

With a bit of cleanup effort, the patch set reduces this overhead.

  [PATCH 1/5] KVM: x86: MMU: Make force_pt_level bool
  [PATCH 2/5] KVM: x86: MMU: Simplify force_pt_level calculation code in 
FNAME(page_fault)()
  [PATCH 3/5] KVM: x86: MMU: Merge mapping_level_dirty_bitmap() into 
mapping_level()
  [PATCH 4/5] KVM: x86: MMU: Remove mapping_level_dirty_bitmap()
  [PATCH 5/5] KVM: x86: MMU: Eliminate an extra memory slot search in 
mapping_level()

Takuya
--
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/


[GIT PULL] pin control fixes for v4.3

2015-10-15 Thread Linus Walleij
Hi Linus,

here are some overdue (what can I say, I was on a short vacation)
driver fixes for the pin control subsystem. Details in the signed tag.
Please pull them in!

Yours,
Linus Walleij

The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde:

  Linux 4.3-rc2 (2015-09-20 14:32:34 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
tags/pinctrl-v4.3-3

for you to fetch changes up to de7f8e3e6b1bb6e3e400bf675e4052fa3d927987:

  pinctrl: uniphier: fix input enable settings for PH1-sLD8
(2015-10-02 04:06:26 -0700)


Slightly delayed driver fixes for pin control:
- Allwinner sun5i A10s had a faulty mapping
- Freescale i.MX25 had some bad arithmetics
- Uniphier PH1-sLD8 missed some input enable settings


Hans de Goede (1):
  pinctrl: sun5i: Fix a10s pwm1 pinctrl mapping

Masahiro Yamada (1):
  pinctrl: uniphier: fix input enable settings for PH1-sLD8

Uwe Kleine-König (1):
  pinctrl: imx25: ensure that a pin with id i is at position i in
the info array

 drivers/pinctrl/freescale/pinctrl-imx25.c   |   4 +-
 drivers/pinctrl/sunxi/pinctrl-sun5i-a10s.c  |   2 +-
 drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c | 226 ++--
 3 files changed, 117 insertions(+), 115 deletions(-)
--
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] ext4: use private version of page_zero_new_buffers() for data=journal mode

2015-10-15 Thread Jan Kara
On Fri 09-10-15 00:01:09, Ted Tso wrote:
> If there is a error while copying data from userspace into the page
> cache during a write(2) system call, in data=journal mode, in
> ext4_journalled_write_end() were using page_zero_new_buffers() from
> fs/buffer.c.  Unfortunately, this sets the buffer dirty flag, which is
> no good if journalling is enabled.  This is a long-standing bug that
> goes back for years and years in ext3, but a combination of (a)
> data=journal not being very common, (b) in many case it only results
> in a warning message. and (c) only very rarely causes the kernel hang,
> means that we only really noticed this as a problem when commit
> 998ef75ddb caused this failure to happen frequently enough to cause
> generic/208 to fail when run in data=journal mode.
> 
> The fix is to have our own version of this function that doesn't call
> mark_dirty_buffer(), since we will end up calling
> ext4_handle_dirty_metadata() on the buffer head(s) in questions very
> shortly afterwards in ext4_journalled_write_end().
> 
> Thanks to Dave Hansen and Linus Torvalds for helping to identify the
> root cause of the problem.
> 
> Signed-off-by: Theodore Ts'o 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza
> ---
>  fs/ext4/inode.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index ae52e32..0a589bb 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -1181,6 +1181,38 @@ errout:
>   return ret ? ret : copied;
>  }
>  
> +/*
> + * This is a private version of page_zero_new_buffers() which doesn't
> + * set the buffer to be dirty, since in data=journalled mode we need
> + * to call ext4_handle_dirty_metadata() instad.
> + */
> +static void zero_new_buffers(struct page *page, unsigned from, unsigned to)
> +{
> + unsigned int block_start = 0, block_end;
> + struct buffer_head *head, *bh;
> +
> + bh = head = page_buffers(page);
> + do {
> + block_end = block_start + bh->b_size;
> + if (buffer_new(bh)) {
> + if (block_end > from && block_start < to) {
> + if (!PageUptodate(page)) {
> + unsigned start, size;
> +
> + start = max(from, block_start);
> + size = min(to, block_end) - start;
> +
> + zero_user(page, start, size);
> + set_buffer_uptodate(bh);
> + }
> + clear_buffer_new(bh);
> + }
> + }
> + block_start = block_end;
> + bh = bh->b_this_page;
> + } while (bh != head);
> +}
> +
>  static int ext4_journalled_write_end(struct file *file,
>struct address_space *mapping,
>loff_t pos, unsigned len, unsigned copied,
> @@ -1207,7 +1239,7 @@ static int ext4_journalled_write_end(struct file *file,
>   if (copied < len) {
>   if (!PageUptodate(page))
>   copied = 0;
> - page_zero_new_buffers(page, from+copied, to);
> + zero_new_buffers(page, from+copied, to);
>   }
>  
>   ret = ext4_walk_page_buffers(handle, page_buffers(page), from,
> -- 
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Jan Kara 
SUSE Labs, CR
--
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 7/8] tools/vm/slabinfo: cosmetic globals cleanup

2015-10-15 Thread Sergey Senozhatsky
checkpatch.pl complains about globals being explicitly zeroed
out: "ERROR: do not initialise globals to 0 or NULL".

New globals, introduced in this patch set, have no explicit 0
initialization; clean up the old ones to make it less hairy.

Signed-off-by: Sergey Senozhatsky 
---
 tools/vm/slabinfo.c | 54 ++---
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/tools/vm/slabinfo.c b/tools/vm/slabinfo.c
index 60beb91..86e698d0 100644
--- a/tools/vm/slabinfo.c
+++ b/tools/vm/slabinfo.c
@@ -53,43 +53,43 @@ struct aliasinfo {
struct slabinfo *slab;
 } aliasinfo[MAX_ALIASES];
 
-int slabs = 0;
-int actual_slabs = 0;
-int aliases = 0;
-int alias_targets = 0;
-int highest_node = 0;
+int slabs;
+int actual_slabs;
+int aliases;
+int alias_targets;
+int highest_node;
 
 char buffer[4096];
 
-int show_empty = 0;
-int show_report = 0;
-int show_alias = 0;
-int show_slab = 0;
+int show_empty;
+int show_report;
+int show_alias;
+int show_slab;
 int skip_zero = 1;
-int show_numa = 0;
-int show_track = 0;
-int show_first_alias = 0;
-int validate = 0;
-int shrink = 0;
-int show_inverted = 0;
-int show_single_ref = 0;
-int show_totals = 0;
-int sort_size = 0;
-int sort_active = 0;
-int set_debug = 0;
-int show_ops = 0;
-int show_activity = 0;
+int show_numa;
+int show_track;
+int show_first_alias;
+int validate;
+int shrink;
+int show_inverted;
+int show_single_ref;
+int show_totals;
+int sort_size;
+int sort_active;
+int set_debug;
+int show_ops;
+int show_activity;
 int output_lines = -1;
 int sort_loss;
 int extended_totals;
 int show_bytes;
 
 /* Debug options */
-int sanity = 0;
-int redzone = 0;
-int poison = 0;
-int tracking = 0;
-int tracing = 0;
+int sanity;
+int redzone;
+int poison;
+int tracking;
+int tracing;
 
 int page_size;
 
-- 
2.6.1.134.g4b1fd35

--
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 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

2015-10-15 Thread Mikko Rapeli
On Thu, Oct 15, 2015 at 11:29:12AM +0100, David Vrabel wrote:
> On 15/10/15 06:56, Mikko Rapeli wrote:
> > xen/interface/xen.h is not exported from kernel headers so remove the
> > dependency and provide needed defines for domid_t and xen_pfn_t if they
> > are not already defined by some other e.g. Xen specific headers.
> > 
> > Suggested by Andrew Cooper  on lkml message
> > <5569f9c9.8000...@citrix.com>.
> >
> > The ifdef for ARM is ugly but did not find better solutions for it.
> > 
> > Fixes userspace compilation error:
> > 
> > xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or 
> > directory
> [...]
> > --- a/include/uapi/xen/privcmd.h
> > +++ b/include/uapi/xen/privcmd.h
> > @@ -35,7 +35,19 @@
> >  
> >  #include 
> >  #include 
> > -#include 
> > +
> > +/* Might be defined by Xen specific headers, but if not */
> > +#ifndef domid_t
> > +typedef __u16 domid_t;
> > +#endif /* domid_t */
> 
> As the kbuild bot points out, this does not work since the existence of
> a typedef cannot be checked with #ifdef.

Yeah, this hack doesn't cut it. Sorry. Tried to implement these changes:
http://www.spinics.net/lists/linux-api/msg11048.html

> I'm not really sure what problem you're trying to solve.  A user space
> program making use of this interface gets the domid_t and xen_pfn_t etc
> typedefs from the headers provided as part of the libxenctrl library.

I'm trying to make sure that kernel headers in userspace compile with minimal
dependencies which are gcc and libc.

For me it is clear by now that many Linux API's and ABI's like Xen parts do
not live in the uapi header files and instead there's a separate userspace
library with needed headers and defines which have embedded copies of
the needed API and ABI definitions, like header files.

So how could this file be changed so that it compiles in userspace without
definitions from libxenctrl?

I guess I could copy the needed definitions for domid_t and xen_pfn_t from
xen/interface/xen.h of libxenctrl. That I should have done to begin with
instead of trying to hack something on my own.

-Mikko
--
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/8] tools/vm/slabinfo: limit the number of reported slabs

2015-10-15 Thread Sergey Senozhatsky
Introduce opt "-N|--lines=K" to limit the number of slabs
being reported in output_slabs().

Signed-off-by: Sergey Senozhatsky 
---
 tools/vm/slabinfo.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/tools/vm/slabinfo.c b/tools/vm/slabinfo.c
index 258ed01..2ef7f0c 100644
--- a/tools/vm/slabinfo.c
+++ b/tools/vm/slabinfo.c
@@ -79,6 +79,7 @@ int sort_active = 0;
 int set_debug = 0;
 int show_ops = 0;
 int show_activity = 0;
+int output_lines = -1;
 
 /* Debug options */
 int sanity = 0;
@@ -124,6 +125,7 @@ static void usage(void)
"-v|--validate  Validate slabs\n"
"-z|--zero  Include empty slabs\n"
"-1|--1ref  Single reference\n"
+   "-N|--lines=K   Show the first K slabs\n"
"\nValid debug options (FZPUT may be combined)\n"
"a / A  Switch on all debug options (=FZUP)\n"
"-  Switch off all debug options\n"
@@ -1242,11 +1244,14 @@ static void output_slabs(void)
 {
struct slabinfo *slab;
 
-   for (slab = slabinfo; slab < slabinfo + slabs; slab++) {
+   for (slab = slabinfo; (slab < slabinfo + slabs) &&
+   output_lines != 0; slab++) {
 
if (slab->alias)
continue;
 
+   if (output_lines != -1)
+   output_lines--;
 
if (show_numa)
slab_numa(slab, 0);
@@ -1285,6 +1290,7 @@ struct option opts[] = {
{ "validate", no_argument, NULL, 'v' },
{ "zero", no_argument, NULL, 'z' },
{ "1ref", no_argument, NULL, '1'},
+   { "lines", required_argument, NULL, 'N'},
{ NULL, 0, NULL, 0 }
 };
 
@@ -1296,7 +1302,7 @@ int main(int argc, char *argv[])
 
page_size = getpagesize();
 
-   while ((c = getopt_long(argc, argv, "aAd::Defhil1noprstvzTS",
+   while ((c = getopt_long(argc, argv, "aAd::Defhil1noprstvzTSN:",
opts, NULL)) != -1)
switch (c) {
case '1':
@@ -1358,7 +1364,13 @@ int main(int argc, char *argv[])
case 'S':
sort_size = 1;
break;
-
+   case 'N':
+   if (optarg) {
+   output_lines = atoi(optarg);
+   if (output_lines < 1)
+   output_lines = 1;
+   }
+   break;
default:
fatal("%s: Invalid option '%c'\n", argv[0], optopt);
 
-- 
2.6.1.134.g4b1fd35

--
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 4/8] tools/vm/slabinfo: fix alternate opts names

2015-10-15 Thread Sergey Senozhatsky
Fix mismatches between usage() output and real opts[] options.
Add missing alternative opt names, e.g., '-S' had no '--Size'
opts[] entry, etc.

Signed-off-by: Sergey Senozhatsky 
---
 tools/vm/slabinfo.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/vm/slabinfo.c b/tools/vm/slabinfo.c
index 2e154f1..de4974d 100644
--- a/tools/vm/slabinfo.c
+++ b/tools/vm/slabinfo.c
@@ -1294,12 +1294,14 @@ struct option opts[] = {
{ "first-alias", no_argument, NULL, 'f' },
{ "help", no_argument, NULL, 'h' },
{ "inverted", no_argument, NULL, 'i'},
+   { "slabs", no_argument, NULL, 'l' },
{ "numa", no_argument, NULL, 'n' },
{ "ops", no_argument, NULL, 'o' },
-   { "report", no_argument, NULL, 'r' },
{ "shrink", no_argument, NULL, 's' },
-   { "slabs", no_argument, NULL, 'l' },
-   { "track", no_argument, NULL, 't'},
+   { "report", no_argument, NULL, 'r' },
+   { "Size", no_argument, NULL, 'S'},
+   { "tracking", no_argument, NULL, 't'},
+   { "Totals", no_argument, NULL, 'T'},
{ "validate", no_argument, NULL, 'v' },
{ "zero", no_argument, NULL, 'z' },
{ "1ref", no_argument, NULL, '1'},
-- 
2.6.1.134.g4b1fd35

--
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 5/8] tools/vm/slabinfo: introduce extended totals mode

2015-10-15 Thread Sergey Senozhatsky
Add "-X|--Xtotals" opt to output extended totals summary,
which includes:
-- totals summary
-- slabs sorted by size
-- slabs sorted by loss (waste)

Example:
===

slabinfo --X -N 1
  Slabcache Totals
  
  Slabcaches :  91  Aliases  : 120->69  Active:  65
  Memory used: 568.3M   # Loss   :  30.4M   MRatio: 5%
  # Objects  : 920.1K   # PartObj: 161.2K   ORatio:17%

  Per CacheAverage Min Max   Total
  -
  #Objects   14.1K   1  227.8K  920.1K
  #Slabs   533   1   11.7K   34.7K
  #PartSlab 86   04.3K5.6K
  %PartSlab24%  0%100% 16%
  PartObjs  17   0  129.3K  161.2K
  % PartObj17%  0%100% 17%
  Memory  8.7M8.1K  384.7M  568.3M
  Used8.2M 160  366.5M  537.9M
  Loss  468.8K   0   18.2M   30.4M

  Per Object   Average Min Max
  -
  Memory   587   88.1K
  User 584   88.1K
  Loss   2   0  64

  Slabs sorted by size
  --
  Name   Objects ObjsizeSpace Slabs/Part/Cpu  O/S O %Fr %Ef 
Flg
  ext4_inode_cache2111421736   384.7M11732/40/10   18 3   0  95 
a

  Slabs sorted by loss
  --
  Name   Objects ObjsizeLoss Slabs/Part/Cpu  O/S O %Fr %Ef 
Flg
  ext4_inode_cache211142173618.2M11732/40/10   18 3   0  95 
a

Signed-off-by: Sergey Senozhatsky 
---
 tools/vm/slabinfo.c | 54 +++--
 1 file changed, 44 insertions(+), 10 deletions(-)

diff --git a/tools/vm/slabinfo.c b/tools/vm/slabinfo.c
index de4974d..44b83ce 100644
--- a/tools/vm/slabinfo.c
+++ b/tools/vm/slabinfo.c
@@ -81,6 +81,7 @@ int show_ops = 0;
 int show_activity = 0;
 int output_lines = -1;
 int sort_loss;
+int extended_totals;
 
 /* Debug options */
 int sanity = 0;
@@ -128,6 +129,7 @@ static void usage(void)
"-1|--1ref  Single reference\n"
"-N|--lines=K   Show the first K slabs\n"
"-L|--Loss  Sort by loss\n"
+   "-X|--Xtotals   Show extended summary information\n"
"\nValid debug options (FZPUT may be combined)\n"
"a / A  Switch on all debug options (=FZUP)\n"
"-  Switch off all debug options\n"
@@ -615,8 +617,7 @@ static void slabcache(struct slabinfo *s)
total_free ? (s->free_fastpath * 100 / total_free) : 0,
s->order_fallback, s->order, s->cmpxchg_double_fail,
s->cmpxchg_double_cpu_fail);
-   }
-   else
+   } else {
printf("%-21s %8ld %7d %8s %14s %4d %1d %3ld %3ld %s\n",
s->name, s->objects, s->object_size, size_str, dist_str,
s->objs_per_slab, s->order,
@@ -624,6 +625,7 @@ static void slabcache(struct slabinfo *s)
s->slabs ? (s->objects * s->object_size * 100) /
(s->slabs * (page_size << s->order)) : 100,
flags);
+   }
 }
 
 /*
@@ -1256,15 +1258,16 @@ static void read_slab_dir(void)
 static void output_slabs(void)
 {
struct slabinfo *slab;
+   int lines = output_lines;
 
for (slab = slabinfo; (slab < slabinfo + slabs) &&
-   output_lines != 0; slab++) {
+   lines != 0; slab++) {
 
if (slab->alias)
continue;
 
-   if (output_lines != -1)
-   output_lines--;
+   if (lines != -1)
+   lines--;
 
if (show_numa)
slab_numa(slab, 0);
@@ -1285,6 +1288,30 @@ static void output_slabs(void)
}
 }
 
+static void xtotals(void)
+{
+   totals();
+
+   link_slabs();
+   rename_slabs();
+
+   printf("\nSlabs sorted by size\n");
+   printf("--\n");
+   sort_loss = 0;
+   sort_size = 1;
+   sort_slabs();
+   output_slabs();
+
+   printf("\nSlabs sorted by loss\n");
+   printf("--\n");
+   line = 0;
+   sort_loss = 1;
+   sort_size = 0;
+   sort_slabs();
+   output_slabs();
+   printf("\n");
+}
+
 struct option opts[] = {
{ "aliases", no_argument, NULL, 'a' },
{ "activity", no_argument, NULL, 'A' },
@@ -1307,6 +1334,7 @@ struct option opts[] = {
{ "1ref", no_argument, NULL, '1'},
{ "lines", required_argument, NULL, 'N'},
{ "Loss", no_argument, NULL, 'L'},
+   

Re: [PATCH] compiler, READ_ONCE: Fix build failure with some older GCC

2015-10-15 Thread Ingo Molnar

* Andrey Ryabinin  wrote:

> Some old versions of GCC doesn't handle __alias (or maybe a combination
> of 'static __always_inline __alias') right.
> 
> GCC creates outline and unused copy of __read_once_size_check()
> function in the object file which references memcpy and causes
> the build failure:
>   arch/x86/entry/vdso/vclock_gettime.o: In function 
> `__read_once_size_check':
>   vclock_gettime.c:(.text+0x5f): undefined reference to `memcpy'
>   arch/x86/entry/vdso/vgetcpu.o: In function `__read_once_size_check':
>   vgetcpu.c:(.text+0x2f): undefined reference to `memcpy'
> 
> We could avoid using alias to work around this problem.
> 
> Reported-by: Stephen Rothwell 
> Signed-off-by: Andrey Ryabinin 
> ---
>  include/linux/compiler.h | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index aa2ae4c..3436a4c 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -231,8 +231,11 @@ void __read_once_size_nocheck(const volatile void *p, 
> void *res, int size)
>   __READ_ONCE_SIZE;
>  }
>  #else
> -static __always_inline __alias(__read_once_size_check)
> -void __read_once_size_nocheck(const volatile void *p, void *res, int size);
> +static __always_inline
> +void __read_once_size_nocheck(const volatile void *p, void *res, int size)
> +{
> + __READ_ONCE_SIZE;
> +}
>  #endif

Yeah, so could you please re-send the original two patches, with all the 
changes 
(typo fixes, renaming, this build fix, etc.) propagated that were found in 
testing 
and that were suggested in the review thread?

I'll remove the broken commits from linux-next meanwhile.

Thanks,

Ingo
--
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] smpboot: Add smpboot state variables instead of reusing CPU hotplug states

2015-10-15 Thread Daniel Wagner
The cpu hotplug state machine in smpboot.c is reusing the states from
cpu.h. That is confusing when it comes to the CPU_DEAD_FROZEN usage.
Paul explained to me that he was in need of an additional state
for destinguishing between a CPU error states. For this he just
picked CPU_DEAD_FROZEN.

8038dad7e888581266c76df15d70ca457a3c5910 smpboot: Add common code for 
notification from dying CPU
2a442c9c6453d3d043dfd89f2e03a1deff8a6f06 x86: Use common 
outgoing-CPU-notification code

Instead of reusing the states, let's add new definition inside
the smpboot.c file with explenation what those states
mean. Thanks Paul for providing them.

Signed-off-by: Daniel Wagner 
Cc: Thomas Gleixner 
Cc: "Paul E. McKenney" 
Cc: Peter Zijlstra 
Cc: xen-de...@lists.xenproject.org
Cc: linux-kernel@vger.kernel.org
---
 arch/x86/xen/smp.c  |  4 +--
 include/linux/cpu.h |  3 +-
 kernel/smpboot.c| 82 -
 3 files changed, 67 insertions(+), 22 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3f4ebf0..804bf5c 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -495,7 +495,7 @@ static int xen_cpu_up(unsigned int cpu, struct task_struct 
*idle)
rc = HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL);
BUG_ON(rc);
 
-   while (cpu_report_state(cpu) != CPU_ONLINE)
+   while (!cpu_check_online(cpu))
HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
 
return 0;
@@ -767,7 +767,7 @@ static int xen_hvm_cpu_up(unsigned int cpu, struct 
task_struct *tidle)
 * This can happen if CPU was offlined earlier and
 * offlining timed out in common_cpu_die().
 */
-   if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+   if (cpu_check_timeout(cpu)) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
}
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 23c30bd..f78ab46 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -284,7 +284,8 @@ void arch_cpu_idle_dead(void);
 
 DECLARE_PER_CPU(bool, cpu_dead_idle);
 
-int cpu_report_state(int cpu);
+int cpu_check_online(int cpu);
+int cpu_check_timeout(int cpu);
 int cpu_check_up_prepare(int cpu);
 void cpu_set_state_online(int cpu);
 #ifdef CONFIG_HOTPLUG_CPU
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index a818cbc..75e5724 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -371,19 +371,63 @@ int smpboot_update_cpumask_percpu_thread(struct 
smp_hotplug_thread *plug_thread,
 }
 EXPORT_SYMBOL_GPL(smpboot_update_cpumask_percpu_thread);
 
+/* The CPU is offline, and its last offline operation was
+ * successful and proceeded normally.  (Or, alternatively, the
+ * CPU never has come online, as this is the initial state.)
+ */
+#define CPUHP_POST_DEAD0x01
+
+/* The CPU is in the process of coming online.
+ * Simple architectures can skip this state, and just invoke
+ * cpu_set_state_online() unconditionally instead.
+ */
+#define CPUHP_UP_PREPARE   0x02
+
+/* The CPU is now online.  Simple architectures can skip this
+ * state, and just invoke cpu_wait_death() and cpu_report_death()
+ * unconditionally instead.
+ */
+#define CPUHP_ONLINE   0x03
+
+/* The CPU has gone offline, so that it may now be safely
+ * powered off (or whatever the architecture needs to do to it).
+ */
+#define CPUHP_DEAD 0x04
+
+/* The CPU did not go offline in a timely fashion, if at all,
+ * so it might need special processing at the next online (for
+ * example, simply refusing to bring it online).
+ */
+#define CPUHP_BROKEN   0x05
+
+/* The CPU eventually did go offline, but not in a timely
+ * fashion.  If some sort of reset operation is required before it
+ * can be brought online, that reset operation needs to be carried
+ * out at online time.  (Or, again, the architecture might simply
+ * refuse to bring it online.)
+ */
+#define CPUHP_TIMEOUT  0x06
+
 static DEFINE_PER_CPU(atomic_t, cpu_hotplug_state) = 
ATOMIC_INIT(CPU_POST_DEAD);
 
 /*
  * Called to poll specified CPU's state, for example, when waiting for
  * a CPU to come online.
  */
-int cpu_report_state(int cpu)
+int cpu_check_online(int cpu)
+{
+   return atomic_read(_cpu(cpu_hotplug_state, cpu)) ==
+  CPUHP_ONLINE;
+}
+
+int cpu_check_timeout(int cpu)
 {
-   return atomic_read(_cpu(cpu_hotplug_state, cpu));
+   return atomic_read(_cpu(cpu_hotplug_state, cpu)) ==
+  CPUHP_TIMEOUT;
 }
 
 /*
- * If CPU has died properly, set its state to CPU_UP_PREPARE and
+ * If CPU has died properly, set its state to CPUHP_UP_PREPARE and
  * return success.  Otherwise, return -EBUSY if the CPU died after
  * cpu_wait_death() timed out.  And yet otherwise again, return -EAGAIN
  * if cpu_wait_death() timed out and the CPU still hasn't gotten around
@@ -397,19 +441,19 @@ int 

[PATCH v2] cpufreq, intel_pstate, Fix intel_pstate powersave min_perf_pct value

2015-10-15 Thread Prarit Bhargava
Rafael, as requested ...

[v2]: rebased on
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge

^^^ prolly doesn't need to be in the commit log

P.

---8<---

On systems that initialize the intel_pstate driver with the performance
governor, and then switch to the powersave governor will not transition to
lower cpu frequencies until /sys/devices/system/cpu/intel_pstate/min_perf_pct
is set to a low value.

The behavior of governor switching changed after commit a04759924e25
("[cpufreq] intel_pstate: honor user space min_perf_pct override on
 resume").  The commit introduced tracking of performance percentage
changes via sysfs in order to restore userspace changes during
suspend/resume.  The problem occurs because the global values of the newly
introduced max_sysfs_pct and min_sysfs_pct are not lowered on the governor
change and this causes the powersave governor to inherit the performance
governor's settings.

A simple change would have been to reset max_sysfs_pct to 100 and
min_sysfs_pct to 0 on a governor change, which fixes the problem with
governor switching.  However, since we cannot break userspace[1] the fix
is now to give each governor its own limits storage area so that governor
specific changes are tracked.

I successfully tested this by booting with both the performance governor
and the powersave governor by default, and switching between the two
governors (while monitoring /sys/devices/system/cpu/intel_pstate/ values,
and looking at the output of cpupower frequency-info).  Suspend/Resume
testing was performed by Doug Smythies.

[1] Systems which suspend/resume using the unmaintained pm-utils package
will always transition to the performance governor before the suspend and
after the resume.  This means a system using the powersave governor will
go from powersave to performance, then suspend/resume, performance to
powersave.  The simple change during governor changes would have been
overwritten when the governor changed before and after the suspend/resume.
I have submitted https://bugzilla.redhat.com/show_bug.cgi?id=1271225
against Fedora to remove the 94cpufreq file that causes the problem.  It
should be noted that pm-utils is obsoleted with newer versions of systemd.

Cc: Kristen Carlson Accardi 
Cc: "Rafael J. Wysocki" 
Cc: Viresh Kumar 
Cc: linux...@vger.kernel.org
Cc: Doug Smythies 
Signed-off-by: Prarit Bhargava 
---
 drivers/cpufreq/intel_pstate.c | 142 -
 1 file changed, 85 insertions(+), 57 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index c568226..cde38c8 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -167,7 +167,20 @@ struct perf_limits {
int min_perf_ctl;
 };
 
-static struct perf_limits limits = {
+static struct perf_limits performance_limits = {
+   .no_turbo = 0,
+   .turbo_disabled = 0,
+   .max_perf_pct = 100,
+   .max_perf = int_tofp(1),
+   .min_perf_pct = 100,
+   .min_perf = int_tofp(1),
+   .max_policy_pct = 100,
+   .max_sysfs_pct = 100,
+   .min_policy_pct = 0,
+   .min_sysfs_pct = 0,
+};
+
+static struct perf_limits powersave_limits = {
.no_turbo = 0,
.turbo_disabled = 0,
.max_perf_pct = 100,
@@ -182,6 +195,12 @@ static struct perf_limits limits = {
.min_perf_ctl = 0,
 };
 
+#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE
+static struct perf_limits *limits = _limits;
+#else
+static struct perf_limits *limits = _limits;
+#endif
+
 #if IS_ENABLED(CONFIG_ACPI)
 /*
  * The max target pstate ratio is a 8 bit value in both PLATFORM_INFO MSR and
@@ -256,7 +275,7 @@ static int intel_pstate_init_perf_limits(struct 
cpufreq_policy *policy)
if (turbo_pss_ctl <= cpu->pstate.max_pstate &&
turbo_pss_ctl > cpu->pstate.min_pstate) {
pr_debug("intel_pstate: no turbo range exists in _PSS\n");
-   limits.no_turbo = limits.turbo_disabled = 1;
+   limits->no_turbo = limits->turbo_disabled = 1;
cpu->pstate.turbo_pstate = cpu->pstate.max_pstate;
turbo_absent = true;
}
@@ -415,7 +434,7 @@ static inline void update_turbo_state(void)
 
cpu = all_cpu_data[0];
rdmsrl(MSR_IA32_MISC_ENABLE, misc_en);
-   limits.turbo_disabled =
+   limits->turbo_disabled =
(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE ||
 cpu->pstate.max_pstate == cpu->pstate.turbo_pstate);
 }
@@ -434,14 +453,14 @@ static void intel_pstate_hwp_set(void)
 
for_each_online_cpu(cpu) {
rdmsrl_on_cpu(cpu, MSR_HWP_REQUEST, );
-   adj_range = limits.min_perf_pct * range / 100;
+   adj_range = limits->min_perf_pct * range / 100;
min = hw_min + adj_range;
value &= 

Re: [PATCH] pci: restrict 64-bit pci device to assign resource from behind of max_pfn

2015-10-15 Thread kbuild test robot
Hi Wenlin,

[auto build test ERROR on pci/next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Wenlin-Kang/pci-restrict-64-bit-pci-device-to-assign-resource-from-behind-of-max_pfn/20151015-184913
config: mips-fuloong2e_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   drivers/pci/setup-res.c: In function '__pci_assign_resource':
>> drivers/pci/setup-res.c:224:6: error: 'max_pfn' undeclared (first use in 
>> this function)
(max_pfn + 1) << PAGE_SHIFT : PCIBIOS_MIN_MEM;
 ^
   drivers/pci/setup-res.c:224:6: note: each undeclared identifier is reported 
only once for each function it appears in

vim +/max_pfn +224 drivers/pci/setup-res.c

   218   * For 64-bit pci device, assign resource start from the next 
page
   219   * boundary above the maximum physical page address
   220   */
   221  resource_size_t min_iomem;
   222  
   223  min_iomem = (res->flags & IORESOURCE_MEM_64) ?
 > 224  (max_pfn + 1) << PAGE_SHIFT : 
 > PCIBIOS_MIN_MEM;
   225  min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : min_iomem;
   226  #else
   227  min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : 
PCIBIOS_MIN_MEM;

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


.config.gz
Description: Binary data


Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

2015-10-15 Thread Kosuke Tatsukawa
Tatsukawa Kosuke wrote:
> J. Bruce Fields wrote:
>> On Wed, Oct 14, 2015 at 03:57:13AM +, Kosuke Tatsukawa wrote:
>>> J. Bruce Fields wrote:
>>> > On Mon, Oct 12, 2015 at 10:41:06AM +, Kosuke Tatsukawa wrote:
>>> >> J. Bruce Fields wrote:
>>> >> > On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote:
>>> >> >> Neil Brown wrote:
>>> >> >> > Kosuke Tatsukawa  writes:
>>> >> >> > 
>>> >> >> >> There are several places in net/sunrpc/svcsock.c which calls
>>> >> >> >> waitqueue_active() without calling a memory barrier.  Add a memory
>>> >> >> >> barrier just as in wq_has_sleeper().
>>> >> >> >>
>>> >> >> >> I found this issue when I was looking through the linux source code
>>> >> >> >> for places calling waitqueue_active() before wake_up*(), but 
>>> >> >> >> without
>>> >> >> >> preceding memory barriers, after sending a patch to fix a similar
>>> >> >> >> issue in drivers/tty/n_tty.c  (Details about the original issue 
>>> >> >> >> can be
>>> >> >> >> found here: https://lkml.org/lkml/2015/9/28/849).
>>> >> >> > 
>>> >> >> > hi,
>>> >> >> > this feels like the wrong approach to the problem.  It requires 
>>> >> >> > extra
>>> >> >> > 'smb_mb's to be spread around which are hard to understand as easy 
>>> >> >> > to
>>> >> >> > forget.
>>> >> >> > 
>>> >> >> > A quick look seems to suggest that (nearly) every waitqueue_active()
>>> >> >> > will need an smb_mb.  Could we just put the smb_mb() inside
>>> >> >> > waitqueue_active()??
>>> >> >> 
>>> >> >> 
>>> >> >> There are around 200 occurrences of waitqueue_active() in the kernel
>>> >> >> source, and most of the places which use it before wake_up are either
>>> >> >> protected by some spin lock, or already has a memory barrier or some
>>> >> >> kind of atomic operation before it.
>>> >> >> 
>>> >> >> Simply adding smp_mb() to waitqueue_active() would incur extra cost in
>>> >> >> many cases and won't be a good idea.
>>> >> >> 
>>> >> >> Another way to solve this problem is to remove the waitqueue_active(),
>>> >> >> making the code look like this;
>>> >> >>   if (wq)
>>> >> >>   wake_up_interruptible(wq);
>>> >> >> This also fixes the problem because the spinlock in the wake_up*() 
>>> >> >> acts
>>> >> >> as a memory barrier and prevents the code from being reordered by the
>>> >> >> CPU (and it also makes the resulting code is much simpler).
>>> >> > 
>>> >> > I might not care which we did, except I don't have the means to test
>>> >> > this quickly, and I guess this is some of our most frequently called
>>> >> > code.
>>> >> > 
>>> >> > I suppose your patch is the most conservative approach, as the
>>> >> > alternative is a spinlock/unlock in wake_up_interruptible, which I
>>> >> > assume is necessarily more expensive than an smp_mb().
>>> >> > 
>>> >> > As far as I can tell it's been this way since forever.  (Well, since a
>>> >> > 2002 patch "NFSD: TCP: rationalise locking in RPC server routines" 
>>> >> > which
>>> >> > removed some spinlocks from the data_ready routines.)
>>> >> > 
>>> >> > I don't understand what the actual race is yet (which code exactly is
>>> >> > missing the wakeup in this case?  nfsd threads seem to instead get
>>> >> > woken up by the wake_up_process() in svc_xprt_do_enqueue().)
>>> >> 
>>> >> Thank you for the reply.  I tried looking into this.
>>> >> 
>>> >> The callbacks in net/sunrpc/svcsock.c are set up in svc_tcp_init() and
>>> >> svc_udp_init(), which are both called from svc_setup_socket().
>>> >> svc_setup_socket() is called (indirectly) from lockd, nfsd, and nfsv4
>>> >> callback port related code.
>>> >> 
>>> >> Maybe I'm wrong, but there might not be any kernel code that is using
>>> >> the socket's wait queue in this case.
>>> > 
>>> > As Trond points out there are probably waiters internal to the
>>> > networking code.
>>> 
>>> Trond and Bruce, thank you for the comment.  I was able to find the call
>>> to the wait function that was called from nfsd.
>>> 
>>> sk_stream_wait_connect() and sk_stream_wait_memory() were called from
>>> either do_tcp_sendpages() or tcp_sendmsg() called from within
>>> svc_send().  sk_stream_wait_connect() shouldn't be called at this point,
>>> because the socket has already been used to receive the rpc request.
>>> 
>>> On the wake_up side, sk_write_space() is called from the following
>>> locations.  The relevant ones seems to be preceded by atomic_sub or a
>>> memory barrier.
>>> + ksocknal_write_space 
>>> [drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c:633]
>>> + atm_pop_raw [net/atm/raw.c:40]
>>> + sock_setsockopt [net/core/sock.c:740]
>>> + sock_wfree [net/core/sock.c:1630]
>>>   Preceded by atomic_sub in sock_wfree()
>>> + ccid3_hc_tx_packet_recv [net/dccp/ccids/ccid3.c:442]
>>> + do_tcp_sendpages [net/ipv4/tcp.c:1008]
>>> + tcp_sendmsg [net/ipv4/tcp.c:1300]
>>> + do_tcp_setsockopt [net/ipv4/tcp.c:2597]
>>> + tcp_new_space [net/ipv4/tcp_input.c:4885]
>>>   Preceded by smp_mb__after_atomic in tcp_check_space()

Re: [PATCH v3 1/4] mtd: nand: allow compile test of MTD_NAND_PXA3xx

2015-10-15 Thread Arnd Bergmann
On Thursday 15 October 2015 17:12:18 kbuild test robot wrote:
>drivers/mtd/nand/pxa3xx_nand.c: In function 'drain_fifo':
> >> drivers/mtd/nand/pxa3xx_nand.c:507:4: error: implicit declaration of 
> >> function 'readsl' [-Werror=implicit-function-declaration]
>readsl(info->mmio_base + NDDB, data, 8);
>^

It should be easy to fix this by changing the code to use ioread32_rep() instead
of readsl(). They behave the same way on pointers returned from ioremap() etc,
and the other one is available on all architectures.

Arnd
--
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 10/31] perf test: Enforce LLVM test for BPF test

2015-10-15 Thread Wangnan (F)



On 2015/10/14 23:48, Namhyung Kim wrote:

On Wed, Oct 14, 2015 at 12:41:21PM +, Wang Nan wrote:

This patch replaces the original toy BPF program with previous introduced
bpf-script-example.c. Dynamically embedded it into 'llvm-src.c'.

The newly introduced BPF program attaches a BPF program at
'sys_epoll_pwait()', and collect half samples from it. perf itself never
use that syscall, so further test can verify their result with it.

Since BPF program require LINUX_VERSION_CODE of runtime kernel, this
patch computes that code from uname.

Since the resuling BPF object is useful for further testcases, this patch
introduces 'prepare' and 'cleanup' method to tests, and makes test__llvm()
create a MAP_SHARED memory array to hold the resulting object.

Signed-off-by: He Kuang 
Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexei Starovoitov 
Cc: Brendan Gregg 
Cc: Daniel Borkmann 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Kaixu Xia 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/n/ebpf-6yw9eg0ej3l4jnqhinngk...@git.kernel.org
---

[SNIP]


+void test__llvm_prepare(void)
+{
+   p_test_llvm__bpf_result = mmap(NULL, SHARED_BUF_INIT_SIZE,
+  PROT_READ | PROT_WRITE,
+  MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+   if (!p_test_llvm__bpf_result)

It should check MAP_FAILED instead.



Fixed by this way:

diff --git a/tools/perf/tests/llvm.c b/tools/perf/tests/llvm.c
index e722e8a..25ddeaf 100644
--- a/tools/perf/tests/llvm.c
+++ b/tools/perf/tests/llvm.c
@@ -199,12 +199,15 @@ void test__llvm_prepare(void)

for (i = 0; llvm_testcases[i].source; i++) {
struct test_llvm__bpf_result *result;
+   void *p;

-   result = mmap(NULL, SHARED_BUF_INIT_SIZE,
- PROT_READ | PROT_WRITE,
- MAP_SHARED | MAP_ANONYMOUS, -1, 0);
-   if (!result)
+   p = mmap(NULL, SHARED_BUF_INIT_SIZE,
+PROT_READ | PROT_WRITE,
+MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+   if (p == MAP_FAILED)
return;
+
+   result = p;
memset((void *)result, '\0', SHARED_BUF_INIT_SIZE);

llvm_testcases[i].result = result;

Thank you.

--
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] ARM: configs: Add Freescale LS1021A defconfig

2015-10-15 Thread Arnd Bergmann
On Thursday 15 October 2015 02:11:57 Huan Wang wrote:
> > On Wednesday 14 October 2015 10:18:47 Huan Wang wrote:
> > > > On Thursday 24 September 2015 07:27:10 Huan Wang wrote:
> > > > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang 
> > > > > >  wrote:
> > > > > Any suggestion? Thanks.
> > > >
> > > > Try enabling DEBUG_LL for your platform to get some debug output, if
> > > > you still don't get any helpful messages, try also inserting
> > > >
> > > >   printascii(__func__);
> > > >
> > > > statements in the early boot process to see how far you get before the 
> > > > hang.
> > > >
> > 
> [Alison Wang] ls1021a uses duart as the default serial port, not lpuart. So
> 8250/16550 serial driver is used. Let me explain my debug process in detail.

Ah, I see.

> When CONFIG_VMSPLIT_2G is used, I could boot up the whole kernel and get the
> print message " Booting Linux on physical CPU 0xf00" after "Starting kernel"
> as below.
> 
> Starting kernel ...
> [0.00] Booting Linux on physical CPU 0xf00
> .
> 
> But when CONFIG_VMSPLIT_3G is used, I couldn't get print message " Booting 
> Linux
> on physical CPU 0xf00". It only hangs at  "Starting kernel ...".
> 
> Moreover, I add some asm code in __turn_mmu_on to print some simple 
> characters, and
> I could get the print characters when CONFIG_VMSPLIT_3G is used. So I guess 
> there
> is something wrong with the page tables.

Ok. What I was suggesting above though was to try to pinpoint exactly
where it goes wrong. You have verified that it does not crash before
the page tables are enabled, but that is very early. You have also shown
that the kernel crashes before the point at which the 'Booting Linux on
physical CPU 0xf00' message is printed to the kernel, but that is *much*
later: setup_arch() calls parse_early_param(), which in turn sets up
early_console_write(). This means the 'Booting Linux on physical CPU 0xf00'
is still stuck in the log buffer and you may have crashed someone
inbetween.

If you can call printascii(), you can try to do that just after enabling
the page tables to see if that was the problem like you suspect, or otherwise
add more printascii() statements between __turn_mmu_on and parse_early_param()
to pinpoint the exact code that breaks.

Arnd
--
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 v3 3/4] ARM: dts: Add STM32 DMA support for STM32F429 MCU

2015-10-15 Thread M'boumba Cedric Madianga
This patch adds STM32 DMA bindings for STM32F429.

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/boot/dts/stm32f429.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index d78a481..037eb29 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -174,6 +174,37 @@
reg = <0x40023800 0x400>;
clocks = <_hse>;
};
+
+   dma1: dma-controller@40026000 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026000 0x400>;
+   interrupts = <11>,
+<12>,
+<13>,
+<14>,
+<15>,
+<16>,
+<17>,
+<47>;
+   clocks = < 0 21>;
+   #dma-cells = <4>;
+   };
+
+   dma2: dma-controller@40026400 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026400 0x400>;
+   interrupts = <56>,
+<57>,
+<58>,
+<59>,
+<60>,
+<68>,
+<69>,
+<70>;
+   clocks = < 0 22>;
+   #dma-cells = <4>;
+   st,mem2mem;
+   };
};
 };
 
-- 
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: [PATCHv3] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ

2015-10-15 Thread Szabolcs Nagy
* Will Deacon  [2015-10-09 11:33:52 +0100]:

> On Fri, Oct 09, 2015 at 03:59:40PM +0530, Manjeet Pawar wrote:
> > MINSIGSTKSZ and SIGSTKSZ for ARM64 are not correctly set in latest kernel.
> > This patch fixes this issue.
> > 
> > This issue is reported in LTP (testcase: sigaltstack02.c).
> > Testcase failed when sigaltstack() called with stack size "MINSIGSTKSZ - 1"
> > Since in Glibc-2.22, MINSIGSTKSZ is set to 5120 but in kernel
> > it is set to 2048 so testcase gets failed.
> > 
> > Testcase Output:
> > sigaltstack02 1  TPASS  :  stgaltstack() fails, Invalid Flag value,errno:22
> > sigaltstack02 2  TFAIL  :  sigaltstack() returned 0, expected -1,errno:12
> 
> I'm still unable to reproduce this failure. Is this with defconfig?
> 
> > Reported Issue in Glibc Bugzilla:
> > Bugfix in Glibc-2.22: [Bug 16850]
> > https://sourceware.org/bugzilla/show_bug.cgi?id=16850
> > 
> > Signed-off-by: Akhilesh Kumar 
> > Signed-off-by: Manjeet Pawar 
> > Signed-off-by: Rohit Thapliyal 
> > ---
> > v1 -> Changes in uapi overall header
> > v2 -> Changes done in arm64 headers
> > v3 -> Changes done in both uapi & arm64 headers
> > 
> >  arch/arm64/include/uapi/asm/signal.h |3 +++
> >  include/uapi/asm-generic/signal.h|2 ++
> >  2 files changed, 5 insertions(+)
> 
> Acked-by: Will Deacon 
> 
> Arnd: are you planning to take this via asm-generic, or shall I queue it
> on the arm64 fixes branch?
> 

i just noticed this and wanted to note that an old
glibc can fail on a new kernel with this patch if
an application uses MINSIGSTKSZ altstack.

(the specific LTP bug could have been fixed on the libc
side, checking against whatever the libc MINSIGSTKSZ is
as long as it is larger than the kernel value, which
makes sense as userspace may have additional overhead
the kernel is not aware of so please don't try to keep
this in sync with glibc.. hopefully there will not be
another change though).

> Will
> 
> > diff --git a/arch/arm64/include/uapi/asm/signal.h 
> > b/arch/arm64/include/uapi/asm/signal.h
> > index 8d1e723..991bf5d 100644
> > --- a/arch/arm64/include/uapi/asm/signal.h
> > +++ b/arch/arm64/include/uapi/asm/signal.h
> > @@ -19,6 +19,9 @@
> >  /* Required for AArch32 compatibility. */
> >  #define SA_RESTORER0x0400
> >  
> > +#define MINSIGSTKSZ 5120
> > +#define SIGSTKSZ16384
> > +
> >  #include 
> >  
> >  #endif
> > diff --git a/include/uapi/asm-generic/signal.h 
> > b/include/uapi/asm-generic/signal.h
> > index 9df61f1..b98b67b 100644
> > --- a/include/uapi/asm-generic/signal.h
> > +++ b/include/uapi/asm-generic/signal.h
> > @@ -80,8 +80,10 @@
> >   * SA_RESTORER 0x0400
> >   */
> >  
> > +#if !defined MINSIGSTKSZ || !defined SIGSTKSZ
> >  #define MINSIGSTKSZ2048
> >  #define SIGSTKSZ   8192
> > +#endif
> >  
> >  #ifndef __ASSEMBLY__
> >  typedef struct {
> > -- 
> > 1.7.9.5
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.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: [RFT PATCH 3/3] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common

2015-10-15 Thread Tomeu Vizoso
On 15 October 2015 at 12:55, Javier Martinez Canillas
 wrote:
> The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
> can't neither be removed nor be detected. But the node isn't marked
> as non-removable and instead has the broken-cd DT property.
>
> This causes the device to be removed when the system enters into a
> suspend state and the following warnings is shown after a resume:
>
> [  181.944636] mmc2: error -2 during resume (card was removed?)

Hi Javier,

isn't wifi on snow on mmc_3?

With your patch, I don't see any change, but if I do it on mmc_3
instead, the machine fails to resume. Will try to get more info.

Regards,

Tomeu

> Signed-off-by: Javier Martinez Canillas 
>
> ---
>
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
> b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> index 0a7f408824d8..bf27957fd660 100644
> --- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> @@ -520,7 +520,7 @@
>  _0 {
> status = "okay";
> num-slots = <1>;
> -   broken-cd;
> +   non-removable;
> card-detect-delay = <200>;
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <2 3>;
> --
> 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/
--
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] staging: vt6655: Remove boolean comparisons

2015-10-15 Thread Luis de Bethencourt
Boolean tests do not need explicit comparison to true or false.

Signed-off-by: Luis de Bethencourt 
---
 drivers/staging/vt6655/card.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
index f842be6..5159270 100644
--- a/drivers/staging/vt6655/card.c
+++ b/drivers/staging/vt6655/card.c
@@ -472,14 +472,14 @@ bool CARDbRadioPowerOn(struct vnt_private *pDevice)
bool bResult = true;
 
pr_debug("chester power on\n");
-   if (pDevice->bRadioControlOff == true) {
-   if (pDevice->bHWRadioOff == true)
+   if (pDevice->bRadioControlOff) {
+   if (pDevice->bHWRadioOff)
pr_debug("chester bHWRadioOff\n");
-   if (pDevice->bRadioControlOff == true)
+   if (pDevice->bRadioControlOff)
pr_debug("chester bRadioControlOff\n");
return false; }
 
-   if (pDevice->bRadioOff == false) {
+   if (!pDevice->bRadioOff) {
pr_debug("chester pbRadioOff\n");
return true; }
 
-- 
2.5.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 v2 0/4] timer: Improve itimers scalability

2015-10-15 Thread Frederic Weisbecker
On Wed, Oct 14, 2015 at 05:18:27PM -0400, George Spelvin wrote:
> I'm going to give 4/4 a closer look to see if the races with timer
> expiration make more sense to me than last time around.
> (E.g. do CPU time signals even work in CONFIG_NO_HZ_FULL?)

Those enqueued with timer_settime() do work. But itimers,
and rlimits (RLIMIT_RTTIME, RLIMIT_CPU) aren't supported well. I
need to rework that.

> 
> But although I haven't yet convinced myself the current code is right,
> the changes don't seem to make it any worse.  So consider all four
> 
> Reviewed-by: George Spelvin 
> 
> Thank you!
--
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: [PATCHv3] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ

2015-10-15 Thread Arnd Bergmann
On Thursday 15 October 2015 14:12:41 Szabolcs Nagy wrote:
> * Will Deacon  [2015-10-09 11:33:52 +0100]:
> 
> > On Fri, Oct 09, 2015 at 03:59:40PM +0530, Manjeet Pawar wrote:
> > > MINSIGSTKSZ and SIGSTKSZ for ARM64 are not correctly set in latest kernel.
> > > This patch fixes this issue.
> > > 
> > > This issue is reported in LTP (testcase: sigaltstack02.c).
> > > Testcase failed when sigaltstack() called with stack size "MINSIGSTKSZ - 
> > > 1"
> > > Since in Glibc-2.22, MINSIGSTKSZ is set to 5120 but in kernel
> > > it is set to 2048 so testcase gets failed.
> > > 
> > > Testcase Output:
> > > sigaltstack02 1  TPASS  :  stgaltstack() fails, Invalid Flag 
> > > value,errno:22
> > > sigaltstack02 2  TFAIL  :  sigaltstack() returned 0, expected -1,errno:12
> > 
> > I'm still unable to reproduce this failure. Is this with defconfig?
> > 
> > > Reported Issue in Glibc Bugzilla:
> > > Bugfix in Glibc-2.22: [Bug 16850]
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=16850
> > > 
> > > Signed-off-by: Akhilesh Kumar 
> > > Signed-off-by: Manjeet Pawar 
> > > Signed-off-by: Rohit Thapliyal 
> > > ---
> > > v1 -> Changes in uapi overall header
> > > v2 -> Changes done in arm64 headers
> > > v3 -> Changes done in both uapi & arm64 headers
> > > 
> > >  arch/arm64/include/uapi/asm/signal.h |3 +++
> > >  include/uapi/asm-generic/signal.h|2 ++
> > >  2 files changed, 5 insertions(+)
> > 
> > Acked-by: Will Deacon 
> > 
> > Arnd: are you planning to take this via asm-generic, or shall I queue it
> > on the arm64 fixes branch?
> > 
> 
> i just noticed this and wanted to note that an old
> glibc can fail on a new kernel with this patch if
> an application uses MINSIGSTKSZ altstack.

Well worth noting, but I think we should consider this intentional:

If an application built against an old glibc uses MINSIGSTKSZ, it
current gets random data corruption of a segmentation fault that
are both hard to track down, while a new kernel would result in
more sensible error code that is easier to debug.

Arnd
--
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: [PATCHv3 03/11] arm64: Introduce helpers for page table levels

2015-10-15 Thread Mark Rutland
On Thu, Oct 15, 2015 at 01:37:35PM +0200, Christoffer Dall wrote:
> On Wed, Oct 14, 2015 at 12:20:26PM +0100, Suzuki K. Poulose wrote:
> > Introduce helpers for finding the number of page table
> > levels required for a given VA width, shift for a particular
> > page table level.
> > 
> > Convert the existing users to the new helpers. More users
> > to follow.
> > 
> > Cc: Ard Biesheuvel 
> > Cc: Mark Rutland 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Marc Zyngier 
> > Signed-off-by: Suzuki K. Poulose 
> > 
> > ---
> > Changes since V2:
> >   - Add comments around the macros
> >   - Change ARM64_HW_PGTABLE_LEVEL_SHIFT to accept pagetable level as
> > described by ARM ARM
> > ---
> >  arch/arm64/include/asm/pgtable-hwdef.h |   25 ++---
> >  1 file changed, 22 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
> > b/arch/arm64/include/asm/pgtable-hwdef.h
> > index 95c1ec0..c6194ab 100644
> > --- a/arch/arm64/include/asm/pgtable-hwdef.h
> > +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> > @@ -16,13 +16,31 @@
> >  #ifndef __ASM_PGTABLE_HWDEF_H
> >  #define __ASM_PGTABLE_HWDEF_H
> >  
> > +/*
> > + * Number of page-table levels required to address 'va_bits' wide
> > + * address, without section mapping. We resolve the top (va_bits - 
> > PAGE_SHIFT)
> > + * bits with (PAGE_SHIFT - 3) bits at each page table level. Hence:
> > + *
> > + *  levels = DIV_ROUND_UP((va_bits - PAGE_SHIFT), (PAGE_SHIFT - 3))
> > + *
> > + * We cannot include linux/kernel.h which defines DIV_ROUND_UP here
> > + * due to build issues. So we use the following magic formula.
> > + */
> > +#define ARM64_HW_PGTABLE_LEVELS(va_bits) (((va_bits) - 4) / (PAGE_SHIFT - 
> > 3))
> > +
> > +/*
> > + * Size mapped by an entry at level n
> > + * We map PAGE_SHIFT - 3 at all levels, except the PAGE_SHIFT bits at the 
> > last level
> > + */
> > +#define ARM64_HW_PGTABLE_LEVEL_SHIFT(n)((PAGE_SHIFT - 3) * (4 - (n)) + 
> > 3)
> 
> I feel like I'm partially failing the interview question again, in that
> I don't fully understand the '+ 3' in the end?

The last level handles PAGE_SHIFT bits (the bits from the VA that are
the same in the PA). We only accounted for (PAGE_SHIFT - 3) bits at each
level when multiplying, so we add those 3 missing bits back at the end.

Thanks,
Mark.
--
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: [PATCHv3 08/11] arm64: Check for selected granule support

2015-10-15 Thread Suzuki K. Poulose

On 15/10/15 13:37, Mark Rutland wrote:

On Thu, Oct 15, 2015 at 12:25:33PM +0100, Suzuki K. Poulose wrote:

On Thu, Oct 15, 2015 at 11:45:15AM +0100, Mark Rutland wrote:

On Wed, Oct 14, 2015 at 04:13:47PM -0500, Jeremy Linton wrote:

On 10/14/2015 06:20 AM, Suzuki K. Poulose wrote:





8>

Author: Suzuki K. Poulose 
Date:   Wed Oct 14 11:25:16 2015 +0100

 arm64: Check for selected granule support

 Ensure that the selected page size is supported by the CPU(s). If it isn't
 park the CPU. A check is added to the EFI stub to detect if the boot CPU
 supports the page size, failing which, we fail the boot gracefully, with
 an error message.

 Signed-off-by: Suzuki K. Poulose 
 [ Added a check to EFI stub ]
 Signed-off-by: Jeremy Linton 


Your sign-off should be last, given you are taking resposibility for
Jeremy's patch.


OK, I was a bit confused about how it should look like. I kept it on top
so that I could add [ ] for Jeremy's contribution.



However, I would prefer that the EFI stub addition were a separate/later
patch.


OK, that makes sense.




diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index a7f3d4b..72d814c 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h



+#define ID_AA64MMFR0_TGRAN4_NI 0xf
+#define ID_AA64MMFR0_TGRAN4_ON 0x0
+#define ID_AA64MMFR0_TGRAN64_NI0xf
+#define ID_AA64MMFR0_TGRAN64_ON0x0
+#define ID_AA64MMFR0_TGRAN16_NI0x0
+#define ID_AA64MMFR0_TGRAN16_ON0x1


I still don't like "ON" here -- I thought these would also be changed
s/ON/SUPPORTED/.


I know and I expected that. I have "_ON" in my 'CPU feature' series, which
will/can be reused here. Hence kept it _ON. I can change it everywhere to
_SUPPORTED, since I may need to spin another version for that.



  #include 
  #include 
+#include 
  #include 


Nit: include order.


OK





+#if defined(CONFIG_ARM64_4K_PAGES)
+#define PAGE_SIZE_STR  "4K"
+#elif defined(CONFIG_ARM64_64K_PAGES)
+#define PAGE_SIZE_STR  "64K"
+#endif
+
  efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
unsigned long *image_addr,
unsigned long *image_size,
@@ -25,6 +32,17 @@ efi_status_t __init handle_kernel_image(efi_system_table_t 
*sys_table_arg,
unsigned long kernel_size, kernel_memsize = 0;
unsigned long nr_pages;
void *old_image_addr = (void *)*image_addr;
+   u64 aa64mmfr0_el1;
+
+   /*
+* Check to see if the CPU supports the requested pagesize
+*/
+   asm volatile("mrs %0, ID_AA64MMFR0_EL1" : "=r" (aa64mmfr0_el1));


Can we not use read_cpuid() or similar here?


Yes, I will try that out. I didn't want to include additional header-files
in efi-stub.c.



+   aa64mmfr0_el1 >>= ID_AA64MMFR0_TGRAN_SHIFT;


... and can we not do the shift and mask in one go?




+   if ((aa64mmfr0_el1 & 0xf) != ID_AA64MMFR0_TGRAN_SUPPORTED) {
+   pr_efi_err(sys_table_arg, PAGE_SIZE_STR" granule not supported by 
the CPU\n");


Nit: space before the first quote, please.


Will do

Thanks
Suzuki

--
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 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

2015-10-15 Thread David Vrabel
On 15/10/15 06:56, Mikko Rapeli wrote:
> xen/interface/xen.h is not exported from kernel headers so remove the
> dependency and provide needed defines for domid_t and xen_pfn_t if they
> are not already defined by some other e.g. Xen specific headers.
> 
> Suggested by Andrew Cooper  on lkml message
> <5569f9c9.8000...@citrix.com>.
> 
> The ifdef for ARM is ugly but did not find better solutions for it.
> 
> Fixes userspace compilation error:
> 
> xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or 
> directory
[...]
> --- a/include/uapi/xen/privcmd.h
> +++ b/include/uapi/xen/privcmd.h
> @@ -35,7 +35,19 @@
>  
>  #include 
>  #include 
> -#include 
> +
> +/* Might be defined by Xen specific headers, but if not */
> +#ifndef domid_t
> +typedef __u16 domid_t;
> +#endif /* domid_t */

As the kbuild bot points out, this does not work since the existence of
a typedef cannot be checked with #ifdef.

I'm not really sure what problem you're trying to solve.  A user space
program making use of this interface gets the domid_t and xen_pfn_t etc
typedefs from the headers provided as part of the libxenctrl library.

David
--
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 4/5] KVM: x86: MMU: Remove mapping_level_dirty_bitmap()

2015-10-15 Thread Takuya Yoshikawa
Now that it has only one caller, and its name is not so helpful for
readers, just remove it.

Signed-off-by: Takuya Yoshikawa 
---
 arch/x86/kvm/mmu.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 890cd69..78a3d08 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -851,6 +851,14 @@ static int host_mapping_level(struct kvm *kvm, gfn_t gfn)
return ret;
 }
 
+static inline bool memslot_invalid(struct kvm_memory_slot *slot)
+{
+   if (!slot || slot->flags & KVM_MEMSLOT_INVALID)
+   return true;
+
+   return false;
+}
+
 static struct kvm_memory_slot *
 gfn_to_memslot_dirty_bitmap(struct kvm_vcpu *vcpu, gfn_t gfn,
bool no_dirty_log)
@@ -858,25 +866,22 @@ gfn_to_memslot_dirty_bitmap(struct kvm_vcpu *vcpu, gfn_t 
gfn,
struct kvm_memory_slot *slot;
 
slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
-   if (!slot || slot->flags & KVM_MEMSLOT_INVALID ||
- (no_dirty_log && slot->dirty_bitmap))
+   if (memslot_invalid(slot) || (no_dirty_log && slot->dirty_bitmap))
slot = NULL;
 
return slot;
 }
 
-static bool mapping_level_dirty_bitmap(struct kvm_vcpu *vcpu, gfn_t large_gfn)
-{
-   return !gfn_to_memslot_dirty_bitmap(vcpu, large_gfn, true);
-}
-
 static int mapping_level(struct kvm_vcpu *vcpu, gfn_t large_gfn,
 bool *force_pt_level)
 {
int host_level, level, max_level;
+   struct kvm_memory_slot *slot;
+
+   slot = kvm_vcpu_gfn_to_memslot(vcpu, large_gfn);
 
if (likely(!*force_pt_level))
-   *force_pt_level = mapping_level_dirty_bitmap(vcpu, large_gfn);
+   *force_pt_level = memslot_invalid(slot) || slot->dirty_bitmap;
if (unlikely(*force_pt_level))
return PT_PAGE_TABLE_LEVEL;
 
-- 
1.7.9.5

--
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: [PATCHv3 08/11] arm64: Check for selected granule support

2015-10-15 Thread Mark Rutland
> >>+#define id_aa64mmfr0_tgran_shift   ID_AA64MMFR0_TGRAN64_SHIFT
> >>+#define id_aa64mmfr0_tgran_on  ID_AA64MMFR0_TGRAN64_ON
> >>+
> >>+#else
> >>+
> >>+#define id_aa64mmfr0_tgran_shift   ID_AA64MMFR0_TGRAN4_SHIFT
> >>+#define id_aa64mmfr0_tgran_on  ID_AA64MMFR0_TGRAN4_ON
> >
> >Any reason for not using upper-case names for the macros?
> 
> Nothing in particular. I had them in upper-case in the previous version,
> changed it here ;) for absolutely no reason. I could switch it back.

Please do!

> >Given they're local you could just call them TGRAN_SHIFT and TRGRAN_ON
> >to make the asm slightly nicer.
> 
> Given Jeremy's suggestion to add something to the EFI stub, I will retain
> the original definition with all upper-case and define it somewhere in
> a header so that we can reuse it.

Ok, that's also fine by me.

Thanks,
Mark.
--
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] ARM: edma: fix residue race for cyclic

2015-10-15 Thread John Ogness
When retrieving the residue value for cyclic transfers, the DST
field of the active PaRAM is read. However, the AM335x Technical
Reference Manual states:

  11.3.3.6 Parameter Set Updates

  After the TR is read from the PaRAM (and is in the process of
  being submitted to the EDMA3TC), the following fields are
  updated as needed: ... DST

This means the DST is incremented even though the DMA transfer
may not have started yet or is in progress. Thus if the reader
of the residue accesses the DMA buffer too quickly, the CPU
will read where data is not yet written.

The CCSTAT.ACTV register is a boolean that is set if any TR is
being processed by either the EMDA3CC or EDMA3TC. By polling
this register it is possible to ensure that the residue value
returned is valid for immediate processing.

Signed-off-by: John Ogness 
---
 arch/arm/common/edma.c |   17 +
 drivers/dma/edma.c |8 
 include/linux/platform_data/edma.h |1 +
 3 files changed, 26 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 873dbfc..86ce980 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -995,6 +995,23 @@ void edma_set_dest(unsigned slot, dma_addr_t dest_port,
 }
 EXPORT_SYMBOL(edma_set_dest);
 
+#define EDMA_CCSTAT_ACTV (1 << 4)
+
+/**
+ * edma_is_actv - report if any transfer requests are active
+ * @slot: parameter RAM slot being examined
+ *
+ * Returns true if any transfer requests are active on the slot
+ */
+bool edma_is_actv(unsigned slot)
+{
+   u32 ctlr = EDMA_CTLR(slot);
+   unsigned int ccstat;
+
+   ccstat = edma_read(ctlr, EDMA_CCSTAT);
+   return (ccstat & EDMA_CCSTAT_ACTV);
+}
+
 /**
  * edma_get_position - returns the current transfer point
  * @slot: parameter RAM slot being examined
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 3e5d4f1..493c774 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -891,6 +891,14 @@ static u32 edma_residue(struct edma_desc *edesc)
pos = edma_get_position(edesc->echan->slot[0], dst);
 
/*
+* "pos" may represent a transfer request that is still being
+* processed by the EDMACC or EDMATC. Wait until all transfer
+* requests on the active slot are finished before proceeding.
+*/
+   while (edma_is_actv(edesc->echan->slot[0]))
+   cpu_relax();
+
+   /*
 * Cyclic is simple. Just subtract pset[0].addr from pos.
 *
 * We never update edesc->residue in the cyclic case, so we
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index bdb2710..20c50e2 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -130,6 +130,7 @@ void edma_set_src(unsigned slot, dma_addr_t src_port,
enum address_mode mode, enum fifo_width);
 void edma_set_dest(unsigned slot, dma_addr_t dest_port,
 enum address_mode mode, enum fifo_width);
+bool edma_is_actv(unsigned slot);
 dma_addr_t edma_get_position(unsigned slot, bool dst);
 void edma_set_src_index(unsigned slot, s16 src_bidx, s16 src_cidx);
 void edma_set_dest_index(unsigned slot, s16 dest_bidx, s16 dest_cidx);
-- 
1.7.10.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] pci: restrict 64-bit pci device to assign resource from behind of max_pfn

2015-10-15 Thread Wenlin Kang
This patch restricts 64-bit pci device to assign resource from behind of
max_pfn when kernel config enables CONFIG_64BIT.

On some system that pci device requires assignment of large resource(eg,
1GB or larger), sometimes,the assignment of some devices may fail under
the current way.

e.g. the follow case is that.

...
[0.00] e820: [mem 0x9000-0xfed1bfff] available for PCI devices
[0.00] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:72 
nr_node_ids:2
...
[6.564750] pci :00:1c.7:   bridge window [mem 0x9f00-0xa08f]
[6.587130] pci :84:06.0: BAR 14: can't assign mem (size 0x6000)
[6.609158] pci :84:00.0: BAR 14: can't assign mem (size 0x10)
...

On this case, although the kernel has [0x9000-0xfed1bfff] [1.73GB]
size space is available for PCI devices, assignment of some devices fail
yet, the cause is the resource isn't yet enough for devices.

After apply this patch, this problem get resolved, the patch makes kernel
assign resource from behind of max_pfn for 64-bit pci devices when kernel
is 64BIT, however, previous way always assigns resource below 4GB no
matter it is 32 or 64-bit devices, so this patch extends this window of
pci resource on 64-bit system that both 32 and 64-bit pci device exist or
only 64-bit device exists, makes it more likely that we can assign
resource to more or all devices.

Signed-off-by: wlkang 
Signed-off-by: Wenlin Kang 
---
 drivers/pci/setup-res.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 232f925..dafd667 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -206,7 +206,19 @@ static int __pci_assign_resource(struct pci_bus *bus, 
struct pci_dev *dev,
resource_size_t min;
int ret;
 
+#ifdef CONFIG_64BIT
+   /*
+* For 64-bit pci device, assign resource start from the next page
+* boundary above the maximum physical page address
+*/
+   resource_size_t min_iomem;
+
+   min_iomem = (res->flags & IORESOURCE_MEM_64) ?
+   (max_pfn + 1) << PAGE_SHIFT : PCIBIOS_MIN_MEM;
+   min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : min_iomem;
+#else
min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
+#endif
 
/*
 * First, try exact prefetching match.  Even if a 64-bit
-- 
1.7.9.5

--
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: [Xen-devel] [PATCH v4 30/79] gntdev.h: use __u32 and __u64 from linux/types.h

2015-10-15 Thread David Vrabel
On 15/10/15 06:56, Mikko Rapeli wrote:
> Fixes userspace compilation errors like:
> 
> xen/gntdev.h:38:2: error: unknown type name ‘uint32_t’

Applied to for-linus-4.4, thanks.

David
--
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] ARM: edma: fix residue race for cyclic

2015-10-15 Thread Peter Ujfalusi
On 10/15/2015 01:46 PM, John Ogness wrote:
> When retrieving the residue value for cyclic transfers, the DST
> field of the active PaRAM is read. However, the AM335x Technical
> Reference Manual states:
> 
>   11.3.3.6 Parameter Set Updates
> 
>   After the TR is read from the PaRAM (and is in the process of
>   being submitted to the EDMA3TC), the following fields are
>   updated as needed: ... DST
> 
> This means the DST is incremented even though the DMA transfer
> may not have started yet or is in progress. Thus if the reader
> of the residue accesses the DMA buffer too quickly, the CPU
> will read where data is not yet written.
> 
> The CCSTAT.ACTV register is a boolean that is set if any TR is
> being processed by either the EMDA3CC or EDMA3TC. By polling
> this register it is possible to ensure that the residue value
> returned is valid for immediate processing.
> 
> Signed-off-by: John Ogness 
> ---
>  arch/arm/common/edma.c |   17 +

The arch/arm/common/edma.c does not exist anymore - see linux-next.

It is a good practice to include the maintainers for patches, like Sekhar and
Vinod in case of eDMA/dmaengine...

>  drivers/dma/edma.c |8 
>  include/linux/platform_data/edma.h |1 +
>  3 files changed, 26 insertions(+)
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index 873dbfc..86ce980 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -995,6 +995,23 @@ void edma_set_dest(unsigned slot, dma_addr_t dest_port,
>  }
>  EXPORT_SYMBOL(edma_set_dest);
>  
> +#define EDMA_CCSTAT_ACTV (1 << 4)
> +
> +/**
> + * edma_is_actv - report if any transfer requests are active
> + * @slot: parameter RAM slot being examined
> + *
> + * Returns true if any transfer requests are active on the slot
> + */
> +bool edma_is_actv(unsigned slot)
> +{
> + u32 ctlr = EDMA_CTLR(slot);
> + unsigned int ccstat;
> +
> + ccstat = edma_read(ctlr, EDMA_CCSTAT);
> + return (ccstat & EDMA_CCSTAT_ACTV);
> +}
> +
>  /**
>   * edma_get_position - returns the current transfer point
>   * @slot: parameter RAM slot being examined
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 3e5d4f1..493c774 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -891,6 +891,14 @@ static u32 edma_residue(struct edma_desc *edesc)
>   pos = edma_get_position(edesc->echan->slot[0], dst);
>  
>   /*
> +  * "pos" may represent a transfer request that is still being
> +  * processed by the EDMACC or EDMATC. Wait until all transfer
> +  * requests on the active slot are finished before proceeding.
> +  */
> + while (edma_is_actv(edesc->echan->slot[0]))
> + cpu_relax();

What happens if ACTV does not switch to 0? I know the chances are low, but are
we going to spin forever here?

> +
> + /*
>* Cyclic is simple. Just subtract pset[0].addr from pos.
>*
>* We never update edesc->residue in the cyclic case, so we
> diff --git a/include/linux/platform_data/edma.h 
> b/include/linux/platform_data/edma.h
> index bdb2710..20c50e2 100644
> --- a/include/linux/platform_data/edma.h
> +++ b/include/linux/platform_data/edma.h
> @@ -130,6 +130,7 @@ void edma_set_src(unsigned slot, dma_addr_t src_port,
>   enum address_mode mode, enum fifo_width);
>  void edma_set_dest(unsigned slot, dma_addr_t dest_port,
>enum address_mode mode, enum fifo_width);
> +bool edma_is_actv(unsigned slot);
>  dma_addr_t edma_get_position(unsigned slot, bool dst);
>  void edma_set_src_index(unsigned slot, s16 src_bidx, s16 src_cidx);
>  void edma_set_dest_index(unsigned slot, s16 dest_bidx, s16 dest_cidx);
> 


-- 
Péter
--
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 v2] ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board

2015-10-15 Thread Masahiro Yamada
The IRQ signal from external devices on this board is connected to
the XIRQ4 pin of the SoC.  The IRQ number should be 52, not 50.

Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b 
SoC/board support")
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - change IRQ to 52

 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts 
b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 33963ac..f80f772 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -85,7 +85,7 @@
 };
 
  {
-   interrupts = <0 50 4>;
+   interrupts = <0 52 4>;
 };
 
  {
-- 
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 v2 1/2] thermal: mediatek: Add cpu power cooling model.

2015-10-15 Thread dawei chien
On Mon, 2015-10-12 at 18:26 +0100, Punit Agrawal wrote:
> Mark Rutland  writes:
> 
> > On Wed, Oct 07, 2015 at 08:22:40PM +0800, Dawei Chien wrote:
> >> From: "Dawei.Chien" 
> >> 
> >> This power model is base on Intelligent Power Allocation (IPA) technical,
> >> requires that the operating-points of the CPUs are registered using the
> >> kernel's opp library and the `cpufreq_frequency_table` is assigned to the
> >> `struct device` of the cpu MT8173.
> >> 
> >> Signed-off-by: Dawei.Chien 
> >> ---
> >> This patch is base on
> >> https://patchwork.kernel.org/patch/7034601/
> >> ---
> >>  drivers/cpufreq/mt8173-cpufreq.c |   97 
> >> +-
> >>  1 file changed, 86 insertions(+), 11 deletions(-)
> >> 
> >> diff --git a/drivers/cpufreq/mt8173-cpufreq.c 
> >> b/drivers/cpufreq/mt8173-cpufreq.c
> >> index 49caed2..9233ec5 100644
> >> --- a/drivers/cpufreq/mt8173-cpufreq.c
> >> +++ b/drivers/cpufreq/mt8173-cpufreq.c
> >> @@ -28,7 +28,8 @@
> >>  #define MAX_VOLT_SHIFT(20)
> >>  #define MAX_VOLT_LIMIT(115)
> >>  #define VOLT_TOL  (1)
> >> -
> >> +#define CAPACITANCE_CA53  (263)
> >> +#define CAPACITANCE_CA57  (530)
> >>  /*
> >>   * The struct mtk_cpu_dvfs_info holds necessary information for doing CPU 
> >> DVFS
> >>   * on each CPU power/clock domain of Mediatek SoCs. Each CPU cluster in
> >> @@ -51,6 +52,72 @@ struct mtk_cpu_dvfs_info {
> >>bool need_voltage_tracking;
> >>  };
> >>  
> >> +struct mtk_cpu_static_power {
> >> +  unsigned long voltage;
> >> +  unsigned int power;
> >> +};
> >> +
> >> +/* measured by WA program. */
> >> +static const struct mtk_cpu_static_power mtk_ca53_static_power[] = {
> >> +  {859000, 43},
> >> +  {908000, 52},
> >> +  {983000, 86},
> >> +  {1009000, 123},
> >> +  {1028000, 138},
> >> +  {1083000, 172},
> >> +  {1109000, 180},
> >> +  {1125000, 192},
> >> +};
> >> +
> >> +/* measured by WA program. */
> >> +static const struct mtk_cpu_static_power mtk_ca57_static_power[] = {
> >> +  {828000, 72},
> >> +  {867000, 90},
> >> +  {927000, 156},
> >> +  {968000, 181},
> >> +  {1007000, 298},
> >> +  {1049000, 435},
> >> +  {1089000, 533},
> >> +  {1125000, 533},
> >> +};
> >
> > This should be described in the DT, rather than necessitating tonnes of
> > these tables in the kernel.
> 
> The above table is a simplification that is tying the static power of a
> device to a voltage (indirectly via frequency for ease of indexing
> perhaps).
> 
> We should definitely look at describing the static power model in the
> device tree - but it is not entirely clear what is the best model to
> use as basis for the device tree bindings.
> 
> Static power consumption depends on a few different parameters (silicon
> process, voltage, temperature, etc.). The relationship between them
> maybe non-linear and not all of these maybe significant for a given
> platform. e.g., for Juno, we are using a regression based on voltage and
> temperature which was deemed close enough (very subjective tbh).
> 
> On the other hand, dynamic power consumption is somewhat simpler and I
> have patches[0][1][2] enabling it's description in device tree. Your comments
> there would be very much appreciated.
> 
> As for this patch, I hope it can be moved to using the device tree when
> the bindings for static power are agreed upon. Although sub-optimal, I
> can't see any other way forward for now.
> 
> [0] http://thread.gmane.org/gmane.linux.kernel/2011466/focus=130373
> [1] http://thread.gmane.org/gmane.linux.kernel/2011466/focus=2011465
> [2] http://article.gmane.org/gmane.linux.drivers.sensors/37859

Hi Mark/Punit,
Thank you for your nice comments. I will resend this patch with device tree for 
dynamic/static power model,
and refer to Punit's patches, thank you.

> >
> > Mark.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.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: sdhci-pci or sdhci_pci

2015-10-15 Thread Richard Weinberger
On Thu, Oct 15, 2015 at 1:00 PM, Muni Sekhar  wrote:
>  [ Please keep me in CC as I'm not subscribed to the list]
>
> Hello,
>
> I loaded sdhci-pci.ko, but lsmod shows it as sdhci_pci.
> Why is that lsmod shows wrong module name( '-' changed to '_')?
>
>
> # lsmod
> Module  Size  Used by
> sdhci_pci  23301  0
> sdhci  43685  1 sdhci_pci

The problem is that module names must contain a dash. This is why kbuild
is renaming them.
IIRC because the modalias mechanism is using them.
CC'ing Rusty. Maybe he can give more details. :)

-- 
Thanks,
//richard
--
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] i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348

2015-10-15 Thread Wolfram Sang
On Thu, Sep 24, 2015 at 12:06:54PM +0300, Mika Westerberg wrote:
> ACPI SSCN/FMCN methods were originally added because then the platform can
> provide the most accurate HCNT/LCNT values to the driver. However, this
> seems not to be true for Dell Inspiron 7348 where using these causes the
> touchpad to fail in boot:
> 
>   i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
>   i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
>   i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
>   i2c_designware INT3433:00: controller timed out
> 
> The values received from ACPI are (in fast mode):
> 
>   HCNT: 72
>   LCNT: 160
> 
> this translates to following timings (input clock is 100MHz on Broadwell):
> 
>   tHIGH: 720 ns (spec min 600 ns)
>   tLOW: 1600 ns (spec min 1300 ns)
>   Bus period: 2920 ns (assuming 300 ns tf and tr)
>   Bus speed: 342.5 kHz
> 
> Both tHIGH and tLOW are within the I2C specification.
> 
> The calculated values when ACPI parameters are not used are (in fast mode):
> 
>   HCNT: 87
>   LCNT: 159
> 
> which translates to:
> 
>   tHIGH: 870 ns (spec min 600 ns)
>   tLOW: 1590 ns (spec min 1300 ns)
>   Bus period 3060 ns (assuming 300 ns tf and tr)
>   Bus speed 326.8 kHz
> 
> These values are also within the I2C specification.
> 
> Since both ACPI and calculated values meet the I2C specification timing
> requirements it is hard to say why the touchpad does not function properly
> with the ACPI values except that the bus speed is higher in this case (but
> still well below the max 400kHz).
> 
> Solve this by adding DMI quirk to the driver that disables using ACPI
> parameters on this particulare machine.
> 
> Reported-by: Pavel Roskin 
> Signed-off-by: Mika Westerberg 

Pavel, have you tested this patch?



signature.asc
Description: Digital signature


Re: [PATCH v2 1/4] i2c: designware-platdrv: enable RuntimePM before registering to the core

2015-10-15 Thread Wolfram Sang
On Fri, Oct 09, 2015 at 10:39:24AM +0100, Wolfram Sang wrote:
> From: Wolfram Sang 
> 
> The core may register clients attached to this master which may use
> funtionality from the master. So, RuntimePM must be enabled before, otherwise
> this will fail.
> 
> Signed-off-by: Wolfram Sang 

No feedback here, but for the other two drivers the same principle was
acked. CCing Mika, just in case.

Applied to for-current, thanks!

> ---
>  drivers/i2c/busses/i2c-designware-platdrv.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 3dd2de31a2f8d3..73d58415bbc100 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -253,12 +253,6 @@ static int dw_i2c_probe(struct platform_device *pdev)
>   adap->dev.parent = >dev;
>   adap->dev.of_node = pdev->dev.of_node;
>  
> - r = i2c_add_numbered_adapter(adap);
> - if (r) {
> - dev_err(>dev, "failure adding adapter\n");
> - return r;
> - }
> -
>   if (dev->pm_runtime_disabled) {
>   pm_runtime_forbid(>dev);
>   } else {
> @@ -268,6 +262,13 @@ static int dw_i2c_probe(struct platform_device *pdev)
>   pm_runtime_enable(>dev);
>   }
>  
> + r = i2c_add_numbered_adapter(adap);
> + if (r) {
> + dev_err(>dev, "failure adding adapter\n");
> + pm_runtime_disable(>dev);
> + return r;
> + }
> +
>   return 0;
>  }
>  
> -- 
> 2.1.4
> 


signature.asc
Description: Digital signature


Re: [PATCH] scsi: advansys needs ISA dma api for ISA support

2015-10-15 Thread Hannes Reinecke
On 10/12/2015 05:10 PM, Arnd Bergmann wrote:
> The advansys drvier uses the request_dma function that is used on ISA
> machines for the internal DMA controller, which causes build errors
> on platforms that have ISA slots but do not provide the ISA DMA API:
> 
> drivers/scsi/advansys.c: In function 'advansys_board_found':
> drivers/scsi/advansys.c:11300:10: error: implicit declaration of function 
> 'request_dma' [-Werror=implicit-function-declaration]
> 
> The problem now showed up in ARM randconfig builds after commit
> 6571fb3f8b7f ("advansys: Update to version 3.5 and remove compilation
> warning") made it possible to build on platforms that have neither
> VIRT_TO_BUS nor ISA_DMA_API but that do have ISA.
> 
> This adds the missing dependency.
> 
> Signed-off-by: Arnd Bergmann 
> 
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index d2f480b04a52..d4aa6a1a806c 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -499,6 +499,7 @@ config SCSI_ADVANSYS
>   tristate "AdvanSys SCSI support"
>   depends on SCSI
>   depends on ISA || EISA || PCI
> + depends on ISA_DMA_API || !ISA
>   help
> This is a driver for all SCSI host adapters manufactured by
> AdvanSys. It is documented in the kernel source in
> 
Sorry to chime in again, but wouldn't this allow to build on platforms
which have neither ISA_DMA_API nor ISA, like oldish sparc systems with
proprietary S-BUS?

Why not ISA_DMA_API || EISA || PCI ?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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/


  1   2   3   4   5   6   7   8   9   10   >