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

[Stephen Rothwell]

Hi Linus,

Today's linux-next merge of the gpio tree got a conflict in
drivers/gpio/gpiolib.c between commit 324b0398781e ("gpio: Fix
potential NULL handler data in chained irqchip handler") from Linus
Torvalds' tree and commit 3f97d5fcf99c ("gpio: handle also nested
irqchips in the chained handler set-up") from the gpio tree.

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

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

diff --cc drivers/gpio/gpiolib.c
index c68d037de656,6e00c82be142..
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@@ -413,12 -407,25 +407,25 @@@ void gpiochip_set_chained_irqchip(struc
return;
}
  
-   /*
-* The parent irqchip is already using the chip_data for this
-* irqchip, so our callbacks simply use the handler_data.
-*/
-   irq_set_handler_data(parent_irq, gpiochip);
-   irq_set_chained_handler(parent_irq, parent_handler);
+   if (parent_handler) {
+   if (gpiochip->can_sleep) {
+   chip_err(gpiochip,
+"you cannot have chained interrupts on a "
+"chip that may sleep\n");
+   return;
+   }
 -  irq_set_chained_handler(parent_irq, parent_handler);
+   /*
+* The parent irqchip is already using the chip_data for this
+* irqchip, so our callbacks simply use the handler_data.
+*/
+   irq_set_handler_data(parent_irq, gpiochip);
++  irq_set_chained_handler(parent_irq, parent_handler);
+   }
+ 
+   /* Set the parent IRQ for all affected IRQs */
+   for (offset = 0; offset < gpiochip->ngpio; offset++)
+   irq_set_parent(irq_find_mapping(gpiochip->irqdomain, offset),
+  parent_irq);
  }
  EXPORT_SYMBOL_GPL(gpiochip_set_chained_irqchip);
  


signature.asc
Description: PGP signature

[PATCH] serial: remove use of gpiochip_remove() retval

[Pramod Gurav]

Get rid of using return value from gpiochip_remove() as it returns
void with a new change in kernel.

Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Signed-off-by: Pramod Gurav 
---
 drivers/tty/serial/max310x.c   |   10 --
 drivers/tty/serial/sc16is7xx.c |   13 +
 2 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 82573dc..0041a64 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -1248,7 +1248,7 @@ static int max310x_probe(struct device *dev, struct 
max310x_devtype *devtype,
mutex_destroy(>mutex);
 
 #ifdef CONFIG_GPIOLIB
-   WARN_ON(gpiochip_remove(>gpio));
+   gpiochip_remove(>gpio);
 
 out_uart:
 #endif
@@ -1263,12 +1263,10 @@ out_clk:
 static int max310x_remove(struct device *dev)
 {
struct max310x_port *s = dev_get_drvdata(dev);
-   int i, ret = 0;
+   int i;
 
 #ifdef CONFIG_GPIOLIB
-   ret = gpiochip_remove(>gpio);
-   if (ret)
-   return ret;
+   gpiochip_remove(>gpio);
 #endif
 
for (i = 0; i < s->uart.nr; i++) {
@@ -1282,7 +1280,7 @@ static int max310x_remove(struct device *dev)
uart_unregister_driver(>uart);
clk_disable_unprepare(s->clk);
 
-   return ret;
+   return 0;
 }
 
 static const struct of_device_id __maybe_unused max310x_dt_ids[] = {
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 3284c31..6246820 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1157,7 +1157,7 @@ static int sc16is7xx_probe(struct device *dev,
 
 #ifdef CONFIG_GPIOLIB
if (devtype->nr_gpio)
-   WARN_ON(gpiochip_remove(>gpio));
+   gpiochip_remove(>gpio);
 
 out_uart:
 #endif
@@ -1173,14 +1173,11 @@ out_clk:
 static int sc16is7xx_remove(struct device *dev)
 {
struct sc16is7xx_port *s = dev_get_drvdata(dev);
-   int i, ret = 0;
+   int i;
 
 #ifdef CONFIG_GPIOLIB
-   if (s->devtype->nr_gpio) {
-   ret = gpiochip_remove(>gpio);
-   if (ret)
-   return ret;
-   }
+   if (s->devtype->nr_gpio)
+   gpiochip_remove(>gpio);
 #endif
 
for (i = 0; i < s->uart.nr; i++) {
@@ -1195,7 +1192,7 @@ static int sc16is7xx_remove(struct device *dev)
if (!IS_ERR(s->clk))
clk_disable_unprepare(s->clk);
 
-   return ret;
+   return 0;
 }
 
 static const struct of_device_id __maybe_unused sc16is7xx_dt_ids[] = {
-- 
1.7.9.5

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

Re: [PATCH] drm/exynos: remove ifdeferry from initialization code

[Inki Dae]

On 2014년 09월 30일 20:29, Andrzej Hajda wrote:
> Hi Inki,
> 
> Gently ping.

Hi Andrzej,

I merged it to local repository to test. But now exynos drm doesn't work
correctly since pulling drm-next of Dave regardless of your patch.

Problems are,
1. error occurs when we try to test modetest with -v option from second
times.
2. error occurs when we try to test unbind.

Now we are checking these problems. Can you try to also check it?

Thanks,
Inki Dae

> 
> Andrzej
> 
> On 09/10/2014 01:53 PM, Andrzej Hajda wrote:
>> The patch replaces separate calls to driver (de)registration by
>> loops over the array of drivers. As a result it significantly
>> decreases number of ifdefs. Additionally it moves device registration
>> related ifdefs to header file.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> Hi Inki,
>>
>> During testing your component match support patch [1] I have prepared patch
>> removing most ifdefs from exynos_drm_drv.c. It is based on your patch, but
>> I can rebase it if necessary.
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37031
>>
>> Regards
>> Andrzej
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 170 
>> +++-
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h |  25 +++--
>>  2 files changed, 48 insertions(+), 147 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index b2c710a..a660e46 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -553,74 +553,54 @@ static const struct component_master_ops 
>> exynos_drm_ops = {
>>  .unbind = exynos_drm_unbind,
>>  };
>>  
>> -static int exynos_drm_platform_probe(struct platform_device *pdev)
>> -{
>> -struct component_match *match;
>> -int ret;
>> -
>> -pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> -exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>> -
>> +static struct platform_driver * const exynos_drm_drivers[] = {
>>  #ifdef CONFIG_DRM_EXYNOS_FIMD
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -return ret;
>> +_driver,
>>  #endif
>> -
>>  #ifdef CONFIG_DRM_EXYNOS_DP
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_fimd_drv;
>> +_driver,
>>  #endif
>> -
>>  #ifdef CONFIG_DRM_EXYNOS_DSI
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_dp_drv;
>> +_driver,
>>  #endif
>> -
>>  #ifdef CONFIG_DRM_EXYNOS_HDMI
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_dsi_drv;
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_mixer_drv;
>> +_driver,
>> +_driver,
>>  #endif
>> -
>>  #ifdef CONFIG_DRM_EXYNOS_G2D
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_hdmi_drv;
>> +_driver,
>>  #endif
>> -
>>  #ifdef CONFIG_DRM_EXYNOS_FIMC
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_g2d_drv;
>> +_driver,
>>  #endif
>> -
>>  #ifdef CONFIG_DRM_EXYNOS_ROTATOR
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_fimc_drv;
>> +_driver,
>>  #endif
>> -
>>  #ifdef CONFIG_DRM_EXYNOS_GSC
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_rotator_drv;
>> +_driver,
>>  #endif
>> -
>>  #ifdef CONFIG_DRM_EXYNOS_IPP
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_gsc_drv;
>> +_driver,
>> +#endif
>> +};
>> +
>> +static int exynos_drm_platform_probe(struct platform_device *pdev)
>> +{
>> +struct component_match *match;
>> +int ret, i;
>> +
>> +pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> +exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>> +
>> +for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
>> +ret = platform_driver_register(exynos_drm_drivers[i]);
>> +if (ret < 0)
>> +goto err_unregister_drivers;
>> +}
>>  
>>  ret = exynos_platform_device_ipp_register();
>>  if (ret < 0)
>> -goto err_unregister_ipp_drv;
>> -#endif
>> +goto err_unregister_drivers;
>>  
>>  match = exynos_drm_match_add(>dev);
>>  if (IS_ERR(match)) {
>> @@ -632,96 +612,24 @@ static int exynos_drm_platform_probe(struct 
>> platform_device *pdev)
>>  match);
>>  
>>  err_unregister_ipp_dev:
>> -
>> -#ifdef CONFIG_DRM_EXYNOS_IPP
>>  exynos_platform_device_ipp_unregister();
>> -err_unregister_ipp_drv:
>> -platform_driver_unregister(_driver);
>> -err_unregister_gsc_drv:
>> -#endif
>>  
>> -#ifdef CONFIG_DRM_EXYNOS_GSC
>> -

[PATCH] ASoC: remove use of gpiochip_remove() retval

[Pramod Gurav]

Get rid of using return value from gpiochip_remove() as it returns
void with a new change in kernel.

Cc: Linus Walleij 
Cc: Alexandre Courbot 
CC: Liam Girdwood 
CC: Mark Brown 
Cc: Jaroslav Kysela  
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linux-g...@vger.kernel.org
Signed-off-by: Pramod Gurav 
---
 sound/soc/codecs/wm5100.c |5 +
 sound/soc/codecs/wm8903.c |6 +-
 sound/soc/codecs/wm8962.c |5 +
 sound/soc/codecs/wm8996.c |6 +-
 4 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c
index 7bb0d36..a01ad62 100644
--- a/sound/soc/codecs/wm5100.c
+++ b/sound/soc/codecs/wm5100.c
@@ -2319,11 +2319,8 @@ static void wm5100_init_gpio(struct i2c_client *i2c)
 static void wm5100_free_gpio(struct i2c_client *i2c)
 {
struct wm5100_priv *wm5100 = i2c_get_clientdata(i2c);
-   int ret;
 
-   ret = gpiochip_remove(>gpio_chip);
-   if (ret != 0)
-   dev_err(>dev, "Failed to remove GPIOs: %d\n", ret);
+   gpiochip_remove(>gpio_chip);
 }
 #else
 static void wm5100_init_gpio(struct i2c_client *i2c)
diff --git a/sound/soc/codecs/wm8903.c b/sound/soc/codecs/wm8903.c
index aa09848..c038b3e 100644
--- a/sound/soc/codecs/wm8903.c
+++ b/sound/soc/codecs/wm8903.c
@@ -1877,11 +1877,7 @@ static void wm8903_init_gpio(struct wm8903_priv *wm8903)
 
 static void wm8903_free_gpio(struct wm8903_priv *wm8903)
 {
-   int ret;
-
-   ret = gpiochip_remove(>gpio_chip);
-   if (ret != 0)
-   dev_err(wm8903->dev, "Failed to remove GPIOs: %d\n", ret);
+   gpiochip_remove(>gpio_chip);
 }
 #else
 static void wm8903_init_gpio(struct wm8903_priv *wm8903)
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index 1098ae3..9077411 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -3398,11 +3398,8 @@ static void wm8962_init_gpio(struct snd_soc_codec *codec)
 static void wm8962_free_gpio(struct snd_soc_codec *codec)
 {
struct wm8962_priv *wm8962 = snd_soc_codec_get_drvdata(codec);
-   int ret;
 
-   ret = gpiochip_remove(>gpio_chip);
-   if (ret != 0)
-   dev_err(codec->dev, "Failed to remove GPIOs: %d\n", ret);
+   gpiochip_remove(>gpio_chip);
 }
 #else
 static void wm8962_init_gpio(struct snd_soc_codec *codec)
diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index f16ff4f..b1dcc11 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -2216,11 +2216,7 @@ static void wm8996_init_gpio(struct wm8996_priv *wm8996)
 
 static void wm8996_free_gpio(struct wm8996_priv *wm8996)
 {
-   int ret;
-
-   ret = gpiochip_remove(>gpio_chip);
-   if (ret != 0)
-   dev_err(wm8996->dev, "Failed to remove GPIOs: %d\n", ret);
+   gpiochip_remove(>gpio_chip);
 }
 #else
 static void wm8996_init_gpio(struct wm8996_priv *wm8996)
-- 
1.7.9.5

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

Re: [PATCH 1/1 net-next] ieee802154: fix __init functions

[Marcel Holtmann]

Hi Fabian,

> Commit 3243acd37fd9
> ("ieee802154: add __init to lowpan_frags_sysctl_register")
> 
> added __init to lowpan_frags_ns_sysctl_register instead of
> lowpan_frags_sysctl_register
> 
> Suggested-by: Alexander Aring 
> Signed-off-by: Fabian Frederick 
> ---
> net/ieee802154/reassembly.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)

when trying to apply this to bluetooth-next kernel, I am getting this:

Applying: ieee802154: fix __init functions
error: patch failed: net/ieee802154/reassembly.c:498
error: net/ieee802154/reassembly.c: patch does not apply
Patch failed at 0001 ieee802154: fix __init functions

Regards

Marcel

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

Re: uid=0 inside user-namespace and procfs file permissions

[Aditya Kali]

On Tue, Sep 30, 2014 at 7:38 PM, Eric W. Biederman
 wrote:
> Aditya Kali  writes:
>
>> On Tue, Sep 30, 2014 at 5:35 PM, Eric W. Biederman
>>  wrote:
>>> Aditya Kali  writes:
>>>
 Hi all,

 I am trying to run a process with uid=0 inside userns. But in the when
 I also do capset() after setresuid(0, 0, 0), I am seeing inconsistent
 proc file permissions. Almost all the files in /proc// has global
 'root' as owner and group even if the actual process uid is correctly
 changed.

 I wrote a simple program that demonstrate the issue:

 1. parent, as global root (uid=0 in init_user_ns) fork()s a child
 2. child:
 a) unshare(CLONE_NEWUSER)
 b) [wait for parent to write uid_map]
 c) setresgid(id, id, id) ; setresuid(0, 0, 0);
 d) conditionally call capset() to clear capabilities
 e) execve(/bin/sleep)
 3. parent:
 a) populates child's uid_map and maps some uid to 0 inside userns. ex:
 0 99 1
 b) waitpid()

 (the actual program can be found at http://pastebin.com/f4P17VFn for
 your reference).

 When there is no capset() call after setresuid(0,0,0), everything is
 fine. But when I do a capset() to clear all capabilities, the 'owner'
 and 'group' of all the files under /proc//  of the child
 process are reverted to global 'root' user.

 # without capset (2.d):
 root@vm1# id
 uid=0(root) gid=0(root) groups=0(root)

 root@vm1# ./userns_uid0
 child_pid: 24277
 proc_file: /proc/24277/uid_map
 proc_file: /proc/24277/gid_map
 child resuming

 ^Z
 [1]+  Stopped ./userns_uid0
 root@vm1# cat /proc/24277/uid_map
  0 99  1
 root@vm1# cat /proc/24277/status | grep -e "Uid:" -e "Gid:"
 Uid: 99 99 99 99
 Gid: 99 99 99 99
 root@vm1# ls -l /proc/24277/
 total 0
 dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:31 attr
 -r 1 nobody nobody 0 2014-09-30 16:31 auxv
 -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cgroup
 --w--- 1 nobody nobody 0 2014-09-30 16:31 clear_refs
 -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cmdline
 -rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 comm
 -rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 coredump_filter
 -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cpuset
 ...
 [All files have owner='nobody' and group='nobody' .. same as that of
 the process]

 With the additional capset() call, the files under /proc//
 are now owned by global root:

 root@vm1# ./userns_uid0 resetcaps
 child_pid: 24706
 proc_file: /proc/24706/uid_map
 proc_file: /proc/24706/gid_map
 child resuming
 resetting caps
 ^Z
 [2]+  Stopped ./userns_uid0 resetcaps
 root@vm1# cat /proc/24706/uid_map
  0 99  1
 root@vm1# cat /proc/24706/status | grep -e "Uid:" -e "Gid:"
 Uid: 99 99 99 99
 Gid: 99 99 99 99

 [Everything as before till now]

 root@vm1# ls -l /proc/24706/
 total 0
 dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:47 attr
 -r 1 root   root   0 2014-09-30 16:47 auxv
 -r--r--r-- 1 root   root   0 2014-09-30 16:47 cgroup
 --w--- 1 root   root   0 2014-09-30 16:47 clear_refs
 -r--r--r-- 1 root   root   0 2014-09-30 16:47 cmdline
 -rw-r--r-- 1 root   root   0 2014-09-30 16:47 comm
 -rw-r--r-- 1 root   root   0 2014-09-30 16:47 coredump_filter
 -r--r--r-- 1 root   root   0 2014-09-30 16:47 cpuset
 ...
 -r--r--r-- 1 root   root   0 2014-09-30 16:47 mountinfo
 -r--r--r-- 1 root   root   0 2014-09-30 16:47 mounts
 -r 1 root   root   0 2014-09-30 16:47 mountstats
 dr-xr-xr-x 5 nobody nobody 0 2014-09-30 16:47 net
 dr-x--x--x 2 root   root   0 2014-09-30 16:47 ns
 -r--r--r-- 1 root   root   0 2014-09-30 16:47 numa_maps
 ...
 -r--r--r-- 1 root   root   0 2014-09-30 16:47 status
 -r 1 root   root   0 2014-09-30 16:47 syscall
 dr-xr-xr-x 3 nobody nobody 0 2014-09-30 16:47 task
 ..

 Only the directories 'attr', 'net' and 'task' are owned by the uid=99.
 Rest all files are owned by global root.

 This behavior seems inconsistent. I ran this on 3.17 kernel. Can
 someone with expertise in this area explain if this is expected?
>>>
>>> So I am not quite certain what you are seeing.
>>>
>>> In general proc files are expected to be owned by the euid of a process.
>>> However when the task_dumpable is cleared the files become owned by the
>>> global root user.  We have considered relaxing that to the namespace
>>> root user but so far implementing a more granular task_dumpable has not
>>> been done.
>>>
>>
>> I tried explicitly setting PR_SET_DUMPABLE before execve(), but that
>> didn't either.
>>
>>> The directories are world readable so they don't matter.
>>>
>>> What puzzles me is that 

Re: [RFC PATCH] Perf Bench: Locking Microbenchmark

[Ingo Molnar]

* Tuan Bui  wrote:

> Subject: [RFC PATCH] Perf Bench: Locking Microbenchmark
> 
> In response to this thread https://lkml.org/lkml/2014/2/11/93, 
> this is a micro benchmark that stresses locking contention in 
> the kernel with creat(2) system call by spawning multiple 
> processes to spam this system call.  This workload generate 
> similar results and contentions in AIM7 fserver workload but 
> can generate outputs within seconds.
> 
> With the creat(2) system call the contention vary on what locks 
> are used in the particular file system. I have ran this 
> benchmark only on ext4 and xfs file system.
> 
> Running the creat workload on ext4 show contention in the mutex 
> lock that is used by ext4_orphan_add() and ext4_orphan_del() to 
> add or delete an inode from the list of inodes. At the same 
> time running the creat workload on xfs show contention in the 
> spinlock that is used by xsf_log_commit_cil() to commit a 
> transaction to the Committed Item List.
> 
> Here is a comparison of this benchmark with AIM7 running 
> fserver workload at 500-1000 users along with a perf trace 
> running on ext4 file system.
> 
> Test machine is a 8-sockets 80 cores Westmere system HT-off on 
> v3.17-rc6.
> 
>   AIM7AIM7perf-bench  perf-bench
> Users Jobs/minJobs/min/child  Ops/sec Ops/sec/child
> 500   119668.25   239.34  104249  208
> 600   126074.90   210.12  106136  176
> 700   128662.42   183.80  106175  151
> 800   119822.05   149.78  106290  132
> 900   106150.25   117.94  105230  116
> 1000  104681.29   104.68  106489  106
> 
> Perf trace for AIM7 fserver:
> 14.51%reaim   [kernel.kallsyms]   [k] osq_lock
> 4.98% reaim   reaim   [.] add_long
> 4.98% reaim   reaim   [.] add_int
> 4.31% reaim   [kernel.kallsyms]   [k] mutex_spin_on_owner
> ...
> 
> Perf trace of perf bench creat
> 22.37%locking-creat  [kernel.kallsyms][k] osq_lock
> 5.77% locking-creat  [kernel.kallsyms][k] mutex_spin_on_owner
> 5.31% locking-creat  [kernel.kallsyms][k] _raw_spin_lock
> 5.15% locking-creat  [jbd2]   [k] 
> jbd2_journal_put_journal_head
> ...

Very nice!

If you compare an strace of AIM7 steady state and 'perf bench 
lock' steady state, is it comparable, i.e. do the syscalls and 
other behavioral patterns match up?

> +'locking'::
> +Locking stressing benchmarks.
> +
>  'all'::
>   All benchmark subsystems.
>  
> @@ -213,6 +216,11 @@ Suite for evaluating wake calls.
>  *requeue*::
>  Suite for evaluating requeue calls.
>  
> +SUITES FOR 'locking'
> +~~
> +*creat*::
> +Suite for evaluating locking contention through creat(2).

So I'd display it in the help text prominently that it's a 
workload similar to the AIM7 workload.

> +static const struct option options[] = {
> + OPT_UINTEGER('s', "start", _nr_threads, "Numbers of processes to 
> start"),
> + OPT_UINTEGER('e', "end", _nr_threads, "Numbers of process to end"),
> + OPT_UINTEGER('i', "increment", _threads_by, "Number of 
> threads to increment)"),
> + OPT_UINTEGER('r', "runtime", _dur, "Specify benchmark runtime in 
> seconds"),
> + OPT_END()
> +};

Is this the kind of parameters that AIM7 takes as well?

In any case, this is a very nice benchmarking utility.

Thanks,

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

[PATCH 1/1 net-next] ieee802154: fix __init functions

[Fabian Frederick]

Commit 3243acd37fd9
("ieee802154: add __init to lowpan_frags_sysctl_register")

added __init to lowpan_frags_ns_sysctl_register instead of
lowpan_frags_sysctl_register

Suggested-by: Alexander Aring 
Signed-off-by: Fabian Frederick 
---
 net/ieee802154/reassembly.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ieee802154/reassembly.c b/net/ieee802154/reassembly.c
index 30ec608..7cfcd68 100644
--- a/net/ieee802154/reassembly.c
+++ b/net/ieee802154/reassembly.c
@@ -498,7 +498,7 @@ static void lowpan_frags_sysctl_unregister(void)
unregister_net_sysctl_table(lowpan_ctl_header);
 }
 #else
-static inline int __init lowpan_frags_ns_sysctl_register(struct net *net)
+static inline int lowpan_frags_ns_sysctl_register(struct net *net)
 {
return 0;
 }
@@ -507,7 +507,7 @@ static inline void lowpan_frags_ns_sysctl_unregister(struct 
net *net)
 {
 }
 
-static inline int lowpan_frags_sysctl_register(void)
+static inline int __init lowpan_frags_sysctl_register(void)
 {
return 0;
 }
-- 
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/

[PATCH net 2/2] r8152: disable power cut for RTL8153

[Hayes Wang]

The firmware would be clear when the power cut is enabled for
RTL8153.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 18b9e0d..604ef21 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3397,7 +3397,7 @@ static void rtl8153_unload(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, >flags))
return;
 
-   r8153_power_cut_en(tp, true);
+   r8153_power_cut_en(tp, false);
 }
 
 static int rtl_ops_init(struct r8152 *tp, const struct usb_device_id *id)
-- 
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/

[PATCH net 1/2] r8152: remove clearing bp

[Hayes Wang]

The xxx_clear_bp() is used to halt the firmware. It only necessary
for updating the new firmware. Besides, depend on the version of
the current firmware, it may have problem to halt the firmware
directly. Finally, halt the firmware would let the firmware code
useless, and the bugs which are fixed by the firmware would occur.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 28 +---
 1 file changed, 1 insertion(+), 27 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f68a4e6..18b9e0d 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,7 +24,7 @@
 #include 
 
 /* Version Information */
-#define DRIVER_VERSION "v1.06.0 (2014/03/03)"
+#define DRIVER_VERSION "v1.06.1 (2014/10/01)"
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
 #define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters"
 #define MODULENAME "r8152"
@@ -2201,28 +2201,6 @@ static void rtl_phy_reset(struct r8152 *tp)
}
 }
 
-static void rtl_clear_bp(struct r8152 *tp)
-{
-   ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_0, 0);
-   ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_2, 0);
-   ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_4, 0);
-   ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_6, 0);
-   ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_0, 0);
-   ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_2, 0);
-   ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_4, 0);
-   ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_6, 0);
-   mdelay(3);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_BP_BA, 0);
-   ocp_write_word(tp, MCU_TYPE_USB, USB_BP_BA, 0);
-}
-
-static void r8153_clear_bp(struct r8152 *tp)
-{
-   ocp_write_byte(tp, MCU_TYPE_PLA, PLA_BP_EN, 0);
-   ocp_write_byte(tp, MCU_TYPE_USB, USB_BP_EN, 0);
-   rtl_clear_bp(tp);
-}
-
 static void r8153_teredo_off(struct r8152 *tp)
 {
u32 ocp_data;
@@ -2265,8 +2243,6 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
r8152_mdio_write(tp, MII_BMCR, data);
}
 
-   rtl_clear_bp(tp);
-
set_bit(PHY_RESET, >flags);
 }
 
@@ -2417,8 +2393,6 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8152_mdio_write(tp, MII_BMCR, data);
}
 
-   r8153_clear_bp(tp);
-
if (tp->version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
data &= ~CTAP_SHORT_EN;
-- 
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] x86, MCE, AMD: save IA32_MCi_STATUS before machine_check_poll() resets it

[Chen Yucong]

On Tue, 2014-09-30 at 12:09 +0200, Borislav Petkov wrote:
> 
> Now let me repeat my question: how are you testing your patches?
> 
There are no any hardware facilities that can help me to inject some
MCE errors. So I have to modify the kernel source code for testing my
patches.

My method is based on the `mce-injection' that is better suited to 
Intel processors. So I have replaced rdmsrl/wrmsrl/rdmsr_safe with
mce_rdmsrl/mce_wrmsrl/mce_rdmsr_safe in mce_amd.c. But I use a new
kernel module for error injection instead of writing /dev/mcelog.

For more detailed information about testing, you can refer the 
attachments.

thx!
cyc 
  
diff -uNr amd_inject/linux-3.16.3/arch/x86/include/asm/mce.h linux-3.16.3/arch/x86/include/asm/mce.h
--- amd_inject/linux-3.16.3/arch/x86/include/asm/mce.h	2014-09-18 01:22:16.0 +0800
+++ linux-3.16.3/arch/x86/include/asm/mce.h	2014-10-01 09:36:06.302670241 +0800
@@ -166,6 +166,7 @@
 #endif
 
 #ifdef CONFIG_X86_MCE_AMD
+void raise_amd_threshold_event(void);
 void mce_amd_feature_init(struct cpuinfo_x86 *c);
 #else
 static inline void mce_amd_feature_init(struct cpuinfo_x86 *c) { }
@@ -185,10 +186,14 @@
 	MCP_DONTLOG = (1 << 2),		/* only clear, don't log */
 };
 void machine_check_poll(enum mcp_flags flags, mce_banks_t *b);
+u64 mce_rdmsrl(u32 msr);
+void mce_wrmsrl(u32 msr, u64 v);
+int mce_rdmsr_safe(u32 msr, u32 *low, u32 *high);
 
 int mce_notify_irq(void);
 void mce_notify_process(void);
 
+extern int amd_inject;
 DECLARE_PER_CPU(struct mce, injectm);
 
 extern void register_mce_write_callback(ssize_t (*)(struct file *filp,
diff -uNr amd_inject/linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce_amd.c linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce_amd.c
--- amd_inject/linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce_amd.c	2014-09-18 01:22:16.0 +0800
+++ linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce_amd.c	2014-10-01 11:09:07.817585622 +0800
@@ -274,6 +274,7 @@
 	struct mce m;
 
 	mce_setup();
+	m.mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
 
 	/* assume first bank caused it */
 	for (bank = 0; bank < mca_cfg.banks; ++bank) {
@@ -291,7 +292,7 @@
 ++address;
 			}
 
-			if (rdmsr_safe(address, , ))
+			if (mce_rdmsr_safe(address, , ))
 break;
 
 			if (!(high & MASK_VALID_HI)) {
@@ -305,26 +306,35 @@
 			 (high & MASK_LOCKED_HI))
 continue;
 
-			/*
-			 * Log the machine check that caused the threshold
-			 * event.
-			 */
-			machine_check_poll(MCP_TIMESTAMP,
-	&__get_cpu_var(mce_poll_banks));
-
 			if (high & MASK_OVERFLOW_HI) {
-rdmsrl(address, m.misc);
-rdmsrl(MSR_IA32_MC0_STATUS + bank * 4,
-   m.status);
+m.misc = mce_rdmsrl(address);
+m.status = mce_rdmsrl(MSR_IA32_MC0_STATUS + bank * 4);
+if (m.status & MCI_STATUS_ADDRV)
+	m.addr = mce_rdmsrl(MSR_IA32_MC0_ADDR + bank * 4);
 m.bank = K8_MCE_THRESHOLD_BASE
    + bank * NR_BLOCKS
    + block;
 mce_log();
+mce_wrmsrl(MSR_IA32_MC0_STATUS + bank * 4, 0);
 return;
 			}
 		}
 	}
+
+	/*
+	 * Log the machine check that caused the threshold
+	 * event.
+	 */
+	machine_check_poll(MCP_TIMESTAMP,
+&__get_cpu_var(mce_poll_banks));
+
+}
+
+void raise_amd_threshold_event(void)
+{
+	amd_threshold_interrupt();
 }
+EXPORT_SYMBOL_GPL(raise_amd_threshold_event);
 
 /*
  * Sysfs Interface
diff -uNr amd_inject/linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce.c linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce.c
--- amd_inject/linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce.c	2014-09-18 01:22:16.0 +0800
+++ linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce.c	2014-10-01 09:40:13.269228358 +0800
@@ -48,6 +48,9 @@
 
 #include "mce-internal.h"
 
+int amd_inject = 0;
+EXPORT_PER_CPU_SYMBOL_GPL(amd_inject);
+
 static DEFINE_MUTEX(mce_chrdev_read_mutex);
 
 #define rcu_dereference_check_mce(p) \
@@ -131,6 +134,7 @@
 	m->apicid = cpu_data(m->extcpu).initial_apicid;
 	rdmsrl(MSR_IA32_MCG_CAP, m->mcgcap);
 }
+EXPORT_SYMBOL_GPL(mce_setup);
 
 DEFINE_PER_CPU(struct mce, injectm);
 EXPORT_PER_CPU_SYMBOL_GPL(injectm);
@@ -391,7 +395,7 @@
 }
 
 /* MSR access wrappers used for error injection */
-static u64 mce_rdmsrl(u32 msr)
+u64 mce_rdmsrl(u32 msr)
 {
 	u64 v;
 
@@ -415,8 +419,9 @@
 
 	return v;
 }
 
-static void mce_wrmsrl(u32 msr, u64 v)
+void mce_wrmsrl(u32 msr, u64 v)
 {
 	if (__this_cpu_read(injectm.finished)) {
 		int offset = msr_to_offset(msr);
@@ -427,6 +432,18 @@
 	}
 	wrmsrl(msr, v);
 }
+
+int mce_rdmsr_safe(u32 msr, u32 *low, u32 *high) 
+{
+u64 __val = mce_rdmsrl(msr);
+
+(*low) = (u32)__val;
+(*high) = (u32)(__val >> 32);
+
+	return 0;
+}
 
 /*
  * Collect all global (w.r.t. this processor) status about this machine
@@ -1637,6 +1654,7 @@
 		mce_adjust_timer = mce_intel_adjust_timer;
 		break;
 	case X86_VENDOR_AMD:
+		amd_inject = 1;
 		mce_amd_feature_init(c);
 		break;
 	default:
diff -uNr amd_inject/linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce-inject.c linux-3.16.3/arch/x86/kernel/cpu/mcheck/mce-inject.c
--- 

[PATCH net 0/2] r8152: patches about firmware

[Hayes Wang]

The patches fix the issues when the firmware exists.

For the multiple OS, the firmware may be loaded by the
driver of the other OS. And the Linux driver has influences
on it.

Hayes Wang (2):
  r8152: remove clearing bp
  r8152: disable power cut for RTL8153

 drivers/net/usb/r8152.c | 30 ++
 1 file changed, 2 insertions(+), 28 deletions(-)

-- 
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 v2 1/2] x86_64,entry: Filter RFLAGS.NT on entry from userspace

[Andy Lutomirski]

On Tue, Sep 30, 2014 at 10:09 PM, Sebastian Lackner
 wrote:
>> + testl $X86_EFLAGS_NT,EFLAGS(%rsp)   /* saved EFLAGS match cpu */
>> + jz 1f
>> + pushq_cfi $(X86_EFLAGS_IF|X86_EFLAGS_FIXED)
>> + popfq_cfi
>> +1:
>> +
>
> Do you think it makes sense to change the order here, so that no jump happens 
> if
> NT is not set (which happens a bit more often, than the other way round)? 
> Just a
> guess though, haven't measured if pipeline effects have such a big influence 
> in this
> case. ;)
>

It should be immeasurable in a tight loop, since it will predict
correctly almost every time.  And, unless cfi state works across
.pushsection (does it?), getting the cfi annotations right will be
more complicated.

--Andy

-- 
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 1/2] x86_64,entry: Filter RFLAGS.NT on entry from userspace

[Sebastian Lackner]

> + testl $X86_EFLAGS_NT,EFLAGS(%rsp)   /* saved EFLAGS match cpu */
> + jz 1f
> + pushq_cfi $(X86_EFLAGS_IF|X86_EFLAGS_FIXED)
> + popfq_cfi
> +1:
> +

Do you think it makes sense to change the order here, so that no jump happens if
NT is not set (which happens a bit more often, than the other way round)? Just a
guess though, haven't measured if pipeline effects have such a big influence in 
this
case. ;)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] init: Disable defaults if init= fails

[Andy Lutomirski]

On Tue, Sep 30, 2014 at 8:16 PM, Rob Landley  wrote:
> On 09/30/14 20:52, Frank Rowand wrote:
>> On 9/30/2014 5:58 PM, Rob Landley wrote:
>>> If you're going to argue that it should "default y", that's a defensible
>>> choice. But please don't argue for kernel config symbols with a negative
>>> meaning or we'll start having allyesconfig_n brain damage too...
>>
>> Yes, "default y" is a valid answer to my request.
>
> Works for me.
>
 Instead of using a config option, would adding another kernel
 command line option, such as 'init_fail_is_fatal', work for
 your needs?
>>>
>>> That was the previous series of patches you ignored, which added code so
>>> you can provide _extra_ kernel commands to tell it _not_ to do stuff.
>>> The patches did not generate noticeable enthusiasm.
>>
>> But there also was not a strong push back either.  Just Chuck's suggestion
>> of an alternate syntax, and your suggestion of instead using a config
>> option (and possibly immediately deprecating the config option).
>>
>> You could as easily frame the argument that the added code was to
>> tell the kernel to "_do_ stuff" (panic) instead of "_not_ do stuff".
>> But that is just semantics on my part; whatever.
>>
>> I thought the general trend was to try to avoid adding config options.
>> The strictinit method seems fine to me.
>
> Embedded guys care:
>
> http://elinux.org/Linux_Tiny
>
> http://lkml.iu.edu//hypermail/linux/kernel/1409.2/03763.html
>
 I have a feeling this has already been proposed,
 as the 'strictinit' option mentioned in the changes from v3
 below might be the same concept?
>>>
>>> That was it, yes.
>>>
>>> Having to get your kernel config right (and your kernel command line
>>> right) in order for your system to boot is not really a new concept, is
>>> it? You can still specify "init=/bin/sh" if you want that. (I do it all
>>> the time when I need to edit a system I haven't bothered to look up the
>>> root password to.)
>>
>> Yes, of course I can.  So it falls back to personal preference (as I said,
>> I like that some failed boots will drop into a shell without having to
>> change the kernel command line).
>
> The config option lets it do that. Default Y preserves the old behavior.

I significantly prefer default N.  Scripts that play with init= really
don't want the fallback, and I can imagine contexts in which it could
be a security problem.

--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 v2 2/2] x86_64: Don't save flags on context switch

[Andy Lutomirski]

Now that the kernel always runs with clean flags (in particular, NT
is clear), there is no need to save and restore flags on every
context switch.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/switch_to.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index d7f3b3b78ac3..751bf4b7bf11 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -79,12 +79,12 @@ do {
\
 #else /* CONFIG_X86_32 */
 
 /* frame pointer must be last for get_wchan */
-#define SAVE_CONTEXT"pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
-#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
+#define SAVE_CONTEXT"pushq %%rbp ; movq %%rsi,%%rbp\n\t"
+#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\t"
 
 #define __EXTRA_CLOBBER  \
, "rcx", "rbx", "rdx", "r8", "r9", "r10", "r11", \
- "r12", "r13", "r14", "r15"
+ "r12", "r13", "r14", "r15", "flags"
 
 #ifdef CONFIG_CC_STACKPROTECTOR
 #define __switch_canary
  \
@@ -100,7 +100,11 @@ do {   
\
 #define __switch_canary_iparam
 #endif /* CC_STACKPROTECTOR */
 
-/* Save restore flags to clear handle leaking NT */
+/*
+ * There is no need to save or restore flags, because flags are always
+ * clean in kernel mode, with the possible exception of IOPL.  Kernel IOPL
+ * has no effect.
+ */
 #define switch_to(prev, next, last) \
asm volatile(SAVE_CONTEXT \
 "movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP */   \
-- 
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/

[PATCH v2 1/2] x86_64,entry: Filter RFLAGS.NT on entry from userspace

[Andy Lutomirski]

The NT flag doesn't do anything in long mode other than causing IRET
to #GP.  Oddly, CPL3 code can still set NT using popf.

Entry via hardware or software interrupt clears NT automatically, so
the only relevant entries are fast syscalls.

If user code causes kernel code to run with NT set, then there's at
least some (small) chance that it could cause trouble.  For example,
user code could cause a call to EFI code with NT set, and who knows
what would happen?  Apparently some games on Wine sometimes do
this (!), and, if an IRET return happens, they will segfault.  That
segfault cannot be handled, because signal delivery fails, too.

This patch programs the CPU to clear NT on entry via SYSCALL (both
32-bit and 64-bit, by my reading of the AMD APM), and it clears NT
in software on entry via SYSENTER.

To save a few cycles, this borrows a trick from Jan Beulich in Xen:
it checks whether NT is set before trying to clear it.  As a result,
it seems to have very little effect on SYSENTER performance on my
machine.

Testers beware: on Xen, SYSENTER with NT set turns into a GPF.

I haven't touched anything on 32-bit kernels.

The syscall mask change comes from a variant of this patch by Anish
Bhatt.

Cc: sta...@vger.kernel.org
Reported-by: Anish Bhatt 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/ia32/ia32entry.S| 12 
 arch/x86/kernel/cpu/common.c |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 4299eb05023c..44d1dd371454 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -151,6 +151,18 @@ ENTRY(ia32_sysenter_target)
 1: movl(%rbp),%ebp
_ASM_EXTABLE(1b,ia32_badarg)
ASM_CLAC
+
+   /*
+* Sysenter doesn't filter flags, so we need to clear NT
+* ourselves.  To save a few cycles, we can check whether
+* NT was set instead of doing an unconditional popfq.
+*/
+   testl $X86_EFLAGS_NT,EFLAGS(%rsp)   /* saved EFLAGS match cpu */
+   jz 1f
+   pushq_cfi $(X86_EFLAGS_IF|X86_EFLAGS_FIXED)
+   popfq_cfi
+1:
+
orl $TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP-ARGOFFSET)
testl   
$_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
CFI_REMEMBER_STATE
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e4ab2b42bd6f..31265580c38a 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1184,7 +1184,7 @@ void syscall_init(void)
/* Flags to clear on syscall */
wrmsrl(MSR_SYSCALL_MASK,
   X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_IF|
-  X86_EFLAGS_IOPL|X86_EFLAGS_AC);
+  X86_EFLAGS_IOPL|X86_EFLAGS_AC|X86_EFLAGS_NT);
 }
 
 /*
-- 
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/

[PATCH 1/1 linux-next] net/dccp/ccid.c: add __init to ccid_activate

[Fabian Frederick]

ccid_activate is only called by __init ccid_initialize_builtins in same module.

Signed-off-by: Fabian Frederick 
---
 net/dccp/ccid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dccp/ccid.c b/net/dccp/ccid.c
index 5975572..8349897 100644
--- a/net/dccp/ccid.c
+++ b/net/dccp/ccid.c
@@ -99,7 +99,7 @@ static void ccid_kmem_cache_destroy(struct kmem_cache *slab)
kmem_cache_destroy(slab);
 }
 
-static int ccid_activate(struct ccid_operations *ccid_ops)
+static int __init ccid_activate(struct ccid_operations *ccid_ops)
 {
int err = -ENOBUFS;
 
-- 
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/

[PATCH v2 0/2] x86_64,entry: Clear NT on entry and speed up switch_to

[Andy Lutomirski]

Anish Bhatt noticed that user programs can set RFLAGS.NT before
syscall or sysenter, and the kernel entry code doesn't filter out
NT.  This causes kernel C code and, depending on thread flags, the
exit slow path to run with NT set.

The former is a little bit scary (imagine calling into EFI with NT
set), and the latter will fail with #GP and send a spurious SIGSEGV.

One answer would be "don't do that".  But the kernel can do better
here.

These patches filter NT on all kernel entries.  For syscall (both
bitnesses), this is free.  For sysenter, it seems to cost very
little (less than my ability to measure, although I didn't try that
hard).  Patch 2, which isn't tagged for -stable, speeds up context
switches by avoiding saving and restoring flags, so this series
should be a decent overall performance win.

See: https://bugs.winehq.org/show_bug.cgi?id=33275

Changes from v1:
 - Spell sta...@vger.kernel.org correctly
 - Tidy up changelog text
 - Actually commit an asm constraint fix in patch 2 (egads!)
 - Replace the unconditional popfq with a branch

Andy Lutomirski (2):
  x86_64,entry: Filter RFLAGS.NT on entry from userspace
  x86_64: Don't save flags on context switch

 arch/x86/ia32/ia32entry.S| 12 
 arch/x86/include/asm/switch_to.h | 12 
 arch/x86/kernel/cpu/common.c |  2 +-
 3 files changed, 21 insertions(+), 5 deletions(-)

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

[PATCH 1/1 linux-next] net/dccp/proto.c: add __init to dccp_mib_init

[Fabian Frederick]

dccp_mib_init is only called by __init dccp_init in same module.

Signed-off-by: Fabian Frederick 
---
 net/dccp/proto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dccp/proto.c b/net/dccp/proto.c
index e421edd..6d090c4 100644
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -1082,7 +1082,7 @@ void dccp_shutdown(struct sock *sk, int how)
 
 EXPORT_SYMBOL_GPL(dccp_shutdown);
 
-static inline int dccp_mib_init(void)
+static inline int __init dccp_mib_init(void)
 {
dccp_statistics = alloc_percpu(struct dccp_mib);
if (!dccp_statistics)
-- 
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 1/1 linux-next] ieee802154: add __init to lowpan_frags_sysctl_register

[David Miller]

From: Fabian Frederick 
Date: Wed, 1 Oct 2014 06:36:49 +0200 (CEST)

>     I didn't see _ns_ . I'll send the right fix based on wpan-next.

You'll have to send it to me, because I applied your patch already
to net-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next] ieee802154: add __init to lowpan_frags_sysctl_register

[Fabian Frederick]

> On 01 October 2014 at 02:25 Alexander Aring  wrote:
>
>
> Hi,
>
> On Tue, Sep 30, 2014 at 10:34:08PM +0200, Fabian Frederick wrote:
> > lowpan_frags_sysctl_register is only called by __init lowpan_net_frag_init
> > (part of the lowpan module).
> >
> > Signed-off-by: Fabian Frederick 
> > ---
> > This is untested.
> >
> >  net/ieee802154/reassembly.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ieee802154/reassembly.c b/net/ieee802154/reassembly.c
> > index 32755cb..30ec608 100644
> > --- a/net/ieee802154/reassembly.c
> > +++ b/net/ieee802154/reassembly.c
> > @@ -485,7 +485,7 @@ static void __net_exit
> > lowpan_frags_ns_sysctl_unregister(struct net *net)
> > 
> >  static struct ctl_table_header *lowpan_ctl_header;
> > 
> > -static int lowpan_frags_sysctl_register(void)
> > +static int __init lowpan_frags_sysctl_register(void)
>
> yes right, but there is more lacks of missing "__init". See below.
>
> >  {
> >     lowpan_ctl_header = register_net_sysctl(_net,
> >                                             "net/ieee802154/6lowpan",
> > @@ -498,7 +498,7 @@ static void lowpan_frags_sysctl_unregister(void)
> >     unregister_net_sysctl_table(lowpan_ctl_header);
> >  }
> >  #else
> > -static inline int lowpan_frags_ns_sysctl_register(struct net *net)
> > +static inline int __init lowpan_frags_ns_sysctl_register(struct net *net)
>
> This is wrong, it's callback from "struct pernet_operations lowpan_frags_ops".
>
> >  {
> >     return 0;
> >  }
>
>
> Your patch adds "__init" now for two different functions and we have
> two different declarations for these functions, depends if CONFIG_SYSCTL is
> enabled.
>
> Now if CONFIG_SYSCTL select we have as lowpan_frags_sysctl_register
> declaration:
>
> static int __init lowpan_frags_sysctl_register(void)
>
> if not:
>
> static inline int lowpan_frags_sysctl_register(void)
>
> Same for lowpan_frags_ns_sysctl_register and vice versa for CONFIG_SYSCTL.
>
> Your changes are for two different functions (Don't know if you realized
> that):

Hi Alexander,

    I didn't see _ns_ . I'll send the right fix based on wpan-next.

Thanks,
Fabian


>
> "lowpan_frags_sysctl_register" and "lowpan_frags_ns_sysctl_register",
> which makes no sense. Also lowpan_frags_ns_sysctl_register isn't called
> by module init which is wrong.
>
>
> To make "correct" cleanup for this "__init" should be add to the functions,
> for
> both declarations if CONFIG_SYSCTL is set or not:
>
>  - lowpan_net_frag_init
>  - lowpan_frags_sysctl_register
>
>
> I see now it's already applied, David please revert this change. Are you
> fine to apply a correct version of this to wpan-next tree, next time?
>
> - Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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, MCE, AMD: save IA32_MCi_STATUS before machine_check_poll() resets it

[Chen Yucong]

On Tue, 2014-09-30 at 12:09 +0200, Borislav Petkov wrote:
> On Tue, Sep 30, 2014 at 05:56:31PM +0800, Chen Yucong wrote:
> > I just clear it to avoid that the mce_log() call logs the above
> > threshold event again in machine_check_poll().
> 
> Ok, that's a good point, please put it in the commit message.
> 
> > It is just used for scanning other banks for recording other valid
> > error information.
> 
> This is actually not what we want - we want to log the errors which
> cause the overflow first and then the rest. So you don't need the goto
> but simply have the machine_check_poll() at the end. 


From: Chen Yucong 

machine_check_poll() will reset IA32_MCi_STATUS register to zero.
So we need to save the content of IA32_MCi_STATUS MSRs before
calling machine_check_poll() for logging threshold interrupt event.

mce_setup() does not gather the content of IA32_MCG_STATUS, so it
should be read explicitly. Moreover, we need to clear IA32_MCx_STATUS
to avoid that mce_log() logs the processed threshold event again
at next time.

Signed-off-by: Chen Yucong 
---
 arch/x86/kernel/cpu/mcheck/mce_amd.c |   18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c 
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index f8c56bd..643e6a2 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -274,6 +274,7 @@ static void amd_threshold_interrupt(void)
struct mce m;
 
mce_setup();
+   rdmsrl(MSR_IA32_MCG_STATUS, m.mcgstatus);
 
/* assume first bank caused it */
for (bank = 0; bank < mca_cfg.banks; ++bank) {
@@ -305,24 +306,27 @@ static void amd_threshold_interrupt(void)
 (high & MASK_LOCKED_HI))
continue;
 
-   /*
-* Log the machine check that caused the threshold
-* event.
-*/
-   machine_check_poll(MCP_TIMESTAMP,
-   this_cpu_ptr(_poll_banks));
-
if (high & MASK_OVERFLOW_HI) {
rdmsrl(address, m.misc);
rdmsrl(MSR_IA32_MCx_STATUS(bank), m.status);
+   if (m.status & MCI_STATUS_ADDRV)
+   rdmsrl(MSR_IA32_MCx_ADDR(bank), m.addr);
m.bank = K8_MCE_THRESHOLD_BASE
   + bank * NR_BLOCKS
   + block;
mce_log();
+
+   wrmsrl(MSR_IA32_MCx_STATUS(bank), 0);
return;
}
}
}
+
+   /*
+* Log the machine check that caused the threshold event.
+*/
+   machine_check_poll(MCP_TIMESTAMP,
+   this_cpu_ptr(_poll_banks));
 }
 
 /*
-- 
1.7.10.4



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

Re: [PATCH net v6 4/4] tg3: Fix tx_pending checks for tg3_tso_bug

[Eric Dumazet]

On Tue, 2014-09-30 at 20:14 -0700, Prashant wrote:

> Sorry about the late reply, out of all the HW bug conditions checked in 
> tg3_tx_frag_set() the most frequently hit condition is the short 8 byte 
> dma bug, where the chip cannot handle TX descriptors whose data buffer 
> is 8 bytes or less. Most of the LSO skb's given to the driver has their 
> fragments filled upto PAGE_SIZE (expect the last fragment depending on 
> skb->len). And if such a LSO skb's last fragment meets the 8 bytes HW 
> bug condition the above routine will not help workaround this particular 
> case.

Thats pretty easy to work around.

Say rebuilt skb has N frags (N > 1 given your description)

They are numbered 0, ... N-2, N-1

Instead of filling N-2 completely, fill it to PAGE_SIZE-8, so that last
frag has at least 8 bytes in it.

Also take a look at commit 2e4e44107176d552f8bb1bb76053e850e3809841
("net: add alloc_skb_with_frags() helper")



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fuse: handle release synchronously (v4)

[Miklos Szeredi]

On Tue, Sep 30, 2014 at 10:44 PM, Linus Torvalds
 wrote:
> On Tue, Sep 30, 2014 at 12:19 PM, Miklos Szeredi  wrote:
>>
>> What about flock(2), FL_SETLEASE, etc semantics (which are the sane ones,
>> compared to the POSIX locks shit which mandates release of lock on each 
>> close(2)
>> instead of "when all [duplicate] descriptors have been closed")?
>>
>> You have to do that from ->release(), there's no question about that.
>
> We do locks_remove_file() independently on ->release, but yes, it's
> basically done just before the last release.
>
> But it has the *exact* same semantics as release, including very much
> having nothing what-so-ever to do with "last close()".
>
> If the file descriptor is opened for other reasons (ie mmap, /proc
> accesses, whatever), then that delays locks_remove_file() the same way
> it delays release.
>
> None of that has *anothing* to do with "synchronous". Thinking it does is 
> wrong.

Oh, and btw. nfsv4 has a synchronous ->release implementation.
Probably for exactly the same reason Anand and Maxim wants it in their
server.  Note: locks_remove_file() works for local locking, but
distributed filesystems need to release locks and leases in their
->release.

And yes, /proc does temporary ref of file.  But it's an implementation
detail, and should be fixable.  As to mmap, it's almost like dup(2)
regarding the file, we could actually handle it that way and have a
flush at munmap time too.

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

Re: [PATCH v7 00/11] kernel: Add support for restart handler call chain

[Guenter Roeck]

On 09/30/2014 04:40 PM, Stephen Rothwell wrote:

Hi Guenter,

On Tue, 30 Sep 2014 15:30:00 -0700 Guenter Roeck  wrote:


On Tue, Sep 30, 2014 at 02:20:02PM -0700, Andrew Morton wrote:

On Tue, 19 Aug 2014 17:45:27 -0700 Guenter Roeck  wrote:


Introduce a system restart handler call chain to solve the described problems.


So someone has merged eight of these patches into linux-next but these
three:

watchdog-s3c2410-add-restart-handler.patch
clk-samsung-register-restart-handlers-for-s3c2412-and-s3c2443.patch
clk-rockchip-add-restart-handler.patch

were omitted.  What's up?


Most likely PBKC on my side; Looks like I forgot to add those when I created
the immutable branch for others to merge. Sorry for that :-(.

Having said that, I somehow thought that the clock patches would go in through
the clock tree. Heiko, did I get that wrong ? Separately, I sent a pull request
that includes the watchdog patch to Wim.


So far, that immutable branch has been merged into the battery tree
(and thus into linux-next) by Sebastian in order to add (I assume):

18a702e0de98 power: reset: use restart_notifier mechanism for msm-poweroff
371bb20d6927 power: Add simple gpio-restart driver

on top of it.

So, I guess the watchdog and clk trees also need to merge that
immutable branch and then add their respective patches from the mmotm
series to their trees.


Yes, and now I remember why I did not include those patches: They are not
authored by myself. I thought it was not appropriate for me to include them
in the branch I created. Maybe flawed thinking, but that was my reasoning.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 2/2] staging: skein: File Reorg

[Eric Rost]

Reorganizes file to remove #defines from middle of functions. Also
removes #if'd loop declarations and adds ternary if driven loops.

Signed-off-by: Eric Rost 
---
 drivers/staging/skein/skein_block.c |  680 ++-
 1 file changed, 351 insertions(+), 329 deletions(-)

diff --git a/drivers/staging/skein/skein_block.c 
b/drivers/staging/skein/skein_block.c
index 71c14f5..88bc718 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -42,17 +42,9 @@
 #define debug_save_tweak(ctx)
 #endif
 
-/*  SKEIN_256 **/
 #if !(SKEIN_USE_ASM & 256)
-void skein_256_process_block(struct skein_256_ctx *ctx, const u8 *blk_ptr,
-size_t blk_cnt, size_t byte_cnt_add)
-{ /* do it in C */
-   enum {
-   WCNT = SKEIN_256_STATE_WORDS
-   };
 #undef  RCNT
 #define RCNT (SKEIN_256_ROUNDS_TOTAL / 8)
-
 #ifdef SKEIN_LOOP /* configure how much to unroll the loop */
 #define SKEIN_UNROLL_256 (((SKEIN_LOOP) / 100) % 10)
 #else
@@ -63,56 +55,7 @@ void skein_256_process_block(struct skein_256_ctx *ctx, 
const u8 *blk_ptr,
 #if (RCNT % SKEIN_UNROLL_256)
 #error "Invalid SKEIN_UNROLL_256" /* sanity check on unroll count */
 #endif
-   size_t  r;
-   u64  kw[WCNT+4+RCNT*2]; /* key schedule: chaining vars + tweak + "rot"*/
-#else
-   u64  kw[WCNT+4]; /* key schedule words : chaining vars + tweak */
-#endif
-   u64  X0, X1, X2, X3; /* local copy of context vars, for speed */
-   u64  w[WCNT]; /* local copy of input block */
-#ifdef SKEIN_DEBUG
-   const u64 *X_ptr[4]; /* use for debugging (help cc put Xn in regs) */
-
-   X_ptr[0] =   X_ptr[1] =   X_ptr[2] =   X_ptr[3] = 
 #endif
-   skein_assert(blk_cnt != 0); /* never call with blk_cnt == 0! */
-   ts[0] = ctx->h.tweak[0];
-   ts[1] = ctx->h.tweak[1];
-   do  {
-   /*
-* this implementation only supports 2**64 input bytes
-* (no carry out here)
-*/
-   ts[0] += byte_cnt_add; /* update processed length */
-
-   /* precompute the key schedule for this block */
-   ks[0] = ctx->x[0];
-   ks[1] = ctx->x[1];
-   ks[2] = ctx->x[2];
-   ks[3] = ctx->x[3];
-   ks[4] = ks[0] ^ ks[1] ^ ks[2] ^ ks[3] ^ SKEIN_KS_PARITY;
-
-   ts[2] = ts[0] ^ ts[1];
-
-   /* get input block in little-endian format */
-   skein_get64_lsb_first(w, blk_ptr, WCNT);
-   debug_save_tweak(ctx);
-   skein_show_block(BLK_BITS, >h, ctx->x, blk_ptr, w, ks, ts);
-
-   /* do the first full key injection */
-   X0 = w[0] + ks[0];
-   X1 = w[1] + ks[1] + ts[0];
-   X2 = w[2] + ks[2] + ts[1];
-   X3 = w[3] + ks[3];
-
-   /* show starting state values */
-   skein_show_r_ptr(BLK_BITS, >h, SKEIN_RND_KEY_INITIAL,
-x_ptr);
-
-   blk_ptr += SKEIN_256_BLOCK_BYTES;
-
-   /* run the rounds */
-
 #define ROUND256(p0, p1, p2, p3, ROT, r_num) \
 do { \
X##p0 += X##p1;  \
@@ -159,10 +102,7 @@ do { \
ts[r + (R) + 2] = ts[r + (R) - 1];\
skein_show_r_ptr(BLK_BITS, >h, SKEIN_RND_KEY_INJECT, X_ptr); \
 } while (0)
-
-   for (r = 1; r < 2 * RCNT; r += 2 * SKEIN_UNROLL_256)
 #endif
-   {
 #define R256_8_ROUNDS(R) \
 do { \
R256(0, 1, 2, 3, R_256_0, 8 * (R) + 1);  \
@@ -177,57 +117,362 @@ do { 
\
I256(2 * (R) + 1);   \
 } while (0)
 
-   R256_8_ROUNDS(0);
+#define R256_UNROLL_R(NN) \
+   ((SKEIN_UNROLL_256 == 0 &&\
+   SKEIN_256_ROUNDS_TOTAL / 8 > (NN)) || \
+   (SKEIN_UNROLL_256 > (NN)))
+
+#if  (SKEIN_UNROLL_256 > 14)
+#error  "need more unrolling in skein_256_process_block"
+#endif
+#endif
+
+#if !(SKEIN_USE_ASM & 512)
+#undef  RCNT
+#define RCNT  (SKEIN_512_ROUNDS_TOTAL/8)
+
+#ifdef SKEIN_LOOP /* configure how much to unroll the loop */
+#define SKEIN_UNROLL_512 (((SKEIN_LOOP)/10)%10)
+#else
+#define SKEIN_UNROLL_512 (0)
+#endif
+
+#if SKEIN_UNROLL_512
+#if (RCNT % SKEIN_UNROLL_512)
+#error "Invalid SKEIN_UNROLL_512" /* sanity check on unroll count */
+#endif
+#endif
+#define ROUND512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, r_num) \
+do { \
+   X##p0 += X##p1;  \
+   X##p1 = rotl_64(X##p1, ROT##_0); \
+   X##p1 ^= X##p0;  \
+   X##p2 += X##p3; 

[PATCH v4 1/2] staging: skein: Whitespace cleanup

[Eric Rost]

Pretties up multiline #defines and many other whitespace issues

Signed-off-by: Eric Rost 
---
 drivers/staging/skein/skein_block.c |  585 +++
 1 file changed, 315 insertions(+), 270 deletions(-)

diff --git a/drivers/staging/skein/skein_block.c 
b/drivers/staging/skein/skein_block.c
index 616364f..71c14f5 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -26,15 +26,18 @@
 #define SKEIN_LOOP 001 /* default: unroll 256 and 512, but not 1024 */
 #endif
 
-#define BLK_BITS(WCNT*64) /* some useful definitions for code here */
+#define BLK_BITS(WCNT * 64) /* some useful definitions for code here */
 #define KW_TWK_BASE (0)
 #define KW_KEY_BASE (3)
 #define ks  (kw + KW_KEY_BASE)
 #define ts  (kw + KW_TWK_BASE)
 
 #ifdef SKEIN_DEBUG
-#define debug_save_tweak(ctx) { \
-   ctx->h.tweak[0] = ts[0]; ctx->h.tweak[1] = ts[1]; }
+#define debug_save_tweak(ctx)   \
+{   \
+   ctx->h.tweak[0] = ts[0];\
+   ctx->h.tweak[1] = ts[1];\
+}
 #else
 #define debug_save_tweak(ctx)
 #endif
@@ -43,15 +46,15 @@
 #if !(SKEIN_USE_ASM & 256)
 void skein_256_process_block(struct skein_256_ctx *ctx, const u8 *blk_ptr,
 size_t blk_cnt, size_t byte_cnt_add)
-   { /* do it in C */
+{ /* do it in C */
enum {
WCNT = SKEIN_256_STATE_WORDS
};
 #undef  RCNT
-#define RCNT  (SKEIN_256_ROUNDS_TOTAL/8)
+#define RCNT (SKEIN_256_ROUNDS_TOTAL / 8)
 
 #ifdef SKEIN_LOOP /* configure how much to unroll the loop */
-#define SKEIN_UNROLL_256 (((SKEIN_LOOP)/100)%10)
+#define SKEIN_UNROLL_256 (((SKEIN_LOOP) / 100) % 10)
 #else
 #define SKEIN_UNROLL_256 (0)
 #endif
@@ -96,7 +99,8 @@ void skein_256_process_block(struct skein_256_ctx *ctx, const 
u8 *blk_ptr,
debug_save_tweak(ctx);
skein_show_block(BLK_BITS, >h, ctx->x, blk_ptr, w, ks, ts);
 
-   X0 = w[0] + ks[0]; /* do the first full key injection */
+   /* do the first full key injection */
+   X0 = w[0] + ks[0];
X1 = w[1] + ks[1] + ts[0];
X2 = w[2] + ks[2] + ts[1];
X3 = w[3] + ks[3];
@@ -109,29 +113,34 @@ void skein_256_process_block(struct skein_256_ctx *ctx, 
const u8 *blk_ptr,
 
/* run the rounds */
 
-#define ROUND256(p0, p1, p2, p3, ROT, r_num)  \
-do { \
-   X##p0 += X##p1; X##p1 = rotl_64(X##p1, ROT##_0); X##p1 ^= X##p0; \
-   X##p2 += X##p3; X##p3 = rotl_64(X##p3, ROT##_1); X##p3 ^= X##p2; \
+#define ROUND256(p0, p1, p2, p3, ROT, r_num) \
+do { \
+   X##p0 += X##p1;  \
+   X##p1 = rotl_64(X##p1, ROT##_0); \
+   X##p1 ^= X##p0;  \
+   X##p2 += X##p3;  \
+   X##p3 = rotl_64(X##p3, ROT##_1); \
+   X##p3 ^= X##p2;  \
 } while (0)
 
 #if SKEIN_UNROLL_256 == 0
 #define R256(p0, p1, p2, p3, ROT, r_num) /* fully unrolled */ \
-do { \
-   ROUND256(p0, p1, p2, p3, ROT, r_num); \
-   skein_show_r_ptr(BLK_BITS, >h, r_num, X_ptr); \
+do {  \
+   ROUND256(p0, p1, p2, p3, ROT, r_num); \
+   skein_show_r_ptr(BLK_BITS, >h, r_num, X_ptr);\
 } while (0)
 
-#define I256(R) \
-do { \
-   /* inject the key schedule value */ \
-   X0   += ks[((R)+1) % 5]; \
-   X1   += ks[((R)+2) % 5] + ts[((R)+1) % 3]; \
-   X2   += ks[((R)+3) % 5] + ts[((R)+2) % 3]; \
-   X3   += ks[((R)+4) % 5] + (R)+1;   \
+#define I256(R)   \
+do {  \
+   /* inject the key schedule value */   \
+   X0   += ks[((R) + 1) % 5];\
+   X1   += ks[((R) + 2) % 5] + ts[((R) + 1) % 3];\
+   X2   += ks[((R) + 3) % 5] + ts[((R) + 2) % 3];\
+   X3   += ks[((R) + 4) % 5] + (R) + 1;  \
skein_show_r_ptr(BLK_BITS, >h, SKEIN_RND_KEY_INJECT, X_ptr); \
 } while (0)
-#else /* looping version */
+#else
+/* looping version */
 #define R256(p0, p1, p2, p3, ROT, r_num) \
 do { \
ROUND256(p0, p1, p2, p3, ROT, r_num); \
@@ -141,85 +150,85 @@ do { \
 #define I256(R) \
 do { \
/* inject the key schedule value */ \
-   X0   += ks[r+(R)+0]; \
-   X1   += ks[r+(R)+1] + ts[r+(R)+0]; \
-   X2   += ks[r+(R)+2] + ts[r+(R)+1]; \
-   X3   += ks[r+(R)+3] +r+(R);\
-   /* rotate key schedule */ \
-   ks[r + (R) + 4]   = ks[r + (R) - 1]; \
-   ts[r + (R) + 2]   = ts[r + (R) - 1]; \
+   X0 += ks[r + (R) + 0]; \
+   X1 += ks[r + (R) + 1] + ts[r + (R) + 0];

[PATCH v4 0/2] staging: skein: Fixes Conditional white space problems

[Eric Rost]

This patchset fixes the following checkpatch.pl Warnings in
skein_block.c:

WARNING: suspect code indent for conditional statements (16, 16)
+   for (r = 1; r < 2 * RCNT; r += 2 * SKEIN_UNROLL_512)
[...]
+   {

WARNING: suspect code indent for conditional statements (16, 16)
+   for (r = 1; r <= 2 * RCNT; r += 2 * SKEIN_UNROLL_1024)
[...]
+   {

It also removes macro definitions from inside functions and cleans up
whitespace issues.

Eric Rost (2):
  staging: skein: Whitespace cleanup
  staging: skein: File Reorg

 drivers/staging/skein/skein_block.c |  933 +++
 1 file changed, 500 insertions(+), 433 deletions(-)

-- 
1.7.10.4

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

Re: [PATCH v5] init: Disable defaults if init= fails

[Rob Landley]

On 09/30/14 20:52, Frank Rowand wrote:
> On 9/30/2014 5:58 PM, Rob Landley wrote:
>> If you're going to argue that it should "default y", that's a defensible
>> choice. But please don't argue for kernel config symbols with a negative
>> meaning or we'll start having allyesconfig_n brain damage too...
> 
> Yes, "default y" is a valid answer to my request.

Works for me.

>>> Instead of using a config option, would adding another kernel
>>> command line option, such as 'init_fail_is_fatal', work for
>>> your needs?
>>
>> That was the previous series of patches you ignored, which added code so
>> you can provide _extra_ kernel commands to tell it _not_ to do stuff.
>> The patches did not generate noticeable enthusiasm.
> 
> But there also was not a strong push back either.  Just Chuck's suggestion
> of an alternate syntax, and your suggestion of instead using a config
> option (and possibly immediately deprecating the config option).
> 
> You could as easily frame the argument that the added code was to
> tell the kernel to "_do_ stuff" (panic) instead of "_not_ do stuff".
> But that is just semantics on my part; whatever.
> 
> I thought the general trend was to try to avoid adding config options.
> The strictinit method seems fine to me.

Embedded guys care:

http://elinux.org/Linux_Tiny

http://lkml.iu.edu//hypermail/linux/kernel/1409.2/03763.html

>>> I have a feeling this has already been proposed,
>>> as the 'strictinit' option mentioned in the changes from v3
>>> below might be the same concept?
>>
>> That was it, yes.
>>
>> Having to get your kernel config right (and your kernel command line
>> right) in order for your system to boot is not really a new concept, is
>> it? You can still specify "init=/bin/sh" if you want that. (I do it all
>> the time when I need to edit a system I haven't bothered to look up the
>> root password to.)
> 
> Yes, of course I can.  So it falls back to personal preference (as I said,
> I like that some failed boots will drop into a shell without having to
> change the kernel command line).

The config option lets it do that. Default Y preserves the old behavior.

*shrug*

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 4/4] tg3: Fix tx_pending checks for tg3_tso_bug

[Prashant]

On 9/5/2014 9:39 PM, David Miller wrote:

From: David Miller 
Date: Fri, 05 Sep 2014 17:13:06 -0700 (PDT)


From: Eric Dumazet 
Date: Fri, 05 Sep 2014 17:03:30 -0700


Instead of this private helper (and pretty limited one btw), we could
add a core function, that would build skbs with order-0 fragments.

Instead of skb_linearize(), I guess many call sites could instead use
this new helper.

Because as you said, skb_linearize() of one 64KB GSO packet can ask
order-5 allocations, and this generally does not work reliably.


xen-netback could make use of this helper too.


I was curious what it might look like so I cobbled the following
completely untested patch together :-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index da1378a..eba0ad6 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -955,6 +955,67 @@ struct sk_buff *skb_copy(const struct sk_buff *skb, gfp_t 
gfp_mask)
  EXPORT_SYMBOL(skb_copy);

  /**
+ * skb_copy_pskb   -   copy sk_buff into a paged skb
+ * @oskb: buffer to copy
+ * @gfp_mask: allocation priority
+ *
+ * Normalize a paged skb into one that maximally uses order
+ * zero pages in it's fragment array.  This is used to canonicalize
+ * spaghetti SKBs that use the page array inefficiently (f.e. only
+ * one byte per page frag).
+ */
+
+struct sk_buff *skb_copy_pskb(const struct sk_buff *oskb, gfp_t gfp_mask)
+{
+   unsigned int data_len = oskb->data_len;
+   int offset, npages, i;
+   struct sk_buff *skb;
+
+   npages = (data_len + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
+   if (npages > MAX_SKB_FRAGS)
+   return NULL;
+
+   skb = __alloc_skb(skb_end_offset(oskb), gfp_mask,
+ skb_alloc_rx_flag(oskb), NUMA_NO_NODE);
+   if (!skb)
+   return NULL;
+
+   skb_reserve(skb, skb_headroom(oskb));
+   skb_put(skb, skb_headlen(oskb));
+   skb_copy_from_linear_data(oskb, skb->data, skb->len);
+
+   copy_skb_header(skb, oskb);
+
+   skb->truesize += data_len;
+   offset = skb_headlen(oskb);
+   for (i = 0; i < npages; i++) {
+   struct page *page = alloc_page(gfp_mask);
+   unsigned int chunk;
+   u8 *vaddr;
+
+   if (!page) {
+   kfree(skb);
+   skb = NULL;
+   break;
+   }
+
+   chunk = min_t(unsigned int, data_len, PAGE_SIZE);
+   skb_fill_page_desc(skb, i, page, 0, chunk);
+
+   vaddr = kmap_atomic(page);
+   skb_copy_bits(oskb, offset, vaddr, chunk);
+   kunmap_atomic(vaddr);
+
+   offset += chunk;
+   data_len -= chunk;
+   skb->data_len += chunk;
+   }
+
+   return skb;
+}
+EXPORT_SYMBOL(skb_copy_pskb);
+
+/**
   *__pskb_copy_fclone  -  create copy of an sk_buff with private head.
   *@skb: buffer to copy
   *@headroom: headroom of new skb

Sorry about the late reply, out of all the HW bug conditions checked in 
tg3_tx_frag_set() the most frequently hit condition is the short 8 byte 
dma bug, where the chip cannot handle TX descriptors whose data buffer 
is 8 bytes or less. Most of the LSO skb's given to the driver has their 
fragments filled upto PAGE_SIZE (expect the last fragment depending on 
skb->len). And if such a LSO skb's last fragment meets the 8 bytes HW 
bug condition the above routine will not help workaround this particular 
case.

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

linux-next: manual merge of the vfio tree with the pci tree

[Stephen Rothwell]

Hi Alex,

Today's linux-next merge of the vfio tree got a conflict in
drivers/pci/msi.c between commits a160fe94cb53 ("PCI/MSI: Remove unused
get_cached_msi_msg()") and 18ef822c59f6 ("PCI/MSI: Rename
__get_cached_msi_msg() to get_cached_msi_msg()") from the pci tree and
commit 3b307ffe3faa ("PCI: Export MSI message relevant functions") from
the vfio tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).  And then I added this merge fix patch (I should probably
also have added an include of linux/irq.h):

From: Stephen Rothwell 
Date: Wed, 1 Oct 2014 13:09:58 +1000
Subject: [PATCH] vfio: update for get_cached_msi_msg API change

Signed-off-by: Stephen Rothwell 
---
 drivers/vfio/pci/vfio_pci_intrs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
b/drivers/vfio/pci/vfio_pci_intrs.c
index 553212f037c3..a068bb0d69e5 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -559,7 +559,7 @@ static int vfio_msi_set_vector_signal(struct 
vfio_pci_device *vdev,
if (msix) {
struct msi_msg msg;
 
-   get_cached_msi_msg(irq, );
+   get_cached_msi_msg(irq_get_msi_desc(irq), );
write_msi_msg(irq, );
}
 
-- 
2.1.1


Someone needs to remember to send this fix to Linus when these 2 trees
are merged into his tree ...
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/pci/msi.c
index d077749df25b,e468d65eb238..
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@@ -288,6 -305,14 +288,7 @@@ void get_cached_msi_msg(struct msi_des
  
*msg = entry->msg;
  }
 -
 -void get_cached_msi_msg(unsigned int irq, struct msi_msg *msg)
 -{
 -  struct msi_desc *entry = irq_get_msi_desc(irq);
 -
 -  __get_cached_msi_msg(entry, msg);
 -}
+ EXPORT_SYMBOL_GPL(get_cached_msi_msg);
  
  void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
  {


signature.asc
Description: PGP signature

Re: [PATCH RESEND V9 1/6] power: reset: Add generic SYSCON register mapped reset

[Guenter Roeck]

On 09/30/2014 04:25 PM, Feng Kan wrote:

Add a generic SYSCON register mapped reset mechanism.

Signed-off-by: Feng Kan 
---
  drivers/power/reset/Kconfig |  5 ++
  drivers/power/reset/Makefile|  1 +
  drivers/power/reset/syscon-reboot.c | 96 +
  3 files changed, 102 insertions(+)
  create mode 100644 drivers/power/reset/syscon-reboot.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1915dde..a863fa1 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -143,4 +143,9 @@ config POWER_RESET_KEYSTONE
help
  Reboot support for the KEYSTONE SoCs.

+config POWER_RESET_SYSCON
+   bool "Generic SYSCON regmap reset driver"
+   depends on POWER_RESET && MFD_SYSCON && OF


Other drivers have
select MFD_SYSCON


+   help
+ Reboot support for generic SYSCON mapped register reset.
  endif
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 01e401d..76ce1c5 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_POWER_RESET_VERSATILE) += arm-versatile-reboot.o
  obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
  obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
  obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
+obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/syscon-reboot.c 
b/drivers/power/reset/syscon-reboot.c
new file mode 100644
index 000..948e0ee
--- /dev/null
+++ b/drivers/power/reset/syscon-reboot.c
@@ -0,0 +1,96 @@
+/*
+ * Generic Syscon Reboot Driver
+ *
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Author: Feng Kan 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 


alphabetic order of include files ?


+#include 
+#include 
+#include 
+
+struct syscon_reboot_context {
+   struct regmap *map;
+   u32 offset;
+   u32 mask;
+   struct notifier_block restart_handler;
+};
+
+static struct syscon_reboot_context *syscon_reboot_ctx;
+
+static int syscon_restart_handle(struct notifier_block *this,
+   unsigned long mode, void *cmd)
+{
+   struct syscon_reboot_context *ctx = syscon_reboot_ctx;


Since restart_handler is part of syscon_reboot_context, you
do not need a static variable. You can use
struct syscon_reboot_context *ctx = container_of(ctx, struct 
syscon_reboot_context, restart_handler);
instead.


+   unsigned long timeout;
+
+   /* Issue the reboot */
+   if (ctx->map)
+   regmap_write(ctx->map, ctx->offset, ctx->mask);
+

The check for ctx->map is not needed. If the restart handler is installed,
it will always be valid.


+   timeout = jiffies + HZ;
+   while (time_before(jiffies, timeout))
+   cpu_relax();
+

jiffies won't work here, and nothing else is expected to happen.
Just use mdelay(1000);


+   pr_emerg("Unable to restart system\n");
+   return NOTIFY_DONE;
+}
+
+static int syscon_reboot_probe(struct platform_device *pdev)
+{
+   struct syscon_reboot_context *ctx;
+   struct device *dev = >dev;
+   int err;
+
+   ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
+   if (!ctx)
+   return -ENOMEM;
+
+   ctx->map = syscon_regmap_lookup_by_phandle(dev->of_node, "regmap");
+   if (IS_ERR(ctx->map))
+   return PTR_ERR(ctx->map);
+
+   if (of_property_read_u32(pdev->dev.of_node, "offset", >offset))
+   return -EINVAL;
+
+   if (of_property_read_u32(pdev->dev.of_node, "mask", >mask))
+   return -EINVAL;
+
+   ctx->restart_handler.notifier_call = syscon_restart_handle;
+   ctx->restart_handler.priority = 128;
+   err = register_restart_handler(>restart_handler);
+   if (err)
+   dev_err(dev, "can't register restart notifier (err=%d)\n", err);
+
+   syscon_reboot_ctx = ctx;
+
+   return 0;
+}
+
+static struct of_device_id syscon_reboot_of_match[] = {
+   { .compatible = "syscon-reboot" },
+   {}
+};
+
+static struct platform_driver syscon_reboot_driver = {
+   .probe = syscon_reboot_probe,
+   .driver = {
+   .name = "syscon-reboot",
+   .of_match_table = syscon_reboot_of_match,
+   },
+};
+module_platform_driver(syscon_reboot_driver);



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

Re: [PATCH v3 2/3] drivers: staging: skein: In progress

[Eric Rost]

On Tue, 2014-09-30 at 09:21 -0700, Greg KH wrote:
> On Tue, Sep 30, 2014 at 02:00:05AM -0500, Eric Rost wrote:
> > In progress commit
> > Signed-off-by: Eric Rost 
> > ---
> 
> What does this mean?
> 
> And you need a blank line before your signed-off-by: line.
> 
> thanks,
> 
> greg k-h

It means I need to collapse this into two patches and it was late. I
will resend.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v8 2/2] ARM: EXYNOS: Move PMU specific definitions from common.h

[Pankaj Dubey]

Hi Arnd,

On Tuesday, September 30, 2014 4:09 PM, Arnd Bergmann wrote,
> To: linux-arm-ker...@lists.infradead.org
> Cc: Pankaj Dubey; linux-kernel@vger.kernel.org;
linux-samsung-...@vger.kernel.org;
> kgene@samsung.com; li...@arm.linux.org.uk; naus...@samsung.com;
> tomasz.f...@gmail.com; thomas...@samsung.com; vikas.saj...@samsung.com
> Subject: Re: [PATCH v8 2/2] ARM: EXYNOS: Move PMU specific definitions
from
> common.h
> 
> On Tuesday 30 September 2014 15:51:21 Pankaj Dubey wrote:
> >
> > +static inline void pmu_raw_writel(u32 val, u32 offset) {
> > +   __raw_writel(val, pmu_base_addr + offset); }
> > +
> > +static inline u32 pmu_raw_readl(u32 offset) {
> > +   return __raw_readl(pmu_base_addr + offset); }
> > +
> >
> 
> While you're at it, please convert these to use readl_relaxed() instead,
which is safe to
> use in drivers and works independent of CPU endianess.
> 

OK, I will update this. 

Thanks,
Pankaj Dubey
>   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: uid=0 inside user-namespace and procfs file permissions

[Eric W. Biederman]

Aditya Kali  writes:

> On Tue, Sep 30, 2014 at 5:35 PM, Eric W. Biederman
>  wrote:
>> Aditya Kali  writes:
>>
>>> Hi all,
>>>
>>> I am trying to run a process with uid=0 inside userns. But in the when
>>> I also do capset() after setresuid(0, 0, 0), I am seeing inconsistent
>>> proc file permissions. Almost all the files in /proc// has global
>>> 'root' as owner and group even if the actual process uid is correctly
>>> changed.
>>>
>>> I wrote a simple program that demonstrate the issue:
>>>
>>> 1. parent, as global root (uid=0 in init_user_ns) fork()s a child
>>> 2. child:
>>> a) unshare(CLONE_NEWUSER)
>>> b) [wait for parent to write uid_map]
>>> c) setresgid(id, id, id) ; setresuid(0, 0, 0);
>>> d) conditionally call capset() to clear capabilities
>>> e) execve(/bin/sleep)
>>> 3. parent:
>>> a) populates child's uid_map and maps some uid to 0 inside userns. ex:
>>> 0 99 1
>>> b) waitpid()
>>>
>>> (the actual program can be found at http://pastebin.com/f4P17VFn for
>>> your reference).
>>>
>>> When there is no capset() call after setresuid(0,0,0), everything is
>>> fine. But when I do a capset() to clear all capabilities, the 'owner'
>>> and 'group' of all the files under /proc//  of the child
>>> process are reverted to global 'root' user.
>>>
>>> # without capset (2.d):
>>> root@vm1# id
>>> uid=0(root) gid=0(root) groups=0(root)
>>>
>>> root@vm1# ./userns_uid0
>>> child_pid: 24277
>>> proc_file: /proc/24277/uid_map
>>> proc_file: /proc/24277/gid_map
>>> child resuming
>>>
>>> ^Z
>>> [1]+  Stopped ./userns_uid0
>>> root@vm1# cat /proc/24277/uid_map
>>>  0 99  1
>>> root@vm1# cat /proc/24277/status | grep -e "Uid:" -e "Gid:"
>>> Uid: 99 99 99 99
>>> Gid: 99 99 99 99
>>> root@vm1# ls -l /proc/24277/
>>> total 0
>>> dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:31 attr
>>> -r 1 nobody nobody 0 2014-09-30 16:31 auxv
>>> -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cgroup
>>> --w--- 1 nobody nobody 0 2014-09-30 16:31 clear_refs
>>> -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cmdline
>>> -rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 comm
>>> -rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 coredump_filter
>>> -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cpuset
>>> ...
>>> [All files have owner='nobody' and group='nobody' .. same as that of
>>> the process]
>>>
>>> With the additional capset() call, the files under /proc//
>>> are now owned by global root:
>>>
>>> root@vm1# ./userns_uid0 resetcaps
>>> child_pid: 24706
>>> proc_file: /proc/24706/uid_map
>>> proc_file: /proc/24706/gid_map
>>> child resuming
>>> resetting caps
>>> ^Z
>>> [2]+  Stopped ./userns_uid0 resetcaps
>>> root@vm1# cat /proc/24706/uid_map
>>>  0 99  1
>>> root@vm1# cat /proc/24706/status | grep -e "Uid:" -e "Gid:"
>>> Uid: 99 99 99 99
>>> Gid: 99 99 99 99
>>>
>>> [Everything as before till now]
>>>
>>> root@vm1# ls -l /proc/24706/
>>> total 0
>>> dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:47 attr
>>> -r 1 root   root   0 2014-09-30 16:47 auxv
>>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 cgroup
>>> --w--- 1 root   root   0 2014-09-30 16:47 clear_refs
>>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 cmdline
>>> -rw-r--r-- 1 root   root   0 2014-09-30 16:47 comm
>>> -rw-r--r-- 1 root   root   0 2014-09-30 16:47 coredump_filter
>>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 cpuset
>>> ...
>>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 mountinfo
>>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 mounts
>>> -r 1 root   root   0 2014-09-30 16:47 mountstats
>>> dr-xr-xr-x 5 nobody nobody 0 2014-09-30 16:47 net
>>> dr-x--x--x 2 root   root   0 2014-09-30 16:47 ns
>>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 numa_maps
>>> ...
>>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 status
>>> -r 1 root   root   0 2014-09-30 16:47 syscall
>>> dr-xr-xr-x 3 nobody nobody 0 2014-09-30 16:47 task
>>> ..
>>>
>>> Only the directories 'attr', 'net' and 'task' are owned by the uid=99.
>>> Rest all files are owned by global root.
>>>
>>> This behavior seems inconsistent. I ran this on 3.17 kernel. Can
>>> someone with expertise in this area explain if this is expected?
>>
>> So I am not quite certain what you are seeing.
>>
>> In general proc files are expected to be owned by the euid of a process.
>> However when the task_dumpable is cleared the files become owned by the
>> global root user.  We have considered relaxing that to the namespace
>> root user but so far implementing a more granular task_dumpable has not
>> been done.
>>
>
> I tried explicitly setting PR_SET_DUMPABLE before execve(), but that
> didn't either.
>
>> The directories are world readable so they don't matter.
>>
>> What puzzles me is that you have directories owned by nobody, and you
>> are talking about uid = 99 and gid = 99.  Nobody is traditionally
>> (u16_t)-2 and there should never actually be used by anyone.   And is
>> 

Re: [PATCH 3/3 v2] drivers/bus: Device driver for FSL-MC DPRC devices

[Timur Tabi]

Scott Wood wrote:

> >+   if (num_child_objects_in_mc != 0) {

>
>Like here.  Just do "if (num_child_objects_in_mc) {"



This seems to be a place that is testing for zero as a value rather than
as a stand-in for NULL, so I'd argue it's better style to leave it as
is.


But in this case, zero means "none left", so this is a perfectly valid 
use-case for omitting the !=.


strcmp() is the only time I can think of to put an explicit != 0, 
because this:


if (!strcmp(s1, s2))

is counter-intuitive.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: add mremap flag for preserving the old mapping

[Daniel Micay]

On 30/09/14 01:49 PM, Andy Lutomirski wrote:
> 
> I think it might pay to add an explicit vm_op to authorize
> duplication, especially for non-cow mappings.  IOW this kind of
> extension seems quite magical for anything that doesn't have the
> normal COW semantics, including for plain old read-only mappings.

This sounds like the best way forwards.

Setting up the op for private, anonymous mappings and having it check
vm_flags & VM_WRITE dynamically seems like it would be enough for the
intended use case in general purpose allocators. It can be extended to
other mapping types later if there's a compelling use case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3 v2] drivers/bus: Device driver for FSL-MC DPRC devices

[Scott Wood]

On Tue, 2014-09-30 at 21:19 -0500, Timur Tabi wrote:
> On Fri, Sep 19, 2014 at 5:49 PM, J. German Rivera
>  wrote:
> > +/**
> > + * dprc_remove_devices - Removes devices for objects removed from a DPRC
> > + *
> > + * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
> > + * @obj_desc_array: array of object descriptors for child objects currently
> > + * present in the DPRC in the MC.
> > + * @num_child_objects_in_mc: number of entries in obj_desc_array
> > + *
> > + * Synchronizes the state of the Linux bus driver with the actual state of
> > + * the MC by removing devices that represent MC objects that have
> > + * been dynamically removed in the physical DPRC.
> > + */
> > +static void dprc_remove_devices(struct fsl_mc_device *mc_bus_dev,
> > +   struct dprc_obj_desc *obj_desc_array,
> > +   int num_child_objects_in_mc)
> > +{
> > +   if (num_child_objects_in_mc != 0) {
> 
> Like here.  Just do "if (num_child_objects_in_mc) {"

This seems to be a place that is testing for zero as a value rather than
as a stand-in for NULL, so I'd argue it's better style to leave it as
is.

-Scott


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

Re: [PATCH 3/3 v2] drivers/bus: Device driver for FSL-MC DPRC devices

[Timur Tabi]

On Fri, Sep 19, 2014 at 5:49 PM, J. German Rivera
 wrote:

> +static int __fsl_mc_device_remove(struct device *dev, void *data)
> +{
> +   WARN_ON(dev == NULL);
> +   WARN_ON(data != NULL);

I see a lot of direct comparisons with NULL and 0.  You don't need to
be so explicit:

WARN_ON(!dev);
WARN_ON(!data);

"!= 0" and "!= NULL" is almost always unnecessary, and you can delete them.


> +   fsl_mc_device_remove(to_fsl_mc_device(dev));
> +   return 0;
> +}
> +
> +/**
> + * dprc_remove_devices - Removes devices for objects removed from a DPRC
> + *
> + * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
> + * @obj_desc_array: array of object descriptors for child objects currently
> + * present in the DPRC in the MC.
> + * @num_child_objects_in_mc: number of entries in obj_desc_array
> + *
> + * Synchronizes the state of the Linux bus driver with the actual state of
> + * the MC by removing devices that represent MC objects that have
> + * been dynamically removed in the physical DPRC.
> + */
> +static void dprc_remove_devices(struct fsl_mc_device *mc_bus_dev,
> +   struct dprc_obj_desc *obj_desc_array,
> +   int num_child_objects_in_mc)
> +{
> +   if (num_child_objects_in_mc != 0) {

Like here.  Just do "if (num_child_objects_in_mc) {"

> +   /*
> +* Remove child objects that are in the DPRC in Linux,
> +* but not in the MC:
> +*/
> +   struct dprc_child_objs objs;
> +
> +   objs.child_count = num_child_objects_in_mc;
> +   objs.child_array = obj_desc_array;
> +   device_for_each_child(_bus_dev->dev, ,
> + __fsl_mc_device_remove_if_not_in_mc);
> +   } else {
> +   /*
> +* There are no child objects for this DPRC in the MC.
> +* So, remove all the child devices from Linux:
> +*/
> +   device_for_each_child(_bus_dev->dev, NULL,
> + __fsl_mc_device_remove);
> +   }
> +}
> +
> +static int __fsl_mc_device_match(struct device *dev, void *data)
> +{
> +   struct dprc_obj_desc *obj_desc = data;
> +   struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
> +
> +   return FSL_MC_DEVICE_MATCH(mc_dev, obj_desc);
> +}
> +
> +static struct fsl_mc_device *fsl_mc_device_lookup(struct dprc_obj_desc
> +   *obj_desc,
> + struct fsl_mc_device
> +   *mc_bus_dev)
> +{
> +   struct device *dev;
> +
> +   dev = device_find_child(_bus_dev->dev, obj_desc,
> +   __fsl_mc_device_match);
> +
> +   return (dev != NULL) ? to_fsl_mc_device(dev) : NULL;

return dev ? to_fsl_mc_device(dev) : NULL;

> +}
> +
> +/**
> + * dprc_add_new_devices - Adds devices to the logical bus for a DPRC
> + *
> + * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
> + * @obj_desc_array: array of device descriptors for child devices currently
> + * present in the physical DPRC.
> + * @num_child_objects_in_mc: number of entries in obj_desc_array
> + *
> + * Synchronizes the state of the Linux bus driver with the actual
> + * state of the MC by adding objects that have been newly discovered
> + * in the physical DPRC.
> + */
> +static void dprc_add_new_devices(struct fsl_mc_device *mc_bus_dev,
> +struct dprc_obj_desc *obj_desc_array,
> +int num_child_objects_in_mc)
> +{
> +   int error;
> +   int i;
> +
> +   for (i = 0; i < num_child_objects_in_mc; i++) {
> +   struct dprc_region_desc region_desc;
> +   struct fsl_mc_device *child_dev;
> +   struct fsl_mc_io *mc_io = NULL;
> +   struct dprc_obj_desc *obj_desc = _desc_array[i];
> +
> +   if (strlen(obj_desc->type) == 0)
> +   continue;
> +   /*
> +* Check if device is already known to Linux:
> +*/
> +   child_dev = fsl_mc_device_lookup(obj_desc, mc_bus_dev);
> +   if (child_dev != NULL)
> +   continue;
> +
> +   if (strcmp(obj_desc->type, "dprc") == 0) {

As for the !=0 thing, I make an exception for strcmp(), however, since
its meaning is not intuitive.

> +   /*
> +* Get the MC portal physical address for the device
> +* (specified in the device's first MMIO region):
> +*/
> +   if (WARN_ON(obj_desc->region_count == 0))
> +   continue;
> +
> +   error = dprc_get_obj_region(mc_bus_dev->mc_io,
> +   

Re: Re: [hw_breakpoint] WARNING: at kernel/trace/trace_kprobe.c:1393 kprobe_trace_self_tests_init()

[Masami Hiramatsu]

(2014/10/01 2:58), Oleg Nesterov wrote:
> Hi Fengguang,
> 
> On 09/30, Fengguang Wu wrote:
>>
>> Hi Oleg,
>>
>> 0day kernel testing robot got the below dmesg and the first bad commit is
>>
>> commit 8b4d801b2b123b6c09742f861fe44a8527b84d47
>> Author: Oleg Nesterov 
>> AuthorDate: Thu Jun 20 17:50:06 2013 +0200
>> Commit: Ingo Molnar 
>> CommitDate: Thu Jun 20 17:57:00 2013 +0200
>>
>> hw_breakpoint: Fix cpu check in task_bp_pinned(cpu)
>>
>> trinity fuzzer triggered WARN_ONCE("Can't find any breakpoint
>> slot") in arch_install_hw_breakpoint() but the problem is not
>> arch-specific.
>>
>> The problem is, task_bp_pinned(cpu) checks "cpu == iter->cpu"
>> but this doesn't account the "all cpus" events with iter->cpu <
>> 0.
>>
>> This means that, say, register_user_hw_breakpoint(tsk) can
>> happily create the arbitrary number > HBP_NUM of breakpoints
>> which can not be activated. toggle_bp_task_slot() is equally
>> wrong by the same reason and nr_task_bp_pinned[] can have
>> negative entries.
>>
>> Simple test:
>>
>>  # perl -e 'sleep 1 while 1' &
>>  # perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10,mem:0x10 -p `pidof 
>> perl`
>>
>> Before this patch this triggers the same problem/WARN_ON(),
>> after the patch it correctly fails with -ENOSPC.
>>
>> Reported-by: Vince Weaver 
>> Signed-off-by: Oleg Nesterov 
>> Acked-by: Frederic Weisbecker 
>> Cc: 
>> Link: http://lkml.kernel.org/r/20130620155006.ga6...@redhat.com
>> Signed-off-by: Ingo Molnar 
>>
>> +---+++--+
>> |   | 
>> 003002e04e | 8b4d801b2b | v3.17-rc7_093000 |
>> +---+++--+
>> | boot_successes| 60 
>> | 0  | 0|
>> | boot_failures | 0  
>> | 20 | 11   |
>> | WARNING:at_kernel/trace/trace_kprobe.c:kprobe_trace_self_tests_init() | 0  
>> | 20 | 11   |
>> | backtrace:kprobe_trace_self_tests_init| 0  
>> | 20 | 11   |
>> | backtrace:warn_slowpath_null  | 0  
>> | 20 | 11   |
>> | backtrace:kernel_init_freeable| 0  
>> | 20 | 11   |
>> +---+++--+
>>
>> [4.188679] Testing kprobe tracing:
>> [4.189810] Could not insert probe at kprobe_trace_selftest_target+0: -22
> 
> __register_trace_kprobe() fails.
> 
> No, I am very sure this can't be caused by the commit above. If nothing else,
> task_bp_pinned() changed by this commit is not even called in this case.

Uh, right. I'm trying to reproduce this to analyze...

Anyway, I'd like to remove the whole of kprobe_trace selftest from the
kernel binary. Instead of that, we already have ftracetest scripts.
We can run the test after the kernel booted.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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] bq27x00_battery: Fix flag reading for bq27742

[Sebastian Reichel]

Hi,

On Tue, Sep 30, 2014 at 11:18:56AM -0700, Puthikorn Voravootivat wrote:
> This patch fix the following issues.
> - Flag for bq27742 is 2 bytes contracy to 1 byte for older hardware
> - Don't read FLAG_CI as bq27742 does not have it
> - Use Battery full capacity register as last measure discharge
> 
> Signed-off-by: Puthikorn Voravootivat 
> Reviewed-by: Benson Leung 

http://git.infradead.org/battery-2.6.git/commit/a3c0c3e79066c78b890c078998c8c6bd577f1d21

-- Sebastian


signature.asc
Description: Digital signature

[PATCH v3 15/15] misc: at25: Add ACPI probing support

[Rafael J. Wysocki]

From: Mika Westerberg 

Add support for matching using DT compatible string from ACPI _DSD.

Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---
drivers/misc/eeprom/at25.c | 7 +++
 drivers/misc/eeprom/at25.c |7 +++
 1 file changed, 7 insertions(+)

Index: linux-pm/drivers/misc/eeprom/at25.c
===
--- linux-pm.orig/drivers/misc/eeprom/at25.c
+++ linux-pm/drivers/misc/eeprom/at25.c
@@ -459,11 +459,18 @@ static const struct of_device_id at25_of
 };
 MODULE_DEVICE_TABLE(of, at25_of_match);
 
+static const struct acpi_device_id at25_acpi_match[] = {
+   { "PRP0001" },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, at25_acpi_match);
+
 static struct spi_driver at25_driver = {
.driver = {
.name   = "at25",
.owner  = THIS_MODULE,
.of_match_table = at25_of_match,
+   .acpi_match_table = at25_acpi_match,
},
.probe  = at25_probe,
.remove = at25_remove,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/15] input: gpio_keys_polled - Add ACPI probing support

[Rafael J. Wysocki]

From: Mika Westerberg 

Allow the driver to probe from ACPI namespace.

Signed-off-by: Aaron Lu 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/input/keyboard/gpio_keys_polled.c |7 +++
 1 file changed, 7 insertions(+)

Index: linux-pm/drivers/input/keyboard/gpio_keys_polled.c
===
--- linux-pm.orig/drivers/input/keyboard/gpio_keys_polled.c
+++ linux-pm/drivers/input/keyboard/gpio_keys_polled.c
@@ -181,6 +181,12 @@ static const struct of_device_id gpio_ke
 };
 MODULE_DEVICE_TABLE(of, gpio_keys_polled_of_match);
 
+static const struct acpi_device_id gpio_keys_polled_acpi_match[] = {
+   { "PRP0001" }, /* Device Tree shoehorned into ACPI */
+   { },
+};
+MODULE_DEVICE_TABLE(acpi, gpio_keys_polled_acpi_match);
+
 static int gpio_keys_polled_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -309,6 +315,7 @@ static struct platform_driver gpio_keys_
.name   = DRV_NAME,
.owner  = THIS_MODULE,
.of_match_table = gpio_keys_polled_of_match,
+   .acpi_match_table = gpio_keys_polled_acpi_match,
},
 };
 module_platform_driver(gpio_keys_polled_driver);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/15] input: gpio_keys_polled - Make use of device property API

[Rafael J. Wysocki]

From: Aaron Lu 

Make use of device property API in this driver so that both OF based
system and ACPI based system can use this driver.

Signed-off-by: Aaron Lu 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---

Dmitry, does this look better than the previous one to you?

---
 drivers/input/keyboard/gpio_keys_polled.c |  119 +-
 1 file changed, 52 insertions(+), 67 deletions(-)

Index: linux-pm/drivers/input/keyboard/gpio_keys_polled.c
===
--- linux-pm.orig/drivers/input/keyboard/gpio_keys_polled.c
+++ linux-pm/drivers/input/keyboard/gpio_keys_polled.c
@@ -25,9 +25,7 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
+#include 
 
 #define DRV_NAME   "gpio-keys-polled"
 
@@ -102,21 +100,57 @@ static void gpio_keys_polled_close(struc
pdata->disable(bdev->dev);
 }
 
-#ifdef CONFIG_OF
+static int gpio_keys_polled_get_button(struct device *dev, void *child,
+  void *data)
+{
+   struct gpio_keys_platform_data *pdata = data;
+   struct gpio_keys_button *button;
+   struct gpio_desc *desc;
+
+   desc = devm_get_named_gpiod_from_child(dev, child, "gpios", 0);
+   if (IS_ERR(desc)) {
+   int err = PTR_ERR(desc);
+
+   if (err != -EPROBE_DEFER)
+   dev_err(dev, "Failed to get gpio flags, error: %d\n",
+   err);
+   return err;
+   }
+
+   button = >buttons[pdata->nbuttons++];
+   button->gpiod = desc;
+
+   if (device_child_property_read_u32(dev, child, "linux,code",
+  >code)) {
+   dev_err(dev, "Button without keycode: %d\n",
+   pdata->nbuttons - 1);
+   return -EINVAL;
+   }
+
+   device_child_property_read_string(dev, child, "label", >desc);
+
+   if (device_child_property_read_u32(dev, child, "linux,input-type",
+  >type))
+   button->type = EV_KEY;
+
+   button->wakeup = !device_get_child_property(dev, child,
+   "gpio-key,wakeup", NULL);
+
+   if (device_child_property_read_u32(dev, child, "debounce-interval",
+  >debounce_interval))
+   button->debounce_interval = 5;
+
+   return 0;
+}
+
 static struct gpio_keys_platform_data 
*gpio_keys_polled_get_devtree_pdata(struct device *dev)
 {
-   struct device_node *node, *pp;
struct gpio_keys_platform_data *pdata;
struct gpio_keys_button *button;
int error;
int nbuttons;
-   int i;
-
-   node = dev->of_node;
-   if (!node)
-   return NULL;
 
-   nbuttons = of_get_child_count(node);
+   nbuttons = device_get_child_node_count(dev);
if (nbuttons == 0)
return NULL;
 
@@ -126,54 +160,14 @@ static struct gpio_keys_platform_data *g
return ERR_PTR(-ENOMEM);
 
pdata->buttons = (struct gpio_keys_button *)(pdata + 1);
-   pdata->nbuttons = nbuttons;
 
-   pdata->rep = !!of_get_property(node, "autorepeat", NULL);
-   of_property_read_u32(node, "poll-interval", >poll_interval);
+   pdata->rep = !device_get_property(dev, "autorepeat", NULL);
+   device_property_read_u32(dev, "poll-interval", >poll_interval);
 
-   i = 0;
-   for_each_child_of_node(node, pp) {
-   int gpio;
-   enum of_gpio_flags flags;
-
-   if (!of_find_property(pp, "gpios", NULL)) {
-   pdata->nbuttons--;
-   dev_warn(dev, "Found button without gpios\n");
-   continue;
-   }
-
-   gpio = of_get_gpio_flags(pp, 0, );
-   if (gpio < 0) {
-   error = gpio;
-   if (error != -EPROBE_DEFER)
-   dev_err(dev,
-   "Failed to get gpio flags, error: %d\n",
-   error);
-   return ERR_PTR(error);
-   }
-
-   button = >buttons[i++];
-
-   button->gpio = gpio;
-   button->active_low = flags & OF_GPIO_ACTIVE_LOW;
-
-   if (of_property_read_u32(pp, "linux,code", >code)) {
-   dev_err(dev, "Button without keycode: 0x%x\n",
-   button->gpio);
-   return ERR_PTR(-EINVAL);
-   }
-
-   button->desc = of_get_property(pp, "label", NULL);
-
-   if (of_property_read_u32(pp, "linux,input-type", >type))
-   button->type = EV_KEY;
-
-   button->wakeup = !!of_get_property(pp, "gpio-key,wakeup", NULL);
-
-   if (of_property_read_u32(pp, 

[PATCH v3 14/15] misc: at25: Make use of device property API

[Rafael J. Wysocki]

From: Mika Westerberg 

Make use of device property API in this driver so that both DT and ACPI
based systems can use this driver.

Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/misc/eeprom/at25.c | 34 +-
 1 file changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c
index 634f72929e12..58f6cdd2551c 100644
--- a/drivers/misc/eeprom/at25.c
+++ b/drivers/misc/eeprom/at25.c
@@ -18,7 +18,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 /*
  * NOTE: this is an *EEPROM* driver.  The vagaries of product naming
@@ -301,35 +301,33 @@ static ssize_t at25_mem_write(struct memory_accessor 
*mem, const char *buf,
 
 /*-*/
 
-static int at25_np_to_chip(struct device *dev,
-  struct device_node *np,
-  struct spi_eeprom *chip)
+static int at25_fw_to_chip(struct device *dev, struct spi_eeprom *chip)
 {
u32 val;
 
memset(chip, 0, sizeof(*chip));
-   strncpy(chip->name, np->name, sizeof(chip->name));
+   strncpy(chip->name, "at25", sizeof(chip->name));
 
-   if (of_property_read_u32(np, "size", ) == 0 ||
-   of_property_read_u32(np, "at25,byte-len", ) == 0) {
+   if (device_property_read_u32(dev, "size", ) == 0 ||
+   device_property_read_u32(dev, "at25,byte-len", ) == 0) {
chip->byte_len = val;
} else {
dev_err(dev, "Error: missing \"size\" property\n");
return -ENODEV;
}
 
-   if (of_property_read_u32(np, "pagesize", ) == 0 ||
-   of_property_read_u32(np, "at25,page-size", ) == 0) {
+   if (device_property_read_u32(dev, "pagesize", ) == 0 ||
+   device_property_read_u32(dev, "at25,page-size", ) == 0) {
chip->page_size = (u16)val;
} else {
dev_err(dev, "Error: missing \"pagesize\" property\n");
return -ENODEV;
}
 
-   if (of_property_read_u32(np, "at25,addr-mode", ) == 0) {
+   if (device_property_read_u32(dev, "at25,addr-mode", ) == 0) {
chip->flags = (u16)val;
} else {
-   if (of_property_read_u32(np, "address-width", )) {
+   if (device_property_read_u32(dev, "address-width", )) {
dev_err(dev,
"Error: missing \"address-width\" property\n");
return -ENODEV;
@@ -350,7 +348,7 @@ static int at25_np_to_chip(struct device *dev,
val);
return -ENODEV;
}
-   if (of_find_property(np, "read-only", NULL))
+   if (!device_get_property(dev, "read-only", NULL))
chip->flags |= EE_READONLY;
}
return 0;
@@ -360,21 +358,15 @@ static int at25_probe(struct spi_device *spi)
 {
struct at25_data*at25 = NULL;
struct spi_eeprom   chip;
-   struct device_node  *np = spi->dev.of_node;
int err;
int sr;
int addrlen;
 
/* Chip description */
if (!spi->dev.platform_data) {
-   if (np) {
-   err = at25_np_to_chip(>dev, np, );
-   if (err)
-   return err;
-   } else {
-   dev_err(>dev, "Error: no chip description\n");
-   return -ENODEV;
-   }
+   err = at25_fw_to_chip(>dev, );
+   if (err)
+   return err;
} else
chip = *(struct spi_eeprom *)spi->dev.platform_data;
 
-- 
1.8.4.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 v3 11/15] input: gpio_keys_polled - Add support for GPIO descriptors

[Rafael J. Wysocki]

From: Aaron Lu 

GPIO descriptors are the preferred way over legacy GPIO numbers
nowadays. Convert the driver to use GPIO descriptors internally but
still allow passing legacy GPIO numbers from platform data to support
existing platforms.

Signed-off-by: Aaron Lu 
Signed-off-by: Mika Westerberg 
Acked-by: Alexandre Courbot 
Reviewed-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/input/keyboard/gpio_keys_polled.c | 39 +--
 include/linux/gpio_keys.h |  3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/input/keyboard/gpio_keys_polled.c 
b/drivers/input/keyboard/gpio_keys_polled.c
index 432d36395f35..b7a514ced509 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,15 +52,14 @@ static void gpio_keys_polled_check_state(struct input_dev 
*input,
int state;
 
if (bdata->can_sleep)
-   state = !!gpio_get_value_cansleep(button->gpio);
+   state = !!gpiod_get_value_cansleep(button->gpiod);
else
-   state = !!gpio_get_value(button->gpio);
+   state = !!gpiod_get_value(button->gpiod);
 
if (state != bdata->last_state) {
unsigned int type = button->type ?: EV_KEY;
 
-   input_event(input, type, button->code,
-   !!(state ^ button->active_low));
+   input_event(input, type, button->code, state);
input_sync(input);
bdata->count = 0;
bdata->last_state = state;
@@ -259,7 +259,6 @@ static int gpio_keys_polled_probe(struct platform_device 
*pdev)
for (i = 0; i < pdata->nbuttons; i++) {
struct gpio_keys_button *button = >buttons[i];
struct gpio_keys_button_data *bdata = >data[i];
-   unsigned int gpio = button->gpio;
unsigned int type = button->type ?: EV_KEY;
 
if (button->wakeup) {
@@ -267,15 +266,31 @@ static int gpio_keys_polled_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
-   error = devm_gpio_request_one(>dev, gpio, GPIOF_IN,
- button->desc ? : DRV_NAME);
-   if (error) {
-   dev_err(dev, "unable to claim gpio %u, err=%d\n",
-   gpio, error);
-   return error;
+   /*
+* Legacy GPIO number so request the GPIO here and
+* convert it to descriptor.
+*/
+   if (!button->gpiod && gpio_is_valid(button->gpio)) {
+   unsigned flags = 0;
+
+   if (button->active_low)
+   flags |= GPIOF_ACTIVE_LOW;
+
+   error = devm_gpio_request_one(>dev, button->gpio,
+   flags, button->desc ? : DRV_NAME);
+   if (error) {
+   dev_err(dev, "unable to claim gpio %u, 
err=%d\n",
+   button->gpio, error);
+   return error;
+   }
+
+   button->gpiod = gpio_to_desc(button->gpio);
}
 
-   bdata->can_sleep = gpio_cansleep(gpio);
+   if (IS_ERR(button->gpiod))
+   return PTR_ERR(button->gpiod);
+
+   bdata->can_sleep = gpiod_cansleep(button->gpiod);
bdata->last_state = -1;
bdata->threshold = DIV_ROUND_UP(button->debounce_interval,
pdata->poll_interval);
diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h
index 8b622468952c..ee2d8c6f9130 100644
--- a/include/linux/gpio_keys.h
+++ b/include/linux/gpio_keys.h
@@ -2,6 +2,7 @@
 #define _GPIO_KEYS_H
 
 struct device;
+struct gpio_desc;
 
 /**
  * struct gpio_keys_button - configuration parameters
@@ -17,6 +18,7 @@ struct device;
  * disable button via sysfs
  * @value: axis value for %EV_ABS
  * @irq:   Irq number in case of interrupt keys
+ * @gpiod: GPIO descriptor
  */
 struct gpio_keys_button {
unsigned int code;
@@ -29,6 +31,7 @@ struct gpio_keys_button {
bool can_disable;
int value;
unsigned int irq;
+   struct gpio_desc *gpiod;
 };
 
 /**
-- 
1.8.4.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 v3 09/15] leds: leds-gpio: Make use of device property API

[Rafael J. Wysocki]

From: Max Eliaser 

Make use of device property API in this driver so that both OF and ACPI
based system can use the same driver.

Signed-off-by: Max Eliaser 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/leds/leds-gpio.c |   99 +++
 1 file changed, 42 insertions(+), 57 deletions(-)

Index: linux-pm/drivers/leds/leds-gpio.c
===
--- linux-pm.orig/drivers/leds/leds-gpio.c
+++ linux-pm/drivers/leds/leds-gpio.c
@@ -15,13 +15,11 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 struct gpio_led_data {
struct led_classdev cdev;
@@ -171,65 +169,59 @@ static inline int sizeof_gpio_leds_priv(
(sizeof(struct gpio_led_data) * num_leds);
 }
 
-/* Code to create from OpenFirmware platform devices */
-#ifdef CONFIG_OF_GPIO
-static struct gpio_leds_priv *gpio_leds_create_of(struct platform_device *pdev)
+static int gpio_leds_create_led(struct device *dev, void *child, void *data)
+{
+   struct gpio_leds_priv *priv = data;
+   struct gpio_led led = {};
+   const char *state = NULL;
+
+   led.gpiod = devm_get_named_gpiod_from_child(dev, child, "gpios", 0);
+   if (IS_ERR(led.gpiod))
+   return PTR_ERR(led.gpiod);
+
+   device_child_property_read_string(dev, child, "label", );
+   device_child_property_read_string(dev, child, "linux,default-trigger",
+ _trigger);
+
+   device_child_property_read_string(dev, child, "linux,default_state",
+ );
+   if (state) {
+   if (!strcmp(state, "keep"))
+   led.default_state = LEDS_GPIO_DEFSTATE_KEEP;
+   else if (!strcmp(state, "on"))
+   led.default_state = LEDS_GPIO_DEFSTATE_ON;
+   else
+   led.default_state = LEDS_GPIO_DEFSTATE_OFF;
+   }
+
+   if (!device_get_child_property(dev, child, "retain-state-suspended", 
NULL))
+   led.retain_state_suspended = 1;
+
+   return create_gpio_led(, >leds[priv->num_leds++], dev, NULL);
+}
+
+static struct gpio_leds_priv *gpio_leds_create(struct platform_device *pdev)
 {
-   struct device_node *np = pdev->dev.of_node, *child;
struct gpio_leds_priv *priv;
-   int count, ret;
+   int ret, count;
 
-   /* count LEDs in this device, so we know how much to allocate */
-   count = of_get_available_child_count(np);
+   count = device_get_child_node_count(>dev);
if (!count)
return ERR_PTR(-ENODEV);
 
-   for_each_available_child_of_node(np, child)
-   if (of_get_gpio(child, 0) == -EPROBE_DEFER)
-   return ERR_PTR(-EPROBE_DEFER);
-
priv = devm_kzalloc(>dev, sizeof_gpio_leds_priv(count),
GFP_KERNEL);
if (!priv)
return ERR_PTR(-ENOMEM);
 
-   for_each_available_child_of_node(np, child) {
-   struct gpio_led led = {};
-   enum of_gpio_flags flags;
-   const char *state;
-
-   led.gpio = of_get_gpio_flags(child, 0, );
-   led.active_low = flags & OF_GPIO_ACTIVE_LOW;
-   led.name = of_get_property(child, "label", NULL) ? : 
child->name;
-   led.default_trigger =
-   of_get_property(child, "linux,default-trigger", NULL);
-   state = of_get_property(child, "default-state", NULL);
-   if (state) {
-   if (!strcmp(state, "keep"))
-   led.default_state = LEDS_GPIO_DEFSTATE_KEEP;
-   else if (!strcmp(state, "on"))
-   led.default_state = LEDS_GPIO_DEFSTATE_ON;
-   else
-   led.default_state = LEDS_GPIO_DEFSTATE_OFF;
-   }
-
-   if (of_get_property(child, "retain-state-suspended", NULL))
-   led.retain_state_suspended = 1;
-
-   ret = create_gpio_led(, >leds[priv->num_leds++],
- >dev, NULL);
-   if (ret < 0) {
-   of_node_put(child);
-   goto err;
-   }
+   ret = device_for_each_child_node(>dev, gpio_leds_create_led, 
priv);
+   if (ret) {
+   for (count = priv->num_leds - 2; count >= 0; count--)
+   delete_gpio_led(>leds[count]);
+   return ERR_PTR(ret);
}
 
return priv;
-
-err:
-   for (count = priv->num_leds - 2; count >= 0; count--)
-   delete_gpio_led(>leds[count]);
-   return ERR_PTR(-ENODEV);
 }
 
 static const struct of_device_id of_gpio_leds_match[] = {
@@ -238,13 +230,6 @@ static const struct of_device_id of_gpio
 };
 
 

[PATCH v3 04/15] ACPI: Document ACPI device specific properties

[Rafael J. Wysocki]

From: Mika Westerberg 

This document describes the data format and interfaces of ACPI device
specific properties.

Signed-off-by: Mika Westerberg 
Signed-off-by: Darren Hart 
Signed-off-by: Rafael J. Wysocki 
---
 Documentation/acpi/properties.txt | 410 ++
 1 file changed, 410 insertions(+)
 create mode 100644 Documentation/acpi/properties.txt

diff --git a/Documentation/acpi/properties.txt 
b/Documentation/acpi/properties.txt
new file mode 100644
index 000..13a93c5
--- /dev/null
+++ b/Documentation/acpi/properties.txt
@@ -0,0 +1,410 @@
+ACPI device properties
+==
+This document describes the format and interfaces of ACPI device
+properties as specified in "Device Properties UUID For _DSD" available
+here:
+
+http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
+
+1. Introduction
+---
+In systems that use ACPI and want to take advantage of device specific
+properties, there needs to be a standard way to return and extract
+name-value pairs for a given ACPI device.
+
+An ACPI device that wants to export its properties must implement a
+static name called _DSD that takes no arguments and returns a package of
+packages:
+
+   Name (_DSD, Package () {
+   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+   Package () {
+   Package () {"name1", },
+   Package () {"name2", }
+   }
+   })
+
+The UUID identifies contents of the following package. In case of ACPI
+device properties it is daffd814-6eba-4d8c-8a91-bc9bbf4aa301.
+
+In each returned package, the first item is the name and must be a string.
+The corresponding value can be a string, integer, reference, or package. If
+a package it may only contain strings, integers, and references.
+
+An example device where we might need properties is a device that uses
+GPIOs. In addition to the GpioIo/GpioInt resources the driver needs to
+know which GPIO is used for which purpose.
+
+To solve this we add the following ACPI device properties to the device:
+
+   Device (DEV0)
+   {
+   Name (_CRS, ResourceTemplate () {
+   GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
+   "\\_SB.PCI0.LPC", 0, ResourceConsumer) {0}
+   GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
+   "\\_SB.PCI0.LPC", 0, ResourceConsumer) {1}
+   ...
+   })
+
+   Name (_DSD, Package () {
+   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+   Package () {
+   Package () {"reset-gpio", {^DEV0, 0, 0, 0}},
+   Package () {"shutdown-gpio", {^DEV0, 1, 0, 0}},
+   }
+   })
+   }
+
+Now the device driver can reference the GPIOs using names instead of
+using indexes.
+
+If there is an existing Device Tree binding for a device, it is expected
+that the same bindings are used with ACPI properties, so that the driver
+dealing with the device needs only minor modifications if any.
+
+2. Formal definition of properties
+--
+The following chapters define the currently supported properties. For
+these there exists a helper function that can be used to extract the
+property value.
+
+2.1 Integer types
+-
+ACPI integers are always 64-bit. However, for drivers the full range is
+typically not needed so we provide a set of functions which convert the
+64-bit integer to a smaller Linux integer type.
+
+An integer property looks like this:
+
+   Package () {"i2c-sda-hold-time-ns", 300},
+   Package () {"clock-frequency", 40},
+
+To read a property value, use a unified property accessor as shown
+below:
+
+   u32 val;
+   int ret;
+
+   ret = device_property_read_u32(dev, "clock-frequency", );
+   if (ret)
+   /* Handle error */
+
+The function returns 0 if the property is copied to 'val' or negative
+errno if something went wrong (or the property does not exist).
+
+2.2 Integer arrays
+--
+An integer array is a package holding only integers. Arrays can be used to
+represent different things like Linux input key codes to GPIO mappings, pin
+control settings, dma request lines, etc.
+
+An integer array looks like this:
+
+   Package () {
+   "max8952,dvs-mode-microvolt",
+   Package () {
+   125,
+   120,
+   105,
+   95,
+   }
+   }
+
+The above array property can be accessed like:
+
+   u32 voltages[4];
+   int ret;
+
+   ret = device_property_read_u32_array(dev, "max8952,dvs-mode-microvolt",
+voltages, ARRAY_SIZE(voltages));
+   if 

[PATCH v3 06/15] gpio: Support for unified device properties interface

[Rafael J. Wysocki]

From: Mika Westerberg 

Some drivers need to deal with only firmware representation of its
GPIOs. An example would be a GPIO button array driver where each button
is described as a separate firmware node in device tree. Typically these
child nodes do not have physical representation in the Linux device
model.

In order to help device drivers to handle such firmware child nodes we
add dev[m]_get_named_gpiod_from_child() that takes a child firmware
node pointer as its second argument (the first one is the parent device
itself), finds the GPIO using whatever is the underlying firmware
method, and requests the GPIO properly.

Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---

Linus, does this look better than the previous one to you?

---
 drivers/gpio/devres.c |   34 +
 drivers/gpio/gpiolib.c|   56 ++
 include/linux/gpio/consumer.h |5 +++
 3 files changed, 95 insertions(+)

Index: linux-pm/drivers/gpio/devres.c
===
--- linux-pm.orig/drivers/gpio/devres.c
+++ linux-pm/drivers/gpio/devres.c
@@ -109,6 +109,40 @@ struct gpio_desc *__must_check __devm_gp
 EXPORT_SYMBOL(__devm_gpiod_get_index);
 
 /**
+ * devm_get_named_gpiod_from_child - managed dev_get_named_gpiod_from_child()
+ * @dev:   GPIO consumer
+ * @child: firmware node (child of @dev)
+ * @propname:  name of the firmware property
+ * @index: index of the GPIO in the property value in case of many
+ *
+ * GPIO descriptors returned from this function are automatically disposed on
+ * driver detach.
+ */
+struct gpio_desc *devm_get_named_gpiod_from_child(struct device *dev, void 
*child,
+ const char *propname, int 
index)
+{
+   struct gpio_desc **dr;
+   struct gpio_desc *desc;
+
+   dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
+ GFP_KERNEL);
+   if (!dr)
+   return ERR_PTR(-ENOMEM);
+
+   desc = dev_get_named_gpiod_from_child(dev, child, propname, index);
+   if (IS_ERR(desc)) {
+   devres_free(dr);
+   return desc;
+   }
+
+   *dr = desc;
+   devres_add(dev, dr);
+
+   return desc;
+}
+EXPORT_SYMBOL(devm_get_named_gpiod_from_child);
+
+/**
  * devm_gpiod_get_index_optional - Resource-managed gpiod_get_index_optional()
  * @dev: GPIO consumer
  * @con_id: function within the GPIO consumer
Index: linux-pm/drivers/gpio/gpiolib.c
===
--- linux-pm.orig/drivers/gpio/gpiolib.c
+++ linux-pm/drivers/gpio/gpiolib.c
@@ -1717,6 +1717,62 @@ struct gpio_desc *__must_check __gpiod_g
 EXPORT_SYMBOL_GPL(__gpiod_get_index);
 
 /**
+ * dev_get_named_gpiod_from_child - obtain a GPIO from firmware node
+ * @dev:   parent device
+ * @child: firmware node (child of @dev)
+ * @propname:  name of the firmware property
+ * @idx:   index of the GPIO in the property value in case of many
+ *
+ * This function can be used for drivers that get their configuration
+ * from firmware in such a way that some properties are described as child
+ * nodes for the parent device in DT or ACPI.
+ *
+ * Function properly finds the corresponding GPIO using whatever is the
+ * underlying firmware interface and then makes sure that the GPIO
+ * descriptor is requested before it is returned to the caller.
+ *
+ * In case of error an ERR_PTR() is returned.
+ */
+struct gpio_desc *dev_get_named_gpiod_from_child(struct device *dev, void 
*child,
+const char *propname, int 
index)
+{
+   struct gpio_desc *desc = ERR_PTR(-ENODEV);
+   bool active_low = false;
+   int ret;
+
+   if (!child)
+   return ERR_PTR(-EINVAL);
+
+   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
+   enum of_gpio_flags flags;
+
+   desc = of_get_named_gpiod_flags(child, propname, index, );
+   if (!IS_ERR(desc))
+   active_low = flags & OF_GPIO_ACTIVE_LOW;
+   } else if (ACPI_COMPANION(dev)) {
+   struct acpi_gpio_info info;
+
+   desc = acpi_get_gpiod_by_index(child, propname, index, );
+   if (!IS_ERR(desc))
+   active_low = info.active_low;
+   }
+
+   if (IS_ERR(desc))
+   return desc;
+
+   ret = gpiod_request(desc, NULL);
+   if (ret)
+   return ERR_PTR(ret);
+
+   /* Only value flag can be set from both DT and ACPI is active_low */
+   if (active_low)
+   set_bit(FLAG_ACTIVE_LOW, >flags);
+
+   return desc;
+}
+EXPORT_SYMBOL_GPL(dev_get_named_gpiod_from_child);
+
+/**
  * gpiod_get_index_optional - obtain an optional GPIO from a multi-index GPIO
  *function
  * @dev: GPIO consumer, can be NULL for system-global GPIOs
Index: 

[PATCH v3 05/15] gpio / ACPI: Add support for _DSD device properties

[Rafael J. Wysocki]

From: Mika Westerberg 

With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.

With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:

  // Bluetooth device with reset and shutdown GPIOs
  Device (BTH)
  {
  Name (_HID, ...)

  Name (_CRS, ResourceTemplate ()
  {
  GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
  "\\_SB.GPO0", 0, ResourceConsumer) {15}
  GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
  "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
  })

  Name (_DSD, Package ()
  {
  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
  Package ()
  {
  Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
  Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
  }
  })
  }

The format of the supported GPIO property is:

  Package () { "name", Package () { ref, index, pin, active_low }}

  ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
  index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
  pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
  active_low - If 1 the GPIO is marked as active_low.

Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
it to 1 marks the GPIO as active low.

In our Bluetooth example the "reset-gpio" refers to the second GpioIo()
resource, second pin in that resource with the GPIO number of 31.

This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.

Signed-off-by: Mika Westerberg 
Acked-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/gpio/gpiolib-acpi.c |   78 
 drivers/gpio/gpiolib.c  |   30 ++--
 drivers/gpio/gpiolib.h  |7 ++-
 3 files changed, 94 insertions(+), 21 deletions(-)

Index: linux-pm/drivers/gpio/gpiolib-acpi.c
===
--- linux-pm.orig/drivers/gpio/gpiolib-acpi.c
+++ linux-pm/drivers/gpio/gpiolib-acpi.c
@@ -293,6 +293,7 @@ void acpi_gpiochip_free_interrupts(struc
 struct acpi_gpio_lookup {
struct acpi_gpio_info info;
int index;
+   int pin_index;
struct gpio_desc *desc;
int n;
 };
@@ -306,13 +307,24 @@ static int acpi_find_gpio(struct acpi_re
 
if (lookup->n++ == lookup->index && !lookup->desc) {
const struct acpi_resource_gpio *agpio = >data.gpio;
+   int pin_index = lookup->pin_index;
+
+   if (pin_index >= agpio->pin_table_length)
+   return 1;
 
lookup->desc = acpi_get_gpiod(agpio->resource_source.string_ptr,
- agpio->pin_table[0]);
+ agpio->pin_table[pin_index]);
lookup->info.gpioint =
agpio->connection_type == ACPI_RESOURCE_GPIO_TYPE_INT;
-   lookup->info.active_low =
-   agpio->polarity == ACPI_ACTIVE_LOW;
+
+   /*
+* ActiveLow is only specified for GpioInt resource. If
+* GpioIo is used then the only way to set the flag is
+* to use _DSD "gpios" property.
+*/
+   if (lookup->info.gpioint)
+   lookup->info.active_low =
+   agpio->polarity == ACPI_ACTIVE_LOW;
}
 
return 1;
@@ -320,40 +332,75 @@ static int acpi_find_gpio(struct acpi_re
 
 /**
  * acpi_get_gpiod_by_index() - get a GPIO descriptor from device resources
- * @dev: pointer to a device to get GPIO from
+ * @adev: pointer to a ACPI device to get GPIO from
+ * @propname: Property name of the GPIO (optional)
  * @index: index of GpioIo/GpioInt resource (starting from %0)
  * @info: info pointer to fill in (optional)
  *
- * Function goes through ACPI resources for @dev and based on @index looks
+ * Function goes through ACPI resources for @adev and based on @index looks
  * up a GpioIo/GpioInt resource, translates it to the Linux GPIO descriptor,
  * and returns it. @index matches GpioIo/GpioInt resources only so if there
  * are total %3 GPIO resources, the index goes from %0 to %2.
  *
+ * If @propname is specified the GPIO is looked using device property. In
+ * that case @index is used to select the GPIO entry in the property value
+ * (in case of multiple).
+ *
  * If the GPIO cannot be translated or there is an error an ERR_PTR is
  * returned.
  *
  * Note: if the GPIO resource has 

[PATCH v3 07/15] gpio: sch: Consolidate core and resume banks

[Rafael J. Wysocki]

From: Mika Westerberg 

This is actually a single device with two sets of identical registers,
which just happen to start from a different offset. Instead of having
separate GPIO chips created we consolidate them to be single GPIO chip.

In addition having a single GPIO chip allows us to handle ACPI GPIO
translation in the core in a more generic way, since the two GPIO chips
share the same parent ACPI device.

Signed-off-by: Mika Westerberg 
Acked-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/gpio/gpio-sch.c | 293 ++--
 1 file changed, 112 insertions(+), 181 deletions(-)

diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 41e91d70301e..99720c8bc8ed 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -29,290 +29,221 @@
 
 #include 
 
-static DEFINE_SPINLOCK(gpio_lock);
-
-#define CGEN   (0x00)
-#define CGIO   (0x04)
-#define CGLV   (0x08)
-
-#define RGEN   (0x20)
-#define RGIO   (0x24)
-#define RGLV   (0x28)
-
-static unsigned short gpio_ba;
-
-static int sch_gpio_core_direction_in(struct gpio_chip *gc, unsigned  gpio_num)
-{
-   u8 curr_dirs;
-   unsigned short offset, bit;
-
-   spin_lock(_lock);
-
-   offset = CGIO + gpio_num / 8;
-   bit = gpio_num % 8;
-
-   curr_dirs = inb(gpio_ba + offset);
-
-   if (!(curr_dirs & (1 << bit)))
-   outb(curr_dirs | (1 << bit), gpio_ba + offset);
+#define GEN0x00
+#define GIO0x04
+#define GLV0x08
+
+struct sch_gpio {
+   struct gpio_chip chip;
+   spinlock_t lock;
+   unsigned short iobase;
+   unsigned short core_base;
+   unsigned short resume_base;
+};
 
-   spin_unlock(_lock);
-   return 0;
-}
+#define to_sch_gpio(c) container_of(c, struct sch_gpio, chip)
 
-static int sch_gpio_core_get(struct gpio_chip *gc, unsigned gpio_num)
+static unsigned sch_gpio_offset(struct sch_gpio *sch, unsigned gpio,
+   unsigned reg)
 {
-   int res;
-   unsigned short offset, bit;
+   unsigned base = 0;
 
-   offset = CGLV + gpio_num / 8;
-   bit = gpio_num % 8;
+   if (gpio >= sch->resume_base) {
+   gpio -= sch->resume_base;
+   base += 0x20;
+   }
 
-   res = !!(inb(gpio_ba + offset) & (1 << bit));
-   return res;
+   return base + reg + gpio / 8;
 }
 
-static void sch_gpio_core_set(struct gpio_chip *gc, unsigned gpio_num, int val)
+static unsigned sch_gpio_bit(struct sch_gpio *sch, unsigned gpio)
 {
-   u8 curr_vals;
-   unsigned short offset, bit;
-
-   spin_lock(_lock);
-
-   offset = CGLV + gpio_num / 8;
-   bit = gpio_num % 8;
-
-   curr_vals = inb(gpio_ba + offset);
-
-   if (val)
-   outb(curr_vals | (1 << bit), gpio_ba + offset);
-   else
-   outb((curr_vals & ~(1 << bit)), gpio_ba + offset);
-   spin_unlock(_lock);
+   if (gpio >= sch->resume_base)
+   gpio -= sch->resume_base;
+   return gpio % 8;
 }
 
-static int sch_gpio_core_direction_out(struct gpio_chip *gc,
-   unsigned gpio_num, int val)
+static void sch_gpio_enable(struct sch_gpio *sch, unsigned gpio)
 {
-   u8 curr_dirs;
unsigned short offset, bit;
+   u8 enable;
 
-   spin_lock(_lock);
+   spin_lock(>lock);
 
-   offset = CGIO + gpio_num / 8;
-   bit = gpio_num % 8;
-
-   curr_dirs = inb(gpio_ba + offset);
-   if (curr_dirs & (1 << bit))
-   outb(curr_dirs & ~(1 << bit), gpio_ba + offset);
+   offset = sch_gpio_offset(sch, gpio, GEN);
+   bit = sch_gpio_bit(sch, gpio);
 
-   spin_unlock(_lock);
+   enable = inb(sch->iobase + offset);
+   if (!(enable & (1 << bit)))
+   outb(enable | (1 << bit), sch->iobase + offset);
 
-   /*
-* according to the datasheet, writing to the level register has no
-* effect when GPIO is programmed as input.
-* Actually the the level register is read-only when configured as 
input.
-* Thus presetting the output level before switching to output is _NOT_ 
possible.
-* Hence we set the level after configuring the GPIO as output.
-* But we cannot prevent a short low pulse if direction is set to high
-* and an external pull-up is connected.
-*/
-   sch_gpio_core_set(gc, gpio_num, val);
-   return 0;
+   spin_unlock(>lock);
 }
 
-static struct gpio_chip sch_gpio_core = {
-   .label  = "sch_gpio_core",
-   .owner  = THIS_MODULE,
-   .direction_input= sch_gpio_core_direction_in,
-   .get= sch_gpio_core_get,
-   .direction_output   = sch_gpio_core_direction_out,
-   .set= sch_gpio_core_set,
-};
-
-static int sch_gpio_resume_direction_in(struct gpio_chip *gc,
-   unsigned gpio_num)
+static int 

[PATCH v3 03/15] ACPI: Allow drivers to match using Device Tree compatible property

[Rafael J. Wysocki]

From: Mika Westerberg 

We have lots of existing Device Tree enabled drivers and allocating
separate _HID for each is not feasible. Instead we allocate special _HID
"PRP0001" that means that the match should be done using Device Tree
compatible property using driver's .of_match_table instead.

If there is a need to distinguish from where the device is enumerated
(DT/ACPI) driver can check dev->of_node or ACPI_COMPATION(dev).

Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/property.c |   34 +
 drivers/acpi/scan.c |   91 ++--
 include/acpi/acpi_bus.h |1 
 include/linux/acpi.h|8 +---
 4 files changed, 118 insertions(+), 16 deletions(-)

Index: linux-pm/drivers/acpi/property.c
===
--- linux-pm.orig/drivers/acpi/property.c
+++ linux-pm/drivers/acpi/property.c
@@ -76,6 +76,37 @@ static bool acpi_properties_format_valid
return true;
 }
 
+static void acpi_init_of_compatible(struct acpi_device *adev)
+{
+   const union acpi_object *of_compatible;
+   struct acpi_hardware_id *hwid;
+   bool acpi_of = false;
+
+   /*
+* Check if the special PRP0001 ACPI ID is present and in that
+* case we fill in Device Tree compatible properties for this
+* device.
+*/
+   list_for_each_entry(hwid, >pnp.ids, list) {
+   if (!strcmp(hwid->id, "PRP0001")) {
+   acpi_of = true;
+   break;
+   }
+   }
+
+   if (!acpi_of)
+   return;
+
+   if (acpi_dev_get_property_array(adev, "compatible", ACPI_TYPE_STRING,
+   _compatible)) {
+   acpi_handle_warn(adev->handle,
+"PRP0001 requires compatible property\n");
+   return;
+   }
+
+   adev->data.of_compatible = of_compatible;
+}
+
 void acpi_init_properties(struct acpi_device *adev)
 {
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
@@ -119,6 +150,8 @@ void acpi_init_properties(struct acpi_de
 
adev->data.pointer = buf.pointer;
adev->data.properties = properties;
+
+   acpi_init_of_compatible(adev);
return;
}
 
@@ -130,6 +163,7 @@ void acpi_init_properties(struct acpi_de
 void acpi_free_properties(struct acpi_device *adev)
 {
ACPI_FREE((void *)adev->data.pointer);
+   adev->data.of_compatible = NULL;
adev->data.pointer = NULL;
adev->data.properties = NULL;
 }
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -124,17 +124,43 @@ static int create_modalias(struct acpi_d
if (list_empty(_dev->pnp.ids))
return 0;
 
-   len = snprintf(modalias, size, "acpi:");
-   size -= len;
+   /*
+* If the device has PRP0001 we expose DT compatible modalias
+* instead.
+*/
+   if (acpi_dev->data.of_compatible) {
+   const union acpi_object *of_compatible, *obj;
+   int i;
+
+   len = snprintf(modalias, size, "of:Nprp0001Tacpi");
+
+   of_compatible = acpi_dev->data.of_compatible;
+   for (i = 0; i < of_compatible->package.count; i++) {
+   obj = _compatible->package.elements[i];
+
+   count = snprintf([len], size, "C%s",
+obj->string.pointer);
+   if (count < 0)
+   return -EINVAL;
+   if (count >= size)
+   return -ENOMEM;
+
+   len += count;
+   size -= count;
+   }
+   } else {
+   len = snprintf(modalias, size, "acpi:");
+   size -= len;
 
-   list_for_each_entry(id, _dev->pnp.ids, list) {
-   count = snprintf([len], size, "%s:", id->id);
-   if (count < 0)
-   return -EINVAL;
-   if (count >= size)
-   return -ENOMEM;
-   len += count;
-   size -= count;
+   list_for_each_entry(id, _dev->pnp.ids, list) {
+   count = snprintf([len], size, "%s:", id->id);
+   if (count < 0)
+   return -EINVAL;
+   if (count >= size)
+   return -ENOMEM;
+   len += count;
+   size -= count;
+   }
}
 
modalias[len] = '\0';
@@ -864,6 +890,51 @@ int acpi_match_device_ids(struct acpi_de
 }
 EXPORT_SYMBOL(acpi_match_device_ids);
 
+/* Performs match for special "PRP0001" shoehorn ACPI ID */
+static bool 

[PATCH v3 02/15] Driver core: Unified device properties interface for platform firmware

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" 

Add a uniform interface by which device drivers can request device
properties from the platform firmware by providing a property name
and the corresponding data type.  The purpose of it is to help to
write portable code that won't depend on any particular platform
firmware interface.

Three general helper functions, device_get_property(),
device_read_property() and device_read_property_array() are provided.
The first one allows the raw value of a given device property to be
accessed.  The remaining two allow the value of a numeric or string
property and multiple numeric or string values of one array
property to be acquired, respectively.  Static inline wrappers are also
provided for the various property data types that can be passed to
device_read_property() or device_read_property_array() for extra type
checking.

In addition to that, new generic routines are provided for retrieving
properties from device description objects in the platform firmware
in case a device driver needs/wants to access properties of a child
object of a given device object.  There are cases in which there is
no struct device representation of such child objects and this
additional API is useful then.  Again, three functions are provided,
device_get_child_property(), device_read_child_property(),
device_read_child_property_array(), in analogy with device_get_property(),
device_read_property() and device_read_property_array() described above,
respectively, along with static inline wrappers for all of the propery
data types that can be used.  For all of them, the first argument is
a struct device pointer to the parent device object and the second
argument is a (void *) pointer to the child description provided by
the platform firmware (either ACPI or FDT).

Finally, device_for_each_child_node() is added for iterating over
the children of the device description object associated with a
given device.

The interface covers both ACPI and Device Trees.

This change set includes material from Mika Westerberg and Aaron Lu.

Signed-off-by: Aaron Lu 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---

Greg, please let me know if you're fine with this one.

---
 drivers/acpi/property.c  |  188 +
 drivers/base/Makefile|2 
 drivers/base/property.c  |  235 +++
 drivers/of/base.c|  186 +
 include/linux/acpi.h |   42 
 include/linux/of.h   |   37 +++
 include/linux/property.h |  207 +
 7 files changed, 896 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/property.c
 create mode 100644 include/linux/property.h

Index: linux-pm/drivers/acpi/property.c
===
--- linux-pm.orig/drivers/acpi/property.c
+++ linux-pm/drivers/acpi/property.c
@@ -362,3 +362,191 @@ int acpi_dev_get_property_reference(stru
return -EPROTO;
 }
 EXPORT_SYMBOL_GPL(acpi_dev_get_property_reference);
+
+int acpi_dev_prop_get(struct acpi_device *adev, const char *propname,
+ void **valptr)
+{
+   return acpi_dev_get_property(adev, propname, ACPI_TYPE_ANY,
+(const union acpi_object **)valptr);
+}
+
+int acpi_dev_prop_read(struct acpi_device *adev, const char *propname,
+  enum dev_prop_type proptype, void *val)
+{
+   const union acpi_object *obj;
+   int ret = -EINVAL;
+
+   if (!val)
+   return -EINVAL;
+
+   if (proptype >= DEV_PROP_U8 && proptype <= DEV_PROP_U64) {
+   ret = acpi_dev_get_property(adev, propname, ACPI_TYPE_INTEGER, 
);
+   if (ret)
+   return ret;
+
+   switch (proptype) {
+   case DEV_PROP_U8:
+   if (obj->integer.value > U8_MAX)
+   return -EOVERFLOW;
+   *(u8 *)val = obj->integer.value;
+   break;
+   case DEV_PROP_U16:
+   if (obj->integer.value > U16_MAX)
+   return -EOVERFLOW;
+   *(u16 *)val = obj->integer.value;
+   break;
+   case DEV_PROP_U32:
+   if (obj->integer.value > U32_MAX)
+   return -EOVERFLOW;
+   *(u32 *)val = obj->integer.value;
+   break;
+   default:
+   *(u64 *)val = obj->integer.value;
+   break;
+   }
+   } else if (proptype == DEV_PROP_STRING) {
+   ret = acpi_dev_get_property(adev, propname, ACPI_TYPE_STRING, 
);
+   if (ret)
+   return ret;
+
+   *(char **)val = obj->string.pointer;
+   }
+   return ret;
+}
+
+static int 

[PATCH v3 10/15] leds: leds-gpio: Add ACPI probing support

[Rafael J. Wysocki]

From: Max Eliaser 

This allows the driver to probe from ACPI namespace.

Signed-off-by: Max Eliaser 
Signed-off-by: Mika Westerberg 
Acked-by: Bryan Wu 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/leds/leds-gpio.c |8 
 1 file changed, 8 insertions(+)

Index: linux-pm/drivers/leds/leds-gpio.c
===
--- linux-pm.orig/drivers/leds/leds-gpio.c
+++ linux-pm/drivers/leds/leds-gpio.c
@@ -231,6 +231,13 @@ static const struct of_device_id of_gpio
 
 MODULE_DEVICE_TABLE(of, of_gpio_leds_match);
 
+static const struct acpi_device_id acpi_gpio_leds_match[] = {
+   { "PRP0001" }, /* Device Tree shoehorned into ACPI */
+   {},
+};
+
+MODULE_DEVICE_TABLE(acpi, acpi_gpio_leds_match);
+
 static int gpio_led_probe(struct platform_device *pdev)
 {
struct gpio_led_platform_data *pdata = dev_get_platdata(>dev);
@@ -286,6 +293,7 @@ static struct platform_driver gpio_led_d
.name   = "leds-gpio",
.owner  = THIS_MODULE,
.of_match_table = of_gpio_leds_match,
+   .acpi_match_table = acpi_gpio_leds_match,
},
 };
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/15] ACPI: Add support for device specific properties

[Rafael J. Wysocki]

From: Mika Westerberg 

Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.

ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.

In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.

If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:

Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", },
Package () {"name2", },
...
}
})

The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].

We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.

The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.

[1] 
http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] 
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf

Reviewed-by: Hanjun Guo 
Reviewed-by: Josh Triplett 
Signed-off-by: Darren Hart 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/Makefile   |1 
 drivers/acpi/internal.h |6 
 drivers/acpi/property.c |  364 
 drivers/acpi/scan.c |2 
 include/acpi/acpi_bus.h |7 
 include/linux/acpi.h|   40 +
 6 files changed, 420 insertions(+)
 create mode 100644 drivers/acpi/property.c

Index: linux-pm/drivers/acpi/Makefile
===
--- linux-pm.orig/drivers/acpi/Makefile
+++ linux-pm/drivers/acpi/Makefile
@@ -46,6 +46,7 @@ acpi-y+= acpi_pnp.o
 acpi-y += power.o
 acpi-y += event.o
 acpi-y += sysfs.o
+acpi-y += property.o
 acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
 acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
 acpi-$(CONFIG_ACPI_NUMA)   += numa.o
Index: linux-pm/drivers/acpi/internal.h
===
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -181,4 +181,10 @@ struct platform_device *acpi_create_plat
 bool acpi_osi_is_win8(void);
 #endif
 
+/*--
+   Device properties
+  -- */
+void acpi_init_properties(struct acpi_device *adev);
+void acpi_free_properties(struct acpi_device *adev);
+
 #endif /* _ACPI_INTERNAL_H_ */
Index: linux-pm/drivers/acpi/property.c
===
--- /dev/null
+++ linux-pm/drivers/acpi/property.c
@@ -0,0 +1,364 @@
+/*
+ * ACPI device specific properties support.
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * All rights reserved.
+ *
+ * Authors: Mika Westerberg 
+ *  Darren Hart 
+ *  Rafael J. Wysocki 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+#include "internal.h"
+
+/* ACPI _DSD device properties UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 */
+static const u8 prp_uuid[16] = {
+   0x14, 0xd8, 0xff, 0xda, 0xba, 0x6e, 0x8c, 0x4d,
+   0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01
+};
+
+static bool acpi_property_value_ok(const union acpi_object *value)
+{
+   int j;
+
+   /*
+* The value must be an integer, a string, a reference, or a package
+* whose every element must be an integer, a string, or a reference.
+*/
+   switch (value->type) {
+   case ACPI_TYPE_INTEGER:
+   case ACPI_TYPE_STRING:
+   case ACPI_TYPE_LOCAL_REFERENCE:
+  

[PATCH v3 00/15] Add ACPI _DSD and unified device properties support

[Rafael J. Wysocki]

Hi Everyone,

Since Dmitry was suggesting that instead of using struct fw_dev_node pointers,
as we did in the previous version, we could pass the parent device along with
the child pointer to iterator functions while walking the children of a given
device node, the following patches do just that.  Some things look better this
way, but some look worse.  Please tell me what you think.

Mika has tested them on Minnowboard and Minnowboard MAX using the MFD patch
(number 5 previously) that is not included as it has been already applied.

The cover letter below is still applicable mostly, so I'm leaving it as is.

The only patches that changed are [2, 4, 6, 9, 12/15], so I didn't add any
ACKs to them to be prudent.

On Tuesday, September 16, 2014 02:52:31 PM Mika Westerberg wrote:
> This is a second revision of the patches first submitted here [1].
> 
> The recent publication of the ACPI 5.1 specification [2] adds a reserved name
> for Device Specific Data (_DSD, Section 6.2.5). This mechanism allows for
> passing arbitrary hardware description data to the OS. The exact format of the
> _DSD data is specific to the UUID paired with it [3].   
> 
> An ACPI Device Properties UUID has been defined [4] to provide a format
> compatible with existing device tree schemas. The purpose for this was to
> allow for the reuse of the existing schemas and encourage the development
> of firmware agnostic device drivers.
> 
> This series accomplishes the following (as well as some other dependencies):
> 
>  * Add _DSD support to the ACPI core
>This simply reads the UUID and the accompanying Package
> 
>  * Add ACPI Device Properties _DSD format support
>This understands the hierarchical key:value pair structure
>defined by the Device Properties UUID
> 
>  * Add a unified device properties API with ACPI and OF backends
>This provides for the firmware agnostic device properties
>Interface to be used by drivers
> 
>  * Provides 3 example drivers that were previously Device Tree aware that
>can now be used with either Device Tree or ACPI Device Properties. The
>drivers use "PRP0001" as their _HID which means that the match should be
>done using driver's .of_match_table instead.
> 
> The patch series has been tested on Minnoboard and Minnowboard MAX and the
> relevant part of DSDTs are at the end of this cover letter.
> 
> This series does not provide for a means to append to a system DSDT. That
> will ultimately be required to make the most effective use of the _DSD
> mechanism. Work is underway on that as a separate effort.
> 
> Most important changes to the previous RFC version:
> 
>   * Added wrapper functions for most used property types
>   * Return -EOVERFLOW in case integer would not fit to a type
>   * Dropped dev_prop_ops
>   * We now have dev_node_xxx() functions to access firmware node
> properties without dev pointer
>   * The accessor function names try to be close to their corresponding of_*
> counterpart
>   * Tried to have a bit better examples in the documentation patch
>   * gpiolib got support for _DSD and also it now understand firmware node
> properties with dev_node_get_named_gpiod() that requests the GPIO
> properly.
>   * Support for "PRP0001" _HID/_CID. This means that the match should be
> done using driver .of_match_table instead.
>   * Add unified property support for at25 SPI eeprom driver as well.
> 
> [1] https://lkml.org/lkml/2014/8/17/10
> [2] http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf
> [3] 
> http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> [4] 
> http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
> 
> Aaron Lu (2):
>   input: gpio_keys_polled - Add support for GPIO descriptors
>   input: gpio_keys_polled - Make use of device property API
> 
> Max Eliaser (2):
>   leds: leds-gpio: Make use of device property API
>   leds: leds-gpio: Add ACPI probing support
> 
> Mika Westerberg (11):
>   ACPI: Add support for device specific properties
>   ACPI: Allow drivers to match using Device Tree compatible property
>   ACPI: Document ACPI device specific properties
>   mfd: Add ACPI support
>   gpio / ACPI: Add support for _DSD device properties
>   gpio: Add support for unified device properties interface
>   gpio: sch: Consolidate core and resume banks
>   leds: leds-gpio: Add support for GPIO descriptors
>   input: gpio_keys_polled - Add ACPI probing support
>   misc: at25: Make use of device property API
>   misc: at25: Add ACPI probing support
> 
> Rafael J. Wysocki (1):
>   Driver core: Unified device properties interface for platform firmware
> 
>  Documentation/acpi/enumeration.txt|  27 ++
>  Documentation/acpi/properties.txt | 410 +
>  drivers/acpi/Makefile |   1 +
>  drivers/acpi/internal.h   |   6 +
>  drivers/acpi/property.c   | 584 
> 

[PATCH v3 08/15] leds: leds-gpio: Add support for GPIO descriptors

[Rafael J. Wysocki]

From: Mika Westerberg 

GPIO descriptors are the preferred way over legacy GPIO numbers
nowadays. Convert the driver to use GPIO descriptors internally but
still allow passing legacy GPIO numbers from platform data to support
existing platforms.

Signed-off-by: Mika Westerberg 
Acked-by: Alexandre Courbot 
Acked-by: Bryan Wu 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/leds/leds-gpio.c | 80 +++-
 include/linux/leds.h |  1 +
 2 files changed, 46 insertions(+), 35 deletions(-)

diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index 57ff20fecf57..c84e913527f0 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,11 +25,10 @@
 
 struct gpio_led_data {
struct led_classdev cdev;
-   unsigned gpio;
+   struct gpio_desc *gpiod;
struct work_struct work;
u8 new_level;
u8 can_sleep;
-   u8 active_low;
u8 blinking;
int (*platform_gpio_blink_set)(unsigned gpio, int state,
unsigned long *delay_on, unsigned long *delay_off);
@@ -40,12 +40,16 @@ static void gpio_led_work(struct work_struct *work)
container_of(work, struct gpio_led_data, work);
 
if (led_dat->blinking) {
-   led_dat->platform_gpio_blink_set(led_dat->gpio,
-led_dat->new_level,
-NULL, NULL);
+   int gpio = desc_to_gpio(led_dat->gpiod);
+   int level = led_dat->new_level;
+
+   if (gpiod_is_active_low(led_dat->gpiod))
+   level = !level;
+
+   led_dat->platform_gpio_blink_set(gpio, level, NULL, NULL);
led_dat->blinking = 0;
} else
-   gpio_set_value_cansleep(led_dat->gpio, led_dat->new_level);
+   gpiod_set_value_cansleep(led_dat->gpiod, led_dat->new_level);
 }
 
 static void gpio_led_set(struct led_classdev *led_cdev,
@@ -60,9 +64,6 @@ static void gpio_led_set(struct led_classdev *led_cdev,
else
level = 1;
 
-   if (led_dat->active_low)
-   level = !level;
-
/* Setting GPIOs with I2C/etc requires a task context, and we don't
 * seem to have a reliable way to know if we're already in one; so
 * let's just assume the worst.
@@ -72,11 +73,16 @@ static void gpio_led_set(struct led_classdev *led_cdev,
schedule_work(_dat->work);
} else {
if (led_dat->blinking) {
-   led_dat->platform_gpio_blink_set(led_dat->gpio, level,
-NULL, NULL);
+   int gpio = desc_to_gpio(led_dat->gpiod);
+
+   if (gpiod_is_active_low(led_dat->gpiod))
+   level = !level;
+
+   led_dat->platform_gpio_blink_set(gpio, level, NULL,
+NULL);
led_dat->blinking = 0;
} else
-   gpio_set_value(led_dat->gpio, level);
+   gpiod_set_value(led_dat->gpiod, level);
}
 }
 
@@ -85,9 +91,10 @@ static int gpio_blink_set(struct led_classdev *led_cdev,
 {
struct gpio_led_data *led_dat =
container_of(led_cdev, struct gpio_led_data, cdev);
+   int gpio = desc_to_gpio(led_dat->gpiod);
 
led_dat->blinking = 1;
-   return led_dat->platform_gpio_blink_set(led_dat->gpio, GPIO_LED_BLINK,
+   return led_dat->platform_gpio_blink_set(gpio, GPIO_LED_BLINK,
delay_on, delay_off);
 }
 
@@ -97,24 +104,33 @@ static int create_gpio_led(const struct gpio_led *template,
 {
int ret, state;
 
-   led_dat->gpio = -1;
+   if (!template->gpiod) {
+   unsigned long flags = 0;
 
-   /* skip leds that aren't available */
-   if (!gpio_is_valid(template->gpio)) {
-   dev_info(parent, "Skipping unavailable LED gpio %d (%s)\n",
-   template->gpio, template->name);
-   return 0;
-   }
+   /* skip leds that aren't available */
+   if (!gpio_is_valid(template->gpio)) {
+   dev_info(parent, "Skipping unavailable LED gpio %d 
(%s)\n",
+   template->gpio, template->name);
+   return 0;
+   }
 
-   ret = devm_gpio_request(parent, template->gpio, template->name);
-   if (ret < 0)
-   return ret;
+   if (template->active_low)
+   flags |= GPIOF_ACTIVE_LOW;
+
+   ret = devm_gpio_request_one(parent, template->gpio, flags,
+   template->name);
+

Re: [PATCH v5] init: Disable defaults if init= fails

[Frank Rowand]

On 9/30/2014 5:58 PM, Rob Landley wrote:
> On 09/30/14 19:41, Frank Rowand wrote:
>> The earliest mention I find of this on lkml is v4.  Was there earlier
>> discussion of this elsewhere?  (Just so I have a clue as to the full
>> context and don't repeat previous discussion.)  The mention of names
>> in the change logs tells me I should be able to find the discussion
>> somewhere.
> 
> The previous ones had a different topic sentence (add strictinit). So
> they added code to do less.

Thanks!  That gives me the context I was looking for.

For posterity and anyone searching in the future, the previous
threads were:

   [PATCH ...] init: Add strictinit to disable init= fallbacks

> 
>> On 9/28/2014 7:40 PM, Andy Lutomirski wrote:
>>> If a user puts init=/whatever on the command line and /whatever
>>> can't be run, then the kernel will try a few default options before
>>> giving up.  If init=/whatever came from a bootloader prompt, then
>>> this is unexpected but probably harmless.  On the other hand, if it
>>> comes from a script (e.g. a tool like virtme or perhaps a future
>>> kselftest script), then the fallbacks are likely to exist, but
>>> they'll do the wrong thing.  For example, they might unexpectedly
>>> invoke systemd.
>>>
>>> This makes a failure to run the specified init= process be fatal.
>>>
>>> As a temporary measure, users can set CONFIG_INIT_FALLBACK=y to
>>> preserve the old behavior.  If no one speaks up, we can remove that
>>> option entirely after a release or two.
>>
>> I'm speaking up already, no need to wait two releases.  I like the
>> current behavior where I can fall back into a shell without
>> recompiling the kernel and/or changing the boot command line to
>> debug an init failure.
>>
>> I would suggest that the current behavior remain the
>> default and the choice to make a failure of the specified
>> init= process fatal should be an explicit choice.
> 
> Oh please no. Having to switch kernel configuration entries _on_ in
> order to switch behavior _off_ is how you get nonsense like
> allnoconfig_y which breaks miniconfig, why is why I patch it back out
> locally:
> 
> http://landley.net/hg/aboriginal/file/1672/sources/patches/linux-deeplystupid.patch
> 
> If you're going to argue that it should "default y", that's a defensible
> choice. But please don't argue for kernel config symbols with a negative
> meaning or we'll start having allyesconfig_n brain damage too...

Yes, "default y" is a valid answer to my request.

> 
>> Instead of using a config option, would adding another kernel
>> command line option, such as 'init_fail_is_fatal', work for
>> your needs?
> 
> That was the previous series of patches you ignored, which added code so
> you can provide _extra_ kernel commands to tell it _not_ to do stuff.
> The patches did not generate noticeable enthusiasm.

But there also was not a strong push back either.  Just Chuck's suggestion
of an alternate syntax, and your suggestion of instead using a config
option (and possibly immediately deprecating the config option).

You could as easily frame the argument that the added code was to
tell the kernel to "_do_ stuff" (panic) instead of "_not_ do stuff".
But that is just semantics on my part; whatever.

I thought the general trend was to try to avoid adding config options.
The strictinit method seems fine to me.


>> I have a feeling this has already been proposed,
>> as the 'strictinit' option mentioned in the changes from v3
>> below might be the same concept?
> 
> That was it, yes.
> 
> Having to get your kernel config right (and your kernel command line
> right) in order for your system to boot is not really a new concept, is
> it? You can still specify "init=/bin/sh" if you want that. (I do it all
> the time when I need to edit a system I haven't bothered to look up the
> root password to.)

Yes, of course I can.  So it falls back to personal preference (as I said,
I like that some failed boots will drop into a shell without having to
change the kernel command line).

-Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/5] enhance DMA CMA on x86

[Peter Hurley]

On 09/30/2014 07:45 PM, Thomas Gleixner wrote:
> Whether the proposed patchset is the correct solution to support it is
> a completely different question.

This patchset has been in mainline since 3.16 and has already caused
regressions, so the question of whether this is the correct solution has
already been answered.

> So either you stop this right now and help Akinobu to find the proper
> solution 

If this is only a test platform for ARM parts then I don't think it
unreasonable to suggest forking x86 swiotlb support into a iommu=cma
selector that gets DMA mapping working for this test platform and doesn't
cause a bunch of breakage.

Which is different than if the plan is to ship production units for x86;
then a general purpose solution will be required.

As to the good design of a general purpose solution for allocating and
mapping huge order pages, you are certainly more qualified to help Akinobu
than I am.

Regards,
Peter Hurley

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

Re: [PATCH v2 3/3] toshiba_acpi: Change HCI/SCI functions return code type

[Rafael J. Wysocki]

On Tuesday, September 30, 2014 01:58:14 PM Darren Hart wrote:
> On Mon, Sep 29, 2014 at 08:40:09PM -0600, Azael Avalos wrote:
> > Currently the HCI/SCI read/write functions are returning
> > the status of the ACPI call and also assigning the
> > returned value of the HCI/SCI function, however, only
> > the HCI/SCI status is being checked.
> > 
> > This patch changes such functions, returning the value
> > of the HCI/SCI function instead of the ACPI call status,
> > eliminating one parameter, and returning something
> > useful that indeed is being checked.
> > 
> > Signed-off-by: Azael Avalos 
> 
> Cc linux-acpi
> 
> Rafael,
> 
> This follows a couple patches renaming interfaces and error codes. While
> there is some information to be had in checking for ACPI specific errors, I
> don't think it's significant to warrant asking Azael to go the other way and
> check for them specifically and add errorcodes to the interface rather than
> cleanup the functionality as it stands today and simplifiy the code as he does
> here.
> 
> Any objection?

Nope.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v2, 1/4] powerpc/perf/hv-24x7: use kmem_cache instead of aligned stack allocations

[Michael Ellerman]

On Wed, 2014-24-09 at 19:24:38 UTC, suka...@linux.vnet.ibm.com wrote:
> From: Cody P Schafer 
> 
> Ian pointed out the use of __aligned(4096) caused rather large stack
> consumption in single_24x7_request(), so use the kmem_cache
> hv_page_cache (which we've already got set up for other allocations)
> insead of allocating locally.
> 
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index 70d4f74..2f2215c 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -294,7 +294,7 @@ static unsigned long single_24x7_request(u8 domain, u32 
> offset, u16 ix,
>u16 lpar, u64 *res,
>bool success_expected)
>  {
> - unsigned long ret;
> + unsigned long ret = -ENOMEM;
>  
>   /*
>* request_buffer and result_buffer are not required to be 4k aligned,
> @@ -304,7 +304,27 @@ static unsigned long single_24x7_request(u8 domain, u32 
> offset, u16 ix,
>   struct reqb {
>   struct hv_24x7_request_buffer buf;
>   struct hv_24x7_request req;
> - } __packed __aligned(4096) request_buffer = {
> + } __packed * request_buffer;

No space after the * please.

> + struct resb {

You never use the struct name so this can be anonymous, eg:

struct {
struct hv_24x7_data_result_buffer buf;
...

> + struct hv_24x7_data_result_buffer buf;
> + struct hv_24x7_result res;
> + struct hv_24x7_result_element elem;
> + __be64 result;
> + } __packed * result_buffer;

No space again.

> + BUILD_BUG_ON(sizeof(*request_buffer) > 4096);
> + BUILD_BUG_ON(sizeof(*result_buffer) > 4096);
> +
> + request_buffer = kmem_cache_alloc(hv_page_cache, GFP_USER);

Why aren't we using kzalloc here?

It looks like we're initialising everything below except the reserved fields,
but are they allowed to be non-zero? It's probably safer to just kzalloc it.

> + if (!request_buffer)
> + goto out_reqb;

If prefer labels to be named for what they do, so this would be just "out".

> +
> + result_buffer = kmem_cache_zalloc(hv_page_cache, GFP_USER);
> + if (!result_buffer)
> + goto out_resb;

And this would be "out_free_request_buffer".

> +
> + *request_buffer = (struct reqb) {
>   .buf = {
>   .interface_version = HV_24X7_IF_VERSION_CURRENT,
>   .num_requests = 1,
> @@ -320,28 +340,30 @@ static unsigned long single_24x7_request(u8 domain, u32 
> offset, u16 ix,
>   }
>   };
>  
> - struct resb {
> - struct hv_24x7_data_result_buffer buf;
> - struct hv_24x7_result res;
> - struct hv_24x7_result_element elem;
> - __be64 result;
> - } __packed __aligned(4096) result_buffer = {};
> -
>   ret = plpar_hcall_norets(H_GET_24X7_DATA,
> - virt_to_phys(_buffer), sizeof(request_buffer),
> - virt_to_phys(_buffer),  sizeof(result_buffer));
> + virt_to_phys(request_buffer), sizeof(*request_buffer),
> + virt_to_phys(result_buffer),  sizeof(*result_buffer));
>  
>   if (ret) {
>   if (success_expected)
>   pr_err_ratelimited("hcall failed: %d %#x %#x %d => 
> 0x%lx (%ld) detail=0x%x failing ix=%x\n",
>   domain, offset, ix, lpar,
>   ret, ret,
> - result_buffer.buf.detailed_rc,
> - result_buffer.buf.failing_request_ix);
> - return ret;
> + result_buffer->buf.detailed_rc,
> + result_buffer->buf.failing_request_ix);
> + goto out_hcall;
>   }
>  
> - *res = be64_to_cpu(result_buffer.result);
> + *res = be64_to_cpu(result_buffer->result);
> + kfree(result_buffer);
> + kfree(request_buffer);
> + return ret;
> +
> +out_hcall:
> + kfree(result_buffer);
> +out_resb:
> + kfree(request_buffer);
> +out_reqb:
>   return ret;
>  }

Wouldn't this be better as:

*res = be64_to_cpu(result_buffer->result);

out_free_result_buffer:
kfree(result_buffer);
out_free_request_buffer:
kfree(request_buffer);
out:
return ret;
}


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

linux-next: manual merge of the net-next tree with the berlin tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
arch/arm/boot/dts/berlin2q-marvell-dmp.dts between commit 461316fca705
("ARM: berlin: enable the eSATA interface on the BG2Q DMP") from the
berlin tree and commit 75215193b975 ("ARM: dts: berlin: enable the
Ethernet port on the BG2Q DMP") from the net-next tree.

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

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

diff --cc arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index 1958cbfe61fa,ea1f99b8eed6..
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@@ -46,10 -46,6 +46,14 @@@
status = "okay";
  };
  
 + {
 +  status = "okay";
 +};
 +
 +_phy {
 +  status = "okay";
 +};
++
+  {
+   status = "okay";
+ };


signature.asc
Description: PGP signature

RE: [PATCH V1] regulator: DA9211 : Fix a bug in update of mask bit

[Opensource [James Seong-Won Ban]]

On Tuesday, September 30, 2014 9:45 PM Mark Brown wrote:

> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Tuesday, September 30, 2014 9:45 PM
> To: Opensource [James Seong-Won Ban]
> Cc: Liam Girdwood; Support Opensource; LKML; David Dajun Chen
> Subject: Re: [PATCH V1] regulator: DA9211 : Fix a bug in update of mask bit
> 
> On Mon, Sep 29, 2014 at 04:59:20PM +0900, James Ban wrote:
> > This is a patch for fixing a bug about mask bit operation.
> 
> Applied, but please try to make sure that your changelogs are more
> descriptive - what is the bug?  Please also use subject lines matching
> the style for the subsystem.
The proper operation of mask bit should be set as '0' for enabling the 
interrupt.
The result of mask operation at previous code was the same to new one.
But the meaning in the previous code was to set mask bit as '1'.
What is subject line you said?
If you give me an example, it would be very helpful to me.

Regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v2,2/4] Simplify catalog_read()

[Sukadev Bhattiprolu]

Michael Ellerman [m...@ellerman.id.au] wrote:
| > @@ -203,6 +125,7 @@ static ssize_t catalog_read(struct file *filp, struct 
kobject *kobj,
| >  
| > page_offset = offset / 4096;
| > page_count  = count  / 4096;
| 
| I don't see where page_count is used.

Yes, I will remove it.

| 
| > +   offset_in_page = count % 4096;
| 
| Shouldn't offset_in_page be based on offset ?

Yes. I will fix that.

Thanks,

Sukadev

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] init: Disable defaults if init= fails

[Rob Landley]

On 09/30/14 19:41, Frank Rowand wrote:
> The earliest mention I find of this on lkml is v4.  Was there earlier
> discussion of this elsewhere?  (Just so I have a clue as to the full
> context and don't repeat previous discussion.)  The mention of names
> in the change logs tells me I should be able to find the discussion
> somewhere.

The previous ones had a different topic sentence (add strictinit). So
they added code to do less.

> On 9/28/2014 7:40 PM, Andy Lutomirski wrote:
>> If a user puts init=/whatever on the command line and /whatever
>> can't be run, then the kernel will try a few default options before
>> giving up.  If init=/whatever came from a bootloader prompt, then
>> this is unexpected but probably harmless.  On the other hand, if it
>> comes from a script (e.g. a tool like virtme or perhaps a future
>> kselftest script), then the fallbacks are likely to exist, but
>> they'll do the wrong thing.  For example, they might unexpectedly
>> invoke systemd.
>>
>> This makes a failure to run the specified init= process be fatal.
>>
>> As a temporary measure, users can set CONFIG_INIT_FALLBACK=y to
>> preserve the old behavior.  If no one speaks up, we can remove that
>> option entirely after a release or two.
> 
> I'm speaking up already, no need to wait two releases.  I like the
> current behavior where I can fall back into a shell without
> recompiling the kernel and/or changing the boot command line to
> debug an init failure.
> 
> I would suggest that the current behavior remain the
> default and the choice to make a failure of the specified
> init= process fatal should be an explicit choice.

Oh please no. Having to switch kernel configuration entries _on_ in
order to switch behavior _off_ is how you get nonsense like
allnoconfig_y which breaks miniconfig, why is why I patch it back out
locally:

http://landley.net/hg/aboriginal/file/1672/sources/patches/linux-deeplystupid.patch

If you're going to argue that it should "default y", that's a defensible
choice. But please don't argue for kernel config symbols with a negative
meaning or we'll start having allyesconfig_n brain damage too...

> Instead of using a config option, would adding another kernel
> command line option, such as 'init_fail_is_fatal', work for
> your needs?

That was the previous series of patches you ignored, which added code so
you can provide _extra_ kernel commands to tell it _not_ to do stuff.
The patches did not generate noticeable enthusiasm.

> I have a feeling this has already been proposed,
> as the 'strictinit' option mentioned in the changes from v3
> below might be the same concept?

That was it, yes.

Having to get your kernel config right (and your kernel command line
right) in order for your system to boot is not really a new concept, is
it? You can still specify "init=/bin/sh" if you want that. (I do it all
the time when I need to edit a system I haven't bothered to look up the
root password to.)

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: uid=0 inside user-namespace and procfs file permissions

[Aditya Kali]

On Tue, Sep 30, 2014 at 5:35 PM, Eric W. Biederman
 wrote:
> Aditya Kali  writes:
>
>> Hi all,
>>
>> I am trying to run a process with uid=0 inside userns. But in the when
>> I also do capset() after setresuid(0, 0, 0), I am seeing inconsistent
>> proc file permissions. Almost all the files in /proc// has global
>> 'root' as owner and group even if the actual process uid is correctly
>> changed.
>>
>> I wrote a simple program that demonstrate the issue:
>>
>> 1. parent, as global root (uid=0 in init_user_ns) fork()s a child
>> 2. child:
>> a) unshare(CLONE_NEWUSER)
>> b) [wait for parent to write uid_map]
>> c) setresgid(id, id, id) ; setresuid(0, 0, 0);
>> d) conditionally call capset() to clear capabilities
>> e) execve(/bin/sleep)
>> 3. parent:
>> a) populates child's uid_map and maps some uid to 0 inside userns. ex:
>> 0 99 1
>> b) waitpid()
>>
>> (the actual program can be found at http://pastebin.com/f4P17VFn for
>> your reference).
>>
>> When there is no capset() call after setresuid(0,0,0), everything is
>> fine. But when I do a capset() to clear all capabilities, the 'owner'
>> and 'group' of all the files under /proc//  of the child
>> process are reverted to global 'root' user.
>>
>> # without capset (2.d):
>> root@vm1# id
>> uid=0(root) gid=0(root) groups=0(root)
>>
>> root@vm1# ./userns_uid0
>> child_pid: 24277
>> proc_file: /proc/24277/uid_map
>> proc_file: /proc/24277/gid_map
>> child resuming
>>
>> ^Z
>> [1]+  Stopped ./userns_uid0
>> root@vm1# cat /proc/24277/uid_map
>>  0 99  1
>> root@vm1# cat /proc/24277/status | grep -e "Uid:" -e "Gid:"
>> Uid: 99 99 99 99
>> Gid: 99 99 99 99
>> root@vm1# ls -l /proc/24277/
>> total 0
>> dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:31 attr
>> -r 1 nobody nobody 0 2014-09-30 16:31 auxv
>> -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cgroup
>> --w--- 1 nobody nobody 0 2014-09-30 16:31 clear_refs
>> -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cmdline
>> -rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 comm
>> -rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 coredump_filter
>> -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cpuset
>> ...
>> [All files have owner='nobody' and group='nobody' .. same as that of
>> the process]
>>
>> With the additional capset() call, the files under /proc//
>> are now owned by global root:
>>
>> root@vm1# ./userns_uid0 resetcaps
>> child_pid: 24706
>> proc_file: /proc/24706/uid_map
>> proc_file: /proc/24706/gid_map
>> child resuming
>> resetting caps
>> ^Z
>> [2]+  Stopped ./userns_uid0 resetcaps
>> root@vm1# cat /proc/24706/uid_map
>>  0 99  1
>> root@vm1# cat /proc/24706/status | grep -e "Uid:" -e "Gid:"
>> Uid: 99 99 99 99
>> Gid: 99 99 99 99
>>
>> [Everything as before till now]
>>
>> root@vm1# ls -l /proc/24706/
>> total 0
>> dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:47 attr
>> -r 1 root   root   0 2014-09-30 16:47 auxv
>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 cgroup
>> --w--- 1 root   root   0 2014-09-30 16:47 clear_refs
>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 cmdline
>> -rw-r--r-- 1 root   root   0 2014-09-30 16:47 comm
>> -rw-r--r-- 1 root   root   0 2014-09-30 16:47 coredump_filter
>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 cpuset
>> ...
>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 mountinfo
>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 mounts
>> -r 1 root   root   0 2014-09-30 16:47 mountstats
>> dr-xr-xr-x 5 nobody nobody 0 2014-09-30 16:47 net
>> dr-x--x--x 2 root   root   0 2014-09-30 16:47 ns
>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 numa_maps
>> ...
>> -r--r--r-- 1 root   root   0 2014-09-30 16:47 status
>> -r 1 root   root   0 2014-09-30 16:47 syscall
>> dr-xr-xr-x 3 nobody nobody 0 2014-09-30 16:47 task
>> ..
>>
>> Only the directories 'attr', 'net' and 'task' are owned by the uid=99.
>> Rest all files are owned by global root.
>>
>> This behavior seems inconsistent. I ran this on 3.17 kernel. Can
>> someone with expertise in this area explain if this is expected?
>
> So I am not quite certain what you are seeing.
>
> In general proc files are expected to be owned by the euid of a process.
> However when the task_dumpable is cleared the files become owned by the
> global root user.  We have considered relaxing that to the namespace
> root user but so far implementing a more granular task_dumpable has not
> been done.
>

I tried explicitly setting PR_SET_DUMPABLE before execve(), but that
didn't either.

> The directories are world readable so they don't matter.
>
> What puzzles me is that you have directories owned by nobody, and you
> are talking about uid = 99 and gid = 99.  Nobody is traditionally
> (u16_t)-2 and there should never actually be used by anyone.   And is
> used as the default number of unmapped uids and gids.
>
> It looks like you are doing something weird with nobody so I don't have
> a clue what is actually 

Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500

[Scott Wood]

On Tue, 2014-09-30 at 08:50 -0700, Guenter Roeck wrote:
> On Mon, Sep 29, 2014 at 06:31:06PM -0500, Scott Wood wrote:
> > On Mon, 2014-09-29 at 23:03 +, Jojy Varghese wrote:
> > > 
> > > On 9/29/14 12:06 PM, "Guenter Roeck"  wrote:
> > > 
> > > >Those are errors related to PCIe hotplug, and are seen with unexpected
> > > >PCIe
> > > >device removals (triggered, for example, by removing power from a PCIe
> > > >adapter).
> > > >The behavior we see on E5500 is quite similar to the same behavior on
> > > >E500:
> > > >If unhandled, the CPU keeps executing the same instruction over and over
> > > >again
> > > >if there is an error on a PCIe access and thus stalls. I don't know if
> > > >this
> > > >is considered an erratum or expected behavior, but it is one we have to
> > > >address
> > > >since we have to be able to handle that condition. 
> > 
> > The reason I ask is that the handling for e500 was described as an
> > erratum workaround.  If it is an erratum it would be nice to know the
> > erratum number and the full list of affected chips.
> > 
> My understanding, which may be wrong, was that this is expected behavior,
> at least for E5500. I actually thought I had seen it somewhere in the
> specification (response to PCIe errors), but I don't recall where exactly.
> 
> At least for my part I am not aware of an erratum.

Jia Hongtao, can you comment here?

> > > >Ultimately, we'll want
> > > >to
> > > >implement PCIe error handlers for the affected drivers, but that will be
> > > >a next
> > > >step.
> > 
> > For now can we at least print a ratelimited error message?  I don't like
> > the idea of silently ignoring these errors.  I suppose it's a separate
> > issue from extending the workaround to cover e500mc, though.
> > 
> I don't really like the idea of printing an error message pretty much each 
> time
> when an unexpected hotplug event occurs.

Unexpected events seem like the sort of thing you'd want to log, but my
concern is that this might not be the only cause of PCI errors.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] init: Disable defaults if init= fails

[Frank Rowand]

The earliest mention I find of this on lkml is v4.  Was there earlier
discussion of this elsewhere?  (Just so I have a clue as to the full
context and don't repeat previous discussion.)  The mention of names
in the change logs tells me I should be able to find the discussion
somewhere.


On 9/28/2014 7:40 PM, Andy Lutomirski wrote:
> If a user puts init=/whatever on the command line and /whatever
> can't be run, then the kernel will try a few default options before
> giving up.  If init=/whatever came from a bootloader prompt, then
> this is unexpected but probably harmless.  On the other hand, if it
> comes from a script (e.g. a tool like virtme or perhaps a future
> kselftest script), then the fallbacks are likely to exist, but
> they'll do the wrong thing.  For example, they might unexpectedly
> invoke systemd.
> 
> This makes a failure to run the specified init= process be fatal.
> 
> As a temporary measure, users can set CONFIG_INIT_FALLBACK=y to
> preserve the old behavior.  If no one speaks up, we can remove that
> option entirely after a release or two.

I'm speaking up already, no need to wait two releases.  I like the
current behavior where I can fall back into a shell without
recompiling the kernel and/or changing the boot command line to
debug an init failure.

I would suggest that the current behavior remain the
default and the choice to make a failure of the specified
init= process fatal should be an explicit choice.

Instead of using a config option, would adding another kernel
command line option, such as 'init_fail_is_fatal', work for
your needs?  I have a feeling this has already been proposed,
as the 'strictinit' option mentioned in the changes from v3
below might be the same concept?

Thanks,

Frank

> 
> Signed-off-by: Andy Lutomirski 
> ---
> 
> Changes from v4:
>  - Update the panic message (sorry for the noise)
> 
> Changes from v3:
>  - Get rid of the strictinit option.  Now the new behavior is the default
>unless CONFIG_INIT_FALLBACK=y (Rob Landley)
> 
> Changes from v2:
>  - Improve docs further, to leave the door open to giving strictinit
>some sensible semantics if init= is not set.
>  - Improve error output in the failure case (Shuah Khan).
> 
> Changes from v1:
>  - Add missing "if" to the docs (Randy Dunlap)
> 
>  init/Kconfig | 11 +++
>  init/main.c  |  7 ++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index e84c6423a2e5..063029a1556f 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1299,6 +1299,17 @@ source "usr/Kconfig"
>  
>  endif
>  
> +config INIT_FALLBACK
> + bool "Fall back to defaults if init= parameter is bad"
> + help
> +   If enabled, the kernel will try the default init binaries if an
> +   explicit request from the init= parameter fails.
> +
> +   This is a temporary measure to allow broken configurations
> +   to continue to boot.
> +
> +   If unsure, say N.
> +
>  config CC_OPTIMIZE_FOR_SIZE
>   bool "Optimize for size"
>   help
> diff --git a/init/main.c b/init/main.c
> index bb1aed928f21..2bd6105e5dc5 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -960,8 +960,13 @@ static int __ref kernel_init(void *unused)
>   ret = run_init_process(execute_command);
>   if (!ret)
>   return 0;
> +#ifndef CONFIG_INIT_FALLBACK
> + panic("Requested init %s failed (error %d).",
> +   execute_command, ret);
> +#else
>   pr_err("Failed to execute %s (error %d).  Attempting 
> defaults...\n",
> - execute_command, ret);
> +execute_command, ret);
> +#endif
>   }
>   if (!try_to_run_init_process("/sbin/init") ||
>   !try_to_run_init_process("/etc/init") ||
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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,entry: Filter RFLAGS.NT on entry from userspace

[Andy Lutomirski]

On Tue, Sep 30, 2014 at 5:27 PM, Chuck Ebbert  wrote:
> On Tue, 30 Sep 2014 12:40:35 -0700
> Andy Lutomirski  wrote:
>
>> The NT flag doesn't do anything in long mode other than causing IRET
>> to #GP.  Oddly, CPL3 code can still net NT using popf.
>>
>> Entry via hardware or software interrupt clears NT automatically, so
>> the only relevant entries are fast syscalls.
>>
>> This patch programs the CPU to clear NT on entry via SYSCALL (both
>> 32-bit and 64-bit, by my reading of the AMD APM).  It also clears NT
>> (and some other flags) in software on SYSENTER.
>>
>> I haven't touched anything on 32-bit kernels.
>>
>> If user code causes kernel code to run with NT set, then there's at
>> least some (small) chance that it could cause trouble.  For example,
>> user code could cause a call to EFI code with NT set, and who knows
>> what would happen.  Apparently Wine sometimes does this (!), and, if
>> an IRET return happens, Wine will segfault.
>>
>> I think that Wine should be fixed to stop setting NT when a syscall
>> happens, but handling NT more gracefully is still nice.
>>
>> The syscall mask change comes from a variant of this patch by Anish
>> Bhatt.
>>
>> Cc: sta...@kernel.org
>> Reported-by: Anish Bhatt 
>> Signed-off-by: Andy Lutomirski 
>> ---
>>  arch/x86/ia32/ia32entry.S| 10 +-
>>  arch/x86/kernel/cpu/common.c |  2 +-
>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
>> index 4299eb05023c..079f42a7ad58 100644
>> --- a/arch/x86/ia32/ia32entry.S
>> +++ b/arch/x86/ia32/ia32entry.S
>> @@ -143,7 +143,15 @@ ENTRY(ia32_sysenter_target)
>>   pushq_cfi %r10
>>   CFI_REL_OFFSET rip,0
>>   pushq_cfi %rax
>> - cld
>> +
>> + /*
>> +  * Sysenter doesn't filter flags, so we should filter them
>> +  * ourselves.
>> +  */
>> + pushfq_cfi
>> + andl 
>> $~(X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_NT|X86_EFLAGS_IOPL),(%rsp)
>> + popfq_cfi
>
> Can't you just push a constant and pop that onto flags instead? It's
> not like we care what's in there on entry to the kernel.

I don't see why not.  I'll test on Xen just to be sure.

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

Re: uid=0 inside user-namespace and procfs file permissions

[Eric W. Biederman]

Aditya Kali  writes:

> Hi all,
>
> I am trying to run a process with uid=0 inside userns. But in the when
> I also do capset() after setresuid(0, 0, 0), I am seeing inconsistent
> proc file permissions. Almost all the files in /proc// has global
> 'root' as owner and group even if the actual process uid is correctly
> changed.
>
> I wrote a simple program that demonstrate the issue:
>
> 1. parent, as global root (uid=0 in init_user_ns) fork()s a child
> 2. child:
> a) unshare(CLONE_NEWUSER)
> b) [wait for parent to write uid_map]
> c) setresgid(id, id, id) ; setresuid(0, 0, 0);
> d) conditionally call capset() to clear capabilities
> e) execve(/bin/sleep)
> 3. parent:
> a) populates child's uid_map and maps some uid to 0 inside userns. ex:
> 0 99 1
> b) waitpid()
>
> (the actual program can be found at http://pastebin.com/f4P17VFn for
> your reference).
>
> When there is no capset() call after setresuid(0,0,0), everything is
> fine. But when I do a capset() to clear all capabilities, the 'owner'
> and 'group' of all the files under /proc//  of the child
> process are reverted to global 'root' user.
>
> # without capset (2.d):
> root@vm1# id
> uid=0(root) gid=0(root) groups=0(root)
>
> root@vm1# ./userns_uid0
> child_pid: 24277
> proc_file: /proc/24277/uid_map
> proc_file: /proc/24277/gid_map
> child resuming
>
> ^Z
> [1]+  Stopped ./userns_uid0
> root@vm1# cat /proc/24277/uid_map
>  0 99  1
> root@vm1# cat /proc/24277/status | grep -e "Uid:" -e "Gid:"
> Uid: 99 99 99 99
> Gid: 99 99 99 99
> root@vm1# ls -l /proc/24277/
> total 0
> dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:31 attr
> -r 1 nobody nobody 0 2014-09-30 16:31 auxv
> -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cgroup
> --w--- 1 nobody nobody 0 2014-09-30 16:31 clear_refs
> -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cmdline
> -rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 comm
> -rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 coredump_filter
> -r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cpuset
> ...
> [All files have owner='nobody' and group='nobody' .. same as that of
> the process]
>
> With the additional capset() call, the files under /proc//
> are now owned by global root:
>
> root@vm1# ./userns_uid0 resetcaps
> child_pid: 24706
> proc_file: /proc/24706/uid_map
> proc_file: /proc/24706/gid_map
> child resuming
> resetting caps
> ^Z
> [2]+  Stopped ./userns_uid0 resetcaps
> root@vm1# cat /proc/24706/uid_map
>  0 99  1
> root@vm1# cat /proc/24706/status | grep -e "Uid:" -e "Gid:"
> Uid: 99 99 99 99
> Gid: 99 99 99 99
>
> [Everything as before till now]
>
> root@vm1# ls -l /proc/24706/
> total 0
> dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:47 attr
> -r 1 root   root   0 2014-09-30 16:47 auxv
> -r--r--r-- 1 root   root   0 2014-09-30 16:47 cgroup
> --w--- 1 root   root   0 2014-09-30 16:47 clear_refs
> -r--r--r-- 1 root   root   0 2014-09-30 16:47 cmdline
> -rw-r--r-- 1 root   root   0 2014-09-30 16:47 comm
> -rw-r--r-- 1 root   root   0 2014-09-30 16:47 coredump_filter
> -r--r--r-- 1 root   root   0 2014-09-30 16:47 cpuset
> ...
> -r--r--r-- 1 root   root   0 2014-09-30 16:47 mountinfo
> -r--r--r-- 1 root   root   0 2014-09-30 16:47 mounts
> -r 1 root   root   0 2014-09-30 16:47 mountstats
> dr-xr-xr-x 5 nobody nobody 0 2014-09-30 16:47 net
> dr-x--x--x 2 root   root   0 2014-09-30 16:47 ns
> -r--r--r-- 1 root   root   0 2014-09-30 16:47 numa_maps
> ...
> -r--r--r-- 1 root   root   0 2014-09-30 16:47 status
> -r 1 root   root   0 2014-09-30 16:47 syscall
> dr-xr-xr-x 3 nobody nobody 0 2014-09-30 16:47 task
> ..
>
> Only the directories 'attr', 'net' and 'task' are owned by the uid=99.
> Rest all files are owned by global root.
>
> This behavior seems inconsistent. I ran this on 3.17 kernel. Can
> someone with expertise in this area explain if this is expected?

So I am not quite certain what you are seeing.

In general proc files are expected to be owned by the euid of a process.
However when the task_dumpable is cleared the files become owned by the
global root user.  We have considered relaxing that to the namespace
root user but so far implementing a more granular task_dumpable has not
been done.

The directories are world readable so they don't matter.

What puzzles me is that you have directories owned by nobody, and you
are talking about uid = 99 and gid = 99.  Nobody is traditionally
(u16_t)-2 and there should never actually be used by anyone.   And is
used as the default number of unmapped uids and gids.

It looks like you are doing something weird with nobody so I don't have
a clue what is actually going on.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v2,2/4] Simplify catalog_read()

[Michael Ellerman]

On Wed, 2014-24-09 at 19:24:39 UTC, suka...@linux.vnet.ibm.com wrote:
> catalog_read() implements the read interface for the sysfs file
> 
>   /sys/bus/event_source/devices/hv_24x7/interface/catalog
> 
> It essentially takes a buffer, an offset and count as parameters
> to the read() call.  It makes a hypervisor call to read a specific
> page from the catalog and copy the required bytes into the given
> buffer. Each call to catalog_read() returns at most one 4K page.
> 
> Given these requirements, we should be able to simplify the
> catalog_read().
> 
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index 2f2215c..9427ef7 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -185,6 +105,8 @@ static ssize_t catalog_read(struct file *filp, struct 
> kobject *kobj,
>   ssize_t ret = 0;
>   size_t catalog_len = 0, catalog_page_len = 0, page_count = 0;
>   loff_t page_offset = 0;
> + loff_t offset_in_page;
> + size_t copy_len;
>   uint64_t catalog_version_num = 0;
>   void *page = kmem_cache_alloc(hv_page_cache, GFP_USER);
>   struct hv_24x7_catalog_page_0 *page_0 = page;
> @@ -203,6 +125,7 @@ static ssize_t catalog_read(struct file *filp, struct 
> kobject *kobj,
>  
>   page_offset = offset / 4096;
>   page_count  = count  / 4096;

I don't see where page_count is used.

> + offset_in_page = count % 4096;

Shouldn't offset_in_page be based on offset ?

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

Re: [PATCH 0/2] x86: Quark: Add legacy_cache_size and TLB comments

[Bryan O'Donoghue]

On 01/10/14 01:11, Thomas Gleixner wrote:

Bryan,

On Wed, 1 Oct 2014, Bryan O'Donoghue wrote:

what are you trying to achieve by sending out patches faster than
anyone can review?


Thomas.

That's not the intention at all.


Doing this has an obvious outcome:

   1) The patches you whip up 10 seconds after the review hits your
  inbox are likely not to be well thought out. Neither are the
  changelogs.

  Just by skimming the lot I noticed at least two issues which you
  just mechanically fixed up without applying any thought. I'm not
  going to tell you, simply because you are starting to abuse and
  waste my time.

   2) Keeping #1 as your modus operandi will make sure that you get on
  the backlog list of reviewers and maintainers and in the worst
  case on the shitlist.


1)
OK, I take your point on the frequency.

2)
On the substance.
I'm certainly not trying to antagonise you here - I assumed you were 
*suggesting* to apply those comments directly ?
Which is why I updated the sent patches with your comments - since they 
seemed more descriptive anyway - and sent back to the list.



Thanks,
Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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,entry: Filter RFLAGS.NT on entry from userspace

[Chuck Ebbert]

On Tue, 30 Sep 2014 12:40:35 -0700
Andy Lutomirski  wrote:

> The NT flag doesn't do anything in long mode other than causing IRET
> to #GP.  Oddly, CPL3 code can still net NT using popf.
> 
> Entry via hardware or software interrupt clears NT automatically, so
> the only relevant entries are fast syscalls.
> 
> This patch programs the CPU to clear NT on entry via SYSCALL (both
> 32-bit and 64-bit, by my reading of the AMD APM).  It also clears NT
> (and some other flags) in software on SYSENTER.
> 
> I haven't touched anything on 32-bit kernels.
> 
> If user code causes kernel code to run with NT set, then there's at
> least some (small) chance that it could cause trouble.  For example,
> user code could cause a call to EFI code with NT set, and who knows
> what would happen.  Apparently Wine sometimes does this (!), and, if
> an IRET return happens, Wine will segfault.
> 
> I think that Wine should be fixed to stop setting NT when a syscall
> happens, but handling NT more gracefully is still nice.
> 
> The syscall mask change comes from a variant of this patch by Anish
> Bhatt.
> 
> Cc: sta...@kernel.org
> Reported-by: Anish Bhatt 
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/ia32/ia32entry.S| 10 +-
>  arch/x86/kernel/cpu/common.c |  2 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> index 4299eb05023c..079f42a7ad58 100644
> --- a/arch/x86/ia32/ia32entry.S
> +++ b/arch/x86/ia32/ia32entry.S
> @@ -143,7 +143,15 @@ ENTRY(ia32_sysenter_target)
>   pushq_cfi %r10
>   CFI_REL_OFFSET rip,0
>   pushq_cfi %rax
> - cld
> +
> + /*
> +  * Sysenter doesn't filter flags, so we should filter them
> +  * ourselves.
> +  */
> + pushfq_cfi
> + andl 
> $~(X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_NT|X86_EFLAGS_IOPL),(%rsp)
> + popfq_cfi

Can't you just push a constant and pop that onto flags instead? It's
not like we care what's in there on entry to the kernel.

> +
>   SAVE_ARGS 0,1,0
>   /* no need to do an access_ok check here because rbp has been
>  32bit zero extended */ 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index e4ab2b42bd6f..31265580c38a 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1184,7 +1184,7 @@ void syscall_init(void)
>   /* Flags to clear on syscall */
>   wrmsrl(MSR_SYSCALL_MASK,
>  X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_IF|
> -X86_EFLAGS_IOPL|X86_EFLAGS_AC);
> +X86_EFLAGS_IOPL|X86_EFLAGS_AC|X86_EFLAGS_NT);
>  }
>  
>  /*

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next] ieee802154: add __init to lowpan_frags_sysctl_register

[Alexander Aring]

Hi,

On Tue, Sep 30, 2014 at 10:34:08PM +0200, Fabian Frederick wrote:
> lowpan_frags_sysctl_register is only called by __init lowpan_net_frag_init
> (part of the lowpan module).
> 
> Signed-off-by: Fabian Frederick 
> ---
> This is untested.
> 
>  net/ieee802154/reassembly.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ieee802154/reassembly.c b/net/ieee802154/reassembly.c
> index 32755cb..30ec608 100644
> --- a/net/ieee802154/reassembly.c
> +++ b/net/ieee802154/reassembly.c
> @@ -485,7 +485,7 @@ static void __net_exit 
> lowpan_frags_ns_sysctl_unregister(struct net *net)
>  
>  static struct ctl_table_header *lowpan_ctl_header;
>  
> -static int lowpan_frags_sysctl_register(void)
> +static int __init lowpan_frags_sysctl_register(void)

yes right, but there is more lacks of missing "__init". See below.

>  {
>   lowpan_ctl_header = register_net_sysctl(_net,
>   "net/ieee802154/6lowpan",
> @@ -498,7 +498,7 @@ static void lowpan_frags_sysctl_unregister(void)
>   unregister_net_sysctl_table(lowpan_ctl_header);
>  }
>  #else
> -static inline int lowpan_frags_ns_sysctl_register(struct net *net)
> +static inline int __init lowpan_frags_ns_sysctl_register(struct net *net)

This is wrong, it's callback from "struct pernet_operations lowpan_frags_ops".

>  {
>   return 0;
>  }


Your patch adds "__init" now for two different functions and we have
two different declarations for these functions, depends if CONFIG_SYSCTL is
enabled.

Now if CONFIG_SYSCTL select we have as lowpan_frags_sysctl_register declaration:

static int __init lowpan_frags_sysctl_register(void)

if not:

static inline int lowpan_frags_sysctl_register(void)

Same for lowpan_frags_ns_sysctl_register and vice versa for CONFIG_SYSCTL.

Your changes are for two different functions (Don't know if you realized that):

"lowpan_frags_sysctl_register" and "lowpan_frags_ns_sysctl_register",
which makes no sense. Also lowpan_frags_ns_sysctl_register isn't called
by module init which is wrong.


To make "correct" cleanup for this "__init" should be add to the functions, for
both declarations if CONFIG_SYSCTL is set or not:

 - lowpan_net_frag_init
 - lowpan_frags_sysctl_register


I see now it's already applied, David please revert this change. Are you
fine to apply a correct version of this to wpan-next tree, next time?

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

uid=0 inside user-namespace and procfs file permissions

[Aditya Kali]

Hi all,

I am trying to run a process with uid=0 inside userns. But in the when
I also do capset() after setresuid(0, 0, 0), I am seeing inconsistent
proc file permissions. Almost all the files in /proc// has global
'root' as owner and group even if the actual process uid is correctly
changed.

I wrote a simple program that demonstrate the issue:

1. parent, as global root (uid=0 in init_user_ns) fork()s a child
2. child:
a) unshare(CLONE_NEWUSER)
b) [wait for parent to write uid_map]
c) setresgid(id, id, id) ; setresuid(0, 0, 0);
d) conditionally call capset() to clear capabilities
e) execve(/bin/sleep)
3. parent:
a) populates child's uid_map and maps some uid to 0 inside userns. ex:
0 99 1
b) waitpid()

(the actual program can be found at http://pastebin.com/f4P17VFn for
your reference).

When there is no capset() call after setresuid(0,0,0), everything is
fine. But when I do a capset() to clear all capabilities, the 'owner'
and 'group' of all the files under /proc//  of the child
process are reverted to global 'root' user.

# without capset (2.d):
root@vm1# id
uid=0(root) gid=0(root) groups=0(root)

root@vm1# ./userns_uid0
child_pid: 24277
proc_file: /proc/24277/uid_map
proc_file: /proc/24277/gid_map
child resuming

^Z
[1]+  Stopped ./userns_uid0
root@vm1# cat /proc/24277/uid_map
 0 99  1
root@vm1# cat /proc/24277/status | grep -e "Uid:" -e "Gid:"
Uid: 99 99 99 99
Gid: 99 99 99 99
root@vm1# ls -l /proc/24277/
total 0
dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:31 attr
-r 1 nobody nobody 0 2014-09-30 16:31 auxv
-r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cgroup
--w--- 1 nobody nobody 0 2014-09-30 16:31 clear_refs
-r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cmdline
-rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 comm
-rw-r--r-- 1 nobody nobody 0 2014-09-30 16:31 coredump_filter
-r--r--r-- 1 nobody nobody 0 2014-09-30 16:31 cpuset
...
[All files have owner='nobody' and group='nobody' .. same as that of
the process]

With the additional capset() call, the files under /proc//
are now owned by global root:

root@vm1# ./userns_uid0 resetcaps
child_pid: 24706
proc_file: /proc/24706/uid_map
proc_file: /proc/24706/gid_map
child resuming
resetting caps
^Z
[2]+  Stopped ./userns_uid0 resetcaps
root@vm1# cat /proc/24706/uid_map
 0 99  1
root@vm1# cat /proc/24706/status | grep -e "Uid:" -e "Gid:"
Uid: 99 99 99 99
Gid: 99 99 99 99

[Everything as before till now]

root@vm1# ls -l /proc/24706/
total 0
dr-xr-xr-x 2 nobody nobody 0 2014-09-30 16:47 attr
-r 1 root   root   0 2014-09-30 16:47 auxv
-r--r--r-- 1 root   root   0 2014-09-30 16:47 cgroup
--w--- 1 root   root   0 2014-09-30 16:47 clear_refs
-r--r--r-- 1 root   root   0 2014-09-30 16:47 cmdline
-rw-r--r-- 1 root   root   0 2014-09-30 16:47 comm
-rw-r--r-- 1 root   root   0 2014-09-30 16:47 coredump_filter
-r--r--r-- 1 root   root   0 2014-09-30 16:47 cpuset
...
-r--r--r-- 1 root   root   0 2014-09-30 16:47 mountinfo
-r--r--r-- 1 root   root   0 2014-09-30 16:47 mounts
-r 1 root   root   0 2014-09-30 16:47 mountstats
dr-xr-xr-x 5 nobody nobody 0 2014-09-30 16:47 net
dr-x--x--x 2 root   root   0 2014-09-30 16:47 ns
-r--r--r-- 1 root   root   0 2014-09-30 16:47 numa_maps
...
-r--r--r-- 1 root   root   0 2014-09-30 16:47 status
-r 1 root   root   0 2014-09-30 16:47 syscall
dr-xr-xr-x 3 nobody nobody 0 2014-09-30 16:47 task
..

Only the directories 'attr', 'net' and 'task' are owned by the uid=99.
Rest all files are owned by global root.

This behavior seems inconsistent. I ran this on 3.17 kernel. Can
someone with expertise in this area explain if this is expected?

Thanks,
-- 
Aditya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vfs: Don't exchange "short" filenames unconditionally.

[Al Viro]

On Mon, Sep 29, 2014 at 11:42:18AM -0700, Paul E. McKenney wrote:

> Assuming that incrementing the external name's reference count is
> atomic_add_unless, I could believe this part.  Or if you have some
> locking that makes it impossible to increment the reference count
> in any case where there is any risk that it might be decremented
> to zero, I guess.
> 
> Which might well be the pair of write_seqcount_begin() calls in __d_move(),
> now that I look more carefully.  So if the name has to be in use somewhere
> before it can be copied, then a copy can only be created if there is at
> least one copy that is not currently being removed?  If so, OK.

Huh?  copy_name() does copy a _reference_, not the name itself.  All the
copying involved is source->d_name.name = target->d_name.name.  And those
are simply unsigned char *.

write_seqcount_begin() is irrelevant here.  Look: all callers of
__d_move(x, y) are holding references both to x and y.  Contributing to
the refcount of dentries themselves, that is, not the names.

That gives exclusion between __d_move() and free_dentry() - the latter cannot
be called until dentry refcount reaches zero.  RCU is completely irrelevant
here.  In fact, no call chain leads to __d_move() under rcu_read_lock().
You must hold the target dentry hard, or it could simply be freed right
under you.

And __d_move() is taking ->d_lock on all dentries involved (in
addition to rename_lock serializing it system-wide).

What could possibly lead to refcount zero being observed on target of
__d_move()?  The history of any dentry is this:
* it is created by __d_alloc().  Nobody can see it until __d_alloc()
returns.  Dentry refcount (not to be confused with refcount of external
name) is 1.
* it passes through some (usually - zero) __d_move() calls.
Some - as the first argument, some - as the second one.  All those
calls are serialized by global seqlock - callers must hold rename_lock.
And all of them are done by somebody who is holding a counting reference
to dentries in question.
* counting references to dentry might be taken and dropped;
eventually refcount reaches zero (under ->d_lock) and no further
counting references can be taken after that.  See __dentry_kill() - the
first thing it does is poisoning the refcount, so that any future
attempt to increment it would fail.  __dentry_kill() (still under ->d_lock
of dentry, ->d_lock of its parent and ->i_lock of its inode) removes
dentry from the tree, from hash and from the alias list of inode;
Then it drops the locks.  At that point the only search structure dentry
might be found in is shrink list; if it's not on such list, free_dentry()
is called immediately, otherwise it's marked so that the code processing
the shrink list in question would, as soon as it gets to that sucker,
remove it from the shrink list and call the same free_dentry().  And that's
the only thing done to such dentry by somebody finding it via a shrink list.
* once free_dentry() has been reached, dentry can can be only seen
by RCU lookups, and after the grace period ends it gets physically freed.

free_dentry() isn't allowed to overlap __d_move(); to have that happen is
a serious dentry refcounting bug.  No __d_move() is allowed _after_
free_dentry() has been entered, either.  Again, it would take a refcounting
bug for dentries to have that happen - basically, double dput() somewhere.
If that happens, all bets are off, of course - if dentry gets unexpectedly
freed under somebody who has grabbed a reference to it and has not dropped
it yet, we are fucked.

Nothing outside of __d_move() is allowed to change ->d_name.name.  RCU-critical
code is allowed to fetch and dereference it, and such code relies upon
a) freeing of name seen by somebody who'd done rcu_read_lock() being
delayed until after the matching rcu_read_unlock()
b) store of terminating NUL done by __d_alloc() (and never overwritten
afterwards) being seen by RCU-critical code that has found the pointer to
that name in dentry->d_name.name

All other code accessing ->d_name.name is required to hold one of the locks
that are held by __d_move() and its callers.  Grabbing any of those leads
to smp_mb() on alpha, which serves as data dependency barrier there, so
we don't need explicit barrier there as we do in RCU-critical places - guarding
NUL will be seen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] x86: Quark: Add legacy_cache_size and TLB comments

[Thomas Gleixner]

Bryan,

On Wed, 1 Oct 2014, Bryan O'Donoghue wrote:

what are you trying to achieve by sending out patches faster than
anyone can review?

Doing this has an obvious outcome:

  1) The patches you whip up 10 seconds after the review hits your
 inbox are likely not to be well thought out. Neither are the
 changelogs.

 Just by skimming the lot I noticed at least two issues which you
 just mechanically fixed up without applying any thought. I'm not
 going to tell you, simply because you are starting to abuse and
 waste my time.

  2) Keeping #1 as your modus operandi will make sure that you get on
 the backlog list of reviewers and maintainers and in the worst
 case on the shitlist.

Thanks,

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

Re: [RFC 3/7] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding

[Bjorn Andersson]

On Tue 30 Sep 16:16 PDT 2014, Jeffrey Hugo wrote:

> On 9/30/2014 8:37 AM, Bjorn Andersson wrote:
> > On Tue 30 Sep 06:46 PDT 2014, Kumar Gala wrote:
> >
> >>
> >> On Sep 29, 2014, at 7:34 PM, Bjorn Andersson 
> >>  wrote:
> >>
> >>> diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt 
> >>> b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> >>> new file mode 100644
> >>> index 000..a846101
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> >>> @@ -0,0 +1,122 @@
> >>> +Qualcomm Resource Power Manager (RPM) over SMD
> >>> +
> >>> +This driver is used to interface with the Resource Power Manager (RPM) 
> >>> found in
> >>> +various Qualcomm platforms. The RPM allows each component in the system 
> >>> to vote
> >>> +for state of the system resources, such as clocks, regulators and bus
> >>> +frequencies.
> >>> +
> >>> +- compatible:
> >>> + Usage: required
> >>> + Value type: 
> >>> + Definition: must be one of:
> >>> + "qcom,rpm-msm8974”
> >>
> >> Why not “qcom,rpm-smd”.  I’d like to get Jeff H’s input on how
> >> what we do here for compat and distinguish the A-family RPM support vs
> >> B-family/RPM-SMD support.
> >>
> >
> > I don't see anything indicating changes in the actual communication, but as
> > this also encodes what resources are exposed we have to keep this specific.
> >
> > I'm not sure what you mean with distinguish the A and B family, they are
> > completely different and there are no overlap in compatibles or 
> > implementation.
> >
> > The overlap is in how children are communicating with the rpm, but this is 
> > an
> > implementation detail - and noted in that patch as a future improvement.
> >
> >
> > I forgot to add Jeff, but did send him a separate email asking for his 
> > input on
> > all this.
> >
> 
> Yep.  I saw the series.  Still doing a deep dive.
> 
> The rpm-smd driver (and the A family equivalent) is outside of my area 
> of expertise, but I have some familiarity with it as it is a SMD client. 
>   Internally we have a singular compat for all of B family, but I 
> haven't been able to figure out how that works to expose all of the 
> resources.  I'll talk to my contact later in the week to see what the 
> differences are.
> 

That's right, because you have these tables in devicetree in the caf version.
You have to have this information somewhere!

> Is the per target compat the way to do this though?  The way its 
> currently done means we'll have atleast a dozen tables in 
> qcom-smd-rpm.c, and I can't imagine they will have anything more than 
> minor differences from the msm8x74_resource_table that currently exists 
> in patch 6 of the series.  Why wouldn't one table that is a superset of 
> all supported targets work?
> 

It would work as long as e.g. QCOM_RPM_PM8941_MVS1 always is vsa number 4.

But sure, it's a much better fit than the family a and this rpm would reject
invalid resources, so it might work. But this works without us knowing about
all possible platforms.


But if the case is that multiple platforms expose the same table we can always
tie the same table to multiple compatibles.

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

Re: [PATCH v6 00/10] ARM: Berlin: Ethernet support

[David Miller]

From: Sebastian Hesselbarth 
Date: Wed, 01 Oct 2014 00:01:53 +0200

> Just to make sure how long I have to take care of potential merge
> issues, is your current net-next meant for v3.18 or v3.19?

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

[RFC PATCH] Perf Bench: Locking Microbenchmark

[Tuan Bui]

Subject: [RFC PATCH] Perf Bench: Locking Microbenchmark

In response to this thread https://lkml.org/lkml/2014/2/11/93, this is
a micro benchmark that stresses locking contention in the kernel with
creat(2) system call by spawning multiple processes to spam this system
call.  This workload generate similar results and contentions in AIM7
fserver workload but can generate outputs within seconds.

With the creat(2) system call the contention vary on what locks are used
in the particular file system. I have ran this benchmark only on ext4
and xfs file system.

Running the creat workload on ext4 show contention in the mutex lock
that is used by ext4_orphan_add() and ext4_orphan_del() to add or delete
an inode from the list of inodes. At the same time running the creat
workload on xfs show contention in the spinlock that is used by
xsf_log_commit_cil() to commit a transaction to the Committed Item List.

Here is a comparison of this benchmark with AIM7 running fserver workload
at 500-1000 users along with a perf trace running on ext4 file system.

Test machine is a 8-sockets 80 cores Westmere system HT-off on v3.17-rc6.

AIM7AIM7perf-bench  perf-bench
Users   Jobs/minJobs/min/child  Ops/sec Ops/sec/child
500 119668.25   239.34  104249  208
600 126074.90   210.12  106136  176
700 128662.42   183.80  106175  151
800 119822.05   149.78  106290  132
900 106150.25   117.94  105230  116
1000104681.29   104.68  106489  106

Perf trace for AIM7 fserver:
14.51%  reaim   [kernel.kallsyms]   [k] osq_lock
4.98%   reaim   reaim   [.] add_long
4.98%   reaim   reaim   [.] add_int
4.31%   reaim   [kernel.kallsyms]   [k] mutex_spin_on_owner
...

Perf trace of perf bench creat
22.37%  locking-creat  [kernel.kallsyms][k] osq_lock
5.77%   locking-creat  [kernel.kallsyms][k] mutex_spin_on_owner
5.31%   locking-creat  [kernel.kallsyms][k] _raw_spin_lock
5.15%   locking-creat  [jbd2]   [k] 
jbd2_journal_put_journal_head
...

Signed-off-by: Tuan Bui 
---
 tools/perf/Documentation/perf-bench.txt |8 ++
 tools/perf/Makefile.perf|1 +
 tools/perf/bench/bench.h|1 +
 tools/perf/bench/locking.c  |  234 +++
 tools/perf/builtin-bench.c  |8 ++
 5 files changed, 252 insertions(+)
 create mode 100644 tools/perf/bench/locking.c

diff --git a/tools/perf/Documentation/perf-bench.txt 
b/tools/perf/Documentation/perf-bench.txt
index f6480cb..e679135 100644
--- a/tools/perf/Documentation/perf-bench.txt
+++ b/tools/perf/Documentation/perf-bench.txt
@@ -58,6 +58,9 @@ SUBSYSTEM
 'futex'::
Futex stressing benchmarks.
 
+'locking'::
+Locking stressing benchmarks.
+
 'all'::
All benchmark subsystems.
 
@@ -213,6 +216,11 @@ Suite for evaluating wake calls.
 *requeue*::
 Suite for evaluating requeue calls.
 
+SUITES FOR 'locking'
+~~
+*creat*::
+Suite for evaluating locking contention through creat(2).
+
 SEE ALSO
 
 linkperf:perf[1]
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 2240974..e5a9d23 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -438,6 +438,7 @@ BUILTIN_OBJS += $(OUTPUT)bench/mem-memset.o
 BUILTIN_OBJS += $(OUTPUT)bench/futex-hash.o
 BUILTIN_OBJS += $(OUTPUT)bench/futex-wake.o
 BUILTIN_OBJS += $(OUTPUT)bench/futex-requeue.o
+BUILTIN_OBJS += $(OUTPUT)bench/locking.o
 
 BUILTIN_OBJS += $(OUTPUT)builtin-diff.o
 BUILTIN_OBJS += $(OUTPUT)builtin-evlist.o
diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h
index 3c4dd44..d31c0ba 100644
--- a/tools/perf/bench/bench.h
+++ b/tools/perf/bench/bench.h
@@ -34,6 +34,7 @@ extern int bench_mem_memset(int argc, const char **argv, 
const char *prefix);
 extern int bench_futex_hash(int argc, const char **argv, const char *prefix);
 extern int bench_futex_wake(int argc, const char **argv, const char *prefix);
 extern int bench_futex_requeue(int argc, const char **argv, const char 
*prefix);
+extern int bench_locking_creat(int argc, const char **argv, const char 
*prefix);
 
 #define BENCH_FORMAT_DEFAULT_STR   "default"
 #define BENCH_FORMAT_DEFAULT   0
diff --git a/tools/perf/bench/locking.c b/tools/perf/bench/locking.c
new file mode 100644
index 000..8cbe8a6
--- /dev/null
+++ b/tools/perf/bench/locking.c
@@ -0,0 +1,234 @@
+/*
+ * locking.c
+ *
+ * Simple micro benchmark that stress kernel locking contention with
+ * creat(2) system call by spawning multiple processes to call
+ * this system call.
+ *
+ * Results output are average operations/sec for all threads and
+ * average operations/sec per threads.
+ *
+ * Tuan Bui 
+ */
+
+#include "../perf.h"
+#include "../util/util.h"
+#include 

[PATCH] x86: Call identify_cpu() unconditionally once remove other callsites

[Bryan O'Donoghue]

Removes some bit-rot around cpu_detect_cache_sizes() in common.c
cpu_detect_cache_sizes() is valid for X86_32 and X86_64

AMD/Centaur/Cyrix/Transmeta currently call cpu_detect_cache_sizes()
as part of their respective initalisation routines.

cpu_detect_cache_sizes() is responsible for determining Cache/TLB size
and optionally calling into legacy_cache_size. Currently on Intel
processors this is broken.

This patch moves cpu_detect_cache_sizes() to one place in identify_cpu()
via default_init(). default_init() will therefore be called for every x86
processor unambiguously

Signed-off-by: Bryan O'Donoghue 
---
 arch/x86/kernel/cpu/amd.c   |  2 --
 arch/x86/kernel/cpu/centaur.c   |  2 --
 arch/x86/kernel/cpu/common.c| 11 +++
 arch/x86/kernel/cpu/cyrix.c |  2 +-
 arch/x86/kernel/cpu/transmeta.c |  2 --
 5 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 60e5497..7406f6d 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -672,8 +672,6 @@ static void init_amd(struct cpuinfo_x86 *c)
if (c->x86 >= 6)
set_cpu_bug(c, X86_BUG_FXSAVE_LEAK);
 
-   cpu_detect_cache_sizes(c);
-
/* Multi core CPU? */
if (c->extended_cpuid_level >= 0x8008) {
amd_detect_cmp(c);
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index d8fba5c..cbbf492 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -62,8 +62,6 @@ static void init_c3(struct cpuinfo_x86 *c)
c->x86_cache_alignment = c->x86_clflush_size * 2;
set_cpu_cap(c, X86_FEATURE_REP_GOOD);
}
-
-   cpu_detect_cache_sizes(c);
 }
 
 enum {
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e4ab2b4..4770e7c 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -67,9 +67,8 @@ void __init setup_cpu_local_masks(void)
 
 static void default_init(struct cpuinfo_x86 *c)
 {
-#ifdef CONFIG_X86_64
cpu_detect_cache_sizes(c);
-#else
+
/* Not much we can do here... */
/* Check if at least it has cpuid */
if (c->cpuid_level == -1) {
@@ -79,11 +78,9 @@ static void default_init(struct cpuinfo_x86 *c)
else if (c->x86 == 3)
strcpy(c->x86_model_id, "386");
}
-#endif
 }
 
 static const struct cpu_dev default_cpu = {
-   .c_init = default_init,
.c_vendor   = "Unknown",
.c_x86_vendor   = X86_VENDOR_UNKNOWN,
 };
@@ -874,6 +871,12 @@ static void identify_cpu(struct cpuinfo_x86 *c)
 #endif
 
/*
+* Unconditionally call default_init to detect legacy
+* Cache/TLB sizes
+*/
+   default_init(c);
+
+   /*
 * Vendor-specific initialization.  In this section we
 * canonicalize the feature flags, meaning if there are
 * features a certain CPU supports which CPUID doesn't
diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index aaf152e..5cd1bba 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -373,7 +373,7 @@ static void init_nsc(struct cpuinfo_x86 *c)
/* Handle the GX (Formally known as the GX2) */
 
if (c->x86 == 5 && c->x86_model == 5)
-   cpu_detect_cache_sizes(c);
+   return;
else
init_cyrix(c);
 }
diff --git a/arch/x86/kernel/cpu/transmeta.c b/arch/x86/kernel/cpu/transmeta.c
index 3fa0e5a..87f0835 100644
--- a/arch/x86/kernel/cpu/transmeta.c
+++ b/arch/x86/kernel/cpu/transmeta.c
@@ -25,8 +25,6 @@ static void init_transmeta(struct cpuinfo_x86 *c)
 
early_init_transmeta(c);
 
-   cpu_detect_cache_sizes(c);
-
/* Print CMS and CPU revision */
max = cpuid_eax(0x8086);
cpu_rev = 0;
-- 
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 v3 0/5] enhance DMA CMA on x86

[Peter Hurley]

On 09/30/2014 07:45 PM, Thomas Gleixner wrote:
> On Tue, 30 Sep 2014, Peter Hurley wrote:
>> I read the UFS Unified Memory Extension v1.0 (JESD220-1) specification and
>> it is not clear to me that using DMA mapping is the right approach to
>> supporting UM, at least on x86.
>>
>> And without a mainline user, the merits of this approach are not evident.
>> I cannot even find a production x86 UFS controller, much less one that
>> supports UME.
>>
>> The only PCI UFS controller I could find (and that mainline supports) is
>> Samsung's x86 FPGA-based test unit for developing UFS devices in a x86 test
>> environment, and not a production x86 design.
> 
> And how is that relevant? That device exists and you have no reason to
> deny it to be supported just because you are not interested in it.
>  
>> Unless there's something else I've missed, I don't think these patches
>> belong in mainline.
> 
> You missed that there is no reason WHY such a device should not be
> supported in mainline.

Mainline already supports this card right now without these patches.

>> Samsung's own roadmap
>> (http://www.slideshare.net/linaroorg/next-gen-mobilestorageufs)
>> mentions nothing about bringing UFS to x86 designs.
> 
> And that's telling you what? 
> 
>- That we should deny Samsung proper support for their obviously
>  x86 based test card
> 
>- That we should ignore a JEDEC Standard which is obviously never
>  going to hit x86 land just because you decide it?
> 
> Your argumentation is just ass backwards. Linux wants to support the
> full zoo of hardware including this particular PCI card. Period.
> 
> Whether the proposed patchset is the correct solution to support it is
> a completely different question.

And there is currently no way to determine that because there is no
user in mainline that requires this support.

Which you would understand if you had read more carefully.

Regards,
Peter Hurley

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

Re: [PATCH 0/5] HID: wacom: introduce generic HID handling

[Jason Gerecke]

On Tue, Sep 30, 2014 at 10:27 AM, Benjamin Tissoires
 wrote:
> On Sep 26 2014 or thereabouts, Jason Gerecke wrote:
>> On Fri, Sep 26, 2014 at 4:03 AM, Jiri Kosina  wrote:
>> > On Tue, 23 Sep 2014, Benjamin Tissoires wrote:
>> >
>> >> Hi guys,
>> >>
>> >> So, this patch series aims at supporting natively any future HID 
>> >> compliant wacom
>> >> tablet. Those found on the various laptops (ISDv4/5) already are HID 
>> >> compliant
>> >> and they should work in the future without any modification of the kernel.
>> >>
>> >> Few things to note here:
>> >> - I used the PID 0x00E6 found on the Lenovo X230 for the tests
>> >> - I did not removed its entry in the list because there is a slightly 
>> >> different
>> >>   behavior while using this patch set: when more than two fingers are on 
>> >> the
>> >>   screen, the tablet stops sending finger events, while with the wacom
>> >>   proprietary bits, it continues to send them. Besides that, the events 
>> >> emitted
>> >>   before and after the patch series are the same (at least on the E6)
>> >> - I can not rely on hid-input directly because wacom wants to be in 
>> >> control of
>> >>   the input devices it creates. This might be solved in the future, but 
>> >> for now
>> >>   it is just easier to rewrite the few mapping/events handling than 
>> >> trying to
>> >>   fit in the hid-input model.
>> >> - there will still be more specific use cases to handle later (see the 
>> >> joke of
>> >>   the MS surface 3 pen[1] for instance), but this should give a roughly 
>> >> working
>> >>   pen/touch support for those future devices.
>> >>
>> >> Jason, I would be very glad if you could conduct a few tests for this on 
>> >> the
>> >> ISDv4/5 sensors you have.
>> >
>> > I am waiting with this one for testing results from Jason, but if you guys
>> > want this to go in the next merge window, I'd like to ask you not to
>> > postpone the testing too much.
>> >
>> > Thanks.
>> >
>>
>> I'm in the process of capturing traces from hid-record for multiple
>> tablet PCs both pre- and post-patch to locate any obvious issues. My
>> initial results are promising on the pen side (the only things I've
>> noticed so far is the 2nd barrel switch not being supported -- as
>> might be suspected) but less so on the touch side (single-finger
>> devices seem to work fine, but the new code doesn't seem to handle any
>> of the multitouch devices I've tried).
>
> Do you consider not having the second barrel switch a blocker or can we
> ship it this and send a fix later?
>
> As for the touch, I tested/developed it on the Lenovo X230. It presents
> a hid-multitouch compatible touch interface, when the feature input_mode
> is sent with the value '2'. By re-reading it, it seems to me that you
> are trying to replay the touch traces you got before the patch, but this
> will not work because the touch protocol is not the same. ISDv4 used to
> rely on the proprietary touch protocol which is hard to describe in HID.
>
> I would say that as long as there is no regression (actually there can
> not be for old devices :-P), we should still carry this series for 3.18.
> We might need to adjust the bits here and there, but if we can have a
> *basic* support of the tablet out of the box, this is still much better
> than silently ignoring it.
>
I'm in agreement. The lack of second-switch support was expected and
somewhat trivial at this moment. We can work on finessing it as we go.

Regarding the touch input, I haven't had enough time to dive in to
figuring out what is wrong, but traces aren't the issue (I've not been
able to use traces for multitouch testing because the driver can't
query features->touch_max ;)). Working with actual hardware, I don't
get _any_ events out of the driver when using the touchscreen. I
checked that the device is sending the non-vendor-defined reports,
which does seem to be the case. The descriptor for the reports also
seem to be reasonable, appearing to follow Microsoft's
recommendations...

>>
>> Expect more news next week :)
>
> So?
>
I'm not sure if you want to fix touch first or just get these upstream
and fix during RC (as you said, it won't cause any regressions...) but
I'll give the following:

Acked-by: Jason Gerecke 

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours

>>
>>
>> PS: I'm pretty sure ISDv5 shouldn't be relied on for HID data :| The
>> descriptor for the Cintiq Companion Hybrid, at least, is like our
>> branded sensors with useful data only in the touchscreen descriptor
>> (the pen descriptor is a bunch of opaque vendor-defined reports). Not
>> sure if the Cintiq Companion is the same though since it runs
>> Windows...
>
> Ouch. For those, we will need to either fix the report descriptors or
> handle them in the same way you always used to do: manually.
>
> Cheers,
> Benjamin
>
>> >>
>> >> [1] 

Re: [PATCH v3 0/5] enhance DMA CMA on x86

[Thomas Gleixner]

On Tue, 30 Sep 2014, Peter Hurley wrote:
> I read the UFS Unified Memory Extension v1.0 (JESD220-1) specification and
> it is not clear to me that using DMA mapping is the right approach to
> supporting UM, at least on x86.
> 
> And without a mainline user, the merits of this approach are not evident.
> I cannot even find a production x86 UFS controller, much less one that
> supports UME.
> 
> The only PCI UFS controller I could find (and that mainline supports) is
> Samsung's x86 FPGA-based test unit for developing UFS devices in a x86 test
> environment, and not a production x86 design.

And how is that relevant? That device exists and you have no reason to
deny it to be supported just because you are not interested in it.
 
> Unless there's something else I've missed, I don't think these patches
> belong in mainline.

You missed that there is no reason WHY such a device should not be
supported in mainline.

> Samsung's own roadmap
> (http://www.slideshare.net/linaroorg/next-gen-mobilestorageufs)
> mentions nothing about bringing UFS to x86 designs.

And that's telling you what? 

   - That we should deny Samsung proper support for their obviously
 x86 based test card

   - That we should ignore a JEDEC Standard which is obviously never
 going to hit x86 land just because you decide it?

Your argumentation is just ass backwards. Linux wants to support the
full zoo of hardware including this particular PCI card. Period.

Whether the proposed patchset is the correct solution to support it is
a completely different question.

So either you stop this right now and help Akinobu to find the proper
solution or you just go back in your uncontaminated x86 cave and STFU.

Thanks,

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

[PATCH 1/2] x86: Quark: Update cache reporting, add Quark SoC X1000 string

[Bryan O'Donoghue]

Adds a path for legacy_cache_size to get a Quark SoC X1000 cache size
Update init_intel to take account of Quark X1000 reporting cache size
via legacy_cache_size

Add string to family/model structure for completeness and better
output of /proc/cpuinfo

Signed-off-by: Bryan O'Donoghue 
---
 arch/x86/kernel/cpu/intel.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 50ce751..f37f589 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -396,7 +396,15 @@ static void init_intel(struct cpuinfo_x86 *c)
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
+   /*
+* If cache_size has not been initialized via legacy_cache()
+* probe it via init_intel_cacheinfo().
+*/
+   if (c->x86_cache_size == 0)
+   l2 = init_intel_cacheinfo(c);
+   else
+   l2 = c->x86_cache_size;
+
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
/* Check for version and the number of counters */
@@ -500,6 +508,13 @@ static unsigned int intel_size_cache(struct cpuinfo_x86 
*c, unsigned int size)
 */
if ((c->x86 == 6) && (c->x86_model == 11) && (size == 0))
size = 256;
+
+   /*
+* Intel Quark SoC X1000 contains a 4-way set associative
+* 16K cache with a 16 byte cache line and 256 lines per tag
+*/
+   if ((c->x86 == 5) && (c->x86_model == 9))
+   size = 16;
return size;
 }
 #endif
@@ -701,7 +716,8 @@ static const struct cpu_dev intel_cpu_dev = {
  [3] = "OverDrive PODP5V83",
  [4] = "Pentium MMX",
  [7] = "Mobile Pentium 75 - 200",
- [8] = "Mobile Pentium MMX"
+ [8] = "Mobile Pentium MMX",
+ [9] = "Quark SoC X1000",
  }
},
{ .family = 6, .model_names =
-- 
1.9.1

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

[PATCH 0/2] x86: Quark: Add legacy_cache_size and TLB comments

[Bryan O'Donoghue]

First patch:
Quark X1000 contains a 16k 4-way set associative unified L1 cache
with 256 sets. The second patch gets Quark X1000 reporting 16k of
cache in-line with other legacy reporting processors like PIII Tualatin

Second patch:
Adds a comment to arch/x86/kernel/setup.c. Quark SoC X1000
advertises PGE via cpuid but doesn't infact implement the functionality
to support global pages in the TLB.
Linux will by default toggle CR4.PGE for processors that advertise PGE
A fix is already in place to ensure __flush_tlb() as opposed to
__flush_tlb_all() is called during normal operation.

Since __flush_tlb() just rewrites CR3 there's no need to take any further
action on Quark after writing CR3 in setup.c to flush the TLB. We comment
that behaviour. Note cpu_has_pge() will be nuked later in the boot but,
changing the value at this phase of the boot is considered harmful and so
instead we have agreed to comment the existing code

Bryan O'Donoghue (2):
  x86: Quark: Update cache reporting, add Quark SoC X1000 string
  x86: Quark: Comment setup_arch for TLB/PGE bugfix

 arch/x86/kernel/cpu/intel.c | 20 ++--
 arch/x86/kernel/setup.c |  9 +
 2 files changed, 27 insertions(+), 2 deletions(-)

-- 
1.9.1

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

[PATCH 2/2] x86: Quark: Comment setup_arch for TLB/PGE bugfix

[Bryan O'Donoghue]

Quark X1000 requires CR3 to be rewritten to flush TLB entries
irrespective of the PGE bits in CR4 or PTE.PGE

Add a comment to setup_arch to indicate that the code

load_cr3(swapper_pg_dir);
__flush_tlb_all();

Will already have flushed the TLB @ the CR3 reload allowing us
to skip over a potential if/else for Quark.

This comment clearly states the bug, the behaviour we rely on
and the reason why we only do it this way - one time.

Later on cpu_has_pge() will be false due to a fixup in
intel_init_early() and __flush_tlb_all() will work as expected
from that point onwards

Signed-off-by: Bryan O'Donoghue 
---
 arch/x86/kernel/setup.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 41ead8d..235cfd3 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -879,6 +879,15 @@ void __init setup_arch(char **cmdline_p)
KERNEL_PGD_PTRS);
 
load_cr3(swapper_pg_dir);
+   /*
+* Note: Quark X1000 CPUs advertise PGE incorrectly and require
+* a cr3 based tlb flush, so the following __flush_tlb_all()
+* will not flush anything because the cpu quirk which clears
+* X86_FEATURE_PGE has not been invoked yet. Though due to the
+* load_cr3() above the TLB has been flushed already. The
+* quirk is invoked before subsequent calls to __flush_tlb_all()
+* so proper operation is guaranteed.
+*/
__flush_tlb_all();
 #else
printk(KERN_INFO "Command line: %s\n", boot_command_line);
-- 
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 v7 00/11] kernel: Add support for restart handler call chain

[Stephen Rothwell]

Hi Guenter,

On Tue, 30 Sep 2014 15:30:00 -0700 Guenter Roeck  wrote:
>
> On Tue, Sep 30, 2014 at 02:20:02PM -0700, Andrew Morton wrote:
> > On Tue, 19 Aug 2014 17:45:27 -0700 Guenter Roeck  wrote:
> > 
> > > Introduce a system restart handler call chain to solve the described 
> > > problems.
> > 
> > So someone has merged eight of these patches into linux-next but these
> > three:
> > 
> > watchdog-s3c2410-add-restart-handler.patch
> > clk-samsung-register-restart-handlers-for-s3c2412-and-s3c2443.patch
> > clk-rockchip-add-restart-handler.patch
> > 
> > were omitted.  What's up?
> 
> Most likely PBKC on my side; Looks like I forgot to add those when I created
> the immutable branch for others to merge. Sorry for that :-(.
> 
> Having said that, I somehow thought that the clock patches would go in through
> the clock tree. Heiko, did I get that wrong ? Separately, I sent a pull 
> request
> that includes the watchdog patch to Wim.

So far, that immutable branch has been merged into the battery tree
(and thus into linux-next) by Sebastian in order to add (I assume):

18a702e0de98 power: reset: use restart_notifier mechanism for msm-poweroff
371bb20d6927 power: Add simple gpio-restart driver

on top of it.

So, I guess the watchdog and clk trees also need to merge that
immutable branch and then add their respective patches from the mmotm
series to their trees.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

[PATCH RESEND V9 2/6] Documentation: power: reset: Add documentation for generic SYSCON reboot driver

[Feng Kan]

Add documentation for generic SYSCON reboot driver.

Signed-off-by: Feng Kan 
---
 .../bindings/power/reset/syscon-reboot.txt | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/syscon-reboot.txt

diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt 
b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
new file mode 100644
index 000..1190631
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
@@ -0,0 +1,23 @@
+Generic SYSCON mapped register reset driver
+
+This is a generic reset driver using syscon to map the reset register.
+The reset is generally performed with a write to the reset register
+defined by the register map pointed by syscon reference plus the offset
+with the mask defined in the reboot node.
+
+Required properties:
+- compatible: should contain "syscon-reboot"
+- regmap: this is phandle to the register map node
+- offset: offset in the register map for the reboot register (in bytes)
+- mask: the reset value written to the reboot register (32 bit access)
+
+Default will be little endian mode, 32 bit access only.
+
+Examples:
+
+   reboot {
+  compatible = "syscon-reboot";
+  regmap = <>;
+  offset = <0x0>;
+  mask = <0x1>;
+   };
-- 
1.9.1

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

[PATCH RESEND V9 0/6] Add generic syscon reboot driver

[Feng Kan]

Enable reboot driver for the X-Gene platform. Add generic syscon reboot
driver. Replace X-Gene reboot driver with the generic syscon reboot
driver.

V9 Change:
- rebase on Guenter Roeck's reset handler patch set now in linux next.
  This allows for a generic reset to be call rather than the arm
  specific reset handler.

V8 Change:
- change Kconfig to depend on ARM || ARM64 || COMPILE_TEST

V7 Change:
- Seem V3 on, the patches were not making in to the mailinglist.
- Fix build error produced by other ARCH while including this
  driver. Set to depend on arm64 ARCH for now.

V6 Change:
- Add documentation for scu node.

V5 Change:
- Documentation update, endian and access size.

V4 Change:
- Remove old X-Gene reboot driver
- Add generic syscon reboot driver
- Add DTS and Kconfig for X-Gene reboot using syscon method

V3 Change:
- Remove the reboot driver's use of acpi resource patch.
- Change the reboot driver to use syscon to parse out
  system clock register. Remove the old method of getting
  register from the reboot driver directly.
- Remove documentation since its now simple.

V2 Change:
- Add support for using ACPI resource.


Feng Kan (6):
  power: reset: Add generic SYSCON register mapped reset
  Documentation: power: reset: Add documentation for generic SYSCON
reboot driver
  Documentation: arm64: add SCU dts binding documentation to linux
kernel
  arm64: dts: Add X-Gene reboot driver dts node
  arm64: Select reboot driver for X-Gene platform
  power: reset: Remove X-Gene reboot driver

 Documentation/devicetree/bindings/arm/apm/scu.txt  |  17 
 .../bindings/power/reset/syscon-reboot.txt |  23 +
 arch/arm64/Kconfig |   2 +
 arch/arm64/boot/dts/apm-storm.dtsi |  11 +++
 drivers/power/reset/Kconfig|  11 +--
 drivers/power/reset/Makefile   |   2 +-
 drivers/power/reset/syscon-reboot.c|  96 +++
 drivers/power/reset/xgene-reboot.c | 103 -
 8 files changed, 155 insertions(+), 110 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
 create mode 100644 
Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
 create mode 100644 drivers/power/reset/syscon-reboot.c
 delete mode 100644 drivers/power/reset/xgene-reboot.c

-- 
1.9.1

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

[PATCH RESEND V9 3/6] Documentation: arm64: add SCU dts binding documentation to linux kernel

[Feng Kan]

This add documentation for the SCU system clock unit device tree binding
to the kernel.

Signed-off-by: Feng Kan 
---
 Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt

diff --git a/Documentation/devicetree/bindings/arm/apm/scu.txt 
b/Documentation/devicetree/bindings/arm/apm/scu.txt
new file mode 100644
index 000..b45be06
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/apm/scu.txt
@@ -0,0 +1,17 @@
+APM X-GENE SoC series SCU Registers
+
+This system clock unit contain various register that control block resets,
+clock enable/disables, clock divisors and other deepsleep registers.
+
+Properties:
+ - compatible : should contain two values. First value must be:
+  - "apm,xgene-scu"
+   second value must be always "syscon".
+
+ - reg : offset and length of the register set.
+
+Example :
+   scu: system-clk-controller@1700 {
+   compatible = "apm,xgene-scu","syscon";
+   reg = <0x0 0x1700 0x0 0x400>;
+   };
-- 
1.9.1

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

[PATCH RESEND V9 5/6] arm64: Select reboot driver for X-Gene platform

[Feng Kan]

Select reboot driver for X-Gene platform.

Signed-off-by: Feng Kan 
---
 arch/arm64/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 2ca2ebd..2edccbc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -149,6 +149,8 @@ config ARCH_VEXPRESS
 
 config ARCH_XGENE
bool "AppliedMicro X-Gene SOC Family"
+   select MFD_SYSCON
+   select POWER_RESET_SYSCON
help
  This enables support for AppliedMicro X-Gene SOC Family
 
-- 
1.9.1

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

[PATCH RESEND V9 4/6] arm64: dts: Add X-Gene reboot driver dts node

[Feng Kan]

Add X-Gene platform reboot driver dts node.

Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm-storm.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm-storm.dtsi
index f391972..cfde5f8 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -103,6 +103,11 @@
#size-cells = <2>;
ranges;
 
+   scu: system-clk-controller@1700 {
+   compatible = "apm,xgene-scu","syscon";
+   reg = <0x0 0x1700 0x0 0x400>;
+   };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
@@ -442,5 +447,11 @@
clocks = < 0>;
};
 
+   reboot: reboot@1714 {
+   compatible = "syscon-reboot";
+   regmap = <>;
+   offset = <0x14>;
+   mask = <0x1>;
+   };
};
 };
-- 
1.9.1

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

[PATCH RESEND V9 6/6] power: reset: Remove X-Gene reboot driver

[Feng Kan]

Remove X-Gene reboot driver.

Signed-off-by: Feng Kan 
Signed-off-by: Loc Ho 
---
 drivers/power/reset/Kconfig|   6 ---
 drivers/power/reset/Makefile   |   1 -
 drivers/power/reset/xgene-reboot.c | 103 -
 3 files changed, 110 deletions(-)
 delete mode 100644 drivers/power/reset/xgene-reboot.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index a863fa1..98f9086 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -130,12 +130,6 @@ config POWER_RESET_VEXPRESS
  Power off and reset support for the ARM Ltd. Versatile
  Express boards.
 
-config POWER_RESET_XGENE
-   bool "APM SoC X-Gene reset driver"
-   depends on ARM64
-   help
- Reboot support for the APM SoC X-Gene Eval boards.
-
 config POWER_RESET_KEYSTONE
bool "Keystone reset driver"
depends on ARCH_KEYSTONE
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 76ce1c5..e6cda42 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -14,6 +14,5 @@ obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
 obj-$(CONFIG_POWER_RESET_ST) += st-poweroff.o
 obj-$(CONFIG_POWER_RESET_VERSATILE) += arm-versatile-reboot.o
 obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
-obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
 obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
 obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/xgene-reboot.c 
b/drivers/power/reset/xgene-reboot.c
deleted file mode 100644
index 6b49be6..000
--- a/drivers/power/reset/xgene-reboot.c
+++ /dev/null
@@ -1,103 +0,0 @@
-/*
- * AppliedMicro X-Gene SoC Reboot Driver
- *
- * Copyright (c) 2013, Applied Micro Circuits Corporation
- * Author: Feng Kan 
- * Author: Loc Ho 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- *
- * This driver provides system reboot functionality for APM X-Gene SoC.
- * For system shutdown, this is board specify. If a board designer
- * implements GPIO shutdown, use the gpio-poweroff.c driver.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-struct xgene_reboot_context {
-   struct platform_device *pdev;
-   void *csr;
-   u32 mask;
-};
-
-static struct xgene_reboot_context *xgene_restart_ctx;
-
-static void xgene_restart(enum reboot_mode mode, const char *cmd)
-{
-   struct xgene_reboot_context *ctx = xgene_restart_ctx;
-   unsigned long timeout;
-
-   /* Issue the reboot */
-   if (ctx)
-   writel(ctx->mask, ctx->csr);
-
-   timeout = jiffies + HZ;
-   while (time_before(jiffies, timeout))
-   cpu_relax();
-
-   dev_emerg(>pdev->dev, "Unable to restart system\n");
-}
-
-static int xgene_reboot_probe(struct platform_device *pdev)
-{
-   struct xgene_reboot_context *ctx;
-
-   ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
-   if (!ctx) {
-   dev_err(>dev, "out of memory for context\n");
-   return -ENODEV;
-   }
-
-   ctx->csr = of_iomap(pdev->dev.of_node, 0);
-   if (!ctx->csr) {
-   devm_kfree(>dev, ctx);
-   dev_err(>dev, "can not map resource\n");
-   return -ENODEV;
-   }
-
-   if (of_property_read_u32(pdev->dev.of_node, "mask", >mask))
-   ctx->mask = 0x;
-
-   ctx->pdev = pdev;
-   arm_pm_restart = xgene_restart;
-   xgene_restart_ctx = ctx;
-
-   return 0;
-}
-
-static struct of_device_id xgene_reboot_of_match[] = {
-   { .compatible = "apm,xgene-reboot" },
-   {}
-};
-
-static struct platform_driver xgene_reboot_driver = {
-   .probe = xgene_reboot_probe,
-   .driver = {
-   .name = "xgene-reboot",
-   .of_match_table = xgene_reboot_of_match,
-   },
-};
-
-static int __init xgene_reboot_init(void)
-{
-   return platform_driver_register(_reboot_driver);
-}
-device_initcall(xgene_reboot_init);
-- 
1.9.1

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

[PATCH RESEND V9 1/6] power: reset: Add generic SYSCON register mapped reset

[Feng Kan]

Add a generic SYSCON register mapped reset mechanism.

Signed-off-by: Feng Kan 
---
 drivers/power/reset/Kconfig |  5 ++
 drivers/power/reset/Makefile|  1 +
 drivers/power/reset/syscon-reboot.c | 96 +
 3 files changed, 102 insertions(+)
 create mode 100644 drivers/power/reset/syscon-reboot.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1915dde..a863fa1 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -143,4 +143,9 @@ config POWER_RESET_KEYSTONE
help
  Reboot support for the KEYSTONE SoCs.
 
+config POWER_RESET_SYSCON
+   bool "Generic SYSCON regmap reset driver"
+   depends on POWER_RESET && MFD_SYSCON && OF
+   help
+ Reboot support for generic SYSCON mapped register reset.
 endif
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 01e401d..76ce1c5 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_POWER_RESET_VERSATILE) += arm-versatile-reboot.o
 obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
 obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
 obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
+obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/syscon-reboot.c 
b/drivers/power/reset/syscon-reboot.c
new file mode 100644
index 000..948e0ee
--- /dev/null
+++ b/drivers/power/reset/syscon-reboot.c
@@ -0,0 +1,96 @@
+/*
+ * Generic Syscon Reboot Driver
+ *
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Author: Feng Kan 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct syscon_reboot_context {
+   struct regmap *map;
+   u32 offset;
+   u32 mask;
+   struct notifier_block restart_handler;
+};
+
+static struct syscon_reboot_context *syscon_reboot_ctx;
+
+static int syscon_restart_handle(struct notifier_block *this,
+   unsigned long mode, void *cmd)
+{
+   struct syscon_reboot_context *ctx = syscon_reboot_ctx;
+   unsigned long timeout;
+
+   /* Issue the reboot */
+   if (ctx->map)
+   regmap_write(ctx->map, ctx->offset, ctx->mask);
+
+   timeout = jiffies + HZ;
+   while (time_before(jiffies, timeout))
+   cpu_relax();
+
+   pr_emerg("Unable to restart system\n");
+   return NOTIFY_DONE;
+}
+
+static int syscon_reboot_probe(struct platform_device *pdev)
+{
+   struct syscon_reboot_context *ctx;
+   struct device *dev = >dev;
+   int err;
+
+   ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
+   if (!ctx)
+   return -ENOMEM;
+
+   ctx->map = syscon_regmap_lookup_by_phandle(dev->of_node, "regmap");
+   if (IS_ERR(ctx->map))
+   return PTR_ERR(ctx->map);
+
+   if (of_property_read_u32(pdev->dev.of_node, "offset", >offset))
+   return -EINVAL;
+
+   if (of_property_read_u32(pdev->dev.of_node, "mask", >mask))
+   return -EINVAL;
+
+   ctx->restart_handler.notifier_call = syscon_restart_handle;
+   ctx->restart_handler.priority = 128;
+   err = register_restart_handler(>restart_handler);
+   if (err)
+   dev_err(dev, "can't register restart notifier (err=%d)\n", err);
+
+   syscon_reboot_ctx = ctx;
+
+   return 0;
+}
+
+static struct of_device_id syscon_reboot_of_match[] = {
+   { .compatible = "syscon-reboot" },
+   {}
+};
+
+static struct platform_driver syscon_reboot_driver = {
+   .probe = syscon_reboot_probe,
+   .driver = {
+   .name = "syscon-reboot",
+   .of_match_table = syscon_reboot_of_match,
+   },
+};
+module_platform_driver(syscon_reboot_driver);
-- 
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 v3 0/5] enhance DMA CMA on x86

[Akinobu Mita]

2014-09-30 23:34 GMT+09:00 Peter Hurley :
> On 09/29/2014 10:32 AM, Akinobu Mita wrote:
>> 2014-09-29 21:09 GMT+09:00 Peter Hurley :
>>> On 09/27/2014 08:31 PM, Akinobu Mita wrote:
 2014-09-27 23:30 GMT+09:00 Peter Hurley :
> On 04/15/2014 09:08 AM, Akinobu Mita wrote:
>> This patch set enhances the DMA Contiguous Memory Allocator on x86.
>>>
>>> [...]
>>>
> What this patchset does is restrict all iommu configurations which can
> map all of system memory to one _very_ small physical region, thus 
> disabling
> the whole point of an iommu.
>
> Now I know why my GPU is causing paging to disk! And why my RAID 
> controller
> stalls for ages when I do a git log at the same time as a kernel build!

 The solution I have for this is that instead of trying to
 dma_alloc_from_contiguous() firstly, call alloc_pages() in 
 dma_alloc_coherent().
 dma_alloc_from_contiguous() should be called only when alloc_pages() is 
 failed
 or DMA_ATTR_FORCE_CONTIGUOUS is specified in dma_attr.
>>>
>>> Why is all this extra complexity being added when there are no X86 users
>>> of DMA_ATTR_FORCE_CONTIGUOUS?
>>
>> I misunderstood DMA_ATTR_FORCE_CONTIGUOUS.  It is specified to request
>> that underlaying DMA mapping span physically contiguous with IOMMU.
>> But current alloc_dma_coherent() for intel-iommu always returns
>> physically contiguous memory, so it is ignored on x86.
>>
> And the apparent goal of this patchset is to enable DMA allocation below
> 4GB, which is already supported in the existing page allocator with the
> GFP_DMA32 flag?!

 The goal of this patchset is to enable huge DMA allocation which
 alloc_pages() can't (> MAX_ORDER) for the devices that require it.
>>>
>>> What x86 devices need > MAX_ORDER DMA allocation and why can't they allocate
>>> directly from dma_alloc_from_contiguous()?
>>
>> I need this for UFS unified memory extension which is apparently not in
>> mainline for now.
>> http://www.jedec.org/standards-documents/docs/jesd220-1
>> http://www.jedec.org/sites/default/files/T_Fujisawa_MF_2013.pdf
>>
>> But there must be some other use cases on x86, too.  Because I have
>> received several emails privately from developers who care its status.
>>
>> And allocating directly from dma_alloc_from_contiguous() in the driver
>> doesn't work with IOMMU, as it just returns memory regoin and doesn't
>> create DMA mapping.
>
>
> I read the UFS Unified Memory Extension v1.0 (JESD220-1) specification and
> it is not clear to me that using DMA mapping is the right approach to
> supporting UM, at least on x86.

Without DMA mapping, there is no way for the devices to access host
memory.  Unified memory extension requires a single contiguous memory
region instead of multiple scattered mapping.

> And without a mainline user, the merits of this approach are not evident.
> I cannot even find a production x86 UFS controller, much less one that
> supports UME.
>
> The only PCI UFS controller I could find (and that mainline supports) is
> Samsung's x86 FPGA-based test unit for developing UFS devices in a x86 test
> environment, and not a production x86 design.
>
> Samsung's own roadmap 
> (http://www.slideshare.net/linaroorg/next-gen-mobilestorageufs)
> mentions nothing about bringing UFS to x86 designs.
>
> Unless there's something else I've missed, I don't think these patches
> belong in mainline.

Removing CONFIG_CMA_DMA support from x86_64 will disappoint me, but it's
personal opinion.  FWIW, MIPS also starts supporting it in linux-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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,entry: Filter RFLAGS.NT on entry from userspace

[Thomas Gleixner]

On Tue, 30 Sep 2014, Andy Lutomirski wrote:

> On Tue, Sep 30, 2014 at 3:27 PM, Thomas Gleixner  wrote:
> > On Tue, 30 Sep 2014, Andy Lutomirski wrote:
> >> It would certainly be possible to clear NT and retry IRET if IRET
> >> fails with NT set.  This would have no overhead for anything relevant.
> >> That would be this alternative from my 0/2 email:
> >>
> >>  - Don't filter NT on sysenter.  Instead, filter it on EFI entry
> >>and modify the IRET code to retry without NT set if NT was set.
> >>
> >> Thomas hpa, etc: any thoughts?
> >
> > Filter it right away. That's solid and obvious. Anything else is just
> > complex and prone for future brown paperbag failures.
> 
> Yeah, agreed.  That's exactly what these patches do, although, if you
> put them in -tip and want to keep the stable CC, it's probably worth
> fixing the address (oops).

Even more oops as you failed to update it in your reply again 
 
> > We get the context switch benefit from it, so there is some
> > compensation for the extra cycles.
> 
> If we ever want those cycles back, I bet that the compat sysenter path
> could be trimmed down a lot.  For example, I think that all of the
> zero-extension stuff is unnecessary now that we have the magic syscall
> wrappers for all (?) syscalls.

Emphasis on "(?)". So yes, once we verified that 

Thanks,

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

Re: ext4: 3.17? problems

[Henrique de Moraes Holschuh]

On Tue, 30 Sep 2014, Pavel Machek wrote:
> > > So I had to hard power-down the machine. That should be perfectly
> > > safe, as ext4 has a journal, and this is plain SATA disk, right?
> >   Yes, it should be safe.
> 
> Good.

...

> Is there some phase during shutdown where journalling no longer
> protects fs integrity?

Hmm... what kind of backing device?  Because I have Crucial/Micron M500 SSDs
here that _always_ complain (in a SMART counter/attribute) that they have
been subject to a sudden poweroff *when subject to a normal system
shutdown*.

This is scaring me a great deal.  Are we doing something different for SSDs
in the scsi-sd or libata shutdown paths?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 3/7] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding

[Jeffrey Hugo]

On 9/30/2014 8:37 AM, Bjorn Andersson wrote:

On Tue 30 Sep 06:46 PDT 2014, Kumar Gala wrote:



On Sep 29, 2014, at 7:34 PM, Bjorn Andersson  
wrote:


diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt 
b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
new file mode 100644
index 000..a846101
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
@@ -0,0 +1,122 @@
+Qualcomm Resource Power Manager (RPM) over SMD
+
+This driver is used to interface with the Resource Power Manager (RPM) found in
+various Qualcomm platforms. The RPM allows each component in the system to vote
+for state of the system resources, such as clocks, regulators and bus
+frequencies.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,rpm-msm8974”


Why not “qcom,rpm-smd”.  I’d like to get Jeff H’s input on how
what we do here for compat and distinguish the A-family RPM support vs
B-family/RPM-SMD support.



I don't see anything indicating changes in the actual communication, but as
this also encodes what resources are exposed we have to keep this specific.

I'm not sure what you mean with distinguish the A and B family, they are
completely different and there are no overlap in compatibles or implementation.

The overlap is in how children are communicating with the rpm, but this is an
implementation detail - and noted in that patch as a future improvement.


I forgot to add Jeff, but did send him a separate email asking for his input on
all this.



Yep.  I saw the series.  Still doing a deep dive.

The rpm-smd driver (and the A family equivalent) is outside of my area 
of expertise, but I have some familiarity with it as it is a SMD client. 
 Internally we have a singular compat for all of B family, but I 
haven't been able to figure out how that works to expose all of the 
resources.  I'll talk to my contact later in the week to see what the 
differences are.


Is the per target compat the way to do this though?  The way its 
currently done means we'll have atleast a dozen tables in 
qcom-smd-rpm.c, and I can't imagine they will have anything more than 
minor differences from the msm8x74_resource_table that currently exists 
in patch 6 of the series.  Why wouldn't one table that is a superset of 
all supported targets work?



+
+- qcom,smd-channels:
+   Usage: required
+   Value type: 
+   Definition: Shared Memory Channel used for communication with the RPM
+


This needs more details.



Not sure what more to add here. It should contain the name of the channel used
for communication with the rpm. For all current platforms this would be
"rpm_requests".


+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+= SUBDEVICES


As I mentioned for the the RPM binding on a-family, we should split out the
devices into their own binding specs.



Please actually read https://lkml.org/lkml/2014/3/10/567, it's now the third
time I send you that link. If you don't like it then ask Rob to revise his
statement.

For me it makes sense to consolidate the RPM binding in one document rather
than spreading it out in 10 different documents with some implicit
dependencies.

Regards,
Bjorn




Jeffrey Hugo
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation.

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