Re: [PATCH V2] Allow compaction of unevictable pages

[Eric B Munson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/09/2015 03:57 PM, David Rientjes wrote:
> On Mon, 9 Mar 2015, Eric B Munson wrote:
> 
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h 
>> index f279d9c..599fb01 100644 --- a/include/linux/mmzone.h +++
>> b/include/linux/mmzone.h @@ -232,8 +232,6 @@ struct lruvec { 
>> #define ISOLATE_UNMAPPED ((__force isolate_mode_t)0x2) /* Isolate
>> for asynchronous migration */ #define ISOLATE_ASYNC_MIGRATE
>> ((__force isolate_mode_t)0x4) -/* Isolate unevictable pages */ 
>> -#define ISOLATE_UNEVICTABLE ((__force isolate_mode_t)0x8)
>> 
>> /* LRU Isolation modes. */ typedef unsigned __bitwise__
>> isolate_mode_t; diff --git a/mm/compaction.c b/mm/compaction.c 
>> index 8c0d945..4a8ea87 100644 --- a/mm/compaction.c +++
>> b/mm/compaction.c @@ -872,8 +872,7 @@
>> isolate_migratepages_range(struct compact_control *cc, unsigned
>> long start_pfn, if (!pageblock_pfn_to_page(pfn, block_end_pfn,
>> cc->zone)) continue;
>> 
>> -pfn = isolate_migratepages_block(cc, pfn, block_end_pfn, -
>> ISOLATE_UNEVICTABLE); +  pfn = isolate_migratepages_block(cc,
>> pfn, block_end_pfn, 0);
>> 
>> /* * In case of fatal failure, release everything that might diff
>> --git a/mm/vmscan.c b/mm/vmscan.c index 5e8eadd..3b2a444 100644 
>> --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1234,10 +1234,6 @@ int
>> __isolate_lru_page(struct page *page, isolate_mode_t mode) if
>> (!PageLRU(page)) return ret;
>> 
>> -/* Compaction should not handle unevictable pages but CMA can
>> do so */ -   if (PageUnevictable(page) && !(mode &
>> ISOLATE_UNEVICTABLE)) -  return ret; - ret = -EBUSY;
>> 
>> /*
> 
> Looks better!
> 
> I think there's one more cleanup we can do now thanks to your
> patch: dropping the isolate_mode_t formal from
> isolate_migratepages_block() entirely since that function can now
> just do
> 
> const isolate_mode_t isolate_mode = (cc->mode == MIGRATE_ASYNC ?
> ISOLATE_ASYNC_MIGRATE : 0);
> 
> since we already pass in the struct compact_control and
> isolate_mode only depends on MIGRATE_ASYNC or not.
> 
> If you'd like to fold that change into this patch because it's
> logically allowed by it, feel free to add my enthusiastic
> 
> Acked-by: David Rientjes 
> 
> Otherwise, I'll just send a change on top of it if you don't have
> time.

I'll V3 out shortly with that change.

Thanks for the review.

Eric
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJU/gUNAAoJELbVsDOpoOa9088P/1/HpbuC/CqmFq4FLTdPpXrt
AfDzzGL2e55dVE18Iqmcw6/LUJNb6gr49KmvlnPpMXVmUGTUhtgCySJqQTWtTcHq
NiXC6TuKYsknD7eYIeaR2M9zTN5Cq9swP01d8nIXCilfNNnK31QzlGrxVS5Vk8+X
OzlBUbdcfsOPaRItqadae0cQ19eNTtq33v9msRAwiovuyIL5LkNN1savq1sJVz7B
W9LFwhmUOrKYtxf8AlrSQ0Kg/X5YOskpaTQoPif0BoRkvNsAtE9sWDlzg4a24pn5
HGrlWcjJLsw4ZhEwfUnX1w5m2C2NhEbwKJ08eqyPF5kNavdzDqx+TsZ79ZYYMEVL
bYJcRZ0+Oef/u5ICpJrvlS2FdDqweAKuvT1bUcXoUZQfxxHi5gujp+4vfBZk3ct0
mnpbEcUAq5btck99p9PcAE6C3+T+NKjX+R7mVkOwbhFRpzrV1YMqreb7bcGutzhB
00QhNciI5izfJZIdasq783T7XFyd7oO1gl0MNf/lI1v0dklSr92j4WF7d6rbGX4h
Nnnbt4If1qP/F0n/NjRprHJg1muUZW2J8GBCq11cWnWXkl4y7S208MbyIewf1iVy
yl+ko2nFTbyDMYG46wsCoxqxmuWtUap+oanvF4NXbQ47wQO8hI8vjN9ph1MACxJP
l1pRsS0/XBUIBhnVYQMG
=suBI
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: light: Add support for Capella CM3323 color/light sensor

[Daniel Baluta]

On Mon, Mar 9, 2015 at 5:45 PM, Jonathan Cameron  wrote:
> On 02/03/15 19:03, Kevin Tsai wrote:
>> Hi Daniel,
>>
>> Ambient light sensor is trying to match the brightness sensitivity of human 
>> visual system.  Please see the following links:
>> http://en.wikipedia.org/wiki/Color_vision#mediaviewer/File:Eyesensitivity.svg
>> http://en.wikipedia.org/wiki/Color_vision
>>
>> You can compare the spectrum with the datasheet.  The green channel is 
>> matched with ALS spectrum.
> It's close (ish) to the right measurement, but it isn't the right 
> measurement.  As such
> I'd argue we leave it up to userspace to make the jump and use Green if a 
> true estimate
> if illuminance isn't available, but don't suggest it is available from the 
> kernel.


Ok, I will respin the patch with this in mind.

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

[PATCH 1/2] CAPABILITIES: add cap_isequal helper

[Mateusz Guzik]

Can be used to determine whether two given sets have the same
capabilities.

Signed-off-by: Mateusz Guzik 
---
 include/linux/capability.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index af9f0b9..2fcf941 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -155,6 +155,16 @@ static inline int cap_isclear(const kernel_cap_t a)
return 1;
 }
 
+static inline int cap_isequal(const kernel_cap_t a, const kernel_cap_t b)
+{
+   unsigned __capi;
+   CAP_FOR_EACH_U32(__capi) {
+   if (a.cap[__capi] != b.cap[__capi])
+   return 0;
+   }
+   return 1;
+}
+
 /*
  * Check if "a" is a subset of "set".
  * return 1 if ALL of the capabilities in "a" are also in "set"
-- 
1.8.3.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] crypto: amcc: remove incorrect __init/__exit markups

[Dmitry Torokhov]

Even if bus is not hot-pluggable, the devices can be bound and unbound
from the driver via sysfs, so we should not be using __init/__exit
annotations on probe() and remove() methods. The only exception is
drivers registered with platform_driver_probe() which specifically
disables sysfs bind/unbind attributes.

Signed-off-by: Dmitry Torokhov 
---
 drivers/crypto/amcc/crypto4xx_core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/amcc/crypto4xx_core.c 
b/drivers/crypto/amcc/crypto4xx_core.c
index d02b771..3b28e8c 100644
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -1155,7 +1155,7 @@ struct crypto4xx_alg_common crypto4xx_alg[] = {
 /**
  * Module Initialization Routine
  */
-static int __init crypto4xx_probe(struct platform_device *ofdev)
+static int crypto4xx_probe(struct platform_device *ofdev)
 {
int rc;
struct resource res;
@@ -1263,7 +1263,7 @@ err_alloc_dev:
return rc;
 }
 
-static int __exit crypto4xx_remove(struct platform_device *ofdev)
+static int crypto4xx_remove(struct platform_device *ofdev)
 {
struct device *dev = &ofdev->dev;
struct crypto4xx_core_device *core_dev = dev_get_drvdata(dev);
@@ -1291,7 +1291,7 @@ static struct platform_driver crypto4xx_driver = {
.of_match_table = crypto4xx_match,
},
.probe  = crypto4xx_probe,
-   .remove = __exit_p(crypto4xx_remove),
+   .remove = crypto4xx_remove,
 };
 
 module_platform_driver(crypto4xx_driver);
-- 
2.2.0.rc0.207.ga3a616c


-- 
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 2/2] fs: avoid unnecessary prepare_creds in faccessat

[Mateusz Guzik]

Sometimes faccessat needs to modify current thread's credentials, but
calls prepare_creds unconditionally.

Take advantage of the fact that we can detect whether any modification
to credentials is needed and in turn avoid unnecessary allocations.

Signed-off-by: Mateusz Guzik 
---
 fs/open.c | 53 +++--
 1 file changed, 35 insertions(+), 18 deletions(-)

diff --git a/fs/open.c b/fs/open.c
index 33f9cbf..166eb45 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -330,8 +330,10 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, 
offset, loff_t, len)
  */
 SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, filename, int, mode)
 {
-   const struct cred *old_cred;
-   struct cred *override_cred;
+   const struct cred *old_cred = current_cred();
+   struct cred *override_cred = NULL;
+   kernel_cap_t cap_effective;
+   int modify_cap_effective = 0;
struct path path;
struct inode *inode;
int res;
@@ -340,24 +342,37 @@ SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, 
filename, int, mode)
if (mode & ~S_IRWXO)/* where's F_OK, X_OK, W_OK, R_OK? */
return -EINVAL;
 
-   override_cred = prepare_creds();
-   if (!override_cred)
-   return -ENOMEM;
-
-   override_cred->fsuid = override_cred->uid;
-   override_cred->fsgid = override_cred->gid;
-
if (!issecure(SECURE_NO_SETUID_FIXUP)) {
/* Clear the capabilities if we switch to a non-root user */
-   kuid_t root_uid = make_kuid(override_cred->user_ns, 0);
-   if (!uid_eq(override_cred->uid, root_uid))
-   cap_clear(override_cred->cap_effective);
-   else
-   override_cred->cap_effective =
-   override_cred->cap_permitted;
+   kuid_t root_uid = make_kuid(old_cred->user_ns, 0);
+   if (!uid_eq(old_cred->uid, root_uid)) {
+   if (!cap_isclear(old_cred->cap_effective)) {
+   cap_clear(cap_effective);
+   modify_cap_effective = 1;
+   }
+   } else {
+   if (!cap_isequal(old_cred->cap_effective,
+   old_cred->cap_permitted)) {
+   cap_effective = old_cred->cap_permitted;
+   modify_cap_effective = 1;
+   }
+   }
}
 
-   old_cred = override_creds(override_cred);
+   if (!uid_eq(old_cred->fsuid, old_cred->uid) ||
+   !gid_eq(old_cred->fsgid, old_cred->gid) ||
+   modify_cap_effective) {
+   override_cred = prepare_creds();
+   if (!override_cred)
+   return -ENOMEM;
+
+   override_cred->fsuid = override_cred->uid;
+   override_cred->fsgid = override_cred->gid;
+   if (modify_cap_effective)
+   override_cred->cap_effective = cap_effective;
+
+   override_creds(override_cred);
+   }
 retry:
res = user_path_at(dfd, filename, lookup_flags, &path);
if (res)
@@ -399,8 +414,10 @@ out_path_release:
goto retry;
}
 out:
-   revert_creds(old_cred);
-   put_cred(override_cred);
+   if (override_cred) {
+   revert_creds(old_cred);
+   put_cred(override_cred);
+   }
return res;
 }
 
-- 
1.8.3.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 0/2] avoid prepare_creds in faccessat when possible

[Mateusz Guzik]

Sometimes faccessat needs to modify current thread's credentials, but
calls prepare_creds unconditionally.

However, typically resulting credentials are identical to original ones
and in that case newcredentials are unnecessary. We can detect this before
allocating anything.

This patch series adds a helper which allows comparing capability sets and
modifies faccessat to use it.

Mateusz Guzik (2):
  CAPABILITIES: add cap_isequal helper
  fs: avoid unnecessary prepare_creds in faccessat

 fs/open.c  | 53 ++
 include/linux/capability.h | 10 +
 2 files changed, 45 insertions(+), 18 deletions(-)

-- 
1.8.3.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 2/2] pinctrl: mediatek: Adjust mt8173 pinctrl kconfig

[Arnd Bergmann]

On Friday 06 March 2015 14:24:51 Yingjoe Chen wrote:
> Linus,
> This one make PINCTRL_MT8173 option user selectable and is based on
> mtk-staging in your tree. If you think this is OK, please applied or
> squash this into previous change. Thanks.

The patch looks good in principle, just two small comments

> --

To simplify the job for Linus here, please start the line above
with 

8<--

(a stylized pair if scissors)

which is the magic that git-am looks for.


> ARM64 maintainer doesn't want to add MACH_* for each SoC.
> Adjust mt8173 pinctrl kconfig entry so user can manually select it.
> 
> Also make PINCTRL_MT8135 build when COMPILE_TEST is enabled.
> 
> Signed-off-by: Yingjoe Chen 
> ---
>  drivers/pinctrl/mediatek/Kconfig | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/mediatek/Kconfig 
> b/drivers/pinctrl/mediatek/Kconfig
> index 49b8649..1472f0e 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -1,4 +1,4 @@
> -if ARCH_MEDIATEK
> +if ARCH_MEDIATEK || COMPILE_TEST
>  
>  config PINCTRL_MTK_COMMON
>   bool
> @@ -8,11 +8,13 @@ config PINCTRL_MTK_COMMON
>   select OF_GPIO
>  
>  config PINCTRL_MT8135
> - def_bool MACH_MT8135
> + def_bool MACH_MT8135 || COMPILE_TEST
>   select PINCTRL_MTK_COMMON
>  
>  config PINCTRL_MT8173
> - def_bool MACH_MT8173
> + bool "Mediatek MT8173 pin control"
> + def_bool y
> + depends on ARM64 || COMPILE_TEST
>   select PINCTRL_MTK_COMMON
>  

You have slightly different logic here: PINCTRL_MT8135 will
always be enabled when COMPILE_TEST is on, while PINCTRL_MT8173
is enabled by default in this case, but can be turned off.

Neither of them is what you really want, which would be

config PINCTRL_MT8135
bool "Mediatek MT8135 pin control"
depends on MACH_MT8135 || COMPILE_TEST
default MACH_MT8135
select PINCTRL_MTK_COMMON

config PINCTRL_MT8135
bool "Mediatek MT8173 pin control"
depends on MACH_MT8173 || COMPILE_TEST
default MACH_MT8173
select PINCTRL_MTK_COMMON

This way, the options are only enabled by default if MACH_MT8135
or MACH_MT8173 are enabled, but you are free to enable or disable
them when COMPILE_TEST is set. Alternatively, you can do

config PINCTRL_MT8135
bool "Mediatek MT8135 pin control" if COMPILE_TEST && !MACH_MT8135
default MACH_MT8135
select PINCTRL_MTK_COMMON

config PINCTRL_MT8135
bool "Mediatek MT8173 pin control" if COMPILE_TEST && !MACH_MT8173
default MACH_MT8173
select PINCTRL_MTK_COMMON

which will let you turn on the options if COMPILE_TEST is set, but not
let you turn them off when the drivers are required.

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

Re: [PATCH 3/4] x86: save user rsp in pt_regs->sp on SYSCALL64 fastpath

[Denys Vlasenko]

On Mon, Mar 9, 2015 at 9:11 PM, Andy Lutomirski  wrote:
>> @@ -253,11 +247,13 @@ GLOBAL(system_call_after_swapgs)
>>  */
>> ENABLE_INTERRUPTS(CLBR_NONE)
>> ALLOC_PT_GPREGS_ON_STACK 8  /* +8: space for orig_ax */
>> +   movq%rcx,RIP(%rsp)
>> +   movqPER_CPU_VAR(old_rsp),%rcx
>> +   movq%r11,EFLAGS(%rsp)
>> +   movq%rcx,RSP(%rsp)
>> +   movq_cfi rax,ORIG_RAX
>> SAVE_C_REGS_EXCEPT_RAX_RCX_R11
>> movq$-ENOSYS,RAX(%rsp)
>> -   movq_cfi rax,ORIG_RAX
>> -   movq%r11,EFLAGS(%rsp)
>> -   movq%rcx,RIP(%rsp)
>
> Why the reordering?

No strong reason.

iret stack is "above" the rest of pt_regs.

This does not matter now, but when/if we convert to PUSHes
for register saving, pushes which build iret frame
will have to be before "save C-clobbered registers" part,
exactly as in this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/3] staging: panel: return register value

[Willy Tarreau]

On Mon, Mar 09, 2015 at 08:08:24PM +0530, Sudip Mukherjee wrote:
> we were returning success even if the module failed to register.
> now we are returning the actual return value, success or error.
> 
> Signed-off-by: Sudip Mukherjee 

Thanks for this.

Acked-by: Willy Tarreau 

Willy

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

[PATCH v3 -next 02/11] serial: core: Fix kernel doc for uart_console_write()

[Peter Hurley]

'/**' is required to start a kernel-doc comment block.

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/serial_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 3f823c26..373cfde 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1766,7 +1766,7 @@ static const struct file_operations uart_proc_fops = {
 #endif
 
 #if defined(CONFIG_SERIAL_CORE_CONSOLE) || defined(CONFIG_CONSOLE_POLL)
-/*
+/**
  * uart_console_write - write a console message to a serial port
  * @port: the port to write the message
  * @s: array of characters
-- 
2.3.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/

[GIT] Networking

[David Miller]

1) nft_compat accidently truncates ethernet protocol to 8-bits, from
   Arturo Borrero.

2) Memory leak in ip_vs_proc_conn(), from Julian Anastasov.

3) Don't allow the space required for nftables rules to exceed the
   maximum value representable in the dlen field.  From Patrick
   McHardy.

4) bcm63xx_enet can accidently leave interrupts permanently disabled
   due to errors in the NAPI polling exit logic.  Fix from
   Nicolas Schichan.

5) Fix OOPSes triggerable by the ping protocol module, due to missing
   address family validations etc.  From Lorenzo Colitti.

6) Don't use RCU locking in sleepable context in team driver, from
   Jiri Pirko.

7) xen-netback miscalculates statistic offset pointers when reporting
   the stats to userspace.  From David Vrabel.

8) Fix a leak of up to 256 pages per VIF destroy in xen-netaback,
   also from David Vrabel.

9) ip_check_defrag() cannot assume that skb_network_offset(),
   particularly when it is used by the AF_PACKET fanout defrag code.
   From Alexander Drozdov.

10) gianfar driver doesn't query OF node names properly when trying to
determine the number of hw queues available.  Fix it to explicitly
check for OF nodes named queue-group.  From Tobias Waldekranz.

11) MID field in macb driver should be 12 bits, not 16.  From Punnaiah
Choudary Kalluri.

12) Fix unintentional regression in traceroute due to timestamp socket
option changes.  Empty ICMP payloads should be allowed in
non-timestamp cases.  From Willem de Bruijn.

13) When devices are unregistered, we have to get rid of AF_PACKET
multicast list entries that point to it via ifindex.  Fix from
Francesco Ruggeri.

Please pull, thanks a lot!

The following changes since commit 6587457b4b3d663b237a0f95ddf6e67d1828c8ea:

  Merge tag 'dma-buf-for-4.0-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf (2015-03-04 
09:59:51 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master

for you to fetch changes up to e6441bae326271090755e1707196ad05aa1dc703:

  tipc: fix bug in link failover handling (2015-03-09 16:20:41 -0400)


Ahmed S. Darwish (2):
  can: kvaser_usb: Avoid double free on URB submission failures
  can: kvaser_usb: Read all messages in a bulk-in URB buffer

Alexander Drozdov (1):
  ipv4: ip_check_defrag should not assume that skb_network_offset is zero

Alexey Brodkin (1):
  stmmac: check IRQ availability early on probe

Arnd Bergmann (1):
  ARM: fix typos in smc91x platform data

Arturo Borrero (1):
  netfilter: nft_compat: don't truncate ethernet protocol type to u8

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

David S. Miller (4):
  Merge branch 'xgene'
  Merge branch 'xen-netback'
  Merge git://git.kernel.org/.../pablo/nf
  Merge tag 'linux-can-fixes-for-4.0-20150309' of 
git://git.kernel.org/.../mkl/linux-can

David Vrabel (3):
  xen-netback: return correct ethtool stats
  xen-netback: unref frags when handling a from-guest skb with a frag list
  xen-netback: refactor xenvif_handle_frag_list()

Eric Dumazet (1):
  tcp: align tcp_xmit_size_goal() on tcp_tso_autosize()

Florian Fainelli (1):
  net: bcmgenet: properly disable password matching

Francesco Ruggeri (1):
  net: delete stale packet_mclist entries

Fugang Duan (1):
  net: fec: fix rcv is not last issue when do suspend/resume test

Iyappan Subramanian (3):
  Documentation: dts: Update compatible field description for APM X-Gene
  dtb: change binding name to match with newer firmware DT
  drivers: net: xgene: fix new firmware backward compatibility with older 
driver

Jiri Pirko (1):
  team: don't traverse port list using rcu in team_set_mac_address

Jon Paul Maloy (1):
  tipc: fix bug in link failover handling

Josh Cartwright (1):
  net: macb: constify macb configuration data

Julian Anastasov (1):
  ipvs: add missing ip_vs_pe_put in sync code

Lorenzo Colitti (1):
  net: ping: Return EAFNOSUPPORT when appropriate.

Marc Kleine-Budde (2):
  MAINTAINERS: linux-can moved to github
  MAINTAINERS: add Marc Kleine-Budde as co maintainer for CAN networking 
layer

Mark Salter (1):
  net: eth: xgene: fix booting with devicetree

Nicolas Schichan (1):
  bcm63xx_enet: fix poll callback.

Oliver Hartkopp (1):
  can: add missing initialisations in CAN related skbuffs

Pablo Neira Ayuso (3):
  netfilter: nf_tables: fix addition/deletion of elements from commit/abort
  Merge https://git.kernel.org/.../horms/ipvs
  netfilter: nf_tables: fix error handling of rule replacement

Patrick McHardy (3):
  netfilter: nf_tables: fix transaction race condition
  netfilter: nf_tables: check for overflow of rule dlen field
  netfilter: nf_tables: fix userd

[PATCH v3 -next 01/11] console: Add extensible console matching

[Peter Hurley]

Add match() method to struct console which allows the console to
perform console command line matching instead of (or in addition to)
default console matching (ie., by fixed name and index).

The match() method returns 0 to indicate a successful match; normal
console matching occurs if no match() method is defined or the
match() method returns non-zero. The match() method is expected to set
the console index if required.

Re-implement earlycon-to-console-handoff with direct matching of
"console=uart|uart8250,..." to the 8250 ttyS console.

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/8250/8250_core.c  | 64 +++-
 drivers/tty/serial/8250/8250_early.c | 23 -
 include/linux/console.h  |  3 +-
 include/linux/serial_8250.h  |  2 --
 kernel/printk/printk.c   | 52 ++---
 5 files changed, 67 insertions(+), 77 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index e3b9570a..5eb95fd 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -3337,9 +3337,54 @@ static int serial8250_console_setup(struct console *co, 
char *options)
return uart_set_options(port, co, baud, parity, bits, flow);
 }
 
-static int serial8250_console_early_setup(void)
+/**
+ * serial8250_console_match - non-standard console matching
+ * @co:  registering console
+ * @name:name from console command line
+ * @idx: index from console command line
+ * @options: ptr to option string from console command line
+ *
+ * Only attempts to match console command lines of the form:
+ * console=uart<>,io|mmio|mmio32,,
+ * console=uart<>,,options
+ * This form is used to register an initial earlycon boot console and
+ * replace it with the serial8250_console at 8250 driver init.
+ *
+ * Performs console setup for a match (as required by interface)
+ *
+ * Returns 0 if console matches; otherwise non-zero to use default matching
+ */
+static int serial8250_console_match(struct console *co, char *name, int idx,
+   char *options)
 {
-   return serial8250_find_port_for_earlycon();
+   char match[] = "uart";  /* 8250-specific earlycon name */
+   unsigned char iotype;
+   unsigned long addr;
+   int i;
+
+   if (strncmp(name, match, 4) != 0)
+   return -ENODEV;
+
+   if (uart_parse_earlycon(options, &iotype, &addr, &options))
+   return -ENODEV;
+
+   /* try to match the port specified on the command line */
+   for (i = 0; i < nr_uarts; i++) {
+   struct uart_port *port = &serial8250_ports[i].port;
+
+   if (port->iotype != iotype)
+   continue;
+   if ((iotype == UPIO_MEM || iotype == UPIO_MEM32) &&
+   (port->mapbase != addr))
+   continue;
+   if (iotype == UPIO_PORT && port->iobase != addr)
+   continue;
+
+   co->index = i;
+   return serial8250_console_setup(co, options);
+   }
+
+   return -ENODEV;
 }
 
 static struct console serial8250_console = {
@@ -3347,7 +3392,7 @@ static struct console serial8250_console = {
.write  = serial8250_console_write,
.device = uart_console_device,
.setup  = serial8250_console_setup,
-   .early_setup= serial8250_console_early_setup,
+   .match  = serial8250_console_match,
.flags  = CON_PRINTBUFFER | CON_ANYTIME,
.index  = -1,
.data   = &serial8250_reg,
@@ -3361,19 +3406,6 @@ static int __init serial8250_console_init(void)
 }
 console_initcall(serial8250_console_init);
 
-int serial8250_find_port(struct uart_port *p)
-{
-   int line;
-   struct uart_port *port;
-
-   for (line = 0; line < nr_uarts; line++) {
-   port = &serial8250_ports[line].port;
-   if (uart_match_port(p, port))
-   return line;
-   }
-   return -ENODEV;
-}
-
 #define SERIAL8250_CONSOLE &serial8250_console
 #else
 #define SERIAL8250_CONSOLE NULL
diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index c31a22b..49bca65 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -173,26 +173,3 @@ int __init setup_early_serial8250_console(char *cmdline)
 
return setup_earlycon(cmdline, match, early_serial8250_setup);
 }
-
-int serial8250_find_port_for_earlycon(void)
-{
-   struct earlycon_device *device = early_device;
-   struct uart_port *port = device ? &device->port : NULL;
-   int line;
-   int ret;
-
-   if (!port || (!port->membase && !port->iobase))
-   return -ENODEV;
-
-   line = serial8250_find_port(port);
- 

Re: [PATCH v2] MTD: cfi: reduce stack size

[Sergei Shtylyov]

Hello.

On 3/9/2015 10:34 PM, Arnd Bergmann wrote:


The cfi_staa_write_buffers function uses a large amount of kernel stack
whenever CONFIG_MTD_MAP_BANK_WIDTH_32 is set, and that results in a
warning on ARM allmodconfig builds:



drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers':
drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1208 
bytes is larger than 1024 bytes [-Wframe-larger-than=]



It turns out that this is largely a result of a suboptimal implementation
of map_word_andequal(). Replacing this function with a straightforward
one reduces the stack size in this function by exactly 200 bytes,
shrinks the .text segment for this file from 27648 bytes to 26608 bytes,
and makes the warning go away.



Signed-off-by: Arnd Bergmann 



diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 5f487d776411..7b5841663d4f 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -314,7 +314,15 @@ static inline map_word map_word_or(struct map_info *map, 
map_word val1, map_word
return r;
  }

-#define map_word_andequal(m, a, b, z) map_word_equal(m, z, map_word_and(m, a, 
b))
+static inline int map_word_andequal(struct map_info *map, map_word val1, 
map_word val2, map_word val3)
+{
+   int i;


   I think empty line is needed here.


+   for (i=0; i < map_words(map); i++) {


   Could you please be consistent and surround all binary operators with 
spaces, like on the line below?



+   if ((val1.x[i] & val2.x[i]) != val3.x[i])
+   return 0;
+   }
+   return 1;
+}

[...]

WBR, Sergei

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

[PATCH v3 -next 05/11] serial: 8250_early: Assume uart already initialized if no baud option

[Peter Hurley]

The  option string is not supplied if the earlycon
is started via devicetree and OF_EARLYCON_DECLARE(). The option string
is also not required if started via kernel command line parameters of
the form:
  earlycon=uart,mmio,
  console=uart,mmio,

If earlycon_device->baud is 0, then an option string was not supplied.
In this case, assume the uart has already been initialized by the
bootloader or firmware.

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/8250/8250_early.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index d7b831b..1701d00 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -149,12 +149,18 @@ static int __init early_serial8250_setup(struct 
earlycon_device *device,
return 0;
 
if (!device->baud) {
+   struct uart_port *port = &device->port;
+   unsigned int ier;
+
device->baud = probe_baud(&device->port);
snprintf(device->options, sizeof(device->options), "%u",
 device->baud);
-   }
 
-   init_port(device);
+   /* assume the device was initialized, only mask interrupts */
+   ier = serial8250_early_in(port, UART_IER);
+   serial8250_early_out(port, UART_IER, ier & UART_IER_UUE);
+   } else
+   init_port(device);
 
device->con->write = early_serial8250_write;
return 0;
-- 
2.3.1

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

[PATCH v3 -next 03/11] serial: 8250_early: Remove early_device variable

[Peter Hurley]

early_device was only required for serial8250_find_port_for_earlycon(),
which was replaced by extensible console matching.

Fixup early_serial8250_write() to get the earlycon_device * from
console->data (which is initialized by {of_}setup_earlycon()).

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/8250/8250_early.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index 49bca65..d7b831b 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -36,8 +36,6 @@
 #include 
 #include 
 
-static struct earlycon_device *early_device;
-
 unsigned int __weak __init serial8250_early_in(struct uart_port *port, int 
offset)
 {
switch (port->iotype) {
@@ -90,7 +88,8 @@ static void __init serial_putc(struct uart_port *port, int c)
 static void __init early_serial8250_write(struct console *console,
const char *s, unsigned int count)
 {
-   struct uart_port *port = &early_device->port;
+   struct earlycon_device *device = console->data;
+   struct uart_port *port = &device->port;
unsigned int ier;
 
/* Save the IER and disable interrupts preserving the UUE bit */
@@ -157,7 +156,6 @@ static int __init early_serial8250_setup(struct 
earlycon_device *device,
 
init_port(device);
 
-   early_device = device;
device->con->write = early_serial8250_write;
return 0;
 }
-- 
2.3.1

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

[PATCH v3 -next 11/11] serial: 8250_early: Remove setup_early_serial8250_console()

[Peter Hurley]

setup_earlycon() will now match and register the desired earlycon
from the param string (as if 'earlycon=...' had been set on the
command line). Use setup_earlycon() from existing arch call sites
which start an earlycon directly.

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 arch/mips/mti-malta/malta-init.c | 4 ++--
 drivers/firmware/pcdp.c  | 4 ++--
 drivers/tty/serial/8250/8250_early.c | 5 -
 include/linux/serial_8250.h  | 1 -
 4 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/mips/mti-malta/malta-init.c b/arch/mips/mti-malta/malta-init.c
index 6849f53..cec3e18 100644
--- a/arch/mips/mti-malta/malta-init.c
+++ b/arch/mips/mti-malta/malta-init.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -75,7 +75,7 @@ static void __init console_config(void)
if ((strstr(fw_getcmdline(), "earlycon=")) == NULL) {
sprintf(console_string, "uart8250,io,0x3f8,%d%c%c", baud,
parity, bits);
-   setup_early_serial8250_console(console_string);
+   setup_earlycon(console_string);
}
 
if ((strstr(fw_getcmdline(), "console=")) == NULL) {
diff --git a/drivers/firmware/pcdp.c b/drivers/firmware/pcdp.c
index a330492..75273a25 100644
--- a/drivers/firmware/pcdp.c
+++ b/drivers/firmware/pcdp.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include "pcdp.h"
 
@@ -43,7 +43,7 @@ setup_serial_console(struct pcdp_uart *uart)
}
 
add_preferred_console("uart", 8250, &options[9]);
-   return setup_early_serial8250_console(options);
+   return setup_earlycon(options);
 #else
return -ENODEV;
 #endif
diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index d272139..a2b4e58 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -167,8 +167,3 @@ static int __init early_serial8250_setup(struct 
earlycon_device *device,
 }
 EARLYCON_DECLARE(uart8250, early_serial8250_setup);
 EARLYCON_DECLARE(uart, early_serial8250_setup);
-
-int __init setup_early_serial8250_console(char *cmdline)
-{
-   return setup_earlycon(cmdline);
-}
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index f26ae7f..ca9f87b 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -120,7 +120,6 @@ extern int early_serial_setup(struct uart_port *port);
 
 extern unsigned int serial8250_early_in(struct uart_port *port, int offset);
 extern void serial8250_early_out(struct uart_port *port, int offset, int 
value);
-extern int setup_early_serial8250_console(char *cmdline);
 extern void serial8250_do_set_termios(struct uart_port *port,
struct ktermios *termios, struct ktermios *old);
 extern int serial8250_do_startup(struct uart_port *port);
-- 
2.3.1

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

[PATCH v3 -next 07/11] serial: earlycon: Ignore parse_options() error code

[Peter Hurley]

Because setup_earlycon() continues to attempt console registration
if an error occurred parsing the option string, the actual value of
the error code from parse_options() is ignored.

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/earlycon.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 0480c8f..da5e8c8 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -114,9 +114,8 @@ int __init setup_earlycon(char *buf, const char *match,
 
buf += len + 1;
 
-   err = parse_options(&early_console_dev, buf);
/* On parsing error, pass the options buf to the setup function */
-   if (!err)
+   if (!parse_options(&early_console_dev, buf))
buf = NULL;
 
port->uartclk = BASE_BAUD * 16;
-- 
2.3.1

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

[PATCH v3 -next 06/11] serial: 8250_early: Fix setup() error code

[Peter Hurley]

If parsing failed to decode a valid uart addr, return -ENODEV instead
of success. Although setup_earlycon() will detect the failure anyway
(because the write() method has not been set), that behavior is not
obvious and should not be relied on.

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/8250/8250_early.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index 1701d00..b199c10 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -146,7 +146,7 @@ static int __init early_serial8250_setup(struct 
earlycon_device *device,
 const char *options)
 {
if (!(device->port.membase || device->port.iobase))
-   return 0;
+   return -ENODEV;
 
if (!device->baud) {
struct uart_port *port = &device->port;
-- 
2.3.1

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

[PATCH v3 -next 08/11] serial: earlycon: Skip parse_options() if empty string

[Peter Hurley]

Earlycon param strings of the form
   earlycon=
are rejected from parse_options() with an error (which, in turn,
results in a NULL argument for the setup() method options parameter).

Only pass non-empty string to parse_options(); this will enable
handling actual parse errors differently than expected and allow
formats.

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/earlycon.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index da5e8c8..025ea01 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -109,13 +109,16 @@ int __init setup_earlycon(char *buf, const char *match,
len = strlen(match);
if (strncmp(buf, match, len))
return 0;
-   if (buf[len] && (buf[len] != ','))
-   return 0;
 
-   buf += len + 1;
+   if (buf[len]) {
+   if (buf[len] != ',')
+   return 0;
+   buf += len + 1;
+   } else
+   buf = NULL;
 
/* On parsing error, pass the options buf to the setup function */
-   if (!parse_options(&early_console_dev, buf))
+   if (buf && !parse_options(&early_console_dev, buf))
buf = NULL;
 
port->uartclk = BASE_BAUD * 16;
-- 
2.3.1

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

[PATCH v3 -next 09/11] serial: earlycon: Refactor earlycon registration

[Peter Hurley]

Separate earlycon matching from registration; add register_earlycon
which initializes and registers the matched earlycon.

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/earlycon.c | 42 +-
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 025ea01..9fb76b6 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -96,27 +96,13 @@ static int __init parse_options(struct earlycon_device 
*device, char *options)
return 0;
 }
 
-int __init setup_earlycon(char *buf, const char *match,
- int (*setup)(struct earlycon_device *, const char *))
+
+static int __init
+register_earlycon(char *buf, int (*setup)(struct earlycon_device *, const char 
*))
 {
int err;
-   size_t len;
struct uart_port *port = &early_console_dev.port;
 
-   if (!buf || !match || !setup)
-   return 0;
-
-   len = strlen(match);
-   if (strncmp(buf, match, len))
-   return 0;
-
-   if (buf[len]) {
-   if (buf[len] != ',')
-   return 0;
-   buf += len + 1;
-   } else
-   buf = NULL;
-
/* On parsing error, pass the options buf to the setup function */
if (buf && !parse_options(&early_console_dev, buf))
buf = NULL;
@@ -136,6 +122,28 @@ int __init setup_earlycon(char *buf, const char *match,
return 0;
 }
 
+int __init setup_earlycon(char *buf, const char *match,
+ int (*setup)(struct earlycon_device *, const char *))
+{
+   size_t len;
+
+   if (!buf || !match || !setup)
+   return 0;
+
+   len = strlen(match);
+   if (strncmp(buf, match, len))
+   return 0;
+
+   if (buf[len]) {
+   if (buf[len] != ',')
+   return 0;
+   buf += len + 1;
+   } else
+   buf = NULL;
+
+   return register_earlycon(buf, setup);
+}
+
 int __init of_setup_earlycon(unsigned long addr,
 int (*setup)(struct earlycon_device *, const char 
*))
 {
-- 
2.3.1

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

[PATCH v3 -next 10/11] serial: earlycon: Enable earlycon without command line param

[Peter Hurley]

Earlycon matching can only be triggered if 'earlycon=...' has been
specified on the kernel command line. To workaround this limitation
requires tight coupling between arches and specific serial drivers
in order to start an earlycon. Devicetree avoids this limitation
with a link table that contains the required data to match earlycons.

Mirror this approach for earlycon match by name. Re-purpose
EARLYCON_DECLARE to generate a table entry which associates name with
setup() function. Re-purpose setup_earlycon() to scan this table for
an earlycon match, which is registered if found.

Declare one "earlycon" early_param, which calls setup_earlycon().

This design allows setup_earlycon() to be called directly with a
param string (as if 'earlycon=...' had been set on the command line).
Re-registration (either directly or by early_param) is prevented.

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/8250/8250_early.c |  7 +--
 drivers/tty/serial/earlycon.c| 92 
 include/asm-generic/vmlinux.lds.h|  9 
 include/linux/serial_core.h  | 19 
 4 files changed, 94 insertions(+), 33 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index b199c10..d272139 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -170,10 +170,5 @@ EARLYCON_DECLARE(uart, early_serial8250_setup);
 
 int __init setup_early_serial8250_console(char *cmdline)
 {
-   char match[] = "uart8250";
-
-   if (cmdline && cmdline[4] == ',')
-   match[4] = '\0';
-
-   return setup_earlycon(cmdline, match, early_serial8250_setup);
+   return setup_earlycon(cmdline);
 }
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 9fb76b6..5fdc9f3 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -10,6 +10,9 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -34,6 +37,10 @@ static struct earlycon_device early_console_dev = {
.con = &early_con,
 };
 
+extern struct earlycon_id __earlycon_table[];
+static const struct earlycon_id __earlycon_table_sentinel
+   __used __section(__earlycon_table_end);
+
 static const struct of_device_id __earlycon_of_table_sentinel
__used __section(__earlycon_of_table_end);
 
@@ -96,9 +103,7 @@ static int __init parse_options(struct earlycon_device 
*device, char *options)
return 0;
 }
 
-
-static int __init
-register_earlycon(char *buf, int (*setup)(struct earlycon_device *, const char 
*))
+static int __init register_earlycon(char *buf, const struct earlycon_id *match)
 {
int err;
struct uart_port *port = &early_console_dev.port;
@@ -112,7 +117,7 @@ register_earlycon(char *buf, int (*setup)(struct 
earlycon_device *, const char *
port->membase = earlycon_map(port->mapbase, 64);
 
early_console_dev.con->data = &early_console_dev;
-   err = setup(&early_console_dev, buf);
+   err = match->setup(&early_console_dev, buf);
if (err < 0)
return err;
if (!early_console_dev.con->write)
@@ -122,27 +127,76 @@ register_earlycon(char *buf, int (*setup)(struct 
earlycon_device *, const char *
return 0;
 }
 
-int __init setup_earlycon(char *buf, const char *match,
- int (*setup)(struct earlycon_device *, const char *))
+/**
+ * setup_earlycon - match and register earlycon console
+ * @buf:   earlycon param string
+ *
+ * Registers the earlycon console matching the earlycon specified
+ * in the param string @buf. Acceptable param strings are of the form
+ *,io|mmio|mmio32,,
+ *,0x,
+ *,
+ *
+ *
+ * Only for the third form does the earlycon setup() method receive the
+ *  string in the 'options' parameter; all other forms set
+ * the parameter to NULL.
+ *
+ * Returns 0 if an attempt to register the earlycon was made,
+ * otherwise negative error code
+ */
+int __init setup_earlycon(char *buf)
 {
-   size_t len;
+   const struct earlycon_id *match;
 
-   if (!buf || !match || !setup)
-   return 0;
+   if (!buf || !buf[0])
+   return -EINVAL;
 
-   len = strlen(match);
-   if (strncmp(buf, match, len))
-   return 0;
+   if (early_con.flags & CON_ENABLED)
+   return -EALREADY;
 
-   if (buf[len]) {
-   if (buf[len] != ',')
-   return 0;
-   buf += len + 1;
-   } else
-   buf = NULL;
+   for (match = __earlycon_table; match->name[0]; match++) {
+   size_t len = strlen(match->name);
 
-   return register_earlycon(buf, setup);
+   if (strncmp(buf, match->nam

[PATCH v3 -next 00/11] Extensible console matching & direct earlycon

[Peter Hurley]

Changes from v2:
* remainder of unapplied series
* Changed the title and commit log for
  "serial: earlycon: Allow earlycon params with name only" to
  "serial: earlycon: Skip parse_options() for empty string" per Rob's
  comment.

Changes from v1:
* rebased on and requires "console: Fix console name size mismatch"


Hi Greg & Andrew,

This patch series implements:
  1. console-definable (aka extensible) matching
  2. generic earlycon-to-console handoff via extensible matching
  3. arch/prom support for direct earlycon


Extensible console matching

Extensible console matching enables the console itself to define the
conditions for a "command line" match. This mimics the design of
device matching in the driver model. Two important use-cases which this
feature enables are generic earlycon-to-console handoff and support
for driver migration.

Earlycon-to-console handoff was implemented in 2007. Console command
lines of the form:
   console=uart,io,0x3f8,115200n8
start an earlycon and later allow the 8250 driver console to takeover.
Unfortunately this implementation requires direct coupling between
the earlycon and the console and is facilitated by ugly hacks like
editing the console command line in-place.

Extensible console matching allows the 8250 driver to directly match
that console command line instead, and enables other serial drivers
to trivially support console handoff themselves.

In addition, extensible console matching allows a new driver to
provide support for a different driver's console. This requirement
stems from needing to minimize breakage when migrating serial drivers.
Since many devices are based on the original 8250/16550 designs
but sometimes have features incompatible with the existing 8250 driver
support, the initial driver is often standalone. When/if the standalone
driver is migrated to the 8250 driver, the problem of console names in
the command line remains. Extensible console matching enables a simple
migration path.


Direct earlycon

This feature enables arches and proms to start an earlycon directly,
rather than requiring an "earlycon=" command line parameter.
Devicetree can already do this via the 'linux,stdout-path' property,
but arch and prom code requires direct coupling to the serial driver.

This support is implemented by judicious refactoring and the same
construct that devicetree and early_param use: a link table containing
the necessary information (name and setup() function) to find and
bind the appropriate earlycon "driver".


NB: I combined these two features in this series because their
implementations heavily overlap in the same source files.

Regards,

Peter Hurley (11):
  console: Add extensible console matching
  serial: core: Fix kernel doc for uart_console_write()
  serial: 8250_early: Remove early_device variable
  serial: earlycon: Move ->uartclk initialize
  serial: 8250_early: Assume uart already initialized if no baud option
  serial: 8250_early: Fix setup() error code
  serial: earlycon: Ignore parse_options() error code
  serial: earlycon: Skip parse_options() if empty string
  serial: earlycon: Refactor earlycon registration
  serial: earlycon: Enable earlycon without command line param
  serial: 8250_early: Remove setup_early_serial8250_console()

 arch/mips/mti-malta/malta-init.c |   4 +-
 drivers/firmware/pcdp.c  |   4 +-
 drivers/tty/serial/8250/8250_core.c  |  64 --
 drivers/tty/serial/8250/8250_early.c |  51 --
 drivers/tty/serial/earlycon.c| 101 ---
 drivers/tty/serial/serial_core.c |   2 +-
 include/asm-generic/vmlinux.lds.h|   9 
 include/linux/console.h  |   3 +-
 include/linux/serial_8250.h  |   3 --
 include/linux/serial_core.h  |  19 ---
 kernel/printk/printk.c   |  52 +++---
 11 files changed, 185 insertions(+), 127 deletions(-)

-- 
2.3.1

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

[PATCH v3 -next 04/11] serial: earlycon: Move ->uartclk initialize

[Peter Hurley]

Initializing the ->uartclk field is not related to option parsing;
relocate from parse_options() to setup_earlycon() (which mirrors the
behavior of of_setup_earlycon()).

Acked-by: Rob Herring 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/earlycon.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 58d6bcd..0480c8f 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -76,8 +76,6 @@ static int __init parse_options(struct earlycon_device 
*device, char *options)
return -EINVAL;
}
 
-   port->uartclk = BASE_BAUD * 16;
-
if (options) {
device->baud = simple_strtoul(options, NULL, 0);
length = min(strcspn(options, " ") + 1,
@@ -121,6 +119,7 @@ int __init setup_earlycon(char *buf, const char *match,
if (!err)
buf = NULL;
 
+   port->uartclk = BASE_BAUD * 16;
if (port->mapbase)
port->membase = earlycon_map(port->mapbase, 64);
 
-- 
2.3.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] crypto: qat - remove incorrect __exit markup

[Dmitry Torokhov]

PCI bus is hot-pluggable, and even if it wasn't one can still unbind the
device from driver via sysfs, so we should not make driver's remove
method as __exit.

Signed-off-by: Dmitry Torokhov 
---
 drivers/crypto/qat/qat_dh895xcc/adf_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/qat/qat_dh895xcc/adf_drv.c 
b/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
index 8ffdb95..e7af9d5 100644
--- a/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
+++ b/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
@@ -379,7 +379,7 @@ out_err:
return ret;
 }
 
-static void __exit adf_remove(struct pci_dev *pdev)
+static void adf_remove(struct pci_dev *pdev)
 {
struct adf_accel_dev *accel_dev = adf_devmgr_pci_to_accel_dev(pdev);
 
-- 
2.2.0.rc0.207.ga3a616c


-- 
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: RCU stalls on heavy socket traffic

[Sebastian Andrzej Siewior]

On 03/09/2015 07:02 PM, Paul E. McKenney wrote:
> abaf3f9d275b (rcu: Revert "Allow post-unlock reference for rt_mutex" to avoid 
> priority-inversion)
> 
> This patch fixed a priority-inversion problem, so might well fix your
> RCU CPU stall-warning problem.

Yes, it fixes the problem. Thank you.

>   Thanx, Paul
> 

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 0/3] clk: divider: three exactness fixes (and a rant)

[Uwe Kleine-König]

Hello Stephen,

On Mon, Mar 09, 2015 at 12:05:34PM -0700, Stephen Boyd wrote:
> On 03/09/15 02:58, Philipp Zabel wrote:
> > Am Freitag, den 06.03.2015, 11:40 -0800 schrieb Stephen Boyd:
> >> On 03/06/15 11:28, Uwe Kleine-König wrote:
> >>> Hello Mike,
> >>>
> >>> On Fri, Mar 06, 2015 at 10:57:30AM -0800, Mike Turquette wrote:
>  Quoting Uwe Kleine-König (2015-02-21 02:40:22)
> > Hello,
> >
> > TLDR: only apply patch 1 and rip of CLK_DIVIDER_ROUND_CLOSEST.
> >
> > I stared at clk-divider.c for some time now given Sascha's failing test
> > case. I found a fix for the failure (which happens to be what Sascha
> > suspected).
> >
> > The other two patches fix problems only present when handling dividers
> > that have CLK_DIVIDER_ROUND_CLOSEST set. Note that these are still
> > heavily broken however. So having a 4bit-divider and a parent clk of
> > 1 (as in Sascha's test case) requesting
> >
> > clk_set_rate(clk, 666)
> >
> > sets the rate to 625 (div=15) instead of 667 (div=16). The reason is the
> > choice of parent_rate in clk_divider_bestdiv's loop is wrong for
> > CLK_DIVIDER_ROUND_CLOSEST (with and without patch 1). A fix here is
> > non-trivial and for sure more than one rate must be tested here. This is
> > complicated by the fact that clk_round_rate might return a value bigger
> > than the requested rate which convinces me (once more) that it's a bad
> > idea to allow that. Even if this was fixed for .round_rate,
> > clk_divider_set_rate is still broken because it also uses
> >
> > div = DIV_ROUND_UP(parent_rate, rate);
> >
> > to calculate the (pretended) best divider to get near rate.
> >
> > Note this makes at least two reasons to remove support for
> > CLK_DIVIDER_ROUND_CLOSEST!
> >
> > Instead I'd favour creating a function
> >
> > clk_round_rate_nearest
> >
> > as was suggested some time ago by Soren Brinkmann and me[1] that doesn't
>  Uwe,
> 
>  Thanks for the fixes. I'm thinking of taking all three for 4.0. I also
>  agree on clk_round_rate_nearest (along with a _ceil and _floor version
>  as well). That's something we can do for 4.1 probably.
> >>> I'd say that we make round_rate the _floor version. I guess in most
> >>> cases that already does the right thing. Also I think 4.1 is very
> >>> ambitious, so my suggestion for 4.1 is:
> >>>
> >>>  - add a WARN_ON_ONCE to clk_round_rate catching calls that return a
> >>>value bigger than requested.
> >>>  - implement clk_round_rate_nearest using clk_round_rate and the
> >>>assumption that it returns a value that is <= the requested rate.
> >>>I think without that there are too many special cases to handle and
> >>>probably not even a reliable way to determine the nearest rate.
> >>>  - while we're at it tightening the requirements for clk_round_rate
> >>>let's also specify the expected rounding. I'd vote for the
> >>>mathematical rounding, that is
> >>>
> >>>   clk_round_rate(someclk, 333)
> >>>
> >>>explicitly is allowed to return a rate bigger than 333 as long as it
> >>>is less than 333.5.
> >>>
> >>> At one point while developing patch 1 I had the dividers fixed for the
> >>> rounding issue. I think I still have that patch somewhere so can post it
> >>> as RFC.
> >>>
> >> Why do we need clk_round_rate_nearest? We have rate constraints now so
> >> drivers should be moving towards requesting a rate that's within a
> >> tolerance they can accept if they even care to enforce anything like
> >> that. Eventually clk_round_rate() returning a value smaller or larger
> >> than what it's called with won't matter as long as what the
> >> implementation does fits within the constraints that consumers specify.
> >> It may even be possible to remove clk_round_rate() as a consumer API.
> > If I have to provide a panel pixel clock I usually want to get a rate as
> > close as possible to the specified typical rate, but within the
> > specified limits.
> >
> > Assume a panel with 70 MHz ideal pixel clock and a valid range of 60 MHz
> > to 80 MHz. If the clock supply supports two frequencies within that
> > range, 60 MHz and 72 MHz, I'd prefer 72 MHz to be chosen over 60 Mhz.
> >
> >
> 
> Hm.. Maybe we should tweak the arguments to clk_set_range() to have a
> "typical" rate? So instead of the current API:
> 
>   int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned
> long max)

Looking at the current implementation of clk_set_rate_range I wonder how
it should be used. The "usual" code flow goes through

ret = clk_core_set_rate_nolock(clk->core, clk->core->req_rate);

without modifying clk->core->req_rate first. So after

clk_set_rate(clk, 50);

a call to

clk_set_rate_range(clk, 100, 200);

returns -EINVAL (at least if determine_rate isn't implemented). Is
this intended? This even happens if th

Re: [PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size

[Borislav Petkov]

On Mon, Mar 09, 2015 at 01:06:00PM -0700, Yinghai Lu wrote:
> Yes. Just to emphasize that  " We need to make sure [z_extra_offset,
> init_size) will fit ZO"

So you want to say:

"We need to make sure the compressed kernel fits in the interval
[z_extra_offset, z_extra_offset + init_size)"

?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] net: delete stale packet_mclist entries

[David Miller]

From: frugg...@aristanetworks.com (Francesco Ruggeri)
Date: Mon, 09 Mar 2015 12:09:52 -0700

> From ce9a4f202723f6ba1b18bc7c4a258c130c1f4148 Mon Sep 17 00:00:00 2001
> From: Francesco Ruggeri 
> Date: Mon, 9 Mar 2015 11:51:04 -0700
> Subject: [PATCH 1/1] net: delete stale packet_mclist entries
> 
> When an interface is deleted from a net namespace the ifindex in the
> corresponding entries in PF_PACKET sockets' mclists becomes stale.
> This can create inconsistencies if later an interface with the same ifindex
> is moved from a different namespace (not that unlikely since ifindexes are
> per-namespace).
> In particular we saw problems with dev->promiscuity, resulting
> in "promiscuity touches roof, set promiscuity failed. promiscuity
> feature of device might be broken" warnings and EOVERFLOW failures of
> setsockopt(PACKET_ADD_MEMBERSHIP).
> This patch deletes the mclist entries for interfaces that are deleted.
> Since this now causes setsockopt(PACKET_DROP_MEMBERSHIP) to fail with
> EADDRNOTAVAIL if called after the interface is deleted, also make
> packet_mc_drop not fail.
> 
> Signed-off-by: Francesco Ruggeri 

Indeed, this is consistent with how we will fail an add of an MC list
entry if the ifindex doesn't resolve to an actual device.

Applied, thanks.

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

Re: [PATCH 1/2] x86_64,signal: Save and restore SS in signal frames

[Andy Lutomirski]

Hi Ingo,

Here's a blast from the past.  I asked Andi today, and he seems
conceptually okay with this.  Could you consider applying it?  Aside
from being a bug fix IMO, it will allow my sigreturn test to work
reasonably well as a native 64-bit program.

I checked: it still applies cleanly.

--Andy

On Fri, Jul 11, 2014 at 9:29 AM, Andy Lutomirski  wrote:
> The comment in the signal code says that apps can save/restore other
> segments on their own.  It's true that apps can *save* SS on their
> own, but there's no way for apps to restore it: SYSCALL effectively
> resets SS to __USER_DS, so any value that user code tries to load
> into SS gets lost on entry to sigreturn.
>
> This recycles two padding bytes in the segment selector area for SS.
>
> I suspect that 64-bit programs that try to run 16-bit code and uses
> signals will have a lot of trouble without this.
>
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/include/asm/sigcontext.h  | 2 +-
>  arch/x86/include/uapi/asm/sigcontext.h | 2 +-
>  arch/x86/kernel/signal.c   | 8 +---
>  3 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/include/asm/sigcontext.h 
> b/arch/x86/include/asm/sigcontext.h
> index 9dfce4e..f910cdc 100644
> --- a/arch/x86/include/asm/sigcontext.h
> +++ b/arch/x86/include/asm/sigcontext.h
> @@ -59,7 +59,7 @@ struct sigcontext {
> unsigned short cs;
> unsigned short gs;
> unsigned short fs;
> -   unsigned short __pad0;
> +   unsigned short ss;
> unsigned long err;
> unsigned long trapno;
> unsigned long oldmask;
> diff --git a/arch/x86/include/uapi/asm/sigcontext.h 
> b/arch/x86/include/uapi/asm/sigcontext.h
> index d8b9f90..076b11f 100644
> --- a/arch/x86/include/uapi/asm/sigcontext.h
> +++ b/arch/x86/include/uapi/asm/sigcontext.h
> @@ -179,7 +179,7 @@ struct sigcontext {
> __u16 cs;
> __u16 gs;
> __u16 fs;
> -   __u16 __pad0;
> +   __u16 ss;
> __u64 err;
> __u64 trapno;
> __u64 oldmask;
> diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
> index 2851d63..08d7a9e 100644
> --- a/arch/x86/kernel/signal.c
> +++ b/arch/x86/kernel/signal.c
> @@ -94,15 +94,8 @@ int restore_sigcontext(struct pt_regs *regs, struct 
> sigcontext __user *sc,
> COPY(r15);
>  #endif /* CONFIG_X86_64 */
>
> -#ifdef CONFIG_X86_32
> COPY_SEG_CPL3(cs);
> COPY_SEG_CPL3(ss);
> -#else /* !CONFIG_X86_32 */
> -   /* Kernel saves and restores only the CS segment register on 
> signals,
> -* which is the bare minimum needed to allow mixed 32/64-bit 
> code.
> -* App's signal handler can save/restore other segments if 
> needed. */
> -   COPY_SEG_CPL3(cs);
> -#endif /* CONFIG_X86_32 */
>
> get_user_ex(tmpflags, &sc->flags);
> regs->flags = (regs->flags & ~FIX_EFLAGS) | (tmpflags & 
> FIX_EFLAGS);
> @@ -164,6 +157,7 @@ int setup_sigcontext(struct sigcontext __user *sc, void 
> __user *fpstate,
> put_user_ex(regs->cs, &sc->cs);
> put_user_ex(0, &sc->gs);
> put_user_ex(0, &sc->fs);
> +   put_user_ex(regs->ss, &sc->ss);
>  #endif /* CONFIG_X86_32 */
>
> put_user_ex(fpstate, &sc->fpstate);
> --
> 1.9.3
>



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

Re: [PATCH v2 3/6] mtd: nand: vf610_nfc: add device tree bindings

[Bill Pringlemeir]

On  9 Mar 2015, ste...@agner.ch wrote:

> Signed-off-by: Bill Pringlemeir 
> Signed-off-by: Stefan Agner 
> ---
> .../devicetree/bindings/mtd/vf610-nfc.txt | 39 ++
> 1 file changed, 39 insertions(+) create mode 100644
> Documentation/devicetree/bindings/mtd/vf610-nfc.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
> b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
> new file mode 100644
> index 000..312c872
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt

[snip]

> +- reg: Address range of the mtd chip 
> +- interrupts: Should contain the STMMAC interrupts 

What is 'STMMAC'?  Is that something I cribbed from another file?  Ah, I
see 'spear_smi.txt' which is an NAND driver with a 'clock-frequency'
parameter (probably before 'assigned-clocks' support).

 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mtd/spear_smi.txt

I don't think 'STMMAC' makes sense.

  +- interrupts: irq to be used

Maybe?  Same as mxc-nand.txt.  It is not so helpful though.

> +- nand-bus-width: see nand.txt
> +- nand-ecc-mode: see nand.txt
> +- nand-on-flash-bbt: see nand.txt 
> +- clock-frequency : Optional clock rate to NFC in Hz

I guess this changed?  We might want to put a note about what kind of
impact this might have on the bus.  Ie,

 assigned-clocks: Input SOC clock to the NAND controller.
 assigned-clock-rates: The NAND bus timing is derived from this clock
rate and should not exceed maximum timing for any NAND memory chip
in a board stuffing.  Typical NAND memory timings derived from this
clock are found in the SOC hardware reference manual.
 
Originally, the reason I made this file was because the
'clock-frequency' was non-standard.  I guess it is nice to have it
anyways.

Fwiw,
Bill Pringlemeir.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/9] mtd: pxa3xx_nand: add support for the Marvell Berlin nand controller

[Robert Jarzmik]

Ezequiel Garcia  writes:

>>> Which flash do you have there?
>> The one with 0xba20 id as I said, which is AFAIK a Numonyx NAND02GR4B2C.
>> 
>
> $ grep "0xBA" drivers/mtd/nand/nand_ids.c
> EXTENDED_ID_NAND("NAND 256MiB 1,8V 16-bit", 0xBA, 256, LP_OPTIONS16),
>
> Seems already supported by the NAND core. The MTD way of probing
> a non-ONFI device is by using the IDs in nand_ids.c. Additional
> configuration (timings in this case) is applied between the nand_scan_ident()
> and nand_scan_tail() calls.

Ok, agreed.

I've seen your answer in the "rework timings setup" mail thread. I think you
have perfectly understood what bothers me :)

Cheers.

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

[PATCH] locking/mutex: Refactor mutex_spin_on_owner()

[Jason Low]

This patch applies on top of tip.

---
Similar to what Linus suggested for rwsem_spin_on_owner(), in
mutex_spin_on_owner(), instead of having while (true) and breaking
out of the spin loop on lock->owner != owner, we can have the loop
directly check for while (lock->owner == owner). This improves the
readability of the code.

Signed-off-by: Jason Low 
---
 kernel/locking/mutex.c |   17 +
 1 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 16b2d3c..1c3b7c5 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -224,16 +224,8 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock,
 static noinline
 bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
 {
-   bool ret;
-
rcu_read_lock();
-   while (true) {
-   /* Return success when the lock owner changed */
-   if (lock->owner != owner) {
-   ret = true;
-   break;
-   }
-
+   while (lock->owner == owner) {
/*
 * Ensure we emit the owner->on_cpu, dereference _after_
 * checking lock->owner still matches owner, if that fails,
@@ -242,16 +234,17 @@ bool mutex_spin_on_owner(struct mutex *lock, struct 
task_struct *owner)
 */
barrier();
 
+   /* Stop spinning when need_resched or owner is not running. */
if (!owner->on_cpu || need_resched()) {
-   ret = false;
-   break;
+   rcu_read_unlock();
+   return false;
}
 
cpu_relax_lowlatency();
}
rcu_read_unlock();
 
-   return ret;
+   return true;
 }
 
 /*
-- 
1.7.2.5



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

[PATCH] Staging: dgnc: fix bitmask

[Matteo Semenzato]

From: Matteo Semenzato 

The bitmask should be used on msignals since the signals variable is not
used anywhere in the function.

Signed-off-by: Matteo Semenzato 
---
 drivers/staging/dgnc/dgnc_cls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index bedc522..29c6316 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -1137,7 +1137,7 @@ static void cls_parse_modem(struct channel_t *ch, 
unsigned char signals)
 * Scrub off lower bits. They signify delta's, which I don't
 * care about
 */
-   signals &= 0xf0;
+   msignals &= 0xf0;
 
spin_lock_irqsave(&ch->ch_lock, flags);
if (msignals & UART_MSR_DCD)
-- 
2.3.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 3/4] x86: save user rsp in pt_regs->sp on SYSCALL64 fastpath

[Andy Lutomirski]

On Mon, Mar 9, 2015 at 11:39 AM, Denys Vlasenko  wrote:
> PER_CPU(old_rsp) usage is simplified - now it is used only
> as temp storage, and userspace stack pointer is immediately stored
> in pt_regs->sp on syscall entry, instead of being used later,
> on syscall exit.
>
> Instead of PER_CPU(old_rsp) and task->thread.usersp, C code
> uses pt_regs->sp now.
>
> FIXUP/RESTORE_TOP_OF_STACK are simplified.
>
> Signed-off-by: Denys Vlasenko 
> CC: Linus Torvalds 
> CC: Steven Rostedt 
> CC: Ingo Molnar 
> CC: Borislav Petkov 
> CC: "H. Peter Anvin" 
> CC: Andy Lutomirski 
> CC: Oleg Nesterov 
> CC: Frederic Weisbecker 
> CC: Alexei Starovoitov 
> CC: Will Drewry 
> CC: Kees Cook 
> CC: x...@kernel.org
> CC: linux-kernel@vger.kernel.org

Looks correct.

> @@ -253,11 +247,13 @@ GLOBAL(system_call_after_swapgs)
>  */
> ENABLE_INTERRUPTS(CLBR_NONE)
> ALLOC_PT_GPREGS_ON_STACK 8  /* +8: space for orig_ax */
> +   movq%rcx,RIP(%rsp)
> +   movqPER_CPU_VAR(old_rsp),%rcx
> +   movq%r11,EFLAGS(%rsp)
> +   movq%rcx,RSP(%rsp)
> +   movq_cfi rax,ORIG_RAX
> SAVE_C_REGS_EXCEPT_RAX_RCX_R11
> movq$-ENOSYS,RAX(%rsp)
> -   movq_cfi rax,ORIG_RAX
> -   movq%r11,EFLAGS(%rsp)
> -   movq%rcx,RIP(%rsp)

Why the reordering?

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

[PATCH] Staging: comedi: fix information leak

[Matteo Semenzato]

From: Matteo Semenzato 

The comedi_cmd struct has an hole after chanlist_len that could contain 
uninitialized
memory, this struct is copied to userspace.

Signed-off-by: Matteo Semenato 
---
 drivers/staging/comedi/comedi_fops.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 727640e..1cdf0a2 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -1718,6 +1718,8 @@ static int do_cmdtest_ioctl(struct comedi_device *dev,
unsigned int __user *user_chanlist;
int ret;
 
+   memset(&cmd, 0, sizeof(cmd));
+
/* get the user's cmd and do some simple validation */
ret = __comedi_get_user_cmd(dev, arg, &cmd);
if (ret)
-- 
2.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 v3 1/7] x86, kaslr: Use init_size instead of run_size

[Yinghai Lu]

On Mon, Mar 9, 2015 at 1:00 PM, Borislav Petkov  wrote:
> On Mon, Mar 09, 2015 at 12:35:25PM -0700, Yinghai Lu wrote:
>> Can you put back:
>> "
>> So need to make sure [z_extra_offset, init_size) will fit ZO, that means
>> init_size need to be adjusted according to ZO size.
>> That make init_size is always >= run_size.
>
> Why?
>
> We don't adjust init_size. We assign INIT_SIZE to it. Or do you want to
> say that we indirectly adjust init_size through INIT_SIZE?

Yes. Just to emphasize that  " We need to make sure [z_extra_offset,
init_size) will fit ZO"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch v3] mm, hugetlb: abort __get_user_pages if current has been oom killed

[David Rientjes]

If __get_user_pages() is faulting a significant number of hugetlb pages,
usually as the result of mmap(MAP_LOCKED), it can potentially allocate a
very large amount of memory.

If the process has been oom killed, this will cause a lot of memory to
potentially deplete memory reserves.

In the same way that commit 4779280d1ea4 ("mm: make get_user_pages() 
interruptible") aborted for pending SIGKILLs when faulting non-hugetlb
memory, based on the premise of commit 462e00cc7151 ("oom: stop
allocating user memory if TIF_MEMDIE is set"), hugetlb page faults now
terminate when the process has been oom killed.

Cc: Greg Thelen 
Cc: Naoya Horiguchi 
Cc: Davidlohr Bueso 
Acked-by: "Kirill A. Shutemov" 
Signed-off-by: David Rientjes 
---
 v3: tweak changelog per Greg

 mm/hugetlb.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3276,6 +3276,15 @@ long follow_hugetlb_page(struct mm_struct *mm, struct 
vm_area_struct *vma,
struct page *page;
 
/*
+* If we have a pending SIGKILL, don't keep faulting pages and
+* potentially allocating memory.
+*/
+   if (unlikely(fatal_signal_pending(current))) {
+   remainder = 0;
+   break;
+   }
+
+   /*
 * Some archs (sparc64, sh*) have multiple pte_ts to
 * each hugepage.  We have to make sure we get the
 * first, for the page indexing below to work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size

[Borislav Petkov]

On Mon, Mar 09, 2015 at 12:35:25PM -0700, Yinghai Lu wrote:
> Can you put back:
> "
> So need to make sure [z_extra_offset, init_size) will fit ZO, that means
> init_size need to be adjusted according to ZO size.
> That make init_size is always >= run_size.

Why?

We don't adjust init_size. We assign INIT_SIZE to it. Or do you want to
say that we indirectly adjust init_size through INIT_SIZE?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] x86: save r11 into pt_regs->flags on SYSCALL64 fastpath

[Andy Lutomirski]

On Mon, Mar 9, 2015 at 11:39 AM, Denys Vlasenko  wrote:
> Before this patch, r11 was saved in pt_regs->r11.
> Which looks natural, but requires messy shuffling to/from iret frame
> whenever ptrace or e.g. sys_iopl wants to modify flags - because
> that's how this register is used by SYSCALL/SYSRET.
>
> This patch saves r11 in pt_regs->flags,
> and uses that value for SYSRET64 insn. Shuffling is eliminated.
>
> FIXUP/RESTORE_TOP_OF_STACK are simplified.
>
> stub_iopl is no longer needed: pt_regs->flags needs no fixing up.
>
> Testing shows that syscall fast path is ~54.3 ns before
> and after the patch (on 2.7 GHz Sandy Bridge CPU).

Acked-by: Andy Lutomirski 

>
> Signed-off-by: Denys Vlasenko 
> CC: Linus Torvalds 
> CC: Steven Rostedt 
> CC: Ingo Molnar 
> CC: Borislav Petkov 
> CC: "H. Peter Anvin" 
> CC: Andy Lutomirski 
> CC: Oleg Nesterov 
> CC: Frederic Weisbecker 
> CC: Alexei Starovoitov 
> CC: Will Drewry 
> CC: Kees Cook 
> CC: x...@kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
>  arch/x86/include/asm/calling.h | 20 ++--
>  arch/x86/kernel/entry_64.S | 24 +++-
>  2 files changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/arch/x86/include/asm/calling.h b/arch/x86/include/asm/calling.h
> index f1a962f..4b5f7bf 100644
> --- a/arch/x86/include/asm/calling.h
> +++ b/arch/x86/include/asm/calling.h
> @@ -95,9 +95,11 @@ For 32-bit we have the following conventions - kernel is 
> built with
> CFI_ADJUST_CFA_OFFSET 15*8+\addskip
> .endm
>
> -   .macro SAVE_C_REGS_HELPER offset=0 rax=1 rcx=1 r8plus=1
> -   .if \r8plus
> +   .macro SAVE_C_REGS_HELPER offset=0 rax=1 rcx=1 r8910=1 r11=1
> +   .if \r11
> movq_cfi r11, 6*8+\offset
> +   .endif
> +   .if \r8910
> movq_cfi r10, 7*8+\offset
> movq_cfi r9,  8*8+\offset
> movq_cfi r8,  9*8+\offset
> @@ -113,16 +115,19 @@ For 32-bit we have the following conventions - kernel 
> is built with
> movq_cfi rdi, 14*8+\offset
> .endm
> .macro SAVE_C_REGS offset=0
> -   SAVE_C_REGS_HELPER \offset, 1, 1, 1
> +   SAVE_C_REGS_HELPER \offset, 1, 1, 1, 1
> .endm
> .macro SAVE_C_REGS_EXCEPT_RAX_RCX offset=0
> -   SAVE_C_REGS_HELPER \offset, 0, 0, 1
> +   SAVE_C_REGS_HELPER \offset, 0, 0, 1, 1
> .endm
> .macro SAVE_C_REGS_EXCEPT_R891011
> -   SAVE_C_REGS_HELPER 0, 1, 1, 0
> +   SAVE_C_REGS_HELPER 0, 1, 1, 0, 0
> .endm
> .macro SAVE_C_REGS_EXCEPT_RCX_R891011
> -   SAVE_C_REGS_HELPER 0, 1, 0, 0
> +   SAVE_C_REGS_HELPER 0, 1, 0, 0, 0
> +   .endm
> +   .macro SAVE_C_REGS_EXCEPT_RAX_RCX_R11
> +   SAVE_C_REGS_HELPER 0, 0, 0, 1, 0
> .endm
>
> .macro SAVE_EXTRA_REGS offset=0
> @@ -179,6 +184,9 @@ For 32-bit we have the following conventions - kernel is 
> built with
> .macro RESTORE_C_REGS_EXCEPT_R11
> RESTORE_C_REGS_HELPER 1,1,0,1,1
> .endm
> +   .macro RESTORE_C_REGS_EXCEPT_RCX_R11
> +   RESTORE_C_REGS_HELPER 1,0,0,1,1
> +   .endm
> .macro RESTORE_RSI_RDI
> RESTORE_C_REGS_HELPER 0,0,0,0,0
> .endm
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index 5117a2b..324200a 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -121,14 +121,12 @@ ENDPROC(native_usergs_sysret64)
>  #endif
>
>  /*
> - * C code is not supposed to know about undefined top of stack. Every time
> - * a C function with an pt_regs argument is called from the SYSCALL based
> - * fast path FIXUP_TOP_OF_STACK is needed.
> + * C code is not supposed to know that the iret frame is not populated.
> + * Every time a C function with an pt_regs argument is called from
> + * the SYSCALL based fast path FIXUP_TOP_OF_STACK is needed.
>   * RESTORE_TOP_OF_STACK syncs the syscall state after any possible ptregs
>   * manipulation.
>   */
> -
> -   /* %rsp:at FRAMEEND */
> .macro FIXUP_TOP_OF_STACK tmp offset=0
> movq PER_CPU_VAR(old_rsp),\tmp
> movq \tmp,RSP+\offset(%rsp)
> @@ -136,15 +134,13 @@ ENDPROC(native_usergs_sysret64)
> movq $__USER_CS,CS+\offset(%rsp)
> movq RIP+\offset(%rsp),\tmp  /* get rip */
> movq \tmp,RCX+\offset(%rsp)  /* copy it to rcx as sysret would do */
> -   movq R11+\offset(%rsp),\tmp  /* get eflags */
> -   movq \tmp,EFLAGS+\offset(%rsp)
> +   movq EFLAGS+\offset(%rsp),\tmp /* ditto for rflags->r11 */
> +   movq \tmp,R11+\offset(%rsp)
> .endm
>
> .macro RESTORE_TOP_OF_STACK tmp offset=0
> movq RSP+\offset(%rsp),\tmp
> movq \tmp,PER_CPU_VAR(old_rsp)
> -   movq EFLAGS+\offset(%rsp),\tmp
> -   movq \tmp,R11+\offset(%rsp)
> .endm
>
>  /*
> @@ -257,9 +253,10 @@ GLOBAL(system_call_after_swapgs)
>  */
> ENABLE_INTERRUPTS(CLBR_NONE)
> ALLOC_PT_GPREGS_ON_STACK 8  /* +8: space for orig_ax */
> -   SAV

Re: [PATCH V2] Allow compaction of unevictable pages

[David Rientjes]

On Mon, 9 Mar 2015, Eric B Munson wrote:

> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index f279d9c..599fb01 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -232,8 +232,6 @@ struct lruvec {
>  #define ISOLATE_UNMAPPED ((__force isolate_mode_t)0x2)
>  /* Isolate for asynchronous migration */
>  #define ISOLATE_ASYNC_MIGRATE((__force isolate_mode_t)0x4)
> -/* Isolate unevictable pages */
> -#define ISOLATE_UNEVICTABLE  ((__force isolate_mode_t)0x8)
>  
>  /* LRU Isolation modes. */
>  typedef unsigned __bitwise__ isolate_mode_t;
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 8c0d945..4a8ea87 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -872,8 +872,7 @@ isolate_migratepages_range(struct compact_control *cc, 
> unsigned long start_pfn,
>   if (!pageblock_pfn_to_page(pfn, block_end_pfn, cc->zone))
>   continue;
>  
> - pfn = isolate_migratepages_block(cc, pfn, block_end_pfn,
> - ISOLATE_UNEVICTABLE);
> + pfn = isolate_migratepages_block(cc, pfn, block_end_pfn, 0);
>  
>   /*
>* In case of fatal failure, release everything that might
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 5e8eadd..3b2a444 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1234,10 +1234,6 @@ int __isolate_lru_page(struct page *page, 
> isolate_mode_t mode)
>   if (!PageLRU(page))
>   return ret;
>  
> - /* Compaction should not handle unevictable pages but CMA can do so */
> - if (PageUnevictable(page) && !(mode & ISOLATE_UNEVICTABLE))
> - return ret;
> -
>   ret = -EBUSY;
>  
>   /*

Looks better!

I think there's one more cleanup we can do now thanks to your patch: 
dropping the isolate_mode_t formal from isolate_migratepages_block() 
entirely since that function can now just do

const isolate_mode_t isolate_mode =
(cc->mode == MIGRATE_ASYNC ? ISOLATE_ASYNC_MIGRATE : 0);

since we already pass in the struct compact_control and isolate_mode only 
depends on MIGRATE_ASYNC or not.

If you'd like to fold that change into this patch because it's logically 
allowed by it, feel free to add my enthusiastic

Acked-by: David Rientjes 

Otherwise, I'll just send a change on top of it if you don't have time.

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

Re: [PATCH v2 1/5] arm: KVM: export vcpi->pause state via MP_STATE ioctls

[Peter Maydell]

On 10 March 2015 at 04:29, Christoffer Dall  wrote:
> On Mon, Mar 09, 2015 at 04:34:21PM +, Alex Bennée wrote:
>> - Boot
>> - Power on secondary CPUs
>> - Power off one secondary CPU
>> - Migrate to file (cpu_powered reflects state of each CPU)
>>
>> - Start fresh QEMU
>> - Restore from file (cpu_powered -> vcpu->paused via ioctl)
>> - Run (we continue with the same power state pre-migrate)
>>
>> - PSCI RESET
>> - Does what it does, power all secondaries down?
>> - Kernel boots, turns them on?
>>
> Hmmm. As long as QEMU always inits all VCPUs in the exact same way
> (including the KVM_ARM_VCPU_POWER_OFF feature bit) I guess it works and
> that's probably a reasonable requirement for migration.

We init the VCPUs with the POWER_OFF flag set for exactly the
set of CPUs that we want to start powered off. Typically that
means that the first CPU is inited with POWER_OFF clear and the
rest are inited with it set.

Regardless, if we're doing an incoming migration, then the
incoming data will be used to set the VCPU on/off state
appropriately for resuming the VM. (This might include
powering on a VCPU that's been inited in power-off and never
run, or powering down a VCPU that was inited power-on but
never ran. In the 'migration moves a vcpu to powered-on'
case we'll also set the vcpu's PC and other registers so
when it is run it will DTRT.)

If the resumed guest subsequently does a PSCI reset then
QEMU will re-init the VCPUs with the set of feature bits that
the machine model/etc defines for a reset condition for this
board, which will be the same "first CPU powered on, all the
rest powered off" config we started with.

(It's the user's responsibility to ensure that when doing a
migration the QEMUs at both ends are identically configured,
incidentally.)

-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] pinctrl: cygnus: add initial IOMUX driver support

[Paul Bolle]

Ray Jui schreef op ma 09-03-2015 om 12:40 [-0700]:
> I don't see this as an "issue" to be quite honest.

(Off topic: is issue a, well, strong word? To my (non-English) mind it's
rather neutral, carrying by itself less urgency than, say, problem. If
I'm wrong I might have confused quite a few people by using it quite
often. And that would be a real issue!)

> By saying that, I at
> least agree with you that these are not information that's mandatory to
> be in the driver given what we already have. MODULE_LICENSE is covered
> by license header. MODULE_DESCRIPTION is covered by descriptions in
> Kconfig. MODULE_AUTHOR is much less important than what's in the
> MAINTAINERS list.
> 
> Since I have to submit a new patch series to address the "ngpios" issue
> that Linus mentioned in the other email, I don't mind removing all these
> MODULE_* macros in the driver all together.

I see.

Thanks,


Paul Bolle

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

Re: [PATCH] net: macb: constify macb configuration data

[David Miller]

From: Josh Cartwright 
Date: Mon, 9 Mar 2015 11:14:39 -0500

> The configurations are not modified by the driver.  Make them 'const' so
> that they may be placed in a read-only section.
> 
> Signed-off-by: Josh Cartwright 

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

Re: [PATCH] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)

[Andy Lutomirski]

On Mon, Mar 9, 2015 at 12:26 PM, H. Peter Anvin  wrote:
> On 03/09/2015 12:13 PM, Andy Lutomirski wrote:
>> On Mon, Mar 9, 2015 at 10:44 AM, H. Peter Anvin  wrote:
>>> On 03/09/2015 09:44 AM, Linus Torvalds wrote:

 And remember: those zero-cost out-of-order branches turn quite
 expensive if they *ever* mispredict. Even a 5% mispredict rate is
 likely to mean "it's better to have a data dependency chain".

 So it could easily go either way. I'm not convinced the old code is bad at 
 all.

>>>
>>> I'm inclined to side with Linus here.  I'm hesitant to change this based
>>> on pure speculation.
>>>
>>> To answer Andy's question: I do believe we need espfix for V86 mode as well.
>>>
>>
>> I think we don't.  Did I screw up my test?
>>
>
> I don't see how your test executes V86 mode code at all, since there
> seems to be nothing mapped at the bottom of memory?

It executes the implicit #PF at the bottom of memory :)

Seriously, though, I think that IRET doesn't check whether the
instruction we're returning to can be fetched, so IRET will complete
successfully and then we'll get #PF.  The resulting SIGSEGV kicks us
out of vm86 mode, and, assuming that the kernel isn't buggy (hah!) the
v86 state will get saved back to the vm86plus_struct and we can see if
esp got corrupted.

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

[PATCH] ARM: shmobile: R-Car Gen2: Add da9063/da9210 regulator quirk

[Geert Uytterhoeven]

The r8a7790/lager and r8a7791/koelsch development boards have da9063 and
da9210 regulators.  Both regulators have their interrupt request lines
tied to the same interrupt pin (IRQ2) on the SoC.

After cold boot or da9063-induced restart, both the da9063 and da9210
seem to assert their interrupt request lines.  Hence as soon as one
driver requests this irq, it gets stuck in an interrupt storm, as it
only manages to deassert its own interrupt request line, and the other
driver hasn't installed an interrupt handler yet.

To handle this, install a quirk that masks the interrupts in both the
da9063 and da9210.  This quirk has to run after the i2c master driver
has been initialized, but before the i2c slave drivers are initialized.
As it depends on i2c, select I2C if one of the affected platforms is
enabled in the kernel config.

On koelsch, the following happens:

  - Cold boot or reboot using the da9063 restart handler:

IRQ2 is asserted, installing da9063/da9210 regulator quirk
...
i2c i2c-6: regulator_quirk_notify: 1, IRQC_MONITOR = 0x3fb
i2c 6-0058: regulator_quirk_notify: 1, IRQC_MONITOR = 0x3fb
i2c 6-0058: Detected da9063
i2c 6-0058: Masking da9063 interrupt sources
i2c 6-0068: regulator_quirk_notify: 1, IRQC_MONITOR = 0x3fb
i2c 6-0068: Detected da9210
i2c 6-0068: Masking da9210 interrupt sources
i2c 6-0068: IRQ2 is not asserted, removing quirk

  - Warm boot (reset button):

rcar_gen2_regulator_quirk: IRQ2 is not asserted, not installing quirk

Signed-off-by: Geert Uytterhoeven 
Tested-by: Wolfram Sang 
Reviewed-by: Mark Brown 
---
v2:
  - Add Tested-by, Reviewed-by,
  - Add check for "renesas,lager", which is known to be affected (thanks
Wolfram),
  - Make ARCH_R8A7790 and ARCH_R8A7791 select I2C, as the quirk needs
i2c to be builtin, and drop the #ifdef on CONFIG_I2C,
  - Use the passed notifier_block to unregister the notifier, so we can
get rid of the forward declaration,
  - Move the quirk code to a separate file for easier maintenance,
  - Postpone iounmap() until after bus_unregister_notifier(),
  - Remove error checking for bus_{,un}register_notifier(); these
currently cannot fail, and if they ever do, there's nothing we can
do about it,
  - Comment rewording and restructuring,
  - Drop RFC state.

I do not have schematics for r8a7793/gose, but according to the BSP, it
has both da9210 and da9063, so most probably it's also affected.

References:
  - "ARM: shmobile: koelsch: da9210/da9063 interrupt storm (was: Re:
[PATCH 3/4] ARM: shmobile: koelsch: Add DA9063 PMIC device node for
system restart") (https://lkml.org/lkml/2015/2/17/254),
  - "[PATCH/RFC 1/2] regulator: da9210: Mask all interrupt sources to
deassert interrupt line" (https://lkml.org/lkml/2015/2/17/274)
  - "[PATCH/RFC 2/2] regulator: da9210: Add optional interrupt support"
(https://lkml.org/lkml/2015/2/17/275)
---
 arch/arm/mach-shmobile/Kconfig |   2 +
 arch/arm/mach-shmobile/Makefile|   2 +
 arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 147 +
 3 files changed, 151 insertions(+)
 create mode 100644 arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index c2952f58e7683ac7..0fb484221c90e0eb 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -73,10 +73,12 @@ config ARCH_R8A7779
 config ARCH_R8A7790
bool "R-Car H2 (R8A77900)"
select ARCH_RCAR_GEN2
+   select I2C
 
 config ARCH_R8A7791
bool "R-Car M2-W (R8A77910)"
select ARCH_RCAR_GEN2
+   select I2C
 
 config ARCH_R8A7794
bool "R-Car E2 (R8A77940)"
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index d3aca07b51a8a149..9e9d6788de512d31 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -32,6 +32,8 @@ cpu-y := platsmp.o headsmp.o
 # Shared SoC family objects
 obj-$(CONFIG_ARCH_RCAR_GEN2)   += setup-rcar-gen2.o platsmp-apmu.o $(cpu-y)
 CFLAGS_setup-rcar-gen2.o   += -march=armv7-a
+obj-$(CONFIG_ARCH_R8A7790) += regulator-quirk-rcar-gen2.o
+obj-$(CONFIG_ARCH_R8A7791) += regulator-quirk-rcar-gen2.o
 
 # SMP objects
 smp-y  := $(cpu-y)
diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c 
b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
new file mode 100644
index ..384e6e934b876528
--- /dev/null
+++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
@@ -0,0 +1,147 @@
+/*
+ * R-Car Generation 2 da9063/da9210 regulator quirk
+ *
+ * The r8a7790/lager and r8a7791/koelsch development boards have da9063 and
+ * da9210 regulators.  Both regulators have their interrupt request lines tied
+ * to the same interrupt pin (IRQ2) on the SoC.
+ *
+ * After cold boot or da9063-induced restart, both the da906

Re: [PATCH v4 2/2] cgroups: add a pids subsystem

[Tejun Heo]

Hello, Austin.

On Mon, Mar 09, 2015 at 02:58:11PM -0400, Austin S Hemmelgarn wrote:
> On 2015-03-08 23:34, Tejun Heo wrote:
> >
> >Does pids limit make sense in the root cgroup?
> >
> I would say it kind of does, although I would just expect it to track
> /proc/sys/kernel/pid_max (either as a read-only value, or as an alternative
> way to set it).

I don't think that's a good idea.  It doesn't add anything while
putting pids controller in conflict with how other controllers handle
the root cgroup.  Furthermore, I don't think it's generally a good
idea to add things because it may help convenience in some cases,
which is exactly the case here.  Why add non-orthogonal component when
the only reason is "yeah, it may be a bit more convenient in some
imaginary cases"?  We'd be restricting the design space we can move
inside for no good reason.

Thanks.

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

[PATCH v2] HID: i2c-hid: Fix suspend/resume when already runtime suspended

[Doug Anderson]

If the i2c-hid device was runtime suspended and then the system
suspended itself we'd end up disabling interrupts twice (in
i2c_hid_runtime_suspend and i2c_hid_suspend) and not reenabling them
until later when the i2c-hid device was runtime resumed.
Unfortunately the i2c_hid_resume() calls i2c_hid_hwreset() and that
only works properly if interrupts are enabled.

We can fix this by taking the advice from "runtime_pm.txt".
Specifically we'll change i2c-hid to always resume to full power.
This only works if our parents are also resumed to full power, but
given the suggestion in "runtime_pm.txt" this seems a reasonable
assumption.

Signed-off-by: Doug Anderson 
---
Note that this was tested on a 3.14 kernel with backports.  Any
testing that folks can do on ToT is appreciated.

Changes in v2:
- Move pm_runtime_enable() higher in resume

 drivers/hid/i2c-hid/i2c-hid.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index ab4dd95..9e013f6 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -1090,15 +1090,18 @@ static int i2c_hid_suspend(struct device *dev)
struct hid_device *hid = ihid->hid;
int ret = 0;
 
-   disable_irq(ihid->irq);
-   if (device_may_wakeup(&client->dev))
-   enable_irq_wake(ihid->irq);
+   if (!pm_runtime_suspended(dev)) {
+   /* Save some power */
+   i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
+
+   disable_irq(ihid->irq);
+   }
 
if (hid->driver && hid->driver->suspend)
ret = hid->driver->suspend(hid, PMSG_SUSPEND);
 
-   /* Save some power */
-   i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
+   if (device_may_wakeup(&client->dev))
+   enable_irq_wake(ihid->irq);
 
return ret;
 }
@@ -1110,6 +1113,11 @@ static int i2c_hid_resume(struct device *dev)
struct i2c_hid *ihid = i2c_get_clientdata(client);
struct hid_device *hid = ihid->hid;
 
+   /* We'll resume to full power */
+   pm_runtime_disable(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+
enable_irq(ihid->irq);
ret = i2c_hid_hwreset(client);
if (ret)
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sunrpc: fix braino in ->poll()

[J. Bruce Fields]

On Sat, Mar 07, 2015 at 09:08:46PM +, Al Viro wrote:
> POLL_OUT isn't what callers of ->poll() are expecting to see; it's
> actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap
> bit...

Thanks!--b.

> 
> Signed-off-by: Al Viro 
> ---
> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> index 33fb105..5199bb1 100644
> --- a/net/sunrpc/cache.c
> +++ b/net/sunrpc/cache.c
> @@ -921,7 +921,7 @@ static unsigned int cache_poll(struct file *filp, 
> poll_table *wait,
>   poll_wait(filp, &queue_wait, wait);
>  
>   /* alway allow write */
> - mask = POLL_OUT | POLLWRNORM;
> + mask = POLLOUT | POLLWRNORM;
>  
>   if (!rp)
>   return mask;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] pinctrl: cygnus: add initial IOMUX driver support

[Ray Jui]

On 3/9/2015 12:30 PM, Paul Bolle wrote:
> Ray Jui schreef op ma 09-03-2015 om 12:00 [-0700]:
>> I think it depends on how you see it. Based on this logic, then one can
>> also argue comments in the code will be pre-processed away and are not
>> needed. They at least serve the same documentation purpose in a way.
> 
> So why not make them comments? And even that might not be needed:
> - MODULE_LICENSE() only summarizes, in just a few words, what takes a
> few paragraphs in the customary comment at the top of a file;
> - MODULE_DESCRIPTION() repeats what, in general, has been said in the
> Kconfig entry for that driver and in the git commit explanation;
> - and I'm not sure what the benefit is of MODULE_AUTHOR() in the first
> place (even for actually modular drivers).
> 
>> So
>> far I haven't seen other people complaining that having these module
>> based macros in the driver are confusing when the Kconfig has a bool.
> 
> Perhaps that's just because review doesn't spot all issues. Patch
> bandwidth exceeding review bandwidth and all that.

I don't see this as an "issue" to be quite honest. By saying that, I at
least agree with you that these are not information that's mandatory to
be in the driver given what we already have. MODULE_LICENSE is covered
by license header. MODULE_DESCRIPTION is covered by descriptions in
Kconfig. MODULE_AUTHOR is much less important than what's in the
MAINTAINERS list.

Since I have to submit a new patch series to address the "ngpios" issue
that Linus mentioned in the other email, I don't mind removing all these
MODULE_* macros in the driver all together.

> 
> Anyhow, right now there's another thread discussing the questions my
> review comments raise. Eg, "The Kconfig symbol is bool, there is module
> related code in the driver, why note make the Kconfig symbol tristate
> (and the driver modular)?". I think that is one of the questions mixing
> built-in and modular semantics raises.
> 
> 
> Paul Bolle
> 

Thanks,

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

Re: [PATCH v2 0/7] New Lenovos 2015 touchpads: party time!

[Benjamin Tissoires]

On Mon, Mar 9, 2015 at 4:24 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 09-03-15 07:46, Dmitry Torokhov wrote:
>>
>> On Wed, Feb 25, 2015 at 03:58:20PM +0100, Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> On 25-02-15 15:36, Benjamin Tissoires wrote:

 On Mon, Feb 16, 2015 at 10:23 PM, Benjamin Tissoires
  wrote:
>
> On Fri, Feb 6, 2015 at 3:04 PM, Benjamin Tissoires
>  wrote:
>>
>> Hi,
>>
>> This is the second episode of the Lenovo 2015 party :)
>>
>> Thanks to Andrew, we now have an idea within the driver of what are
>> the extra
>> buttons aimed for, and the patch series looks cleaner.
>> Many thanks for your help.
>>
>> I marked only patches 1/7, 2/7 and 3/7 as stable because they are
>> really
>> stable fixes. Without the rest of the series, user-space can cope with
>> the
>> kernel result, and so there is IMO no need to backport too many
>> patches in
>> stable. I bet distributions will cherry-pick the rest of the series
>> however.
>>
>
> Guys,
>
> any chances we consider this for 3.20 (or whatever it will be
> numbered)?
> I'd really like to see this accepted upstream in one way or one other
> so we will prevent the mess we had to deal with last year.
>

 Hans, Dmitry,

 well, it's been 3 weeks since I received the loaner I have to support
 these touchpads. I will have to return it next week or the week after
 at most. That means that I will not be able to conduct more tests at
 that point.
 Can I ask you to please review the series?
>>>
>>>
>>> Ah, sorry I missed you did a v2 (I did review v1).
>>>
>>> Series looks good to me and is:
>>>
>>> Acked-by: Hans de Goede 
>>
>>
>> I did a few edits of the patches in the 2 series so I created a separate
>> branch "synaptics" based on 3.19. I'd appreciate if you could give it q
>> quick spin before I will send it for 4.0.
>
>
> I don't have access to the hardware in question, but Benjamin does, so
> we'll have to wait (a bit) for him to wake up :)
>

It took me a little bit of time to retrieve the laptop and get it tested.
So far, so good:
- t440s (2013) shows the correct behavior
- x1 carbon 3 has the buttons properly forwarded through the
trackstick interface and are reacting as expected.

Thanks Dmitry!

I've added Daniel to the thread and asked it this morning if he could
also give a try to the series.

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

[PATCH v2] MTD: cfi: reduce stack size

[Arnd Bergmann]

The cfi_staa_write_buffers function uses a large amount of kernel stack
whenever CONFIG_MTD_MAP_BANK_WIDTH_32 is set, and that results in a
warning on ARM allmodconfig builds:

drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers':
drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1208 
bytes is larger than 1024 bytes [-Wframe-larger-than=]

It turns out that this is largely a result of a suboptimal implementation
of map_word_andequal(). Replacing this function with a straightforward
one reduces the stack size in this function by exactly 200 bytes,
shrinks the .text segment for this file from 27648 bytes to 26608 bytes,
and makes the warning go away.

Signed-off-by: Arnd Bergmann 

diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 5f487d776411..7b5841663d4f 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -314,7 +314,15 @@ static inline map_word map_word_or(struct map_info *map, 
map_word val1, map_word
return r;
 }
 
-#define map_word_andequal(m, a, b, z) map_word_equal(m, z, map_word_and(m, a, 
b))
+static inline int map_word_andequal(struct map_info *map, map_word val1, 
map_word val2, map_word val3)
+{
+   int i;
+   for (i=0; i < map_words(map); i++) {
+   if ((val1.x[i] & val2.x[i]) != val3.x[i])
+   return 0;
+   }
+   return 1;
+}
 
 static inline int map_word_bitsset(struct map_info *map, map_word val1, 
map_word val2)
 {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] avc: remove unnecessary pointer reassignment

[Paul Moore]

On Wed, Mar 4, 2015 at 1:07 PM, Paul Moore  wrote:
> On Fri, Feb 27, 2015 at 8:15 AM, Stephen Smalley  wrote:
>> On 02/26/2015 04:54 PM, Jeff Vander Stoep wrote:
>>> Commit f01e1af445fa ("selinux: don't pass in NULL avd to 
>>> avc_has_perm_noaudit")
>>> made this pointer reassignment unnecessary. Avd should continue to reference
>>> the stack-based copy.
>>>
>>> Signed-off-by: Jeff Vander Stoep 
>>
>> Acked-by:  Stephen Smalley 
>
> Thanks everyone for the patch and the review.  I'll merge this next
> week into selinux#next.

I apologize for the delay, but I just merged this into selinux#next;
it should be in the next linux-next kernel.

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

Re: [PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size

[Yinghai Lu]

On Mon, Mar 9, 2015 at 5:49 AM, Borislav Petkov  wrote:
> I ended up committing this. Anything I've missed?
>
> ---
> From: Yinghai Lu 
> Date: Sat, 7 Mar 2015 14:07:15 -0800
> Subject: [PATCH] x86/setup: Use init_size instead of run_size
>
> Commit
>
>   e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
>
> introduced run_size for KASLR to represent the size of kernel proper
> (vmlinux).
>
> However, we should use the actual runtime size (which provides for
> copy/decompress), i.e. init_size, as it includes .bss and .brk.
>
> Why, you ask?
>
> Because init_size is the size needed for safe kernel decompression and
> thus can be higher than run_size in case the decompressor needs a larger
> buffer.
>
> From arch/x86/boot/header.S:
>   #define ZO_INIT_SIZE(ZO__end - ZO_startup_32 + ZO_z_extract_offset)
>   #define VO_INIT_SIZE(VO__end - VO__text)
>   #if ZO_INIT_SIZE > VO_INIT_SIZE
>   #define INIT_SIZE ZO_INIT_SIZE
>   #else
>   #define INIT_SIZE VO_INIT_SIZE
>   #endif
>   init_size:  .long INIT_SIZE # kernel initialization size
>
> The boot loader allocates a buffer of size init_size which it
> reads from the setup header and loads the compressed kernel
> (arch/x86/boot/compressed/vmlinux) in it.
>
> init_size initially comes from the kernel proper's (vmlinux) init size.
> It includes the .bss and .brk area.
>
> When the boot loader hands off to the compressed kernel, the last
> moves itself to z_extract_offset within the buffer to make sure that
> the decompressor output does not overwrite input data before it gets
> consumed.
>
> However, z_extract_offset is the size difference
> between the uncompressed and compressed kernel (see
> arch/x86/boot/compressed/mkpiggy.c) and thus represents the additional
> space needed for decompression but it doesn't factor in a bigger
> ZO_INIT_SIZE.

Can you put back:
"
So need to make sure [z_extra_offset, init_size) will fit ZO, that means
init_size need to be adjusted according to ZO size.
That make init_size is always >= run_size.
"

>
> During ASLR buffer searching, we need to make sure the new buffer is big
> enough for decompression. So use init_size instead, and kill run_size
> related code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MTD: cfi: reduce stack size

[Arnd Bergmann]

On Monday 09 March 2015 12:58:54 Ezequiel Garcia wrote:
> On 03/09/2015 10:58 AM, Arnd Bergmann wrote:
> > The cfi_staa_write_buffers function uses a large amount of ernel stack
> 
> Typo: "ernel"

ok

> > whenever CONFIG_MTD_MAP_BANK_WIDTH_32 is set, and that results in a
> > warning on ARM allmodconfig builds:
> > 
> > drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers':
> > drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1208 
> > bytes is larger than 1024 bytes [-Wframe-larger-than=]
> > 
> > It turns out that this is largely a result of a suboptimal implementation
> > of map_word_andequal(). Replacing this function with a straightforward
> > one reduces the stack size in this function by exactly 200 bytes,
> > shrinks the .text segment for this file from 27648 bytes to 26608 bytes,
> > and makes the warning go away.
> > 
> > Signed-off-by: Arnd Bergmann 
> > 
> > diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
> > index 5f487d776411..2d2457bee50c 100644
> > --- a/include/linux/mtd/map.h
> > +++ b/include/linux/mtd/map.h
> > @@ -314,7 +314,15 @@ static inline map_word map_word_or(struct map_info 
> > *map, map_word val1, map_word
> > return r;
> >  }
> >  
> > -#define map_word_andequal(m, a, b, z) map_word_equal(m, z, map_word_and(m, 
> > a, b))
> > +static inline int map_word_andequal(struct map_info *map, map_word val1, 
> > map_word val2, map_word val3)
> > +{
> > +   int i;
> > +   for (i=0; i 
> Nit:
> 
> for (i = 0; i < map_words(map); i++)

It's the same as five other copies of the same loop in this file, but I've
changed this one now.

Thanks,

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

Re: [PATCH] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)

[Denys Vlasenko]

>> What we definitely should do here is at least frame this check with
>>> That being said, what ends up in the high bits of esp when we iret to
>>> vm86 mode?
>>
>> I don't know. I guess it's time to write an actual vm86 testcase :)
>
> Ick.  I can try...

I found an example which runs small bit of 16-bit code using vm86 machinery.
Tried in 32-bit kernel under qemu, it worked: printed "Hello".
/*
 * Adaped from: runcom version 0.1 (c) 2003 Fabrice Bellar
 * "Simple example of use of vm86: launch a basic .com DOS executable"
 *
 * gcc -m32 -Os -Wall -static vm86.c -ovm86
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

//#define SIGTEST

#define COM_BASE_ADDR0x10100

static inline void set_bit(uint8_t *a, unsigned int bit)
{
a[bit / 8] |= (1 << (bit % 8));
}

static inline uint8_t *seg_to_linear(unsigned int seg, unsigned int reg)
{
return (uint8_t *)((seg << 4) + (reg & 0x));
}

static inline void pushw(struct vm86_regs *r, int val)
{
r->esp = (r->esp & ~0x) | ((r->esp - 2) & 0x);
*(uint16_t *)seg_to_linear(r->ss, r->esp) = val;
}

void dump_regs(struct vm86_regs *r)
{
fprintf(stderr,
"AX=%08lx BX=%08lx CX=%08lx DX=%08lx\n"
"SI=%08lx DI=%08lx BP=%08lx SP=%08lx\n"
"IP=%08lx FL=%08lx\n"
"CS=%04x DS=%04x ES=%04x SS=%04x FS=%04x GS=%04x\n",
r->eax, r->ebx, r->ecx, r->edx, r->esi, r->edi, r->ebp, r->esp,
r->eip, r->eflags,
r->cs, r->ds, r->es, r->ss, r->fs, r->gs);
}

#ifdef SIGTEST
void alarm_handler(int sig)
{
fprintf(stderr, "alarm signal=%d\n", sig);
alarm(1);
}
#endif

extern char code16;
extern char code16_end;

int main(int argc, char **argv)
{
uint8_t *vm86_mem;
int ret, seg;
struct vm86plus_struct ctx;
struct vm86_regs *r;

vm86_mem = mmap((void *)0x, 0x11,
PROT_WRITE | PROT_READ | PROT_EXEC,
MAP_FIXED | MAP_ANON | MAP_PRIVATE, -1, 0);
if (vm86_mem == MAP_FAILED) {
perror("mmap");
exit(1);
}
#ifdef SIGTEST
{
struct sigaction act;

act.sa_handler = alarm_handler;
sigemptyset(&act.sa_mask);
act.sa_flags = 0;
sigaction(SIGALRM, &act, NULL);
alarm(1);
}
#endif

/* load 16-bit code at COM_BASE_ADDR */
memcpy(vm86_mem + COM_BASE_ADDR, &code16, &code16_end - &code16);

memset(&ctx, 0, sizeof(ctx));
/* init basic registers */
r = &ctx.regs;
r->eip = 0x100;
r->esp = 0xfffe;
seg = (COM_BASE_ADDR - 0x100) >> 4;
r->cs = seg;
r->ss = seg;
r->ds = seg;
r->es = seg;
r->fs = seg;
r->gs = seg;
r->eflags = 1 << 19; //EFLAGS.VIF

set_bit((uint8_t *)&ctx.int_revectored, 0x21);
/* put return code */
*seg_to_linear(r->cs, 0) = 0xb4; /* mov ah, $0 */
*seg_to_linear(r->cs, 1) = 0x00;
*seg_to_linear(r->cs, 2) = 0xcd; /* int $0x21 */
*seg_to_linear(r->cs, 3) = 0x21;
pushw(&ctx.regs, 0x);

for(;;) {
ret = vm86(VM86_ENTER, &ctx);
switch(VM86_TYPE(ret)) {
case VM86_INTx:
{
int int_num, ah;

int_num = VM86_ARG(ret);
if (int_num != 0x21)
goto unknown_int;
ah = (r->eax >> 8) & 0xff;
switch(ah) {
case 0x00: /* exit */
exit(0);
case 0x02: /* write char */
{
uint8_t c = r->edx;
write(1, &c, 1);
}
break;
case 0x09: /* write string */
{
			int ptr = r->edx;
uint8_t c;
for(;;) {
c = *seg_to_linear(r->ds, ptr++);
if (c == '$')
break;
write(1, &c, 1);
}
r->eax = (r->eax & ~0xff) | '$';
}
break;
default:
unknown_int:
fprintf(stderr, "unsupported int 0x%02x\n", int_num);
dump_regs(&ctx.regs);
//exit(1);
}
}
break;
case VM86_SIGNAL:
/* a signal came, we just ignore that */
break;
case VM86_STI:
break;
default:
fprintf(stderr, "unhandled vm86 return code (0x%x)\n", ret);
dump_regs(&ctx.regs);
exit(1);
}
}
}

void code()
{
	asm volatile("\n"
	"	.code16""\n"

	"code16:""\n"
	"	mov	$(0x100+msg-code16),%dx""\n"
	"	mov	$0x09,%ah""\n"
	"	int	$0x21""\n"
	"	ret""\n"

	"msg:""\n"
	"	.string	\"Hello\"""\n"
	"	.byte	10""\n"
	"	.string	\"$\"""\n"

	"code16_end:""\n"
	"	.code32""\n"
	);
}

Re: [PATCH v2 1/5] arm: KVM: export vcpi->pause state via MP_STATE ioctls

[Christoffer Dall]

On Mon, Mar 09, 2015 at 04:34:21PM +, Alex Bennée wrote:
> 
> Christoffer Dall  writes:
> 
> > Hi Alex,
> >
> > The subject of this change has a typo, and I also think it's not about
> > exposing the pause state (that's just an internal name/concept), but
> > about exposing the PSCI state, or simply the VCPU power state.
> 
> arm: KVM: export VCPU power state via MP_STATE ioctl?
> 

arm/arm64: KVM: 

otherwise looks good to me ;)


> >
> > On Mon, Mar 02, 2015 at 01:29:00PM +, Alex Bennée wrote:
> >> To cleanly restore an SMP VM we need to ensure that the current pause
> >> state of each vcpu is correctly recorded. Things could get confused if
> >> the CPU starts running after migration restore completes when it was
> >> paused before it state was captured.
> >> 
> >> We use the existing KVM_GET/SET_MP_STATE ioctl to do this. The arm/arm64
> >> interface is a lot simpler as the only valid states are
> >> KVM_MP_STATE_RUNNABLE and KVM_MP_STATE_HALTED.
> >> 
> >> Signed-off-by: Alex Bennée 
> >> 
> >> diff --git a/Documentation/virtual/kvm/api.txt 
> >> b/Documentation/virtual/kvm/api.txt
> >> index b112efc..602156f 100644
> >> --- a/Documentation/virtual/kvm/api.txt
> >> +++ b/Documentation/virtual/kvm/api.txt
> >> @@ -997,7 +997,7 @@ for vm-wide capabilities.
> >>  4.38 KVM_GET_MP_STATE
> >>  
> >>  Capability: KVM_CAP_MP_STATE
> >> -Architectures: x86, s390
> >> +Architectures: x86, s390, arm, arm64
> >>  Type: vcpu ioctl
> >>  Parameters: struct kvm_mp_state (out)
> >>  Returns: 0 on success; -1 on error
> >> @@ -1027,15 +1027,21 @@ Possible values are:
> >>   - KVM_MP_STATE_LOAD:the vcpu is in a special load/startup 
> >> state
> >>   [s390]
> >>  
> >> -On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an
> >> -in-kernel irqchip, the multiprocessing state must be maintained by 
> >> userspace on
> >> +For x86:
> >> +
> >> +This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel
> >> +irqchip, the multiprocessing state must be maintained by userspace on
> >
> > Nit: I would not taint the git log with this change but instead just
> > introduce a paragraph below starting with "On arm/arm64, " and you would
> > get the same effect.
> >
> >>  these architectures.
> >>  
> >> +For arm/arm64:
> >> +
> >> +The only states that are valid are KVM_MP_STATE_HALTED and
> >> +KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not.
> >
> > As suggested on the QEMU series, HALTED is probably not the right thing
> > to use.
> 
> KVM_MP_STATE_STOPPED is currently only used for s390 but seems to fit.
> I'm wary of adding yet another define.
> 

sounds fine, as long as it doesn't have some inherently different
meaning with s390.

> >
> >>  
> >>  4.39 KVM_SET_MP_STATE
> >>  
> >>  Capability: KVM_CAP_MP_STATE
> >> -Architectures: x86, s390
> >> +Architectures: x86, s390, arm, arm64
> >>  Type: vcpu ioctl
> >>  Parameters: struct kvm_mp_state (in)
> >>  Returns: 0 on success; -1 on error
> >> @@ -1043,10 +1049,16 @@ Returns: 0 on success; -1 on error
> >>  Sets the vcpu's current "multiprocessing state"; see KVM_GET_MP_STATE for
> >>  arguments.
> >>  
> >> -On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an
> >> -in-kernel irqchip, the multiprocessing state must be maintained by 
> >> userspace on
> >> +For x86:
> >> +
> >> +This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel
> >> +irqchip, the multiprocessing state must be maintained by userspace on
> >>  these architectures.
> >>  
> >> +For arm/arm64:
> >> +
> >> +The only states that are valid are KVM_MP_STATE_HALTED and
> >> +KVM_MP_STATE_RUNNABLE which reflect if the vcpu should be paused or not.
> >
> > same as above
> >
> >>  
> >>  4.40 KVM_SET_IDENTITY_MAP_ADDR
> >>  
> >> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> >> index 5560f74..8531536 100644
> >> --- a/arch/arm/kvm/arm.c
> >> +++ b/arch/arm/kvm/arm.c
> >> @@ -183,6 +183,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
> >> ext)
> >>case KVM_CAP_ARM_PSCI:
> >>case KVM_CAP_ARM_PSCI_0_2:
> >>case KVM_CAP_READONLY_MEM:
> >> +  case KVM_CAP_MP_STATE:
> >>r = 1;
> >>break;
> >>case KVM_CAP_COALESCED_MMIO:
> >> @@ -313,13 +314,29 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct 
> >> kvm_vcpu *vcpu,
> >>  int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
> >>struct kvm_mp_state *mp_state)
> >>  {
> >> -  return -EINVAL;
> >> +  if (vcpu->arch.pause)
> >> +  mp_state->mp_state = KVM_MP_STATE_HALTED;
> >> +  else
> >> +  mp_state->mp_state = KVM_MP_STATE_RUNNABLE;
> >> +
> >> +  return 0;
> >>  }
> >>  
> >>  int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
> >>struct kvm_mp_state *mp_state)
> >>  {
> >> -  return -EINVAL;
> >> +  switch (mp_state->mp_state) {
> >> +  case KVM_MP_STATE_RUNNABLE:
> >> +  vcpu-

Re: [PATCH v5 3/8] pinctrl: cygnus: add initial IOMUX driver support

[Paul Bolle]

Ray Jui schreef op ma 09-03-2015 om 12:00 [-0700]:
> I think it depends on how you see it. Based on this logic, then one can
> also argue comments in the code will be pre-processed away and are not
> needed. They at least serve the same documentation purpose in a way.

So why not make them comments? And even that might not be needed:
- MODULE_LICENSE() only summarizes, in just a few words, what takes a
few paragraphs in the customary comment at the top of a file;
- MODULE_DESCRIPTION() repeats what, in general, has been said in the
Kconfig entry for that driver and in the git commit explanation;
- and I'm not sure what the benefit is of MODULE_AUTHOR() in the first
place (even for actually modular drivers).

> So
> far I haven't seen other people complaining that having these module
> based macros in the driver are confusing when the Kconfig has a bool.

Perhaps that's just because review doesn't spot all issues. Patch
bandwidth exceeding review bandwidth and all that.

Anyhow, right now there's another thread discussing the questions my
review comments raise. Eg, "The Kconfig symbol is bool, there is module
related code in the driver, why note make the Kconfig symbol tristate
(and the driver modular)?". I think that is one of the questions mixing
built-in and modular semantics raises.


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)

[H. Peter Anvin]

On 03/09/2015 12:13 PM, Andy Lutomirski wrote:
> On Mon, Mar 9, 2015 at 10:44 AM, H. Peter Anvin  wrote:
>> On 03/09/2015 09:44 AM, Linus Torvalds wrote:
>>>
>>> And remember: those zero-cost out-of-order branches turn quite
>>> expensive if they *ever* mispredict. Even a 5% mispredict rate is
>>> likely to mean "it's better to have a data dependency chain".
>>>
>>> So it could easily go either way. I'm not convinced the old code is bad at 
>>> all.
>>>
>>
>> I'm inclined to side with Linus here.  I'm hesitant to change this based
>> on pure speculation.
>>
>> To answer Andy's question: I do believe we need espfix for V86 mode as well.
>>
> 
> I think we don't.  Did I screw up my test?
> 

I don't see how your test executes V86 mode code at all, since there
seems to be nothing mapped at the bottom of memory?

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ps3: Fix trivial typos in comment and debug message

[Geoff Levand]

On Sat, 2015-03-07 at 13:03 +0100, Yannick Guerrini wrote:
> Change 'prosessor' to 'processor'
> Change 'set_inteval' to 'set_interval'
> 
> Signed-off-by: Yannick Guerrini 
> ---
>  drivers/ps3/ps3-lpm.c | 4 ++--

Looks good.  Thanks for the fixes.

Acked-by: Geoff Levand 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)

[Andy Lutomirski]

On Mon, Mar 9, 2015 at 10:44 AM, H. Peter Anvin  wrote:
> On 03/09/2015 09:44 AM, Linus Torvalds wrote:
>>
>> And remember: those zero-cost out-of-order branches turn quite
>> expensive if they *ever* mispredict. Even a 5% mispredict rate is
>> likely to mean "it's better to have a data dependency chain".
>>
>> So it could easily go either way. I'm not convinced the old code is bad at 
>> all.
>>
>
> I'm inclined to side with Linus here.  I'm hesitant to change this based
> on pure speculation.
>
> To answer Andy's question: I do believe we need espfix for V86 mode as well.
>

I think we don't.  Did I screw up my test?

--Andy

> -hpa
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
/*
 * vm86 regs test.
 * Copyright (c) 2014-2015 Andrew Lutomirski.
 *
 * This tests that vm86 regs work as expected.
 *
 * GPL v2.
 */

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

static void sethandler(int sig, void (*handler)(int, siginfo_t *, void *),
		   int flags)
{
	struct sigaction sa;

	memset(&sa, 0, sizeof(sa));
	sa.sa_sigaction = handler;
	sa.sa_flags = SA_SIGINFO | flags;
	sigemptyset(&sa.sa_mask);
	if (sigaction(sig, &sa, 0))
		err(1, "sigaction");
}

static void sigsegv_vm86(int sig, siginfo_t *info, void *ctx_void)
{
	ucontext_t *ctx = (ucontext_t*)ctx_void;

	printf("Back from vm86.  EIP = %lx\n",
	   (unsigned long)ctx->uc_mcontext.gregs[REG_EIP]);
	
}

static void test_vm86(unsigned short cs, unsigned short ss)
{
	struct vm86plus_struct v86, req_v86;
	long ret;

	memset(&v86, 0, sizeof(v86));

	v86.regs.eip = 0;
	v86.regs.cs = cs;
	v86.regs.ss = ss;
	v86.regs.esp = 0xbaadf00d;

	req_v86 = v86;

	printf("[RUN]\tcs = 0x%hx, ss = 0x%hx\n", cs, ss);

	ret = syscall(SYS_vm86, VM86_ENTER, &v86);

	if (ret == -1 && errno == ENOSYS) {
		printf("[SKIP]\tvm86 not supported\n");
		return;
	}

	printf("[OK]\tSurvived vm86 roundtrip.  esp = %lx, should be %lx\n", v86.regs.esp, req_v86.regs.esp);
}

int main(void)
{
	sethandler(SIGSEGV, sigsegv_vm86, SA_ONSTACK);
	test_vm86(0, 0);
	test_vm86(0, 3);
	test_vm86(3, 0);
	test_vm86(3, 3);
	return 0;
}

[RFC 1/1 linux-next] fs/hfsplus: use kasprintf instead of kmalloc/strcpy.

[Fabian Frederick]

This patch removes prefixlen from all getxattr/setxattr callsites and
maximum attribute preallocation.

It's an RFC because it could bring a memory leak somewhere if attribute
is stored on the old preallocation basis and I don't know the code enough
to evaluate the risk.

Suggested-by: Andrew Morton 
Cc: Andrew Morton 
Signed-off-by: Fabian Frederick 
---
 fs/hfsplus/xattr.c  | 21 +++--
 fs/hfsplus/xattr.h  |  4 ++--
 fs/hfsplus/xattr_security.c |  6 ++
 fs/hfsplus/xattr_trusted.c  |  5 ++---
 fs/hfsplus/xattr_user.c |  4 ++--
 5 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index 16f545d..99d84fa 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -426,7 +426,7 @@ static int copy_name(char *buffer, const char *xattr_name, 
int name_len)
 
 int hfsplus_setxattr(struct dentry *dentry, const char *name,
 const void *value, size_t size, int flags,
-const char *prefix, size_t prefixlen)
+const char *prefix)
 {
char *xattr_name;
int res;
@@ -434,12 +434,10 @@ int hfsplus_setxattr(struct dentry *dentry, const char 
*name,
if (!strcmp(name, ""))
return -EINVAL;
 
-   xattr_name = kmalloc(NLS_MAX_CHARSET_SIZE * HFSPLUS_ATTR_MAX_STRLEN + 1,
-   GFP_KERNEL);
+   xattr_name = kasprintf(GFP_KERNEL, "%s%s", prefix, name);
if (!xattr_name)
return -ENOMEM;
-   strcpy(xattr_name, prefix);
-   strcpy(xattr_name + prefixlen, name);
+
res = __hfsplus_setxattr(dentry->d_inode, xattr_name, value, size,
 flags);
kfree(xattr_name);
@@ -584,7 +582,7 @@ failed_getxattr_init:
 
 ssize_t hfsplus_getxattr(struct dentry *dentry, const char *name,
 void *value, size_t size,
-const char *prefix, size_t prefixlen)
+const char *prefix)
 {
int res;
char *xattr_name;
@@ -592,14 +590,10 @@ ssize_t hfsplus_getxattr(struct dentry *dentry, const 
char *name,
if (!strcmp(name, ""))
return -EINVAL;
 
-   xattr_name = kmalloc(NLS_MAX_CHARSET_SIZE * HFSPLUS_ATTR_MAX_STRLEN + 1,
-GFP_KERNEL);
+   xattr_name = kasprintf(GFP_KERNEL, "%s%s", prefix, name);
if (!xattr_name)
return -ENOMEM;
 
-   strcpy(xattr_name, prefix);
-   strcpy(xattr_name + prefixlen, name);
-
res = __hfsplus_getxattr(dentry->d_inode, xattr_name, value, size);
kfree(xattr_name);
return res;
@@ -863,7 +857,7 @@ static int hfsplus_osx_getxattr(struct dentry *dentry, 
const char *name,
return -EOPNOTSUPP;
 
return hfsplus_getxattr(dentry, name, buffer, size,
-   XATTR_MAC_OSX_PREFIX, XATTR_MAC_OSX_PREFIX_LEN);
+   XATTR_MAC_OSX_PREFIX);
 }
 
 static int hfsplus_osx_setxattr(struct dentry *dentry, const char *name,
@@ -880,8 +874,7 @@ static int hfsplus_osx_setxattr(struct dentry *dentry, 
const char *name,
return -EOPNOTSUPP;
 
return hfsplus_setxattr(dentry, name, buffer, size, flags,
-   XATTR_MAC_OSX_PREFIX,
-   XATTR_MAC_OSX_PREFIX_LEN);
+   XATTR_MAC_OSX_PREFIX);
 }
 
 static size_t hfsplus_osx_listxattr(struct dentry *dentry, char *list,
diff --git a/fs/hfsplus/xattr.h b/fs/hfsplus/xattr.h
index f9b0955..fa637ab 100644
--- a/fs/hfsplus/xattr.h
+++ b/fs/hfsplus/xattr.h
@@ -23,14 +23,14 @@ int __hfsplus_setxattr(struct inode *inode, const char 
*name,
 
 int hfsplus_setxattr(struct dentry *dentry, const char *name,
   const void *value, size_t size, int flags,
-  const char *prefix, size_t prefixlen);
+  const char *prefix);
 
 ssize_t __hfsplus_getxattr(struct inode *inode, const char *name,
   void *value, size_t size);
 
 ssize_t hfsplus_getxattr(struct dentry *dentry, const char *name,
 void *value, size_t size,
-const char *prefix, size_t prefixlen);
+const char *prefix);
 
 ssize_t hfsplus_listxattr(struct dentry *dentry, char *buffer, size_t size);
 
diff --git a/fs/hfsplus/xattr_security.c b/fs/hfsplus/xattr_security.c
index aacff00..d19d626 100644
--- a/fs/hfsplus/xattr_security.c
+++ b/fs/hfsplus/xattr_security.c
@@ -17,16 +17,14 @@ static int hfsplus_security_getxattr(struct dentry *dentry, 
const char *name,
void *buffer, size_t size, int type)
 {
return hfsplus_getxattr(dentry, name, buffer, size,
-   XATTR_SECURITY_PREFIX,
-   XATTR_SECURITY_PREFIX_LEN);
+   XATTR_

[PATCH 1/1] net: delete stale packet_mclist entries

[Francesco Ruggeri]

>From ce9a4f202723f6ba1b18bc7c4a258c130c1f4148 Mon Sep 17 00:00:00 2001
From: Francesco Ruggeri 
Date: Mon, 9 Mar 2015 11:51:04 -0700
Subject: [PATCH 1/1] net: delete stale packet_mclist entries

When an interface is deleted from a net namespace the ifindex in the
corresponding entries in PF_PACKET sockets' mclists becomes stale.
This can create inconsistencies if later an interface with the same ifindex
is moved from a different namespace (not that unlikely since ifindexes are
per-namespace).
In particular we saw problems with dev->promiscuity, resulting
in "promiscuity touches roof, set promiscuity failed. promiscuity
feature of device might be broken" warnings and EOVERFLOW failures of
setsockopt(PACKET_ADD_MEMBERSHIP).
This patch deletes the mclist entries for interfaces that are deleted.
Since this now causes setsockopt(PACKET_DROP_MEMBERSHIP) to fail with
EADDRNOTAVAIL if called after the interface is deleted, also make
packet_mc_drop not fail.

Signed-off-by: Francesco Ruggeri 
---
 net/packet/af_packet.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 5bf1e96..f8db706 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3123,11 +3123,18 @@ static int packet_dev_mc(struct net_device *dev, struct 
packet_mclist *i,
return 0;
 }
 
-static void packet_dev_mclist(struct net_device *dev, struct packet_mclist *i, 
int what)
+static void packet_dev_mclist_delete(struct net_device *dev,
+struct packet_mclist **mlp)
 {
-   for ( ; i; i = i->next) {
-   if (i->ifindex == dev->ifindex)
-   packet_dev_mc(dev, i, what);
+   struct packet_mclist *ml;
+
+   while ((ml = *mlp) != NULL) {
+   if (ml->ifindex == dev->ifindex) {
+   packet_dev_mc(dev, ml, -1);
+   *mlp = ml->next;
+   kfree(ml);
+   } else
+   mlp = &ml->next;
}
 }
 
@@ -3204,12 +3211,11 @@ static int packet_mc_drop(struct sock *sk, struct 
packet_mreq_max *mreq)
packet_dev_mc(dev, ml, -1);
kfree(ml);
}
-   rtnl_unlock();
-   return 0;
+   break;
}
}
rtnl_unlock();
-   return -EADDRNOTAVAIL;
+   return 0;
 }
 
 static void packet_flush_mclist(struct sock *sk)
@@ -3559,7 +3565,7 @@ static int packet_notifier(struct notifier_block *this,
switch (msg) {
case NETDEV_UNREGISTER:
if (po->mclist)
-   packet_dev_mclist(dev, po->mclist, -1);
+   packet_dev_mclist_delete(dev, &po->mclist);
/* fallthrough */
 
case NETDEV_DOWN:
-- 
1.8.1.4

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

Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

[David Cohen]

Hi Linus,

On Mon, Mar 09, 2015 at 11:16:08AM -0500, Felipe Balbi wrote:
> On Sat, Mar 07, 2015 at 09:06:22PM +0100, Linus Walleij wrote:
> > On Fri, Feb 20, 2015 at 8:17 PM, David Cohen
> >  wrote:
> > > On Fri, Feb 20, 2015 at 10:53:44AM +0100, Linus Walleij wrote:
> > 
> > >> I would put this adjacent to the phy driver somewhere in drivers/usb/*
> > >> and make the actual USB-driver thing handle its GPIOs directly.
> > >> But I guess David and Felipe have already discussed that as we're
> > >> seeing this patch?
> > >
> > > - The mux functions would be controlled by a possible new pinctrl-gpio
> > > driver (Linus, your input here would be nice :)
> > 
> > I don't understand what this means, does it mean a pin control function
> > somewhere else controlled by a GPIO pin?
> > 
> > Or do you mean a new combined pin control and GPIO driver (we have
> > plenty of these).
> > 
> > If you elaborate on what you need to do in that driver I might
> > understand it better.

This is a "virtual" ACPI device. Long story short we've 3 GPIOs
controlling the state of an USB OTG port. Neither of the hw components
controlled by these GPIOs are connected to a bus.
The ACPI table was implemented in such way that it considers this USB
port as a single "device" giving all 3 GPIOs to it.

When upstreaming this driver, the feedback I got is to split this driver
into simpler and more generic ones. FWIW ACPI tables are constructed
considering a valid Linux API during its implementation and are quite
difficult to change after product is released. The solution would be to
use MFD subsystem: this driver would create simpler children platform
devices.

But at least on ACPI case, GPIO API blocks the ability to create
children platform devices that require GPIO as platform data, despite
we've many drivers on upstream that expect this behavior: e.g. extcon-gpio.c

Are we considering those driver deprecated from the GPIO point of view?
If yes, we need to provide an update for them (we can't let upstreamed
drivers broken). If no, we need to provide a way to move forward the
GPIO to children devices.

BR, David

> 
> there's a discrete mux (not something integrated in the SoC) whose
> select signal is tied to a GPIO (in some cases, more than one, but
> usually people use 2-state muxes).
> 
> -- 
> balbi


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

Re: [PATCH 0/3] clk: divider: three exactness fixes (and a rant)

[Stephen Boyd]

On 03/09/15 02:58, Philipp Zabel wrote:
> Am Freitag, den 06.03.2015, 11:40 -0800 schrieb Stephen Boyd:
>> On 03/06/15 11:28, Uwe Kleine-König wrote:
>>> Hello Mike,
>>>
>>> On Fri, Mar 06, 2015 at 10:57:30AM -0800, Mike Turquette wrote:
 Quoting Uwe Kleine-König (2015-02-21 02:40:22)
> Hello,
>
> TLDR: only apply patch 1 and rip of CLK_DIVIDER_ROUND_CLOSEST.
>
> I stared at clk-divider.c for some time now given Sascha's failing test
> case. I found a fix for the failure (which happens to be what Sascha
> suspected).
>
> The other two patches fix problems only present when handling dividers
> that have CLK_DIVIDER_ROUND_CLOSEST set. Note that these are still
> heavily broken however. So having a 4bit-divider and a parent clk of
> 1 (as in Sascha's test case) requesting
>
> clk_set_rate(clk, 666)
>
> sets the rate to 625 (div=15) instead of 667 (div=16). The reason is the
> choice of parent_rate in clk_divider_bestdiv's loop is wrong for
> CLK_DIVIDER_ROUND_CLOSEST (with and without patch 1). A fix here is
> non-trivial and for sure more than one rate must be tested here. This is
> complicated by the fact that clk_round_rate might return a value bigger
> than the requested rate which convinces me (once more) that it's a bad
> idea to allow that. Even if this was fixed for .round_rate,
> clk_divider_set_rate is still broken because it also uses
>
> div = DIV_ROUND_UP(parent_rate, rate);
>
> to calculate the (pretended) best divider to get near rate.
>
> Note this makes at least two reasons to remove support for
> CLK_DIVIDER_ROUND_CLOSEST!
>
> Instead I'd favour creating a function
>
> clk_round_rate_nearest
>
> as was suggested some time ago by Soren Brinkmann and me[1] that doesn't
 Uwe,

 Thanks for the fixes. I'm thinking of taking all three for 4.0. I also
 agree on clk_round_rate_nearest (along with a _ceil and _floor version
 as well). That's something we can do for 4.1 probably.
>>> I'd say that we make round_rate the _floor version. I guess in most
>>> cases that already does the right thing. Also I think 4.1 is very
>>> ambitious, so my suggestion for 4.1 is:
>>>
>>>  - add a WARN_ON_ONCE to clk_round_rate catching calls that return a
>>>value bigger than requested.
>>>  - implement clk_round_rate_nearest using clk_round_rate and the
>>>assumption that it returns a value that is <= the requested rate.
>>>I think without that there are too many special cases to handle and
>>>probably not even a reliable way to determine the nearest rate.
>>>  - while we're at it tightening the requirements for clk_round_rate
>>>let's also specify the expected rounding. I'd vote for the
>>>mathematical rounding, that is
>>>
>>> clk_round_rate(someclk, 333)
>>>
>>>explicitly is allowed to return a rate bigger than 333 as long as it
>>>is less than 333.5.
>>>
>>> At one point while developing patch 1 I had the dividers fixed for the
>>> rounding issue. I think I still have that patch somewhere so can post it
>>> as RFC.
>>>
>> Why do we need clk_round_rate_nearest? We have rate constraints now so
>> drivers should be moving towards requesting a rate that's within a
>> tolerance they can accept if they even care to enforce anything like
>> that. Eventually clk_round_rate() returning a value smaller or larger
>> than what it's called with won't matter as long as what the
>> implementation does fits within the constraints that consumers specify.
>> It may even be possible to remove clk_round_rate() as a consumer API.
> If I have to provide a panel pixel clock I usually want to get a rate as
> close as possible to the specified typical rate, but within the
> specified limits.
>
> Assume a panel with 70 MHz ideal pixel clock and a valid range of 60 MHz
> to 80 MHz. If the clock supply supports two frequencies within that
> range, 60 MHz and 72 MHz, I'd prefer 72 MHz to be chosen over 60 Mhz.
>
>

Hm.. Maybe we should tweak the arguments to clk_set_range() to have a
"typical" rate? So instead of the current API:

  int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned
long max)

we should have

 int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned
long typical, unsigned long max)

with the semantics that we'll set the rate within the min,max
constraints and try to get the rate as close to the typical rate as
possible? That would match quite a few datasheets out there that specify
these triplets.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH] iio: pressure: add support for MS5611 pressure and temperature sensor

[tduszyns]

On Sun, Mar 08, 2015 at 09:11:07PM +0200, Daniel Baluta wrote:
> Hi Tomasz,
>
> On Sun, Mar 8, 2015 at 7:29 PM, Tomasz Duszynski  wrote:
> > Add support for Measurement Specialities MS5611 pressure
> > and temperature sensor.
> >
> > Signed-off-by: Tomasz Duszynski 
>
> 
>
> > +++ b/drivers/iio/pressure/ms5611_i2c.c
> > @@ -0,0 +1,131 @@
> > +/*
> > + * MS5611 pressure and temperature sensor driver (I2C bus)
> > + *
> > + * Copyright (c) Tomasz Duszynski 
> > + *
> > + * 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.
> > + *
>
> If fixed, please specify here the I2C slave address.
OK
>
> > + */
> > +#include 
>
> 
>
> > +static int ms5611_read_adc(struct ms5611_state *st, s32 *val)
> > +{
> > +   int ret;
> > +   u8 buf[3];
> > +
> > +   ret = i2c_smbus_read_i2c_block_data(st->client, MS5611_READ_ADC,
> > +   3, buf);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   *val = (buf[0] << 16) | (buf[1] << 8) | buf[0];
>
> Hmm, buf[2] is not used. Is this intended or the formula
> has buf[2] as the last OR factor?
You're right. Last factor should be buf[2].
>
> thanks,
> Daniel.

Thanks for review!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: pressure: add support for MS5611 pressure and temperature sensor

[tduszyns]

Hi Peter,

On Sun, Mar 08, 2015 at 07:16:00PM +0100, Peter Meerwald wrote:
> > Add support for Measurement Specialities MS5611 pressure
> > and temperature sensor.
>
> comments inline below
>
> > Signed-off-by: Tomasz Duszynski 
> > ---
> >  drivers/iio/pressure/Kconfig   |  27 +
> >  drivers/iio/pressure/Makefile  |   4 +
> >  drivers/iio/pressure/ms5611.h  |  44 +++
> >  drivers/iio/pressure/ms5611_core.c | 239 
> > +
> >  drivers/iio/pressure/ms5611_i2c.c  | 131 
> >  drivers/iio/pressure/ms5611_spi.c  | 137 +
> >  6 files changed, 582 insertions(+)
> >  create mode 100644 drivers/iio/pressure/ms5611.h
> >  create mode 100644 drivers/iio/pressure/ms5611_core.c
> >  create mode 100644 drivers/iio/pressure/ms5611_i2c.c
> >  create mode 100644 drivers/iio/pressure/ms5611_spi.c
> >
> > diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
> > index a3be537..fa62950 100644
> > --- a/drivers/iio/pressure/Kconfig
> > +++ b/drivers/iio/pressure/Kconfig
> > @@ -52,6 +52,33 @@ config MPL3115
> >To compile this driver as a module, choose M here: the module
> >will be called mpl3115.
> >
> > +config MS5611
> > +   tristate "Measurement Specialities MS5611 pressure sensor driver"
> > +   help
> > + Say Y here to build support for the Measurement Specialities
> > + MS5611 pressure and temperature sensor.
> > +
> > + To compile this driver as a module, choose M here: the module will
> > + be called ms5611_core.
> > +
> > +config MS5611_I2C
> > +   tristate "support I2C bus connection"
> > +   depends on I2C && MS5611
> > +   help
> > + Say Y here to build I2C bus support for MS5611.
> > +
> > + To compile this driver as a module, choose M here: the module will
> > + be called ms5611_i2c.
> > +
> > +config MS5611_SPI
> > +   tristate "support SPI bus connection"
> > +   depends on SPI_MASTER && MS5611
> > +   help
> > + Say Y here to build SPI bus support for MS5611.
> > +
> > + To compile this driver as a module, choose M here: the module will
> > + be called ms5611_spi.
> > +
> >  config IIO_ST_PRESS
> > tristate "STMicroelectronics pressure sensor Driver"
> > depends on (I2C || SPI_MASTER) && SYSFS
> > diff --git a/drivers/iio/pressure/Makefile b/drivers/iio/pressure/Makefile
> > index 88011f2..82f34f6 100644
> > --- a/drivers/iio/pressure/Makefile
> > +++ b/drivers/iio/pressure/Makefile
> > @@ -14,3 +14,7 @@ obj-$(CONFIG_T5403) += t5403.o
> >
> >  obj-$(CONFIG_IIO_ST_PRESS_I2C) += st_pressure_i2c.o
> >  obj-$(CONFIG_IIO_ST_PRESS_SPI) += st_pressure_spi.o
> > +
>
> alphebetic order?
Fixed
>
> > +obj-$(CONFIG_MS5611) += ms5611_core.o
> > +obj-$(CONFIG_MS5611_I2C) += ms5611_i2c.o
> > +obj-$(CONFIG_MS5611_SPI) += ms5611_spi.o
> > diff --git a/drivers/iio/pressure/ms5611.h b/drivers/iio/pressure/ms5611.h
> > new file mode 100644
> > index 000..f4d44a5
> > --- /dev/null
> > +++ b/drivers/iio/pressure/ms5611.h
> > @@ -0,0 +1,44 @@
> > +/*
> > + * MS5611 pressure and temperature sensor driver
> > + *
> > + * Copyright (c) Tomasz Duszynski 
> > + *
> > + * 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.
> > + *
> > + */
> > +#ifndef _MS5611_H
> > +#define _MS5611_H
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MS5611_RESET   0x1e
> > +#define MS5611_READ_ADC0x00
> > +#define MS5611_READ_PROM_WORD  0xA0
> > +#define MS5611_START_TEMP_CONV 0x58
> > +#define MS5611_START_PRESSURE_CONV 0x48
> > +
> > +#define MS5611_CONV_TIME_MIN   9040
> > +#define MS5611_CONV_TIME_MAX   1
> > +
> > +#define MS5611_PROM_WORDS_NB   8
> > +
> > +struct ms5611_state {
> > +   void *client;
> > +   struct mutex lock;
> > +
> > +   int (*reset)(struct device *dev);
> > +   int (*read_prom_word)(struct device *dev, int index, u16 *word);
> > +   int (*read_adc_temp_and_pressure)(struct device *dev,
> > + s32 *temp, s32 *pressure);
> > +
>
> probably regmap could be used to avoid duplicate code?
All communication with this sensor is command based and I don't see
how regmap would fit here.
>
> > +   u16 prom[MS5611_PROM_WORDS_NB];
> > +};
> > +
> > +int ms5611_probe(struct iio_dev *indio_dev, struct device *dev);
> > +int ms5611_remove(struct iio_dev *indio_dev);
> > +
> > +#endif /* _MS5611_H */
> > diff --git a/drivers/iio/pressure/ms5611_core.c 
> > b/drivers/iio/pressure/ms5611_core.c
> > new file mode 100644
> > index 000..e4deda7
> > --- /dev/null
> > +++ b/drivers/iio/pressure/ms5611_core.c
> > @@ -0,0 +1,239 @@
> > +/*
> > + * MS5611 pressure and temperature sensor driver
> > + *
> > + * Copyright (c) Tomasz Duszynski 
> > + *
> > + * This program 

Re: [PATCH v5 3/8] pinctrl: cygnus: add initial IOMUX driver support

[Ray Jui]

On 3/9/2015 11:40 AM, Paul Bolle wrote:
> Linus Walleij schreef op ma 09-03-2015 om 17:28 [+0100]:
>> I think you're right. Or I fear you're right.
>>
>> But this problem is present in so many drivers that a generic
>> fixup needs to be done with a script and across an entire subsystem
>> at once,
> 
> Why don't we start with checking for similar cases during review, like
> I'm now doing for only a week or two?
> 
>>  and besides I'm not sure of these macros disturb so much.
> 
> I think they're confusing at best. Ie, when reading the code and the
> corresponding Kconfig file one has to wonder: should the Kconfig symbol
> actually be tristate or should it stay bool but did someone forget to
> delete the module-specific code?
> 
>> They are documentation in a sense, albeit a kind of documentation
>> we used before we had git to record the actual authors of the
>> code.
> 
> They're useful, mostly, for module utilities. Outside that scope they
> add information that thousands of files (that can also only be built-in
> but do not have these macros) do not have and, apparently, do not need.

I think it depends on how you see it. Based on this logic, then one can
also argue comments in the code will be pre-processed away and are not
needed. They at least serve the same documentation purpose in a way. So
far I haven't seen other people complaining that having these module
based macros in the driver are confusing when the Kconfig has a bool.

Ray

> 
> Thanks,
> 
> 
> Paul Bolle
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] spmi: pmic_arb: enable build on arm64 platforms

[Paul Bolle]

Stanimir Varbanov schreef op ma 09-03-2015 om 18:53 [+0200]:
> On 02/23/2015 02:57 PM, Ivan T. Ivanov wrote:
> > What if we just drop ARM dependency? 
> 
> I'm fine with this, Paul?

Well I'm fine with anything you do, as long as the Kconfig dependencies
make sense and the commit summary and the commit explanation match the
change. In other words: if you submit an updated patch and I don't bark
you may assume I'm fine with the change. This doesn't need an Ack on my
side anyhow (as if anything does).

Thanks,


Paul Bolle

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

Re: [PATCH v4 2/2] cgroups: add a pids subsystem

[Austin S Hemmelgarn]

On 2015-03-08 23:34, Tejun Heo wrote:


Does pids limit make sense in the root cgroup?

I would say it kind of does, although I would just expect it to track 
/proc/sys/kernel/pid_max (either as a read-only value, or as an 
alternative way to set it).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1 linux-next] fs/hfsplus: use bool instead of int for is_known_namespace() return value

[Fabian Frederick]

is_known_namespace() only returns true/false.
Also remove inline and let compiler decide what to do with
static functions.

Inspired-by: "David S. Miller" 
Cc: Andrew Morton 
Signed-off-by: Fabian Frederick 
---
 fs/hfsplus/xattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index 16f545d..8d62de0 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -44,7 +44,7 @@ static int strcmp_xattr_acl(const char *name)
return -1;
 }
 
-static inline int is_known_namespace(const char *name)
+static bool is_known_namespace(const char *name)
 {
if (strncmp(name, XATTR_SYSTEM_PREFIX, XATTR_SYSTEM_PREFIX_LEN) &&
strncmp(name, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN) &&
-- 
1.9.1

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

Re: [PATCH 2/2] spi: qup: Request CS GPIO's during probe

[Stephen Boyd]

On 03/09/15 01:20, Ivan T. Ivanov wrote:
> Hi Stephen,
>
>> On Mar 6, 2015, at 8:34 PM, Stephen Boyd  wrote:
>> On 03/06/15 07:26, Ivan T. Ivanov wrote:
>>> Ensure that driver is owner of the GPIO's used for CS signals.
>> Why? What happens if we don’t?
> We can have wrong DT configuration, which could reconfigure
> GPIO’s without any warning or error.

Ouch. That sounds bad. Can you please add this information to the commit
text?

>
>>> Signed-off-by: Ivan T. Ivanov 
>>> ---
>>> drivers/spi/spi-qup.c | 17 -
>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
>>> index 2b2c359..a07ba46 100644
>>> --- a/drivers/spi/spi-qup.c
>>> +++ b/drivers/spi/spi-qup.c
>>> @@ -14,11 +14,13 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>> #include 
>>> #include 
>>> @@ -499,7 +501,7 @@ static int spi_qup_probe(struct platform_device *pdev)
>>> struct device *dev;
>>> void __iomem *base;
>>> u32 max_freq, iomode, num_cs;
>>> -   int ret, irq, size;
>>> +   int ret, irq, size, cs, cs_gpio;
>>>
>>> dev = &pdev->dev;
>>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> @@ -556,6 +558,19 @@ static int spi_qup_probe(struct platform_device *pdev)
>>> else
>>> master->num_chipselect = num_cs;
>>>
>>> +   for (cs = 0; cs < master->num_chipselect; cs++) {
>>> +   cs_gpio = of_get_named_gpio(dev->of_node, "cs-gpios", cs);
>>> +
>>> +   if (!gpio_is_valid(cs_gpio))
>>> +   continue;
>>> +
>>> +   ret = devm_gpio_request(&pdev->dev, cs_gpio, "spi-qup-cs");
>>> +   if (ret) {
>>> +   dev_err(&pdev->dev, "can't get cs gpios\n");
>>> +   goto error;
>>> +   }
>>> +   }
>>> +
>>> master->bus_num = pdev->id;
>> Is this related to [1]? In that case I was just relying on DT/pinctrl to
>> properly request the gpios.
> But the DT/pinctrl did not request GPIO’s, it just configure them.
> For some reason we are ending without any pinctrl_map of type 
> PIN_MAP_TYPE_MUX_GROUP, which is used for pin reservation. 
>

Ah ok. I seem to be misremembering the details.

Can you please use the gpiod interfaces here (devm_gpiod_get_index)?
That's more modern. Also, don't print any error because -EPROBE_DEFER
may come out and because __gpiod_get_index() already prints an error on
failure at the debug level.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH v2 1/1] serial: 8250_dw: Fix get_mctrl behaviour

[Jonathan Richardson]

On 15-03-09 11:40 AM, Dmitry Torokhov wrote:
> On Thu, Feb 26, 2015 at 4:35 PM, Jonathan Richardson
>  wrote:
>> @@ -334,6 +342,30 @@ static int dw8250_probe_of(struct uart_port *p,
>> if (id >= 0)
>> p->line = id;
>>
>> +   if (of_property_read_bool(np, "dcd-override")) {
>> +   /* Always report DCD as active */
>> +   data->msr_mask_on |= UART_MSR_DCD;
>> +   data->msr_mask_off |= UART_MSR_DDCD;
>> +   }
>> +
>> +   if (of_property_read_bool(np, "dsr-override")) {
>> +   /* Always report DSR as active */
>> +   data->msr_mask_on |= UART_MSR_DSR;
>> +   data->msr_mask_off |= UART_MSR_DDSR;
>> +   }
>> +
>> +   if (of_property_read_bool(np, "cts-override")) {
>> +   /* Always report DSR as active */
>> +   data->msr_mask_on |= UART_MSR_DSR;
>> +   data->msr_mask_off |= UART_MSR_DDSR;
>> +   }
>> +
>> +   if (of_property_read_bool(np, "ri-override")) {
>> +   /* Always report Ring indicator as inactive */
>> +   data->msr_mask_off |= UART_MSR_RI;
>> +   data->msr_mask_off |= UART_MSR_TERI;
> 
> This looks like a typo. Should the 1st line be data->msr_mask_on by any 
> chance?

I think the code is correct. The signals other than ri need to be
reported as active (masked on) if specified, but ri needs to be inactive
(masked off) unlike the other 3. This is stated in the kernel docs
mentioned in the commit. ri behaves differently than the others.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/8] pinctrl: cygnus: add gpio/pinconf driver

[Paul Bolle]

Linus Walleij schreef op ma 09-03-2015 om 17:41 [+0100]:
> As pointed out in another mail on similar subject, I think these macros
> are a kind of obsolete documentation and if they should be dropped we
> need to go over an entire subsystem at a time and remove all boolean users
> in a big patch.

And, as I stated in that other thread, we could start by first checking
for things like this during review. (And if people were to do clean up
patches I'd suggest to do them one driver at a time. Just to keep things
manageable.)


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1 linux-next] fs/hfsplus: atomically set inode->i_flags

[Fabian Frederick]

According to commit 5f16f3225b06

("ext4: atomically set inode->i_flags in ext4_set_inode_flags()")

Cc: "Theodore Ts'o" 
Cc: Andrew Morton 
Signed-off-by: Fabian Frederick 
---
 fs/hfsplus/ioctl.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/fs/hfsplus/ioctl.c b/fs/hfsplus/ioctl.c
index d3ff5cc..8e98f5d 100644
--- a/fs/hfsplus/ioctl.c
+++ b/fs/hfsplus/ioctl.c
@@ -76,7 +76,7 @@ static int hfsplus_ioctl_setflags(struct file *file, int 
__user *user_flags)
 {
struct inode *inode = file_inode(file);
struct hfsplus_inode_info *hip = HFSPLUS_I(inode);
-   unsigned int flags;
+   unsigned int flags, new_fl = 0;
int err = 0;
 
err = mnt_want_write_file(file);
@@ -110,14 +110,12 @@ static int hfsplus_ioctl_setflags(struct file *file, int 
__user *user_flags)
}
 
if (flags & FS_IMMUTABLE_FL)
-   inode->i_flags |= S_IMMUTABLE;
-   else
-   inode->i_flags &= ~S_IMMUTABLE;
+   new_fl |= S_IMMUTABLE;
 
if (flags & FS_APPEND_FL)
-   inode->i_flags |= S_APPEND;
-   else
-   inode->i_flags &= ~S_APPEND;
+   new_fl |= S_APPEND;
+
+   inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
 
if (flags & FS_NODUMP_FL)
hip->userflags |= HFSPLUS_FLG_NODUMP;
-- 
1.9.1

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

Re: [PATCH v5 3/8] pinctrl: cygnus: add initial IOMUX driver support

[Paul Bolle]

Linus Walleij schreef op ma 09-03-2015 om 17:28 [+0100]:
> I think you're right. Or I fear you're right.
> 
> But this problem is present in so many drivers that a generic
> fixup needs to be done with a script and across an entire subsystem
> at once,

Why don't we start with checking for similar cases during review, like
I'm now doing for only a week or two?

>  and besides I'm not sure of these macros disturb so much.

I think they're confusing at best. Ie, when reading the code and the
corresponding Kconfig file one has to wonder: should the Kconfig symbol
actually be tristate or should it stay bool but did someone forget to
delete the module-specific code?

> They are documentation in a sense, albeit a kind of documentation
> we used before we had git to record the actual authors of the
> code.

They're useful, mostly, for module utilities. Outside that scope they
add information that thousands of files (that can also only be built-in
but do not have these macros) do not have and, apparently, do not need.

Thanks,


Paul Bolle

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

[PATCH 3/4] x86: save user rsp in pt_regs->sp on SYSCALL64 fastpath

[Denys Vlasenko]

PER_CPU(old_rsp) usage is simplified - now it is used only
as temp storage, and userspace stack pointer is immediately stored
in pt_regs->sp on syscall entry, instead of being used later,
on syscall exit.

Instead of PER_CPU(old_rsp) and task->thread.usersp, C code
uses pt_regs->sp now.

FIXUP/RESTORE_TOP_OF_STACK are simplified.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Steven Rostedt 
CC: Ingo Molnar 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Oleg Nesterov 
CC: Frederic Weisbecker 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
 arch/x86/include/asm/compat.h |  2 +-
 arch/x86/include/asm/ptrace.h |  8 ++--
 arch/x86/kernel/entry_64.S| 18 +++---
 arch/x86/kernel/perf_regs.c   |  2 +-
 arch/x86/kernel/process_64.c  |  3 +--
 5 files changed, 12 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
index 59c6c40..acdee09 100644
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@ -301,7 +301,7 @@ static inline void __user 
*arch_compat_alloc_user_space(long len)
sp = task_pt_regs(current)->sp;
} else {
/* -128 for the x32 ABI redzone */
-   sp = this_cpu_read(old_rsp) - 128;
+   sp = task_pt_regs(current)->sp - 128;
}
 
return (void __user *)round_down(sp - len, 16);
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 4077d96..74bb2e0 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -145,12 +145,8 @@ static inline bool user_64bit_mode(struct pt_regs *regs)
 #endif
 }
 
-#define current_user_stack_pointer()   this_cpu_read(old_rsp)
-/* ia32 vs. x32 difference */
-#define compat_user_stack_pointer()\
-   (test_thread_flag(TIF_IA32) \
-? current_pt_regs()->sp\
-: this_cpu_read(old_rsp))
+#define current_user_stack_pointer()   current_pt_regs()->sp
+#define compat_user_stack_pointer()current_pt_regs()->sp
 #endif
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 703ced0..d86788c 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -128,8 +128,6 @@ ENDPROC(native_usergs_sysret64)
  * manipulation.
  */
.macro FIXUP_TOP_OF_STACK tmp offset=0
-   movq PER_CPU_VAR(old_rsp),\tmp
-   movq \tmp,RSP+\offset(%rsp)
movq $__USER_DS,SS+\offset(%rsp)
movq $__USER_CS,CS+\offset(%rsp)
movq RIP+\offset(%rsp),\tmp  /* get rip */
@@ -139,8 +137,7 @@ ENDPROC(native_usergs_sysret64)
.endm
 
.macro RESTORE_TOP_OF_STACK tmp offset=0
-   movq RSP+\offset(%rsp),\tmp
-   movq \tmp,PER_CPU_VAR(old_rsp)
+   /* nothing to do */
.endm
 
 /*
@@ -222,9 +219,6 @@ ENDPROC(native_usergs_sysret64)
  * Interrupts are off on entry.
  * Only called from user space.
  *
- * XXX if we had a free scratch register we could save the RSP into the stack 
frame
- *  and report it properly in ps. Unfortunately we haven't.
- *
  * When user can change the frames always force IRET. That is because
  * it deals with uncanonical addresses better. SYSRET has trouble
  * with them due to bugs in both AMD and Intel CPUs.
@@ -253,11 +247,13 @@ GLOBAL(system_call_after_swapgs)
 */
ENABLE_INTERRUPTS(CLBR_NONE)
ALLOC_PT_GPREGS_ON_STACK 8  /* +8: space for orig_ax */
+   movq%rcx,RIP(%rsp)
+   movqPER_CPU_VAR(old_rsp),%rcx
+   movq%r11,EFLAGS(%rsp)
+   movq%rcx,RSP(%rsp)
+   movq_cfi rax,ORIG_RAX
SAVE_C_REGS_EXCEPT_RAX_RCX_R11
movq$-ENOSYS,RAX(%rsp)
-   movq_cfi rax,ORIG_RAX
-   movq%r11,EFLAGS(%rsp)
-   movq%rcx,RIP(%rsp)
CFI_REL_OFFSET rip,RIP
testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP)
jnz tracesys
@@ -293,7 +289,7 @@ ret_from_sys_call:
CFI_REGISTERrip,rcx
movqEFLAGS(%rsp),%r11
/*CFI_REGISTER  rflags,r11*/
-   movqPER_CPU_VAR(old_rsp), %rsp
+   movqRSP(%rsp),%rsp
/*
 * 64bit SYSRET restores rip from rcx,
 * rflags from r11 (but RF and VM bits are forced to 0),
diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c
index 781861c..02a8720 100644
--- a/arch/x86/kernel/perf_regs.c
+++ b/arch/x86/kernel/perf_regs.c
@@ -177,7 +177,7 @@ void perf_get_regs_user(struct perf_regs *regs_user,
 * than just blindly copying user_regs.
 */
regs_user->abi = PERF_SAMPLE_REGS_ABI_64;
-   regs_user_copy->sp = this_cpu_read(old_rsp);
+   regs_user_copy->sp = user_regs->sp;
regs_user_copy->cs = __USER_CS;
regs_user_copy->ss = __USER_DS;
regs_user_copy->cx = -1;  /* usually contains garbage */
diff --git a/a

Re: [PATCH v2 1/1] serial: 8250_dw: Fix get_mctrl behaviour

[Dmitry Torokhov]

On Thu, Feb 26, 2015 at 4:35 PM, Jonathan Richardson
 wrote:
> @@ -334,6 +342,30 @@ static int dw8250_probe_of(struct uart_port *p,
> if (id >= 0)
> p->line = id;
>
> +   if (of_property_read_bool(np, "dcd-override")) {
> +   /* Always report DCD as active */
> +   data->msr_mask_on |= UART_MSR_DCD;
> +   data->msr_mask_off |= UART_MSR_DDCD;
> +   }
> +
> +   if (of_property_read_bool(np, "dsr-override")) {
> +   /* Always report DSR as active */
> +   data->msr_mask_on |= UART_MSR_DSR;
> +   data->msr_mask_off |= UART_MSR_DDSR;
> +   }
> +
> +   if (of_property_read_bool(np, "cts-override")) {
> +   /* Always report DSR as active */
> +   data->msr_mask_on |= UART_MSR_DSR;
> +   data->msr_mask_off |= UART_MSR_DDSR;
> +   }
> +
> +   if (of_property_read_bool(np, "ri-override")) {
> +   /* Always report Ring indicator as inactive */
> +   data->msr_mask_off |= UART_MSR_RI;
> +   data->msr_mask_off |= UART_MSR_TERI;

This looks like a typo. Should the 1st line be data->msr_mask_on by any chance?

Thanks,
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 1/4] Cleaned hexadecimal dump

[Mark Brown]

On Sat, Mar 07, 2015 at 12:56:32PM -0500, Adrian Remonda wrote:

> +static void hexDump(const void *src, size_t length, size_t bLine, char 
> *prefix)
> +{

Please call this hex_dump or something - that's more in line with the
kernel coding style.  Please also don't vUse aHungarian nNotation, it's
also not the kernel coding style.


signature.asc
Description: Digital signature

[PATCH 1/4] x86: save r11 into pt_regs->flags on SYSCALL64 fastpath

[Denys Vlasenko]

Before this patch, r11 was saved in pt_regs->r11.
Which looks natural, but requires messy shuffling to/from iret frame
whenever ptrace or e.g. sys_iopl wants to modify flags - because
that's how this register is used by SYSCALL/SYSRET.

This patch saves r11 in pt_regs->flags,
and uses that value for SYSRET64 insn. Shuffling is eliminated.

FIXUP/RESTORE_TOP_OF_STACK are simplified.

stub_iopl is no longer needed: pt_regs->flags needs no fixing up.

Testing shows that syscall fast path is ~54.3 ns before
and after the patch (on 2.7 GHz Sandy Bridge CPU).

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Steven Rostedt 
CC: Ingo Molnar 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Oleg Nesterov 
CC: Frederic Weisbecker 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
 arch/x86/include/asm/calling.h | 20 ++--
 arch/x86/kernel/entry_64.S | 24 +++-
 2 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/arch/x86/include/asm/calling.h b/arch/x86/include/asm/calling.h
index f1a962f..4b5f7bf 100644
--- a/arch/x86/include/asm/calling.h
+++ b/arch/x86/include/asm/calling.h
@@ -95,9 +95,11 @@ For 32-bit we have the following conventions - kernel is 
built with
CFI_ADJUST_CFA_OFFSET 15*8+\addskip
.endm
 
-   .macro SAVE_C_REGS_HELPER offset=0 rax=1 rcx=1 r8plus=1
-   .if \r8plus
+   .macro SAVE_C_REGS_HELPER offset=0 rax=1 rcx=1 r8910=1 r11=1
+   .if \r11
movq_cfi r11, 6*8+\offset
+   .endif
+   .if \r8910
movq_cfi r10, 7*8+\offset
movq_cfi r9,  8*8+\offset
movq_cfi r8,  9*8+\offset
@@ -113,16 +115,19 @@ For 32-bit we have the following conventions - kernel is 
built with
movq_cfi rdi, 14*8+\offset
.endm
.macro SAVE_C_REGS offset=0
-   SAVE_C_REGS_HELPER \offset, 1, 1, 1
+   SAVE_C_REGS_HELPER \offset, 1, 1, 1, 1
.endm
.macro SAVE_C_REGS_EXCEPT_RAX_RCX offset=0
-   SAVE_C_REGS_HELPER \offset, 0, 0, 1
+   SAVE_C_REGS_HELPER \offset, 0, 0, 1, 1
.endm
.macro SAVE_C_REGS_EXCEPT_R891011
-   SAVE_C_REGS_HELPER 0, 1, 1, 0
+   SAVE_C_REGS_HELPER 0, 1, 1, 0, 0
.endm
.macro SAVE_C_REGS_EXCEPT_RCX_R891011
-   SAVE_C_REGS_HELPER 0, 1, 0, 0
+   SAVE_C_REGS_HELPER 0, 1, 0, 0, 0
+   .endm
+   .macro SAVE_C_REGS_EXCEPT_RAX_RCX_R11
+   SAVE_C_REGS_HELPER 0, 0, 0, 1, 0
.endm
 
.macro SAVE_EXTRA_REGS offset=0
@@ -179,6 +184,9 @@ For 32-bit we have the following conventions - kernel is 
built with
.macro RESTORE_C_REGS_EXCEPT_R11
RESTORE_C_REGS_HELPER 1,1,0,1,1
.endm
+   .macro RESTORE_C_REGS_EXCEPT_RCX_R11
+   RESTORE_C_REGS_HELPER 1,0,0,1,1
+   .endm
.macro RESTORE_RSI_RDI
RESTORE_C_REGS_HELPER 0,0,0,0,0
.endm
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 5117a2b..324200a 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -121,14 +121,12 @@ ENDPROC(native_usergs_sysret64)
 #endif
 
 /*
- * C code is not supposed to know about undefined top of stack. Every time
- * a C function with an pt_regs argument is called from the SYSCALL based
- * fast path FIXUP_TOP_OF_STACK is needed.
+ * C code is not supposed to know that the iret frame is not populated.
+ * Every time a C function with an pt_regs argument is called from
+ * the SYSCALL based fast path FIXUP_TOP_OF_STACK is needed.
  * RESTORE_TOP_OF_STACK syncs the syscall state after any possible ptregs
  * manipulation.
  */
-
-   /* %rsp:at FRAMEEND */
.macro FIXUP_TOP_OF_STACK tmp offset=0
movq PER_CPU_VAR(old_rsp),\tmp
movq \tmp,RSP+\offset(%rsp)
@@ -136,15 +134,13 @@ ENDPROC(native_usergs_sysret64)
movq $__USER_CS,CS+\offset(%rsp)
movq RIP+\offset(%rsp),\tmp  /* get rip */
movq \tmp,RCX+\offset(%rsp)  /* copy it to rcx as sysret would do */
-   movq R11+\offset(%rsp),\tmp  /* get eflags */
-   movq \tmp,EFLAGS+\offset(%rsp)
+   movq EFLAGS+\offset(%rsp),\tmp /* ditto for rflags->r11 */
+   movq \tmp,R11+\offset(%rsp)
.endm
 
.macro RESTORE_TOP_OF_STACK tmp offset=0
movq RSP+\offset(%rsp),\tmp
movq \tmp,PER_CPU_VAR(old_rsp)
-   movq EFLAGS+\offset(%rsp),\tmp
-   movq \tmp,R11+\offset(%rsp)
.endm
 
 /*
@@ -257,9 +253,10 @@ GLOBAL(system_call_after_swapgs)
 */
ENABLE_INTERRUPTS(CLBR_NONE)
ALLOC_PT_GPREGS_ON_STACK 8  /* +8: space for orig_ax */
-   SAVE_C_REGS_EXCEPT_RAX_RCX
+   SAVE_C_REGS_EXCEPT_RAX_RCX_R11
movq$-ENOSYS,RAX(%rsp)
movq_cfi rax,ORIG_RAX
+   movq%r11,EFLAGS(%rsp)
movq%rcx,RIP(%rsp)
CFI_REL_OFFSET rip,RIP
testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP)
@@ -277,7 +274,7 @@ system_call_fastpath:
 

Re: [PATCH 3/4] Added input buffer from the terminal.

[Mark Brown]

On Sat, Mar 07, 2015 at 12:56:34PM -0500, Adrian Remonda wrote:

> + int ret = 0;
> + char *pSrc = src;

The kernel coding style doesn't use Hungarian notation...

> + if (input_tx) {
> + size = strlen(input_tx+1);
> + tx = (uint8_t *)malloc(size);
> + rx = (uint8_t *)malloc(size);

You should never need to cast the return value of malloc() - if it's
needed it's masking some other problem.


signature.asc
Description: Digital signature

[PATCH 0/4 v2] x86: entry_64.S: steps towards simpler iret frame handling

[Denys Vlasenko]

These changes make SYSENTER64 code path save flags and user's
stack pointer in pt_regs->flags and pt_regs->sp, where they belong.

As a result, we can drop stub_iopl() and thread_struct::usersp.

Usage of PER_CPU(old_rsp) is reduced to bare minimum.

FIXUP/RESTORE_TOP_OF_STACK macros are on diet too.

Changes since v1: on Ingo's request, split into 4 patches intead of 2.

CC: Linus Torvalds 
CC: Steven Rostedt 
CC: Ingo Molnar 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Oleg Nesterov 
CC: Frederic Weisbecker 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org

Denys Vlasenko (4):
  x86: save r11 into pt_regs->flags on SYSCALL64 fastpath
  Remove stub_iopl
  x86: save user %rsp in pt_regs->sp on SYSCALL64 fastpath
  Remove unused stuff

 arch/x86/include/asm/calling.h   | 20 +-
 arch/x86/include/asm/compat.h|  2 +-
 arch/x86/include/asm/processor.h |  6 -
 arch/x86/include/asm/ptrace.h|  8 ++
 arch/x86/kernel/entry_64.S   | 57 ++--
 arch/x86/kernel/perf_regs.c  |  2 +-
 arch/x86/kernel/process_64.c |  8 +-
 arch/x86/syscalls/syscall_64.tbl |  2 +-
 arch/x86/um/sys_call_table_64.c  |  2 +-
 9 files changed, 40 insertions(+), 67 deletions(-)

-- 
1.8.1.4

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

Re: [PATCH] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)

[Andy Lutomirski]

On Mon, Mar 9, 2015 at 11:16 AM, Linus Torvalds
 wrote:
> On Mon, Mar 9, 2015 at 11:04 AM, Andy Lutomirski  wrote:
>>
>> One option would be to change the NMI entry code to move itself down 8
>> bytes if this happens (came from kernel mode or sp == sp0 - 12,
>> perhaps).
>
> Hmm. That whole code currently depends on the stack setup being just a
> single instruction (the move to esp). And that simplifies things, I'd
> like to keep it that way.
>
> I'd *much* rather just keep the 8-byte padding. What was so
> problematic with that? It worked. It's been around forever. Removing
> it is the bug.

Let's at least fix it, then.  processor.h has:

#define INIT_TSS  {  \
.x86_tss = {  \
.sp0= sizeof(init_stack) + (long)&init_stack, \

(moved in -tip)

That's bogus, and this bogosity is why I broke 32-bit -next in the
first place: I assumed it was correct.

I'll get it if no one beats me to it.

--Andy

>
> Linus



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] Rename regulator_set_optimum_mode

[Mark Brown]

On Wed, Feb 11, 2015 at 07:35:26PM -0800, Bjorn Andersson wrote:
> Changing the name of the regulator_set_optimum_mode() to
> regulator_set_load() better reflects that the API is doing.

Applied all, thanks.


signature.asc
Description: Digital signature

Re: [PATCH] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)

[Denys Vlasenko]

On Mon, Mar 9, 2015 at 7:16 PM, Linus Torvalds
 wrote:
> On Mon, Mar 9, 2015 at 11:04 AM, Andy Lutomirski  wrote:
>>
>> One option would be to change the NMI entry code to move itself down 8
>> bytes if this happens (came from kernel mode or sp == sp0 - 12,
>> perhaps).
>
> Hmm. That whole code currently depends on the stack setup being just a
> single instruction (the move to esp). And that simplifies things, I'd
> like to keep it that way.
>
> I'd *much* rather just keep the 8-byte padding. What was so
> problematic with that? It worked. It's been around forever. Removing
> it is the bug.

Unfortunately, looks like keeping the gap is the safest thing to do.

Hopes that tss.sp0 was true top of the stack, sans "a few little problems",
died so quickly :/
(and we didn't even touch vm86 yet).

We probably better off to give that 8 a name. Now it's just another
magic constant in the entry.S maze.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: sama5d4: Properly configure L2CC

[Alexandre Belloni]

On 09/03/2015 at 17:23:37 +, Russell King - ARM Linux wrote :
> On Wed, Mar 04, 2015 at 12:29:23PM +0100, Alexandre Belloni wrote:
> > As the bootloader may not properly configure the L2CC, enforce its 
> > configuration
> > in the kernel.
> > 
> > Signed-off-by: Alexandre Belloni 
> 
> And I assume you never bothered to read the kernel messages which result
> from this?  I guess this means I need to ensure that the kernel freezes
> if you do this kind of thing so you can't ignore the complaints from
> the L2C code.
> 
> It would be much better if you configured the L2C in the boot loader/
> board firmware rather than trying to have the kernel do it.
> 

As I understand, there is no proper way to enable prefetch from the
kernel so if it is not done by the bootloader or firmware (and it is
not), then we are out of luck.

Or is there something done right on berlin and exynos that I'm not doing
here?


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] driver core: fix several coding style warnings

[Joe Perches]

On Mon, 2015-03-09 at 20:08 +0200, Ioana Antoche wrote:
> Fix checkpatch.pl warnings such as:
> * missing blank line after declarations
> * line over 80 characters
> 
> Signed-off-by: Ioana Antoche 
> ---
> * undo changes related to "ERROR: that open brace { should be on the previous 
> line".

Not quite.

> diff --git a/drivers/base/bus.c b/drivers/base/bus.c

> @@ -298,8 +299,7 @@ static struct device *next_device(struct klist_iter *i)
>   * count in the supplied callback.
>   */
>  int bus_for_each_dev(struct bus_type *bus, struct device *start,
> -  void *data, int (*fn)(struct device *, void *))
> -{
> +  void *data, int (*fn)(struct device *, void *)) {

Don't want this change here.

> @@ -395,7 +395,8 @@ struct device *subsys_find_device_by_id(struct bus_type 
> *subsys, unsigned int id
>   return NULL;
>  
>   if (hint) {
> - klist_iter_init_node(&subsys->p->klist_devices, &i, 
> &hint->p->knode_bus);
> + klist_iter_init_node(&subsys->p->klist_devices, &i,
> + &hint->p->knode_bus);

Please run your patches though checkpatch --strict.

This second line should be aligned to the open parenthesis like:

klist_iter_init_node(&subsys->p->klist_devices, &i,
 &hint->p->knode_bus);


> @@ -448,8 +449,7 @@ static struct device_driver *next_driver(struct 
> klist_iter *i)
>   * so it doesn't disappear before returning to the caller.
>   */
>  int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
> -  void *data, int (*fn)(struct device_driver *, void *))
> -{
> +  void *data, int (*fn)(struct device_driver *, void *)) {

Maybe you re-sent your original patch?

> @@ -1092,7 +1095,8 @@ struct device *subsys_dev_iter_next(struct 
> subsys_dev_iter *iter)
>   knode = klist_next(&iter->ki);
>   if (!knode)
>   return NULL;
> - dev = container_of(knode, struct device_private, 
> knode_bus)->device;
> + dev = container_of(knode, struct device_private, knode_bus)
> +   ->device;

That's not nice to read.
If it exceeds 80 columns, just leave it alone
or if it really bothers you, use a temporary
for container_of then dereference that.



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

Re: [PATCH] ASoC: tlv320aic23: remove incorrect __exit markups

[Mark Brown]

On Mon, Mar 09, 2015 at 11:18:14AM -0700, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, the devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_probe() which specifically disables sysfs bind/unbind
> attributes.

Applied, thanks.


signature.asc
Description: Digital signature

[PATCH] ASoC: tlv320aic23: remove incorrect __exit markups

[Dmitry Torokhov]

Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Signed-off-by: Dmitry Torokhov 
---
 sound/soc/codecs/tlv320aic23-i2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic23-i2c.c 
b/sound/soc/codecs/tlv320aic23-i2c.c
index f137019..78a94af 100644
--- a/sound/soc/codecs/tlv320aic23-i2c.c
+++ b/sound/soc/codecs/tlv320aic23-i2c.c
@@ -31,7 +31,7 @@ static int tlv320aic23_i2c_probe(struct i2c_client *i2c,
return tlv320aic23_probe(&i2c->dev, regmap);
 }
 
-static int __exit tlv320aic23_i2c_remove(struct i2c_client *i2c)
+static int tlv320aic23_i2c_remove(struct i2c_client *i2c)
 {
snd_soc_unregister_codec(&i2c->dev);
return 0;
@@ -56,7 +56,7 @@ static struct i2c_driver tlv320aic23_i2c_driver = {
   .of_match_table = of_match_ptr(tlv320aic23_of_match),
   },
.probe = tlv320aic23_i2c_probe,
-   .remove = __exit_p(tlv320aic23_i2c_remove),
+   .remove = tlv320aic23_i2c_remove,
.id_table = tlv320aic23_id,
 };
 
-- 
2.2.0.rc0.207.ga3a616c


-- 
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] perf, x86: Fix Haswell CYCLE_ACTIVITY.* counter constraints

[Andi Kleen]

From: Andi Kleen 

Some of the CYCLE_ACTIVITY.* events can only be scheduled on
counter 2.  Due to a typo Haswell matched those with
INTEL_EVENT_CONSTRAINT, which lead to the events never
matching as the comparison does not expect anything
in the umask too. Fix the typo.

Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/cpu/perf_event_intel.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 498b6d9..a686ad6 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -212,11 +212,11 @@ static struct event_constraint 
intel_hsw_event_constraints[] = {
INTEL_UEVENT_CONSTRAINT(0x01c0, 0x2), /* INST_RETIRED.PREC_DIST */
INTEL_EVENT_CONSTRAINT(0xcd, 0x8), /* MEM_TRANS_RETIRED.LOAD_LATENCY */
/* CYCLE_ACTIVITY.CYCLES_L1D_PENDING */
-   INTEL_EVENT_CONSTRAINT(0x08a3, 0x4),
+   INTEL_UEVENT_CONSTRAINT(0x08a3, 0x4),
/* CYCLE_ACTIVITY.STALLS_L1D_PENDING */
-   INTEL_EVENT_CONSTRAINT(0x0ca3, 0x4),
+   INTEL_UEVENT_CONSTRAINT(0x0ca3, 0x4),
/* CYCLE_ACTIVITY.CYCLES_NO_EXECUTE */
-   INTEL_EVENT_CONSTRAINT(0x04a3, 0xf),
+   INTEL_UEVENT_CONSTRAINT(0x04a3, 0xf),
EVENT_CONSTRAINT_END
 };
 
-- 
1.9.3

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

Re: [PATCH] ASoC: arizona: match wait_for_completion_timeout return type

[Mark Brown]

On Sun, Mar 08, 2015 at 09:16:49AM -0400, Nicholas Mc Guire wrote:
> return type of wait_for_completion_timeout is unsigned long not int. An
> appropriately named unsigned long is added and the assignment fixed up.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH 1/2] ASoC: wm8996: match wait_for_completion_timeout return type

[Mark Brown]

On Sun, Mar 08, 2015 at 06:02:15AM -0400, Nicholas Mc Guire wrote:
> return type of wait_for_completion_timeout is unsigned long not int. An
> appropriately named unsigned long is added and the assignment fixed up
> in case of completion occurring the remaining time is >=1 so ret is set to
> 1 if no timeout occurred.

Applied both, thanks.


signature.asc
Description: Digital signature

Re: [PATCH] ASoC: wm2200: match wait_for_completion_timeout return type

[Mark Brown]

On Sun, Mar 08, 2015 at 07:06:05AM -0400, Nicholas Mc Guire wrote:
> return type of wait_for_completion_timeout is unsigned long not int. An
> appropriately named unsigned long is added and the assignment fixed up.

applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)

[Linus Torvalds]

On Mon, Mar 9, 2015 at 11:04 AM, Andy Lutomirski  wrote:
>
> One option would be to change the NMI entry code to move itself down 8
> bytes if this happens (came from kernel mode or sp == sp0 - 12,
> perhaps).

Hmm. That whole code currently depends on the stack setup being just a
single instruction (the move to esp). And that simplifies things, I'd
like to keep it that way.

I'd *much* rather just keep the 8-byte padding. What was so
problematic with that? It worked. It's been around forever. Removing
it is the bug.

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

Re: [PATCH v2] regmap: introduce regmap_name to fix syscon regmap trace events

[Mark Brown]

On Mon, Mar 09, 2015 at 12:20:13PM +0100, Philipp Zabel wrote:
> This patch fixes a NULL pointer dereference when enabling regmap event
> tracing in the presence of a syscon regmap, introduced by commit bdb0066df96e
> ("mfd: syscon: Decouple syscon interface from platform devices").
> That patch introduced syscon regmaps that have their dev field set to NULL.
> The regmap trace events expect it to point to a valid struct device and feed
> it to dev_name():

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH] ASoC: wm5100: match wait_for_completion_timeout return type

[Mark Brown]

On Sun, Mar 08, 2015 at 06:57:07AM -0400, Nicholas Mc Guire wrote:
> return type of wait_for_completion_timeout is unsigned long not int. An
> appropriately named unsigned long is added and the assignment fixed up.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH] fs/pstore/ram.c: Fix the ramoops module parameters update

[Mark Salyzyn]

On 03/09/2015 04:17 AM, long.wanglong wrote:

In the function ramoops_probe, the console_size, pmsg_size,
ftrace_size may be update because the value is not the power
of two. We should update the module parameter variables
as well so they are visible through /sys/module/ramoops/parameters
correctly.

Signed-off-by: Wang Long 
---
  fs/pstore/ram.c | 3 +++
  1 file changed, 3 insertions(+)

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

[PATCH] ASoC: cx20442: remove incorerct __exit markups

[Dmitry Torokhov]

Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Signed-off-by: Dmitry Torokhov 
---
 sound/soc/codecs/cx20442.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/cx20442.c b/sound/soc/codecs/cx20442.c
index 0b10979..0f334bc 100644
--- a/sound/soc/codecs/cx20442.c
+++ b/sound/soc/codecs/cx20442.c
@@ -420,7 +420,7 @@ static int cx20442_platform_probe(struct platform_device 
*pdev)
&cx20442_codec_dev, &cx20442_dai, 1);
 }
 
-static int __exit cx20442_platform_remove(struct platform_device *pdev)
+static int cx20442_platform_remove(struct platform_device *pdev)
 {
snd_soc_unregister_codec(&pdev->dev);
return 0;
@@ -431,7 +431,7 @@ static struct platform_driver cx20442_platform_driver = {
.name = "cx20442-codec",
},
.probe = cx20442_platform_probe,
-   .remove = __exit_p(cx20442_platform_remove),
+   .remove = cx20442_platform_remove,
 };
 
 module_platform_driver(cx20442_platform_driver);
-- 
2.2.0.rc0.207.ga3a616c


-- 
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: [PCI] BUG: unable to handle kernel

[Guenter Roeck]

On 03/09/2015 11:09 AM, Murali Karicheri wrote:

On 03/09/2015 01:34 PM, Guenter Roeck wrote:

On 03/09/2015 10:03 AM, Murali Karicheri wrote:

On 03/09/2015 12:07 PM, Guenter Roeck wrote:

On 03/09/2015 08:53 AM, Murali Karicheri wrote:

On 03/09/2015 10:44 AM, Bjorn Helgaas wrote:

On Mon, Mar 9, 2015 at 9:17 AM, Murali Karicheri
wrote:

On 03/06/2015 12:58 PM, Murali Karicheri wrote:


On 03/06/2015 11:55 AM, Guenter Roeck wrote:


On Fri, Mar 06, 2015 at 10:48:59AM -0500, Murali Karicheri wrote:
[ ... ]


From 098b4f5e4ab9407fbdbfcca3a91785c17e25cf03 Mon Sep 17
00:00:00 2001

From: Murali Karicheri
Date: Fri, 6 Mar 2015 10:23:08 -0500
Subject: [PATCH] pci: of : fix kernel crash

This is a debug patch to root cause the kernel crash

commit 0b2af171520e5d5e7d5b5f479b90a6a5014d9df6

PCI: Update DMA configuration from DT

Signed-off-by: Murali Karicheri
---
drivers/of/of_pci.c | 8 
drivers/pci/host-bridge.c | 5 +
2 files changed, 13 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 86d3c38..5a59fb8 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -129,6 +129,14 @@ void of_pci_dma_configure(struct pci_dev
*pci_dev)
struct device *dev =&pci_dev->dev;
struct device *bridge = pci_get_host_bridge_device(pci_dev);

+ if (!bridge || !bridge->parent) {
+ if (!bridge)
+ pr_err("PCI bridge not found\n");
+ if (!bridge->parent)
+ pr_err("PCI bridge parent not found\n");



You'll see a crash here if bridge is NULL. Maybe add an else before
the second
if statement ? Also, dev_err might be a bit more useful and
would be
available.


Fixed and attached.

Murali


Thanks,
Guenter


+ return;
+ }
+
of_dma_configure(dev, bridge->parent->of_node);
pci_put_host_bridge_device(bridge);
}
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 3e5bbf9..ef2ab51 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -28,6 +28,11 @@ struct device
*pci_get_host_bridge_device(struct
pci_dev *dev)
struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
struct device *bridge = root_bus->bridge;

+ if (!bridge) {
+ pr_err("PCI: bridge not found\n");
+ return NULL;
+ }
+
kobject_get(&bridge->kobj);
return bridge;
}
--
1.7.9.5






BJorn,

Any chance of applying the attached debug patch to see if this fixes
and
provide some additional information on this BUG? Not sure who will
pick this
one and apply.


The change that caused the oops (0b2af171520e ("PCI: Update DMA
configuration from DT")) only exists on my pci/iommu branch, so I'm
the one to apply it.

It's much easier for me to deal with plain text patches (not
attachments).

I'm hesitating because I don't want to encourage use of the 0-day
testing robot as a tool at which we can just throw debug patches. The
robot is a service that costs somebody real money, and I want to be a
good neighbor when using it.


Thanks for the clarification as I don't have much information on the
testing robot. At the same time the question is how similar incidence
in the past have been handled. I am a newbie w.r.t to this. This is
first time I have introduced a patch that impacts multiple
arch/machines.



Was the information in the robot's report enough to reproduce the
oops? If not, is there additional information we could add to the
report that would enable you to reproduce it? Even if we can't
reproduce the oops, the report seems detailed enough that we should be
able to deduce the problem and produce a fix in which we have high
confidence.


The BUG report essentially indicates the crash happened in
of_pci_dma_configure(). The machine specific log make sense to a
person familiar with this arch and I am not familiar with the same. So
anyone can help narrow down the root cause of this?

Looking at the code, there are two ptr variables that are accessed
without checking for NULL as initial thinking was that these can never
be NULL. So the debug patch is just adding addition check before
accessing the ptr. I can send this patch without debug prints if that
make sense. I was thinking to get confirmation that this is indeed the
case before adding the check. What do you think the right approach
here? Send a patch for this to the ML for adding the check as a
potential fix? Or someone can help me investigate the crash dump and
root cause it? or if we can use test robot to confirm this, I can
re-send the patch ASIS to the list. Please clarify.


If the assumption is that the pointers can never be NULL,
wouldn't it be important to see a call trace and to find out
if the NULL pointers can actually be seen by design,
or if there is some other bug ?


Call trace shows

[ 0.57] [<7976c1ac>] pci_device_add+0xbc/0x820
[ 0.57] [<7976c1ac>] pci_device_add+0xbc/0x820


And BUG seems to be in of_pci_dma_configure() as shown in the BUG report.

of_pci_dma_configure() calls newly added API call to
pci_get_host_bridge_device(). Seems like this has succeeded which
means bridge is non NULL IMO. However in this function it passes

Re: [PATCH] x86/fpu: drop_fpu() should not assume that tsk == current

[Borislav Petkov]

On Mon, Mar 09, 2015 at 07:06:47PM +0100, Oleg Nesterov wrote:
> Yes... should I resend?

Nah, already fixed up and uploaded to

http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=tip-x86-fpu-urgent

I'm going to collect the fpu urgent-only stuff there so that we don't
lose track of the patches flying back and forth.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mtd: maps: sa1100-flash: remove incorrect __exit markups

[Dmitry Torokhov]

Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Signed-off-by: Dmitry Torokhov 
---
 drivers/mtd/maps/sa1100-flash.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/maps/sa1100-flash.c b/drivers/mtd/maps/sa1100-flash.c
index ea69720..892ad6a 100644
--- a/drivers/mtd/maps/sa1100-flash.c
+++ b/drivers/mtd/maps/sa1100-flash.c
@@ -274,7 +274,7 @@ static int sa1100_mtd_probe(struct platform_device *pdev)
return err;
 }
 
-static int __exit sa1100_mtd_remove(struct platform_device *pdev)
+static int sa1100_mtd_remove(struct platform_device *pdev)
 {
struct sa_info *info = platform_get_drvdata(pdev);
struct flash_platform_data *plat = dev_get_platdata(&pdev->dev);
@@ -286,7 +286,7 @@ static int __exit sa1100_mtd_remove(struct platform_device 
*pdev)
 
 static struct platform_driver sa1100_mtd_driver = {
.probe  = sa1100_mtd_probe,
-   .remove = __exit_p(sa1100_mtd_remove),
+   .remove = sa1100_mtd_remove,
.driver = {
.name   = "sa1100-mtd",
},
-- 
2.2.0.rc0.207.ga3a616c


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