RE: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

[Doug Smythies]

On 2016.04.08 15:19 Doug Smythies wrote:
> On 2016.04.08 14:00 Rafael J. Wysocki wrote:
>> On Friday, April 08, 2016 08:50:54 AM Mike Galbraith wrote:
>>> On Fri, 2016-04-08 at 08:45 +0200, Peter Zijlstra wrote:
>>> 
 Cute, I thought you used governor=performance for your runs?
>>> 
>>> I do, and those numbers are with it thus set.

>> Well, this is a trade-off.
>>
>> 4.5 introduced a power regression here so this one goes back to the previous
>> state of things.

> Mike:
>
> Could you send me, or point me to, the program "pipe-test"?
> So far, I have only found one, but it is both old and not
> the same program you are running (based on print statements).
>
> I realize I might not be to recreate your problem scenario anyhow,
> I just want to try.

I still didn't find the exact same program, but I think I found some
earlier version of the correct test.

I get (long term average):
Kernel 4.4.0-17: Powersave 3.93 usecs/loop ; Performance 3.93 usecs/loop 0.89
Kernel 4.5-rc7: Powersave 3.47 usecs/loop ; Performance 3.51 usecs/loop  1.00
Kernel 4.6-rc1: Powersave 3.84 usecs/loop ; Performance 3.88 usecs/loop  0.90

So, similar results (so far, I didn't try reverted yet).

... Doug

.queuecommand field in struct scsi_host_template, for sas

[pesa1]

While the following method, in drivers/scsi/libsas/sas_scsi_host:180
int sas_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
seems to be the implementation for the `queuecommand` field of struct
scsi_host_template.


Where is it initialized so, for a general sas device?

I can not find, in the code initialization for a scsi device, to the
'sas_queuecommand'.


This is, while the scsi layer, clearly uses that field, in
scsi_dispatch_command():

rtn = host->hostt->queuecommand(host, cmd);

So, where does it get initialized?.

Thanks





--
View this message in context: 
http://linux-kernel.2935.n7.nabble.com/queuecommand-field-in-struct-scsi-host-template-for-sas-tp1347757.html
Sent from the Linux Kernel mailing list archive at Nabble.com.

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

[Mike Galbraith]

On Sat, 2016-04-09 at 00:17 -0700, Doug Smythies wrote:

> I still didn't find the exact same program, but I think I found some
> earlier version of the correct test.
> 
> I get (long term average):
> Kernel 4.4.0-17: Powersave 3.93 usecs/loop ; Performance 3.93 usecs/loop 0.89
> Kernel 4.5-rc7: Powersave 3.47 usecs/loop ; Performance 3.51 usecs/loop  1.00
> Kernel 4.6-rc1: Powersave 3.84 usecs/loop ; Performance 3.88 usecs/loop  0.90
> 
> So, similar results (so far, I didn't try reverted yet).

I likely see a bit more go missing because I throttle no_hz when idle
is being hammered at high frequency.

-Mike

Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to change compatible mode

[Dmitry Safonov]

2016-04-08 23:44 GMT+03:00 Andy Lutomirski :
> On Apr 8, 2016 9:20 AM, "Dmitry Safonov"  wrote:
>>
>>
>> And if it's not there - return error?
>
> No, just leave IP unchanged.

Ok, will resend with this fixup.

>
> Feel free to ask for help on some of these details.  user_64bit_mode
> will be helpful too.

Thanks.

>> I doubt, is it sane to remove
>> TS_COMPAT instead, leaving TIF_IA32, as for some cases
>> we need to know if task is compatible outside of syscall's path?
>
> No.  TS_COMPAT is important, and it's also better behaved than
> TIF_IA32 -- it has a very specific meaning: "am I currently executing
> a 32-bit syscall".
>
>
> The comment is wrong :). TS_COMPAT is true on int80 or 32-bit vdso
> syscall entries and is false otherwise.  64-bit tasks can use int80
> and, with your patches, will be able to use the 32-bit vdso entry as
> well.
>

Oh, yes, I see what you pointing, thanks, will work on it.

[PATCH v2] iio: max5487: Add support for Maxim digital potentiometers

[Cristina Moraru]

Add implementation for Maxim MAX5487, MAX5488, MAX5489
digital potentiometers.

Datasheet:
http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf

Signed-off-by: Cristina Moraru 
CC: Daniel Baluta 
---
Changes since v1:
Fix spacing
Eliminate max5487_cfg struct
Add kohms as driver data
 drivers/iio/potentiometer/Kconfig   |  11 +++
 drivers/iio/potentiometer/Makefile  |   1 +
 drivers/iio/potentiometer/max5487.c | 169 
 3 files changed, 181 insertions(+)
 create mode 100644 drivers/iio/potentiometer/max5487.c

diff --git a/drivers/iio/potentiometer/Kconfig 
b/drivers/iio/potentiometer/Kconfig
index fd75db7..242c62d 100644
--- a/drivers/iio/potentiometer/Kconfig
+++ b/drivers/iio/potentiometer/Kconfig
@@ -5,6 +5,17 @@
 
 menu "Digital potentiometers"
 
+config MAX5487
+tristate "Maxim MAX5487/MAX5488/MAX5489  Digital Potentiometer driver"
+depends on SPI
+help
+  Say yes here to build support for the Maxim
+  MAX5487, MAX5488, MAX5489 digital potentiomenter
+  chips.
+
+  To compile this driver as a module, choose M here: the
+  module will be called max5487.
+
 config MCP4531
tristate "Microchip MCP45xx/MCP46xx Digital Potentiometer driver"
depends on I2C
diff --git a/drivers/iio/potentiometer/Makefile 
b/drivers/iio/potentiometer/Makefile
index 8afe492..bc2dfd8 100644
--- a/drivers/iio/potentiometer/Makefile
+++ b/drivers/iio/potentiometer/Makefile
@@ -3,4 +3,5 @@
 #
 
 # When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_MAX5487) += max5487.o
 obj-$(CONFIG_MCP4531) += mcp4531.o
diff --git a/drivers/iio/potentiometer/max5487.c 
b/drivers/iio/potentiometer/max5487.c
new file mode 100644
index 000..fa455b8
--- /dev/null
+++ b/drivers/iio/potentiometer/max5487.c
@@ -0,0 +1,169 @@
+/*
+ * max5487.c - Support for MAX5487, MAX5488, MAX5489 digital potentiometers
+ *
+ * Copyright (C) Cristina-Gabriela Moraru 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define MAX5487_DRV_NAME "max5487"
+
+#define MAX5487_WRITE_WIPER_A  0x01
+#define MAX5487_WRITE_WIPER_B  0x02
+
+/* copy both wiper regs to NV regs */
+#define MAX5487_COPY_AB_TO_NV  0x23
+/* copy both NV regs to wiper regs */
+#define MAX5487_COPY_NV_TO_AB  0x33
+
+#define MAX5487_MAX_POS255
+
+struct max5487_data {
+   struct regmap *regmap;
+   int kohms;
+};
+
+#define MAX5487_CHANNEL(ch, addr) {\
+   .type = IIO_RESISTANCE, \
+   .indexed = 1,   \
+   .output = 1,\
+   .channel = ch,  \
+   .address = addr,\
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),   \
+}
+
+static const struct iio_chan_spec max5487_channels[] = {
+   MAX5487_CHANNEL(0, MAX5487_WRITE_WIPER_A),
+   MAX5487_CHANNEL(1, MAX5487_WRITE_WIPER_B),
+};
+
+static int max5487_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan,
+   int *val, int *val2, long mask)
+{
+   struct max5487_data *data = iio_priv(indio_dev);
+
+   if (mask != IIO_CHAN_INFO_SCALE)
+   return -EINVAL;
+
+   *val = 1000 * data->kohms;
+   *val2 = MAX5487_MAX_POS;
+   return IIO_VAL_FRACTIONAL;
+}
+
+static int max5487_write_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan,
+int val, int val2, long mask)
+{
+   struct max5487_data *data = iio_priv(indio_dev);
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   if (val < 0 || val > MAX5487_MAX_POS)
+   return -EINVAL;
+   return regmap_write(data->regmap, chan->address, val);
+   default:
+   return -EINVAL;
+   }
+   return -EINVAL;
+}
+
+static const struct iio_info max5487_info = {
+   .read_raw = &max5487_read_raw,
+   .write_raw = &max5487_write_raw,
+   .driver_module = THIS_MODULE,
+};
+
+static const struct regmap_config max5487_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+
+   .max_register = MAX5487_COPY_NV_TO_AB,
+};
+
+static int max5487_spi_probe(struct spi_device *spi)
+{
+   struct iio_dev *indio_dev;
+   struct max5487_data *data;
+   const struct spi_device_id *id = spi_get_device_id(spi);
+   int ret;
+
+   indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*data));
+   if (!indio_dev)
+

Re: [PATCH] mtd: nand: nuc900: allow compiling with COMPILE_TEST

[Rafał Miłecki]

On 9 April 2016 at 01:40, kbuild test robot  wrote:
> [auto build test WARNING on mtd/master]
> [also build test WARNING on v4.6-rc2 next-20160408]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/mtd-nand-nuc900-allow-compiling-with-COMPILE_TEST/20160408-185814
> base:   git://git.infradead.org/linux-mtd.git master
> config: blackfin-allyesconfig (attached as .config)
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=blackfin
>
> All warnings (new ones prefixed by >>):
>
>>> drivers/mtd/nand/nuc900_nand.c:36:0: warning: "SWRST" redefined [enabled by 
>>> default]
>arch/blackfin/mach-bf533/include/mach/defBF532.h:25:0: note: this is the 
> location of the previous definition

Uh, I'm not sure what to do about this. The name SWRST sounds a bit
generic so I guess it shouldn't be defined by any common header.

In case of blackfin it's part of the System Interrupt Controller and
other defines are prefixed with SIC_. Maybe we should rename
blackfin's SWRST to SIC_SWRST?

[PATCH] nilfs2: constify nilfs_sc_operations structures

[Julia Lawall]

The nilfs_sc_operations structures are never modified, so declare them
as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 fs/nilfs2/segment.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c
index 4317f72..483e663 100644
--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -617,7 +617,7 @@ static void nilfs_write_file_node_binfo(struct 
nilfs_sc_info *sci,
*vblocknr = binfo->bi_v.bi_vblocknr;
 }
 
-static struct nilfs_sc_operations nilfs_sc_file_ops = {
+static const struct nilfs_sc_operations nilfs_sc_file_ops = {
.collect_data = nilfs_collect_file_data,
.collect_node = nilfs_collect_file_node,
.collect_bmap = nilfs_collect_file_bmap,
@@ -666,7 +666,7 @@ static void nilfs_write_dat_node_binfo(struct nilfs_sc_info 
*sci,
*binfo_dat = binfo->bi_dat;
 }
 
-static struct nilfs_sc_operations nilfs_sc_dat_ops = {
+static const struct nilfs_sc_operations nilfs_sc_dat_ops = {
.collect_data = nilfs_collect_dat_data,
.collect_node = nilfs_collect_file_node,
.collect_bmap = nilfs_collect_dat_bmap,
@@ -674,7 +674,7 @@ static struct nilfs_sc_operations nilfs_sc_dat_ops = {
.write_node_binfo = nilfs_write_dat_node_binfo,
 };
 
-static struct nilfs_sc_operations nilfs_sc_dsync_ops = {
+static const struct nilfs_sc_operations nilfs_sc_dsync_ops = {
.collect_data = nilfs_collect_file_data,
.collect_node = NULL,
.collect_bmap = NULL,
@@ -1043,7 +1043,7 @@ static size_t nilfs_segctor_buffer_rest(struct 
nilfs_sc_info *sci)
 
 static int nilfs_segctor_scan_file(struct nilfs_sc_info *sci,
   struct inode *inode,
-  struct nilfs_sc_operations *sc_ops)
+  const struct nilfs_sc_operations *sc_ops)
 {
LIST_HEAD(data_buffers);
LIST_HEAD(node_buffers);
@@ -1550,7 +1550,7 @@ nilfs_segctor_update_payload_blocknr(struct nilfs_sc_info 
*sci,
sector_t blocknr;
unsigned long nfinfo = segbuf->sb_sum.nfinfo;
unsigned long nblocks = 0, ndatablk = 0;
-   struct nilfs_sc_operations *sc_op = NULL;
+   const struct nilfs_sc_operations *sc_op = NULL;
struct nilfs_segsum_pointer ssp;
struct nilfs_finfo *finfo = NULL;
union nilfs_binfo binfo;

Re: [PATCH 2/2] pci, acpi: free IO resource during shutdown

[Tomasz Nowicki]

On 08.04.2016 19:46, Sinan Kaya wrote:

Hi Tomasz,

On 4/8/2016 2:51 AM, Tomasz Nowicki wrote:

Hi Sinan,

On 08.04.2016 05:40, Sinan Kaya wrote:

Hi Tomasz,

On 4/7/2016 5:41 PM, Bjorn Helgaas wrote:

You say this is undoing the effect of pci_remap_iospace(), but that's

only called by native drivers and the generic (OF) driver, not by
pci_root.c.


See the ACPI root bridge driver above.

If this is a fix to patches that haven't been merged yet, we need to
squash the fix into the patches.



Can you merge these to two patches to your series for the next post?

I need to remove weak on the first patch per direction from Bjorn and
fix the function comments. You could as well do this while you are merging.

Let me know what your preference is.



Please do necessary fixes for your patches and send me the repo reference link. 
I will merge these to my patch set. Thanks!

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


I posted the updated patch here. Changes are:

- I squashed these two patches together per Bjorn's request.
- Removed the weak declarations from both remap and unmap calls.
- Fixed the doxygen document to match the actual parameters.

https://us.codeaurora.org/cgit/quic/server/kernel/commit/?h=okaya/pciunmapv2&id=6120a5f0c5e6d757f18a076917fa202e2c9823d0



Thanks Sinan!

Tomasz

[PATCH] ALSA: constify ct_timer_ops structures

[Julia Lawall]

The ct_timer_ops structures are never modified, so declare them as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 sound/pci/ctxfi/cttimer.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/pci/ctxfi/cttimer.c b/sound/pci/ctxfi/cttimer.c
index a5d4604..8f94534 100644
--- a/sound/pci/ctxfi/cttimer.c
+++ b/sound/pci/ctxfi/cttimer.c
@@ -49,7 +49,7 @@ struct ct_timer {
spinlock_t lock;/* global timer lock (for xfitimer) */
spinlock_t list_lock;   /* lock for instance list */
struct ct_atc *atc;
-   struct ct_timer_ops *ops;
+   const struct ct_timer_ops *ops;
struct list_head instance_head;
struct list_head running_head;
unsigned int wc;/* current wallclock */
@@ -128,7 +128,7 @@ static void ct_systimer_prepare(struct ct_timer_instance 
*ti)
 
 #define ct_systimer_free   ct_systimer_prepare
 
-static struct ct_timer_ops ct_systimer_ops = {
+static const struct ct_timer_ops ct_systimer_ops = {
.init = ct_systimer_init,
.free_instance = ct_systimer_free,
.prepare = ct_systimer_prepare,
@@ -322,7 +322,7 @@ static void ct_xfitimer_free_global(struct ct_timer *atimer)
ct_xfitimer_irq_stop(atimer);
 }
 
-static struct ct_timer_ops ct_xfitimer_ops = {
+static const struct ct_timer_ops ct_xfitimer_ops = {
.prepare = ct_xfitimer_prepare,
.start = ct_xfitimer_start,
.stop = ct_xfitimer_stop,

Re: [PATCH] mm: memcontrol: let v2 cgroups follow changes in system swappiness

[Vladimir Davydov]

On Fri, Apr 08, 2016 at 06:49:04PM -0400, Johannes Weiner wrote:
> Cgroup2 currently doesn't have a per-cgroup swappiness setting. We
> might want to add one later - that's a different discussion - but
> until we do, the cgroups should always follow the system setting.
> Otherwise it will be unchangeably set to whatever the ancestor
> inherited from the system setting at the time of cgroup creation.
> 
> Signed-off-by: Johannes Weiner 
> Cc: sta...@vger.kernel.org # 4.5

Acked-by: Vladimir Davydov 

Re: [PATCH] ALSA: constify ct_timer_ops structures

[Takashi Iwai]

On Sat, 09 Apr 2016 10:36:15 +0200,
Julia Lawall wrote:
> 
> The ct_timer_ops structures are never modified, so declare them as const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Applied, thanks.


Takashi

> 
> ---
>  sound/pci/ctxfi/cttimer.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/pci/ctxfi/cttimer.c b/sound/pci/ctxfi/cttimer.c
> index a5d4604..8f94534 100644
> --- a/sound/pci/ctxfi/cttimer.c
> +++ b/sound/pci/ctxfi/cttimer.c
> @@ -49,7 +49,7 @@ struct ct_timer {
>   spinlock_t lock;/* global timer lock (for xfitimer) */
>   spinlock_t list_lock;   /* lock for instance list */
>   struct ct_atc *atc;
> - struct ct_timer_ops *ops;
> + const struct ct_timer_ops *ops;
>   struct list_head instance_head;
>   struct list_head running_head;
>   unsigned int wc;/* current wallclock */
> @@ -128,7 +128,7 @@ static void ct_systimer_prepare(struct ct_timer_instance 
> *ti)
>  
>  #define ct_systimer_free ct_systimer_prepare
>  
> -static struct ct_timer_ops ct_systimer_ops = {
> +static const struct ct_timer_ops ct_systimer_ops = {
>   .init = ct_systimer_init,
>   .free_instance = ct_systimer_free,
>   .prepare = ct_systimer_prepare,
> @@ -322,7 +322,7 @@ static void ct_xfitimer_free_global(struct ct_timer 
> *atimer)
>   ct_xfitimer_irq_stop(atimer);
>  }
>  
> -static struct ct_timer_ops ct_xfitimer_ops = {
> +static const struct ct_timer_ops ct_xfitimer_ops = {
>   .prepare = ct_xfitimer_prepare,
>   .start = ct_xfitimer_start,
>   .stop = ct_xfitimer_stop,
> 
> 

[PATCH] qdisc: constify meta_type_ops structures

[Julia Lawall]

The meta_type_ops structures are never modified, so declare them as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 net/sched/em_meta.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/sched/em_meta.c b/net/sched/em_meta.c
index f2aabc0..a309a07 100644
--- a/net/sched/em_meta.c
+++ b/net/sched/em_meta.c
@@ -796,7 +796,7 @@ struct meta_type_ops {
int (*dump)(struct sk_buff *, struct meta_value *, int);
 };
 
-static struct meta_type_ops __meta_type_ops[TCF_META_TYPE_MAX + 1] = {
+static const struct meta_type_ops __meta_type_ops[TCF_META_TYPE_MAX + 1] = {
[TCF_META_TYPE_VAR] = {
.destroy = meta_var_destroy,
.compare = meta_var_compare,
@@ -812,7 +812,7 @@ static struct meta_type_ops 
__meta_type_ops[TCF_META_TYPE_MAX + 1] = {
}
 };
 
-static inline struct meta_type_ops *meta_type_ops(struct meta_value *v)
+static inline const struct meta_type_ops *meta_type_ops(struct meta_value *v)
 {
return &__meta_type_ops[meta_type(v)];
 }
@@ -870,7 +870,7 @@ static int em_meta_match(struct sk_buff *skb, struct 
tcf_ematch *m,
 static void meta_delete(struct meta_match *meta)
 {
if (meta) {
-   struct meta_type_ops *ops = meta_type_ops(&meta->lvalue);
+   const struct meta_type_ops *ops = meta_type_ops(&meta->lvalue);
 
if (ops && ops->destroy) {
ops->destroy(&meta->lvalue);
@@ -964,7 +964,7 @@ static int em_meta_dump(struct sk_buff *skb, struct 
tcf_ematch *em)
 {
struct meta_match *meta = (struct meta_match *) em->data;
struct tcf_meta_hdr hdr;
-   struct meta_type_ops *ops;
+   const struct meta_type_ops *ops;
 
memset(&hdr, 0, sizeof(hdr));
memcpy(&hdr.left, &meta->lvalue.hdr, sizeof(hdr.left));

Re: [PATCH V2] mtd: nand: pasemi: switch to pr_* functions

[Andy Shevchenko]

On Fri, Apr 8, 2016 at 2:13 PM, Rafał Miłecki  wrote:
> 1) Use pr_fmt to keep messages consistent
> 2) Don't warn if kzalloc fails as it dumps stack on its own
> 3) Use %pR format for displaying whole resource to avoid:
> warning: format ‘%08llx’ expects type ‘long long unsigned int’, but argument 
> 2 has type ‘resource_size_t’
>
> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/mtd/nand/pasemi_nand.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/pasemi_nand.c b/drivers/mtd/nand/pasemi_nand.c
> index 63fcb8c..e8372b4 100644
> --- a/drivers/mtd/nand/pasemi_nand.c
> +++ b/drivers/mtd/nand/pasemi_nand.c
> @@ -22,6 +22,8 @@
>
>  #undef DEBUG
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
>  #include 
>  #include 
>  #include 
> @@ -112,8 +114,6 @@ static int pasemi_nand_probe(struct platform_device 
> *ofdev)
> /* Allocate memory for MTD device structure and private data */
> chip = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
> if (!chip) {
> -   printk(KERN_WARNING
> -  "Unable to allocate PASEMI NAND MTD device 
> structure\n");
> err = -ENOMEM;
> goto out;
> }
> @@ -163,13 +163,12 @@ static int pasemi_nand_probe(struct platform_device 
> *ofdev)
> }
>
> if (mtd_device_register(pasemi_nand_mtd, NULL, 0)) {
> -   printk(KERN_ERR "pasemi_nand: Unable to register MTD 
> device\n");
> +   pr_err("Unable to register MTD device\n");

And why not to use dev_err(&ofdev->dev, …); ?

> err = -ENODEV;
> goto out_lpc;
> }
>
> -   printk(KERN_INFO "PA Semi NAND flash at %08llx, control at I/O %x\n",
> -  res.start, lpcctl);
> +   pr_info("PA Semi NAND flash at %pR, control at I/O %x\n", &res, 
> lpcctl);
>

Ditto.

> return 0;
>
> --
> 1.8.4.5
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 02/14] IOSF: Add interface for the cases requiring fid

[Andy Shevchenko]

On Sat, Apr 9, 2016 at 12:29 AM, Yang, Fei  wrote:
> Sorry, this one has wrong commit message, please comment on the other patch 
> with [PATCH 02/14] removed

Hm, I didn't see anything except this patch.
Perhaps you first go to our internal mailing list for preliminary review?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] sbs-battery: fix power status when battery charging near dry

[Daniel Kurtz]

On Wed, Apr 6, 2016 at 12:32 PM, YH Huang  wrote:
> POWER_SUPPLY_STATUS_NOT_CHARGING is used for AC connected, but
> battery not charging (e.g. because battery temperature is out
> of acceptable range).
>
> When battery is charging near dry and BATTERY_FULL_DISCHARGED is set,
> it is wrong to set as POWER_SUPPLY_STATUS_NOT_CHARGING.
> Just use BATTERY_DISCHARGING to decide the power supply status is
> discharging or charging.
>
> Signed-off-by: YH Huang 

Reviewed-by: Daniel Kurtz 

> ---
>  drivers/power/sbs-battery.c |4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/power/sbs-battery.c b/drivers/power/sbs-battery.c
> index d6226d6..768b9fc 100644
> --- a/drivers/power/sbs-battery.c
> +++ b/drivers/power/sbs-battery.c
> @@ -382,8 +382,6 @@ static int sbs_get_battery_property(struct i2c_client 
> *client,
>
> if (ret & BATTERY_FULL_CHARGED)
> val->intval = POWER_SUPPLY_STATUS_FULL;
> -   else if (ret & BATTERY_FULL_DISCHARGED)
> -   val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
> else if (ret & BATTERY_DISCHARGING)
> val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
> else
> @@ -702,8 +700,6 @@ static void sbs_delayed_work(struct work_struct *work)
>
> if (ret & BATTERY_FULL_CHARGED)
> ret = POWER_SUPPLY_STATUS_FULL;
> -   else if (ret & BATTERY_FULL_DISCHARGED)
> -   ret = POWER_SUPPLY_STATUS_NOT_CHARGING;
> else if (ret & BATTERY_DISCHARGING)
> ret = POWER_SUPPLY_STATUS_DISCHARGING;
> else
> --
> 1.7.9.5
>

LOAN

[darlehen]

Brauchen Sie einen Kredit? Wir bieten Darlehen in 2% gelten heute Kontakt mit 
uns auf: legacyassetgro...@hotmail.com

Re: [PATCH 03/15] irqchip/gic: Don't unnecessarily write the IRQ configuration

[Marc Zyngier]

On Thu, 17 Mar 2016 14:19:07 +
Jon Hunter  wrote:

> If the interrupt configuration matches the current configuration, then
> don't bother writing the configuration again.
> 
> Signed-off-by: Jon Hunter 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny.

[PATCH] bmips: add support for BCM63268

[Álvaro Fernández Rojas]

This SoC is very similar to BCM63168 and Broadcom usually refers to them as
BCM63268.
Add BCM63268 and missing BCM63168 to device tree documentation.

Signed-off-by: Álvaro Fernández Rojas 
Acked-by: Rob Herring 
---
 v3: use numerical order
 v2: keep support for BCM63168

 Documentation/devicetree/bindings/mips/brcm/soc.txt | 1 +
 arch/mips/bmips/setup.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mips/brcm/soc.txt 
b/Documentation/devicetree/bindings/mips/brcm/soc.txt
index e58a4f6..4a7e030 100644
--- a/Documentation/devicetree/bindings/mips/brcm/soc.txt
+++ b/Documentation/devicetree/bindings/mips/brcm/soc.txt
@@ -5,6 +5,7 @@ Required properties:
 - compatible: "brcm,bcm3384", "brcm,bcm33843"
   "brcm,bcm3384-viper", "brcm,bcm33843-viper"
   "brcm,bcm6328", "brcm,bcm6358", "brcm,bcm6368",
+  "brcm,bcm63168", "brcm,bcm63268",
   "brcm,bcm7125", "brcm,bcm7346", "brcm,bcm7358", "brcm,bcm7360",
   "brcm,bcm7362", "brcm,bcm7420", "brcm,bcm7425"
 
diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
index 38b5bd5..92d0483 100644
--- a/arch/mips/bmips/setup.c
+++ b/arch/mips/bmips/setup.c
@@ -116,6 +116,7 @@ static const struct bmips_quirk bmips_quirk_list[] = {
{ "brcm,bcm6358",   &bcm6358_quirks },
{ "brcm,bcm6368",   &bcm6368_quirks },
{ "brcm,bcm63168",  &bcm6368_quirks },
+   { "brcm,bcm63268",  &bcm6368_quirks },
{ },
 };
 
-- 
2.1.4

[PATCH 2/2] bmips: add device tree example for BCM6358

[Álvaro Fernández Rojas]

This adds a device tree example for SFR Neufbox4 (Sercomm version), which
also serves as a real example for brcm,bcm6358-leds.

Signed-off-by: Álvaro Fernández Rojas 
---
 v5: more device tree improvements
  - There is just ohci/ehci node.
  - Avoid using underscores in node names.
  - Use interrupt-controller for cpu_intc.
  - Rename uart aliases to serial.
 v4: Device tree improvements:
  - Switch to native-endian for syscon.
  - Switch to bcm6345-l1-intc interrupt controller.
  - Add ehci and ohci nodes.
 v3: Device tree fixes
  - Use interrupt-controller instead of periph_intc.
  - Use led@# instead of naming the LEDs.
 v2: Remove led0 alias and use stdout-path only

 .../devicetree/bindings/mips/brcm/soc.txt  |   2 +-
 arch/mips/bmips/Kconfig|   4 +
 arch/mips/boot/dts/brcm/Makefile   |   2 +
 arch/mips/boot/dts/brcm/bcm6358.dtsi   | 130 +
 arch/mips/boot/dts/brcm/bcm96358nb4ser.dts |  46 
 5 files changed, 183 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/boot/dts/brcm/bcm6358.dtsi
 create mode 100644 arch/mips/boot/dts/brcm/bcm96358nb4ser.dts

diff --git a/Documentation/devicetree/bindings/mips/brcm/soc.txt 
b/Documentation/devicetree/bindings/mips/brcm/soc.txt
index 7bab90c..e58a4f6 100644
--- a/Documentation/devicetree/bindings/mips/brcm/soc.txt
+++ b/Documentation/devicetree/bindings/mips/brcm/soc.txt
@@ -4,7 +4,7 @@ Required properties:
 
 - compatible: "brcm,bcm3384", "brcm,bcm33843"
   "brcm,bcm3384-viper", "brcm,bcm33843-viper"
-  "brcm,bcm6328", "brcm,bcm6368",
+  "brcm,bcm6328", "brcm,bcm6358", "brcm,bcm6368",
   "brcm,bcm7125", "brcm,bcm7346", "brcm,bcm7358", "brcm,bcm7360",
   "brcm,bcm7362", "brcm,bcm7420", "brcm,bcm7425"
 
diff --git a/arch/mips/bmips/Kconfig b/arch/mips/bmips/Kconfig
index e2c4fd6..264328d 100644
--- a/arch/mips/bmips/Kconfig
+++ b/arch/mips/bmips/Kconfig
@@ -21,6 +21,10 @@ config DT_BCM93384WVG_VIPER
bool "BCM93384WVG Viper CPU (EXPERIMENTAL)"
select BUILTIN_DTB
 
+config DT_BCM96358NB4SER
+   bool "BCM96358NB4SER"
+   select BUILTIN_DTB
+
 config DT_BCM96368MVWG
bool "BCM96368MVWG"
select BUILTIN_DTB
diff --git a/arch/mips/boot/dts/brcm/Makefile b/arch/mips/boot/dts/brcm/Makefile
index eabeb60..fda9d38 100644
--- a/arch/mips/boot/dts/brcm/Makefile
+++ b/arch/mips/boot/dts/brcm/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_DT_BCM93384WVG)   += bcm93384wvg.dtb
 dtb-$(CONFIG_DT_BCM93384WVG_VIPER) += bcm93384wvg_viper.dtb
+dtb-$(CONFIG_DT_BCM96358NB4SER)+= bcm96358nb4ser.dtb
 dtb-$(CONFIG_DT_BCM96368MVWG)  += bcm96368mvwg.dtb
 dtb-$(CONFIG_DT_BCM9EJTAGPRB)  += bcm9ejtagprb.dtb
 dtb-$(CONFIG_DT_BCM97125CBMB)  += bcm97125cbmb.dtb
@@ -14,6 +15,7 @@ dtb-$(CONFIG_DT_BCM97435SVMB) += bcm97435svmb.dtb
 dtb-$(CONFIG_DT_NONE)  += \
bcm93384wvg.dtb \
bcm93384wvg_viper.dtb   \
+   bcm96358nb4ser.dtb  \
bcm96368mvwg.dtb\
bcm9ejtagprb.dtb\
bcm97125cbmb.dtb\
diff --git a/arch/mips/boot/dts/brcm/bcm6358.dtsi 
b/arch/mips/boot/dts/brcm/bcm6358.dtsi
new file mode 100644
index 000..f9d8d39
--- /dev/null
+++ b/arch/mips/boot/dts/brcm/bcm6358.dtsi
@@ -0,0 +1,130 @@
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "brcm,bcm6358";
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mips-hpt-frequency = <15000>;
+
+   cpu@0 {
+   compatible = "brcm,bmips4350";
+   device_type = "cpu";
+   reg = <0>;
+   };
+
+   cpu@1 {
+   compatible = "brcm,bmips4350";
+   device_type = "cpu";
+   reg = <1>;
+   };
+   };
+
+   clocks {
+   periph_clk: periph-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   };
+   };
+
+   aliases {
+   serial0 = &uart0;
+   serial1 = &uart1;
+   };
+
+   cpu_intc: interrupt-controller {
+   #address-cells = <0>;
+   compatible = "mti,cpu-interrupt-controller";
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
+
+   ubus {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   compatible = "simple-bus";
+   ranges;
+
+   

[PATCH 1/2] bmips: add BCM6358 support

[Álvaro Fernández Rojas]

BCM6358 has a shared TLB which conflicts with current SMP support, so it must
be disabled for now.
BCM6358 uses >= 0xfffe addresses for internal registers, which need to be
remapped (by using a simplified version of BRCM63xx ioremap.h).
However, 0xfff8 is a better address, since it also covers BCM3368, leaving
the possibility to add it in the future.

Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes, resend
 v4: no changes, resend
 v3: Use a hardcoded constant for is_bmips_internal_registers (BCM3368 base
  address)
 v2: Use a different approach for remapping internal registers

 arch/mips/bmips/setup.c| 10 +
 arch/mips/include/asm/mach-bmips/ioremap.h | 33 ++
 2 files changed, 43 insertions(+)
 create mode 100644 arch/mips/include/asm/mach-bmips/ioremap.h

diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
index 3553528..38b5bd5 100644
--- a/arch/mips/bmips/setup.c
+++ b/arch/mips/bmips/setup.c
@@ -95,6 +95,15 @@ static void bcm6328_quirks(void)
bcm63xx_fixup_cpu1();
 }
 
+static void bcm6358_quirks(void)
+{
+   /*
+* BCM6358 needs special handling for its shared TLB, so
+* disable SMP for now
+*/
+   bmips_smp_enabled = 0;
+}
+
 static void bcm6368_quirks(void)
 {
bcm63xx_fixup_cpu1();
@@ -104,6 +113,7 @@ static const struct bmips_quirk bmips_quirk_list[] = {
{ "brcm,bcm3384-viper", &bcm3384_viper_quirks   },
{ "brcm,bcm33843-viper",&bcm3384_viper_quirks   },
{ "brcm,bcm6328",   &bcm6328_quirks },
+   { "brcm,bcm6358",   &bcm6358_quirks },
{ "brcm,bcm6368",   &bcm6368_quirks },
{ "brcm,bcm63168",  &bcm6368_quirks },
{ },
diff --git a/arch/mips/include/asm/mach-bmips/ioremap.h 
b/arch/mips/include/asm/mach-bmips/ioremap.h
new file mode 100644
index 000..29c7a7b
--- /dev/null
+++ b/arch/mips/include/asm/mach-bmips/ioremap.h
@@ -0,0 +1,33 @@
+#ifndef __ASM_MACH_BMIPS_IOREMAP_H
+#define __ASM_MACH_BMIPS_IOREMAP_H
+
+#include 
+
+static inline phys_addr_t fixup_bigphys_addr(phys_addr_t phys_addr, 
phys_addr_t size)
+{
+   return phys_addr;
+}
+
+static inline int is_bmips_internal_registers(phys_addr_t offset)
+{
+   if (offset >= 0xfff8)
+   return 1;
+
+   return 0;
+}
+
+static inline void __iomem *plat_ioremap(phys_addr_t offset, unsigned long 
size,
+unsigned long flags)
+{
+   if (is_bmips_internal_registers(offset))
+   return (void __iomem *)offset;
+
+   return NULL;
+}
+
+static inline int plat_iounmap(const volatile void __iomem *addr)
+{
+   return is_bmips_internal_registers((unsigned long)addr);
+}
+
+#endif /* __ASM_MACH_BMIPS_IOREMAP_H */
-- 
2.1.4

[PATCH 1/2] MIPS: BMIPS: improve BCM6328 device tree

[Álvaro Fernández Rojas]

- Remove unneeded leds0 alias.
- Switch to bcm6345-l1-intc interrupt controller.
- Use interrupt-controller instead of periph_intc and cpu_intc.
- Add uart1, ehci and ohci nodes.
- Refactor syscon and syscon-reboot.
- Avoid using underscores in node names.
- Rename uart aliases to serial.

Signed-off-by: Álvaro Fernández Rojas 
---
 v2: more device tree improvements
  - There is just ohci/ehci node.
  - Avoid using underscores in node names.
  - Use interrupt-controller for cpu_intc.
  - Rename uart aliases to serial.

 arch/mips/boot/dts/brcm/bcm6328.dtsi | 50 
 1 file changed, 39 insertions(+), 11 deletions(-)

diff --git a/arch/mips/boot/dts/brcm/bcm6328.dtsi 
b/arch/mips/boot/dts/brcm/bcm6328.dtsi
index 9d19236..5633b9d 100644
--- a/arch/mips/boot/dts/brcm/bcm6328.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm6328.dtsi
@@ -23,7 +23,7 @@
};
 
clocks {
-   periph_clk: periph_clk {
+   periph_clk: periph-clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <5000>;
@@ -31,11 +31,11 @@
};
 
aliases {
-   leds0 = &leds0;
-   uart0 = &uart0;
+   serial0 = &uart0;
+   serial1 = &uart1;
};
 
-   cpu_intc: cpu_intc {
+   cpu_intc: interrupt-controller {
#address-cells = <0>;
compatible = "mti,cpu-interrupt-controller";
 
@@ -50,16 +50,16 @@
compatible = "simple-bus";
ranges;
 
-   periph_intc: periph_intc@1020 {
-   compatible = "brcm,bcm3380-l2-intc";
-   reg = <0x1024 0x4 0x102c 0x4>,
- <0x1020 0x4 0x1028 0x4>;
+   periph_intc: interrupt-controller@1020 {
+   compatible = "brcm,bcm6345-l1-intc";
+   reg = <0x1020 0x10>,
+ <0x1030 0x10>;
 
interrupt-controller;
#interrupt-cells = <1>;
 
interrupt-parent = <&cpu_intc>;
-   interrupts = <2>;
+   interrupts = <2>, <3>;
};
 
uart0: serial@1100 {
@@ -71,13 +71,22 @@
status = "disabled";
};
 
-   timer: timer@1040 {
+   uart1: serial@1120 {
+   compatible = "brcm,bcm6345-uart";
+   reg = <0x1120 0x18>;
+   interrupt-parent = <&periph_intc>;
+   interrupts = <39>;
+   clocks = <&periph_clk>;
+   status = "disabled";
+   };
+
+   timer: syscon@1040 {
compatible = "syscon";
reg = <0x1040 0x2c>;
native-endian;
};
 
-   reboot {
+   reboot: syscon-reboot@1068 {
compatible = "syscon-reboot";
regmap = <&timer>;
offset = <0x28>;
@@ -91,5 +100,24 @@
reg = <0x1800 0x24>;
status = "disabled";
};
+
+   ehci: usb@10002500 {
+   compatible = "brcm,bcm6328-ehci", "generic-ehci";
+   reg = <0x10002500 0x100>;
+   big-endian;
+   interrupt-parent = <&periph_intc>;
+   interrupts = <42>;
+   status = "disabled";
+   };
+
+   ohci: usb@10002600 {
+   compatible = "brcm,bcm6328-ohci", "generic-ohci";
+   reg = <0x10002600 0x100>;
+   big-endian;
+   no-big-frame-no;
+   interrupt-parent = <&periph_intc>;
+   interrupts = <41>;
+   status = "disabled";
+   };
};
 };
-- 
2.1.4

[PATCH 2/2] MIPS: BMIPS: improve BCM6368 device tree

[Álvaro Fernández Rojas]

- Remove unneeded leds0 alias.
- Switch to bcm6345-l1-intc interrupt controller.
- Use interrupt-controller instead of periph_intc and cpu_intc.
- Add uart1 node.
- Single ohci and ehci nodes.
- Avoid using underscores in node names.
- Rename uart aliases to serial.
- Remove blank line in cpus node.

Signed-off-by: Álvaro Fernández Rojas 
---
 v2: more device tree improvements
  - There is just ohci/ehci node.
  - Avoid using underscores in node names.
  - Use interrupt-controller for cpu_intc.
  - Rename uart aliases to serial.
  - Remove blank line.

 arch/mips/boot/dts/brcm/bcm6368.dtsi | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/arch/mips/boot/dts/brcm/bcm6368.dtsi 
b/arch/mips/boot/dts/brcm/bcm6368.dtsi
index 1f6b9b5..d0e3a70 100644
--- a/arch/mips/boot/dts/brcm/bcm6368.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm6368.dtsi
@@ -20,11 +20,10 @@
device_type = "cpu";
reg = <1>;
};
-
};
 
clocks {
-   periph_clk: periph_clk {
+   periph_clk: periph-clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <5000>;
@@ -32,11 +31,11 @@
};
 
aliases {
-   leds0 = &leds0;
-   uart0 = &uart0;
+   serial0 = &uart0;
+   serial1 = &uart1;
};
 
-   cpu_intc: cpu_intc {
+   cpu_intc: interrupt-controller {
#address-cells = <0>;
compatible = "mti,cpu-interrupt-controller";
 
@@ -64,16 +63,16 @@
mask = <0x1>;
};
 
-   periph_intc: periph_intc@1020 {
-   compatible = "brcm,bcm3380-l2-intc";
-   reg = <0x1024 0x4 0x102c 0x4>,
- <0x1020 0x4 0x1028 0x4>;
+   periph_intc: interrupt-controller@1020 {
+   compatible = "brcm,bcm6345-l1-intc";
+   reg = <0x1020 0x10>,
+ <0x1030 0x10>;
 
interrupt-controller;
#interrupt-cells = <1>;
 
interrupt-parent = <&cpu_intc>;
-   interrupts = <2>;
+   interrupts = <2>, <3>;
};
 
leds0: led-controller@10d0 {
@@ -93,7 +92,16 @@
status = "disabled";
};
 
-   ehci0: usb@10001500 {
+   uart1: serial@1120 {
+   compatible = "brcm,bcm6345-uart";
+   reg = <0x1120 0x18>;
+   interrupt-parent = <&periph_intc>;
+   interrupts = <3>;
+   clocks = <&periph_clk>;
+   status = "disabled";
+   };
+
+   ehci: usb@10001500 {
compatible = "brcm,bcm6368-ehci", "generic-ehci";
reg = <0x10001500 0x100>;
big-endian;
@@ -102,7 +110,7 @@
status = "disabled";
};
 
-   ohci0: usb@10001600 {
+   ohci: usb@10001600 {
compatible = "brcm,bcm6368-ohci", "generic-ohci";
reg = <0x10001600 0x100>;
big-endian;
-- 
2.1.4

Re: [PATCH 04/15] irqchip/gic: WARN if setting the interrupt type fails

[Marc Zyngier]

On Thu, 17 Mar 2016 15:04:01 +
Jon Hunter  wrote:

> 
> On 17/03/16 14:51, Thomas Gleixner wrote:
> > On Thu, 17 Mar 2016, Jon Hunter wrote:
> > 
> >> Setting the interrupt type for private peripheral interrupts (PPIs) may
> >> not be supported by a given GIC because it is IMPLEMENTATION DEFINED
> >> whether this is allowed. There is no way to know if setting the type is
> >> supported for a given GIC and so the value written is read back to
> >> verify it matches the desired configuration. If it does not match then
> >> an error is return.
> >>
> >> There are cases where the interrupt configuration read from firmware
> >> (such as a device-tree blob), has been incorrect and hence
> >> gic_configure_irq() has returned an error. This error has gone
> >> undetected because the error code returned was ignored but the interrupt
> >> still worked fine because the configuration for the interrupt could not
> >> be overwritten.
> >>
> >> Given that this has done undetected and we should only fail to set the
> >> type for PPIs whose configuration cannot be changed anyway, don't return
> >> an error and simply WARN if this fails. This will allows us to fix up any
> >> places in the kernel where we should be checking the return status and
> >> maintain back compatibility with firmware images that may have incorrect
> >> interrupt configurations.
> > 
> > Though silently returning 0 is really the wrong thing to do. You can add the
> > warn, but why do you want to return success?
> 
> Yes that would be the correct thing to do I agree. However, the problem
> is that if we do this, then after the patch "irqdomain: Don't set type
> when mapping an IRQ" is applied, we may break interrupts for some
> existing device-tree binaries that have bad configuration (such as omap4
> and tegra20/30 ... see patches 1 and 2) that have gone unnoticed. So it
> is a back compatibility issue.
> 
> If you are wondering why these interrupts break after "irqdomain: Don't
> set type when mapping an IRQ", it is because today
> irq_create_fwspec_mapping() does not check the return code from setting
> the type, but if we defer setting the type until __setup_irq() which
> does check the return code, then all of a sudden interrupts that were
> working (even with bad configurations) start to fail.
> 
> The reason why I opted not to return an error code from
> gic_configure_irq() is it really can't fail. The failure being reported
> does not prevent the interrupt from working, but tells you your
> configuration does not match the hardware setting which you cannot
> overwrite.
> 
> So to maintain back compatibility and avoid any silent errors, I opted
> to make it a WARN and not return an error.
> 
> If people are ok with potentially breaking interrupts for device-tree
> binaries with bad settings, then I am ok to return an error here.

I think we need to phase things. Let's start with warning people for a
few kernel releases. Actively maintained platforms will quickly address
the issue (fixing their DT). As I see it, this issue seems rather
widespread (even kvmtool outputs a DT with the wrong triggering
information).

Once we've fixed the bulk of the platforms and virtual environments, we
can start thinking about making it fail harder.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

Re: Odroid XU4 deadlock

[Krzysztof Kozlowski]

On Fri, Apr 8, 2016 at 5:36 PM, Anand Moon  wrote:
> hi Javier,
>
> On 8 April 2016 at 20:25, Javier Martinez Canillas
>  wrote:
>> Hello Anand,
>>
>> On 04/08/2016 09:51 AM, Anand Moon wrote:
>>> Hi All,
>>>
>>> I am observing this deadlock or warning on my Odroid XU4.
>>> I thinks the is related to clk from exynos5_i2c_xfer  clk_prepare_enable
>>> but I am not able to figure out which clk.
>>>
>>
>> By reading your logs, it seems the problem is a possible ABBA deadlock since
>> the S3C RTC driver grabs the prepare_lock and then the regmap->lock, and the
>> CPUFreq driver leads to the locks being grabbed in the inverse order.

First of all this is not a deadlock. Yet. :) This is just lockdep
report of possible deadlock. This is deadlock:
http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7/builds/13/steps/Boot%20odroid/logs/serial

...and I believe it is the same as the report from lockdep. Which
means that this report truly a predicted deadlock. There are minor
differences between deadlock on my board and report from Anand but
still the same devices are involved. In Anands report the involved
S2MPS11 regulator and S2MPS11 clock use the same regmap. In my case
one path comes from S5M RTC which uses different regmap than S2MPS11
clock. This is the difference which puzzles me.

Anyway this is known issue. In case of my board mentioned deadlock
happens only on multi_v7 on around 15% of boots. I noticed it around
v4.4 and it happens still.

>>
>>> [   11.640221] ==
>>> [   11.646343] [ INFO: possible circular locking dependency detected ]
>>> [   11.652590] 4.6.0-rc2-xu4ml #35 Not tainted
>>> [   11.656749] ---
>>> [   11.662992] kworker/1:1/85 is trying to acquire lock:
>>> [   11.668010]  (prepare_lock){+.+...}, at: []
>>> clk_prepare_lock+0x50/0xf8
>>> [   11.675375]
>>> [   11.675375] but task is already holding lock:
>>> [   11.681185]  (sec_core:428:(regmap)->lock){+.+...}, at:
>>> [] regmap_read+0x2c/0x5c
>>> [   11.689417]
>>> [   11.689417] which lock already depends on the new lock.
>>> [   11.689417]
>>> [   11.697561]
>>> [   11.697561] the existing dependency chain (in reverse order) is:
>>> [   11.705008]
>>> [   11.705008] -> #1 (sec_core:428:(regmap)->lock){+.+...}:
>>> [   11.710467][] regmap_update_bits_base+0x30/0x70
>>> [   11.716545][] s2mps11_clk_prepare+0x30/0x38
>>> [   11.722262][] clk_core_prepare+0x98/0xbc
>>> [   11.727711][] clk_prepare+0x1c/0x2c
>>> [   11.732734][] s3c_rtc_probe+0x2d0/0x43c
>>
>> the S3C RTC driver tries to prepare the RTC source clock S2MPS11_CLK_AP
>> and that leads to the prepare_lock to be held and then the regmap->lock
>> since s2mps11_clk_prepare() calls regmap_update_bits().
>>
>>> [   11.738108][] platform_drv_probe+0x4c/0xb0
>>> [   11.743749][] driver_probe_device+0x20c/0x2b8
>>> [   11.749641][] bus_for_each_drv+0x60/0x94
>>> [   11.755103][] __device_attach+0xb4/0x118
>>> [   11.760558][] bus_probe_device+0x88/0x90
>>> [   11.766020][] deferred_probe_work_func+0x6c/0x9c
>>> [   11.772169][] process_one_work+0x1a8/0x514
>>> [   11.777806][] worker_thread+0x38/0x56c
>>> [   11.783082][] kthread+0xf4/0x10c
>>> [   11.787847][] ret_from_fork+0x14/0x24
>>> [   11.793050]
>>> [   11.793050] -> #0 (prepare_lock){+.+...}:
>>> [   11.797212][] mutex_lock_nested+0x78/0x4dc
>>> [   11.802845][] clk_prepare_lock+0x50/0xf8
>>> [   11.808304][] clk_unprepare+0x1c/0x2c
>>> [   11.813499][] exynos5_i2c_xfer+0x1dc/0x304
>>
>> and here the locks are grabbed in the inverse order, since the regulator
>> driver uses regmap read (grabbing the regmap->lock) and then a clock is
>> prepared in exynos5_i2c_xfer.
>>
>>> [   11.819129][] __i2c_transfer+0x13c/0x278
>>> [   11.824589][] i2c_transfer+0x94/0xc4
>>> [   11.829701][] regmap_i2c_read+0x48/0x64
>>> [   11.835074][] _regmap_raw_read+0xb4/0x114
>>> [   11.840630][] _regmap_bus_read+0x24/0x58
>>> [   11.846084][] _regmap_read+0x60/0xb8
>>> [   11.851201][] regmap_read+0x3c/0x5c
>>> [   11.856224][] 
>>> regulator_get_voltage_sel_regmap+0x20/0x54
>>> [   11.863109][] _regulator_get_voltage+0x20/0xb8
>>> [   11.863141][] _regulator_do_set_voltage+0x240/0x370
>>> [   11.863173][] regulator_set_voltage_unlocked+0xcc/0x230
>>> [   11.863205][] regulator_set_voltage+0x28/0x54
>>> [   11.863234][] _set_opp_voltage+0x30/0x98
>>> [   11.863264][] dev_pm_opp_set_rate+0x1e0/0x540
>>> [   11.863337][] __cpufreq_driver_target+0x168/0x290
>>> [   11.863375][] od_dbs_timer+0xdc/0x164
>>> [   11.863407][] dbs_work_handler+0x30/0x58
>>> [   11.863437][] process_one_work+0x1a8/0x514
>>> [   11.863465][] worker_thread+0x38/0x56c
>>> [  

Re: [PATCH 05/15] irqchip: Mask the non-type/sense bits when translating an IRQ

[Marc Zyngier]

On Thu, 17 Mar 2016 14:19:09 +
Jon Hunter  wrote:

> The firmware parameter that contains the IRQ sense bits may also contain
> other data. When return the IRQ type, bits outside of these sense bits
> should be masked. If these bits are not masked and
> irq_create_fwspec_mapping() is called to map an IRQ, then the comparison
> of the type returned from irq_domain_translate() will never match
> that returned by irq_get_trigger_type() (because this function masks the
> none sense bits) and so we will always call irq_set_irq_type() to program
> the type even if it was not really necessary.
> 
> Currently, the downside to this is unnecessarily re-programmming the type
> but nevertheless this should be avoided.
> 
> The Tegra LIC, TI Crossbar and GIC-V3 irqchips all have client instances
> (from reviewing the device-tree sources) where bits outside the IRQ sense
> bits are set, but do not mask these bits. Therefore, ensure these bits
> are masked for these irqchips.

For GICv3, this shouldn't be the case. The DT clearly says that the 3rd
field should only contain the trigger description. It looks like people
have been copying their GICv2 DT and simply slapped the v3 description
in the middle, without changing their interrupt specifiers. Duh.

I guess this patch doesn't hurt though.

> 
> Signed-off-by: Jon Hunter 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny.

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

[Peter Zijlstra]

On Fri, Apr 08, 2016 at 10:59:59PM +0200, Rafael J. Wysocki wrote:
> On Friday, April 08, 2016 08:50:54 AM Mike Galbraith wrote:
> > On Fri, 2016-04-08 at 08:45 +0200, Peter Zijlstra wrote:
> > 
> > > Cute, I thought you used governor=performance for your runs?
> > 
> > I do, and those numbers are with it thus set.
> 
> Well, this is a trade-off.
> 
> 4.5 introduced a power regression here so this one goes back to the previous
> state of things.

Just for my elucidation; how can gov=performance have a 'power'
regression?

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

[Peter Zijlstra]

On Fri, Apr 08, 2016 at 03:19:14PM -0700, Doug Smythies wrote:
> Could you send me, or point me to, the program "pipe-test"?
> So far, I have only found one, but it is both old and not
> the same program you are running (based on print statements).

The latest public one lives as: perf bench sched pipe

Re: [PATCH 09/15] irqchip/gic: Don't initialise chip if mapping IO space fails

[Marc Zyngier]

On Thu, 17 Mar 2016 14:19:13 +
Jon Hunter  wrote:

> If we fail to map the address space for the GIC distributor or CPU
> interface, then don't attempt to initialise the chip, just WARN and
> return.
> 
> Signed-off-by: Jon Hunter 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny.

Re: [PATCH v2] iio: potentiometer: add driver for Maxim Integrated DS1803

[Slawomir Stepien]

On Apr 08, 2016 23:27, Slawomir Stepien wrote:
> +static int ds1803_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct ds1803_data *data = iio_priv(indio_dev);
> + int pot = chan->channel;
> + int ret;
> + u16 result;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + ret = i2c_master_recv(data->client, (char *)&result,
> + indio_dev->num_channels);
> + if (ret < 0)
> + return ret;
> +
> + /* Get bits for given pot */
> + *val = (pot == 0 ? result & 0xff : result >> 8);
> + return IIO_VAL_INT;
> +
> + case IIO_CHAN_INFO_SCALE:
> + *val = 1000 * data->cfg->kohms;
> + *val2 = DS1803_MAX_POS;
> + return IIO_VAL_FRACTIONAL;
> + }
> +
> + return -EINVAL;
> +}

Or maybe this is more clean?

static int ds1803_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val, int *val2, long mask)
{
struct ds1803_data *data = iio_priv(indio_dev);
int pot = chan->channel;
int ret;
unsigned char result[indio_dev->num_channels];

switch (mask) {
case IIO_CHAN_INFO_RAW:
ret = i2c_master_recv(data->client, result,
indio_dev->num_channels);
if (ret < 0)
return ret;

*val = result[pot];
return IIO_VAL_INT;

case IIO_CHAN_INFO_SCALE:
*val = 1000 * data->cfg->kohms;
*val2 = DS1803_MAX_POS;
return IIO_VAL_FRACTIONAL;
}

return -EINVAL;
}

What do you think?

-- 
Slawomir Stepien

[PATCH] USB: ftdi_sio: constify ftdi_sio_quirk structures

[Julia Lawall]

The ftdi_sio_quirk structures are never modified, so declare them as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/usb/serial/ftdi_sio.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 3a814e8..0082080 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -93,27 +93,27 @@ static int   ftdi_8u2232c_probe(struct usb_serial *serial);
 static void  ftdi_USB_UIRT_setup(struct ftdi_private *priv);
 static void  ftdi_HE_TIRA1_setup(struct ftdi_private *priv);
 
-static struct ftdi_sio_quirk ftdi_jtag_quirk = {
+static const struct ftdi_sio_quirk ftdi_jtag_quirk = {
.probe  = ftdi_jtag_probe,
 };
 
-static struct ftdi_sio_quirk ftdi_NDI_device_quirk = {
+static const struct ftdi_sio_quirk ftdi_NDI_device_quirk = {
.probe  = ftdi_NDI_device_setup,
 };
 
-static struct ftdi_sio_quirk ftdi_USB_UIRT_quirk = {
+static const struct ftdi_sio_quirk ftdi_USB_UIRT_quirk = {
.port_probe = ftdi_USB_UIRT_setup,
 };
 
-static struct ftdi_sio_quirk ftdi_HE_TIRA1_quirk = {
+static const struct ftdi_sio_quirk ftdi_HE_TIRA1_quirk = {
.port_probe = ftdi_HE_TIRA1_setup,
 };
 
-static struct ftdi_sio_quirk ftdi_stmclite_quirk = {
+static const struct ftdi_sio_quirk ftdi_stmclite_quirk = {
.probe  = ftdi_stmclite_probe,
 };
 
-static struct ftdi_sio_quirk ftdi_8u2232c_quirk = {
+static const struct ftdi_sio_quirk ftdi_8u2232c_quirk = {
.probe  = ftdi_8u2232c_probe,
 };
 
@@ -1775,7 +1775,7 @@ static void remove_sysfs_attrs(struct usb_serial_port 
*port)
 static int ftdi_sio_probe(struct usb_serial *serial,
const struct usb_device_id *id)
 {
-   struct ftdi_sio_quirk *quirk =
+   const struct ftdi_sio_quirk *quirk =
(struct ftdi_sio_quirk *)id->driver_info;
 
if (quirk && quirk->probe) {
@@ -1792,7 +1792,7 @@ static int ftdi_sio_probe(struct usb_serial *serial,
 static int ftdi_sio_port_probe(struct usb_serial_port *port)
 {
struct ftdi_private *priv;
-   struct ftdi_sio_quirk *quirk = usb_get_serial_data(port->serial);
+   const struct ftdi_sio_quirk *quirk = usb_get_serial_data(port->serial);
 
 
priv = kzalloc(sizeof(struct ftdi_private), GFP_KERNEL);

[PATCH] uprobes/x86: constify uprobe_xol_ops structures

[Julia Lawall]

The uprobe_xol_ops structures are never modified, so declare them as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 arch/x86/kernel/uprobes.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index bf4db6e..bd07415 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -578,7 +578,7 @@ static void default_abort_op(struct arch_uprobe *auprobe, 
struct pt_regs *regs)
riprel_post_xol(auprobe, regs);
 }
 
-static struct uprobe_xol_ops default_xol_ops = {
+static const struct uprobe_xol_ops default_xol_ops = {
.pre_xol  = default_pre_xol_op,
.post_xol = default_post_xol_op,
.abort= default_abort_op,
@@ -695,7 +695,7 @@ static void branch_clear_offset(struct arch_uprobe 
*auprobe, struct insn *insn)
0, insn->immediate.nbytes);
 }
 
-static struct uprobe_xol_ops branch_xol_ops = {
+static const struct uprobe_xol_ops branch_xol_ops = {
.emulate  = branch_emulate_op,
.post_xol = branch_post_xol_op,
 };

Re: [PATCH 10/15] irqchip/gic: Remove static irq_chip definition for eoimode1

[Marc Zyngier]

On Thu, 17 Mar 2016 14:19:14 +
Jon Hunter  wrote:

> There are only 3 differences (not including the name) in the definitions
> of the gic_chip and gic_eoimode1_chip structures. Instead of statically
> defining the gic_eoimode1_chip structure, remove it and populate the
> eoimode1 functions dynamically for the appropriate GIC irqchips.
> 
> Signed-off-by: Jon Hunter 

Linus' remark notwithstanding,

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny.

Re: [PATCH 11/15] irqchip/gic: Return an error if GIC initialisation fails

[Marc Zyngier]

On Thu, 17 Mar 2016 14:19:15 +
Jon Hunter  wrote:

> If the GIC initialisation fails, then currently we do not return an error
> or clean-up afterwards. Although for root controllers, this failure may be
> fatal anyway, for secondary controllers, it may not be fatal and so return
> an error on failure and clean-up.
> 
> For non-banked GIC controllers, make sure that we free any memory
> allocated if we fail to initialise the IRQ domain. Please note that
> free_percpu() only frees memory if the pointer passed to it is not NULL
> and so it is unnecessary to check if both pointers are valid or not.
> 
> Signed-off-by: Jon Hunter 
> ---
>  drivers/irqchip/irq-gic.c | 57 
> ++-
>  1 file changed, 41 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index b0a781f8c450..42a1412b5186 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -999,13 +999,13 @@ static const struct irq_domain_ops gic_irq_domain_ops = 
> {
>   .unmap = gic_irq_domain_unmap,
>  };
>  
> -static void __init __gic_init_bases(unsigned int gic_nr, int irq_start,
> +static int __init __gic_init_bases(unsigned int gic_nr, int irq_start,
>  void __iomem *dist_base, void __iomem *cpu_base,
>  u32 percpu_offset, struct fwnode_handle *handle)
>  {
>   irq_hw_number_t hwirq_base;
>   struct gic_chip_data *gic;
> - int gic_irqs, irq_base, i;
> + int gic_irqs, irq_base, i, ret;
>  
>   BUG_ON(gic_nr >= CONFIG_ARM_GIC_MAX_NR);
>  
> @@ -1030,17 +1030,16 @@ static void __init __gic_init_bases(unsigned int 
> gic_nr, int irq_start,
>   gic->chip.irq_set_affinity = gic_set_affinity;
>  #endif
>  
> -#ifdef CONFIG_GIC_NON_BANKED
> - if (percpu_offset) { /* Frankein-GIC without banked registers... */
> + if (IS_ENABLED(CONFIG_GIC_NON_BANKED) && percpu_offset) {
> + /* Frankein-GIC without banked registers... */
>   unsigned int cpu;
>  
>   gic->dist_base.percpu_base = alloc_percpu(void __iomem *);
>   gic->cpu_base.percpu_base = alloc_percpu(void __iomem *);
>   if (WARN_ON(!gic->dist_base.percpu_base ||
>   !gic->cpu_base.percpu_base)) {
> - free_percpu(gic->dist_base.percpu_base);
> - free_percpu(gic->cpu_base.percpu_base);
> - return;
> + ret = -ENOMEM;
> + goto error;
>   }
>  
>   for_each_possible_cpu(cpu) {
> @@ -1052,9 +1051,8 @@ static void __init __gic_init_bases(unsigned int 
> gic_nr, int irq_start,
>   }
>  
>   gic_set_base_accessor(gic, gic_get_percpu_base);
> - } else
> -#endif
> - {   /* Normal, sane GIC... */
> + } else {
> + /* Normal, sane GIC... */
>   WARN(percpu_offset,
>"GIC_NON_BANKED not enabled, ignoring %08x offset!",
>percpu_offset);
> @@ -1104,8 +1102,10 @@ static void __init __gic_init_bases(unsigned int 
> gic_nr, int irq_start,
>   hwirq_base, &gic_irq_domain_ops, gic);
>   }
>  
> - if (WARN_ON(!gic->domain))
> - return;
> + if (WARN_ON(!gic->domain)) {
> + ret = -ENODEV;
> + goto error;
> + }
>  
>   if (gic_nr == 0) {
>   /*
> @@ -1127,6 +1127,18 @@ static void __init __gic_init_bases(unsigned int 
> gic_nr, int irq_start,
>   gic_dist_init(gic);
>   gic_cpu_init(gic);
>   gic_pm_init(gic);
> +
> + return 0;
> +
> +error:
> + if (IS_ENABLED(CONFIG_GIC_NON_BANKED) && percpu_offset) {
> + free_percpu(gic->dist_base.percpu_base);
> + free_percpu(gic->cpu_base.percpu_base);
> + }
> +
> + kfree(gic->chip.name);

Ah, this is where Linus' remark about "GICv2" clashes. Either you keep
the allocation in the previous patch, or you guard this with a test on
the EOImode. I'll leave it up to you.

> +
> + return ret;
>  }
>  
>  void __init gic_init(unsigned int gic_nr, int irq_start,
> @@ -1187,7 +1199,7 @@ gic_of_init(struct device_node *node, struct 
> device_node *parent)
>   void __iomem *cpu_base;
>   void __iomem *dist_base;
>   u32 percpu_offset;
> - int irq;
> + int irq, ret;
>  
>   if (WARN_ON(!node))
>   return -ENODEV;
> @@ -1212,8 +1224,14 @@ gic_of_init(struct device_node *node, struct 
> device_node *parent)
>   if (of_property_read_u32(node, "cpu-offset", &percpu_offset))
>   percpu_offset = 0;
>  
> - __gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
> + ret = __gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
>&node->fwnode);
> + if (ret) {
> + iounmap(dist_base);
> + iounmap(cpu_

Re: [PATCH] perf trace: Add support for printing call chains on sys_exit events.

[Milian Wolff]

On Freitag, 8. April 2016 15:18:53 CEST Arnaldo Carvalho de Melo wrote:
> Em Fri, Apr 08, 2016 at 02:57:54PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Apr 08, 2016 at 01:34:15PM +0200, Milian Wolff escreveu:
> > > Now, one can print the call chain for every encountered sys_exit
> > > event, e.g.:
> > > 
> > > Note that it is advised to increase the number of mmap pages to
> > > prevent event losses when using this new feature. Often, adding
> > > `-m 10M` to the `perf trace` invocation is enough.
> > > 
> > > This feature is also available in strace when built with libunwind
> > > 
> > > via `strace -k`. Performance wise, this solution is much better:
> > > $ time find path/to/linux &> /dev/null
> > > 
> > > real0m0.051s
> > > user0m0.013s
> > > sys 0m0.037s
> > > 
> > > $ time perf trace -m 800M --call-graph dwarf find path/to/linux &>
> > > /dev/null
> > > 
> > > real0m2.624s
> > > user0m1.203s
> > > sys 0m1.333s
> > > 
> > > $ time strace -k find path/to/linux  &> /dev/null
> > > 
> > > real0m35.398s
> > > user0m10.403s
> > > sys 0m23.173s
> > > 
> > > Note that it is currently not possible to configure the print output.
> > > Adding such a feature, similar to what is available in `perf script`
> > > via its `--fields` knob can be added later on.
> > 
> > You mixed up multiple changes in one single patch, I'll break it down
> > while testing, and before pushing upstream.
> 
> Expanding a bit the audience:
> 
> First test, it works, great! But do we really need that address? I guess
> not, right, perhaps via some callchain parameter, to tell what we want to
> see? But by default knowing the function name + DSO seems enough, no?

...

> Yeah, you agree with that, now that I read the patch 8-):
> 
> +   /* TODO: user-configurable print_opts */
> +   unsigned int print_opts = PRINT_IP_OPT_IP

;-)

I even tried to make the code of `perf script` reusable for `perf trace`, but 
stopped once I realised that it currently relies on the existance of a 
`perf_session`, which does not exist when we do live tracing. It only exists 
for replaying in `builtin-trace.c`. So it involves some more refactoring which 
I did not have the time for.



> Better, but perhaps we should try aligning, up to a limit, the function
> names/DSOs?
> 
> [root@jouet bpf]# trace -e nanosleep --call-graph dwarf usleep 1
>  0.063 ( 0.063 ms): usleep/6132 nanosleep(rqtp: 0x7ffd1b7a8e70  
>  ) = 0 syscall_slow_exit_work
> ([kernel.kallsyms]) do_syscall_64  ([kernel.kallsyms])
> return_from_SYSCALL_64 ([kernel.kallsyms]) __nanosleep   
> (/usr/lib64/libc-2.22.so) usleep (/usr/lib64/libc-2.22.so)
> [unknown]  (/usr/bin/usleep) __libc_start_main 
> (/usr/lib64/libc-2.22.so) [unknown]  (/usr/bin/usleep)
> [root@jouet bpf]#
> 
> wdyt?

Yes, sounds good. Many profilers I've worked with always dump the IP, so I 
thought we should do it here as well. `perf script` e.g. does it. Could we 
maybe print the IP if the symbol is [unknown]?

> Also, after this initial support is in, I think the next step is to
> allow per syscall configs, like we have for per tracepoints, i.e. this
> should be possible:
> 
># trace -e nanosleep(call-graph=dwarf),socket -a
> 
> And then we would get callchains just for nanosleep calls, not for
> socket ones. We then need to think how to ask that efficiently to the
> kernel, in this case it should be instead of using
> raw_syscalls:sys_enter + tracepoint filters set via ioctl, to use
> syscalls:sys_{enter,exit}_nanosleep, with callgraphs +
> syscalls:sys_{enter,exit}_socket, without.
> 
> Doing it this way allows us to avoid asking callchains for a lot of
> events when we want just for a few ones, to reduce overhead.
 
Yep, sounds useful for some more specific use-cases. For me, this patch is 
sufficient as I'd just do:

$ trace -e nanosleep --call-graph=dwarf ...

What I think is more important though is to make sure we only ask for 
callchains on the sys_exit events. Afaik, my patch will do it also for the 
sys_enter which is just additional cost with no benefit? So fixing that first 
is I think even more important, but I don't know how.

> Anyway, I think I'll just break this down into multiple patches and then
> we can work on these other aspects.

Yes, but note that I'll be busy and then on vacation for the next two weeks. 
I'll get back to this after wards.

> David, ah, his patch floated on the linux-perf-users mailing list, easy
> one once the thread->priv one got out of the way (it was being used by
> builtin-trace.c and the unwind code, ugh).
> 
> Thanks,

Same to you, cheers!

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptog

Re: [PATCH 12/15] irqchip/gic: Pass GIC pointer to save/restore functions

[Marc Zyngier]

On Thu, 17 Mar 2016 14:19:16 +
Jon Hunter  wrote:

> Instead of passing the GIC index to the save/restore functions pass a
> pointer to the GIC chip data. This will allow these save/restore
> functions to be re-used by a platform driver where the GIC chip data
> structure is allocated dynamically and so there is no applicable index
> for identifying the GIC.
> 
> Signed-off-by: Jon Hunter 

Eventually, I'd like to move to a situation where we don't statically
allocate the chip data anymore, and kill CONFIG_ARM_GIC_MAX_NR
altogether. This is obviously a step in the right direction.

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny.

[PATCH] qlge: Replace create_singlethread_workqueue with alloc_ordered_workqueue

[Amitoj Kaur Chawla]

Replace deprecated create_singlethread_workqueue with
alloc_ordered_workqueue.

Work items include getting tx/rx frame sizes, resetting MPI processor,
setting asic recovery bit so ordering seems necessary as only one work
item should be in queue/executing at any given time, hence the use of
alloc_ordered_workqueue.

WQ_MEM_RECLAIM flag has been set since ethernet devices seem to sit in
memory reclaim path, so to guarantee forward progress regardless of 
memory pressure.

Signed-off-by: Amitoj Kaur Chawla 
Acked-by: Tejun Heo 
---
Not sure if the assumption of requiring ordering of work items
is correct.

 drivers/net/ethernet/qlogic/qlge/qlge_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c 
b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
index b28e73e..83d7210 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
@@ -4687,7 +4687,7 @@ static int ql_init_device(struct pci_dev *pdev, struct 
net_device *ndev,
/*
 * Set up the operating parameters.
 */
-   qdev->workqueue = create_singlethread_workqueue(ndev->name);
+   qdev->workqueue = alloc_ordered_workqueue(ndev->name, WQ_MEM_RECLAIM);
INIT_DELAYED_WORK(&qdev->asic_reset_work, ql_asic_reset_work);
INIT_DELAYED_WORK(&qdev->mpi_reset_work, ql_mpi_reset_work);
INIT_DELAYED_WORK(&qdev->mpi_work, ql_mpi_work);
-- 
1.9.1

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

[Rafael J. Wysocki]

On Sat, Apr 9, 2016 at 1:07 PM, Peter Zijlstra  wrote:
> On Fri, Apr 08, 2016 at 10:59:59PM +0200, Rafael J. Wysocki wrote:
>> On Friday, April 08, 2016 08:50:54 AM Mike Galbraith wrote:
>> > On Fri, 2016-04-08 at 08:45 +0200, Peter Zijlstra wrote:
>> >
>> > > Cute, I thought you used governor=performance for your runs?
>> >
>> > I do, and those numbers are with it thus set.
>>
>> Well, this is a trade-off.
>>
>> 4.5 introduced a power regression here so this one goes back to the previous
>> state of things.
>
> Just for my elucidation; how can gov=performance have a 'power'
> regression?

Because of what is used as the "default" idle state most of the time.

C1 was used before 4.5 and that changed to polling in 4.5.

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

[Rafael J. Wysocki]

On Sat, Apr 9, 2016 at 8:40 AM, Mike Galbraith  wrote:
> On Fri, 2016-04-08 at 22:59 +0200, Rafael J. Wysocki wrote:
>> On Friday, April 08, 2016 08:50:54 AM Mike Galbraith wrote:
>> > On Fri, 2016-04-08 at 08:45 +0200, Peter Zijlstra wrote:
>> >
>> > > Cute, I thought you used governor=performance for your runs?
>> >
>> > I do, and those numbers are with it thus set.
>>
>> Well, this is a trade-off.
>>
>> 4.5 introduced a power regression here so this one goes back to the previous
>> state of things.
>
> That sounds somewhat reasonable.  Too bad I don't have a super duper
> watt meter handy.. seeing that you really really are saving me money
> would perhaps make me less fond of those prettier numbers.

You can look at the turbostat Watts numbers ("turbostat --debug" and
the last three columns of the output in turbostat as included in the
kernel source).

That requires an Intel CPU with RAPL.

Re: alternatives to null-terminated byte arrays in syscalls in the future?

[One Thousand Gnomes]

On Fri, 8 Apr 2016 14:04:00 -0700
Andrew Kelley  wrote:

> The open syscall looks like this:
> 
> SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, 
> mode)
> 
> filename is a null terminated byte array. Null termination is one way
> to handle lengths of byte arrays, but arguably a better way is to keep
> track of the length in a separate field. Many programming languages
> use pointer + length instead of null termination for various reasons.
> 
> When it's time to make a syscall such as open, software which does not
> have a null character at the end of byte arrays are forced to allocate
> memory, do a memcpy, insert a null byte, perform the open syscall,
> then deallocate the memory.

That should only happen if the language wasn't carefully thought out. If
your name objects include both the length and the space available so you
can do array offset validation then

- you can check if the \0 will fit
- your app or interreter can add space for \0 or even include it
  specifically

I would also be very surprised if most applications doing such
conversions even showed up meaningfully in the profiling. pathname
syscalls are not the most common ones being executed.

Alan

[PATCH 4/4] selftests: Add test for sigaltstack(SS_ONSTACK|SS_AUTODISARM)

[Stas Sergeev]

This patch adds the test case for SS_AUTODISARM flag.
The test-case tries to set SS_AUTODISARM flag and checks if
the nested signal corrupts the stack after swapcontext().

CC: Shuah Khan 
CC: linux-kernel@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: Andy Lutomirski 

Signed-off-by: Stas Sergeev 
---
 tools/testing/selftests/Makefile |   1 +
 tools/testing/selftests/sigaltstack/Makefile |   8 ++
 tools/testing/selftests/sigaltstack/sas.c| 156 +++
 3 files changed, 165 insertions(+)
 create mode 100644 tools/testing/selftests/sigaltstack/Makefile
 create mode 100644 tools/testing/selftests/sigaltstack/sas.c

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index b04afc3..ff9e5f2 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -19,6 +19,7 @@ TARGETS += powerpc
 TARGETS += pstore
 TARGETS += ptrace
 TARGETS += seccomp
+TARGETS += sigaltstack
 TARGETS += size
 TARGETS += static_keys
 TARGETS += sysctl
diff --git a/tools/testing/selftests/sigaltstack/Makefile 
b/tools/testing/selftests/sigaltstack/Makefile
new file mode 100644
index 000..56af56e
--- /dev/null
+++ b/tools/testing/selftests/sigaltstack/Makefile
@@ -0,0 +1,8 @@
+CFLAGS = -Wall
+BINARIES = sas
+all: $(BINARIES)
+
+include ../lib.mk
+
+clean:
+   rm -rf $(BINARIES)
diff --git a/tools/testing/selftests/sigaltstack/sas.c 
b/tools/testing/selftests/sigaltstack/sas.c
new file mode 100644
index 000..57da8bf
--- /dev/null
+++ b/tools/testing/selftests/sigaltstack/sas.c
@@ -0,0 +1,156 @@
+/*
+ * Stas Sergeev 
+ *
+ * test sigaltstack(SS_ONSTACK | SS_AUTODISARM)
+ * If that succeeds, then swapcontext() can be used inside sighandler safely.
+ *
+ */
+
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef SS_AUTODISARM
+#define SS_AUTODISARM  (1 << 4)
+#endif
+
+static void *sstack, *ustack;
+static ucontext_t uc, sc;
+static const char *msg = "[OK]\tStack preserved";
+static const char *msg2 = "[FAIL]\tStack corrupted";
+struct stk_data {
+   char msg[128];
+   int flag;
+};
+
+void my_usr1(int sig, siginfo_t *si, void *u)
+{
+   char *aa;
+   int err;
+   stack_t stk;
+   struct stk_data *p;
+
+   register unsigned long sp asm("sp");
+
+   if (sp < (unsigned long)sstack ||
+   sp >= (unsigned long)sstack + SIGSTKSZ) {
+   printf("[FAIL]\tSP is not on sigaltstack\n");
+   exit(EXIT_FAILURE);
+   }
+   /* put some data on stack. other sighandler will try to overwrite it */
+   aa = alloca(1024);
+   assert(aa);
+   p = (struct stk_data *)(aa + 512);
+   strcpy(p->msg, msg);
+   p->flag = 1;
+   printf("[RUN]\tsignal USR1\n");
+   err = sigaltstack(NULL, &stk);
+   if (err) {
+   perror("[FAIL]\tsigaltstack()");
+   exit(EXIT_FAILURE);
+   }
+   if (stk.ss_flags != SS_DISABLE)
+   printf("[FAIL]\tss_flags=%i, should be SS_DISABLE\n",
+   stk.ss_flags);
+   else
+   printf("[OK]\tsigaltstack is disabled in sighandler\n");
+   swapcontext(&sc, &uc);
+   printf("%s\n", p->msg);
+   if (!p->flag) {
+   printf("[RUN]\tAborting\n");
+   exit(EXIT_FAILURE);
+   }
+}
+
+void my_usr2(int sig, siginfo_t *si, void *u)
+{
+   char *aa;
+   struct stk_data *p;
+
+   printf("[RUN]\tsignal USR2\n");
+   aa = alloca(1024);
+   /* dont run valgrind on this */
+   /* try to find the data stored by previous sighandler */
+   p = memmem(aa, 1024, msg, strlen(msg));
+   if (p) {
+   printf("[FAIL]\tsigaltstack re-used\n");
+   /* corrupt the data */
+   strcpy(p->msg, msg2);
+   /* tell other sighandler that his data is corrupted */
+   p->flag = 0;
+   }
+}
+
+static void switch_fn(void)
+{
+   printf("[RUN]\tswitched to user ctx\n");
+   raise(SIGUSR2);
+   setcontext(&sc);
+}
+
+int main(void)
+{
+   struct sigaction act;
+   stack_t stk;
+   int err;
+
+   sigemptyset(&act.sa_mask);
+   act.sa_flags = SA_ONSTACK | SA_SIGINFO;
+   act.sa_sigaction = my_usr1;
+   sigaction(SIGUSR1, &act, NULL);
+   act.sa_sigaction = my_usr2;
+   sigaction(SIGUSR2, &act, NULL);
+   sstack = mmap(NULL, SIGSTKSZ, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0);
+   if (sstack == MAP_FAILED) {
+   perror("mmap()");
+   return EXIT_FAILURE;
+   }
+   stk.ss_sp = sstack;
+   stk.ss_size = SIGSTKSZ;
+   stk.ss_flags = SS_ONSTACK | SS_AUTODISARM;
+   err = sigaltstack(&stk, NULL);
+   if (err) {
+   perror("[FAIL]\tsigaltstack(SS_ONSTACK | SS_AUTODISARM)");
+   stk.ss_flags = SS_ONSTACK;
+   }
+   e

[PATCH v6(RESEND) 0/4] make sigaltstack() compatible with swapcontext()

[Stas Sergeev]

It is absolutely unclear what happened with my patch series,
but it is neither applied nor rejected. So here's the re-send.

The following patches make it possible to use swapcontext()
in a sighandler that works on sigaltstack.
The approach is inspired by Andy Lutomirski's suggestion that
sigaltstack should disarm itself after saving into uc_stack:
https://lkml.org/lkml/2016/2/1/594

I add the SS_AUTODISARM flag that does exactly that.
On sighandler exit, the sigaltstack is restored from uc_stack.
Another possible name could be SS_ONESHOT, but, since it gets
always re-enabled, I choose SS_AUTODISARM.

Change since v5:
- Fix description of patch 4/4

Change since v4:
- Implement this Andy Lutomirski's suggestion:
https://lkml.org/lkml/2016/3/6/158
that allows the run-time probing of the existence of the
flags added in the future.

[PATCH 1/4] [Cleanup] x86: signal: unify the sigaltstack check with
A clean-up patch that unifies x86's sigaltstack handling with
other arches.
[PATCH 2/4] sigaltstack: preparations for adding new SS_xxx flags
Andy's suggested changes
[PATCH 3/4] sigaltstack: implement SS_AUTODISARM flag
This patch implements SS_AUTODISARM flag
[PATCH 4/4] selftests: Add test for
This patch adds the selftest code for new functionality

CC: linux-kernel@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: Andy Lutomirski 
CC: Oleg Nesterov 
CC: Shuah Khan 
CC: Ingo Molnar 

Diffstat:
 arch/x86/kernel/signal.c |   23 +--
 include/linux/sched.h|8 +
 include/linux/signal.h   |4 
 include/uapi/linux/signal.h  |7 +
 kernel/fork.c|2 
 kernel/signal.c  |   26 ++--
 tools/testing/selftests/Makefile |1 
 tools/testing/selftests/sigaltstack/Makefile |8 +
 tools/testing/selftests/sigaltstack/sas.c|  156 +++
 9 files changed, 208 insertions(+), 27 deletions(-)

[PATCH 3/4] sigaltstack: implement SS_AUTODISARM flag

[Stas Sergeev]

This patch implements the SS_AUTODISARM flag that can be ORed with
SS_ONSTACK when forming ss_flags.
When this flag is set, sigaltstack will be disabled when entering
the signal handler; more precisely, after saving sas to uc_stack.
When leaving the signal handler, the sigaltstack is restored by
uc_stack.
When this flag is used, it is safe to switch from sighandler with
swapcontext(). Without this flag, the subsequent signal will corrupt
the state of the switched-away sighandler.

To detect the support of this functionality, one can do
err = sigaltstack(SS_DISABLE | SS_AUTODISARM);
if (err && errno == EINVAL) unsupported();

Signed-off-by: Stas Sergeev 

CC: Ingo Molnar 
CC: Peter Zijlstra 
CC: Richard Weinberger 
CC: Andrew Morton 
CC: Oleg Nesterov 
CC: Tejun Heo 
CC: Heinrich Schuchardt 
CC: Jason Low 
CC: Andrea Arcangeli 
CC: Frederic Weisbecker 
CC: Konstantin Khlebnikov 
CC: Josh Triplett 
CC: "Eric W. Biederman" 
CC: Aleksa Sarai 
CC: "Amanieu d'Antras" 
CC: Paul Moore 
CC: Sasha Levin 
CC: Palmer Dabbelt 
CC: Vladimir Davydov 
CC: linux-kernel@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: Andy Lutomirski 
---
 include/linux/sched.h   |  8 
 include/linux/signal.h  |  4 +++-
 include/uapi/linux/signal.h |  4 +++-
 kernel/fork.c   |  2 +-
 kernel/signal.c | 10 --
 5 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index a10494a..26201cd 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1587,6 +1587,7 @@ struct task_struct {
 
unsigned long sas_ss_sp;
size_t sas_ss_size;
+   unsigned sas_ss_flags;
 
struct callback_head *task_works;
 
@@ -2573,6 +2574,13 @@ static inline int sas_ss_flags(unsigned long sp)
return on_sig_stack(sp) ? SS_ONSTACK : 0;
 }
 
+static inline void sas_ss_reset(struct task_struct *p)
+{
+   p->sas_ss_sp = 0;
+   p->sas_ss_size = 0;
+   p->sas_ss_flags = SS_DISABLE;
+}
+
 static inline unsigned long sigsp(unsigned long sp, struct ksignal *ksig)
 {
if (unlikely((ksig->ka.sa.sa_flags & SA_ONSTACK)) && ! sas_ss_flags(sp))
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 92557bb..3fbe814 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -432,8 +432,10 @@ int __save_altstack(stack_t __user *, unsigned long);
stack_t __user *__uss = uss; \
struct task_struct *t = current; \
put_user_ex((void __user *)t->sas_ss_sp, &__uss->ss_sp); \
-   put_user_ex(sas_ss_flags(sp), &__uss->ss_flags); \
+   put_user_ex(t->sas_ss_flags, &__uss->ss_flags); \
put_user_ex(t->sas_ss_size, &__uss->ss_size); \
+   if (t->sas_ss_flags & SS_AUTODISARM) \
+   sas_ss_reset(t); \
 } while (0);
 
 #ifdef CONFIG_PROC_FS
diff --git a/include/uapi/linux/signal.h b/include/uapi/linux/signal.h
index 7c73165..7388260 100644
--- a/include/uapi/linux/signal.h
+++ b/include/uapi/linux/signal.h
@@ -7,7 +7,9 @@
 #define SS_ONSTACK 1
 #define SS_DISABLE 2
 
+/* bit-flags */
+#define SS_AUTODISARM  (1 << 4)/* disable sas during sighandling */
 /* mask for all SS_xxx flags */
-#define SS_FLAG_BITS   0
+#define SS_FLAG_BITS   SS_AUTODISARM
 
 #endif /* _UAPI_LINUX_SIGNAL_H */
diff --git a/kernel/fork.c b/kernel/fork.c
index 2e391c7..68c8716 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1483,7 +1483,7 @@ static struct task_struct *copy_process(unsigned long 
clone_flags,
 * sigaltstack should be cleared when sharing the same VM
 */
if ((clone_flags & (CLONE_VM|CLONE_VFORK)) == CLONE_VM)
-   p->sas_ss_sp = p->sas_ss_size = 0;
+   sas_ss_reset(p);
 
/*
 * Syscall tracing and stepping should be turned off in the
diff --git a/kernel/signal.c b/kernel/signal.c
index 9a24bc3..e1096ad 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3133,6 +3133,7 @@ do_sigaltstack (const stack_t __user *uss, stack_t __user 
*uoss, unsigned long s
 
current->sas_ss_sp = (unsigned long) ss_sp;
current->sas_ss_size = ss_size;
+   current->sas_ss_flags = ss_flags;
}
 
error = 0;
@@ -3163,9 +3164,14 @@ int restore_altstack(const stack_t __user *uss)
 int __save_altstack(stack_t __user *uss, unsigned long sp)
 {
struct task_struct *t = current;
-   return  __put_user((void __user *)t->sas_ss_sp, &uss->ss_sp) |
-   __put_user(sas_ss_flags(sp), &uss->ss_flags) |
+   int err = __put_user((void __user *)t->sas_ss_sp, &uss->ss_sp) |
+   __put_user(t->sas_ss_flags, &uss->ss_flags) |
__put_user(t->sas_ss_size, &uss->ss_size);
+   if (err)
+   return err;
+   if (t->sas_ss_flags & SS_AUTODISARM)
+   sas_ss_reset(t);
+   return 0;
 }
 
 #ifdef CONFIG_COMPAT
-- 
2.7.2

[PATCH 2/4] sigaltstack: preparations for adding new SS_xxx flags

[Stas Sergeev]

This patch adds SS_FLAG_BITS - the mask that splits sigaltstack
mode values and bit-flags. Since there is no bit-flags yet, the
mask is defined to 0. The flags are added by subsequent patches.
With every new flag, the mask should have the appropriate bit cleared.

This makes sure if some flag is tried on a kernel that doesn't
support it, the EINVAL error will be returned, because such a
flag will be treated as an invalid mode rather than the bit-flag.
That way the existence of the particular features can be probed
at run-time.

This change was suggested by Andy Lutomirski:
https://lkml.org/lkml/2016/3/6/158

Signed-off-by: Stas Sergeev 

CC: Andrew Morton 
CC: Oleg Nesterov 
CC: "Peter Zijlstra (Intel)" 
CC: "Amanieu d'Antras" 
CC: Michal Hocko 
CC: Richard Weinberger 
CC: Vladimir Davydov 
CC: Sasha Levin 
CC: linux-kernel@vger.kernel.org
---
 include/uapi/linux/signal.h |  3 +++
 kernel/signal.c | 16 ++--
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/include/uapi/linux/signal.h b/include/uapi/linux/signal.h
index e1bd50c2..7c73165 100644
--- a/include/uapi/linux/signal.h
+++ b/include/uapi/linux/signal.h
@@ -7,4 +7,7 @@
 #define SS_ONSTACK 1
 #define SS_DISABLE 2
 
+/* mask for all SS_xxx flags */
+#define SS_FLAG_BITS   0
+
 #endif /* _UAPI_LINUX_SIGNAL_H */
diff --git a/kernel/signal.c b/kernel/signal.c
index 0508544..9a24bc3 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3100,7 +3100,8 @@ do_sigaltstack (const stack_t __user *uss, stack_t __user 
*uoss, unsigned long s
if (uss) {
void __user *ss_sp;
size_t ss_size;
-   int ss_flags;
+   unsigned ss_flags;
+   int ss_mode;
 
error = -EFAULT;
if (!access_ok(VERIFY_READ, uss, sizeof(*uss)))
@@ -3115,18 +3116,13 @@ do_sigaltstack (const stack_t __user *uss, stack_t 
__user *uoss, unsigned long s
if (on_sig_stack(sp))
goto out;
 
+   ss_mode = ss_flags & ~SS_FLAG_BITS;
error = -EINVAL;
-   /*
-* Note - this code used to test ss_flags incorrectly:
-*old code may have been written using ss_flags==0
-*to mean ss_flags==SS_ONSTACK (as this was the only
-*way that worked) - this fix preserves that older
-*mechanism.
-*/
-   if (ss_flags != SS_DISABLE && ss_flags != SS_ONSTACK && 
ss_flags != 0)
+   if (ss_mode != SS_DISABLE && ss_mode != SS_ONSTACK &&
+   ss_mode != 0)
goto out;
 
-   if (ss_flags == SS_DISABLE) {
+   if (ss_mode == SS_DISABLE) {
ss_size = 0;
ss_sp = NULL;
} else {
-- 
2.7.2

[PATCH 1/4] [Cleanup] x86: signal: unify the sigaltstack check with other arches

[Stas Sergeev]

Currently x86's get_sigframe() checks for "current->sas_ss_size"
to determine whether there is a need to switch to sigaltstack.
The common practice used by all other arches is to check for
sas_ss_flags(sp) == 0

This patch makes the code consistent with other arches.
The slight complexity of the patch is added by the optimization on
!sigstack check that was requested by Andy Lutomirski: sas_ss_flags(sp)==0
already implies that we are not on a sigstack, so the code is shuffled
to avoid the duplicate checking.

This patch have no any user-visible impact. It is purely a cleanup.

CC: linux-kernel@vger.kernel.org
CC: Andy Lutomirski 
CC: Thomas Gleixner 
CC: Ingo Molnar 
CC: "H. Peter Anvin" 
CC: x...@kernel.org
CC: Borislav Petkov 
CC: Brian Gerst 
CC: Oleg Nesterov 
CC: Richard Weinberger 

Signed-off-by: Stas Sergeev 
---
 arch/x86/kernel/signal.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index cb6282c..285183b 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -213,18 +213,17 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs 
*regs, size_t frame_size,
if (config_enabled(CONFIG_X86_64))
sp -= 128;
 
-   if (!onsigstack) {
-   /* This is the X/Open sanctioned signal stack switching.  */
-   if (ka->sa.sa_flags & SA_ONSTACK) {
-   if (current->sas_ss_size)
-   sp = current->sas_ss_sp + current->sas_ss_size;
-   } else if (config_enabled(CONFIG_X86_32) &&
-  (regs->ss & 0x) != __USER_DS &&
-  !(ka->sa.sa_flags & SA_RESTORER) &&
-  ka->sa.sa_restorer) {
-   /* This is the legacy signal stack switching. */
-   sp = (unsigned long) ka->sa.sa_restorer;
-   }
+   /* This is the X/Open sanctioned signal stack switching.  */
+   if (ka->sa.sa_flags & SA_ONSTACK) {
+   if (sas_ss_flags(sp) == 0)
+   sp = current->sas_ss_sp + current->sas_ss_size;
+   } else if (config_enabled(CONFIG_X86_32) &&
+  !onsigstack &&
+  (regs->ss & 0x) != __USER_DS &&
+  !(ka->sa.sa_flags & SA_RESTORER) &&
+  ka->sa.sa_restorer) {
+   /* This is the legacy signal stack switching. */
+   sp = (unsigned long) ka->sa.sa_restorer;
}
 
if (fpu->fpstate_active) {
-- 
2.7.2

Re: [PATCH 04/10] iio: stx104: Change STX104 dependency to ISA_BUS

[One Thousand Gnomes]

> I believe this is the source of the issues I encountered on my initial
> attempt to decouple the X86_32 dependency from the ISA option. I suspect
> if I add an explicit X86_32 dependency to the PNPBIOS driver, I will be
> able to remove the X86_32 dependency from the ISA option without
> incident from the other drivers.

That would be correct. PnPBIOS is obsoleted by ACPI so a 64bit x86
platform shouldn't be using PnPBIOS nor anything non x86. Strictly
speaking PnpBIOS is not ISA, it's onboard devices.

ISA devices that can be enumerated are usually enumerated via ISAPnP
which is platform independent.

Quite a few of the ISA drivers if you review them more carefully have
other endian and size assumptions, IRQ assumptions and probably fun bugs
because they've simply never been run on anything else even when it is
possible.

Alan

[PATCH] fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

[enpengxu]

From: Enpeng Xu 

Signed-off-by: Enpeng Xu 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 49e4f26..527eca7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -746,7 +746,7 @@ static void gen8_ppgtt_clear_pte_range(struct 
i915_address_space *vm,
num_entries--;
}
 
-   kunmap_px(ppgtt, pt);
+   kunmap_px(ppgtt, pt_vaddr);
 
pte = 0;
if (++pde == I915_PDES) {
-- 
2.1.0

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

[One Thousand Gnomes]

> If anyone has a better idea on how userspace should connect the master
> pty file descriptor the slave file descriptor, I would be willing to
> implement that instead.

If we are willing to go away from the existing mess of a tty interface
inflicted on us by BSD and then mashed up by POSIX then a syscall of

  int err = ptypair(int fd[2], int perms, int flags);

[where flags is the O_ ones we usually need to cover (CLOEXEC etc) and
maybe even some kind of "private" flag to say don't even expose it via
devpts).

would do remarkably sane things to the majoirty of use cases as it breaks
the dependence on grantpt and also the historic screwup that pty pairs
aren't allocated atomically with both file handles returned as pipe()
does.

Alan

Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks

[Peter Zijlstra]

On Sat, Apr 09, 2016 at 11:25:39AM +0800, Xunlei Pang wrote:

> > In any case, I just realized we do not in fact provide this guarantee
> > (of pointing to a blocked task) that needs a bit more work.
> 
> Current patch calls rt_mutex_adjust_prio() before wake_up_q() the
> wakee, at that moment the wakee has been removed by
> rt_mutex_slowunlock()->mark_wakeup_next_waiter(), from current's
> pi_waiters, rt_mutex_adjust_prio() won't see this wakee, so I think
> this should not be problem.

No, any wakeup after mark_wakeup_next_waiter() will make the task run.
And since we must always consider spurious wakeups, we cannot rely on us
(eg. our wake_up_q call) being the one and only.

Therefore it is possible and the only thing that stands between us and
doom is the fact that the wake_q stuff holds a task reference.

But we cannot guarantee that the task we have a pointer to is in fact
blocked.

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

[Peter Zijlstra]

On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote:

> > > Widely diverging from
> > > CPU's behavior, IO grouped all internal tasks into an internal leaf
> > > node and used to assign a fixed weight to it.
> > 
> > That's just plain broken... That is not how a proportional weight based
> > hierarchical controller works.
> 
> That's a strong statement. 

No its plain fact.

If you modify a graph, it is not the same graph.

Even if you argue by merit of the function on this graph, and state that
only the result of this function is important, and any modification to
the graph that leaves this result in tact is good; ie. a modification
invariant to the function, this fails.

Because for proportional controllers all that matters is the number and
weight of edges leaving a node.

The modification described above does clearly change the outcome and is
not invariant under the proportional weight distribution function.

> When the hierarchy is composed of
> equivalent objects as in CPU, not distinguishing internal and leaf
> nodes would be a more natural way to organize; however, it isn't
> necessarily true in all cases.  For example, while a writeback IO
> would be issued by some task, the task itself might not have done
> anything to cause that IO and the IO would essentially be anonymous in
> the resource domain.  Also, different controllers use different units
> of organization - CPU sees threads, IO sees IO contexts which are
> usually shared in a process.  The difference would lead to differing
> scaling behaviors in proportional distribution.
> 
> While the separate buckets and entities model may not be as elegant as
> tree of uniform objects, it is far from uncommon and more robust when
> dealing with different types of objects.

The graph does not care about the type of objects the nodes represent,
and proportional weight distribution only cares about the edges.

With cpu-cgroup the nodes are not of uniform type either, they can be a
group or a task. You get runtime type identification and make it work.

There just isn't an excuse for crazy crap like this. Its wrong, no two
ways about it.

Re: [PATCH 0/2] perf probe fixes for ppc64le

[Naveen N. Rao]

On 2016/04/08 04:57PM, Balbir Singh wrote:
> On Thu, 2016-04-07 at 14:56 +0530, Naveen N. Rao wrote:
> > On 2016/04/07 06:19PM, Balbir Singh wrote:
> > > 
> > > 
> > > On 06/04/16 22:32, Naveen N. Rao wrote:
> > > > 
> > > > This patchset fixes three issues found with perf probe on ppc64le:
> > > > 1. 'perf test kallsyms' failure on ppc64le (reported by Michael
> > > > Ellerman). This was due to the symbols being fixed up during symbol
> > > > table load. This is fixed in patch 2 by delaying symbol fixup until
> > > > later.
> > > > 2. perf probe function offset was being calculated from the local entry
> > > > point (LEP), which does not match user expectation when trying to look
> > > > at function disassembly output (reported by Ananth N). This is fixed for
> > > > kallsyms in patch 1 and for symbol table in patch 2.
> > > I think the bit where the offset is w.r.t LEP when using a name, but w.r.t
> > > GEP when using function+offset can be confusing.
> > Thanks for your review!
> > 
> > The rationale for this is actually from the end-user perspective. The 
> > two use cases we are considering are:
> > 1. User just wants to probe at function entry point:
> > # perf probe _do_fork
> > 
> > In this case, the user most definitely needs the local entry point, 
> > without which the probe won't be hit. So, for this case, we 
> > automatically insert the probe at the LEP.
> > 
> > [We really only want to alter perf probe behavior in this case only, but 
> > we were incorrectly changing the behavior of perf with the below 
> > scenario as well.]
> > 
> > 2. User wants to probe at a specific location. In this case, the user 
> > most likely starts by looking at the function disassembly. For instance:
> > # objdump -S -d vmlinux.bak | grep -A100 \<_do_fork\>:
> > c00b6a00 <_do_fork>:
> >   unsigned long stack_start,
> >   unsigned long stack_size,
> >   int __user *parent_tidptr,
> >   int __user *child_tidptr,
> >   unsigned long tls)
> > {
> > c00b6a00:   f7 00 4c 3c addis   r2,r12,247
> > c00b6a04:   00 86 42 38 addir2,r2,-31232
> > c00b6a08:   a6 02 08 7c mflrr0
> > c00b6a0c:   d0 ff 41 fb std r26,-48(r1)
> > c00b6a10:   26 80 90 7d mfocrf  r12,8
> > ..
> > if (!(clone_flags & CLONE_UNTRACED)) {
> > c00b6a54:   e3 4f c7 7b rldicl. r7,r30,41,63
> > c00b6a58:   2c 00 82 40 bne c00b6a84 
> ><_do_fork+0x84>
> > if (clone_flags & CLONE_VFORK)
> > c00b6a5c:   e3 97 c8 7b rldicl. r8,r30,50,63
> > c00b6a60:   a0 01 82 41 beq c00b6c00 
> ><_do_fork+0x200>
> > c00b6a64:   20 00 20 39 li  r9,32
> > trace = PTRACE_EVENT_VFORK;
> > c00b6a68:   02 00 80 3b li  r28,2
> > c00b6a6c:   10 02 4d e9 ld  r10,528(r13)
> > 
> > If the user wants to probe at _do_fork+0x54, he'd do:
> > # perf probe _do_fork+0x54
> > 
> > With the earlier approach, we would insert the probe at _do_fork+0x5c 
> > (0x54 from the LEP) instead, which is incorrect.
> > 
> > In reality, user would probably just use debuginfo:
> > # perf probe -L _do_fork
> > <_do_fork@/root/linus/kernel/fork.c:0>
> >   0  long _do_fork(unsigned long clone_flags,
> >   unsigned long stack_start,
> >   unsigned long stack_size,
> >   int __user *parent_tidptr,
> >   int __user *child_tidptr,
> >   unsigned long tls)
> >   6  {
> > struct task_struct *p;
> >   8 int trace = 0;
> > long nr;
> >  
> > /*
> >  * Determine whether and which event to report to 
> >ptracer.  When
> >  * called from kernel_thread or CLONE_UNTRACED is 
> >explicitly
> >  * requested, no event is reported; otherwise, report 
> >if the event
> >  * for the type of forking is enabled.
> >  */
> >  17 if (!(clone_flags & CLONE_UNTRACED)) {
> >  18 if (clone_flags & CLONE_VFORK)
> >  19 trace = PTRACE_EVENT_VFORK;
> >  20 else if ((clone_flags & CSIGNAL) != SIGCHLD)
> >  21 trace = PTRACE_EVENT_CLONE;
> > 
> > # perf probe _do_fork:17
> > 
> > In this case, perf chooses the right address based on DWARF. The current 
> > patchset matches the behavior of perf without debuginfo with this.
> 
> 
> I agree what I worry is that perf probe _do_fork sets a breakpoint after
> perf probe _do_fork+0x4. I a

Re: [PATCH 04/10] iio: stx104: Change STX104 dependency to ISA_BUS

[William Breathitt Gray]

On Sat, Apr 09, 2016 at 01:58:14PM +0100, One Thousand Gnomes wrote:
>> I believe this is the source of the issues I encountered on my initial
>> attempt to decouple the X86_32 dependency from the ISA option. I suspect
>> if I add an explicit X86_32 dependency to the PNPBIOS driver, I will be
>> able to remove the X86_32 dependency from the ISA option without
>> incident from the other drivers.
>
>That would be correct. PnPBIOS is obsoleted by ACPI so a 64bit x86
>platform shouldn't be using PnPBIOS nor anything non x86. Strictly
>speaking PnpBIOS is not ISA, it's onboard devices.
>
>ISA devices that can be enumerated are usually enumerated via ISAPnP
>which is platform independent.
>
>Quite a few of the ISA drivers if you review them more carefully have
>other endian and size assumptions, IRQ assumptions and probably fun bugs
>because they've simply never been run on anything else even when it is
>possible.
>
>Alan

It looks like I'm in quite a pickle. Even if the patch for the PnPBIOS
driver removes the errors and warnings, there may be runtime bugs in
other drivers expecting X86_32. The only way I can see to prevent that
is to audit all the drivers which depend on the ISA option -- a behemoth
undertaking which would be far too impractical and error-prone for me to
do.

The alternative then is to do as Guenter Roeck suggests and
introduce/select ISA_BUS in the various other architectures which lack
it. In this scenario, I would expect the ISA option to be avoided for
new drivers, wherefore the ISA_BUS option can be used regardless of
architecture configuration.

I would prefer for a single ISA configuration option, but not at the
expense on breaking existing drivers; therefore, I will work instead on
adding the necessary ISA_BUS code to the various areas which require
them. If there are problems with this plan too, let me know.

William Breathitt Gray

Re: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.

[Tetsuo Handa]

Michal Hocko wrote:
> On Wed 17-02-16 19:34:46, Tetsuo Handa wrote:
> > >From 6f07b71c97766ec111d26c3424bded465ca48195 Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa 
> > Date: Wed, 17 Feb 2016 16:37:01 +0900
> > Subject: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.
> > 
> > We are trying to reduce the possibility of hitting OOM livelock by
> > introducing the OOM reaper, but there are situations where the OOM reaper
> > cannot reap the victim's memory. We want to introduce the OOM reaper as
> > simple as possible and make the OOM reaper better via incremental
> > development.
> > 
> > This patch adds a timer for handling corner cases where a TIF_MEMDIE
> > thread got stuck by reasons not handled by the initial version of the
> > OOM reaper. Since "mm,oom: exclude TIF_MEMDIE processes from candidates."
> > made sure that we won't choose the same OOM victim forever and this patch
> > makes sure that the kernel automatically presses SysRq-f upon OOM stalls,
> > we will not OOM stall forever as long as the OOM killer is called.
> 
> Can we actually start by incremental changes first and only get to this
> after we cannot find a proper way to fix existing issues?
> 
> I would like to at least make mmap_sem taken for write killable
> first. This should allow the oom_reaper to make a forward progress and
> allow the OOM killer to select another task when necessary (e.g. the
> victim wasn't sitting on a large amount of reclaimable memory). This
> has an advantage that the TIF_MEMDIE release is bound to a clearly
> defined action rather than a $RANDOM timemout which will always be hard
> to justify. We can talk about timeout based solutions after we are able
> to livelock the system even after all well defined actions will have
> failed. I really consider it premature right now.
> 

We can never fix the mmap_sem taken for write issue because

  (1) You hesitate to guarantee sending SIGKILL to all thread groups
  sharing the victim's memory by eliminating the shortcuts which
  do not send SIGKILL.

  (2) Even if you agree on guarantee sending SIGKILL to all thread
  groups sharing the victim's memory by eliminating the shortcuts,
  there might be OOM_SCORE_ADJ_MIN thread groups which means that
  we are not allowed to send SIGKILL after all.

Unlocking TIF_MEMDIE by the OOM reaper upon successful reaping is
the fastpath and unlocking TIF_MEMDIE by the timer is the slowpath.

Also, I think that the OOM reaper would be a too large change to backport
for 3.10-based and 2.6.32-based distributions.

There is no reason to add this patch which handles the slowpath right now.

> > Signed-off-by: Tetsuo Handa 
> > ---
> >  mm/oom_kill.c | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index ebc6764..fba2c62 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -45,6 +45,11 @@ int sysctl_oom_dump_tasks = 1;
> >  
> >  DEFINE_MUTEX(oom_lock);
> >  
> > +static void oomkiller_reset(unsigned long arg)
> > +{
> > +}
> > +static DEFINE_TIMER(oomkiller_victim_wait_timer, oomkiller_reset, 0, 0);
> > +
> >  #ifdef CONFIG_NUMA
> >  /**
> >   * has_intersects_mems_allowed() - check task eligiblity for kill
> > @@ -299,7 +304,8 @@ enum oom_scan_t oom_scan_process_thread(struct 
> > oom_control *oc,
> >  */
> > if (test_tsk_thread_flag(task, TIF_MEMDIE)) {
> > if (!is_sysrq_oom(oc))
> > -   return OOM_SCAN_ABORT;
> > +   return timer_pending(&oomkiller_victim_wait_timer) ?
> > +   OOM_SCAN_ABORT : OOM_SCAN_CONTINUE;
> > }
> > if (!task->mm)
> > return OOM_SCAN_CONTINUE;
> > @@ -452,6 +458,8 @@ void mark_oom_victim(struct task_struct *tsk)
> >  */
> > __thaw_task(tsk);
> > atomic_inc(&oom_victims);
> > +   /* Make sure that we won't wait for this task forever. */
> > +   mod_timer(&oomkiller_victim_wait_timer, jiffies + 5 * HZ);
> >  }
> >  
> >  /**
> > -- 
> > 1.8.3.1
> 
> -- 
> Michal Hocko
> SUSE Labs

Re: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.

[Tetsuo Handa]

Tetsuo Handa wrote:
> There is no reason to add this patch which handles the slowpath right now.
Oops.
There is no reason _not_ to add this patch which handles the slowpath right now.

Re: [PATCH] leftpad.2: Document new syscall

[Richard Weinberger]

Am 08.04.2016 um 20:10 schrieb Heinrich Schuchardt:
> On 04/01/2016 12:33 AM, Richard Weinberger wrote:
>> From: Daniel Walter 
>>
>> Signed-off-by: Daniel Walter 
>> Signed-off-by: Richard Weinberger 
>> ---
>>  man2/leftpad.2 | 55 +++
>>  1 file changed, 55 insertions(+)
>>  create mode 100644 man2/leftpad.2
>>
>> diff --git a/man2/leftpad.2 b/man2/leftpad.2
>> new file mode 100644
>> index 000..ff5f401
>> --- /dev/null
>> +++ b/man2/leftpad.2
>> @@ -0,0 +1,55 @@
>> +.\" Copyright (c) 2016 sigma-star gmbh
>> +.\" (off...@sigma-star.at)
>> +.\"
>> +.\" %%%LICENSE_START(GPLv2+_DOC_FULL)
>> +.\" This is free documentation; 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.
>> +.\"
>> +.\" The GNU General Public License's references to "object code"
>> +.\" and "executables" are to be interpreted as the output of any
>> +.\" document formatting or typesetting system, including
>> +.\" intermediate and printed output.
>> +.\"
>> +.\" This manual 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 manual; if not, see
>> +.\" .
>> +.\" %%%LICENSE_END
>> +.\"
>> +.TH LEFTPAD 2 2016-04-01 "Linux" "Linux Programmer's Manual"
>> +.SH NAME
>> +leftpad
>> +.SH SYNOPSIS
>> +.nf
>> +.B #include 
>> +
>> +.BI "int leftpad(char *src, char pad, char *dst, size_t dst_len);
>> +.fi
>> +.SH DESCRIPTION
>> +This function provides left padding for strings.
>> +.LP
>> +The string in
>> +.I src
>> +will be left padded with the chosen padding character
>> +.I pad
>> +and stored in
>> +.I dst
>> + .
>> +.SH RETURN VALUE
>> +On success, returns the number of padding characters added.
>> +.SH ERRORS
>> +.TP
>> +.B EINVAL
>> +The size of the destination buffer
>> +.I dst
>> +is shorter than the source string
>> +.I src
>> + . Or the destination string is longer than 4096 bytes.
> 
> Why should the call be limited to an arbitrary number of 4096 bytes?
> 
> There is no such limit in malloc so why should we need one here?
> 
> NAK

Sorry, the review window for this patch is now closed.
Please resend your comments on April 1st 2017.

Thanks,
//richard

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

[H. Peter Anvin]

On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes 
 wrote:
>
>> If anyone has a better idea on how userspace should connect the
>master
>> pty file descriptor the slave file descriptor, I would be willing to
>> implement that instead.
>
>If we are willing to go away from the existing mess of a tty interface
>inflicted on us by BSD and then mashed up by POSIX then a syscall of
>
>  int err = ptypair(int fd[2], int perms, int flags);
>
>[where flags is the O_ ones we usually need to cover (CLOEXEC etc) and
>maybe even some kind of "private" flag to say don't even expose it via
>devpts).
>
>would do remarkably sane things to the majoirty of use cases as it
>breaks
>the dependence on grantpt and also the historic screwup that pty pairs
>aren't allocated atomically with both file handles returned as pipe()
>does.
>
>Alan

We don't even need to do that if we'd be willing to change the user space 
interface... if we could rely on the POSIX interface then posix_openpt() could 
simply open /dev/pts/ptmx and everything would just work.

The trick here is how to make it work in the presence of some extremely bad 
practices in existing userspace.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [alsa-devel] [PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver

[Lars-Peter Clausen]

On 04/08/2016 06:08 PM, Jose Abreu wrote:
> Hi Lars,
> 
> 
> On 08-04-2016 16:52, Lars-Peter Clausen wrote:
>> On 04/08/2016 12:06 PM, Jose Abreu wrote:
>>> Hi Mark,
>>>
>>>
>>> On 07-04-2016 18:53, Mark Brown wrote:
 On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote:

> + Optional properties:
> + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If set
> +   it is required to use the properties 'dmas' and 'dma-names'.
 This is not a good interface, it's describing Linux internal APIs.  If
 the device needs to operate in PIO mode it should just do that.
>>> I added this interface because there is no direct way to check if DMA is
>>> available on the I2S controller so it is not possible to automatically 
>>> change
>>> between DMA and PIO mode. As the I2S controller can be built with or 
>>> without DMA
>>> support it is necessary to somehow check if DMA is enabled or not and 
>>> according
>>> to that use either ALSA DMA engine or the custom platform driver sent in 
>>> these
>>> patches. I did not want to remove drivers functionality so I added this 
>>> property
>>> to the DT. This way a user can select between DMA and PIO mode.
>> That's OK, but you need to describe the hardware, not the indented behavior
>> of the software driver.
>>
> 
> Is this okay: "snps,use-dmaengine: Set this boolean paramater if I2S 
> controller
> has DMA support. If set the properties 'dmas' and 'dma-names' must be also 
> set" ?

The description is better. But the name of the property is still imperative
rather then descriptive. It tells the software what should be done rather
then describing what the hardware looks like.

Since there is already the dmas property which is present if a DMA is
connected and is absent when no DMA is present it should be enough to just
check that property rather than requiring an additional one.

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

[Eric W. Biederman]

"H. Peter Anvin"  writes:

> On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes 
>  wrote:
>>
>>> If anyone has a better idea on how userspace should connect the
>>master
>>> pty file descriptor the slave file descriptor, I would be willing to
>>> implement that instead.
>>
>>If we are willing to go away from the existing mess of a tty interface
>>inflicted on us by BSD and then mashed up by POSIX then a syscall of
>>
>>  int err = ptypair(int fd[2], int perms, int flags);
>>
>>[where flags is the O_ ones we usually need to cover (CLOEXEC etc) and
>>maybe even some kind of "private" flag to say don't even expose it via
>>devpts).
>>
>>would do remarkably sane things to the majoirty of use cases as it
>>breaks
>>the dependence on grantpt and also the historic screwup that pty pairs
>>aren't allocated atomically with both file handles returned as pipe()
>>does.
>>
>>Alan
>
> We don't even need to do that if we'd be willing to change the user
> space interface... if we could rely on the POSIX interface then
> posix_openpt() could simply open /dev/pts/ptmx and everything would
> just work.

At a quick skim it does look like userspace uses posix_openpt for the
most part.  Certainly portable apps that can run on FreeBSD do.
And just grepping through binaries all of the ones I have checked so far
are calling posix_openpt.

Peter if you or someone could start updating the userspace version of
posix_openpt to use /dev/pts/ptmx when available over /dev/ptmx in
parallel to the kernel work to always allow mount of devpts to give
distinct instances that would be great.

> The trick here is how to make it work in the presence of some
> extremely bad practices in existing userspace.

Yeah.  I am going to look and see if I can move this controversial bit
to a separate patch so we can discuss it more conviniently.

Eric

Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support

[Lars-Peter Clausen]

On 04/08/2016 06:12 PM, Jose Abreu wrote:
[...]
>>
>> [...]
>>> +- adi,enable-audio: If set the ADV7511 driver will register a codec 
>>> interface
>>> +  into ALSA SoC.
>> This is not a description of the hardware.
> 
> Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511
> transmitter routes audio signals" ?

I don't think we need this property. There is no problem with registering
the audio part unconditionally. As long as there is no connection we wont
create a sound card that is exposed to userspace.

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

[Mike Galbraith]

On Sat, 2016-04-09 at 14:33 +0200, Rafael J. Wysocki wrote:
> On Sat, Apr 9, 2016 at 8:40 AM, Mike Galbraith  
> wrote:
> > On Fri, 2016-04-08 at 22:59 +0200, Rafael J. Wysocki wrote:
> > > On Friday, April 08, 2016 08:50:54 AM Mike Galbraith wrote:
> > > > On Fri, 2016-04-08 at 08:45 +0200, Peter Zijlstra wrote:
> > > > 
> > > > > Cute, I thought you used governor=performance for your runs?
> > > > 
> > > > I do, and those numbers are with it thus set.
> > > 
> > > Well, this is a trade-off.
> > > 
> > > 4.5 introduced a power regression here so this one goes back to the 
> > > previous
> > > state of things.
> > 
> > That sounds somewhat reasonable.  Too bad I don't have a super duper
> > watt meter handy.. seeing that you really really are saving me money
> > would perhaps make me less fond of those prettier numbers.
> 
> You can look at the turbostat Watts numbers ("turbostat --debug" and
> the last three columns of the output in turbostat as included in the
> kernel source).

Hm.  I think I want my prettier numbers back.

714KHz/877KHz = 0.81
25Watt/30Watt = 0.83

-Mike

[PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled

[Andi Kleen]

From: Andi Kleen 

When I run chrome on my opensuse system every time I open
a new tab the system log is spammed with:

audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857
comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e
syscall=273 compat=0 ip=0x7fe27c11a444 code=0x5

This happens because chrome uses SECCOMP for its sandbox,
and for some reason always reaches a SECCOMP_KILL or more likely
SECCOMP_RET_ERRNO in the rule set.

The seccomp auditing was originally added by Eric with

commit 85e7bac33b8d5edafc4e219c7dfdb3d48e0b4e31
Author: Eric Paris 
Date:   Tue Jan 3 14:23:05 2012 -0500

seccomp: audit abnormal end to a process due to seccomp

The audit system likes to collect information about processes that
end
abnormally (SIGSEGV) as this may me useful intrusion detection
information.
This patch adds audit support to collect information when seccomp
forces a
task to exit because of misbehavior in a similar way.

I don't have any other syscall auditing enabled,
just the standard user space auditing used by the systemd
and PAM userland. So basic auditing is alwas enabled,
but no other kernel auditing.

I don't think it makes much sense to only log seccomp events when
nothing else is audited by the kernel.

So make the seccomp auditing depend on syscall auditing being
enabled. This stops the log spam on my system, and still gives
the information on system with heavier auditing enabled.

Cc: epa...@redhat.com
Signed-off-by: Andi Kleen 
---
 include/linux/audit.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index e38e3fc..379970f 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -317,7 +317,7 @@ void audit_core_dumps(long signr);
 
 static inline void audit_seccomp(unsigned long syscall, long signr, int code)
 {
-   if (!audit_enabled)
+   if (!audit_enabled || !test_thread_flag(TIF_SYSCALL_AUDIT))
return;
 
/* Force a record to be reported if a signal was delivered. */
-- 
2.7.4

Re: [Intel-gfx] [PATCH] fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

[Matthew Auld]

There's already a patch in the works for this:
https://patchwork.freedesktop.org/patch/80078/

Regards,
Matt

По поводу изготовления наружной рекламы

[Световые Короба]

Здравствуйте!

Не так давно я проходил мимо Вашего здания, и заметил, что на фасаде здания нет 
вывески Вашей организации.

Я профессионально занимаюсь производством и установкой вывесок (у нас своя 
мастерская).

Размещение рекламных вывесок в Вашем здании разрешено. Поток привлеченных 
клиентов с улицы - быстро окупит вывеску.

Мы можем изготовить:
- Вывески - от 5500 руб.
- Объемные буквы от 85 руб. см
- Световые короба 9000 руб.
- И другое виды конструкций.

По вывескам могу предложить много интересных вариантов - бюджетных и более 
серьезных.

Если принципиально интерес у Вас есть - просто напишите - какого размера и 
какого типа вывеску Вам хотелось бы - я смогу рассчитать стоимость изготовления 
и монтаж. 

С уважением, Юрий.

Re: [PATCH 04/10] iio: stx104: Change STX104 dependency to ISA_BUS

[One Thousand Gnomes]

> It looks like I'm in quite a pickle. Even if the patch for the PnPBIOS
> driver removes the errors and warnings, there may be runtime bugs in
> other drivers expecting X86_32. The only way I can see to prevent that
> is to audit all the drivers which depend on the ISA option -- a behemoth
> undertaking which would be far too impractical and error-prone for me to
> do.

I actually wouldn't worry. We've got lots of other drivers that don't
work on all the platforms they should because nobody has ever tried them
out.

At least if they compile on the different platforms people will be able
to try them. It's not making anything any worse - it used to not work and
it still doesn't work is the failure case 8)

Alan

Re: Kernel stability on baytrail machines

[Pavel Machek]

Hi!

> aprox. 6 months ago I started facing random freezes on my baytrail
> based computers I manage. It took me a while before I found a bug
> report in freedesktop bugzilla named "complete freeze after:
> drm/i915/vlv: WA for Turbo and RC6 to work together" -
> https://bugs.freedesktop.org/show_bug.cgi?id=88012. It took a few
> more months for this bug to escalate into MAJOR importance and was
> later moved into kernel bugzilla as "intel_idle.max_cstate=1
> required on baytrail to prevent crashes" -
> https://bugzilla.kernel.org/show_bug.cgi?id=109051.
> 
> Based on the ammount of comments in both bugtickets and probably
> connected observations on different linux distros forums, this seems
> to be a showstopper on mainstream Baytrail based machines for many
> users. I'm trying to understand, how visible (and thus important) is
> this instability across baytrail machines on linux kernel across
> population.
> 
> I do feel that the importance of the mentioned bug is currently
> underestimated. Can anyone here give a note, how much current linux
> kernel is supposed to be stable on general baytrail machines?

If you did not get any replies... you might want to check MAINTAINERS file, and
put Intel x86 maintainers on Cc list.

I'm sure someone cares :-).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

[Pavel Machek]

Hi!

> >>>What's tricky about patterns is that you need to control 3 (or more)
> >>>leds at a time. Problem you are trying to solve here is ... control of
> >>>3 leds, at the same time.
> >>>
> >>>So let's solve them together.
> >>
> >>OK, now I've got your point. So we'd need to have a means for defining
> >>patterns. The interface could be located at /sys/class/leds/patterns.
> >>
> >>We'd need to have a flexible way for defining LED class devices involved
> >>in a pattern. Since we cannot guarantee no space in a LED class device
> >>name, then a single attribute containing space separated list is not an
> >>option. We'd have to create a predefined set of attributes that would
> >>contain LED class device name. Predefined implies that it would be
> >>a fixed number, i.e. either some attributes would always remain unused
> >>or, which is even worse, we could run out of free attributes for some
> >>use cases.
> >
> >There's a better solution: make pattern behave as a trigger for leds
> >it controls.
> >
> >So we'd have
> >
> >/sys/class/leds/patterns/lp5523
> >
> >then we'd have
> >
> >/sys/class/leds/lp5523::red/trigger = "lp5523:1"
> >/sys/class/leds/lp5523::green/trigger = "lp5523:2"
> >/sys/class/leds/lp5523::blue/trigger = "lp5523:3"
> >
> >(or something similar, I'd have to boot the n900 to see the exact
> >names).
> 
> How about implementing patterns as a specific typer of triggers?
> Let's say we have ledtrig-rgb-pattern:

Well, we'd need ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, ... , as we
can have more than one rgb led. But yes.

> After setting a trigger following sysfs attribute would appear
> in a LED class device sysfs interface:
> 
> $cat /sys/class/lp5523::red/rgb_color
> red green blue [none]
> 
> $echo "red" > /sys/class/leds/lp5523::red/rgb_color
> 
> and similarly
> 
> $echo "green" > /sys/class/leds/lp5523::green/rgb_color
> $echo "blue" > /sys/class/leds/lp5523::blue/rgb_color

Yes, that would work -- selecting channels from the pattern.

> Similar approach could be applied for blink patterns:
> There could be additional attributes provided for defining
> the position in a blink sequence, or/and blink period.

For patterns, I'd suggest array of (r g b time) values.

Pattern engines can do stuff like "slowly turn LED from off to red, then switch 
color to
white, then slowly turn it to yellow, then turn it off at once" with defined 
speeds
for "slowly" and option of either linear on non-linear brightness ramping.

The last option might be a bit too much, but I believe we should support the 
rest.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

[Pavel Machek]

Hi!

> >> Also, because soon enough we will have to support USB Power Delivery
> >> with Type C connector, this is bound to change in the coming months.
> >> 
> >> Frankly, I wanted all of this to be decided in userland with the
> >> kernel just providing notification and basic safety checks (we don't
> >> want to allow a bogus userspace daemon frying anybody's devices).
> >> 
> >> How would you feel about that ?
> >
> > So init=/bin/bash boot no longer provides machine that charges itself?
> >
> > That would be bad. Traditionally, hardware controls battery charging,
> > and if hardware needs some help, we should do it in kernel, to mask
> > the difference from userspace.
> 
> this is a very valid point which I hadn't considered :-)
> 
> Seems like kernel it is, no matter how easy or how difficult it gets.

Basically yes. Note that for some bells & whistles, you can require userland 
help.

For example it would probably be ok if it charged slower than usual... but I 
guess
that does not really help in this case.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

[Peter Zijlstra]

On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote:
> > Yes, I'm familiar with the problem; but simply mandating leaf only nodes
> > is not a solution, for the very simple fact that there are tasks in the
> > root cgroup that cannot ever be moved out, so we _must_ be able to deal
> > with !leaf nodes containing tasks.
> 
> As Johannes already pointed out, the root cgroup has always been
> special.

The root of the tree isn't special except for 2 properties.

 - it _is_ a root; iow, it doesn't have any incoming edges.
   This also means it doesn't have a parent; nor can have a weight,
   since that is an edge propery, not a node property.

 - it always exists; for without a root there is no tree.

Making it _more_ special is silly.

> > Maybe, but so far I've only heard people complain this v2 thing didn't
> > work for them, and as far as I can see the whole v2 model is internally
> > inconsistent and impossible to implement.
> 
> I suppose we live in different bubbles.  Can you please elaborate
> which parts of cgroup v2 model are internally inconsistent and
> impossible to implement?  I'd be happy to rectify the situation.

The fact that we have to deal with tasks in the root cgroup while not
allowing tasks in any other node is internally inconsistent.

If I can deal with tasks in one node (root) I can equally deal with
tasks in any other node in exactly the same manner.

Making it different is actually _more_ code.

Hello....!!

[Paul Lukas]

PEASE URGENT RESPONSE,

I am Dr Paul Lukas,the Audit and Account Manager (A.D.B)Bank in Ouagadougou 
Burkina Faso,west africa

I have a business transaction for you.In my department i discovered an 
abandoned Sum of US$10.2 Million Dollars.In an account that belongs to one of 
our late foreign customer who died on Air crash with his family member. ever 
Since he died,Nobody to claim the left over balance in the account.
It is therefore upon this discovery that I decided to seek your assistance to 
present you as his business associate for my bank to transfer the funds to your 
account.

If you accept i would give you the guide lines of how we can achieve this 
transfer of the balance $10.2 Million Dollars to your account.
the fund will be share 50-50%. by both of us

if you are capable to handle this transaction please furnish me the following 
information for more details.

Full names:...
Country:..
Your pravite phone number:...
Your Age/Sex:..

Regards,
Dr Paul Lukas.

begger help for this comment about intel_cacheinfo.c

[赵瑞哲]

in this commit

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/arch/x86/kernel/cpu/intel_cacheinfo.c?id=b2bb85549134c005e997e5a7ed303bda6a1ae738

Mike wrote:
> We should not try to save and restore cpus_allowed on current. We can't use 
> work_on_cpu() here, > since it's in the hotplug cpu path (if anyone else 
> tries to get the hotplug lock from a workqueue we > could deadlock against 
> them). Fortunately, we can just use smp_call_function_single() since the > 
> function can run from an interrupt.

but I really can't understand that how the deadlock works.

anyone can give some hints?

any response is appreiated :)

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

[Mike Galbraith]

Hm, setting gov=performance, and taking the average of 3 30 second
interval PkgWatt samples as pipe-test runs..

714KHz/28.03Ws = 25.46
877KHz/30.28Ws = 28.96

..for pipe-test, the tradeoff look a bit more like red than green.

-Mike

Re: [PATCH v1 00/12] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

[Bryan O'Donoghue]

On Thu, 2016-04-07 at 23:37 +0300, Andy Shevchenko wrote:
> This is combined series of two things:
>  - split out the Intel LPSS specific driver from 8250_pci into
> 8250_lpss
>  - enable DMA support on Intel Quark UART
> 
> The patch has been tested on few Intel SoCs / platforms.
> 
> This is targeting serial subsystem, thus it would be nice to get and
> Ack from Vinod first.
> Moreover, the series depends on series [1] that is now under review.
> 
> That's why I ask Vinod to create immutable tag / branch for the [1]
> and the
> dependants (at least one more, which is sata_dwc_460ex).
> 
> [1] http://www.spinics.net/lists/dmaengine/msg08709.html

Andy.

Which tree/branch exactly are you applying this against ? I'd like to
test it out on Galileo.

Could you give a link ?

---
bod

Re: Kernel crash on startup - bisected to commit 3b24d854cb35

[Larry Finger]

On 04/09/2016 12:33 AM, Eric Dumazet wrote:

On Fri, Apr 8, 2016 at 10:28 PM, Larry Finger  wrote:

Following a recent pull of the wireless-drivers-next repo. my system got a
kernel panic on startup at native_apic_msr_write+0x27. The problem was
bisected to commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt
under synflood"). I am confident of the bisection as a kernel built with the
previous commit (3a5d1c0) boots OK.

I have not yet captured the entire traceback for the crash, but I do have a
crappy photo of the screen that I have attached. The RIP is at
native_apic_msr_write+0x27. As this crash is likely configuration dependent,
a copy of my .config is also attached. Note that IPv6 is turned off on my
machine.

Please let me know if any other info is needed.


Can you double check you have this fix ?

commit 8501786929de4616b10b8059ad97abd304a7dddf
Author: Eric Dumazet 
Date:   Wed Apr 6 22:07:34 2016 -0700

 tcp/dccp: fix inet_reuseport_add_sock()

 David Ahern reported panics in __inet_hash() caused by my recent commit.

 The reason is inet_reuseport_add_sock() was still using
 sk_nulls_for_each_rcu() instead of sk_for_each_rcu().
 SO_REUSEPORT enabled listeners were causing an instant crash.

 While chasing this bug, I found that I forgot to clear SOCK_RCU_FREE
 flag, as it is inherited from the parent at clone time.

 Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt
under synflood")
 Signed-off-by: Eric Dumazet 
 Reported-by: David Ahern 
 Tested-by: David Ahern 
 Signed-off-by: David S. Miller 


No, I did not have that patch. After pulling from net-next to get it, my system 
no longer panics.


Note to linux-wireless readers. At the moment, a system built from 
wireless-drivers-next will have this problem.


Thanks,

Larry

Re: HVMLite / PVHv2 - using x86 EFI boot entry

[Luis R. Rodriguez]

On Wed, Apr 06, 2016 at 01:11:30PM +0200, Daniel Kiper wrote:
> On Wed, Apr 06, 2016 at 04:40:27AM +0200, Luis R. Rodriguez wrote:
> > Boris sent out the first HVMLite series of patches to add a new Xen guest 
> > type
> > February 1, 2016 [0]. We've been talking off list with a few folks now over
> > the prospect of instead of adding yet-another-boot-entry we instead fixate
> > HVMLite to use the x86 EFI boot entry. There's a series of reasons to 
> > consider
> > this, likewise there are reasons to question the effort required and if its
> > really needed. We'd like some more public review of this proposal, and see 
> > if
> > others can come up with other ideas, both in favor or against this proposal.
> >
> > This in particular is also a good time to get x86 Linux folks to chime on on
> > the general design proposal of HVMLite design, given that outside of the 
> > boot
> > entry discussion it would seem including myself that we didn't get the memo
> > over the proposed architecture review [1]. At least on my behalf perhaps the
> > only sticking thorns of the design was the new boot entry, which came to me
> > as a surprise, and this thread addresses and the lack of addressing 
> > semantics
> > for early boot (which we may seem to need to address; some of this is being
> > addressing in parallels through other work). The HVMLite document talks 
> > about
> > using ACPI_FADT_NO_VGA -- we don't use this yet upstream but I have some 
> > pending
> > changes which should make it easy to integrate its use on HVMLite. Perhaps
> > there are others that may have some other points they may want to raise 
> > now...
> >
> > A huge summary of the discussion over EFI boot option for HVMLite is now on 
> > a
> > wiki [2], below I'll just provide the outline of the discussion. Consider 
> > this a
> > request for more public review, feel free to take any of the items below and
> > elaborate on it as you see fit.
> >
> > Worth mentioning also is that this topic will be discussed at the 2016 Xen
> > Hackathon April 18-19 [3] at the ARM Cambridge, UK Headquarters so if you 
> > can
> > attend and this topic interests you, consider attending.
> 
> I hope that you will be there as one of the biggest proponents of EFI entry 
> point.
> If you does not it will be difficult or impossible to discuss this issue 
> without you.
> In the worst case I can raise this topic on behalf of you and then we should 
> organize
> phone call if possible (and accepted by others). However, to do that I must 
> know your
> plans in advance.

I'll be there!

  Luis

[GIT PULL] USB driver fixes for 4.6-rc3

[Greg KH]

The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9:

  Linux 4.6-rc2 (2016-04-03 09:09:40 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.6-rc3

for you to fetch changes up to 636c8a8d85d0564222071f0caa4a4e6bf527efe5:

  Merge tag 'usb-serial-4.6-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus 
(2016-04-08 15:41:58 -0700)


USB fixes for 4.6-rc3

Here are some USB fixes and new device ids for 4.6-rc3.

Nothing major, the normal USB gadget fixes and usb-serial driver ids,
along with some other fixes mixed in.  All except the USB serial ids
have been tested in linux-next, the id additions should be fine as they
are "trivial".

Signed-off-by: Greg Kroah-Hartman 


Arnd Bergmann (1):
  usb: phy: qcom-8x16: fix regulator API abuse

Bjørn Mork (1):
  USB: option: add "D-Link DWM-221 B1" device id

Dan Carpenter (1):
  usb: gadget: f_midi: unlock on error

Felipe Balbi (3):
  usb: dwc3: core: improve reset sequence
  usb: dwc3: gadget: fix endpoint renaming
  usb: gadget: udc: atmel: don't disable enpdoints we don't own

Felipe F. Tonello (2):
  usb: gadget: f_midi: added spinlock on transmit function
  usb: gadget: f_midi: Fixed a bug when buflen was smaller than 
wMaxPacketSize

Greg Kroah-Hartman (3):
  Merge tag 'fixes-for-v4.6-rc2' of git://git.kernel.org/.../balbi/usb into 
usb-linus
  Merge tag 'fixes-for-v4.6-rc3' of git://git.kernel.org/.../balbi/usb into 
usb-linus
  Merge tag 'usb-serial-4.6-rc3' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus

Grygorii Strashko (2):
  usb: gadget: udc-core: remove manual dma configuration
  usb: dwc3: keystone: drop dma_mask configuration

Heikki Krogerus (1):
  usb: dwc3: pci: add ID for one more Intel Broxton platform

Ignat Korchagin (1):
  USB: usbip: fix potential out-of-bounds write

Jiebing Li (1):
  usb: dwc3: gadget: release spin lock during gadget resume

John Youn (2):
  usb: gadget: composite: Access SSP Dev Cap fields properly
  usb: ch9: Fix SSP Device Cap wFunctionalitySupport type

Josh Boyer (1):
  USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices

Martyn Welch (1):
  USB: serial: cp210x: Adding GE Healthcare Device ID

Mathias Nyman (1):
  usb: fix regression in SuperSpeed endpoint descriptor parsing

Oliver Neukum (3):
  USB: mct_u232: add sanity checking in probe
  USB: cypress_m8: add endpoint sanity check
  USB: digi_acceleport: do sanity checking for the number of ports

Przemek Rudy (1):
  usb: dwc2: do not override forced dr_mode in gadget setup

Yoshihiro Shimoda (3):
  usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler()
  usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer
  usb: renesas_usbhs: fix to avoid using a disabled ep in 
usbhsg_queue_done()

 drivers/usb/core/config.c   | 16 
 drivers/usb/dwc2/gadget.c   | 23 ---
 drivers/usb/dwc3/core.c | 48 +-
 drivers/usb/dwc3/dwc3-keystone.c|  5 ---
 drivers/usb/dwc3/dwc3-pci.c |  2 +
 drivers/usb/dwc3/gadget.c   | 11 +++--
 drivers/usb/gadget/composite.c  |  8 ++--
 drivers/usb/gadget/function/f_midi.c| 17 +++-
 drivers/usb/gadget/udc/atmel_usba_udc.c | 14 ---
 drivers/usb/gadget/udc/udc-core.c   |  6 ---
 drivers/usb/phy/phy-qcom-8x16-usb.c | 72 +
 drivers/usb/renesas_usbhs/fifo.c|  4 +-
 drivers/usb/renesas_usbhs/mod_gadget.c  |  6 ++-
 drivers/usb/serial/cp210x.c |  1 +
 drivers/usb/serial/cypress_m8.c | 11 +++--
 drivers/usb/serial/digi_acceleport.c| 19 +
 drivers/usb/serial/ftdi_sio.c   |  4 ++
 drivers/usb/serial/ftdi_sio_ids.h   |  8 
 drivers/usb/serial/mct_u232.c   |  9 -
 drivers/usb/serial/option.c |  2 +
 drivers/usb/usbip/usbip_common.c| 11 +
 include/uapi/linux/usb/ch9.h|  2 +-
 22 files changed, 151 insertions(+), 148 deletions(-)

[GIT PULL] Staging driver fixes for 4.6-rc3

[Greg KH]

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-4.6-rc3

for you to fetch changes up to 53c43c5ca13328ac8f415aa2251791b441a12b51:

  Revert "Staging: olpc_dcon: Remove obsolete driver" (2016-04-04 13:52:35 
-0700)


Staging / IIO driver fixes for 4.6-rc3

Here are some IIO driver fixes, along with two staging driver fixes for
4.6-rc3.

One staging driver patch reverts the deletion of a driver that happened
in 4.6-rc1.  We thought that laptop.org was dead, but it's still alive
and kicking, and has users that were mad we broke their hardware by
deleting a driver for their machines.  So that driver is added back and
everyone is happy again.

All of these have been in linux-next for a while with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Arnd Bergmann (1):
  iio: st_magn: always define ST_MAGN_TRIGGER_SET_STATE

Greg Kroah-Hartman (3):
  Merge tag 'iio-fixes-for-4.6a' of git://git.kernel.org/.../jic23/iio into 
usb-linus
  Merge tag 'iio-fixes-for-4.6b' of git://git.kernel.org/.../jic23/iio into 
staging-linus
  Revert "Staging: olpc_dcon: Remove obsolete driver"

Irina Tirdea (4):
  iio: fix config watermark initial value
  iio: accel: bmc150: fix endianness when reading axes
  iio: gyro: bmg160: fix endianness when reading axes
  iio: gyro: bmg160: fix buffer read values

Krzysztof Kozlowski (1):
  iio: adc: Fix build error of missing devm_ioremap_resource on UM

Markus Böhme (1):
  staging/rdma/hfi1: select CRC32

Matt Ranostay (2):
  iio: light: apds9960: correct FIFO check condition
  iio: health: max30100: correct FIFO check condition

Richard Weinberger (1):
  iio: imu: Fix inv_mpu6050 dependencies

Stefan Eichenberger (2):
  iio: adc: max1363: add missing adc to max1363_id
  iio: adc: max1363: correct reference voltage

 MAINTAINERS  |   8 +
 drivers/iio/accel/bmc150-accel-core.c|   7 +-
 drivers/iio/adc/Kconfig  |   1 +
 drivers/iio/adc/max1363.c|  12 +-
 drivers/iio/gyro/bmg160_core.c   |   9 +-
 drivers/iio/health/max30100.c|   3 +-
 drivers/iio/imu/inv_mpu6050/Kconfig  |   3 +-
 drivers/iio/industrialio-buffer.c|   1 +
 drivers/iio/light/apds9960.c |   3 +-
 drivers/iio/magnetometer/st_magn.h   |   1 +
 drivers/staging/Kconfig  |   2 +
 drivers/staging/Makefile |   1 +
 drivers/staging/olpc_dcon/Kconfig|  35 ++
 drivers/staging/olpc_dcon/Makefile   |   6 +
 drivers/staging/olpc_dcon/TODO   |   9 +
 drivers/staging/olpc_dcon/olpc_dcon.c| 813 +++
 drivers/staging/olpc_dcon/olpc_dcon.h| 111 
 drivers/staging/olpc_dcon/olpc_dcon_xo_1.c   | 205 +++
 drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c | 161 ++
 drivers/staging/rdma/hfi1/Kconfig|   1 +
 20 files changed, 1377 insertions(+), 15 deletions(-)
 create mode 100644 drivers/staging/olpc_dcon/Kconfig
 create mode 100644 drivers/staging/olpc_dcon/Makefile
 create mode 100644 drivers/staging/olpc_dcon/TODO
 create mode 100644 drivers/staging/olpc_dcon/olpc_dcon.c
 create mode 100644 drivers/staging/olpc_dcon/olpc_dcon.h
 create mode 100644 drivers/staging/olpc_dcon/olpc_dcon_xo_1.c
 create mode 100644 drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c

[GIT PULL] TTY/Serial fixes for 4.6-rc3

[Greg KH]

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.6-rc3

for you to fetch changes up to 5e00bbfbc5ec21e87d24e206bba9fc2cbe6631a1:

  tty: Fix merge of "tty: Refactor tty_open()" (2016-03-31 20:49:39 -0700)


TTY fixes for 4.6-rc3

Here are two tty fixes for issues found.  One was due to a merge error
in 4.6-rc1, and the other a regression fix for UML consoles that broke
in 4.6-rc1.

Both have been in linux-next for a while.

Signed-off-by: Greg Kroah-Hartman 


Peter Hurley (2):
  tty: Fix UML console breakage
  tty: Fix merge of "tty: Refactor tty_open()"

 drivers/tty/tty_io.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Re: [PATCH RFC] select_idle_sibling experiments

[Chris Mason]

On Wed, Apr 06, 2016 at 09:27:24AM +0200, Mike Galbraith wrote:
> > On Tue, 2016-04-05 at 14:08 -0400, Chris Mason wrote:
> 
> > Now, on to the patch.  I pushed some code around and narrowed the
> > problem down to select_idle_sibling()   We have cores going into and out
> > of idle fast enough that even this cut our latencies in half:
> 
> Are you using NO_HZ?  If so, you may want to try the attached.

[ nohz throttling patch ]

I tested the nohz throttle two different ways, first with schbench's
pipe simulation, it's easily 8% faster with messages bouncing between
cpus.

In production it's hard to pick a single number because the benchmarks
produce latency curves as the workload scales up in RPS.  The benefits
range from 2-9% depending on the metric.  It's a nice win, and I'd love to
see it go in.

-chris

[PATCH] ARM: dts: imx6: Add dts for Embest MarS Board

[Sergio Prado]

Embest MarS Board [1] is a multi-core platform based on Freescale i.MX6
Cortex-A9 Dual Core, running up to 1GHz with 1 GB of RAM, 4GB of eMMC
and with a 4MB SPI flash.

[1] http://www.embest-tech.com/shop/star/marsboard.html

Signed-off-by: Sergio Prado 
---
 arch/arm/boot/dts/imx6q-marsboard.dts | 411 ++
 1 file changed, 411 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-marsboard.dts

diff --git a/arch/arm/boot/dts/imx6q-marsboard.dts 
b/arch/arm/boot/dts/imx6q-marsboard.dts
new file mode 100644
index ..a2bcc795ef3f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-marsboard.dts
@@ -0,0 +1,411 @@
+/*
+ * Copyright (C) 2016 Sergio Prado (sergio.pr...@e-labworks.com)
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include 
+
+/ {
+   model = "Embest MarS Board i.MX6Dual";
+   compatible = "embest,imx6q-marsboard", "fsl,imx6dl";
+
+   memory {
+   reg = <0x1000 0x4000>;
+   };
+
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg_3p3v: regulator@1 {
+   compatible = "regulator-fixed";
+   reg = <1>;
+   regulator-name = "3P3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   reg_usb_otg_vbus: regulator@2 {
+   compatible = "regulator-fixed";
+   reg = <2>;
+   regulator-name = "usb_otg_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_led>;
+
+   led@1 {
+   label = "imx6:green:user1";
+   gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   linux,default-trigger = "heartbeat";
+   };
+
+   led@2 {
+   label = "imx6:green:user2";
+   gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+   };
+};
+
+&uart1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart1>;
+   status = "okay";
+};
+
+&uart2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart2>;
+   status = "okay";
+};
+
+&uart3 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart3>;
+   status = "okay";
+};
+
+&uart4 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart4>;
+   status = "okay";
+};
+
+&uart5 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart5>;
+   status = "okay";
+};
+
+&fec {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinc

Re: [PATCH v1 00/12] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

[Andy Shevchenko]

On Sat, Apr 9, 2016 at 7:53 PM, Bryan O'Donoghue
 wrote:
> On Thu, 2016-04-07 at 23:37 +0300, Andy Shevchenko wrote:
>> This is combined series of two things:
>>  - split out the Intel LPSS specific driver from 8250_pci into
>> 8250_lpss
>>  - enable DMA support on Intel Quark UART
>>
>> The patch has been tested on few Intel SoCs / platforms.
>>
>> This is targeting serial subsystem, thus it would be nice to get and
>> Ack from Vinod first.
>> Moreover, the series depends on series [1] that is now under review.
>>
>> That's why I ask Vinod to create immutable tag / branch for the [1]
>> and the
>> dependants (at least one more, which is sata_dwc_460ex).
>>
>> [1] http://www.spinics.net/lists/dmaengine/msg08709.html
>
> Andy.
>
> Which tree/branch exactly are you applying this against ? I'd like to
> test it out on Galileo.
>

It's based on linux-next. it would be nice to have your tag / comments!

> Could you give a link ?
>

You may try my branch
https://bitbucket.org/andy-shev/linux/branch/topic%2Fdw%2Fqrk

> ---
> bod
>



-- 
With Best Regards,
Andy Shevchenko

[GIT PULL] libnvdimm fixes for 4.6-rc3

[Williams, Dan J]

Hi Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes

...to receive 3 fixes, the first 2 are tagged for -stable.

1/ The ndctl utility/library gained expanded unit tests illuminating a
long standing bug in the libnvdimm SMART data retrieval implementation.
 It has been broken since its initial implementation, now fixed.

2/ Another one line fix for the detection of stale info blocks.
 Without this change userspace can get into a situation where it is
unable to reconfigure a namespace.

3/ Fix the badblock initialization path in the presence of the new (in
4,6-rc1) section alignment workarounds.  Without this change badblocks
will be reported at the wrong offset.

These have received a build success report from the kbuild robot and
have appeared in -next with no reported issues.

The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9:

  Linux 4.6-rc2 (2016-04-03 09:09:40 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes

for you to fetch changes up to a390180291dd9a2392bbab4242cde712c326efc6:

  libnvdimm, pfn: fix nvdimm_namespace_add_poison() vs section alignment 
(2016-04-07 20:02:06 -0700)


Dan Williams (3):
  libnvdimm: fix smart data retrieval
  libnvdimm, pfn: fix uuid validation
  libnvdimm, pfn: fix nvdimm_namespace_add_poison() vs section alignment

 drivers/nvdimm/bus.c  |  2 +-
 drivers/nvdimm/core.c | 41 -
 drivers/nvdimm/nd.h   |  4 ++--
 drivers/nvdimm/pfn_devs.c |  2 +-
 drivers/nvdimm/pmem.c | 36 +---
 5 files changed, 53 insertions(+), 32 deletions(-)

Клиентские базы тел +79139393506 (tеlеgгam_whatsaрр_vibег) Skype: prodawez389 Email: prodawez...@yandex.ru

[linux-kernel@vger.kernel.org]

Клиентские базы тел +79139393506 (tеlеgгam_whatsapp_vibег) Skype: prodawez389 
Email: prodawez...@yandex.ru

[PATCH] of: Add vendor prefix for Shenzhen Embest Technology

[Sergio Prado]

Signed-off-by: Sergio Prado 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index e52cc8a6b2ae..3d08bafd5669 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -74,6 +74,7 @@ eaEmbedded Artists AB
 ebvEBV Elektronik
 edtEmerging Display Technologies
 elan   Elan Microelectronic Corp.
+embest Shenzhen Embest Technology Co., Ltd.
 emmicroEM Microelectronic
 energymicroSilicon Laboratories (formerly Energy Micro AS)
 epcos  EPCOS AG
-- 
1.9.1

sched: tweak select_idle_sibling to look for idle threads

[Chris Mason]

select_task_rq_fair() can leave cpu utilization a little lumpy,
especially as the workload ramps up to the maximum capacity of the
machine.  The end result can be high p99 response times as apps
wait to get scheduled, even when boxes are mostly idle.

I wrote schbench to try and measure this:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/schbench.git

The basic idea is to record the latency between when a thread is kicked
and when it actually gets the CPU.  For this patch I used a simple model
where a thread thinks for a while and then waits for data from another
thread.  The command line below will start two messenger threads with 18
workers per messenger:

./schbench -m 2 -t 18 -s 3 -c 3 -r 30
Latency percentiles (usec)
50.th: 52
75.th: 63
90.th: 74
95.th: 80
*99.th: 118
99.5000th: 707
99.9000th: 5016
Over=0, min=0, max=12941

p99 numbers here are acceptable, but you can see the curve starting.
if I use 19 workers per messenger, p99 goes through the roof.  This
machine has two sockets, 10 cores each, so with HT on, this commandline
has one pthread on each CPU:

./schbench -m 2 -t 19 -s 3 -c 3 -r 30
Latency percentiles (usec)
50.th: 51
75.th: 63
90.th: 76
95.th: 89
*99.th: 2132
99.5000th: 6920
99.9000th: 12752
Over=0, min=0, max=17079

This commit tries to solve things by doing an extra scan in
select_idle_sibling().  If it can find an idle sibling in any core in the
package, it will return that:

./schbench -m2 -t 19 -c 3 -s 3 -r 30
Latency percentiles (usec)
50.th: 65
75.th: 104
90.th: 115
95.th: 118
*99.th: 124
99.5000th: 127
99.9000th: 262
Over=0, min=0, max=12987

This basically means the whole fleet can have one more pthread per socket
and still maintain acceptable latencies.  I can actually go up to -t 20,
but it's not as consistent:

./schbench -m2 -t 20 -c 3 -s 3 -r 30
Latency percentiles (usec)
50.th: 50
75.th: 63
90.th: 75
95.th: 81
*99.th: 111
99.5000th: 975
99.9000th: 12464
Over=0, min=0, max=18317

This does preserve the existing logic to prefer idle cores over idle
CPU threads, and includes some tests to try and avoid the idle scan when we're
actually better off sharing a non-idle CPU with someone else.

Benchmarks in production show overall capacity going up between 2-5%
depending on the metric.

Credits to Arun Sharma  for initial versions of this
patch.

Signed-off-by: Chris Mason 

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 56b7d4b..2c47240 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4969,11 +4969,34 @@ find_idlest_cpu(struct sched_group *group, struct 
task_struct *p, int this_cpu)
 }
 
 /*
+ * helper for select_idle_sibling to decide if it should look for idle
+ * threads
+ */
+static int bounce_to_target(struct task_struct *p, int cpu)
+{
+   s64 delta;
+
+   /*
+* as the run queue gets bigger, its more and more likely that
+* balance will have distributed things for us, and less likely
+* that scanning all our CPUs for an idle one will find one.
+* So, if nr_running > 1, just call this CPU good enough
+*/
+   if (cpu_rq(cpu)->cfs.nr_running > 1)
+   return 1;
+
+   /* taken from task_hot() */
+   delta = rq_clock_task(task_rq(p)) - p->se.exec_start;
+   return delta < (s64)sysctl_sched_migration_cost;
+}
+
+/*
  * Try and locate an idle CPU in the sched_domain.
  */
 static int select_idle_sibling(struct task_struct *p, int target)
 {
struct sched_domain *sd;
+   struct sched_domain *package_sd;
struct sched_group *sg;
int i = task_cpu(p);
 
@@ -4989,7 +5012,8 @@ static int select_idle_sibling(struct task_struct *p, int 
target)
/*
 * Otherwise, iterate the domains and find an elegible idle cpu.
 */
-   sd = rcu_dereference(per_cpu(sd_llc, target));
+   package_sd = rcu_dereference(per_cpu(sd_llc, target));
+   sd = package_sd;
for_each_lower_domain(sd) {
sg = sd->groups;
do {
@@ -4998,7 +5022,12 @@ static int select_idle_sibling(struct task_struct *p, 
int target)
goto next;
 
for_each_cpu(i, sched_group_cpus(sg)) {
-   if (i == target || !idle_cpu(i))
+   /*
+* we tested target for idle up above,
+* but don't skip it here because it might
+* have raced to idle while we were scanning
+*/
+   if (!idle_cpu(i))
goto next;
}
 
@@ -5009,6 +5038,24 @@ next:
sg = sg->next;
  

[PATCH] staging: wilc1000: rework comments in wilc_sdio.c

[mohammed . billoo]

From: Mohammed Billoo 

Remove unnecessary comments (highlighting sections of functions), make
multiline comments into single line comments, and ensure that multiline
comments adhere to coding style.
---
 drivers/staging/wilc1000/wilc_sdio.c | 136 ---
 1 file changed, 31 insertions(+), 105 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index a839a79..a082e12 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -1,11 +1,7 @@
-/* // 
*/
-/*  */
-/* Copyright (c) Atmel Corporation.  All rights reserved. */
-/*  */
-/* Module Name:  wilc_sdio.c */
-/*  */
-/*  */
-/* 
 */
+/* Copyright (c) Atmel Corporation.  All rights reserved.
+ *
+ * Module Name:  wilc_sdio.c
+ */
 
 #include 
 #include "wilc_wlan_if.h"
@@ -257,11 +253,6 @@ static void wilc_sdio_disable_interrupt(struct wilc *dev)
dev_info(&func->dev, "wilc_sdio_disable_interrupt OUT\n");
 }
 
-/
- *
- *  Function 0
- *
- /
 
 static int sdio_set_func0_csa_address(struct wilc *wilc, u32 adr)
 {
@@ -269,9 +260,7 @@ static int sdio_set_func0_csa_address(struct wilc *wilc, 
u32 adr)
struct sdio_cmd52 cmd;
int ret;
 
-   /**
-*  Review: BIG ENDIAN
-**/
+   /* Review: BIG ENDIAN */
cmd.read_write = 1;
cmd.function = 0;
cmd.raw = 0;
@@ -334,11 +323,6 @@ _fail_:
return 0;
 }
 
-/
- *
- *  Function 1
- *
- /
 
 static int sdio_set_func1_block_size(struct wilc *wilc, u32 block_size)
 {
@@ -369,11 +353,7 @@ _fail_:
return 0;
 }
 
-/
- *
- *  Sdio interfaces
- *
- /
+
 static int sdio_write_reg(struct wilc *wilc, u32 addr, u32 data)
 {
struct sdio_func *func = dev_to_sdio_func(wilc->dev);
@@ -398,9 +378,7 @@ static int sdio_write_reg(struct wilc *wilc, u32 addr, u32 
data)
} else {
struct sdio_cmd53 cmd;
 
-   /**
-*  set the AHB address
-**/
+   /* set the AHB address */
if (!sdio_set_func0_csa_address(wilc, addr))
goto _fail_;
 
@@ -436,31 +414,23 @@ static int sdio_write(struct wilc *wilc, u32 addr, u8 
*buf, u32 size)
 
cmd.read_write = 1;
if (addr > 0) {
-   /**
-*  has to be word aligned...
-**/
+   /* has to be word aligned... */
if (size & 0x3) {
size += 4;
size &= ~0x3;
}
 
-   /**
-*  func 0 access
-**/
+   /* func 0 access */
cmd.function = 0;
cmd.address = 0x10f;
} else {
-   /**
-*  has to be word aligned...
-**/
+   /* has to be word aligned... */
if (size & 0x3) {
size += 4;
size &= ~0x3;
}
 
-   /**
-*  func 1 access
-**/
+   /* func 1 access */
cmd.function = 1;
cmd.address = 0;
}
@@ -576,31 +546,23 @@ static int sdio_read(struct wilc *wilc, u32 addr, u8 
*buf, u32 size)
 
cmd.read_write = 0;
if (addr > 0) {
-   /**
-*  has to be word aligned...
-**/
+   /* has to be word aligned... */
if (size & 0x3) {
size += 4;
size &= ~0x3;
}
 
-   /**
-*  func 0 access
-**/
+   /* func 0 access */
cmd.function = 0;
cmd.address = 0x10f;
} else {
-   /**
-*  has to be word aligned...
-**/
+   /* has to be word aligned... */
if (size & 0x3) {
size += 4;
size &= ~0x3;
}
 
-   /**
-*  func 1 access
-**/
+   /* func 1 access */
cmd.function = 1;
cmd.address = 0;
}
@@ -627,7 +589,7 @@ static int sdio_read(struct wilc *wilc, u32 addr, u8 *buf, 
u32 size)
if (addr > 0)
addr += nblk * block_size;
buf += nblk * block_size;
-   }   /* if (nblk > 0) */
+   }
 
if

Re: Kernel stability on baytrail machines

[One Thousand Gnomes]

> > I do feel that the importance of the mentioned bug is currently
> > underestimated. Can anyone here give a note, how much current linux
> > kernel is supposed to be stable on general baytrail machines?  
> 
> If you did not get any replies... you might want to check MAINTAINERS file, 
> and
> put Intel x86 maintainers on Cc list.
> 
> I'm sure someone cares :-).

Yes we care, and there are people looking at the various reports.

Alan

Re: [PATCH] drivers/virtio/virtio_ring.c: Deinline virtqueue_add, save 1016 bytes

[Michael S. Tsirkin]

On Fri, Apr 08, 2016 at 08:58:44PM +0200, Denys Vlasenko wrote:
> This function compiles to 839 bytes of machine code.
> In C, it is ~150 lines long.
> 
> This function has 3 callsites.
> 
> Signed-off-by: Denys Vlasenko 
> CC: "Michael S. Tsirkin" 
> CC: virtualizat...@lists.linux-foundation.org
> CC: linux-kernel@vger.kernel.org

This function is one of the most performance critical ones in the driver, a
bunch of tuning went into it, making this inline intentionally.  I'd
have to see some numbers showing making it non-inline is a worth-while
tradeoff.

> ---
>  drivers/virtio/virtio_ring.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index e12e385..77a4771 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -126,7 +126,7 @@ static struct vring_desc *alloc_indirect(struct virtqueue 
> *_vq,
>   return desc;
>  }
>  
> -static inline int virtqueue_add(struct virtqueue *_vq,
> +static int virtqueue_add(struct virtqueue *_vq,
>   struct scatterlist *sgs[],
>   unsigned int total_sg,
>   unsigned int out_sgs,
> -- 
> 2.1.0

[RFC][PATCHSET] reduce messing with iovecs in cifs

[Al Viro]

Now that sendmsg/recvmsg do not mangle iovecs and are capable of
handling bvec-based ->msg_iter, we can seriously reduce the amount of PITA
in cifs.  The series below is completely untested, and I would appreciate
comments/review/testing/etc.

I'll post the individual patches in followups; for those who prefer to use
git it can be found in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git sendmsg.cifs

1/6: [net] drop 'size' argument of sock_recvmsg()
should go via net-next; does what it says.

2/6: cifs: merge the hash calculation helpers
takes the common parts of {cifs,smb2,smb3}_calc_signature() into a
common helper.

3/6: cifs: quit playing games with draining iovecs
Switch smb_send_kvec() to passing msghdr (and thus iov_iter) and
make it use sock_sendmsg() - that allows to avoid draining iovecs, since
->msg_iter will be advanced properly and all we need is to keep it around
between the calls of sock_sendmsg(), rather than reinitializing it on each
loop iteration.  The same thing allows to get rid of messing with kmap()
when sending the stuff in ->rq_pages[] - ITER_BVEC will do the right thing.

4/6: cifs: no need to wank with copying and advancing iovec on recvmsg side 
either
Similar to the previous - use sock_recvmsg() in cifs_readv_from_socket()
and there's no need to modify iovecs, or allocate a copy especially for
such modifications, etc.

5/6: cifs_readv_receive: use cifs_read_from_socket()
building a 1-element iovec array for cifs_readv_from_socket() is
an overkill - simple cifs_read_from_socket() will do just fine.

6/6: cifs: don't bother with kmap on read_pages side
Similar to the other half of 3/6: we can use ITER_BVEC for
read-into-page case.  Just make cifs_readv_from_socket() take msghdr from
caller and use a helper that would feed it a bvec-backed ->msg_iter.

[PATCH 2/6] cifs: merge the hash calculation helpers

[Al Viro]

three practically identical copies...

Signed-off-by: Al Viro 
---
 fs/cifs/cifsencrypt.c   |  97 ---
 fs/cifs/cifsproto.h |   3 ++
 fs/cifs/smb2transport.c | 107 +---
 3 files changed, 67 insertions(+), 140 deletions(-)

diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
index 4897dac..6aeb8d4 100644
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -66,45 +66,15 @@ cifs_crypto_shash_md5_allocate(struct TCP_Server_Info 
*server)
return 0;
 }
 
-/*
- * Calculate and return the CIFS signature based on the mac key and SMB PDU.
- * The 16 byte signature must be allocated by the caller. Note we only use the
- * 1st eight bytes and that the smb header signature field on input contains
- * the sequence number before this function is called. Also, this function
- * should be called with the server->srv_mutex held.
- */
-static int cifs_calc_signature(struct smb_rqst *rqst,
-   struct TCP_Server_Info *server, char *signature)
+int __cifs_calc_signature(struct smb_rqst *rqst,
+   struct TCP_Server_Info *server, char *signature,
+   struct shash_desc *shash)
 {
int i;
int rc;
struct kvec *iov = rqst->rq_iov;
int n_vec = rqst->rq_nvec;
 
-   if (iov == NULL || signature == NULL || server == NULL)
-   return -EINVAL;
-
-   if (!server->secmech.sdescmd5) {
-   rc = cifs_crypto_shash_md5_allocate(server);
-   if (rc) {
-   cifs_dbg(VFS, "%s: Can't alloc md5 crypto\n", __func__);
-   return -1;
-   }
-   }
-
-   rc = crypto_shash_init(&server->secmech.sdescmd5->shash);
-   if (rc) {
-   cifs_dbg(VFS, "%s: Could not init md5\n", __func__);
-   return rc;
-   }
-
-   rc = crypto_shash_update(&server->secmech.sdescmd5->shash,
-   server->session_key.response, server->session_key.len);
-   if (rc) {
-   cifs_dbg(VFS, "%s: Could not update with response\n", __func__);
-   return rc;
-   }
-
for (i = 0; i < n_vec; i++) {
if (iov[i].iov_len == 0)
continue;
@@ -117,12 +87,10 @@ static int cifs_calc_signature(struct smb_rqst *rqst,
if (i == 0) {
if (iov[0].iov_len <= 8) /* cmd field at offset 9 */
break; /* nothing to sign or corrupt header */
-   rc =
-   crypto_shash_update(&server->secmech.sdescmd5->shash,
+   rc = crypto_shash_update(shash,
iov[i].iov_base + 4, iov[i].iov_len - 4);
} else {
-   rc =
-   crypto_shash_update(&server->secmech.sdescmd5->shash,
+   rc = crypto_shash_update(shash,
iov[i].iov_base, iov[i].iov_len);
}
if (rc) {
@@ -134,21 +102,64 @@ static int cifs_calc_signature(struct smb_rqst *rqst,
 
/* now hash over the rq_pages array */
for (i = 0; i < rqst->rq_npages; i++) {
-   struct kvec p_iov;
+   void *kaddr = kmap(rqst->rq_pages[i]);
+   size_t len = rqst->rq_pagesz;
+
+   if (i == rqst->rq_npages - 1)
+   len = rqst->rq_tailsz;
+
+   crypto_shash_update(shash, kaddr, len);
 
-   cifs_rqst_page_to_kvec(rqst, i, &p_iov);
-   crypto_shash_update(&server->secmech.sdescmd5->shash,
-   p_iov.iov_base, p_iov.iov_len);
kunmap(rqst->rq_pages[i]);
}
 
-   rc = crypto_shash_final(&server->secmech.sdescmd5->shash, signature);
+   rc = crypto_shash_final(shash, signature);
if (rc)
-   cifs_dbg(VFS, "%s: Could not generate md5 hash\n", __func__);
+   cifs_dbg(VFS, "%s: Could not generate hash\n", __func__);
 
return rc;
 }
 
+/*
+ * Calculate and return the CIFS signature based on the mac key and SMB PDU.
+ * The 16 byte signature must be allocated by the caller. Note we only use the
+ * 1st eight bytes and that the smb header signature field on input contains
+ * the sequence number before this function is called. Also, this function
+ * should be called with the server->srv_mutex held.
+ */
+static int cifs_calc_signature(struct smb_rqst *rqst,
+   struct TCP_Server_Info *server, char *signature)
+{
+   int rc;
+
+   if (!rqst->rq_iov || !signature || !server)
+   return -EINVAL;
+
+   if (!server->secmech.sdescmd5) {
+   rc = cifs_crypto_shash_md5_allocate(server);
+   if (rc) {
+   cifs_dbg(VFS, "%s: Can't alloc md5 crypto\n", __func__);
+   return -1;
+   

[PATCH 1/6] [net] drop 'size' argument of sock_recvmsg()

[Al Viro]

all callers have it equal to msg_data_left(msg).

Signed-off-by: Al Viro 
---
 drivers/target/iscsi/iscsi_target_util.c |  5 ++---
 include/linux/net.h  |  3 +--
 net/socket.c | 23 ++-
 3 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target_util.c 
b/drivers/target/iscsi/iscsi_target_util.c
index 428b0d9..5772038 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -1283,9 +1283,8 @@ static int iscsit_do_rx_data(
iov_iter_kvec(&msg.msg_iter, READ | ITER_KVEC,
  count->iov, count->iov_count, data);
 
-   while (total_rx < data) {
-   rx_loop = sock_recvmsg(conn->sock, &msg,
- (data - total_rx), MSG_WAITALL);
+   while (msg_data_left(&msg)) {
+   rx_loop = sock_recvmsg(conn->sock, &msg, MSG_WAITALL);
if (rx_loop <= 0) {
pr_debug("rx_loop: %d total_rx: %d\n",
rx_loop, total_rx);
diff --git a/include/linux/net.h b/include/linux/net.h
index 49175e4..72c1e06 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -218,8 +218,7 @@ int sock_create_lite(int family, int type, int proto, 
struct socket **res);
 struct socket *sock_alloc(void);
 void sock_release(struct socket *sock);
 int sock_sendmsg(struct socket *sock, struct msghdr *msg);
-int sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
-int flags);
+int sock_recvmsg(struct socket *sock, struct msghdr *msg, int flags);
 struct file *sock_alloc_file(struct socket *sock, int flags, const char 
*dname);
 struct socket *sockfd_lookup(int fd, int *err);
 struct socket *sock_from_file(struct file *file, int *err);
diff --git a/net/socket.c b/net/socket.c
index 5f77a8e..956426e3 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -709,17 +709,16 @@ void __sock_recv_ts_and_drops(struct msghdr *msg, struct 
sock *sk,
 EXPORT_SYMBOL_GPL(__sock_recv_ts_and_drops);
 
 static inline int sock_recvmsg_nosec(struct socket *sock, struct msghdr *msg,
-size_t size, int flags)
+int flags)
 {
-   return sock->ops->recvmsg(sock, msg, size, flags);
+   return sock->ops->recvmsg(sock, msg, msg_data_left(msg), flags);
 }
 
-int sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
-int flags)
+int sock_recvmsg(struct socket *sock, struct msghdr *msg, int flags)
 {
-   int err = security_socket_recvmsg(sock, msg, size, flags);
+   int err = security_socket_recvmsg(sock, msg, msg_data_left(msg), flags);
 
-   return err ?: sock_recvmsg_nosec(sock, msg, size, flags);
+   return err ?: sock_recvmsg_nosec(sock, msg, flags);
 }
 EXPORT_SYMBOL(sock_recvmsg);
 
@@ -746,7 +745,7 @@ int kernel_recvmsg(struct socket *sock, struct msghdr *msg,
 
iov_iter_kvec(&msg->msg_iter, READ | ITER_KVEC, vec, num, size);
set_fs(KERNEL_DS);
-   result = sock_recvmsg(sock, msg, size, flags);
+   result = sock_recvmsg(sock, msg, flags);
set_fs(oldfs);
return result;
 }
@@ -796,7 +795,7 @@ static ssize_t sock_read_iter(struct kiocb *iocb, struct 
iov_iter *to)
if (!iov_iter_count(to))/* Match SYS5 behaviour */
return 0;
 
-   res = sock_recvmsg(sock, &msg, iov_iter_count(to), msg.msg_flags);
+   res = sock_recvmsg(sock, &msg, msg.msg_flags);
*to = msg.msg_iter;
return res;
 }
@@ -1696,7 +1695,7 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, 
size_t, size,
msg.msg_iocb = NULL;
if (sock->file->f_flags & O_NONBLOCK)
flags |= MSG_DONTWAIT;
-   err = sock_recvmsg(sock, &msg, iov_iter_count(&msg.msg_iter), flags);
+   err = sock_recvmsg(sock, &msg, flags);
 
if (err >= 0 && addr != NULL) {
err2 = move_addr_to_user(&address,
@@ -2073,7 +2072,7 @@ static int ___sys_recvmsg(struct socket *sock, struct 
user_msghdr __user *msg,
struct iovec iovstack[UIO_FASTIOV];
struct iovec *iov = iovstack;
unsigned long cmsg_ptr;
-   int total_len, len;
+   int len;
ssize_t err;
 
/* kernel mode address */
@@ -2091,7 +2090,6 @@ static int ___sys_recvmsg(struct socket *sock, struct 
user_msghdr __user *msg,
err = copy_msghdr_from_user(msg_sys, msg, &uaddr, &iov);
if (err < 0)
return err;
-   total_len = iov_iter_count(&msg_sys->msg_iter);
 
cmsg_ptr = (unsigned long)msg_sys->msg_control;
msg_sys->msg_flags = flags & (MSG_CMSG_CLOEXEC|MSG_CMSG_COMPAT);
@@ -2101,8 +2099,7 @@ static int ___sys_recvmsg(struct socket *sock, struct 
user_msghdr __user *msg,
 
if (sock->file->f_flags & O_NONBLOCK)
flags |= MSG_DONTWAIT;
-   err = (nosec ? sock_recvmsg_nosec

[PATCH 3/6] cifs: quit playing games with draining iovecs

[Al Viro]

... and use ITER_BVEC for the page part of request to send

Signed-off-by: Al Viro 
---
 fs/cifs/cifsproto.h |   2 -
 fs/cifs/transport.c | 141 +++-
 2 files changed, 41 insertions(+), 102 deletions(-)

diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index d9b4f44..7d5f53a 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -37,8 +37,6 @@ extern void cifs_buf_release(void *);
 extern struct smb_hdr *cifs_small_buf_get(void);
 extern void cifs_small_buf_release(void *);
 extern void free_rsp_buf(int, void *);
-extern void cifs_rqst_page_to_kvec(struct smb_rqst *rqst, unsigned int idx,
-   struct kvec *iov);
 extern int smb_send(struct TCP_Server_Info *, struct smb_hdr *,
unsigned int /* length */);
 extern unsigned int _get_xid(void);
diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
index 87abe8e..206a597 100644
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -124,41 +124,32 @@ cifs_delete_mid(struct mid_q_entry *mid)
 /*
  * smb_send_kvec - send an array of kvecs to the server
  * @server:Server to send the data to
- * @iov:   Pointer to array of kvecs
- * @n_vec: length of kvec array
+ * @smb_msg:   Message to send
  * @sent:  amount of data sent on socket is stored here
  *
  * Our basic "send data to server" function. Should be called with srv_mutex
  * held. The caller is responsible for handling the results.
  */
 static int
-smb_send_kvec(struct TCP_Server_Info *server, struct kvec *iov, size_t n_vec,
-   size_t *sent)
+smb_send_kvec(struct TCP_Server_Info *server, struct msghdr *smb_msg,
+ size_t *sent)
 {
int rc = 0;
-   int i = 0;
-   struct msghdr smb_msg;
-   unsigned int remaining;
-   size_t first_vec = 0;
+   int retries = 0;
struct socket *ssocket = server->ssocket;
 
*sent = 0;
 
-   smb_msg.msg_name = (struct sockaddr *) &server->dstaddr;
-   smb_msg.msg_namelen = sizeof(struct sockaddr);
-   smb_msg.msg_control = NULL;
-   smb_msg.msg_controllen = 0;
+   smb_msg->msg_name = (struct sockaddr *) &server->dstaddr;
+   smb_msg->msg_namelen = sizeof(struct sockaddr);
+   smb_msg->msg_control = NULL;
+   smb_msg->msg_controllen = 0;
if (server->noblocksnd)
-   smb_msg.msg_flags = MSG_DONTWAIT + MSG_NOSIGNAL;
+   smb_msg->msg_flags = MSG_DONTWAIT + MSG_NOSIGNAL;
else
-   smb_msg.msg_flags = MSG_NOSIGNAL;
-
-   remaining = 0;
-   for (i = 0; i < n_vec; i++)
-   remaining += iov[i].iov_len;
+   smb_msg->msg_flags = MSG_NOSIGNAL;
 
-   i = 0;
-   while (remaining) {
+   while (msg_data_left(smb_msg)) {
/*
 * If blocking send, we try 3 times, since each can block
 * for 5 seconds. For nonblocking  we have to try more
@@ -177,35 +168,21 @@ smb_send_kvec(struct TCP_Server_Info *server, struct kvec 
*iov, size_t n_vec,
 * after the retries we will kill the socket and
 * reconnect which may clear the network problem.
 */
-   rc = kernel_sendmsg(ssocket, &smb_msg, &iov[first_vec],
-   n_vec - first_vec, remaining);
+   rc = sock_sendmsg(ssocket, smb_msg);
if (rc == -EAGAIN) {
-   i++;
-   if (i >= 14 || (!server->noblocksnd && (i > 2))) {
+   retries++;
+   if (retries >= 14 ||
+   (!server->noblocksnd && (retries > 2))) {
cifs_dbg(VFS, "sends on sock %p stuck for 15 
seconds\n",
 ssocket);
-   rc = -EAGAIN;
-   break;
+   return -EAGAIN;
}
-   msleep(1 << i);
+   msleep(1 << retries);
continue;
}
 
if (rc < 0)
-   break;
-
-   /* send was at least partially successful */
-   *sent += rc;
-
-   if (rc == remaining) {
-   remaining = 0;
-   break;
-   }
-
-   if (rc > remaining) {
-   cifs_dbg(VFS, "sent %d requested %d\n", rc, remaining);
-   break;
-   }
+   return rc;
 
if (rc == 0) {
/* should never happen, letting socket clear before
@@ -215,59 +192,11 @@ smb_send_kvec(struct TCP_Server_Info *server, struct kvec 
*iov, size_t n_vec,
continue;
}
 
-   remaining -= rc;
-
-   /* the line below resets i */
-   for (i = fi

[PATCH 4/6] cifs: no need to wank with copying and advancing iovec on recvmsg side either

[Al Viro]

Signed-off-by: Al Viro 
---
 fs/cifs/cifsglob.h |  2 --
 fs/cifs/connect.c  | 72 --
 2 files changed, 5 insertions(+), 69 deletions(-)

diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index d21da9f..df03c5e 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -615,8 +615,6 @@ struct TCP_Server_Info {
boolsec_mskerberos; /* supports legacy MS Kerberos */
boollarge_buf;  /* is current buffer large? */
struct delayed_work echo; /* echo ping workqueue job */
-   struct kvec *iov;   /* reusable kvec array for receives */
-   unsigned int nr_iov;/* number of kvecs in array */
char*smallbuf;  /* pointer to current "small" buffer */
char*bigbuf;/* pointer to current "big" buffer */
unsigned int total_read; /* total amount of data read in this pass */
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index a763cd3..eb42665 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -501,77 +501,20 @@ server_unresponsive(struct TCP_Server_Info *server)
return false;
 }
 
-/*
- * kvec_array_init - clone a kvec array, and advance into it
- * @new:   pointer to memory for cloned array
- * @iov:   pointer to original array
- * @nr_segs:   number of members in original array
- * @bytes: number of bytes to advance into the cloned array
- *
- * This function will copy the array provided in iov to a section of memory
- * and advance the specified number of bytes into the new array. It returns
- * the number of segments in the new array. "new" must be at least as big as
- * the original iov array.
- */
-static unsigned int
-kvec_array_init(struct kvec *new, struct kvec *iov, unsigned int nr_segs,
-   size_t bytes)
-{
-   size_t base = 0;
-
-   while (bytes || !iov->iov_len) {
-   int copy = min(bytes, iov->iov_len);
-
-   bytes -= copy;
-   base += copy;
-   if (iov->iov_len == base) {
-   iov++;
-   nr_segs--;
-   base = 0;
-   }
-   }
-   memcpy(new, iov, sizeof(*iov) * nr_segs);
-   new->iov_base += base;
-   new->iov_len -= base;
-   return nr_segs;
-}
-
-static struct kvec *
-get_server_iovec(struct TCP_Server_Info *server, unsigned int nr_segs)
-{
-   struct kvec *new_iov;
-
-   if (server->iov && nr_segs <= server->nr_iov)
-   return server->iov;
-
-   /* not big enough -- allocate a new one and release the old */
-   new_iov = kmalloc(sizeof(*new_iov) * nr_segs, GFP_NOFS);
-   if (new_iov) {
-   kfree(server->iov);
-   server->iov = new_iov;
-   server->nr_iov = nr_segs;
-   }
-   return new_iov;
-}
-
 int
 cifs_readv_from_socket(struct TCP_Server_Info *server, struct kvec *iov_orig,
   unsigned int nr_segs, unsigned int to_read)
 {
int length = 0;
int total_read;
-   unsigned int segs;
struct msghdr smb_msg;
-   struct kvec *iov;
-
-   iov = get_server_iovec(server, nr_segs);
-   if (!iov)
-   return -ENOMEM;
 
smb_msg.msg_control = NULL;
smb_msg.msg_controllen = 0;
+   iov_iter_kvec(&smb_msg.msg_iter, READ | ITER_KVEC,
+ iov_orig, nr_segs, to_read);
 
-   for (total_read = 0; to_read; total_read += length, to_read -= length) {
+   for (total_read = 0; msg_data_left(&smb_msg); total_read += length) {
try_to_freeze();
 
if (server_unresponsive(server)) {
@@ -579,10 +522,7 @@ cifs_readv_from_socket(struct TCP_Server_Info *server, 
struct kvec *iov_orig,
break;
}
 
-   segs = kvec_array_init(iov, iov_orig, nr_segs, total_read);
-
-   length = kernel_recvmsg(server->ssocket, &smb_msg,
-   iov, segs, to_read, 0);
+   length = sock_recvmsg(server->ssocket, &smb_msg, 0);
 
if (server->tcpStatus == CifsExiting) {
total_read = -ESHUTDOWN;
@@ -603,8 +543,7 @@ cifs_readv_from_socket(struct TCP_Server_Info *server, 
struct kvec *iov_orig,
length = 0;
continue;
} else if (length <= 0) {
-   cifs_dbg(FYI, "Received no data or error: expecting 
%d\n"
-"got %d", to_read, length);
+   cifs_dbg(FYI, "Received no data or error: %d\n", 
length);
cifs_reconnect(server);
total_read = -ECONNABORTED;
break;
@@ -783,7 +722,6 @@ static void clean_demultiplex_info(struct TCP_Server_Info 
*server)
}
 
kfree(server->hostname);
-   kfree(server->iov);
kfree(server);
 
length = atom

[PATCH 5/6] cifs_readv_receive: use cifs_read_from_socket()

[Al Viro]

Signed-off-by: Al Viro 
---
 fs/cifs/cifssmb.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 76fcb50..3da077a 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -1447,10 +1447,8 @@ cifs_readv_receive(struct TCP_Server_Info *server, 
struct mid_q_entry *mid)
len = min_t(unsigned int, buflen, server->vals->read_rsp_size) -
HEADER_SIZE(server) + 1;
 
-   rdata->iov.iov_base = buf + HEADER_SIZE(server) - 1;
-   rdata->iov.iov_len = len;
-
-   length = cifs_readv_from_socket(server, &rdata->iov, 1, len);
+   length = cifs_read_from_socket(server,
+  buf + HEADER_SIZE(server) - 1, len);
if (length < 0)
return length;
server->total_read += length;
@@ -1502,9 +1500,8 @@ cifs_readv_receive(struct TCP_Server_Info *server, struct 
mid_q_entry *mid)
len = data_offset - server->total_read;
if (len > 0) {
/* read any junk before data into the rest of smallbuf */
-   rdata->iov.iov_base = buf + server->total_read;
-   rdata->iov.iov_len = len;
-   length = cifs_readv_from_socket(server, &rdata->iov, 1, len);
+   length = cifs_read_from_socket(server,
+  buf + server->total_read, len);
if (length < 0)
return length;
server->total_read += length;
-- 
2.8.0.rc3

[PATCH 6/6] cifs: don't bother with kmap on read_pages side

[Al Viro]

just do ITER_BVEC recvmsg

Signed-off-by: Al Viro 
---
 fs/cifs/cifsproto.h |  7 +++---
 fs/cifs/connect.c   | 65 -
 fs/cifs/file.c  | 53 ++-
 3 files changed, 55 insertions(+), 70 deletions(-)

diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index 7d5f53a..0f9a6bc 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -179,10 +179,9 @@ extern int set_cifs_acl(struct cifs_ntsd *, __u32, struct 
inode *,
 
 extern void dequeue_mid(struct mid_q_entry *mid, bool malformed);
 extern int cifs_read_from_socket(struct TCP_Server_Info *server, char *buf,
-unsigned int to_read);
-extern int cifs_readv_from_socket(struct TCP_Server_Info *server,
-   struct kvec *iov_orig, unsigned int nr_segs,
-   unsigned int to_read);
+unsigned int to_read);
+extern int cifs_read_page_from_socket(struct TCP_Server_Info *server,
+ struct page *page, unsigned int to_read);
 extern void cifs_setup_cifs_sb(struct smb_vol *pvolume_info,
   struct cifs_sb_info *cifs_sb);
 extern int cifs_match_super(struct super_block *, void *);
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index eb42665..e33c5e0 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -501,39 +501,34 @@ server_unresponsive(struct TCP_Server_Info *server)
return false;
 }
 
-int
-cifs_readv_from_socket(struct TCP_Server_Info *server, struct kvec *iov_orig,
-  unsigned int nr_segs, unsigned int to_read)
+static int
+cifs_readv_from_socket(struct TCP_Server_Info *server, struct msghdr *smb_msg)
 {
int length = 0;
int total_read;
-   struct msghdr smb_msg;
 
-   smb_msg.msg_control = NULL;
-   smb_msg.msg_controllen = 0;
-   iov_iter_kvec(&smb_msg.msg_iter, READ | ITER_KVEC,
- iov_orig, nr_segs, to_read);
+   smb_msg->msg_control = NULL;
+   smb_msg->msg_controllen = 0;
 
-   for (total_read = 0; msg_data_left(&smb_msg); total_read += length) {
+   for (total_read = 0; msg_data_left(smb_msg); total_read += length) {
try_to_freeze();
 
-   if (server_unresponsive(server)) {
-   total_read = -ECONNABORTED;
-   break;
-   }
+   if (server_unresponsive(server))
+   return -ECONNABORTED;
 
-   length = sock_recvmsg(server->ssocket, &smb_msg, 0);
+   length = sock_recvmsg(server->ssocket, smb_msg, 0);
 
-   if (server->tcpStatus == CifsExiting) {
-   total_read = -ESHUTDOWN;
-   break;
-   } else if (server->tcpStatus == CifsNeedReconnect) {
+   if (server->tcpStatus == CifsExiting)
+   return -ESHUTDOWN;
+
+   if (server->tcpStatus == CifsNeedReconnect) {
cifs_reconnect(server);
-   total_read = -ECONNABORTED;
-   break;
-   } else if (length == -ERESTARTSYS ||
-  length == -EAGAIN ||
-  length == -EINTR) {
+   return -ECONNABORTED;
+   }
+
+   if (length == -ERESTARTSYS ||
+   length == -EAGAIN ||
+   length == -EINTR) {
/*
 * Minimum sleep to prevent looping, allowing socket
 * to clear and app threads to set tcpStatus
@@ -542,11 +537,12 @@ cifs_readv_from_socket(struct TCP_Server_Info *server, 
struct kvec *iov_orig,
usleep_range(1000, 2000);
length = 0;
continue;
-   } else if (length <= 0) {
+   }
+
+   if (length <= 0) {
cifs_dbg(FYI, "Received no data or error: %d\n", 
length);
cifs_reconnect(server);
-   total_read = -ECONNABORTED;
-   break;
+   return -ECONNABORTED;
}
}
return total_read;
@@ -556,12 +552,21 @@ int
 cifs_read_from_socket(struct TCP_Server_Info *server, char *buf,
  unsigned int to_read)
 {
-   struct kvec iov;
+   struct msghdr smb_msg;
+   struct kvec iov = {.iov_base = buf, .iov_len = to_read};
+   iov_iter_kvec(&smb_msg.msg_iter, READ | ITER_KVEC, &iov, 1, to_read);
 
-   iov.iov_base = buf;
-   iov.iov_len = to_read;
+   return cifs_readv_from_socket(server, &smb_msg);
+}
 
-   return cifs_readv_from_socket(server, &iov, 1, to_read);
+int
+cifs_read_page_from_socket(struct TCP_Server_Info *server, struct page *page,
+ unsigned int to_read)
+{
+   struct msghdr smb_msg;
+   s

[PATCH v2 2/2] lib: lz4: cleanup unaligned access efficiency detection

[Rui Salvaterra]

These identifiers are bogus. The interested architectures should define
HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this
isn't true for some arch, it should be fixed in the arch definition.

Signed-off-by: Rui Salvaterra 
---
 lib/lz4/lz4defs.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/lib/lz4/lz4defs.h b/lib/lz4/lz4defs.h
index 0710a62..c79d7ea 100644
--- a/lib/lz4/lz4defs.h
+++ b/lib/lz4/lz4defs.h
@@ -24,9 +24,7 @@
 typedef struct _U16_S { u16 v; } U16_S;
 typedef struct _U32_S { u32 v; } U32_S;
 typedef struct _U64_S { u64 v; } U64_S;
-#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)\
-   || defined(CONFIG_ARM) && __LINUX_ARM_ARCH__ >= 6   \
-   && defined(ARM_EFFICIENT_UNALIGNED_ACCESS)
+#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
 
 #define A16(x) (((U16_S *)(x))->v)
 #define A32(x) (((U32_S *)(x))->v)
-- 
2.7.4

[PATCH v2 0/2] lib: lz4: fix for big endian and cleanup

[Rui Salvaterra]

v2:
 - Addressed GregKH's review and comments.


Hi,

The first patch fixes zram with lz4 compression on ppc64 (and big endian
architectures with efficient unaligned access), the second is just a
cleanup.

Thanks,

Rui


Rui Salvaterra (2):
  lib: lz4: fixed zram with lz4 on big endian machines
  lib: lz4: cleanup unaligned access efficiency detection

 lib/lz4/lz4defs.h | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

-- 
2.7.4

[PATCH v2 1/2] lib: lz4: fixed zram with lz4 on big endian machines

[Rui Salvaterra]

Based on Sergey's test patch [1], this fixes zram with lz4 compression
on big endian cpus.

Note that the 64-bit preprocessor test is not a cleanup, it's part of
the fix, since those identifiers are bogus (for example, __ppc64__
isn't defined anywhere else in the kernel, which means we'd fall into
the 32-bit definitions on ppc64).

Tested on ppc64 with no regression on x86_64.

[1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4

Cc: sta...@vger.kernel.org
Suggested-by: Sergey Senozhatsky 
Signed-off-by: Rui Salvaterra 
---
 lib/lz4/lz4defs.h | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/lib/lz4/lz4defs.h b/lib/lz4/lz4defs.h
index abcecdc..0710a62 100644
--- a/lib/lz4/lz4defs.h
+++ b/lib/lz4/lz4defs.h
@@ -11,8 +11,7 @@
 /*
  * Detects 64 bits mode
  */
-#if (defined(__x86_64__) || defined(__x86_64) || defined(__amd64__) \
-   || defined(__ppc64__) || defined(__LP64__))
+#if defined(CONFIG_64BIT)
 #define LZ4_ARCH64 1
 #else
 #define LZ4_ARCH64 0
@@ -35,6 +34,10 @@ typedef struct _U64_S { u64 v; } U64_S;
 
 #define PUT4(s, d) (A32(d) = A32(s))
 #define PUT8(s, d) (A64(d) = A64(s))
+
+#define LZ4_READ_LITTLEENDIAN_16(d, s, p)  \
+   (d = s - A16(p))
+
 #define LZ4_WRITE_LITTLEENDIAN_16(p, v)\
do {\
A16(p) = v; \
@@ -51,10 +54,13 @@ typedef struct _U64_S { u64 v; } U64_S;
 #define PUT8(s, d) \
put_unaligned(get_unaligned((const u64 *) s), (u64 *) d)
 
-#define LZ4_WRITE_LITTLEENDIAN_16(p, v)\
-   do {\
-   put_unaligned(v, (u16 *)(p)); \
-   p += 2; \
+#define LZ4_READ_LITTLEENDIAN_16(d, s, p)  \
+   (d = s - get_unaligned_le16(p))
+
+#define LZ4_WRITE_LITTLEENDIAN_16(p, v)\
+   do {\
+   put_unaligned_le16(v, (u16 *)(p));  \
+   p += 2; \
} while (0)
 #endif
 
@@ -140,9 +146,6 @@ typedef struct _U64_S { u64 v; } U64_S;
 
 #endif
 
-#define LZ4_READ_LITTLEENDIAN_16(d, s, p) \
-   (d = s - get_unaligned_le16(p))
-
 #define LZ4_WILDCOPY(s, d, e)  \
do {\
LZ4_COPYPACKET(s, d);   \
-- 
2.7.4

Re: [RFC 0/4] NFC: pn533: support for pn532 via I2C

[Samuel Ortiz]

Hi Michael,

On Fri, Mar 25, 2016 at 03:46:50PM +0100, Michael Thalmeier wrote:
> Michael Thalmeier (4):
>   NFC: pn533: Send ATR_REQ only if NFC_PROTO_NFC_DEP bit is set in
> poll_protocols
>   NFC: pn533: fix deadlock when socket is closed while processing
> command
>   NFC: pn533: Separate pn533 driver in HW dependant and independant
> parts
>   NFC: pn533: add I2C phy driver
This looks very clean, thanks a lot.
I applied and pushed all 4 patches, after cleaning the checkpatch
warnings. I'd like you to address one comment on patch #4 as a
follow up patch.

Cheers,
Samuel.

Re: [RFC 4/4] NFC: pn533: add I2C phy driver

[Samuel Ortiz]

Hi Michael,

On Fri, Mar 25, 2016 at 03:46:54PM +0100, Michael Thalmeier wrote:
> This adds the I2C phy interface for the pn533 driver. This way the driver can
> be used to interact with I2C connected pn532.
> 
> Signed-off-by: Michael Thalmeier 
> ---
>  drivers/nfc/pn533/Kconfig  |  11 ++
>  drivers/nfc/pn533/Makefile |   2 +
>  drivers/nfc/pn533/i2c.c| 277 
> +
>  drivers/nfc/pn533/pn533.c  |  29 +
>  drivers/nfc/pn533/pn533.h  |   2 +
>  5 files changed, 321 insertions(+)
>  create mode 100644 drivers/nfc/pn533/i2c.c
> 
> diff --git a/drivers/nfc/pn533/Kconfig b/drivers/nfc/pn533/Kconfig
> index b5a926e..d94122d 100644
> --- a/drivers/nfc/pn533/Kconfig
> +++ b/drivers/nfc/pn533/Kconfig
> @@ -14,3 +14,14 @@ config NFC_PN533_USB
>  
> If you choose to build a module, it'll be called pn533_usb.
> Say N if unsure.
> +
> +config NFC_PN533_I2C
> + tristate "NFC PN533 device support (I2C)"
> + depends on I2C
> + select NFC_PN533
> + ---help---
> +   This module adds support for the NXP pn533 I2C interface.
> +   Select this if your platform is using the I2C bus.
> +
> +   If you choose to build a module, it'll be called pn533_i2c.
> +   Say N if unsure.
> diff --git a/drivers/nfc/pn533/Makefile b/drivers/nfc/pn533/Makefile
> index 12c6be4..51d24c6 100644
> --- a/drivers/nfc/pn533/Makefile
> +++ b/drivers/nfc/pn533/Makefile
> @@ -2,6 +2,8 @@
>  # Makefile for PN533 NFC driver
>  #
>  pn533_usb-objs  = usb.o
> +pn533_i2c-objs  = i2c.o
>  
>  obj-$(CONFIG_NFC_PN533) += pn533.o
>  obj-$(CONFIG_NFC_PN533_USB) += pn533_usb.o
> +obj-$(CONFIG_NFC_PN533_I2C) += pn533_i2c.o
> diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> new file mode 100644
> index 000..35066b30
> --- /dev/null
> +++ b/drivers/nfc/pn533/i2c.c
> @@ -0,0 +1,277 @@
> +/*
> + * Driver for NXP PN533 NFC Chip - I2C transport layer
> + *
> + * Copyright (C) 2011 Instituto Nokia de Tecnologia
> + * Copyright (C) 2012-2013 Tieto Poland
> + * Copyright (C) 2016 HALE electronic
> + *
> + *
> + * 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, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "pn533.h"
> +
> +#define VERSION "0.1"
> +
> +#define PN533_I2C_DRIVER_NAME "pn533_i2c"
> +
> +struct pn533_i2c_phy {
> + struct i2c_client *i2c_dev;
> + struct pn533 *priv;
> +
> + int hard_fault; /*
> +  * < 0 if hardware error occured (e.g. i2c err)
> +  * and prevents normal operation.
> +  */
> +};
> +
> +static int pn533_i2c_send_ack(struct pn533 *dev, gfp_t flags)
> +{
> + struct pn533_i2c_phy *phy = dev->phy;
> + struct i2c_client *client = phy->i2c_dev;
> + u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
> + /* spec 6.2.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
> + int rc;
> +
> + rc = i2c_master_send(client, ack, 6);
> +
> + return rc;
> +}
> +
> +static int pn533_i2c_send_frame(struct pn533 *dev,
> + struct sk_buff *out)
> +{
> + struct pn533_i2c_phy *phy = dev->phy;
> + struct i2c_client *client = phy->i2c_dev;
> + int rc;
> +
> + if (phy->hard_fault != 0)
> + return phy->hard_fault;
> +
> + if (phy->priv == NULL)
> + phy->priv = dev;
> +
> + print_hex_dump_debug("PN533_i2c TX: ", DUMP_PREFIX_NONE, 16, 1,
> +  out->data, out->len, false);
> +
> + rc = i2c_master_send(client, out->data, out->len);
> +
> + if (rc == -EREMOTEIO) { /* Retry, chip was in power down */
> + usleep_range(6000, 1);
> + rc = i2c_master_send(client, out->data, out->len);
> + }
> +
> + if (rc >= 0) {
> + if (rc != out->len)
> + rc = -EREMOTEIO;
> + else
> + rc = 0;
> + }
> +
> + return rc;
> +}
> +
> +static void pn533_i2c_abort_cmd(struct pn533 *dev, gfp_t flags)
> +{
> + /* An ack will cancel the last issued command */
> + pn533_i2c_send_ack(dev, flags);
> +
> + /* schedule cmd_complete_work to finish current command execution */
> + if (dev->cmd != NULL)
> + dev->cmd->status = -EN

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

[H. Peter Anvin]

On April 9, 2016 7:45:46 AM PDT, ebied...@xmission.com wrote:
>"H. Peter Anvin"  writes:
>
>> On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes
> wrote:
>>>
 If anyone has a better idea on how userspace should connect the
>>>master
 pty file descriptor the slave file descriptor, I would be willing
>to
 implement that instead.
>>>
>>>If we are willing to go away from the existing mess of a tty
>interface
>>>inflicted on us by BSD and then mashed up by POSIX then a syscall of
>>>
>>>  int err = ptypair(int fd[2], int perms, int flags);
>>>
>>>[where flags is the O_ ones we usually need to cover (CLOEXEC etc)
>and
>>>maybe even some kind of "private" flag to say don't even expose it
>via
>>>devpts).
>>>
>>>would do remarkably sane things to the majoirty of use cases as it
>>>breaks
>>>the dependence on grantpt and also the historic screwup that pty
>pairs
>>>aren't allocated atomically with both file handles returned as pipe()
>>>does.
>>>
>>>Alan
>>
>> We don't even need to do that if we'd be willing to change the user
>> space interface... if we could rely on the POSIX interface then
>> posix_openpt() could simply open /dev/pts/ptmx and everything would
>> just work.
>
>At a quick skim it does look like userspace uses posix_openpt for the
>most part.  Certainly portable apps that can run on FreeBSD do.
>And just grepping through binaries all of the ones I have checked so
>far
>are calling posix_openpt.
>
>Peter if you or someone could start updating the userspace version of
>posix_openpt to use /dev/pts/ptmx when available over /dev/ptmx in
>parallel to the kernel work to always allow mount of devpts to give
>distinct instances that would be great.
>
>> The trick here is how to make it work in the presence of some
>> extremely bad practices in existing userspace.
>
>Yeah.  I am going to look and see if I can move this controversial bit
>to a separate patch so we can discuss it more conviniently.
>
>Eric

On the flipside, if we were to allow ourselves to break userspace, at this 
point I would suggest making /dev/pts/ptmx have a different device number and 
make the legacy /dev/ptmx print a warning message, after which it can at least 
eventually be deleted.

This might not be a bad idea anyway.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [PATCH] x86/vdso: Remove direct HPET access through the vDSO

[Thomas Gleixner]

On Thu, 7 Apr 2016, Andy Lutomirski wrote:

> Allowing user code to map the HPET is problematic.  HPET
> implementations are notoriously buggy, and there are probably many
> machines on which even MMIO reads from bogus HPET addresses are
> problematic.
> 
> We have a report that the Dell Precision M2800 with:
> 
> ACPI: HPET 0xC8FE6238 38 (v01 DELL   CBX3  01072009 AMI. 0005)
> 
> is either so slow when accessing the HPET or actually hangs in some
> regard, causing soft lockups to be reported if users do unexpected
> things to the HPET.
> 
> The vclock HPET code has also always been a questionable speedup.
> Accessing an HPET is exceedingly slow (on the order of several
> microseconds), so the added overhead in requiring a syscall to read
> the HPET is a small fraction of the total code of accessing it.
> 
> To avoid future problems, let's just delete the code entirely.
> 
> In the long run, this could actually be a speedup.  Waiman Long as a
> patch to optimize the case where multiple CPUs contend for the HPET,
> but that won't help unless all the accesses are mediated by the
> kernel.
> 
> Cc: Waiman Long 
> Reported-by: Rasmus Villemoes 
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Thomas Gleixner