Re: [RESEND PATCH 2/6] soc: Mediatek: Add SCPSYS CPU power domain driver

2015-06-22 Thread Sascha Hauer
Hi Scott,

On Fri, Jun 19, 2015 at 02:01:17AM +0800, Scott Shu wrote:
> This adds a CPU power domain driver for the Mediatek SCPSYS unit on
> MT6580.

This seems to be support for the very same hardware as I am posting
here:

https://lkml.org/lkml/2015/6/22/41

We should consolidate this.

My driver is currently handles all power domains except the CPUs while
yours handles only the CPUs.
I currently haven't looked whether CPUs can just be part of a power
domain aswell, but if that works this would probably be the way to go.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[GIT PULL] arch/microblaze changes for 4.2-rc1

2015-06-22 Thread Michal Simek
Hi Linus,

please pull these microblaze chagnes to your tree.

Thanks,
Michal

The following changes since commit d4a4f75cd8f29cd9464a5a32e9224a91571d6649:

  Linux 4.1-rc7 (2015-06-07 20:23:50 -0700)

are available in the git repository at:

  git://git.monstr.eu/linux-2.6-microblaze.git tags/microblaze-4.2-rc1

for you to fetch changes up to c4fa9a6ae285ec4777d0524a4ee9c9039a5a4c28:

  microblaze/PCI: Remove unnecessary struct pci_dev declaration
(2015-06-08 10:03:14 +0200)


Microblaze patches for 4.2-rc1

- Some PCI fixups
- Add new MB versions
- Sparse fixups


Bjorn Helgaas (3):
  microblaze/PCI: Remove unused declarations
  microblaze/PCI: Remove unnecessary pci_bus_find_capability()
declaration
  microblaze/PCI: Remove unnecessary struct pci_dev declaration

Michal Simek (2):
  microblaze: Add missing release version code
  microblaze: Label local function static

 arch/microblaze/include/asm/pci.h| 17 -
 arch/microblaze/kernel/cpu/cpuinfo.c |  2 ++
 arch/microblaze/kernel/dma.c |  1 +
 arch/microblaze/kernel/kgdb.c|  2 +-
 4 files changed, 4 insertions(+), 18 deletions(-)


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature


[PATCH v2 2/2] powerpc32: rewrite of csum_partial_copy_generic based of copy_tofrom_user

2015-06-22 Thread Christophe Leroy
csum_partial_copy_generic() does the same as copy_tofrom_user and also
calculates the checksum during the copy. Unlike copy_tofrom_user(), the existing
version of csum_partial_copy_generic() doesn't take benefit of the cache

This patch is a rewrite of csum_partial_copy_generic() based on
copy_tofrom_user().
The previous version of csum_partial_copy_generic() was handling errors. Now we
have the checksum wrapper functions to handle the error case like in powerpc64
so we can make the error case simple: just return -EFAULT.
copy_tofrom_user() only has r12 available => we use it for the checksum
r7 and r8 which contains pointers to error feedback are used, so we stack them.

On a TCP benchmark using socklib on the loopback interface on which checksum
offload and scatter/gather have been deactivated, we get about 20% performance
increase.

Signed-off-by: Christophe Leroy 
---
v2: no change, patch reformatted with format-patch -M -C

 arch/powerpc/lib/checksum_32.S | 320 +++--
 1 file changed, 209 insertions(+), 111 deletions(-)

diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S
index 7874e8a..7b95a68 100644
--- a/arch/powerpc/lib/checksum_32.S
+++ b/arch/powerpc/lib/checksum_32.S
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -103,123 +104,220 @@ _GLOBAL(csum_partial)
  *
  * csum_partial_copy_generic(src, dst, len, sum, src_err, dst_err)
  */
+#define CSUM_COPY_16_BYTES_WITHEX(n)   \
+8 ## n ## 0:   \
+   lwz r7,4(r4);   \
+8 ## n ## 1:   \
+   lwz r8,8(r4);   \
+8 ## n ## 2:   \
+   lwz r9,12(r4);  \
+8 ## n ## 3:   \
+   lwzur10,16(r4); \
+8 ## n ## 4:   \
+   stw r7,4(r6);   \
+   adder12,r12,r7; \
+8 ## n ## 5:   \
+   stw r8,8(r6);   \
+   adder12,r12,r8; \
+8 ## n ## 6:   \
+   stw r9,12(r6);  \
+   adder12,r12,r9; \
+8 ## n ## 7:   \
+   stwur10,16(r6); \
+   adder12,r12,r10
+
+#define CSUM_COPY_16_BYTES_EXCODE(n)   \
+.section __ex_table,"a";   \
+   .align  2;  \
+   .long   8 ## n ## 0b,src_error; \
+   .long   8 ## n ## 1b,src_error; \
+   .long   8 ## n ## 2b,src_error; \
+   .long   8 ## n ## 3b,src_error; \
+   .long   8 ## n ## 4b,dst_error; \
+   .long   8 ## n ## 5b,dst_error; \
+   .long   8 ## n ## 6b,dst_error; \
+   .long   8 ## n ## 7b,dst_error; \
+   .text
+
+   .text
+   .stabs  "arch/powerpc/lib/",N_SO,0,0,0f
+   .stabs  "checksum_32.S",N_SO,0,0,0f
+0:
+
+CACHELINE_BYTES = L1_CACHE_BYTES
+LG_CACHELINE_BYTES = L1_CACHE_SHIFT
+CACHELINE_MASK = (L1_CACHE_BYTES-1)
+
 _GLOBAL(csum_partial_copy_generic)
-   addic   r0,r6,0
-   subir3,r3,4
-   subir4,r4,4
-   srwi.   r6,r5,2
-   beq 3f  /* if we're doing < 4 bytes */
-   andi.   r9,r4,2 /* Align dst to longword boundary */
-   beq+1f
-81:lhz r6,4(r3)/* do 2 bytes to get aligned */
-   addir3,r3,2
-   subir5,r5,2
-91:sth r6,4(r4)
-   addir4,r4,2
-   addcr0,r0,r6
-   srwi.   r6,r5,2 /* # words to do */
-   beq 3f
-1: srwi.   r6,r5,4 /* # groups of 4 words to do */
-   beq 10f
-   mtctr   r6
-71:lwz r6,4(r3)
-72:lwz r9,8(r3)
-73:lwz r10,12(r3)
-74:lwzur11,16(r3)
-   adder0,r0,r6
-75:stw r6,4(r4)
-   adder0,r0,r9
-76:stw r9,8(r4)
-   adder0,r0,r10
-77:stw r10,12(r4)
-   adder0,r0,r11
-78:stwur11,16(r4)
-   bdnz71b
-10:rlwinm. r6,r5,30,30,31  /* # words left to do */
-   beq 13f
-   mtctr   r6
-82:lwzur9,4(r3)
-92:stwur9,4(r4)
-   adder0,r0,r9
-   bdnz82b
-13:andi.   r5,r5,3
-3: cmpwi   0,r5,2
-   blt+4f
-83:lhz r6,4(r3)
-   addir3,r3,2
-   subir5,r5,2
-93:sth r6,4(r4)
+   stwur1,-16(r1)
+   stw r7,12(r1)
+   stw r8,8(r1)
+
+   andi.   r0,r4,1 /* is destination address even ? */
+   cmplwi  cr7,r0,0
+   addic   r12,r6,0
+   addir6,r4,-4
+   neg r0,r4
+   addir4,r3,-4
+   andi.   r0,r0,CACHELINE_MASK/* # bytes to start of cache line */
+   beq 58f
+
+   cmplw   0,r5,r0 /* is this more than total to do? */
+   blt 63f /* if not much to do */
+   andi.   r8,r0,3 /* get it word-aligned first */
+   mtctr   r8
+   beq+61f
+   li  r3,0
+70:lbz r9,4(r4)/* do some bytes */
+   addir4,r4,1
+   slwir3,r3,8
+   rlwimi  

[PATCH v2 1/2] powerpc32: checksum_wrappers_64 becomes checksum_wrappers

2015-06-22 Thread Christophe Leroy
The powerpc64 checksum wrapper functions adds the csum_and_copy_to_user() which
otherwise is implemented in include/net/checksum.h by using csum_partial() then
copy_to_user()

Those two wrapper fonctions are also applicable to powerpc32 as it is based on
the use of csum_partial_copy_generic() which also exists on powerpc32

This patch renames arch/powerpc/lib/checksum_wrappers_64.c to
arch/powerpc/lib/checksum_wrappers.c and
makes it non-conditional to CONFIG_WORD_SIZE

Signed-off-by: Christophe Leroy 
---
v2: no change, patch reformatted with format-patch -M -C

 arch/powerpc/include/asm/checksum.h  | 9 -
 arch/powerpc/lib/Makefile| 3 +--
 arch/powerpc/lib/{checksum_wrappers_64.c => checksum_wrappers.c} | 0
 3 files changed, 1 insertion(+), 11 deletions(-)
 rename arch/powerpc/lib/{checksum_wrappers_64.c => checksum_wrappers.c} (100%)

diff --git a/arch/powerpc/include/asm/checksum.h 
b/arch/powerpc/include/asm/checksum.h
index 8251a3b..0ffd793 100644
--- a/arch/powerpc/include/asm/checksum.h
+++ b/arch/powerpc/include/asm/checksum.h
@@ -56,21 +56,12 @@ extern __wsum csum_partial_copy_generic(const void *src, 
void *dst,
  int len, __wsum sum,
  int *src_err, int *dst_err);
 
-#ifdef __powerpc64__
 #define _HAVE_ARCH_COPY_AND_CSUM_FROM_USER
 extern __wsum csum_and_copy_from_user(const void __user *src, void *dst,
  int len, __wsum sum, int *err_ptr);
 #define HAVE_CSUM_COPY_USER
 extern __wsum csum_and_copy_to_user(const void *src, void __user *dst,
int len, __wsum sum, int *err_ptr);
-#else
-/*
- * the same as csum_partial, but copies from src to dst while it
- * checksums.
- */
-#define csum_partial_copy_from_user(src, dst, len, sum, errp)   \
-csum_partial_copy_generic((__force const void *)(src), (dst), (len), 
(sum), (errp), NULL)
-#endif
 
 #define csum_partial_copy_nocheck(src, dst, len, sum)   \
 csum_partial_copy_generic((src), (dst), (len), (sum), NULL, NULL)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index a47e142..e46b068 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -22,8 +22,7 @@ obj64-$(CONFIG_SMP)   += locks.o
 obj64-$(CONFIG_ALTIVEC)+= vmx-helper.o
 
 ifeq ($(CONFIG_GENERIC_CSUM),)
-obj-y  += checksum_$(CONFIG_WORD_SIZE).o
-obj-$(CONFIG_PPC64)+= checksum_wrappers_64.o
+obj-y  += checksum_$(CONFIG_WORD_SIZE).o checksum_wrappers.o
 endif
 
 obj-$(CONFIG_PPC_EMULATE_SSTEP)+= sstep.o ldstfp.o
diff --git a/arch/powerpc/lib/checksum_wrappers_64.c 
b/arch/powerpc/lib/checksum_wrappers.c
similarity index 100%
rename from arch/powerpc/lib/checksum_wrappers_64.c
rename to arch/powerpc/lib/checksum_wrappers.c
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 0/2] powerpc32: optimisation of csum_partial_copy_generic()

2015-06-22 Thread Christophe Leroy
This patch optimises csum_partial_copy_generic() by making use of cache
instructions (dcbt/dcbz) just like copy_tofrom_user() does

On a TCP benchmark using socklib on the loopback interface on which checksum
offload and scatter/gather have been deactivated, we get about 20% performance
increase.

v2 is just a new issue with format-patch -M -C, other changes.

Christophe Leroy (2):
  powerpc32: checksum_wrappers_64 becomes checksum_wrappers
  powerpc32: rewrite of csum_partial_copy_generic based of copy_tofrom_user

 arch/powerpc/include/asm/checksum.h|   9 -
 arch/powerpc/lib/Makefile  |   3 +-
 arch/powerpc/lib/checksum_32.S | 320 ++---
 ...{checksum_wrappers_64.c => checksum_wrappers.c} |   0
 4 files changed, 210 insertions(+), 122 deletions(-)
 rename arch/powerpc/lib/{checksum_wrappers_64.c => checksum_wrappers.c} (100%)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


staging patch not in staging tree (was: Re: [PATCH 1/2] staging: ft1000-usb: fixed table alignment)

2015-06-22 Thread Sudip Mukherjee
On Mon, Jun 22, 2015 at 07:06:49PM +0530, Sudip Mukherjee wrote:
> On Mon, Jun 22, 2015 at 03:02:37PM +0200, Peter Karlsson wrote:
> > On 2015-06-22 06:29, Sudip Mukherjee wrote:
> > > which tree have you been using?
> > > Greg will have three staging tree, use staging-testing
> > 
> > I have used linux-next tree :/
> well, I am now confused why linux-next is not having this struct.
> at line 415 of drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
> struct timeval tv; is there in staging-next. And today's linux-next
> has merged staging-next. Then how that struct timeval is not there in
> linux-next ?

I was doing a bisect to see why the files are differing in staging-next
and linux-next. And it turns out to be:
8b37bf430656 ("staging: ft1000: Replace timeval and time_t with time64_t")

which didn't go through the staging tree.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Linux 3.4.108

2015-06-22 Thread Zefan Li
I'm announcing the release of the 3.4.108 kernel.

All users of the 3.4 kernel series must upgrade.

The updated 3.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

---

Adrian Knoth (1):
  ALSA: hdspm - Constrain periods to 2 on older cards

Al Viro (6):
  debugfs: leave freeing a symlink body until inode eviction
  autofs4 copy_dev_ioctl(): keep the value of ->size we'd used for 
allocation
  sunrpc: fix braino in ->poll()
  gadgetfs: use-after-free in ->aio_read()
  ocfs2: _really_ sync the right range
  don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()

Alan Stern (3):
  USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)
  USB: fix use-after-free bug in usb_hcd_unlink_urb()
  USB: usbfs: don't leak kernel data in siginfo

Aleksander Morgado (1):
  xhci: fix reporting of 0-sized URBs in control endpoint

Alex Deucher (6):
  drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary
  drm/radeon: do a posting read in r100_set_irq
  drm/radeon: do a posting read in rs600_set_irq
  drm/radeon: do a posting read in r600_set_irq
  drm/radeon: do a posting read in evergreen_set_irq
  drm/radeon: do a posting read in si_set_irq

Alexandre Belloni (1):
  ARM: at91: pm: fix at91rm9200 standby

Andrey Ryabinin (1):
  smack: fix possible use after frees in task_security() callers

Andy Lutomirski (2):
  x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization
  x86/asm/entry/32: Fix user_mode() misuses

Arik Nemtsov (1):
  mac80211: set only VO as a U-APSD enabled AC

Bart Van Assche (1):
  Defer processing of REQ_PREEMPT requests for blocked devices

Ben Greear (1):
  Fix lockup related to stop_machine being stuck in __do_softirq.

Ben Hutchings (2):
  splice: Apply generic position and size checks to each write
  xen-pciback: Add name prefix to global 'permissive' variable

Benjamin Tissoires (1):
  Input: synaptics - handle spurious release of trackstick buttons

Bob Copeland (1):
  mac80211: drop unencrypted frames in mesh fwding

Brian King (1):
  bnx2x: Force fundamental reset for EEH recovery

Brian Silverman (1):
  sched: Fix RLIMIT_RTTIME when PI-boosting to RT

Chen Jie (1):
  jffs2: fix handling of corrupted summary length

Chris Wilson (1):
  ACPI / video: Load the module even if ACPI is disabled

Chuck Lever (1):
  xprtrdma: Free the pd if ib_query_qp() fails

Dan Carpenter (3):
  ALSA: off by one bug in snd_riptide_joystick_probe()
  tcm_fc: missing curly braces in ft_invl_hw_context()
  ipvs: uninitialized data with IP_VS_IPV6

Daniel Borkmann (1):
  rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY

Daniel Mack (1):
  ALSA: snd-usb: add quirks for Roland UA-22

Daniel Martin (1):
  Input: synaptics - query min dimensions for fw v8.1

Darrick J. Wong (2):
  dm io: reject unsupported DISCARD requests with EOPNOTSUPP
  dm io: deal with wandering queue limits when handling REQ_DISCARD and 
REQ_WRITE_SAME

David Disseldorp (1):
  cifs: fix use-after-free bug in find_writable_file

David Hildenbrand (1):
  KVM: s390: base hrtimer on a monotonic clock

David Miller (1):
  radeon: Do not directly dereference pointers to BIOS area.

Dmitry Eremin-Solenikov (4):
  ARM: pxa: add regulator_has_full_constraints to corgi board file
  ARM: pxa: add regulator_has_full_constraints to poodle board file
  ARM: pxa: add regulator_has_full_constraints to spitz board file
  ARM: 8284/1: sa1100: clear RCSR_SMR on resume

Dmitry M. Fedin (1):
  ALSA: usb - Creative USB X-Fi Pro SB1095 volume knob support

Dmitry Torokhov (1):
  Input: synaptics - fix middle button on Lenovo 2015 products

Dmitry Tunin (1):
  Bluetooth: ath3k: Add support of AR3012 bluetooth 13d3:3423 device

Doug Goldstein (2):
  USB: ftdi_sio: Added custom PID for Synapse Wireless product
  USB: ftdi_sio: Use jtag quirk for SNAP Connect E10

Eli Cohen (1):
  IB/core: Avoid leakage from kernel to user space

Eric Dumazet (2):
  netfilter: xt_socket: fix a stack corruption bug
  softirq: reduce latencies

Eric Nelson (1):
  ASoC: sgtl5000: remove useless register write clearing CHRGPUMP_POWERUP

Feng Tang (1):
  x86/reboot: Fix a warning message triggered by stop_other_cpus()

Florian Westphal (1):
  net: make skb_gso_segment error handling more robust

Grazvydas Ignotas (1):
  mm/memory.c: actually remap enough memory

Hui Wang (1):
  ALSA: hda - Add one more node in the EAPD supporting candidate list

Ian Abbott (2):
  staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back
 

Re: [PATCH v2 00/14] x86: Rewrite exit-to-userspace code

2015-06-22 Thread Andy Lutomirski
On Mon, Jun 22, 2015 at 12:50 PM, Andy Lutomirski  wrote:
> On Thu, Jun 18, 2015 at 12:08 PM, Andy Lutomirski  wrote:
>> This is the first big batch of x86 asm-to-C conversion patches.
>
> Ingo, what's the plan for these?  I found a minor design error that's
> harmless so far (I think), but I don't know whether I should fix it as
> a follow-up or do a v3.

Never mind.  Don't apply them.  I found a real bug.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] fs/file.c: don't acquire files->file_lock in fd_install()

2015-06-22 Thread Eric Dumazet
On Mon, 2015-06-22 at 03:32 +0100, Al Viro wrote:
> On Tue, Apr 28, 2015 at 09:25:03PM -0700, Eric Dumazet wrote:
> 
> > @@ -553,11 +572,20 @@ void __fd_install(struct files_struct *files, 
> > unsigned int fd,
> > struct file *file)
> >  {
> > struct fdtable *fdt;
> > -   spin_lock(>file_lock);
> > -   fdt = files_fdtable(files);
> > +
> > +   rcu_read_lock_sched();
> > +
> > +   while (unlikely(files->resize_in_progress)) {
> > +   rcu_read_unlock_sched();
> > +   wait_event(files->resize_wait, !files->resize_in_progress);
> > +   rcu_read_lock_sched();
> > +   }
> > +   /* coupled with smp_wmb() in expand_fdtable() */
> > +   smp_rmb();
> > +   fdt = rcu_dereference_sched(files->fdt);
> > BUG_ON(fdt->fd[fd] != NULL);
> > rcu_assign_pointer(fdt->fd[fd], file);
> > -   spin_unlock(>file_lock);
> > +   rcu_read_unlock_sched();
> 
> Umm...  You've taken something that was safe to use in atomic contexts
> and turned into something that might wait for GFP_KERNEL allocation; what's
> to guarantee that no users get broken by that?  At the very least, you want
> to slap might_sleep() in there - the actual sleep is going to be very rare,
> so it would be an extremely hard to reproduce and debug.
> 
> AFAICS, all current in-tree users should be safe, but fd_install() is exported
> and quiet changes of that sort are rather antisocial.  Generally I don't give
> a damn about out-of-tree code, but this one is over the top.
> 
> I _think_ it's otherwise OK, but please, add might_sleep() *AND* a note in
> Documentation/filesystems/porting.
> 

Good points. I am currently traveling and will address this asap.

Thanks


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm-exynos tree

2015-06-22 Thread Inki Dae
Hi Stephen,

On 2015년 06월 23일 10:52, Stephen Rothwell wrote:
> Hi Inki,
> 
> After merging the drm-exynos tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

Thanks for report.

I found out this problem. That is because below patch missed "static"
when defining of_graph_get_endpoint_by_regs function,
a0f7001c18ca ("of: add helper for getting endpoint node of specific
identifiers")

For this, I will fix and post it soon.

Thanks,
Inki Dae

> 
> drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_regs':
> adv7604.c:(.text+0x586c): multiple definition of 
> `of_graph_get_endpoint_by_regs'
> drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here
> drivers/media/platform/soc_camera/atmel-isi.o: In function 
> `of_graph_get_endpoint_by_regs':
> atmel-isi.c:(.text+0x1ec9): multiple definition of 
> `of_graph_get_endpoint_by_regs'
> drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
> first defined here
> drivers/media/platform/soc_camera/rcar_vin.o: In function 
> `of_graph_get_endpoint_by_regs':
> rcar_vin.c:(.text+0x307c): multiple definition of 
> `of_graph_get_endpoint_by_regs'
> drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
> first defined here
> 
> Caused by commit:
> 
>   a0f7001c18ca ("of: add helper for getting endpoint node of specific 
> identifiers")
> 
> I have used the drm-exynos from next-20150622 for today.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH-v2 0/3] mfd: 88pm800: Add Device tree support

2015-06-22 Thread Vaibhav Hiremath



On Thursday 18 June 2015 12:28 AM, Vaibhav Hiremath wrote:

This patch-series adds support for Device tree to 88PM800 mfd driver.
It also enabled configuration of irq clear method through DT.

Testing::
  - Boot tested on PXA1928 based platform.
  - probe of mfd, rtc and regulator function passing successfully.
  - Basic read operations on registers


V1 => V1
===
Link to V1: http://lkml.iu.edu/hypermail/linux/kernel/1505.3/04386.html

   - Split binding changes from original commit
   - Updated binding info as per Rob's suggestion
   - Dropped PATCH 4/4, as discussed during review
   - Dropped PATCH 3/4, as it is independent RTC code change,
 so will submit it separately to ease merging.
   - Fixed all other minor comments

Attempt has been made to push some of the patches to the list sometime
back in 2013.

Link to previous patch submission:
 https://lkml.org/lkml/2013/8/14/86

Vaibhav Hiremath (3):
   mfd: 88pm800: Add device tree support
   mfd: 88pm800: Allow configuration of interrupt clear method
   mfd: devicetree: bindings: Add new 88pm800 mfd binding

  Documentation/devicetree/bindings/mfd/88pm800.txt | 60 +++
  drivers/mfd/88pm800.c | 40 +--
  include/linux/mfd/88pm80x.h   |  6 ++-
  3 files changed, 99 insertions(+), 7 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mfd/88pm800.txt




Any update on this?

If there are no review comments, then can it be queued ?

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/3] drm/msm: dsi host: add missing of_node_put()

2015-06-22 Thread Archit Taneja


On 06/22/2015 09:30 PM, Srinivas Kandagatla wrote:



On 22/06/15 15:54, Archit Taneja wrote:

Decrement device node refcount if of_get_child_by_name is successfully
called.

Signed-off-by: Archit Taneja 
---
  drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index de04009..1751659 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1582,6 +1582,8 @@ int msm_dsi_host_register(struct mipi_dsi_host
*host, bool check_defer)
  node = of_get_child_by_name(msm_host->pdev->dev.of_node,
  "panel");
  if (node) {
+of_node_put(node);
+


Atleast from the current state of code, It looks like the driver is
going to refer to the node of_node_put?, So I think this is not the
right place to have of_node_put.


That's right. I made the same mistake in the later patches too. I'll fix 
these.


Thanks,
Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v6 1/9] nvmem: Add a simple NVMEM framework for nvmem providers

2015-06-22 Thread Joe Perches
On Tue, 2015-06-23 at 00:08 +0100, Srinivas Kandagatla wrote:
> This patch adds just providers part of the framework just to enable easy
> review.
[]
>  include/linux/nvmem-provider.h |  54 ++

Unless there are going to be users of nvmem-provider.h
outside of the drivers/nvmem directory, perhaps that
file (and nvmem-consumer.h) should be in drivers/nvmem/


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] IB/srpt: Convert use of __constant_cpu_to_beXX to cpu_to_beXX

2015-06-22 Thread Vaishali Thakkar
In little endian cases, the macro cpu_to_be{16,32,64} unfolds to
__swab{16,32,64} which provides special case for constants. In
big endian cases, __constant_cpu_to_be{16,32,64} and
cpu_to_be{16,32,64} expand directly to the same expression. So,
replace __constant_cpu_to_be{16,32,64} with cpu_to_be{16,32,64}
with the goal of getting rid of the definitions of
__constant_cpu_to_be{16,32,64} completely.

The Coccinelle semantic patch that performs this transformation
is as follows:

@@expression x;@@

(
- __constant_cpu_to_be16(x)
+ cpu_to_be16(x)
|
- __constant_cpu_to_be32(x)
+ cpu_to_be32(x)
|
- __constant_cpu_to_be64(x)
+ cpu_to_be64(x)
)

Signed-off-by: Vaishali Thakkar 
---
 drivers/infiniband/ulp/srpt/ib_srpt.c | 61 ++-
 1 file changed, 25 insertions(+), 36 deletions(-)

diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c 
b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 9b84b4c..e673cc2 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -303,7 +303,7 @@ static void srpt_get_iou(struct ib_dm_mad *mad)
int i;
 
ioui = (struct ib_dm_iou_info *)mad->data;
-   ioui->change_id = __constant_cpu_to_be16(1);
+   ioui->change_id = cpu_to_be16(1);
ioui->max_controllers = 16;
 
/* set present for slot 1 and empty for the rest */
@@ -331,13 +331,13 @@ static void srpt_get_ioc(struct srpt_port *sport, u32 
slot,
 
if (!slot || slot > 16) {
mad->mad_hdr.status
-   = __constant_cpu_to_be16(DM_MAD_STATUS_INVALID_FIELD);
+   = cpu_to_be16(DM_MAD_STATUS_INVALID_FIELD);
return;
}
 
if (slot > 2) {
mad->mad_hdr.status
-   = __constant_cpu_to_be16(DM_MAD_STATUS_NO_IOC);
+   = cpu_to_be16(DM_MAD_STATUS_NO_IOC);
return;
}
 
@@ -349,10 +349,10 @@ static void srpt_get_ioc(struct srpt_port *sport, u32 
slot,
iocp->device_version = cpu_to_be16(sdev->dev_attr.hw_ver);
iocp->subsys_vendor_id = cpu_to_be32(sdev->dev_attr.vendor_id);
iocp->subsys_device_id = 0x0;
-   iocp->io_class = __constant_cpu_to_be16(SRP_REV16A_IB_IO_CLASS);
-   iocp->io_subclass = __constant_cpu_to_be16(SRP_IO_SUBCLASS);
-   iocp->protocol = __constant_cpu_to_be16(SRP_PROTOCOL);
-   iocp->protocol_version = __constant_cpu_to_be16(SRP_PROTOCOL_VERSION);
+   iocp->io_class = cpu_to_be16(SRP_REV16A_IB_IO_CLASS);
+   iocp->io_subclass = cpu_to_be16(SRP_IO_SUBCLASS);
+   iocp->protocol = cpu_to_be16(SRP_PROTOCOL);
+   iocp->protocol_version = cpu_to_be16(SRP_PROTOCOL_VERSION);
iocp->send_queue_depth = cpu_to_be16(sdev->srq_size);
iocp->rdma_read_depth = 4;
iocp->send_size = cpu_to_be32(srp_max_req_size);
@@ -380,13 +380,13 @@ static void srpt_get_svc_entries(u64 ioc_guid,
 
if (!slot || slot > 16) {
mad->mad_hdr.status
-   = __constant_cpu_to_be16(DM_MAD_STATUS_INVALID_FIELD);
+   = cpu_to_be16(DM_MAD_STATUS_INVALID_FIELD);
return;
}
 
if (slot > 2 || lo > hi || hi > 1) {
mad->mad_hdr.status
-   = __constant_cpu_to_be16(DM_MAD_STATUS_NO_IOC);
+   = cpu_to_be16(DM_MAD_STATUS_NO_IOC);
return;
}
 
@@ -437,7 +437,7 @@ static void srpt_mgmt_method_get(struct srpt_port *sp, 
struct ib_mad *rq_mad,
break;
default:
rsp_mad->mad_hdr.status =
-   __constant_cpu_to_be16(DM_MAD_STATUS_UNSUP_METHOD_ATTR);
+   cpu_to_be16(DM_MAD_STATUS_UNSUP_METHOD_ATTR);
break;
}
 }
@@ -493,11 +493,11 @@ static void srpt_mad_recv_handler(struct ib_mad_agent 
*mad_agent,
break;
case IB_MGMT_METHOD_SET:
dm_mad->mad_hdr.status =
-   __constant_cpu_to_be16(DM_MAD_STATUS_UNSUP_METHOD_ATTR);
+   cpu_to_be16(DM_MAD_STATUS_UNSUP_METHOD_ATTR);
break;
default:
dm_mad->mad_hdr.status =
-   __constant_cpu_to_be16(DM_MAD_STATUS_UNSUP_METHOD);
+   cpu_to_be16(DM_MAD_STATUS_UNSUP_METHOD);
break;
}
 
@@ -1539,7 +1539,7 @@ static int srpt_build_cmd_rsp(struct srpt_rdma_ch *ch,
memset(srp_rsp, 0, sizeof *srp_rsp);
srp_rsp->opcode = SRP_RSP;
srp_rsp->req_lim_delta =
-   __constant_cpu_to_be32(1 + atomic_xchg(>req_lim_delta, 0));
+   cpu_to_be32(1 + atomic_xchg(>req_lim_delta, 0));
srp_rsp->tag = tag;
srp_rsp->status = status;
 
@@ -1589,8 +1589,7 @@ static int srpt_build_tskmgmt_rsp(struct srpt_rdma_ch *ch,
memset(srp_rsp, 0, sizeof *srp_rsp);
 
srp_rsp->opcode = SRP_RSP;
-   srp_rsp->req_lim_delta = __constant_cpu_to_be32(1
-  

Re: Crypto Update for 4.2

2015-06-22 Thread Herbert Xu
On Mon, Jun 22, 2015 at 09:26:51PM -0700, Linus Torvalds wrote:
>
> So it looks to me like those AEAD interface changes already make sure
> to use the full 64 bits of the sequence number.
> 
> But if I'm wrong, please holler. You clearly know both sides of this,
> since you wrote all the patches involved, so I'd like you to
> double-check me.

Yes the AEAD conversion does the right thing and uses the full 64
bits of the sequence number.  In fact it was during that conversion
when I noticed the bug and sent in a fix to Steffen.

Thanks for the heads up!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: Crypto Update for 4.2

2015-06-22 Thread Linus Torvalds
On Mon, Jun 22, 2015 at 1:44 AM, Herbert Xu  wrote:
>
> Here is the crypto update for 4.2:

So this generates conflicts with your earlier changes (that I got
through the networking tree - they are your patches, but they went
through Steffen Klassert and then David Miller).

I resolved them, but I want you to double-check the end result.

Some of the conflicts are just trivial (but annoying) conflicts due to
whitespace changes to the vmx routines.

But the changes to net/ipv4/esp4.c and net/ipv6/esp6.c are actual real
code conflicts, even though the in the merge they look like no change
at all, because I picked your side and the changes on the other side
just went away.

I did that, because ss far as I can tell, the changes in commits
7021b2e1cddd and 000ae7b2690e (that switch esp4/6 over to the new AEAD
interface) obviate the commits I got earlier to use the high-order
sequence number bits for IV generation.

So it looks to me like those AEAD interface changes already make sure
to use the full 64 bits of the sequence number.

But if I'm wrong, please holler. You clearly know both sides of this,
since you wrote all the patches involved, so I'd like you to
double-check me.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[Patch v1] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel

2015-06-22 Thread Jiang Liu
The data type resource_size_t may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT. So reject ACPI resource descriptors which
will cause resource_size_t overflow with 32bit kernel

This issue was triggered on a platform running 32bit kernel with an
ACPI resource descriptor with address range [0x4-0xf].
Please refer to https://lkml.org/lkml/2015/6/19/277 for more information.

Reported-by: Boszormenyi Zoltan 
Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces to 
simplify implementation")
Signed-off-by: Jiang Liu 
Cc: sta...@vger.kernel.org # 4.0
---
 drivers/acpi/resource.c |   24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 8244f013f210..f1c966e05078 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -193,6 +193,7 @@ static bool acpi_decode_space(struct resource_win *win,
u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 : ACPI_DECODE_16;
bool wp = addr->info.mem.write_protect;
u64 len = attr->address_length;
+   u64 start, end, offset = 0;
struct resource *res = >res;
 
/*
@@ -204,9 +205,6 @@ static bool acpi_decode_space(struct resource_win *win,
pr_debug("ACPI: Invalid address space min_addr_fix %d, 
max_addr_fix %d, len %llx\n",
 addr->min_address_fixed, addr->max_address_fixed, len);
 
-   res->start = attr->minimum;
-   res->end = attr->maximum;
-
/*
 * For bridges that translate addresses across the bridge,
 * translation_offset is the offset that must be added to the
@@ -214,12 +212,22 @@ static bool acpi_decode_space(struct resource_win *win,
 * primary side. Non-bridge devices must list 0 for all Address
 * Translation offset bits.
 */
-   if (addr->producer_consumer == ACPI_PRODUCER) {
-   res->start += attr->translation_offset;
-   res->end += attr->translation_offset;
-   } else if (attr->translation_offset) {
+   if (addr->producer_consumer == ACPI_PRODUCER)
+   offset = attr->translation_offset;
+   else if (attr->translation_offset)
pr_debug("ACPI: translation_offset(%lld) is invalid for 
non-bridge device.\n",
 attr->translation_offset);
+   start = attr->minimum + offset;
+   end = attr->maximum + offset;
+
+   win->offset = offset;
+   res->start = start;
+   res->end = end;
+   if (sizeof(resource_size_t) < sizeof(u64) &&
+   (offset != win->offset || start != res->start || end != res->end)) {
+   pr_warn("acpi resource window ([%#llx-%#llx] ignored, not CPU 
addressable)\n",
+   attr->minimum, attr->maximum);
+   return false;
}
 
switch (addr->resource_type) {
@@ -236,8 +244,6 @@ static bool acpi_decode_space(struct resource_win *win,
return false;
}
 
-   win->offset = attr->translation_offset;
-
if (addr->producer_consumer == ACPI_PRODUCER)
res->flags |= IORESOURCE_WINDOW;
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/1] scsi: remove redundant NULL check before kfree

2015-06-22 Thread Maninder Singh
There is no need of NULL check before kfree,
So removing the same.

Signed-off-by: Maninder Singh 
Reviewed-by: Rohit Thapliyal 
---
 drivers/scsi/aic94xx/aic94xx_init.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/aic94xx/aic94xx_init.c 
b/drivers/scsi/aic94xx/aic94xx_init.c
index 4b135cc..a449fde 100644
--- a/drivers/scsi/aic94xx/aic94xx_init.c
+++ b/drivers/scsi/aic94xx/aic94xx_init.c
@@ -589,8 +589,7 @@ static void asd_destroy_ha_caches(struct asd_ha_struct 
*asd_ha)
if (asd_ha->hw_prof.scb_ext)
asd_free_coherent(asd_ha, asd_ha->hw_prof.scb_ext);
 
-   if (asd_ha->hw_prof.ddb_bitmap)
-   kfree(asd_ha->hw_prof.ddb_bitmap);
+   kfree(asd_ha->hw_prof.ddb_bitmap);
asd_ha->hw_prof.ddb_bitmap = NULL;
 
for (i = 0; i < ASD_MAX_PHYS; i++) {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] virtio-blk: Allow extended partitions

2015-06-22 Thread Fam Zheng
This will allow up to DISK_MAX_PARTS (256) partitions, with for example
GPT in the guest. Otherwise, the partition scan code will only discover
the first 15 partitions.

Signed-off-by: Fam Zheng 
---
 drivers/block/virtio_blk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 5ea2f0b..97daa70 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -657,6 +657,7 @@ static int virtblk_probe(struct virtio_device *vdev)
vblk->disk->private_data = vblk;
vblk->disk->fops = _fops;
vblk->disk->driverfs_dev = >dev;
+   vblk->disk->flags |= GENHD_FL_EXT_DEVT;
vblk->index = index;
 
/* configure queue flush support */
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file

2015-06-22 Thread Michael Ellerman
On Fri, 2015-06-19 at 10:12 -0400, David Long wrote:
> On 06/19/15 00:19, Michael Ellerman wrote:
> > On Mon, 2015-06-15 at 12:42 -0400, David Long wrote:
> >> From: "David A. Long" 
> >>
> >> The pt_regs_offset structure is used for HAVE_REGS_AND_STACK_ACCESS_API
> >>   feature and has identical definitions in four different arch ptrace.h
> >> include files. It seems unlikely that definition would ever need to be
> >> changed regardless of architecture so lets move it into
> >> include/linux/ptrace.h.
> >>
> >> Signed-off-by: David A. Long 
> >> ---
> >>   arch/powerpc/kernel/ptrace.c | 5 -
> >
> > Built and booted on powerpc, but is there an easy way to actually test the 
> > code
> > paths in question?
> >
> 
> There is an easy way to "smoke test" it on all archiectures that also 
> implement kprobes (which powerpc does).  If I'm understanding the 
> powerpc code correctly (WRT register naming conventions) just do the 
> following:
> 
> cd /sys/kernel/debug/tracing
> echo 'p do_fork %gpr0' > kprobe_events
> echo 1 > events/kprobes/enable
> ls
> cat trace
> echo 0 > events/kprobes/enable
> 
> Every fork() call done on the system between those two echo commands 
> (hence the "ls") should append a line to the trace file.  For a more 
> exhaustive test one could repeat this sequence for every register in the 
> architecture.

OK, so I went the whole hog and did:

$ echo 'p do_fork %gpr0 %gpr1 %gpr2 %gpr3 %gpr4 %gpr5 %gpr6 %gpr7 %gpr8 %gpr9 
%gpr10 %gpr11 %gpr12 %gpr13 %gpr14 %gpr15 %gpr16 %gpr17 %gpr18 %gpr19 %gpr20 
%gpr21 %gpr22 %gpr23 %gpr24 %gpr25 %gpr26 %gpr27 %gpr28 %gpr29 %gpr30 %gpr31 
%nip %msr %ctr %link %xer %ccr %softe %trap %dar %dsisr' > kprobe_events

And I get:

bash-2057  [001] d...   535.433941: p_do_fork_0: 
(do_fork+0x8/0x490) arg1=0xc00094d0 arg2=0xc001fbe9be30 
arg3=0xc1133bb8 arg4=0x1200011 arg5=0x0 arg6=0x0 arg7=0x0 
arg8=0x3fff7c885940 arg9=0x1 arg10=0xc001fbe9bea0 arg11=0x0 arg12=0xc01 
arg13=0xc00094c8 arg14=0xcfdc0480 arg15=0x0 arg16=0x2200 
arg17=0x1016d6e8 arg18=0x0 arg19=0x4400 arg20=0x0 arg21=0x10037c82208 
arg22=0x1017b008 arg23=0x10143d18 arg24=0x10178854 arg25=0x10144f90 
arg26=0x10037c821e8 arg27=0x0 arg28=0x0 arg29=0x0 arg30=0x0 arg31=0x809 
arg32=0x3788c010 arg33=0xc00a7fe8 arg34=0x80029033 
arg35=0xc00094c8 arg36=0xc00094d0 arg37=0x0 arg38=0x4844 
arg39=0x1 arg40=0x700 arg41=0xc001fbe9bd50 arg42=0xc001fbe9bd30

Which is ugly as hell, but appears unchanged since before your patch.

I take it it's expected that the names are not decoded in the output?

Also I wonder why we choose "gpr" when "r" is the more usual prefix on powerpc.
I guess we can add new aliases to the table.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: Re: [PATCH v2] perf probe: Fix failure to probe events on arm

2015-06-22 Thread Masami Hiramatsu
On 2015/06/20 6:08, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jun 18, 2015 at 02:49:10AM +, He Kuang escreveu:
>> Fix failure to probe events on arm, problem is introduced by commit
>> 5a51fcd1f30c ("perf probe: Skip kernel symbols which is out of
>> .text"). For some architectures, label '_etext' is not in the .text
>> section(in .notes section for arm/arm64). Label out of .text section is
>> not loaded as symbols and we got a zero value when look up its address,
>> which causes all events be wrongly skiped.
>>
>> This patch skip checking text address range when failed to get the
>> address of '_etext' and fixes the problem.
> 
> Masami, since you guys discussed this patch, can I have your Acked-by?

Oops, I missed the mails..

OK I'll send it.

Thanks!

-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] perf probe: Fix failure to probe events on arm

2015-06-22 Thread Masami Hiramatsu
On 2015/06/18 11:49, He Kuang wrote:
> Fix failure to probe events on arm, problem is introduced by commit
> 5a51fcd1f30c ("perf probe: Skip kernel symbols which is out of
> .text"). For some architectures, label '_etext' is not in the .text
> section(in .notes section for arm/arm64). Label out of .text section is
> not loaded as symbols and we got a zero value when look up its address,
> which causes all events be wrongly skiped.
> 
> This patch skip checking text address range when failed to get the
> address of '_etext' and fixes the problem.
> 
> Problem can be reproduced on arm as following:
> 
>   # perf probe --add='generic_perform_write'
>   generic_perform_write+0 is out of .text, skip it.
>   Probe point 'generic_perform_write' not found.
> Error: Failed to add events.
> 
> After this patch:
> 
>   # perf probe --add='generic_perform_write'
>   Added new event:
> probe:generic_perform_write (on generic_perform_write)
> 
>   You can now use it in all perf tools, such as:
> 
> perf record -e probe:generic_perform_write -aR sleep 1

Looks good to me :)

Acked-by: Masami Hiramatsu 

Thanks!

> 
> Signed-off-by: He Kuang 
> ---
>  tools/perf/util/probe-event.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 076527b..381f23a 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -249,8 +249,12 @@ static void clear_probe_trace_events(struct 
> probe_trace_event *tevs, int ntevs)
>  static bool kprobe_blacklist__listed(unsigned long address);
>  static bool kprobe_warn_out_range(const char *symbol, unsigned long address)
>  {
> + u64 etext_addr;
> +
>   /* Get the address of _etext for checking non-probable text symbol */
> - if (kernel_get_symbol_address_by_name("_etext", false) < address)
> + etext_addr = kernel_get_symbol_address_by_name("_etext", false);
> +
> + if (etext_addr != 0 && etext_addr < address)
>   pr_warning("%s is out of .text, skip it.\n", symbol);
>   else if (kprobe_blacklist__listed(address))
>   pr_warning("%s is blacklisted function, skip it.\n", symbol);
> 


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v5 4/6] drm: bridge/dw_hdmi-i2s-audio: add audio driver

2015-06-22 Thread Yakir Yang

Russell,

在 2015/6/22 18:10, Russell King - ARM Linux 写道:

On Mon, Jun 22, 2015 at 12:06:04PM +0200, Paul Bolle wrote:

But I think there's no platform_device with a "dw-hdmi-i2s-audio" name.
So I wonder whether this MODULE_ALIAS() is actually needed. What breaks
if you leave it out?

+   } else if (hdmi_readb(hdmi, HDMI_CONFIG0_ID) & HDMI_CONFIG0_I2S) {
+   pdevinfo.name = "dw-hdmi-ahb-audio";

This should be "dw-hdmi-i2s-audio" to avoid picking up on my AHB audio
driver.

Yep, thanks a lot ;)

- Yakir


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v5 4/6] drm: bridge/dw_hdmi-i2s-audio: add audio driver

2015-06-22 Thread Yakir Yang

Paul,

在 2015/6/22 18:06, Paul Bolle 写道:

Something I didn't notice in v4, sorry.

On Sat, 2015-06-20 at 00:28 +0800, Yakir Yang wrote:

--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c
+#define DRIVER_NAME "dw-hdmi-i2s-audio"
+MODULE_ALIAS(PLATFORM_MODULE_PREFIX DRIVER_NAME);

0) Side note: this is the first time that PLATFORM_MODULE_PREFIX is used
inside MODULE_ALIAS(). But none of the 1000+ other "platform:" aliases
do that. And neither does 5/6 of this series! That suggests, I think,
that this shouldn't be done.

You could consider adding something like
 #define MODULE_ALIAS_PLATFORM(NAME) MODULE_ALIAS(PLATFORM_MODULE_PREFIX 
NAME)

But then, I think, all the current 1000+ platform: aliases should be
converted to that macro. Would that be worth it?

Yeah, It would be horrible to coverted to that macro  ;)


1) Now on to my remark: this alias seems to be only useful if there also
is a struct platform_device with a "dw-hdmi-i2s-audio" name. Because
that platform_device would, badly summarized, fire of a
"MODALIAS=platform:dw-hdmi-i2s-audio" uevent when created. Which, in its
turn, would trigger userspace to load this module, correct?

But I think there's no platform_device with a "dw-hdmi-i2s-audio" name.
So I wonder whether this MODULE_ALIAS() is actually needed. What breaks
if you leave it out?
Thanks for your attentive comment .  Actually there should be an 
platform device that named "dw-hdmi-i2s-audio" which I misspelt in 
dw_hdmi.c driver.


thanks,
- Yakir


(Likewise for 5/6, but there the platform_device should have a
"rockchip-hdmi-audio" name.)

Thanks,


Paul Bolle







--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v5 5/5] block: loop: support DIO & AIO

2015-06-22 Thread Ming Lei
On Tue, Jun 23, 2015 at 12:00 AM, Christoph Hellwig  wrote:
> On Mon, Jun 22, 2015 at 08:09:55PM +0800, Ming Lei wrote:
>> For the general async interface, it is a bit complicated than sync 
>> interfaces:
>>
>> -  iocb need to be one parameter, because it often depends on callers, such
>> as loop can preallocate it
>> - direct I/O need to be another parameter(in loop we can use the same helper
>> to handle sync request)
>> - bvec and the segment number are another two parameters
>> - not mention the common parameters(file, offset, pos, complete...)
>
> We only really need iocb + iov_iter, they carry everything we need.

Then the helper becomes the fowllowing:

ssize_t vfs_iter_async_write(struct kiocb *kiocb, struct iov_iter *iter)
{
   ssize_t ret;

   iter->type |= WRITE;
   ret = file->f_op->write_iter(, iter);

   return ret;
}

I am wondering its value and we can do that easily in call site, also it isn't
easy to name it since sometimes we may need to let the helper handle
sync requests, such as loop's case.

Thanks,
Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] usb: ci_hdrc_imx: add optional hub clock

2015-06-22 Thread Peter Chen
On Mon, Jun 22, 2015 at 12:54:14AM +0800, Maciej S. Szmigiero wrote:
> This patch adds ability to define optional clock of connected
> USB hub to ChipIdea i.MX usb controller driver.
> 
> This is needed for example for UDOO board.
> Previously, this board DT file used a fact that non-core registers
> of this USB controller have a separate driver (usbmisc_imx) which
> did allow defining a separate clock.
> 
> Because the non-core registers are in fact using the same clock as
> main controller this allowed to use one of such clock definitions
> to enable USB hub clock instead.
> 
> However, since commit 73dea4a912b2
> ("usb: chipidea: usbmisc_imx: delete clock information") this
> possibility no longer exists and loading USB support on this board
> results in a hard SoC lockup.
> 
> Note that this is not specific to particular USB hub chip used,
> rather than to a particular board.
> Since this is a DT-based board there is no board platform file to
> put such clock enable.
> Also, USB bus devices aren't instantiated in DT file since it is an
> enumerable bus.
> 
> NOP PHY also can't be used as clock consumer since this
> USB controller needs a true MXS phy definition, which accepts only
> one clock (different from USB controller one).
> 
> Based on a patch previously submitted by Fabio Estevam, with consent.
> 
> Signed-off-by: Maciej Szmigiero 
> 
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt 
> b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
> index 38a5480..fc65f1c 100644
> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
> @@ -5,6 +5,8 @@ Required properties:
>  - reg: Should contain registers location and length
>  - interrupts: Should contain controller interrupt
>  - fsl,usbphy: phandle of usb phy that connects to the port
> +- clocks: phandles of clocks that drive the controller and optionally
> +  an USB hub connected to it
>  
>  Recommended properies:
>  - phy_type: the type of the phy connected to the core. Should be one
> @@ -20,12 +22,14 @@ Optional properties:
>  - external-vbus-divider: enables off-chip resistor divider for Vbus
>  - maximum-speed: limit the maximum connection speed to "full-speed".
>  - tpl-support: TPL (Targeted Peripheral List) feature for targeted hosts
> +- clock-names: must be "default", "hub" if optional USB hub clock is used
>  
>  Examples:
>  usb@02184000 { /* USB OTG */
>   compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
>   reg = <0x02184000 0x200>;
>   interrupts = <0 43 0x04>;
> + clocks = < IMX6QDL_CLK_USBOH3>;
>   fsl,usbphy = <>;
>   fsl,usbmisc = < 0>;
>   disable-over-current;
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 389f0e0..bb7f859 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -65,6 +65,7 @@ struct ci_hdrc_imx_data {
>   struct usb_phy *phy;
>   struct platform_device *ci_pdev;
>   struct clk *clk;
> + struct clk *clk_hub;
>   struct imx_usbmisc_data *usbmisc_data;
>   bool supports_runtime_pm;
>   bool in_lpm;
> @@ -196,6 +197,16 @@ static int ci_hdrc_imx_probe(struct platform_device 
> *pdev)
>   goto disable_device;
>   }
>  
> + data->clk_hub = devm_clk_get(>dev, "hub");
> + if (!IS_ERR(data->clk_hub)) {
> + ret = clk_prepare_enable(data->clk_hub);
> + if (ret) {
> + dev_err(>dev,
> + "Failed to enable clk_hub: %d\n", ret);
> + goto disable_device;
> + }
> + }
> +

Hi Maciej,

As I said before, the USB HUB is just an USB peripheral, we should
not put a peripheral's clock information to controller driver, I think
hub driver should take responsibilities for it, just like other usb
pheripheral drivers, like usb modem, etc. You can talk it with Alan
Stern about it.

>   platform_set_drvdata(pdev, data);
>  
>   if (data->supports_runtime_pm) {
> @@ -223,6 +234,8 @@ static int ci_hdrc_imx_remove(struct platform_device 
> *pdev)
>   pm_runtime_disable(>dev);
>   pm_runtime_put_noidle(>dev);
>   }
> + if (!IS_ERR(data->clk_hub))
> + clk_disable_unprepare(data->clk_hub);
>   ci_hdrc_remove_device(data->ci_pdev);
>   clk_disable_unprepare(data->clk);
>  
> 

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v5 3/3] locking/qrwlock: Don't contend with readers when setting _QW_WAITING

2015-06-22 Thread Waiman Long

On 06/22/2015 12:21 PM, Will Deacon wrote:

Hi Waiman,

On Fri, Jun 19, 2015 at 04:50:02PM +0100, Waiman Long wrote:

The current cmpxchg() loop in setting the _QW_WAITING flag for writers
in queue_write_lock_slowpath() will contend with incoming readers
causing possibly extra cmpxchg() operations that are wasteful. This
patch changes the code to do a byte cmpxchg() to eliminate contention
with new readers.

[...]


diff --git a/arch/x86/include/asm/qrwlock.h b/arch/x86/include/asm/qrwlock.h
index a8810bf..5678b0a 100644
--- a/arch/x86/include/asm/qrwlock.h
+++ b/arch/x86/include/asm/qrwlock.h
@@ -7,8 +7,7 @@
  #define queued_write_unlock queued_write_unlock
  static inline void queued_write_unlock(struct qrwlock *lock)
  {
-barrier();
-ACCESS_ONCE(*(u8 *)>cnts) = 0;
+   smp_store_release(>wmode, 0);
  }
  #endif

I reckon you could actually use this in the asm-generic header and remove
the x86 arch version altogether. Most architectures support single-copy
atomic byte access and those that don't (alpha?) can just not use qrwlock
(or override write_unlock with atomic_sub).

I already have a patch making this change, so I'm happy either way.


Yes, I am aware of that. If you have a patch to make that change, I am 
fine with that too.


Cheers,
Longman


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 7/8] cpufreq: st: Provide runtime initialised driver for ST's platforms

2015-06-22 Thread Viresh Kumar
On 22-06-15, 16:43, Lee Jones wrote:
> +config ARM_ST_CPUFREQ
> + bool "ST CPUFreq support"

Isn't using ST just too generic? There are multiple SoCs ST has been
involved with, I have worked on a completely different series.
Probably a more relative string is required here, like stih407 ?

> + depends on SOC_STIH407

> diff --git a/drivers/cpufreq/st-cpufreq.c b/drivers/cpufreq/st-cpufreq.c
> +static int st_cpufreq_cmp(const void *a, const void *b)
> +{
> + const struct st_dvfs_tab *a_tab = a, *b_tab = b;
> +
> + if (a_tab->freq > b_tab->freq)
> + return -1;
> +
> + if (a_tab->freq < b_tab->freq)
> + return 1;
> +
> + return 0;
> +}
> +
> +static int st_cpufreq_check_if_matches(struct device_node *child,
> +const char *prop,
> +unsigned int match)
> +{
> + unsigned int dt_major, dt_minor;
> + unsigned int soc_major, soc_minor;
> + const __be32 *tmp;
> + unsigned int val;
> + int len = 0;
> + int i;
> +
> + tmp = of_get_property(child, prop , );
> + if (!tmp || !len)
> + return -EINVAL;
> +
> + val = be32_to_cpup(tmp);
> +
> + len /= sizeof(u32);
> + if (len == 1 && val == 0xff)
> + /*
> +  * If 'cuts' or 'substrate' value is 0xff, it means that
> +  * the entry is valid for ALL cuts and substrates
> +  */
> + goto matchfound;
> +
> + /* Check if this opp node is for us */
> + for (i = 0; i < len; i++) {
> + if (match == val)
> + goto matchfound;
> +
> + if (!strcmp(prop, "st,cuts")) {
> + dt_major  = val & 0xff;;
> + dt_minor  = val >> 8 & 0xff;
> + soc_major = match & 0xff;
> + soc_minor = match >> 8 & 0xff;
> +
> + if (dt_major == soc_major &&
> + (!dt_minor || (dt_minor == soc_minor)))
> + goto matchfound;
> + }
> + val++;
> + }
> +
> + /* No match found */
> + return -EINVAL;
> +
> +matchfound:
> + return 0;
> +}
> +
> +static int st_cpufreq_get_version(struct platform_device *pdev,
> +   unsigned int *minor, unsigned int *major)
> +{
> + struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
> + struct device_node *np = pdev->dev.of_node;
> + struct regmap *syscfg_regmap;
> + unsigned int minor_offset, major_offset;
> + unsigned int socid, minid;
> + int ret;
> +
> + /* Get Major */
> + syscfg_regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> + if (IS_ERR(syscfg_regmap)) {
> + dev_err(>dev,
> + "No syscfg phandle specified in %s [%li]\n",
> + np->full_name, PTR_ERR(syscfg_regmap));
> + return PTR_ERR(syscfg_regmap);
> + }
> +
> + ret = of_property_read_u32_index(np, "st,syscfg",
> +  MAJOR_ID_INDEX, _offset);
> + if (ret) {
> + dev_err(>dev,
> + "No minor number offset provided in %s [%d]\n",
> + np->full_name, ret);
> + return ret;
> + }
> +
> + ret = regmap_read(syscfg_regmap, major_offset, );
> + if (ret)
> + return ret;
> +
> + /* Get Minor */
> + ret = of_property_read_u32_index(np, "st,syscfg-eng",
> +  MINOR_ID_INDEX, _offset);
> + if (ret) {
> + dev_err(>dev, "No minor number offset provided %s [%d]\n",
> + np->full_name, ret);
> + return ret;
> + }
> +
> + ret = regmap_read(ddata->regmap_eng, minor_offset, );
> + if (ret) {
> + dev_err(>dev,
> + "Failed to read the minor number from syscon [%d]\n",
> + ret);
> + return ret;
> + }
> +
> + *major = ((socid >> VERSION_SHIFT) & 0xf) + 1;
> + *minor = minid & 0xf;
> +
> + return 0;
> +}
> +
> +static int st_cpufreq_get_dvfs_info(struct platform_device *pdev)
> +{
> + struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
> + struct st_dvfs_tab *dvfs_tab = >dvfs_tab[0];
> + struct device_node *np = pdev->dev.of_node;
> + struct device_node *opplist, *opp;
> + unsigned int minor = 0, major = 0;
> + int err, ret = 0;
> +
> + opplist = of_get_child_by_name(np, "opp-list");

st,opp-list ?

> + if (!opplist) {
> + dev_err(>dev, "opp-list node missing\n");
> + return -ENODATA;
> + }
> +
> + ret = st_cpufreq_get_version(pdev, , );
> + if (ret) {
> + dev_err(>dev, "No OPP match found for this platform\n");
> + return ret;
> + }
> +
> + for_each_child_of_node(opplist, opp) {
> + if (ddata->dvfs_tab_count == 

Re: [PATCH 08/08] ARM: shmobile: Remove CMT renesas,channels-mask from DTS

2015-06-22 Thread Magnus Damm
Hi Laurent,

On Tue, Jun 23, 2015 at 7:40 AM, Laurent Pinchart
 wrote:
> Hi Magnus,
>
> Thank you for the patch.
>
> On Sunday 21 June 2015 17:10:33 Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Update the DTS to remove the now deprecated "renesas,channels-mask"
>> property.
>>
>> The channel information is now kept in the device driver and can easily
>> be determined based on the compat string.
>
> Unless I've missed something (which is entirely possibly given the late hour),
> the channel mask is only stored in the driver for the Gen2 CMT instances.

The case for sh73a0 and r8a7740 is also covered by some of the earlier
patches in this series. So unless I'm mistaken the series should cover
all current in-tree CMT DT users that we have. I'm not aware of any
out-of-tree users.

You are right that there are more unused compat strings documented, so
those will break. I would be tempted in phasing those out somehow.
Also, I did not spend much time cleaning up the non R-Car Gen2 cases,
so in general that needs some love.

Thanks!

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linux 4.0.6

2015-06-22 Thread Greg KH
diff --git a/Makefile b/Makefile
index 1880cf77059b..af6da040b952 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 0
-SUBLEVEL = 5
+SUBLEVEL = 6
 EXTRAVERSION =
 NAME = Hurr durr I'ma sheep
 
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index c3255e0c90aa..dbb3f4d2bf84 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -223,6 +223,25 @@
 /include/ "tps65217.dtsi"
 
  {
+   /*
+* Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
+* mode") at poweroff.  Most BeagleBone versions do not support RTC-only
+* mode and risk hardware damage if this mode is entered.
+*
+* For details, see linux-omap mailing list May 2015 thread
+*  [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
+* In particular, messages:
+*  http://www.spinics.net/lists/linux-omap/msg118585.html
+*  http://www.spinics.net/lists/linux-omap/msg118615.html
+*
+* You can override this later with
+*   {  /delete-property/ ti,pmic-shutdown-controller;  }
+* if you want to use RTC-only mode and made sure you are not affected
+* by the hardware problems. (Tip: double-check by performing a current
+* measurement after shutdown: it should be less than 1 mA.)
+*/
+   ti,pmic-shutdown-controller;
+
regulators {
dcdc1_reg: regulator@0 {
regulator-name = "vdds_dpr";
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 43d54017b779..d0ab012fa379 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -16,7 +16,8 @@
 #include "mt8173.dtsi"
 
 / {
-   model = "mediatek,mt8173-evb";
+   model = "MediaTek MT8173 evaluation board";
+   compatible = "mediatek,mt8173-evb", "mediatek,mt8173";
 
aliases {
serial0 = 
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index d2bfbc2e8995..be15e52a47a0 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -109,7 +109,7 @@ void __init init_IRQ(void)
 #endif
 }
 
-#ifdef DEBUG_STACKOVERFLOW
+#ifdef CONFIG_DEBUG_STACKOVERFLOW
 static inline void check_stack_overflow(void)
 {
unsigned long sp;
diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c
index 838d3a6a5b7d..cea02968a908 100644
--- a/arch/mips/kvm/emulate.c
+++ b/arch/mips/kvm/emulate.c
@@ -2101,7 +2101,7 @@ enum emulation_result kvm_mips_complete_mmio_load(struct 
kvm_vcpu *vcpu,
if (vcpu->mmio_needed == 2)
*gpr = *(int16_t *) run->mmio.data;
else
-   *gpr = *(int16_t *) run->mmio.data;
+   *gpr = *(uint16_t *)run->mmio.data;
 
break;
case 1:
diff --git a/arch/mips/ralink/ill_acc.c b/arch/mips/ralink/ill_acc.c
index e20b02e3ae28..e10d10b9e82a 100644
--- a/arch/mips/ralink/ill_acc.c
+++ b/arch/mips/ralink/ill_acc.c
@@ -41,7 +41,7 @@ static irqreturn_t ill_acc_irq_handler(int irq, void *_priv)
addr, (type >> ILL_ACC_OFF_S) & ILL_ACC_OFF_M,
type & ILL_ACC_LEN_M);
 
-   rt_memc_w32(REG_ILL_ACC_TYPE, REG_ILL_ACC_TYPE);
+   rt_memc_w32(ILL_INT_STATUS, REG_ILL_ACC_TYPE);
 
return IRQ_HANDLED;
 }
diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
index db257a58571f..e657b7ba3292 100644
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -200,10 +200,21 @@
 #define TLS_SIZE (GDT_ENTRY_TLS_ENTRIES * 8)
 
 #ifdef __KERNEL__
+
+/*
+ * early_idt_handler_array is an array of entry points referenced in the
+ * early IDT.  For simplicity, it's a real array with one entry point
+ * every nine bytes.  That leaves room for an optional 'push $0' if the
+ * vector has no error code (two bytes), a 'push $vector_number' (two
+ * bytes), and a jump to the common entry code (up to five bytes).
+ */
+#define EARLY_IDT_HANDLER_SIZE 9
+
 #ifndef __ASSEMBLY__
-extern const char early_idt_handlers[NUM_EXCEPTION_VECTORS][2+2+5];
+
+extern const char 
early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE];
 #ifdef CONFIG_TRACING
-#define trace_early_idt_handlers early_idt_handlers
+# define trace_early_idt_handler_array early_idt_handler_array
 #endif
 
 /*
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index c4f8d4659070..b111ab5c4509 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -167,7 +167,7 @@ asmlinkage __visible void __init x86_64_start_kernel(char * 
real_mode_data)
clear_bss();
 
for (i = 0; i < NUM_EXCEPTION_VECTORS; i++)
-   set_intr_gate(i, early_idt_handlers[i]);
+   set_intr_gate(i, early_idt_handler_array[i]);

Linux 4.0.6

2015-06-22 Thread Greg KH
I'm announcing the release of the 4.0.6 kernel.

All users of the 4.0 kernel series must upgrade.

The updated 4.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.0.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 
 arch/arm/boot/dts/am335x-bone-common.dtsi  |   19 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|3 
 arch/mips/kernel/irq.c |2 
 arch/mips/kvm/emulate.c|2 
 arch/mips/ralink/ill_acc.c |2 
 arch/x86/include/asm/segment.h |   15 +
 arch/x86/kernel/head64.c   |2 
 arch/x86/kernel/head_32.S  |   33 +--
 arch/x86/kernel/head_64.S  |   20 +-
 arch/x86/net/bpf_jit_comp.c|   35 +++
 arch/x86/vdso/Makefile |2 
 block/blk-mq.c |8 
 block/genhd.c  |   13 -
 drivers/ata/ahci_mvebu.c   |2 
 drivers/ata/pata_octeon_cf.c   |2 
 drivers/base/cacheinfo.c   |2 
 drivers/bus/mvebu-mbus.c   |  109 ++-
 drivers/dma/at_xdmac.c |  233 +++--
 drivers/dma/dmaengine.c|6 
 drivers/dma/pl330.c|3 
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c  |4 
 drivers/gpu/drm/i915/i915_gem.c|3 
 drivers/gpu/drm/i915/intel_dp.c|5 
 drivers/gpu/drm/i915/intel_i2c.c   |   20 +-
 drivers/gpu/drm/radeon/atombios_crtc.c |7 
 drivers/gpu/drm/radeon/dce3_1_afmt.c   |2 
 drivers/gpu/drm/radeon/radeon_device.c |   15 +
 drivers/gpu/drm/radeon/radeon_vm.c |   17 +
 drivers/i2c/busses/i2c-hix5hd2.c   |2 
 drivers/i2c/busses/i2c-s3c2410.c   |1 
 drivers/iio/adc/twl6030-gpadc.c|2 
 drivers/iio/imu/adis16400.h|2 
 drivers/iio/imu/adis16400_buffer.c |   26 +-
 drivers/iio/imu/adis16400_core.c   |   41 +++-
 drivers/input/mouse/alps.c |5 
 drivers/input/mouse/elantech.c |8 
 drivers/input/mouse/synaptics.c|7 
 drivers/iommu/intel-iommu.c|   20 +-
 drivers/irqchip/irq-sunxi-nmi.c|2 
 drivers/md/md.c|   13 -
 drivers/net/bonding/bond_options.c |2 
 drivers/net/ethernet/emulex/benet/be_cmds.c|   87 +
 drivers/net/ethernet/emulex/benet/be_ethtool.c |   18 +
 drivers/net/ethernet/emulex/benet/be_main.c|   16 -
 drivers/net/phy/dp83640.c  |   23 ++
 drivers/net/phy/phy.c  |7 
 drivers/net/usb/cdc_ncm.c  |2 
 drivers/net/xen-netback/xenbus.c   |   34 ++-
 drivers/of/dynamic.c   |2 
 drivers/staging/ozwpan/ozhcd.c |8 
 drivers/staging/ozwpan/ozusbif.h   |4 
 drivers/staging/ozwpan/ozusbsvc1.c |   19 +-
 drivers/tty/n_tty.c|   17 +
 drivers/tty/serial/imx.c   |8 
 drivers/usb/dwc3/core.h|4 
 drivers/usb/host/xhci.c|   57 --
 drivers/usb/host/xhci.h|2 
 drivers/usb/serial/cp210x.c|1 
 drivers/usb/serial/ftdi_sio.c  |1 
 drivers/usb/serial/ftdi_sio_ids.h  |1 
 drivers/virtio/virtio_pci_common.c |1 
 fs/aio.c   |   45 +++-
 fs/btrfs/extent-tree.c |   18 +
 fs/btrfs/extent_io.c   |5 
 fs/btrfs/ioctl.c   |6 
 fs/btrfs/send.c|7 
 fs/btrfs/super.c   |9 
 include/linux/backing-dev.h|1 
 include/net/inet_connection_sock.h |3 
 include/net/sctp/sctp.h|7 
 include/trace/events/writeback.h   |1 
 kernel/sched/fair.c|2 
 kernel/trace/ring_buffer_benchmark.c   |2 
 mm/backing-dev.c   |   18 -
 mm/memory_hotplug.c|4 
 net/bridge/br_fdb.c|2 
 net/bridge/br_multicast.c  |4 
 net/caif/caif_socket.c |8 
 net/ceph/crush/mapper.c|   16 +
 

Re: [PATCH 8/8] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation

2015-06-22 Thread Viresh Kumar
[Adding Rob]

On 22-06-15, 16:43, Lee Jones wrote:

At least some description was required here on why you need additional
bindings are what are they.

Over that, this patch should have been present before any other
patches using these bindings.

> Cc: devicet...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---
>  .../devicetree/bindings/cpufreq/cpufreq-st.txt | 48 
> ++
>  1 file changed, 48 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt 
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> new file mode 100644
> index 000..cfa8952
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> @@ -0,0 +1,48 @@
> +Binding for ST's CPUFreq driver
> +===

OPP-v2 bindings are out now and you can probably use them to make life
simple, they are part of Rafael's recent pull request:
https://lkml.org/lkml/2015/6/22/606

> +Required properties:
> +---
> +- compatible : Supported values are:
> + "st,stih407-cpufreq"

Nodes for virtual devices aren't allowed in DT.

> +Required properties [for working voltage scaling]:
> +-
> +
> +Located in CPUFreq's node:
> +
> +- st,syscfg  : Phandle to Major number register
> + First cell: offset to major number
> +- st,syscfg-eng  : Phandle to Minor number and Pcode registers
> + First cell: offset to process code
> + Second cell: offset to minor number
> +
> +Located in CPU's node:
> +
> +- st,opp-list: Bootloader provided node containing one or 
> more 'opp@X' sub-nodes

I can see that this will be passed in from the bootloader. But at
least an example on how exactly things would actually look would have
been good. In logs if not in this file.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linux 3.14.45

2015-06-22 Thread Greg KH
diff --git a/Makefile b/Makefile
index 9f2471c6fbbe..c92186c3efd7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 14
-SUBLEVEL = 44
+SUBLEVEL = 45
 EXTRAVERSION =
 NAME = Remembering Coco
 
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index d1fea7a054be..7479d8d847a6 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -110,7 +110,7 @@ void __init init_IRQ(void)
 #endif
 }
 
-#ifdef DEBUG_STACKOVERFLOW
+#ifdef CONFIG_DEBUG_STACKOVERFLOW
 static inline void check_stack_overflow(void)
 {
unsigned long sp;
diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
index 6f1c3a8a33ab..bcc9a2f46c62 100644
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -212,10 +212,21 @@
 #define TLS_SIZE (GDT_ENTRY_TLS_ENTRIES * 8)
 
 #ifdef __KERNEL__
+
+/*
+ * early_idt_handler_array is an array of entry points referenced in the
+ * early IDT.  For simplicity, it's a real array with one entry point
+ * every nine bytes.  That leaves room for an optional 'push $0' if the
+ * vector has no error code (two bytes), a 'push $vector_number' (two
+ * bytes), and a jump to the common entry code (up to five bytes).
+ */
+#define EARLY_IDT_HANDLER_SIZE 9
+
 #ifndef __ASSEMBLY__
-extern const char early_idt_handlers[NUM_EXCEPTION_VECTORS][2+2+5];
+
+extern const char 
early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE];
 #ifdef CONFIG_TRACING
-#define trace_early_idt_handlers early_idt_handlers
+# define trace_early_idt_handler_array early_idt_handler_array
 #endif
 
 /*
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 85126ccbdf6b..5fc4ac7c6582 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -162,7 +162,7 @@ asmlinkage void __init x86_64_start_kernel(char * 
real_mode_data)
clear_bss();
 
for (i = 0; i < NUM_EXCEPTION_VECTORS; i++)
-   set_intr_gate(i, early_idt_handlers[i]);
+   set_intr_gate(i, early_idt_handler_array[i]);
load_idt((const struct desc_ptr *)_descr);
 
copy_bootdata(__va(real_mode_data));
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index f36bd42d6f0c..30a2aa3782fa 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -477,21 +477,22 @@ is486:
 __INIT
 setup_once:
/*
-* Set up a idt with 256 entries pointing to ignore_int,
-* interrupt gates. It doesn't actually load idt - that needs
-* to be done on each CPU. Interrupts are enabled elsewhere,
-* when we can be relatively sure everything is ok.
+* Set up a idt with 256 interrupt gates that push zero if there
+* is no error code and then jump to early_idt_handler_common.
+* It doesn't actually load the idt - that needs to be done on
+* each CPU. Interrupts are enabled elsewhere, when we can be
+* relatively sure everything is ok.
 */
 
movl $idt_table,%edi
-   movl $early_idt_handlers,%eax
+   movl $early_idt_handler_array,%eax
movl $NUM_EXCEPTION_VECTORS,%ecx
 1:
movl %eax,(%edi)
movl %eax,4(%edi)
/* interrupt gate, dpl=0, present */
movl $(0x8E00 + __KERNEL_CS),2(%edi)
-   addl $9,%eax
+   addl $EARLY_IDT_HANDLER_SIZE,%eax
addl $8,%edi
loop 1b
 
@@ -523,26 +524,28 @@ setup_once:
andl $0,setup_once_ref  /* Once is enough, thanks */
ret
 
-ENTRY(early_idt_handlers)
+ENTRY(early_idt_handler_array)
# 36(%esp) %eflags
# 32(%esp) %cs
# 28(%esp) %eip
# 24(%rsp) error code
i = 0
.rept NUM_EXCEPTION_VECTORS
-   .if (EXCEPTION_ERRCODE_MASK >> i) & 1
-   ASM_NOP2
-   .else
+   .ifeq (EXCEPTION_ERRCODE_MASK >> i) & 1
pushl $0# Dummy error code, to make stack frame uniform
.endif
pushl $i# 20(%esp) Vector number
-   jmp early_idt_handler
+   jmp early_idt_handler_common
i = i + 1
+   .fill early_idt_handler_array + i*EARLY_IDT_HANDLER_SIZE - ., 1, 0xcc
.endr
-ENDPROC(early_idt_handlers)
+ENDPROC(early_idt_handler_array)

-   /* This is global to keep gas from relaxing the jumps */
-ENTRY(early_idt_handler)
+early_idt_handler_common:
+   /*
+* The stack is the hardware frame, an error code or zero, and the
+* vector number.
+*/
cld
 
cmpl $2,(%esp)  # X86_TRAP_NMI
@@ -602,7 +605,7 @@ ex_entry:
 is_nmi:
addl $8,%esp/* drop vector number and error code */
iret
-ENDPROC(early_idt_handler)
+ENDPROC(early_idt_handler_common)
 
 /* This is the default interrupt "handler" :-) */
ALIGN
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index a468c0a65c42..a2dc0add72ed 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -321,26 +321,28 @@ 

Linux 3.14.45

2015-06-22 Thread Greg KH
I'm announcing the release of the 3.14.45 kernel.

All users of the 3.14 kernel series must upgrade.

The updated 3.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 -
 arch/mips/kernel/irq.c |2 -
 arch/x86/include/asm/segment.h |   15 +++--
 arch/x86/kernel/head64.c   |2 -
 arch/x86/kernel/head_32.S  |   33 +++-
 arch/x86/kernel/head_64.S  |   20 +
 arch/x86/net/bpf_jit_comp.c|7 +-
 block/genhd.c  |   12 +-
 drivers/ata/pata_octeon_cf.c   |2 -
 drivers/gpu/drm/i915/intel_dp.c|5 +---
 drivers/gpu/drm/i915/intel_i2c.c   |   20 ++---
 drivers/gpu/drm/radeon/radeon_device.c |   15 +
 drivers/iio/adc/twl6030-gpadc.c|2 -
 drivers/iio/imu/adis16400.h|1 
 drivers/iio/imu/adis16400_core.c   |   38 +++--
 drivers/input/mouse/elantech.c |7 +++---
 drivers/input/mouse/synaptics.c|6 -
 drivers/net/phy/dp83640.c  |   19 ++--
 drivers/net/phy/phy.c  |6 +++--
 drivers/net/xen-netback/xenbus.c   |   33 
 drivers/staging/ozwpan/ozusbsvc1.c |   19 
 drivers/tty/n_tty.c|   17 --
 drivers/tty/serial/imx.c   |8 ++
 drivers/usb/serial/cp210x.c|1 
 drivers/usb/serial/ftdi_sio.c  |1 
 drivers/usb/serial/ftdi_sio_ids.h  |1 
 fs/btrfs/extent_io.c   |5 +++-
 fs/btrfs/super.c   |9 +++
 kernel/trace/ring_buffer_benchmark.c   |2 -
 mm/memory_hotplug.c|4 ++-
 net/bridge/br_fdb.c|2 +
 net/bridge/br_multicast.c  |2 -
 net/caif/caif_socket.c |8 ++
 net/ceph/crush/mapper.c|   16 ++---
 net/core/dev.c |2 -
 net/ipv4/route.c   |4 +++
 net/ipv4/tcp_minisocks.c   |2 -
 net/ipv4/udp.c |   24 ++--
 net/ipv6/tcp_ipv6.c|2 -
 net/ipv6/udp.c |6 +
 net/sched/sch_api.c|   10 +---
 net/unix/af_unix.c |8 ++
 net/wireless/wext-compat.c |2 +
 sound/pci/hda/patch_realtek.c  |1 
 sound/usb/mixer.c  |1 
 sound/usb/mixer_maps.c |5 
 46 files changed, 298 insertions(+), 111 deletions(-)

Aaro Koskinen (1):
  pata_octeon_cf: fix broken build

Alexei Starovoitov (1):
  x86: bpf_jit: fix compilation of large bpf programs

Andy Lutomirski (1):
  x86/asm/irq: Stop relying on magic JMP behavior for early_idt_handlers

Axel Lin (1):
  iio: adc: twl6030-gpadc: Fix modalias

Chengyu Song (1):
  btrfs: incorrect handling for fiemap_fill_next_extent return

Clemens Ladisch (1):
  ALSA: usb-audio: add MAYA44 USB+ mixer control names

Dan Williams (1):
  block: fix ext_dev_lock lockdep report

Eric Dumazet (1):
  udp: fix behavior of wrong checksums

Eric W. Biederman (1):
  ipv4: Avoid crashing in ip_error

Florent Fourcot (1):
  tcp/ipv6: fix flow label setting in TIME_WAIT state

Florian Fainelli (1):
  net: phy: Allow EEE for all RGMII variants

Greg Kroah-Hartman (1):
  Linux 3.14.45

Gu Zheng (1):
  mm/memory_hotplug.c: set zone->wait_table to null after freeing it

Hans de Goede (1):
  Input: elantech - fix detection of touchpads where the revision matches a 
known rate

Ian Campbell (1):
  xen: netback: read hotplug script once at start of day.

Ilya Dryomov (1):
  crush: ensuring at most num-rep osds are selected

James Hogan (1):
  MIPS: Fix enabling of DEBUG_STACKOVERFLOW

Jani Nikula (1):
  drm/i915: Fix DDC probe for passive adapters

Jason A. Donenfeld (3):
  ozwpan: Use proper check to prevent heap overflow
  ozwpan: divide-by-zero leading to panic
  ozwpan: unchecked signed subtraction leads to DoS

Jeff Mahoney (1):
  btrfs: cleanup orphans while looking up default subvolume

Jim Bride (1):
  drm/i915/hsw: Fix workaround for server AUX channel clock divisor

Johannes Berg (1):
  cfg80211: wext: clear sinfo struct before calling driver

John D. Blair (1):
  USB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle

Jérôme Glisse (1):
  drm/radeon: fix freeze for laptop with Turks/Thames GPU.

Lars-Peter Clausen (1):
  iio: 

Re: Linux 3.10.81

2015-06-22 Thread Greg KH
diff --git a/Makefile b/Makefile
index 067433219984..6d19e37d36d5 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 10
-SUBLEVEL = 80
+SUBLEVEL = 81
 EXTRAVERSION =
 NAME = TOSSUG Baby Fish
 
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index d1fea7a054be..7479d8d847a6 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -110,7 +110,7 @@ void __init init_IRQ(void)
 #endif
 }
 
-#ifdef DEBUG_STACKOVERFLOW
+#ifdef CONFIG_DEBUG_STACKOVERFLOW
 static inline void check_stack_overflow(void)
 {
unsigned long sp;
diff --git a/block/genhd.c b/block/genhd.c
index 7694dffe9f0e..b09f5fc94dee 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -422,9 +422,9 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
/* allocate ext devt */
idr_preload(GFP_KERNEL);
 
-   spin_lock(_devt_lock);
+   spin_lock_bh(_devt_lock);
idx = idr_alloc(_devt_idr, part, 0, NR_EXT_DEVT, GFP_NOWAIT);
-   spin_unlock(_devt_lock);
+   spin_unlock_bh(_devt_lock);
 
idr_preload_end();
if (idx < 0)
@@ -449,9 +449,9 @@ void blk_free_devt(dev_t devt)
return;
 
if (MAJOR(devt) == BLOCK_EXT_MAJOR) {
-   spin_lock(_devt_lock);
+   spin_lock_bh(_devt_lock);
idr_remove(_devt_idr, blk_mangle_minor(MINOR(devt)));
-   spin_unlock(_devt_lock);
+   spin_unlock_bh(_devt_lock);
}
 }
 
@@ -691,13 +691,13 @@ struct gendisk *get_gendisk(dev_t devt, int *partno)
} else {
struct hd_struct *part;
 
-   spin_lock(_devt_lock);
+   spin_lock_bh(_devt_lock);
part = idr_find(_devt_idr, blk_mangle_minor(MINOR(devt)));
if (part && get_disk(part_to_disk(part))) {
*partno = part->partno;
disk = part_to_disk(part);
}
-   spin_unlock(_devt_lock);
+   spin_unlock_bh(_devt_lock);
}
 
return disk;
diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c
index e73bef3093d2..5507f36a06b4 100644
--- a/drivers/ata/pata_octeon_cf.c
+++ b/drivers/ata/pata_octeon_cf.c
@@ -1068,7 +1068,7 @@ static struct of_device_id octeon_cf_match[] = {
},
{},
 };
-MODULE_DEVICE_TABLE(of, octeon_i2c_match);
+MODULE_DEVICE_TABLE(of, octeon_cf_match);
 
 static struct platform_driver octeon_cf_driver = {
.probe  = octeon_cf_probe,
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 4a21e13cc58c..d5e666fb459c 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -441,7 +441,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
   struct intel_gmbus,
   adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
-   int i, reg_offset;
+   int i = 0, inc, try = 0, reg_offset;
int ret = 0;
 
mutex_lock(_priv->gmbus_mutex);
@@ -453,12 +453,14 @@ gmbus_xfer(struct i2c_adapter *adapter,
 
reg_offset = dev_priv->gpio_mmio_base;
 
+retry:
I915_WRITE(GMBUS0 + reg_offset, bus->reg0);
 
-   for (i = 0; i < num; i++) {
+   for (; i < num; i += inc) {
+   inc = 1;
if (gmbus_is_index_read(msgs, i, num)) {
ret = gmbus_xfer_index_read(dev_priv, [i]);
-   i += 1;  /* set i to the index of the read xfer */
+   inc = 2; /* an index read is two msgs */
} else if (msgs[i].flags & I2C_M_RD) {
ret = gmbus_xfer_read(dev_priv, [i], 0);
} else {
@@ -530,6 +532,18 @@ clear_err:
 adapter->name, msgs[i].addr,
 (msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
 
+   /*
+* Passive adapters sometimes NAK the first probe. Retry the first
+* message once on -ENXIO for GMBUS transfers; the bit banging algorithm
+* has retries internally. See also the retry loop in
+* drm_do_probe_ddc_edid, which bails out on the first -ENXIO.
+*/
+   if (ret == -ENXIO && i == 0 && try++ == 0) {
+   DRM_DEBUG_KMS("GMBUS [%s] NAK on first message, retry\n",
+ adapter->name);
+   goto retry;
+   }
+
goto out;
 
 timeout:
diff --git a/drivers/iio/imu/adis16400.h b/drivers/iio/imu/adis16400.h
index 0916bf6b6c31..1e8fd2e81d45 100644
--- a/drivers/iio/imu/adis16400.h
+++ b/drivers/iio/imu/adis16400.h
@@ -165,6 +165,7 @@ struct adis16400_state {
int filt_int;
 
struct adis adis;
+   unsigned long avail_scan_mask[2];
 };
 
 /* At the moment triggers are only used for ring buffer
diff --git a/drivers/iio/imu/adis16400_core.c b/drivers/iio/imu/adis16400_core.c
index 

Linux 3.10.81

2015-06-22 Thread Greg KH
I'm announcing the release of the 3.10.81 kernel.

All users of the 3.10 kernel series must upgrade.

The updated 3.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.10.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 -
 arch/mips/kernel/irq.c   |2 -
 block/genhd.c|   12 +--
 drivers/ata/pata_octeon_cf.c |2 -
 drivers/gpu/drm/i915/intel_i2c.c |   20 +++---
 drivers/iio/imu/adis16400.h  |1 
 drivers/iio/imu/adis16400_core.c |   38 ---
 drivers/input/mouse/elantech.c   |7 +++---
 drivers/net/phy/dp83640.c|2 -
 drivers/net/phy/phy.c|6 +++--
 drivers/net/xen-netback/xenbus.c |   33 +-
 drivers/staging/ozwpan/ozusbsvc1.c   |   19 -
 drivers/usb/serial/cp210x.c  |1 
 drivers/usb/serial/ftdi_sio.c|1 
 drivers/usb/serial/ftdi_sio_ids.h|1 
 fs/btrfs/extent_io.c |5 +++-
 fs/btrfs/super.c |9 
 kernel/trace/ring_buffer_benchmark.c |2 -
 mm/memory_hotplug.c  |4 ++-
 net/bridge/br_multicast.c|2 -
 net/caif/caif_socket.c   |8 +++
 net/ipv4/route.c |4 +++
 net/ipv4/udp.c   |6 +
 net/ipv6/udp.c   |6 +
 net/sched/sch_api.c  |   10 +
 net/unix/af_unix.c   |8 +++
 net/wireless/wext-compat.c   |2 +
 sound/pci/hda/patch_realtek.c|1 
 sound/usb/mixer.c|1 
 sound/usb/mixer_maps.c   |5 
 30 files changed, 156 insertions(+), 64 deletions(-)

Aaro Koskinen (1):
  pata_octeon_cf: fix broken build

Chengyu Song (1):
  btrfs: incorrect handling for fiemap_fill_next_extent return

Clemens Ladisch (1):
  ALSA: usb-audio: add MAYA44 USB+ mixer control names

Dan Williams (1):
  block: fix ext_dev_lock lockdep report

Eric Dumazet (1):
  udp: fix behavior of wrong checksums

Eric W. Biederman (1):
  ipv4: Avoid crashing in ip_error

Florian Fainelli (1):
  net: phy: Allow EEE for all RGMII variants

Greg Kroah-Hartman (1):
  Linux 3.10.81

Gu Zheng (1):
  mm/memory_hotplug.c: set zone->wait_table to null after freeing it

Hans de Goede (1):
  Input: elantech - fix detection of touchpads where the revision matches a 
known rate

Ian Campbell (1):
  xen: netback: read hotplug script once at start of day.

James Hogan (1):
  MIPS: Fix enabling of DEBUG_STACKOVERFLOW

Jani Nikula (1):
  drm/i915: Fix DDC probe for passive adapters

Jason A. Donenfeld (3):
  ozwpan: Use proper check to prevent heap overflow
  ozwpan: divide-by-zero leading to panic
  ozwpan: unchecked signed subtraction leads to DoS

Jeff Mahoney (1):
  btrfs: cleanup orphans while looking up default subvolume

Johannes Berg (1):
  cfg80211: wext: clear sinfo struct before calling driver

John D. Blair (1):
  USB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle

Lars-Peter Clausen (1):
  iio: adis16400: Report pressure channel scale

Mark Salyzyn (1):
  unix/caif: sk_socket can disappear when state is unlocked

Patrick Riphagen (1):
  USB: serial: ftdi_sio: Add support for a Motion Tracker Development Board

Paul Cercueil (2):
  iio: adis16400: Use != channel indices for the two voltage channels
  iio: adis16400: Compute the scan mask from channel indices

Richard Cochran (1):
  net: dp83640: fix broken calibration routine.

Takashi Iwai (1):
  ALSA: hda/realtek - Add a fixup for another Acer Aspire 9420

Thadeu Lima de Souza Cascardo (1):
  bridge: fix parsing of MLDv2 reports

WANG Cong (1):
  net_sched: invoke ->attach() after setting dev->qdisc

Wang Long (1):
  ring-buffer-benchmark: Fix the wrong sched_priority of producer

Wolfram Sang (1):
  ALSA: usb-audio: Add mic volume fix quirk for Logitech Quickcam Fusion



signature.asc
Description: PGP signature


Re: [PATCH v2 11/15] KVM: MTRR: sort variable MTRRs

2015-06-22 Thread Xiao Guangrong



On 06/22/2015 07:24 PM, Paolo Bonzini wrote:



On 17/06/2015 18:11, Paolo Bonzini wrote:

Also, this loop looks weird.  Is this what you wanted?

 list_for_each_entry(tmp, _state->head, node)
 if (cur->base >= tmp->base)
 break;
 list_add_tail(>node, >node);

If so, can you look at kvm/queue and see if it is okay for you (so that
we can get the series in 4.2)?


Ping?

If I don't get testing results before Wednesday, I'll drop this series
from the 4.2 pull request.


Paolo, sorry for the delay. Your changes are good to me. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 5/8] ARM: STi: STiH407: Move PWM nodes STiH407 => STiH407-family

2015-06-22 Thread Viresh Kumar
On 22-06-15, 16:43, Lee Jones wrote:
> This also incorporates the STiH410.

Any explanation to why this patch is part of this series ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 4/8] ARM: STi: STiH407: Provide a node for CPUFreq

2015-06-22 Thread Viresh Kumar
[Ccing Rob]

On 22-06-15, 16:43, Lee Jones wrote:
> Signed-off-by: Lee Jones 
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> b/arch/arm/boot/dts/stih407-family.dtsi
> index f48767e..f57fd83 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -98,6 +98,11 @@
>   ranges;
>   compatible = "simple-bus";
>  
> + cpufreq {
> + compatible = "st,stih407-cpufreq";
> + st,syscfg = <_core 0x8e0>;
> + };

These virtual nodes aren't allowed in DT and you have added them
before the bindings patch :).

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform

2015-06-22 Thread Viresh Kumar
Hi Bartlomiej,

[Adding Rafael & Rob to cc list. Please don't forget for any PM
specific patches :)]

First of all, really sorry for missing this mail thread. Don't know
how I missed it though. And please please please, do send a ping
reminder (to me at least), if you think the mail thread is
missed/ignored by the Maintainers.

Its been two months, and not a single reminder :).. And I wouldn't
have seen this email if you wouldn't have pinged me on IRC ..

On 10-04-15, 19:58, Bartlomiej Zolnierkiewicz wrote:
> This patch series removes the use of Exynos4x12 specific support
> from cpufreq-exynos driver and enables the use of cpufreq-dt driver
> for this platform.

Excellent.

> In order to preserve support for Exynos4x12 'boost' mode cpufreq-dt
> driver is made aware of 'boost' mode frequencies and boost-opps
> binding is provided.

That's good too..

> boost-opps binding is currently limited to cpufreq-dt but once there is
> a need for cpufreq wide and/or generic Linux device support for 'boost'
> mode cpufreq-dt can be updated to handle the new code without changing
> the binding itself.

You already know that operating-points-v2 bindings are already
accepted and applied by Rafael. Its not that the earlier bindings are
discarded or obsolete now, but are only present for simple use cases.

There are NO plans for extending the earlier OPP bindings Unless its
really required. And what you are trying to do in cpufreq-dt's
bindings, really belongs to OPP bindings.

As the new bindings will be present in 4.2, getting the code (at least
the basic code) for them into 4.3 wouldn't be that difficult. Anyway,
your stuff isn't going out in 4.2 either and so you *shall* adopt
to opp-v2 bindings in your next version.

Migrating platforms to opp-v2 wouldn't be that difficult, mostly
changes required only in dts files, unless you are using a driver of
your own.

I would be updating cpufreq-dt at the earlier to support basic
features of opp-v2 for 4.3. Some code is already posted:

http://permalink.gmane.org/gmane.linux.power-management.general/61326

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] USB: atm: cxacru: fix blank line after declaration

2015-06-22 Thread Aaron Raimist
Fixed a coding style issue. Adds blank lines after declarations.

Signed-off-by: Aaron Raimist 
---
 drivers/usb/atm/cxacru.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index 813d4d3..1173f9c 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -270,6 +270,7 @@ static ssize_t cxacru_sysfs_showattr_dB(s16 value, char 
*buf)
 static ssize_t cxacru_sysfs_showattr_bool(u32 value, char *buf)
 {
static char *str[] = { "no", "yes" };
+
if (unlikely(value >= ARRAY_SIZE(str)))
return snprintf(buf, PAGE_SIZE, "%u\n", value);
return snprintf(buf, PAGE_SIZE, "%s\n", str[value]);
@@ -278,6 +279,7 @@ static ssize_t cxacru_sysfs_showattr_bool(u32 value, char 
*buf)
 static ssize_t cxacru_sysfs_showattr_LINK(u32 value, char *buf)
 {
static char *str[] = { NULL, "not connected", "connected", "lost" };
+
if (unlikely(value >= ARRAY_SIZE(str) || str[value] == NULL))
return snprintf(buf, PAGE_SIZE, "%u\n", value);
return snprintf(buf, PAGE_SIZE, "%s\n", str[value]);
@@ -702,6 +704,7 @@ static int cxacru_cm_get_array(struct cxacru_data 
*instance, enum cxacru_cm_requ
len = ret / 4;
for (offb = 0; offb < len; ) {
int l = le32_to_cpu(buf[offb++]);
+
if (l < 0 || l > stride || l > (len - offb) / 2) {
if (printk_ratelimit())
usb_err(instance->usbatm, "invalid data length 
from cm %#x: %d\n",
@@ -732,6 +735,7 @@ cleanup:
 static int cxacru_card_status(struct cxacru_data *instance)
 {
int ret = cxacru_cm(instance, CM_REQUEST_CARD_GET_STATUS, NULL, 0, 
NULL, 0);
+
if (ret < 0) {  /* firmware not loaded */
usb_dbg(instance->usbatm, "cxacru_adsl_start: CARD_GET_STATUS 
returned %d\n", ret);
return ret;
@@ -945,6 +949,7 @@ static int cxacru_fw(struct usb_device *usb_dev, enum 
cxacru_fw_request fw,
offb = offd = 0;
do {
int l = min_t(int, stride, size - offd);
+
buf[offb++] = fw;
buf[offb++] = l;
buf[offb++] = code1;
@@ -1091,8 +1096,8 @@ static int cxacru_heavy_init(struct usbatm_data 
*usbatm_instance,
 {
const struct firmware *fw, *bp;
struct cxacru_data *instance = usbatm_instance->driver_data;
-
int ret = cxacru_find_firmware(instance, "fw", );
+
if (ret) {
usb_warn(usbatm_instance, "firmware (cxacru-fw.bin) unavailable 
(system misconfigured?)\n");
return ret;
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] ipv6: Fixed source specific default route handling.

2015-06-22 Thread YOSHIFUJI Hideaki/吉藤英明
Matthias Schiffer wrote:
> On 06/22/2015 07:58 AM, Steven Barth wrote:
>> On 22.06.2015 00:35, Matthias Schiffer wrote:
>>> Could you explain in detail what you mean with "If you want specific SA,
>>> add same route with higher metric and/or (more) specific src match."?
>>> Routes aren't bound to specific addresses except via the "src" attribute
>>> (which is called prefsrc in the kernel), which is exactly what it not
>>> working. I can't control the chosen source address at all when
>>> source-specific routes are involved.
>> Except that prefsrc and src are two different beasts and usually ip route 
>> from transates to
>> RTA_SRC instead of RTA_PREFSOURCE when used with a prefix length.
>>
>> Try adding two routes to the same destination with the same metric but 
>> different source values with PREFSRC (e.g. IPv4) and then
>> try doing the same with SRC (e.g. IPv6). The former will fail but the latter 
>> will succeed.
> 
> Ah sorry, I didn't know that "src" and "prefsrc" were distinct concepts.
> I meant to refer to "src" whenever I wrote "prefsrc". What are the
> precise semantics of the "src" attribute? Any RFC I can read, or is this
> a Linux-specific concept?
> 

"src" is long-lived feature which is usually used with mutiple routing
tables by "ip rule".

--yoshfuji

>>
>>
>> https://tools.ietf.org/html/draft-troan-homenet-sadr-01
>> was the original draft for source-address dependent routing IIRC so might be 
>> a good read.
> 
> Thanks for the link, that helps a bit.
> 
>>
>>
>>>
>>> Even though the source-specific route has a higher metric than the
>>> generic one, the source-specific one shadows the generic route.
>>
>> (was a bit ago since I read into this so please correct me if I am wrong)
>> IIRC this is intentional since longest-prefix-match beats metric here
>> and the source-address match counts to being more-specific here. See also 
>> above difference between PREFSRC and SRC.
> 
> Ah, that would explain the metric issue. I looks like the source of my
> confusion is that for source-specific routes *all* addresses are in the
> candidate set, not only the addresses of the outgoing interface (which
> makes sense as ip6_route_get_saddr() is called with a NULL rt6_info in
> the source-specific case).
> 
> I'm not sure if this can be fixed in a sane way (as there seems to be a
> dependency cycle: source address should depend on outgoing interface,
> which depends on the chosen route, which depends on the source address),
> but it leads to highly unintuitive source address selection :(
> 
> Markus suggested in the commit message not to call ip6_route_output at
> all before the source address has been selected. Wouldn't this make it
> impossible to choose the source address depending on the outgoing
> interface in the non-source-specific case as well?
> 
>> Cheers,
>>
>> Steven
> 
> Thanks for the explanation,
> Matthias
> 

-- 
吉藤英明 
ミラクル・リナックス株式会社 技術本部 サポート部
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


linux-next: build failure after merge of the drm-exynos tree

2015-06-22 Thread Stephen Rothwell
Hi Inki,

After merging the drm-exynos tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_regs':
adv7604.c:(.text+0x586c): multiple definition of `of_graph_get_endpoint_by_regs'
drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here
drivers/media/platform/soc_camera/atmel-isi.o: In function 
`of_graph_get_endpoint_by_regs':
atmel-isi.c:(.text+0x1ec9): multiple definition of 
`of_graph_get_endpoint_by_regs'
drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
first defined here
drivers/media/platform/soc_camera/rcar_vin.o: In function 
`of_graph_get_endpoint_by_regs':
rcar_vin.c:(.text+0x307c): multiple definition of 
`of_graph_get_endpoint_by_regs'
drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
first defined here

Caused by commit:

  a0f7001c18ca ("of: add helper for getting endpoint node of specific 
identifiers")

I have used the drm-exynos from next-20150622 for today.

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


pgp7UAeGFf671.pgp
Description: OpenPGP digital signature


Re: [PATCH v2 6/7]powerpc/powernv: generic nest pmu event functions

2015-06-22 Thread Sukadev Bhattiprolu
Madhavan Srinivasan [ma...@linux.vnet.ibm.com] wrote:
| From: Madhavan Srinivasan 
| Subject: [PATCH v2 6/7]powerpc/powernv: generic nest pmu event functions
| 
| Add generic format attribute and set of generic nest pmu related
| event functions to be used by each nest pmu. Add code to register nest pmus.
| 
| Cc: Michael Ellerman 
| Cc: Benjamin Herrenschmidt 
| Cc: Paul Mackerras 
| Cc: Anton Blanchard 
| Cc: Sukadev Bhattiprolu 
| Cc: Anshuman Khandual 
| Cc: Stephane Eranian 
| Signed-off-by: Madhavan Srinivasan 
| ---
|  arch/powerpc/perf/nest-pmu.c | 109 
+++
|  1 file changed, 109 insertions(+)
| 
| diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
| index 8fad2d9..a662c14 100644
| --- a/arch/powerpc/perf/nest-pmu.c
| +++ b/arch/powerpc/perf/nest-pmu.c
| @@ -13,6 +13,108 @@
|  static struct perchip_nest_info p8_perchip_nest_info[P8_MAX_CHIP];
|  static struct nest_pmu *per_nest_pmu_arr[P8_MAX_NEST_PMUS];
| 
| +PMU_FORMAT_ATTR(event, "config:0-20");
| +struct attribute *p8_nest_format_attrs[] = {
| + _attr_event.attr,
| + NULL,
| +};
| +
| +struct attribute_group p8_nest_format_group = {
| + .name = "format",
| + .attrs = p8_nest_format_attrs,
| +};

Could this be included in previous/separate patch? That way,
this patch could focus on just registering the nest-pmu.

| +
| +static int p8_nest_event_init(struct perf_event *event)
| +{
| + int chip_id;
| +
| + if (event->attr.type != event->pmu->type)
| + return -ENOENT;
| +
| + /* Sampling not supported yet */
| + if (event->hw.sample_period)
| + return -EINVAL;
| +
| + /* unsupported modes and filters */
| + if (event->attr.exclude_user   ||
| + event->attr.exclude_kernel ||
| + event->attr.exclude_hv ||
| + event->attr.exclude_idle   ||
| + event->attr.exclude_host   ||
| + event->attr.exclude_guest)
| + return -EINVAL;
| +
| + if (event->cpu < 0)
| + return -EINVAL;
| +
| + chip_id = topology_physical_package_id(event->cpu);
| + event->hw.event_base = event->attr.config +
| + p8_perchip_nest_info[chip_id].vbase;
| +
| + return 0;
| +}
| +
| +static void p8_nest_read_counter(struct perf_event *event)
| +{
| + u64 *addr;
| 

Define as uint64_t so we can eliminate one cast below? Would also
be consistent with p8_nest_perf_event_update().

| 
| + u64 data = 0;
| +
| + addr = (u64 *)event->hw.event_base;
| + data = __be64_to_cpu((uint64_t)*addr);
| + local64_set(>hw.prev_count, data);
| +}
| +
| +static void p8_nest_perf_event_update(struct perf_event *event)
| +{
| + u64 counter_prev, counter_new, final_count;
| + uint64_t *addr;
| +
| + addr = (u64 *)event->hw.event_base;

uint64_t *?

| + counter_prev = local64_read(>hw.prev_count);
| + counter_new = __be64_to_cpu((uint64_t)*addr);

Redundant cast? addr is already uint64_t *?

| + final_count = counter_new - counter_prev;
| +
| + local64_set(>hw.prev_count, counter_new);
| + local64_add(final_count, >count);
| +}
| +
| +static void p8_nest_event_start(struct perf_event *event, int flags)
| +{

Check PERF_EF_RELOAD before reloading?

| + event->hw.state = 0;
| + p8_nest_read_counter(event);
| +}
| +
| +static void p8_nest_event_stop(struct perf_event *event, int flags)
| +{

Check PERF_EF_UPDATE when stopping?

| + p8_nest_perf_event_update(event);
| +}
| +
| +static int p8_nest_event_add(struct perf_event *event, int flags)
| +{

Check PERF_EF_START flags before starting the counter on an ->add()?

| + p8_nest_event_start(event, flags);
| + return 0;
| +}
| +
| +/*
| + * Populate pmu ops in the structure
| + */
| +static int update_pmu_ops(struct nest_pmu *pmu)
| +{
| + if (!pmu)
| + return -EINVAL;
| +
| + pmu->pmu.task_ctx_nr = perf_invalid_context;
| + pmu->pmu.event_init = p8_nest_event_init;
| + pmu->pmu.add = p8_nest_event_add;
| + pmu->pmu.del = p8_nest_event_stop;
| + pmu->pmu.start = p8_nest_event_start;
| + pmu->pmu.stop = p8_nest_event_stop;
| + pmu->pmu.read = p8_nest_perf_event_update;
| + pmu->pmu.attr_groups = pmu->attr_groups;
| +
| + return 0;
| +}
| +
|  /*
|   * Populate event name and string in attribute
|   */
| @@ -106,6 +208,7 @@ static int nest_pmu_create(struct device_node *dev, int 
pmu_index)
|   /* Save the name to register the PMU with it */
|   sprintf(buf, "Nest_%s", (char *)pp->value);
|   pmu_ptr->pmu.name = (char *)buf;
| + pmu_ptr->attr_groups[1] = _nest_format_group;
|   }
| 
|   /* Skip these, we dont need it */
| @@ -179,6 +282,12 @@ static int nest_pmu_create(struct device_node *dev, int 
pmu_index)
|   (struct ppc64_nest_ima_events *)p8_events_arr,
|  

Re: clustered MD

2015-06-22 Thread NeilBrown
On Sun, 14 Jun 2015 17:19:31 -0500
Goldwyn Rodrigues  wrote:

> 
> 
> On 06/12/2015 01:46 PM, David Teigland wrote:
> > When a node fails, its dirty areas get special treatment from other nodes
> > using the area_resyncing() function.  Should the suspend_list be created
> > before any reads or writes from the file system are processed by md?  It
> > seems to me that gfs journal recovery could read/write to dirty regions
> > (from the failed node) before md was finished setting up the suspend_list.
> > md could probably prevent that by using the recover_prep() dlm callback to
> > set a flag that would block any i/o that arrived before the suspend_list
> > was ready.
> >
> > .
> 
> Yes, we should call mddev_suspend() in recover_prep() and mddev_resume() 
> after suspend_list is created. Thanks for pointing it out.
> 

The only thing that nodes need to be careful of between the time when
some other node disappears and when that disappearance has been
completely handled is reads.
md/raid1 must ensure that  if/when the filesystem reads from a region
that the missing node was writing to, that the filesystem sees
consistent data - on all nodes.

So it needs to suspend read-balancing while it is uncertain.

Once the bitmap from the node has been loaded, the normal protection
against read-balancing in a "dirty" region is sufficient.  While
waiting for the bitmap to be loaded, the safe thing to do would be to
disable read-balancing completely.

So I think that recover_prep() should set a flag which disables all
read balancing, and recover_done() (or similar) should clear that flag.
Probably there should be one flag for each other node.

Calling mddev_suspend to suspect all IO is over-kill.  Suspending all
read balancing is all that is needed.

Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: vdso && f_op->mremap (Was: special_mapping_fault() is broken)

2015-06-22 Thread Andy Lutomirski
On Mon, Jun 22, 2015 at 5:47 PM, Oleg Nesterov  wrote:
> On 06/21, Oleg Nesterov wrote:
>>
>> Forgot to add Andy...
>
> Add Pavel ;)
>
> I never understood why ->mremap() lives in file_operations, not in
> vm_operations_struct. To me vma->vm_file->f_op in move_vma() just
> looks strange, vma->vm_ops->mremap(new_vma) looks "obviously better".
>
> And afaics more useful. CRIU remaps vdso, but this does not update
> mm->context.vdso. OK, probably this does not matter currently, CRIU
> can't c/r the compat tasks, and 64-bit apps do not use context.vdso.
> Afaics. Still, I think we might want to have special_mapping_remap()
> and we can't do this because ->vm_file == NULL.

I would like this.  Then I could clean up and resubmit my patch to
keep context.vdso up to date.

Oleg, can you let me know what patch, if any, I should be reviewing?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 2/4] sched:Consider imbalance_pct when comparing loads in numa_has_capacity

2015-06-22 Thread Rik van Riel
On 06/22/2015 12:29 PM, Srikar Dronamraju wrote:
> * Rik van Riel  [2015-06-16 10:39:13]:
> 
>> On 06/16/2015 07:56 AM, Srikar Dronamraju wrote:
>>> This is consistent with all other load balancing instances where we
>>> absorb unfairness upto env->imbalance_pct. Absorbing unfairness upto
>>> env->imbalance_pct allows to pull and retain task to their preferred
>>> nodes.
>>>
>>> Signed-off-by: Srikar Dronamraju 
>>
>> How does this work with other workloads, eg.
>> single instance SPECjbb2005, or two SPECjbb2005
>> instances on a four node system?
>>
>> Is the load still balanced evenly between nodes
>> with this patch?
>>
> 
> Yes, I have looked at mpstat logs while running SPECjbb2005 for 1JVMper
> System, 2 JVMs per System and 4 JVMs per System and observed that the
> load spreading was similar with and without this patch.
> 
> Also I have visualized using htop when running 0.5X (i.e 48 threads on
> 96 cpu system) cpu stress workloads to see that the spread is similar
> before and after the patch.
> 
> Please let me know if there are any better ways to observe the
> spread. In a slightly loaded or less loaded system, the chance of
> migrating threads to their home node by way of calling migrate_task_to
> and migrate_swap might be curtailed without this patch. i.e 2 process
> each having N/2 threads may converge slower without this change.

Awesome.  Feel free to put my Acked-by: on this patch.

Acked-by: Rik van Riel 


-- 
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC PATCH] powerpc/numa: initialize distance lookup table from drconf path

2015-06-22 Thread Anton Blanchard
Hi Nikunj,

> From: Nikunj A Dadhania 
> 
> powerpc/numa: initialize distance lookup table from drconf path
> 
> In some situations, a NUMA guest that supports
> ibm,dynamic-memory-reconfiguration node will end up having flat NUMA
> distances between nodes. This is because of two problems in the
> current code.

Thanks for the patch. Have we tested that this doesn't regress the
non dynamic representation?

Regards,
Anton

> 1) Different representations of associativity lists.
> 
>There is an assumption about the associativity list in
>initialize_distance_lookup_table(). Associativity list has two
> forms:
> 
>a) [cpu,memory]@x/ibm,associativity has following
>   format:
> 
> 
>b)
> ibm,dynamic-reconfiguration-memory/ibm,associativity-lookup-arrays
> 
>  
>M = the number of associativity lists
>N = the number of entries per associativity list
> 
>Fix initialize_distance_lookup_table() so that it does not assume
>"case a". And update the caller to skip the length field before
>sending the associativity list.
> 
> 2) Distance table not getting updated from drconf path.
> 
>Node distance table will not get initialized in certain cases as
>ibm,dynamic-reconfiguration-memory path does not initialize the
>lookup table.
> 
>Call initialize_distance_lookup_table() from drconf path with
>appropriate associativity list.
> 
> Reported-by: Bharata B Rao 
> Signed-off-by: Nikunj A Dadhania 
> ---
>  arch/powerpc/mm/numa.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 5e80621..8b9502a 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -225,7 +225,7 @@ static void initialize_distance_lookup_table(int
> nid, for (i = 0; i < distance_ref_points_depth; i++) {
>   const __be32 *entry;
>  
> - entry =
> [be32_to_cpu(distance_ref_points[i])];
> + entry =
> [be32_to_cpu(distance_ref_points[i]) - 1];
> distance_lookup_table[nid][i] = of_read_number(entry, 1); }
>  }
> @@ -248,8 +248,12 @@ static int associativity_to_nid(const __be32
> *associativity) nid = -1;
>  
>   if (nid > 0 &&
> - of_read_number(associativity, 1) >=
> distance_ref_points_depth)
> - initialize_distance_lookup_table(nid, associativity);
> + of_read_number(associativity, 1) >=
> distance_ref_points_depth) {
> + /*
> +  * Skip the length field and send start of
> associativity array
> +  */
> + initialize_distance_lookup_table(nid, associativity
> + 1);
> + }
>  
>  out:
>   return nid;
> @@ -507,6 +511,12 @@ static int of_drconf_to_nid_single(struct
> of_drconf_cell *drmem, 
>   if (nid == 0x || nid >= MAX_NUMNODES)
>   nid = default_nid;
> +
> + if (nid > 0) {
> + index = drmem->aa_index * aa->array_sz;
> + initialize_distance_lookup_table(nid,
> +
> >arrays[index]);
> + }
>   }
>  
>   return nid;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: vdso && f_op->mremap (Was: special_mapping_fault() is broken)

2015-06-22 Thread Linus Torvalds
On Mon, Jun 22, 2015 at 5:47 PM, Oleg Nesterov  wrote:
>
> In short. Shouldn't we move ->mremap() to vm_operations_struct before
> it has another user? We need to fix aio.c, but this is trivial.
>
> No?

Sounds like the right thing to do, but maybe there's some reason I
miss that it's the way it is..

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] power: max17042_battery: add HEALTH and TEMP_* properties support

2015-06-22 Thread Krzysztof Kozlowski
2015-06-08 10:22 GMT+09:00 Krzysztof Kozlowski :
> 2015-05-24 12:41 GMT+09:00 Ramakrishna Pallala 
> :
>> This patch adds the support for following battery properties
>> to max17042 fuel gauge driver.
>>
>> POWER_SUPPLY_PROP_TEMP_ALERT_MIN
>> POWER_SUPPLY_PROP_TEMP_ALERT_MAX
>> POWER_SUPPLY_PROP_TEMP_MIN
>> POWER_SUPPLY_PROP_TEMP_MAX
>> POWER_SUPPLY_PROP_HEALTH
>
> I wonder, have you tested the patch? After booting on Trats2 device
> (max77693 which identifies itself as 17047-like) the values are:
> POWER_SUPPLY_TEMP_ALERT_MIN=1280
> POWER_SUPPLY_TEMP_ALERT_MAX=1270
> POWER_SUPPLY_TEMP=257
> This is okay, datasheet says that register after booting will have
> value of 0x7f80.
>
> However setting them to some value which should trigger interrupts
> (like 300 for MIN or 200 for MAX) does not trigger the interrupt. I
> added a printk in max17042_thread_handler().
>
> Is the temperature alert feature working?

Dear Ramakrishna Pallala,

Can you reply to my question above?
If this feature is not working, then it should be removed.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[GIT PULL] power supply changes for 4.2

2015-06-22 Thread Sebastian Reichel
Hi Linus,

The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118:

  Linux 4.1-rc4 (2015-05-18 10:13:47 -0700)

are available in the git repository at:

  git://git.infradead.org/battery-2.6.git tags/for-4.2

for you to fetch changes up to 43df61051ab9af985ec439ee9be9c299e7de34e8:

  power_supply: Correct kerneldoc copy paste errors (2015-06-19 14:21:01 +0200)


power supply and reset changes for the v4.2 series

 * New charger drivers: BQ24257, BQ25890, AXP288, RT9455
 * MAX17042 battery: add health & temperature support
 * BQ2415x charger: add ACPI support
 * misc. fixes and cleanups


Anda-Maria Nicolae (7):
  power_supply: bq2415x_charger: Fix coding style issues
  power_supply: bq2415x_charger: Add ACPI support
  of: Add vendor prefix for Richtek Technology Corporation
  Documentation: devicetree: Add Richtek RT9455 bindings
  power_supply: Add support for Richtek RT9455 battery charger
  power_supply: rt9455_charger: Check if CONFIG_USB_PHY is enabled
  power_supply: rt9455_charger: Fix error reported by static analysis tool

Bjorn Andersson (1):
  power_supply: Correct kerneldoc copy paste errors

Frans Klaver (1):
  sbs-battery: add option to always register battery

Hans de Goede (1):
  power: Add devm_power_supply_get_by_phandle() helper function

Heiko Stübner (1):
  power: reset: gpio-restart: increase priority slightly

Krzysztof Kozlowski (8):
  power_supply: Fix NULL pointer dereference during bq27x00_battery probe
  power_supply: Fix possible NULL pointer dereference on early uevent
  power: axp288_fuel_gauge: Constify platform_device_id
  power: at91-reset: Constify platform_device_id
  power_supply: Use wrappers to avoid races when registering power supply
  power_supply: charger-manager: Add parent for power supply
  power_supply: sysfs: Bring back write to writeable properties
  power_supply: max17042: Add OF support for setting thresholds

Laurentiu Palcu (4):
  power_supply: Add TI BQ24257 charger driver
  Documentation: devicetree: Add TI BQ25890 bindings
  power_supply: Add support for TI BQ25890 charger chip
  power_supply: bq25890: make chip_id int

Ramakrishna Pallala (2):
  power: max17042_battery: add HEALTH and TEMP_* properties support
  power: axp288_charger: axp288 charger driver

Takeshi Yoshimura (2):
  power_supply: 88pm860x_charger: Do not call free_irq() twice
  wm831x_power: Fix off-by-one at free_irq()

Thomas Elste (1):
  power: bq24190_charger: Change first_time flag reset condition

Uwe Kleine-König (4):
  power: reset: gpio-poweroff: let devm_gpiod_get set direction of gpio
  power: reset: ltc2952: use _optional variant of devm_gpiod_get
  power_supply: bq25890: use flags argument of devm_gpiod_get
  power_supply: bq24257: use flags argument of devm_gpiod_get

 Documentation/devicetree/bindings/power/bq24257.txt |   21 ++
 Documentation/devicetree/bindings/power/bq25890.txt |   46 +++
 Documentation/devicetree/bindings/power/rt9455_charger.txt  |   48 +++
 Documentation/devicetree/bindings/power_supply/max17042_battery.txt |   13 +
 Documentation/devicetree/bindings/vendor-prefixes.txt   |1 +
 drivers/power/88pm860x_charger.c|1 -
 drivers/power/Kconfig   |   28 ++
 drivers/power/Makefile  |4 +
 drivers/power/axp288_charger.c  |  941 
+
 drivers/power/axp288_fuel_gauge.c   |2 +-
 drivers/power/bq2415x_charger.c |   94 
--
 drivers/power/bq24190_charger.c |   11 +-
 drivers/power/bq24257_charger.c |  858 

 drivers/power/bq25890_charger.c |  994 

 drivers/power/charger-manager.c |3 +-
 drivers/power/max17042_battery.c|  199 
+++-
 drivers/power/power_supply_core.c   |  106 
++-
 drivers/power/power_supply_leds.c   |4 +-
 drivers/power/power_supply_sysfs.c  |4 +-
 drivers/power/reset/at91-reset.c|2 +-
 drivers/power/reset/gpio-poweroff.c |   25 +-
 drivers/power/reset/gpio-restart.c  |2 +-
 drivers/power/reset/ltc2952-poweroff.c 

[GIT PULL] HSI changes for 4.2

2015-06-22 Thread Sebastian Reichel
Hi Linus,

The following changes since commit b953c0d234bc72e8489d3bf51a276c5c4ec85345:

  Linux 4.1 (2015-06-21 22:05:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git 
tags/hsi-for-4.2

for you to fetch changes up to f451e76f896922137f8316cb071ae2cab78091ad:

  HSI: nokia-modem: use flags argument of devm_gpiod_get to set direction 
(2015-06-23 02:40:03 +0200)


HSI changes for the v4.2 series

* misc. fixes


Sebastian Reichel (2):
  HSI: cmt_speech: fix timestamp interface
  HSI: nokia-modem: Reduce missing driver message to debug level

Uwe Kleine-König (1):
  HSI: nokia-modem: use flags argument of devm_gpiod_get to set direction

 drivers/hsi/clients/cmt_speech.c |  9 +++--
 drivers/hsi/clients/nokia-modem.c| 11 ---
 include/uapi/linux/hsi/cs-protocol.h | 16 +++-
 3 files changed, 22 insertions(+), 14 deletions(-)

-- Sebastian


signature.asc
Description: Digital signature


vdso && f_op->mremap (Was: special_mapping_fault() is broken)

2015-06-22 Thread Oleg Nesterov
On 06/21, Oleg Nesterov wrote:
>
> Forgot to add Andy...

Add Pavel ;)

I never understood why ->mremap() lives in file_operations, not in
vm_operations_struct. To me vma->vm_file->f_op in move_vma() just
looks strange, vma->vm_ops->mremap(new_vma) looks "obviously better".

And afaics more useful. CRIU remaps vdso, but this does not update
mm->context.vdso. OK, probably this does not matter currently, CRIU
can't c/r the compat tasks, and 64-bit apps do not use context.vdso.
Afaics. Still, I think we might want to have special_mapping_remap()
and we can't do this because ->vm_file == NULL.

And perhaps other architectures can depend on the "correct" value
in >context.vdso more then x86, I dunno...

In short. Shouldn't we move ->mremap() to vm_operations_struct before
it has another user? We need to fix aio.c, but this is trivial.

No?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[RFC v5 PATCH 3/9] hugetlbfs: hugetlb_vmtruncate_list() needs to take a range to delete

2015-06-22 Thread Mike Kravetz
fallocate hole punch will want to unmap a specific range of pages.
Modify the existing hugetlb_vmtruncate_list() routine to take a
start/end range.  If end is 0, this indicates all pages after start
should be unmapped.  This is the same as the existing truncate
functionality.  Modify existing callers to add 0 as end of range.

Since the routine will be used in hole punch as well as truncate
operations, it is more appropriately renamed to hugetlb_vmdelete_list().

Signed-off-by: Mike Kravetz 
---
 fs/hugetlbfs/inode.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index e5a93d8..e9d4c8d 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -374,11 +374,15 @@ static void hugetlbfs_evict_inode(struct inode *inode)
 }
 
 static inline void
-hugetlb_vmtruncate_list(struct rb_root *root, pgoff_t pgoff)
+hugetlb_vmdelete_list(struct rb_root *root, pgoff_t start, pgoff_t end)
 {
struct vm_area_struct *vma;
 
-   vma_interval_tree_foreach(vma, root, pgoff, ULONG_MAX) {
+   /*
+* end == 0 indicates that the entire range after
+* start should be unmapped.
+*/
+   vma_interval_tree_foreach(vma, root, start, end ? end : ULONG_MAX) {
unsigned long v_offset;
 
/*
@@ -387,13 +391,20 @@ hugetlb_vmtruncate_list(struct rb_root *root, pgoff_t 
pgoff)
 * which overlap the truncated area starting at pgoff,
 * and no vma on a 32-bit arch can span beyond the 4GB.
 */
-   if (vma->vm_pgoff < pgoff)
-   v_offset = (pgoff - vma->vm_pgoff) << PAGE_SHIFT;
+   if (vma->vm_pgoff < start)
+   v_offset = (start - vma->vm_pgoff) << PAGE_SHIFT;
else
v_offset = 0;
 
-   unmap_hugepage_range(vma, vma->vm_start + v_offset,
-vma->vm_end, NULL);
+   if (end) {
+   end = ((end - start) << PAGE_SHIFT) +
+  vma->vm_start + v_offset;
+   if (end > vma->vm_end)
+   end = vma->vm_end;
+   } else
+   end = vma->vm_end;
+
+   unmap_hugepage_range(vma, vma->vm_start + v_offset, end, NULL);
}
 }
 
@@ -409,7 +420,7 @@ static int hugetlb_vmtruncate(struct inode *inode, loff_t 
offset)
i_size_write(inode, offset);
i_mmap_lock_write(mapping);
if (!RB_EMPTY_ROOT(>i_mmap))
-   hugetlb_vmtruncate_list(>i_mmap, pgoff);
+   hugetlb_vmdelete_list(>i_mmap, pgoff, 0);
i_mmap_unlock_write(mapping);
truncate_hugepages(inode, offset);
return 0;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] block: partition-generic: Catch alloc_part_info failure

2015-06-22 Thread Axel Lin
Make add_partition() return proper ERR_PTR if alloc_part_info() fails.
This ensures the caller of add_partition() can catch the error by IS_ERROR
macro.

Signed-off-by: Axel Lin 
---
 block/partition-generic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/block/partition-generic.c b/block/partition-generic.c
index 0d9e5f9..94de205 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -309,8 +309,10 @@ struct hd_struct *add_partition(struct gendisk *disk, int 
partno,
 
if (info) {
struct partition_meta_info *pinfo = alloc_part_info(disk);
-   if (!pinfo)
+   if (!pinfo) {
+   err = -ENOMEM;
goto out_free_stats;
+   }
memcpy(pinfo, info, sizeof(*info));
p->info = pinfo;
}
-- 
2.1.0



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[RFC v5 PATCH 9/9] mm: madvise allow remove operation for hugetlbfs

2015-06-22 Thread Mike Kravetz
Now that we have hole punching support for hugetlbfs, we can
also support the MADV_REMOVE interface to it.

Signed-off-by: Dave Hansen 
Signed-off-by: Mike Kravetz 
---
 mm/madvise.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index d215ea9..3c1b7f0 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -467,7 +467,7 @@ static long madvise_remove(struct vm_area_struct *vma,
 
*prev = NULL;   /* tell sys_madvise we drop mmap_sem */
 
-   if (vma->vm_flags & (VM_LOCKED | VM_HUGETLB))
+   if (vma->vm_flags & VM_LOCKED)
return -EINVAL;
 
f = vma->vm_file;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[RFC v5 PATCH 7/9] hugetlbfs: New huge_add_to_page_cache helper routine

2015-06-22 Thread Mike Kravetz
Currently, there is  only a single place where hugetlbfs pages are
added to the page cache.  The new fallocate code be adding a second
one, so break the functionality out into its own helper.

Signed-off-by: Dave Hansen 
Signed-off-by: Mike Kravetz 
---
 include/linux/hugetlb.h |  2 ++
 mm/hugetlb.c| 27 ++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index e6ed378..71a24a7 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -330,6 +330,8 @@ struct huge_bootmem_page {
 struct page *alloc_huge_page_node(struct hstate *h, int nid);
 struct page *alloc_huge_page_noerr(struct vm_area_struct *vma,
unsigned long addr, int avoid_reserve);
+int huge_add_to_page_cache(struct page *page, struct address_space *mapping,
+   pgoff_t idx);
 
 /* arch callback */
 int __init alloc_bootmem_huge_page(struct hstate *h);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a485d9c..77712c8 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3239,6 +3239,23 @@ static bool hugetlbfs_pagecache_present(struct hstate *h,
return page != NULL;
 }
 
+int huge_add_to_page_cache(struct page *page, struct address_space *mapping,
+  pgoff_t idx)
+{
+   struct inode *inode = mapping->host;
+   struct hstate *h = hstate_inode(inode);
+   int err = add_to_page_cache(page, mapping, idx, GFP_KERNEL);
+
+   if (err)
+   return err;
+   ClearPagePrivate(page);
+
+   spin_lock(>i_lock);
+   inode->i_blocks += blocks_per_huge_page(h);
+   spin_unlock(>i_lock);
+   return 0;
+}
+
 static int hugetlb_no_page(struct mm_struct *mm, struct vm_area_struct *vma,
   struct address_space *mapping, pgoff_t idx,
   unsigned long address, pte_t *ptep, unsigned int 
flags)
@@ -3286,21 +3303,13 @@ retry:
set_page_huge_active(page);
 
if (vma->vm_flags & VM_MAYSHARE) {
-   int err;
-   struct inode *inode = mapping->host;
-
-   err = add_to_page_cache(page, mapping, idx, GFP_KERNEL);
+   int err = huge_add_to_page_cache(page, mapping, idx);
if (err) {
put_page(page);
if (err == -EEXIST)
goto retry;
goto out;
}
-   ClearPagePrivate(page);
-
-   spin_lock(>i_lock);
-   inode->i_blocks += blocks_per_huge_page(h);
-   spin_unlock(>i_lock);
} else {
lock_page(page);
if (unlikely(anon_vma_prepare(vma))) {
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[RFC v5 PATCH 6/9] mm/hugetlb: alloc_huge_page handle areas hole punched by fallocate

2015-06-22 Thread Mike Kravetz
Areas hole punched by fallocate will not have entries in the
region/reserve map.  However, shared mappings with min_size subpool
reservations may still have reserved pages.  alloc_huge_page needs
to handle this special case and do the proper accounting.

Signed-off-by: Mike Kravetz 
---
 mm/hugetlb.c | 54 +++---
 1 file changed, 39 insertions(+), 15 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 9d2859f..a485d9c 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1600,32 +1600,56 @@ static struct page *alloc_huge_page(struct 
vm_area_struct *vma,
struct hugepage_subpool *spool = subpool_vma(vma);
struct hstate *h = hstate_vma(vma);
struct page *page;
-   long chg, commit;
+   long map_chg, map_commit;
+   long gbl_chg;
int ret, idx;
struct hugetlb_cgroup *h_cg;
 
idx = hstate_index(h);
/*
-* Processes that did not create the mapping will have no
-* reserves and will not have accounted against subpool
-* limit. Check that the subpool limit can be made before
-* satisfying the allocation MAP_NORESERVE mappings may also
-* need pages and subpool limit allocated allocated if no reserve
-* mapping overlaps.
+* Examine the region/reserve map to determine if the process
+* has a reservation for the page to be allocated.  A return
+* code of zero indicates a reservation exists (no change).
 */
-   chg = vma_needs_reservation(h, vma, addr);
-   if (chg < 0)
+   map_chg = gbl_chg = vma_needs_reservation(h, vma, addr);
+   if (map_chg < 0)
return ERR_PTR(-ENOMEM);
-   if (chg || avoid_reserve)
-   if (hugepage_subpool_get_pages(spool, 1) < 0)
+
+   /*
+* Processes that did not create the mapping will have no
+* reserves as indicated by the region/reserve map. Check
+* that the allocation will not exceed the subpool limit.
+* Allocations for MAP_NORESERVE mappings also need to be
+* checked against any subpool limit.
+*/
+   if (map_chg || avoid_reserve) {
+   gbl_chg = hugepage_subpool_get_pages(spool, 1);
+   if (gbl_chg < 0)
return ERR_PTR(-ENOSPC);
 
+   /*
+* Even though there was no reservation in the region/reserve
+* map, there could be reservations associated with the
+* subpool that can be used.  This would be indicated if the
+* return value of hugepage_subpool_get_pages() is zero.
+* However, if avoid_reserve is specified we still avoid even
+* the subpool reservations.
+*/
+   if (avoid_reserve)
+   gbl_chg = 1;
+   }
+
ret = hugetlb_cgroup_charge_cgroup(idx, pages_per_huge_page(h), _cg);
if (ret)
goto out_subpool_put;
 
spin_lock(_lock);
-   page = dequeue_huge_page_vma(h, vma, addr, avoid_reserve, chg);
+   /*
+* glb_chg is passed to indicate whether or not a page must be taken
+* from the global free pool (global change).  gbl_chg == 0 indicates
+* a reservation exists for the allocation.
+*/
+   page = dequeue_huge_page_vma(h, vma, addr, avoid_reserve, gbl_chg);
if (!page) {
spin_unlock(_lock);
page = alloc_buddy_huge_page(h, NUMA_NO_NODE);
@@ -1641,8 +1665,8 @@ static struct page *alloc_huge_page(struct vm_area_struct 
*vma,
 
set_page_private(page, (unsigned long)spool);
 
-   commit = vma_commit_reservation(h, vma, addr);
-   if (unlikely(chg > commit)) {
+   map_commit = vma_commit_reservation(h, vma, addr);
+   if (unlikely(map_chg > map_commit)) {
/*
 * The page was added to the reservation map between
 * vma_needs_reservation and vma_commit_reservation.
@@ -1662,7 +1686,7 @@ static struct page *alloc_huge_page(struct vm_area_struct 
*vma,
 out_uncharge_cgroup:
hugetlb_cgroup_uncharge_cgroup(idx, pages_per_huge_page(h), h_cg);
 out_subpool_put:
-   if (chg || avoid_reserve)
+   if (map_chg || avoid_reserve)
hugepage_subpool_put_pages(spool, 1);
return ERR_PTR(-ENOSPC);
 }
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[RFC v5 PATCH 1/9] mm/hugetlb: add region_del() to delete a specific range of entries

2015-06-22 Thread Mike Kravetz
fallocate hole punch will want to remove a specific range of pages.
The existing region_truncate() routine deletes all region/reserve
map entries after a specified offset.  region_del() will provide
this same functionality if the end of region is specified as -1.
Hence, region_del() can replace region_truncate().

Unlike region_truncate(), region_del() can return an error in the
rare case where it can not allocate memory for a region descriptor.
This ONLY happens in the case where an existing region must be split.
Current callers passing -1 as end of range will never experience
this error and do not need to deal with error handling.  Future
callers of region_del() (such as fallocate hole punch) will need to
handle this error.

Signed-off-by: Mike Kravetz 
---
 mm/hugetlb.c | 88 ++--
 1 file changed, 62 insertions(+), 26 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a8c3087..3fc2359 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -385,43 +385,79 @@ out_nrg:
 }
 
 /*
- * Truncate the reserve map at index 'end'.  Modify/truncate any
- * region which contains end.  Delete any regions past end.
- * Return the number of huge pages removed from the map.
+ * Delete the specified range [f, t) from the reserve map.  If the
+ * t parameter is -1, this indicates that ALL regions after f should
+ * be deleted.  Locate the regions which intersect [f, t) and either
+ * trim, delete or split the existing regions.
+ *
+ * Returns the number of huge pages deleted from the reserve map.
+ * In the normal case, the return value is zero or more.  In the
+ * case where a region must be split, a new region descriptor must
+ * be allocated.  If the allocation fails, -ENOMEM will be returned.
+ * NOTE: If the parameter t == -1, then we will never split a region
+ * and possibly return -ENOMEM.  Callers specifying t == -1 do not
+ * need to check for -ENOMEM error.
  */
-static long region_truncate(struct resv_map *resv, long end)
+static long region_del(struct resv_map *resv, long f, long t)
 {
struct list_head *head = >regions;
struct file_region *rg, *trg;
-   long chg = 0;
+   struct file_region *nrg = NULL;
+   long del = 0;
 
+   if (t == -1)
+   t = LONG_MAX;
+retry:
spin_lock(>lock);
-   /* Locate the region we are either in or before. */
-   list_for_each_entry(rg, head, link)
-   if (end <= rg->to)
+   list_for_each_entry_safe(rg, trg, head, link) {
+   if (rg->to <= f)
+   continue;
+   if (rg->from >= t)
break;
-   if (>link == head)
-   goto out;
 
-   /* If we are in the middle of a region then adjust it. */
-   if (end > rg->from) {
-   chg = rg->to - end;
-   rg->to = end;
-   rg = list_entry(rg->link.next, typeof(*rg), link);
-   }
+   if (f > rg->from && t < rg->to) { /* Must split region */
+   if (!nrg) {
+   spin_unlock(>lock);
+   nrg = kmalloc(sizeof(*nrg), GFP_KERNEL);
+   if (!nrg)
+   return -ENOMEM;
+   goto retry;
+   }
 
-   /* Drop any remaining regions. */
-   list_for_each_entry_safe(rg, trg, rg->link.prev, link) {
-   if (>link == head)
+   del += t - f;
+
+   /* New entry for end of split region */
+   nrg->from = t;
+   nrg->to = rg->to;
+   INIT_LIST_HEAD(>link);
+
+   /* Original entry is trimmed */
+   rg->to = f;
+
+   list_add(>link, >link);
+   nrg = NULL;
break;
-   chg += rg->to - rg->from;
-   list_del(>link);
-   kfree(rg);
+   }
+
+   if (f <= rg->from && t >= rg->to) { /* Remove entire region */
+   del += rg->to - rg->from;
+   list_del(>link);
+   kfree(rg);
+   continue;
+   }
+
+   if (f <= rg->from) {/* Trim beginning of region */
+   del += t - rg->from;
+   rg->from = t;
+   } else {/* Trim end of region */
+   del += rg->to - f;
+   rg->to = f;
+   }
}
 
-out:
spin_unlock(>lock);
-   return chg;
+   kfree(nrg);
+   return del;
 }
 
 /*
@@ -559,7 +595,7 @@ void resv_map_release(struct kref *ref)
struct resv_map *resv_map = container_of(ref, struct resv_map, refs);
 
/* Clear out any active regions before we release the map. */
-   region_truncate(resv_map, 0);

[RFC v5 PATCH 0/9] hugetlbfs: add fallocate support

2015-06-22 Thread Mike Kravetz
No major changes since last RFC.  Externalized existing hugetlb
fault mutex code.  Added more comments to alloc_huge_page reservation
handling as I could not come up with a good way to encapsulate.
libhugetlbfs test cases and man page updates will be included with
a later request for patch inclusion.

hugetlbfs is used today by applications that want a high degree of
control over huge page usage.  Often, large hugetlbfs files are used
to map a large number huge pages into the application processes.
The applications know when page ranges within these large files will
no longer be used, and ideally would like to release them back to
the subpool or global pools for other uses.  The fallocate() system
call provides an interface for preallocation and hole punching within
files.  This patch set adds fallocate functionality to hugetlbfs.

RFC v5:
  Simply made existing hugetlb fault mutex hash routine available for
use by fallocate.
  Unable to come up with good reservation encapsulation routines for
alloc_huge_page, so attempted to comment better.
RFC v4:
  Removed alloc_huge_page/hugetlb_reserve_pages race patches as already
in mmotm
  Moved hugetlb_fix_reserve_counts in series as suggested by Naoya Horiguchi
  Inline'ed hugetlb_fault_mutex routines as suggested by Davidlohr Bueso and
existing code changed to use new interfaces as suggested by Naoya
  fallocate preallocation code cleaned up and made simpler
  Modified alloc_huge_page to handle special case where allocation is
for a hole punched area with spool reserves
RFC v3:
  Folded in patch for alloc_huge_page/hugetlb_reserve_pages race
in current code
  fallocate allocation and hole punch is synchronized with page
faults via existing mutex table
   hole punch uses existing hugetlb_vmtruncate_list instead of more
generic unmap_mapping_range for unmapping
   Error handling for the case when region_del() fails
RFC v2:
  Addressed alignment and error handling issues noticed by Hillf Danton
  New region_del() routine for region tracking/resv_map of ranges
  Fixed several issues found during more extensive testing
  Error handling in region_del() when kmalloc() fails stills needs
to be addressed
  madvise remove support remains

Mike Kravetz (9):
  mm/hugetlb: add region_del() to delete a specific range of entries
  mm/hugetlb: expose hugetlb fault mutex for use by fallocate
  hugetlbfs: hugetlb_vmtruncate_list() needs to take a range to delete
  hugetlbfs: truncate_hugepages() takes a range of pages
  mm/hugetlb: vma_has_reserves() needs to handle fallocate hole punch
  mm/hugetlb: alloc_huge_page handle areas hole punched by fallocate
  hugetlbfs: New huge_add_to_page_cache helper routine
  hugetlbfs: add hugetlbfs_fallocate()
  mm: madvise allow remove operation for hugetlbfs

 fs/hugetlbfs/inode.c| 281 
 include/linux/hugetlb.h |  14 ++-
 mm/hugetlb.c| 245 +
 mm/madvise.c|   2 +-
 4 files changed, 456 insertions(+), 86 deletions(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[RFC v5 PATCH 2/9] mm/hugetlb: expose hugetlb fault mutex for use by fallocate

2015-06-22 Thread Mike Kravetz
hugetlb page faults are currently synchronized by the table of
mutexes (htlb_fault_mutex_table).  fallocate code will need to
synchronize with the page fault code when it allocates or
deletes pages.  Expose interfaces so that fallocate operations
can be synchronized with page faults.  Minor name changes to
be more consistent with other global hugetlb symbols.

Signed-off-by: Mike Kravetz 
---
 include/linux/hugetlb.h |  5 +
 mm/hugetlb.c| 20 ++--
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 2050261..33c6b32 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -85,6 +85,11 @@ int dequeue_hwpoisoned_huge_page(struct page *page);
 bool isolate_huge_page(struct page *page, struct list_head *list);
 void putback_active_hugepage(struct page *page);
 void free_huge_page(struct page *page);
+extern struct mutex *hugetlb_fault_mutex_table;
+u32 hugetlb_fault_mutex_hash(struct hstate *h, struct mm_struct *mm,
+   struct vm_area_struct *vma,
+   struct address_space *mapping,
+   pgoff_t idx, unsigned long address);
 
 #ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
 pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3fc2359..9657cca 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -64,7 +64,7 @@ DEFINE_SPINLOCK(hugetlb_lock);
  * prevent spurious OOMs when the hugepage pool is fully utilized.
  */
 static int num_fault_mutexes;
-static struct mutex *htlb_fault_mutex_table cacheline_aligned_in_smp;
+struct mutex *hugetlb_fault_mutex_table cacheline_aligned_in_smp;
 
 /* Forward declaration */
 static int hugetlb_acct_memory(struct hstate *h, long delta);
@@ -2347,7 +2347,7 @@ static void __exit hugetlb_exit(void)
}
 
kobject_put(hugepages_kobj);
-   kfree(htlb_fault_mutex_table);
+   kfree(hugetlb_fault_mutex_table);
 }
 module_exit(hugetlb_exit);
 
@@ -2380,12 +2380,12 @@ static int __init hugetlb_init(void)
 #else
num_fault_mutexes = 1;
 #endif
-   htlb_fault_mutex_table =
+   hugetlb_fault_mutex_table =
kmalloc(sizeof(struct mutex) * num_fault_mutexes, GFP_KERNEL);
-   BUG_ON(!htlb_fault_mutex_table);
+   BUG_ON(!hugetlb_fault_mutex_table);
 
for (i = 0; i < num_fault_mutexes; i++)
-   mutex_init(_fault_mutex_table[i]);
+   mutex_init(_fault_mutex_table[i]);
return 0;
 }
 module_init(hugetlb_init);
@@ -3316,7 +3316,7 @@ backout_unlocked:
 }
 
 #ifdef CONFIG_SMP
-static u32 fault_mutex_hash(struct hstate *h, struct mm_struct *mm,
+u32 hugetlb_fault_mutex_hash(struct hstate *h, struct mm_struct *mm,
struct vm_area_struct *vma,
struct address_space *mapping,
pgoff_t idx, unsigned long address)
@@ -3341,7 +3341,7 @@ static u32 fault_mutex_hash(struct hstate *h, struct 
mm_struct *mm,
  * For uniprocesor systems we always use a single mutex, so just
  * return 0 and avoid the hashing overhead.
  */
-static u32 fault_mutex_hash(struct hstate *h, struct mm_struct *mm,
+u32 hugetlb_fault_mutex_hash(struct hstate *h, struct mm_struct *mm,
struct vm_area_struct *vma,
struct address_space *mapping,
pgoff_t idx, unsigned long address)
@@ -3389,8 +3389,8 @@ int hugetlb_fault(struct mm_struct *mm, struct 
vm_area_struct *vma,
 * get spurious allocation failures if two CPUs race to instantiate
 * the same page in the page cache.
 */
-   hash = fault_mutex_hash(h, mm, vma, mapping, idx, address);
-   mutex_lock(_fault_mutex_table[hash]);
+   hash = hugetlb_fault_mutex_hash(h, mm, vma, mapping, idx, address);
+   mutex_lock(_fault_mutex_table[hash]);
 
entry = huge_ptep_get(ptep);
if (huge_pte_none(entry)) {
@@ -3473,7 +3473,7 @@ out_ptl:
put_page(pagecache_page);
}
 out_mutex:
-   mutex_unlock(_fault_mutex_table[hash]);
+   mutex_unlock(_fault_mutex_table[hash]);
/*
 * Generally it's safe to hold refcount during waiting page lock. But
 * here we just wait to defer the next page fault to avoid busy loop and
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[RFC v5 PATCH 8/9] hugetlbfs: add hugetlbfs_fallocate()

2015-06-22 Thread Mike Kravetz
This is based on the shmem version, but it has diverged quite
a bit.  We have no swap to worry about, nor the new file sealing.
Add synchronication via the fault mutex table to coordinate
page faults,  fallocate allocation and fallocate hole punch.

What this allows us to do is move physical memory in and out of
a hugetlbfs file without having it mapped.  This also gives us
the ability to support MADV_REMOVE since it is currently
implemented using fallocate().  MADV_REMOVE lets madvise() remove
pages from the middle of a hugetlbfs file, which wasn't possible
before.

hugetlbfs fallocate only operates on whole huge pages.

Based-on code-by: Dave Hansen 
Signed-off-by: Mike Kravetz 
---
 fs/hugetlbfs/inode.c| 158 +++-
 include/linux/hugetlb.h |   3 +
 mm/hugetlb.c|   2 +-
 3 files changed, 161 insertions(+), 2 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 160d58d4..05b9d47 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include/* remove ASAP */
+#include 
 #include 
 #include 
 #include 
@@ -504,6 +505,160 @@ static int hugetlb_vmtruncate(struct inode *inode, loff_t 
offset)
return 0;
 }
 
+static long hugetlbfs_punch_hole(struct inode *inode, loff_t offset, loff_t 
len)
+{
+   struct hstate *h = hstate_inode(inode);
+   loff_t hpage_size = huge_page_size(h);
+   loff_t hole_start, hole_end;
+
+   /*
+* For hole punch round up the beginning offset of the hole and
+* round down the end.
+*/
+   hole_start = round_up(offset, hpage_size);
+   hole_end = round_down(offset + len, hpage_size);
+
+   if (hole_end > hole_start) {
+   struct address_space *mapping = inode->i_mapping;
+
+   mutex_lock(>i_mutex);
+   i_mmap_lock_write(mapping);
+   if (!RB_EMPTY_ROOT(>i_mmap))
+   hugetlb_vmdelete_list(>i_mmap,
+   hole_start >> PAGE_SHIFT,
+   hole_end  >> PAGE_SHIFT);
+   i_mmap_unlock_write(mapping);
+   remove_inode_hugepages(inode, hole_start, hole_end);
+   mutex_unlock(>i_mutex);
+   }
+
+   return 0;
+}
+
+static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset,
+   loff_t len)
+{
+   struct inode *inode = file_inode(file);
+   struct address_space *mapping = inode->i_mapping;
+   struct hstate *h = hstate_inode(inode);
+   struct vm_area_struct pseudo_vma;
+   struct mm_struct *mm = current->mm;
+   loff_t hpage_size = huge_page_size(h);
+   unsigned long hpage_shift = huge_page_shift(h);
+   pgoff_t start, index, end;
+   int error;
+   u32 hash;
+
+   if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
+   return -EOPNOTSUPP;
+
+   if (mode & FALLOC_FL_PUNCH_HOLE)
+   return hugetlbfs_punch_hole(inode, offset, len);
+
+   /*
+* Default preallocate case.
+* For this range, start is rounded down and end is rounded up
+* as well as being converted to page offsets.
+*/
+   start = offset >> hpage_shift;
+   end = (offset + len + hpage_size - 1) >> hpage_shift;
+
+   mutex_lock(>i_mutex);
+
+   /* We need to check rlimit even when FALLOC_FL_KEEP_SIZE */
+   error = inode_newsize_ok(inode, offset + len);
+   if (error)
+   goto out;
+
+   /*
+* Initialize a pseudo vma that just contains the policy used
+* when allocating the huge pages.  The actual policy field
+* (vm_policy) is determined based on the index in the loop below.
+*/
+   memset(_vma, 0, sizeof(struct vm_area_struct));
+   pseudo_vma.vm_flags = (VM_HUGETLB | VM_MAYSHARE | VM_SHARED);
+   pseudo_vma.vm_file = file;
+
+   for (index = start; index < end; index++) {
+   /*
+* This is supposed to be the vaddr where the page is being
+* faulted in, but we have no vaddr here.
+*/
+   struct page *page;
+   unsigned long addr;
+   int avoid_reserve = 0;
+
+   cond_resched();
+
+   /*
+* fallocate(2) manpage permits EINTR; we may have been
+* interrupted because we are using up too much memory.
+*/
+   if (signal_pending(current)) {
+   error = -EINTR;
+   break;
+   }
+
+   /* Get policy based on index */
+   pseudo_vma.vm_policy =
+   mpol_shared_policy_lookup(_I(inode)->policy,
+   index);
+
+   /* addr is the offset within the file (zero based) */
+   

[RFC v5 PATCH 4/9] hugetlbfs: truncate_hugepages() takes a range of pages

2015-06-22 Thread Mike Kravetz
Modify truncate_hugepages() to take a range of pages (start, end)
instead of simply start. If an end value of -1 is passed, the
current "truncate" functionality is maintained. Existing callers
are modified to pass -1 as end of range. By keying off end == -1,
the routine behaves differently for truncate and hole punch.
Page removal is now synchronized with page allocation via faults
by using the fault mutex table. The hole punch case can experience
the rare region_del error and must handle accordingly.

Add the routine hugetlb_fix_reserve_counts to fix up reserve counts
in the case where region_del returns an error.

Since the routine handles more than just the truncate case, it is
renamed to remove_inode_hugepages().  To be consistent, the routine
truncate_huge_page() is renamed remove_huge_page().

Downstream of remove_inode_hugepages(), the routine
hugetlb_unreserve_pages() is also modified to take a range of pages.
hugetlb_unreserve_pages is modified to detect an error from
region_del and pass it back to the caller.

Signed-off-by: Mike Kravetz 
---
 fs/hugetlbfs/inode.c| 98 -
 include/linux/hugetlb.h |  4 +-
 mm/hugetlb.c| 40 ++--
 3 files changed, 128 insertions(+), 14 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index e9d4c8d..160d58d4 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -318,26 +318,61 @@ static int hugetlbfs_write_end(struct file *file, struct 
address_space *mapping,
return -EINVAL;
 }
 
-static void truncate_huge_page(struct page *page)
+static void remove_huge_page(struct page *page)
 {
ClearPageDirty(page);
ClearPageUptodate(page);
delete_from_page_cache(page);
 }
 
-static void truncate_hugepages(struct inode *inode, loff_t lstart)
+
+/*
+ * remove_inode_hugepages handles two distinct cases: truncation and hole
+ * punch.  There are subtle differences in operation for each case.
+
+ * truncation is indicated by end of range being -1
+ * In this case, we first scan the range and release found pages.
+ * After releasing pages, hugetlb_unreserve_pages cleans up region/reserv
+ * maps and global counts.
+ * hole punch is indicated if end is not -1
+ * In the hole punch case we scan the range and release found pages.
+ * Only when releasing a page is the associated region/reserv map
+ * deleted.  The region/reserv map for ranges without associated
+ * pages are not modified.
+ * Note: If the passed end of range value is beyond the end of file, but
+ * not -1 this routine still performs a hole punch operation.
+ */
+static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
+  loff_t lend)
 {
struct hstate *h = hstate_inode(inode);
struct address_space *mapping = >i_data;
const pgoff_t start = lstart >> huge_page_shift(h);
+   const pgoff_t end = lend >> huge_page_shift(h);
+   struct vm_area_struct pseudo_vma;
struct pagevec pvec;
pgoff_t next;
int i, freed = 0;
+   long lookup_nr = PAGEVEC_SIZE;
+   bool truncate_op = (lend == -1);
 
+   memset(_vma, 0, sizeof(struct vm_area_struct));
+   pseudo_vma.vm_flags = (VM_HUGETLB | VM_MAYSHARE | VM_SHARED);
pagevec_init(, 0);
next = start;
-   while (1) {
-   if (!pagevec_lookup(, mapping, next, PAGEVEC_SIZE)) {
+   while (next < end) {
+   /*
+* Make sure to never grab more pages that we
+* might possibly need.
+*/
+   if (end - next < lookup_nr)
+   lookup_nr = end - next;
+
+   /*
+* This pagevec_lookup() may return pages past 'end',
+* so we must check for page->index > end.
+*/
+   if (!pagevec_lookup(, mapping, next, lookup_nr)) {
if (next == start)
break;
next = start;
@@ -346,26 +381,69 @@ static void truncate_hugepages(struct inode *inode, 
loff_t lstart)
 
for (i = 0; i < pagevec_count(); ++i) {
struct page *page = pvec.pages[i];
+   u32 hash;
+
+   hash = hugetlb_fault_mutex_hash(h, current->mm,
+   _vma,
+   mapping, next, 0);
+   mutex_lock(_fault_mutex_table[hash]);
 
lock_page(page);
+   if (page->index >= end) {
+   unlock_page(page);
+   mutex_unlock(_fault_mutex_table[hash]);
+   next = end; /* we are done */
+   break;
+   }
+
+   /*
+* 

[RFC v5 PATCH 5/9] mm/hugetlb: vma_has_reserves() needs to handle fallocate hole punch

2015-06-22 Thread Mike Kravetz
In vma_has_reserves(), the current assumption is that reserves are
always present for shared mappings.  However, this will not be the
case with fallocate hole punch.  When punching a hole, the present
page will be deleted as well as the region/reserve map entry (and
hence any reservation).  vma_has_reserves is passed "chg" which
indicates whether or not a region/reserve map is present.  Use
this to determine if reserves are actually present or were removed
via hole punch.

Signed-off-by: Mike Kravetz 
---
 mm/hugetlb.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7cd4b67..9d2859f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -692,9 +692,19 @@ static int vma_has_reserves(struct vm_area_struct *vma, 
long chg)
return 0;
}
 
-   /* Shared mappings always use reserves */
-   if (vma->vm_flags & VM_MAYSHARE)
-   return 1;
+   if (vma->vm_flags & VM_MAYSHARE) {
+   /*
+* We know VM_NORESERVE is not set.  Therefore, there SHOULD
+* be a region map for all pages.  The only situation where
+* there is no region map is if a hole was punched via
+* fallocate.  In this case, there really are no reverves to
+* use.  This situation is indicated if chg != 0.
+*/
+   if (chg)
+   return 0;
+   else
+   return 1;
+   }
 
/*
 * Only the process that called mmap() has reserves for
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] fs: optimize inotify/fsnotify code for unwatched files

2015-06-22 Thread Paul E. McKenney
On Mon, Jun 22, 2015 at 09:03:08PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 22, 2015 at 09:29:49AM -0700, Paul E. McKenney wrote:
> 
> > I believe that there still are some cases.  But why would offline
> > CPUs seem so iffy?  CPUs coming up execute code before they are fully
> > operational, and during that time, much of the kernel views them as
> > being offline.  Yet they do have to execute significant code in order
> > to get themselves set up.
> 
> I'm thinking we do far too much during bringup and tear-down as it is.
> But yes maybe.

Boot, suspend, and hibernation indeed would be faster if we did less,
but we still will have to do something.

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/2] powerpc32: checksum_wrappers_64 becomes checksum_wrappers

2015-06-22 Thread Scott Wood
On Mon, 2015-06-22 at 19:01 +0200, Christophe Leroy wrote:
> The powerpc64 checksum wrapper functions adds the 
> csum_and_copy_to_user() which
> otherwise is implemented in include/net/checksum.h by using 
> csum_partial() then
> copy_to_user()
> 
> Those two wrapper fonctions are also applicable to powerpc32 as it 
> is based on
> the use of csum_partial_copy_generic() which also exists on powerpc32
> 
> This patch renames arch/powerpc/lib/checksum_wrappers_64.c to
> arch/powerpc/lib/checksum_wrappers.c and
> makes it non-conditional to CONFIG_WORD_SIZE
> 
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/include/asm/checksum.h |   9 ---
>  arch/powerpc/lib/Makefile   |   3 +-
>  arch/powerpc/lib/checksum_wrappers.c| 102 
> 
>  arch/powerpc/lib/checksum_wrappers_64.c | 102 --
> --

Please pass "-M -C" to git format-patch so we can see if anything 
changed while being moved.

-Scott

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] fs: optimize inotify/fsnotify code for unwatched files

2015-06-22 Thread Paul E. McKenney
On Mon, Jun 22, 2015 at 08:52:29PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 22, 2015 at 08:11:21AM -0700, Paul E. McKenney wrote:
> > That depends on how slow the resulting slow global state would be.
> > We have some use cases (definitely KVM, perhaps also some of the VFS
> > code) that need the current speed, as opposed to the profound slowness
> > that three trips through synchronize_sched() would provide.
> 
> So what we have with that percpu-rwsem code that I send out earlier
> today is a conditional smp_mb(), and I think we can do the same for
> SRCU.
> 
> I'm just not sure !GP is common enough for all SRCU cases to be worth
> doing.

Especially given that we don't want the readers to have to acquire a
lock in order to get a consistent view of whether or not a grace period
is in progress.

> Those that rely on sync_srcu() and who do it rarely would definitely
> benefit. The same with those that rarely do call_srcu().
> 
> But those that heavily use call_srcu() would be better off with the
> prolonged GP with 3 sync_sched() calls in.

Those are indeed two likely possibilities.  Other possibilities include
cases where synchronize_srcu() is invoked rarely, but where its latency
is visible to userspace, and those where there really is a need to
wait synchronously for a grace period, so that call_srcu() doesn't buy
you anything.

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] fs: optimize inotify/fsnotify code for unwatched files

2015-06-22 Thread Paul E. McKenney
On Mon, Jun 22, 2015 at 11:50:50AM -0700, Dave Hansen wrote:
> On 06/22/2015 08:11 AM, Paul E. McKenney wrote:
> > But if Dave is willing to test it, I would be happy to send along
> > a fast-readers patch, easy to do.
> 
> I'm always willing to test, but the cost of the srcu_read_lock() barrier
> shows up even on my 2-year-old "Intel(R) Core(TM) i5-3320M CPU @
> 2.60GHz" laptop.  The numbers I shared in this thread are on a newer CPU
> than that, so I'm fairly confident this will show up on just about any
> (big core) Intel CPU newer than SandyBridge.
> 
> The tests I've been running are:
> 
>   https://github.com/antonblanchard/will-it-scale
> 
> with two new 1-byte read/write tests copied in to "tests/":
> 
>   https://www.sr71.net/~dave/intel/read1byte.c
>   https://www.sr71.net/~dave/intel/write1byte.c
> 
> The one-byte thing is silly but it does help isolate the kernel's
> overhead from what the app is doing.

OK, here is an experimental patch that provides a fast-readers variant
of RCU, forward-ported from v3.3.  Because we didn't have call_srcu()
and srcu_barrier() back then, it is not a drop-in replacement for SRCU,
so you need to adapt the code to the API, which means putting an "fr"
in front of the "srcu" in the API members.

Understood on the overhead of the memory-barrier instruction showing
up consistently.  My point was instead that getting rid of this
memory-barrier instruction does not come for free, as it greatly
increases the latency of synchronize_frsrcu().  In a real workload,
it is entirely possible that the savings from eliminating the memory
barrier are overwhelmed by the increased grace-period latency.

Anyway, the patch is below.  Very lightly tested.

Thanx, Paul



commit d28d4e08ee2f87e6746ac77b07d5c94a65bcbd95
Author: Paul E. McKenney 
Date:   Mon Jun 22 14:51:18 2015 -0700

rcu: Add a fast-readers variant of SRCU

Dave Hansen's testing of single-byte I/O to tmpfs showed significant
system-level overhead from the memory barriers in srcu_read_lock()
and srcu_read_unlock().

This experimental not-for-merging commit therefore re-introduces the old
variant of SRCU that avoided read-side memory barriers.  This of course
also introduces that variant's slow grace periods.  There is no analog
to call_rcu(), nor is there an analog to rcu_barrier(), so this is not a
drop-in replacement for SRCU.  Unlike SRCU, this implementation cannot
be invoked from idle or offline CPUs.  This variant therefore gets its
own API: frsrcu_read_lock(), frsrcu_read_unlock(), and so on.

Reported-by: Dave Hansen 
Signed-off-by: Paul E. McKenney 

diff --git a/include/linux/frsrcu.h b/include/linux/frsrcu.h
new file mode 100644
index ..5ad60d2d5bca
--- /dev/null
+++ b/include/linux/frsrcu.h
@@ -0,0 +1,250 @@
+/*
+ * Fast-Reader Sleepable Read-Copy Update mechanism for mutual exclusion
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you can access it online at
+ * http://www.gnu.org/licenses/gpl-2.0.html.
+ *
+ * Copyright (C) IBM Corporation, 2006, 2015
+ *
+ * Author: Paul McKenney 
+ */
+
+#ifndef _LINUX_FRSRCU_H
+#define _LINUX_FRSRCU_H
+
+#include 
+#include 
+
+struct frsrcu_struct_array {
+   int c[2];
+};
+
+struct frsrcu_struct {
+   int completed;
+   struct frsrcu_struct_array __percpu *per_cpu_ref;
+   struct mutex mutex;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+   struct lockdep_map dep_map;
+#endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
+};
+
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+
+int __init_frsrcu_struct(struct frsrcu_struct *frsp, const char *name,
+struct lock_class_key *key);
+
+#define init_frsrcu_struct(frsp) \
+({ \
+   static struct lock_class_key __frsrcu_key; \
+   \
+   __init_frsrcu_struct((frsp), #frsp, &__frsrcu_key); \
+})
+
+#define __FRSRCU_DEP_MAP_INIT(frsrcu_name) .dep_map = { .name = #frsrcu_name },
+#else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
+
+int init_frsrcu_struct(struct frsrcu_struct *frsp);
+
+#define __FRSRCU_DEP_MAP_INIT(frsrcu_name)
+#endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
+
+#define __FRSRCU_STRUCT_INIT(name) \
+   {   \
+   

Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property

2015-06-22 Thread Krzysztof Kozlowski
On 23.06.2015 08:46, Krzysztof Kozlowski wrote:
> On 23.06.2015 00:04, Michael Turquette wrote:
>> Quoting Kukjin Kim (2015-06-21 18:46:26)
>>> Krzysztof Kozlowski wrote:

 On 22.06.2015 10:38, Kukjin Kim wrote:
> Krzysztof Kozlowski wrote:
>> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski :
>>> 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz 
>>> :
 From: Thomas Abraham 

 For Exynos4210 platforms, add CPU operating points and CPU
 regulator supply properties for migrating from Exynos specific
 cpufreq driver to using generic cpufreq driver.

 Changes by Bartlomiej:
 - removed Exynos5250 and Exynos5420 support for now

 Cc: Kukjin Kim 
 Cc: Doug Anderson 
 Cc: Javier Martinez Canillas 
 Cc: Andreas Faerber 
 Cc: Sachin Kamat 
 Cc: Andreas Farber 
 Cc: Javier Martinez Canillas 
 Signed-off-by: Thomas Abraham 
 Signed-off-by: Bartlomiej Zolnierkiewicz 
>>>
>>> Acked-by: Krzysztof Kozlowski 
>>
>> Rebased and applied to my tree, I'll sent it later to Kukjin unless he
>> picks it by himself from LKML.
>>
> Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied 
> based on
> v4.2-rc1 after v4.2-rc1 release.

 You mean it is for v4.3, not v4.2?

>>> Oops, yes v4.3.
>>>
>>> Thanks for the correction.
>>
>> Kukjin & Krzysztof,
>>
>> I'm confused on this point. I was planning to take patches 1, 2, 3, 5
>> and 6 towards 4.2 (e.g. in the pull request that I'll send out this
>> week).
>>
>> Is patch 4 going out for 4.2 or 4.3?
> 
> It is quite late for sending pull request to arm-soc for 4.2.
> For example SoCFPGA pull request from last week was rejected:
> http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980

Oh, that was wrong link. Here it is:
http://www.spinics.net/lists/arm-kernel/msg425911.html

> If you want to take it for 4.2 then I am fine with it but this will
> cause some easy but annoying conflicts. There aren't difficult - just
> most of nodes in board DTS changed their place.
> 
> Example of resolution (target file after merge, with cpu nodes reordered
> alphabetically):
> https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH 11/13] fs/locks: Replace lg_local with a per-cpu spinlock

2015-06-22 Thread Oleg Nesterov
Off-topic question,

On 06/22, Peter Zijlstra wrote:
>
> @@ -2650,9 +2660,8 @@ static void *locks_start(struct seq_file
>  
>   iter->li_pos = *pos + 1;
>   percpu_down_write(_rwsem);
> - lg_global_lock(_lock_lglock);
>   spin_lock(_lock_lock);
> - return seq_hlist_start_percpu(_lock_list, >li_cpu, *pos);
> + return seq_hlist_start_percpu(_lock_list.hlist, >li_cpu, 
> *pos);
>  }

...

>  static void locks_stop(struct seq_file *f, void *v)
>   __releases(_lock_lock)
>  {
>   spin_unlock(_lock_lock);

With or without this patch, why locks_start/locks_stop need to take/drop
blocked_lock_lock ?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[GIT PULL v2] SCSI updates for the 4.1+ merge window

2015-06-22 Thread James Bottomley
This is a resend of the original tree with the tag attached at original
commit c8806b6 snic: driver for Cisco SCSI HBA

---

This is the usual grab bag of driver updates (lpfc, hpsa,
megaraid_sas, cxgbi, be2iscsi) plus an assortment of minor updates.
There are also one new driver: the Cisco snic; the advansys driver has
been rewritten to get rid of the warning about converting it to the
DMA API, the tape statistics patch got in and finally, there's a
resuffle of SCSI header files to separate more cleanly initiator from
target mode (and better share the common definitions).

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc

The Short Changelog is:

Bart Van Assche (6):
  qla2xxx: Fix indentation
  qla2xxx: Comment out unreachable code
  target: Minimize SCSI header #include directives
  target: Correct a comment
  Move code that is used both by initiator and target drivers
  Split SCSI header files

Brian King (1):
  ipr: Increase default adapter init stage change timeout

Christoph Hellwig (9):
  virtio_scsi: don't select CONFIG_BLK_DEV_INTEGRITY
  megaraid_sas : swap whole register in megasas_register_aen
  megaraid_sas : fix megasas_fire_cmd_fusion calling convention
  megaraid_sas : add missing byte swaps to the sriov code
  megaraid_sas : bytewise or should be done on native endian variables
  megaraid_sas : move endianness conversion into caller of 
megasas_get_seq_num
  megaraid_sas : add endianness conversions for all ones
  megaraid_sas : add endianness annotations
  megaraid_sas : add missing __iomem annotations

Dan Carpenter (2):
  csiostor: fix an error code in csio_hw_init()
  sd: fix an error return in probe()

Don Brace (2):
  hpsa: change driver version
  hpsa: add in new controller id

Hannes Reinecke (24):
  scsi: Do not set cmd_per_lun to 1 in the host template
  advansys: Update to version 3.5 and remove compilation warning
  advansys: Remove call to dma_cache_sync()
  advansys: use spin_lock_irqsave() in interrupt handler
  advansys: Check for DMA mapping errors
  advansys: Remove cmd_per_lun setting
  advansys: Remove obsolete virtual memory mapping comment
  advansys: Remove 'a_flag'
  advansys: rename 'ASC_RQ_XX' to 'ADV_RQ_XX'
  advansys: Remove CC_VERY_LONG_SG_LIST
  advansys: Remove ASC_SCSI_REQ_Q
  advansys: scsi_q1->data_addr is little endian
  advansys: cleanup function return codes
  advansys: Make AscIsrChipHalted() a void function
  advansys: remove 'ERR' definition
  advansys: Remove 'TRUE' and 'FALSE' definitions
  advansys: use standard data types
  advansys: use 'bool' instead of 'int'
  advansys: Use dma_pool for sg elements
  advansys: Use DMA-API for mapping request blocks
  advansys: Use DMA-API for carrier buffer
  advansys: use DMA-API for mapping sense buffer
  advansys: use shared host tag map for command lookup
  advansys: use host_reset

James Bottomley (2):
  ips: remove pointless #warning
  scsi_scan: fix queue depth initialisation problem

James Smart (24):
  lpfc: Update version to 10.7.0.0 for upstream patch set.
  lpfc: Fix to drop PLOGIs from fabric node till LOGO processing completes
  lpfc: Fix scsi task management error message.
  lpfc: Fix cq_id masking problem.
  lpfc: Fix scsi prep dma buf error.
  lpfc: Add support for using block multi-queue
  lpfc: Devices are not discovered during takeaway/giveback testing
  lpfc: Fix vport deletion failure.
  lpfc: Check for active portpeerbeacon.
  lpfc: Update driver version for upstream patch set 10.6.0.1.
  lpfc: Change buffer pool empty message to miscellaneous category
  lpfc: Fix incorrect log message reported for empty FCF record.
  lpfc: Fix rport leak.
  lpfc: Correct loss of RSCNs during array takeaway/giveback testing.
  lpfc: Fix crash in vport_delete.
  lpfc: Fix to remove IRQF_SHARED flag for MSI/MSI-X vectors.
  lpfc: Fix discovery issue when changing from Pt2Pt to Fabric.
  lpfc: Correct reporting of vport state on fdisc command failure.
  lpfc: Add support for RDP ELS command.
  lpfc: Fix ABORTs WQ selection in terminate_rport_io
  lpfc: Correct reference counting of rport
  lpfc: Add support for ELS LCB.
  lpfc: Correct loss of target discovery after cable swap.
  lpfc: The lpfc driver does not issue RFF_ID and RFT_ID in the correct 
sequence

Joe Handzik (3):
  hpsa: add more ioaccel2 error handling, including underrun statuses.
  hpsa: Get queue depth from identify physical bmic for physical disks.
  hpsa: use ioaccel2 path to submit IOs to physical drives in HBA mode.

Johannes Thumshirn (1):
  advansys: fix compilation errors and warnings when CONFIG_PCI is not set

John Soni Jose (6):
  be2iscsi : Bump the driver version
  be2iscsi : 

Re: [PATCH 02/13] driver-core: defer all probes until late_initcall

2015-06-22 Thread Rob Herring
On Fri, Jun 19, 2015 at 6:20 PM, Rafael J. Wysocki  wrote:
> On Friday, June 19, 2015 03:36:46 PM Tomeu Vizoso wrote:
>> On 18 June 2015 at 23:50, Rafael J. Wysocki  wrote:
>> > On Wednesday, June 17, 2015 03:42:12 PM Tomeu Vizoso wrote:
>> >> To decrease the chances of devices deferring their probes because of
>> >> dependencies not having probed yet because of their drivers not having
>> >> registered yet, delay all probing until the late initcall level.
>> >>
>> >> This will allow us to avoid deferred probes completely later by probing
>> >> dependencies on demand, or by probing them in dependency order.
>> >>
>> >> Signed-off-by: Tomeu Vizoso 
>> >> ---
>> >>  drivers/base/dd.c | 8 +++-
>> >>  1 file changed, 7 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> >> index a638bbb..18438aa 100644
>> >> --- a/drivers/base/dd.c
>> >> +++ b/drivers/base/dd.c
>> >> @@ -407,6 +407,12 @@ int driver_probe_device(struct device_driver *drv, 
>> >> struct device *dev)
>> >>   if (!device_is_registered(dev))
>> >>   return -ENODEV;
>> >>
>> >> + /* Defer all probes until we start processing the queue */
>> >> + if (!driver_deferred_probe_enable) {
>> >> + driver_deferred_probe_add(dev);
>> >
>> > Do I think correctly that this will effectively force everybody to use 
>> > deferred
>> > probing?
>>
>> Guess it depends on the meaning of "using deferred probing". It will
>> defer the probe of the first device to late_initcall (which will
>> happen much earlier in time than before), but afterwards all built-in
>> drivers will be available and depending on the order in which we try
>> to probe devices, none may actually ask to defer its probe.
>
> So this will break things like the PNP system driver which relies on probing
> stuff at the fs_initcall stage for correctness.  It may also break other
> things with similar assumptions.

Yes, but I think that this can be done for only OF based devices
rather than globally for all platform devices and solve that problem.
Matching is already dependent of the type of device.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 00/21] On-demand device registration

2015-06-22 Thread Rob Herring
On Mon, Jun 22, 2015 at 10:23 AM, Tomeu Vizoso
 wrote:
> On 28 May 2015 at 06:33, Rob Herring  wrote:
>> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
>>  wrote:
>>> Hello,
>>>
>>> I have a problem with the panel on my Tegra Chromebook taking longer than
>>> expected to be ready during boot (Stéphane Marchesin reported what is
>>> basically the same issue in [0]), and have looked into ordered probing as a
>>> better way of solving this than moving nodes around in the DT or playing 
>>> with
>>> initcall levels.
>>>
>>> While reading the thread [1] that Alexander Holler started with his series 
>>> to
>>> make probing order deterministic, it occurred to me that it should be 
>>> possible
>>> to achieve the same by registering devices as they are referenced by other
>>> devices.
>>
>> I like the concept and novel approach.
>>
>>> This basically reuses the information that is already implicit in the 
>>> probe()
>>> implementations, saving us from refactoring existing drivers or adding
>>> information to DTBs.
>>>
>>> Something I'm not completely happy with is that I have had to move the call 
>>> to
>>> of_platform_populate after all platform drivers have been registered.
>>> Otherwise I don't see how I could register drivers on demand as we don't 
>>> have
>>> yet each driver's compatible strings.
>>
>> Yeah, this is the opposite of what we'd really like.
>
> Can you elaborate on the reasons why we would like to have devices
> registered before built-in drivers finish registering, even if we
> don't probe them yet?

My main thought was for modules we will almost always have devices
appearing first. More generally, we can have devices and drivers
coming or going at any point in time and should not put restrictions
on ordering.

Also, I think all the probe ordering and dependency tracking should be
done within the driver core (i.e. dependencies are a list of struct
devices). At some level it has to become firmware specific, but we
want to minimize that part. I could be convinced otherwise and you
have put more thought into this problem than I have.

>> Ideally, we would
>> have a solution that works for modules too. However, we're no worse
>> off. We pretty much build-in dependencies to avoid module ordering
>> problems.
>
> Nod, I haven't looked yet at requesting modules on-demand, but I guess
> it should be doable. Modules that have dependencies described in the
> firmware should get them probed automatically already though.
>
>> Perhaps we need to make the probing on-demand rather than simply on
>> device<->driver match occurring.
>
> I'm afraid that too much old code depends on that. For example, Rafael
> pointed out to the PNP subsystem, which registers a driver that will
> probe devices with the EISA ID PNP0c02 to reserve memory regions for
> devices that will be probed later.
>
> http://lxr.free-electrons.com/source/drivers/pnp/system.c
>
> My understanding is that probing of PNP0c02 devices must happen before
> the actual devices that depend on those regions are probed, so if we
> decoupled the probing from the driver/device registration, we would be
> breaking that assumption.

That shouldn't matter as PNP matching is PNP specific. We already have
different ways of matching with device/driver name or of_match_table
for example. Changing how and when OF matching occurs would not affect
PNP matching. We do matching on device and driver add currently. For
the "when" part, we would need to add what I'll call async matching or
deferred matching which in addition to matching on the of_match_table
also matches on the dependency list having probed. Your last series
essentially does this, but the difference is yours is not OF specific
and I think it needs to be. I mean it is OF specific only in the
aspect that matching already is. From a driver and subsystem
standpoint, it should not be OF specific much like deferred probe is
not OF specific, but in reality only occurs (currently) on OF probed
drivers.

>>> For machs that don't move of_platform_populate() to a later point, these
>>> patches shouldn't cause any problems but it's not guaranteed that we'll 
>>> avoid
>>> all the deferred probes as some drivers may not be registered yet.
>>
>> Ideally, of_platform_populate is not explicitly called by each
>> platform. So I think we need to make this work for the default case.
>
> The problem is that some platforms will need fixing because some
> initcalls assume that some devices will have been registered already,
> or even probed. I think removing those assumptions shouldn't be
> problematic because I haven't had much trouble with this on the four
> platforms I have tested with, but I cannot test every board that is
> supported upstream.
>
> I can ask though the KernelCI folks to boot my branch in all their
> boards and make sure that those work when of_platform_populate is
> called in late_initcall.

I'd imagine Kevin would be happy to. That is still a subset of h/w, so
we'd need a way to disable any solution.

[PATCH 1/3] USB: Export usb_wakeup_enabled_descendants()

2015-06-22 Thread Douglas Anderson
In (e583d9d USB: global suspend and remote wakeup don't mix) we
introduced wakeup_enabled_descendants() as a static function.  We'd
like to use this function in USB controller drivers to know if we
should keep the controller on during suspend time, since doing so has
a power impact.

Signed-off-by: Douglas Anderson 
---
 drivers/usb/core/hub.c  | 7 ---
 include/linux/usb/hcd.h | 5 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 43cb2f2..fdc59db 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3034,13 +3034,14 @@ static int usb_disable_remote_wakeup(struct usb_device 
*udev)
 }
 
 /* Count of wakeup-enabled devices at or below udev */
-static unsigned wakeup_enabled_descendants(struct usb_device *udev)
+unsigned usb_wakeup_enabled_descendants(struct usb_device *udev)
 {
struct usb_hub *hub = usb_hub_to_struct_hub(udev);
 
return udev->do_remote_wakeup +
(hub ? hub->wakeup_enabled_descendants : 0);
 }
+EXPORT_SYMBOL_GPL(usb_wakeup_enabled_descendants);
 
 /*
  * usb_port_suspend - suspend a usb device's upstream port
@@ -3149,7 +3150,7 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
 * Therefore we will turn on the suspend feature if udev or any of its
 * descendants is enabled for remote wakeup.
 */
-   else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) > 0)
+   else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)
status = set_port_feature(hub->hdev, port1,
USB_PORT_FEAT_SUSPEND);
else {
@@ -3548,7 +3549,7 @@ static int hub_suspend(struct usb_interface *intf, 
pm_message_t msg)
}
if (udev)
hub->wakeup_enabled_descendants +=
-   wakeup_enabled_descendants(udev);
+   usb_wakeup_enabled_descendants(udev);
}
 
if (hdev->do_remote_wakeup && hub->quirk_check_port_auto_suspend) {
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index c9aa779..30d74c9 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -626,11 +626,16 @@ extern wait_queue_head_t usb_kill_urb_queue;
 #define usb_endpoint_out(ep_dir)   (!((ep_dir) & USB_DIR_IN))
 
 #ifdef CONFIG_PM
+extern unsigned usb_wakeup_enabled_descendants(struct usb_device *udev);
 extern void usb_root_hub_lost_power(struct usb_device *rhdev);
 extern int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg);
 extern int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg);
 extern void usb_hcd_resume_root_hub(struct usb_hcd *hcd);
 #else
+static inline unsigned usb_wakeup_enabled_descendants(struct usb_device *udev)
+{
+   return 0;
+}
 static inline void usb_hcd_resume_root_hub(struct usb_hcd *hcd)
 {
return;
-- 
2.4.3.573.g4eafbef

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch v2 2/2] pinctrl: samsung: remove "out of memory" messages

2015-06-22 Thread Krzysztof Kozlowski
On 23.06.2015 00:13, Dan Carpenter wrote:
> Checkpatch.pl complains about these:
> 
> WARNING: Possible unnecessary 'out of memory' message
> 
> The messages use a little extra RAM and they add a few extra lines of
> code.  We're probably never going to hit these out of memory situations
> but if we did then kmalloc() has pretty good error messages built-in.
> 
> Signed-off-by: Dan Carpenter 


Looks good:
Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


> 
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c 
> b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
> index fa84db6..5574b8a 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
> @@ -203,10 +203,8 @@ static int exynos5440_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
>  
>   /* Allocate memory for pin-map entries */
>   map = kzalloc(sizeof(*map) * map_cnt, GFP_KERNEL);
> - if (!map) {
> - dev_err(dev, "could not alloc memory for pin-maps\n");
> + if (!map)
>   return -ENOMEM;
> - }
>   *nmaps = 0;
>  
>   /*
> @@ -214,10 +212,8 @@ static int exynos5440_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
>* from the node name from which these map entries are be created.
>*/
>   gname = kasprintf(GFP_KERNEL, "%s%s", np->name, GROUP_SUFFIX);
> - if (!gname) {
> - dev_err(dev, "failed to alloc memory for group name\n");
> + if (!gname)
>   goto free_map;
> - }
>  
>   /*
>* don't have config options? then skip over to creating function
> @@ -228,10 +224,8 @@ static int exynos5440_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
>  
>   /* Allocate memory for config entries */
>   cfg = kzalloc(sizeof(*cfg) * cfg_cnt, GFP_KERNEL);
> - if (!cfg) {
> - dev_err(dev, "failed to alloc memory for configs\n");
> + if (!cfg)
>   goto free_gname;
> - }
>  
>   /* Prepare a list of config settings */
>   for (idx = 0, cfg_cnt = 0; idx < ARRAY_SIZE(pcfgs); idx++) {
> @@ -253,10 +247,8 @@ skip_cfgs:
>   if (of_find_property(np, "samsung,exynos5440-pin-function", NULL)) {
>   fname = kasprintf(GFP_KERNEL,
> "%s%s", np->name, FUNCTION_SUFFIX);
> - if (!fname) {
> - dev_err(dev, "failed to alloc memory for func name\n");
> + if (!fname)
>   goto free_cfg;
> - }
>  
>   map[*nmaps].data.mux.group = gname;
>   map[*nmaps].data.mux.function = fname;
> @@ -647,10 +639,8 @@ static int exynos5440_pinctrl_parse_dt_pins(struct 
> platform_device *pdev,
>   }
>  
>   *pin_list = devm_kzalloc(dev, *npins * sizeof(**pin_list), GFP_KERNEL);
> - if (!*pin_list) {
> - dev_err(dev, "failed to allocate memory for pin list\n");
> + if (!*pin_list)
>   return -ENOMEM;
> - }
>  
>   return of_property_read_u32_array(cfg_np, "samsung,exynos5440-pins",
>   *pin_list, *npins);
> @@ -678,17 +668,15 @@ static int exynos5440_pinctrl_parse_dt(struct 
> platform_device *pdev,
>   return -EINVAL;
>  
>   groups = devm_kzalloc(dev, grp_cnt * sizeof(*groups), GFP_KERNEL);
> - if (!groups) {
> - dev_err(dev, "failed allocate memory for ping group list\n");
> + if (!groups)
>   return -EINVAL;
> - }
> +
>   grp = groups;
>  
>   functions = devm_kzalloc(dev, grp_cnt * sizeof(*functions), GFP_KERNEL);
> - if (!functions) {
> - dev_err(dev, "failed to allocate memory for function list\n");
> + if (!functions)
>   return -EINVAL;
> - }
> +
>   func = functions;
>  
>   /*
> @@ -708,10 +696,8 @@ static int exynos5440_pinctrl_parse_dt(struct 
> platform_device *pdev,
>   /* derive pin group name from the node name */
>   gname = devm_kasprintf(dev, GFP_KERNEL,
>  "%s%s", cfg_np->name, GROUP_SUFFIX);
> - if (!gname) {
> - dev_err(dev, "failed to alloc memory for group name\n");
> + if (!gname)
>   return -ENOMEM;
> - }
>  
>   grp->name = gname;
>   grp->pins = pin_list;
> @@ -727,18 +713,13 @@ skip_to_pin_function:
>   /* derive function name from the node name */
>   fname = devm_kasprintf(dev, GFP_KERNEL,
>  "%s%s", cfg_np->name, FUNCTION_SUFFIX);
> - if (!fname) {
> - dev_err(dev, "failed to alloc memory for func name\n");
> + if (!fname)
>   return -ENOMEM;
> - }
>  
>   func->name = fname;
>   func->groups = devm_kzalloc(dev, sizeof(char *), GFP_KERNEL);
> - if (!func->groups) {
> - dev_err(dev, 

[PATCH 2/3] Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB

2015-06-22 Thread Douglas Anderson
Some SoCs with a dwc2 USB controller may need to keep the PHY on to
support remote wakeup.  Allow specifying this as a device tree
property.

Signed-off-by: Douglas Anderson 
---
 Documentation/devicetree/bindings/usb/dwc2.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index fd132cb..84d258d 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -17,6 +17,9 @@ Refer to clk/clock-bindings.txt for generic clock consumer 
properties
 Optional properties:
 - phys: phy provider specifier
 - phy-names: shall be "usb2-phy"
+- snps,need-phy-for-wake: if present indicates that the phy needs to be left
+  on for remote wakeup during suspend.
+
 Refer to phy/phy-bindings.txt for generic phy consumer properties
 - dr_mode: shall be one of "host", "peripheral" and "otg"
   Refer to usb/generic.txt
@@ -35,4 +38,5 @@ Example:
clock-names = "otg";
phys = <>;
phy-names = "usb2-phy";
+   snps,need-phy-for-wake;
 };
-- 
2.4.3.573.g4eafbef

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/3] USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled

2015-06-22 Thread Douglas Anderson
If the 'snps,need-phy-for-wake' is set in the device tree then:

- We know that we can wakeup, so call device_set_wakeup_capable().
  The USB core will use this knowledge to enable wakeup by default.
- We know that we should keep the PHY on during suspend if something
  on our root hub needs remote wakeup.  This requires the patch (USB:
  Export usb_wakeup_enabled_descendants()).  Note that we don't keep
  the PHY on at suspend time if it's not needed because it would be a
  power draw.

If we later find some users of dwc2 that can support wakeup without
keeping the PHY on we may want to add a way to call
device_set_wakeup_capable() without keeping the PHY on at suspend
time.

Signed-off-by: Chris Zhong 
Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/core.h |  2 ++
 drivers/usb/dwc2/platform.c | 45 +++--
 2 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 53b8de0..b60a1e8 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -687,6 +687,8 @@ struct dwc2_hsotg {
enum usb_dr_mode dr_mode;
unsigned int hcd_enabled:1;
unsigned int gadget_enabled:1;
+   unsigned int need_phy_for_wake:1;
+   unsigned int phy_off_for_suspend:1;
 
struct phy *phy;
struct usb_phy *uphy;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 9093530..38fce75 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -42,7 +42,9 @@
 #include 
 #include 
 #include 
+#include 
 
+#include 
 #include 
 
 #include "core.h"
@@ -222,6 +224,10 @@ static int dwc2_driver_probe(struct platform_device *dev)
 
hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
 
+   hsotg->need_phy_for_wake =
+   of_property_read_bool(dev->dev.of_node,
+ "snps,need-phy-for-wake");
+
/*
 * Attempt to find a generic PHY, then look for an old style
 * USB PHY
@@ -265,6 +271,14 @@ static int dwc2_driver_probe(struct platform_device *dev)
hsotg->gadget_enabled = 1;
}
 
+   /*
+* If we need PHY for wakeup we must be wakeup capable.
+* When we have a device that can wake without the PHY we
+* can adjust this condition.
+*/
+   if (hsotg->need_phy_for_wake)
+   device_set_wakeup_capable(>dev, true);
+
if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
retval = dwc2_hcd_init(hsotg, irq);
if (retval) {
@@ -282,6 +296,28 @@ static int dwc2_driver_probe(struct platform_device *dev)
return retval;
 }
 
+static bool __maybe_unused dwc2_can_poweroff_phy(struct dwc2_hsotg *dwc2)
+{
+   struct usb_device *root_hub = dwc2_hsotg_to_hcd(dwc2)->self.root_hub;
+
+   if (dwc2->lx_state == DWC2_L0)
+   return false;
+
+   /* If the controller isn't allowed to wakeup then we can power off. */
+   if (!device_may_wakeup(dwc2->dev))
+   return true;
+
+   /*
+* We don't want to power off the PHY if something under the
+* root hub has wakeup enabled.
+*/
+   if (usb_wakeup_enabled_descendants(root_hub))
+   return false;
+
+   /* No reason to keep the PHY powered, so allow poweroff */
+   return true;
+}
+
 static int __maybe_unused dwc2_suspend(struct device *dev)
 {
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
@@ -290,8 +326,10 @@ static int __maybe_unused dwc2_suspend(struct device *dev)
if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_suspend(dwc2);
} else {
-   if (dwc2->lx_state == DWC2_L0)
+   if (!dwc2_can_poweroff_phy(dwc2))
return 0;
+
+   dwc2->phy_off_for_suspend = true;
phy_exit(dwc2->phy);
phy_power_off(dwc2->phy);
 
@@ -307,9 +345,12 @@ static int __maybe_unused dwc2_resume(struct device *dev)
if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_resume(dwc2);
} else {
+   if (!dwc2->phy_off_for_suspend)
+   return ret;
+
phy_power_on(dwc2->phy);
phy_init(dwc2->phy);
-
+   dwc2->phy_off_for_suspend = false;
}
return ret;
 }
-- 
2.4.3.573.g4eafbef

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 0/3] dwc2 patches to allow wakeup on Rockchip rk3288

2015-06-22 Thread Douglas Anderson
This series of patches, together with
 from Chris Zhong and a
dts change allow us to wake up from a USB device on rk3288 boards.
The patches were tested on rk3288-jerry in the chromeos-3.14 kernel.
The chromeos-3.14 kernel tested included a full set of dwc2 backports
from upstream, so this is expected to function upstream once we get
everything setup there.


Douglas Anderson (3):
  USB: Export usb_wakeup_enabled_descendants()
  Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB
  USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled

 Documentation/devicetree/bindings/usb/dwc2.txt |  4 +++
 drivers/usb/core/hub.c |  7 ++--
 drivers/usb/dwc2/core.h|  2 ++
 drivers/usb/dwc2/platform.c| 45 --
 include/linux/usb/hcd.h|  5 +++
 5 files changed, 58 insertions(+), 5 deletions(-)

-- 
2.4.3.573.g4eafbef

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch v2 1/2] pinctrl: samsung: don't truncate the last char

2015-06-22 Thread Krzysztof Kozlowski
On 23.06.2015 00:12, Dan Carpenter wrote:
> We were allocating enough space because sizeof("-grp") and
> sizeof("-mux") are both equal to 5 but in the snprintf() we only allowed
> for 4 characters so the last 'p' and 'x' characters were truncated.
> 
> The allocate and sprintf can be done in one step with the kasprintf().
> 
> Signed-off-by: Dan Carpenter 

Looks good:
Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


> 
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c 
> b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
> index f5619fb..fa84db6 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
> @@ -44,9 +44,7 @@
>  #define PIN_NAME_LENGTH  10
>  
>  #define GROUP_SUFFIX "-grp"
> -#define GSUFFIX_LEN  sizeof(GROUP_SUFFIX)
>  #define FUNCTION_SUFFIX  "-mux"
> -#define FSUFFIX_LEN  sizeof(FUNCTION_SUFFIX)
>  
>  /*
>   * pin configuration type and its value are packed together into a 16-bits.
> @@ -215,12 +213,11 @@ static int exynos5440_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
>* Allocate memory for pin group name. The pin group name is derived
>* from the node name from which these map entries are be created.
>*/
> - gname = kzalloc(strlen(np->name) + GSUFFIX_LEN, GFP_KERNEL);
> + gname = kasprintf(GFP_KERNEL, "%s%s", np->name, GROUP_SUFFIX);
>   if (!gname) {
>   dev_err(dev, "failed to alloc memory for group name\n");
>   goto free_map;
>   }
> - snprintf(gname, strlen(np->name) + 4, "%s%s", np->name, GROUP_SUFFIX);
>  
>   /*
>* don't have config options? then skip over to creating function
> @@ -254,13 +251,12 @@ static int exynos5440_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
>  skip_cfgs:
>   /* create the function map entry */
>   if (of_find_property(np, "samsung,exynos5440-pin-function", NULL)) {
> - fname = kzalloc(strlen(np->name) + FSUFFIX_LEN, GFP_KERNEL);
> + fname = kasprintf(GFP_KERNEL,
> +   "%s%s", np->name, FUNCTION_SUFFIX);
>   if (!fname) {
>   dev_err(dev, "failed to alloc memory for func name\n");
>   goto free_cfg;
>   }
> - snprintf(fname, strlen(np->name) + 4, "%s%s", np->name,
> -  FUNCTION_SUFFIX);
>  
>   map[*nmaps].data.mux.group = gname;
>   map[*nmaps].data.mux.function = fname;
> @@ -710,14 +706,12 @@ static int exynos5440_pinctrl_parse_dt(struct 
> platform_device *pdev,
>   }
>  
>   /* derive pin group name from the node name */
> - gname = devm_kzalloc(dev, strlen(cfg_np->name) + GSUFFIX_LEN,
> - GFP_KERNEL);
> + gname = devm_kasprintf(dev, GFP_KERNEL,
> +"%s%s", cfg_np->name, GROUP_SUFFIX);
>   if (!gname) {
>   dev_err(dev, "failed to alloc memory for group name\n");
>   return -ENOMEM;
>   }
> - snprintf(gname, strlen(cfg_np->name) + 4, "%s%s", cfg_np->name,
> -  GROUP_SUFFIX);
>  
>   grp->name = gname;
>   grp->pins = pin_list;
> @@ -731,14 +725,12 @@ skip_to_pin_function:
>   continue;
>  
>   /* derive function name from the node name */
> - fname = devm_kzalloc(dev, strlen(cfg_np->name) + FSUFFIX_LEN,
> - GFP_KERNEL);
> + fname = devm_kasprintf(dev, GFP_KERNEL,
> +"%s%s", cfg_np->name, FUNCTION_SUFFIX);
>   if (!fname) {
>   dev_err(dev, "failed to alloc memory for func name\n");
>   return -ENOMEM;
>   }
> - snprintf(fname, strlen(cfg_np->name) + 4, "%s%s", cfg_np->name,
> -  FUNCTION_SUFFIX);
>  
>   func->name = fname;
>   func->groups = devm_kzalloc(dev, sizeof(char *), GFP_KERNEL);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v5] NET: Add ezchip ethernet driver

2015-06-22 Thread Paul Gortmaker
[Re: [PATCH v5] NET: Add ezchip ethernet driver] On 22/06/2015 (Mon 10:45) 
Mahesh Bandewar wrote:

> On Tue, Jun 16, 2015 at 7:35 AM, Noam Camus  wrote:
> >
> > From: Noam Camus 
> >
> > Simple LAN device for debug or management purposes.
> > Device supports interrupts for RX and TX(completion).
> > Device does not have DMA ability.
> >
> > Signed-off-by: Noam Camus 
> > Signed-off-by: Tal Zilcer 
> > Acked-by: Alexey Brodkin 
> > ---
> > Change log for v5:
> > Basically its all based on Florian comments.
> > Main items are:
> > 1) Move all interrupt chore to bottom-half
> > 2) use memcpy_toio/fromio
> > 3) dev_kfree_skb() moved to bottom-half
> > 4) add set_rx_mode callback
> > 5) use platform api toward non-DT platforms
> > ---

[...]

> > diff --git a/drivers/net/ethernet/ezchip/Kconfig 
> > b/drivers/net/ethernet/ezchip/Kconfig
> > new file mode 100644
> > index 000..d031177
> > --- /dev/null
> > +++ b/drivers/net/ethernet/ezchip/Kconfig
> > @@ -0,0 +1,27 @@
> > +#
> > +# EZchip network device configuration
> > +#
> > +
> > +config NET_VENDOR_EZCHIP
> > +   bool "EZchip devices"
> > +   default y
> >
> Why this has to be included in the default build? Shouldn't it be
> either "m" or "N" by default?
> 

Mahesh, in the future please don't quote 1200 lines of code in its
entirety just to add these two lines of comment, which in this case
happen to also be incorrect.  It is a NET_VENDOR_ option which
is just the lead in as it clearly states below if we go look...

> > +   ---help---
> > + If you have a network (Ethernet) device belonging to this class, 
> > say Y
> > + and read the Ethernet-HOWTO, available from
> > + .

Noam, since you are unlikely to get this in final from before net-next
closes (happening any time now), please delete the Howto reference when
you resubmit in two weeks, assuming that my cleanup here:

   https://patchwork.ozlabs.org/patch/487080/

gets applied to this release.

> > +
> > + Note that the answer to this question doesn't directly affect the
> > + kernel: saying N will just cause the configurator to skip all
> > + the questions about EZchip devices. If you say Y, you will be 
> > asked for
> > + your specific device in the following questions.

Mahesh, here above.  So he's not doing a "default y" on an actual driver
(which, if he were, yes that would be wrong.)  What worries me more
though, is that ...

> > +
> > +if NET_VENDOR_EZCHIP
> > +
> > +config EZCHIP_NPS_MANAGEMENT_ENET
> > +   tristate "EZchip NPS management enet support"

...there is no dependency line here.  None.  Noam - this implicitly
means that you expect this to build on all arch for all combinations of
.config files.  At a quick glance I see a dts fragment, and I also see a
call to of_get_mac_address() so I'm thinking there needs to be some
dependency here, on OF or OF_NET, or... ?

Paul.
--

> > +   ---help---
> > + Simple LAN device for debug or management purposes.
> > + Device supports interrupts for RX and TX(completion).
> > + Device does not have DMA ability.
> > +
> > +endif
> > diff --git a/drivers/net/ethernet/ezchip/Makefile 
> > b/drivers/net/ethernet/ezchip/Makefile
> > new file mode 100644
> > index 000..e490176
> > --- /dev/null
> > +++ b/drivers/net/ethernet/ezchip/Makefile

[snip]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property

2015-06-22 Thread Krzysztof Kozlowski
On 23.06.2015 00:04, Michael Turquette wrote:
> Quoting Kukjin Kim (2015-06-21 18:46:26)
>> Krzysztof Kozlowski wrote:
>>>
>>> On 22.06.2015 10:38, Kukjin Kim wrote:
 Krzysztof Kozlowski wrote:
> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski :
>> 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz 
>> :
>>> From: Thomas Abraham 
>>>
>>> For Exynos4210 platforms, add CPU operating points and CPU
>>> regulator supply properties for migrating from Exynos specific
>>> cpufreq driver to using generic cpufreq driver.
>>>
>>> Changes by Bartlomiej:
>>> - removed Exynos5250 and Exynos5420 support for now
>>>
>>> Cc: Kukjin Kim 
>>> Cc: Doug Anderson 
>>> Cc: Javier Martinez Canillas 
>>> Cc: Andreas Faerber 
>>> Cc: Sachin Kamat 
>>> Cc: Andreas Farber 
>>> Cc: Javier Martinez Canillas 
>>> Signed-off-by: Thomas Abraham 
>>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>>
>> Acked-by: Krzysztof Kozlowski 
>
> Rebased and applied to my tree, I'll sent it later to Kukjin unless he
> picks it by himself from LKML.
>
 Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied 
 based on
 v4.2-rc1 after v4.2-rc1 release.
>>>
>>> You mean it is for v4.3, not v4.2?
>>>
>> Oops, yes v4.3.
>>
>> Thanks for the correction.
> 
> Kukjin & Krzysztof,
> 
> I'm confused on this point. I was planning to take patches 1, 2, 3, 5
> and 6 towards 4.2 (e.g. in the pull request that I'll send out this
> week).
> 
> Is patch 4 going out for 4.2 or 4.3?

It is quite late for sending pull request to arm-soc for 4.2.
For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980

If you want to take it for 4.2 then I am fine with it but this will
cause some easy but annoying conflicts. There aren't difficult - just
most of nodes in board DTS changed their place.

Example of resolution (target file after merge, with cpu nodes reordered
alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd

Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] extcon: palmas: Fix NULL pointer error

2015-06-22 Thread Krzysztof Kozlowski
2015-06-22 18:52 GMT+09:00 Chanwoo Choi :
> This patch fixes NULL pointer error by removing the unneeded kfree() call
> of edev->name because extcon-palmas no longer allocate the memory for 
> edev->name.
>
> Fixes: d71aadda19f8 ("extcon: Remove the optional name of extcon device")
> Signed-off-by: Chanwoo Choi 
> ---
> Changes from v1:
> - Remove the palmas_usb_remove() due to no operation.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v4] hexdump: fix for non-aligned buffers

2015-06-22 Thread Horacio Mijail Antón Quiles
An hexdump with a buf not aligned to the groupsize causes
non-naturally-aligned memory accesses. This was causing a kernel panic on
the processor BlackFin BF527, when such an unaligned buffer was fed by the
function ubifs_scanned_corruption in fs/ubifs/scan.c .

To fix this, if the buffer is not aligned to groupsize in a platform which
does not define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, then change the
groupsize to 1, so alignment is no longer a problem.
This behavior is coherent with the way the function currently deals with
inappropriate parameter combinations, which is to fall back to safe
"defaults", even if that means changing the output format and the implicit
access patterns that could have been expected.

Signed-off-by: Horacio Mijail Antón Quiles 
---
Changes in v4:
  - Really corrected patch format issues! (per Joe Perches')

Changes in v3:
  - Corrected patch format issues (per Joe Perches' indication)
  - Changed git's mail header to avoid encoding issues
  
Changes in v2:
  - Changed from ad-hoc calculation to IS_ALIGNED() for readability (per 
  Joe Perches' indication)
  - Made the explanation clearer (aligned vs naturally aligned)

---
 lib/hexdump.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/hexdump.c b/lib/hexdump.c
index 7ea0969..a3bd5d5 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -124,6 +124,11 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
if ((len % groupsize) != 0) /* no mixed size output */
groupsize = 1;
 
+   /* fall back to 1-byte groups if buf is not aligned to groupsize */
+   if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) &&
+   !IS_ALIGNED((uintptr_t)buf, groupsize))
+   groupsize = 1;
+
ngroups = len / groupsize;
ascii_column = rowsize * 2 + rowsize / groupsize + 1;
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 2/3] clk: stm32: Add clock driver for STM32F4[23]xxx devices

2015-06-22 Thread Stephen Boyd
On 06/10, Daniel Thompson wrote:
> The driver supports decoding and statically modelling PLL state (i.e.
> we inherit state from bootloader) and provides support for all
> peripherals that support simple one-bit gated clocks. The covers all
> peripherals whose clocks come from the AHB, APB1 or APB2 buses.
> 
> It has been tested on an STM32F429I-Discovery board. The clock counts
> for TIM2, USART1 and SYSTICK are all set correctly and the wall clock
> looks OK when checked with a stopwatch. I have also tested a prototype
> driver for the RNG hardware. The RNG clock is correctly enabled by the
> framework (also did inverse test and proved that by changing DT to
> configure the wrong clock bit then we observe the RNG driver to fail).
> 
> Signed-off-by: Daniel Thompson 
> Reviewed-by: Maxime Coquelin 

I also squashed in some sparse fixes. Please check.

drivers/clk/clk-stm32f4.c:135:44:
warning: constant 0x00f17ef417ff is so big it is long
drivers/clk/clk-stm32f4.c:137:44:
warning: constant 0x04777f33f6fec9ff is so big it is long
drivers/clk/clk-stm32f4.c:206:12:
warning: symbol 'clk_register_apb_mul' was not declared. Should
it be static?
drivers/clk/clk-stm32f4.c:285:12:
warning: symbol 'stm32f4_rcc_lookup_clk' was not declared. Should
it be static?

---8<
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index c825bbd4335f..b9b12a742970 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -132,9 +132,9 @@ enum { SYSTICK, FCLK };
  * This bitmask tells us which bit offsets (0..192) on STM32F4[23]xxx
  * have gate bits associated with them. Its combined hweight is 71.
  */
-static const u64 stm32f42xx_gate_map[] = { 0x00f17ef417ff,
-  0x0001,
-  0x04777f33f6fec9ff };
+static const u64 stm32f42xx_gate_map[] = { 0x00f17ef417ffull,
+  0x0001ull,
+  0x04777f33f6fec9ffull };
 
 static struct clk *clks[MAX_CLKS];
 static DEFINE_SPINLOCK(stm32f4_clk_lock);
@@ -186,7 +186,7 @@ static long clk_apb_mul_round_rate(struct clk_hw *hw, 
unsigned long rate,
 }
 
 static int clk_apb_mul_set_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long parent_rate)
+   unsigned long parent_rate)
 {
/*
 * We must report success but we can do so unconditionally because
@@ -203,9 +203,9 @@ static const struct clk_ops clk_apb_mul_factor_ops = {
.recalc_rate = clk_apb_mul_recalc_rate,
 };
 
-struct clk *clk_register_apb_mul(struct device *dev, const char *name,
-const char *parent_name, unsigned long flags,
-u8 bit_idx)
+static struct clk *clk_register_apb_mul(struct device *dev, const char *name,
+   const char *parent_name,
+   unsigned long flags, u8 bit_idx)
 {
struct clk_apb_mul *am;
struct clk_init_data init;
@@ -282,7 +282,8 @@ static int stm32f4_rcc_lookup_clk_idx(u8 primary, u8 
secondary)
   (BIT_ULL_WORD(secondary) >= 2 ? hweight64(table[2]) : 0);
 }
 
-struct clk *stm32f4_rcc_lookup_clk(struct of_phandle_args *clkspec, void *data)
+static struct clk *
+stm32f4_rcc_lookup_clk(struct of_phandle_args *clkspec, void *data)
 {
int i = stm32f4_rcc_lookup_clk_idx(clkspec->args[0], clkspec->args[1]);
 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] of: acpi: Rename of_node() and acpi_node() to to_of_node() and to_acpi_node()

2015-06-22 Thread Rafael J. Wysocki
On Monday, June 22, 2015 10:38:53 PM Alexander Sverdlin wrote:
> Commit 8a0662d9 introduced of_node and acpi_node symbols in global namespace
> but there were already ~63 of_node local variables or function parameters
> (no single acpi_node though, but anyway).
> 
> After debugging undefined but used of_node local varible (which turned out
> to reference static function of_node() instead) it became clear that the names
> for the functions are too short and too generic for global scope.
> 
> Signed-off-by: Alexander Sverdlin 

Putting the whole world into the To: field of your messages is not a good idea
in general.

I'm fine with this change, personally.

Does anyone in the CC list have any objections?


> ---
> 
> Compile-tested on x86_64 with ACPI and ARM with OF.
> 
>  drivers/base/property.c  | 26 +-
>  drivers/gpio/gpiolib.c   |  4 ++--
>  drivers/leds/leds-gpio.c |  2 +-
>  include/acpi/acpi_bus.h  |  2 +-
>  include/linux/acpi.h |  4 ++--
>  include/linux/of.h   |  4 ++--
>  6 files changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 1d0b116..dfd4de6 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -128,9 +128,9 @@ EXPORT_SYMBOL_GPL(device_property_present);
>  bool fwnode_property_present(struct fwnode_handle *fwnode, const char 
> *propname)
>  {
>   if (is_of_node(fwnode))
> - return of_property_read_bool(of_node(fwnode), propname);
> + return of_property_read_bool(to_of_node(fwnode), propname);
>   else if (is_acpi_node(fwnode))
> - return !acpi_dev_prop_get(acpi_node(fwnode), propname, NULL);
> + return !acpi_dev_prop_get(to_acpi_node(fwnode), propname, NULL);
> 
>   return !!pset_prop_get(to_pset(fwnode), propname);
>  }
> @@ -285,10 +285,10 @@ EXPORT_SYMBOL_GPL(device_property_read_string);
>  ({ \
>   int _ret_; \
>   if (is_of_node(_fwnode_)) \
> - _ret_ = OF_DEV_PROP_READ_ARRAY(of_node(_fwnode_), _propname_, \
> + _ret_ = OF_DEV_PROP_READ_ARRAY(to_of_node(_fwnode_), 
> _propname_, \
>  _type_, _val_, _nval_); \
>   else if (is_acpi_node(_fwnode_)) \
> - _ret_ = acpi_dev_prop_read(acpi_node(_fwnode_), _propname_, \
> + _ret_ = acpi_dev_prop_read(to_acpi_node(_fwnode_), _propname_, \
>  _proptype_, _val_, _nval_); \
>   else \
>   _ret_ = pset_prop_read_array(to_pset(_fwnode_), _propname_, \
> @@ -424,11 +424,11 @@ int fwnode_property_read_string_array(struct 
> fwnode_handle *fwnode,
>  {
>   if (is_of_node(fwnode))
>   return val ?
> - of_property_read_string_array(of_node(fwnode), propname,
> -   val, nval) :
> - of_property_count_strings(of_node(fwnode), propname);
> + of_property_read_string_array(to_of_node(fwnode),
> +   propname, val, nval) :
> + of_property_count_strings(to_of_node(fwnode), propname);
>   else if (is_acpi_node(fwnode))
> - return acpi_dev_prop_read(acpi_node(fwnode), propname,
> + return acpi_dev_prop_read(to_acpi_node(fwnode), propname,
> DEV_PROP_STRING, val, nval);
> 
>   return pset_prop_read_array(to_pset(fwnode), propname,
> @@ -455,9 +455,9 @@ int fwnode_property_read_string(struct fwnode_handle 
> *fwnode,
>   const char *propname, const char **val)
>  {
>   if (is_of_node(fwnode))
> - return of_property_read_string(of_node(fwnode), propname, val);
> + return of_property_read_string(to_of_node(fwnode), propname, 
> val);
>   else if (is_acpi_node(fwnode))
> - return acpi_dev_prop_read(acpi_node(fwnode), propname,
> + return acpi_dev_prop_read(to_acpi_node(fwnode), propname,
> DEV_PROP_STRING, val, 1);
> 
>   return -ENXIO;
> @@ -475,13 +475,13 @@ struct fwnode_handle *device_get_next_child_node(struct 
> device *dev,
>   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
>   struct device_node *node;
> 
> - node = of_get_next_available_child(dev->of_node, 
> of_node(child));
> + node = of_get_next_available_child(dev->of_node, 
> to_of_node(child));
>   if (node)
>   return >fwnode;
>   } else if (IS_ENABLED(CONFIG_ACPI)) {
>   struct acpi_device *node;
> 
> - node = acpi_get_next_child(dev, acpi_node(child));
> + node = acpi_get_next_child(dev, to_acpi_node(child));
>   if (node)
>   return acpi_fwnode_handle(node);
>   }
> @@ -500,7 +500,7 @@ EXPORT_SYMBOL_GPL(device_get_next_child_node);
>  

[PATCH v6 9/9] nvmem: Add to MAINTAINERS for nvmem framework

2015-06-22 Thread Srinivas Kandagatla
This patch adds MAINTAINERS to nvmem framework.

Signed-off-by: Srinivas Kandagatla 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b2ef613..26e1829 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6993,6 +6993,15 @@ S:   Supported
 F: drivers/block/nvme*
 F: include/linux/nvme.h
 
+NVMEM FRAMEWORK
+M: Srinivas Kandagatla 
+M: Maxime Ripard 
+S: Maintained
+F: drivers/nvmem/
+F: Documentation/devicetree/bindings/nvmem/
+F: include/linux/nvmem-provider.h
+F: include/linux/nvmem-consumer.h
+
 NXP-NCI NFC DRIVER
 M: Clément Perrochaud 
 R: Charles Gorand 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Documentation/vDSO: don't build tests when cross compiling

2015-06-22 Thread Jonathan Corbet
On Mon, 22 Jun 2015 15:10:28 -0600
Jonathan Corbet  wrote:

> On Mon, 22 Jun 2015 16:41:10 -0400
> Paul Gortmaker  wrote:
> 
> > "These compilers are only functional for kernel builds. They cannot be
> > used to build userspace code"  
> 
> I guess that's probably the key point.  Maybe I should just apply the
> patches and be done with it.

I have done that, FWIW, with all three patches.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] PM / Domains: Avoid infinite loops in attach/detach code

2015-06-22 Thread Rafael J. Wysocki
On Monday, June 22, 2015 09:31:22 AM Geert Uytterhoeven wrote:
> If pm_genpd_{add,remove}_device() keeps on failing with -EAGAIN, we end
> up with an infinite loop in genpd_dev_pm_{at,de}tach().
> 
> This may happen due to a genpd.prepared_count imbalance.  This is a bug
> elsewhere, but it will result in a system lock up, possibly during
> reboot of an otherwise functioning system.
> 
> To avoid this, put a limit on the maximum number of loop iterations,
> including a simple back-off mechanism.  If the limit is reached, the
> operation will just fail.  An error message is already printed.
> 
> Signed-off-by: Geert Uytterhoeven 

This was too late for my first 4.2 pull request, but I may push it in the
second half of the merge window.  Does it depend on anything?

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] intel powerclamp: support Knights Landing

2015-06-22 Thread Rafael J. Wysocki
On Monday, June 22, 2015 04:51:13 PM Chandramouli, Dasaratharaman wrote:
> Can we make this patch available for 4.2

It is included in the power management and ACPI pull request for 4.1-rc1
I've just sent.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v6 8/9] nvmem: sunxi: Move the SID driver to the nvmem framework

2015-06-22 Thread Srinivas Kandagatla
From: Maxime Ripard 

Now that we have the nvmem framework, we can consolidate the common
driver code. Move the driver to the framework, and hopefully, it will
fix the sysfs file creation race.

Signed-off-by: Maxime Ripard 
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
Signed-off-by: Srinivas Kandagatla 
---
 Documentation/ABI/testing/sysfs-driver-sunxi-sid   |  22 ---
 .../bindings/misc/allwinner,sunxi-sid.txt  |  17 ---
 .../bindings/nvmem/allwinner,sunxi-sid.txt |  21 +++
 drivers/misc/eeprom/Kconfig|  13 --
 drivers/misc/eeprom/Makefile   |   1 -
 drivers/misc/eeprom/sunxi_sid.c| 156 
 drivers/nvmem/Kconfig  |  11 ++
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/sunxi-sid.c  | 160 +
 9 files changed, 194 insertions(+), 209 deletions(-)
 delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
 delete mode 100644 
Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
 create mode 100644 
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
 delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
 create mode 100644 drivers/nvmem/sunxi-sid.c

diff --git a/Documentation/ABI/testing/sysfs-driver-sunxi-sid 
b/Documentation/ABI/testing/sysfs-driver-sunxi-sid
deleted file mode 100644
index ffb9536..000
--- a/Documentation/ABI/testing/sysfs-driver-sunxi-sid
+++ /dev/null
@@ -1,22 +0,0 @@
-What:  /sys/devices/*//eeprom
-Date:  August 2013
-Contact:   Oliver Schinagl 
-Description:   read-only access to the SID (Security-ID) on current
-   A-series SoC's from Allwinner. Currently supports A10, A10s, A13
-   and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
-   whereas the newer A20 SoC exposes 512 bytes split into sections.
-   Besides the 16 bytes of SID, there's also an SJTAG area,
-   HDMI-HDCP key and some custom keys. Below a quick overview, for
-   details see the user manual:
-   0x000  128 bit root-key (sun[457]i)
-   0x010  128 bit boot-key (sun7i)
-   0x020   64 bit security-jtag-key (sun7i)
-   0x028   16 bit key configuration (sun7i)
-   0x02b   16 bit custom-vendor-key (sun7i)
-   0x02c  320 bit low general key (sun7i)
-   0x040   32 bit read-control access (sun7i)
-   0x064  224 bit low general key (sun7i)
-   0x080 2304 bit HDCP-key (sun7i)
-   0x1a0  768 bit high general key (sun7i)
-Users: any user space application which wants to read the SID on
-   Allwinner's A-series of CPU's.
diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt 
b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
deleted file mode 100644
index fabdf64..000
--- a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Allwinner sunxi-sid
-
-Required properties:
-- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
-- reg: Should contain registers location and length
-
-Example for sun4i:
-   sid@01c23800 {
-   compatible = "allwinner,sun4i-a10-sid";
-   reg = <0x01c23800 0x10>
-   };
-
-Example for sun7i:
-   sid@01c23800 {
-   compatible = "allwinner,sun7i-a20-sid";
-   reg = <0x01c23800 0x200>
-   };
diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt 
b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
new file mode 100644
index 000..d543ed3
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
@@ -0,0 +1,21 @@
+Allwinner sunxi-sid
+
+Required properties:
+- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example for sun4i:
+   sid@01c23800 {
+   compatible = "allwinner,sun4i-a10-sid";
+   reg = <0x01c23800 0x10>
+   };
+
+Example for sun7i:
+   sid@01c23800 {
+   compatible = "allwinner,sun7i-a20-sid";
+   reg = <0x01c23800 0x200>
+   };
diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
index 9536852f..04f2e1f 100644
--- a/drivers/misc/eeprom/Kconfig
+++ b/drivers/misc/eeprom/Kconfig
@@ -96,17 +96,4 @@ config EEPROM_DIGSY_MTC_CFG
 
  If unsure, say N.
 
-config EEPROM_SUNXI_SID
-   tristate "Allwinner sunxi security ID support"
-   depends on ARCH_SUNXI && SYSFS
-   help
- This is a driver for the 'security ID' available on various Allwinner
- devices.
-
- Due to the potential risks involved with 

Re: [RFC][PATCH 06/13] percpu-rwsem: Provide percpu_down_read_trylock()

2015-06-22 Thread Oleg Nesterov
On 06/22, Peter Zijlstra wrote:
>
> +static inline bool percpu_down_read_trylock(struct percpu_rw_semaphore *sem)
> +{
> + bool ret = true;
> +
> + preempt_disable();
> + __this_cpu_inc(*sem->refcount);
> + if (unlikely(!rcu_sync_is_idle(>rss)))
> + ret = __percpu_down_read_trylock(sem);
> + preempt_enable();
> +
> + if (ret)
> + rwsem_acquire_read(>rw_sem.dep_map, 0, 1, _RET_IP_);
> +
> + return ret;
> +}
...
> +bool __percpu_down_read_trylock(struct percpu_rw_semaphore *sem)
> +{
> + smp_mb(); /* A matches D */
> +
> + if (likely(smp_load_acquire(>state) != readers_block))
> + return true;
> +
> + __percpu_up_read(sem);
> +
> + return false;
> +}

Looks like we can slightly refactor this code to avoid the code
duplication. But this is minor too and we can do this later.

Reviewed-by: Oleg Nesterov 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v6 7/9] nvmem: qfprom: Add bindings for qfprom

2015-06-22 Thread Srinivas Kandagatla
This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
is based on simple nvmem framework.

Reviewed-by: Stephen Boyd 
Signed-off-by: Srinivas Kandagatla 
---
 Documentation/devicetree/bindings/nvmem/qfprom.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/qfprom.txt

diff --git a/Documentation/devicetree/bindings/nvmem/qfprom.txt 
b/Documentation/devicetree/bindings/nvmem/qfprom.txt
new file mode 100644
index 000..8a8d55f
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/qfprom.txt
@@ -0,0 +1,35 @@
+= Qualcomm QFPROM device tree bindings =
+
+This binding is intended to represent QFPROM which is found in most QCOM SOCs.
+
+Required properties:
+- compatible: should be "qcom,qfprom"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+   qfprom: qfprom@0070 {
+   compatible  = "qcom,qfprom";
+   reg = <0x0070 0x8000>;
+   ...
+   /* Data cells */
+   tsens_calibration: calib@404 {
+   reg = <0x4404 0x10>;
+   };
+   };
+
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+   tsens {
+   ...
+   nvmem-cell = <_calibration>;
+   nvmem-cell-names = "calibration";
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v6 5/9] Documentation: nvmem: add nvmem api level and how-to doc

2015-06-22 Thread Srinivas Kandagatla
This patch add basic how-to and api summary documentation for simple
NVMEM framework.

Signed-off-by: Srinivas Kandagatla 
---
 Documentation/nvmem/nvmem.txt | 151 ++
 1 file changed, 151 insertions(+)
 create mode 100644 Documentation/nvmem/nvmem.txt

diff --git a/Documentation/nvmem/nvmem.txt b/Documentation/nvmem/nvmem.txt
new file mode 100644
index 000..28b3579
--- /dev/null
+++ b/Documentation/nvmem/nvmem.txt
@@ -0,0 +1,151 @@
+   NVMEM SUBSYSTEM
+ Srinivas Kandagatla 
+
+This document explains the Simple NVMEM Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+===
+*NVMEM* is the abbreviation for Non Volatile Memory layer. It is used to
+retrieve configuration or SOC or Device specific data from a non volatile 
memories
+like eeprom, efuses and so on.
+
+Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they
+all had to duplicate pretty much the same code to register a sysfs file, allow
+in-kernel users to access the content of the devices they were driving, etc.
+
+This was also a problem as far as other in-kernel users were involved, since
+the solutions used were pretty much different from on driver to another, there
+was a rather big abstraction leak.
+
+Introduction of this framework aims at solving this. It also introduces DT
+representation for consumer devices to go get the data they require (MAC
+Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs.
+This framework is based on regmap, so that most of the abstraction
+available in regmap can be reused, across multiple types of buses.
+
+NVMEM Providers

+
+NVMEM provider refers to an entity that implements methods to initialize, read
+and write the non-volatile memory.
+
+2. Registering/Unregistering the NVMEM provider
+===
+
+A NVMEM provider can register with NVMEM core by suppling relevant
+nvmem configuration to nvmem_register(), on success core would return a valid
+nvmem_device pointer.
+
+nvmem_unregister(nvmem) is used to unregister the already registered provider.
+
+For example for simple qfprom case:
+
+static struct nvmem_config econfig = {
+   .name = "qfprom",
+   .owner = THIS_MODULE,
+};
+
+static int qfprom_probe(struct platform_device *pdev)
+{
+   ...
+   econfig.dev = >dev;
+   nvmem = nvmem_register();
+   ...
+}
+
+It is mandatory that the NVMEM provider has a regmap associated with its
+struct device.
+
+NVMEM Consumers

+
+NVMEM consumers are the entities which make use of the NVMEM provider to
+read/write into NVMEM.
+
+3. NVMEM cell based consumer APIs.
+=
+
+NVMEM cells are the data entries/fields in the NVMEM.
+The NVMEM framework provides 3 APIs to read/write NVMEM cells.
+
+struct nvmem_cell *nvmem_cell_get(struct device *dev, const char *name);
+struct nvmem_cell *devm_nvmem_cell_get(struct device *dev, const char *name);
+
+void nvmem_cell_put(struct nvmem_cell *cell);
+void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell);
+
+void *nvmem_cell_read(struct nvmem_cell *cell, ssize_t *len);
+int nvmem_cell_write(struct nvmem_cell *cell, void *buf, ssize_t len);
+
+*nvmem_cell_get() apis will get a reference to nvmem cell for a given id,
+and nvmem_cell_read/write() can then directly read or write to the cell.
+Once the usage of the cell is finished the consumer should call 
*nvmem_cell_put()
+to free all the allocation memory for the cell.
+
+4. Direct NVMEM device based consumer APIs.
+==
+
+In some instances it is necessary to directly read/write the NVMEM.
+To facilitate such consumers NVMEM framework provides below apis.
+
+struct nvmem_device *nvmem_device_get(struct device *dev, const char *name);
+struct nvmem_device *devm_nvmem_device_get(struct device *dev,
+  const char *name);
+void nvmem_device_put(struct nvmem_device *nvmem);
+int nvmem_device_read(struct nvmem_device *nvmem, unsigned int offset,
+ size_t bytes, void *buf);
+int nvmem_device_write(struct nvmem_device *nvmem, unsigned int offset,
+  size_t bytes, void *buf);
+int nvmem_device_cell_read(struct nvmem_device *nvmem,
+  struct nvmem_cell_info *info, void *buf);
+int nvmem_device_cell_write(struct nvmem_device *nvmem,
+   struct nvmem_cell_info *info, void *buf);
+
+Before the consumers can read/write NVMEM directly, it should get hold
+of nvmem_controller from one of the *nvmem_device_get() api.
+
+Difference between these apis and cell based apis is that these apis
+always take nvmem_device as parameter.
+
+5. Releasing a reference to the NVMEM
+=
+
+When the consumers no longer needs the NVMEM, it has to release the reference
+to the NVMEM 

[PATCH v6 3/9] nvmem: Add nvmem_device based consumer apis.

2015-06-22 Thread Srinivas Kandagatla
This patch adds read/write apis which are based on nvmem_device. It is
common that the drivers like omap cape manager or qcom cpr driver to
access bytes directly at particular offset in the eeprom and not from
nvmem cell info in DT. These driver would need to get access to the nvmem
directly, which is what these new APIS provide.

These wrapper apis would help such users to avoid code duplication in
there drivers and also avoid them reading a big eeprom blob and parsing
it internally in there driver.

Signed-off-by: Srinivas Kandagatla 
---
 drivers/nvmem/core.c   | 256 +
 include/linux/nvmem-consumer.h |  79 +
 include/linux/nvmem-provider.h |  10 +-
 3 files changed, 337 insertions(+), 8 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 78cd5c8..82b564c 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -434,6 +434,147 @@ static void __nvmem_device_put(struct nvmem_device *nvmem)
mutex_unlock(_mutex);
 }
 
+static int nvmem_match(struct device *dev, const void *data)
+{
+   return !strcmp(dev_name(dev), data);
+}
+
+static struct nvmem_device *nvmem_find(const char *name)
+{
+   struct device *d;
+
+   d = class_find_device(_class, NULL, name, nvmem_match);
+
+   return d ? to_nvmem_device(d) : NULL;
+}
+
+/**
+ * of_nvmem_device_get() - Get nvmem device from a given id
+ *
+ * @dev node: Device tree node that uses the nvmem device
+ * @id: nvmem name from nvmem-names property.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_device.
+ */
+struct nvmem_device *of_nvmem_device_get(struct device_node *np, const char 
*id)
+{
+
+   struct device_node *nvmem_np;
+   int index;
+
+   index = of_property_match_string(np, "nvmem-names", id);
+
+   nvmem_np = of_parse_phandle(np, "nvmem", index);
+   if (!nvmem_np)
+   return ERR_PTR(-EINVAL);
+
+   return __nvmem_device_get(nvmem_np, NULL, NULL);
+
+}
+EXPORT_SYMBOL_GPL(of_nvmem_device_get);
+
+
+/**
+ * nvmem_device_get() - Get nvmem device from a given id
+ *
+ * @dev : Device that uses the nvmem device
+ * @id: nvmem name from nvmem-names property.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_device.
+ */
+struct nvmem_device *nvmem_device_get(struct device *dev, const char *dev_name)
+{
+   if (dev->of_node) { /* try dt first */
+   struct nvmem_device *nvmem;
+
+   nvmem = of_nvmem_device_get(dev->of_node, dev_name);
+
+   if (!IS_ERR(nvmem) || PTR_ERR(nvmem) == -EPROBE_DEFER)
+   return nvmem;
+
+   }
+
+   return nvmem_find(dev_name);
+
+}
+EXPORT_SYMBOL_GPL(nvmem_device_get);
+
+static int devm_nvmem_device_match(struct device *dev, void *res, void *data)
+{
+   struct nvmem_device **nvmem = res;
+   if (!nvmem || !*nvmem) {
+   WARN_ON(!nvmem || !*nvmem);
+   return 0;
+   }
+   return *nvmem == data;
+}
+
+static void devm_nvmem_device_release(struct device *dev, void *res)
+{
+   nvmem_device_put(*(struct nvmem_device **)res);
+}
+
+/**
+ * devm_nvmem_device_put() - put alredy got nvmem device
+ *
+ * @nvmem: pointer to nvmem device allocated by devm_nvmem_cell_get(),
+ * that needs to be released.
+ */
+void devm_nvmem_device_put(struct device *dev, struct nvmem_device *nvmem)
+{
+   int ret;
+
+   ret = devres_release(dev, devm_nvmem_device_release,
+devm_nvmem_device_match, nvmem);
+
+   WARN_ON(ret);
+
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_device_put);
+
+/**
+ * nvmem_device_put() - put alredy got nvmem device
+ *
+ * @nvmem: pointer to nvmem device that needs to be released.
+ */
+void nvmem_device_put(struct nvmem_device *nvmem)
+{
+   __nvmem_device_put(nvmem);
+}
+EXPORT_SYMBOL_GPL(nvmem_device_put);
+
+/**
+ * devm_nvmem_device_get() - Get nvmem cell of device form a given id
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem name in nvmems property.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell.  The nvmem_cell will be freed by the
+ * automatically once the device is freed.
+ */
+struct nvmem_device *devm_nvmem_device_get(struct device *dev, const char *id)
+{
+   struct nvmem_device **ptr, *nvmem;
+
+   ptr = devres_alloc(devm_nvmem_device_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return ERR_PTR(-ENOMEM);
+
+   nvmem = nvmem_device_get(dev, id);
+   if (!IS_ERR(nvmem)) {
+   *ptr = nvmem;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return nvmem;
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_device_get);
+
 static struct nvmem_cell *nvmem_cell_get_from_list(const char *cell_id)
 {
struct nvmem_cell *cell = NULL;
@@ -794,6 +935,121 @@ int 

[PATCH v6 2/9] nvmem: Add a simple NVMEM framework for consumers

2015-06-22 Thread Srinivas Kandagatla
This patch adds just consumers part of the framework just to enable easy
review.

Up until now, nvmem drivers were stored in drivers/misc, where they all
had to duplicate pretty much the same code to register a sysfs file,
allow in-kernel users to access the content of the devices they were
driving, etc.

This was also a problem as far as other in-kernel users were involved,
since the solutions used were pretty much different from on driver to
another, there was a rather big abstraction leak.

This introduction of this framework aims at solving this. It also
introduces DT representation for consumer devices to go get the data they
require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from
the nvmems.

Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.

Signed-off-by: Maxime Ripard 
[Maxime Ripard: intial version of the framework]
Signed-off-by: Srinivas Kandagatla 
---
 drivers/nvmem/core.c   | 415 +
 include/linux/nvmem-consumer.h |  75 
 2 files changed, 490 insertions(+)
 create mode 100644 include/linux/nvmem-consumer.h

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 17a826d..78cd5c8 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -379,6 +380,420 @@ int nvmem_unregister(struct nvmem_device *nvmem)
 }
 EXPORT_SYMBOL_GPL(nvmem_unregister);
 
+static struct nvmem_device *__nvmem_device_get(struct device_node *np,
+  struct nvmem_cell **cellp,
+  const char *cell_id)
+{
+   struct nvmem_device *nvmem = NULL;
+
+   mutex_lock(_mutex);
+
+   if (np) {
+   nvmem = of_nvmem_find(np);
+   if (!nvmem) {
+   mutex_unlock(_mutex);
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+   } else {
+   struct nvmem_cell *cell = nvmem_find_cell(cell_id);
+
+   if (cell) {
+   nvmem = cell->nvmem;
+   *cellp = cell;
+   }
+
+   if (!nvmem) {
+   mutex_unlock(_mutex);
+   return ERR_PTR(-ENOENT);
+   }
+   }
+
+   nvmem->users++;
+   mutex_unlock(_mutex);
+
+   if (!try_module_get(nvmem->owner)) {
+   dev_err(>dev,
+   "could not increase module refcount for cell %s\n",
+   nvmem->name);
+
+   mutex_lock(_mutex);
+   nvmem->users--;
+   mutex_unlock(_mutex);
+
+   return ERR_PTR(-EINVAL);
+   }
+
+   return nvmem;
+}
+
+static void __nvmem_device_put(struct nvmem_device *nvmem)
+{
+   module_put(nvmem->owner);
+   mutex_lock(_mutex);
+   nvmem->users--;
+   mutex_unlock(_mutex);
+}
+
+static struct nvmem_cell *nvmem_cell_get_from_list(const char *cell_id)
+{
+   struct nvmem_cell *cell = NULL;
+   struct nvmem_device *nvmem;
+
+   nvmem = __nvmem_device_get(NULL, , cell_id);
+   if (IS_ERR(nvmem))
+   return ERR_CAST(nvmem);
+
+
+   return cell;
+
+}
+/**
+ * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem cell name from nvmem-cell-names property.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell.  The nvmem_cell will be freed by the
+ * nvmem_cell_put().
+ */
+struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
+   const char *name)
+{
+   struct device_node *cell_np, *nvmem_np;
+   struct nvmem_cell *cell;
+   struct nvmem_device *nvmem;
+   const __be32 *addr;
+   int rval, len, index;
+
+   index = of_property_match_string(np, "nvmem-cell-names", name);
+
+   cell_np = of_parse_phandle(np, "nvmem-cell", index);
+   if (!cell_np)
+   return ERR_PTR(-EINVAL);
+
+   nvmem_np = of_get_next_parent(cell_np);
+   if (!nvmem_np)
+   return ERR_PTR(-EINVAL);
+
+   nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
+   if (IS_ERR(nvmem))
+   return ERR_CAST(nvmem);
+
+   addr = of_get_property(cell_np, "reg", );
+   if (!addr || (len < 2 * sizeof(int))) {
+   dev_err(>dev, "nvmem: invalid reg on %s\n",
+   cell_np->full_name);
+   rval  = -EINVAL;
+   goto err_mem;
+   }
+
+   cell = kzalloc(sizeof(*cell), GFP_KERNEL);
+   if (!cell) {
+   rval = -ENOMEM;
+   goto err_mem;
+   }
+
+   cell->nvmem = nvmem;
+   cell->offset = be32_to_cpup(addr++);
+   cell->bytes = be32_to_cpup(addr);
+   cell->name = cell_np->name;
+
+  

[PATCH v6 4/9] nvmem: Add bindings for simple nvmem framework

2015-06-22 Thread Srinivas Kandagatla
This patch adds bindings for simple nvmem framework which allows nvmem
consumers to talk to nvmem providers to get access to nvmem cell data.

Signed-off-by: Maxime Ripard 
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla 
---
 Documentation/devicetree/bindings/nvmem/nvmem.txt | 85 +++
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/nvmem.txt

diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt 
b/Documentation/devicetree/bindings/nvmem/nvmem.txt
new file mode 100644
index 000..d1a37e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt
@@ -0,0 +1,85 @@
+= NVMEM(Non Volatile Memory) Data Device Tree Bindings =
+
+This binding is intended to represent the location of hardware
+configuration data stored in NVMEMs like eeprom, efuses and so on.
+
+On a significant proportion of boards, the manufacturer has stored
+some data on NVMEM, for the OS to be able to retrieve these information
+and act upon it. Obviously, the OS has to know about where to retrieve
+these data from, and where they are stored on the storage device.
+
+This document is here to document this.
+
+= Data providers =
+Contains bindings specific to provider drivers and data cells as children
+of this node.
+
+Optional properties:
+ read-only: Mark the provider as read only.
+
+= Data cells =
+These are the child nodes of the provider which contain data cell
+information like offset and size in nvmem provider.
+
+Required properties:
+reg:   specifies the offset in byte within that storage device, start bit
+   in the byte and the length in bits of the data we care about.
+   There could be more than one offset-length pairs in this property.
+
+Optional properties:
+
+bit-offset: specifies the offset in bit within the address range specified
+   by reg property. Can take values from 0-7.
+nbits: specifies number of bits this cell occupies starting from bit-offset.
+
+For example:
+
+   /* Provider */
+   qfprom: qfprom@0070 {
+   ...
+
+   /* Data cells */
+   tsens_calibration: calib@404 {
+   reg = <0x404 0x10>;
+   };
+
+   tsens_calibration_bckp: calib_bckp@504 {
+   reg = <0x504 0x11>;
+   bit-offset = 6;
+   nbits = 128;
+   };
+
+   pvs_version: pvs-version@6 {
+   reg = <0x6 0x2>
+   bit-offset = 7;
+   nbits = 2;
+   };
+
+   speed_bin: speed-bin@c{
+   reg = <0xc 0x1>;
+   bit-offset = 2;
+   nbits   = 3;
+
+   };
+   ...
+   };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells/providers.
+
+Required-properties:
+nvmem-cell: list of phandle to the nvmem data cells.
+nvmem-cell-names: names for the each nvmem-cell specified. Required if
+   nvmem-cell is used.
+
+Optional-properties:
+nvmem  : list of phandles to nvmem providers.
+nvmem-names: names for the each nvmem provider. required if nvmem is used.
+
+For example:
+
+   tsens {
+   ...
+   nvmem-cell = <_calibration>;
+   nvmem-cell-names = "calibration";
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v6 6/9] nvmem: qfprom: Add Qualcomm QFPROM support.

2015-06-22 Thread Srinivas Kandagatla
This patch adds QFPROM support driver which is used by other drivers
like thermal sensor and cpufreq.

On MSM parts there are some efuses (called qfprom) these fuses store
things like calibration data, speed bins.. etc. Drivers like cpufreq,
thermal sensors would read out this data for configuring the driver.

Signed-off-by: Srinivas Kandagatla 
---
 drivers/nvmem/Kconfig  | 15 +
 drivers/nvmem/Makefile |  4 +++
 drivers/nvmem/qfprom.c | 89 ++
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/nvmem/qfprom.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index f157b6d..7fff0e2 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -8,3 +8,18 @@ menuconfig NVMEM
  from both the Linux Kernel and the userspace.
 
  If unsure, say no.
+
+if NVMEM
+
+config QCOM_QFPROM
+   tristate "QCOM QFPROM Support"
+   depends on ARCH_QCOM || COMPILE_TEST
+   select REGMAP_MMIO
+   help
+ Say y here to enable QFPROM support. The QFPROM provides access
+ functions for QFPROM data to rest of the drivers via nvmem interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-qfprom.
+
+endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 6df2c69..ff44fe9 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -4,3 +4,7 @@
 
 obj-$(CONFIG_NVMEM)+= nvmem_core.o
 nvmem_core-y   := core.o
+
+# Devices
+obj-$(CONFIG_QCOM_QFPROM)  += nvmem_qfprom.o
+nvmem_qfprom-y := qfprom.o
diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
new file mode 100644
index 000..7f7a82f
--- /dev/null
+++ b/drivers/nvmem/qfprom.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright (C) 2015 Srinivas Kandagatla 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 
+
+static struct regmap_config qfprom_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 8,
+   .reg_stride = 1,
+};
+
+static struct nvmem_config econfig = {
+   .name = "qfprom",
+   .owner = THIS_MODULE,
+};
+
+static int qfprom_remove(struct platform_device *pdev)
+{
+   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+   return nvmem_unregister(nvmem);
+}
+
+static int qfprom_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct resource *res;
+   struct nvmem_device *nvmem;
+   struct regmap *regmap;
+   void __iomem *base;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   qfprom_regmap_config.max_register = resource_size(res) - 1;
+
+   regmap = devm_regmap_init_mmio(dev, base, _regmap_config);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, "regmap init failed\n");
+   return PTR_ERR(regmap);
+   }
+   econfig.dev = dev;
+   nvmem = nvmem_register();
+   if (IS_ERR(nvmem))
+   return PTR_ERR(nvmem);
+
+   platform_set_drvdata(pdev, nvmem);
+
+   return 0;
+}
+
+static const struct of_device_id qfprom_of_match[] = {
+   { .compatible = "qcom,qfprom",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, qfprom_of_match);
+
+static struct platform_driver qfprom_driver = {
+   .probe = qfprom_probe,
+   .remove = qfprom_remove,
+   .driver = {
+   .name = "qcom,qfprom",
+   .of_match_table = qfprom_of_match,
+   },
+};
+module_platform_driver(qfprom_driver);
+MODULE_AUTHOR("Srinivas Kandagatla ");
+MODULE_DESCRIPTION("Qualcomm QFPROM driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v6 0/9] Add simple NVMEM Framework via regmap.

2015-06-22 Thread Srinivas Kandagatla
Thankyou all for providing inputs and comments on previous versions of this
patchset. Here is the v6 of the patchset addressing all the issues raised as
part of previous versions review.

This patchset adds a new simple NVMEM framework to kernel, and it is tested
with various drivers like "QCOM thermal sensors", "QCOM cpr driver",
"begal bone cape manager" and few more on the way.

Greg KH,
 Is it possible to take these patches via your tree Or do you think it
 should go via ARM-SOC tree?

Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they
all had to duplicate pretty much the same code to register a sysfs file, allow
in-kernel users to access the content of the devices they were driving, etc.

This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.

Introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs.

After learning few things about QCOM qfprom and other eeprom/efuses, which
has packed fields at bit level. Which makes it important to add support to
such memories. This version adds support to this type of non volatile
memories by adding support to bit level nvmem-cells.

Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.

patch 1-4 Introduces the NVMEM framework.
Patch 5-6 Adds Qualcomm specific qfprom driver.
Patch 7 migrates an existing driver to nvmem framework.
Patch 8 adds entry in MAINTAINERS.

Its also possible to migrate other nvmem drivers to this framework.

Providers APIs:
nvmem_register/unregister();

Consumers APIs:
Cell based apis for both DT/Non-DT:
nvmem_cell_get()/nvmem_cell_put();
devm_nvmem_cell_get()/devm_nvmem_cell_put();
of_nvmem_cell_get()
nvmem_cell_read()/nvmem_cell_write();

Raw byte access apis for both DT/non-DT.
nvmem_device_get()/nvmem_device_put()
devm_nvmem_device_get()/nvmem_device_put()
of_nvmem_device_get()

nvmem_device_read()/nvmem_device_write();
nvmem_device_cell_read()/nvmem_device_cell_write();

Device Tree:

/* Provider */
qfprom: qfprom@0070 {
...

/* Data cells */
tsens_calibration: calib@404 {
reg = <0x404 0x10>;
};

tsens_calibration_bckp: calib_bckp@504 {
reg = <0x504 0x11>;
bit-offset = 6;
nbits = 128;
};

pvs_version: pvs-version@6 {
reg = <0x6 0x2>
bit-offset = 7;
nbits = 2;
};

speed_bin: speed-bin@c{
reg = <0xc 0x1>;
bit-offset = 2;
nbits   = 3;

};
...
};

userspace interface: binary file in /sys/class/nvmem/*/nvmem

ex:
hexdump /sys/class/nvmem/qfprom0/nvmem


  
000        
*
0a0 db10 2240  e000 0c00 0c00  0c00
000        
...
*
0001000

Changes since v5(https://lkml.org/lkml/2015/5/21/643)
 * skipped regmap patches which are already merged by Mark.
 * Fixed lot of style related comments by Stephen.
 * Fixed sunxi driver.
 * added devm_* variants requested by Stephen.
 * added of_* variants requested by Pantelis Antoniou
 * added read_only options for non-dt drivers.
 * added basic how-to doc.

Changes since v4(https://lkml.org/lkml/2015/3/30/725)
 * rename eeprom to nvmem suggested by Matt Porter
 * added bit level support to nvmem cells, if not framework is
not usable for qcom platforms.
 * removed ternary operator shortcut suggested by Mark B.
 * unified consumer/provider apis for both DT and non-DT.
 * added name support for cell.
 * added bit level bindings.
 * added read-only support suggested by Matt Porter and others.
 * added new nvmem_device based consumer apis.

Changes since v3(https://lkml.org/lkml/2015/3/24/1066)
 * simplified logic in bin_attr_eeprom_read/write spotted by Mark Brown.
 * moved from using regmap_bulk_read/write to regmap_raw_read/write
 spotted by Mark Brown
 * Fixed return error codes for the dummy wrappers spotted by Sascha Hauer
 * Fixed various error code checks in core spotted by Sascha Hauer.
 * Simplified consumer bindings suggested by Sascha Hauer.
 * Added eeprom-mmio helper functions.

Changes since 

[PATCH v6 1/9] nvmem: Add a simple NVMEM framework for nvmem providers

2015-06-22 Thread Srinivas Kandagatla
This patch adds just providers part of the framework just to enable easy
review.

Up until now, NVMEM drivers like eeprom were stored in drivers/misc,
where they all had to duplicate pretty much the same code to register
a sysfs file, allow in-kernel users to access the content of the devices
they were driving, etc.

This was also a problem as far as other in-kernel users were involved,
since the solutions used were pretty much different from on driver to
another, there was a rather big abstraction leak.

This introduction of this framework aims at solving this. It also
introduces DT representation for consumer devices to go get the data
they require (MAC Addresses, SoC/Revision ID, part numbers, and so on)
from the nvmems.

Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.

Signed-off-by: Maxime Ripard 
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla 
---
 drivers/Kconfig|   2 +
 drivers/Makefile   |   1 +
 drivers/nvmem/Kconfig  |  10 ++
 drivers/nvmem/Makefile |   6 +
 drivers/nvmem/core.c   | 398 +
 include/linux/nvmem-provider.h |  54 ++
 6 files changed, 471 insertions(+)
 create mode 100644 drivers/nvmem/Kconfig
 create mode 100644 drivers/nvmem/Makefile
 create mode 100644 drivers/nvmem/core.c
 create mode 100644 include/linux/nvmem-provider.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index c0cc96b..69d7305 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -182,4 +182,6 @@ source "drivers/thunderbolt/Kconfig"
 
 source "drivers/android/Kconfig"
 
+source "drivers/nvmem/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 46d2554..f86b897 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS)   += ras/
 obj-$(CONFIG_THUNDERBOLT)  += thunderbolt/
 obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/
 obj-$(CONFIG_ANDROID)  += android/
+obj-$(CONFIG_NVMEM)+= nvmem/
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
new file mode 100644
index 000..f157b6d
--- /dev/null
+++ b/drivers/nvmem/Kconfig
@@ -0,0 +1,10 @@
+menuconfig NVMEM
+   tristate "NVMEM Support"
+   select REGMAP
+   help
+ Support for NVMEM devices.
+
+ This framework is designed to provide a generic interface to NVMEM
+ from both the Linux Kernel and the userspace.
+
+ If unsure, say no.
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
new file mode 100644
index 000..6df2c69
--- /dev/null
+++ b/drivers/nvmem/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for nvmem drivers.
+#
+
+obj-$(CONFIG_NVMEM)+= nvmem_core.o
+nvmem_core-y   := core.o
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
new file mode 100644
index 000..17a826d
--- /dev/null
+++ b/drivers/nvmem/core.c
@@ -0,0 +1,398 @@
+/*
+ * nvmem framework core.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla 
+ * Copyright (C) 2013 Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 
+
+struct nvmem_device {
+   const char  *name;
+   struct regmap   *regmap;
+   struct module   *owner;
+   struct device   dev;
+   int stride;
+   int word_size;
+   int ncells;
+   int id;
+   int users;
+   size_t  size;
+   boolread_only;
+};
+
+struct nvmem_cell {
+   const char *name;
+   int offset;
+   int bytes;
+   int bit_offset;
+   int nbits;
+   struct nvmem_device *nvmem;
+   struct list_headnode;
+};
+
+static DEFINE_MUTEX(nvmem_mutex);
+static DEFINE_IDA(nvmem_ida);
+
+static LIST_HEAD(nvmem_cells);
+static DEFINE_MUTEX(nvmem_cells_mutex);
+
+#define to_nvmem_device(d) container_of(d, struct nvmem_device, dev)
+
+static ssize_t bin_attr_nvmem_read(struct file *filp, struct kobject *kobj,
+   struct bin_attribute *attr,
+   char *buf, loff_t pos, size_t count)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct nvmem_device 

Re: [PATCHv4 00/27] perf stat: Introduce --per-thread option

2015-06-22 Thread Arnaldo Carvalho de Melo
Em Tue, Jun 23, 2015 at 12:36:01AM +0200, Jiri Olsa escreveu:
> hi,
> adding the possibility to display stat data per thread.
> 
> Allowing following commands and output:
> 
>   $ perf stat  -e cycles,instructions --per-thread -p 30190,30242

While testing Adrian's Intel PT patchkit I realised we have --per-thread
in 'record', wonder if using a long option with the exact same name but
different meanings for 'stat' and 'record'  would cause confusion...

- Arnaldo

>   ^C
>Performance counter stats for process id '30190,30242':
> 
>cat-30190 0  cycles
>yes-30242 3,842,525,421  cycles
>cat-30190 0  instructions
>yes-3024210,370,817,010  instructions
> 
>  1.143155657 seconds time elapsed
> 
> 
> Also works under interval mode:
> 
>   $ perf stat  -e cycles,instructions --per-thread -p 30190,30242 -I 1000
>   #   time comm-pid  counts unit events
>1.73435  cat-3019089,058  cycles
>1.73435  yes-30242 3,360,786,902  cycles   
>   (100.00%)
>1.73435  cat-3019014,066  
> instructions
>1.73435  yes-30242 9,069,937,462  
> instructions
>2.000204830  cat-30190 0  cycles
>2.000204830  yes-30242 3,351,667,626  cycles
>2.000204830  cat-30190 0  
> instructions
>2.000204830  yes-30242 9,045,796,885  
> instructions
>   ^C 2.771286639  cat-30190 0  cycles
>2.771286639  yes-30242 2,593,884,166  cycles
>2.771286639  cat-30190 0  
> instructions
>2.771286639  yes-30242 7,001,171,191  
> instructions
> 
> 
> Available in here:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/per_thread
> 
> v4 changes:
>   - add thread_map__set_(pid|comm) interface
>   - several fixes for task comm string reading
>   - added perf_evlist__reset_stats function
> 
> v3 changes:
>   - some patches already pulled in, rebased on latest acme's perf/core
>   - fixed cpu_map__get/thread_map__get to accept NULL map
>   - renamed propagate_maps to perf_evlist__propagate_maps
>   - renamed --per-task option to --per-thread
>   - changed 'task-pid' header output to 'comm-pid'
> 
> v2 changes:
>   - renamed xyarray__zero to xyarray__reset
>   - using atomic_t for cpu_map/thread_map refcnt
>   - moving all stat functions into stat object
>   - using init_stats to initialize 'struct stats*'
>   - change TASK-$pid output into $comm-$pid
>   - updated doc with --per-task option
> 
> 
> thanks,
> jirka
> ---
> Jiri Olsa (27):
>   perf tools: Change thread_map::map into struct
>   perf tools: Add comm string into struct thread_map
>   perf tools: Add reference counting for cpu_map object
>   perf tools: Add reference counting for thread_map object
>   perf tools: Propagate cpu maps through the evlist
>   perf tools: Propagate thread maps through the evlist
>   perf tools: Make perf_evsel__(nr_)cpus generic
>   perf tests: Add thread_map object tests
>   perf stat: Introduce perf_counts function
>   perf stat: Use xyarray for cpu evsel counts
>   perf stat: Make stats work over the thread dimension
>   perf stat: Rename struct perf_counts::cpu member to values
>   perf stat: Introduce perf_evlist__reset_stats
>   perf stat: Move perf_evsel__(alloc|free|reset)_stat_priv into stat 
> object
>   perf stat: Move perf_evsel__(alloc|free)_prev_raw_counts into stat 
> object
>   perf stat: Move perf_evlist__(alloc|free|reset)_stats into stat object
>   perf stat: Introduce perf_evsel__alloc_stats function
>   perf stat: Introduce perf_evsel__read function
>   perf stat: Introduce read_counters function
>   perf stat: Separate counters reading and processing
>   perf stat: Move zero_per_pkg into counter process code
>   perf stat: Move perf_stat initialization counter process code
>   perf stat: Remove perf_evsel__read_cb function
>   perf stat: Rename print_interval to process_interval
>   perf stat: Using init_stats instead of memset
>   perf stat: Introduce print_counters function
>   perf stat: Introduce --per-thread option
> 
>  tools/perf/Documentation/perf-stat.txt  |   4 +
>  tools/perf/builtin-stat.c   | 404 
> ++--
>  tools/perf/builtin-trace.c  |   4 +-
>  tools/perf/tests/Build  |   1 +
>  tools/perf/tests/builtin-test.c |   4 +
>  tools/perf/tests/code-reading.c |   4 +-
>  

  1   2   3   4   5   6   7   8   9   10   >