Re: [PATCH 10/10] Kconfig: cleanup SERIO_I8042 dependencies

[Mark Salter]

On Sun, 2013-12-15 at 02:36 -0800, Dmitry Torokhov wrote:
> On Sat, Dec 14, 2013 at 10:32:31AM -0800, H. Peter Anvin wrote:
> > On 12/14/2013 08:59 AM, Mark Salter wrote:
> > > Remove messy dependencies from SERIO_I8042 by having it depend on one
> > > Kconfig symbol (ARCH_MIGHT_HAVE_PC_SERIO) and having architectures
> > > which need it select ARCH_MIGHT_HAVE_PC_SERIO in arch/*/Kconfig.
> > > New architectures are unlikely to need SERIO_I8042, so this avoids
> > > having an ever growing list of architectures to exclude.

> How are we going to merge this? In bulk through input tree or peacemeal
> through all arches first?
> 

They should all go together to eliminate the chance of bisect breakage.
Either the input tree or maybe akpm tree.


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

Re: [PATCH RT 2/5] a few open coded completions

[Sebastian Andrzej Siewior]

* Steven Rostedt | 2013-12-11 10:34:20 [-0500]:

>As this chunck doesn't need to be in the stable branch, I'm just going
>to nuke it.
>
>I'll even fix up the change log too.

Thank you for the fixups. I just did the same thing in the v3.12 tree.
The chunk you nuked is now in Dave's net tree as a0a9663dd214 ("net: make
neigh_priv_len in struct net_device 16bit instead of 8bit"). As it
describes it is buggy on -RT but not mainline therefore it has no stable
tag for mainline and I would add one for RT.

>
>Thanks,
>
>-- Steve

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

Re: [PATCH 2/3] read_lock migrate_disable pushdown to rt_read_lock

[Sebastian Andrzej Siewior]

* Steven Rostedt | 2013-12-06 10:25:32 [-0500]:

>
>Let me analyze the original code first. I'll poke peterz and tglx too
>to make sure this modification is OK.

I took 1/3. I postpone the remaining two until I hear something from
you.

>Thanks,
>
>-- Steve

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

Re: [REGRESSION] rfcomm (userland) broken by commit 29cd718b

[Gianluca Anzolin]

On Sun, Dec 15, 2013 at 09:03:35AM -0500, Peter Hurley wrote:
> On 12/15/2013 06:24 AM, Gianluca Anzolin wrote:
> >On Fri, Dec 13, 2013 at 12:35:26AM +0100, Alexander Holler wrote:
> >>Am 12.12.2013 21:36, schrieb Peter Hurley:
> >>
> What currently happens is that when one kills rfcomm (and any other
> terminal which might use that tty), the entry in /dev doesn't
> disappear. That means the same call to refcomm with the same device
> (e.g. [/dev/]rfcomm1 doesn't work.
> >>>
> >>>Thanks for the report, Alexander.
> >>>
> >>>Point 4 above details a different situation; something else is
> >>>happening.
> >>>
> >>>Would you please detail the necessary steps to reproduce this regression?
> >>>(How do you 'kill' rfcomm? etc.  Shell command lines would be best.)
> >>
> >>Just call
> >>
> >>rfcomm connect rfcomm9 01:23:45:67:89:ab
> >>
> >>wait until the connection happened  (a message will appear) and then
> >>press ctrl-c. This still terminates the bluetooth connection, but the
> >>device in /dev is now left.
> >
> >Yes I'm able to reproduce the regression which is indeed caused by that
> >commit.
> >
> >However I'm puzzled. Surely there is a fifth case I didn't cover because
> >when rfcomm_dev_state_change() is called, the tty_port is there but the tty 
> >is
> >not, and therefore I cannot get a reference to it and send the HUP.
> 
> There is a fifth case, but it's crazy.
> 
> The tty has been properly shutdown and destroyed because the tty file handle
> was closed, not hungup. The rfcomm device reference was properly put
> when the tty was released.
> 
> But when the remote hangs up (and sends disc), then rfcomm_dev_state_change()
> is called -- to kill the port reference (thus the rfcomm device) that was
> instantiated locally! Ridiculous. Doubly ridiculous because it's the local
> port shutdown that closes the dlc locally that sends the disconnect (and sets
> the local dlc state) that triggers the received rfcomm_dev_state_change()!
> 
> If this behavior is desirable (or necessary because it's been exposed to
> userspace), then why was the design ever reference-counted to begin with?
> 
> Regards,
> Peter Hurley

The attached patch fixes the regression by releasing the tty_port in the
shutdown method(). This way we can avoid strange games in the dlc callback
where we are constrained by the dlc lock.

If this kind of approach is acceptable I will submit the patch for inclusion in
a separate email.

Thanks,
Gianluca
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 84fcf9f..917b441 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -129,6 +129,11 @@ static void rfcomm_dev_shutdown(struct tty_port *port)
 
 	/* close the dlc */
 	rfcomm_dlc_close(dev->dlc, 0);
+
+	/* release the port if it was created with the flag RELEASE_ONHUP */
+	if (test_bit(RFCOMM_RELEASE_ONHUP, >flags) &&
+	!test_and_set_bit(RFCOMM_TTY_RELEASED, >flags))
+		tty_port_put(>port);
 }
 
 static const struct tty_port_operations rfcomm_port_ops = {

[RFC PATCH v3] powerpc: Loading kernels over 8Mbytes without CONFIG_PIN_TLB

[Christophe Leroy]

Hereunder is a try to implement the sizing of the initial memory size based on
initial-mapped-area size given by uboot in r7.
As this has an impact on all powerpc platforms due to the need to provide the
info up to function setup_initial_memory_limit(), I'm not completly sure of the
proper implementation.
Thanks to provide comments.

Today on the 8xx, the only way to load kernels whose size is greater than
8Mbytes is to activate CONFIG_PIN_TLB. Otherwise, the physical memory initially
mapped is limited to 8Mbytes. This patch uses the size of initial memory mapped
by the bootloader and given to the kernel through register r7.
This is done regardless of whether CONFIG_PIN_TLB is active or not. It allows to
load "big" kernels (for instance when activating CONFIG_LOCKDEP_SUPPORT) without
having to activate CONFIG_PIN_TLB.

Not-yet-signed-off-by: Christophe Leroy 

Index: linux/arch/powerpc/include/asm/mmu.h
===
--- linux/arch/powerpc/include/asm/mmu.h(revision 5484)
+++ linux/arch/powerpc/include/asm/mmu.h(copie de travail)
@@ -138,7 +138,8 @@
 extern void early_init_mmu_secondary(void);
 
 extern void setup_initial_memory_limit(phys_addr_t first_memblock_base,
-  phys_addr_t first_memblock_size);
+  phys_addr_t first_memblock_size,
+  u64 init_mem_size);
 
 #ifdef CONFIG_PPC64
 /* This is our real memory area size on ppc64 server, on embedded, we
Index: linux/arch/powerpc/kernel/head_8xx.S
===
--- linux/arch/powerpc/kernel/head_8xx.S(revision 5484)
+++ linux/arch/powerpc/kernel/head_8xx.S(copie de travail)
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#define EPAPR_MAGIC0x65504150
+
 /* Macro to make the code more readable. */
 #ifdef CONFIG_8xx_CPU6
 #define DO_8xx_CPU6(val, reg)  \
@@ -77,10 +79,19 @@
.globl  __start
 __start:
mr  r31,r3  /* save device tree ptr */
+   li  r30,0
 
+   lis r8,EPAPR_MAGIC@h
+   ori r8,r8, EPAPR_MAGIC@l
+   cmpwcr0,r8, r6
+   bne 1f
+
+   mr  r30,r7  /* save initial ram size */
+
/* We have to turn on the MMU right away so we get cache modes
 * set correctly.
 */
+1:
bl  initial_mmu
 
 /* We now have the lower 8 Meg mapped into TLB entries, and the caches
@@ -717,6 +728,8 @@
  */
li  r3,0
mr  r4,r31
+   li  r5,0
+   mr  r6,r30
bl  machine_init
bl  MMU_init
 
@@ -841,11 +854,17 @@
ori r8, r8, MI_BOOTINIT|0x2 /* Inhibit cache -- Cort */
mtspr   SPRN_MD_RPN, r8
 
+   /* Map two more 8M kernel data pages if needed
+* We check how much memory is mapped by the bootloader
+   */
+   lis r8, 0x0100
+   cmplw   cr0, r8, r30
+   blt 2f
+
 #ifdef CONFIG_PIN_TLB
-   /* Map two more 8M kernel data pages.
-   */
addir10, r10, 0x0100
mtspr   SPRN_MD_CTR, r10
+#endif
 
lis r8, KERNELBASE@h/* Create vaddr for TLB */
addis   r8, r8, 0x0080  /* Add 8M */
@@ -858,20 +877,26 @@
addis   r11, r11, 0x0080/* Add 8M */
mtspr   SPRN_MD_RPN, r11
 
+   lis r8, 0x0180
+   cmplw   cr0, r8, r30
+   blt 2f
+
+#ifdef CONFIG_PIN_TLB
addir10, r10, 0x0100
mtspr   SPRN_MD_CTR, r10
+#endif
 
addis   r8, r8, 0x0080  /* Add 8M */
mtspr   SPRN_MD_EPN, r8
mtspr   SPRN_MD_TWC, r9
addis   r11, r11, 0x0080/* Add 8M */
mtspr   SPRN_MD_RPN, r11
-#endif
 
/* Since the cache is enabled according to the information we
 * just loaded into the TLB, invalidate and enable the caches here.
 * We should probably check/set other modeslater.
 */
+2:
lis r8, IDC_INVALL@h
mtspr   SPRN_IC_CST, r8
mtspr   SPRN_DC_CST, r8
Index: linux/arch/powerpc/kernel/prom.c
===
--- linux/arch/powerpc/kernel/prom.c(revision 5484)
+++ linux/arch/powerpc/kernel/prom.c(copie de travail)
@@ -649,7 +649,7 @@
}
 }
 
-void __init early_init_devtree(void *params)
+void __init early_init_devtree(void *params, u64 init_mem_size)
 {
phys_addr_t limit;
 
@@ -697,7 +697,7 @@
/* make sure we've parsed cmdline for mem= before this */
if (memory_limit)
first_memblock_size = min_t(u64, first_memblock_size, 
memory_limit);
-   setup_initial_memory_limit(memstart_addr, first_memblock_size);
+   setup_initial_memory_limit(memstart_addr, first_memblock_size, 
init_mem_size);
/* Reserve MEMBLOCK regions used by kernel, initrd, dt, etc... */
memblock_reserve(PHYSICAL_START, 

Re: [PATCH] include/uapi/linux/netlink.h -Wall -Wextra -Werror support fix

[Levente Kurusa]

On 12/15/2013 03:40 PM, Doron Tsur wrote:
> For code using:
> #include 
> NLMSG_OK
> -I/include
> 
> Tested-by: Doron Tsur 
This should go where your Signed-off-by line is.

[insert newlines here]
> Test log:
> Compilation environments:
> Ubuntu 13.10, x86_64, gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
> Ubuntu 13.04, x86_64, gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
> [ -ftrack-macro-expansion=2 issue submitted:
>   gcc.gnu.org/bugzilla/show_bug.cgi?id=59495 ]


[insert newlines here]
> Kernel headers installed at:
> make -C .../linux-stable headers_install \
> INSTALL_HDR_PATH=/builds/kernel_tests_user_headers/


[insert newlines here]
> Pre-patch compilation:
> gcc -Wall -Wextra -Werror
> -I/builds/kernel_tests_pre_patch_user_headers/include
> include-uapi-linux-netlink.h.test.c
> In file included from include-uapi-linux-netlink.h.test.c:2:0:
> include-uapi-linux-netlink.h.test.c: In function ‘main’:
> /builds/kernel_tests_pre_patch_user_headers/include/linux/netlink.h:89:24:
> error: comparison between signed and unsigned integer expressions
> [-Werror=sign-compare]
>(nlh)->nlmsg_len <= (len))
> ^
> include-uapi-linux-netlink.h.test.c:26:5: note: in expansion of macro 
> ‘NLMSG_OK’
>  NLMSG_OK(_netlink_header, active_len));
>  ^
> cc1: all warnings being treated as errors


[insert newlines here]
> Post-patch:
> $ gcc  -Wall -Wextra -Werror
> -I/builds/kernel_tests_user_headers/include/
> include-uapi-linux-netlink.h.test.c


[insert newlines here]
> $ ./a.out
> nlmsg_len= 1, len = 1 NLMSG_OK(nlh,len) test result: 0
> nlmsg_len= 1, len = 3000 NLMSG_OK(nlh,len) test result: 0
> nlmsg_len= 3000, len = 1 NLMSG_OK(nlh,len) test result: 0
> nlmsg_len= 3000, len = 3000 NLMSG_OK(nlh,len) test result: 1
> 
> Signed-off-by: Doron Tsur 

Please make your commit message understandable by adding newlines and such.
Also it doesn't say what did you change and why. All it says, that there
was a warning and post-patch there is no warning.

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

Re: [PATCH 1/3] make migrate disable/enable conditioned on softirq_nestcnt transition

[Sebastian Andrzej Siewior]

* Steven Rostedt | 2013-12-05 19:45:30 [-0500]:

>On Fri, 6 Dec 2013 00:42:22 +0100
>Nicholas Mc Guire  wrote:
>> --- a/kernel/softirq.c
>> +++ b/kernel/softirq.c
>> @@ -569,8 +569,8 @@ static void do_current_softirqs(int need_rcu_bh_qs)
>>  
>>  void local_bh_disable(void)
>>  {
>> -migrate_disable();
>> -current->softirq_nestcnt++;
>> +if (++current->softirq_nestcnt == 1)
>> +migrate_disable();
>>  }
>>  EXPORT_SYMBOL(local_bh_disable);
>>  
>> @@ -584,8 +584,8 @@ void local_bh_enable(void)
>>  do_current_softirqs(1);
>>  local_irq_enable();
>>  
>> -current->softirq_nestcnt--;
>> -migrate_enable();
>> +if (--current->softirq_nestcnt == 0)
>> +migrate_enable();
>
>I wonder if we should add a:
>
>   BUG_ON(current->softirq_nestcnt < 0);

We have a WARN_ON() in each enable path. That one in local_bh_enable()
isn't part of the context here. If you want to s/WARN_/BUG_/ then I
would prefer not to since there are a few people with no UART and this
could break the system while the current sollution keeps the system
running.

>As for the patch, I haven't found anything wrong with it.
>
>Reviewed-by: Steven Rostedt 
Thanks.

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

[PATCH] include/uapi/linux/netlink.h -Wall -Wextra -Werror support fix

[Doron Tsur]

For code using:
#include 
NLMSG_OK
-I/include

Tested-by: Doron Tsur 
Test log:
Compilation environments:
Ubuntu 13.10, x86_64, gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Ubuntu 13.04, x86_64, gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
[ -ftrack-macro-expansion=2 issue submitted:
  gcc.gnu.org/bugzilla/show_bug.cgi?id=59495 ]
Kernel headers installed at:
make -C .../linux-stable headers_install \
INSTALL_HDR_PATH=/builds/kernel_tests_user_headers/
Pre-patch compilation:
gcc -Wall -Wextra -Werror
-I/builds/kernel_tests_pre_patch_user_headers/include
include-uapi-linux-netlink.h.test.c
In file included from include-uapi-linux-netlink.h.test.c:2:0:
include-uapi-linux-netlink.h.test.c: In function ‘main’:
/builds/kernel_tests_pre_patch_user_headers/include/linux/netlink.h:89:24:
error: comparison between signed and unsigned integer expressions
[-Werror=sign-compare]
   (nlh)->nlmsg_len <= (len))
^
include-uapi-linux-netlink.h.test.c:26:5: note: in expansion of macro ‘NLMSG_OK’
 NLMSG_OK(_netlink_header, active_len));
 ^
cc1: all warnings being treated as errors
Post-patch:
$ gcc  -Wall -Wextra -Werror
-I/builds/kernel_tests_user_headers/include/
include-uapi-linux-netlink.h.test.c
$ ./a.out
nlmsg_len= 1, len = 1 NLMSG_OK(nlh,len) test result: 0
nlmsg_len= 1, len = 3000 NLMSG_OK(nlh,len) test result: 0
nlmsg_len= 3000, len = 1 NLMSG_OK(nlh,len) test result: 0
nlmsg_len= 3000, len = 3000 NLMSG_OK(nlh,len) test result: 1

Signed-off-by: Doron Tsur 
---
 include/uapi/linux/netlink.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index 1a85940..1884d4e 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -86,7 +86,7 @@ struct nlmsghdr {
  (struct nlmsghdr*)(((char*)(nlh)) + 
NLMSG_ALIGN((nlh)->nlmsg_len)))
 #define NLMSG_OK(nlh,len) ((len) >= (int)sizeof(struct nlmsghdr) && \
   (nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \
-  (nlh)->nlmsg_len <= (len))
+  (int)(nlh)->nlmsg_len <= (len))
 #define NLMSG_PAYLOAD(nlh,len) ((nlh)->nlmsg_len - NLMSG_SPACE((len)))
 
 #define NLMSG_NOOP 0x1 /* Nothing. */
-- 
1.7.1

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

[PATCH] User level kernel headers -Wall -Wextra -Werror support fix For code using: #include NLMSG_OK -I/include

[Doron Tsur]

Tested-by: Doron Tsur 
Test log:
Compilation environments:
Ubuntu 13.10, x86_64, gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Ubuntu 13.04, x86_64, gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
[ -ftrack-macro-expansion=2 issue submitted:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59495 ]
Kernel headers installed at:
make -C .../linux-stable headers_install \
INSTALL_HDR_PATH=/builds/kernel_tests_user_headers/
Pre-patch compilation:
gcc -Wall -Wextra -Werror
-I/builds/kernel_tests_pre_patch_user_headers/include
include-uapi-linux-netlink.h.test.c
In file included from include-uapi-linux-netlink.h.test.c:2:0:
include-uapi-linux-netlink.h.test.c: In function ‘main’:
/builds/kernel_tests_pre_patch_user_headers/include/linux/netlink.h:89:24:
error: comparison between signed and unsigned integer expressions
[-Werror=sign-compare]
   (nlh)->nlmsg_len <= (len))
^
include-uapi-linux-netlink.h.test.c:26:5: note: in expansion of macro ‘NLMSG_OK’
 NLMSG_OK(_netlink_header, active_len));
 ^
cc1: all warnings being treated as errors
Post-patch:
$ gcc  -Wall -Wextra -Werror
-I/builds/kernel_tests_user_headers/include/
include-uapi-linux-netlink.h.test.c
$ ./a.out
nlmsg_len= 1, len = 1 NLMSG_OK(nlh,len) test result: 0
nlmsg_len= 1, len = 3000 NLMSG_OK(nlh,len) test result: 0
nlmsg_len= 3000, len = 1 NLMSG_OK(nlh,len) test result: 0
nlmsg_len= 3000, len = 3000 NLMSG_OK(nlh,len) test result: 1

Signed-off-by: Doron Tsur 
---
 include/uapi/linux/netlink.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index 1a85940..1884d4e 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -86,7 +86,7 @@ struct nlmsghdr {
  (struct nlmsghdr*)(((char*)(nlh)) + 
NLMSG_ALIGN((nlh)->nlmsg_len)))
 #define NLMSG_OK(nlh,len) ((len) >= (int)sizeof(struct nlmsghdr) && \
   (nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \
-  (nlh)->nlmsg_len <= (len))
+  (int)(nlh)->nlmsg_len <= (len))
 #define NLMSG_PAYLOAD(nlh,len) ((nlh)->nlmsg_len - NLMSG_SPACE((len)))
 
 #define NLMSG_NOOP 0x1 /* Nothing. */
-- 
1.7.1

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

Re: [PATCH v2 1/1] ARM: dts: Add missing clocks for exynos4412 dwmmc node

[Alex Ling]

Thanks for pointing out this, Tomasz. I'll use those patches instead.


Regards,
Alex

On Sat, Dec 14, 2013 at 9:24 PM, Tomasz Figa  wrote:
> Hi Alex,
>
> On Saturday 14 of December 2013 13:21:30 Alex Ling wrote:
>> This patch adds "biu" and "ciu" clocks for exynos4412 dwmmc
>> node. Without this patch, dwmmc host driver will skip enabling the
>> two clocks and it will break dwmmc host function on exynos4412.
>> Tested on FriendlyARM TINY4412 board.
>>
>> Signed-off-by: Alex Ling 
>> ---
>> Changes for v2:
>>- Fix patch description as Mark Rutland suggested
>>
>>  arch/arm/boot/dts/exynos4412.dtsi |2 ++
>>  1 file changed, 2 insertions(+)
>
> The patch is correct, but unfortunately it's not the only thing that
> is wrong with MSHC device tree node for Exynos4x12.
>
> Please refer to my series fixing DW-MSHC support on Exynos4x12 (and
> enabling it on TRATS2 board):
> http://www.spinics.net/lists/arm-kernel/msg293652.html
>
> Best regards,
> Tomasz
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] rfcomm (userland) broken by commit 29cd718b

[Peter Hurley]

On 12/15/2013 06:24 AM, Gianluca Anzolin wrote:

On Fri, Dec 13, 2013 at 12:35:26AM +0100, Alexander Holler wrote:

Am 12.12.2013 21:36, schrieb Peter Hurley:


What currently happens is that when one kills rfcomm (and any other
terminal which might use that tty), the entry in /dev doesn't
disappear. That means the same call to refcomm with the same device
(e.g. [/dev/]rfcomm1 doesn't work.


Thanks for the report, Alexander.

Point 4 above details a different situation; something else is
happening.

Would you please detail the necessary steps to reproduce this regression?
(How do you 'kill' rfcomm? etc.  Shell command lines would be best.)


Just call

rfcomm connect rfcomm9 01:23:45:67:89:ab

wait until the connection happened  (a message will appear) and then
press ctrl-c. This still terminates the bluetooth connection, but the
device in /dev is now left.


Yes I'm able to reproduce the regression which is indeed caused by that
commit.

However I'm puzzled. Surely there is a fifth case I didn't cover because
when rfcomm_dev_state_change() is called, the tty_port is there but the tty is
not, and therefore I cannot get a reference to it and send the HUP.


There is a fifth case, but it's crazy.

The tty has been properly shutdown and destroyed because the tty file handle
was closed, not hungup. The rfcomm device reference was properly put
when the tty was released.

But when the remote hangs up (and sends disc), then rfcomm_dev_state_change()
is called -- to kill the port reference (thus the rfcomm device) that was
instantiated locally! Ridiculous. Doubly ridiculous because it's the local
port shutdown that closes the dlc locally that sends the disconnect (and sets
the local dlc state) that triggers the received rfcomm_dev_state_change()!

If this behavior is desirable (or necessary because it's been exposed to
userspace), then why was the design ever reference-counted to begin with?

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

Re: [PATCH 0/2] gpio: davinci: reuse for keystone arch

[Sekhar Nori]

On Sunday 15 December 2013 07:20 PM, Sekhar Nori wrote:
> On Sunday 15 December 2013 12:41 AM, Santosh Shilimkar wrote:
>> Linus, Sekhar,
>>
>> On Thursday 12 December 2013 01:12 PM, Grygorii Strashko wrote:
>>> This series is intended to update Davinci GPIO driver and reuse
>>> it for Keystone SoCs, because Keystone uses the similar GPIO IP like 
>>> Davinci.
>>> Keystone GPIO IP: supports:
>>> - up to 32 GPIO lines;
>>> - only unbanked irqs;
>>>
>>> See Documentation:
>>> Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>>>
>>> This series depends on:
>>> [1] "[PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio"
>>> https://lkml.org/lkml/2013/11/8/22
>>> [2] "[PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement"
>>> https://www.mail-archive.com/devicetree@vger.kernel.org/msg05970.html
>>> [3] "gpio: davinci: get rid of DAVINCI_N_GPIO"
>>> https://lkml.org/lkml/2013/11/26/405
>>> [4] "gpio: introduce GPIO_DAVINCI kconfig option"
>>> https://lkml.org/lkml/2013/11/26/435
>>> [5] "gpio: davinci: use chained_irq_enter/chained_irq_exit API"
>>> https://lkml.org/lkml/2013/11/26/428
>>>
>>> To handle all dependencies, I've created a branch where I collected all 
>>> "ready to merge" patches (all acks added in patches) and this series:
>>> - https://github.com/grygoriyS/linux.git
>>> - branch: keystone-master-gpio-for-next
>>>
>> Can one of you pull all these patches ?
> 
> So I went through my backlog and queued all that I think is ready. Here
> is the branch. Let me know if there is anything else missing.

Forgot to mention that I have not been able to test them today though.
They will hit linux-next only after I have been able to test them and I
send a pull request to arm-soc or Linus W.

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

Re: [RFC v2 1/4] power: asv: Add common ASV support for Samsung SoCs

[Tomasz Figa]

On Sunday 15 of December 2013 22:30:13 Yadwinder Singh Brar wrote:
[snip]
> >> +
> >> + return NULL;
> >> +}
> >> +
> >> +unsigned int asv_get_volt(enum asv_type_id target_type,
> >> + unsigned int target_freq)
> >
> > Do you need this function at all? I believe this is all about populating
> > device's OPP array with frequencies and voltages according to its ASV
> > level. Users will be able to query for required voltage using standard OPP
> > calls then, without a need for ASV specific functions like this one.
> >
> 
> Yes, I had put a comment in initial version after commit message :
> "Hopefully asv_get_volt() can go out in future, once all users start using OPP
> library." , which seems to be missed in this version.
> I had kept it for the time being in initial version, to keep it
> usable(for testing) with
> existing cpufreq drivers, which need to reworked and may take time.

Hmm, at the moment none of cpufreq drivers use ASV, so they need to be
reworked anyway to use it either by the means of a private get_volt
function or OPP framework. I agree that OPP may require more work,
though.

If we decide to keep this function in final version, a comment should be
added saying that its usage is deprecated in favor of generic OPP helpers.

> 
> [snip]
> >> +
> >> + for (i = 0; i < asv_info->nr_dvfs_level; i++) {
> >> + if (dev_pm_opp_add(dev, dvfs_table[i].freq * 1000,
> >> + dvfs_table[i].volt)) {
> >> + dev_warn(dev, "Failed to add OPP %d\n",
> >> +  dvfs_table[i].freq);
> >
> > Hmm, shouldn't it be considered a failure instead?
> >
> 
> hmm, not really always. Theoretically system with some less(failed to add)
> levels can work. Moreover I had prefered to keep it only warning, just to
> keep the behaviour of  asv_init_opp_table() similar to that of its
> counter part of_init_opp_table().

I'm not quite convinced about it. If dev_pm_opp_add() fails, doesn't it mean
that something broke seriously in upper layer and we should propagate the
error down? Especially when looking at opp_add(), the only failure
conditions I can find are memory allocation errors which mean that the
system is unlikely to operate correctly anyway.

> 
> >> + continue;
> >> + }
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static struct asv_member *asv_init_member(struct asv_info *asv_info)
> >> +{
> >> + struct asv_member *asv_mem;
> >> + int ret = 0;
> >> +
> >> + if (!asv_info) {
> >> + pr_err("No ASV info provided\n");
> >> + return NULL;
> >
> > I'd suggest adopting the ERR_PTR() convention, which allows returning more
> > information about the error.
> >
> 
> Will it be really usefull here?, as we are not checking return value
> of any function.

Why not? Here you have ERR_PTR(-EINVAL), then...

> Bur for some cases below, i will also like to get it used.
> 
> >> + }
> >> +
> >> + asv_mem = kzalloc(sizeof(*asv_mem), GFP_KERNEL);
> >> + if (!asv_mem) {
> >> + pr_err("Allocation failed for member: %s\n", asv_info->name);
> >> + return NULL;

ERR_PTR(-ENOMEM) here.

These are two completely different error cases.

> >> + }
> 
> [snip]
> >
> > Hmm, I don't see a point of these three separate callbacks above.
> >
> > In general, I'd suggest a different architecture. I'd see this more as:
> >
> > 1) Platform code registers static platform device to instantiate SoC ASV
> >driver.
> > 2) SoC specific ASV driver probes, reads group ID from hardware register,
> >calls register_asv_member() with appropriate DVFS table for detected
> >group.
> > 3) Driver using ASV calls asv_init_opp_table() with its struct device and
> >ASV member name, which causes the ASV code to fill device's operating
> >point using OPP calls.
> >
> > Now client driver has all the information it needs and the work of ASV
> > subsystem is done. The control flow between drivers would be much simpler
> > and no callbacks would have to be called.
> >
> 
> Architecture stated above seems to be a subset(one possible way of use),
> of the proposed architecture. If someone really have nothing much to do,
> he can adopt the above stated approach using this framework also,
> callbacks are not mandatory.

I believe that kernel design principles are to first start with something
simple and then if a real need for an extension shows up then extend
existing code base with missing features.

> 
> Since we usually have more things to do other than only reading
> fused group value and simply parsing a table index, so in drivers we have to
> implement functions to segregate stuff and different people do it in
> different way. Its an attempt to provide a way to keep structure(functions)
> similar for easy understanding and factoring out of common code.

I fail to see those more things. Could you elaborate a bit 

Re: [PATCH 0/2] gpio: davinci: reuse for keystone arch

[Sekhar Nori]

On Sunday 15 December 2013 12:41 AM, Santosh Shilimkar wrote:
> Linus, Sekhar,
> 
> On Thursday 12 December 2013 01:12 PM, Grygorii Strashko wrote:
>> This series is intended to update Davinci GPIO driver and reuse
>> it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci.
>> Keystone GPIO IP: supports:
>> - up to 32 GPIO lines;
>> - only unbanked irqs;
>>
>> See Documentation:
>> Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>>
>> This series depends on:
>> [1] "[PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio"
>> https://lkml.org/lkml/2013/11/8/22
>> [2] "[PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement"
>> https://www.mail-archive.com/devicetree@vger.kernel.org/msg05970.html
>> [3] "gpio: davinci: get rid of DAVINCI_N_GPIO"
>> https://lkml.org/lkml/2013/11/26/405
>> [4] "gpio: introduce GPIO_DAVINCI kconfig option"
>> https://lkml.org/lkml/2013/11/26/435
>> [5] "gpio: davinci: use chained_irq_enter/chained_irq_exit API"
>> https://lkml.org/lkml/2013/11/26/428
>>
>> To handle all dependencies, I've created a branch where I collected all 
>> "ready to merge" patches (all acks added in patches) and this series:
>> - https://github.com/grygoriyS/linux.git
>> - branch: keystone-master-gpio-for-next
>>
> Can one of you pull all these patches ?

So I went through my backlog and queued all that I think is ready. Here
is the branch. Let me know if there is anything else missing.

https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio

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

Re: [RFC v2 1/4] power: asv: Add common ASV support for Samsung SoCs

[Yadwinder Singh Brar]

Hi Tomasz,

Thanks for your thorough review and nice suggestions.

[snip]
>> +}
>> +
>> +static struct asv_member *asv_get_mem(enum asv_type_id asv_type)
>
> I don't really like this enum based look-up. It's hard to define an enum
> that covers any possible existing and future platforms that would not be
> bloated with single platform specific entries. IMHO something string based
> could be more scalable.
>

Yes, I also agree string based look-up will be better. I was thinking
to convert to it,
after initial discussion over the APIs.

>> +{
>> + struct asv_member *asv_mem;
>> + struct asv_info *asv_info;
>> +
>> + list_for_each_entry(asv_mem, _list, node) {
>> + asv_info = asv_mem->asv_info;
>> + if (asv_type == asv_info->type)
>> + return asv_mem;
>> + }
>
> Don't you need any kind of locking here? A mutex in add_asv_member()
> suggests that read access to the list should be protected as well.
>

hmmm, yes should be their for completeness of code.

>> +
>> + return NULL;
>> +}
>> +
>> +unsigned int asv_get_volt(enum asv_type_id target_type,
>> + unsigned int target_freq)
>
> Do you need this function at all? I believe this is all about populating
> device's OPP array with frequencies and voltages according to its ASV
> level. Users will be able to query for required voltage using standard OPP
> calls then, without a need for ASV specific functions like this one.
>

Yes, I had put a comment in initial version after commit message :
"Hopefully asv_get_volt() can go out in future, once all users start using OPP
library." , which seems to be missed in this version.
I had kept it for the time being in initial version, to keep it
usable(for testing) with
existing cpufreq drivers, which need to reworked and may take time.

[snip]
>> +
>> + for (i = 0; i < asv_info->nr_dvfs_level; i++) {
>> + if (dev_pm_opp_add(dev, dvfs_table[i].freq * 1000,
>> + dvfs_table[i].volt)) {
>> + dev_warn(dev, "Failed to add OPP %d\n",
>> +  dvfs_table[i].freq);
>
> Hmm, shouldn't it be considered a failure instead?
>

hmm, not really always. Theoretically system with some less(failed to add)
levels can work. Moreover I had prefered to keep it only warning, just to
keep the behaviour of  asv_init_opp_table() similar to that of its
counter part of_init_opp_table().

>> + continue;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static struct asv_member *asv_init_member(struct asv_info *asv_info)
>> +{
>> + struct asv_member *asv_mem;
>> + int ret = 0;
>> +
>> + if (!asv_info) {
>> + pr_err("No ASV info provided\n");
>> + return NULL;
>
> I'd suggest adopting the ERR_PTR() convention, which allows returning more
> information about the error.
>

Will it be really usefull here?, as we are not checking return value
of any function.
Bur for some cases below, i will also like to get it used.

>> + }
>> +
>> + asv_mem = kzalloc(sizeof(*asv_mem), GFP_KERNEL);
>> + if (!asv_mem) {
>> + pr_err("Allocation failed for member: %s\n", asv_info->name);
>> + return NULL;
>> + }

[snip]
>
> Hmm, I don't see a point of these three separate callbacks above.
>
> In general, I'd suggest a different architecture. I'd see this more as:
>
> 1) Platform code registers static platform device to instantiate SoC ASV
>driver.
> 2) SoC specific ASV driver probes, reads group ID from hardware register,
>calls register_asv_member() with appropriate DVFS table for detected
>group.
> 3) Driver using ASV calls asv_init_opp_table() with its struct device and
>ASV member name, which causes the ASV code to fill device's operating
>point using OPP calls.
>
> Now client driver has all the information it needs and the work of ASV
> subsystem is done. The control flow between drivers would be much simpler
> and no callbacks would have to be called.
>

Architecture stated above seems to be a subset(one possible way of use),
of the proposed architecture. If someone really have nothing much to do,
he can adopt the above stated approach using this framework also,
callbacks are not mandatory.

Since we usually have more things to do other than only reading
fused group value and simply parsing a table index, so in drivers we have to
implement functions to segregate stuff and different people do it in
different way. Its an attempt to provide a way to keep structure(functions)
similar for easy understanding and factoring out of common code.

Moreover, I feels need of callbacks if we have to do something depending
upon(specific) the user/instance of  ASV member. One thing came
in my mind was dev_node may be required if we may think of parsing
ASV table from DT and may be more things in future.


I would like to get rectified, other nit/suggestions stated by you 

Re: [RFC v2 1/4] power: asv: Add common ASV support for Samsung SoCs

[Yadwinder Singh Brar]

Hi Abhilash,

[ ... ]
>> + * @nr_dvfs_level: Number of dvfs levels supported by member.
>> + * @dvfs_table: Table containing supported ASV freqs and corresponding 
>> volts.
>> + * @asv_grp: ASV group of member.
>> + * @flags: ASV flags
> What are the ASV flags you had in mind ?

Right now we don't have any, some thing like delayed
init of asv table depending upon dev_node/user(instance)
was coming in my mind.
Actually I missed to remove it for the time being.

Thanks for your review and other suggestions.

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

Re: [RFC v1 3/9] gpio: davinci: use chained_irq_enter/chained_irq_exit API

[Sekhar Nori]

On Wednesday 27 November 2013 01:10 AM, Grygorii Strashko wrote:
> It's unsafe to call IRQ chip callbacks (.irq_mask/irq_unmask/irq_ack)
> from chained IRQ handler directly. Because, Davinci GPIO block is used
> by different SoCs, which, in turn, have different Main IRQ controllers
> (Davinci - aintc, cp-intc; Keystone - arm-gic) which may introduce
> diffrent set of IRQ chip callbacks. As result, call of
> gpio_irq_handler() on Keysone will simply cause crash the system,
> because ARM-GIC implements .irq_eoi() instead of .irq_ack().
> 
> Hence, fix it by using Kernel chained_irq_enter/chained_irq_exit APIs as
> they are intended to handle exact such cases.
> 
> Signed-off-by: Grygorii Strashko 

Queued with Linus's and Santosh's acks.

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

Re: [PATCH] expand micro-optimizations in kernel to newer model CPUs

[Borislav Petkov]

On Sun, Dec 15, 2013 at 04:42:50AM -0800, John wrote:
> I am using ANOVA to establish that the generic group differs from the
> optimized group.

You probably should run a couple other benchmarks, in addition, for
greater confidence that this optimization actually brings any palpable
improvement and is not just causing code bloat.

For example, last time I did a perf profile of a kernel build on AMD
F15h, the PILERDRIVER "optimization" was actually even a bit worse than
the standard MK8 one.

http://marc.info/?l=linux-kernel=138081947417204

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH v6 6/6] ARM: davinci: da850 evm: add GPIO pinumux entries DT node

[Sekhar Nori]

On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote:
> From: KV Sujith 
> 
> Add GPIO DT node and pinmux entries for DA850 EVM. GPIO is
> configurable differently on different boards. So add GPIO
> pinmuxing in dts file.
> 
> Signed-off-by: KV Sujith 
> Signed-off-by: Philip Avinash 
> Signed-off-by: Lad, Prabhakar 
> ---
>  arch/arm/boot/dts/da850-evm.dts |   20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index 588ce58..f82c129 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -17,6 +17,21 @@
>   soc {
>   pmx_core: pinmux@1c14120 {
>   status = "okay";
> +
> + gpio_pins: pinmux_gpio_pins {
> + pinctrl-single,bits = <
> + /* GPIO2_4 GPIO2_6 */
> + 0x18 0x8080 0xf0f0
> + /* GPIO2_8 GPIO2_15 */
> + 0x14 0x8008 0xf00f
> + /* GPIO3_12 GPIO3_13 */
> + 0x1C 0x8800 0xff00
> + /* GPIO4_0 GPIO4_1 */
> + 0x28 0x8800 0xff00
> + /* GPIO6_9 GPIO6_10 GPIO6_13 */
> + 0x34 0x08800800 0x0ff00f00
> + >;
> + };
>   };

Shouldn't these pinmux entries be part of actual device
node which needs them to be muxed this way? For now, I
have committed the attached reduced patch.

Thanks,
Sekhar

---8<---
>From 3a9574f2aa4ffd9b867321a1f298893410bd3718 Mon Sep 17 00:00:00 2001
From: KV Sujith 
Date: Thu, 21 Nov 2013 23:45:31 +0530
Subject: [PATCH 1/1] ARM: davinci: da850 evm: add GPIO pinumux entries DT node

Add GPIO DT node and pinmux entries for DA850 EVM. GPIO is
configurable differently on different boards. So add GPIO
pinmuxing in dts file.

Signed-off-by: KV Sujith 
Signed-off-by: Philip Avinash 
Signed-off-by: Lad, Prabhakar 
Signed-off-by: Sekhar Nori 
---
 arch/arm/boot/dts/da850-evm.dts |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 588ce58..1e11e5a 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -101,6 +101,9 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
};
+   gpio: gpio@1e26000 {
+   status = "okay";
+   };
};
nand_cs3@6200 {
status = "okay";
-- 
1.7.10.1



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

Re: [RFC] Add ff-memless-next driver

[Michal Malý]

On Saturday 14 of December 2013 18:04:02 Joe Perches wrote:
> On Sun, 2013-12-15 at 01:19 +0100, Michal Malý wrote:
> > diff --git a/drivers/input/ff-memless-next.c
> > b/drivers/input/ff-memless-next.c
> []
> 
> > +static inline s32 mlnx_clamp_level(const s32 level)
> > +{
> > +   return (level > 0x7fff) ? 0x7fff : ((level < -0x7fff) ? -0x7fff :
> > level);
> 
>   clamp(level, -0x7fff, 0x7fff);
> []
> 
> > +static inline int mlnx_is_conditional(const struct ff_effect *effect)
> > +{
> > +   return (effect->type == FF_DAMPER) || (effect->type == FF_FRICTION) ||
> > (effect->type == FF_INERTIA) || (effect->type == FF_SPRING); +}
> 
> Maybe try to run your patch through scripts/checkpatch.pl
> 
> bool?
> 80 char line max? (true for the file, not just here)
> switch?
>   switch (effect->type) {
>   case FF_DAMPER:
>   case FF_FRICTION:
>   case FF_INERTIA:
>   case FF_SPRING:
>   return true;
>   }
>   return false;

Okay, thanks for the input. I found a problem regarding effect updating in the 
code anyway. I'll submit a corrected version of the patch once I'm sure it's 
fixed.

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

Re: [PATCH v6 5/6] ARM: davinci: da850: add GPIO DT node

[Sekhar Nori]

On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote:
> From: KV Sujith 
> 
> Add DT node for Davinci GPIO driver.
> 
> Signed-off-by: KV Sujith 
> Signed-off-by: Philip Avinash 
> Signed-off-by: Lad, Prabhakar 

Added to v3.14/dt branch of my k.org tree.

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

Re: [PATCH] regulator: core: Use postcore_initcall(regulator_init_complete)

[Shawn Guo]

On Wed, Nov 27, 2013 at 12:55:20AM +, Mark Brown wrote:
> On Tue, Nov 26, 2013 at 12:46:03AM +, Mark Brown wrote:
> 
> > lot changing the callers is probably the cleanest.  I'll probably do
> > that tomorrow if a patch doesn't turn up before then.
> 
> Sorry, that'll now be Wednesday - an unusually busy day started by
> someone deciding to fell trees outside my window early this morning put
> a bit of a spanner in the works.

What is going on about that patch?

Shawn

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

Re: [PATCH] expand micro-optimizations in kernel to newer model CPUs

[John]

- Original Message -
> From: Richard Weinberger <>
>
> A *very* small speedup.
> 
> And I really doubt your numbers.
> Why are you using ANOVA? You're comparing *two* groups not more than two.
> I had a quick look at your raw numbers, they don't seem to be normally
> distributed at all.
> Did you remove some peaks?
> 


Hi Richard.  Thank you for your interest.  Yes, a small speedup as I mentioned 
but  I'll note that the current kernel code includes the MCORE2 option.  I 
tested this against some of the newer ones and they are all on par with each 
other.  For example, here are differences in median values:

CPUDifference in median value
core2        +87.5 ms
core7-avx+79.7 ms
core-avx-i+257.2 ms

I am using ANOVA to establish that the generic group differs from the optimized 
group.  I have always used ANOVA for this sort of comparison whether using two 
or more groups.  In fact, thumb through any medical or scientific journal, 
you'll see others in pier reviewed article doing the same.  

I did not remove any datapoints; I do not understand why you don't think the 
sets are normally distributed.  Did you see the normal quantile plots?  
Additionally, the population variances are fairly equal (Levene and Barlett 
tests). 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 3/6] gpio: davinci: remove unused variable intc_irq_num

[Sekhar Nori]

On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote:
> From: "Lad, Prabhakar" 
> 
> As the davinci-gpio driver is migrated to use irqdomain
> there is no need to pass the irq base for the gpio driver.
> This patch removes this variable from davinci_gpio_platform_data
> and also the refrences from the machine file.
> 
> Signed-off-by: Lad, Prabhakar 

Queuing for v3.14 along with Linus's ack.

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

Re: [PATCH v6 2/6] This patch converts the davinci gpio driver to use irqdomain support.

[Sekhar Nori]

On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote:
> From: "Lad, Prabhakar" 
> 
> Signed-off-by: Lad, Prabhakar 
> [grygorii.stras...@ti.com:
>  - switch to use one irq-domain per  all GPIO banks
>  - keep irq_create_mapping() call in gpio_to_irq_banked() as it
>simply transformed to irq_find_mapping() if IRQ mapping exist
>already]
> Signed-off-by: Grygorii Strashko 

A proper subject line is missing. I added the following as the subject:

gpio: davinci: convert to use irqdomain

and moved your current subject line to become the commit text.

> @@ -396,6 +411,20 @@ static int davinci_gpio_irq_setup(struct platform_device 
> *pdev)
>   }
>   clk_prepare_enable(clk);
>  
> + irq = irq_alloc_descs(-1, 0, ngpio, 0);
> + if (irq < 0) {
> + dev_err(dev, "Couldn't allocate IRQ numbers\n");
> + return -ENODEV;

modified this to:

return irq;

since your have already received a more relevant error code. With these
modifications and Linus's ack, queuing for v3.14.

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

Re: [PATCH v5 3/3] perf diff: color the Weighted Diff column

[Jiri Olsa]

On Tue, Dec 10, 2013 at 06:19:02PM +0530, Ramkumar Ramachandra wrote:
> In
> 
>   $ perf diff -c wdiff:M,N
> 
> color the numbers in the Weighted Diff column either green or red,
> depending on whether the number is positive or negative.
> 
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Cc: Arnaldo Carvalho de Melo 
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  tools/perf/builtin-diff.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index c07cd3c..8e6e541 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -777,6 +777,7 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
>   container_of(fmt, struct diff_hpp_fmt, fmt);
>   struct hist_entry *pair = get_pair_fmt(he, dfmt);
>   double diff;
> + s64 wdiff;
>   char pfmt[20] = " ";
>  
>   if (!pair)
> @@ -805,6 +806,18 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
>   scnprintf(pfmt, 20, "%%%d.6f", dfmt->header_width);
>   return value_color_snprintf(hpp->buf, hpp->size,
>   pfmt, diff);
> + case COMPUTE_WEIGHTED_DIFF:
> + if (he->dummy)
> + goto dummy_print;
> + if (pair->diff.computed)
> + wdiff = pair->diff.wdiff;
> + else
> + wdiff = compute_wdiff(he, pair);
> +
> + scnprintf(pfmt, 20, "%%14ld", dfmt->header_width);
> + return color_snprintf(hpp->buf, hpp->size,
> + wdiff > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
> + pfmt, wdiff);

this one is still wrong, you either need to use 'abs(wdiff) > 0'
or call value_color_snprintf (which is better) as in previous cases

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

Re: [PATCH v5 1/3] perf diff: color the Delta column

[Jiri Olsa]

On Tue, Dec 10, 2013 at 06:19:00PM +0530, Ramkumar Ramachandra wrote:

SNIP

> + return scnprintf(hpp->buf, hpp->size, "%*s",
> + dfmt->header_width, pfmt);
> +}
> +
> +static int hpp__color_delta(struct perf_hpp_fmt *fmt,
> + struct perf_hpp *hpp, struct hist_entry *he)
> +{
> + return __hpp__color_compare(fmt, hpp, he, COMPUTE_DELTA);
> +}
> +
>  static void
>  hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
>  {
> @@ -940,8 +979,16 @@ static void data__hpp_register(struct data__file *d, int 
> idx)
>   fmt->entry  = hpp__entry_global;
>  
>   /* TODO more colors */
> - if (idx == PERF_HPP_DIFF__BASELINE)
> + switch (idx) {
> + case PERF_HPP_DIFF__BASELINE:
>   fmt->color = hpp__color_baseline;
> + break;
> + case PERF_HPP_DIFF__DELTA:
> + fmt->color = hpp__color_delta;
> + break;
> + default:
> + break;
> + }

please put changes below into separated patch

>  
>   init_header(d, dfmt);
>   perf_hpp__column_register(fmt);
> diff --git a/tools/perf/util/color.c b/tools/perf/util/color.c
> index 66e44a5..ec5c756 100644
> --- a/tools/perf/util/color.c
> +++ b/tools/perf/util/color.c
> @@ -2,6 +2,8 @@
>  #include "cache.h"
>  #include "color.h"
>  
> +#include 
> +

nit: extra empty line

>  int perf_use_color_default = -1;
>  
>  static int parse_color(const char *name, int len)
> @@ -298,10 +300,10 @@ const char *get_percent_color(double percent)
>* entries in green - and keep the low overhead places
>* normal:
>*/
> - if (percent >= MIN_RED)
> + if (fabs(percent) >= MIN_RED)
>   color = PERF_COLOR_RED;
>   else {
> - if (percent > MIN_GREEN)
> + if (fabs(percent) > MIN_GREEN)
>   color = PERF_COLOR_GREEN;
>   }
>   return color;
> -- 
> 1.8.5.rc0.5.g70ebc73.dirty
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] expand micro-optimizations in kernel to newer model CPUs

[Richard Weinberger]

On Sun, Dec 15, 2013 at 1:00 PM, John  wrote:
> - Original Message -
>
>> From: H. Peter Anvin 
>> Sent: Saturday, December 14, 2013 6:41 PM
>> Subject: Re: Fw: [PATCH] expand micro-optimizations in kernel to newer model 
>> CPUs
>
>>
>> Please submit in the email form requested by the
>> Documentation/SubmittingPatches email; in particular we need the
>> Signed-off-by: statements.
>>
>>
>> ááá -hpa
>>
>
> From: John Audia 
>
>
> Signed-off-by: John Audia 
>
>
> This patch has been tested on and known to work with kernel versions from 3.2
> up to the latest git version (pulled on 12/14/2013).
>
> This patch will expand the number of microarchitectures to include new
> processors including: AMD K10-family, AMD Family 10h (Barcelona), AMD Family
> 14h (Bobcat), AMD Family 15h (Bulldozer), AMD Family 15h (Piledriver), AMD
> Family 16h (Jaguar), Intel 1st Gen Core i3/i5/i7 (Nehalem), Intel 2nd Gen Core
> i3/i5/i7 (Sandybridge), Intel 3rd Gen Core i3/i5/i7 (Ivybridge), and Intel 4th
> Gen Core i3/i5/i7 (Haswell). It also offers the compiler the 'native' flag.
>
> Small but real speed increases are measurable using a make endpoint comparing
> a generic kernel to one built with one of the respective microarchs.

A *very* small speedup.

And I really doubt your numbers.
Why are you using ANOVA? You're comparing *two* groups not more than two.
I had a quick look at your raw numbers, they don't seem to be normally
distributed at all.
Did you remove some peaks?

> See the following experimental evidence of this statement:
> https://github.com/graysky2/kernel_gcc_patch
>
> ---
> diff -uprN a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
> --- a/arch/x86/include/asm/module.h2013-11-03 18:41:51.0 -0500
> +++ b/arch/x86/include/asm/module.h2013-12-15 06:21:24.351122516 -0500
> @@ -15,6 +15,16 @@
> á#define MODULE_PROC_FAMILY "586MMX "
> á#elif defined CONFIG_MCORE2
> á#define MODULE_PROC_FAMILY "CORE2 "
> +#elif defined CONFIG_MNATIVE
> +#define MODULE_PROC_FAMILY "NATIVE "
> +#elif defined CONFIG_MCOREI7
> +#define MODULE_PROC_FAMILY "COREI7 "
> +#elif defined CONFIG_MCOREI7AVX
> +#define MODULE_PROC_FAMILY "COREI7AVX "
> +#elif defined CONFIG_MCOREAVXI
> +#define MODULE_PROC_FAMILY "COREAVXI "
> +#elif defined CONFIG_MCOREAVX2
> +#define MODULE_PROC_FAMILY "COREAVX2 "
> á#elif defined CONFIG_MATOM
> á#define MODULE_PROC_FAMILY "ATOM "
> á#elif defined CONFIG_M686
> @@ -33,6 +43,18 @@
> á#define MODULE_PROC_FAMILY "K7 "
> á#elif defined CONFIG_MK8
> á#define MODULE_PROC_FAMILY "K8 "
> +#elif defined CONFIG_MK10
> +#define MODULE_PROC_FAMILY "K10 "
> +#elif defined CONFIG_MBARCELONA
> +#define MODULE_PROC_FAMILY "BARCELONA "
> +#elif defined CONFIG_MBOBCAT
> +#define MODULE_PROC_FAMILY "BOBCAT "
> +#elif defined CONFIG_MBULLDOZER
> +#define MODULE_PROC_FAMILY "BULLDOZER "
> +#elif defined CONFIG_MPILEDRIVER
> +#define MODULE_PROC_FAMILY "PILEDRIVER "
> +#elif defined CONFIG_MJAGUAR
> +#define MODULE_PROC_FAMILY "JAGUAR "
> á#elif defined CONFIG_MELAN
> á#define MODULE_PROC_FAMILY "ELAN "
> á#elif defined CONFIG_MCRUSOE
> diff -uprN a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
> --- a/arch/x86/Kconfig.cpu2013-11-03 18:41:51.0 -0500
> +++ b/arch/x86/Kconfig.cpu2013-12-15 06:21:24.351122516 -0500
> @@ -139,7 +139,7 @@ config MPENTIUM4
> á
> á
> áconfig MK6
> -bool "K6/K6-II/K6-III"
> +bool "AMD K6/K6-II/K6-III"
> ádepends on X86_32
> á---help---
> á áSelect this for an AMD K6-family processor. áEnables use of
> @@ -147,7 +147,7 @@ config MK6
> á áflags to GCC.
> á
> áconfig MK7
> -bool "Athlon/Duron/K7"
> +bool "AMD Athlon/Duron/K7"
> ádepends on X86_32
> á---help---
> á áSelect this for an AMD Athlon K7-family processor. áEnables use of
> @@ -155,12 +155,55 @@ config MK7
> á áflags to GCC.
> á
> áconfig MK8
> -bool "Opteron/Athlon64/Hammer/K8"
> +bool "AMD Opteron/Athlon64/Hammer/K8"
> á---help---
> á áSelect this for an AMD Opteron or Athlon64 Hammer-family processor.
> á áEnables use of some extended instructions, and passes appropriate
> á áoptimization flags to GCC.
> á
> +config MK10
> +bool "AMD 61xx/7x50/PhenomX3/X4/II/K10"
> +---help---
> + áSelect this for an AMD 61xx Eight-Core Magny-Cours, Athlon X2 7x50,
> +Phenom X3/X4/II, Athlon II X2/X3/X4, or Turion II-family processor.
> + áEnables use of some extended instructions, and passes appropriate
> + áoptimization flags to GCC.
> +
> +config MBARCELONA
> +bool "AMD Barcelona"
> +---help---
> + áSelect this for AMD Barcelona and newer processors.
> +
> + áEnables -march=barcelona
> +
> +config MBOBCAT
> +bool "AMD Bobcat"
> +---help---
> + áSelect this for AMD Bobcat processors.
> +
> + áEnables -march=btver1
> +
> +config MBULLDOZER
> +bool "AMD Bulldozer"
> +---help---
> + áSelect this for AMD Bulldozer processors.
> +
> + áEnables -march=bdver1
> +
> +config MPILEDRIVER
> +bool "AMD Piledriver"
> +---help---
> + áSelect this for AMD Piledriver processors.
> +
> + áEnables -march=bdver2
> +
> +config MJAGUAR
> +bool "AMD 

Re: [PATCH] expand micro-optimizations in kernel to newer model CPUs

[John]

> From: Austin S Hemmelgarn <>
> This really depends on how you define 'big'.  Even a 1% performance
> increase is significant for a realtime system, and for someone with a
> cluster of systems, getting even a small improvement in performance on
> all of the systems could mean a huge increase in effective processing power.
> 

I have resubmitted per H. Peter Anvin's request:

http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/04844.html


Please cc me on any replies as I am not subscribed to lkml.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] radeon_pm: fix oops in hwmon_attributes_visible() and radeon_hwmon_show_temp_thresh()

[Borislav Petkov]

On Thu, Dec 12, 2013 at 11:29:41PM +, Deucher, Alexander wrote:
> Fix is already queued in my next -fixes pull.  Thanks!

I just hit this too so +1.

Btw, if Linus cuts -rc4 tonight and your pull request doesn't make it
in before then, we probably should warn people using radeon and testing
-rcs that they need this fix too.

Dunno, just a heads-up I think.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

[Kay Sievers]

On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares  wrote:
>> It does that per process doing that, and that's the problem for how
>> udev works/worked. The binary hwdb is on-disk and can be mmaped, and
>> there is no difference between initialization, first, or subsequent
>> queries.
>
> OK, point taken.
>
> I see that a mechanism for fast lookup of hardware identification data
> is needed. However, why should such a mechanism depend on udev, systemd,
> or Linux in general?
>
> What I would really like to have is a universal library for HW lookup,
> independent of anything else and widely portable. All the hardware data
> would be provided by other packages -- pci.ids, usb.ids, kernel modules,
> etc. -- and compiled to a binary format available for instant queries.

Yeah, that's what udev's hwdb is for us now.

For the textual strings, it seems relatively easy to commit to a
reasonable stable format, but I doubt that text strings alone would
justify supporting a binary format to compile to.

I wouldn't want to commit to cross-platform stability for other device
properties we use, or things which will end up in the hwdb. It's hard
enough already to coordinate the development across Linux
distributions, and generic cross-platform device-management metadata
maintenance doesn't sound too promising or an easy goal to me.

Some data of hwdb is entirely Linux and Linux kernel device specific.
The hwdb query string to lookup the binary radix tree in the hwdb file
is just the Linux kernel modalias strings, and they are directly
passed as queries to hwdb. Other platforms could do the same thing,
sure, but I'm not sure this really makes too much sense.

> Do I miss anything?

No, you didn't. It's just that we develop for and work with Linux
only, and this is really hard enough already. :)

I personally never think about other platforms because I don't really
know/care about or use them; and hwdb was just a tiny and not
important enough piece of the problem we need to solve, so it became
part of udev.

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

[PATCH] PNPBIOS: check return value of pnp_add_device()

[Dmitry Torokhov]

pnp_add_device() may fail so we need to handle errors and avoid leaking
memory.

Also, when pnp_alloc_dev fails, return -ENOMEM rather than -1.

Signed-off-by: Dmitry Torokhov 
---
 drivers/pnp/pnpbios/core.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c
index 9b86a01..074569e 100644
--- a/drivers/pnp/pnpbios/core.c
+++ b/drivers/pnp/pnpbios/core.c
@@ -312,18 +312,19 @@ static int __init insert_device(struct pnp_bios_node 
*node)
struct list_head *pos;
struct pnp_dev *dev;
char id[8];
+   int error;
 
/* check if the device is already added */
list_for_each(pos, _protocol.devices) {
dev = list_entry(pos, struct pnp_dev, protocol_list);
if (dev->number == node->handle)
-   return -1;
+   return -EEXIST;
}
 
pnp_eisa_id_to_string(node->eisa_id & PNP_EISA_ID_MASK, id);
dev = pnp_alloc_dev(_protocol, node->handle, id);
if (!dev)
-   return -1;
+   return -ENOMEM;
 
pnpbios_parse_data_stream(dev, node);
dev->active = pnp_is_active(dev);
@@ -342,7 +343,12 @@ static int __init insert_device(struct pnp_bios_node *node)
if (!dev->active)
pnp_init_resources(dev);
 
-   pnp_add_device(dev);
+   error = pnp_add_device(dev);
+   if (error) {
+   put_device(>dev);
+   return error;
+   }
+
pnpbios_interface_attach_device(node);
 
return 0;
-- 
1.8.3.1


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

[PATCH] PNPACPI: check return value of pnp_add_device()

[Dmitry Torokhov]

pnp_add_device() may fail so we need to handle errors and avoid leaking
memory. Also, do not use ACPI-specific return codes (AE_OK) but rather
standard one (0).

Signed-off-by: Dmitry Torokhov 
---
 drivers/pnp/pnpacpi/core.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
index 14655a0..4bd4c54 100644
--- a/drivers/pnp/pnpacpi/core.c
+++ b/drivers/pnp/pnpacpi/core.c
@@ -242,6 +242,7 @@ static int __init pnpacpi_add_device(struct acpi_device 
*device)
struct pnp_dev *dev;
char *pnpid;
struct acpi_hardware_id *id;
+   int error;
 
/* Skip devices that are already bound */
if (device->physical_node_count)
@@ -300,10 +301,16 @@ static int __init pnpacpi_add_device(struct acpi_device 
*device)
/* clear out the damaged flags */
if (!dev->active)
pnp_init_resources(dev);
-   pnp_add_device(dev);
+
+   error = pnp_add_device(dev);
+   if (error) {
+   put_device(>dev);
+   return error;
+   }
+
num++;
 
-   return AE_OK;
+   return 0;
 }
 
 static acpi_status __init pnpacpi_add_device_handler(acpi_handle handle,
-- 
1.8.3.1


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

[PATCH] Input: pmic8xxx-pwrkey - switch to using managed resources

[Dmitry Torokhov]

This simplifies error handling and device removal paths.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/misc/pmic8xxx-pwrkey.c | 74 
 1 file changed, 25 insertions(+), 49 deletions(-)

diff --git a/drivers/input/misc/pmic8xxx-pwrkey.c 
b/drivers/input/misc/pmic8xxx-pwrkey.c
index ef93840..aaf3325 100644
--- a/drivers/input/misc/pmic8xxx-pwrkey.c
+++ b/drivers/input/misc/pmic8xxx-pwrkey.c
@@ -32,7 +32,6 @@
  * @key_press_irq: key press irq number
  */
 struct pmic8xxx_pwrkey {
-   struct input_dev *pwr;
int key_press_irq;
 };
 
@@ -110,22 +109,22 @@ static int pmic8xxx_pwrkey_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
-   pwrkey = kzalloc(sizeof(*pwrkey), GFP_KERNEL);
+   pwrkey = devm_kzalloc(>dev, sizeof(*pwrkey), GFP_KERNEL);
if (!pwrkey)
return -ENOMEM;
 
-   pwr = input_allocate_device();
+   pwrkey->key_press_irq = key_press_irq;
+
+   pwr = devm_input_allocate_device(>dev);
if (!pwr) {
dev_dbg(>dev, "Can't allocate power button\n");
-   err = -ENOMEM;
-   goto free_pwrkey;
+   return -ENOMEM;
}
 
input_set_capability(pwr, EV_KEY, KEY_POWER);
 
pwr->name = "pmic8xxx_pwrkey";
pwr->phys = "pmic8xxx_pwrkey/input0";
-   pwr->dev.parent = >dev;
 
delay = (pdata->kpd_trigger_delay_us << 10) / USEC_PER_SEC;
delay = 1 + ilog2(delay);
@@ -133,7 +132,7 @@ static int pmic8xxx_pwrkey_probe(struct platform_device 
*pdev)
err = regmap_read(regmap, PON_CNTL_1, _cntl);
if (err < 0) {
dev_err(>dev, "failed reading PON_CNTL_1 err=%d\n", err);
-   goto free_input_dev;
+   return err;
}
 
pon_cntl &= ~PON_CNTL_TRIG_DELAY_MASK;
@@ -146,66 +145,43 @@ static int pmic8xxx_pwrkey_probe(struct platform_device 
*pdev)
err = regmap_write(regmap, PON_CNTL_1, pon_cntl);
if (err < 0) {
dev_err(>dev, "failed writing PON_CNTL_1 err=%d\n", err);
-   goto free_input_dev;
+   return err;
}
 
-   err = input_register_device(pwr);
+   err = devm_request_irq(>dev, key_press_irq, pwrkey_press_irq,
+  IRQF_TRIGGER_RISING,
+  "pmic8xxx_pwrkey_press", pwr);
if (err) {
-   dev_dbg(>dev, "Can't register power key: %d\n", err);
-   goto free_input_dev;
+   dev_err(>dev, "Can't get %d IRQ for pwrkey: %d\n",
+   key_press_irq, err);
+   return err;
}
 
-   pwrkey->key_press_irq = key_press_irq;
-   pwrkey->pwr = pwr;
-
-   platform_set_drvdata(pdev, pwrkey);
-
-   err = request_irq(key_press_irq, pwrkey_press_irq,
-   IRQF_TRIGGER_RISING, "pmic8xxx_pwrkey_press", pwr);
-   if (err < 0) {
-   dev_dbg(>dev, "Can't get %d IRQ for pwrkey: %d\n",
-key_press_irq, err);
-   goto unreg_input_dev;
+   err = devm_request_irq(>dev, key_release_irq, pwrkey_release_irq,
+  IRQF_TRIGGER_RISING,
+  "pmic8xxx_pwrkey_release", pwr);
+   if (err) {
+   dev_err(>dev, "Can't get %d IRQ for pwrkey: %d\n",
+   key_release_irq, err);
+   return err;
}
 
-   err = request_irq(key_release_irq, pwrkey_release_irq,
-IRQF_TRIGGER_RISING, "pmic8xxx_pwrkey_release", pwr);
-   if (err < 0) {
-   dev_dbg(>dev, "Can't get %d IRQ for pwrkey: %d\n",
-key_release_irq, err);
-
-   goto free_press_irq;
+   err = input_register_device(pwr);
+   if (err) {
+   dev_err(>dev, "Can't register power key: %d\n", err);
+   return err;
}
 
+   platform_set_drvdata(pdev, pwrkey);
device_init_wakeup(>dev, pdata->wakeup);
 
return 0;
-
-free_press_irq:
-   free_irq(key_press_irq, pwrkey);
-unreg_input_dev:
-   input_unregister_device(pwr);
-   pwr = NULL;
-free_input_dev:
-   input_free_device(pwr);
-free_pwrkey:
-   kfree(pwrkey);
-   return err;
 }
 
 static int pmic8xxx_pwrkey_remove(struct platform_device *pdev)
 {
-   struct pmic8xxx_pwrkey *pwrkey = platform_get_drvdata(pdev);
-   int key_release_irq = platform_get_irq(pdev, 0);
-   int key_press_irq = platform_get_irq(pdev, 1);
-
device_init_wakeup(>dev, 0);
 
-   free_irq(key_press_irq, pwrkey->pwr);
-   free_irq(key_release_irq, pwrkey->pwr);
-   input_unregister_device(pwrkey->pwr);
-   kfree(pwrkey);
-
return 0;
 }
 
-- 
1.8.3.1


-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH 2/2] gpio: introduce GPIO_DAVINCI kconfig option

[Sekhar Nori]

On Friday 29 November 2013 02:05 PM, Linus Walleij wrote:
> On Thu, Nov 21, 2013 at 4:34 PM, Grygorii Strashko
>  wrote:
> 
>> The compatible to Davinci GPIO HW block is used by other TI SoCs, like
>> Keystone, where GPIO support is declared as optional.
>>
>> Hence, introduce GPIO_DAVINCI Kconfig option which will allow to enable
>> Davinci GPIO driver for Keystone SoCs when needed. At same time, kept
>> Davinci GPIO driver enabled for Davinci SoCs by default.
>>
>> Signed-off-by: Grygorii Strashko 
> 
> Acked-by: Linus Walleij 
> 
> Sekhar, same comment here.

Queuing this with your's, Santosh's and Prabhakar's acks.

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

Re: [PATCH] expand micro-optimizations in kernel to newer model CPUs

[John]

- Original Message -

> From: H. Peter Anvin 
> Sent: Saturday, December 14, 2013 6:41 PM
> Subject: Re: Fw: [PATCH] expand micro-optimizations in kernel to newer model 
> CPUs

> 
> Please submit in the email form requested by the
> Documentation/SubmittingPatches email; in particular we need the
> Signed-off-by: statements.
> 
> 
>     -hpa
> 

From: John Audia 


Signed-off-by: John Audia 


This patch has been tested on and known to work with kernel versions from 3.2
up to the latest git version (pulled on 12/14/2013).

This patch will expand the number of microarchitectures to include new
processors including: AMD K10-family, AMD Family 10h (Barcelona), AMD Family
14h (Bobcat), AMD Family 15h (Bulldozer), AMD Family 15h (Piledriver), AMD
Family 16h (Jaguar), Intel 1st Gen Core i3/i5/i7 (Nehalem), Intel 2nd Gen Core
i3/i5/i7 (Sandybridge), Intel 3rd Gen Core i3/i5/i7 (Ivybridge), and Intel 4th
Gen Core i3/i5/i7 (Haswell). It also offers the compiler the 'native' flag.

Small but real speed increases are measurable using a make endpoint comparing
a generic kernel to one built with one of the respective microarchs.

See the following experimental evidence of this statement:
https://github.com/graysky2/kernel_gcc_patch

---
diff -uprN a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
--- a/arch/x86/include/asm/module.h2013-11-03 18:41:51.0 -0500
+++ b/arch/x86/include/asm/module.h2013-12-15 06:21:24.351122516 -0500
@@ -15,6 +15,16 @@
 #define MODULE_PROC_FAMILY "586MMX "
 #elif defined CONFIG_MCORE2
 #define MODULE_PROC_FAMILY "CORE2 "
+#elif defined CONFIG_MNATIVE
+#define MODULE_PROC_FAMILY "NATIVE "
+#elif defined CONFIG_MCOREI7
+#define MODULE_PROC_FAMILY "COREI7 "
+#elif defined CONFIG_MCOREI7AVX
+#define MODULE_PROC_FAMILY "COREI7AVX "
+#elif defined CONFIG_MCOREAVXI
+#define MODULE_PROC_FAMILY "COREAVXI "
+#elif defined CONFIG_MCOREAVX2
+#define MODULE_PROC_FAMILY "COREAVX2 "
 #elif defined CONFIG_MATOM
 #define MODULE_PROC_FAMILY "ATOM "
 #elif defined CONFIG_M686
@@ -33,6 +43,18 @@
 #define MODULE_PROC_FAMILY "K7 "
 #elif defined CONFIG_MK8
 #define MODULE_PROC_FAMILY "K8 "
+#elif defined CONFIG_MK10
+#define MODULE_PROC_FAMILY "K10 "
+#elif defined CONFIG_MBARCELONA
+#define MODULE_PROC_FAMILY "BARCELONA "
+#elif defined CONFIG_MBOBCAT
+#define MODULE_PROC_FAMILY "BOBCAT "
+#elif defined CONFIG_MBULLDOZER
+#define MODULE_PROC_FAMILY "BULLDOZER "
+#elif defined CONFIG_MPILEDRIVER
+#define MODULE_PROC_FAMILY "PILEDRIVER "
+#elif defined CONFIG_MJAGUAR
+#define MODULE_PROC_FAMILY "JAGUAR "
 #elif defined CONFIG_MELAN
 #define MODULE_PROC_FAMILY "ELAN "
 #elif defined CONFIG_MCRUSOE
diff -uprN a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
--- a/arch/x86/Kconfig.cpu2013-11-03 18:41:51.0 -0500
+++ b/arch/x86/Kconfig.cpu2013-12-15 06:21:24.351122516 -0500
@@ -139,7 +139,7 @@ config MPENTIUM4
 
 
 config MK6
-bool "K6/K6-II/K6-III"
+bool "AMD K6/K6-II/K6-III"
 depends on X86_32
 ---help---
   Select this for an AMD K6-family processor.  Enables use of
@@ -147,7 +147,7 @@ config MK6
   flags to GCC.
 
 config MK7
-bool "Athlon/Duron/K7"
+bool "AMD Athlon/Duron/K7"
 depends on X86_32
 ---help---
   Select this for an AMD Athlon K7-family processor.  Enables use of
@@ -155,12 +155,55 @@ config MK7
   flags to GCC.
 
 config MK8
-bool "Opteron/Athlon64/Hammer/K8"
+bool "AMD Opteron/Athlon64/Hammer/K8"
 ---help---
   Select this for an AMD Opteron or Athlon64 Hammer-family processor.
   Enables use of some extended instructions, and passes appropriate
   optimization flags to GCC.
 
+config MK10
+bool "AMD 61xx/7x50/PhenomX3/X4/II/K10"
+---help---
+  Select this for an AMD 61xx Eight-Core Magny-Cours, Athlon X2 7x50,
+Phenom X3/X4/II, Athlon II X2/X3/X4, or Turion II-family processor.
+  Enables use of some extended instructions, and passes appropriate
+  optimization flags to GCC.
+
+config MBARCELONA
+bool "AMD Barcelona"
+---help---
+  Select this for AMD Barcelona and newer processors.
+
+  Enables -march=barcelona
+
+config MBOBCAT
+bool "AMD Bobcat"
+---help---
+  Select this for AMD Bobcat processors.
+
+  Enables -march=btver1
+
+config MBULLDOZER
+bool "AMD Bulldozer"
+---help---
+  Select this for AMD Bulldozer processors.
+
+  Enables -march=bdver1
+
+config MPILEDRIVER
+bool "AMD Piledriver"
+---help---
+  Select this for AMD Piledriver processors.
+
+  Enables -march=bdver2
+
+config MJAGUAR
+bool "AMD Jaguar"
+---help---
+  Select this for AMD Jaguar processors.
+
+  Enables -march=btver2
+
 config MCRUSOE
 bool "Crusoe"
 depends on X86_32
@@ -251,8 +294,17 @@ config MPSC
   using the cpu family field
   in /proc/cpuinfo. Family 15 is an older Xeon, Family 6 a newer one.
 
+config MATOM
+bool "Intel Atom"
+---help---
+
+  Select this for the Intel Atom platform. Intel Atom CPUs have an
+  in-order pipelining architecture and thus can benefit from
+  accordingly optimized code. Use a recent GCC with specific Atom
+  support in order to fully benefit from 

Re: [PATCH 1/2] gpio: davinci: get rid of DAVINCI_N_GPIO

[Sekhar Nori]

On Friday 29 November 2013 02:03 PM, Linus Walleij wrote:
> On Thu, Nov 21, 2013 at 4:34 PM, Grygorii Strashko
>  wrote:
> 
>> Since Davinci GPIO driver is moved to support gpiolib it has to use
>> ARCH_NR_GPIOS (can be configured using CONFIG_ARCH_NR_GPIO Kconfig
>> option) configuration instead of any mach/platform specific options.
>>
>> Hence, replace private DAVINCI_N_GPIO with common ARCH_NR_GPIOS. This is
>> safe because default value for ARCH_NR_GPIOS=256 and maximum number of
>> supported GPIOs for Davinci is DAVINCI_N_GPIO=144.
>>
>> More over, this is one of steps to re-use Davinci GPIO driver by other
>> mach/platform.
>>
>> Signed-off-by: Grygorii Strashko 
> 
> Acked-by: Linus Walleij 

Added to v3.14/gpio of my k.org tree with Prabhakar's, Santosh's and
your acks.

> 
> Now we have a handful of people patching DaVinci GPIOs...
> 
> Sekhar: can you coordinate the different DaVinci patches? If you want me
> to take a complete set of stuff at the end of the day you can give me a
> pull request for inclusion into the GPIO tree.

Will do.

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

Re: [PATCH v7] gpio: davinci: use {readl|writel}_relaxed() instead of __raw_*

[Sekhar Nori]

On Friday 13 December 2013 09:34 AM, Prabhakar Lad wrote:
> Hi Linus,
> 
> On Fri, Dec 13, 2013 at 2:01 AM, Linus Walleij  
> wrote:
>> On Wed, Dec 11, 2013 at 6:52 PM, Prabhakar Lad
>>  wrote:
>>
>>> From: "Lad, Prabhakar" 
>>>
>>> This patch replaces the __raw_readl/writel with
>>> {readl|writel}_relaxed(), Altough the code runs on ARMv5
>>> based SOCs, changing this will help copying the code

s/copying/using

>>> for other uses.

Call out usability on big-endian machines specifically here.

>>>
>>> Signed-off-by: Lad, Prabhakar 
>>> ---
>>>  This patch is part of series [1] rest of the patches
>>>  are Acked/reviewed so posting this patch independently
>>>  and marking it as v7.
>>>
>>>  [1] http://www.spinics.net/lists/devicetree/msg13037.html
>>>
>>>  drivers/gpio/gpio-davinci.c |   36 ++--
>>
>> Acked-by: Linus Walleij 
>>
> Thanks for the Ack.
> 
>> Should I take this into the GPIO tree, or should it go
>> in through the DaVinci tree?
>>
> To avoid dependencies its better it goes via DaVinci tree.

I added this to v3.14/gpio branch of my tree (with modifications I
mentioned above).

I dont think there are dependencies for this particular patch though
(applies and builds nicely on latest Linus  T's tree). Even then, there
are too many GPIO patches floating around and I think it is better for
me to collect them for a while and if there really are no platform code
dependencies overall, I can probably hand that branch off to Linus W. We
will see.

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

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

[Martin Mares]

Hello!

> It does that per process doing that, and that's the problem for how
> udev works/worked. The binary hwdb is on-disk and can be mmaped, and
> there is no difference between initialization, first, or subsequent
> queries.

OK, point taken.

I see that a mechanism for fast lookup of hardware identification data
is needed. However, why should such a mechanism depend on udev, systemd,
or Linux in general?

What I would really like to have is a universal library for HW lookup,
independent of anything else and widely portable. All the hardware data
would be provided by other packages -- pci.ids, usb.ids, kernel modules,
etc. -- and compiled to a binary format available for instant queries.

Do I miss anything?

Have a nice fortnight
-- 
Martin `MJ' Mares http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A half-joke: What is the difference between a cat?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/7] Input: pmic8xxx-pwrkey - Migrate to regmap APIs

[Dmitry Torokhov]

On Tue, Dec 10, 2013 at 03:43:11PM -0800, Stephen Boyd wrote:
> Use the regmap APIs for this driver instead of custom pm8xxx
> APIs. This breaks this driver's dependency on the pm8xxx APIs and
> allows us to easily port it to other bus protocols in the future.
> 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/input/misc/pmic8xxx-pwrkey.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/input/misc/pmic8xxx-pwrkey.c 
> b/drivers/input/misc/pmic8xxx-pwrkey.c
> index 233b216..a4de105 100644
> --- a/drivers/input/misc/pmic8xxx-pwrkey.c
> +++ b/drivers/input/misc/pmic8xxx-pwrkey.c
> @@ -18,9 +18,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> -#include 
>  #include 
>  
>  #define PON_CNTL_1 0x1C
> @@ -83,7 +83,8 @@ static int pmic8xxx_pwrkey_probe(struct platform_device 
> *pdev)
>   int key_press_irq = platform_get_irq(pdev, 1);
>   int err;
>   unsigned int delay;
> - u8 pon_cntl;
> + unsigned int pon_cntl;
> + struct regmap *regmap;
>   struct pmic8xxx_pwrkey *pwrkey;
>   const struct pm8xxx_pwrkey_platform_data *pdata =
>   dev_get_platdata(>dev);
> @@ -108,6 +109,10 @@ static int pmic8xxx_pwrkey_probe(struct platform_device 
> *pdev)
>   err = -ENOMEM;
>   }
>  
> + regmap = dev_get_regmap(pdev->dev.parent, NULL);
> + if (!regmap)
> + return -ENODEV;

And you are leaking memory here...

> +
>   input_set_capability(pwr, EV_KEY, KEY_POWER);
>  
>   pwr->name = "pmic8xxx_pwrkey";
> @@ -116,7 +121,7 @@ static int pmic8xxx_pwrkey_probe(struct platform_device 
> *pdev)
>   delay = (pdata->kpd_trigger_delay_us << 10) / USEC_PER_SEC;
>   delay = 1 + ilog2(delay);
>  
> - err = pm8xxx_readb(pdev->dev.parent, PON_CNTL_1, _cntl);
> + err = regmap_read(regmap, PON_CNTL_1, _cntl);
>   if (err < 0) {
>   dev_err(>dev, "failed reading PON_CNTL_1 err=%d\n", err);
>   return err;
> @@ -129,7 +134,7 @@ static int pmic8xxx_pwrkey_probe(struct platform_device 
> *pdev)
>   else
>   pon_cntl &= ~PON_CNTL_PULL_UP;
>  
> - err = pm8xxx_writeb(pdev->dev.parent, PON_CNTL_1, pon_cntl);
> + err = regmap_write(regmap, PON_CNTL_1, pon_cntl);
>   if (err < 0) {
>   dev_err(>dev, "failed writing PON_CNTL_1 err=%d\n", err);
>   return err;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 

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

Re: [REGRESSION] rfcomm (userland) broken by commit 29cd718b

[Gianluca Anzolin]

On Fri, Dec 13, 2013 at 12:35:26AM +0100, Alexander Holler wrote:
> Am 12.12.2013 21:36, schrieb Peter Hurley:
> 
> >> What currently happens is that when one kills rfcomm (and any other
> >> terminal which might use that tty), the entry in /dev doesn't
> >> disappear. That means the same call to refcomm with the same device
> >> (e.g. [/dev/]rfcomm1 doesn't work.
> > 
> > Thanks for the report, Alexander.
> > 
> > Point 4 above details a different situation; something else is
> > happening.
> > 
> > Would you please detail the necessary steps to reproduce this regression?
> > (How do you 'kill' rfcomm? etc.  Shell command lines would be best.)
> 
> Just call
> 
> rfcomm connect rfcomm9 01:23:45:67:89:ab
> 
> wait until the connection happened  (a message will appear) and then
> press ctrl-c. This still terminates the bluetooth connection, but the
> device in /dev is now left.

Yes I'm able to reproduce the regression which is indeed caused by that
commit.

However I'm puzzled. Surely there is a fifth case I didn't cover because
when rfcomm_dev_state_change() is called, the tty_port is there but the tty is
not, and therefore I cannot get a reference to it and send the HUP.

I'll let you know when I have something working.

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

Re: [PATCH 1/7] Input: pmic8xxx-pwrkey - Pass input device directly to interrupt

[Dmitry Torokhov]

Hi Stephen,

On Tue, Dec 10, 2013 at 03:43:10PM -0800, Stephen Boyd wrote:
> Instead of passing the pointer to the container structure just
> pass the input device here. This saves a dereference in the fast
> path.
> 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/input/misc/pmic8xxx-pwrkey.c | 22 --
>  1 file changed, 8 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/input/misc/pmic8xxx-pwrkey.c 
> b/drivers/input/misc/pmic8xxx-pwrkey.c
> index ce3c426..233b216 100644
> --- a/drivers/input/misc/pmic8xxx-pwrkey.c
> +++ b/drivers/input/misc/pmic8xxx-pwrkey.c
> @@ -32,26 +32,21 @@
>   * @key_press_irq: key press irq number
>   */
>  struct pmic8xxx_pwrkey {
> - struct input_dev *pwr;

This causes compile errors as you need pwrkey->pwr in remove() to
unregister input device. I'll fix it up.

>   int key_press_irq;
>  };
>  
> -static irqreturn_t pwrkey_press_irq(int irq, void *_pwrkey)
> +static irqreturn_t pwrkey_press_irq(int irq, void *pwr)
>  {
> - struct pmic8xxx_pwrkey *pwrkey = _pwrkey;
> -
> - input_report_key(pwrkey->pwr, KEY_POWER, 1);
> - input_sync(pwrkey->pwr);
> + input_report_key(pwr, KEY_POWER, 1);
> + input_sync(pwr);
>  
>   return IRQ_HANDLED;
>  }
>  
> -static irqreturn_t pwrkey_release_irq(int irq, void *_pwrkey)
> +static irqreturn_t pwrkey_release_irq(int irq, void *pwr)
>  {
> - struct pmic8xxx_pwrkey *pwrkey = _pwrkey;
> -
> - input_report_key(pwrkey->pwr, KEY_POWER, 0);
> - input_sync(pwrkey->pwr);
> + input_report_key(pwr, KEY_POWER, 0);
> + input_sync(pwr);
>  
>   return IRQ_HANDLED;
>  }
> @@ -147,12 +142,11 @@ static int pmic8xxx_pwrkey_probe(struct platform_device 
> *pdev)
>   }
>  
>   pwrkey->key_press_irq = key_press_irq;
> - pwrkey->pwr = pwr;
>  
>   platform_set_drvdata(pdev, pwrkey);
>  
>   err = devm_request_irq(>dev, key_press_irq, pwrkey_press_irq,
> - IRQF_TRIGGER_RISING, "pmic8xxx_pwrkey_press", pwrkey);
> + IRQF_TRIGGER_RISING, "pmic8xxx_pwrkey_press", pwr);
>   if (err < 0) {
>   dev_dbg(>dev, "Can't get %d IRQ for pwrkey: %d\n",
>key_press_irq, err);
> @@ -160,7 +154,7 @@ static int pmic8xxx_pwrkey_probe(struct platform_device 
> *pdev)
>   }
>  
>   err = devm_request_irq(>dev, key_release_irq, pwrkey_release_irq,
> -  IRQF_TRIGGER_RISING, "pmic8xxx_pwrkey_release", pwrkey);
> +  IRQF_TRIGGER_RISING, "pmic8xxx_pwrkey_release", pwr);
>   if (err < 0) {
>   dev_dbg(>dev, "Can't get %d IRQ for pwrkey: %d\n",
>key_release_irq, err);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 

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

Re: [PATCH v6 7/7] jump_label: use defined macros instead of hard-coding for better readability

[Jiang Liu]

On 12/14/2013 12:20 AM, Steven Rostedt wrote:
> On Wed, 11 Dec 2013 00:03:53 +0800
> Jiang Liu  wrote:
> 
>> Use macro JUMP_LABEL_TRUE_BRANCH instead of hard-coding for better
>> readability.
> 
> Looks good, just a little nit. (see below)
> 
>>
>> Signed-off-by: Jiang Liu 
>> ---
>>  include/linux/jump_label.h | 15 ++-
...
>> @@ -123,9 +126,11 @@ extern void static_key_slow_dec(struct static_key *key);
>>  extern void jump_label_apply_nops(struct module *mod);
>>  
>>  #define STATIC_KEY_INIT_TRUE ((struct static_key) \
>> -{ .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
>> +{ .enabled = ATOMIC_INIT(1), \
>> +  .entries = (void *)JUMP_LABEL_TYPE_TRUE_BRANCH })
>>  #define STATIC_KEY_INIT_FALSE ((struct static_key) \
>> -{ .enabled = ATOMIC_INIT(0), .entries = (void *)0 })
>> +{ .enabled = ATOMIC_INIT(0), \
>> +  .entries = (void *)JUMP_LABEL_TYPE_FALSE_BRANCH })
> 
> Can we prettify the backslashes like:
> 
> #define STATIC_KEY_INIT_TRUE ((struct static_key) \
>   { .enabled = ATOMIC_INIT(1),\
> .entries = (void *)JUMP_LABEL_TYPE_TRUE_BRANCH })
> #define STATIC_KEY_INIT_FALSE ((struct static_key)\
>   { .enabled = ATOMIC_INIT(0),\
> .entries = (void *)JUMP_LABEL_TYPE_FALSE_BRANCH })
> 
> 
> Other than that.
> 
> Acked-by: Steven Rostedt 
Thanks Steve.
Will make this change.

> 
> -- Steve
> 
>>  
>>  #else  /* !HAVE_JUMP_LABEL */
>>  
> 

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

Re: [PATCH v6 6/7] arm64, jump label: optimize jump label implementation

[Jiang Liu]

Hi Will,
Thanks for review.
On 12/13/2013 11:41 PM, Will Deacon wrote:
> Hi Jiang Liu,
> 
> Thanks for the updated patches! I still have some small comments, but I
> don't think they will cause you much work. See inline.
> 
> On Tue, Dec 10, 2013 at 04:03:52PM +, Jiang Liu wrote:
>> Optimize jump label implementation for ARM64 by dynamically patching
>> kernel text.
>>
>> Signed-off-by: Jiang Liu 
...
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + */
>> +#ifndef _ASM_ARM64_JUMP_LABEL_H
>> +#define _ASM_ARM64_JUMP_LABEL_H
> 
> Just use __ASM_JUMP_LABEL_H to keep consistent with out other headers.
Sure, will make this change.

> 
>> +#include 
>> +
>> +#ifdef __KERNEL__
>> +
>> +#define JUMP_LABEL_NOP_SIZE 4
> 
> This is the same as AARCH64_INSN_SIZE; just use the latter.
Yes, it's the same as AARCH64_INSN_SIZE but JUMP_LABEL_NOP_SIZE is
needed by the jump label core. So I directly define JUMP_LABEL_NOP_SIZE
as 4 instead of AARCH64_INSN_SIZE to avoid pulling asm/insn.h into
asm/jump_label.h.

Thanks!
Gerry

> 
>> +
>> +static __always_inline bool arch_static_branch(struct static_key *key)
>> +{
>> +asm goto("1: nop\n\t"
>> + ".pushsection __jump_table,  \"aw\"\n\t"
>> + ".align 3\n\t"
>> + ".quad 1b, %l[l_yes], %c0\n\t"
>> + ".popsection\n\t"
>> + :  :  "i"(key) :  : l_yes);
>> +
>> +return false;
>> +l_yes:
>> +return true;
>> +}
>> +
>> +#endif /* __KERNEL__ */
>> +
>> +typedef u64 jump_label_t;
>> +
>> +struct jump_entry {
>> +jump_label_t code;
>> +jump_label_t target;
>> +jump_label_t key;
>> +};
>> +
>> +#endif  /* _ASM_ARM64_JUMP_LABEL_H */
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index cd95a25..e155d56 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -18,6 +18,7 @@ arm64-obj-$(CONFIG_SMP)+= smp.o 
>> smp_spin_table.o
>>  arm64-obj-$(CONFIG_HW_PERF_EVENTS)  += perf_event.o
>>  arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
>>  arm64-obj-$(CONFIG_EARLY_PRINTK)+= early_printk.o
>> +arm64-obj-$(CONFIG_JUMP_LABEL)  += jump_label.o
>>  
>>  obj-y   += $(arm64-obj-y) vdso/
>>  obj-m   += $(arm64-obj-m)
>> diff --git a/arch/arm64/kernel/jump_label.c b/arch/arm64/kernel/jump_label.c
>> new file mode 100644
>> index 000..b13ef62
>> --- /dev/null
>> +++ b/arch/arm64/kernel/jump_label.c
>> @@ -0,0 +1,59 @@
>> +/*
>> + * Copyright (C) 2013 Huawei Ltd.
>> + * Author: Jiang Liu 
>> + *
>> + * Based on arch/arm/kernel/jump_label.c
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#ifdef HAVE_JUMP_LABEL
> 
> Slightly worrying... this should be CONFIG_HAVE_JUMP_LABEL, right? How did
> you manage to test this code?
> 
> Will
> 

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

Re: [PATCH v6 6/7] arm64, jump label: optimize jump label implementation

[Jiang Liu]

On 12/13/2013 11:52 PM, Steven Rostedt wrote:
> On Fri, 13 Dec 2013 10:50:23 -0500
> Steven Rostedt  wrote:
> 
>> On Fri, 13 Dec 2013 15:41:04 +
>> Will Deacon  wrote:
>>
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#ifdef HAVE_JUMP_LABEL
>>>
>>> Slightly worrying... this should be CONFIG_HAVE_JUMP_LABEL, right? How did
>>> you manage to test this code?
>>
>> In  we have:
>>
>> #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
>>
>> [...]
>>
>> # include 
> 
> This also makes the include of  in the C file
> redundant.
> 
> -- Steve
Thanks, Steve.
Will remove the redundant include header file.

> 
>> # define HAVE_JUMP_LABEL
>> #endif   /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
>>
>>
>> -- Steve
> 

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

Re: [PATCH 5/7] genirq: Add devm_request_any_context_irq()

[Dmitry Torokhov]

On Tue, Dec 10, 2013 at 03:43:14PM -0800, Stephen Boyd wrote:
> Some drivers use request_any_context_irq() but there isn't a
> devm_* function for it. Add one so that these drivers don't need
> to explicitly free the irq on driver detach.
> 
> Cc: Thomas Gleixner 

Thomas, would it be OK with me picking this patch through my tree if you
do not have issues with it?

Thanks.

> Signed-off-by: Stephen Boyd 
> ---
>  include/linux/interrupt.h |  5 +
>  kernel/irq/devres.c   | 45 +
>  2 files changed, 50 insertions(+)
> 
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index c9e831d..8334f9b 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -160,6 +160,11 @@ devm_request_irq(struct device *dev, unsigned int irq, 
> irq_handler_t handler,
>devname, dev_id);
>  }
>  
> +extern int __must_check
> +devm_request_any_context_irq(struct device *dev, unsigned int irq,
> +  irq_handler_t handler, unsigned long irqflags,
> +  const char *devname, void *dev_id);
> +
>  extern void devm_free_irq(struct device *dev, unsigned int irq, void 
> *dev_id);
>  
>  /*
> diff --git a/kernel/irq/devres.c b/kernel/irq/devres.c
> index bd8e788..f71e9ff 100644
> --- a/kernel/irq/devres.c
> +++ b/kernel/irq/devres.c
> @@ -73,6 +73,51 @@ int devm_request_threaded_irq(struct device *dev, unsigned 
> int irq,
>  EXPORT_SYMBOL(devm_request_threaded_irq);
>  
>  /**
> + *   devm_request_any_context_irq - allocate an interrupt line for a managed 
> device
> + *   @dev: device to request interrupt for
> + *   @irq: Interrupt line to allocate
> + *   @handler: Function to be called when the IRQ occurs
> + *   @thread_fn: function to be called in a threaded interrupt context. NULL
> + *   for devices which handle everything in @handler
> + *   @irqflags: Interrupt type flags
> + *   @devname: An ascii name for the claiming device
> + *   @dev_id: A cookie passed back to the handler function
> + *
> + *   Except for the extra @dev argument, this function takes the
> + *   same arguments and performs the same function as
> + *   request_any_context_irq().  IRQs requested with this function will be
> + *   automatically freed on driver detach.
> + *
> + *   If an IRQ allocated with this function needs to be freed
> + *   separately, devm_free_irq() must be used.
> + */
> +int devm_request_any_context_irq(struct device *dev, unsigned int irq,
> +   irq_handler_t handler, unsigned long irqflags,
> +   const char *devname, void *dev_id)
> +{
> + struct irq_devres *dr;
> + int rc;
> +
> + dr = devres_alloc(devm_irq_release, sizeof(struct irq_devres),
> +   GFP_KERNEL);
> + if (!dr)
> + return -ENOMEM;
> +
> + rc = request_any_context_irq(irq, handler, irqflags, devname, dev_id);
> + if (rc) {
> + devres_free(dr);
> + return rc;
> + }
> +
> + dr->irq = irq;
> + dr->dev_id = dev_id;
> + devres_add(dev, dr);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(devm_request_any_context_irq);
> +
> +/**
>   *   devm_free_irq - free an interrupt
>   *   @dev: device to free interrupt for
>   *   @irq: Interrupt line to free
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 

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

Re: [PATCH] input: egalax: Send touch end event when is about to suspend

[Dmitry Torokhov]

Hi Felipe,

On Tue, Dec 10, 2013 at 04:03:16PM -0800, Felipe F. Tonello wrote:
> From: "Felipe F. Tonello" 
> 
> This is useful to report for users of this device that don't know anything
> about the suspension of the device. So users will receive a touch end event
> when the device is about to suspend, making it more user friendly.
> 
> One example of users is the X Server with the evdev input driver. This patch
> make sure that the X server will propagate a touch end event to its windows.
> 

Hmm, I would argue we need to do this in input core, similarly to what
we do for the keys, so that all drivers would benefit from the change.

Thanks.

> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/input/touchscreen/egalax_ts.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/egalax_ts.c 
> b/drivers/input/touchscreen/egalax_ts.c
> index 054d225..1f21f0d 100644
> --- a/drivers/input/touchscreen/egalax_ts.c
> +++ b/drivers/input/touchscreen/egalax_ts.c
> @@ -63,6 +63,7 @@
>  struct egalax_ts {
>   struct i2c_client   *client;
>   struct input_dev*input_dev;
> + boolids_in_use[MAX_SUPPORT_POINTS];
>  };
>  
>  static irqreturn_t egalax_ts_interrupt(int irq, void *dev_id)
> @@ -117,6 +118,8 @@ static irqreturn_t egalax_ts_interrupt(int irq, void 
> *dev_id)
>   input_mt_report_pointer_emulation(input_dev, true);
>   input_sync(input_dev);
>  
> + ts->ids_in_use[id] = down;
> +
>   return IRQ_HANDLED;
>  }
>  
> @@ -247,9 +250,22 @@ static int egalax_ts_suspend(struct device *dev)
>   0x3, 0x6, 0xa, 0x3, 0x36, 0x3f, 0x2, 0, 0, 0
>   };
>   struct i2c_client *client = to_i2c_client(dev);
> - int ret;
> + struct egalax_ts *ts = i2c_get_clientdata(client);
> + int ret, id;
>  
>   ret = i2c_master_send(client, suspend_cmd, MAX_I2C_DATA_LEN);
> +
> + /* We send a touch end event (for the ids in use) if the egalax module 
> is
> +about to be turned off. */
> + for (id = 0; id < MAX_SUPPORT_POINTS; ++id) {
> + if (ts->ids_in_use[id]) {
> + input_mt_slot(ts->input_dev, id);
> + input_mt_report_slot_state(ts->input_dev, 
> MT_TOOL_FINGER, false);
> + input_mt_report_pointer_emulation(ts->input_dev, true);
> + input_sync(ts->input_dev);
> + }
> + }
> +
>   return ret > 0 ? 0 : ret;
>  }
>  
> -- 
> 1.8.3.1
> 

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

Re: [PATCH 10/10] Kconfig: cleanup SERIO_I8042 dependencies

[Dmitry Torokhov]

On Sat, Dec 14, 2013 at 10:32:31AM -0800, H. Peter Anvin wrote:
> On 12/14/2013 08:59 AM, Mark Salter wrote:
> > Remove messy dependencies from SERIO_I8042 by having it depend on one
> > Kconfig symbol (ARCH_MIGHT_HAVE_PC_SERIO) and having architectures
> > which need it select ARCH_MIGHT_HAVE_PC_SERIO in arch/*/Kconfig.
> > New architectures are unlikely to need SERIO_I8042, so this avoids
> > having an ever growing list of architectures to exclude.
> > 
> > Signed-off-by: Mark Salter 
> > CC: Dmitry Torokhov 
> > CC: Richard Henderson 
> > CC: linux-al...@vger.kernel.org
> > CC: Russell King 
> > CC: linux-arm-ker...@lists.infradead.org
> > CC: Tony Luck 
> > CC: Fenghua Yu 
> > CC: linux-i...@vger.kernel.org
> > CC: Ralf Baechle 
> > CC: linux-m...@linux-mips.org
> > CC: Benjamin Herrenschmidt 
> > CC: Paul Mackerras 
> > CC: linuxppc-...@lists.ozlabs.org
> > CC: Paul Mundt 
> > CC: linux...@vger.kernel.org
> > CC: "David S. Miller" 
> > CC: sparcli...@vger.kernel.org
> > CC: Guan Xuetao 
> > CC: Ingo Molnar 
> > CC: Thomas Gleixner 
> > CC: "H. Peter Anvin" 
> > CC: x...@kernel.org
> 
> Acked-by: H. Peter Anvin 

How are we going to merge this? In bulk through input tree or peacemeal
through all arches first?

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

Re: [PATCH] drivers: input: Include appropriate header file in cyttsp_i2c_common.c

[Dmitry Torokhov]

On Sat, Dec 14, 2013 at 12:57:52PM -0800, Josh Triplett wrote:
> On Sat, Dec 14, 2013 at 07:08:22PM +0530, Rashika Kheria wrote:
> > This patch includes appropriate header file cyttsp4_core.h in
> > touchscreen/cyttsp_i2c_common.c because functions
> > cyttsp_i2c_read_block_data() and cyttsp_i2c_write_block_data()
> > have their prototype declaration in cyttsp4_core.h.
> > 
> > Thus, it also eliminates the following warning in cyttsp_i2c_common.c:
> > drivers/input/touchscreen/cyttsp_i2c_common.c:34:5: warning: no previous 
> > prototype for ‘cyttsp_i2c_read_block_data’ [-Wmissing-prototypes]
> > drivers/input/touchscreen/cyttsp_i2c_common.c:64:5: warning: no previous 
> > prototype for ‘cyttsp_i2c_write_block_data’ [-Wmissing-prototypes]
> > 
> > 
> > Signed-off-by: Rashika Kheria 
> 
> Reviewed-by: Josh Triplett 

Applied, thank you.

> 
> >  drivers/input/touchscreen/cyttsp_i2c_common.c |2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/input/touchscreen/cyttsp_i2c_common.c 
> > b/drivers/input/touchscreen/cyttsp_i2c_common.c
> > index 1d7b6f1..ccefa56 100644
> > --- a/drivers/input/touchscreen/cyttsp_i2c_common.c
> > +++ b/drivers/input/touchscreen/cyttsp_i2c_common.c
> > @@ -31,6 +31,8 @@
> >  #include 
> >  #include 
> >  
> > +#include "cyttsp4_core.h"
> > +
> >  int cyttsp_i2c_read_block_data(struct device *dev, u8 *xfer_buf,
> >   u16 addr, u8 length, void *values)
> >  {
> > -- 
> > 1.7.9.5
> > 

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

[PATCH 1/3] leds: add support for LSI Zevio LED controller

[dt . tangr]

From: Daniel Tang 

This adds initial support for the LED controller found on the LSI Zevio SoC.

Signed-off-by: Daniel Tang 
---
 drivers/leds/Kconfig  |7 ++
 drivers/leds/Makefile |1 +
 drivers/leds/leds-zevio.c |  168 +
 3 files changed, 176 insertions(+)
 create mode 100644 drivers/leds/leds-zevio.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 72156c1..ec8b565 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -487,6 +487,13 @@ config LEDS_BLINKM
  This option enables support for the BlinkM RGB LED connected
  through I2C. Say Y to enable support for the BlinkM LED.
 
+config LEDS_ZEVIO
+   tristate "LED support for LSI Zevio LED controller"
+   depends on LEDS_CLASS
+   help
+ This option enables support for the LSI Zevio LED controller.
+ Say Y to enable support for the LSI Zevio LED controller.
+
 comment "LED Triggers"
 source "drivers/leds/trigger/Kconfig"
 
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 3cd76db..85c4b54 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_LEDS_ASIC3)  += leds-asic3.o
 obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
 obj-$(CONFIG_LEDS_LM355x)  += leds-lm355x.o
 obj-$(CONFIG_LEDS_BLINKM)  += leds-blinkm.o
+obj-$(CONFIG_LEDS_ZEVIO)   += leds-zevio.o
 
 # LED SPI Drivers
 obj-$(CONFIG_LEDS_DAC124S085)  += leds-dac124s085.o
diff --git a/drivers/leds/leds-zevio.c b/drivers/leds/leds-zevio.c
new file mode 100644
index 000..017ebf0
--- /dev/null
+++ b/drivers/leds/leds-zevio.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2013 Daniel Tang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LED_CONTROL0x00
+
+#define LED_GREEN  (1 << 4)
+#define LED_RED(1 << 5)
+
+struct zevio_led {
+   void __iomem *base;
+
+   struct led_classdev zevio_red_led;
+   struct led_classdev zevio_green_led;
+
+   spinlock_t lock;
+};
+
+static void zevio_led_set(struct zevio_led *priv, unsigned long mask)
+{
+   u32 reg;
+
+   spin_lock(>lock);
+
+   reg = readl(priv->base + LED_CONTROL);
+   writel(reg | mask, priv->base + LED_CONTROL);
+
+   spin_unlock(>lock);
+}
+
+static void zevio_led_clr(struct zevio_led *priv, unsigned long mask)
+{
+   u32 reg;
+
+   spin_lock(>lock);
+
+   reg = readl(priv->base + LED_CONTROL);
+   writel(reg & ~mask, priv->base + LED_CONTROL);
+
+   spin_unlock(>lock);
+}
+
+static void zevio_red_set(struct led_classdev *led_cdev,
+  enum led_brightness brightness)
+{
+   struct zevio_led *priv = container_of(led_cdev, struct zevio_led,
+  zevio_red_led);
+
+   if (brightness == 0)
+   zevio_led_clr(priv, LED_RED);
+   else
+   zevio_led_set(priv, LED_RED);
+}
+
+static void zevio_green_set(struct led_classdev *led_cdev,
+enum led_brightness brightness)
+{
+   struct zevio_led *priv = container_of(led_cdev, struct zevio_led,
+  zevio_green_led);
+
+   if (brightness == 0)
+   zevio_led_clr(priv, LED_GREEN);
+   else
+   zevio_led_set(priv, LED_GREEN);
+}
+
+static int zevio_led_probe(struct platform_device *pdev)
+{
+   struct device_node *of_node = pdev->dev.of_node;
+   struct zevio_led *priv;
+   int ret;
+   u32 reg;
+
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   priv->base = of_iomap(of_node, 0);
+   if (!priv->base)
+   return -EINVAL;
+
+   spin_lock_init(>lock);
+
+   reg = readl(priv->base + LED_CONTROL);
+   writel(~reg, priv->base + LED_CONTROL);
+   if (readl(priv->base + LED_CONTROL) == reg) {
+   dev_warn(>dev, "led registers appear to be read-only");
+   }
+
+   writel(0, priv->base + LED_CONTROL);
+
+   priv->zevio_red_led.name= "zevio::red_led";
+   priv->zevio_red_led.default_trigger = "default-on",
+   priv->zevio_red_led.max_brightness  = 1;
+   priv->zevio_red_led.brightness_set  = zevio_red_set;
+   priv->zevio_red_led.flags   = LED_CORE_SUSPENDRESUME;
+
+   priv->zevio_green_led.name  = "zevio::green_led";
+   priv->zevio_green_led.default_trigger   = "default-on",
+   priv->zevio_green_led.max_brightness= 1;
+   priv->zevio_green_led.brightness_set= zevio_green_set;
+   priv->zevio_green_led.flags 

[PATCH 2/3] arm: nspire: modify device tree to use the LSI Zevio LED driver

[dt . tangr]

From: Daniel Tang 


Signed-off-by: Daniel Tang 
---
 arch/arm/boot/dts/nspire.dtsi |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
index a22ffe6..bb453bb 100644
--- a/arch/arm/boot/dts/nspire.dtsi
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -167,8 +167,9 @@
reg = <0x900F 0x1000>;
};
 
-   led: led@9011 {
-   reg = <0x9011 0x1000>;
+   led: led@90110B00 {
+   compatible = "lsi,zevio-led";
+   reg = <0x90110B00 0x100>;
};
};
};
-- 
1.7.10.4

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

[PATCH 3/3] devicetree: bindings: document lsi,zevio-led

[dt . tangr]

From: Daniel Tang 

This describes the device tree bindings for the LSI Zevio LED Controller

Signed-off-by: Daniel Tang 
---
 Documentation/devicetree/bindings/leds/leds-zevio.txt |   13 +
 1 file changed, 13 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-zevio.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-zevio.txt 
b/Documentation/devicetree/bindings/leds/leds-zevio.txt
new file mode 100644
index 000..44b0d87
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-zevio.txt
@@ -0,0 +1,13 @@
+LSI Zevio LED controller
+
+Required properties:
+ - compatible : should be "lsi,zevio-led".
+
+Examples:
+
+led {
+   compatible = "lsi,zevio-led";
+   reg = <0x90110B00 0x100>;
+};
+
+
-- 
1.7.10.4

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

Re: [PATCH] regmap: irq: Allow using zero value for ack_base

[Alexander Shiyan]

> On 12/15/2013 10:36 AM, Alexander Shiyan wrote:
> > In some cases, clear interrupt register may be at address 0.
> > This patch allows to use such configurations by adding additional
> > configuration bit to indicate this.
> > 
> > Signed-off-by: Alexander Shiyan 
> > ---
> >  drivers/base/regmap/regmap-irq.c | 6 +++---
> >  include/linux/regmap.h   | 5 -
> >  2 files changed, 7 insertions(+), 4 deletions(-)
...
> > diff --git a/include/linux/regmap.h b/include/linux/regmap.h
> > index e559078..3a36f61 100644
> > --- a/include/linux/regmap.h
> > +++ b/include/linux/regmap.h
...
> > @@ -520,6 +522,7 @@ struct regmap_irq_chip {
> > unsigned int irq_reg_stride;
> > bool init_ack_masked:1;
> > bool mask_invert:1;
> > +   bool use_ack:1;
> I think this will break something. Better use 0 as default value.
> Reason I think so, is because in the above code you effectively add a new
> possibility for most code to run.

This is not a default value but bit-size of this field.

---

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

[Kay Sievers]

On Sun, Dec 15, 2013 at 10:18 AM, Martin Mares  wrote:
> Hello Kay,
>
>> Libpci and its linear search through megabytes of text files for evey
>> new query is too inefficient, that we cannot afford to use it during
>> early bootup. It was the largest hit left in bootup profiling on
>> machines booting userspace in the sub-1-second range on common
>> machines. It was probably never meant to provide efficient queries,
>> but it's the reason we can never use it during early boot.
>
> I do not know what you are speaking about -- libpci definitely does
> not perform linear scans on pci.ids. It builds a hash table from pci.ids
> on the first query and and all subsequent queries are O(1) on average.

It does that per process doing that, and that's the problem for how
udev works/worked. The binary hwdb is on-disk and can be mmaped, and
there is no difference between initialization, first, or subsequent
queries.

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

Re: [PATCH] regmap: irq: Allow using zero value for ack_base

[Levente Kurusa]

On 12/15/2013 10:36 AM, Alexander Shiyan wrote:
> In some cases, clear interrupt register may be at address 0.
> This patch allows to use such configurations by adding additional
> configuration bit to indicate this.
> 
> Signed-off-by: Alexander Shiyan 
> ---
>  drivers/base/regmap/regmap-irq.c | 6 +++---
>  include/linux/regmap.h   | 5 -
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/base/regmap/regmap-irq.c 
> b/drivers/base/regmap/regmap-irq.c
> index 763c60d..8269206 100644
> --- a/drivers/base/regmap/regmap-irq.c
> +++ b/drivers/base/regmap/regmap-irq.c
> @@ -113,7 +113,7 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
>* OR if there is masked interrupt which hasn't been Acked,
>* it'll be ignored in irq handler, then may introduce irq storm
>*/
> - if (d->mask_buf[i] && d->chip->ack_base) {
> + if (d->mask_buf[i] && (d->chip->ack_base || d->chip->use_ack)) {
>   reg = d->chip->ack_base +
>   (i * map->reg_stride * d->irq_reg_stride);
>   ret = regmap_write(map, reg, d->mask_buf[i]);
> @@ -271,7 +271,7 @@ static irqreturn_t regmap_irq_thread(int irq, void *d)
>   for (i = 0; i < data->chip->num_regs; i++) {
>   data->status_buf[i] &= ~data->mask_buf[i];
>  
> - if (data->status_buf[i] && chip->ack_base) {
> + if (data->status_buf[i] && (chip->ack_base || chip->use_ack)) {
>   reg = chip->ack_base +
>   (i * map->reg_stride * data->irq_reg_stride);
>   ret = regmap_write(map, reg, data->status_buf[i]);
> @@ -448,7 +448,7 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int 
> irq_flags,
>   goto err_alloc;
>   }
>  
> - if (d->status_buf[i] && chip->ack_base) {
> + if (d->status_buf[i] && (chip->ack_base || chip->use_ack)) {
>   reg = chip->ack_base +
>   (i * map->reg_stride * d->irq_reg_stride);
>   ret = regmap_write(map, reg,
> diff --git a/include/linux/regmap.h b/include/linux/regmap.h
> index e559078..3a36f61 100644
> --- a/include/linux/regmap.h
> +++ b/include/linux/regmap.h
> @@ -497,11 +497,13 @@ struct regmap_irq {
>   *
>   * @status_base: Base status register address.
>   * @mask_base:   Base mask register address.
> - * @ack_base:Base ack address.  If zero then the chip is clear on read.
> + * @ack_base:Base ack address. If zero then the chip is clear on read.
> + *   Using zero value is possible with @use_ack bit.
>   * @wake_base:   Base address for wake enables.  If zero unsupported.
>   * @irq_reg_stride:  Stride to use for chips where registers are not 
> contiguous.
>   * @init_ack_masked: Ack all masked interrupts once during initalization.

Oh a typo!  'initalization' should be 'initialization'
>   * @mask_invert: Inverted mask register: cleared bits are masked out.
> + * @use_ack: Use @ack register even it zero.
'even it zero' should be 'even if it is zero'


>   * @wake_invert: Inverted wake register: cleared bits are wake enabled.
>   * @runtime_pm:  Hold a runtime PM lock on the device when accessing it.
>   *
> @@ -520,6 +522,7 @@ struct regmap_irq_chip {
>   unsigned int irq_reg_stride;
>   bool init_ack_masked:1;
>   bool mask_invert:1;
> + bool use_ack:1;
I think this will break something. Better use 0 as default value.
Reason I think so, is because in the above code you effectively add a new
possibility for most code to run.

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

[PATCH] regmap: irq: Allow using zero value for ack_base

[Alexander Shiyan]

In some cases, clear interrupt register may be at address 0.
This patch allows to use such configurations by adding additional
configuration bit to indicate this.

Signed-off-by: Alexander Shiyan 
---
 drivers/base/regmap/regmap-irq.c | 6 +++---
 include/linux/regmap.h   | 5 -
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 763c60d..8269206 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -113,7 +113,7 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
 * OR if there is masked interrupt which hasn't been Acked,
 * it'll be ignored in irq handler, then may introduce irq storm
 */
-   if (d->mask_buf[i] && d->chip->ack_base) {
+   if (d->mask_buf[i] && (d->chip->ack_base || d->chip->use_ack)) {
reg = d->chip->ack_base +
(i * map->reg_stride * d->irq_reg_stride);
ret = regmap_write(map, reg, d->mask_buf[i]);
@@ -271,7 +271,7 @@ static irqreturn_t regmap_irq_thread(int irq, void *d)
for (i = 0; i < data->chip->num_regs; i++) {
data->status_buf[i] &= ~data->mask_buf[i];
 
-   if (data->status_buf[i] && chip->ack_base) {
+   if (data->status_buf[i] && (chip->ack_base || chip->use_ack)) {
reg = chip->ack_base +
(i * map->reg_stride * data->irq_reg_stride);
ret = regmap_write(map, reg, data->status_buf[i]);
@@ -448,7 +448,7 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int 
irq_flags,
goto err_alloc;
}
 
-   if (d->status_buf[i] && chip->ack_base) {
+   if (d->status_buf[i] && (chip->ack_base || chip->use_ack)) {
reg = chip->ack_base +
(i * map->reg_stride * d->irq_reg_stride);
ret = regmap_write(map, reg,
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index e559078..3a36f61 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -497,11 +497,13 @@ struct regmap_irq {
  *
  * @status_base: Base status register address.
  * @mask_base:   Base mask register address.
- * @ack_base:Base ack address.  If zero then the chip is clear on read.
+ * @ack_base:Base ack address. If zero then the chip is clear on read.
+ *   Using zero value is possible with @use_ack bit.
  * @wake_base:   Base address for wake enables.  If zero unsupported.
  * @irq_reg_stride:  Stride to use for chips where registers are not 
contiguous.
  * @init_ack_masked: Ack all masked interrupts once during initalization.
  * @mask_invert: Inverted mask register: cleared bits are masked out.
+ * @use_ack: Use @ack register even it zero.
  * @wake_invert: Inverted wake register: cleared bits are wake enabled.
  * @runtime_pm:  Hold a runtime PM lock on the device when accessing it.
  *
@@ -520,6 +522,7 @@ struct regmap_irq_chip {
unsigned int irq_reg_stride;
bool init_ack_masked:1;
bool mask_invert:1;
+   bool use_ack:1;
bool wake_invert:1;
bool runtime_pm:1;
 
-- 
1.8.3.2

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

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

[Martin Mares]

Hello Kay,

> Libpci and its linear search through megabytes of text files for evey
> new query is too inefficient, that we cannot afford to use it during
> early bootup. It was the largest hit left in bootup profiling on
> machines booting userspace in the sub-1-second range on common
> machines. It was probably never meant to provide efficient queries,
> but it's the reason we can never use it during early boot.

I do not know what you are speaking about -- libpci definitely does
not perform linear scans on pci.ids. It builds a hash table from pci.ids
on the first query and and all subsequent queries are O(1) on average.

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

Re: Replace /dev/random input mix polynomial with Brent's xorgen?

[George Spelvin]

> Agreed, but that's we have the input_rotate.  Do you have analysis or
> arguments why we Richard Brent's construction would do a better job?
> 
> BTW, one other design requirement I had when desining the mixing
> function was if you fix in all zero's, the result was a reversible
> mixing of the bits; in other words, "dd if=/dev/zero of=/dev/random"
> is guaranteed to not lose any entropy caused by self-cancellation.

To address your second paragraph first: both the existing and Brent's
construction are linear feedback shift registers.  The only difference
is the polynomial.

Becuase it's a bijective function (a permutation), the input of any
fixed string to the pool is an invertible operation, and therefore cannot
lose entropy.  I agree that this property is essential, and it remains.

The difference is that currently the mxing is done using a word-wise
polynomial, followed by some ad-hoc bit mixing within the word using
the twist table.  Brent's design is more integrated and mixes all the
bits in a uniform manner.

It is, however, a relatively minor tweak, nothing fundamental.

> I'm not convinced we need to worry about cache timing attacks, since
> they typically involve a chosen plaintext attack and a fixed key ---
> and the attacker isn't going to know what we are going to be
> encrypting, let alone be able to chose the plaintext.

You're describing standard key-recovery attacks.  For /dev/random,
just knowing the *ciphertext* constitutes a successful attack.

In fact, even partial (a few bits of) knowledge about the ciphertext is
a violation of the intended security guarantee.

I haven't gone through a full analysis, but there are plenty of functions
available with fixed access patterns and timing, where the issue simply
Goes Away.  Why not use one?

> Even if that were not the case, see the paper, "Are AES x86 Cache Timing
> Attacks Still Feasible?":
>
>   http://cseweb.ucsd.edu/~hovav/dist/aes_cache.pdf

The paper's first point, that hardware support makes all this moot, is
of course true, and I agree it's difficult, but the rest is addressing
x86 running a web browser!

What about all the all the small routers, Raspberry Pis and the like
generating lots of session keys without a lot of UI code bloat?
And with simpler cache structures without hardware prefetchers and
other confounding factors.

And it seems to be making the point that a per-core L1 means that you
have to probe the L2.  But hyperthreading means that you can have
an attacking thread sharing L1 with the encryption.


The exact hash function is not critical, but it seems that there are
secure alternatives that are faster (Rijndael's key schedule is simple,
but when used as a hash, rekeying per block needs to be included), don't
need lookup tables (smaller minimum kernel!), and have fixed timing so I
don't need to even think about whether a cache timing attack is practical.

If hardware AES support changes those factors, then by all means use AES.
I just think the combination of all three factors militate against AES for
the standard software fallback.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/10] alpha: select ARCH_MIGHT_HAVE_PC_SERIO

[Matt Turner]

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

[PATCH] drivers: ptp: Include new header file in ptp_pch.c

[Rashika Kheria]

Create a new header file include/linux/ptp_pch.h which contains
prototype declaration of functions pch_ch_control_read(),
pch_ch_control_write(), pch_ch_event_read(), pch_ch_event_write(),
pch_src_uuid_lo_read(), pch_src_uuid_hi_read(), pch_rx_snap_read(),
pch_tx_snap_read() and pch_set_station_address().

Include the new header file in drivers/ptp/ptp_pch.c and
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c because they
use these functions. Remove these functions prototypes from header
file drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h.

This eliminates the following warnings in ptp_pch.c:

drivers/ptp/ptp_pch.c:194:5: warning: no previous prototype for 
‘pch_ch_control_read’ [-Wmissing-prototypes]
drivers/ptp/ptp_pch.c:205:6: warning: no previous prototype for 
‘pch_ch_control_write’ [-Wmissing-prototypes]
drivers/ptp/ptp_pch.c:213:5: warning: no previous prototype for 
‘pch_ch_event_read’ [-Wmissing-prototypes]
drivers/ptp/ptp_pch.c:224:6: warning: no previous prototype for 
‘pch_ch_event_write’ [-Wmissing-prototypes]
drivers/ptp/ptp_pch.c:232:5: warning: no previous prototype for 
‘pch_src_uuid_lo_read’ [-Wmissing-prototypes]
drivers/ptp/ptp_pch.c:243:5: warning: no previous prototype for 
‘pch_src_uuid_hi_read’ [-Wmissing-prototypes]
drivers/ptp/ptp_pch.c:254:5: warning: no previous prototype for 
‘pch_rx_snap_read’ [-Wmissing-prototypes]
drivers/ptp/ptp_pch.c:271:5: warning: no previous prototype for 
‘pch_tx_snap_read’ [-Wmissing-prototypes]
drivers/ptp/ptp_pch.c:312:5: warning: no previous prototype for 
‘pch_set_station_address’ [-Wmissing-prototypes]

Signed-off-by: Rashika Kheria rashika.khe...@gmail.com
---
 drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h|9 -
 .../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c   |1 +
 drivers/ptp/ptp_pch.c  |1 +
 include/linux/ptp_pch.h|   16 
 4 files changed, 18 insertions(+), 9 deletions(-)
 create mode 100644 include/linux/ptp_pch.h

diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h 
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
index 2a900307..79533c8 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
@@ -666,15 +666,6 @@ void pch_gbe_free_tx_resources(struct pch_gbe_adapter 
*adapter,
 void pch_gbe_free_rx_resources(struct pch_gbe_adapter *adapter,
   struct pch_gbe_rx_ring *rx_ring);
 void pch_gbe_update_stats(struct pch_gbe_adapter *adapter);
-u32 pch_ch_control_read(struct pci_dev *pdev);
-void pch_ch_control_write(struct pci_dev *pdev, u32 val);
-u32 pch_ch_event_read(struct pci_dev *pdev);
-void pch_ch_event_write(struct pci_dev *pdev, u32 val);
-u32 pch_src_uuid_lo_read(struct pci_dev *pdev);
-u32 pch_src_uuid_hi_read(struct pci_dev *pdev);
-u64 pch_rx_snap_read(struct pci_dev *pdev);
-u64 pch_tx_snap_read(struct pci_dev *pdev);
-int pch_set_station_address(u8 *addr, struct pci_dev *pdev);
 
 /* pch_gbe_param.c */
 void pch_gbe_check_options(struct pch_gbe_adapter *adapter);
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c 
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 27ffe0e..03e2c14 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -24,6 +24,7 @@
 #include linux/net_tstamp.h
 #include linux/ptp_classify.h
 #include linux/gpio.h
+#include linux/ptp_pch.h
 
 #define DRV_VERSION 1.01
 const char pch_driver_version[] = DRV_VERSION;
diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
index 71a2559..ec5cf7d 100644
--- a/drivers/ptp/ptp_pch.c
+++ b/drivers/ptp/ptp_pch.c
@@ -20,6 +20,7 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307, USA.
  */
 
+#include linux/ptp_pch.h
 #include linux/device.h
 #include linux/err.h
 #include linux/init.h
diff --git a/include/linux/ptp_pch.h b/include/linux/ptp_pch.h
new file mode 100644
index 000..bd23d53
--- /dev/null
+++ b/include/linux/ptp_pch.h
@@ -0,0 +1,16 @@
+#include linux/types.h
+#include linux/pci.h
+
+/* Function prototype declaration common between
+ * drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c and
+ * drivers/ptp/ptp_pch.c.*/
+
+u32 pch_ch_control_read(struct pci_dev *pdev);
+void pch_ch_control_write(struct pci_dev *pdev, u32 val);
+u32 pch_ch_event_read(struct pci_dev *pdev);
+void pch_ch_event_write(struct pci_dev *pdev, u32 val);
+u32 pch_src_uuid_lo_read(struct pci_dev *pdev);
+u32 pch_src_uuid_hi_read(struct pci_dev *pdev);
+u64 pch_rx_snap_read(struct pci_dev *pdev);
+u64 pch_tx_snap_read(struct pci_dev *pdev);
+int pch_set_station_address(u8 *addr, struct pci_dev *pdev);
-- 
1.7.9.5

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

Linux 3.13-rc4

[Linus Torvalds]

So I delayed this a couple of days to get back to my normal Sunday
release schedule, but I'm not entirely happy with the result. Things
aren't calming down the way they should be, and -rc4 is bigger than
previous rc's. And I don't think I can just blame the two extra days.

Anyway, what that means from a practical standpoint is that I'm going
to be *very* grumpy at anybody who sends me unnecessary crap. If it's
not  regression or marked for stable, then just don't send it to me.
Because you *will* be called names if you can't follow those simple
rules. Comprende?

Anyway, the bulk of changes for rc4 is drivers (notably networking and
gpu, but there's usb, input and media driver updates too). Aside from
that, there are the usual arch updates (mainly ARM) and the slightly
less usual selinux updates.  And generic networking, with some random
stuff thrown in for good measure. The shortlog isn't very short, but
it's appended for your reading pleasure.

We're obviously heading for the holiday season, and I'm really hoping
that will help calm things down too for the rest of the release
candidates...

  Linus

---

Aaro Koskinen (1):
  usb: phy-generic: fix nop xceiv probe

Alan Cox (2):
  sc1200_wdt: Fix oops
  drivers/char/i8k.c: add Dell XPLS L421X

Alan Stern (1):
  usb: dwc3: fix implementation of endpoint wedge

Alex Deucher (6):
  drm/radeon: fix typo in fetching mpll params
  drm/radeon: program DCE2 audio dto just like DCE3
  drm/radeon/dpm: simplify state adjust logic for NI
  drm/radeon: fixup bad vram size on SI
  drm/radeon: fix null pointer dereference in dce6+ audio code
  drm/radeon/atom: fix bus probes when hw_i2c is set (v2)

Alexander Bondar (1):
  iwlwifi: pcie: stop sending commands to dead firmware

Alexander Duyck (1):
  PCI: Avoid unnecessary CPU switch when calling driver .probe() method

Alexandre Demers (1):
  drm/radeon: Fix a typo in Cayman and Evergreen registers

Alexandre Rames (1):
  sfc: Stop/re-start PTP when stopping/starting the datapath.

Alexey Khoroshilov (1):
  [media] dvb_demux: fix deadlock in dmx_section_feed_release_filter()

Anatolij Gustschin (1):
  powerpc/52xx: Re-enable bestcomm driver in defconfigs

Andrew Liu (1):
  Input: keyboard - keycode  KEY_MAX changes some keycode values

Andrew Rybchenko (1):
  sfc: RX buffer allocation takes prefix size into account in IP
header alignment

Andrey Vagin (2):
  virtio-net: determine type of bufs correctly
  virtio: delete napi structures from netdev before releasing memory

Andrzej Pietrasiewicz (1):
  usb: gadget: f_mass_storage: fix mass storage dependency

Andy Honig (3):
  KVM: Improve create VCPU parameter (CVE-2013-4587)
  KVM: x86: Fix potential divide by 0 in lapic (CVE-2013-6367)
  KVM: x86: Convert vapic synchronization to _cached functions
(CVE-2013-6368)

Anssi Hannula (1):
  ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devices

Antti Palosaari (4):
  [media] af9035: add [0413:6a05] Leadtek WinFast DTV Dongle Dual
  [media] af9035: fix broken I2C and USB I/O
  [media] af9033: fix broken I2C
  [media] rtl2830: add parent for I2C adapter

Apelete Seketeli (1):
  usb: fix musb gadget to enable OTG mode conditionally

Arend van Spriel (1):
  brcmfmac: fix uninitialized warning

Aristeu Rozanski (1):
  sb_edac: Shut up compiler warning when EDAC_DEBUG is enabled

Ashutosh Dixit (4):
  misc: mic: Bug fix for sysfs poll usage.
  misc: mic: Fix user space namespace pollution from mic_common.h.
  misc: mic: Fix endianness issues.
  misc: mic: Suppress memory space sparse warnings

Axel Lin (2):
  regulator: pfuze100: Fix address of FABID
  include/linux/kernel.h: make might_fault() a nop for !MMU

Ben Hutchings (4):
  HID: kye: Fix missing break in kye_report_fixup()
  sfc: Add length checks to efx_xmit_with_hwtstamp() and efx_ptp_is_ptp_tx()
  sfc: Rate-limit log message for PTP packets without a matching
timestamp event
  sfc: Maintain current frequency adjustment when applying a time offset

Ben Skeggs (3):
  drm/nv04-nv30/clk: provide an empty domain list
  drm/nouveau: unreference fence after syncing
  drm/nouveau/sw: fix oops if gpu has its display block disabled

Bjorn Helgaas (2):
  Revert workqueue: allow work_on_cpu() to be called recursively
  MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers

Bob Copeland (1):
  Revert mac80211: allow disable power save in mesh

Borislav Petkov (1):
  brcmsmac: Fix build dep on LEDS_CLASS

Brian Carnes (1):
  hwmon: (w83l786ng) Fix fan speed control mode setting and reporting

Carolyn Wyborny (1):
  igb: Fix for issue where values could be too high for udelay function.

Catalin Marinas (1):
  arm64: Fix memory shareability attribute for ioremap_wc/cache

Cedric Le Goater (2):
  offb: Little endian fixes
  

[PATCH 2/3] SubmittingPatches: Add recommendation for mailing list references

[Josh Triplett]

SubmittingPatches already mentions referencing bugs fixed by a commit,
but doesn't mention citing relevant mailing list discussions.  Add a
note to that effect, along with a recommendation to use the
https://lkml.kernel.org/ redirector.

Portions based on text from git's SubmittingPatches.

Signed-off-by: Josh Triplett j...@joshtriplett.org
---
 Documentation/SubmittingPatches | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c74e73c..53e6590 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -112,7 +112,15 @@ to do frotz, as if you are giving orders to the codebase 
to change
 its behaviour.
 
 If the patch fixes a logged bug entry, refer to that bug entry by
-number and URL.
+number and URL.  If the patch follows from a mailing list discussion,
+give a URL to the mailing list archive; use the https://lkml.kernel.org/
+redirector with a Message-Id, to ensure that the links cannot become
+stale.
+
+However, try to make your explanation understandable without external
+resources.  In addition to giving a URL to a mailing list archive or
+bug, summarize the relevant points of the discussion that led to the
+patch as submitted.
 
 If you want to refer to a specific commit, don't just refer to the
 SHA-1 ID of the commit. Please also include the oneline summary of
-- 
1.8.5.1

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

[PATCH 3/3] SubmittingPatches: Document the use of git

[Josh Triplett]

Most of the mechanical portions of SubmittingPatches exist to help patch
submitters replicate the output of git.  Mention this explicitly, both
as a reminder that git will help with this process, and as signposting to
let git users know what they can safely skip.

Signed-off-by: Josh Triplett j...@joshtriplett.org
---
 Documentation/SubmittingPatches | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 53e6590..fdad7d1 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -14,7 +14,10 @@ Read Documentation/SubmitChecklist for a list of items to 
check
 before submitting code.  If you are submitting a driver, also read
 Documentation/SubmittingDrivers.
 
-
+Many of these steps describe the default behavior of the git version
+control system; if you use git to prepare your patches, you'll find much
+of the mechanical work done for you, though you'll still need to prepare
+and document a sensible set of patches.
 
 
 SECTION 1 - CREATING AND SENDING YOUR CHANGE
@@ -25,7 +28,9 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE
 1) diff -up
 
 
-Use diff -up or diff -uprN to create patches.
+Use diff -up or diff -uprN to create patches.  git generates patches
+in this form by default; if you're using git, you can skip this section
+entirely.
 
 All changes to the Linux kernel occur in the form of patches, as
 generated by diff(1).  When creating your patch, make sure to create it
@@ -66,19 +71,14 @@ Make sure your patch does not include any extra files which 
do not
 belong in a patch submission.  Make sure to review your patch -after-
 generated it with diff(1), to ensure accuracy.
 
-If your changes produce a lot of deltas, you may want to look into
-splitting them into individual patches which modify things in
-logical stages.  This will facilitate easier reviewing by other
-kernel developers, very important if you want your patch accepted.
-There are a number of scripts which can aid in this:
-
-Quilt:
-http://savannah.nongnu.org/projects/quilt
+If your changes produce a lot of deltas, you need to split them into
+individual patches which modify things in logical stages; see section
+#3.  This will facilitate easier reviewing by other kernel developers,
+very important if you want your patch accepted.
 
-Andrew Morton's patch scripts:
-http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
-Instead of these scripts, quilt is the recommended patch management
-tool (see above).
+If you're using git, git rebase -i can help you with this process.  If
+you're not using git, quilt http://savannah.nongnu.org/projects/quilt
+is another popular alternative.
 
 
 
@@ -607,7 +607,8 @@ patch.
 If you are going to include a diffstat after the --- marker, please
 use diffstat options -p 1 -w 70 so that filenames are listed from
 the top of the kernel source tree and don't use too much horizontal
-space (easily fit in 80 columns, maybe with some indentation).
+space (easily fit in 80 columns, maybe with some indentation).  (git
+generates appropriate diffstats by default.)
 
 See more details on the proper patch format in the following
 references.
-- 
1.8.5.1

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

[PATCH 1/3] SubmittingPatches: Add style recommendation to use imperative descriptions

[Josh Triplett]

Most commit messages use this style, and the recommendation frequently
comes up in discussions (especially in response to patches that don't
use it), but that recommendation doesn't actually appear anywhere in
Documentation.  Add this style guideline to SubmittingPatches, using the
description from git's SubmittingPatches.

Signed-off-by: Josh Triplett j...@joshtriplett.org
---
 Documentation/SubmittingPatches | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 26b1e31..c74e73c 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -106,6 +106,11 @@ I.e., the patch (series) and its description should be 
self-contained.
 This benefits both the patch merger(s) and reviewers.  Some reviewers
 probably didn't even receive earlier versions of the patch.
 
+Describe your changes in imperative mood, e.g. make xyzzy do frotz
+instead of [This patch] makes xyzzy do frotz or [I] changed xyzzy
+to do frotz, as if you are giving orders to the codebase to change
+its behaviour.
+
 If the patch fixes a logged bug entry, refer to that bug entry by
 number and URL.
 
-- 
1.8.5.1

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

Re: [PATCH] drivers: ptp: Include new header file in ptp_pch.c

[Josh Triplett]

On Mon, Dec 16, 2013 at 02:14:15AM +0530, Rashika Kheria wrote:
 Create a new header file include/linux/ptp_pch.h which contains
 prototype declaration of functions pch_ch_control_read(),
 pch_ch_control_write(), pch_ch_event_read(), pch_ch_event_write(),
 pch_src_uuid_lo_read(), pch_src_uuid_hi_read(), pch_rx_snap_read(),
 pch_tx_snap_read() and pch_set_station_address().
 
 Include the new header file in drivers/ptp/ptp_pch.c and
 drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c because they
 use these functions. Remove these functions prototypes from header
 file drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h.
 
 This eliminates the following warnings in ptp_pch.c:
 
 drivers/ptp/ptp_pch.c:194:5: warning: no previous prototype for 
 ‘pch_ch_control_read’ [-Wmissing-prototypes]
 drivers/ptp/ptp_pch.c:205:6: warning: no previous prototype for 
 ‘pch_ch_control_write’ [-Wmissing-prototypes]
 drivers/ptp/ptp_pch.c:213:5: warning: no previous prototype for 
 ‘pch_ch_event_read’ [-Wmissing-prototypes]
 drivers/ptp/ptp_pch.c:224:6: warning: no previous prototype for 
 ‘pch_ch_event_write’ [-Wmissing-prototypes]
 drivers/ptp/ptp_pch.c:232:5: warning: no previous prototype for 
 ‘pch_src_uuid_lo_read’ [-Wmissing-prototypes]
 drivers/ptp/ptp_pch.c:243:5: warning: no previous prototype for 
 ‘pch_src_uuid_hi_read’ [-Wmissing-prototypes]
 drivers/ptp/ptp_pch.c:254:5: warning: no previous prototype for 
 ‘pch_rx_snap_read’ [-Wmissing-prototypes]
 drivers/ptp/ptp_pch.c:271:5: warning: no previous prototype for 
 ‘pch_tx_snap_read’ [-Wmissing-prototypes]
 drivers/ptp/ptp_pch.c:312:5: warning: no previous prototype for 
 ‘pch_set_station_address’ [-Wmissing-prototypes]
 
 Signed-off-by: Rashika Kheria rashika.khe...@gmail.com

Reviewed-by: Josh Triplett j...@joshtriplett.org

  drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h|9 -
  .../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c   |1 +
  drivers/ptp/ptp_pch.c  |1 +
  include/linux/ptp_pch.h|   16 
  4 files changed, 18 insertions(+), 9 deletions(-)
  create mode 100644 include/linux/ptp_pch.h
 
 diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h 
 b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
 index 2a900307..79533c8 100644
 --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
 +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
 @@ -666,15 +666,6 @@ void pch_gbe_free_tx_resources(struct pch_gbe_adapter 
 *adapter,
  void pch_gbe_free_rx_resources(struct pch_gbe_adapter *adapter,
  struct pch_gbe_rx_ring *rx_ring);
  void pch_gbe_update_stats(struct pch_gbe_adapter *adapter);
 -u32 pch_ch_control_read(struct pci_dev *pdev);
 -void pch_ch_control_write(struct pci_dev *pdev, u32 val);
 -u32 pch_ch_event_read(struct pci_dev *pdev);
 -void pch_ch_event_write(struct pci_dev *pdev, u32 val);
 -u32 pch_src_uuid_lo_read(struct pci_dev *pdev);
 -u32 pch_src_uuid_hi_read(struct pci_dev *pdev);
 -u64 pch_rx_snap_read(struct pci_dev *pdev);
 -u64 pch_tx_snap_read(struct pci_dev *pdev);
 -int pch_set_station_address(u8 *addr, struct pci_dev *pdev);
  
  /* pch_gbe_param.c */
  void pch_gbe_check_options(struct pch_gbe_adapter *adapter);
 diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c 
 b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
 index 27ffe0e..03e2c14 100644
 --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
 +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
 @@ -24,6 +24,7 @@
  #include linux/net_tstamp.h
  #include linux/ptp_classify.h
  #include linux/gpio.h
 +#include linux/ptp_pch.h
  
  #define DRV_VERSION 1.01
  const char pch_driver_version[] = DRV_VERSION;
 diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
 index 71a2559..ec5cf7d 100644
 --- a/drivers/ptp/ptp_pch.c
 +++ b/drivers/ptp/ptp_pch.c
 @@ -20,6 +20,7 @@
   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307, USA.
   */
  
 +#include linux/ptp_pch.h
  #include linux/device.h
  #include linux/err.h
  #include linux/init.h
 diff --git a/include/linux/ptp_pch.h b/include/linux/ptp_pch.h
 new file mode 100644
 index 000..bd23d53
 --- /dev/null
 +++ b/include/linux/ptp_pch.h
 @@ -0,0 +1,16 @@
 +#include linux/types.h
 +#include linux/pci.h
 +
 +/* Function prototype declaration common between
 + * drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c and
 + * drivers/ptp/ptp_pch.c.*/
 +
 +u32 pch_ch_control_read(struct pci_dev *pdev);
 +void pch_ch_control_write(struct pci_dev *pdev, u32 val);
 +u32 pch_ch_event_read(struct pci_dev *pdev);
 +void pch_ch_event_write(struct pci_dev *pdev, u32 val);
 +u32 pch_src_uuid_lo_read(struct pci_dev *pdev);
 +u32 pch_src_uuid_hi_read(struct pci_dev *pdev);
 +u64 pch_rx_snap_read(struct pci_dev *pdev);
 +u64 pch_tx_snap_read(struct pci_dev *pdev);
 +int pch_set_station_address(u8 *addr, struct pci_dev *pdev);
 -- 
 1.7.9.5
 
--
To unsubscribe from this 

Re: [PATCH RT 2/5] a few open coded completions

[Steven Rostedt]

On Sun, 15 Dec 2013 16:28:39 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:


 Thank you for the fixups. I just did the same thing in the v3.12 tree.
 The chunk you nuked is now in Dave's net tree as a0a9663dd214 (net: make
 neigh_priv_len in struct net_device 16bit instead of 8bit). As it
 describes it is buggy on -RT but not mainline therefore it has no stable
 tag for mainline and I would add one for RT.

Yeah, I realized that too. I'll be adding it to the stable release.
That's why I didn't do the releases on Friday. I'll do them on Monday
after one final test with re-adding that change.

Thanks!

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

Re: [PATCH 1/3] SubmittingPatches: Add style recommendation to use imperative descriptions

[Borislav Petkov]

On Sun, Dec 15, 2013 at 12:59:26PM -0800, Josh Triplett wrote:
 Most commit messages use this style, and the recommendation frequently
 comes up in discussions (especially in response to patches that don't
 use it), but that recommendation doesn't actually appear anywhere in
 Documentation.  Add this style guideline to SubmittingPatches, using the
 description from git's SubmittingPatches.
 
 Signed-off-by: Josh Triplett j...@joshtriplett.org

Acked-by: Borislav Petkov b...@suse.de

We should probably also document the wished-for structure of a commit
message:

The current situation is A. The shortcoming is B. Change/fix it by doing
C.

This helps very much in explaining to the unenlightened onlooker what
a patch is trying to fix without having to ask the author a bunch of
questions first.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] SubmittingPatches: Document the use of git

[Borislav Petkov]

On Sun, Dec 15, 2013 at 12:59:51PM -0800, Josh Triplett wrote:
 Most of the mechanical portions of SubmittingPatches exist to help patch
 submitters replicate the output of git.  Mention this explicitly, both
 as a reminder that git will help with this process, and as signposting to
 let git users know what they can safely skip.
 
 Signed-off-by: Josh Triplett j...@joshtriplett.org

Very good idea!

Acked-by: Borislav Petkov b...@suse.de

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] SubmittingPatches: Add recommendation for mailing list references

[Borislav Petkov]

On Sun, Dec 15, 2013 at 12:59:40PM -0800, Josh Triplett wrote:
 SubmittingPatches already mentions referencing bugs fixed by a commit,
 but doesn't mention citing relevant mailing list discussions.  Add a
 note to that effect, along with a recommendation to use the
 https://lkml.kernel.org/ redirector.
 
 Portions based on text from git's SubmittingPatches.
 
 Signed-off-by: Josh Triplett j...@joshtriplett.org

Yep.

Acked-by: Borislav Petkov b...@suse.de

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in aio_migratepage

[Kristian Nielsen]

What is the status of this?

If I understand correctly, the crash I saw is different from what Dave
saw.

There was one patched scheduled for inclusion that fixes Dave's crash. But
what about mine? I have been running 3.13-rc2 for a couple of weeks now with
your other patch, without seeing it again, which suggests it has helped. But
it seems that patch has a locking bug as described by Dave (sleeping under
spinlock)? So this appears unsolved as of yet...

So I just wanted to check that this was not forgotten. Is there something I
can do to help get this sorted out? Should I try to run with unpatched -rc4
for some time to check if it appears again? Anything else?

 - Kristian.

Dave Jones da...@redhat.com writes:

 On Mon, Dec 02, 2013 at 06:10:46PM +0800, Gu Zheng wrote:
   Hi Kristian, Dave,
   
   Could you please help to check whether the following patch can fix this 
 issue?

 This introduces some locking bugs..


 [  222.327950] BUG: sleeping function called from invalid context at 
 kernel/locking/mutex.c:616
 [  222.328004] in_atomic(): 1, irqs_disabled(): 0, pid: 12794, name: 
 trinity-child1
 [  222.328044] 1 lock held by trinity-child1/12794:
 [  222.328072]  #0:  ((mapping-private_lock)-rlock){+.+...}, at: 
 [81210a64] aio_free_ring+0x44/0x160
 [  222.328147] CPU: 1 PID: 12794 Comm: trinity-child1 Not tainted 3.13.0-rc2+ 
 #12 
 [  222.328268]  0268 880229517d68 8173bc52 
 
 [  222.328320]  880229517d90 8108ad95 880223b6acd0 
 
 [  222.328370]   880229517e08 81741cf3 
 880229517dc0
 [  222.328421] Call Trace:
 [  222.328443]  [8173bc52] dump_stack+0x4e/0x7a
 [  222.328475]  [8108ad95] __might_sleep+0x175/0x200
 [  222.328510]  [81741cf3] mutex_lock_nested+0x33/0x400
 [  222.328545]  [81179e68] unmap_mapping_range+0x68/0x170
 [  222.328582]  [81160a35] truncate_pagecache+0x35/0x60
 [  222.328617]  [81160a72] truncate_setsize+0x12/0x20
 [  222.328651]  [81210ab9] aio_free_ring+0x99/0x160
 [  222.328684]  [81213071] SyS_io_setup+0xef1/0xf00
 [  222.328717]  [8174eaa4] tracesys+0xdd/0xe2

 [  222.328769] ==
 [  222.328804] [ INFO: possible circular locking dependency detected ]
 [  222.328838] 3.13.0-rc2+ #12 Not tainted
 [  222.328862] ---
 [  222.328896] trinity-child1/12794 is trying to acquire lock:
 [  222.328928]  (mapping-i_mmap_mutex){+.+...}, at: [81179e68] 
 unmap_mapping_range+0x68/0x170
 [  222.328987] 
 but task is already holding lock:
 [  222.329020]  ((mapping-private_lock)-rlock){+.+...}, at: 
 [81210a64] aio_free_ring+0x44/0x160
 [  222.329081] 
 which lock already depends on the new lock.

 [  222.329125] 
 the existing dependency chain (in reverse order) is:
 [  222.329166] 
 - #2 ((mapping-private_lock)-rlock){+.+...}:
 [  222.329211][810af833] lock_acquire+0x93/0x1c0
 [  222.329248][817454f0] _raw_spin_lock+0x40/0x80
 [  222.329285][811f334d] __set_page_dirty_buffers+0x2d/0xb0
 [  222.331243][8115aada] set_page_dirty+0x3a/0x60
 [  222.334437][81179a7f] unmap_single_vma+0x62f/0x830
 [  222.337633][8117ad19] unmap_vmas+0x49/0x90
 [  222.340819][811804bd] unmap_region+0x9d/0x110
 [  222.343968][811829f6] do_munmap+0x226/0x3b0
 [  222.346689][81182bc4] vm_munmap+0x44/0x60
 [  222.349741][81183b42] SyS_munmap+0x22/0x30
 [  222.352758][8174eaa4] tracesys+0xdd/0xe2
 [  222.355735] 
 - #1 ((ptlock_ptr(page))-rlock#2){+.+...}:
 [  222.361611][810af833] lock_acquire+0x93/0x1c0
 [  222.364589][817454f0] _raw_spin_lock+0x40/0x80
 [  222.367200][81186338] __page_check_address+0x98/0x160
 [  222.370168][811864fe] page_mkclean+0xfe/0x1c0
 [  222.373120][8115ad60] clear_page_dirty_for_io+0x60/0x100
 [  222.376076][8124d207] mpage_submit_page+0x47/0x80
 [  222.379015][8124d350] mpage_process_page_bufs+0x110/0x130
 [  222.381955][8124d91b] 
 mpage_prepare_extent_to_map+0x22b/0x2f0
 [  222.384895][8125318f] ext4_writepages+0x4ef/0x1050
 [  222.387839][8115cdf1] do_writepages+0x21/0x50
 [  222.390786][81150959] 
 __filemap_fdatawrite_range+0x59/0x60
 [  222.393747][81150a5d] 
 filemap_write_and_wait_range+0x2d/0x70
 [  222.396729][812498ca] ext4_sync_file+0xba/0x4d0
 [  222.399714][811f1691] do_fsync+0x51/0x80
 [  222.402317][811f1980] SyS_fsync+0x10/0x20
 [  222.405240][8174eaa4] tracesys+0xdd/0xe2
 [  222.407760] 
 - #0 (mapping-i_mmap_mutex){+.+...}:
 [  222.413349]   

Re: [PATCH 1/3] SubmittingPatches: Add style recommendation to use imperative descriptions

[Josh Triplett]

On Sun, Dec 15, 2013 at 10:14:29PM +0100, Borislav Petkov wrote:
 On Sun, Dec 15, 2013 at 12:59:26PM -0800, Josh Triplett wrote:
  Most commit messages use this style, and the recommendation frequently
  comes up in discussions (especially in response to patches that don't
  use it), but that recommendation doesn't actually appear anywhere in
  Documentation.  Add this style guideline to SubmittingPatches, using the
  description from git's SubmittingPatches.
  
  Signed-off-by: Josh Triplett j...@joshtriplett.org
 
 Acked-by: Borislav Petkov b...@suse.de
 
 We should probably also document the wished-for structure of a commit
 message:
 
 The current situation is A. The shortcoming is B. Change/fix it by doing
 C.
 
 This helps very much in explaining to the unenlightened onlooker what
 a patch is trying to fix without having to ask the author a bunch of
 questions first.

git's SubmittingPatches has some bits that could help there.  I wouldn't
recommend writing the structure quite so rigidly (A and B aren't always
needed, depending on the nature of the problem and the fix), but some
guidance would help.

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

Re: Replace /dev/random input mix polynomial with Brent's xorgen?

[George Spelvin]

 My draft patch series uses Skein/Threefish.  The authors conveniently
 specified a way to use it as a PRNG, and it's very fast without
 special hardware support (consequently, for all kinds of hardware.)
 On my laptop, reading from /dev/urandom becomes about 25 times faster
 for large reads, and about 40% faster for small reads where the
 syscall overhead is more important.

Well, /dev/urandom is documented as being *deliberately* slow.  It's meant
only to produce 128 to 256 bits of seed material for CPRNG.  I don't
know if Ted considers speeding it up to be goal or an antigoal. :-)

One thing i've thought about is adding a /dev/frandom, which is seeded
once at open time and then produces a reasonably strong large block of
cryptographic output, very quickly.  (Key size between 128 and 192 bits.)

I understand why Ted didn't do this in the first place, but the number
of people I see doing something like cat /dev/urandom  /dev/sdx
to test incompressible data is remarkable.

If the additional code is small, perhaps it's worth doing.


BTW, if it helps on 32-bit platforms I can get you rotate constats for
a 32-bit version of threefish.  I haven't generated a key scheduling
constant, though.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUG: key ffff8800192a6ad0 not in .data!

[Bjorn Helgaas]

On Sun, Dec 15, 2013 at 10:04 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 On Sun, Dec 15, 2013 at 02:31:23PM +0800, Fengguang Wu wrote:
 Greetings,

 I got the below dmesg and the first bad commit is

 I thought this was already fixed in Bjorn's tree, but perhaps he hasn't
 merged in the one-liner for it...

Yes, this is fixed.  I actually dropped that MSI change temporarily
until we can fold in the memory leak fixes, so it is not currently in
linux-next.

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

Re: Replace /dev/random input mix polynomial with Brent's xorgen?

[Theodore Ts'o]

On Sun, Dec 15, 2013 at 03:34:59AM -0500, George Spelvin wrote:
  I'm not convinced we need to worry about cache timing attacks, since
  they typically involve a chosen plaintext attack and a fixed key ---
  and the attacker isn't going to know what we are going to be
  encrypting, let alone be able to chose the plaintext.
 
 You're describing standard key-recovery attacks.  For /dev/random,
 just knowing the *ciphertext* constitutes a successful attack.

Um, no.  The *ciphertext* is the output.  The attacker can get all of
the ciphertext he or she wants by reading /dev/random (although we'd
probably do some folding as we currently do so the attacker won't even
get all of the ciphertext).  What the attacker has to be able to do is
given some of the ciphertext bits, be able to predict future
ciphertext bits given some construction which uses AES as the basis.

For example, using something simple (we'd probably using something
more complicated, such as Davies-Meyer), show me a cache timing attack
where the attacker can get to see arbitrary values of:

  R_X = AES(KEY, I+X)

But where the attacker does not know KEY, *or* I, but can get to see
R_X for values 0  X  N.  The attacker has to be able to predict
R_(N+1).

Show me a cache timing attack given this scenario, and I'll be
convinced.  I believe this is **harder** than a standard key-recovery
attack, since the attacker doesn't get to choose the plaintext.  And
if you can't choose the plaintext in order try to recover the key,
please tell me how use can use cache timings in order to predict
R_(N+1), or even some bits of R_(N+1)?  Especially given that any good
crypto algorithm is designed so that even one or two bits change in
the key or the plaintext will result in massive changes in the
ciphertext

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

Re: [PATCH v3] usb: gadget: Add UDC driver for Aeroflex Gaisler GRUSBDC

[Andreas Larsson]

On 12/13/2013 08:52 PM, Felipe Balbi wrote:

Hi,

On Fri, Dec 13, 2013 at 08:48:30AM +0100, Andreas Larsson wrote:

On Wed, Dec 04, 2013 at 09:13:58AM +0100, Andreas Larsson wrote:

+static void gr_finish_request(struct gr_ep *ep, struct gr_request *req,
+ int status)
+{
+   struct gr_udc *dev;
+
+   list_del_init(req-queue);
+
+   if (likely(req-req.status == -EINPROGRESS))
+   req-req.status = status;
+   else
+   status = req-req.status;
+
+   dev = ep-dev;
+   usb_gadget_unmap_request(dev-gadget, req-req, ep-is_in);
+   gr_free_dma_desc_chain(dev, req);
+
+   if (ep-is_in) /* For OUT, actual gets updated bit by bit */
+   req-req.actual = req-req.length;
+
+   if (!status) {
+   if (ep-is_in)
+   gr_dbgprint_request(SENT, ep, req);
+   else
+   gr_dbgprint_request(RECV, ep, req);
+   }
+
+   /* Prevent changes to ep-queue during callback */
+   ep-callback = 1;
+   if (req == dev-ep0reqo  !status) {
+   if (req-setup)
+   gr_ep0_setup(dev, req);
+   else
+   dev_err(dev-dev,
+   Unexpected non setup packet on ep0in\n);
+   } else if (req-req.complete) {
+   unsigned long flags;
+
+   /*
+* Complete should be called with interrupts disabled according
+* to the contract of struct usb_request
+*/
+   local_irq_save(flags);


sorry but this driver isn't ready for inclusion. local_irq_save() is a
pretty good hint that there's something wrong in the driver. Consider
the fact that local_irq_save() will disable preemption even when
CONFIG_PREEMPT_FULL is enabled and you have a bit a problem.


This connection between local_irq_save and CONFIG_PREEMPT_RT_FULL was
unknown to me. Sure, I can disable interrupts right at spin lock
time.


that's better.


Alright, I'll put this in v4.



Also, the way you're using thread IRQs is quite wrong. I can't let that
pass and get merged upstream, sorry.


What is quite wrong? What is it that I need to fix?


Ideally the hardirq handler should be usually to actually check if
$this_device generated the IRQ, that should involve reading a IRQSTATUS
register of some sort.

Sure, check that IRQs are actually enabled, but you also need to read
STATUS register before waking the thread up.


I agree that that would be preferable. Unfortunately, the hardware lacks 
status register bits that indicates whether interrupts has been 
generated or not. That is why the only check is if interrupts are 
disabled, because that is the only sure way to know that the softirq 
handler does not need to go through everything.


Best regards,
Andreas Larsson

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

RE: [PATCH v2 2/4] pciehp: Use link change notifications for hot-plug and removal

[Rajat Jain]

Hello,


 -Original Message-
 From: Bjorn Helgaas [mailto:bhelg...@google.com]
 
 On Fri, Dec 13, 2013 at 12:04 PM, Rajat Jain rajatj...@juniper.net
 wrote:
  On Thu, Dec 12, 2013 at 11:26 PM, Yinghai Lu ying...@kernel.org
 wrote:
   On Thu, Dec 12, 2013 at 2:44 PM, Bjorn Helgaas
   bhelg...@google.com
 
  Also, I think the device removal should _always_ be initiated (if not
 done already) whenever the Link goes down for any reason (irrespective
 of whether the attention button is implemented or not, or whether the
 surprise events are supported or not). I think this is logical as it
 makes no sense for the software to think the device is accessible when
 in reality it is not. In fact I think we should also remove the checks
 in pciehp_disable_slot() that ensure that the adapter should be
 populated and latch should be closed.
 
 I agree.
 
  What does the other OS do about this repeater?  Did you verify that
  it disables the link when powering off the slot?  If we were smarter
  about presence detect, I wonder if that would be enough.
 
   Also we can get rid of annoying aer during power off slot.
 
  I don't know the details of this issue.  It may be possible to avoid
  the AER in some way other than turning off the link.
 
  Sorry, I could not understand what we are talking about here. I'd
 appreciate if you could elaborate if you see this as a problem related
 to the patch?
 
 I assume Yinghai means that when we power off the slot, if AER is still
 enabled, it may report errors caused by the link going down.
 PCIe r3.0 sec. 3.2.1 says some of these cases must not be considered
 errors if the link is disabled, the port is associated with a hot-
 pluggable slot, etc.  Maybe his platform doesn't follow those rules, or
 maybe there's some other AER error that's not covered by them.
 
 It's related to your patch because you are removing the link disable,
 and Yinghai says that if we leave the link enabled, he gets unwanted AER
 errors when powering off the slot.  Sorry if this was all obvious to
 you.  I don't know any more details.  It'd be nice to know the exact AER
 errors and the PCIe capability info.  Then we might be able to figure
 out a way to leave the link enabled while still suppressing the AER
 errors.

Thanks for the explanation. I understand now.

Yinghai: would you be able to give any details on what AER errors were seen, 
and a dump of all of the capabilities? 

 
  Once again: the way I interpret this is:
  * Always enable Link events.
  * Disable presence events if attention button is present.
 
 That sounds like a good plan to me.


Of course, this'll be done only if the link state change notification 
capability is present, otherwise I'll leave it to the current default state :-) 

Just FYI: Today, I once again used a truth table to convince myself that all 
possible combinations of (attention button support, surprise event support, 
power controller support) will work fine and if there is going to be a 
difference in behavior before and after this change. It looks the user 
experience is going to be exactly the same except for the following 2 which 
also seem to be fine: 

a) If a port has none of them: Attention button, Surprise event support, power 
controller. Then the current behavior is that it can only be added by doing 
echo 1  /sys/./power. After this change, no need to do this. The device 
will be automatically added as soon as the link comes up (which would come up 
as soon as it is plugged in, since there is no power controller).

b) If a port has all of them: Attention button, Surprise event support, power 
controller. Then the current behavior is that it shall be enabled as soon as it 
is plugged in. But with this change the user has to push the attention button 
to enable it. Which may be fine, because we just seem to have said that the 
attention button presence indicates that it takes priority over everything 
(including the surprise bit).

 
 I'm also dubious about this use of presence detect:
 
 pciehp_power_thread
   pciehp_enable_slot
 pciehp_get_adapter_status
   pciehp_readw(ctrl, PCI_EXP_SLTSTA, slot_status)
   *status = !!(slot_status  PCI_EXP_SLTSTA_PDS)
 board_added
   pciehp_power_on_slot
 
 because we apparently look at PCI_EXP_SLTSTA_PDS when the slot is
 powered off.  Only in-band presence detection is required by spec, and
 in-band detection only works when power is applied.  So I think this
 pciehp_get_adapter_status() call should probably just be removed.

Hummm, right, understood. However, then I think we also need cobbling in 
pciehp_probe(), pciehp_resume() because there also I see the same problem:

/* Check if slot is occupied */
slot = ctrl-slot;
pciehp_get_adapter_status(slot, occupied);
pciehp_get_power_status(slot, poweron);
if (occupied  pciehp_force) {
mutex_lock(slot-hotplug_lock);
pciehp_enable_slot(slot);

Re: BUG: key ffff8800192a6ad0 not in .data!

[Greg Kroah-Hartman]

On Sun, Dec 15, 2013 at 03:12:03PM -0700, Bjorn Helgaas wrote:
 On Sun, Dec 15, 2013 at 10:04 AM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
  On Sun, Dec 15, 2013 at 02:31:23PM +0800, Fengguang Wu wrote:
  Greetings,
 
  I got the below dmesg and the first bad commit is
 
  I thought this was already fixed in Bjorn's tree, but perhaps he hasn't
  merged in the one-liner for it...
 
 Yes, this is fixed.  I actually dropped that MSI change temporarily
 until we can fold in the memory leak fixes, so it is not currently in
 linux-next.

Do you want me to just resend a fixed patch up with the one-line fix,
and the memory-leak-on-error-path fix all as just one patch to make it
easier for you?

thanks,

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

RE: [PATCH v2 2/4] pciehp: Use link change notifications for hot-plug and removal

[Rajat Jain]

  
   Once again: the way I interpret this is:
   * Always enable Link events.
   * Disable presence events if attention button is present.
  
   That sounds like a good plan to me.
 
  How about Diag_Reset from MPT2SAS and others?
  link could up and down
 

I am assuming you are referring to 

static int
_base_diag_reset(struct MPT2SAS_ADAPTER *ioc, int sleep_flag)

Which as far as I could understand would cause link to go down and come up
 again without the kernel knowing anything about it?

Please see below since I think point made by Guenter includes this. 

 
 Good question. Another question is how this would play together with AER
 functions, specifically link_reset and slot_reset.
 
 In this context ... is it possible that the link_reset function from
 struct pci_error_handlers is never called, or am I missing something ?


Very good catch. That seems to be the case, at least as far as I can see.
In fact I think this may be uncovering a more serious problem 
with current code (with no link state events used for hotplug). 

A fatal error is discovered by AER
= Calls do_recovery()
   = reset_link()
  = Which will  reset the link at downstream / root port.

[PS: There is a clear problem the link_reset() is never broadcasted to all
The drivers, but skimming over that for now] 

In general, I guess the question is when a link goes down and back up, whether
or not we want to treat it as a hot unplug followed by a hotplug. I think there
may be cases such as AER (or the one Yinghai mentions) where we don't want to
treat it as a hotplug (see note below). And there may be cases that we
definitely want to treat it as hotplug (need link events!). Situation gets more
complex since there may be pciehp slots downstream of a link getting reset. 

It seems to me that we are saying that a mechanism is needed so that a voluntary
Link flap is NOT treated like a hotplug temporarily?

I found these:

/**
 * pcie_port_device_suspend - suspend port services associated with a PCIe port
 * @dev: PCI Express port to handle
 */
int pcie_port_device_suspend(struct device *dev)
{
return device_for_each_child(dev, NULL, suspend_iter);
}

/**
 * pcie_port_device_suspend - resume port services associated with a PCIe port
 * @dev: PCI Express port to handle
 */
int pcie_port_device_suspend(struct device *dev)
{
return device_for_each_child(dev, NULL, suspend_iter);
}

May be either these can be used or enhancements can be provided to disable a 
specific
Service on a particular port. 

Thanks,

Rajat


Notes: 
* it may not OK, if the kernel thinks the device is accessible when it is 
really not.
  What if during this downtime, someone tries to access the device (say 
userspace)?
* How do we know after the link up, that the device is really the same. 
  If during this reset, the device changed its character, say a different 
class?
  I think a rescan should be mandated after every such event.
 * Do we need to unload and reload the driver after the link reset, since it 
can be a different device?





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

[RFCv4 02/11] HSI: hsi-char: add Device Tree support

[Sebastian Reichel]

Add of_match_table to hsi_char driver, so that it can
be referenced from Device Tree.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/hsi/clients/hsi_char.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index e61e5f9..7f64bed 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -42,6 +42,7 @@
 #include linux/stat.h
 #include linux/hsi/hsi.h
 #include linux/hsi/hsi_char.h
+#include linux/of_device.h
 
 #define HSC_DEVS   16 /* Num of channels */
 #define HSC_MSGS   4
@@ -758,12 +759,22 @@ static int hsc_remove(struct device *dev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id hsi_char_of_match[] = {
+   { .compatible = ssi-char, },
+   { .compatible = hsi-char, },
+   {},
+};
+MODULE_DEVICE_TABLE(of, hsi_char_of_match);
+#endif
+
 static struct hsi_client_driver hsc_driver = {
.driver = {
.name   = hsi_char,
.owner  = THIS_MODULE,
.probe  = hsc_probe,
.remove = hsc_remove,
+   .of_match_table = of_match_ptr(hsi_char_of_match),
},
 };
 
-- 
1.8.5.1

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

[RFCv4 05/11] Documentation: DT: omap-ssi binding documentation

[Sebastian Reichel]

Create device tree binding documentation for
OMAP Synchronous Serial Interface (SSI) device.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 Documentation/devicetree/bindings/hsi/omap_ssi.txt | 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hsi/omap_ssi.txt

diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt 
b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
new file mode 100644
index 000..0a9efd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
@@ -0,0 +1,69 @@
+OMAP SSI controller bindings
+
+Required properties:
+- compatible:  Should include ti,omap3-ssi.
+- reg-names:   Contains the values sys and gdd.
+- reg: Contains a register specifier for each entry in
+   reg-names.
+- interrupt-names:  Contains the value gdd_mpu.
+- interrupts:  Contains interrupt information for each entry in
+   interrupt-names.
+- ranges   Represents the bus address mapping between the main
+   controller node and the child nodes below.
+- #address-cells   Should be set to 1
+- #size-cells  Should be set to 1
+
+Each port is represented as a sub-node of the ti,omap3-ssi device.
+
+Required Port sub-node properties:
+- compatible:  Should be set to the following value
+ti,omap3-ssi-port (applicable to OMAP34xx devices)
+- reg-names:   Contains the values rx and tx.
+- reg: Contains a register specifier for each entry in
+   reg-names.
+- interrupt-parent Should be a phandle for the interrupt controller
+- interrupt-names: Contains the values mpu_irq0 and mpu_irq1.
+- interrupts:  Contains interrupt information for each entry in
+   interrupt-names.
+- ti,ssi-cawake-gpio:  Defines which GPIO pin is used to signify CAWAKE
+   events for the port. This is an optional board-specific
+   property. If it's missing the port will not be
+   enabled.
+
+Example for Nokia N900:
+
+ssi-controller@48058000 {
+   compatible = ti,omap3-ssi;
+
+   /* needed until hwmod is updated to use the compatible string */
+   ti,hwmods = ssi;
+
+   reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+   reg-names = sys,
+   gdd;
+
+   interrupts = 55;
+   interrupt-names = gdd_mpu;
+
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   ssi-port@0 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 51,
+52;
+   interrupt-names = mpu_irq0,
+ mpu_irq1;
+
+   ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+   }
+}
-- 
1.8.5.1

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

[RFCv4 11/11] DTS: ARM: OMAP3-N900: Add SSI protocol support

[Sebastian Reichel]

This adds support for the protocol used to communicate
with its cellular modem.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 arch/arm/boot/dts/omap3-n900.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index c557a77..576a95c 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -534,6 +534,7 @@
power = 50;
 };
 
+#include dt-bindings/hsi/hsi.h
 ssi_port1 {
pinctrl-names = default;
pinctrl-0 = ssi_pins;
@@ -543,6 +544,18 @@
ssi-char {
compatible = ssi-char;
};
+
+   ssi-protocol {
+   compatible = ssi-protocol;
+
+   hsi,mode = HSI_MODE_FRAME;
+   hsi,channels = 4;
+   hsi,speed = 55000;
+   hsi,flow = HSI_FLOW_SYNC;
+   hsi,arb_mode = HSI_ARB_RR;
+
+   nokia,cmt = cmt;
+   };
 };
 
 ssi_port2 {
-- 
1.8.5.1

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

[RFCv4 09/11] DTS: ARM: OMAP3-N900: Add SSI support

[Sebastian Reichel]

Add SSI device tree data for OMAP3 and Nokia N900.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 arch/arm/boot/dts/omap3-n900.dts | 28 
 arch/arm/boot/dts/omap3.dtsi | 47 
 2 files changed, 75 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 6fc85f9..52f5099 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -145,6 +145,19 @@
0x0d4 (PIN_OUTPUT | MUX_MODE4)  /* 
RX51_LCD_RESET_GPIO */
;
};
+
+   ssi_pins: pinmux_ssi {
+   pinctrl-single,pins = 
+   0x150 (PIN_INPUT_PULLUP | MUX_MODE1)/* ssi1_rdy_tx 
*/
+   0x14e (PIN_OUTPUT | MUX_MODE1)  /* ssi1_flag_tx 
*/
+   0x152 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) /* 
ssi1_wake_tx (cawake) */
+   0x14c (PIN_OUTPUT | MUX_MODE1)  /* ssi1_dat_tx 
*/
+   0x154 (PIN_INPUT | MUX_MODE1)   /* ssi1_dat_rx 
*/
+   0x156 (PIN_INPUT | MUX_MODE1)   /* ssi1_flag_rx 
*/
+   0x158 (PIN_OUTPUT | MUX_MODE1)  /* ssi1_rdy_rx 
*/
+   0x15a (PIN_OUTPUT | MUX_MODE1)  /* ssi1_wake */
+   ;
+   };
 };
 
 i2c1 {
@@ -490,6 +503,21 @@
power = 50;
 };
 
+ssi_port1 {
+   pinctrl-names = default;
+   pinctrl-0 = ssi_pins;
+
+   ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+
+   ssi-char {
+   compatible = ssi-char;
+   };
+};
+
+ssi_port2 {
+   status = disabled;
+};
+
 uart1 {
status = disabled;
 };
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index daabf99..b7e485c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -630,5 +630,52 @@
num-eps = 16;
ram-bits = 12;
};
+
+   ssi: ssi-controller@48058000 {
+   compatible = ti,omap3-ssi;
+   ti,hwmods = ssi;
+
+   reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+   reg-names = sys,
+   gdd;
+
+   interrupts = 71;
+   interrupt-names = gdd_mpu;
+
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   ssi_port1: ssi-port@0 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 67,
+68;
+   interrupt-names = mpu_irq0,
+ mpu_irq1;
+   };
+
+   ssi_port2: ssi-port@1 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805b000 0x800,
+ 0x4805b800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 69,
+70;
+   interrupt-names = mpu_irq0,
+ mpu_irq1;
+   };
+   };
};
 };
-- 
1.8.5.1

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

[RFCv4 07/11] Documentation: DT: nokia-cmt binding documentation

[Sebastian Reichel]

Create device tree binding documentation for
Nokia cellular modem GPIO handling.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 .../devicetree/bindings/misc/nokia-cmt.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/nokia-cmt.txt

diff --git a/Documentation/devicetree/bindings/misc/nokia-cmt.txt 
b/Documentation/devicetree/bindings/misc/nokia-cmt.txt
new file mode 100644
index 000..1c87793
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/nokia-cmt.txt
@@ -0,0 +1,28 @@
+Nokia Cellular Modem (CMT) bindings
+
+Required properties:
+- compatible:  Should include nokia,cmt.
+- interrupts:  Interrupt specifier for the cmt reset irq.
+- gpio-names:  Contains the values cmt_apeslpx, cmt_rst_rq,
+   cmt_en, cmt_rst and cmt_bsi.
+- gpios:   Contains gpio information for each entry in gpio-names.
+
+Example for Nokia N900:
+
+cmt: nokia-cmt {
+   compatible = nokia,cmt;
+
+   interrupt-parent = gpio3;
+   interrupts = 8 IRQ_TYPE_EDGE_FALLING; /* gpio line 72 */
+
+   gpios = gpio3  6 GPIO_ACTIVE_HIGH, /* 70 */
+   gpio3  9 GPIO_ACTIVE_HIGH, /* 73 */
+   gpio3 10 GPIO_ACTIVE_HIGH, /* 74 */
+   gpio3 11 GPIO_ACTIVE_HIGH, /* 75 */
+   gpio5 29 GPIO_ACTIVE_HIGH; /* 157 */
+   gpio-names = cmt_apeslpx,
+cmt_rst_rq,
+cmt_en,
+cmt_rst,
+cmt_bsi;
+};
-- 
1.8.5.1

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

[RFCv4 10/11] DTS: ARM: OMAP3-N900: Add CMT support

[Sebastian Reichel]

This adds support for the Nokia N900 cellular modem.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 arch/arm/boot/dts/omap3-n900.dts | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 52f5099..c557a77 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -74,6 +74,26 @@
};
};
 
+   cmt: nokia-cmt {
+   compatible = nokia,cmt;
+
+   pinctrl-names = default;
+   pinctrl-0 = cmt_pins;
+
+   interrupt-parent = gpio3;
+   interrupts = 8 IRQ_TYPE_EDGE_FALLING; /* gpio line 72 */
+
+   gpios = gpio3  6 GPIO_ACTIVE_HIGH, /* 70 */
+   gpio3  9 GPIO_ACTIVE_HIGH, /* 73 */
+   gpio3 10 GPIO_ACTIVE_HIGH, /* 74 */
+   gpio3 11 GPIO_ACTIVE_HIGH, /* 75 */
+   gpio5 29 GPIO_ACTIVE_HIGH; /* 157 */
+   gpio-names = cmt_apeslpx,
+cmt_rst_rq,
+cmt_en,
+cmt_rst,
+cmt_bsi;
+   };
 };
 
 omap3_pmx_core {
@@ -158,6 +178,17 @@
0x15a (PIN_OUTPUT | MUX_MODE1)  /* ssi1_wake */
;
};
+
+   cmt_pins: pinmux_cmt {
+   pinctrl-single,pins = 
+   0x0ac (PIN_OUTPUT | MUX_MODE4)  /* gpio 70 = 
cmt_apeslpx */
+   0x0b0 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) /* gpio 72 = 
ape_rst_rq */
+   0x0b2 (PIN_OUTPUT | MUX_MODE4)  /* gpio 73 = 
cmt_rst_rq */
+   0x0b4 (PIN_OUTPUT | MUX_MODE4)  /* gpio 74 = 
cmt_en */
+   0x0b6 (PIN_OUTPUT | MUX_MODE4)  /* gpio 75 = 
cmt_rst */
+   0x15e (PIN_OUTPUT | MUX_MODE4)  /* gpio 157 = 
cmt_bsi */
+   ;
+   };
 };
 
 i2c1 {
-- 
1.8.5.1

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

[RFCv4 06/11] misc: Introduce Nokia CMT driver

[Sebastian Reichel]

Add driver handling GPIO pins of Nokia modems. The
driver provides reset notifications, so that SSI
clients can subscribe to them easily.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/misc/Kconfig  |   7 ++
 drivers/misc/Makefile |   1 +
 drivers/misc/nokia-cmt.c  | 298 ++
 include/linux/nokia-cmt.h |  46 +++
 4 files changed, 352 insertions(+)
 create mode 100644 drivers/misc/nokia-cmt.c
 create mode 100644 include/linux/nokia-cmt.h

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a3e291d..74e96cc 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,13 @@ config SRAM
  the genalloc API. It is supposed to be used for small on-chip SRAM
  areas found on many SoCs.
 
+config NOKIA_CMT
+   tristate Enable CMT support
+   help
+   If you say Y here, you will enable CMT support.
+
+   If unsure, say Y, or else you will not be able to use the CMT.
+
 source drivers/misc/c2port/Kconfig
 source drivers/misc/eeprom/Kconfig
 source drivers/misc/cb710/Kconfig
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f45473e..b109e84 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
 obj-$(CONFIG_LATTICE_ECP3_CONFIG)  += lattice-ecp3-config.o
 obj-$(CONFIG_SRAM) += sram.o
 obj-y  += mic/
+obj-$(CONFIG_NOKIA_CMT)+= nokia-cmt.o
diff --git a/drivers/misc/nokia-cmt.c b/drivers/misc/nokia-cmt.c
new file mode 100644
index 000..9c40cf6
--- /dev/null
+++ b/drivers/misc/nokia-cmt.c
@@ -0,0 +1,298 @@
+/*
+ * CMT support.
+ *
+ * Copyright (C) 2009 Nokia Corporation. All rights reserved.
+ * Copyright (C) 2013 Sebastian Reichel s...@kernel.org
+ *
+ * Contact: Carlos Chinea carlos.chi...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include asm/atomic.h
+#include linux/nokia-cmt.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/module.h
+#include linux/notifier.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/string.h
+#include linux/of.h
+#include linux/of_gpio.h
+
+/**
+ * struct cmt_gpio - GPIO with name
+ * @gpio: GPIO number
+ * @name: name for the GPIO
+ */
+struct cmt_gpio {
+   int gpio;
+   const char  *name;
+};
+
+/**
+ * struct cmt_device - CMT device data
+ * @cmt_rst_ind_tasklet: Bottom half for CMT reset line events
+ * @cmt_rst_ind_irq: IRQ number of the CMT reset line
+ * @n_head: List of notifiers registered to get CMT events
+ * @node: Link on the list of available CMTs
+ * @device: Reference to the CMT platform device
+ */
+struct cmt_device {
+   struct tasklet_struct   cmt_rst_ind_tasklet;
+   unsigned intcmt_rst_ind_irq;
+   struct atomic_notifier_head n_head;
+   struct list_headnode;
+   struct device   *device;
+   struct cmt_gpio *gpios;
+   int gpio_amount;
+};
+
+static LIST_HEAD(cmt_list);/* List of CMT devices */
+
+int cmt_notifier_register(struct cmt_device *cmtdev, struct notifier_block *nb)
+{
+   struct cmt_device *cmt;
+   int err = -ENODEV;
+
+   if ((!cmtdev) || (!nb))
+   return -EINVAL;
+
+   list_for_each_entry(cmt, cmt_list, node)
+   if (cmt == cmtdev) {
+   err = atomic_notifier_chain_register(cmt-n_head, nb);
+   break;
+   }
+
+   return err;
+}
+EXPORT_SYMBOL_GPL(cmt_notifier_register);
+
+int cmt_notifier_unregister(struct cmt_device *cmtdev,
+   struct notifier_block *nb)
+{
+   struct cmt_device *cmt;
+   int err = -ENODEV;
+
+   if ((!cmtdev) || (!nb))
+   return -EINVAL;
+
+   list_for_each_entry(cmt, cmt_list, node)
+   if (cmt == cmtdev) {
+   err = atomic_notifier_chain_unregister(cmt-n_head,
+   nb);
+   break;
+   }
+
+   return err;
+}

[RFCv4 08/11] HSI: Introduce driver for SSI Protocol

[Sebastian Reichel]

This adds a driver for the SSI McSAAB protocol as used in
the Nokia N900.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/hsi/clients/Kconfig|8 +
 drivers/hsi/clients/Makefile   |3 +-
 drivers/hsi/clients/ssi_protocol.c | 1201 
 include/linux/hsi/ssi_protocol.h   |   41 ++
 4 files changed, 1252 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hsi/clients/ssi_protocol.c
 create mode 100644 include/linux/hsi/ssi_protocol.h

diff --git a/drivers/hsi/clients/Kconfig b/drivers/hsi/clients/Kconfig
index 3bacd27..7103ffc 100644
--- a/drivers/hsi/clients/Kconfig
+++ b/drivers/hsi/clients/Kconfig
@@ -4,6 +4,14 @@
 
 comment HSI clients
 
+config SSI_PROTOCOL
+   tristate SSI protocol
+   depends on HSI  OMAP_SSI  NOKIA_CMT  PHONET
+   help
+   If you say Y here, you will enable the SSI protocol aka McSAAB.
+
+   If unsure, say N.
+
 config HSI_CHAR
tristate HSI/SSI character driver
depends on HSI
diff --git a/drivers/hsi/clients/Makefile b/drivers/hsi/clients/Makefile
index 327c0e2..ccbf768 100644
--- a/drivers/hsi/clients/Makefile
+++ b/drivers/hsi/clients/Makefile
@@ -2,4 +2,5 @@
 # Makefile for HSI clients
 #
 
-obj-$(CONFIG_HSI_CHAR) += hsi_char.o
+obj-$(CONFIG_SSI_PROTOCOL) += ssi_protocol.o
+obj-$(CONFIG_HSI_CHAR) += hsi_char.o
diff --git a/drivers/hsi/clients/ssi_protocol.c 
b/drivers/hsi/clients/ssi_protocol.c
new file mode 100644
index 000..5b23ab8
--- /dev/null
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -0,0 +1,1201 @@
+/*
+ * ssi_protocol.c
+ *
+ * Implementation of the SSI McSAAB improved protocol.
+ *
+ * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ * Copyright (C) 2013 Sebastian Reichel s...@kernel.org
+ *
+ * Contact: Carlos Chinea carlos.chi...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include asm/atomic.h
+#include linux/clk.h
+#include linux/nokia-cmt.h
+#include linux/device.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/if_ether.h
+#include linux/if_arp.h
+#include linux/if_phonet.h
+#include linux/init.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/notifier.h
+#include linux/scatterlist.h
+#include linux/skbuff.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/timer.h
+#include linux/hsi/hsi.h
+#include linux/hsi/ssi_protocol.h
+#include linux/of_device.h
+
+void ssi_waketest(struct hsi_client *cl, unsigned int enable);
+
+#define SSIP_TXQUEUE_LEN   100
+#define SSIP_MAX_MTU   65535
+#define SSIP_DEFAULT_MTU   4000
+#define PN_MEDIA_SOS   21
+#define SSIP_MIN_PN_HDR6   /* FIXME: Revisit */
+#define SSIP_WDTOUT2000/* FIXME: has to be 500 msecs */
+#define SSIP_KATOUT15  /* 15 msecs */
+#define SSIP_MAX_CMDS  5 /* Number of pre-allocated commands buffers */
+#define SSIP_BYTES_TO_FRAMES(x) x) - 1)  2) + 1)
+#define SSIP_CMT_LOADER_SYNC   0x11223344
+/*
+ * SSI protocol command definitions
+ */
+#define SSIP_COMMAND(data) ((data)  28)
+#define SSIP_PAYLOAD(data) ((data)  0xfff)
+/* Commands */
+#define SSIP_SW_BREAK  0
+#define SSIP_BOOTINFO_REQ  1
+#define SSIP_BOOTINFO_RESP 2
+#define SSIP_WAKETEST_RESULT   3
+#define SSIP_START_TRANS   4
+#define SSIP_READY 5
+/* Payloads */
+#define SSIP_DATA_VERSION(data)((data)  0xff)
+#define SSIP_LOCAL_VERID   1
+#define SSIP_WAKETEST_OK   0
+#define SSIP_WAKETEST_FAILED   1
+#define SSIP_PDU_LENGTH(data)  (((data)  8)  0x)
+#define SSIP_MSG_ID(data)  ((data)  0xff)
+/* Generic Command */
+#define SSIP_CMD(cmd, payload) (((cmd)  28) | ((payload)  0xfff))
+/* Commands for the control channel */
+#define SSIP_BOOTINFO_REQ_CMD(ver) \
+   SSIP_CMD(SSIP_BOOTINFO_REQ, SSIP_DATA_VERSION(ver))
+#define SSIP_BOOTINFO_RESP_CMD(ver) \
+   SSIP_CMD(SSIP_BOOTINFO_RESP, SSIP_DATA_VERSION(ver))
+#define SSIP_START_TRANS_CMD(pdulen, id) \
+   SSIP_CMD(SSIP_START_TRANS, (((pdulen)  8) | SSIP_MSG_ID(id)))
+#define SSIP_READY_CMD SSIP_CMD(SSIP_READY, 0)
+#define SSIP_SWBREAK_CMD   SSIP_CMD(SSIP_SW_BREAK, 0)
+
+/* Main state machine states */
+enum {
+   INIT,
+   HANDSHAKE,
+   

[RFCv4 03/11] HSI: hsi-char: fix driver for multiport scenarios

[Sebastian Reichel]

Fix return code check of alloc_chrdev_region, which
returns 0 on success.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/hsi/clients/hsi_char.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index 7f64bed..f51cf45 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -706,7 +706,7 @@ static int hsc_probe(struct device *dev)
if (!hsc_major) {
ret = alloc_chrdev_region(hsc_dev, hsc_baseminor,
HSC_DEVS, devname);
-   if (ret  0)
+   if (ret == 0)
hsc_major = MAJOR(hsc_dev);
} else {
hsc_dev = MKDEV(hsc_major, hsc_baseminor);
-- 
1.8.5.1

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

[RFCv4 01/11] HSI: method to unregister clients from an hsi port

[Sebastian Reichel]

This exports a method to unregister all clients from
an hsi port.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/hsi/hsi.c   | 10 ++
 include/linux/hsi/hsi.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 8bbc0f1..c7b842b 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -198,6 +198,16 @@ static void hsi_port_release(struct device *dev)
 }
 
 /**
+ * hsi_unregister_port - Unregister an HSI port
+ * @port: The HSI port to unregister
+ */
+void hsi_port_unregister_clients(struct hsi_port *port)
+{
+   device_for_each_child(port-device, NULL, hsi_remove_client);
+}
+EXPORT_SYMBOL_GPL(hsi_port_unregister_clients);
+
+/**
  * hsi_unregister_controller - Unregister an HSI controller
  * @hsi: The HSI controller to register
  */
diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
index fb07339..89cc6f2 100644
--- a/include/linux/hsi/hsi.h
+++ b/include/linux/hsi/hsi.h
@@ -284,6 +284,7 @@ int hsi_register_controller(struct hsi_controller *hsi);
 void hsi_unregister_controller(struct hsi_controller *hsi);
 void hsi_add_clients_from_dt(struct hsi_port *port,
struct device_node *clients);
+void hsi_port_unregister_clients(struct hsi_port *port);
 
 static inline void hsi_controller_set_drvdata(struct hsi_controller *hsi,
void *data)
-- 
1.8.5.1

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

[RFCv4 00/11] OMAP SSI driver / N900 modem support

[Sebastian Reichel]

Hi,

This is the fourth round of the OMAP SSI driver patches.

I added some more patches on top of the actual OMAP SSI driver, so that one can
get the overall picture of the planned architecture. This patchset contains
everything, that is needed to get the N900's modem running (without audio
support, which requires another hsi client driver).

After applying the patches one can use ofono with the N900's modem.
This is what I did to test the modem:

 # get ofono and mdbus2 to send some dbus commands
 apt-get install ofono mdbus2
 # ofono assumes, that gpios are available in /dev/cmt. Previously
 # a init script exported the gpios and symlinked them to this
 # directory. I added support for the gpio export directly into
 # nokia-cmt and I plan to write a patch for ofono to check for
 # the cmt gpios directly in /sys. For now this hack can be used
 # to test the modem.
 ln -sf /sys/devices/nokia-cmt.5 /dev/cmt
 # start ofono in debug mode
 export OFONO_ISI_DEBUG
 export OFONO_AT_DEBUG=1
 ofono --nodetach --debug
 # enable the modem
 mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Powered true
 # enable modem's RF parts
 mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Online true
 # scan for available networks
 mdbus2 -s org.ofono /n900_0 org.ofono.NetworkRegistration.Scan

Changes since RFCv3 [0]:
* Added new patches for nokia-cmt driver
* Added new patches for ssi protocol driver
* Removal of ti,hwmods description from DT Documentation
* Removed the hwmod patch, since it has already been applied
* Misc. bug fixes

TODO (short-term):
* Find a DT maintainer, who has time to review the updated DT bindings
* Push nokia-cmt driver through gregkh's linux-misc queue
* Push hsi/ssi drivers through my new linux-hsi queue [1]
* Push DTS patches through benoits queue once the other patches are queued

TODO (long-term):
* Central Message Queue
  I did not yet implement a central message queue in the HSI framework.
  I will do this after Nokia N900 modem is working in the mainline kernel.
* Get clock data from DT
  This depends on a patchset, which is not yet part of any kernel tree.
  Apart from that I don't know which clocks will be needed. That depends
  on the implementation of the hwmod DTification (see next point)
* Remove the hwmod DT hack
  This depends on some future work merging hwmod data into DT.

[0] https://lkml.org/lkml/2013/10/6/127
[1] https://git.kernel.org/cgit/linux/kernel/git/sre/linux-hsi.git/

-- Sebastian

Sebastian Reichel (11):
  HSI: method to unregister clients from an hsi port
  HSI: hsi-char: add Device Tree support
  HSI: hsi-char: fix driver for multiport scenarios
  ARM: OMAP2+: HSI: Introduce OMAP SSI driver
  Documentation: DT: omap-ssi binding documentation
  misc: Introduce Nokia CMT driver
  Documentation: DT: nokia-cmt binding documentation
  HSI: Introduce driver for SSI Protocol
  DTS: ARM: OMAP3-N900: Add SSI support
  DTS: ARM: OMAP3-N900: Add CMT support
  DTS: ARM: OMAP3-N900: Add SSI protocol support

 Documentation/devicetree/bindings/hsi/omap_ssi.txt |   69 +
 .../devicetree/bindings/misc/nokia-cmt.txt |   28 +
 arch/arm/boot/dts/omap3-n900.dts   |   72 +
 arch/arm/boot/dts/omap3.dtsi   |   47 +
 drivers/hsi/Kconfig|1 +
 drivers/hsi/Makefile   |1 +
 drivers/hsi/clients/Kconfig|8 +
 drivers/hsi/clients/Makefile   |3 +-
 drivers/hsi/clients/hsi_char.c |   13 +-
 drivers/hsi/clients/ssi_protocol.c | 1201 +
 drivers/hsi/controllers/Kconfig|   19 +
 drivers/hsi/controllers/Makefile   |6 +
 drivers/hsi/controllers/omap_ssi.c |  619 +
 drivers/hsi/controllers/omap_ssi.h |  166 +++
 drivers/hsi/controllers/omap_ssi_port.c| 1401 
 drivers/hsi/controllers/omap_ssi_regs.h|  171 +++
 drivers/hsi/hsi.c  |   10 +
 drivers/misc/Kconfig   |7 +
 drivers/misc/Makefile  |1 +
 drivers/misc/nokia-cmt.c   |  298 +
 include/linux/hsi/hsi.h|1 +
 include/linux/hsi/ssi_protocol.h   |   41 +
 include/linux/nokia-cmt.h  |   46 +
 23 files changed, 4227 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hsi/omap_ssi.txt
 create mode 100644 Documentation/devicetree/bindings/misc/nokia-cmt.txt
 create mode 100644 drivers/hsi/clients/ssi_protocol.c
 create mode 100644 drivers/hsi/controllers/Kconfig
 create mode 100644 drivers/hsi/controllers/Makefile
 create mode 100644 drivers/hsi/controllers/omap_ssi.c
 create mode 100644 drivers/hsi/controllers/omap_ssi.h
 create mode 100644 drivers/hsi/controllers/omap_ssi_port.c
 create mode 

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

[Stephen Rothwell]

Hi Simon,

Today's linux-next merge of the renesas tree got a conflict in
drivers/clk/Makefile between commit 0ad6125b1579 (clk: at91: add PMC
base support) from the arm-soc tree and commit 10cdfe9f327a (clk:
shmobile: Add R-Car Gen2 clocks support) from the renesas tree.

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

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

diff --cc drivers/clk/Makefile
index ace7309c4369,8dd1339be98b..
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@@ -35,7 -35,7 +35,8 @@@ obj-$(CONFIG_ARCH_TEGRA)  += tegra
  obj-$(CONFIG_PLAT_SAMSUNG)+= samsung/
  obj-$(CONFIG_COMMON_CLK_XGENE)  += clk-xgene.o
  obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
 +obj-$(CONFIG_COMMON_CLK_AT91) += at91/
+ obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/
  
  obj-$(CONFIG_X86) += x86/
  


pgp3jmLvbmLUz.pgp
Description: PGP signature

Re: BUG: key ffff8800192a6ad0 not in .data!

[Bjorn Helgaas]

On Sun, Dec 15, 2013 at 4:14 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 On Sun, Dec 15, 2013 at 03:12:03PM -0700, Bjorn Helgaas wrote:
 On Sun, Dec 15, 2013 at 10:04 AM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
  On Sun, Dec 15, 2013 at 02:31:23PM +0800, Fengguang Wu wrote:
  Greetings,
 
  I got the below dmesg and the first bad commit is
 
  I thought this was already fixed in Bjorn's tree, but perhaps he hasn't
  merged in the one-liner for it...

 Yes, this is fixed.  I actually dropped that MSI change temporarily
 until we can fold in the memory leak fixes, so it is not currently in
 linux-next.

 Do you want me to just resend a fixed patch up with the one-line fix,
 and the memory-leak-on-error-path fix all as just one patch to make it
 easier for you?

It's fine either way.  I'm happy to incorporate an incremental patch
if that's easier for you.

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

Re: pull request: linux-firmware: update cxgb4 firmware

[Ben Hutchings]

On Mon, 2013-12-16 at 01:02 +0530, Hariprasad S wrote:
 Hi,
 
 Can you please pull from the following URL?
 git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
 
 The following changes since commit 7d0c7a8cfd78388d90cc784a185b19dcbdbce824:
   Ben Hutchings (1):
   Merge branch 'wilink4' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/balbi/linux-firmware
 
 are available in the git repository at:
 
   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream

I'm no longer able to pull from this repository.  Depending on whether I
use my cellular data or home DSL connection it fails with either:

$ git fetch git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

or:

$ git fetch git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
fatal: unable to connect to git.chelsio.net:
git.chelsio.net[0: 67.207.112.37]: errno=Connection refused

Ben.

 Hariprasad Shenai (1):
 cxgb4: Updated T4 firmware, add T5 firmware
 
  WHENCE  |8 +---
  cxgb4/t4fw-1.6.2.0.bin  |  Bin 431616 - 0 bytes
  cxgb4/t4fw-1.9.23.0.bin |  Bin 0 - 486912 bytes
  cxgb4/t4fw.bin  |2 +-
  cxgb4/t5fw-1.9.23.0.bin |  Bin 0 - 481280 bytes
  cxgb4/t5fw.bin  |1 +
  6 files changed, 7 insertions(+), 4 deletions(-)
  delete mode 100644 cxgb4/t4fw-1.6.2.0.bin
  create mode 100644 cxgb4/t4fw-1.9.23.0.bin
  create mode 100644 cxgb4/t5fw-1.9.23.0.bin
  create mode 12 cxgb4/t5fw.bin
 
 Thanks,
 Hariprasad Shenai

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing anyway.


signature.asc
Description: This is a digitally signed message part

[BUG] New lockdep trace: v3.13-rc4

[Russell King - ARM Linux]

I just booted 3.13-rc4 on one of my ARM platforms and was greeted by this
trace.  Maybe caused by 975022310233 which appears to take this lock in
softirq context.

=
[ INFO: inconsistent lock state ]
3.13.0-rc4+ #387 Not tainted
-
inconsistent {SOFTIRQ-ON-W} - {IN-SOFTIRQ-W} usage.
swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
 ((sk-sk_dst_lock)-rlock){+.?...}, at: [c056f544] 
__udp4_lib_rcv+0x91c/0x980
{SOFTIRQ-ON-W} state was registered at:
  [c0063034] mark_lock+0x15c/0x704
  [c0063c78] __lock_acquire+0x69c/0x1e14
  [c00659bc] lock_acquire+0xa4/0x114
  [c0688488] _raw_spin_lock+0x34/0x44
  [c0578f3c] inet_bind+0x1ac/0x20c
  [c0502548] SyS_bind+0x6c/0x94
  [c000e980] ret_fast_syscall+0x0/0x48
irq event stamp: 423350
hardirqs last  enabled at (423350): [c050a8a8] __netdev_alloc_frag+0x118/0x14c
hardirqs last disabled at (423349): [c050a7b4] __netdev_alloc_frag+0x24/0x14c
softirqs last  enabled at (423342): [c0028f74] _local_bh_enable+0x2c/0x60
softirqs last disabled at (423343): [c0029678] irq_exit+0xc0/0x110

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock((sk-sk_dst_lock)-rlock);
  Interrupt
lock((sk-sk_dst_lock)-rlock);

 *** DEADLOCK ***

2 locks held by swapper/0/0:
 #0:  (rcu_read_lock){.+.+..}, at: [c0513404] 
__netif_receive_skb_core+0x3c/0x5f0
 #1:  (rcu_read_lock){.+.+..}, at: [c053f9fc] 
ip_local_deliver_finish+0x3c/0x428

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-rc4+ #387
Backtrace: 
[c0012640] (dump_backtrace) from [c00127dc] (show_stack+0x18/0x1c)
 r6:c0a7d150 r5:c0959c30 r4: r3:
[c00127c4] (show_stack) from [c0683a18] (dump_stack+0x70/0x90)
[c06839a8] (dump_stack) from [c0062dd4] (print_usage_bug+0x1dc/0x2e0)
 r4:c0a7d150 r3:c0959c30
[c0062bf8] (print_usage_bug) from [c006335c] (mark_lock+0x484/0x704)
 r10:0006 r9:c0062208 r8:c0959c30 r7:1054 r6:c0a7d150 r5:c095a000
 r4:0004
[c0062ed8] (mark_lock) from [c0063b90] (__lock_acquire+0x5b4/0x1e14)
 r10:da82c134 r9:0004 r8:02b3 r7:0002 r6:c0e9fbbc r5:c0959c30
 r4:0002
[c00635dc] (__lock_acquire) from [c00659bc] (lock_acquire+0xa4/0x114)
 r10: r9:0002 r8: r7: r6:da82c134 r5:c094e000
 r4:
[c0065918] (lock_acquire) from [c0688488] (_raw_spin_lock+0x34/0x44)
 r10:0199 r9:dab02b00 r8:c095880c r7:da82c000 r6:dbafd6e4 r5:0002
 r4:da82c124
[c0688454] (_raw_spin_lock) from [c056f544] (__udp4_lib_rcv+0x91c/0x980)
 r5:da82c124 r4:dab05600
[c056ec28] (__udp4_lib_rcv) from [c056fb3c] (udp_rcv+0x18/0x20)
 r10:c0999280 r9:db83e000 r8:c053ffbc r7:c0958308 r6:c0999280 r5:c078494c
 r4:dab05600
[c056fb24] (udp_rcv) from [c053fa6c] (ip_local_deliver_finish+0xac/0x428)
[c053f9c0] (ip_local_deliver_finish) from [c053ffbc] 
(ip_local_deliver+0xb8/0xc4)
 r10:c0999280 r9:db83e000 r8:c05136b8 r7:0050 r6:dab05600 r5:dbafd6d0
 r4:dab05600
[c053ff04] (ip_local_deliver) from [c053f5a4] (ip_rcv_finish+0x1c8/0x5e4)
 r4:c0540438
[c053f3dc] (ip_rcv_finish) from [c0540438] (ip_rcv+0x470/0x6ec)
 r10:c0999280 r9:db83e000 r8:c05136b8 r7:0050 r6:dab05600 r5:dbafd680
 r4:0050
[c053ffc8] (ip_rcv) from [c05136b8] (__netif_receive_skb_core+0x2f0/0x5f0)
 r10:dab05600 r9: r8:0008 r7:c0957628 r6:db83e000 r5:c095887c
 r4:c0957614
[c05133c8] (__netif_receive_skb_core) from [c05139e4] 
(__netif_receive_skb+0x2c/0x88)
 r10:0001 r9:c0956490 r8:dab05600 r7:0800 r6:dc040080 r5:c0957620
 r4:dab05600
[c05139b8] (__netif_receive_skb) from [c05158d4] 
(netif_receive_skb+0x38/0x118)
 r5:c0957620 r4:dab05600
[c051589c] (netif_receive_skb) from [c05185f4] (napi_gro_receive+0x7c/0xa8)
 r6:dc040080 r5:0003 r4:dab05600
[c0518578] (napi_gro_receive) from [c040b0ec] (fec_enet_rx_napi+0x38c/0x7ac)
 r5:db83e000 r4:db83e600
[c040ad60] (fec_enet_rx_napi) from [c0517894] (net_rx_action+0xbc/0x1e4)
 r10:c1356440 r9:c09500c0 r8:0003 r7:012c r6:0040 r5:0001
 r4:db83e760
[c05177d8] (net_rx_action) from [c00290c4] (__do_softirq+0x11c/0x2e4)
 r10:000c r9:0100 r8:0003 r7:f4000100 r6:c094e000 r5:c095008c
 r4:0001
[c0028fa8] (__do_softirq) from [c0029678] (irq_exit+0xc0/0x110)
 r10:c09ac810 r9:c09ac810 r8:c0956528 r7:f4000100 r6: r5:0096
 r4:c094e000
[c00295b8] (irq_exit) from [c000f298] (handle_IRQ+0x44/0x98)
 r4:c094b084 r3:0182
[c000f254] (handle_IRQ) from [c0008548] (gic_handle_irq+0x30/0x64)
 r6:c094ff00 r5:c0956c70 r4:f400010c r3:00a0
[c0008518] (gic_handle_irq) from [c00132c4] (__irq_svc+0x44/0x58)
Exception stack(0xc094ff00 to 0xc094ff48)
ff00: 0001 0001  c0959c30 c094e000 0001 c06915f8 c1350c40
ff20: c0956528 c09ac810 c09ac810 c094ff54 c094ff18 c094ff48 c006643c c000f668
ff40: 2113 
 r7:c094ff34 r6: r5:2113 r4:c000f668
[c000f630] (arch_cpu_idle) from [c006f404] (cpu_startup_entry+0xa4/0x200)
[c006f360] (cpu_startup_entry) from [c06819ec] 

Re: [PATCH v2 2/4] pciehp: Use link change notifications for hot-plug and removal

[Bjorn Helgaas]

On Sun, Dec 15, 2013 at 4:24 PM, Rajat Jain rajatj...@juniper.net wrote:
  
   Once again: the way I interpret this is:
   * Always enable Link events.
   * Disable presence events if attention button is present.
  
   That sounds like a good plan to me.
 
  How about Diag_Reset from MPT2SAS and others?
  link could up and down
 

 I am assuming you are referring to

 static int
 _base_diag_reset(struct MPT2SAS_ADAPTER *ioc, int sleep_flag)

 Which as far as I could understand would cause link to go down and come up
  again without the kernel knowing anything about it?
 ...

 In general, I guess the question is when a link goes down and back up, whether
 or not we want to treat it as a hot unplug followed by a hotplug. I think 
 there
 may be cases such as AER (or the one Yinghai mentions) where we don't want to
 treat it as a hotplug (see note below). And there may be cases that we
 definitely want to treat it as hotplug (need link events!). Situation gets 
 more
 complex since there may be pciehp slots downstream of a link getting reset.

 It seems to me that we are saying that a mechanism is needed so that a 
 voluntary
 Link flap is NOT treated like a hotplug temporarily?
 ...

 Notes:
 * it may not OK, if the kernel thinks the device is accessible when it is 
 really not.
   What if during this downtime, someone tries to access the device (say 
 userspace)?
 * How do we know after the link up, that the device is really the same.
   If during this reset, the device changed its character, say a different 
 class?
   I think a rescan should be mandated after every such event.
  * Do we need to unload and reload the driver after the link reset, since it 
 can be a different device?

I am quite dubious about the idea of a voluntary link flap.  If the
link goes down and comes back up, I don't see how we can make any
assumptions about what device is there.

I let Alex talk me into pciehp_reset_slot(), which disables presence
detect interrupts while resetting a device, so we already have a bit
of precedent for the idea.  But even in that case, the device could
easily come out of reset as a different device, e.g., if the reset
caused it to load updated firmware.

I would feel much better if we treated link down as a remove and did a
rescan on the link up.

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

Re: [PATCH v2 2/3] clk: bcm281xx: add initial clock framework support

[Alex Elder]

I think I can prepare a series that puts my changes
before Tim's. Unless I have trouble doing that
I will send that out in a few hours.

-Alex

 On Dec 15, 2013, at 11:39 AM, Alex Elder alex.el...@linaro.org wrote:
 
 On 12/14/2013 05:57 PM, Mike Turquette wrote:
 Quoting Alex Elder (2013-12-04 07:33:35)
 +   return true;
 +}
 +
 +/* A bit position must be less than the number of bits in a 32-bit
 register. */
 
 Hi Alex,
 
 The patch is corrupt at line 634 and several other places below.  Did
 you edit it manually? I'm happy with the series after reviewing it but
 it cannot be applied. Can you fix the issue and send me a pull request?
 
 Thanks,
 Mike
 
 First, yes I sent it manually (copy from the git-generated patch
 and paste into a mail message, and I'm sorry about that.  I have
 yet to set up my Linaro settings for git-send-email and I'll
 do that this week.
 
 I have a v3 that has been updated to apply to v3.13-rc3 (there
 is no -rc4 yet).
 
 I'm not sure how this works with the series of 8 patches from Tim
 Kryger that it depends on.  But here is a pull request for the
 version (including the prerequisites) based on 3.13-rc3.  (It is
 done manually again, so there are some line wraps...)
 
 Thanks a lot for the review Mike.  I know you're a busy guy.
 
-Alex
 
 The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
 
  Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
 
 are available in the git repository at:
 
  ssh://g...@git.linaro.org/people/alex.elder/linux.git
 review/bcm-kona-clocks-v3
 
 for you to fetch changes up to cf62c29babf6068abf91588411704566812b7900:
 
  ARM: dts: bcm281xx: define real clocks (2013-12-13 10:40:21 -0600)
 
 
 Alex Elder (3):
  clk: bcm281xx: define kona clock binding
  clk: bcm281xx: add initial clock framework support
  ARM: dts: bcm281xx: define real clocks
 
 Tim Kryger (8):
  ARM: dts: Declare clocks as fixed on bcm11351
  ARM: dts: Specify clocks for UARTs on bcm11351
  Documentation: dt: kona-sdhci: Add clocks property
  ARM: dts: Specify clocks for SDHCIs on bcm11351
  mmc: sdhci-bcm-kona: Add basic use of clocks
  Documentation: dt: kona-timer: Add clocks property
  clocksource: kona: Add basic use of external clock
  ARM: dts: Specify clocks for timer on bcm11351
 
 .../devicetree/bindings/arm/bcm/kona-timer.txt |7 +-
 .../devicetree/bindings/clock/bcm-kona-clock.txt   |   93 ++
 .../devicetree/bindings/mmc/kona-sdhci.txt |4 +
 arch/arm/boot/dts/bcm11351.dtsi|  199 +++-
 drivers/clk/Kconfig|1 +
 drivers/clk/Makefile   |1 +
 drivers/clk/bcm/Kconfig|8 +
 drivers/clk/bcm/Makefile   |3 +
 drivers/clk/bcm/clk-bcm281xx.c |  416 
 drivers/clk/bcm/clk-kona-setup.c   |  769 +++
 drivers/clk/bcm/clk-kona.c | 1033
 
 drivers/clk/bcm/clk-kona.h |  414 
 drivers/clocksource/bcm_kona_timer.c   |   14 +-
 drivers/mmc/host/sdhci-bcm-kona.c  |   37 +-
 include/dt-bindings/clock/bcm281xx.h   |   65 ++
 15 files changed, 3053 insertions(+), 11 deletions(-)
 create mode 100644
 Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
 create mode 100644 drivers/clk/bcm/Kconfig
 create mode 100644 drivers/clk/bcm/Makefile
 create mode 100644 drivers/clk/bcm/clk-bcm281xx.c
 create mode 100644 drivers/clk/bcm/clk-kona-setup.c
 create mode 100644 drivers/clk/bcm/clk-kona.c
 create mode 100644 drivers/clk/bcm/clk-kona.h
 create mode 100644 include/dt-bindings/clock/bcm281xx.h
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Replace /dev/random input mix polynomial with Brent's xorgen?

[Greg Price]

On Sun, Dec 15, 2013 at 05:09:10PM -0500, George Spelvin wrote:
 Well, /dev/urandom is documented as being *deliberately* slow.  It's meant
 only to produce 128 to 256 bits of seed material for CPRNG.  I don't
 know if Ted considers speeding it up to be goal or an antigoal. :-)

Hmm, I don't think I've seen that documentation.  I don't see anything
about that point in the comments of drivers/char/random.c.  The
urandom(4) man page says /dev/urandom is designed for security, not
speed, and is poorly suited to generating large amounts of random
data.  Which is quite different from being designed for slowness!

The great thing about the state of cryptography in 2013 is that we
don't have the kind of tradeoff between speed and security that we had
in the past.  Skein and Salsa20 and some other hashes and ciphers from
within the past decade are all very fast, and they've also been
attacked hard by cryptanalysts (motivated by competitions), and held
up very well.  From my understanding of the literature, moving to
either one from our current SHA-1-based scheme would only increase the
level of confidence one should have in the security of the random driver.

I think it would be great to be able to change the documentation to
is designed for security and is also very fast and well suited to
generating large amounts of random data.  Users are always tempted by
speed, and if we can reduce that temptation by making our CSPRNG
faster (and still secure), it will be good for security.


 BTW, if it helps on 32-bit platforms I can get you rotate constats for
 a 32-bit version of threefish.  I haven't generated a key scheduling
 constant, though.

Interesting.  So, the generic Skein implementations in the SUPERCOP
testing/benchmarking suite are about four times slower on x86_32 than
x86_64.  Which means Skein should still be about 6x faster than the
current /dev/urandom implementation, but it'd be nice to be faster
still.  I imagine the same rough comparisons will hold on other 64-bit
and 32-bit architectures, though the gap between x86_32 and x86_64 is
probably wider because of the scarcity of registers on x86_32.

I wouldn't want to compromise on security to do it, though.  My
confidence in Skein/Threefish's security comes mostly from the SHA-3
competition, where many expert cryptanalysts attacked it and didn't
get very far except in understanding why it seems to be hard to break.
To make, or even evaluate, a 32-bit variant of Threefish seems like
it'd require much deeper understanding of the design of Threefish and
its cryptanalysis than I've tried to develop.  How do you plan to
evaluate the security of your 32-bit Threefish?

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

Re: [BUG] New lockdep trace: v3.13-rc4

[Eric Dumazet]

On Mon, 2013-12-16 at 00:07 +, Russell King - ARM Linux wrote:
 I just booted 3.13-rc4 on one of my ARM platforms and was greeted by this
 trace.  Maybe caused by 975022310233 which appears to take this lock in
 softirq context.

Yep, this was mentioned earlier, thanks !

http://patchwork.ozlabs.org/patch/301382/


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

[git pull] Please pull powerpc.git merge branch

[Benjamin Herrenschmidt]

Hi Linus !

Here are some more powerpc fixes for 3.13.

Uli's patch fixes a regression in ptrace caused by a mis-merge of
a previous LE patch. The rest are all more endian fixes, all fairly
trivial, found during testing of 3.13-rc's.

Cheers,
Ben.

The following changes since commit e641eb03ab2b0f065fa5e64b4202fb5b0441b427:

  powerpc: Fix up the kdump base cap to 128M (2013-12-10 11:28:39 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge

for you to fetch changes up to 803c2d2f84da9dc2619449994af34d27148ab20d:

  powerpc/powernv: Fix OPAL LPC access in Little Endian (2013-12-13 15:55:15 
+1100)


Anton Blanchard (8):
  powerpc: Fix endian issue in setup-common.c
  powerpc: Fix topology core_id endian issue on LE builds
  powerpc/pseries: Fix endian issues in /proc/ppc64/lparcfg
  powerpc/pseries: Fix endian issues in nvram code
  powerpc/pseries: Fix PCIE link speed endian issue
  powerpc/pseries: Fix endian issues in MSI code
  powerpc: Fix endian issues in crash dump code
  powerpc/powernv: Fix endian issue in opal_xscom_read

Benjamin Herrenschmidt (1):
  powerpc/powernv: Fix OPAL LPC access in Little Endian

Ulrich Weigand (1):
  powerpc: PTRACE_PEEKUSR always returns FPR0

 arch/powerpc/include/asm/opal.h |  4 +--
 arch/powerpc/kernel/crash_dump.c|  6 ++--
 arch/powerpc/kernel/ptrace.c|  4 +--
 arch/powerpc/kernel/setup-common.c  |  4 +--
 arch/powerpc/kernel/smp.c   |  4 +--
 arch/powerpc/platforms/powernv/opal-lpc.c   | 12 
 arch/powerpc/platforms/powernv/opal-xscom.c |  4 ++-
 arch/powerpc/platforms/pseries/lparcfg.c| 12 
 arch/powerpc/platforms/pseries/msi.c| 28 ++
 arch/powerpc/platforms/pseries/nvram.c  | 46 ++---
 arch/powerpc/platforms/pseries/pci.c|  8 ++---
 11 files changed, 68 insertions(+), 64 deletions(-)


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

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

[Stephen Rothwell]

Hi Jean,

Today's linux-next merge of the jdelvare-hwmon tree got a conflict in
drivers/hwmon/lm90.c between commits from Linus' tree and commits from
the jdelvare-hwmon tree.

It looks like the jdelvare-hwmon patch series has been reset back
(unintentionally?) to stuff that has already been merged into Linus'
tree ... so I just used the version from Linus' tree.

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


pgpsGgtfud_7k.pgp
Description: PGP signature

Re: [PATCH 10/10] Kconfig: cleanup SERIO_I8042 dependencies

[David Miller]

From: Mark Salter msal...@redhat.com
Date: Sun, 15 Dec 2013 10:50:26 -0500

 On Sun, 2013-12-15 at 02:36 -0800, Dmitry Torokhov wrote:
 How are we going to merge this? In bulk through input tree or peacemeal
 through all arches first?

 They should all go together to eliminate the chance of bisect breakage.
 Either the input tree or maybe akpm tree.

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