Re: [PATCH 2/4] mtd: nand: atmel: Update DT documentation after splitting NFC and NAND

[Brian Norris]

Hi Boris,

BTW, this series has a few conflicts with other things I have queued, so
you'll need to refresh.

On Thu, Dec 04, 2014 at 11:30:12PM +0100, Boris Brezillon wrote:
> The NAND and NFC (NAND Flash Controller) were linked together with a
> parent <-> child relationship.
> 
> This model has several drawbacks:
> - it does not allow for multiple NAND chip handling while the controller
>   support multi-chip (even though the driver is not ready yet)
> - it mixes NAND partitions and NFC nodes at the same level (which is a bit
>   disturbing)

I agree that this is disturbing. (FWIW, it also seems a bit disturbing
that atmel_nand.c actually registers two different drivers and the tries
to synchronize them; this seems like it could be handled better, but I'm
not sure how at the moment.)

> - the introduction of the EBI bus implies defining NAND chips under the
>   EBI node, and the ranges available under the EBI node should be
>   restricted to EBI address space, while the NFC references several
>   registers outside of these EBI ranges.

That's an interesting bit. I've actually run across this sort of problem
on other SoCs, where we have a relationship between two pieces of
hardware--the NAND chip and the NAND controller--where the former might
be on one bus (like your EBI bus, with chip selects), and the latter is
part of the top-level MMIO register space.

But can you elaborate here a bit more? Does the NAND chip actually need
to be represented under your EBI bus?

> Move the NFC node outside of the NAND node, to get a more future-proof
> model.

I'm curious if an alternative solution might work, maybe one like the
Allwiner NAND (sunxi-nand) DT, which just reverses the roles; the 'NFC'
is the parent of the NAND chip(s). We've seen this pattern in other
contexts too.

> Signed-off-by: Boris Brezillon 
> ---
>  .../devicetree/bindings/mtd/atmel-nand.txt | 46 
> --
>  1 file changed, 26 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt 
> b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> index 6edc3b6..8896850 100644
> --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> @@ -30,15 +30,19 @@ Optional properties:
>sector size 1024.
>  - nand-bus-width : 8 or 16 bus width if not present 8
>  - nand-on-flash-bbt: boolean to enable on flash bbt option if not present 
> false
> -- Nand Flash Controller(NFC) is a slave driver under Atmel nand flash
> -  - Required properties:
> -- compatible : "atmel,sama5d3-nfc".
> -- reg : should specify the address and size used for NFC command 
> registers,
> -NFC registers and NFC Sram. NFC Sram address and size can be 
> absent
> -if don't want to use it.
> -- clocks: phandle to the peripheral clock
> -  - Optional properties:
> -- atmel,write-by-sram: boolean to enable NFC write by sram.
> +- atmel,nfc: phandle referencing the NAND Flash Controller, if available.

So this seems to clarify one question I had: is the NAND flash
controller required? The previous language didn't make it extremely
clear that the NFC sub-node was optional. But it does appear your code
makes it optional.

> +
> +The NAND Flash Controller (NFC) is an advanced NAND controller and should be
> +used in conjunction with the NAND flash device.
> +Required properties:
> + - compatible : "atmel,sama5d3-nfc".
> + - reg : should specify the address and size used for NFC command registers,
> + NFC registers and NFC Sram. NFC Sram address and size can be absent
> + if you don't want to use it.
> + - clocks: phandle to the peripheral clock
> +
> +Optional properties:
> + - atmel,write-by-sram: boolean to enable NFC write by sram.
>  
>  Examples:
>  nand0: nand@4000,0 {
> @@ -89,21 +93,23 @@ nand0: nand@4000 {
>  };
>  
>  /* for NFC supported chips */
> +nfc: nfc@7000 {
> + compatible = "atmel,sama5d3-nfc";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + clocks = <&hsmc_clk>
> + reg = <
> + 0x7000 0x1000   /* NFC Command Registers */
> + 0xc000 0x0070   /* NFC HSMC regs */
> + 0x0020 0x0010   /* NFC SRAM banks */
> + >;
> +};
> +
>  nand0: nand@4000 {
>   compatible = "atmel,at91rm9200-nand";
>   #address-cells = <1>;
>   #size-cells = <1>;
>   ranges;
> + atmel,nfc = <&nfc>;
>  ...
> -nfc@7000 {
> - compatible = "atmel,sama5d3-nfc";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - clocks = <&hsmc_clk>
> - reg = <
> - 0x7000 0x1000   /* NFC Command Registers */
> - 0xc000 0x0070   /* NFC HSMC regs */
> - 0x0020 0x0010   /* NFC SRAM banks */
> - >;
> - };
>  };


Brian
--
To unsubscribe from thi

Re: [PATCH] rc: st_rc: Use CONFIG_PM_SLEEP instead of CONFIG_PM for st_rc_suspend() and st_rc_resume()

[Patrice Chotard]

Hi Chen

On 02/01/2015 03:42 PM, Chen Gang S wrote:

st_rc_suspend() and st_rc_resume() depend on CONFIG_PM_SLEEP finally, so
they need CONFIG_PM_SLEEP instead of CONFIG_PM, or they will cause build
warning (with allmodconfig under xtensa):

 CC [M]  drivers/media/pci/smipcie/smipcie.o
   drivers/media/rc/st_rc.c:338:12: warning: 'st_rc_suspend' defined but not 
used [-Wunused-function]
static int st_rc_suspend(struct device *dev)
   ^
   drivers/media/rc/st_rc.c:359:12: warning: 'st_rc_resume' defined but not 
used [-Wunused-function]
static int st_rc_resume(struct device *dev)
   ^

Signed-off-by: Chen Gang 
---
  drivers/media/rc/st_rc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 0e758ae..fbfe958 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -334,7 +334,7 @@ err:
return ret;
  }
  
-#ifdef CONFIG_PM

+#ifdef CONFIG_PM_SLEEP
  static int st_rc_suspend(struct device *dev)
  {
struct st_rc_device *rc_dev = dev_get_drvdata(dev);


Acked-by: Patrice Chotard 

Thanks
--
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] posix_acl: fix reference leaks in posix_acl_create

[Omar Sandoval]

On Wed, Jan 28, 2015 at 06:09:52PM +0100, Christoph Hellwig wrote:
> On Mon, Jan 26, 2015 at 10:16:53PM -0800, Omar Sandoval wrote:
> > get_acl gets a reference which we must release in the error cases.
> > 
> > Signed-off-by: Omar Sandoval 
> 
> Looks good, but at this point goto-based unwinding might be in order.

Hi, Christoph,

There are already a couple of return paths in posix_acl_create, and
there are only these two error cases, so I think gotos might actually
make the code more confusing. In any case, here's an idea:

posix_acl: fix reference leaks in posix_acl_create

get_acl gets a reference which we must release in the error cases.

Signed-off-by: Omar Sandoval 

diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index 0855f77..515d315 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -564,13 +564,11 @@ posix_acl_create(struct inode *dir, umode_t *mode,

*acl = posix_acl_clone(p, GFP_NOFS);
if (!*acl)
-   return -ENOMEM;
+   goto no_mem;

ret = posix_acl_create_masq(*acl, mode);
-   if (ret < 0) {
-   posix_acl_release(*acl);
-   return -ENOMEM;
-   }
+   if (ret < 0)
+   goto no_mem_clone;

if (ret == 0) {
posix_acl_release(*acl);
@@ -591,6 +589,12 @@ no_acl:
*default_acl = NULL;
*acl = NULL;
return 0;
+
+no_mem_clone:
+   posix_acl_release(*acl);
+no_mem:
+   posix_acl_release(p);
+   return -ENOMEM;
 }
 EXPORT_SYMBOL_GPL(posix_acl_create);

-- 
Omar
--
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] drm/rockchip: vop: power off until vop standby take effect

[Daniel Vetter]

On Mon, Feb 02, 2015 at 10:30:09AM +0800, Mark yao wrote:
> On 2015年02月02日 10:07, Daniel Kurtz wrote:
> >Hi Mark, Heiko,
> >
> >On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao  wrote:
> >>Vop standby will take effect end of current frame,
> >>if dsp_hold_valid_irq happen, it means vop standby complete.
> >>
> >>we must wait standby complete when we want to disable aclk,
> >>if not, memory bus maybe dead.
> >>
> >>Signed-off-by: Mark Yao 
> >>---
> >>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   76 
> >> ++-
> >>  1 file changed, 63 insertions(+), 13 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> >>b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >>index fb25836..47ea61f 100644
> >>--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >>+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >>@@ -89,6 +89,7 @@ struct vop {
> >> /* mutex vsync_ work */
> >> struct mutex vsync_mutex;
> >> bool vsync_work_pending;
> >>+   struct completion dsp_hold_completion;
> >>
> >> const struct vop_data *data;
> >>
> >>@@ -382,6 +383,34 @@ static bool is_alpha_support(uint32_t format)
> >> }
> >>  }
> >>
> >>+static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
> >>+{
> >>+   unsigned long flags;
> >>+
> >>+   BUG_ON(!vop->is_enabled);
> >Re: Heiko "use a WARN_ON":
> >
> >If the VOP clock is off, then the system will just hang when trying to
> >write the VOP register so in this case, BUG_ON gives a more reliable
> >crash dump than the hang.
>   In this way, you are right, if vop clocks is disabled, write vop register
> will hang system, and the WARN_ON

if (WARN_ON(cond))
return;

is what we commonly use in i915. Because it's really not any good to use
BUG_ON in drm drivers, at least if you expect anyone to use fbcon on top
of it (i.e. anything even remotely resembling a normal distro): Then the
intial modeset is all done under console_lock, which means that _none_ of
your BUG_ON will ever get out over serial console.

The problem is fbcon locking, but no fool yet signed up to fix it (it's
horrible, I looked ...).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM

[David Gibson]

On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.

This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode).  Some CPU models provide special
registers to control the cache attributes of real mode load and stores but
this is not at all consistent.  This is a problem in particular for SLOF,
the firmware used on KVM guests, which runs entirely in real mode, but
which needs to do IO to load the kernel.

To simplify this qemu implements two special hypercalls, H_LOGICAL_CI_LOAD
and H_LOGICAL_CI_STORE which simulate a cache-inhibited load or store to
a logical address (aka guest physical address).  SLOF uses these for IO.

However, because these are implemented within qemu, not the host kernel,
these bypass any IO devices emulated within KVM itself.  The simplest way
to see this problem is to attempt to boot a KVM guest from a virtio-blk
device with iothread / dataplane enabled.  The iothread code relies on an
in kernel implementation of the virtio queue notification, which is not
triggered by the IO hcalls, and so the guest will stall in SLOF unable to
load the guest OS.

This patch addresses this by providing in-kernel implementations of the
2 hypercalls, which correctly scan the KVM IO bus.  Any access to an
address not handled by the KVM IO bus will cause a VM exit, hitting the
qemu implementation as before.

Note that a userspace change is also required, in order to enable these
new hcall implementations with KVM_CAP_PPC_ENABLE_HCALL.

Signed-off-by: David Gibson 
---
 arch/powerpc/include/asm/kvm_book3s.h |  3 ++
 arch/powerpc/kvm/book3s.c | 76 +++
 arch/powerpc/kvm/book3s_hv.c  | 16 
 arch/powerpc/kvm/book3s_pr_papr.c | 28 +
 4 files changed, 123 insertions(+)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index 942c7b1..578e550 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -292,6 +292,9 @@ static inline bool kvmppc_supports_magic_page(struct 
kvm_vcpu *vcpu)
return !is_kvmppc_hv_enabled(vcpu->kvm);
 }
 
+extern int kvmppc_h_logical_ci_load(struct kvm_vcpu *vcpu);
+extern int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu);
+
 /* Magic register values loaded into r3 and r4 before the 'sc' assembly
  * instruction for the OSI hypercalls */
 #define OSI_SC_MAGIC_R30x113724FA
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 888bf46..792c7cf 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -820,6 +820,82 @@ void kvmppc_core_destroy_vm(struct kvm *kvm)
 #endif
 }
 
+int kvmppc_h_logical_ci_load(struct kvm_vcpu *vcpu)
+{
+   unsigned long size = kvmppc_get_gpr(vcpu, 4);
+   unsigned long addr = kvmppc_get_gpr(vcpu, 5);
+   u64 buf;
+   int ret;
+
+   if (!is_power_of_2(size) || (size > sizeof(buf)))
+   return H_TOO_HARD;
+
+   ret = kvm_io_bus_read(vcpu->kvm, KVM_MMIO_BUS, addr, size, &buf);
+   if (ret != 0)
+   return H_TOO_HARD;
+
+   switch (size) {
+   case 1:
+   kvmppc_set_gpr(vcpu, 4, *(u8 *)&buf);
+   break;
+
+   case 2:
+   kvmppc_set_gpr(vcpu, 4, *(u16 *)&buf);
+   break;
+
+   case 4:
+   kvmppc_set_gpr(vcpu, 4, *(u32 *)&buf);
+   break;
+
+   case 8:
+   kvmppc_set_gpr(vcpu, 4, *(u64 *)&buf);
+   break;
+
+   default:
+   BUG();
+   }
+
+   return H_SUCCESS;
+}
+EXPORT_SYMBOL_GPL(kvmppc_h_logical_ci_load); /* For use by the kvm-pr module */
+
+int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu)
+{
+   unsigned long size = kvmppc_get_gpr(vcpu, 4);
+   unsigned long addr = kvmppc_get_gpr(vcpu, 5);
+   unsigned long val = kvmppc_get_gpr(vcpu, 6);
+   u64 buf;
+   int ret;
+
+   switch (size) {
+   case 1:
+   *(u8 *)&buf = val;
+   break;
+
+   case 2:
+   *(u16 *)&buf = val;
+   break;
+
+   case 4:
+   *(u32 *)&buf = val;
+   break;
+
+   case 8:
+   *(u64 *)&buf = val;
+   break;
+
+   default:
+   return H_TOO_HARD;
+   }
+
+   ret = kvm_io_bus_write(vcpu->kvm, KVM_MMIO_BUS, addr, size, &buf);
+   if (ret != 0)
+   return H_TOO_HARD;
+
+   return H_SUCCESS;
+}
+EXPORT_SYMBOL_GPL(kvmppc_h_logical_ci_store); /* For use by the kvm-pr module 
*/
+
 int kvmppc_core_check_processor_compat(void)
 {
/*
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index de4018a..1013019 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -706,6 +706,20 @@ int kvmppc_pseries_do_hcall(struct kvm_vcp

[PATCH] Add ARCH_MIGHT_HAVE_VGA_CONSOLE

[Yoshinori Sato]

The dependence of VGA_CONSOLE is complicated.
We need clean up.

Signed-off-by: Yoshinori Sato 

---
 arch/alpha/Kconfig| 1 +
 arch/arc/Kconfig  | 1 +
 arch/arm/Kconfig  | 1 +
 arch/c6x/Kconfig  | 1 +
 arch/hexagon/Kconfig  | 1 +
 arch/ia64/Kconfig | 1 +
 arch/m32r/Kconfig | 1 +
 arch/metag/Kconfig| 1 +
 arch/microblaze/Kconfig   | 1 +
 arch/mips/Kconfig | 1 +
 arch/nios2/Kconfig| 1 +
 arch/openrisc/Kconfig | 1 +
 arch/powerpc/Kconfig  | 1 +
 arch/s390/Kconfig | 1 +
 arch/score/Kconfig| 1 +
 arch/tile/Kconfig | 1 +
 arch/um/Kconfig.common| 1 +
 arch/unicore32/Kconfig| 1 +
 arch/x86/Kconfig  | 1 +
 arch/xtensa/Kconfig   | 1 +
 drivers/video/console/Kconfig | 8 
 21 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index b7ff9a3..5940d83 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -27,6 +27,7 @@ config ALPHA
select MODULES_USE_ELF_RELA
select ODD_RT_SIGACTION
select OLD_SIGSUSPEND
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE
help
  The Alpha is a 64-bit general-purpose processor designed and
  marketed by the Digital Equipment Corporation of blessed memory,
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index df94ac1..d2c8401 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -36,6 +36,7 @@ config ARC
select OF_EARLY_FLATTREE
select PERF_USE_VMALLOC
select HAVE_DEBUG_STACKOVERFLOW
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE
 
 config TRACE_IRQFLAGS_SUPPORT
def_bool y
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97d07ed..5662728 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -76,6 +76,7 @@ config ARM
select PERF_USE_VMALLOC
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE if ARCH_FOOTBRIDGE || 
ARCH_INTEGRATOR || ARCH_NETWINDER
# Above selects are sorted alphabetically; please add new ones
# according to that.  Thanks.
help
diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index 77ea09b..d74c07a 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -17,6 +17,7 @@ config C6X
select OF_EARLY_FLATTREE
select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE
 
 config MMU
def_bool n
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 4dc89d1..c08fed2 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -28,6 +28,7 @@ config HEXAGON
select MODULES_USE_ELF_RELA
select GENERIC_CPU_DEVICES
select HAVE_DMA_ATTRS
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE
---help---
  Qualcomm Hexagon is a processor architecture designed for high
  performance and low power across a wide variety of applications.
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 074e52b..55e91d9 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -47,6 +47,7 @@ config IA64
select MODULES_USE_ELF_RELA
select ARCH_USE_CMPXCHG_LOCKREF
select HAVE_ARCH_AUDITSYSCALL
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE
default y
help
  The Itanium Processor Family is Intel's 64-bit successor to
diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
index 9e44bbd..15ed3c9 100644
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -16,6 +16,7 @@ config M32R
select ARCH_USES_GETTIMEOFFSET
select MODULES_USE_ELF_RELA
select HAVE_DEBUG_STACKOVERFLOW
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE
 
 config SBUS
bool
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index 0b389a8..9826622 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -29,6 +29,7 @@ config METAG
select OF
select OF_EARLY_FLATTREE
select SPARSE_IRQ
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE
 
 config STACKTRACE_SUPPORT
def_bool y
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 0bce820..94e9f56 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -2,6 +2,7 @@ config MICROBLAZE
def_bool y
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_MIGHT_HAVE_PC_PARPORT
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_WANT_OPTIONAL_GPIOLIB
select BUILDTIME_EXTABLE_SORT
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 3289969..0d5fe76 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -54,6 +54,7 @@ config MIPS
select CPU_PM if CPU_IDLE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_BINFMT_ELF_STATE
+   select ARCH_MIGHT_HAVE_VGA_CONSOLE 
 
 menu "Machine selection"
 
diff --git a/arch/nios2/Kc

[PATCH] fcntl.h: Fix a typo

[Bart Van Assche]

In the source file fs/fcntl.c and also in the fcntl() man page one
can see that the FD_CLOEXEC flag can be manipulated via F_GETFD and
F_SETFD. Update the comment in  accordingly.

Signed-off-by: Bart Van Assche 
Cc: David Miller 
Cc: Stephen Rothwell 
---
 include/uapi/asm-generic/fcntl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index e063eff..584fa2b 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -157,7 +157,7 @@ struct f_owner_ex {
__kernel_pid_t  pid;
 };
 
-/* for F_[GET|SET]FL */
+/* for F_[GET|SET]FD */
 #define FD_CLOEXEC 1   /* actually anything with low bit set goes */
 
 /* for posix fcntl() and lockf() */
-- 
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: [resend Patch v3 2/2] export the kernel image size KERNEL_IMAGE_SIZE

[Baoquan He]

Hi Thomas,

Could you please also merge this patch? Since you have merged this patch
"x86, boot: Skip relocs when load address unchanged [commit f285f4a21]",
and this issue was raised because it broke kexec/kdump, then I posted
these 2 patches. Without this patch makedumpfile will be broken when
enable kaslr and do the kdump.

Thanks
Baouqan

On 09/30/2014 03:08 PM, Baoquan He wrote:
> Now kaslr makes kernel image size changable, not the fixed size 512M.
> So KERNEL_IMAGE_SIZE need be exported to VMCOREINFO, otherwise makedumfile
> will crash.
> 
> Signed-off-by: Baoquan He 
> Acked-by: Kees Cook 
> Acked-by: Vivek Goyal 
> ---
>  kernel/kexec.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 2bee072..bd680d3 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -2003,6 +2003,9 @@ static int __init crash_save_vmcoreinfo_init(void)
>  #endif
>   VMCOREINFO_NUMBER(PG_head_mask);
>   VMCOREINFO_NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE);
> +#ifdef CONFIG_X86
> +   VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
> +#endif
>  #ifdef CONFIG_HUGETLBFS
>   VMCOREINFO_SYMBOL(free_huge_page);
>  #endif
> 

--
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: checkpatch: length of git commit IDs

[Joe Perches]

On Mon, 2015-02-02 at 08:24 +0100, Stefan Richter wrote:
> On Feb 01 Joe Perches wrote:
> > On Sun, 2015-02-01 at 21:30 +0100, Stefan Richter wrote:
> > > On Feb 01 Joe Perches wrote:
> > > > On Sun, 2015-02-01 at 20:59 +0100, Stefan Richter wrote:
> > > > > > ERROR: Please use 12 or more chars for the git commit ID like: 
> > > > > > 'Commit
> > > > > > 01234567890ab ("commit description")' #5: 
> > > > > > Commit 2a48fc0ab242 "block: autoconvert trivial BKL users to private
> [...]
> > > Thanks for the tip; this works for me.  (checkpatch.pl from current -next
> > > does actually not complain about the line without parentheses.)
> > 
> > Hmm, I think that should be a defect.
> > 
> > Can you send me your git format-patch output please?
> 
> First of all to be sure:  The checkpatch.pl which I last referred to is
> 158501 bytes in size, and the md5sum is bf953e10cbd7405bcf3e885b24c832bd.
> $ scripts/checkpatch.pl 
> patches/scsi-sr-fix-multi-drive-performance-remove-bkl-replacement.patch 
> total: 0 errors, 0 warnings, 71 lines checked

Thanks.
I think I "fixed" it with this patch:
https://lkml.org/lkml/2015/2/1/249


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

Re: [RFC PATCH v3 1/3] mm/cma: change fallback behaviour for CMA freepage

[Joonsoo Kim]

On Mon, Feb 02, 2015 at 04:15:46PM +0900, Joonsoo Kim wrote:
> freepage with MIGRATE_CMA can be used only for MIGRATE_MOVABLE and
> they should not be expanded to other migratetype buddy list
> to protect them from unmovable/reclaimable allocation. Implementing
> these requirements in __rmqueue_fallback(), that is, finding largest
> possible block of freepage has bad effect that high order freepage
> with MIGRATE_CMA are broken continually although there are suitable
> order CMA freepage. Reason is that they are not be expanded to other
> migratetype buddy list and next __rmqueue_fallback() invocation try to
> finds another largest block of freepage and break it again. So,
> MIGRATE_CMA fallback should be handled separately. This patch
> introduces __rmqueue_cma_fallback(), that just wrapper of
> __rmqueue_smallest() and call it before __rmqueue_fallback()
> if migratetype == MIGRATE_MOVABLE.
> 
> This results in unintended behaviour change that MIGRATE_CMA freepage
> is always used first rather than other migratetype as movable
> allocation's fallback. But, as already mentioned above,
> MIGRATE_CMA can be used only for MIGRATE_MOVABLE, so it is better
> to use MIGRATE_CMA freepage first as much as possible. Otherwise,
> we needlessly take up precious freepages with other migratetype and
> increase chance of fragmentation.
> 
> Signed-off-by: Joonsoo Kim 
> ---

Hello, Vlastimil.

This RFC is targeted to you, but, I mistakenly omit your e-mail
on CC list. Sorry about that. :/

How about this v3 which try to clean-up __rmqueue_fallback() much more?

Thanks.
--
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] tun: orphan an skb on tx

[David Woodhouse]

On Sun, 2015-02-01 at 21:07 -0800, David Miller wrote:
> From: David Woodhouse 
> Date: Sun, 01 Feb 2015 21:29:43 +
> 
> > I really was looking for some way to push down something like an XFRM
> > state into the tun device and just say "shove them out here until I tell
> > you otherwise".
> 
> People decided to use TUN and push VPN stuff back into userspace,
> and there are repercussions for that decision.
> 
> I'm not saying this to be mean or whatever, but I was very
> disappointed when userland IPSEC solutions using TUN started showing
> up.

Yeah. That's a valid criticism of vpnc, certainly. I never did
understand why it reimplemented the IPSec stack.

For my OpenConnect client it's somewhat more justified though — the
initial data transport there is over TLS, which the kernel doesn't
support. And if we *can* establish UDP communication, that's over DTLS
which the kernel doesn't support either. It's not even the *standard*
version of DTLS because Cisco are still using a pre-RFC4347 version of
the protocol. And we also need to probe the UDP connectivity and do
keepalives and manage the fallback to using the TCP data transport.

It's not like vpnc where it really is just a case of setting up the ESP
context and letting it run.

It's only now I've added Juniper support, which uses ESP-in-UDP for the
data transport, that I'm doing something that the kernel supports at
all. And now I'm looking at how to make use of that.

> We might as well have not have implemented the IPSEC stack at all,
> because as a result of the userland VPN stuff our IPSEC stack is
> largely unused except by a very narrow group of users.

Well, I'd love to make better use of it if I can. I do suspect it makes
most sense for userspace to continue to manage the probing of UDP
connectivity, and the fallback to TCP mode — and I suspect it also makes
sense to continue to use tun for passing packets up to the VPN client
when it's using the TCP transport.

So the question would be how we handle redirecting the packet flow to
the optional UDP transport, when the VPN client determines that it's
available. For the sake of the user setting up firewall and routing
rules, I do think it's important that it continues to appear to
userspace as the *same* device for the entire lifetime of the session,
regardless of which transport the packets happen to be using at a given
moment in time. It doesn't *have* to be tun, though. 

You don't seem to like my suggestion of somehow pushing down an XFRM
state to the tun device to direct the packets out there instead of up to
userspace. Do you have an alternative suggestion... or a specific
concern that would help me come up with something you like better?

I'm guessing you don't want to push the *whole* management of the TLS
control connection *and* the UDP transport, and probing the latter with
keepalives, into the kernel? I certainly don't :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature

Re: checkpatch: length of git commit IDs

[Stefan Richter]

On Feb 01 Joe Perches wrote:
> On Sun, 2015-02-01 at 21:30 +0100, Stefan Richter wrote:
> > On Feb 01 Joe Perches wrote:
> > > On Sun, 2015-02-01 at 20:59 +0100, Stefan Richter wrote:
> > > > > ERROR: Please use 12 or more chars for the git commit ID like: 'Commit
> > > > > 01234567890ab ("commit description")' #5: 
> > > > > Commit 2a48fc0ab242 "block: autoconvert trivial BKL users to private
[...]
> > Thanks for the tip; this works for me.  (checkpatch.pl from current -next
> > does actually not complain about the line without parentheses.)
> 
> Hmm, I think that should be a defect.
> 
> Can you send me your git format-patch output please?

First of all to be sure:  The checkpatch.pl which I last referred to is
158501 bytes in size, and the md5sum is bf953e10cbd7405bcf3e885b24c832bd.
$ scripts/checkpatch.pl 
patches/scsi-sr-fix-multi-drive-performance-remove-bkl-replacement.patch 
total: 0 errors, 0 warnings, 71 lines checked

patches/scsi-sr-fix-multi-drive-performance-remove-bkl-replacement.patch has no 
obvious style problems and is ready for submission.

Here is the patch file:

Date: Tue, 28 Feb 2012 15:32:44 +0100
From: Stefan Richter 
Subject: [SCSI] sr: fix multi-drive performance, remove BKL replacement

Commit 2a48fc0ab242 "block: autoconvert trivial BKL users to private
mutex" and other commits at the time mechanically swapped BKL for
per-driver global mutexes.  If the sr driver is any indication, these
replacements have still not been checked by anybody for their
necessessity, removed where possible, or the sections they serialize
reduced to a necessary minimum.

The sr_mutex in particular very noticably degraded performance of
CD-DA ripping with multiple drives in parallel.  When several
instances of "grip" are used with two or more drives, their GUIs
became laggier, as did the KDE file manager GUI, and drive utilization
was reduced.  (During ripping, drive lights flicker instead of staying
on most of the time.)  IOW time to rip a stack of CDs was increased.
I didn't measure this but it is highly noticeable.

On the other hand, I don't see what state sr_mutex would protect.
So I removed it entirely and that works fine for me.

Tested with up to six CD-ROM drives connected at the same time (1x
IDE, 5x FireWire), 12 grip instances running (2 per drive, one for
ripping and the other just polling the TOC as a test), and of course
udisks-daemon sitting in the background and polling the CD-ROM drives
as usual.  GUI lags are reduced and ripping throughput increased to
a level how I remember it from BKL era.

Also tested:  Erasing and writing a CD-RW with K3B/cdrecord while grip
and udisks-daemon poll the CD-RW drive and other grip instances rip
CD-DA from three other CD-ROM drives.


On Tue, 2012-02-28 at 16:42 +, Arnd Bergmann wrote:
> I took another look and I believe the cdi->use_count in
> cdrom_open/cdrom_release still requires some protection that is
> currently provided by sr_mutex. Some parts of cdrom_ioctl also
> access this variable and things like cdi->options or cdi->keeplocked.
> 
> I could imagine that you can get rid of the mutex if you turn those
> into atomics and bitops, but there may be other parts of cdrom_device_info
> that need locking. A safer option to solve the performance problems
> could be to replace sr_mutex with a per-device mutex inside of
> cdrom_device_info.

On Fri, 2013-01-04 at 00:11 +0100, Otto Meta wrote:
> Otto Meta wrote:  
> > The single mutex for the sr module, introduced as a BKL replacement,
> > globally serialises all sr ioctls, which hurts multi-drive performance.
> > 
> > This patch replaces sr_mutex with per-device mutexes in struct scsi_cd,
> > allowing concurrent ioctls on different sr devices.  
> 
> Unfortunately it wasn't as easy as that. The patch seems to introduce
> a race condition that corrupts a drive's state under certain circumstances.
> 
> When two drives (e.g. sr0 and sr1) are attached to the same IDE cable, one
> drive has its door locked, which will usually be the case after any operation
> on the drive with inserted media (and whenever it feels like it, even with
> dev.cdrom.lock=0), and the other drive is unlocked, then executing
> 
>   $ eject sr0 & eject sr1
> 
> will eject the unlocked drive and the locked drive will return
> 
>   eject: unable to eject, last error: Inappropriate ioctl for device
> 
> 
> Other drivers down the road probably don't expect concurrent ioctls, so this
> patch cannot be applied safely at this time. Sorry about the noise.
> 
> For the record: Tested with kernels 3.2.35 and 3.8.0-rc1, using IDE CD/DVD
> drives connected via the drivers ata_piix and pata_pdc202xx_old.  


Signed-off-by: Stefan Richter 
---
 drivers/scsi/sr.c |   24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -76,7 +76,6 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_WORM);
 CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_P

[RFC PATCH v3 2/3] mm/page_alloc: factor out fallback freepage checking

[Joonsoo Kim]

This is preparation step to use page allocator's anti fragmentation logic
in compaction. This patch just separates fallback freepage checking part
from fallback freepage management part. Therefore, there is no functional
change.

Signed-off-by: Joonsoo Kim 
---
 mm/page_alloc.c | 128 +---
 1 file changed, 76 insertions(+), 52 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e64b260..6cb18f8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1142,14 +1142,26 @@ static void change_pageblock_range(struct page 
*pageblock_page,
  * as fragmentation caused by those allocations polluting movable pageblocks
  * is worse than movable allocations stealing from unmovable and reclaimable
  * pageblocks.
- *
- * If we claim more than half of the pageblock, change pageblock's migratetype
- * as well.
  */
-static void try_to_steal_freepages(struct zone *zone, struct page *page,
- int start_type, int fallback_type)
+static bool can_steal_fallback(unsigned int order, int start_mt)
+{
+   if (order >= pageblock_order)
+   return true;
+
+   if (order >= pageblock_order / 2 ||
+   start_mt == MIGRATE_RECLAIMABLE ||
+   start_mt == MIGRATE_UNMOVABLE ||
+   page_group_by_mobility_disabled)
+   return true;
+
+   return false;
+}
+
+static void steal_suitable_fallback(struct zone *zone, struct page *page,
+ int start_type)
 {
int current_order = page_order(page);
+   int pages;
 
/* Take ownership for orders >= pageblock_order */
if (current_order >= pageblock_order) {
@@ -1157,19 +1169,39 @@ static void try_to_steal_freepages(struct zone *zone, 
struct page *page,
return;
}
 
-   if (current_order >= pageblock_order / 2 ||
-   start_type == MIGRATE_RECLAIMABLE ||
-   start_type == MIGRATE_UNMOVABLE ||
-   page_group_by_mobility_disabled) {
-   int pages;
+   pages = move_freepages_block(zone, page, start_type);
 
-   pages = move_freepages_block(zone, page, start_type);
+   /* Claim the whole block if over half of it is free */
+   if (pages >= (1 << (pageblock_order-1)) ||
+   page_group_by_mobility_disabled)
+   set_pageblock_migratetype(page, start_type);
+}
 
-   /* Claim the whole block if over half of it is free */
-   if (pages >= (1 << (pageblock_order-1)) ||
-   page_group_by_mobility_disabled)
-   set_pageblock_migratetype(page, start_type);
+static int find_suitable_fallback(struct free_area *area, unsigned int order,
+   int migratetype, bool *can_steal)
+{
+   int i;
+   int fallback_mt;
+
+   if (area->nr_free == 0)
+   return -1;
+
+   *can_steal = false;
+   for (i = 0;; i++) {
+   fallback_mt = fallbacks[migratetype][i];
+   if (fallback_mt == MIGRATE_RESERVE)
+   break;
+
+   if (list_empty(&area->free_list[fallback_mt]))
+   continue;
+
+   if (can_steal_fallback(order, migratetype))
+   *can_steal = true;
+
+   return i;
}
+
+   return -1;
 }
 
 /* Remove an element from the buddy allocator from the fallback list */
@@ -1179,53 +1211,45 @@ __rmqueue_fallback(struct zone *zone, unsigned int 
order, int start_migratetype)
struct free_area *area;
unsigned int current_order;
struct page *page;
+   int fallback_mt;
+   bool can_steal;
 
/* Find the largest possible block of pages in the other list */
for (current_order = MAX_ORDER-1;
current_order >= order && current_order <= 
MAX_ORDER-1;
--current_order) {
-   int i;
-   for (i = 0;; i++) {
-   int migratetype = fallbacks[start_migratetype][i];
-   int buddy_type = start_migratetype;
-
-   /* MIGRATE_RESERVE handled later if necessary */
-   if (migratetype == MIGRATE_RESERVE)
-   break;
-
-   area = &(zone->free_area[current_order]);
-   if (list_empty(&area->free_list[migratetype]))
-   continue;
-
-   page = list_entry(area->free_list[migratetype].next,
-   struct page, lru);
-   area->nr_free--;
+   area = &(zone->free_area[current_order]);
+   fallback_mt = find_suitable_fallback(area, current_order,
+   start_migratetype, &can_steal);
+   if (fallback_mt == -1)
+ 

[RFC PATCH v3 1/3] mm/cma: change fallback behaviour for CMA freepage

[Joonsoo Kim]

freepage with MIGRATE_CMA can be used only for MIGRATE_MOVABLE and
they should not be expanded to other migratetype buddy list
to protect them from unmovable/reclaimable allocation. Implementing
these requirements in __rmqueue_fallback(), that is, finding largest
possible block of freepage has bad effect that high order freepage
with MIGRATE_CMA are broken continually although there are suitable
order CMA freepage. Reason is that they are not be expanded to other
migratetype buddy list and next __rmqueue_fallback() invocation try to
finds another largest block of freepage and break it again. So,
MIGRATE_CMA fallback should be handled separately. This patch
introduces __rmqueue_cma_fallback(), that just wrapper of
__rmqueue_smallest() and call it before __rmqueue_fallback()
if migratetype == MIGRATE_MOVABLE.

This results in unintended behaviour change that MIGRATE_CMA freepage
is always used first rather than other migratetype as movable
allocation's fallback. But, as already mentioned above,
MIGRATE_CMA can be used only for MIGRATE_MOVABLE, so it is better
to use MIGRATE_CMA freepage first as much as possible. Otherwise,
we needlessly take up precious freepages with other migratetype and
increase chance of fragmentation.

Signed-off-by: Joonsoo Kim 
---
 mm/page_alloc.c | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8d52ab1..e64b260 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1029,11 +1029,9 @@ struct page *__rmqueue_smallest(struct zone *zone, 
unsigned int order,
 static int fallbacks[MIGRATE_TYPES][4] = {
[MIGRATE_UNMOVABLE]   = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE, 
MIGRATE_RESERVE },
[MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE,   MIGRATE_MOVABLE, 
MIGRATE_RESERVE },
+   [MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE,   
MIGRATE_RESERVE },
 #ifdef CONFIG_CMA
-   [MIGRATE_MOVABLE] = { MIGRATE_CMA, MIGRATE_RECLAIMABLE, 
MIGRATE_UNMOVABLE, MIGRATE_RESERVE },
[MIGRATE_CMA] = { MIGRATE_RESERVE }, /* Never used */
-#else
-   [MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE,   
MIGRATE_RESERVE },
 #endif
[MIGRATE_RESERVE] = { MIGRATE_RESERVE }, /* Never used */
 #ifdef CONFIG_MEMORY_ISOLATION
@@ -1041,6 +1039,17 @@ static int fallbacks[MIGRATE_TYPES][4] = {
 #endif
 };
 
+#ifdef CONFIG_CMA
+static struct page *__rmqueue_cma_fallback(struct zone *zone,
+   unsigned int order)
+{
+   return __rmqueue_smallest(zone, order, MIGRATE_CMA);
+}
+#else
+static inline struct page *__rmqueue_cma_fallback(struct zone *zone,
+   unsigned int order) { return NULL; }
+#endif
+
 /*
  * Move the free pages in a range to the free lists of the requested type.
  * Note that start_page and end_pages are not aligned on a pageblock
@@ -1192,19 +1201,8 @@ __rmqueue_fallback(struct zone *zone, unsigned int 
order, int start_migratetype)
struct page, lru);
area->nr_free--;
 
-   if (!is_migrate_cma(migratetype)) {
-   try_to_steal_freepages(zone, page,
-   start_migratetype,
-   migratetype);
-   } else {
-   /*
-* When borrowing from MIGRATE_CMA, we need to
-* release the excess buddy pages to CMA
-* itself, and we do not try to steal extra
-* free pages.
-*/
-   buddy_type = migratetype;
-   }
+   try_to_steal_freepages(zone, page, start_migratetype,
+   migratetype);
 
/* Remove the page from the freelists */
list_del(&page->lru);
@@ -1246,7 +1244,11 @@ retry_reserve:
page = __rmqueue_smallest(zone, order, migratetype);
 
if (unlikely(!page) && migratetype != MIGRATE_RESERVE) {
-   page = __rmqueue_fallback(zone, order, migratetype);
+   if (migratetype == MIGRATE_MOVABLE)
+   page = __rmqueue_cma_fallback(zone, order);
+
+   if (!page)
+   page = __rmqueue_fallback(zone, order, migratetype);
 
/*
 * Use MIGRATE_RESERVE rather than fail an allocation. goto
-- 
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/

[RFC PATCH v3 3/3] mm/compaction: enhance compaction finish condition

[Joonsoo Kim]

Compaction has anti fragmentation algorithm. It is that freepage
should be more than pageblock order to finish the compaction if we don't
find any freepage in requested migratetype buddy list. This is for
mitigating fragmentation, but, there is a lack of migratetype
consideration and it is too excessive compared to page allocator's anti
fragmentation algorithm.

Not considering migratetype would cause premature finish of compaction.
For example, if allocation request is for unmovable migratetype,
freepage with CMA migratetype doesn't help that allocation and
compaction should not be stopped. But, current logic regards this
situation as compaction is no longer needed, so finish the compaction.

Secondly, condition is too excessive compared to page allocator's logic.
We can steal freepage from other migratetype and change pageblock
migratetype on more relaxed conditions in page allocator. This is designed
to prevent fragmentation and we can use it here. Imposing hard constraint
only to the compaction doesn't help much in this case since page allocator
would cause fragmentation again.

To solve these problems, this patch borrows anti fragmentation logic from
page allocator. It will reduce premature compaction finish in some cases
and reduce excessive compaction work.

stress-highalloc test in mmtests with non movable order 7 allocation shows
considerable increase of compaction success rate.

Compaction success rate (Compaction success * 100 / Compaction stalls, %)
31.82 : 42.20

Signed-off-by: Joonsoo Kim 
---
 mm/compaction.c | 14 --
 mm/internal.h   |  2 ++
 mm/page_alloc.c | 12 
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 782772d..d40c426 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1170,13 +1170,23 @@ static int __compact_finished(struct zone *zone, struct 
compact_control *cc,
/* Direct compactor: Is a suitable page free? */
for (order = cc->order; order < MAX_ORDER; order++) {
struct free_area *area = &zone->free_area[order];
+   bool can_steal;
 
/* Job done if page is free of the right migratetype */
if (!list_empty(&area->free_list[migratetype]))
return COMPACT_PARTIAL;
 
-   /* Job done if allocation would set block type */
-   if (order >= pageblock_order && area->nr_free)
+   /* MIGRATE_MOVABLE can fallback on MIGRATE_CMA */
+   if (migratetype == MIGRATE_MOVABLE &&
+   !list_empty(&area->free_list[MIGRATE_CMA]))
+   return COMPACT_PARTIAL;
+
+   /*
+* Job done if allocation would steal freepages from
+* other migratetype buddy lists.
+*/
+   if (find_suitable_fallback(area, order, migratetype,
+   true, &can_steal) != -1)
return COMPACT_PARTIAL;
}
 
diff --git a/mm/internal.h b/mm/internal.h
index c4d6c9b..9640650 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -200,6 +200,8 @@ isolate_freepages_range(struct compact_control *cc,
 unsigned long
 isolate_migratepages_range(struct compact_control *cc,
   unsigned long low_pfn, unsigned long end_pfn);
+int find_suitable_fallback(struct free_area *area, unsigned int order,
+   int migratetype, bool only_stealable, bool *can_steal);
 
 #endif
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6cb18f8..0a150f1 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1177,8 +1177,8 @@ static void steal_suitable_fallback(struct zone *zone, 
struct page *page,
set_pageblock_migratetype(page, start_type);
 }
 
-static int find_suitable_fallback(struct free_area *area, unsigned int order,
-   int migratetype, bool *can_steal)
+int find_suitable_fallback(struct free_area *area, unsigned int order,
+   int migratetype, bool only_stealable, bool *can_steal)
 {
int i;
int fallback_mt;
@@ -1198,7 +1198,11 @@ static int find_suitable_fallback(struct free_area 
*area, unsigned int order,
if (can_steal_fallback(order, migratetype))
*can_steal = true;
 
-   return i;
+   if (!only_stealable)
+   return i;
+
+   if (*can_steal)
+   return i;
}
 
return -1;
@@ -1220,7 +1224,7 @@ __rmqueue_fallback(struct zone *zone, unsigned int order, 
int start_migratetype)
--current_order) {
area = &(zone->free_area[current_order]);
fallback_mt = find_suitable_fallback(area, current_order,
-   start_migratetype, &can_steal);
+   start_migratetype, false, &can_steal);

[PATCH 1/2] mailbox: check for bit set before polling

[Jassi Brar]

From: Jassi Brar 

Before polling we just need to see if the TXDONE_BY_POLL bit
is set in txdone_method. There may be another bit (method)
specified as well, like TXDONE_BY_ACK.

Signed-off-by: Jassi Brar 
---
 drivers/mailbox/mailbox.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 59aad4d..19b491d 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -87,7 +87,7 @@ static void msg_submit(struct mbox_chan *chan)
 exit:
spin_unlock_irqrestore(&chan->lock, flags);
 
-   if (!err && chan->txdone_method == TXDONE_BY_POLL)
+   if (!err && (chan->txdone_method & TXDONE_BY_POLL))
poll_txdone((unsigned long)chan->mbox);
 }
 
-- 
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] mailbox: Add Altera mailbox driver

[Ley Foon Tan]

On Mon, Feb 2, 2015 at 3:04 PM, Jassi Brar  wrote:
> On Mon, Dec 22, 2014 at 3:14 PM, Ley Foon Tan  wrote:
> ...
>
>> diff --git a/drivers/mailbox/mailbox-altera.c 
>> b/drivers/mailbox/mailbox-altera.c
>> new file mode 100644
>> index 000..8019795
>> --- /dev/null
>> +++ b/drivers/mailbox/mailbox-altera.c
>> @@ -0,0 +1,385 @@
>> +/*
>> + * Copyright Altera Corporation (C) 2013-2014. All rights reserved
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program.  If not, see .
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define DRIVER_NAME"altera-mailbox"
>> +
>> +#define MAILBOX_CMD_REG0x00
>> +#define MAILBOX_PTR_REG0x04
>> +#define MAILBOX_STS_REG0x08
>> +#define MAILBOX_INTMASK_REG0x0C
>> +
>> +#define INT_PENDING_MSK0x1
>> +#define INT_SPACE_MSK  0x2
>> +
>> +#define STS_PENDING_MSK0x1
>> +#define STS_FULL_MSK   0x2
>> +#define STS_FULL_OFT   0x1
>> +
>> +#define MBOX_PENDING(status)   (((status) & STS_PENDING_MSK))
>> +#define MBOX_FULL(status)  (((status) & STS_FULL_MSK) >> STS_FULL_OFT)
>> +
>> +enum altera_mbox_msg {
>> +   MBOX_CMD = 0,
>> +   MBOX_PTR,
>> +};
>> +
>> +#define MBOX_POLLING_MS1   /* polling interval 1ms */
>> +
> The intention is too aggressive - though poll won't be before next jiffy 
> (>1ms).
> And if you are not expecting a reply, it should be even bigger. Say,
> 50ms default and 5ms when you expect RX?
Currently MBOX_POLLING_MS is used for RX polling and TX polling.
I think change to 5ms should be fine, 50ms is a bit too long. Do you
okay with this?
>
>> +struct altera_mbox {
>> +   bool is_sender; /* 1-sender, 0-receiver */
>> +   bool intr_mode;
>> +   int irq;
>> +   void __iomem *mbox_base;
>> +   struct device *dev;
>> +   struct mbox_controller controller;
>> +
>> +   /* If the controller supports only RX polling mode */
>> +   struct timer_list rxpoll_timer;
>> +};
>> +
>> +static struct altera_mbox *mbox_chan_to_altera_mbox(struct mbox_chan *chan)
>> +{
>> +   if (!chan || !chan->con_priv)
>> +   return NULL;
>> +
>> +   return (struct altera_mbox *)chan->con_priv;
>> +}
>> +
>> +static inline int altera_mbox_full(struct altera_mbox *mbox)
>> +{
>> +   u32 status;
>> +
>> +   status = readl(mbox->mbox_base + MAILBOX_STS_REG);
>> +   return MBOX_FULL(status);
>> +}
>>
> s/readl/readl_relaxed  and s/writel/writel_relaxed everywhere
Noted.
>
>> +
>> +static inline int altera_mbox_pending(struct altera_mbox *mbox)
>> +{
>> +   u32 status;
>> +
>> +   status = readl(mbox->mbox_base + MAILBOX_STS_REG);
>> +   return MBOX_PENDING(status);
>> +}
>> +
>> +static void altera_mbox_rx_intmask(struct altera_mbox *mbox, bool enable)
>> +{
>> +   u32 mask;
>> +
>> +   mask = readl(mbox->mbox_base + MAILBOX_INTMASK_REG);
>> +   if (enable)
>> +   mask |= INT_PENDING_MSK;
>> +   else
>> +   mask &= ~INT_PENDING_MSK;
>> +   writel(mask, mbox->mbox_base + MAILBOX_INTMASK_REG);
>> +}
>> +
>> +static void altera_mbox_tx_intmask(struct altera_mbox *mbox, bool enable)
>> +{
>> +   u32 mask;
>> +
>> +   mask = readl(mbox->mbox_base + MAILBOX_INTMASK_REG);
>> +   if (enable)
>> +   mask |= INT_SPACE_MSK;
>> +   else
>> +   mask &= ~INT_SPACE_MSK;
>> +   writel(mask, mbox->mbox_base + MAILBOX_INTMASK_REG);
>> +}
>> +
>> +static bool altera_mbox_is_sender(struct altera_mbox *mbox)
>> +{
>> +   u32 reg;
>> +   /* Write a magic number to PTR register and read back this register.
>> +* This register is read-write if it is a sender.
>> +*/
>> +   #define MBOX_MAGIC  0xA5A5AA55
>> +   writel(MBOX_MAGIC, mbox->mbox_base + MAILBOX_PTR_REG);
>> +   reg = readl(mbox->mbox_base + MAILBOX_PTR_REG);
>> +   if (reg == MBOX_MAGIC) {
>> +   /* Clear to 0 */
>> +   writel(0, mbox->mbox_base + MAILBOX_PTR_REG);
>> +   return true;
>> +   }
>> +   return false;
>> +}
>> +
>> +static void altera_mbox_rx_data(struct mbox_chan *chan)
>> +{
>> +   struct altera_mbox *mbox = mbox_chan_to_alte

Re: [PATCH v2 4/4] mm/compaction: enhance compaction finish condition

[Joonsoo Kim]

On Sat, Jan 31, 2015 at 11:58:03PM +0800, Zhang Yanfei wrote:
> At 2015/1/30 20:34, Joonsoo Kim wrote:
> > From: Joonsoo 
> > 
> > Compaction has anti fragmentation algorithm. It is that freepage
> > should be more than pageblock order to finish the compaction if we don't
> > find any freepage in requested migratetype buddy list. This is for
> > mitigating fragmentation, but, there is a lack of migratetype
> > consideration and it is too excessive compared to page allocator's anti
> > fragmentation algorithm.
> > 
> > Not considering migratetype would cause premature finish of compaction.
> > For example, if allocation request is for unmovable migratetype,
> > freepage with CMA migratetype doesn't help that allocation and
> > compaction should not be stopped. But, current logic regards this
> > situation as compaction is no longer needed, so finish the compaction.
> > 
> > Secondly, condition is too excessive compared to page allocator's logic.
> > We can steal freepage from other migratetype and change pageblock
> > migratetype on more relaxed conditions in page allocator. This is designed
> > to prevent fragmentation and we can use it here. Imposing hard constraint
> > only to the compaction doesn't help much in this case since page allocator
> > would cause fragmentation again.
> 
> Changing both two behaviours in compaction may change the high order 
> allocation
> behaviours in the buddy allocator slowpath, so just as Vlastimil suggested,
> some data from allocator should be necessary and helpful, IMHO.

As Vlastimil said, fragmentation effect should be checked. I will do
it and report the result on next version.

Thanks.

--
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 4/4] mm/compaction: enhance compaction finish condition

[Joonsoo Kim]

On Fri, Jan 30, 2015 at 03:43:27PM +0100, Vlastimil Babka wrote:
> On 01/30/2015 01:34 PM, Joonsoo Kim wrote:
> > From: Joonsoo 
> > 
> > Compaction has anti fragmentation algorithm. It is that freepage
> > should be more than pageblock order to finish the compaction if we don't
> > find any freepage in requested migratetype buddy list. This is for
> > mitigating fragmentation, but, there is a lack of migratetype
> > consideration and it is too excessive compared to page allocator's anti
> > fragmentation algorithm.
> > 
> > Not considering migratetype would cause premature finish of compaction.
> > For example, if allocation request is for unmovable migratetype,
> > freepage with CMA migratetype doesn't help that allocation and
> > compaction should not be stopped. But, current logic regards this
> > situation as compaction is no longer needed, so finish the compaction.
> > 
> > Secondly, condition is too excessive compared to page allocator's logic.
> > We can steal freepage from other migratetype and change pageblock
> > migratetype on more relaxed conditions in page allocator. This is designed
> > to prevent fragmentation and we can use it here. Imposing hard constraint
> > only to the compaction doesn't help much in this case since page allocator
> > would cause fragmentation again.
> > 
> > To solve these problems, this patch borrows anti fragmentation logic from
> > page allocator. It will reduce premature compaction finish in some cases
> > and reduce excessive compaction work.
> > 
> > stress-highalloc test in mmtests with non movable order 7 allocation shows
> > considerable increase of compaction success rate.
> > 
> > Compaction success rate (Compaction success * 100 / Compaction stalls, %)
> > 31.82 : 42.20
> > 
> > Signed-off-by: Joonsoo Kim 
> 
> I have some worries about longer-term fragmentation, some testing of
> stress-highalloc several times without restarts could be helpful.

Okay. I will do it.

> 
> > ---
> >  include/linux/mmzone.h |  3 +++
> >  mm/compaction.c| 30 --
> >  mm/internal.h  |  1 +
> >  mm/page_alloc.c|  5 ++---
> >  4 files changed, 34 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index f279d9c..a2906bc 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -63,6 +63,9 @@ enum {
> > MIGRATE_TYPES
> >  };
> >  
> > +#define FALLBACK_MIGRATETYPES (4)
> > +extern int fallbacks[MIGRATE_TYPES][FALLBACK_MIGRATETYPES];
> > +
> >  #ifdef CONFIG_CMA
> >  #  define is_migrate_cma(migratetype) unlikely((migratetype) == 
> > MIGRATE_CMA)
> >  #else
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index 782772d..0460e4b 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -1125,6 +1125,29 @@ static isolate_migrate_t isolate_migratepages(struct 
> > zone *zone,
> > return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
> >  }
> >  
> > +static bool can_steal_fallbacks(struct free_area *area,
> > +   unsigned int order, int migratetype)
> 
> Could you move this to page_alloc.c and then you don't have to export the
> fallbacks arrays?

Okay.

> 
> > +{
> > +   int i;
> > +   int fallback_mt;
> > +
> > +   if (area->nr_free == 0)
> > +   return false;
> > +
> > +   for (i = 0; i < FALLBACK_MIGRATETYPES; i++) {
> > +   fallback_mt = fallbacks[migratetype][i];
> > +   if (fallback_mt == MIGRATE_RESERVE)
> > +   break;
> > +
> > +   if (list_empty(&area->free_list[fallback_mt]))
> > +   continue;
> > +
> > +   if (can_steal_freepages(order, migratetype, fallback_mt))
> > +   return true;
> > +   }
> > +   return false;
> > +}
> > +
> >  static int __compact_finished(struct zone *zone, struct compact_control 
> > *cc,
> > const int migratetype)
> >  {
> > @@ -1175,8 +1198,11 @@ static int __compact_finished(struct zone *zone, 
> > struct compact_control *cc,
> > if (!list_empty(&area->free_list[migratetype]))
> > return COMPACT_PARTIAL;
> >  
> > -   /* Job done if allocation would set block type */
> > -   if (order >= pageblock_order && area->nr_free)
> > +   /*
> > +* Job done if allocation would steal freepages from
> > +* other migratetype buddy lists.
> > +*/
> > +   if (can_steal_fallbacks(area, order, migratetype))
> > return COMPACT_PARTIAL;
> 
> Seems somewhat wasteful in scenario where we want to satisfy a movable
> allocation and it's an async compaction. Then we don't compact in
> unmovable/reclaimable pageblock, and yet we will keep checking them for
> fallbacks. A price to pay for having generic code?

I think that there would be lucky case that high order freepage on
unmovable/reclaimable pageblock is made by concurrent freeing.
In this case, finishing compaction wo

Re: [PATCH] mtd: avoid registering reboot notifier twice

[Niklas Cassel]

On 02/02/2015 12:07 AM, Brian Norris wrote:
> On Sun, Feb 01, 2015 at 02:08:50AM +0100, Niklas Cassel wrote:
>> Calling mtd_device_parse_register with the same mtd_info
>> (e.g. registering several partitions on a single device)
>> would add the same reboot notifier twice, causing an
>> infinte loop in notifier_chain_register during boot up.
> No driver should be calling mtd_device_parse_register() multiple times
> on the same mtd_info. Under what context do you see this? What driver?
arch/cris/arch-v32/drivers/axisflashmap.c

It calls mtd_device_register for different partitions on same device using the 
same mtd_info.

What do you suggest this driver should do instead?

>
>> Signed-off-by: Niklas Cassel 
>> ---
>>  drivers/mtd/mtdcore.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
>> index de79576..98efc1e 100644
>> --- a/drivers/mtd/mtdcore.c
>> +++ b/drivers/mtd/mtdcore.c
>> @@ -556,7 +556,7 @@ int mtd_device_parse_register(struct mtd_info *mtd, 
>> const char * const *types,
>>  err = -ENODEV;
>>  }
>>  
>> -if (mtd->_reboot) {
>> +if (mtd->_reboot && !mtd->reboot_notifier.notifier_call) {
>>  mtd->reboot_notifier.notifier_call = mtd_reboot_notifier;
>>  register_reboot_notifier(&mtd->reboot_notifier);
>>  }
> Brian

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

[dgc-xfs:xfs-ioctl-setattr-cleanup 11/12] fs/xfs/xfs_ioctl.c:1146:1: sparse: symbol 'xfs_ioctl_setattr_check_projid' was not declared. Should it be static?

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs 
xfs-ioctl-setattr-cleanup
head:   9b94fcc39822b450af823b3d8cbef6b53ce87ed9
commit: 23bd0735cfdf5322170a9ef48c7d47c2e6567ba8 [11/12] xfs: factor projid 
hint checking out of xfs_ioctl_setattr
reproduce:
  # apt-get install sparse
  git checkout 23bd0735cfdf5322170a9ef48c7d47c2e6567ba8
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   fs/xfs/xfs_ioctl.c:1102:1: sparse: symbol 'xfs_ioctl_setattr_check_extsize' 
was not declared. Should it be static?
>> fs/xfs/xfs_ioctl.c:1146:1: sparse: symbol 'xfs_ioctl_setattr_check_projid' 
>> was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
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 dgc-xfs] xfs: xfs_ioctl_setattr_check_projid can be static

[kbuild test robot]

fs/xfs/xfs_ioctl.c:1146:1: sparse: symbol 'xfs_ioctl_setattr_check_projid' was 
not declared. Should it be static?

Signed-off-by: Fengguang Wu 
---
 xfs_ioctl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index 1f186d2..1060513 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -1142,7 +1142,7 @@ xfs_ioctl_setattr_check_extsize(
return 0;
 }
 
-int
+static int
 xfs_ioctl_setattr_check_projid(
struct xfs_inode*ip,
struct fsxattr  *fa)
--
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 v1 2/2] zram: remove init_lock in zram_make_request

[Sergey Senozhatsky]

On (02/02/15 15:18), Minchan Kim wrote:
> > a quick idea:
> > can we additionally move all bd flush and put work after 
> > zram_reset_device(zram, true)
> > and, perhaps, replace ->bd_holders with something else?
> > 
> > zram_reset_device() will not return until we have active IOs, pending IOs 
> > will be
> > invalidated by ->disksize != 0.
> 
> Sorry, I don't get it. Could you describe what you are concerning about 
> active I/O?
> My concern is just race bd_holder/bd_openers and bd_holders of zram check.
> I don't think any simple solution without bd_mutex.
> If we can close the race, anything could be a solution.
> If we close the race, we should return -EBUSY if anyone is opening the zram 
> device
> so bd_openers check would be better than bd_holders.
> 

yeah, sorry. nevermind.


So, guys, how about doing it differently, in less lines of code,
hopefully. Don't move reset_store()'s work to zram_reset_device().
Instead, move

set_capacity(zram->disk, 0);
revalidate_disk(zram->disk);

out from zram_reset_device() to reset_store(). this two function are
executed only when called from reset_store() anyway. this also will let
us drop `bool reset capacity' param from zram_reset_device().


so we will do in reset_store()

mutex_lock(bdev->bd_mutex);

fsync_bdev(bdev);
zram_reset_device(zram);
set_capacity(zram->disk, 0);

mutex_unlock(&bdev->bd_mutex);

revalidate_disk(zram->disk);
bdput(bdev);



and change zram_reset_device(zram, false) call to simply zram_reset_device(zram)
in __exit zram_exit(void).

-ss
--
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] mailbox: Add Altera mailbox driver

[Jassi Brar]

On Mon, Dec 22, 2014 at 3:14 PM, Ley Foon Tan  wrote:
...

> diff --git a/drivers/mailbox/mailbox-altera.c 
> b/drivers/mailbox/mailbox-altera.c
> new file mode 100644
> index 000..8019795
> --- /dev/null
> +++ b/drivers/mailbox/mailbox-altera.c
> @@ -0,0 +1,385 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2014. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME"altera-mailbox"
> +
> +#define MAILBOX_CMD_REG0x00
> +#define MAILBOX_PTR_REG0x04
> +#define MAILBOX_STS_REG0x08
> +#define MAILBOX_INTMASK_REG0x0C
> +
> +#define INT_PENDING_MSK0x1
> +#define INT_SPACE_MSK  0x2
> +
> +#define STS_PENDING_MSK0x1
> +#define STS_FULL_MSK   0x2
> +#define STS_FULL_OFT   0x1
> +
> +#define MBOX_PENDING(status)   (((status) & STS_PENDING_MSK))
> +#define MBOX_FULL(status)  (((status) & STS_FULL_MSK) >> STS_FULL_OFT)
> +
> +enum altera_mbox_msg {
> +   MBOX_CMD = 0,
> +   MBOX_PTR,
> +};
> +
> +#define MBOX_POLLING_MS1   /* polling interval 1ms */
> +
The intention is too aggressive - though poll won't be before next jiffy (>1ms).
And if you are not expecting a reply, it should be even bigger. Say,
50ms default and 5ms when you expect RX?

> +struct altera_mbox {
> +   bool is_sender; /* 1-sender, 0-receiver */
> +   bool intr_mode;
> +   int irq;
> +   void __iomem *mbox_base;
> +   struct device *dev;
> +   struct mbox_controller controller;
> +
> +   /* If the controller supports only RX polling mode */
> +   struct timer_list rxpoll_timer;
> +};
> +
> +static struct altera_mbox *mbox_chan_to_altera_mbox(struct mbox_chan *chan)
> +{
> +   if (!chan || !chan->con_priv)
> +   return NULL;
> +
> +   return (struct altera_mbox *)chan->con_priv;
> +}
> +
> +static inline int altera_mbox_full(struct altera_mbox *mbox)
> +{
> +   u32 status;
> +
> +   status = readl(mbox->mbox_base + MAILBOX_STS_REG);
> +   return MBOX_FULL(status);
> +}
>
s/readl/readl_relaxed  and s/writel/writel_relaxed everywhere

> +
> +static inline int altera_mbox_pending(struct altera_mbox *mbox)
> +{
> +   u32 status;
> +
> +   status = readl(mbox->mbox_base + MAILBOX_STS_REG);
> +   return MBOX_PENDING(status);
> +}
> +
> +static void altera_mbox_rx_intmask(struct altera_mbox *mbox, bool enable)
> +{
> +   u32 mask;
> +
> +   mask = readl(mbox->mbox_base + MAILBOX_INTMASK_REG);
> +   if (enable)
> +   mask |= INT_PENDING_MSK;
> +   else
> +   mask &= ~INT_PENDING_MSK;
> +   writel(mask, mbox->mbox_base + MAILBOX_INTMASK_REG);
> +}
> +
> +static void altera_mbox_tx_intmask(struct altera_mbox *mbox, bool enable)
> +{
> +   u32 mask;
> +
> +   mask = readl(mbox->mbox_base + MAILBOX_INTMASK_REG);
> +   if (enable)
> +   mask |= INT_SPACE_MSK;
> +   else
> +   mask &= ~INT_SPACE_MSK;
> +   writel(mask, mbox->mbox_base + MAILBOX_INTMASK_REG);
> +}
> +
> +static bool altera_mbox_is_sender(struct altera_mbox *mbox)
> +{
> +   u32 reg;
> +   /* Write a magic number to PTR register and read back this register.
> +* This register is read-write if it is a sender.
> +*/
> +   #define MBOX_MAGIC  0xA5A5AA55
> +   writel(MBOX_MAGIC, mbox->mbox_base + MAILBOX_PTR_REG);
> +   reg = readl(mbox->mbox_base + MAILBOX_PTR_REG);
> +   if (reg == MBOX_MAGIC) {
> +   /* Clear to 0 */
> +   writel(0, mbox->mbox_base + MAILBOX_PTR_REG);
> +   return true;
> +   }
> +   return false;
> +}
> +
> +static void altera_mbox_rx_data(struct mbox_chan *chan)
> +{
> +   struct altera_mbox *mbox = mbox_chan_to_altera_mbox(chan);
> +   u32 data[2];
> +
> +   if (altera_mbox_pending(mbox)) {
> +   data[MBOX_PTR] = readl(mbox->mbox_base + MAILBOX_PTR_REG);
> +   data[MBOX_CMD] = readl(mbox->mbox_base + MAILBOX_CMD_REG);
> +   mbox_chan_received_data(chan, (void *)data);
> +   }
> +}
> +
> +static void altera_mbox_poll_rx(unsign

Re: [PATCH v2 3/4] mm/page_alloc: separate steal decision from steal behaviour part

[Joonsoo Kim]

On Sat, Jan 31, 2015 at 08:38:10PM +0800, Zhang Yanfei wrote:
> At 2015/1/30 20:34, Joonsoo Kim wrote:
> > From: Joonsoo 
> > 
> > This is preparation step to use page allocator's anti fragmentation logic
> > in compaction. This patch just separates steal decision part from actual
> > steal behaviour part so there is no functional change.
> > 
> > Signed-off-by: Joonsoo Kim 
> > ---
> >  mm/page_alloc.c | 49 -
> >  1 file changed, 32 insertions(+), 17 deletions(-)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 8d52ab1..ef74750 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1122,6 +1122,24 @@ static void change_pageblock_range(struct page 
> > *pageblock_page,
> > }
> >  }
> >  
> > +static bool can_steal_freepages(unsigned int order,
> > +   int start_mt, int fallback_mt)
> > +{
> > +   if (is_migrate_cma(fallback_mt))
> > +   return false;
> > +
> > +   if (order >= pageblock_order)
> > +   return true;
> > +
> > +   if (order >= pageblock_order / 2 ||
> > +   start_mt == MIGRATE_RECLAIMABLE ||
> > +   start_mt == MIGRATE_UNMOVABLE ||
> > +   page_group_by_mobility_disabled)
> > +   return true;
> > +
> > +   return false;
> > +}
> 
> So some comments which can tell the cases can or cannot steal freepages
> from other migratetype is necessary IMHO. Actually we can just
> move some comments in try_to_steal_pages to here.

Yes, move some comments looks sufficient to me. I will fix it.

Thanks.
--
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 dgc-xfs] xfs: xfs_ioctl_setattr_check_extsize can be static

[kbuild test robot]

fs/xfs/xfs_ioctl.c:1102:1: sparse: symbol 'xfs_ioctl_setattr_check_extsize' was 
not declared. Should it be static?

Signed-off-by: Fengguang Wu 
---
 xfs_ioctl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index 9f80853..992b669 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -1098,7 +1098,7 @@ out_cancel:
return ERR_PTR(error);
 }
 
-int
+static int
 xfs_ioctl_setattr_check_extsize(
struct xfs_inode*ip,
struct fsxattr  *fa)
--
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/

[dgc-xfs:xfs-ioctl-setattr-cleanup 10/12] fs/xfs/xfs_ioctl.c:1102:1: sparse: symbol 'xfs_ioctl_setattr_check_extsize' was not declared. Should it be static?

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs 
xfs-ioctl-setattr-cleanup
head:   9b94fcc39822b450af823b3d8cbef6b53ce87ed9
commit: d4388d3c0988ec00787ad1f8e63b5e2a6abef1dc [10/12] xfs: factor extsize 
hint checking out of xfs_ioctl_setattr
reproduce:
  # apt-get install sparse
  git checkout d4388d3c0988ec00787ad1f8e63b5e2a6abef1dc
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> fs/xfs/xfs_ioctl.c:1102:1: sparse: symbol 'xfs_ioctl_setattr_check_extsize' 
>> was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/4] mm/page_alloc: separate steal decision from steal behaviour part

[Joonsoo Kim]

On Fri, Jan 30, 2015 at 03:27:50PM +0100, Vlastimil Babka wrote:
> On 01/30/2015 01:34 PM, Joonsoo Kim wrote:
> > From: Joonsoo 
> > 
> > This is preparation step to use page allocator's anti fragmentation logic
> > in compaction. This patch just separates steal decision part from actual
> > steal behaviour part so there is no functional change.
> > 
> > Signed-off-by: Joonsoo Kim 
> > ---
> >  mm/page_alloc.c | 49 -
> >  1 file changed, 32 insertions(+), 17 deletions(-)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 8d52ab1..ef74750 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1122,6 +1122,24 @@ static void change_pageblock_range(struct page 
> > *pageblock_page,
> > }
> >  }
> >  
> > +static bool can_steal_freepages(unsigned int order,
> > +   int start_mt, int fallback_mt)
> > +{
> > +   if (is_migrate_cma(fallback_mt))
> > +   return false;
> > +
> > +   if (order >= pageblock_order)
> > +   return true;
> > +
> > +   if (order >= pageblock_order / 2 ||
> > +   start_mt == MIGRATE_RECLAIMABLE ||
> > +   start_mt == MIGRATE_UNMOVABLE ||
> > +   page_group_by_mobility_disabled)
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
> >  /*
> >   * When we are falling back to another migratetype during allocation, try 
> > to
> >   * steal extra free pages from the same pageblocks to satisfy further
> > @@ -1138,9 +1156,10 @@ static void change_pageblock_range(struct page 
> > *pageblock_page,
> >   * as well.
> >   */
> >  static void try_to_steal_freepages(struct zone *zone, struct page *page,
> > - int start_type, int fallback_type)
> > + int start_type)
> 
> It's actually not 'try_to_' anymore, is it? But could be, see below.
> 
> >  {
> > int current_order = page_order(page);
> > +   int pages;
> >  
> > /* Take ownership for orders >= pageblock_order */
> > if (current_order >= pageblock_order) {
> > @@ -1148,19 +1167,12 @@ static void try_to_steal_freepages(struct zone 
> > *zone, struct page *page,
> > return;
> > }
> >  
> > -   if (current_order >= pageblock_order / 2 ||
> > -   start_type == MIGRATE_RECLAIMABLE ||
> > -   start_type == MIGRATE_UNMOVABLE ||
> > -   page_group_by_mobility_disabled) {
> > -   int pages;
> > +   pages = move_freepages_block(zone, page, start_type);
> >  
> > -   pages = move_freepages_block(zone, page, start_type);
> > -
> > -   /* Claim the whole block if over half of it is free */
> > -   if (pages >= (1 << (pageblock_order-1)) ||
> > -   page_group_by_mobility_disabled)
> > -   set_pageblock_migratetype(page, start_type);
> > -   }
> > +   /* Claim the whole block if over half of it is free */
> > +   if (pages >= (1 << (pageblock_order-1)) ||
> > +   page_group_by_mobility_disabled)
> > +   set_pageblock_migratetype(page, start_type);
> >  }
> >  
> >  /* Remove an element from the buddy allocator from the fallback list */
> > @@ -1170,6 +1182,7 @@ __rmqueue_fallback(struct zone *zone, unsigned int 
> > order, int start_migratetype)
> > struct free_area *area;
> > unsigned int current_order;
> > struct page *page;
> > +   bool can_steal;
> >  
> > /* Find the largest possible block of pages in the other list */
> > for (current_order = MAX_ORDER-1;
> > @@ -1192,10 +1205,11 @@ __rmqueue_fallback(struct zone *zone, unsigned int 
> > order, int start_migratetype)
> > struct page, lru);
> > area->nr_free--;
> >  
> > -   if (!is_migrate_cma(migratetype)) {
> > +   can_steal = can_steal_freepages(current_order,
> > +   start_migratetype, migratetype);
> > +   if (can_steal) {
> 
> can_steal is only used once, why not do if (can_steal_freepages()) directly?
> 
> Or, call can_steal_freepages() from try_to_steal_freepages() and make
> try_to_steal_freepages() return its result. Then here it simplifies to:
> 
> if (!try_to_steal_freepages(...) && is_migrate_cma(...))
>   buddy_type = migratetype;

You're right. Your commented code loosk better.

Your comment on 3/4 and 4/4 makes me reconsider this code factorization
and I found better solution.
I will send it soon.

Thanks.
--
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] gfs2: use __vmalloc GFP_NOFS for fs-related allocations.

[Oleg Drokin]

Hello!

On Feb 2, 2015, at 12:37 AM, Dave Chinner wrote:

> On Sun, Feb 01, 2015 at 10:59:54PM -0500, gr...@linuxhacker.ru wrote:
>> From: Oleg Drokin 
>> 
>> leaf_dealloc uses vzalloc as a fallback to kzalloc(GFP_NOFS), so
>> it clearly does not want any shrinker activity within the fs itself.
>> convert vzalloc into __vmalloc(GFP_NOFS|__GFP_ZERO) to better achieve
>> this goal.
>> 
>> Signed-off-by: Oleg Drokin 
>> ---
>> fs/gfs2/dir.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
>> index c5a34f0..6371192 100644
>> --- a/fs/gfs2/dir.c
>> +++ b/fs/gfs2/dir.c
>> @@ -1896,7 +1896,8 @@ static int leaf_dealloc(struct gfs2_inode *dip, u32 
>> index, u32 len,
>> 
>>  ht = kzalloc(size, GFP_NOFS | __GFP_NOWARN);
>>  if (ht == NULL)
>> -ht = vzalloc(size);
>> +ht = __vmalloc(size, GFP_NOFS | __GFP_NOWARN | __GFP_ZERO,
>> +   PAGE_KERNEL);
> That, in the end, won't help as vmalloc still uses GFP_KERNEL
> allocations deep down in the PTE allocation code. See the hacks in
> the DM and XFS code to work around this. i.e. go look for callers of
> memalloc_noio_save().  It's ugly and grotesque, but we've got no
> other way to limit reclaim context because the MM devs won't pass
> the vmalloc gfp context down the stack to the PTE allocations

Hm, interesting.
So all the other code in the kernel that does this sort of thing (and there's 
quite a bit
outside of xfs and ocfs2) would not get the desired effect?

So, I did some digging in archives and found this thread from 2010 onward with 
various
patches and rants.
Not sure how I missed that before.

Should we have another run at this I wonder?

Bye,
Oleg--
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/4] ARM: at91: sama5d4ek: enable audio support

[Bo Shen]

This patch set enable audio support on sama5d4ek.
It depends the patch [1] (ASoC: atmel-pcm-dma: won't check direction
when configure dma)
[1] https://patchwork.kernel.org/patch/5759441/


Bo Shen (4):
  ARM: at91: dt: sama5d4: add ssc nodes
  ARM: at91: dt: sama5d4ek: enable ssc0
  ARM: at91: dt: sama5d4ek: add and enable wm8904
  ARM: at91: dt: sama5d4ek: enable audio

 arch/arm/boot/dts/at91-sama5d4ek.dts | 31 
 arch/arm/boot/dts/sama5d4.dtsi   | 70 
 2 files changed, 101 insertions(+)

-- 
2.3.0.rc0

--
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/4] ARM: at91: dt: sama5d4ek: enable ssc0

[Bo Shen]

Enable SSC0 node, which will be used for audio.

Signed-off-by: Bo Shen 
---

 arch/arm/boot/dts/at91-sama5d4ek.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d4ek.dts 
b/arch/arm/boot/dts/at91-sama5d4ek.dts
index 9198b71..32e9a9a 100644
--- a/arch/arm/boot/dts/at91-sama5d4ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d4ek.dts
@@ -115,6 +115,10 @@
};
};
 
+   ssc0: ssc@f8008000 {
+   status = "okay";
+   };
+
spi0: spi@f801 {
cs-gpios = <&pioC 3 0>, <0>, <0>, <0>;
status = "okay";
-- 
2.3.0.rc0

--
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/4] ARM: at91: dt: sama5d4: add ssc nodes

[Bo Shen]

Add SSC 0 and 1 nodes.

Signed-off-by: Bo Shen 
---

 arch/arm/boot/dts/sama5d4.dtsi | 70 ++
 1 file changed, 70 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index b94995d..0b3e5f4 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -66,6 +66,8 @@
tcb0 = &tcb0;
tcb1 = &tcb1;
i2c2 = &i2c2;
+   ssc0 = &ssc0;
+   ssc1 = &ssc1;
};
cpus {
#address-cells = <1>;
@@ -793,6 +795,24 @@
clock-names = "mci_clk";
};
 
+   ssc0: ssc@f8008000 {
+   compatible = "atmel,at91sam9g45-ssc";
+   reg = <0xf8008000 0x4000>;
+   interrupts = <48 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+   dmas = <&dma1
+   (AT91_XDMAC_DT_MEM_IF(0) | 
AT91_XDMAC_DT_PER_IF(1)
+   | AT91_XDMAC_DT_PERID(26))>,
+  <&dma1
+   (AT91_XDMAC_DT_MEM_IF(0) | 
AT91_XDMAC_DT_PER_IF(1)
+   | AT91_XDMAC_DT_PERID(27))>;
+   dma-names = "tx", "rx";
+   clocks = <&ssc0_clk>;
+   clock-names = "pclk";
+   status = "disabled";
+   };
+
spi0: spi@f801 {
#address-cells = <1>;
#size-cells = <0>;
@@ -941,6 +961,24 @@
status = "disabled";
};
 
+   ssc1: ssc@fc014000 {
+   compatible = "atmel,at91sam9g45-ssc";
+   reg = <0xfc014000 0x4000>;
+   interrupts = <49 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
+   dmas = <&dma1
+   (AT91_XDMAC_DT_MEM_IF(0) | 
AT91_XDMAC_DT_PER_IF(1)
+   | AT91_XDMAC_DT_PERID(28))>,
+  <&dma1
+   (AT91_XDMAC_DT_MEM_IF(0) | 
AT91_XDMAC_DT_PER_IF(1)
+   | AT91_XDMAC_DT_PERID(29))>;
+   dma-names = "tx", "rx";
+   clocks = <&ssc1_clk>;
+   clock-names = "pclk";
+   status = "disabled";
+   };
+
tcb1: timer@fc02 {
compatible = "atmel,at91sam9x5-tcb";
reg = <0xfc02 0x100>;
@@ -1295,6 +1333,38 @@
atmel,pins = ; /* conflicts with A0/NBS0, MCI0_CDB */
};
};
+
+   ssc0 {
+   pinctrl_ssc0_tx: ssc0_tx {
+   atmel,pins =
+   ; /* PB28 periph B TD0 */
+   };
+
+   pinctrl_ssc0_rx: ssc0_rx {
+   atmel,pins =
+   ; /* PB29 periph B RD0 */
+   };
+   };
+
+   ssc1 {
+   pinctrl_ssc1_tx: ssc1_tx {
+   atmel,pins =
+   ; /* PC21 periph B TD1 */
+   };
+
+   pinctrl_ssc1_rx: ssc1_rx {
+   atmel,pins =
+   ; /* PC23 periph B RD1 */
+   };
+   };
};
 
aic: interrupt-controller@fc06e000 {
-- 
2.3.0.rc0

--
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/4] ARM: at91: dt: sama5d4ek: enable audio

[Bo Shen]

Enable audio support for sama5d4ek board.

Signed-off-by: Bo Shen 
---

 arch/arm/boot/dts/at91-sama5d4ek.dts | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d4ek.dts 
b/arch/arm/boot/dts/at91-sama5d4ek.dts
index 7f47d92..0df5f1b 100644
--- a/arch/arm/boot/dts/at91-sama5d4ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d4ek.dts
@@ -190,6 +190,10 @@
atmel,pins =
; /* PE13 gpio */
};
+   pinctrl_pck2_as_audio_mck: 
pck2_as_audio_mck {
+   atmel,pins =
+   ;
+   };
};
};
};
@@ -268,4 +272,20 @@
gpio-key,wakeup;
};
};
+
+   sound {
+   compatible = "atmel,asoc-wm8904";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_pck2_as_audio_mck>;
+
+   atmel,model = "wm8904 @ SAMA5D4EK";
+   atmel,audio-routing =
+   "Headphone Jack", "HPOUTL",
+   "Headphone Jack", "HPOUTR",
+   "IN1L", "Line In Jack",
+   "IN1R", "Line In Jack";
+
+   atmel,ssc-controller = <&ssc0>;
+   atmel,audio-codec = <&wm8904>;
+   };
 };
-- 
2.3.0.rc0

--
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/4] ARM: at91: dt: sama5d4ek: add and enable wm8904

[Bo Shen]

Add wm8904 codec node and enable it.

Signed-off-by: Bo Shen 
---

 arch/arm/boot/dts/at91-sama5d4ek.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d4ek.dts 
b/arch/arm/boot/dts/at91-sama5d4ek.dts
index 32e9a9a..7f47d92 100644
--- a/arch/arm/boot/dts/at91-sama5d4ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d4ek.dts
@@ -131,6 +131,13 @@
 
i2c0: i2c@f8014000 {
status = "okay";
+
+   wm8904: codec@1a {
+   compatible = "wlf,wm8904";
+   reg = <0x1a>;
+   clocks = <&pck2>;
+   clock-names = "mclk";
+   };
};
 
macb0: ethernet@f802 {
-- 
2.3.0.rc0

--
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] hyperv: Fix the error processing in netvsc_send()

[Jason Wang]

On Fri, Jan 30, 2015 at 11:05 PM, Haiyang Zhang 
 wrote:




 -Original Message-
 From: Jason Wang [mailto:jasow...@redhat.com]
 Sent: Friday, January 30, 2015 5:25 AM
 > + if (ret != 0) {
 > + if (section_index != NETVSC_INVALID_INDEX)
 > + netvsc_free_send_slot(net_device, section_index);
 
 What if ret is -EINVAL or -ENOSPC? Looks like we need free the skb 
in

 this case also.


In these cases, skb is freed in netvsc_start_xmit().



 >
 > + } else if (skb) {
 > + dev_kfree_skb_any(skb);
 
 The caller - netvsc_start_xmit() do this also, may be handle this in
 caller is better since netvsc_start_xmit() is the only user that 
tries

 to send a skb?


When the packet is sent out normally, we frees it in netvsc_send() if 
it's
copied to send-buffer. The free is done in netvsc_send(), because the 
copy
is also in this function. If it's not copied, it will be freed in 
another

function -- netvsc_xmit_completion().

netvsc_start_xmit() only does free skb in error case.


Ok.



 btw, I find during netvsc_start_xmit(), ret was change to -ENOSPC 
when

 queue_sends[q_idx] < 1. But non of the caller check -ENOSPC in fact?


In this case, we don't request re-send, so set ret to a value other 
than
-EAGAIN. 


Why not? We have available slots for it to be sent now. Dropping the 
packet in this case may cause out of order sending.

It's handled in the same way as errors != -EAGAIN, so we don't
need to check this value specifically.


Thanks

--
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] ASoC: atmel-pcm-dma: won't check direction when configure dma

[Bo Shen]

As DMA framework request DMA using direction only in prep_slave
function, (The At91 xdma driver has adapted to this request).
So won't check direction when do DMA configuration.

Signed-off-by: Bo Shen 
---

 sound/soc/atmel/atmel-pcm-dma.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/sound/soc/atmel/atmel-pcm-dma.c b/sound/soc/atmel/atmel-pcm-dma.c
index 33fb3bb..b8e7bad 100644
--- a/sound/soc/atmel/atmel-pcm-dma.c
+++ b/sound/soc/atmel/atmel-pcm-dma.c
@@ -105,13 +105,11 @@ static int atmel_pcm_configure_dma(struct 
snd_pcm_substream *substream,
return ret;
}
 
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   slave_config->dst_addr = ssc->phybase + SSC_THR;
-   slave_config->dst_maxburst = 1;
-   } else {
-   slave_config->src_addr = ssc->phybase + SSC_RHR;
-   slave_config->src_maxburst = 1;
-   }
+   slave_config->dst_addr = ssc->phybase + SSC_THR;
+   slave_config->dst_maxburst = 1;
+
+   slave_config->src_addr = ssc->phybase + SSC_RHR;
+   slave_config->src_maxburst = 1;
 
prtd->dma_intr_handler = atmel_pcm_dma_irq;
 
-- 
2.3.0.rc0

--
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] cpuidle/powernv: Read target_residency value of idle states from DT if available

[Michael Ellerman]

On Mon, 2015-02-02 at 10:40 +0530, Preeti U Murthy wrote:
> The device tree now exposes the residency values for different idle states. 
> Read
> these values instead of calculating residency from the latency values. The 
> values
> exposed in the DT are validated for optimal power efficiency. However to 
> maintain
> compatibility with the older firmware code which does not expose residency
> values, use default values as a fallback mechanism. While at it, use better
> APIs to parse the powermgmt device tree node so as to avoid endianness
> transformation.
> 
> Signed-off-by: Preeti U Murthy 
> ---
> Changes from V2: https://lkml.org/lkml/2015/1/27/1054
> 1. Used APIs to eliminate endianness transformation

Hi Preeti,

I thought I was pretty clear when I said you should do that as a follow-up
patch.

This is now doing too many things, it's not a single logical change, and it's
touching code in arch/powerpc and the driver. Which means neither I nor Rafael
can easily merge it.  

So please go back to the v2 you had. And then do the 
of_property_count_u32_elems()
changes as separate patches.

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/

Re: [PATCH target] vhost/scsi: vhost_skip_iovec_bytes() can be static

[Fam Zheng]

On Mon, 02/02 14:25, kbuild test robot wrote:
> drivers/vhost/scsi.c:1081:5: sparse: symbol 'vhost_skip_iovec_bytes' was not 
> declared. Should it be static?
> 
> Signed-off-by: Fengguang Wu 
> ---
>  scsi.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index d888bd9..8ac003f 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -1078,7 +1078,7 @@ vhost_scsi_send_bad_target(struct vhost_scsi *vs,
>   pr_err("Faulted on virtio_scsi_cmd_resp\n");
>  }
>  
> -int vhost_skip_iovec_bytes(size_t bytes, int max_niov,
> +static int vhost_skip_iovec_bytes(size_t bytes, int max_niov,
>  struct iovec *iov_in, size_t off_in,
>  struct iovec **iov_out, size_t *off_out)

Probably keep the parameter list lines aligned?

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

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

[Stephen Rothwell]

Hi Nicholas,

Today's linux-next merge of the target-updates tree got a conflict in
drivers/vhost/scsi.c between commit 46243860806b ("vhost-scsi: Add
missing virtio-scsi -> TCM attribute conversion") from Linus' tree and
commit 6df22d68ecaf ("vhost/scsi: Add ANY_LAYOUT prerequisites") from
the target-updates tree.

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

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

diff --cc drivers/vhost/scsi.c
index d695b1673ae5,a773af3550ee..
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@@ -911,23 -911,111 +911,128 @@@ vhost_scsi_map_iov_to_prot(struct tcm_v
return 0;
  }
  
 +static int vhost_scsi_to_tcm_attr(int attr)
 +{
 +  switch (attr) {
 +  case VIRTIO_SCSI_S_SIMPLE:
 +  return TCM_SIMPLE_TAG;
 +  case VIRTIO_SCSI_S_ORDERED:
 +  return TCM_ORDERED_TAG;
 +  case VIRTIO_SCSI_S_HEAD:
 +  return TCM_HEAD_TAG;
 +  case VIRTIO_SCSI_S_ACA:
 +  return TCM_ACA_TAG;
 +  default:
 +  break;
 +  }
 +  return TCM_SIMPLE_TAG;
 +}
 +
+ static int
+ vhost_scsi_calc_sgls(struct iovec *iov, size_t off, size_t bytes,
+int *niov, int max_sgls)
+ {
+   size_t tmp = 0;
+   int sgl_count = 0;
+ 
+   *niov = 0;
+ 
+   while (tmp < bytes) {
+   void __user *base = iov[*niov].iov_base + off;
+   size_t len = iov[(*niov)++].iov_len - off;
+ 
+   sgl_count += iov_num_pages(base, len);
+   tmp += min(len, bytes);
+   off = 0;
+   }
+   if (sgl_count > max_sgls) {
+   pr_err("%s: requested sgl_count: %d exceeds pre-allocated"
+  " max_sgls: %d\n", __func__, sgl_count, max_sgls);
+   return -ENOBUFS;
+   }
+   return sgl_count;
+ }
+ 
+ static int
+ vhost_scsi_iov_to_sgl(struct tcm_vhost_cmd *cmd, bool write,
+ struct iovec *iov, size_t iov_off, int niov,
+ struct scatterlist *sg, int sg_count)
+ {
+   int i, ret;
+ 
+   for (i = 0; i < niov; i++) {
+   void __user *base = iov[i].iov_base + iov_off;
+   size_t len = iov[i].iov_len - iov_off;
+ 
+   ret = vhost_scsi_map_to_sgl(cmd, base, len, sg, write);
+   if (ret < 0) {
+   for (i = 0; i < sg_count; i++) {
+   struct page *page = sg_page(&sg[i]);
+   if (page)
+   put_page(page);
+   }
+   return ret;
+   }
+   sg += ret;
+   iov_off = 0;
+   }
+   return 0;
+ }
+ 
+ static int
+ vhost_scsi_mapal(struct tcm_vhost_cmd *cmd,
+size_t prot_bytes, struct iovec *prot_iov, size_t prot_off,
+size_t data_bytes, struct iovec *data_iov, size_t data_off)
+ {
+   int data_sgl_count = 0, niov, ret;
+   bool write = (cmd->tvc_data_direction == DMA_FROM_DEVICE);
+ 
+   if (prot_bytes) {
+   int prot_sgl_count;
+ 
+   if (!prot_iov) {
+   pr_err("%s: prot_iov is NULL, but prot_bytes: %zu"
+  "present\n", __func__, prot_bytes);
+   return -EINVAL;
+   }
+   prot_sgl_count = vhost_scsi_calc_sgls(prot_iov, prot_off,
+ prot_bytes, &niov,
+ 
TCM_VHOST_PREALLOC_PROT_SGLS);
+   if (prot_sgl_count < 0)
+   return prot_sgl_count;
+ 
+   sg_init_table(cmd->tvc_prot_sgl, prot_sgl_count);
+   cmd->tvc_prot_sgl_count = prot_sgl_count;
+   pr_debug("%s prot_sg %p prot_sgl_count %u\n", __func__,
+cmd->tvc_prot_sgl, cmd->tvc_prot_sgl_count);
+ 
+   ret = vhost_scsi_iov_to_sgl(cmd, write, prot_iov, prot_off,
+   niov, cmd->tvc_prot_sgl,
+   prot_sgl_count);
+   if (ret < 0) {
+   cmd->tvc_prot_sgl_count = 0;
+   return ret;
+   }
+   }
+   if (!data_iov) {
+   pr_err("%s: data_iov is NULL, but data_bytes: %zu present\n",
+  __func__, data_bytes);
+   return -EINVAL;
+   }
+   data_sgl_count = vhost_scsi_calc_sgls(data_iov, data_off, data_bytes,
+ &niov, TCM_VHOST_PREALLOC_SGLS);
+   if (data_sgl_count < 0)
+   return data_sgl_count;
+ 
+   sg_init_table(cmd->tvc_sgl, data_sgl_count);
+   cmd->tvc_sgl_count = data_sgl_count;
+   pr_debug("%s data_sg %p data_sgl_count %u\n", __func__,
+ cmd->tvc_sgl, cmd->tvc_sgl_c

Re: [RFC][PATCH 2/3] perf: Add a bit of paranoia

[Vince Weaver]

On Thu, 29 Jan 2015, Peter Zijlstra wrote:

> That said, it does need to do that sibling first leaders later install
> order too. So I've put the below on top.

so I've lost track of exactly which patches I should be running (do I need 
to apply both of the additional patches?)

Meanwhile my haswell was still fuzzing away (without those two 
updated patches) until it triggered the below and crashed.

[407484.309136] [ cut here ]
[407484.314590] WARNING: CPU: 3 PID: 27209 at kernel/watchdog.c:290 
watchdog_overflow_callback+0x92/0xc0()
[407484.325090] Watchdog detected hard LOCKUP on cpu 3
[407484.330093] Modules linked in: btrfs xor raid6_pq ntfs vfat msdos fat 
dm_mod fuse x86_pkg_temp_thermal intel_powerclamp intel_rapl iosf_mbi coretemp 
kvm crct10dif_pclmul snd_hda_codec_realtek snd_hda_codec_hdmi 
snd_hda_codec_generic crc32_pclmul snd_hda_intel ghash_clmulni_intel 
snd_hda_controller aesni_intel snd_hda_codec aes_x86_64 snd_hwdep lrw gf128mul 
snd_pcm ppdev glue_helper xhci_pci mei_me iTCO_wdt iTCO_vendor_support i915 
snd_timer drm_kms_helper snd drm ablk_helper lpc_ich mfd_core evdev pcspkr 
parport_pc psmouse cryptd soundcore i2c_i801 serio_raw parport xhci_hcd mei wmi 
tpm_tis tpm video battery button processor i2c_algo_bit sg sr_mod sd_mod cdrom 
ahci libahci e1000e ehci_pci libata ptp ehci_hcd crc32c_intel usbcore scsi_mod 
usb_common pps_core thermal fan thermal_sys
[407484.408496] CPU: 3 PID: 27209 Comm: perf_fuzzer Tainted: GW  
3.19.0-rc6+ #126
[407484.417914] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 
01/26/2014
[407484.426497]  81a3d3da 88011eac5aa0 816b6761 

[407484.435161]  88011eac5af0 88011eac5ae0 8106dcda 
88011eac5b00
[407484.443900]  8801195f9800 0001 88011eac5c40 
88011eac5ef8
[407484.452588] Call Trace:
[407484.455862][] dump_stack+0x45/0x57
[407484.462741]  [] warn_slowpath_common+0x8a/0xc0
[407484.469851]  [] warn_slowpath_fmt+0x46/0x50
[407484.476743]  [] ? native_sched_clock+0x2a/0x90
[407484.483888]  [] ? native_sched_clock+0x2a/0x90
[407484.490999]  [] watchdog_overflow_callback+0x92/0xc0
[407484.498672]  [] __perf_event_overflow+0x91/0x270
[407484.505984]  [] ? x86_perf_event_set_period+0xca/0x170
[407484.513834]  [] perf_event_overflow+0x19/0x20
[407484.520812]  [] intel_pmu_handle_irq+0x1ba/0x3a0
[407484.528119]  [] perf_event_nmi_handler+0x2b/0x50
[407484.535402]  [] nmi_handle+0xa0/0x150
[407484.541701]  [] ? nmi_handle+0x5/0x150
[407484.548069]  [] default_do_nmi+0x4a/0x140
[407484.554692]  [] do_nmi+0x98/0xe0
[407484.560517]  [] end_repeat_nmi+0x1e/0x2e
[407484.567054]  [] ? perf_get_regs_user+0xbf/0x190
[407484.574256]  [] ? perf_get_regs_user+0xbf/0x190
[407484.581431]  [] ? perf_get_regs_user+0xbf/0x190
[407484.588602]  <>[] 
perf_prepare_sample+0x2ec/0x3c0
[407484.597358]  [] __perf_event_overflow+0x10e/0x270
[407484.604708]  [] ? __perf_event_overflow+0xd9/0x270
[407484.612215]  [] ? perf_tp_event+0xc4/0x210
[407484.619000]  [] ? __perf_sw_event+0x72/0x1f0
[407484.625937]  [] ? perf_swevent_overflow+0xa9/0xe0
[407484.633287]  [] perf_swevent_overflow+0xa9/0xe0
[407484.640467]  [] perf_swevent_event+0x67/0x90
[407484.647343]  [] perf_tp_event+0xc4/0x210
[407484.653923]  [] ? lock_acquire+0x119/0x130
[407484.660606]  [] ? perf_trace_lock_acquire+0x146/0x180
[407484.668332]  [] ? __lock_acquire.isra.31+0x3af/0xfe0
[407484.675962]  [] perf_trace_lock_acquire+0x146/0x180
[407484.683490]  [] ? lock_acquire+0x119/0x130
[407484.690211]  [] lock_acquire+0x119/0x130
[407484.696750]  [] ? perf_event_wakeup+0x5/0xf0
[407484.703640]  [] ? kill_fasync+0xf/0xf0
[407484.710008]  [] perf_event_wakeup+0x38/0xf0
[407484.716798]  [] ? perf_event_wakeup+0x5/0xf0
[407484.723696]  [] perf_pending_event+0x33/0x60
[407484.730570]  [] irq_work_run_list+0x4c/0x80
[407484.737392]  [] irq_work_run+0x18/0x40
[407484.743765]  [] smp_trace_irq_work_interrupt+0x3f/0xc0
[407484.751579]  [] trace_irq_work_interrupt+0x6d/0x80
[407484.759046][] ? lock_acquire+0xbd/0x130
[407484.766380]  [] ? SyS_fcntl+0x5b2/0x650
[407484.772786]  [] _raw_spin_lock+0x31/0x40
[407484.779321]  [] ? SyS_fcntl+0x5b2/0x650
[407484.785813]  [] SyS_fcntl+0x5b2/0x650
[407484.792109]  [] system_call_fastpath+0x16/0x1b
[407484.799195] ---[ end trace 55752a03ec8ab979 ]---
[407490.307881] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected 
by 4, t=5252 jiffies, g=36308737, c=36308736, q=207)
[407490.320908] Task dump for CPU 3:
[407490.325104] perf_fuzzer R  running task0 27209   2304 0x0008
[407490.333439]  8115c837 8800c4293cc8 8115c924 
8824
[407490.342163]  0001 8800c4293b80 8800c4293d90 
8800ceb81000
[407490.350899]  e8cca880 8800c4293b10 8115c799 
8800ceb81000
[407490.359619] Call Trace:
[407490.362932]  [] ? perf_swevent_event+0x67/0x90
[407490.370033]  [] ? perf_tp_event+0

[target:for-next 16/21] drivers/vhost/scsi.c:1081:5: sparse: symbol 'vhost_skip_iovec_bytes' was not declared. Should it be static?

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git 
for-next
head:   2936f1d4f3e8247bd519feba7892371d5e4c6603
commit: 105acf608f25d5e0d9fef669299a5438b7b114ee [16/21] vhost/scsi: Add 
ANY_LAYOUT vhost_skip_iovec_bytes helper
reproduce:
  # apt-get install sparse
  git checkout 105acf608f25d5e0d9fef669299a5438b7b114ee
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/vhost/scsi.c:1081:5: sparse: symbol 'vhost_skip_iovec_bytes' was not 
>> declared. Should it be static?
   drivers/vhost/scsi.c:969:1: warning: 'vhost_scsi_mapal' defined but not used 
[-Wunused-function]
vhost_scsi_mapal(struct tcm_vhost_cmd *cmd, int max_niov,
^

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
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 target] vhost/scsi: vhost_skip_iovec_bytes() can be static

[kbuild test robot]

drivers/vhost/scsi.c:1081:5: sparse: symbol 'vhost_skip_iovec_bytes' was not 
declared. Should it be static?

Signed-off-by: Fengguang Wu 
---
 scsi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index d888bd9..8ac003f 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1078,7 +1078,7 @@ vhost_scsi_send_bad_target(struct vhost_scsi *vs,
pr_err("Faulted on virtio_scsi_cmd_resp\n");
 }
 
-int vhost_skip_iovec_bytes(size_t bytes, int max_niov,
+static int vhost_skip_iovec_bytes(size_t bytes, int max_niov,
   struct iovec *iov_in, size_t off_in,
   struct iovec **iov_out, size_t *off_out)
 {
--
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/

LOL

[Tom]

Hahahaha! Is that you :)


http://tinyurl.com/kz7tdon








No more such info? Simply answer 
--
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 v1 2/2] zram: remove init_lock in zram_make_request

[Minchan Kim]

On Mon, Feb 02, 2015 at 02:59:23PM +0900, Sergey Senozhatsky wrote:
> On (02/02/15 12:41), Minchan Kim wrote:
> > > If we use zram as block device itself(not a fs or swap) and open the
> > > block device as !FMODE_EXCL, bd_holders will be void.
> > > 
> > > Another topic: As I didn't see enough fs/block_dev.c bd_holders in zram
> > > would be mess. I guess we need to study hotplug of device and implement
> > > it for zram reset rather than strange own konb. It should go TODO. :(
> > 
> > Actually, I thought bd_mutex use from custom driver was terrible idea
> > so we should walk around with device hotplug but as I look through
> > another drivers, they have used the lock for a long time.
> > Maybe it's okay to use it in zram?
> > If so, Ganesh's patch is no problem to me although I didn't' review it in 
> > detail.
> > One thing I want to point out is that it would be better to change 
> > bd_holders
> > with bd_openers to filter out because dd test opens block device as !EXCL
> > so bd_holders will be void.
> > 
> > What do you think about it?
> > 
> 
> a quick idea:
> can we additionally move all bd flush and put work after 
> zram_reset_device(zram, true)
> and, perhaps, replace ->bd_holders with something else?
> 
> zram_reset_device() will not return until we have active IOs, pending IOs 
> will be
> invalidated by ->disksize != 0.

Sorry, I don't get it. Could you describe what you are concerning about active 
I/O?
My concern is just race bd_holder/bd_openers and bd_holders of zram check.
I don't think any simple solution without bd_mutex.
If we can close the race, anything could be a solution.
If we close the race, we should return -EBUSY if anyone is opening the zram 
device
so bd_openers check would be better than bd_holders.

> 
>   -ss

-- 
Kind regards,
Minchan Kim
--
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] locking/rtmutex: Optimize setting task running after being blocked

[Davidlohr Bueso]

We explicitly mark the task running after returning from
a __rt_mutex_slowlock() call, which does the actual sleeping
via wait-wake-trylocking. As such, this patch does two things:

(1) refactors the code so that setting current to TASK_RUNNING
is done by __rt_mutex_slowlock(), and not by the callers. The
downside to this is that it becomes a bit unclear when at what
point we block. As such I've added a comment that the task
blocks when calling __rt_mutex_slowlock() so readers can figure
out when it is running again.

(2) relaxes setting current's state through __set_current_state(),
instead of it's more expensive barrier alternative. There was no
need for the implied barrier as we're obviously not planning on
blocking.

Signed-off-by: Davidlohr Bueso 
---
 kernel/locking/rtmutex.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 7c98873..3059bc2f 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1130,6 +1130,7 @@ __rt_mutex_slowlock(struct rt_mutex *lock, int state,
set_current_state(state);
}
 
+   __set_current_state(TASK_RUNNING);
return ret;
 }
 
@@ -1188,10 +1189,9 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
ret = task_blocks_on_rt_mutex(lock, &waiter, current, chwalk);
 
if (likely(!ret))
+   /* sleep on the mutex */
ret = __rt_mutex_slowlock(lock, state, timeout, &waiter);
 
-   set_current_state(TASK_RUNNING);
-
if (unlikely(ret)) {
remove_waiter(lock, &waiter);
rt_mutex_handle_deadlock(ret, chwalk, &waiter);
@@ -1626,10 +1626,9 @@ int rt_mutex_finish_proxy_lock(struct rt_mutex *lock,
 
set_current_state(TASK_INTERRUPTIBLE);
 
+   /* sleep on the mutex */
ret = __rt_mutex_slowlock(lock, TASK_INTERRUPTIBLE, to, waiter);
 
-   set_current_state(TASK_RUNNING);
-
if (unlikely(ret))
remove_waiter(lock, waiter);
 
-- 
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: __might_sleep() warnings on v3.19-rc6

[NeilBrown]

On Sun, 1 Feb 2015 21:08:12 -0800 Linus Torvalds
 wrote:

> On Sun, Feb 1, 2015 at 3:03 PM, NeilBrown  wrote:
> >
> > I guess I could
> >   __set_current_state(TASK_RUNNING);
> > somewhere to defeat the warning, and add a comment explaining why.
> >
> > Would that be a good thing?
> 
> Use "sched_annotate_sleep()" instead, but yes, add a comment about why it's 
> ok.
> 
> Linus
> --
> 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/

OK - following patch is queued to appear in a pull request tomorrow  (I hope).

Thanks,
NeilBrown

From: NeilBrown 
Date: Mon, 2 Feb 2015 17:08:03 +1100
Subject: [PATCH] md/bitmap: fix a might_sleep() warning.

commit 8eb23b9f35aae413140d3fda766a98092c21e9b0
sched: Debug nested sleeps

causes false-positive warnings in RAID5 code.

This annotation removes them and adds a comment
explaining why there is no real problem.

Reported-by: Fengguang Wu 
Signed-off-by: NeilBrown 

diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index da3604e73e8a..1695ee5f3ffc 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -72,6 +72,19 @@ __acquires(bitmap->lock)
/* this page has not been allocated yet */
 
spin_unlock_irq(&bitmap->lock);
+   /* It is possible that this is being called inside a
+* prepare_to_wait/finish_wait loop from raid5c:make_request().
+* In general it is not permitted to sleep in that context as it
+* can cause the loop to spin freely.
+* That doesn't apply here as we can only reach this point
+* once with any loop.
+* When this function completes, either bp[page].map or
+* bp[page].hijacked.  In either case, this function will
+* abort before getting to this point again.  So there is
+* no risk of a free-spin, and so it is safe to assert
+* that sleeping here is allowed.
+*/
+   sched_annotate_sleep();
mappage = kzalloc(PAGE_SIZE, GFP_NOIO);
spin_lock_irq(&bitmap->lock);
 


pgp6HISJ6zhqz.pgp
Description: OpenPGP digital signature

Re: [PATCH V3] cpuidle/powernv: Read target_residency value of idle states from DT if available

[Stewart Smith]

Preeti U Murthy  writes:
> The device tree now exposes the residency values for different idle states. 
> Read
> these values instead of calculating residency from the latency values. The 
> values
> exposed in the DT are validated for optimal power efficiency. However to 
> maintain
> compatibility with the older firmware code which does not expose residency
> values, use default values as a fallback mechanism. While at it, use better
> APIs to parse the powermgmt device tree node so as to avoid endianness
> transformation.
>
> Signed-off-by: Preeti U Murthy 

Same acked-by as before, from perspective of "I merged the firmware side
of things" and things look godo in relation to firmware PoV.

Acked-by: Stewart Smith 

--
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 v1 2/2] zram: remove init_lock in zram_make_request

[Sergey Senozhatsky]

On (02/02/15 12:41), Minchan Kim wrote:
> > If we use zram as block device itself(not a fs or swap) and open the
> > block device as !FMODE_EXCL, bd_holders will be void.
> > 
> > Another topic: As I didn't see enough fs/block_dev.c bd_holders in zram
> > would be mess. I guess we need to study hotplug of device and implement
> > it for zram reset rather than strange own konb. It should go TODO. :(
> 
> Actually, I thought bd_mutex use from custom driver was terrible idea
> so we should walk around with device hotplug but as I look through
> another drivers, they have used the lock for a long time.
> Maybe it's okay to use it in zram?
> If so, Ganesh's patch is no problem to me although I didn't' review it in 
> detail.
> One thing I want to point out is that it would be better to change bd_holders
> with bd_openers to filter out because dd test opens block device as !EXCL
> so bd_holders will be void.
> 
> What do you think about it?
> 

a quick idea:
can we additionally move all bd flush and put work after 
zram_reset_device(zram, true)
and, perhaps, replace ->bd_holders with something else?

zram_reset_device() will not return until we have active IOs, pending IOs will 
be
invalidated by ->disksize != 0.

-ss
--
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: [GIT PULL] aio: fix sleeping while TASK_INTERRUPTIBLE

[Dave Chinner]

On Sun, Feb 01, 2015 at 09:36:52PM -0800, Linus Torvalds wrote:
> On Feb 1, 2015 9:29 PM, "Dave Chinner"  wrote:
> >
> > So what's the outcome here? I'm running v3.19-rc7 kernel and
> > xfstests::generic/036 is still tripping this warning from the aio
> > code:
> 
> So for the aio case, I suspect just adding a sched_annotate_sleep() is the
> solution. But considering that there are apparently some other cases of
> this warning that are nobody seems to bother fixing, it may just be that
> I'll have to disable the warning entirely for 3.19 (and then maybe
> re-enable it during the merge window and see if that makes anybody care
> again)

Simple enough - the patch below removes the warning from generic/036
for me.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com


aio: annotate aio_read_event_ring for sleep patterns

From: Dave Chinner 

Under CONFIG_DEBUG_ATOMIC_SLEEP=y, aio_read_event_ring() will throw
warnings like the following due to being called from wait_event
context:

 WARNING: CPU: 0 PID: 16006 at kernel/sched/core.c:7300 
__might_sleep+0x7f/0x90()
 do not call blocking ops when !TASK_RUNNING; state=1 set at 
[] prepare_to_wait_event+0x63/0x110
 Modules linked in:
 CPU: 0 PID: 16006 Comm: aio-dio-fcntl-r Not tainted 3.19.0-rc6-dgc+ #705
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  821c0372 88003c117cd8 81daf2bd d8d8
  88003c117d28 88003c117d18 8109beda 88003c117cf8
  821c115e 0061  7e4aa300
 Call Trace:
  [] dump_stack+0x4c/0x65
  [] warn_slowpath_common+0x8a/0xc0
  [] warn_slowpath_fmt+0x46/0x50
  [] ? prepare_to_wait_event+0x63/0x110
  [] ? prepare_to_wait_event+0x63/0x110
  [] __might_sleep+0x7f/0x90
  [] mutex_lock+0x24/0x45
  [] aio_read_events+0x4c/0x290
  [] read_events+0x1ec/0x220
  [] ? prepare_to_wait_event+0x110/0x110
  [] ? hrtimer_get_res+0x50/0x50
  [] SyS_io_getevents+0x4d/0xb0
  [] system_call_fastpath+0x12/0x17
 ---[ end trace bde69eaf655a4fea ]---

There is not actually a bug here, so annotate the code to tell the
debug logic that everything is just fine and not to fire a false
positive.

Signed-off-by: Dave Chinner 
---
 fs/aio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/aio.c b/fs/aio.c
index 1b7893e..3176d6c 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1140,6 +1140,7 @@ static long aio_read_events_ring(struct kioctx *ctx,
long ret = 0;
int copy_ret;
 
+   sched_annotate_sleep();
mutex_lock(&ctx->ring_lock);
 
/* Access to ->ring_pages here is protected by ctx->ring_lock. */
--
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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Hi Russell,

On 30 January 2015 at 00:56, Russell King - ARM Linux
 wrote:
> On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
>> Quite possibly for some of these edge some of cases, some of the
>> dma-buf exporters are going to need to get more clever (ie. hand off
>> different scatterlists to different clients).  Although I think by far
>> the two common cases will be "I can support anything via an iommu/mmu"
>> and "I need phys contig".
>>
>> But that isn't an issue w/ dma-buf itself, so much as it is an issue
>> w/ drivers.  I guess there would be more interest in fixing up drivers
>> when actual hw comes along that needs it..
>
> However, validating the attachments is the business of dma-buf.  This
> is actual infrastructure, which should ensure some kind of sanity such
> as the issues I've raised.
>
> The whole "we can push it onto our users" is really on - what that
> results in is the users ignoring most of the requirements and just doing
> their own thing, which ultimately ends up with the whole thing turning
> into a disgusting mess - one which becomes very difficult to fix later.
>
> Now, if we're going to do the "more clever" thing you mention above,
> that rather negates the point of this two-part patch set, which is to
> provide the union of the DMA capabilities of all users.  A union in
> that case is no longer sane as we'd be tailoring the SG lists to each
> user.
>
> If we aren't going to do the "more clever" thing, then yes, we need this
> code to calculate that union, but we _also_ need it to do sanity checking
> right from the start, and refuse conditions which ultimately break the
> ability to make use of that union - in other words, when the union of
> the DMA capabilities means that the dmabuf can't be represented.
>
> Unless we do that, we'll just end up with random drivers interpreting
> what they want from the DMA capabilities, and we'll have some drivers
> exporting (eg) scatterlists which satisfy the maximum byte size of an
> element, but ignoring the maximum number of entries or vice versa, and
> that'll most probably hide the case of "too small a union".
>
I agree, and I'll add the check for
max_segment_size * max_segment_count < dmabuf->size
and resend; will that be alright with you?

> It really doesn't make sense to do both either: that route is even more
> madness, because we'll end up with two classes of drivers - those which
> use the union approach, and those which don't.
>
> The KISS principle applies here.
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.


Best regards,
~Sumit.
--
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] tty: serial: Add 8250 earlycon to support noinit option

[Peter Hurley]

On 02/02/2015 12:33 AM, Eddie Huang wrote:
> Hi Peter,
> 
> On Sun, 2015-02-01 at 21:24 -0800, Greg Kroah-Hartman wrote:
>> On Mon, Feb 02, 2015 at 12:15:31AM -0500, Peter Hurley wrote:
>>> On 02/01/2015 11:28 PM, Greg Kroah-Hartman wrote:
 On Sun, Feb 01, 2015 at 10:45:12PM -0500, Peter Hurley wrote:
> On 02/01/2015 10:16 PM, Eddie Huang wrote:
>>>
> I'll respin proper patches on top of Greg's tty-testing branch with 
> reverts
> for the noinit options. I noticed that one of the noinit patches actually
> has the linkage for the mtk earlycon, so I'll be sure to preserve that.

 I can just drop the patches in the tty-testing branch, that's what it is
 there for :)

 Just let me know the specific patches and I will do so, thanks.
>>>
>>> Well that pretty much means dropping the 3 patches that add earlycon to
>>> 8250_mtk and then applying my patch (needs fixed to apply cleanly, which
>>> I can do) and then applying a fixed-up replacement patch to add earlycon
>>> to 8250_mtk (which I can also supply).
>>>
>>> Is that the way you want to go?
>>
>> Sounds good to me, send your patch, and I'll fix it all up tomorrow.
>>
>> thanks,
>>
>> greg k-h
> 
> Actually, your patch is a little different from my original idea.
> Although my use case only care about divisor now, but other hardware
> setting is still hard-code, not from parameter. In init_port()
> function:   
>   serial8250_early_out(port, UART_LCR, 0x3); /* 8n1 */
>   serial8250_early_out(port, UART_IER, 0);/* no interrupt */
>   serial8250_early_out(port, UART_FCR, 0); /* no fifo */
>   serial8250_early_out(port, UART_MCR, 0x3); /* DTR + RTS */
> 
> This is why I propose a new option "noinit".
> 
> After checking further, in my case, I found that your patch should be
> unnecessary because if skip baudrate, probe_baud() read DLL/DLM register
> and init_port() write the same DLL/DLM value back, no touch any high
> speed register, which means keep uart divisor setting as loader
> 
> Since I don't take "console=uart,mmio32,,noinit" into
> consideration, it is good to drop my patches in the tty-testing branch.
> For my case, I can send another series without noinit, just 8250_mtk.c
> and its linkage modification in 8250_early.c

Ok.

Greg,

The patches to drop from tty-testing are:
* 405017d Document: Modify 8250 earlycon kernel parameters
* 0dff3a4 tty: serial: 8250_mtk: Add earlycon
* b829735 tty: serial: Add 8250 earlycon to support noinit option

Regards,
Peter Hurley
--
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 2/2] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Hi Eduardo,

On Sun, Feb 1, 2015 at 12:54 AM, Eduardo Valentin  wrote:
> On Tue, Jan 27, 2015 at 11:18:22AM +0530, Abhilash Kesavan wrote:
>> Add registers, bit fields and compatible strings for Exynos7 TMU
>> (Thermal Management Unit). Following are a few of the differences
>> in the Exynos7 TMU from earlier SoCs:
>> - 8 trigger levels
>> - Different bit offsets and more registers for the rising
>> and falling thresholds.
>> - New power down detection bit in the TMU_CONTROL register
>> which does not update the CURRENT_TEMP0 when tmu power down
>> is detected.
>> - Change in bit offset for the NEXT_DATA field of EMUL_CON
>> register. EMUL_CON register address has also changed.
>> - INTSTAT and INTCLEAR registers present in earlier SoCs
>> have been combined into one INTPEND register. The register
>> address for INTCLEAR and INTPEND is also different.
>> - Since there are 8 rising/falling interrupts as against
>> at most 4 in earlier SoCs the INTEN bit offsets are different.
>> - Multiple probe support which is handled by a TMU_CONTROL1
>> register (No support for this in the current patch).
>>
>> This patch adds special clock support required only for Exynos7. It
>> also updates the "code_to_temp" prototype as Exynos7 has 9 bit
>> code-temp mapping.
>>
>> Signed-off-by: Abhilash Kesavan 
>
> Applied to my -fixes branch. However, I had to amend it myself to make
> checkpatch.pl --strict silent. In this version, it still outputs:
> CHECK: Alignment should match open parenthesis
> #209: FILE: drivers/thermal/samsung/exynos_tmu.c:558:
> +   if (!data->temp_error1 ||
> +  (pdata->min_efuse_value > data->temp_error1) ||
>
> CHECK: multiple assignments should be avoided
> #366: FILE: drivers/thermal/samsung/exynos_tmu.c:882:
> +   tmu_intstat = tmu_intclear = EXYNOS7_TMU_REG_INTPEND;
>
> total: 0 errors, 0 warnings, 2 checks, 314 lines checked
>
> next, make sure you run checkpatch.pl --strict before sending patches.

Thanks for applying these patches. As this is adding support for a new
SoC, should it not be part of your -next branch ?
I generally just run checkpatch without the "strict" option. Will
ensure that I run it with "strict" in the future.

Regards,
Abhilash
>
>
>> ---
>> This patch set has been tested on linux next-20150123 with Eduardo's
>> thermal-next branch merged along with the arch-side exynos7 related
>> dts changes applied.
>>
>> Changes since v3:
>> Addressed comments from Lukasz Majewski:
>>   - Added more comments in the code setting the thresholds.
>>   - Split the documentation out into another patch.
>> Changes since v2:
>>   - Rebased on top of Lukasz' latest exynos tmu series (v4).
>>   - Added new exynos7 soc_type.
>> Changes since v1:
>>   - Rebased on top of Lukasz' latest exynos tmu series (v2).
>>   - Added sclk support to patch adding Exynos7 tmu support.
>>   Previously, it was a separate patch.
>>   - Used the SOC type to decide if sclk is present.
>>
>>  drivers/thermal/samsung/exynos_tmu.c |  204 
>> --
>>  drivers/thermal/samsung/exynos_tmu.h |1 +
>>  2 files changed, 197 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index 852e622..660ff69 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -119,6 +119,26 @@
>>  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
>>  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
>>
>> +/* Exynos7 specific registers */
>> +#define EXYNOS7_THD_TEMP_RISE7_6 0x50
>> +#define EXYNOS7_THD_TEMP_FALL7_6 0x60
>> +#define EXYNOS7_TMU_REG_INTEN0x110
>> +#define EXYNOS7_TMU_REG_INTPEND  0x118
>> +#define EXYNOS7_TMU_REG_EMUL_CON 0x160
>> +
>> +#define EXYNOS7_TMU_TEMP_MASK0x1ff
>> +#define EXYNOS7_PD_DET_EN_SHIFT  23
>> +#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0
>> +#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1
>> +#define EXYNOS7_TMU_INTEN_RISE2_SHIFT2
>> +#define EXYNOS7_TMU_INTEN_RISE3_SHIFT3
>> +#define EXYNOS7_TMU_INTEN_RISE4_SHIFT4
>> +#define EXYNOS7_TMU_INTEN_RISE5_SHIFT5
>> +#define EXYNOS7_TMU_INTEN_RISE6_SHIFT6
>> +#define EXYNOS7_TMU_INTEN_RISE7_SHIFT7
>> +#define EXYNOS7_EMUL_DATA_SHIFT  7
>> +#define EXYNOS7_EMUL_DATA_MASK   0x1ff
>> +
>>  #define MCELSIUS 1000
>>  /**
>>   * struct exynos_tmu_data : A structure to hold the private data of the TMU
>> @@ -133,6 +153,7 @@
>>   * @lock: lock to implement synchronization.
>>   * @clk: pointer to the clock structure.
>>   * @clk_sec: pointer to the clock structure

Re: [PATCH] gfs2: use __vmalloc GFP_NOFS for fs-related allocations.

[Dave Chinner]

On Sun, Feb 01, 2015 at 10:59:54PM -0500, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin 
> 
> leaf_dealloc uses vzalloc as a fallback to kzalloc(GFP_NOFS), so
> it clearly does not want any shrinker activity within the fs itself.
> convert vzalloc into __vmalloc(GFP_NOFS|__GFP_ZERO) to better achieve
> this goal.
> 
> Signed-off-by: Oleg Drokin 
> ---
>  fs/gfs2/dir.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
> index c5a34f0..6371192 100644
> --- a/fs/gfs2/dir.c
> +++ b/fs/gfs2/dir.c
> @@ -1896,7 +1896,8 @@ static int leaf_dealloc(struct gfs2_inode *dip, u32 
> index, u32 len,
>  
>   ht = kzalloc(size, GFP_NOFS | __GFP_NOWARN);
>   if (ht == NULL)
> - ht = vzalloc(size);
> + ht = __vmalloc(size, GFP_NOFS | __GFP_NOWARN | __GFP_ZERO,
> +PAGE_KERNEL);

That, in the end, won't help as vmalloc still uses GFP_KERNEL
allocations deep down in the PTE allocation code. See the hacks in
the DM and XFS code to work around this. i.e. go look for callers of
memalloc_noio_save().  It's ugly and grotesque, but we've got no
other way to limit reclaim context because the MM devs won't pass
the vmalloc gfp context down the stack to the PTE allocations

Cheers,

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

Re: [PATCH RFC v8 00/21] Add support for i.MX MIPI DSI DRM driver

[Liu Ying]

Correct Philipp's email address in the Cc list.

Liu Ying

On Mon, Feb 02, 2015 at 10:17:45AM +0800, Liu Ying wrote:
> Hi,
> 
> This version has been submitted for a while.
> And, it looks there is no comments on this version.
> Can the maintainers consider to take this?
> 
> Mike, any comments on patch 01/21?  It's a clock driver change.
> 
> Regards,
> Liu Ying
> 
> On Wed, Dec 31, 2014 at 04:23:18PM +0800, Liu Ying wrote:
> > Hi,
> > 
> > This version mainly fixes the Kconfig for the Synopsys DesignWare MIPI DSI
> > host controller bridge driver so that we may pass the allmodconfig for ARM.
> > Also, this version contains a minor change for the Himax HX8369A panel
> > driver to remove several unnecessary headers included.
> > 
> > The i.MX MIPI DSI is a Synopsys DesignWare MIPI DSI host controller IP.
> > This series adds support for a Synopsys DesignWare MIPI DSI host controller
> > DRM bridge driver and a i.MX MIPI DSI specific DRM driver.
> > Currently, the MIPI DSI drivers only support the burst with sync pulse mode.
> > 
> > This series also includes a DRM panel driver for the Truly TFT480800-16-E 
> > panel
> > which is driven by the Himax HX8369A driver IC.  The driver IC data sheet 
> > could
> > be found at [1].  As mentioned by the data sheet, the driver IC supports 
> > several
> > interface modes.  Currently, the DRM panel driver only supports the MIPI 
> > DSI video
> > mode.  New interface modes could be added later(perhaps, just like the way 
> > the DRM
> > simple panel driver supports both MIPI DSI interface panels and 
> > simple(parallel)
> > interface panels).
> > 
> > The MIPI DSI feature is tested on i.MX6Q SabreSD board and i.MX6DL SabreSD 
> > board.
> > The MIPI DSI display could be enabled directly on i.MX6Q SabreSD board after
> > applying this series, because the 26.4MHz pixel clock the panel requires 
> > could be
> > derived from the IPU HSP clock(264MHz) with an integer divider.
> > On i.MX6DL SabreSD board, we need to manually disable the LVDS and HDMI 
> > displays in
> > the device tree blob, since the i.MX6DL IPU HSP clock is 198MHz at present, 
> > which
> > makes the pixel clock share the PLL5 video clock source with the LVDS and 
> > HDMI,
> > thus, the panel cannot get the pixel clock rate it wants.
> > 
> > Patch 01/21 is needed to get a precise pixel clock rate(26.4MHz) from the 
> > PLL5 video
> > clock.  If we don't have this patch, the pixel clock rate is about 20MHz, 
> > which
> > causes a horitonal shift on the display image.
> > 
> > This series can be applied on the drm-next branch.
> > 
> > [1] http://www.allshore.com/pdf/Himax_HX8369-A.pdf
> > 
> > Liu Ying (21):
> >   clk: divider: Correct parent clk round rate if no bestdiv is normally
> > found
> >   of: Add vendor prefix for Himax Technologies Inc.
> >   of: Add vendor prefix for Truly Semiconductors Limited
> >   ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits
> > definition
> >   ARM: imx6q: clk: Add the video_27m clock
> >   ARM: imx6q: clk: Change hdmi_isfr clock's parent to be video_27m clock
> >   ARM: imx6q: clk: Change hsi_tx clock to be a shared clock gate
> >   ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock
> > gate
> >   ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports'
> > node
> >   drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
> >   Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
> > bridge driver
> >   drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
> >   Documentation: dt-bindings: Add bindings for i.MX specific Synopsys DW
> > MIPI DSI driver
> >   drm: imx: Support Synopsys DesignWare MIPI DSI host controller
> >   Documentation: dt-bindings: Add bindings for Himax HX8369A DRM panel
> > driver
> >   drm: panel: Add support for Himax HX8369A MIPI DSI panel
> >   ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
> >   ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI
> > DSI panel
> >   ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of
> > staging
> >   ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller
> >   ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel
> > 
> >  .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt |  73 ++
> >  .../devicetree/bindings/drm/imx/mipi_dsi.txt   |  78 ++
> >  .../devicetree/bindings/panel/himax,hx8369a.txt|  39 +
> >  .../devicetree/bindings/vendor-prefixes.txt|   2 +
> >  arch/arm/boot/dts/imx6q.dtsi   |  20 +-
> >  arch/arm/boot/dts/imx6qdl-sabresd.dtsi |  20 +
> >  arch/arm/boot/dts/imx6qdl.dtsi |  29 +-
> >  arch/arm/configs/imx_v6_v7_defconfig   |  17 +-
> >  arch/arm/mach-imx/clk-imx6q.c  |   7 +-
> >  drivers/clk/clk-divider.c  |   3 +-
> >  drivers/gpu/drm/bridge/Kconfig |

Re: [GIT PULL] aio: fix sleeping while TASK_INTERRUPTIBLE

[Dave Chinner]

On Sun, Feb 01, 2015 at 05:18:17PM -0800, Linus Torvalds wrote:
> On Sun, Feb 1, 2015 at 4:16 PM, Benjamin LaHaise  wrote:
> >>
> >> What's the bug you think could happen?
> >
> > The bug would be in code that gets run via mutex_lock(), kmap(), or (more
> > likely) in the random mm or filesystem code that could be invoked via
> > copy_to_user().
> 
> Ahh. That would be a bug, yes, but it wouldn't be one in the aio code.
> 
> If somebody just does a "schedule()" and thinks that their own private
> events are the only thing that can wake it up, and doesn't use one of
> the millions of "wait_event_xyz()" variations to actually wait for the
> real completion, that is just buggy. Always. Always has been.
> 
> So I wouldn't worry too much about it. It has never been correct to do
> that, and it's not one of the standard patterns for sleeping anyway.
> Which is not to say that it might not exist in some dank corner of the
> kernel, of course, but you shouldn't write code trying to make buggy
> code like that happy. If we ever find code like that, let's just fix
> it where the bug exists, not try to write odd code in places where it
> isn't.
> 
> And I'd actually be a bit surprised to see that kind of really broken
> code. You really almost have to work at it. All our normal "sleep
> until X" patterns are much more obvious, and it's just _simpler_ to do
> the right thing with "wait_event()" than to mis-code an explicit "set
> task state and then just schedule without actually checking the thing
> you are waiting for".

So what's the outcome here? I'm running v3.19-rc7 kernel and
xfstests::generic/036 is still tripping this warning from the aio
code:

[   23.920785] run fstests generic/036 at 2015-02-02 16:13:01
[   24.168001] xfs_io (4814) used greatest stack depth: 11640 bytes left
[   24.187061] [ cut here ]
[   24.187071] WARNING: CPU: 1 PID: 4820 at kernel/sched/core.c:7300 
__might_sleep+0x7f/0x90()
[   24.187076] do not call blocking ops when !TASK_RUNNING; state=1 set at 
[] prepare_to_wait_event+0x63/0x110
[   24.187078] Modules linked in:
[   24.187080] CPU: 1 PID: 4820 Comm: aio-dio-fcntl-r Not tainted 
3.19.0-rc7-dgc+ #706
[   24.187081] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Bochs 01/01/2011
[   24.187084]  821c0372 8800b84d3cd8 81daf2bd 
8c8c
[   24.187085]  8800b84d3d28 8800b84d3d18 8109beda 
8800b84d3cf8
[   24.187087]  821c115e 0061  
7fff38e95180
[   24.187087] Call Trace:
[   24.187093]  [] dump_stack+0x4c/0x65
[   24.187096]  [] warn_slowpath_common+0x8a/0xc0
[   24.187099]  [] warn_slowpath_fmt+0x46/0x50
[   24.187101]  [] ? prepare_to_wait_event+0x63/0x110
[   24.187103]  [] ? prepare_to_wait_event+0x63/0x110
[   24.187104]  [] __might_sleep+0x7f/0x90
[   24.187107]  [] mutex_lock+0x24/0x45
[   24.187111]  [] aio_read_events+0x4c/0x290
[   24.187113]  [] read_events+0x1ec/0x220
[   24.187115]  [] ? prepare_to_wait_event+0x110/0x110
[   24.187119]  [] ? hrtimer_get_res+0x50/0x50
[   24.187121]  [] SyS_io_getevents+0x4d/0xb0
[   24.187124]  [] ? __audit_syscall_exit+0x236/0x2e0
[   24.187127]  [] system_call_fastpath+0x12/0x17
[   24.187128] ---[ end trace 9f078e8e19f765dd ]---

This test does a aio write loop with a single outstanding
event. i.e:

while (1) {
io_prep_pwrite(&iocb, fd, buf, BUF_SIZE, BUF_SIZE);
err = io_submit(ctx, 1, iocbs);
if (err)
.
err = io_getevents(ctx, 1, 1, &ev, NULL);
.
}

The kernel should not be throwing warnings on basic regression
tests, so something needs to be fixed...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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] powerpc/mm: warn on flushing tlb page in kernel context

[Arseny Solokha]

Function __flush_tlb_page() must only be called for user contexts, so
put in extra hardening to warn on calling it for kernel context.

Signed-off-by: Arseny Solokha 
---
 arch/powerpc/mm/tlb_nohash.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index f38ea4d..cbd3d06 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -284,8 +284,15 @@ void __flush_tlb_page(struct mm_struct *mm, unsigned long 
vmaddr,
struct cpumask *cpu_mask;
unsigned int pid;
 
+   /*
+* This function as well as __local_flush_tlb_page() must only be called
+* for user contexts.
+*/
+   if (unlikely(WARN_ON(!mm)))
+   return;
+
preempt_disable();
-   pid = mm ? mm->context.id : 0;
+   pid = mm->context.id;
if (unlikely(pid == MMU_NO_CONTEXT))
goto bail;
cpu_mask = mm_cpumask(mm);
-- 
2.2.2

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

Re: [PATCH v1 2/2] zram: remove init_lock in zram_make_request

[Sergey Senozhatsky]

On (02/02/15 14:18), Minchan Kim wrote:
> Everything are fixed. Ready to send a patch.
> But before sending, hope we fix umount race issue first.
> 

Thanks a lot, Minchan!


OK, surely I don't mind to fix the umount race first, I just didn't want
to interrupt you in the middle of locking rework. the race is hardly
possible, but still.


I didn't review Ganesh's patch yet, I'll try to find some time to take a
look later this day.

I'm also planning to send a small `struct zram' cleanup patch by the end
of this day.


-ss
--
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] tty: serial: Add 8250 earlycon to support noinit option

[Greg Kroah-Hartman]

On Mon, Feb 02, 2015 at 12:15:31AM -0500, Peter Hurley wrote:
> On 02/01/2015 11:28 PM, Greg Kroah-Hartman wrote:
> > On Sun, Feb 01, 2015 at 10:45:12PM -0500, Peter Hurley wrote:
> >> On 02/01/2015 10:16 PM, Eddie Huang wrote:
> 
> >> I'll respin proper patches on top of Greg's tty-testing branch with reverts
> >> for the noinit options. I noticed that one of the noinit patches actually
> >> has the linkage for the mtk earlycon, so I'll be sure to preserve that.
> > 
> > I can just drop the patches in the tty-testing branch, that's what it is
> > there for :)
> > 
> > Just let me know the specific patches and I will do so, thanks.
> 
> Well that pretty much means dropping the 3 patches that add earlycon to
> 8250_mtk and then applying my patch (needs fixed to apply cleanly, which
> I can do) and then applying a fixed-up replacement patch to add earlycon
> to 8250_mtk (which I can also supply).
> 
> Is that the way you want to go?

Sounds good to me, send your patch, and I'll fix it all up tomorrow.

thanks,

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

Re: Linux 3.19-rc7

[Stephen Rothwell]

Hi all,

On Sun, 1 Feb 2015 21:16:48 -0800 Linus Torvalds 
 wrote:
>
> Everything seems to be fairly calm and normal, so this is likely to be
> the last rc unless something unexpected suddenly comes up. Which means
> that I'd like to see more people test-booting and running this puppy
> just to check things out.

I will not be producing linux-next release on Thursday or Friday (or
over the weekend) so Wednesday (my time UTC+1100) will probably be the
last -next before the merge window opens - just in case that affects
anyone's plans to push stuff in just before then. :-)

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


pgpxiZVWnydzF.pgp
Description: OpenPGP digital signature

Re: [PATCH v1 2/2] zram: remove init_lock in zram_make_request

[Minchan Kim]

On Mon, Feb 02, 2015 at 02:09:12PM +0900, Sergey Senozhatsky wrote:
> 
> the patch mosly looks good, except for one place:
> 
> On (02/02/15 13:28), Minchan Kim wrote:
> > @@ -783,6 +812,8 @@ static ssize_t disksize_store(struct device *dev,
> > goto out_destroy_comp;
> > }
> >  
> > +   init_waitqueue_head(&zram->io_done);
> > +   zram_meta_get(zram);
> 
> it was
> +   init_completion(&zram->io_done);
> +   atomic_set(&zram->refcount, 1);
> 
> I think we need to replace zram_meta_get(zram) with 
> atomic_set(&zram->refcount, 1).
> 
> ->refcount is 0 by default and atomic_inc_not_zero(&zram->refcount) will not
> increment it here, nor anywhere else.
> 
> 
> > zram->meta = meta;
> > zram->comp = comp;
> > zram->disksize = disksize;
> > @@ -838,8 +869,8 @@ static ssize_t reset_store(struct device *dev,
> > /* Make sure all pending I/O is finished */
> > fsync_bdev(bdev);
> > bdput(bdev);
> > -
> 
> [..]
> 
> > @@ -1041,6 +1075,7 @@ static int create_device(struct zram *zram, int 
> > device_id)
> > int ret = -ENOMEM;
> >  
> > init_rwsem(&zram->init_lock);
> > +   atomic_set(&zram->refcount, 0);
> 
> sorry, I forgot that zram is kzalloc()-ated. so we can drop
> 
>   atomic_set(&zram->refcount, 0)
> 

Everything are fixed. Ready to send a patch.
But before sending, hope we fix umount race issue first.

Thanks a lot, Sergey!

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

Linux 3.19-rc7

[Linus Torvalds]

Everything seems to be fairly calm and normal, so this is likely to be
the last rc unless something unexpected suddenly comes up. Which means
that I'd like to see more people test-booting and running this puppy
just to check things out.

Fairly normal rc statistics - about 50% drivers, 20% arch updates
(mostly arm and arm64, some x86), with filesystems showing up a bit
more than usual (largely due to some quota changes), and the rest
being "misc" - perf tooling, some minor kernel and vm changes etc.

But it's all pretty small. Shortlog appended for the curious,

  Linus

---

Ahmed S. Darwish (4):
  can: kvaser_usb: Do not sleep in atomic context
  can: kvaser_usb: Send correct context to URB completion
  can: kvaser_usb: Retry the first bulk transfer on -ETIMEDOUT
  can: kvaser_usb: Fix state handling upon BUS_ERROR events

Alexei Starovoitov (2):
  bpf: rcu lock must not be held when calling copy_to_user()
  samples: bpf: relax test_maps check

Andrew Jackson (2):
  ASoC: adi: Add missing return statement.
  drm/i2c: tda998x: set the CEC I2C address based on the slave I2C address

Andrey Ryabinin (1):
  drivers/rtc/rtc-s5m.c: terminate s5m_rtc_id array with empty element

Andy Shevchenko (3):
  spi: dw-mid: fix FIFO size
  spi: dw: amend warning message
  stmmac: prevent probe drivers to crash kernel

Anna Schumaker (1):
  NFS: Fix use of nfs_attr_use_mounted_on_fileid()

Arnaldo Carvalho de Melo (3):
  perf evlist: Remove extraneous 'was' on error message
  perf symbols: Introduce method to iterate symbols ordered by name
  perf symbols: Introduce 'for' method to iterate over the symbols
with a given name

Ashay Jaiswal (1):
  regulator: core: fix race condition in regulator_put()

Aurelien BOUIN (1):
  ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers

Axel Lin (1):
  spi: dw: Fix detecting FIFO depth

Bard Liao (1):
  ASoC: rt286: set the same format for dac and adc

Ben Goz (1):
  drm/amdkfd: PQM handle queue creation fault

Ben Hutchings (8):
  sh_eth: Fix padding of short frames on TX
  sh_eth: Detach net device when stopping queue to resize DMA rings
  sh_eth: Fix crash or memory leak when resizing rings on device
that is down
  sh_eth: Fix serialisation of interrupt disable with interrupt &
NAPI handlers
  sh_eth: Remove RX overflow log messages
  sh_eth: Ensure DMA engines are stopped before freeing buffers
  sh_eth: Check for DMA mapping errors on transmit
  sh_eth: Fix DMA-API usage for RX buffers

Bo Shen (1):
  ASoC: wm8904: fix runtime warning

Bob Paauwe (1):
  drm/i915: Only fence tiled region of object.

Chen-Yu Tsai (1):
  ARM: dts: sunxi: Fix usb-phy support for sun4i/sun5i

Cheng-Yi Chiang (1):
  ASoC: ts3a227e: Check and report jack status at probe

Christoph Hellwig (1):
  net: don't OOPS on socket aio

Clemens Ladisch (1):
  ALSA: seq-dummy: remove deadlock-causing events on close

Daniel Borkmann (3):
  net: cls_bpf: fix size mismatch on filter preparation
  net: cls_bpf: fix auto generation of per list handles
  net: sctp: fix slab corruption from use after free on INIT collisions

David Spinadel (1):
  iwlwifi: mvm: fix EBS on single scan

David Woodhouse (1):
  drm/i915: Init PPGTT before context enable

Dmitry Nezhevenko (1):
  usb-storage/SCSI: blacklist FUA on JMicron 152d:2566 USB-SATA controller

Emmanuel Grumbach (2):
  iwlwifi: mvm: drop non VO frames when flushing
  iwlwifi: mvm: abort scheduled scan upon RFKILL

Eric Dumazet (1):
  netxen: fix netxen_nic_poll() logic

Eugene Crosser (1):
  qeth: clean up error handling

Eyal Shapira (1):
  iwlwifi: mvm: set the tx cmd tid for BAR frame correctly

Ezequiel Garcia (1):
  net: mv643xx_eth: Fix highmem support in non-TSO egress path

Fabio Estevam (2):
  ASoC: fsl_ssi: Fix irq error check
  ASoC: fsl: imx-wm8962: Set the card owner field

Felix Fietkau (1):
  ath9k: fix race condition in irq processing during hardware reset

Fred Chou (1):
  mac80211: correct header length calculation

Geert Uytterhoeven (2):
  ASoC: simple-card: Fix crash in asoc_simple_card_unref()
  DT: i2c: Add devices handled by the da9063 MFD driver

Govindarajulu Varadarajan (2):
  enic: fix rx napi poll return value
  bnx2x: fix napi poll return value for repoll

Greg KH (1):
  MAINTAINERS: add Android driver entries

Greg Thelen (1):
  memcg: remove extra newlines from memcg oom kill log

Guenter Roeck (1):
  arc: mm: Fix build failure

Gui Hecheng (1):
  btrfs: fix raid56 scrub failed in xfstests btrfs/072

Hannes Frederic Sowa (2):
  ipv4: try to cache dst_entries which would cause a redirect
  ipv6: replacing a rt6_info needs to purge possible propagated
rt6_infos too

Hans de Goede (3):
  ARM: dts: sun6i: ippo-q8h-v5: Fix serial0 alias
  ARM: dts: sun4i: Add simp

Re: [PATCH v2 1/4] tty: serial: Add 8250 earlycon to support noinit option

[Peter Hurley]

On 02/01/2015 11:28 PM, Greg Kroah-Hartman wrote:
> On Sun, Feb 01, 2015 at 10:45:12PM -0500, Peter Hurley wrote:
>> On 02/01/2015 10:16 PM, Eddie Huang wrote:

>> I'll respin proper patches on top of Greg's tty-testing branch with reverts
>> for the noinit options. I noticed that one of the noinit patches actually
>> has the linkage for the mtk earlycon, so I'll be sure to preserve that.
> 
> I can just drop the patches in the tty-testing branch, that's what it is
> there for :)
> 
> Just let me know the specific patches and I will do so, thanks.

Well that pretty much means dropping the 3 patches that add earlycon to
8250_mtk and then applying my patch (needs fixed to apply cleanly, which
I can do) and then applying a fixed-up replacement patch to add earlycon
to 8250_mtk (which I can also supply).

Is that the way you want to go?

--
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] cpuidle/powernv: Read target_residency value of idle states from DT if available

[Preeti U Murthy]

The device tree now exposes the residency values for different idle states. Read
these values instead of calculating residency from the latency values. The 
values
exposed in the DT are validated for optimal power efficiency. However to 
maintain
compatibility with the older firmware code which does not expose residency
values, use default values as a fallback mechanism. While at it, use better
APIs to parse the powermgmt device tree node so as to avoid endianness
transformation.

Signed-off-by: Preeti U Murthy 
---
Changes from V2: https://lkml.org/lkml/2015/1/27/1054
1. Used APIs to eliminate endianness transformation

Changes from V1: https://lkml.org/lkml/2015/1/19/221
1. Used a better API for reading the DT property values.
2. Code cleanups

 arch/powerpc/platforms/powernv/setup.c |   37 --
 drivers/cpuidle/cpuidle-powernv.c  |   86 ++--
 2 files changed, 71 insertions(+), 52 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index b700a32..d6a9329 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -409,37 +410,40 @@ static int __init pnv_init_idle_states(void)
 {
struct device_node *power_mgt;
int dt_idle_states;
-   const __be32 *idle_state_flags;
-   u32 len_flags, flags;
+   u32 *flags;
int i;
 
supported_cpuidle_states = 0;
 
if (cpuidle_disable != IDLE_NO_OVERRIDE)
-   return 0;
+   goto out;
 
if (!firmware_has_feature(FW_FEATURE_OPALv3))
-   return 0;
+   goto out;
 
power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
if (!power_mgt) {
pr_warn("opal: PowerMgmt Node not found\n");
-   return 0;
+   goto out;
}
 
-   idle_state_flags = of_get_property(power_mgt,
-   "ibm,cpu-idle-state-flags", &len_flags);
-   if (!idle_state_flags) {
-   pr_warn("DT-PowerMgmt: missing ibm,cpu-idle-state-flags\n");
-   return 0;
+   dt_idle_states = of_property_count_u32_elems(power_mgt,
+   "ibm,cpu-idle-state-flags");
+   if (dt_idle_states < 0) {
+   pr_warn("cpuidle-powernv: no idle states found in the DT\n");
+   goto out;
}
 
-   dt_idle_states = len_flags / sizeof(u32);
-
-   for (i = 0; i < dt_idle_states; i++) {
-   flags = be32_to_cpu(idle_state_flags[i]);
-   supported_cpuidle_states |= flags;
+   flags = kzalloc(sizeof(*flags) * dt_idle_states, GFP_KERNEL);
+   if (of_property_read_u32_array(power_mgt,
+   "ibm,cpu-idle-state-flags", flags, dt_idle_states)) {
+   pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-flags in 
DT\n");
+   goto out_free;
}
+
+   for (i = 0; i < dt_idle_states; i++)
+   supported_cpuidle_states |= flags[i];
+
if (!(supported_cpuidle_states & OPAL_PM_SLEEP_ENABLED_ER1)) {
patch_instruction(
(unsigned int *)pnv_fastsleep_workaround_at_entry,
@@ -449,6 +453,9 @@ static int __init pnv_init_idle_states(void)
PPC_INST_NOP);
}
pnv_alloc_idle_core_states();
+out_free:
+   kfree(flags);
+out:
return 0;
 }
 
diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index 223d505..2ef4b70 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -160,70 +161,81 @@ static int powernv_add_idle_states(void)
struct device_node *power_mgt;
int nr_idle_states = 1; /* Snooze */
int dt_idle_states;
-   const __be32 *idle_state_flags;
-const __be32 *idle_state_latency;
-u32 len_flags, flags, latency_ns;
-   int i;
+   u32 *latency_ns, *residency_ns, *flags;
+   int i, rc;
 
/* Currently we have snooze statically defined */
-
power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
if (!power_mgt) {
pr_warn("opal: PowerMgmt Node not found\n");
-   return nr_idle_states;
+   goto out;
}
 
-   idle_state_flags = of_get_property(power_mgt, 
"ibm,cpu-idle-state-flags", &len_flags);
-   if (!idle_state_flags) {
-   pr_warn("DT-PowerMgmt: missing ibm,cpu-idle-state-flags\n");
-   return nr_idle_states;
+   /* Read values of any property to determine the num of idle states */
+   dt_idle_states = of_property_count_u32_elems(power_mgt,
+   "ibm,cpu-idle-state-flags");
+   if (dt_idle_states < 0) {
+   pr_warn("cpuid

Re: [PATCH bluetooth-next] ieee802154: cc2520: Replace shift operations by BIT macro

[Marcel Holtmann]

Hi Mohammad,

> This patch replaces the shifting operations by BIT macro
> 
> Signed-off-by: Mohammad Jamal 
> ---
> drivers/net/ieee802154/cc2520.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

--
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 bluetooth-next] ieee802154: cc2520: Fix space before , coding style issue

[Marcel Holtmann]

Hi Mohammad,

> This patch removes the warnings (space before , ) shown by
> checkpatch.pl
> 
> Signed-off-by: Mohammad Jamal 
> ---
> drivers/net/ieee802154/cc2520.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

--
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 v1 2/2] zram: remove init_lock in zram_make_request

[Minchan Kim]

On Mon, Feb 02, 2015 at 01:28:47PM +0900, Minchan Kim wrote:
> On Mon, Feb 02, 2015 at 01:01:24PM +0900, Sergey Senozhatsky wrote:
> > On (02/02/15 11:44), Minchan Kim wrote:
> > > > sure, I did think about this. and I actually didn't find any reason not
> > > > to use ->refcount there. if user wants to reset the device, he first
> > > > should umount it to make bdev->bd_holders check happy. and that's where
> > > > IOs will be failed. so it makes sense to switch to ->refcount there, 
> > > > IMHO.
> > > 
> > > If we use zram as block device itself(not a fs or swap) and open the
> > > block device as !FMODE_EXCL, bd_holders will be void.
> > > 
> > 
> > hm.
> > I don't mind to use ->disksize there, but personally I'd maybe prefer
> > to use ->refcount, which just looks less hacky. zram's most common use
> > cases are coming from ram swap device or ram device with fs. so it looks
> > a bit like we care about some corner case here.
> 
> Maybe, but I always test zram with dd so it's not a corner case for me. :)
> 
> > 
> > just my opinion, no objections against ->disksize != 0.
> 
> Thanks. It's a draft for v2. Please review.
> 
> BTW, you pointed out race between bdev_open/close and reset and
> it's cleary bug although it's rare in real practice.
> So, I want to fix it earlier than this patch and mark it as -stable
> if we can fix it easily like Ganesh's work.
> If it gets landing, we could make this patch rebased on it.
> 
> From 699502b4e0c84b3d7b33f8754cf1c0109b16c012 Mon Sep 17 00:00:00 2001
> From: Minchan Kim 
> Date: Mon, 2 Feb 2015 10:36:28 +0900
> Subject: [PATCH v2] zram: remove init_lock in zram_make_request
> 
> Admin could reset zram during I/O operation going on so we have
> used zram->init_lock as read-side lock in I/O path to prevent
> sudden zram meta freeing.
> 
> However, the init_lock is really troublesome.
> We can't do call zram_meta_alloc under init_lock due to lockdep splat
> because zram_rw_page is one of the function under reclaim path and
> hold it as read_lock while other places in process context hold it
> as write_lock. So, we have used allocation out of the lock to avoid
> lockdep warn but it's not good for readability and fainally, I met
> another lockdep splat between init_lock and cpu_hotplug from
> kmem_cache_destroy during working zsmalloc compaction. :(
> 
> Yes, the ideal is to remove horrible init_lock of zram in rw path.
> This patch removes it in rw path and instead, add atomic refcount
> for meta lifetime management and completion to free meta in process
> context. It's important to free meta in process context because
> some of resource destruction needs mutex lock, which could be held
> if we releases the resource in reclaim context so it's deadlock,
> again.
> 
> Signed-off-by: Sergey Senozhatsky 
> Signed-off-by: Minchan Kim 
> ---
>  drivers/block/zram/zram_drv.c | 85 
> ++-
>  drivers/block/zram/zram_drv.h | 20 +-
>  2 files changed, 71 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index aa5a4c5..c6d505c 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -55,7 +55,7 @@ static DEVICE_ATTR_RO(name);
>  
>  static inline int init_done(struct zram *zram)
>  {
> - return zram->meta != NULL;
> + return zram->disksize != 0;
>  }
>  
>  static inline struct zram *dev_to_zram(struct device *dev)
> @@ -358,6 +358,18 @@ out_error:
>   return NULL;
>  }
>  
> +static inline bool zram_meta_get(struct zram *zram)
> +{
> + if (atomic_inc_not_zero(&zram->refcount))
> + return true;
> + return false;
> +}
> +
> +static inline void zram_meta_put(struct zram *zram)
> +{
> + atomic_dec(&zram->refcount);
> +}
> +
>  static void update_position(u32 *index, int *offset, struct bio_vec *bvec)
>  {
>   if (*offset + bvec->bv_len >= PAGE_SIZE)
> @@ -719,6 +731,10 @@ static void zram_bio_discard(struct zram *zram, u32 
> index,
>  
>  static void zram_reset_device(struct zram *zram, bool reset_capacity)
>  {
> + struct zram_meta *meta;
> + struct zcomp *comp;
> + u64 disksize;
> +
>   down_write(&zram->init_lock);
>  
>   zram->limit_pages = 0;
> @@ -728,19 +744,32 @@ static void zram_reset_device(struct zram *zram, bool 
> reset_capacity)
>   return;
>   }
>  
> - zcomp_destroy(zram->comp);
> - zram->max_comp_streams = 1;
> - zram_meta_free(zram->meta, zram->disksize);
> - zram->meta = NULL;
> + meta = zram->meta;
> + comp = zram->comp;
> + disksize = zram->disksize;
> + zram->disksize = 0;
> + /*
> +  * ->refcount will go down to 0 eventually and rw handler cannot
> +  * handle further I/O by init_done checking.
> +  */
> + zram_meta_put(zram);
> + /*
> +  * We want to free zram_meta in process context to avoid
> +  * deadlock between reclaim path and any other locks
> +  */
> + wait_event(z

Re: [PATCH v1 2/2] zram: remove init_lock in zram_make_request

[Sergey Senozhatsky]

the patch mosly looks good, except for one place:

On (02/02/15 13:28), Minchan Kim wrote:
> @@ -783,6 +812,8 @@ static ssize_t disksize_store(struct device *dev,
>   goto out_destroy_comp;
>   }
>  
> + init_waitqueue_head(&zram->io_done);
> + zram_meta_get(zram);

it was
+   init_completion(&zram->io_done);
+   atomic_set(&zram->refcount, 1);

I think we need to replace zram_meta_get(zram) with atomic_set(&zram->refcount, 
1).

->refcount is 0 by default and atomic_inc_not_zero(&zram->refcount) will not
increment it here, nor anywhere else.


>   zram->meta = meta;
>   zram->comp = comp;
>   zram->disksize = disksize;
> @@ -838,8 +869,8 @@ static ssize_t reset_store(struct device *dev,
>   /* Make sure all pending I/O is finished */
>   fsync_bdev(bdev);
>   bdput(bdev);
> -

[..]

> @@ -1041,6 +1075,7 @@ static int create_device(struct zram *zram, int 
> device_id)
>   int ret = -ENOMEM;
>  
>   init_rwsem(&zram->init_lock);
> + atomic_set(&zram->refcount, 0);

sorry, I forgot that zram is kzalloc()-ated. so we can drop

atomic_set(&zram->refcount, 0)

>   zram->queue = blk_alloc_queue(GFP_KERNEL);
>   if (!zram->queue) {


-ss
--
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: __might_sleep() warnings on v3.19-rc6

[Linus Torvalds]

On Sun, Feb 1, 2015 at 3:03 PM, NeilBrown  wrote:
>
> I guess I could
>   __set_current_state(TASK_RUNNING);
> somewhere to defeat the warning, and add a comment explaining why.
>
> Would that be a good thing?

Use "sched_annotate_sleep()" instead, but yes, add a comment about why it's ok.

Linus
--
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/7] extcon: usb-gpio: Introduce gpio usb extcon driver

[Chanwoo Choi]

Hi Roger,

On 01/30/2015 11:03 PM, Roger Quadros wrote:
> On 30/01/15 02:11, Chanwoo Choi wrote:
>> Hi Roger,
>>
>> On 01/28/2015 09:15 PM, Roger Quadros wrote:
>>> This driver observes the USB ID pin connected over a GPIO and
>>> updates the USB cable extcon states accordingly.
>>>
>>> The existing GPIO extcon driver is not suitable for this purpose
>>> as it needs to be taught to understand USB cable states and it
>>> can't handle more than one cable per instance.
>>>
>>> For the USB case we need to handle 2 cable states.
>>> 1) USB (attach/detach)
>>> 2) USB-Host (attach/detach)
>>>
>>> This driver can be easily updated in the future to handle VBUS
>>> events in case it happens to be available on GPIO for any platform.
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>> v3:
>>> - removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
>>>   IRQF_TRIGGER_FALLING
>>> - Added disable_irq() to suspend() and enable_irq() to resume()
>>>
>>>  .../devicetree/bindings/extcon/extcon-usb-gpio.txt |  18 ++
>>>  drivers/extcon/Kconfig |   7 +
>>>  drivers/extcon/Makefile|   1 +
>>>  drivers/extcon/extcon-usb-gpio.c   | 233 
>>> +
>>>  4 files changed, 259 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>>>  create mode 100644 drivers/extcon/extcon-usb-gpio.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt 
>>> b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>>> new file mode 100644
>>> index 000..85fe6b0
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>>> @@ -0,0 +1,18 @@
>>> +USB GPIO Extcon device
>>> +
>>> +This is a virtual device used to generate USB cable states from the USB ID 
>>> pin
>>> +connected to a GPIO pin.
>>> +
>>> +Required properties:
>>> +- compatible: Should be "linux,extcon-usb-gpio"
>>> +- id-gpio: gpio for USB ID pin. See gpio binding.
>>> +
>>> +Example:
>>> +   extcon_usb1 {
>>> +   compatible = "linux,extcon-usb-gpio";
>>> +   id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
>>> +   }
>>> +
>>> +   &omap_dwc3_1 {
>>> +   extcon = <&extcon_usb1>;
>>> +   };
>>> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
>>> index 6a1f7de..fd11536 100644
>>> --- a/drivers/extcon/Kconfig
>>> +++ b/drivers/extcon/Kconfig
>>> @@ -93,4 +93,11 @@ config EXTCON_SM5502
>>>   Silicon Mitus SM5502. The SM5502 is a USB port accessory
>>>   detector and switch.
>>>  
>>> +config EXTCON_USB_GPIO
>>> +   tristate "USB GPIO extcon support"
>>> +   select GPIOLIB
>>> +   help
>>> + Say Y here to enable GPIO based USB cable detection extcon support.
>>> + Used typically if GPIO is used for USB ID pin detection.
>>> +
>>>  endif # MULTISTATE_SWITCH
>>> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
>>> index 0370b42..6a08a98 100644
>>> --- a/drivers/extcon/Makefile
>>> +++ b/drivers/extcon/Makefile
>>> @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)  += extcon-max8997.o
>>>  obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
>>>  obj-$(CONFIG_EXTCON_RT8973A)   += extcon-rt8973a.o
>>>  obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
>>> +obj-$(CONFIG_EXTCON_USB_GPIO)  += extcon-usb-gpio.o
>>> diff --git a/drivers/extcon/extcon-usb-gpio.c 
>>> b/drivers/extcon/extcon-usb-gpio.c
>>> new file mode 100644
>>> index 000..99a58b2
>>> --- /dev/null
>>> +++ b/drivers/extcon/extcon-usb-gpio.c
>>> @@ -0,0 +1,233 @@
>>> +/**
>>> + * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
>>> + *
>>> + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
>>> + * Author: Roger Quadros 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define USB_GPIO_DEBOUNCE_MS   20  /* ms */
>>> +
>>> +struct usb_extcon_info {
>>> +   struct device *dev;
>>> +   struct extcon_dev *edev;
>>> +
>>> +   struct gpio_desc *id_gpiod;
>>> +   int id_irq;
>>> +   bool id_irqwake;/* ID wakeup enabled flag */
>>> +
>>> +   unsigned long debounce_jiffies;
>>> +   struct delayed_work wq_detcable;
>>> +};
>>> +
>>> +/* List of detectable cables */
>>> +enum {
>>> +   EXTCON_CABLE_USB = 0,
>>> +   EXTCON_CABLE_USB_HOST,
>>> +
>>> +   EXTCON_CABLE_END,
>>> +};
>>> +
>>> +static const char *usb_extc

Re: [PATCH] tun: orphan an skb on tx

[David Miller]

From: David Woodhouse 
Date: Sun, 01 Feb 2015 21:29:43 +

> I really was looking for some way to push down something like an XFRM
> state into the tun device and just say "shove them out here until I tell
> you otherwise".

People decided to use TUN and push VPN stuff back into userspace,
and there are repercussions for that decision.

I'm not saying this to be mean or whatever, but I was very
disappointed when userland IPSEC solutions using TUN started showing
up.

We might as well have not have implemented the IPSEC stack at all,
because as a result of the userland VPN stuff our IPSEC stack is
largely unused except by a very narrow group of users.
--
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] powerpc/mm: bail out early when flushing TLB page

[Arseny Solokha]

> On Fri, 2015-01-30 at 19:08 +0700, Arseny Solokha wrote:
>> MMU_NO_CONTEXT is conditionally defined as 0 or (unsigned int)-1. However,
>> in __flush_tlb_page() a corresponding variable is only tested for open
>> coded 0, which can cause NULL pointer dereference if `mm' argument was
>> legitimately passed as such.
>>
>> Bail out early in case the first argument is NULL, thus eliminate confusion
>> between different values of MMU_NO_CONTEXT and avoid disabling and then
>> re-enabling preemption unnecessarily.
> 
> So the comment above isn't quite right... we don't *test* it for open
> coded 0, we test it for MMU_NO_CONTEXT, however we *set* it to 0 for
> NULL mm.
> 
> This is actually correct... on all except 8xx :-) 0 *is* the PID of the
> kernel context, and NULL mm usually means kernel context.

> However, it's correct that this function will not deal properly with a
> NULL mm for other reasons. It must only be called for user contexts.
> 
> Instead of just returning, I would WARN_ON, because if it's ever called
> for a kernel page, then it will not do what's expected and that will
> need fixing. Just a silent return isn't right.

Does this also hold true for __local_flush_tlb_page()? It's called from
local_flush_tlb_page() as follows:

  __local_flush_tlb_page(vma ? vma->vm_mm : NULL, vmaddr,
 mmu_get_tsize(mmu_virtual_psize), 0);

However, if MMU_NO_CONTEXT is 0 and __local_flush_tlb_page() is called with mm
set to NULL, it's effectively a no-op. What else am I missing?

Thanks,

Arsény


> This is different from returning on MMU_NO_CONTEXT, in this case, we
> know there's no active TLB entries for the process, and thus nothing to
> flush.
> 
> Cheers,
> Ben.
> 
>> Signed-off-by: Arseny Solokha 
>> ---
>>  arch/powerpc/mm/tlb_nohash.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
>> index f38ea4d..ab0616b 100644
>> --- a/arch/powerpc/mm/tlb_nohash.c
>> +++ b/arch/powerpc/mm/tlb_nohash.c
>> @@ -284,8 +284,11 @@ void __flush_tlb_page(struct mm_struct *mm, unsigned 
>> long vmaddr,
>>  struct cpumask *cpu_mask;
>>  unsigned int pid;
>>  
>> +if (unlikely(!mm))
>> +return;
>> +
>>  preempt_disable();
>> -pid = mm ? mm->context.id : 0
> 
> Here we test mm, if we pass NULL, that means the kernel mm which has PID
> 0, which is not MMU_NO_CONTEXT
>> ;
>> +pid = mm->context.id;
>>  if (unlikely(pid == MMU_NO_CONTEXT))
>>  goto bail;
>>  cpu_mask = mm_cpumask(mm);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/arm64/kvm/sys_regs.c between commit 3c1e71650833 ("arm/arm64: KVM:
Use set/way op trapping to track the state of the caches") from Linus'
tree and commit 6d52f35af10c ("arm64: KVM: add SGI generation register
emulation") from the kvm tree.

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

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

diff --cc arch/arm64/kvm/sys_regs.c
index b96afdf6cee4,7ad7af51856f..
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@@ -605,7 -693,9 +638,9 @@@ static const struct sys_reg_desc cp14_6
   * register).
   */
  static const struct sys_reg_desc cp15_regs[] = {
+   { Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
+ 
 -  { Op1( 0), CRn( 1), CRm( 0), Op2( 0), access_sctlr, NULL, c1_SCTLR },
 +  { Op1( 0), CRn( 1), CRm( 0), Op2( 0), access_vm_reg, NULL, c1_SCTLR },
{ Op1( 0), CRn( 2), CRm( 0), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
{ Op1( 0), CRn( 2), CRm( 0), Op2( 1), access_vm_reg, NULL, c2_TTBR1 },
{ Op1( 0), CRn( 2), CRm( 0), Op2( 2), access_vm_reg, NULL, c2_TTBCR },


pgpGxY3svxknT.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name

[Chanwoo Choi]

Hi Roger,

On 01/30/2015 11:05 PM, Roger Quadros wrote:
> Hi,
> 
> On 30/01/15 13:04, Roger Quadros wrote:
>> Felipe & Chanwoo,
>>
>> On 26/01/15 14:15, Roger Quadros wrote:
>>> The recommended name for USB-Host cable state is "USB-Host" and not
>>> "USB-HOST" as per drivers/extcon/extcon-class.c extcon_cable_name.
>>>
>>> Change all instances of "USB-HOST" to "USB-Host".
>>>
>>> Signed-off-by: Roger Quadros 
>>> Reviewed-by: Felipe Balbi 
>>> Acked-by: Felipe Balbi 
>>
>> This patch has no dependency to the rest so can be picked up as soon as 
>> possible.
>>
>> Do you think it is better to go via the USB tree?
>> If yes then Chanwoo, can you please Ack this one? Thanks.
>>
>> This would mean that only the first patch needs to go through extcon tree as 
>> Tony
>> will pick the rest.
> 
> Hold on. Let's first decide what we really want to go ahead with
> "USB-Host" or "USB-HOST".

Currently, extcon driver have used the specific cable name(USB-Host or USB-HOST)
without any standard way. So, I have plan to define common cable name in extcon
header file by using capital letter.

Thanks,
Chanwoo Choi

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

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/arm/kvm/mmu.c between commits 363ef89f8e9b ("arm/arm64: KVM:
Invalidate data cache on unmap") and 0d3e4d4fade6 ("arm/arm64: KVM: Use
kernel mapping to perform invalidation on page fault") from Linus' tree
and commits c64735554c0a ("KVM: arm: Add initial dirty page locking
support"), 53c810c364d7 ("KVM: arm: dirty logging write protect
support") and 15a49a44fc36 ("KVM: arm: page logging 2nd stage fault
handling") from the kvm tree.

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

P.S. commits c64735554c0a, 53c810c364d7 and 15a49a44fc36 have no
signed-off-by from their committer (Christoffer Dall).
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/kvm/mmu.c
index 136662547ca6,74aeabaa3c4d..
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@@ -58,26 -78,25 +78,45 @@@ static void kvm_tlb_flush_vmid_ipa(stru
kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
  }
  
 +/*
 + * D-Cache management functions. They take the page table entries by
 + * value, as they are flushing the cache using the kernel mapping (or
 + * kmap on 32bit).
 + */
 +static void kvm_flush_dcache_pte(pte_t pte)
 +{
 +  __kvm_flush_dcache_pte(pte);
 +}
 +
 +static void kvm_flush_dcache_pmd(pmd_t pmd)
 +{
 +  __kvm_flush_dcache_pmd(pmd);
 +}
 +
 +static void kvm_flush_dcache_pud(pud_t pud)
 +{
 +  __kvm_flush_dcache_pud(pud);
 +}
 +
+ /**
+  * stage2_dissolve_pmd() - clear and flush huge PMD entry
+  * @kvm:  pointer to kvm structure.
+  * @addr: IPA
+  * @pmd:  pmd pointer for IPA
+  *
+  * Function clears a PMD entry, flushes addr 1st and 2nd stage TLBs. Marks all
+  * pages in the range dirty.
+  */
+ static void stage2_dissolve_pmd(struct kvm *kvm, phys_addr_t addr, pmd_t *pmd)
+ {
+   if (!kvm_pmd_huge(*pmd))
+   return;
+ 
+   pmd_clear(pmd);
+   kvm_tlb_flush_vmid_ipa(kvm, addr);
+   put_page(virt_to_page(pmd));
+ }
+ 
  static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
  int min, int max)
  {
@@@ -957,12 -957,151 +1009,157 @@@ static bool kvm_is_device_pfn(unsigned 
return !pfn_valid(pfn);
  }
  
 +static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, pfn_t pfn,
 +unsigned long size, bool uncached)
 +{
 +  __coherent_cache_guest_page(vcpu, pfn, size, uncached);
 +}
 +
+ /**
+  * stage2_wp_ptes - write protect PMD range
+  * @pmd:  pointer to pmd entry
+  * @addr: range start address
+  * @end:  range end address
+  */
+ static void stage2_wp_ptes(pmd_t *pmd, phys_addr_t addr, phys_addr_t end)
+ {
+   pte_t *pte;
+ 
+   pte = pte_offset_kernel(pmd, addr);
+   do {
+   if (!pte_none(*pte)) {
+   if (!kvm_s2pte_readonly(pte))
+   kvm_set_s2pte_readonly(pte);
+   }
+   } while (pte++, addr += PAGE_SIZE, addr != end);
+ }
+ 
+ /**
+  * stage2_wp_pmds - write protect PUD range
+  * @pud:  pointer to pud entry
+  * @addr: range start address
+  * @end:  range end address
+  */
+ static void stage2_wp_pmds(pud_t *pud, phys_addr_t addr, phys_addr_t end)
+ {
+   pmd_t *pmd;
+   phys_addr_t next;
+ 
+   pmd = pmd_offset(pud, addr);
+ 
+   do {
+   next = kvm_pmd_addr_end(addr, end);
+   if (!pmd_none(*pmd)) {
+   if (kvm_pmd_huge(*pmd)) {
+   if (!kvm_s2pmd_readonly(pmd))
+   kvm_set_s2pmd_readonly(pmd);
+   } else {
+   stage2_wp_ptes(pmd, addr, next);
+   }
+   }
+   } while (pmd++, addr = next, addr != end);
+ }
+ 
+ /**
+   * stage2_wp_puds - write protect PGD range
+   * @pgd: pointer to pgd entry
+   * @addr:range start address
+   * @end: range end address
+   *
+   * Process PUD entries, for a huge PUD we cause a panic.
+   */
+ static void  stage2_wp_puds(pgd_t *pgd, phys_addr_t addr, phys_addr_t end)
+ {
+   pud_t *pud;
+   phys_addr_t next;
+ 
+   pud = pud_offset(pgd, addr);
+   do {
+   next = kvm_pud_addr_end(addr, end);
+   if (!pud_none(*pud)) {
+   /* TODO:PUD not supported, revisit later if supported */
+   BUG_ON(kvm_pud_huge(*pud));
+   stage2_wp_pmds(pud, addr, next);
+   }
+   } while (pud++, addr = next, addr != end);
+ }
+ 
+ /**
+  * stage2_wp_range() - write protect stage2 memory region range
+  * @kvm:  The KVM pointer
+  * @addr: Start address of range
+  * @end:  End address of range
+  */
+ static void stage2_wp_range(struct kvm *kvm, phys_addr_t addr, phys_addr_t 
end)
+ {
+   pgd_t *pgd;
+   phys_addr_t next;
+ 
+   p

Re: __might_sleep() warnings on v3.19-rc6

[NeilBrown]

(high-jacking the thread a bit... I don't have the patch that I want to reply
to still in my mail box:  the subject still matches...)

I just got a might-sleep warning in my own testing.
This was introduced by 

commit e22b886a8a43b147e1994a9f970f678fc0df2033
Author: Peter Zijlstra 
Date:   Wed Sep 24 10:18:48 2014 +0200

sched/wait: Add might_sleep() checks


In particular:

@@ -318,6 +320,7 @@ do {
  */
 #define wait_event_cmd(wq, condition, cmd1, cmd2)  \
 do {   \
+   might_sleep();  \
if (condition)  \
break;  \
__wait_event_cmd(wq, condition, cmd1, cmd2);\


Where I call this in raid5_quiesce(), 'cmd1' releases a lock and enables
interrupts and  cmd2 takes the lock and disables interrupts.

So it is perfectly OK to sleep at the point where schedule is called, but not
at the point where wait_event_cmd is called.

I can't use wait_event_lock_irq_cmd() as there are actually several spinlocks
I need to manipulate.

So I'm hoping that this part of the patch (at least) can be reverted.

Otherwise I guess I'll need to use __wait_event_cmd().

Thanks,
NeilBrown


pgpZwHNKc9kyM.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 0/2] Quieten softlockup detector on virtualised kernels

[Cyril Bur]

Hi Andrew,

Could you please pick these patches up through your tree?

Thanks,

Cyril

On Fri, 2015-01-09 at 14:34 +1100, Cyril Bur wrote:
> When the hypervisor pauses a virtualised kernel the kernel will observe a jump
> in timebase, this can cause spurious messages from the softlockup detector.
> 
> Whilst these messages are harmless, they are accompanied with a stack trace
> which causes undue concern and more problematically the stack trace in the
> guest has nothing to do with the observed problem and can only be misleading.
> 
> Futhermore, on POWER8 this is completely avoidable with the introduction of
> the Virtual Time Base (VTB) register.
> 
> V2:
>   Remove the export of running_clock
>   Added #ifdef CONFIG_PPC_PSERIES and optimised the non lpar + vtb cases.
>   Replaced the use of sched_clock_with local_clock it was used originally 
> in
> the softlockup detector.
> 
> Cyril Bur (2):
>   Add another clock for use with the soft lockup watchdog.
>   powerpc: add running_clock for powerpc to prevent spurious softlockup
> warnings
> 
>  arch/powerpc/kernel/time.c | 32 
>  include/linux/sched.h  |  1 +
>  kernel/sched/clock.c   | 13 +
>  kernel/watchdog.c  |  2 +-
>  4 files changed, 47 insertions(+), 1 deletion(-)
> 


--
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 Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

[Viresh Kumar]

On 2 February 2015 at 10:15, ethan zhao  wrote:
> On 2015/2/2 12:26, Viresh Kumar wrote:

>  But there is no checking against refcount in or before
>
>  cpufreq_policy_free(), that is one issue I mentioned.

As I said earlier, the completion will only fire once the refcount
is zero. And so there is no need of any check here.

>> That routines doesn't have any tricks and simply frees the policy.
>> Because, before calling cpufreq_policy_put_kobj(), we have set
>> the per-cpu variable to NULL, nobody else will get the policy
>
>  It is possible cpufreq_cpu_get() within the PPC thread was called just
>  before __cpufreq_remove_dev_finish() is to be called in another thread,
>  so you set the per_cpu(cpufreq_cpu_data, cpu) to NULL will not prevent
>  the actions between cpufreq_cpu_get and cpufreq_cpu_put().
>
>  And then the freeing happens in __cpufreq_remove_dev_finish().

It will.. You aren't looking closely enough. If cpufreq_cpu_get() is called just
before remove-dev, then cpufreq_cpu_get() will take:

read_lock_irqsave(&cpufreq_driver_lock, flags);

And it will do:

read_unlock_irqrestore(&cpufreq_driver_lock, flags);

only after increasing the refcount with kobject_get().

While on the other side __cpufreq_remove_dev_finish() will do this:

   write_lock_irqsave(&cpufreq_driver_lock, flags);
   policy = per_cpu(cpufreq_cpu_data, cpu);
   per_cpu(cpufreq_cpu_data, cpu) = NULL;
   write_unlock_irqrestore(&cpufreq_driver_lock, flags);

So, it will wait for the read_lock in cpufreq_cpu_get() to finish before
setting per-cpu variable to NULL. And so, after kobject_put() in
cpufreq_policy_put_kobj(), we will wait for the completion to fire
and that will only happen once a corresponding cpufreq_cpu_put()
is issued.
--
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 Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

[ethan zhao]

On 2015/2/2 12:26, Viresh Kumar wrote:

On 2 February 2015 at 09:46, ethan zhao  wrote:

  We am talking about the policy allocation and de-allocation. right ?
  I showed you the cpufreq_policy_free(policy) doesn't check kobject
  refcount  as above.

  Hmmm, you are still sleeping in the kobject, wake up and don't mix
  water anymore.

It would be nice if we give each other the respect we deserve, And talk
about concrete points here.

 Welcome back to the right way.

if (!cpufreq_suspended)
  cpufreq_policy_put_kobj(policy);

static void cpufreq_policy_put_kobj(struct cpufreq_policy *policy)
{
  ...

  kobject_put(kobj);

  /*
  * We need to make sure that the underlying kobj is
  * actually not referenced anymore by anybody before we
  * proceed with unloading.
  */
  pr_debug("waiting for dropping of refcount\n");
  wait_for_completion(cmp);
}

I gave you exactly what you wanted to go through, but it seems you
haven't tried enough.

Before freeing policy with cpufreq_policy_free(), we call
cpufreq_policy_put_kobj(). Now what does this function do? It waits
for the completion to fire (wait_for_completion()). This completion
will only fire when refcount of a kobject becomes zero.

Initially when we create the kobject, it is initialized to one. And the
last kobject_put() you see above in cpufreq_policy_put_kobj()
makes it zero. All other cpufreq_cpu_get() and put() should happen
in pairs, otherwise this refcount will never be zero again.

As soon as the refcount becomes zero, we are sure no one else is
using the policy structure anymore. And so we free it with
cpufreq_policy_free().

 But there is no checking against refcount in or before

 cpufreq_policy_free(), that is one issue I mentioned.



That routines doesn't have any tricks and simply frees the policy.
Because, before calling cpufreq_policy_put_kobj(), we have set
the per-cpu variable to NULL, nobody else will get the policy

 It is possible cpufreq_cpu_get() within the PPC thread was called just
 before __cpufreq_remove_dev_finish() is to be called in another thread,
 so you set the per_cpu(cpufreq_cpu_data, cpu) to NULL will not prevent
 the actions between cpufreq_cpu_get and cpufreq_cpu_put().

 And then the freeing happens in __cpufreq_remove_dev_finish().

structure by calling cpufreq_cpu_get(). And that's what my patch
tried to solve.

Let me know if I wasn't explanatory enough..


Ethan


--
viresh


--
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 v1 2/2] zram: remove init_lock in zram_make_request

[Minchan Kim]

On Mon, Feb 02, 2015 at 01:01:24PM +0900, Sergey Senozhatsky wrote:
> On (02/02/15 11:44), Minchan Kim wrote:
> > > sure, I did think about this. and I actually didn't find any reason not
> > > to use ->refcount there. if user wants to reset the device, he first
> > > should umount it to make bdev->bd_holders check happy. and that's where
> > > IOs will be failed. so it makes sense to switch to ->refcount there, IMHO.
> > 
> > If we use zram as block device itself(not a fs or swap) and open the
> > block device as !FMODE_EXCL, bd_holders will be void.
> > 
> 
> hm.
> I don't mind to use ->disksize there, but personally I'd maybe prefer
> to use ->refcount, which just looks less hacky. zram's most common use
> cases are coming from ram swap device or ram device with fs. so it looks
> a bit like we care about some corner case here.

Maybe, but I always test zram with dd so it's not a corner case for me. :)

> 
> just my opinion, no objections against ->disksize != 0.

Thanks. It's a draft for v2. Please review.

BTW, you pointed out race between bdev_open/close and reset and
it's cleary bug although it's rare in real practice.
So, I want to fix it earlier than this patch and mark it as -stable
if we can fix it easily like Ganesh's work.
If it gets landing, we could make this patch rebased on it.

>From 699502b4e0c84b3d7b33f8754cf1c0109b16c012 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Mon, 2 Feb 2015 10:36:28 +0900
Subject: [PATCH v2] zram: remove init_lock in zram_make_request

Admin could reset zram during I/O operation going on so we have
used zram->init_lock as read-side lock in I/O path to prevent
sudden zram meta freeing.

However, the init_lock is really troublesome.
We can't do call zram_meta_alloc under init_lock due to lockdep splat
because zram_rw_page is one of the function under reclaim path and
hold it as read_lock while other places in process context hold it
as write_lock. So, we have used allocation out of the lock to avoid
lockdep warn but it's not good for readability and fainally, I met
another lockdep splat between init_lock and cpu_hotplug from
kmem_cache_destroy during working zsmalloc compaction. :(

Yes, the ideal is to remove horrible init_lock of zram in rw path.
This patch removes it in rw path and instead, add atomic refcount
for meta lifetime management and completion to free meta in process
context. It's important to free meta in process context because
some of resource destruction needs mutex lock, which could be held
if we releases the resource in reclaim context so it's deadlock,
again.

Signed-off-by: Sergey Senozhatsky 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 85 ++-
 drivers/block/zram/zram_drv.h | 20 +-
 2 files changed, 71 insertions(+), 34 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index aa5a4c5..c6d505c 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -55,7 +55,7 @@ static DEVICE_ATTR_RO(name);
 
 static inline int init_done(struct zram *zram)
 {
-   return zram->meta != NULL;
+   return zram->disksize != 0;
 }
 
 static inline struct zram *dev_to_zram(struct device *dev)
@@ -358,6 +358,18 @@ out_error:
return NULL;
 }
 
+static inline bool zram_meta_get(struct zram *zram)
+{
+   if (atomic_inc_not_zero(&zram->refcount))
+   return true;
+   return false;
+}
+
+static inline void zram_meta_put(struct zram *zram)
+{
+   atomic_dec(&zram->refcount);
+}
+
 static void update_position(u32 *index, int *offset, struct bio_vec *bvec)
 {
if (*offset + bvec->bv_len >= PAGE_SIZE)
@@ -719,6 +731,10 @@ static void zram_bio_discard(struct zram *zram, u32 index,
 
 static void zram_reset_device(struct zram *zram, bool reset_capacity)
 {
+   struct zram_meta *meta;
+   struct zcomp *comp;
+   u64 disksize;
+
down_write(&zram->init_lock);
 
zram->limit_pages = 0;
@@ -728,19 +744,32 @@ static void zram_reset_device(struct zram *zram, bool 
reset_capacity)
return;
}
 
-   zcomp_destroy(zram->comp);
-   zram->max_comp_streams = 1;
-   zram_meta_free(zram->meta, zram->disksize);
-   zram->meta = NULL;
+   meta = zram->meta;
+   comp = zram->comp;
+   disksize = zram->disksize;
+   zram->disksize = 0;
+   /*
+* ->refcount will go down to 0 eventually and rw handler cannot
+* handle further I/O by init_done checking.
+*/
+   zram_meta_put(zram);
+   /*
+* We want to free zram_meta in process context to avoid
+* deadlock between reclaim path and any other locks
+*/
+   wait_event(zram->io_done, atomic_read(&zram->refcount) == 0);
+
/* Reset stats */
memset(&zram->stats, 0, sizeof(zram->stats));
+   zram->max_comp_streams = 1;
 
-   zram->disksize = 0;
if (reset_capacity)
set_capacity(zram->disk, 

[PATCH 1/5] checkpatch: Improve seq_print->seq_puts suggestion

[Joe Perches]

From: Heba Aamer 

Improve the format specifier test by removing any %% before
looking for any remaining % format specifier.

Signed-off-by: Heba Aamer 
Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 059c032..7f1804e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4854,7 +4854,8 @@ sub process {
 # check for seq_printf uses that could be seq_puts
if ($sline =~ /\bseq_printf\s*\(.*"\s*\)\s*;\s*$/) {
my $fmt = get_quoted_string($line, $rawline);
-   if ($fmt ne "" && $fmt !~ /[^\\]\%/) {
+   $fmt =~ s/%%//g;
+   if ($fmt !~ /%/) {
if (WARN("PREFER_SEQ_PUTS",
 "Prefer seq_puts to seq_printf\n" . 
$herecurr) &&
$fix) {
-- 
2.1.2

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

Re: [PATCH v2 1/4] tty: serial: Add 8250 earlycon to support noinit option

[Greg Kroah-Hartman]

On Sun, Feb 01, 2015 at 10:45:12PM -0500, Peter Hurley wrote:
> On 02/01/2015 10:16 PM, Eddie Huang wrote:
> > Hi Peter,
> > 
> > On Sun, 2015-02-01 at 13:26 -0500, Peter Hurley wrote:
> >> On 02/01/2015 11:27 AM, Peter Hurley wrote:
> >>> Hi Eddie,
> >>>
> >>> On 01/12/2015 08:08 AM, Eddie Huang wrote:
>  Add earlycon support not only baudrate option, but also add noinit 
>  option.
>  If use noinit option, 8250 earlycon will not init serial hardware and use
>  loader setting.
> >>>
> >>> I see this went into Greg's tty-testing branch.
> >>>
> >>> The only point of this is to not program the divisor, right?
> >>>
> >>> I ask because early_serial8250_setup() could already handle this without
> >>> extra options by simply not doing divisor programming if no baud option is
> >>> present.
> >>
> >> Does the patch below work for your use-case?
> >>
> >> [ Note: the patch applies to 3.19-rcX. To test, your noinit patches need 
> >> to be
> >>   reverted first.
> >> ]
> >>
> >> --- >% ---
> >> From: Peter Hurley 
> >> Subject: [PATCH] serial: 8250_early: Assume uart already initialized if no
> >>  baud option
> >>
> >> The  option string is not supplied if the earlycon
> >> is started via devicetree and OF_EARLYCON_DECLARE(). The option string
> >> is also not required if started via kernel command line parameters of
> >> the form:
> >>   earlycon=uart,mmio,
> >>   console=uart,mmio,
> >>
> >> If earlycon_device->baud is 0, then an option string was not supplied.
> >> In this case, assume the uart has already been initialized by the
> >> bootloader or firmware.
> >>
> >> Signed-off-by: Peter Hurley 
> >> ---
> >>  drivers/tty/serial/8250/8250_early.c | 10 --
> >>  1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/tty/serial/8250/8250_early.c 
> >> b/drivers/tty/serial/8250/8250_early.c
> >> index d7b831b..1701d00 100644
> >> --- a/drivers/tty/serial/8250/8250_early.c
> >> +++ b/drivers/tty/serial/8250/8250_early.c
> >> @@ -149,12 +149,18 @@ static int __init early_serial8250_setup(struct 
> >> earlycon_device *device,
> >>return 0;
> >>  
> >>if (!device->baud) {
> >> +  struct uart_port *port = &device->port;
> >> +  unsigned int ier;
> >> +
> >>device->baud = probe_baud(&device->port);
> >>snprintf(device->options, sizeof(device->options), "%u",
> >> device->baud);
> >> -  }
> >>  
> >> -  init_port(device);
> >> +  /* assume the device was initialized, only mask interrupts */
> >> +  ier = serial8250_early_in(port, UART_IER);
> >> +  serial8250_early_out(port, UART_IER, ier & UART_IER_UUE);
> >> +  } else
> >> +  init_port(device);
> > Should add brace in else.
> 
> I don't do that unless I have to.
> 
> > Where is original line here.
> >   early_device = device;
> 
> Whoops :)
> 
> I wrote the patch from a private branch which implements extensible console
> matching (so a console can define its own match function) and a bunch of
> other console cleanup and code removal. In that series, early_device becomes
> unnecessary and is removed.
> 
> I'll respin proper patches on top of Greg's tty-testing branch with reverts
> for the noinit options. I noticed that one of the noinit patches actually
> has the linkage for the mtk earlycon, so I'll be sure to preserve that.

I can just drop the patches in the tty-testing branch, that's what it is
there for :)

Just let me know the specific patches and I will do so, thanks.

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

[PATCH 4/5] checkpatch: Add --strict test for spaces around arithmetic

[Joe Perches]

Some prefer code to have spaces around arithmetic so instead of:
a = b*c+d;
suggest
a = b * c + d;

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index bf23264..32bd31c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3689,7 +3689,22 @@ sub process {
 $op eq '*' or $op eq '/' or
 $op eq '%')
{
-   if ($ctx =~ /Wx[^WCE]|[^WCE]xW/) {
+   if ($check) {
+   if (defined $fix_elements[$n + 
2] && $ctx !~ /[EW]x[EW]/) {
+   if (CHK("SPACING",
+   "spaces 
preferred around that '$op' $at\n" . $hereptr)) {
+   $good = 
rtrim($fix_elements[$n]) . " " . trim($fix_elements[$n + 1]) . " ";
+   
$fix_elements[$n + 2] =~ s/^\s+//;
+   $line_fixed = 1;
+   }
+   } elsif (!defined 
$fix_elements[$n + 2] && $ctx !~ /Wx[OE]/) {
+   if (CHK("SPACING",
+   "space 
preferred before that '$op' $at\n" . $hereptr)) {
+   $good = 
rtrim($fix_elements[$n]) . " " . trim($fix_elements[$n + 1]);
+   $line_fixed = 1;
+   }
+   }
+   } elsif ($ctx =~ /Wx[^WCE]|[^WCE]xW/) {
if (ERROR("SPACING",
  "need consistent 
spacing around '$op' $at\n" . $hereptr)) {
$good = 
rtrim($fix_elements[$n]) . " " . trim($fix_elements[$n + 1]) . " ";
-- 
2.1.2

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

[PATCH 5/5] checkpatch: Make sure a commit reference description uses parentheses

[Joe Perches]

The preferred style for a commit reference in a commit log is:

commit  ("")

A recent commit removed this check for parentheses.  Add it back.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 32bd31c..3642b0d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2191,6 +2191,7 @@ sub process {
my $case = 1;
my $space = 1;
my $hasdesc = 0;
+   my $hasparens = 0;
my $id = '0123456789ab';
my $orig_desc = "commit description";
my $description = "";
@@ -2201,10 +2202,12 @@ sub process {
$case = 0 if ($line =~ 
/\b[Cc]ommit\s+[0-9a-f]{5,40}[^A-F]/);
if ($line =~ 
/\bcommit\s+[0-9a-f]{5,}\s+\("([^"]+)"\)/i) {
$orig_desc = $1;
+   $hasparens = 1;
} elsif ($line =~ /\bcommit\s+[0-9a-f]{5,}\s*$/i &&
 defined $rawlines[$linenr] &&
 $rawlines[$linenr] =~ /^\s*\("([^"]+)"\)/) {
$orig_desc = $1;
+   $hasparens = 1;
} elsif ($line =~ 
/\bcommit\s+[0-9a-f]{5,}\s+\("[^"]+$/i &&
 defined $rawlines[$linenr] &&
 $rawlines[$linenr] =~ /^\s*[^"]+"\)/) {
@@ -2212,12 +2215,13 @@ sub process {
$orig_desc = $1;
$rawlines[$linenr] =~ /^\s*([^"]+)"\)/;
$orig_desc .= " " . $1;
+   $hasparens = 1;
}
 
($id, $description) = git_commit_info($orig_commit,
  $id, $orig_desc);
 
-   if ($short || $long || $space || $case || ($orig_desc 
ne $description)) {
+   if ($short || $long || $space || $case || ($orig_desc 
ne $description) || !$hasparens) {
ERROR("GIT_COMMIT_ID",
  "Please use git commit description style 
'commit <12+ chars of sha1> (\"\")' - ie: '${init_char}ommit $id 
(\"$description\")'\n" . $herecurr);
}
-- 
2.1.2

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

[PATCH 2/5] checkpatch: Improve "no space necessary after cast" test

[Joe Perches]

Code like:
if (a < sizeof() &&
and
{ .len = sizeof() },

incorrectly emits that warning, so add more exceptions to avoid
the warning.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7f1804e..a9baaab 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2541,7 +2541,7 @@ sub process {
}
}
 
-   if ($line =~ /^\+.*(\w+\s*)?\(\s*$Type\s*\)[ 
\t]+(?!$Assignment|$Arithmetic|[,;\({\[\<\>])/ &&
+   if ($line =~ /^\+.*(\w+\s*)?\(\s*$Type\s*\)[ 
\t]+(?!$Assignment|$Arithmetic|[,;:\?\(\{\}\[\<\>]|&&|\|\||\\$)/ &&
(!defined($1) || $1 !~ /sizeof\s*/)) {
if (CHK("SPACING",
"No space is necessary after a cast\n" . 
$herecurr) &&
-- 
2.1.2

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

[PATCH 3/5] checkpatch: Neaten printk_ratelimited message position

[Joe Perches]

Just neatening...

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index a9baaab..bf23264 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3243,7 +3243,7 @@ sub process {
 # check for uses of printk_ratelimit
if ($line =~ /\bprintk_ratelimit\s*\(/) {
WARN("PRINTK_RATELIMITED",
-"Prefer printk_ratelimited or pr__ratelimited to printk_ratelimit\n" . 
$herecurr);
+"Prefer printk_ratelimited or 
pr__ratelimited to printk_ratelimit\n" . $herecurr);
}
 
 # printk should use KERN_* levels.  Note that follow on printk's on the
-- 
2.1.2

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

[PATCH 0/5] checkpatch: Miscellaneous cleanups

[Joe Perches]

Heba Aamer (1):
  checkpatch: Improve seq_print->seq_puts suggestion

Joe Perches (4):
  checkpatch: Improve "no space necessary after cast" test
  checkpatch: Neaten printk_ratelimited message position
  checkpatch: Add --strict test for spaces around arithmetic
  checkpatch: Make sure a commit reference description uses parentheses

 scripts/checkpatch.pl | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

-- 
2.1.2

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

Re: [PATCH Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

[Viresh Kumar]

On 2 February 2015 at 09:46, ethan zhao  wrote:
>  We am talking about the policy allocation and de-allocation. right ?
>  I showed you the cpufreq_policy_free(policy) doesn't check kobject
>  refcount  as above.
>
>  Hmmm, you are still sleeping in the kobject, wake up and don't mix
>  water anymore.

It would be nice if we give each other the respect we deserve, And talk
about concrete points here.

>> if (!cpufreq_suspended)
>>  cpufreq_policy_put_kobj(policy);
>>
>> static void cpufreq_policy_put_kobj(struct cpufreq_policy *policy)
>> {
>>  ...
>>
>>  kobject_put(kobj);
>>
>>  /*
>>  * We need to make sure that the underlying kobj is
>>  * actually not referenced anymore by anybody before we
>>  * proceed with unloading.
>>  */
>>  pr_debug("waiting for dropping of refcount\n");
>>  wait_for_completion(cmp);
>> }

I gave you exactly what you wanted to go through, but it seems you
haven't tried enough.

Before freeing policy with cpufreq_policy_free(), we call
cpufreq_policy_put_kobj(). Now what does this function do? It waits
for the completion to fire (wait_for_completion()). This completion
will only fire when refcount of a kobject becomes zero.

Initially when we create the kobject, it is initialized to one. And the
last kobject_put() you see above in cpufreq_policy_put_kobj()
makes it zero. All other cpufreq_cpu_get() and put() should happen
in pairs, otherwise this refcount will never be zero again.

As soon as the refcount becomes zero, we are sure no one else is
using the policy structure anymore. And so we free it with
cpufreq_policy_free().

That routines doesn't have any tricks and simply frees the policy.
Because, before calling cpufreq_policy_put_kobj(), we have set
the per-cpu variable to NULL, nobody else will get the policy
structure by calling cpufreq_cpu_get(). And that's what my patch
tried to solve.

Let me know if I wasn't explanatory enough..

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

[initramfs] Kernel panic - not syncing: junk in compressed archive

[Fengguang Wu]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git 
initramfs

commit 8dd45530cb1353fbd058d42a3e6d32bde811429b
Author: Mimi Zohar 
AuthorDate: Tue Dec 23 18:27:34 2014 -0500
Commit: Mimi Zohar 
CommitDate: Fri Jan 30 13:42:29 2015 -0500

initramfs: separate reading cpio method from header

In preparation for adding xattr support, read the CPIO method
separately from the rest of the header.

Signed-off-by: Mimi Zohar 

+-++++
| | 7bea7ff67e | 8dd45530cb 
| 870a4dc46e |
+-++++
| boot_successes  | 60 | 0  
| 0  |
| boot_failures   | 0  | 20 
| 11 |
| Kernel_panic-not_syncing:junk_in_compressed_archive | 0  | 20 
| 11 |
| backtrace:populate_rootfs   | 0  | 20 
| 11 |
| backtrace:kernel_init_freeable  | 0  | 20 
| 11 |
+-++++

[0.157126] pci :00:01.0: Activating ISA DMA hang workarounds
[0.157648] pci :00:02.0: Video device with shadowed ROM
[0.158116] PCI: CLS 0 bytes, default 64
[0.158459] Kernel panic - not syncing: junk in compressed archive
[0.158932] CPU: 0 PID: 1 Comm: swapper Not tainted 3.19.0-rc4-g8dd4553 #5
[0.159485] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[0.160116]  d2121770 d2121770 d2045edc c4d34984 d2045ef4 c4d33ea5 c5036200 
d2121770
[0.160116]  c5036200 c51e2b1f d2045f10 c51e2b44 c4f58381 c4f12230 d2121770 
c5036200
[0.160116]  c51e2b1f d2045f84 c460041e 00d0 c4f1c126 c51e2b1f c51e14ba 
c502d814
[0.160116] Call Trace:
[0.160116]  [] dump_stack+0x16/0x18
[0.160116]  [] panic+0x87/0x1a2
[0.160116]  [] ? do_format+0x71/0x71
[0.160116]  [] populate_rootfs+0x25/0xee
[0.160116]  [] ? do_format+0x71/0x71
[0.160116]  [] do_one_initcall+0x7e/0x1d0
[0.160116]  [] ? do_format+0x71/0x71
[0.160116]  [] ? repair_env_string+0x12/0x54
[0.160116]  [] kernel_init_freeable+0xdb/0x158
[0.160116]  [] kernel_init+0xb/0xe0
[0.160116]  [] ? schedule_tail+0x12/0x60
[0.160116]  [] ret_from_kernel_thread+0x20/0x30
[0.160116]  [] ? rest_init+0xa0/0xa0

Elapsed time: 5
qemu-system-x86_64 -cpu kvm64 -enable-kvm -kernel 
/kernel/i386-randconfig-j1-01312211/8dd45530cb1353fbd058d42a3e6d32bde811429b/vmlinuz-3.19.0-rc4-g8dd4553
 -append 'hung_task_panic=1 earlyprintk=ttyS0,115200 debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal  root=/dev/ram0 
rw 
link=/kbuild-tests/run-queue/kvm/i386-randconfig-j1-01312211/linux-devel:devel-jaketown-smoke-201501312324:8dd45530cb1353fbd058d42a3e6d32bde811429b:bisect-linux-4/.vmlinuz-8dd45530cb1353fbd058d42a3e6d32bde811429b-20150201141752-18-ivb41
 branch=linux-devel/devel-jaketown-smoke-201501312324 
BOOT_IMAGE=/kernel/i386-randconfig-j1-01312211/8dd45530cb1353fbd058d42a3e6d32bde811429b/vmlinuz-3.19.0-rc4-g8dd4553
 drbd.minor_count=8'  -initrd /kernel-tests/initrd/quantal-core-i386.cgz -m 320 
-smp 2 -net nic,vlan=1,model=e1000 -net user,vlan=1 -boot order=nc -no-reboot 
-watchdog i6300esb -rtc base=localtime -pidfile 
/dev/shm/kboot/pid-quantal-ivb41-108 -serial 
file:/dev/shm/kboot/serial-quantal-ivb41-108 -daemonize -display none -monitor 
null 

git bisect start 870a4dc46e425037bd3ffacbb683e845a34fceda 
a6391a924cf5a16761ccd6b45094a7d5b9aeebac --
git bisect good 87155b7311bfec75b590b823b11f77adf2a16412  # 11:42 20+  
0  tpm: merge duplicate transmit_cmd() functions
git bisect good 3eda7d0ea3a0365aa72a2007f9450f314d92f065  # 11:52 20+  
0  tpm/tpm_i2c_stm_st33: Change tpm_i2c_stm_st33.h to tpm_stm_st33.h
git bisect good 9d5a5f65fcabb876cb0092901d56627bd5cbfc44  # 12:28 20+  
0  Merge branch 'smack-for-3.20-rebased' of 
git://git.gitorious.org/smack-next/kernel into next
git bisect good 90200f19160734feceb92a3a054864c340242699  # 12:29 20+  
0  Merge branch 'smack-for-3.20-rebased' of 
git://git.gitorious.org/smack-next/kernel into next
git bisect good 7bea7ff67e0cbb30f53ebee7194e238491ddeaab  # 13:41 20+  
0  ima: /proc/keys is now mandatory
git bisect  bad 8dd45530cb1353fbd058d42a3e6d32bde811429b  # 14:18  0- 
20  initramfs: separate reading cpio method from header
# first bad commit: [8dd45530cb1353fbd058d42a3e6d32bde811429b] initramfs: 
se

Re: [PATCH Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

[ethan zhao]

On 2015/2/2 12:09, Viresh Kumar wrote:

On 2 February 2015 at 09:36, ethan zhao  wrote:

  Is that an idea it supposed to be or fact ?

if (!cpufreq_suspended)
 cpufreq_policy_free(policy);

  static void cpufreq_policy_free(struct cpufreq_policy *policy)
{
 free_cpumask_var(policy->related_cpus);
 free_cpumask_var(policy->cpus);
 kfree(policy);
}

  It seems
  you just think about it ideally in mind.

 We am talking about the policy allocation and de-allocation. right ?
 I showed you the cpufreq_policy_free(policy) doesn't check kobject
 refcount  as above.

 Hmmm, you are still sleeping in the kobject, wake up and don't mix
 water anymore.

Thanks,
Ethan



if (!cpufreq_suspended)
 cpufreq_policy_put_kobj(policy);

static void cpufreq_policy_put_kobj(struct cpufreq_policy *policy)
{
 ...

 kobject_put(kobj);

 /*
 * We need to make sure that the underlying kobj is
 * actually not referenced anymore by anybody before we
 * proceed with unloading.
 */
 pr_debug("waiting for dropping of refcount\n");
 wait_for_completion(cmp);
}


--
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 Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

[Viresh Kumar]

On 2 February 2015 at 09:36, ethan zhao  wrote:
>  Is that an idea it supposed to be or fact ?
>
> if (!cpufreq_suspended)
> cpufreq_policy_free(policy);
>
>  static void cpufreq_policy_free(struct cpufreq_policy *policy)
> {
> free_cpumask_var(policy->related_cpus);
> free_cpumask_var(policy->cpus);
> kfree(policy);
> }
>
>  It seems you just think about it ideally in mind.

if (!cpufreq_suspended)
cpufreq_policy_put_kobj(policy);

static void cpufreq_policy_put_kobj(struct cpufreq_policy *policy)
{
...

kobject_put(kobj);

/*
* We need to make sure that the underlying kobj is
* actually not referenced anymore by anybody before we
* proceed with unloading.
*/
pr_debug("waiting for dropping of refcount\n");
wait_for_completion(cmp);
}
--
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 Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

[ethan zhao]

On 2015/2/2 11:59, Viresh Kumar wrote:

On 2 February 2015 at 09:26, ethan zhao  wrote:

  How to prevent the policy to be freed between

cpufreq_cpu_get()  and cpufreq_cpu_put() ?

kobject_get() increases the reference count of a policy and the policy
will only be freed when this is zero. And it will only be zero once all
cpufreq_cpu_get() are matched with corresponding cpufreq_cpu_put().

 Is that an idea it supposed to be or fact ?

if (!cpufreq_suspended)
cpufreq_policy_free(policy);

 static void cpufreq_policy_free(struct cpufreq_policy *policy)
{
free_cpumask_var(policy->related_cpus);
free_cpumask_var(policy->cpus);
kfree(policy);
}

 It seems you just think about it ideally in mind.

 Thanks,
 Ethan



You are maxing up the water with sand ?

:)


--
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 08/12] drm: bridge/dw_hdmi: add audio config interfaces

[Daniel Kurtz]

Hi ykk,

On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan  wrote:
>
> On 01/31/2015 06:48 AM, Russell King - ARM Linux wrote:
>>
>>> +void hdmi_audio_clk_enable(struct dw_hdmi *hdmi)
>>> +{
>>> +   if (hdmi->audio_enable)
>>> +   return;
>>> +
>>> +   mutex_lock(&hdmi->audio_mutex);
>>> +   hdmi->audio_enable = true;
>>> +   hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
>>> HDMI_MC_CLKDIS);
>>> +   mutex_unlock(&hdmi->audio_mutex);
>>
>> This is racy.  The test needs to be within the mutex-protected region.
>
> This function will be called by other driver (dw-hdmi-audio), both modify
> the variable "hdmi->audio_enable", so i add the mutex-protected.

>From your comment it isn't clear whether you understand what Russell meant.
He is say you should do the following:

{
   mutex_lock(&hdmi->audio_mutex);

   if (hdmi->audio_enable) {
  mutex_unlock(&hdmi->audio_mutex);
  return;
   }
   hdmi->audio_enable = true;
   hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);

   mutex_unlock(&hdmi->audio_mutex);
}

By the way, it doesn't matter that the function is called from another driver.
What matters is that this function can be called concurrently on
multiple different threads of execution to change the hdmi audio
enable state.
>From DRM land, it is called with DRM lock held when enabling/disabling
hdmi audio (mode_set / DPMS).
It is also called from audio land, when enabling/disabling audio in
response to some audio events (userspace ioctls?).  I'm not sure
exactly how the audio side works, or what locks are involved, but this
mutex synchronizes calls from these two worlds to ensure that
"hdmi->audio_enable" field always matches the current (intended)
status of the hdmi audio clock.  This would be useful, for example, if
you needed to temporarily disable all HDMI clocks during a mode set,
and then restore the audio clock to its pre-mode_set state:

  // temporarily disable hdmi audio clk
  dw_hdmi_audio_clk_disable(hdmi);
  // do mode_set ...
  dw_hdmi_audio_clk_reenable(hdmi);

 static void dw_hdmi_audio_clk_reenable()
 {
mutex_lock()
if (hdmi->audio_enable)
  dw_hdmi_audio_clk_enable(hdmi)
mutex_unlock()
  }

However, AFAICT, the "hdmi->audio_enable" field is never actually used
like this here or in later patches, so it and the mutex do not seem to
actually be doing anything useful.  In this patch it is probably
better to just drop the mutex and audio_enable, and add them as a
preparatory patch in the patch set where they will actually be used.

-Dan
--
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: [PATCHv2 1/1] cpufreq: exynos: allow modular build

[Viresh Kumar]

On 1 February 2015 at 00:29, Eduardo Valentin  wrote:
> From: Arnd Bergmann 
>
> The exynos cpufreq driver code recently gained a dependency on the
> cooling code, which may be a loadable module. This breaks an ARM
> allmodconfig build:
>
> drivers/built-in.o: In function `exynos_cpufreq_probe':
> :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register'
>
> To avoid this problem, change cpufreq Kconfig to allow the drivers
> to be loadable modules as well and enforce a dependency on the
> thermal module.
>
> This change, in order to allow module builds on this cpufreq
> driver, properly constructs the driver into a single module,
> instead of several modules. The change also keeps the proper
> platform dependency, and therefore, it wont load in platforms
> that are not supposed to be loaded. The user will be able to
> build the support for all platforms, or select which platforms
> (s)he wants (as originally), except that now it can be a module,
> instead.
>
> Besides, it will still keep the driver only on those configs
> that expect it to be on. And it won't compile/load on platforms
> that it is not supposed to. It brings the config ARM_EXYNOS_CPU_FREQ_BOOST_SW
> closer to this driver, so it looks better in the menuconfig.
>
> We intentionally change ARM_EXYNOS5440_CPUFREQ to be tristate too, to
> avoid future troubles.
>
> Cc: Viresh Kumar 
> Cc: Kukjin Kim 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux...@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> Fixes: e725d26c4857 ("cpufreq: exynos: Use device tree to determine if 
> cpufreq cooling should be registered")
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/cpufreq/Kconfig.arm | 44 ++--
>  drivers/cpufreq/Makefile|  9 +
>  2 files changed, 31 insertions(+), 22 deletions(-)
> ---
> Changes from V1:
> - Instead of having several modules, the driver now is constructed by several
> files into a single module, depending on config.
> - The patch does not change existing user defconfigs.
>
> If no objections, I will include this in into my -fixes branch.
>
> Cheers,
>
> Eduardo Valentin
>
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 0f9a2c3..1b06fc4 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -26,13 +26,21 @@ config ARM_VEXPRESS_SPC_CPUFREQ
>
>
>  config ARM_EXYNOS_CPUFREQ
> -   bool
> +   tristate "SAMSUNG EXYNOS CPUfreq Driver"
> +   depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || 
> SOC_EXYNOS5250
> +   depends on THERMAL
> +   help
> + This adds the CPUFreq driver for Samsung EXYNOS platforms.
> + Supported SoC versions are:
> +Exynos4210, Exynos4212, Exynos4412, and Exynos5250.
> +
> + If in doubt, say N.
>
>  config ARM_EXYNOS4210_CPUFREQ
> bool "SAMSUNG EXYNOS4210"
> depends on CPU_EXYNOS4210
> +   depends on ARM_EXYNOS_CPUFREQ
> default y
> -   select ARM_EXYNOS_CPUFREQ
> help
>   This adds the CPUFreq driver for Samsung EXYNOS4210
>   SoC (S5PV310 or S5PC210).
> @@ -42,8 +50,8 @@ config ARM_EXYNOS4210_CPUFREQ
>  config ARM_EXYNOS4X12_CPUFREQ
> bool "SAMSUNG EXYNOS4x12"
> depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
> +   depends on ARM_EXYNOS_CPUFREQ
> default y
> -   select ARM_EXYNOS_CPUFREQ
> help
>   This adds the CPUFreq driver for Samsung EXYNOS4X12
>   SoC (EXYNOS4212 or EXYNOS4412).
> @@ -53,28 +61,14 @@ config ARM_EXYNOS4X12_CPUFREQ
>  config ARM_EXYNOS5250_CPUFREQ
> bool "SAMSUNG EXYNOS5250"
> depends on SOC_EXYNOS5250
> +   depends on ARM_EXYNOS_CPUFREQ
> default y
> -   select ARM_EXYNOS_CPUFREQ
> help
>   This adds the CPUFreq driver for Samsung EXYNOS5250
>   SoC.
>
>   If in doubt, say N.
>
> -config ARM_EXYNOS5440_CPUFREQ
> -   bool "SAMSUNG EXYNOS5440"
> -   depends on SOC_EXYNOS5440
> -   depends on HAVE_CLK && OF
> -   select PM_OPP
> -   default y
> -   help
> - This adds the CPUFreq driver for Samsung EXYNOS5440
> - SoC. The nature of exynos5440 clock controller is
> - different than previous exynos controllers so not using
> - the common exynos framework.
> -
> - If in doubt, say N.
> -
>  config ARM_EXYNOS_CPU_FREQ_BOOST_SW
> bool "EXYNOS Frequency Overclocking - Software"
> depends on ARM_EXYNOS_CPUFREQ && THERMAL
> @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
>
>   If in doubt, say N.
>
> +config ARM_EXYNOS5440_CPUFREQ
> +   tristate "SAMSUNG EXYNOS5440"
> +   depends on SOC_EXYNOS5440
> +   depends on HAVE_CLK && OF
> +   select PM_OPP
> +   default y
> +   help
> + This adds the CPUFreq driver for Samsung EXYNOS5440
> + SoC. The nature of exynos5

[PATCH] CODA: Do not opencode kvfree

[green]

From: Oleg Drokin 

Signed-off-by: Oleg Drokin 
---
 fs/coda/coda_linux.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/coda/coda_linux.h b/fs/coda/coda_linux.h
index d6f7a76..537754b 100644
--- a/fs/coda/coda_linux.h
+++ b/fs/coda/coda_linux.h
@@ -73,7 +73,7 @@ void coda_sysctl_clean(void);
 
 
 #define CODA_FREE(ptr,size) \
-do { if (size < PAGE_SIZE) kfree((ptr)); else vfree((ptr)); } while (0)
+do { kvfree((ptr)); } while (0)
 
 /* inode to cnode access functions */
 
-- 
2.1.0

--
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 v1 2/2] zram: remove init_lock in zram_make_request

[Sergey Senozhatsky]

On (02/02/15 11:44), Minchan Kim wrote:
> > sure, I did think about this. and I actually didn't find any reason not
> > to use ->refcount there. if user wants to reset the device, he first
> > should umount it to make bdev->bd_holders check happy. and that's where
> > IOs will be failed. so it makes sense to switch to ->refcount there, IMHO.
> 
> If we use zram as block device itself(not a fs or swap) and open the
> block device as !FMODE_EXCL, bd_holders will be void.
> 

hm.
I don't mind to use ->disksize there, but personally I'd maybe prefer
to use ->refcount, which just looks less hacky. zram's most common use
cases are coming from ram swap device or ram device with fs. so it looks
a bit like we care about some corner case here.

just my opinion, no objections against ->disksize != 0.

I need to check fs/block_dev. can we switch away from ->bd_holders?

> Another topic: As I didn't see enough fs/block_dev.c bd_holders in zram
> would be mess. I guess we need to study hotplug of device and implement
> it for zram reset rather than strange own konb. It should go TODO. :(

ok, need to investigate this later.
let's land current activities first.

-ss
--
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 Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

[Viresh Kumar]

On 2 February 2015 at 09:26, ethan zhao  wrote:
>  How to prevent the policy to be freed between
>
> cpufreq_cpu_get()  and cpufreq_cpu_put() ?

kobject_get() increases the reference count of a policy and the policy
will only be freed when this is zero. And it will only be zero once all
cpufreq_cpu_get() are matched with corresponding cpufreq_cpu_put().

> You are maxing up the water with sand ?

:)
--
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] gfs2: use __vmalloc GFP_NOFS for fs-related allocations.

[green]

From: Oleg Drokin 

leaf_dealloc uses vzalloc as a fallback to kzalloc(GFP_NOFS), so
it clearly does not want any shrinker activity within the fs itself.
convert vzalloc into __vmalloc(GFP_NOFS|__GFP_ZERO) to better achieve
this goal.

Signed-off-by: Oleg Drokin 
---
 fs/gfs2/dir.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
index c5a34f0..6371192 100644
--- a/fs/gfs2/dir.c
+++ b/fs/gfs2/dir.c
@@ -1896,7 +1896,8 @@ static int leaf_dealloc(struct gfs2_inode *dip, u32 
index, u32 len,
 
ht = kzalloc(size, GFP_NOFS | __GFP_NOWARN);
if (ht == NULL)
-   ht = vzalloc(size);
+   ht = __vmalloc(size, GFP_NOFS | __GFP_NOWARN | __GFP_ZERO,
+  PAGE_KERNEL);
if (!ht)
return -ENOMEM;
 
-- 
2.1.0

--
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 Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

[ethan zhao]

On 2015/2/2 11:43, Viresh Kumar wrote:

On 2 February 2015 at 09:08, ethan zhao  wrote:

We take cpufreq_driver_lock() here, and so this will
block thread B.

  No, there is no  cpufreq_driver_lock acquired between

  cpufreq_cpu_get()  and cpufreq_cpu_put()

I am not saying that the lock is taken between them. But within
cpufreq_cpu_get() to make sure policy doesn't get freed while we
are doing kobject_get().

 How to prevent the policy to be freed between

cpufreq_cpu_get()  and cpufreq_cpu_put() ?


 beginning the deference of policyThread B:
 ... ... __cpufreq_remove_dev_finish()
cpufreq_policy_free(policy);


Perhaps move policy->rwsem out side the policy structure is a way to
avoid
it completely.
and you could stopping the PPC thread stepping forward as my patch as
temporary workaround.

I couldn't understand your problem completely. Apart from giving a
detailed
look of what's going on both threads, always specify where the BUG
actually
is..

The problem is you are using a rwsem inside policy structure to protect its
assessment, that is bad design.

What is the current bug you are facing right now, I haven't understood it well.
Also a lock within the structure isn't new. Its all over the kernel. I
don't understand
why you say its a bad design.

You are maxing up the water with sand ?

Thanks,
Ethan



--
viresh


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

[RFC] change non-atomic bitops method

[Wang, Yalin]

This patch change non-atomic bitops,
add a if() condition to test it, before set/clear the bit.
so that we don't need dirty the cache line, if this bit
have been set or clear. On SMP system, dirty cache line will
need invalidate other processors cache line, this will have
some impact on SMP systems.

Signed-off-by: Yalin Wang 
---
 include/asm-generic/bitops/non-atomic.h | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/bitops/non-atomic.h 
b/include/asm-generic/bitops/non-atomic.h
index 697cc2b..e4ef18a 100644
--- a/include/asm-generic/bitops/non-atomic.h
+++ b/include/asm-generic/bitops/non-atomic.h
@@ -17,7 +17,9 @@ static inline void __set_bit(int nr, volatile unsigned long 
*addr)
unsigned long mask = BIT_MASK(nr);
unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
 
-   *p  |= mask;
+   if ((*p & mask) == 0)
+   *p  |= mask;
+
 }
 
 static inline void __clear_bit(int nr, volatile unsigned long *addr)
@@ -25,7 +27,8 @@ static inline void __clear_bit(int nr, volatile unsigned long 
*addr)
unsigned long mask = BIT_MASK(nr);
unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
 
-   *p &= ~mask;
+   if ((*p & mask) != 0)
+   *p &= ~mask;
 }
 
 /**
@@ -60,7 +63,8 @@ static inline int __test_and_set_bit(int nr, volatile 
unsigned long *addr)
unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
unsigned long old = *p;
 
-   *p = old | mask;
+   if ((old & mask) == 0)
+   *p = old | mask;
return (old & mask) != 0;
 }
 
@@ -79,7 +83,8 @@ static inline int __test_and_clear_bit(int nr, volatile 
unsigned long *addr)
unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
unsigned long old = *p;
 
-   *p = old & ~mask;
+   if ((old & mask) != 0)
+   *p = old & ~mask;
return (old & mask) != 0;
 }
 
-- 
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 2/2] zram: remove init_lock in zram_make_request

[Sergey Senozhatsky]

On (02/02/15 11:45), Minchan Kim wrote:
> On Mon, Feb 02, 2015 at 10:59:40AM +0900, Sergey Senozhatsky wrote:
> > On (02/02/15 10:43), Minchan Kim wrote:
> > > >  static inline int init_done(struct zram *zram)
> > > >  {
> > > > -   return zram->meta != NULL;
> > > > +   return atomic_read(&zram->refcount);
> > > 
> > > As I said previous mail, it could make livelock so I want to use disksize
> > > in here to prevent further I/O handling.
> > 
> > just as I said in my previous email -- is this live lock really possible?
> > we need to umount device to continue with reset. and umount will kill IOs 
> > out
> > of our way.
> > 
> > the other reset caller is  __exit zram_exit(). but once again, I don't
> > expect this function being executed on mounted device and module being
> > in use.
> > 
> > 
> > > > +static inline void zram_put(struct zram *zram)
> > > > +{
> > > > +   if (atomic_dec_and_test(&zram->refcount))
> > > > +   complete(&zram->io_done);
> > > > +}
> > > 
> > > Although I suggested this complete, it might be rather overkill(pz,
> > > understand me it was work in midnight. :))
> > > Instead, we could use just atomic_dec in here and
> > > use wait_event(event, atomic_read(&zram->refcount) == 0) in reset.
> > > 
> > 
> > yes, I think it can do the trick.
> 
> Hey, it's not a trick. It suits for the our goal well. Completion
> was too much, I think.
> 

sure :)

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