Re: [PATCH v4 6/7] Input: pixcir_i2c_ts: Implement wakeup from suspend

[Dmitry Torokhov]

On Mon, May 05, 2014 at 12:04:37PM +0300, Roger Quadros wrote:
> Improve the suspend and resume handlers to allow the device
> to wakeup the system from suspend.
> 
> Signed-off-by: Roger Quadros 
> Acked-by: Mugunthan V N 
> ---
>  drivers/input/touchscreen/pixcir_i2c_ts.c | 53 
> ---
>  1 file changed, 49 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c 
> b/drivers/input/touchscreen/pixcir_i2c_ts.c
> index 927aed1..5f6a27e 100644
> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
> @@ -348,21 +348,66 @@ static void pixcir_input_close(struct input_dev *dev)
>  static int pixcir_i2c_ts_suspend(struct device *dev)
>  {
>   struct i2c_client *client = to_i2c_client(dev);
> + struct pixcir_i2c_ts_data *ts = i2c_get_clientdata(client);
> + struct input_dev *input = ts->input;
> + int ret = 0;
> +
> + mutex_lock(>mutex);
> +
> + if (input->users) {
> + ret = pixcir_stop(ts);
> + if (ret)
> + goto unlock;
> + }
> +
> + /*
> +  * If wakeup is enabled we need to enable interrupt generation
> +  * but don't need to process any reports i.e. ts->exiting must be true.
> +  */
> + if (device_may_wakeup(>dev)) {
> + /* enable wakeup interrupt generation */
> + ret = pixcir_int_enable(ts, 1);
> + if (ret) {
> + dev_err(dev, "Failed to enable interrupt generation\n");
> + goto unlock;
> + }

I am not sure why we need to disable event processing here. Why not do

if (device_may_wakeup(>dev)) {
enable_irq_wake(client->irq); 
ret = pixcir_int_enable(ts, true);
...
} else if (input->users) {
ret = pixcir_stop(ts);
}

like many of the drivers do?

Thanks.

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

Re: [PATCH v4 2/7] Input: pixcir_i2c_ts: Initialize interrupt mode and power mode

[Dmitry Torokhov]

Hi Roger,

On Mon, May 05, 2014 at 12:04:33PM +0300, Roger Quadros wrote:
> @@ -192,8 +364,8 @@ static int pixcir_i2c_ts_remove(struct i2c_client *client)
>  
>   device_init_wakeup(>dev, 0);
>  
> - tsdata->exiting = true;
> - mb();
> + if (!tsdata->exiting)
> + pixcir_stop(tsdata);
>  

I think if we change tsdata->exiting to tsdata->running we won't have to
do it here. Does the version of the patch below work for you?

-- 
Dmitry

Input: pixcir_i2c_ts - initialize interrupt mode and power mode

From: Roger Quadros 

Introduce helper functions to configure power and interrupt registers.
Default to IDLE mode on probe as device supports auto wakeup to ACVIE mode
on detecting finger touch.

Configure interrupt mode and polarity on start up.  Power down on device
closure or module removal.

Signed-off-by: Roger Quadros 
Acked-by: Mugunthan V N 
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/pixcir_i2c_ts.c |  182 -
 include/linux/input/pixcir_ts.h   |   42 +++
 2 files changed, 216 insertions(+), 8 deletions(-)

diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c 
b/drivers/input/touchscreen/pixcir_i2c_ts.c
index 724b839..7d39268 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -29,7 +29,7 @@ struct pixcir_i2c_ts_data {
struct i2c_client *client;
struct input_dev *input;
const struct pixcir_ts_platform_data *chip;
-   bool exiting;
+   bool running;
 };
 
 static void pixcir_ts_poscheck(struct pixcir_i2c_ts_data *data)
@@ -88,7 +88,7 @@ static irqreturn_t pixcir_ts_isr(int irq, void *dev_id)
 {
struct pixcir_i2c_ts_data *tsdata = dev_id;
 
-   while (!tsdata->exiting) {
+   while (tsdata->running) {
pixcir_ts_poscheck(tsdata);
 
if (tsdata->chip->attb_read_val())
@@ -100,6 +100,164 @@ static irqreturn_t pixcir_ts_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+static int pixcir_set_power_mode(struct pixcir_i2c_ts_data *ts,
+enum pixcir_power_mode mode)
+{
+   struct device *dev = >client->dev;
+   int ret;
+
+   ret = i2c_smbus_read_byte_data(ts->client, PIXCIR_REG_POWER_MODE);
+   if (ret < 0) {
+   dev_err(dev, "%s: can't read reg 0x%x : %d\n",
+   __func__, PIXCIR_REG_POWER_MODE, ret);
+   return ret;
+   }
+
+   ret &= ~PIXCIR_POWER_MODE_MASK;
+   ret |= mode;
+
+   /* Always AUTO_IDLE */
+   ret |= PIXCIR_POWER_ALLOW_IDLE;
+
+   ret = i2c_smbus_write_byte_data(ts->client, PIXCIR_REG_POWER_MODE, ret);
+   if (ret < 0) {
+   dev_err(dev, "%s: can't write reg 0x%x : %d\n",
+   __func__, PIXCIR_REG_POWER_MODE, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+/*
+ * Set the interrupt mode for the device i.e. ATTB line behaviour
+ *
+ * @polarity : 1 for active high, 0 for active low.
+ */
+static int pixcir_set_int_mode(struct pixcir_i2c_ts_data *ts,
+  enum pixcir_int_mode mode, bool polarity)
+{
+   struct device *dev = >client->dev;
+   int ret;
+
+   ret = i2c_smbus_read_byte_data(ts->client, PIXCIR_REG_INT_MODE);
+   if (ret < 0) {
+   dev_err(dev, "%s: can't read reg 0x%x : %d\n",
+   __func__, PIXCIR_REG_INT_MODE, ret);
+   return ret;
+   }
+
+   ret &= ~PIXCIR_INT_MODE_MASK;
+   ret |= mode;
+
+   if (polarity)
+   ret |= PIXCIR_INT_POL_HIGH;
+   else
+   ret &= ~PIXCIR_INT_POL_HIGH;
+
+   ret = i2c_smbus_write_byte_data(ts->client, PIXCIR_REG_INT_MODE, ret);
+   if (ret < 0) {
+   dev_err(dev, "%s: can't write reg 0x%x : %d\n",
+   __func__, PIXCIR_REG_INT_MODE, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+/*
+ * Enable/disable interrupt generation
+ */
+static int pixcir_int_enable(struct pixcir_i2c_ts_data *ts, bool enable)
+{
+   struct device *dev = >client->dev;
+   int ret;
+
+   ret = i2c_smbus_read_byte_data(ts->client, PIXCIR_REG_INT_MODE);
+   if (ret < 0) {
+   dev_err(dev, "%s: can't read reg 0x%x : %d\n",
+   __func__, PIXCIR_REG_INT_MODE, ret);
+   return ret;
+   }
+
+   if (enable)
+   ret |= PIXCIR_INT_ENABLE;
+   else
+   ret &= ~PIXCIR_INT_ENABLE;
+
+   ret = i2c_smbus_write_byte_data(ts->client, PIXCIR_REG_INT_MODE, ret);
+   if (ret < 0) {
+   dev_err(dev, "%s: can't write reg 0x%x : %d\n",
+   __func__, PIXCIR_REG_INT_MODE, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int pixcir_start(struct pixcir_i2c_ts_data *ts)
+{
+   struct device *dev = >client->dev;
+   int error;
+
+   /* LEVEL_TOUCH interrupt 

Re: [RESEND PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq

[Anton Vorontsov]

On Mon, May 05, 2014 at 09:51:28AM -0700, Olof Johansson wrote:
> > All the rest of this series has been acked and applied.  Do you have
> > time to review this patch?
> >
> > Thanks!  :)
> 
> FWIW, I've seen very little email traffic from Anton this year, he
> might have limited time for maintainership at the moment.

Yup.

commit 573189354b7c97cd2256b87cf083ee435584594e
Author: Dmitry Eremin-Solenikov 
Date:   Tue Jan 21 03:33:09 2014 +0400

MAINTAINERS: Pick up power supply maintainership

Anton stated that he would have to abandon power supply maintainership
due to the lack of time. By agreement with him and David, pick up power
supply tree.

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

[PATCH v5 2/3] pstore: add seq_ops for norm zone

[Liu ShuoX]

Some developers want to output the pstore record trace flexible.
So add seq_ops into ramoops_zone in case users would make private output
format.

Signed-off-by: Zhang Yanmin 
Signed-off-by: Liu ShuoX 
---
 fs/pstore/inode.c  | 10 --
 include/linux/pstore_ramoops.h |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index d463481..a9c9782 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -207,14 +207,20 @@ static ssize_t pstore_file_read(struct file *file, char 
__user *userbuf,
 static int pstore_file_open(struct inode *inode, struct file *file)
 {
struct pstore_private *ps = inode->i_private;
+   struct ramoops_context *cxt = ps->psi->data;
+   struct ramoops_zone*zones = cxt ? cxt->zones : NULL;
struct seq_file *sf;
int err;
const struct seq_operations *sops = NULL;
 
if (ps->type == PSTORE_TYPE_FTRACE)
sops = _ftrace_seq_ops;
-   if (ps->type == PSTORE_TYPE_NORM)
-   sops = _seq_ops;
+   if (ps->type == PSTORE_TYPE_NORM && zones) {
+   if (zones[ps->id].seq_ops)
+   sops = zones[ps->id].seq_ops;
+   else
+   sops = _seq_ops;
+   }
 
err = seq_open(file, sops);
if (err < 0)
diff --git a/include/linux/pstore_ramoops.h b/include/linux/pstore_ramoops.h
index 28f47a9..b8da964 100644
--- a/include/linux/pstore_ramoops.h
+++ b/include/linux/pstore_ramoops.h
@@ -33,6 +33,7 @@ struct ramoops_zone {
int item_size;
void (*print_record)(struct seq_file *s, void *record);
void *(*get_new_record)(struct persistent_ram_zone *prz);
+   const struct seq_operations *seq_ops;
 };
 
 /*
-- 
1.8.3.2

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

[PATCH v5 3/3] pstore: support current records dump in ramoops

[Liu ShuoX]

dump the records in runtime is useful sometime. We could check the
records and understand driver's and device's status.

Signed-off-by: Zhang Yanmin 
Signed-off-by: Liu ShuoX 
---
 fs/pstore/inode.c  | 39 +++
 fs/pstore/internal.h   |  3 ++-
 fs/pstore/platform.c   | 39 ++-
 fs/pstore/ram.c| 18 ++
 fs/pstore/ram_core.c   | 10 ++
 include/linux/pstore.h |  2 ++
 include/linux/pstore_ram.h |  2 ++
 7 files changed, 95 insertions(+), 18 deletions(-)

diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index a9c9782..a3b817c15df 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -48,10 +48,11 @@ struct pstore_private {
struct list_head list;
struct pstore_info *psi;
enum pstore_type_id type;
+   int curr;
u64 id;
int count;
ssize_t size;
-   chardata[];
+   char*data;
 };
 
 struct pstore_seq_data {
@@ -210,16 +211,27 @@ static int pstore_file_open(struct inode *inode, struct 
file *file)
struct ramoops_context *cxt = ps->psi->data;
struct ramoops_zone*zones = cxt ? cxt->zones : NULL;
struct seq_file *sf;
+   char *buf = NULL;
int err;
+   u64 id = ps->id;
const struct seq_operations *sops = NULL;
 
if (ps->type == PSTORE_TYPE_FTRACE)
sops = _ftrace_seq_ops;
if (ps->type == PSTORE_TYPE_NORM && zones) {
-   if (zones[ps->id].seq_ops)
-   sops = zones[ps->id].seq_ops;
+   if (zones[id].seq_ops)
+   sops = zones[id].seq_ops;
else
sops = _seq_ops;
+   if (ps->curr) {
+   /*
+* Update size again as current buffer
+* size might be changed.
+*/
+   inode->i_size = ps->size =
+   ps->psi->read_curr(, PSTORE_TYPE_NORM,
+   , ps->psi);
+   }
}
 
err = seq_open(file, sops);
@@ -256,12 +268,16 @@ static int pstore_unlink(struct inode *dir, struct dentry 
*dentry)
 {
struct pstore_private *p = dentry->d_inode->i_private;
 
+   if (p->curr)
+   goto unlink;
if (p->psi->erase)
p->psi->erase(p->type, p->id, p->count,
  dentry->d_inode->i_ctime, p->psi);
else
return -EPERM;
 
+   kfree(p->data);
+unlink:
return simple_unlink(dir, dentry);
 }
 
@@ -358,7 +374,7 @@ int pstore_is_mounted(void)
  */
 int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
  char *data, bool compressed, size_t size,
- struct timespec time, struct pstore_info *psi)
+ struct timespec time, struct pstore_info *psi, bool curr)
 {
struct dentry   *root = pstore_sb->s_root;
struct dentry   *dentry;
@@ -374,14 +390,15 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
list_for_each_entry(pos, , list) {
if (pos->type == type &&
pos->id == id &&
-   pos->psi == psi) {
+   pos->psi == psi &&
+   pos->curr == curr) {
rc = -EEXIST;
break;
}
}
spin_unlock_irqrestore(_lock, flags);
if (rc)
-   return rc;
+   goto fail;
 
rc = -ENOMEM;
inode = pstore_get_inode(pstore_sb);
@@ -389,13 +406,15 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
goto fail;
inode->i_mode = S_IFREG | 0444;
inode->i_fop = _file_operations;
-   private = kmalloc(sizeof *private + size, GFP_KERNEL);
+   private = kmalloc(sizeof(*private), GFP_KERNEL);
if (!private)
goto fail_alloc;
private->type = type;
private->id = id;
private->count = count;
private->psi = psi;
+   private->curr = curr;
+   private->data = data;
 
switch (type) {
case PSTORE_TYPE_DMESG:
@@ -434,13 +453,15 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
break;
}
 
+   if (curr)
+   strcat(name, "_cur");
+
mutex_lock(>d_inode->i_mutex);
 
dentry = d_alloc_name(root, name);
if (!dentry)
goto fail_lockedalloc;
 
-   memcpy(private->data, data, size);
inode->i_size = private->size = size;
 
inode->i_private = private;
@@ -465,6 +486,7 @@ fail_alloc:
iput(inode);
 
 fail:
+   kfree(data);
return rc;
 }
 
@@ -497,6 +519,7 @@ static int 

[PATCH] [NOMERGE] reserved ram for pstore on PC (applied on top of new pstore patch)

[Liu ShuoX]

for pstore record test.

Signed-off-by: Liu ShuoX 
---
 arch/x86/kernel/setup.c |   2 +
 fs/pstore/Makefile  |   2 +-
 fs/pstore/test.c| 170 
 3 files changed, 173 insertions(+), 1 deletion(-)
 create mode 100644 fs/pstore/test.c

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 09c76d2..021b17a 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -854,6 +854,7 @@ dump_kernel_offset(struct notifier_block *self, unsigned 
long v, void *p)
  * Note: On x86_64, fixmaps are ready for use even before this is called.
  */
 
+extern void pstore_ram_reserved_memory(void);
 void __init setup_arch(char **cmdline_p)
 {
memblock_reserve(__pa_symbol(_text),
@@ -1217,6 +1218,7 @@ void __init setup_arch(char **cmdline_p)
 
x86_init.resources.reserve_resources();
 
+   pstore_ram_reserved_memory();
e820_setup_gap();
 
 #ifdef CONFIG_VT
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index 4c9095c..b2a961b 100644
--- a/fs/pstore/Makefile
+++ b/fs/pstore/Makefile
@@ -7,5 +7,5 @@ obj-y += pstore.o
 pstore-objs += inode.o platform.o
 obj-$(CONFIG_PSTORE_FTRACE)+= ftrace.o
 
-ramoops-objs += ram.o ram_core.o
+ramoops-objs += ram.o ram_core.o test.o
 obj-$(CONFIG_PSTORE_RAM)   += ramoops.o
diff --git a/fs/pstore/test.c b/fs/pstore/test.c
new file mode 100644
index 000..109c5a8
--- /dev/null
+++ b/fs/pstore/test.c
@@ -0,0 +1,170 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct norm_zone_test_record {
+   unsigned long val;
+   char str[32];
+};
+
+static void print_record(struct seq_file *s, void *rec)
+{
+   struct norm_zone_test_record *record = rec;
+   pstore_print(s, "%s: %ld\n",
+   record->str, record->val);
+}
+
+DEFINE_PSTORE_RAMZONE(test_zone) = {
+   .size = 4096,
+   .name = "test_zone",
+   .item_size = sizeof(struct norm_zone_test_record),
+   .print_record = print_record,
+};
+
+DEFINE_PSTORE_RAMZONE(test_zone1) = {
+   .size = 4096,
+   .name = "test_zone1",
+   .item_size = sizeof(struct norm_zone_test_record),
+   .print_record = print_record,
+};
+
+static void add_test_record(char *str, unsigned long val)
+{
+   struct norm_zone_test_record *record;
+   record = persistent_ram_new_record(test_zone.prz);
+   if (record) {
+   record->val = val;
+   strcpy(record->str, str);
+   }
+   record = persistent_ram_new_record(test_zone1.prz);
+   if (record) {
+   record->val = val;
+   strcpy(record->str, str);
+   }
+}
+
+static int test_cpufreq_transition(struct notifier_block *nb,
+   unsigned long event, void *data)
+{
+   add_test_record("cpufreq transition", event);
+   return 0;
+}
+
+static struct notifier_block freq_transition = {
+   .notifier_call = test_cpufreq_transition,
+};
+
+#define SZ_4K   0x1000
+#define SZ_2M   0x0020
+#define SZ_2_1M 0x00219000
+#define SZ_16M  0x0100
+
+#define PSTORE_RAM_START_DEFAULTSZ_16M
+#define PSTORE_RAM_SIZE_DEFAULT SZ_2_1M
+
+#ifdef CONFIG_X86_32
+#define RAM_MAX_MEM (max_low_pfn << PAGE_SHIFT)
+#else
+#define RAM_MAX_MEM (1 << 28)
+#endif
+
+static struct ramoops_platform_data pstore_ram_data = { 
+   .mem_size   = PSTORE_RAM_SIZE_DEFAULT,
+   .mem_address= PSTORE_RAM_START_DEFAULT,
+   .record_size= SZ_4K,
+   .console_size   = SZ_2M,
+   .dump_oops  = 1,
+};
+
+static struct platform_device pstore_ram_dev = { 
+   .name = "ramoops",
+   .dev = { 
+   .platform_data = _ram_data,
+   },  
+};
+
+static int __init pstore_ram_register(void)
+{
+   int ret;
+
+   ret = platform_device_register(_ram_dev);
+   if (ret) {
+   pr_err("%s: unable to register pstore_ram device: "
+   "start=0x%llx, size=0x%lx, ret=%d\n", __func__,
+   (unsigned long long)pstore_ram_data.mem_address,
+   pstore_ram_data.mem_size, ret);
+   }
+
+   return ret;
+}
+postcore_initcall(pstore_ram_register);
+
+void __init pstore_ram_reserved_memory(void)
+{
+   phys_addr_t mem;
+   size_t size;
+   int ret;
+
+   size = PSTORE_RAM_SIZE_DEFAULT;
+   size += pstore_norm_zones_size(NULL);
+   size = ALIGN(size, PAGE_SIZE);
+   mem = memblock_find_in_range(0, RAM_MAX_MEM, size, PAGE_SIZE);
+   if (!mem) {
+   pr_err("Cannot find memblock range for pstore_ram\n");
+   return;
+   }
+
+   ret = memblock_reserve(mem, size);
+   if (ret) {
+   pr_err("Failed to reserve memory from 0x%llx-0x%llx\n",
+   (unsigned long long)mem,
+   (unsigned long long)(mem + size - 1));
+   return;
+   }
+
+   

[PATCH v5 1/3] pstore: restructure ramoops to support more trace

[Liu ShuoX]

From: Zhang Yanmin 

The patch restructure ramoops of pstore a little to support more user-defined
tracers through ramoops. Here is reason we enhance ramoops:
pstore ramoops is a very import debug feature for mobile development. At 
present,
ramoops has supported kdump, console and ftrace tracer. Sometimes, we need some
special tracers such as recording cmd and data when driver send/receive. But 
now,
it's hard to add new tracers into ramoops without touching the pstore core 
codes.
So we restructure ramoops to let it more flexiable, more eailier to extend.

With this, we split the pstore codes and new tracers which are based on ramoops.
Developer could add a new tracer based on ramoops standalone and pstore detects
it automatically.

Signed-off-by: Zhang Yanmin 
Signed-off-by: Liu ShuoX 
---
 Documentation/ramoops.txt |  71 -
 arch/x86/kernel/vmlinux.lds.S |   9 ++
 drivers/platform/chrome/chromeos_pstore.c |   2 +-
 fs/pstore/inode.c |  85 +++-
 fs/pstore/internal.h  |   1 +
 fs/pstore/platform.c  |  38 +++
 fs/pstore/ram.c   | 159 --
 fs/pstore/ram_core.c  |  20 
 include/linux/pstore.h|   2 +
 include/linux/pstore_ram.h|  21 +---
 include/linux/pstore_ramoops.h|  84 
 11 files changed, 443 insertions(+), 49 deletions(-)
 create mode 100644 include/linux/pstore_ramoops.h

diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 69b3cac..9d37cd4 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -49,7 +49,7 @@ Setting the ramoops parameters can be done in 2 different 
manners:
  2. Use a platform device and set the platform data. The parameters can then
  be set through that platform data. An example of doing that is:
 
-#include 
+#include 
 [...]
 
 static struct ramoops_platform_data ramoops_data = {
@@ -117,3 +117,72 @@ file. Here is an example of usage:
  0 811d9c54  8101a7a0  __const_udelay <- 
native_machine_emergency_restart+0x110/0x1e0
  0 811d9c34  811d9c80  __delay <- __const_udelay+0x30/0x40
  0 811d9d14  811d9c3f  delay_tsc <- __delay+0xf/0x20
+
+6. Persistent record tracing
+
+Persistent record tracing is useful for debugging software and hardware
+related hang issues. Its flexible usage allows developers to record data in
+a self-defined record structure at tracepoints where they want. After
+rebooting or reset, kernel saves the old records and provides "NAME-ramoops"
+file for applications/users to access.
+Here is an example of usage:
+
+#include 
+[...]
+
+struct norm_zone_test_record {
+   unsigned long val;
+   char str[32];
+};
+
+static void print_record(struct seq_file *s, void *rec)
+{
+   struct norm_zone_test_record *record = rec;
+   pstore_print(s, "%s: %ld\n",
+   record->str, record->val);
+}
+
+DEFINE_PSTORE_RAMZONE(test_zone) = {
+   .size = 4096,
+   .name = "test_zone",
+   .item_size = sizeof(struct norm_zone_test_record),
+   .print_record = print_record,
+};
+
+static void add_test_record(char *str, unsigned long val)
+{
+   struct norm_zone_test_record *record;
+   record = ramoops_get_new_record(_zone);
+   if (record) {
+   record->val = val;
+   strcpy(record->str, str);
+   }
+}
+
+static int test_cpufreq_transition(struct notifier_block *nb,
+   unsigned long event, void *data)
+{
+   add_test_record("cpufreq transition", event);
+   return 0;
+}
+
+static struct notifier_block freq_transition = {
+   .notifier_call = test_cpufreq_transition,
+};
+
+static int __init norm_zone_test_init(void)
+{
+   cpufreq_register_notifier(_transition,
+   CPUFREQ_TRANSITION_NOTIFIER);
+   return 0;
+}
+module_init(norm_zone_test_init);
+
+Developers could put a call to the memblock_reserve() function (below) in
+setup_arch to reserve memory and implement a ramoops platform device.
+
+#include 
+#include 
+
+memblock_reserve(ramoops_data.mem_address, ramoops_data.mem_size +
+   pstore_norm_zones_size(NULL));
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 49edf2d..2422622 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -304,6 +304,15 @@ SECTIONS
NOSAVE_DATA
}
 #endif
+#ifdef CONFIG_PSTORE
+   /* ramoops zone */
+   . = ALIGN(8);
+   .ram_zone : AT(ADDR(.ram_zone) - LOAD_OFFSET) {
+   __ramoops_zone_start = .;
+   *(.ram_zone)
+   __ramoops_zone_end = .;
+   }
+#endif
 
/* BSS */
. = ALIGN(PAGE_SIZE);
diff --git a/drivers/platform/chrome/chromeos_pstore.c 
b/drivers/platform/chrome/chromeos_pstore.c
index 

[PATCH v5 0/3] Add a method to expand tracers for pstore easily

[Liu ShuoX]

Hi,
Here are the v5 of this series. The intention is to add a framework to ramoops
and make expanding tracers for pstore easily. Comments are welcome.

Changelog v5:
  1) Document fix

Changelog v4:
  1) Fix record zone traversing lost when get old buffer.
  2) Add dump records to printk log buf function at runtime by code.
  3) Fix some minor issues.

Changelog v3: 
  1) Fix compiling errors when CONFIG_PSTORE_RAM=m.

Changelog v2: 
  1) Fix compiling errors when CONFIG_PSTORE_RAM is disabled.
  2) Add some protection in the code in case we disable CONFIG_PSTORE_RAM.

---
Liu ShuoX (2):
  pstore: add seq_ops for norm zone
  pstore: support current records dump in ramoops

Zhang Yanmin (1):
  pstore: restructure ramoops to support more trace

 Documentation/ramoops.txt |  71 +++-
 arch/x86/kernel/vmlinux.lds.S |   9 ++
 drivers/platform/chrome/chromeos_pstore.c |   2 +-
 fs/pstore/inode.c | 126 +++--
 fs/pstore/internal.h  |   4 +-
 fs/pstore/platform.c  |  77 +++--
 fs/pstore/ram.c   | 177 +-
 fs/pstore/ram_core.c  |  30 +
 include/linux/pstore.h|   4 +
 include/linux/pstore_ram.h|  23 ++--
 include/linux/pstore_ramoops.h|  85 ++
 11 files changed, 543 insertions(+), 65 deletions(-)
 create mode 100644 include/linux/pstore_ramoops.h

-- 
1.8.3.2

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

RE: [PATCH] provide irq_force_affinity fallback for non-SMP

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> Patch 01f8fa4f01d "genirq: Allow forcing cpu affinity of interrupts" added
> an irq_force_affinity() function, and 30ccf03b4a6 "clocksource:
Exynos_mct:
> Use irq_force_affinity() in cpu bringup" subsequently uses it. However,
> the
> driver can be used with CONFIG_SMP disabled, but the function declaration
> is only available for CONFIG_SMP, leading to this build error:
> 
> drivers/clocksource/exynos_mct.c:431:3: error: implicit declaration of
> function 'irq_force_affinity' [-Werror=implicit-function-declaration]
>irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
> 
> This patch introduces a dummy helper function for the non-SMP case
> that always returns success, to get rid of the build error.
> Since the patches causing the problem are marked for stable backports,
> this one should be as well.
> 
> Signed-off-by: Arnd Bergmann 

Arnd, thanks for your fix the build error.

Acked-by: Kukjin Kim 

- Kukjin

> Cc: sta...@vger.kernel.org
> ---
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 0e6b23f..b72a643 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -272,6 +272,11 @@ static inline int irq_set_affinity(unsigned int irq,
> const struct cpumask *m)
>   return -EINVAL;
>  }
> 
> +static inline int irq_force_affinity(unsigned int irq, const struct
> cpumask *cpumask)
> +{
> + return 0;
> +}
> +
>  static inline int irq_can_set_affinity(unsigned int irq)
>  {
>   return 0;

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

Re: [PATCH 0/2] namespaces: log namespaces per task

[James Bottomley]

On Tue, 2014-05-06 at 03:27 +, Serge Hallyn wrote:
> Quoting James Bottomley (james.bottom...@hansenpartnership.com):
> > >> Right, but when the contaner has an audit namespace, that namespace
> > >has
> > >> a name,
> > >
> > >What ns has a name?
> > 
> > The netns for instance.
> 
> And what is its name?

As I think you know ip netns list will show you all of them.  The way
they're applied is via mapped files in /var/run/netns/ which hold the
names.

>   The only name I know that we could log in an
> audit message is the /proc/self/ns/net inode number (which does not
> suffice)

OK, so I think this is the confusion: You're thinking the container
itself doesn't know what name the namespace has been given by the
system, all it knows is the inode number corresponding to a file which
it may or may not be able to see, right?  I'm thinking that the system
that set up the container gave those files names and usually they're the
same name for all the namespaces.  The point is that the orchestration
system (whatever set up the container) will be responsible for the
migration.  It will be the thing that has a unique handle for the
container.  The handle is usually ascii representable, either a human
readable name or some uuid/guid.  It's that handle that we should be
using to prefix the audit message, so when you set up an audit
namespace, it gets supplied with a prefix string corresponding to the
well known name for the container.  This is the string we'd preserve
across migration as part of the audit namespace state ... so the audit
messages all correlate to the container wherever it's migrated to; no
need to do complex tracking of changes to serial numbers.

> > >  The audit ns can be tied to 50 pid namespaces, and
> > >we
> > >want to log which pidns is responsible for something.
> > >
> > >If you mean the pidns has a name, that's the problem...  it does not,
> > >it
> > >only has a inode # which may later be re-use.
> > 
> > I still think there's a miscommunication somewhere: I believe you just need 
> > a stable id to tie the audit to, so why not just give the audit namespace a 
> > name like net?  The id would then be durable across migrations.
> 
> Maybe this is where we're confusing each other - I'm not talking
> about giving the audit ns a name.  I'm talking about being able to
> identify the other namespaces inside an audit message.  In a way
> that (a) is unique across bare metals' entire uptime, and (b)
> can be tracked across migrations.

OK, so that is different from what I'm thinking.  I'm thinking unique
name for migrateable entity, you want a unique name for each component
of the migrateable entity?  My instinct still tells me the orchestration
system is going to have a unique identifier for each different sub
container.

However, I have to point out that a serial number isn't what you want
either if you really mean bare metal.  We do a lot of deployments where
the containers run in a hypervisor, there the serial numbers won't be
unique per box (only per vm) and we'll have to do vm correlation
separately.  whereas a scheme which allows the orchestration system to
supply the names would still be unique in that situation.

James


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

RE: [PATCH 1/2] ARM: SAMSUNG: remove gpio flags in dev-backlight

[Kukjin Kim]

Alexandre Courbot wrote:
> 
> On Thu, Apr 10, 2014 at 11:14 PM, Alexandre Courbot 
> wrote:
> > On Thu, Apr 10, 2014 at 6:51 PM, Jingoo Han  wrote:
> >> On Thursday, April 10, 2014 1:17 PM, Alexandre Courbot wrote:
> >>>
> >>> Ping, can I have the Samsung folks review and ,aybe even merge this
> >>> patch? enable_gpio_flags is never used in any code, is replaced by
> >>> gpiod, and we would like to remove it altogether from pwm_bl. Thanks!
> >>
> >> OK, I see. It looks good.
> >>
> >> As far as I know, 'enable_gpio_flags' has not been being used
> >> for Samsung platform. So, there will be no side effect,
> >> if 'enable_gpio_flags' is removed from 'arch/arm/plat-samsung'
> >> directory.
> >>
> >> Reviewed-by: Jingoo Han 
> >
> > Great, thanks. Ben, Kukjin, could we have your Acked-by?
> >
> > Thierry, if the Samsung maintainers are ok with it, and 2/2 of this
> > series is also ok for you (you merged the same for simple-panel
> > already), can you take both into your tree?
> 
> Last call - could we have a Acked-by from Ben or Kukjin and merge this
> through Thierry's tree? Otherwise I will just have to drop this
> series, which would be sad.

Very sorry for late response. I missed... :(

Looks good to me, so please go ahead with my ack.

Thanks,
Kukjin

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

Re: fanotify man pages for review

[Michael Kerrisk (man-pages)]

On 05/05/2014 08:07 PM, Jan Kara wrote:
>   Hello,
> 
>   below are some minor comments regarding the manpages.
> 
>> diff --git a/man2/fanotify_mark.2 b/man2/fanotify_mark.2
>> new file mode 100644
>> index 000..693eff8
>> --- /dev/null
>> +++ b/man2/fanotify_mark.2
> ...
>> +.B FAN_MARK_IGNORED_SURV_MODIFY
>> +The ignore mask shall survive modify events.
>> +If this flag is not set, the ignore mask is cleared when a modify event 
>> occurs
>> +for the ignored file or directory.
>   This is correct but maybe we should explicitely stress that the modify
> event doesn't have to be delivered to the fanotify group? I.e. the
> clearing happens even if the mark doesn't have FAN_MODIFY set... But maybe
> it would just unecessarily complicate the explanation. Just a suggestion.

I think it's an important detail, worth clarifying.

>> diff --git a/man7/fanotify.7 b/man7/fanotify.7
>> new file mode 100644
>> index 000..083244f
>> --- /dev/null
>> +++ b/man7/fanotify.7
> ...
>> +A possible usage of the ignore mask is for a file cache.
>> +Events of interest for a file cache are modification of a file and closing
>> +of the same.
>> +Hence, the cached directory or mount point is to be marked to receive these
>> +events.
>> +After receiving the first event informing that a file has been modified, the
>> +corresponding cache entry will be invalidated.
>> +No further modification events for this file are of interest until the file 
>> is
>> +closed.
>> +Hence, the modify event can be added to the ignore mask.
>> +Upon receiving the closed event, the modify event can be removed from the
>    close

Thanks. Fixed.

>> +ignore mask and the file cache entry can be updated.
>> +.PP
>> +The entries in the fanotify notification groups refer to files and 
>> directories
>> +via their inode number and to mounts via their mount ID.
>> +If files or directories are renamed or moved, the respective entries 
>> survive.
>> +If files or directories are deleted or mounts are unmounted, the 
>> corresponding
>> +entries are deleted.
>> +.SS The event queue
>> +As events occur on the filesystem objects monitired by a notification group,
  ^^^ monitored
Already fixed.
 
>> +the fanotify system generates events that are collected in a queue.
>> +These events can then be read (using
>> +.BR read (2)
>> +or similar)
>> +from the fanotify file descriptor
>> +returned by
>> +.BR fanotify_init (2).
>> +
>> +Two types of events are generated:
>> +notification events and permission events.
>> +Notification events are merely informative
>> +and require no action to be taken by
>> +the receiving application except for closing the file descriptor passed in 
>> the
>> +event.
>> +Permission events are requests to the receiving application to decide 
>> whether
>> +permission for a file access shall be granted.
>> +For these events, the recipient must write a response which decides whether
>> +access is granted or not.
>> +
>> +Queue entries for notification events are removed when the event has been
>> +read.
>> +Queue entries for permission events are removed when the permission
>> +decision has been taken by writing to the fanotify file descriptor.
>   This is true however it may be slightly misleading - the permission
> events are removed from the queue as soon as they are read. But they are
> destroyed only after the permission response is received. So from
> userspace POV dequeued events are invisible...

Probably also worth clarifying.

>> +A program listening to fanotify events can compare this PID to the PID 
>> returned
>> +by
>> +.BR getpid (2),
>> +to determine whether the event is caused by the listener itself, or is due 
>> to a
>> +file access by another program.
>> +.PP
>> +The bit mask in
>> +.I mask
>> +signals which events have occurred for a single filesystem object.
>> +Multiple bits may be set in this mask,
>> +if more than one event occurred for the monitored filesystem obect.
> ^^ object

Already fixed.

>> +.B ENOENT
>> +The file descriptor
>> +.I fd
>> +in the response structure is not valid.
>> +This might occur because the file was already deleted by another thread or
>> +process.
>   This isn't quite true. Another thread of the same process may have already
> closed the 'fd'. But it has nothing to do with a file being deleted.
> fanotify uses file descriptors exactly so that renames or deletes don't
> make the event invalid.

Okay -- also needs fixing.

Heinrich, do you want to patch the above open points, or shall I take a shot?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH] tty: serial: uartlite: Specify time for sending chars

[Michal Simek]

On 05/05/2014 09:42 PM, Peter Korsgaard wrote:
>> "Michal" == Michal Simek  writes:
> 
> Hi,
> 
>  >> > diff --git a/drivers/tty/serial/uartlite.c 
> b/drivers/tty/serial/uartlite.c
>  >> > index 5f90ef24d475..723a6b79cd14 100644
>  >> > --- a/drivers/tty/serial/uartlite.c
>  >> > +++ b/drivers/tty/serial/uartlite.c
>  >> > @@ -418,14 +418,20 @@ static struct uart_ops ulite_ops = {
>  >> >  #ifdef CONFIG_SERIAL_UARTLITE_CONSOLE
>  >> >  static void ulite_console_wait_tx(struct uart_port *port)
>  >> >  {
>  >> > -   int i;
>  >> > u8 val;
>  >> > +   unsigned long timeout;
>  >> 
>  >> > /* Spin waiting for TX fifo to have space available */
>  >> > -   for (i = 0; i < 10; i++) {
>  >> 
>  >> It would be good to add a note about the slow jtag variant here.
> 
>  > What exactly you would like to see here?
>  > Just that this 1s is here because of mdm uart.
> 
> Something like:
> 
>  /*
>   * Spin waiting for TX fifo to have space available.
>   * When using the Microblaze Debug Module this can take up to 1s
>   */

up to you. You are driver owner. :-)
I have sent v2 with this change and I have added your ACK.

Thanks,
Michal

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




signature.asc
Description: OpenPGP digital signature

Re: [perf] more perf_fuzzer memory corruption

[Vince Weaver]

On Mon, 5 May 2014, Ingo Molnar wrote:
> 
> I'm also thinking about waiting a bit before applying anything even 
> borderline intrusive to the perf core, to make sure there's enough 
> fuzz time to declare stable state (at least as far into the ABI as the 
> fuzzing is able to reach). Future bisection efforts could use that 
> kind of known-stable release.

That does sound like a good idea.  It is nice finally getting to the state 
where you can fuzz for hours (rather than minutes) without hitting a bug.

Of course that might change.  Development of the fuzzer has more or less
stalled for the past 6 months as I was spending all of my time 
reporting/chasing bugs rather than enhancing the fuzzer.  

In any case if we can get the recent patches applied in time for 3.15 I 
think it will turn out to be a nice release perf-event-stability wise.

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

[PATCH v2] tty: serial: uartlite: Specify time for sending chars

[Michal Simek]

Xilinx MDM (Microblaze Debug Module) also contains
uart interface via JTAG which is compatible with
uartlite driver. This interface is really slow
that's why timeout is setup to 1s.

Make this time delay not to be cpu speed dependent.

Signed-off-by: Michal Simek 
Acked-by: Peter Korsgaard 
---

Changes in v2:
- Add Peter's ACK
- Extend commentary

RFC sent here:
https://lkml.org/lkml/2013/9/30/250
I finally got HW design which is just slow to be able
to test it.

---
 drivers/tty/serial/uartlite.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
index 5f90ef24d475..dce27f34937e 100644
--- a/drivers/tty/serial/uartlite.c
+++ b/drivers/tty/serial/uartlite.c
@@ -418,14 +418,23 @@ static struct uart_ops ulite_ops = {
 #ifdef CONFIG_SERIAL_UARTLITE_CONSOLE
 static void ulite_console_wait_tx(struct uart_port *port)
 {
-   int i;
u8 val;
-
-   /* Spin waiting for TX fifo to have space available */
-   for (i = 0; i < 10; i++) {
+   unsigned long timeout;
+
+   /*
+* Spin waiting for TX fifo to have space available.
+* When using the Microblaze Debug Module this can take up to 1s
+*/
+   timeout = jiffies + msecs_to_jiffies(1000);
+   while (1) {
val = uart_in32(ULITE_STATUS, port);
if ((val & ULITE_STATUS_TXFULL) == 0)
break;
+   if (time_after(jiffies, timeout)) {
+   dev_warn(port->dev,
+"timeout waiting for TX buffer empty\n");
+   break;
+   }
cpu_relax();
}
 }
--
1.8.2.3



pgpNfRzVq0Dvf.pgp
Description: PGP signature

Re: [PATCH 08/24] net, diet: Make TCP metrics optional

[Tom Zanussi]

On Mon, 2014-05-05 at 23:23 -0400, David Miller wrote:
> From: Andi Kleen 
> Date: Tue, 6 May 2014 05:21:14 +0200
> 
> > What parts would you remove to get the foot print down for a 2MB
> > single purpose machine?
> 
> I wouldn't use Linux, end of story.
> 
> Maybe two decades ago, but not now, those days are over.

These 'new' systems we're talking about pretty much are the same as
systems from 20 years ago e.g. Quark, which is essentially a 486, with
tiny amounts of RAM, say less than 2 MB, so I hope those days aren't
over forever for Linux...

Anyway, Andi's net-diet and LTO patches allowed me to go from a kernel
text size of above 1100k down to about 750k with the kernel network
stack running an unmodified small web server (nostromo) and the ability
to drop in a dedicated single-purpose application that this type of
system would typically run e.g. something based on for example UDP.

I was able to get that down to about 620k removing INET completely and
replacing it with LWIP, but LWIP either bloated the application back up
to similar memory usage numbers as with INET configured in, or
alternatively required extensive changes to the application in order to
use the not-bloating low-level interface.

But why go to all that trouble when there's a perfectly good networking
stack in the kernel?  Even if most of these options aren't things that
would be useful to most systems, being able to turn them off and save
1/3 of the kernel text size for tiny systems like this does makes a big
difference...

Tom

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

[PATCH 1/7] staging: slicoss: fix use-after-free in slic_entry_probe

[David Matlack]

This patch fixes a use-after-free bug that can cause a kernel
oops. If slic_card_init fails then slic_entry_probe (the pci
probe() function for this device) will return error without
cleaning up memory.

Signed-off-by: David Matlack 
---
 drivers/staging/slicoss/slicoss.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index e27b88f..6113b90 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -3595,7 +3595,6 @@ static int slic_entry_probe(struct pci_dev *pcidev,
struct net_device *netdev;
struct adapter *adapter;
void __iomem *memmapped_ioaddr = NULL;
-   u32 status = 0;
ulong mmio_start = 0;
ulong mmio_len = 0;
struct sliccard *card = NULL;
@@ -3686,16 +3685,11 @@ static int slic_entry_probe(struct pci_dev *pcidev,
adapter->allocated = 1;
}
 
-   status = slic_card_init(card, adapter);
+   err = slic_card_init(card, adapter);
+   if (err)
+   goto err_out_unmap;
 
-   if (status != 0) {
-   card->state = CARD_FAIL;
-   adapter->state = ADAPT_FAIL;
-   adapter->linkstate = LINK_DOWN;
-   dev_err(>dev, "FAILED status[%x]\n", status);
-   } else {
-   slic_adapter_set_hwaddr(adapter);
-   }
+   slic_adapter_set_hwaddr(adapter);
 
netdev->base_addr = (unsigned long)adapter->memorybase;
netdev->irq = adapter->irq;
@@ -3712,7 +3706,7 @@ static int slic_entry_probe(struct pci_dev *pcidev,
 
cards_found++;
 
-   return status;
+   return 0;
 
 err_out_unmap:
iounmap(memmapped_ioaddr);
-- 
1.9.2

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

[PATCH 3/7] staging: slicoss: remove unused members of struct adapter

[David Matlack]

This patch removes two fields from the private "struct adapter".
Specifically,

memorybase  duplicate of slic_regs

memorylengthwritten once and never read. This field is trivially
computed with pci_resource_len if it's ever needed in
the future.

Signed-off-by: David Matlack 
---
 drivers/staging/slicoss/slic.h| 2 --
 drivers/staging/slicoss/slicoss.c | 4 +---
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 702902c..379c4f7 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -420,8 +420,6 @@ struct adapter {
ushort  devid;
ushort  subsysid;
u32 irq;
-   void __iomem *memorybase;
-   u32 memorylength;
u32 drambase;
u32 dramlength;
uintqueues_initialized;
diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 452aa02..b0b8544 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -3422,7 +3422,6 @@ static void slic_init_adapter(struct net_device *netdev,
adapter->busnumber = pcidev->bus->number;
adapter->slotnumber = ((pcidev->devfn >> 3) & 0x1F);
adapter->functionnumber = (pcidev->devfn & 0x7);
-   adapter->memorylength = pci_resource_len(pcidev, 0);
adapter->slic_regs = (__iomem struct slic_regs *)memaddr;
adapter->irq = pcidev->irq;
 /* adapter->netdev = netdev;*/
@@ -3431,7 +3430,6 @@ static void slic_init_adapter(struct net_device *netdev,
adapter->chipid = chip_idx;
adapter->port = 0;  /*adapter->functionnumber;*/
adapter->cardindex = adapter->port;
-   adapter->memorybase = memaddr;
spin_lock_init(>upr_lock.lock);
spin_lock_init(>bit64reglock.lock);
spin_lock_init(>adapter_lock.lock);
@@ -3683,7 +3681,7 @@ static int slic_entry_probe(struct pci_dev *pcidev,
 
slic_adapter_set_hwaddr(adapter);
 
-   netdev->base_addr = (unsigned long)adapter->memorybase;
+   netdev->base_addr = (unsigned long) memmapped_ioaddr;
netdev->irq = adapter->irq;
netdev->netdev_ops = _netdev_ops;
 
-- 
1.9.2

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

Re: [PATCH 2/5] ARM: add SMP support for Broadcom mobile SoCs

[Alex Elder]

On 05/05/2014 08:43 PM, Stephen Boyd wrote:
> On 05/05/14 15:02, Alex Elder wrote:
>> On 04/04/2014 12:55 PM, Stephen Boyd wrote:
>>> On 04/03/14 19:18, Alex Elder wrote:
 +
 +/*
 + * Secondary startup method setup routine to extract the location of
 + * the secondary boot register from a "cpu" or "cpus" device tree
 + * node.  Only the first seen secondary boot register value is used;
 + * any others are ignored.  The secondary boot register value must be
 + * non-zero.
 + *
 + * Returns 0 if successful or an error code otherwise.
 + */
 +static int __init of_enable_method_setup(struct device_node *node)
 +{
 +  int ret;
 +
 +  /* Ignore all but the first one specified */
 +  if (secondary_boot)
 +  return 0;
 +
 +  ret = of_property_read_u32(node, OF_SECONDARY_BOOT, _boot);
 +  if (ret)
 +  pr_err("%s: missing/invalid " OF_SECONDARY_BOOT " property\n",
 +  node->name);
 +
 +  return ret;
 +}
>>> I don't understand why we need this. Why can't we get the secondary boot
>>> address from the /cpus node in the smp_prepare_cpus op. It isn't that
>>> hard to get access to the cpus node there via of_find_node_by_path().
>>> Then we don't need patch 1 at all. If it turns out to be common stuff,
>>> we can always have the common function live in arm common code or maybe
>>> even be a devicetree API.
>> I already responded to this, but never got any response.  I
>> was preparing to re-send this series and wanted to try to
>> pull the added feature (patch 1) out and not be dependent on
>> it.  But I think it's a bit ugly so I'm hoping to get a
>> blessing to proceed with what I originally proposed.  For
>> reference, here's the thread:
>> https://lkml.org/lkml/2014/4/3/421
>>
>> What I'm trying to do is get the value of a "secondary-boot-reg"
>> property from a node known to have an "enable-method" property
>> that matches the method name supplied in CPU_METHOD_OF_DECLARE().
> 
> I don't recall seeing any documentation about the secondary-boot-reg
> property. Please make sure it is documented in the next patch series.

I omitted the documentation, hoping to get some input about how
best to go about it.  I talked with Mark Rutland last week and
agreed to split off the "enable-method" descriptions into a file
separate from "Documentation/devicetree/bindings/arm/cpus.txt"
because it seemed like there might be a proliferation of them.
I will definitely include it this time around.

>> Using the callback function as I originally proposed, this is
>> very easy.  When arm_dt_init_cpu_maps() parses the "cpus" portion
>> of the device tree it calls set_smp_ops_by_method() for a
>> matching "cpu" or "cpus" node, and that function supplies
>> the node to the callback function. The callback can extract
>> additional property values if needed.
>>
>> If I hold off until smp_prepare_cpus() is called, I have to
>> re-parse the device tree to find the "cpus" node (this is
>> in itself trivial).  I then need to re-parse that node to
>> verify the matching "enable-method" property is found before
>> looking for the parameter information I need for that enable
>> method.  I would really prefer not to re-do this parsing
>> step.  It's imprecise and a little inefficient, and it
>> duplicates (but not exactly) logic that's already performed
>> by arm_dt_init_cpu_maps().
> 
> Do you have any devices where the enable-method and secondary-boot-reg
> isn't the same across all CPUs? A lot of the complexity comes from

To be clear, my discussion here is thinking more broadly than
this specific case--beyond the Broadcom SoCs I'm adding support for.

But to answer your question, I am not aware of any such devices.

> broken DTs that don't specify a secondary-boot-reg along with the
> enable-method. From the description and the code it seems that we should
> just always put these two properties in the cpus node to make things
> simple and precise. I agree it's a minor duplication to read the DT

Yes, I agree that specifying it only in "cpus" is preferable
in general, and specifically that was how I was going to
describe this binding.

I could imagine a big.LITTLE machine could have different
methods but I have no experience with that.  It seems we should
just dictate using the "cpus" node (not "cpu" nodes) unless/until
there comes along a real machine that requires multiple methods.
(But as the code now stands, only the first matching "cpu" node
is ever used--any others are ignored--so it wouldn't support such
a theoretical case anyway.)

> again to get the /cpus node and read a property out of it, but I doubt
> you could even measure the difference.

No, that's why I said "a little inefficient."

My bigger issue has to do with the fact that arm_dt_init_cpu_maps()
already does a comprehensive job of parsing device tree nodes and
finding matching "enable-method" entries.  I view this extra
"secondary-boot-reg" 

[PATCH 6/7] staging: slicoss: fix 64-bit isr address bug

[David Matlack]

This patch fixes a bug that only manifests when the physical address of
the interrupt status register is >4GB. Specifically, the driver was only
telling the device about the lower 32 bits of the ISR. This patch adds
the upper 32 bits.

Signed-off-by: David Matlack 
---
 drivers/staging/slicoss/slicoss.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 01401e0..55afe0d 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2815,7 +2815,8 @@ static int slic_card_init(struct sliccard *card, struct 
adapter *adapter)
 
spin_lock_irqsave(>bit64reglock.lock,
adapter->bit64reglock.flags);
-   slic_reg32_write(_regs->slic_addr_upper, 0, DONT_FLUSH);
+   slic_reg32_write(_regs->slic_addr_upper,
+SLIC_GET_ADDR_HIGH(>isr), DONT_FLUSH);
slic_reg32_write(_regs->slic_isp,
 SLIC_GET_ADDR_LOW(>isr), FLUSH);
spin_unlock_irqrestore(>bit64reglock.lock,
-- 
1.9.2

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

[PATCH 5/7] staging: slicoss: fix dma memory leak

[David Matlack]

This patch fixes a memory leak in slic_card_init. If the driver fails
to poll for an interrupt after requesting config data from the device
the dma memory is never freed.

Signed-off-by: David Matlack 
---
 drivers/staging/slicoss/slicoss.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 39e6489..01401e0 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2852,6 +2852,9 @@ static int slic_card_init(struct sliccard *card, struct 
adapter *adapter)
_regs->slic_isp, 0,
_regs->slic_addr_upper,
0, FLUSH);
+   pci_free_consistent(adapter->pcidev,
+   sizeof(struct slic_eeprom),
+   peeprom, phys_config);
return -EINVAL;
}
}
-- 
1.9.2

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

[PATCH 2/7] staging: slicoss: fix multiple free-after-free in slic_entry_remove

[David Matlack]

This patch fixes two free-after-free bugs in slic_entry_remove.
Specifically, slic_unmap_mmio_space() iounmaps adapter->slic_regs,
which is the same region of memory as dev->base_addr (iounmap-ed
a few lines later).

Next, both release_mem_region() and pci_release_regions() are called
on the same pci_dev struct.

Signed-off-by: David Matlack 
---
 drivers/staging/slicoss/slicoss.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 6113b90..452aa02 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2955,8 +2955,6 @@ static void slic_card_cleanup(struct sliccard *card)
 static void slic_entry_remove(struct pci_dev *pcidev)
 {
struct net_device *dev = pci_get_drvdata(pcidev);
-   u32 mmio_start = 0;
-   uint mmio_len = 0;
struct adapter *adapter = netdev_priv(dev);
struct sliccard *card;
struct mcast_address *mcaddr, *mlist;
@@ -2965,12 +2963,6 @@ static void slic_entry_remove(struct pci_dev *pcidev)
slic_unmap_mmio_space(adapter);
unregister_netdev(dev);
 
-   mmio_start = pci_resource_start(pcidev, 0);
-   mmio_len = pci_resource_len(pcidev, 0);
-
-   release_mem_region(mmio_start, mmio_len);
-
-   iounmap((void __iomem *)dev->base_addr);
/* free multicast addresses */
mlist = adapter->mcastaddrs;
while (mlist) {
-- 
1.9.2

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

Re: [PATCH] slab: Fix off by one in object max number tests.

[Pekka Enberg]

On Tue, May 6, 2014 at 6:32 AM, Linus Torvalds
 wrote:
> On Mon, May 5, 2014 at 8:25 PM, David Miller  wrote:
>>
>>> Sam Ravnborg  wrote:

 There is a related patch in this area which I think is not yet applied.

 See: https://lkml.org/lkml/2014/4/18/28

 Maybe this is related.
>>>
>>> Thanks, I'm testing with that patch added as well.
>>
>> I can confirm that this fixes my problems completely.
>
> Ugh. That patch has been out two weeks already. Pekka?

Sorry, I missed that completely.

> I guess I'll apply both patches directly.

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

[PATCH 4/7] staging: slicoss: remove gratuitous debug infrastructure

[David Matlack]

As per the TODO file, this patch removes the gratuitous debug
infrastructure. As an extra incentive for removing this code,
the debugfs files are not cleaned up properly. For example, if
register_netdev() fails in slic_entry_probe() then all debugfs
files get left behind, even after the driver module is unloaded.
Touching these files quickly leads to an oops.

Signed-off-by: David Matlack 
---
 drivers/staging/slicoss/TODO  |   1 -
 drivers/staging/slicoss/slic.h|   3 -
 drivers/staging/slicoss/slicoss.c | 450 +-
 3 files changed, 3 insertions(+), 451 deletions(-)

diff --git a/drivers/staging/slicoss/TODO b/drivers/staging/slicoss/TODO
index 62ff100..20cc9ab 100644
--- a/drivers/staging/slicoss/TODO
+++ b/drivers/staging/slicoss/TODO
@@ -18,7 +18,6 @@ TODO:
  use ethtool instead
- reorder code to elminate use of forward declarations
- don't keep private linked list of drivers.
-   - remove all the gratiutous debug infrastructure
- use PCI_DEVICE()
- do ethtool correctly using ethtool_ops
- NAPI?
diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 379c4f7..7de57c4 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -310,8 +310,6 @@ struct sliccard {
u32   loadtimerset;
uint  config_set;
struct slic_config  config;
-   struct dentry  *debugfs_dir;
-   struct dentry  *debugfs_cardinfo;
struct adapter  *master;
struct adapter  *adapter[SLIC_MAX_PORTS];
struct sliccard *next;
@@ -450,7 +448,6 @@ struct adapter {
u32 pingtimerset;
struct timer_list   loadtimer;
u32 loadtimerset;
-   struct dentry  *debugfs_entry;
struct slic_spinlock upr_lock;
struct slic_spinlock bit64reglock;
struct slic_rspqueue rspqueue;
diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index b0b8544..39e6489 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -81,7 +81,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -104,19 +103,13 @@ static char *slic_banner = "Alacritech SLIC 
Technology(tm) Server "
"and Storage Accelerator (Non-Accelerated)";
 
 static char *slic_proc_version = "2.0.351  2006/07/14 12:26:00";
-static char *slic_product_name = "SLIC Technology(tm) Server "
-   "and Storage Accelerator (Non-Accelerated)";
-static char *slic_vendor = "Alacritech, Inc.";
 
-static int slic_debug = 1;
-static int debug = -1;
 static struct net_device *head_netdevice;
 
 static struct base_driver slic_global = { {}, 0, 0, 0, 1, NULL, NULL };
 static int intagg_delay = 100;
 static u32 dynamic_intagg;
 static unsigned int rcv_count;
-static struct dentry *slic_debugfs;
 
 #define DRV_NAME  "slicoss"
 #define DRV_VERSION   "2.0.1"
@@ -1802,430 +1795,6 @@ static u32 slic_rcvqueue_reinsert(struct adapter 
*adapter, struct sk_buff *skb)
return rcvq->count;
 }
 
-static int slic_debug_card_show(struct seq_file *seq, void *v)
-{
-#ifdef MOOKTODO
-   int i;
-   struct sliccard *card = seq->private;
-   struct slic_config *config = >config;
-   unsigned char *fru = (unsigned char *)(>config.atk_fru);
-   unsigned char *oemfru = (unsigned char *)(>config.OemFru);
-#endif
-
-   seq_printf(seq, "driver_version   : %s\n", slic_proc_version);
-   seq_puts(seq, "Microcode versions:\n");
-   seq_printf(seq, "Gigabit (gb) : %s %s\n",
-   MOJAVE_UCODE_VERS_STRING, MOJAVE_UCODE_VERS_DATE);
-   seq_printf(seq, "Gigabit Receiver : %s %s\n",
-   GB_RCVUCODE_VERS_STRING, GB_RCVUCODE_VERS_DATE);
-   seq_printf(seq, "Vendor   : %s\n", slic_vendor);
-   seq_printf(seq, "Product Name : %s\n", slic_product_name);
-#ifdef MOOKTODO
-   seq_printf(seq, "VendorId : %4.4X\n",
-   config->VendorId);
-   seq_printf(seq, "DeviceId : %4.4X\n",
-   config->DeviceId);
-   seq_printf(seq, "RevisionId   : %2.2x\n",
-   config->RevisionId);
-   seq_printf(seq, "Bus# : %d\n", card->busnumber);
-   seq_printf(seq, "Device # : %d\n", card->slotnumber);
-   seq_printf(seq, "Interfaces   : %d\n", card->card_size);
-   seq_printf(seq, " Initialized : %d\n",
-   card->adapters_activated);
-   seq_printf(seq, " Allocated   : %d\n",
-   card->adapters_allocated);
-   for (i = 0; i < card->card_size; i++) {
-   seq_printf(seq,
-  " MAC%d : %2.2X %2.2X %2.2X %2.2X %2.2X %2.2X\n",
-  i, 

[PATCH 7/7] staging: slicoss: fix use-after-free bug in slic_entry_remove

[David Matlack]

This patch fixes a use-after-free bug that causes a null pointer
dereference in slic_entry_halt.

Since unregister_netdev() will ultimately call slic_entry_halt (the
net_device ndo_stop() virtual function for this device), we should
call it before freeing the memory used by slic_entry_halt.

Signed-off-by: David Matlack 
---
 drivers/staging/slicoss/slicoss.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 55afe0d..96b29ec 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2526,9 +2526,10 @@ static void slic_entry_remove(struct pci_dev *pcidev)
struct sliccard *card;
struct mcast_address *mcaddr, *mlist;
 
+   unregister_netdev(dev);
+
slic_adapter_freeresources(adapter);
slic_unmap_mmio_space(adapter);
-   unregister_netdev(dev);
 
/* free multicast addresses */
mlist = adapter->mcastaddrs;
-- 
1.9.2

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

[PATCH 0/7] staging: slicoss: bug fixes to stabilize driver

[David Matlack]

The following patch series fixes multiple small but critical bugs in
the slicoss driver that can cause kernel oopses, panics, and lots of
memory leaking.

The intent of this patch series is to provide the ground work so that
proper work (NAPI, locking re-design, ... see TODO) can be done.

All patches were tested on the "Mojave" (single port, PCI) card.

David Matlack (7):
  staging: slicoss: fix use-after-free in slic_entry_probe
  staging: slicoss: fix multiple free-after-free in slic_entry_remove
  staging: slicoss: remove unused members of struct adapter
  staging: slicoss: remove gratuitous debug infrastructure
  staging: slicoss: fix dma memory leak
  staging: slicoss: fix 64-bit isr address bug
  staging: slicoss: fix use-after-free bug in slic_entry_remove

 drivers/staging/slicoss/TODO  |   1 -
 drivers/staging/slicoss/slic.h|   5 -
 drivers/staging/slicoss/slicoss.c | 487 ++
 3 files changed, 16 insertions(+), 477 deletions(-)

-- 
1.9.2

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

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

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
Documentation/devicetree/bindings/arm/omap/omap.txt between commit
11e2191c2a6f ("ARM: dts: am437x-gp-evm: Add gp dts") from the  tree and
commit c98be0c96db0 ("doc: spelling error changes") from the trivial tree.

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

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

diff --cc Documentation/devicetree/bindings/arm/omap/omap.txt
index 36ede19a1630,aa71962352ff..
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@@ -117,8 -114,5 +117,8 @@@ Boards
  - AM43x EPOS EVM
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
  
 +- AM437x GP EVM
 +  compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
 +
- - DRA7 EVM:  Software Developement Board for DRA7XX
+ - DRA7 EVM:  Software Development Board for DRA7XX
compatible = "ti,dra7-evm", "ti,dra7"


pgpxZXyTMUJ6T.pgp
Description: PGP signature

Re: [PATCH] slab: Fix off by one in object max number tests.

[David Miller]

From: Linus Torvalds 
Date: Mon, 5 May 2014 20:46:32 -0700

> On Mon, May 5, 2014 at 8:32 PM, Linus Torvalds
>  wrote:
>>
>> I guess I'll apply both patches directly.
> 
> Applied and pushed out. Davem, I hope this means current -git works
> for you on sparc64 again?

Yes it absoultely should, and I'll double check to make sure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] slab: Fix off by one in object max number tests.

[Linus Torvalds]

On Mon, May 5, 2014 at 8:32 PM, Linus Torvalds
 wrote:
>
> I guess I'll apply both patches directly.

Applied and pushed out. Davem, I hope this means current -git works
for you on sparc64 again?

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

Re: [PATCH v3 4/7] of: configure the platform device dma parameters

[Benjamin Herrenschmidt]

On Mon, 2014-05-05 at 16:28 -0600, Bjorn Helgaas wrote:
> I still wonder whether arm, powerpc, and tile (and I just noticed
> microblaze also has a similar dma_direct_map_page()) could all be
> handled by attaching devices to a generic trivial IOMMU driver
> parameterized with the appropriate constant offset.

On powerpc, the offset is not constant, it can be per-device

Cheers,
Ben.


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

[PATCH v1] net-sysfs: expose permanent hardware address in sysfs

[David Decotigny]

Tested:
  grep . /sys/class/net/*/*addr*

Signed-off-by: David Decotigny 
---
 net/core/net-sysfs.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 1cac29e..bf57024 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -127,6 +127,20 @@ static ssize_t address_show(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RO(address);
 
+static ssize_t perm_addr_show(struct device *dev, struct device_attribute 
*attr,
+ char *buf)
+{
+   struct net_device *net = to_net_dev(dev);
+   ssize_t ret = -EINVAL;
+
+   read_lock(_base_lock);
+   if (dev_isalive(net))
+   ret = sysfs_format_mac(buf, net->perm_addr, net->addr_len);
+   read_unlock(_base_lock);
+   return ret;
+}
+static DEVICE_ATTR_RO(perm_addr);
+
 static ssize_t broadcast_show(struct device *dev,
  struct device_attribute *attr, char *buf)
 {
@@ -391,6 +405,7 @@ static struct attribute *net_class_attrs[] = {
_attr_addr_len.attr,
_attr_link_mode.attr,
_attr_address.attr,
+   _attr_perm_addr.attr,
_attr_broadcast.attr,
_attr_speed.attr,
_attr_duplex.attr,
-- 
1.9.1.423.g4596e3a

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

Re: [PATCH 0/2] namespaces: log namespaces per task

[Serge Hallyn]

Quoting Richard Guy Briggs (r...@redhat.com):
> On 14/05/03, James Bottomley wrote:
> > On Tue, 2014-04-22 at 14:12 -0400, Richard Guy Briggs wrote:
> > > Questions:
> > > Is there a way to link serial numbers of namespaces involved in migration 
> > > of a
> > > container to another kernel?  (I had a brief look at CRIU.)  Is there a 
> > > unique
> > > identifier for each running instance of a kernel?  Or at least some 
> > > identifier
> > > within the container migration realm?
> > 
> > Are you asking for a way of distinguishing an migrated container from an
> > unmigrated one?  The answer is pretty much "no" because the job of
> > migration is to restore to the same state as much as possible.
> 
> I hadn't thought to distinguish a migrated container from an unmigrated
> one, but rather I'm more interested in the underlying namespaces.  The
> use of a generation number to identify a migrated namespace may be
> useful along with the logging to tie them together.
> 
> > Reading between the lines, I think your goal is to correlate audit
> > information across a container migration, right?  Ideally the management
> > system should be able to cough up an audit trail for a container
> > wherever it's running and however many times it's been migrated?
> 
> The original intent was to track the underlying namespaces themselves.
> This sounds like another layer on top of that which sounds useful but
> that I had not yet considered.
> 
> But yes, that sounds like a good eventual goal.

Right and we don't need that now, all *I* wanted to convince myself of
was that a serial # as you were using it was not going to be a roadlbock
to that, since once we introduce a serial #, we're stuck with that as
user-space facing api.

> > In that case, I think your idea of a numeric serial number in a dense
> > range is wrong.  Because the range is dense you're obviously never going
> > to be able to use the same serial number across a migration.  However,
> > if you look at all the management systems for containers, they all have
> > a concept of some unique ID per container, be it name, UUID or even
> > GUID.  I suspect it's that you should be using to tag the audit trail
> > with.
> 
> That does sound potentially useful but for the fact that several
> containers could share one or more types of namespaces.
> 
> Would logging just a container ID be sufficient for audit purposes?  I'm
> going to have to dig a bit to understand that one because I was unaware
> each container had a unique ID.

They don't :)

> I did originally consider a UUID/GUID for namespaces.

So I think that apart from resending to address the serial # overflow
comment, I'm happy to ack the patches.  Then we probably need to convicne
Eric that we're not torturing kittens.

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

Re: [PATCH] slab: Fix off by one in object max number tests.

[Linus Torvalds]

On Mon, May 5, 2014 at 8:25 PM, David Miller  wrote:
>
>> Sam Ravnborg  wrote:
>>>
>>> There is a related patch in this area which I think is not yet applied.
>>>
>>> See: https://lkml.org/lkml/2014/4/18/28
>>>
>>> Maybe this is related.
>>
>> Thanks, I'm testing with that patch added as well.
>
> I can confirm that this fixes my problems completely.

Ugh. That patch has been out two weeks already. Pekka?

I guess I'll apply both patches directly.

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

Re: [PATCH 0/2] namespaces: log namespaces per task

[Serge Hallyn]

Quoting James Bottomley (james.bottom...@hansenpartnership.com):
> 
> 
> On May 5, 2014 3:36:38 PM PDT, Serge Hallyn  wrote:
> >Quoting James Bottomley (james.bottom...@hansenpartnership.com):
> >> On Mon, 2014-05-05 at 22:27 +, Serge Hallyn wrote:
> >> > Quoting James Bottomley (james.bottom...@hansenpartnership.com):
> >> > > On Mon, 2014-05-05 at 17:48 -0400, Richard Guy Briggs wrote:
> >> > > > On 14/05/05, Serge E. Hallyn wrote:
> >> > > > > Quoting James Bottomley
> >(james.bottom...@hansenpartnership.com):
> >> > > > > > On Tue, 2014-04-22 at 14:12 -0400, Richard Guy Briggs
> >wrote:
> >> > > > > > > Questions:
> >> > > > > > > Is there a way to link serial numbers of namespaces
> >involved in migration of a
> >> > > > > > > container to another kernel?  (I had a brief look at
> >CRIU.)  Is there a unique
> >> > > > > > > identifier for each running instance of a kernel?  Or at
> >least some identifier
> >> > > > > > > within the container migration realm?
> >> > > > > > 
> >> > > > > > Are you asking for a way of distinguishing an migrated
> >container from an
> >> > > > > > unmigrated one?  The answer is pretty much "no" because the
> >job of
> >> > > > > > migration is to restore to the same state as much as
> >possible.
> >> > > > > > 
> >> > > > > > Reading between the lines, I think your goal is to
> >correlate audit
> >> > > > > > information across a container migration, right?  Ideally
> >the management
> >> > > > > > system should be able to cough up an audit trail for a
> >container
> >> > > > > > wherever it's running and however many times it's been
> >migrated?
> >> > > > > > 
> >> > > > > > In that case, I think your idea of a numeric serial number
> >in a dense
> >> > > > > > range is wrong.  Because the range is dense you're
> >obviously never going
> >> > > > > > to be able to use the same serial number across a
> >migration.  However,
> >> > > > > 
> >> > > > > Ah, but I was being silly before, we can actually address
> >this pretty
> >> > > > > simply.  If we just (for instance) add
> >> > > > > /proc/self/ns/{ic,mnt,net,pid,user,uts}_seq containing the
> >serial number
> >> > > > > for the relevant ns for the task, then criu can dump this
> >info at
> >> > > > > checkpoint.  Then at restart it can dump an audit message per
> >task and
> >> > > > > ns saying old_serial=%x,new_serial=%x.  That way the audit
> >log reader
> >> > > > > can if it cares keep track.
> >> > > > 
> >> > > > This is the sort of idea I had in mind...
> >> > > 
> >> > > OK, but I don't understand then why you need a serial number. 
> >There are
> >> > > plenty of things we preserve across a migration, like namespace
> >name for
> >> > > instance.  Could you explain what function it performs because I
> >think I
> >> > > might be missing something.
> >> > 
> >> > We're looking ahead to a time when audit is namespaced, and a
> >container
> >> > can keep its own audit logs (without limiting what the host audits
> >of
> >> > course).  So if a container is auditing suspicious activity by some
> >> > task in a sub-namesapce, then the whole parent container gets
> >migrated,
> >> > after migration we want to continue being able to correlate the
> >namespaces.
> >> > 
> >> > We're also looking at audit trails on a host that is up for years. 
> >We
> >> > would like every namespace to be uniquely logged there.  That is
> >why
> >> > inode #s on /proc/self/ns/* are not sufficient, unless we add a
> >generation
> >> > # (which would end more complicated, not less, than a serial #).
> >> 
> >> Right, but when the contaner has an audit namespace, that namespace
> >has
> >> a name,
> >
> >What ns has a name?
> 
> The netns for instance.

And what is its name?  The only name I know that we could log in an
audit message is the /proc/self/ns/net inode number (which does not
suffice)

> >  The audit ns can be tied to 50 pid namespaces, and
> >we
> >want to log which pidns is responsible for something.
> >
> >If you mean the pidns has a name, that's the problem...  it does not,
> >it
> >only has a inode # which may later be re-use.
> 
> I still think there's a miscommunication somewhere: I believe you just need a 
> stable id to tie the audit to, so why not just give the audit namespace a 
> name like net?  The id would then be durable across migrations.

Maybe this is where we're confusing each other - I'm not talking
about giving the audit ns a name.  I'm talking about being able to
identify the other namespaces inside an audit message.  In a way
that (a) is unique across bare metals' entire uptime, and (b)
can be tracked across migrations.

And again we don't need to actually implement all that now - all
I wanted to make sure of was that the serial # as proposed by Richard
could be made to work for those purposes, and I now believe they can.

> >> which CRIU would migrate, so why not use that name for the
> >> log .. no need for numbers (unless you make the name a number, of
> >> course)?
> >> 
> >> James
> >
> >Sorry 

Re: [PATCH] slab: Fix off by one in object max number tests.

[David Miller]

From: David Miller 
Date: Mon, 05 May 2014 17:08:55 -0400 (EDT)

> From: Sam Ravnborg 
> Date: Mon, 5 May 2014 23:05:07 +0200
> 
>> On Mon, May 05, 2014 at 04:57:56PM -0400, David Miller wrote:
>>> From: David Miller 
>>> Date: Mon, 05 May 2014 16:20:04 -0400 (EDT)
>>> 
>>> > 
>>> > If freelist_idx_t is a byte, SLAB_OBJ_MAX_NUM should be 255 not 256,
>>> > and likewise if freelist_idx_t is a short, then it should be 65535 not
>>> > 65536.
>>> > 
>>> > Fixes: a41adfa ("slab: introduce byte sized index for the freelist of a 
>>> > slab")
>>> > Signed-off-by: David S. Miller 
>>> > ---
>>> > 
>>> > This was leading to all kinds of random crashes on sparc64 where PAGE_SIZE
>>> > is 8192.  One problem shown was that if spinlock debugging was enabled,
>>> > we'd get deadlocks in copy_pte_range() or do_wp_page() with the same cpu
>>> > already holding a lock it shouldn't hold, or the lock belonging to a
>>> > completely unrelated process.
>>> 
>>> It turns out that after some more testing, I'm still getting spinlock
>>> debugging problems with this fix applied.
>>> 
>>> The change is still very much correct I think, however.
>> 
>> There is a related patch in this area which I think is not yet applied.
>> 
>> See: https://lkml.org/lkml/2014/4/18/28
>> 
>> Maybe this is realted.
> 
> Thanks, I'm testing with that patch added as well.

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

Re: [PATCH 08/24] net, diet: Make TCP metrics optional

[David Miller]

From: Andi Kleen 
Date: Tue, 6 May 2014 05:21:14 +0200

> What parts would you remove to get the foot print down for a 2MB
> single purpose machine?

I wouldn't use Linux, end of story.

Maybe two decades ago, but not now, those days are over.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/24] net, diet: Make ethtool optional

[David Miller]

From: Andi Kleen 
Date: Tue, 6 May 2014 05:14:12 +0200

> You can configure the IP address and transmit and receive packets,
> and that is all a small embedded system is ever interested in.

Then let's agree to disagree, I am absolutely certain that small
systems are interested in much more than just these simple
configuration operations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/24] net, diet: Make TCP metrics optional

[Andi Kleen]

On Mon, May 05, 2014 at 11:12:29PM -0400, David Miller wrote:
> From: Andi Kleen 
> Date: Mon,  5 May 2014 15:25:57 -0700
> 
> > This is all the code that saves connection information
> > between different sockets. Not really essential for
> > small systems.
> 
> It is absolutely essential unless you want poor performance
> of TCP connections.

Ok so every code in the network stack is essential?

What parts would you remove to get the foot print down for a 2MB
single purpose machine?

-Andi

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

Re: [PATCH 22/24] net, diet: Support simpler routing table

[David Miller]

From: Andi Kleen 
Date: Tue, 6 May 2014 05:08:33 +0200

> FWIW it seems to me the trie code is very stable, there doesn't
> seem to be any big changes in a long time.

But it was BUGGY AS HELL in the corner cases because it wasn't
the default while it sat next to fib_hash.

It only got totally fixed when it was the ONLY option.

That's exactly my point, parts of it never got tested and were never
verified because debugging resources for it was split with another
implementation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 19/24] net, diet: Make RPS configurable

[Andi Kleen]

On Mon, May 05, 2014 at 11:14:33PM -0400, David Miller wrote:
> From: Andi Kleen 
> Date: Mon,  5 May 2014 15:26:08 -0700
> 
> > Multiple receive queues are not needed on small systems,
> > so allow disabling them.
> 
> It's only enabled with SMP...

You didn't read the whole description, did you?

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

Re: [RFC][PATCH v2] hwmon: add support for Sensirion SHTC1 sensor

[Guenter Roeck]

On 05/05/2014 07:01 PM, Tomas Pop wrote:

Hi Guenter,

Thanks a lot for comments and patience - with the testing you are right,
I'm still waiting for board, where I will be able to run latest kernel
and have the chip wired in - sorry for this...



No problem. Please make sure that the driver has been tested with the real
chip before the final submission.

Just wondering - don't you have a little test board to make the i2c pins
more readily available ? Such a board could be connected to any i2c adapter
and/or to a mainboard which exposes i2c pins. That is usually how I test
the various sensors I am working with. You could even sell that to the
hobbyists :-).

Thanks,
Guenter

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

Re: [PATCH] ahci: unregister acpi notify handler when a ZPODD is unbound

[Aaron Lu]

On 05/01/2014 12:04 AM, Levente Kurusa wrote:
> When a ZPODD device is unbound via sysfs, the acpi notify handler
> is not removed. This causes panics as observed in Bug #74601. The

Ah...too bad, I forgot to consider this situation, thanks for tracking
this.

> panic only happens when the wake happens from outside the kernel
> (i.e. inserting media or pressing a button). Implement a new
> ahci_remove_one function which causes zpodd_exit to be called for all
> ZPODD devices on the unbound PCI device.
> 
> Signed-off-by: Levente Kurusa 
> ---
> 
> Hi,
> 
> I am not sure if the loop below is correct. Maybe there is a better
> solution to loop through all the devices which might use ZPODD?

I didn't find a proper place either. For hotplug, we did the zpodd_exit
at ata_scsi_handle_link_detach. But for host controller pci device
removal, we used scsi_remove_host in ata_port_detach and there is no
place to add the zpodd_exit for a to-be-removed scsi device...

Looks like we can only iterate the ata devices and call zpodd_exit
explicitly for them if they are zpodd devices. Instead of adding a new
remove callback, what about just embed that into the ata_port_detach
like the following example?


diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 943cc8b83e59..43652da6fea6 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6314,6 +6314,8 @@ int ata_host_activate(struct ata_host *host, int irq,
 static void ata_port_detach(struct ata_port *ap)
 {
unsigned long flags;
+   struct ata_link *link;
+   struct ata_device *dev;
 
if (!ap->ops->error_handler)
goto skip_eh;
@@ -6333,6 +6335,13 @@ static void ata_port_detach(struct ata_port *ap)
cancel_delayed_work_sync(>hotplug_task);
 
  skip_eh:
+   /* clean up zpodd related stuffs on port removal */
+   ata_for_each_link(link, ap, HOST_FIRST) {
+   ata_for_each_dev(dev, link, ALL) {
+   if (zpodd_dev_enabled(dev))
+   zpodd_exit(dev);
+   }
+   }
if (ap->pmp_link) {
int i;
for (i = 0; i < SATA_PMP_MAX_PORTS; i++)

Thanks,
Aaron

> 
> Thanks, Lev.
> 
>  drivers/ata/ahci.c | 21 +
>  drivers/ata/ahci.h |  4 
>  drivers/ata/libata-zpodd.c |  1 +
>  3 files changed, 26 insertions(+)
> 
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 5a0bf8e..6d92bc9 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -475,12 +475,33 @@ static const struct pci_device_id ahci_pci_tbl[] = {
>   { } /* terminate list */
>  };
>  
> +#ifdef CONFIG_SATA_ZPODD
> +void ahci_remove_one(struct pci_dev *pdev)
> +{
> + struct ata_host *host = pci_get_drvdata(pdev);
> + struct ata_link *link;
> + struct ata_device *dev;
> + int i;
> +
> + for (i = 0; i < host->n_ports; i++)
> + ata_for_each_link(link, host->ports[i], HOST_FIRST)
> + ata_for_each_dev(dev, link, ALL)
> + if (dev->zpodd)
> + zpodd_exit(dev);
> +
> + ata_pci_remove_one(pdev);
> +}
> +#endif
>  
>  static struct pci_driver ahci_pci_driver = {
>   .name   = DRV_NAME,
>   .id_table   = ahci_pci_tbl,
>   .probe  = ahci_init_one,
> +#ifdef CONFIG_SATA_ZPODD
> + .remove = ahci_remove_one,
> +#else
>   .remove = ata_pci_remove_one,
> +#endif
>  #ifdef CONFIG_PM
>   .suspend= ahci_pci_device_suspend,
>   .resume = ahci_pci_device_resume,
> diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
> index 51af275..87e4e6d 100644
> --- a/drivers/ata/ahci.h
> +++ b/drivers/ata/ahci.h
> @@ -383,6 +383,10 @@ void ahci_print_info(struct ata_host *host, const char 
> *scc_s);
>  int ahci_host_activate(struct ata_host *host, int irq, unsigned int n_msis);
>  void ahci_error_handler(struct ata_port *ap);
>  
> +#ifdef CONFIG_SATA_ZPODD
> +extern void zpodd_exit(struct ata_device *dev);
> +#endif /* CONFIG_SATA_ZPODD */
> +
>  static inline void __iomem *__ahci_port_base(struct ata_host *host,
>unsigned int port_no)
>  {
> diff --git a/drivers/ata/libata-zpodd.c b/drivers/ata/libata-zpodd.c
> index f3a65a3..fe66949 100644
> --- a/drivers/ata/libata-zpodd.c
> +++ b/drivers/ata/libata-zpodd.c
> @@ -281,3 +281,4 @@ void zpodd_exit(struct ata_device *dev)
>   kfree(dev->zpodd);
>   dev->zpodd = NULL;
>  }
> +EXPORT_SYMBOL_GPL(zpodd_exit);
> 

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

Re: [PATCH 19/24] net, diet: Make RPS configurable

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:26:08 -0700

> Multiple receive queues are not needed on small systems,
> so allow disabling them.

It's only enabled with SMP...

I'm really totally, and completely, convinced that you wrote this
entire patch series with your brain turned off.

I'm not applying any patch in this series Andi, come back when
you have something specific and small and reasonable to discuss,
rather than this huge patch bomb of total and complete crap.

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

Re: [PATCH 09/24] net, diet: Make ethtool optional

[Andi Kleen]

On Mon, May 05, 2014 at 11:11:40PM -0400, David Miller wrote:
> From: Andi Kleen 
> Date: Mon,  5 May 2014 15:25:58 -0700
> 
> > Small embedded systems don't need ethtool, so make it optional.
> 
> You can't do anything non-trivial with an ethernet device without
> ethtool.

You can configure the IP address and transmit and receive packets,
and that is all a small embedded system is ever interested in.

Remember these systems don't have a shell, they just run a 
single application that only does one thing.

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

Re: [PATCH 18/24] net, diet: Make raw sockets optional

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:26:07 -0700

> Not really needed on small embedded systems.  Saves about 5k text,
> more with IPv6.

Sorry, you can't have half a functioning ipv4 stack.

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

Re: [PATCH 08/24] net, diet: Make TCP metrics optional

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:25:57 -0700

> This is all the code that saves connection information
> between different sockets. Not really essential for
> small systems.

It is absolutely essential unless you want poor performance
of TCP connections.

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

Re: [PATCH 05/24] net, diet: Default to small TCP hash tables on small kernels

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:25:54 -0700

> From: Andi Kleen 
> 
> Signed-off-by: Andi Kleen 

Same comment as per other hash table reductions, this doesn't
make any sense even for the claimed goal.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/24] net, diet: Make ethtool optional

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:25:58 -0700

> Small embedded systems don't need ethtool, so make it optional.

You can't do anything non-trivial with an ethernet device without
ethtool.

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

Re: [PATCH 12/24] net, diet: Make rtnetlink optional

[Andi Kleen]

> The moment one of these "small" systems, or whatever you want to call
> it, tries to use any feature added to device configuration in the last
> 20 years ioctl doesn't cut it.

They will simply not use all that complexity ever, 400k is simply prohibitive
with 2MB.

If you want to keep netlink what would you remove instead?

-Andi

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

Re: [PATCH 06/24] net, diet: Use small UDP hash tables on small kernels

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:25:55 -0700

> From: Andi Kleen 
> 
> UDP has two hash tables, for UDP and UDP lite. Default
> them to 16 entries each on small kernels. This can be
> still overriden on the command line.
> 
> Signed-off-by: Andi Kleen 

Likewise, if you make it too small, overrunning the machine
is way too easy.  Maybe it's even more important in a lower
powered machine than a high powered one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/24] net, diet: Make LPF filter optional

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:25:59 -0700

> From: Andi Kleen 
> 
> Small systems don't need the LPF filter, so make it all
> optional
> 
> Saves about 4K text
> 
>text  data bss dec hex filename
>  483545 19371   13480  516396   7e12c net/built-in.o-wo-filter
>  487675 19275   13480  520430   7f0ee net/built-in.o-with-filter
> 
> Signed-off-by: Andi Kleen 

I think you highly underestimate how much "small systems" use
packet capturing and thus BPF.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/24] net, diet: Make FIB hash tables smaller with CONFIG_BASE_SMALL

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:25:53 -0700

> From: Andi Kleen 
> 
> Just make the FIB hash tables much smaller for small
> kernel.
> 
> Signed-off-by: Andi Kleen 

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

Re: [PATCH 21/24] net, diet: Make packet tpacket/mmap/fanout/rings optional

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:26:10 -0700

> From: Andi Kleen 
> 
> Many DHCP clients need basic packet sockets, but they don't need
> the fancy zero copy packet capture code, like tpacket, mmap, rings,
> fanouts. This is quite substantial code, so it's worthwhile to
> make it optional
> 
> Worth nearly 10k code.
> 
>text  data bss dec hex filename
>  952827 71874   25352 1050053  1005c5 net/built-in.o-with-packet-mmap
>  943211 71810   25352 1040373   fdff5 net/built-in.o-wo-packet-mmap
> 
> Signed-off-by: Andi Kleen 

Sorry, I'm not applying this either.

Small systems use packet generation and reception tools commonly, and
the only sane way to do so is with tpacket.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 22/24] net, diet: Support simpler routing table

[Andi Kleen]

On Mon, May 05, 2014 at 11:02:59PM -0400, David Miller wrote:
> From: Andi Kleen 
> Date: Mon,  5 May 2014 15:26:11 -0700
> 
> > Add an optional fib_list that uses a simple list to store routes.
> > This is suitable for single homed client system which typically
> > have only a handful of routes.
> 
> Sorry I'm not applying this.
> 
> We had two routing table implementations for some time and it sucked,
> it meant two code paths and two places for bugs to hide.

FWIW it seems to me the trie code is very stable, there doesn't
seem to be any big changes in a long time.

> 
> I want only one data structure which does the job well, and we have
> that now.

I don't see any good way to slim the trie code down. Do you?

It's just inherently complex. Yes on many systems it's a good thing,
and the complexity is justified,
but on the tiny systems the bloat and code size just hurts.

If we can't get the bloat down these users will just desert us to lwip ...

-Andi

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

Re: [PATCH 12/24] net, diet: Make rtnetlink optional

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:26:01 -0700

> From: Andi Kleen 
> 
> Small systems can use ioctl/ifconfig for routing and
> interface configuration. Make rtnetlink optional
> This saves ~29k without LTO, more with LTO.
> 
>textdata bss dec hex filename
>  483545   19371   13480  516396   7e12c net/built-in.o-with-rtnetlink
>  454365   19275   12936  486576   76cb0 net/built-in.o-wo-rtnetlink
> 
> Signed-off-by: Andi Kleen 

Andi, I've had about enough with this patch series.

We have moved several tools to only use netlink because it's
the only extensible facility, and we are not looking back.

The moment one of these "small" systems, or whatever you want to call
it, tries to use any feature added to device configuration in the last
20 years ioctl doesn't cut it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 14/24] net, diet: Make MIB statistics collections depend on PROC_FS

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:26:03 -0700

> From: Andi Kleen 
> 
> When PROC_FS is not compiled in we don't need the statistics
> gathering code, as the only way to see the output is through
> /proc. Saves about 5k text, likely more in dynamic memory.
> 
>textdata bss dec hex filename
>  3863028993   12564  407859   63933 net/built-in.o-with-mib
>  3815428933   12564  403039   6265f net/built-in.o-wo-mib
> 
> Signed-off-by: Andi Kleen 

Congratulations, you just broke ipv6 device address netlink
dumps amongst other things.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 16/24] net, diet: Make TCP fastopen optional

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:26:05 -0700

> Make TCP fast open a config option. It's not really needed
> on small systems. By itself it saves about 3k text,

It's for the sake of the remote service not the local client,
sorry I'm not applying this, it's a facility we want to be
ubiquitous and in widespread use on as many systems as possible.

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

Re: [PATCH 07/24] net, diet: Make ping sockets optional

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:25:56 -0700

> From: Andi Kleen 
> 
> This saves about 6k text/data. ping still works fine using raw
> sockets like it always did.
> 
>text  data bss dec hex filename
>  268128 115557872  287555   46343 net/ipv4/built-in.o-noping
>  273610 118438176  293629   47afd net/ipv4/built-in.o-ping
> 
> Signed-off-by: Andi Kleen 

Sorry, not applying this, it's been discussed already, and it's
exactly small'ish systems that want this facility.

We want to move away from raw sockets, and making this optional
is not going to help us move forward down that path.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 13/24] net, diet: Make GRO offload optional

[Andi Kleen]

On Mon, May 05, 2014 at 11:01:18PM -0400, David Miller wrote:
> From: Andi Kleen 
> Date: Mon,  5 May 2014 15:26:02 -0700
> 
> > It's not needed on small systems.
> 
> On the contrary, I would expect the performance gains from
> batching the packet receive path to be even larger on slow
> small computers.

Ok I will rephrase it. The issue is really only the text size.

-Andi

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

Re: [PATCH 22/24] net, diet: Support simpler routing table

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:26:11 -0700

> Add an optional fib_list that uses a simple list to store routes.
> This is suitable for single homed client system which typically
> have only a handful of routes.

Sorry I'm not applying this.

We had two routing table implementations for some time and it sucked,
it meant two code paths and two places for bugs to hide.

I want only one data structure which does the job well, and we have
that now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/24] net, diet: Reduce netdev name hash table for CONFIG_BASE_SMALL

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:25:50 -0700

> Small systems typically only have two network devices, so use
> hash shift 2.

Maybe in terms of physical interfaces, but they may also have lots of
software interfaces.

Sorry, this doesn't make any sense, I'm not applying this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 13/24] net, diet: Make GRO offload optional

[David Miller]

From: Andi Kleen 
Date: Mon,  5 May 2014 15:26:02 -0700

> It's not needed on small systems.

On the contrary, I would expect the performance gains from
batching the packet receive path to be even larger on slow
small computers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 05/20] usb: host: xhci-plat: Add clocks support

[Felipe Balbi]

On Tue, May 06, 2014 at 02:14:00AM +0200, Gregory CLEMENT wrote:
> @@ -118,7 +158,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  
>   hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
>   if (!hcd)
> - return -ENOMEM;
> + ret = -ENOMEM;

regression

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] sched: Distinguish sched_wakeup event when wake up a task which did schedule out or not.

[Dongsheng Yang]

ttwu_do_wakeup() is called when the task's state is switched back to
TASK_RUNNING, whether or not the task actually scheduled out. Tracing
the wakeup event when the task never scheduled out is quite confusing.

This patch take the use of 'success' parameter in sched_wakeup tracepoint,
to indicate that the task we are waking up did schedule out or just
change its state to TASK_RUNNING.

success is true:
task was out of run queue and sleeping, we are really wake it up.
success is false:
taks was on run queue all the time and we just change its state
to TASK_RUNNING.

Signed-off-by: Dongsheng Yang 
---
 kernel/sched/core.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9074c6d..14b9fe4 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1420,6 +1420,7 @@ static void ttwu_activate(struct rq *rq, struct 
task_struct *p, int en_flags)
 {
activate_task(rq, p, en_flags);
p->on_rq = 1;
+   trace_sched_wakeup(p, true);
 
/* if a worker is waking up, notify workqueue */
if (p->flags & PF_WQ_WORKER)
@@ -1433,7 +1434,6 @@ static void
 ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
 {
check_preempt_curr(rq, p, wake_flags);
-   trace_sched_wakeup(p, true);
 
p->state = TASK_RUNNING;
 #ifdef CONFIG_SMP
@@ -1481,6 +1481,7 @@ static int ttwu_remote(struct task_struct *p, int 
wake_flags)
if (p->on_rq) {
/* check_preempt_curr() may use rq clock */
update_rq_clock(rq);
+   trace_sched_wakeup(p, false);
ttwu_do_wakeup(rq, p, wake_flags);
ret = 1;
}
@@ -1675,6 +1676,8 @@ static void try_to_wake_up_local(struct task_struct *p)
 
if (!p->on_rq)
ttwu_activate(rq, p, ENQUEUE_WAKEUP);
+   else
+   trace_sched_wakeup(p, false);
 
ttwu_do_wakeup(rq, p, 0);
ttwu_stat(p, smp_processor_id(), 0);
-- 
1.8.2.1

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

Re: CPU performance counters not working on big.LITTLE switcher

[Nicolas Pitre]

On Mon, 5 May 2014, Sonny Rao wrote:

> Hi, we have the problem today that cpu based performance counters don't
> work when we're using the big.LITTLE switcher on Exynos 5420, and it
> doesn't look like code exists to deal with this in the switcher.
> 
> As it stands right now, if you put an A-15 or A-7 PMU node into your
> device-tree on an bl_switcher system it's very broken.  At the minimum, I
> think it should disable performance counters until there's some kind of
> proper implementation.
> 
> I looked into trying to make this work, but it turned out to not be as
> simple as just context switching counters from A-15 to A-7.  The biggest
> problem is that the PMUs are not architecturally compatible.  There are
> different events and differing numbers of counters on these two cores.
>  There's also the tangential issue of representing this in the device tree,
> but that's far less important.
> 
> My guess as to how to fix this is to create an "architectural" PMU which
> contains the intersection of the two performance monitor units with the
> minimum number of counters supported by either core (which in this case
> looks to be 4 on the A7).  However, I don't really have the bandwidth to
> work on this at  the moment.  I was mostly wondering, have other people run
> into this limitation and is there any sort of plan to work on it?

The Linaro kernel release from a year ago or so contained a hack to make 
PMUs available and cope with the switcher.

However, the ultimate solution is to add multi-PMU support in a generic 
way to the kernel and let user space see both A15 and A7 counters.  It 
is then up to the analysis tools to consolidate (some of) them if 
wanted.  And this would work whether the switcher is used, or even when 
the scheduler has learned to do proper task placement for b.L systems 
where tasks may migrate across clusters.

Someone at ARM indicated they'd be working on the multi-PMU support if I 
remember correctly.  For that reason, Linaro stopped maintaining the 
initial hack since it was a lot of work to keep it working on top of 
later kernels and a better solution was coming anyway.  I don't know 
what the status of that work is though.


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

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP & X550CA

[poma]

On 27.04.2014 00:12, poma wrote:
> Need to set wapf to 4 for ASUSTeK COMPUTER INC. X75VBP & X550CA, so that the 
> wireless network adapter is enabled.
> 
> References:
> - asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP
> http://marc.info/?l=linux-kernel=139819918125110
> - Ath9k WiFi now disabled by radio killswitch
> https://bugzilla.redhat.com/show_bug.cgi?id=1089731
> 
> Reported-by: poma 
> Reported-by: Andreas Utterberg 
> Tested-by: poma 
> Tested-by: Andreas Utterberg 
> Cc: Fedora kernel development 
> Cc: Andreas Utterberg 
> Cc: Josh Boyer 
> Cc: Stanislaw Gruszka 
> 
> ---
>  drivers/platform/x86/asus-nb-wmi.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/platform/x86/asus-nb-wmi.c 
> b/drivers/platform/x86/asus-nb-wmi.c
> index 563f59e..d3641e0 100644
> --- a/drivers/platform/x86/asus-nb-wmi.c
> +++ b/drivers/platform/x86/asus-nb-wmi.c
> @@ -137,6 +137,15 @@ static struct dmi_system_id asus_quirks[] = {
>   },
>   {
>   .callback = dmi_matched,
> + .ident = "ASUSTeK COMPUTER INC. X550CA",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "X550CA"),
> + },
> + .driver_data = _asus_x401u,
> + },
> + {
> + .callback = dmi_matched,
>   .ident = "ASUSTeK COMPUTER INC. X55A",
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> @@ -182,6 +191,15 @@ static struct dmi_system_id asus_quirks[] = {
>   },
>   {
>   .callback = dmi_matched,
> + .ident = "ASUSTeK COMPUTER INC. X75VBP",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "X75VBP"),
> + },
> + .driver_data = _asus_x401u,
> + },
> + {
> + .callback = dmi_matched,
>   .ident = "ASUSTeK COMPUTER INC. 1015E",
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> 

Corentin, care to pick up this one?
https://bugzilla.redhat.com/attachment.cgi?id=892751


poma




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

Re: [PATCH] DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t

[James Bottomley]

On Mon, 2014-05-05 at 17:01 -0600, Bjorn Helgaas wrote:
> On Fri, May 02, 2014 at 10:42:18AM +0200, Arnd Bergmann wrote:

> > I don't know about NCR_Q720, but all others are only used on machines
> > where physical addresses and bus addresses are in the same space.
> 
> In general, the driver doesn't know whether physical and bus addresses
> are in the same space.  At least, I *hope* it doesn't have to know,
> because it can't be very generic if it does.

The API was designed for the case where the memory resides on a PCI
device (the Q720 case), the card config gives us a bus address, but if
the system has an IOMMU, we'd have to do a dma_map of the entire region
to set up the IOMMU before we can touch it.  The address it gets back
from the dma_map (the dma_addr_t handle for the IOMMU mapping) is what
we pass into dma_declare_coherent_memory().  The reason it does an
ioremap is because this IOMMU mapped address is now physical to the CPU
and we want to make the region available to virtual space.  Essentially
the memory the allocator hands out behaves as proper virtual memory but
it's backed by physical memory on the card behind the PCI bridge.

I'm still not that fussed about the difference between phys_addr_t and
dma_addr_t, but if the cookie returned from a dma_map is a dma_addr_t
then that's what dma_declare_coherent_memory() should use.  If it's a
phys_addr_t, then likewise.

James

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

RE: [PATCH] arm: dts: exynos4: add missing pinctrls for I2C controllers

[Kukjin Kim]

Tomasz Figa wrote:
> 
> Hi Tomasz,
> 
> On 16.04.2014 14:40, Tomasz Stanislawski wrote:
> > This patch adds missing pinctrls for I2C controllers 2-7.
> >
> > Signed-off-by: Tomasz Stanislawski 
> > ---
> >   arch/arm/boot/dts/exynos4.dtsi |   12 
> >   1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4.dtsi
> b/arch/arm/boot/dts/exynos4.dtsi
> > index 0401f4d..288aa81 100644
> > --- a/arch/arm/boot/dts/exynos4.dtsi
> > +++ b/arch/arm/boot/dts/exynos4.dtsi
> > @@ -357,6 +357,8 @@
> > interrupts = <0 60 0>;
> > clocks = < CLK_I2C2>;
> > clock-names = "i2c";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_bus>;
> > status = "disabled";
> > };
> >
> > @@ -368,6 +370,8 @@
> > interrupts = <0 61 0>;
> > clocks = < CLK_I2C3>;
> > clock-names = "i2c";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_bus>;
> > status = "disabled";
> > };
> >
> > @@ -379,6 +383,8 @@
> > interrupts = <0 62 0>;
> > clocks = < CLK_I2C4>;
> > clock-names = "i2c";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_bus>;
> > status = "disabled";
> > };
> >
> > @@ -390,6 +396,8 @@
> > interrupts = <0 63 0>;
> > clocks = < CLK_I2C5>;
> > clock-names = "i2c";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_bus>;
> > status = "disabled";
> > };
> >
> > @@ -401,6 +409,8 @@
> > interrupts = <0 64 0>;
> > clocks = < CLK_I2C6>;
> > clock-names = "i2c";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_bus>;
> > status = "disabled";
> > };
> >
> > @@ -412,6 +422,8 @@
> > interrupts = <0 65 0>;
> > clocks = < CLK_I2C7>;
> > clock-names = "i2c";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_bus>;
> > status = "disabled";
> > };
> >
> >
> 
> Reviewed-by: Tomasz Figa 
> 
Applied, thanks.

- Kukjin

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

RE: [PATCH] arm: dts: exynos4412-trats2: rename alias for i2c_ak8975 label

[Kukjin Kim]

Tomasz Figa wrote:
> 
> Hi Tomasz,
> 
> On 15.04.2014 16:25, Tomasz Stanislawski wrote:
> > The i2c_ak8975 controler uses label i2c8.
> > This alias is already used for I2C controller 8 defined
> > in file arch/arm/boot/dts/exynos4.dtsi.
> >
> > This patch renames a label for i2c_ak8975 to i2c9.
> >
> > Signed-off-by: Tomasz Stanislawski 
> > ---
> >   arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> > index c16b315..5add765 100644
> > --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> > +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> > @@ -20,7 +20,7 @@
> > compatible = "samsung,trats2", "samsung,exynos4412",
> "samsung,exynos4";
> >
> > aliases {
> > -   i2c8 = _ak8975;
> > +   i2c9 = _ak8975;
> > };
> >
> > memory {
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> Seems reasonable.
> 
> Reviewed-by: Tomasz Figa 
> 
Applied, thanks.

- Kukjin

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

Re: [tip:locking/core] rwsem: Add comments to explain the meaning of the rwsem's count field

[Davidlohr Bueso]

On Mon, 2014-05-05 at 15:51 -0700, Tim Chen wrote:
> On Mon, 2014-05-05 at 20:27 +0200, Ingo Molnar wrote:
> 
> > > Ingo,
> > > 
> > > The delta patch is included below.  Thinking a bit more,
> > > the state diagram approach is not necessarily less verbose
> > > because the state is a tuple (count, wait queue state).
> > > After enumerating the states, we may wind up with very similar
> > > to what I have.
> > 
> > Could we at least try with one diagram and see how it goes?
> > 
> 
> I've tried (see below).  But I don't like how it came out :(

And quite nice, thanks for doing this. Personally, however, I much
prefer the already applied patch to this approach.

Thanks,
Davidlohr

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

Re: [PATCH] sched: Move the wakeup tracepoint from ttwu_do_wakeup() to ttwu_activate().

[Dongsheng Yang]

On 05/06/2014 11:06 AM, Steven Rostedt wrote:

On Tue, 6 May 2014 09:19:51 +0900
Dongsheng Yang  wrote:

I wonder if we should have the event, or way to distinguish the
difference. Hmm, there's that "success" parameter in the tracepoint.
Could we possible be able to trace events where the success is true
only if it was actually waking the event, and false otherwise?

Having the sched_wakeup trace event show you when something woke the
task up may still be useful information. For example, you add yourself
to a wait queue and want to see the "wakeup". If we only show it for
tasks that really woke up then we wont see it for those that added
itself to a waitqueue but was "woken" before it could schedule out.

The original sched_wakeup did this, but with the ttwu rewrite, it was
lost.


Ha, got what you mean. Yes, we can take the use of success in sched_wakeup
event.


Something like below?

-- Steve

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 268a45e..e583989 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1404,6 +1404,7 @@ static void ttwu_activate(struct rq *rq, struct 
task_struct *p, int en_flags)
  {
activate_task(rq, p, en_flags);
p->on_rq = 1;
+   trace_sched_wakeup(p, true);
  
  	/* if a worker is waking up, notify workqueue */

if (p->flags & PF_WQ_WORKER)
@@ -1417,7 +1418,6 @@ static void
  ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
  {
check_preempt_curr(rq, p, wake_flags);
-   trace_sched_wakeup(p, true);
  
  	p->state = TASK_RUNNING;

  #ifdef CONFIG_SMP
@@ -1662,6 +1662,8 @@ static void try_to_wake_up_local(struct task_struct *p)
  
  	if (!p->on_rq)

ttwu_activate(rq, p, ENQUEUE_WAKEUP);
+   else
+   trace_sched_wakeup(p, false);


Also we should add a false trace point in ttwu_remote().
  
  	ttwu_do_wakeup(rq, p, 0);

ttwu_stat(p, smp_processor_id(), 0);


Thanx steven, I will send a new patch as you suggested here.

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



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

Re: [PATCH] rfcomm: Convert spinlocks into mutexes

[Marcel Holtmann]

Hi Libor,

> Enabling CONFIG_DEBUG_ATOMIC_SLEEP has shown that some rfcomm functions
> acquiring spinlocks call sleeping locks further in the chain.  Converting
> the offending spinlocks into mutexes makes sleeping safe.
> 
> Signed-off-by: Libor Pechacek 
> ---
> include/net/bluetooth/rfcomm.h |  6 +++---
> net/bluetooth/rfcomm/core.c|  2 +-
> net/bluetooth/rfcomm/tty.c | 20 ++--
> 3 files changed, 14 insertions(+), 14 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

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

Re: [PATCH 3/4] plist: add plist_rotate

[Steven Rostedt]

On Fri,  2 May 2014 15:02:29 -0400
Dan Streetman  wrote:

> Add plist_rotate(), which moves the specified plist_node after
> all other same-priority plist_nodes in the list.

This is a little confusing? You mean it takes a plist_node from a plist
and simply moves it to the end of the list of all other nodes of the
same priority? Kind of like what a sched_yield() would do with a
SCHED_FIFO task? I wonder if we should call this "plist_yield()" then?

> 
> This is needed by swap, which has a plist of swap_info_structs
> and needs to use each same-priority swap_info_struct equally.

"needs to use each same-priority swap_info_struct equally"

-ENOCOMPUTE

> 
> Also add plist_test_rotate() test function, for use by plist_test()
> to test plist_rotate() function.
> 
> Signed-off-by: Dan Streetman 
> Cc: Mel Gorman 
> Cc: Paul Gortmaker 
> Cc: Steven Rostedt 
> Cc: Thomas Gleixner 
> 
> ---
> 
> This patch is new to this patch set, and it's required by the next patch,
> which needs a way to move a plist entry to the end of all following
> same-priority entries.  This is possible to do manually instead of adding
> a new plist function, but having a common plist function instead of code
> specific only to swap seems preferable.
> 
>  include/linux/plist.h |  2 ++
>  lib/plist.c   | 48 
>  2 files changed, 50 insertions(+)
> 
> diff --git a/include/linux/plist.h b/include/linux/plist.h
> index c815491..06e6925 100644
> --- a/include/linux/plist.h
> +++ b/include/linux/plist.h
> @@ -141,6 +141,8 @@ static inline void plist_node_init(struct plist_node 
> *node, int prio)
>  extern void plist_add(struct plist_node *node, struct plist_head *head);
>  extern void plist_del(struct plist_node *node, struct plist_head *head);
>  
> +extern void plist_rotate(struct plist_node *node, struct plist_head *head);
> +
>  /**
>   * plist_for_each - iterate over the plist
>   * @pos: the type * to use as a loop counter
> diff --git a/lib/plist.c b/lib/plist.c
> index 1ebc95f..a8b54e5 100644
> --- a/lib/plist.c
> +++ b/lib/plist.c
> @@ -134,6 +134,42 @@ void plist_del(struct plist_node *node, struct 
> plist_head *head)
>   plist_check_head(head);
>  }
>  
> +/**
> + * plist_rotate - Rotate @node to end of same-prio entries.
> + *
> + * @node: plist_node pointer - entry to be moved
> + * @head: plist_head pointer - list head
> + */
> +void plist_rotate(struct plist_node *node, struct plist_head *head)
> +{
> + struct plist_node *next;
> + struct list_head *next_node_list = >node_list;

Naming convention should be the same as plist_add() and call this
node_next instead of next_node_list.

-- Steve

> +
> + plist_check_head(head);
> + BUG_ON(plist_head_empty(head));
> + BUG_ON(plist_node_empty(node));
> +
> + if (node == plist_last(head))
> + return;
> +
> + next = plist_next(node);
> +
> + if (node->prio != next->prio)
> + return;
> +
> + plist_del(node, head);
> +
> + plist_for_each_continue(next, head) {
> + if (node->prio != next->prio) {
> + next_node_list = >node_list;
> + break;
> + }
> + }
> + list_add_tail(>node_list, next_node_list);
> +
> + plist_check_head(head);
> +}
> +
>  #ifdef CONFIG_DEBUG_PI_LIST
>  #include 
>  #include 
> @@ -170,6 +206,14 @@ static void __init plist_test_check(int nr_expect)
>   BUG_ON(prio_pos->prio_list.next != >prio_list);
>  }
>  
> +static void __init plist_test_rotate(struct plist_node *node)
> +{
> + plist_rotate(node, _head);
> +
> + if (node != plist_last(_head))
> + BUG_ON(node->prio == plist_next(node)->prio);
> +}
> +
>  static int  __init plist_test(void)
>  {
>   int nr_expect = 0, i, loop;
> @@ -193,6 +237,10 @@ static int  __init plist_test(void)
>   nr_expect--;
>   }
>   plist_test_check(nr_expect);
> + if (!plist_node_empty(test_node + i)) {
> + plist_test_rotate(test_node + i);
> + plist_test_check(nr_expect);
> + }
>   }
>  
>   for (i = 0; i < ARRAY_SIZE(test_node); i++) {

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

[PATCH v3] dma: imx-sdma: add support for sdma memory copy

[Robin Gong]

add "device_prep_dma_memcpy" and "device_prep_dma_sg" for memory copy by sdma.

Signed-off-by: Robin Gong 

---
change:
--v3:
  1. remove redundant check for bus width

--v2:
  1. correct some printk format, such as %pad for dma_addr_t
  2. split duplicated code in prep_dma_memcpy and prep_dma_sg to make code 
clean.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c |  250 ---
 1 files changed, 191 insertions(+), 59 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 4e79183..9abc164 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -229,6 +229,7 @@ struct sdma_context_data {
 } __attribute__ ((packed));
 
 #define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
+#define SDMA_BD_MAX_CNT(0xfffc) /* align with 4 bytes */
 
 struct sdma_engine;
 
@@ -260,6 +261,7 @@ struct sdma_channel {
unsigned intpc_from_device, pc_to_device;
unsigned long   flags;
dma_addr_t  per_address;
+   unsigned intpc_to_pc;
unsigned long   event_mask[2];
unsigned long   watermark_level;
u32 shp_addr, per_addr;
@@ -694,6 +696,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 
sdmac->pc_from_device = 0;
sdmac->pc_to_device = 0;
+   sdmac->pc_to_pc = 0;
 
switch (peripheral_type) {
case IMX_DMATYPE_MEMORY:
@@ -763,6 +766,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 
sdmac->pc_from_device = per_2_emi;
sdmac->pc_to_device = emi_2_per;
+   sdmac->pc_to_pc = emi_2_emi;
 }
 
 static int sdma_load_context(struct sdma_channel *sdmac)
@@ -775,11 +779,12 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int ret;
unsigned long flags;
 
-   if (sdmac->direction == DMA_DEV_TO_MEM) {
+   if (sdmac->direction == DMA_DEV_TO_MEM)
load_address = sdmac->pc_from_device;
-   } else {
+   else if (sdmac->direction == DMA_MEM_TO_MEM)
+   load_address = sdmac->pc_to_pc;
+   else
load_address = sdmac->pc_to_device;
-   }
 
if (load_address < 0)
return load_address;
@@ -1010,99 +1015,203 @@ static void sdma_free_chan_resources(struct dma_chan 
*chan)
clk_disable(sdma->clk_ahb);
 }
 
-static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
-   struct dma_chan *chan, struct scatterlist *sgl,
-   unsigned int sg_len, enum dma_transfer_direction direction,
-   unsigned long flags, void *context)
+static int sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction)
+{
+   int ret = 0;
+
+   sdmac->status = DMA_IN_PROGRESS;
+   sdmac->buf_tail = 0;
+   sdmac->flags = 0;
+   sdmac->direction = direction;
+
+   ret = sdma_load_context(sdmac);
+   if (ret)
+   return ret;
+
+   sdmac->chn_count = 0;
+
+   return ret;
+}
+
+static int check_bd_buswidth(struct sdma_buffer_descriptor *bd,
+struct sdma_channel *sdmac, int count,
+dma_addr_t dma_dst, dma_addr_t dma_src)
+{
+   int ret = 0;
+
+   switch (sdmac->word_size) {
+   case DMA_SLAVE_BUSWIDTH_4_BYTES:
+   bd->mode.command = 0;
+   if ((count | dma_dst | dma_src) & 3)
+   ret = -EINVAL;
+   break;
+   case DMA_SLAVE_BUSWIDTH_2_BYTES:
+   bd->mode.command = 2;
+   if ((count | dma_dst | dma_src) & 1)
+   ret = -EINVAL;
+   break;
+   case DMA_SLAVE_BUSWIDTH_1_BYTE:
+   bd->mode.command = 1;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return ret;
+}
+
+static struct dma_async_tx_descriptor *sdma_prep_memcpy(
+   struct dma_chan *chan, dma_addr_t dma_dst,
+   dma_addr_t dma_src, size_t len, unsigned long flags)
 {
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
-   int ret, i, count;
int channel = sdmac->channel;
-   struct scatterlist *sg;
+   size_t count;
+   int i = 0, param;
+   struct sdma_buffer_descriptor *bd;
 
-   if (sdmac->status == DMA_IN_PROGRESS)
+   if (!chan || !len || sdmac->status == DMA_IN_PROGRESS)
return NULL;
-   sdmac->status = DMA_IN_PROGRESS;
 
-   sdmac->flags = 0;
-
-   sdmac->buf_tail = 0;
+   if (len >= NUM_BD * SDMA_BD_MAX_CNT) {
+   dev_err(sdma->dev, "channel%d: maximum bytes exceeded:%zu > 
%d\n"
+   , channel, len, NUM_BD * SDMA_BD_MAX_CNT);
+   goto err_out;
+   }
 
-   dev_dbg(sdma->dev, "setting 

Re: [PATCH] sched: Move the wakeup tracepoint from ttwu_do_wakeup() to ttwu_activate().

[Steven Rostedt]

On Tue, 6 May 2014 09:19:51 +0900
Dongsheng Yang  wrote:

> > tldr;
> 
> Yes, it is really lng, sorry for my terrible expression in english. :(

No problem. I can imagine the trouble of having to write change logs in
a language that is not your mother tongue.

> >
> > ttwu_do_wakeup() is called when the task's state is switched back to
> > TASK_RUNNING, whether or not the task actually scheduled out. Tracing
> > the wakeup event when the task never scheduled out is quite confusing.
> > It should only trace the task wake up if the task actually did go to
> > sleep. Move the tracepoint from ttwu_do_wakeup() to ttwu_activate()
> > where it is called only if the task is really woken up and not just
> > have its state changed.
> 
> Thanx for your kind comment here, it looks shorter and more clear to me.
> I will update my commit message with your suggestion.
> 
> Thank you very much! :)

I wonder if we should have the event, or way to distinguish the
difference. Hmm, there's that "success" parameter in the tracepoint.
Could we possible be able to trace events where the success is true
only if it was actually waking the event, and false otherwise?

Having the sched_wakeup trace event show you when something woke the
task up may still be useful information. For example, you add yourself
to a wait queue and want to see the "wakeup". If we only show it for
tasks that really woke up then we wont see it for those that added
itself to a waitqueue but was "woken" before it could schedule out.

The original sched_wakeup did this, but with the ttwu rewrite, it was
lost.

Something like below?

-- Steve

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 268a45e..e583989 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1404,6 +1404,7 @@ static void ttwu_activate(struct rq *rq, struct 
task_struct *p, int en_flags)
 {
activate_task(rq, p, en_flags);
p->on_rq = 1;
+   trace_sched_wakeup(p, true);
 
/* if a worker is waking up, notify workqueue */
if (p->flags & PF_WQ_WORKER)
@@ -1417,7 +1418,6 @@ static void
 ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
 {
check_preempt_curr(rq, p, wake_flags);
-   trace_sched_wakeup(p, true);
 
p->state = TASK_RUNNING;
 #ifdef CONFIG_SMP
@@ -1662,6 +1662,8 @@ static void try_to_wake_up_local(struct task_struct *p)
 
if (!p->on_rq)
ttwu_activate(rq, p, ENQUEUE_WAKEUP);
+   else
+   trace_sched_wakeup(p, false);
 
ttwu_do_wakeup(rq, p, 0);
ttwu_stat(p, smp_processor_id(), 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH v2] hwmon: add support for Sensirion SHTC1 sensor

[Tomas Pop]

Hi Guenter, 

Thanks a lot for comments and patience - with the testing you are right,
I'm still waiting for board, where I will be able to run latest kernel
and have the chip wired in - sorry for this...

Thanks, Tomas

On Mon, 2014-05-05 at 18:39 -0700, Guenter Roeck wrote:
> Hi Tomas,
> 
> On 05/05/2014 06:03 PM, Tomas Pop wrote:
> > Hi Guenter,
> >
> > Here is a corrected version, I tried to address your comments and I'm 
> > sending it
> > again with a kind request for comments - we will do some more extensive 
> > testing
> > before the final submission, but I would like to make the code as complete 
> > as
> > as possible before. Here is a list of changes to the previous version:
> >
> Comments below. But I don't think you tested this with real HW, did you ? :-)
> 
> > * positive, but incorrect return codes/lengths from i2c_mater_* are checked
> > * usleep_range used instead of msleep
> > * DEVICE_ATTR used instead of SENSOR_DEVICE_ATTR, ATTRIBITE_GROUPS used
> > * devm_hwmon_device_register_with_groups instead of 
> > devm_hwmon_device_register
> > * direct calls to sysfs_create_group and sysfs_create_group dropped
> > * shtc1_remove function dropped
> > * SHTW1 added to documentation and Kconfig
> > * documentation and formating updates/corrections
> >
> > I did re-compile with C=1 as suggested and it is clear.
> >
> > Patch was generated against kernel v3.15-rc3
> >
> > Thanks,
> > Tomas
> >
> > Signed-off-by: Tomas Pop 
> > ---
> >   Documentation/hwmon/shtc1   |  41 ++
> >   drivers/hwmon/Kconfig   |  10 ++
> >   drivers/hwmon/Makefile  |   1 +
> >   drivers/hwmon/shtc1.c   | 266 
> > 
> >   include/linux/platform_data/shtc1.h |  24 
> >   5 files changed, 342 insertions(+)
> >   create mode 100644 Documentation/hwmon/shtc1
> >   create mode 100644 drivers/hwmon/shtc1.c
> >   create mode 100644 include/linux/platform_data/shtc1.h
> >
> > diff --git a/Documentation/hwmon/shtc1 b/Documentation/hwmon/shtc1
> > new file mode 100644
> > index 000..47c9ed1
> > --- /dev/null
> > +++ b/Documentation/hwmon/shtc1
> > @@ -0,0 +1,41 @@
> > +Kernel driver shtc1
> > +===
> > +
> > +Supported chips:
> > +  * Sensirion SHTC1
> > +Prefix: 'shtc1'
> > +Addresses scanned: none
> > +Datasheet: Publicly available at the Sensirion website
> > +http://www.sensirion.com/file/datasheet_shtc1
> > +
> > +  * Sensirion SHTW1
> > +Prefix: 'shtc1'
> > +Addresses scanned: none
> > +Datasheet: Not publicly available
> > +
> > +Author:
> > +  Johannes Winkelmann 
> > +
> > +Description
> > +---
> > +
> > +This driver implements support for the Sensirion SHTC1 chip, a humidity and
> > +temperature sensor. Temperature is measured in degrees celsius, relative
> > +humidity is expressed as a percentage. Driver can be used as well for SHTW1
> > +chip, which has the same electrical interface.
> > +
> > +The device communicates with the I2C protocol. All sensors are set to I2C
> > +address 0x70. See Documentation/i2c/instantiating-devices for methods to
> > +instantiate the device.
> > +
> > +There are two options configurable by means of shtc1_platform_data:
> > +1. blocking (pull the I2C clock line down while performing the 
> > measurement) or
> > +   non-blocking mode. Blocking mode will guarantee the fastest result but
> > +   the I2C bus will be busy during that time.
> > +2. high or low accuracy. Using high accuracy is strongly recommended.
> > +
> > +sysfs-Interface
> > +---
> > +
> > +temp1_input - temperature input
> > +humidity1_input - humidity input
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index bc196f4..f95ba5b 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -1114,6 +1114,16 @@ config SENSORS_SHT21
> >   This driver can also be built as a module.  If so, the module
> >   will be called sht21.
> >
> > +config SENSORS_SHTC1
> > +   tristate "Sensiron humidity and temperature sensors. SHTC1 and compat."
> > +   depends on I2C
> > +   help
> > + If you say yes here you get support for the Sensiron SHTC1 and SHTW1
> > + humidity and temperature sensor.
> > +
> > + This driver can also be built as a module.  If so, the module
> > + will be called shtc1.
> > +
> >   config SENSORS_S3C
> > tristate "Samsung built-in ADC"
> > depends on S3C_ADC
> > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> > index c48f987..1cc5273 100644
> > --- a/drivers/hwmon/Makefile
> > +++ b/drivers/hwmon/Makefile
> > @@ -125,6 +125,7 @@ obj-$(CONFIG_SENSORS_SCH5627)   += sch5627.o
> >   obj-$(CONFIG_SENSORS_SCH5636) += sch5636.o
> >   obj-$(CONFIG_SENSORS_SHT15)   += sht15.o
> >   obj-$(CONFIG_SENSORS_SHT21)   += sht21.o
> > +obj-$(CONFIG_SENSORS_SHTC1)+= shtc1.o
> >   obj-$(CONFIG_SENSORS_SIS5595) += sis5595.o
> >   obj-$(CONFIG_SENSORS_SMM665)  += smm665.o
> >   

Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

[David Lang]

On Tue, 6 May 2014, Jiri Kosina wrote:


On Mon, 5 May 2014, David Lang wrote:


how would you know that all instances of the datastructure in memory
have= been touched? just because all tasks have run and are outside the
function in question doesn't tell you data structures have been
converted. You have n= o way of knowing when (or if) the next call to
the modified function will take place on any potential in-memory
structure.


The problem you are trying to avoid here is functions expecting to read
"v2" format of the data from memory, while there are still tasks that are
unpredictably writing "v1" format of the data to the memory.

There are several ways to attack this problem:

- stop the whole system, convert all the existing data structures to new
 format (which might potentially be non-trivial, mostly because you
 have to *know* where all the data structures have been allocated), apply
 patch, resume operation [ksplice, probably kpatch in future]
- restrict the data format to be backwards compatible [to be done
 manually during patch creation, currently what kGraft needs to do in
 such case]
- have a proxy code which can read both "v1" and "v2" formats, and writes
 back in the same format it has seen the data structure on input


doesn't this have the same problem of finding all the data?


- once all the *code* has been converted, it still has to understand "v1"
 and "v2", but it can now start writing out "v2" format only [possible
 with kGraft, not implemented in automated fashion]


which is a varient of the second one in that all the data needs to be tagged 
with a version so that it can be converted.


I don't see that 'stop the world' ends up being much better for this.

it does avoid any possibility of v1 code reading v2 data, but it doesn't help in 
avoiding v2 code reading v1 data some time (potentially much) later.


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

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

The truth is that sometimes it takes more than a few reboot for the bug to 
occur.

3.15.0-0.rc4.git0.1.fc21.i686+debug  FAILED
http://koji.fedoraproject.org/koji/buildinfo?buildID=515111
...
ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22
snd_hda_intel :00:07.0: Disabling MSI
snd_hda_intel :00:07.0: position_fix set to 1 for device 1458:a022
...
[ cut here ]
WARNING: CPU: 1 PID: 496 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped 
cacheline [cln=0x03012000]
Modules linked in: ip6t_rpfilter ip6t_REJECT xt_conntrack cfg80211 rfkill 
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat 
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security 
iptable_raw snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_controller kvm_amd snd_hda_codec kvm snd_hwdep nouveau snd_seq mxm_wmi 
video snd_seq_device snd_pcm i2c_algo_bit ttm drm_kms_helper ppdev microcode 
parport_serial parport_pc snd_timer k10temp drm serio_raw i2c_nforce2 parport 
snd i2c_core soundcore wmi acpi_cpufreq sunrpc ata_generic pata_acpi r8169 mii 
skge pata_amd uas usb_storage
[ cut here ]

CPU: 1 PID: 496 Comm: firewalld Not tainted 3.15.0-0.rc4.git0.1.fc21.i686+debug 
#1
Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 
09/07/2010
WARNING: CPU: 2 PID: 852 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
  252e7679 
snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped 
cacheline [cln=0x03012000]
 eed99df0 c0ae6f0d eed99e34
Modules linked in:
 eed99e24 c0454432
 ip6t_rpfilter ip6t_REJECT
 c0ceddd8
 xt_conntrack cfg80211 rfkill
 eed99e54
 ebtable_nat ebtable_broute bridge
 01f0
 stp llc
 c0cebc97
 ebtable_filter
 0251
 ebtables ip6table_nat nf_conntrack_ipv6
 c0754c39
 nf_defrag_ipv6
 0251
 nf_nat_ipv6 ip6table_mangle ip6table_security
 c0754c39
 ip6table_raw ip6table_filter ip6_tables

 iptable_nat nf_conntrack_ipv4
 f3721700
 nf_defrag_ipv4 nf_nat_ipv4
 f2cfc480
 nf_nat
 03012000
 eed99e40 c045448e 0009 eed99e34 c0ceddd8
Call Trace:
 [] dump_stack+0x48/0x60
 nf_conntrack iptable_mangle

 iptable_security iptable_raw
 [] warn_slowpath_common+0x82/0xa0
 snd_hda_codec_realtek snd_hda_codec_generic

 snd_hda_intel snd_hda_controller
 [] ? debug_dma_assert_idle+0x159/0x1d0
 kvm_amd

 [] ? debug_dma_assert_idle+0x159/0x1d0
 snd_hda_codec

 kvm snd_hwdep nouveau snd_seq
 [] warn_slowpath_fmt+0x3e/0x60

 [] debug_dma_assert_idle+0x159/0x1d0

 mxm_wmi video
 [] ? anon_vma_prepare+0x29/0x140

 [] do_wp_page+0xce/0x890
 snd_seq_device snd_pcm

 [] ? __hrtimer_start_range_ns+0x35/0x550
 i2c_algo_bit
 [] handle_mm_fault+0x662/0xb70

 ttm drm_kms_helper
 [] ? __hrtimer_start_range_ns+0x35/0x550
 ppdev microcode parport_serial

 parport_pc snd_timer
 [] __do_page_fault+0x1a7/0x5d0
 k10temp drm serio_raw i2c_nforce2

 [] ? __audit_syscall_entry+0x8c/0xe0

 parport snd
 [] ? trace_hardirqs_on+0xb/0x10

 i2c_core soundcore
 [] ? trace_hardirqs_on_caller+0x13c/0x1e0
 wmi acpi_cpufreq

 [] ? __do_page_fault+0x5d0/0x5d0

 [] do_page_fault+0x1a/0x20

 sunrpc ata_generic pata_acpi
 [] error_code+0x6c/0x74
 r8169 mii
---[ end trace 08b99da35a4e0d8c ]---
Mapped at:
 
[] debug_dma_alloc_coherent+0x22/0x70
 
[] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
 
[] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
 skge
 
[] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
 
[] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
 pata_amd
 uas usb_storage
CPU: 2 PID: 852 Comm: firewalld Tainted: GW 
3.15.0-0.rc4.git0.1.fc21.i686+debug #1
Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 
09/07/2010
  cef7cf31  ecf2ddf0 c0ae6f0d ecf2de34 ecf2de24 c0454432
 c0ceddd8 ecf2de54 0354 c0cebc97 0251 c0754c39 0251 c0754c39
 f3721700 f2cfc480 03012000 ecf2de40 c045448e 0009 ecf2de34 c0ceddd8
Call Trace:
 [] dump_stack+0x48/0x60
 [] warn_slowpath_common+0x82/0xa0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] warn_slowpath_fmt+0x3e/0x60
 [] debug_dma_assert_idle+0x159/0x1d0
 [] ? anon_vma_prepare+0x29/0x140
 [] do_wp_page+0xce/0x890
 [] ? __hrtimer_start_range_ns+0x35/0x550
 [] handle_mm_fault+0x662/0xb70
 [] ? __hrtimer_start_range_ns+0x35/0x550
 [] __do_page_fault+0x1a7/0x5d0
 [] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [] ? __audit_syscall_entry+0x8c/0xe0
 [] ? trace_hardirqs_on+0xb/0x10
 [] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [] ? __do_page_fault+0x5d0/0x5d0
 [] do_page_fault+0x1a/0x20
 [] error_code+0x6c/0x74
---[ end trace 08b99da35a4e0d8d ]---
Mapped at:
 [] debug_dma_alloc_coherent+0x22/0x70
 [] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
 [] 

Re: [PATCH] netdev: pktgen xmit packet through vlan interface

[Zhouyi Zhou]

> You could just force pktgen to not support multi-skb on vlan interfaces?
>
> I thought we went through this a year or two ago and came up with
> something like a 'pktgen-challenged' network interface flag?

Ah yes,  IFF_TX_SKB_SHARING does the job, very sorry for missing that,
 as matter of fact, I have
tailed pktgen model for my personal use.

By the way, would skb_clone save the CPU cycles for
memset(skb_put(skb, datalen), 0, datalen) thing ? especially for
Jesper's qdisc test scenery.





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

Re: [PATCH 2/5] ARM: add SMP support for Broadcom mobile SoCs

[Stephen Boyd]

On 05/05/14 15:02, Alex Elder wrote:
> On 04/04/2014 12:55 PM, Stephen Boyd wrote:
>> On 04/03/14 19:18, Alex Elder wrote:
>>> +
>>> +/*
>>> + * Secondary startup method setup routine to extract the location of
>>> + * the secondary boot register from a "cpu" or "cpus" device tree
>>> + * node.  Only the first seen secondary boot register value is used;
>>> + * any others are ignored.  The secondary boot register value must be
>>> + * non-zero.
>>> + *
>>> + * Returns 0 if successful or an error code otherwise.
>>> + */
>>> +static int __init of_enable_method_setup(struct device_node *node)
>>> +{
>>> +   int ret;
>>> +
>>> +   /* Ignore all but the first one specified */
>>> +   if (secondary_boot)
>>> +   return 0;
>>> +
>>> +   ret = of_property_read_u32(node, OF_SECONDARY_BOOT, _boot);
>>> +   if (ret)
>>> +   pr_err("%s: missing/invalid " OF_SECONDARY_BOOT " property\n",
>>> +   node->name);
>>> +
>>> +   return ret;
>>> +}
>> I don't understand why we need this. Why can't we get the secondary boot
>> address from the /cpus node in the smp_prepare_cpus op. It isn't that
>> hard to get access to the cpus node there via of_find_node_by_path().
>> Then we don't need patch 1 at all. If it turns out to be common stuff,
>> we can always have the common function live in arm common code or maybe
>> even be a devicetree API.
> I already responded to this, but never got any response.  I
> was preparing to re-send this series and wanted to try to
> pull the added feature (patch 1) out and not be dependent on
> it.  But I think it's a bit ugly so I'm hoping to get a
> blessing to proceed with what I originally proposed.  For
> reference, here's the thread:
> https://lkml.org/lkml/2014/4/3/421
>
> What I'm trying to do is get the value of a "secondary-boot-reg"
> property from a node known to have an "enable-method" property
> that matches the method name supplied in CPU_METHOD_OF_DECLARE().

I don't recall seeing any documentation about the secondary-boot-reg
property. Please make sure it is documented in the next patch series.

>
> Using the callback function as I originally proposed, this is
> very easy.  When arm_dt_init_cpu_maps() parses the "cpus" portion
> of the device tree it calls set_smp_ops_by_method() for a
> matching "cpu" or "cpus" node, and that function supplies
> the node to the callback function. The callback can extract
> additional property values if needed.
>
> If I hold off until smp_prepare_cpus() is called, I have to
> re-parse the device tree to find the "cpus" node (this is
> in itself trivial).  I then need to re-parse that node to
> verify the matching "enable-method" property is found before
> looking for the parameter information I need for that enable
> method.  I would really prefer not to re-do this parsing
> step.  It's imprecise and a little inefficient, and it
> duplicates (but not exactly) logic that's already performed
> by arm_dt_init_cpu_maps().

Do you have any devices where the enable-method and secondary-boot-reg
isn't the same across all CPUs? A lot of the complexity comes from
broken DTs that don't specify a secondary-boot-reg along with the
enable-method. From the description and the code it seems that we should
just always put these two properties in the cpus node to make things
simple and precise. I agree it's a minor duplication to read the DT
again to get the /cpus node and read a property out of it, but I doubt
you could even measure the difference.

>
> One more point of clarification.  This "secondary-boot-reg"
> value is *not* the secondary boot address--that is, it's
> not the address secondary cores jump to when they are
> activated.  Instead, this is the address of a register
> that's used to request the ROM code release a core from
> its ROM-implemented holding pen.  For this machine,
> control jumps at that point to secondary_startup(),
> defined in arch/arm/kernel/head.S.

Yes it wouldn't be possible to specify the entry address in DT (depends
on compile time factors). How is this different from cpu-release-addr
though? It looks like it describes something similar to what ePAPR
describes and how arm64 uses it (although those two slightly differ).
Assuming it's paired with a different enable-method than spin-table I
don't see a problem reusing the same name.

>
> So...
>
> Stephen, I'd like to hear from you whether my explanation
> is adequate, and whether you think my addition and use of
> CPU_METHOD_OF_DECLARE_SETUP() is reasonable.  (If you have
> a suggestion for a better name, I'm open.)
>
> If you still don't like it, I'll follow up with a
> new version of the patches, this time parsing the
> device tree in the smp_prepare_cpus() method as
> you suggested.  I don't want this to hold up getting
> this SMP support into the kernel.
>

This was my train of thought. It annoys me that we have smp ops at two
levels. We already have SMP ops that deal with SMP things and now we
have another level that is associated with 

[PATCH V2] perf tools: Clarify the output of perf sched map.

[Dongsheng Yang]

From: Dongsheng 

In output of perf sched map, any shortname of thread will be explained
at the first time when it appear.

Example:
  *A0   228836.978985 secs A0 => perf:23032
  *.   A0   228836.979016 secs B0 => swapper:0
   .  *C0   228836.979099 secs C0 => migration/3:22
  *A0  .   C0   228836.979115 secs
   A0  .  *.228836.979115 secs

But B0, which is explained as swapper:0 did not appear in the
left part of output. Instead, we use '.' as the shortname of
swapper:0. So the comment of "B0 => swapper:0" is not easy to
understand.

This patch clarify the output of perf sched map with not allocating
one letter-number shortname for swapper:0 and print ". => swapper:0"
as the explaination for swapper:0.

Example:
  *A0   228836.978985 secs A0 => perf:23032
  * .  A0   228836.979016 secs . => swapper:0
. *B0   228836.979099 secs B0 => migration/3:22
  *A0   .  B0   228836.979115 secs
   A0   . * .   228836.979115 secs
   A0 *C0   .   228836.979225 secs C0 => ksoftirqd/2:18
   A0 *D0   .   228836.979236 secs D0 => rcu_sched:7

Signed-off-by: Dongsheng 
Acked-by: Ingo Molnar 
---
 tools/perf/builtin-sched.c | 38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 4f0dd21..c6a6f5c 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1300,17 +1300,26 @@ static int map_switch_event(struct perf_sched *sched, 
struct perf_evsel *evsel,
 
new_shortname = 0;
if (!sched_in->shortname[0]) {
-   sched_in->shortname[0] = sched->next_shortname1;
-   sched_in->shortname[1] = sched->next_shortname2;
-
-   if (sched->next_shortname1 < 'Z') {
-   sched->next_shortname1++;
-   } else {
-   sched->next_shortname1='A';
-   if (sched->next_shortname2 < '9') {
-   sched->next_shortname2++;
+   if (!strcmp(thread__comm_str(sched_in), "swapper")) {
+   /*
+* Don't allocate a letter-number for swapper:0
+* as a shortname. Instead, we use '.' for it.
+*/
+   sched_in->shortname[0] = '.';
+   sched_in->shortname[1] = '\0';
+   }else {
+   sched_in->shortname[0] = sched->next_shortname1;
+   sched_in->shortname[1] = sched->next_shortname2;
+
+   if (sched->next_shortname1 < 'Z') {
+   sched->next_shortname1++;
} else {
-   sched->next_shortname2='0';
+   sched->next_shortname1='A';
+   if (sched->next_shortname2 < '9') {
+   sched->next_shortname2++;
+   } else {
+   sched->next_shortname2='0';
+   }
}
}
new_shortname = 1;
@@ -1322,12 +1331,9 @@ static int map_switch_event(struct perf_sched *sched, 
struct perf_evsel *evsel,
else
printf("*");
 
-   if (sched->curr_thread[cpu]) {
-   if (sched->curr_thread[cpu]->tid)
-   printf("%2s ", 
sched->curr_thread[cpu]->shortname);
-   else
-   printf(".  ");
-   } else
+   if (sched->curr_thread[cpu])
+   printf("%2s ", sched->curr_thread[cpu]->shortname);
+   else
printf("   ");
}
 
-- 
1.8.2.1

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

RE: [PATCH 20/27] ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table().

[Zheng, Lv]

Hi,

> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Tuesday, May 06, 2014 8:44 AM
> 
> On Monday, May 05, 2014 08:42:46 AM Josh Boyer wrote:
> > On Mon, May 5, 2014 at 12:23 AM, Zheng, Lv  wrote:
> > > Hi, Rafael
> > >
> > >> From: linux-acpi-ow...@vger.kernel.org 
> > >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> > >> Sent: Monday, May 05, 2014 8:43 AM
> > >>
> > >> On Saturday, May 03, 2014 08:59:14 AM Josh Boyer wrote:
> > >> > On Tue, Apr 29, 2014 at 10:05 PM, Lv Zheng  wrote:
> > >> > > The commit of back porting Linux XSDT validation mechanism has 
> > >> > > introduced
> > >> > > a regreession:
> > >> > >   Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
> > >> > >   Subject: ACPICA: Back port and refine validation of the XSDT root 
> > >> > > table.
> > >> > > There is a pointer still accessed after unmapping.
> > >> > >
> > >> > > This patch fixes this issue.  Lv Zheng.
> > >> > >
> > >> > > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911
> > >> > > Buglink: https://bugs.archlinux.org/task/39811
> > >> > > Signed-off-by: Lv Zheng 
> > >> > > Reported-and-tested-by: Bruce Chiarelli 
> > >> > > Reported-and-tested-by: Spyros Stathopoulos 
> > >> > > Signed-off-by: Bob Moore 
> > >> > > Cc:  # 3.14.x: 671cc68: ACPICA: Back port 
> > >> > > and refine validation of the XSDT root table.
> > >> >
> > >> > This patch should get into 3.15-rcX soon.  It fixes a known regression
> > >> > that prevents booting on machines with AMI firmware, and that is
> > >> > present in 3.14 so we need it for stable as well.  Rafael?
> > >>
> > >> Lv, is it safe to take this patch alone into 3.15-rc?
> > >
> > > Yes, it's safe to only take this patch to be a regression fix.
> >
> > FWIW, Fedora is carrying this on top of 3.14.2 already, and people
> > with the impacted machines say it's working for them.  So I agree it
> > should be safe.
> >
> > Thanks to the both of you.
> 
> OK, queued up for 3.15, thanks!

Actually there are 2 fixes in the same patch set for this issue:
One is a regression fix for commit 671cc68 - let me call it "Solution 1 - ill 
formed XSDT skipping".
 https://patchwork.kernel.org/patch/4090591/
The other is a different approach to solve the old issue that is fixed by 
solution 1 - let me call it "Solution 2 - R/XSDT NULL entry skipping".
 https://patchwork.kernel.org/patch/4090511/
 https://patchwork.kernel.org/patch/4090501/

And if you want to know the whole story before making further decisions.

The commit 671cc68 is introduced to reduce the ACPICA divergences.
Lacking in platforms having such ill formed XSDT shipped, I only unit tested 
the commit in ACPICA development environment where AcpiOsUnmapMemory() is a 
no-op.
Thus the buggy commit is leaked to the Linux kernel during the ACPICA release 
cycle.

When fixing the regression here: 
https://bugzilla.kernel.org/show_bug.cgi?id=73911
At first, the root cause is not addressed due to the same test incapability, 
thus it comes the solution 2 to solve the old issue in a different way.
As the solution 1 prevents higher versioned tables to be used while solution 2 
enables higher versioned tables,
I believe solution 2 is more correct than the old approach.
The solution 2 is based on ACPICA 201403 release, for kernel v3.14, a 
completely different stable material is generated.

In the meanwhile, the regression is root caused.
Though the regression fix may not be useful if the solution 2 is proven to be 
more correct,
ACPICA also merged this regression fix in order to generate a stable material 
for Linux.

I'm not sure if patches for solution 2 also need to be merged using the 
short-cut path.
Possibly not as the solution 2 changed old behavior of Linux, so they are not 
urgent stable materials.

Thanks and best regards
-Lv

> 
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC][PATCH v2] hwmon: add support for Sensirion SHTC1 sensor

[Guenter Roeck]

Hi Tomas,

On 05/05/2014 06:03 PM, Tomas Pop wrote:

Hi Guenter,

Here is a corrected version, I tried to address your comments and I'm sending it
again with a kind request for comments - we will do some more extensive testing
before the final submission, but I would like to make the code as complete as
as possible before. Here is a list of changes to the previous version:


Comments below. But I don't think you tested this with real HW, did you ? :-)


* positive, but incorrect return codes/lengths from i2c_mater_* are checked
* usleep_range used instead of msleep
* DEVICE_ATTR used instead of SENSOR_DEVICE_ATTR, ATTRIBITE_GROUPS used
* devm_hwmon_device_register_with_groups instead of devm_hwmon_device_register
* direct calls to sysfs_create_group and sysfs_create_group dropped
* shtc1_remove function dropped
* SHTW1 added to documentation and Kconfig
* documentation and formating updates/corrections

I did re-compile with C=1 as suggested and it is clear.

Patch was generated against kernel v3.15-rc3

Thanks,
Tomas

Signed-off-by: Tomas Pop 
---
  Documentation/hwmon/shtc1   |  41 ++
  drivers/hwmon/Kconfig   |  10 ++
  drivers/hwmon/Makefile  |   1 +
  drivers/hwmon/shtc1.c   | 266 
  include/linux/platform_data/shtc1.h |  24 
  5 files changed, 342 insertions(+)
  create mode 100644 Documentation/hwmon/shtc1
  create mode 100644 drivers/hwmon/shtc1.c
  create mode 100644 include/linux/platform_data/shtc1.h

diff --git a/Documentation/hwmon/shtc1 b/Documentation/hwmon/shtc1
new file mode 100644
index 000..47c9ed1
--- /dev/null
+++ b/Documentation/hwmon/shtc1
@@ -0,0 +1,41 @@
+Kernel driver shtc1
+===
+
+Supported chips:
+  * Sensirion SHTC1
+Prefix: 'shtc1'
+Addresses scanned: none
+Datasheet: Publicly available at the Sensirion website
+http://www.sensirion.com/file/datasheet_shtc1
+
+  * Sensirion SHTW1
+Prefix: 'shtc1'
+Addresses scanned: none
+Datasheet: Not publicly available
+
+Author:
+  Johannes Winkelmann 
+
+Description
+---
+
+This driver implements support for the Sensirion SHTC1 chip, a humidity and
+temperature sensor. Temperature is measured in degrees celsius, relative
+humidity is expressed as a percentage. Driver can be used as well for SHTW1
+chip, which has the same electrical interface.
+
+The device communicates with the I2C protocol. All sensors are set to I2C
+address 0x70. See Documentation/i2c/instantiating-devices for methods to
+instantiate the device.
+
+There are two options configurable by means of shtc1_platform_data:
+1. blocking (pull the I2C clock line down while performing the measurement) or
+   non-blocking mode. Blocking mode will guarantee the fastest result but
+   the I2C bus will be busy during that time.
+2. high or low accuracy. Using high accuracy is strongly recommended.
+
+sysfs-Interface
+---
+
+temp1_input - temperature input
+humidity1_input - humidity input
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index bc196f4..f95ba5b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1114,6 +1114,16 @@ config SENSORS_SHT21
  This driver can also be built as a module.  If so, the module
  will be called sht21.

+config SENSORS_SHTC1
+   tristate "Sensiron humidity and temperature sensors. SHTC1 and compat."
+   depends on I2C
+   help
+ If you say yes here you get support for the Sensiron SHTC1 and SHTW1
+ humidity and temperature sensor.
+
+ This driver can also be built as a module.  If so, the module
+ will be called shtc1.
+
  config SENSORS_S3C
tristate "Samsung built-in ADC"
depends on S3C_ADC
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index c48f987..1cc5273 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -125,6 +125,7 @@ obj-$(CONFIG_SENSORS_SCH5627)   += sch5627.o
  obj-$(CONFIG_SENSORS_SCH5636) += sch5636.o
  obj-$(CONFIG_SENSORS_SHT15)   += sht15.o
  obj-$(CONFIG_SENSORS_SHT21)   += sht21.o
+obj-$(CONFIG_SENSORS_SHTC1)+= shtc1.o
  obj-$(CONFIG_SENSORS_SIS5595) += sis5595.o
  obj-$(CONFIG_SENSORS_SMM665)  += smm665.o
  obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o
diff --git a/drivers/hwmon/shtc1.c b/drivers/hwmon/shtc1.c
new file mode 100644
index 000..c94f670
--- /dev/null
+++ b/drivers/hwmon/shtc1.c
@@ -0,0 +1,266 @@
+/* Sensirion SHTC1 humidity and temperature sensor driver
+ *
+ * Copyright (C) 2014 Sensirion AG, Switzerland
+ * Author: Johannes Winkelmann 
+ *
+ * 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 

[PATCH v3 1/8] x86, irq: Remove not needed irq_reserve_irqs calling

[Yinghai Lu]

Now x86 only support sparseirq path, for that path, calling path like:
early_irq_init
==> arch_probe_nr_irqs : return legacy irq number
==> alloc_desc for legacy irqs and set bits in allocated_irqs
==> arch_early_irq_init
==> irq_reserve_irqs : set bits again

so we can kill one irq_reserve_irqs calling.

Signed-off-by: Yinghai Lu 
---
 arch/x86/kernel/apic/io_apic.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 6ad4658..398f9c4 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -206,9 +206,6 @@ int __init arch_early_irq_init(void)
count = ARRAY_SIZE(irq_cfgx);
node = cpu_to_node(0);
 
-   /* Make sure the legacy interrupts are marked in the bitmap */
-   irq_reserve_irqs(0, legacy_pic->nr_legacy_irqs);
-
for (i = 0; i < count; i++) {
irq_set_chip_data(i, [i]);
zalloc_cpumask_var_node([i].domain, GFP_KERNEL, node);
-- 
1.8.4.5

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

[PATCH v3 3/8] irq: Use irq_alloc_desc_at instead of irq_reserve_irq

[Yinghai Lu]

irq_reserve_irq actually only set bit allocated_irq, and it is not really
"reserve" and cause confusion.

For !CONFIG_SPARSE_IRQ path, irq_alloc_desc_at() will only set bit
in allocated_irq.

We can use that instead, kill one irq_reserve_irq() calling.

Signed-off-by: Yinghai Lu 
---
 kernel/irq/chip.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6397df2..aff7481 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -28,8 +28,13 @@
 int irq_set_chip(unsigned int irq, struct irq_chip *chip)
 {
unsigned long flags;
-   struct irq_desc *desc = irq_get_desc_lock(irq, , 0);
+   struct irq_desc *desc;
+
+#ifndef CONFIG_SPARSE_IRQ
+   irq_alloc_desc_at(irq, 0);
+#endif
 
+   desc = irq_get_desc_lock(irq, , 0);
if (!desc)
return -EINVAL;
 
@@ -38,12 +43,7 @@ int irq_set_chip(unsigned int irq, struct irq_chip *chip)
 
desc->irq_data.chip = chip;
irq_put_desc_unlock(desc, flags);
-   /*
-* For !CONFIG_SPARSE_IRQ make the irq show up in
-* allocated_irqs. For the CONFIG_SPARSE_IRQ case, it is
-* already marked, and this call is harmless.
-*/
-   irq_reserve_irq(irq);
+
return 0;
 }
 EXPORT_SYMBOL(irq_set_chip);
-- 
1.8.4.5

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

[PATCH v3 0/8] irq: core changes for x86 ioapic hotplug

[Yinghai Lu]

Hi,

These patches are core changes for x86 ioapic hotplug support.

First part for kill old irq_reserve_irqs:
During reviewing ioapic hotplug patchset, Thomas pointed out that
should not extend irq_reserve_irq for that purpose as that is not
actually reserve.
Neet to clean up old irq_reserve_irq before introduce reserve/alloc_reserved
method for ioapic hotplug.
So here patchset that kill irq_reserve_irq that actually set allocated_irqs.
First remove irq_reserve_irqs for x86, and remove irq_reserve_irq
for sh.
Then in set_irq_chip use irq_alloc_desc instead of irq_reserve_irq.
Next will mark bits in allocated_irqs early for init irqs in !SPARSE_IRQ

Second parts are new reserve/alloc_reserved functions:
It will introduce reserved_irqs bit maps to track reserved irqs.
New irq_alloc_reserved_desc() will only allocate desc when that irq
is reserved, at the same time irq_alloc_desc will only allocate desc
when irq is not reserved.

Thanks

Yinghai

-v2: add new reserve/alloc_reserved sets.
-v3: make irq_alloc_descs to avoid reserved irqs.

Yinghai Lu (8):
  x86, irq: Remove not needed irq_reserve_irqs calling
  sh, irq: Remove irq_reserve_irq calling
  irq: Use irq_alloc_desc_at instead of irq_reserve_irq
  s390: Mark bits in allocated_irqs in general code
  irq: Kill irq_reserve_irq/irq_reserve_irqs
  irq: Add new reserved_irqs clear/mark functions
  irq: Add irq_alloc_reserved_desc()
  irq: Do not free unallocated irq descriptors

 arch/s390/kernel/irq.c |   6 +-
 arch/x86/kernel/apic/io_apic.c |   3 -
 drivers/sh/intc/core.c |   7 +-
 include/linux/irq.h|  13 ++--
 kernel/irq/chip.c  |  14 ++--
 kernel/irq/irqdesc.c   | 144 ++---
 6 files changed, 141 insertions(+), 46 deletions(-)

-- 
1.8.4.5

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

[PATCH v3 2/8] sh, irq: Remove irq_reserve_irq calling

[Yinghai Lu]

in sh calling path:
register_intc_controller
==> irq_create_identity_mapping/irq_create_strict_mappins
==>irq_alloc_desc: it will set bits on allocate_irq
==> intc_register_irq
==> irq_reserve_irq: set bits again

so we can kill this irq_reserve_irq calling.

-v2: Fix comment style according to Sergei Shtylyov.

Signed-off-by: Yinghai Lu 
Cc: Simon Horman 
Cc: Magnus Damm 
Cc: linux...@vger.kernel.org
Acked-by: Simon Horman 
---
 drivers/sh/intc/core.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
index 8f32a13..d146ce1 100644
--- a/drivers/sh/intc/core.c
+++ b/drivers/sh/intc/core.c
@@ -80,12 +80,7 @@ static void __init intc_register_irq(struct intc_desc *desc,
unsigned int data[2], primary;
unsigned long flags;
 
-   /*
-* Register the IRQ position with the global IRQ map, then insert
-* it in to the radix tree.
-*/
-   irq_reserve_irq(irq);
-
+   /* Insert it in to the radix tree. */
raw_spin_lock_irqsave(_big_lock, flags);
radix_tree_insert(>tree, enum_id, intc_irq_xlate_get(irq));
raw_spin_unlock_irqrestore(_big_lock, flags);
-- 
1.8.4.5

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

[PATCH v3 5/8] irq: Kill irq_reserve_irq/irq_reserve_irqs

[Yinghai Lu]

No user any more.

Signed-off-by: Yinghai Lu 
---
 include/linux/irq.h  |  6 --
 kernel/irq/irqdesc.c | 25 -
 2 files changed, 31 deletions(-)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 28cbd3e..02dc0e4 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -623,7 +623,6 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned 
int cnt, int node,
irq_alloc_descs(-1, from, cnt, node)
 
 void irq_free_descs(unsigned int irq, unsigned int cnt);
-int irq_reserve_irqs(unsigned int from, unsigned int cnt);
 int arch_probe_early_allocate_nr_irqs(void);
 
 static inline void irq_free_desc(unsigned int irq)
@@ -631,11 +630,6 @@ static inline void irq_free_desc(unsigned int irq)
irq_free_descs(irq, 1);
 }
 
-static inline int irq_reserve_irq(unsigned int irq)
-{
-   return irq_reserve_irqs(irq, 1);
-}
-
 #ifndef irq_reg_writel
 # define irq_reg_writel(val, addr) writel(val, addr)
 #endif
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index dfb971c..49bf891 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -400,31 +400,6 @@ err:
 EXPORT_SYMBOL_GPL(__irq_alloc_descs);
 
 /**
- * irq_reserve_irqs - mark irqs allocated
- * @from:  mark from irq number
- * @cnt:   number of irqs to mark
- *
- * Returns 0 on success or an appropriate error code
- */
-int irq_reserve_irqs(unsigned int from, unsigned int cnt)
-{
-   unsigned int start;
-   int ret = 0;
-
-   if (!cnt || (from + cnt) > nr_irqs)
-   return -EINVAL;
-
-   mutex_lock(_irq_lock);
-   start = bitmap_find_next_zero_area(allocated_irqs, nr_irqs, from, cnt, 
0);
-   if (start == from)
-   bitmap_set(allocated_irqs, start, cnt);
-   else
-   ret = -EEXIST;
-   mutex_unlock(_irq_lock);
-   return ret;
-}
-
-/**
  * irq_get_next_irq - get next allocated irq number
  * @offset:where to start the search
  *
-- 
1.8.4.5

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

[PATCH v3 4/8] s390: Mark bits in allocated_irqs in general code

[Yinghai Lu]

Second irq_reserve_irqs calling is from arch s390, and
s390 does not use SPARSE_IRQ yet.

We could set bits for legacy bits early in !SPARSE_IRQ version
early_irq_init() directly instead of calling irq_reserve_irqs later.

Adding weak version arch_proble_early_allocate_nr_irqs() for
!SPARESE_IRQ, and let s390 to have specific version to
pass correct irq number that need to be marked in allocated_irqs.

Signed-off-by: Yinghai Lu 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: linux...@de.ibm.com
---
 arch/s390/kernel/irq.c |  6 +-
 include/linux/irq.h|  1 +
 kernel/irq/irqdesc.c   | 10 ++
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/s390/kernel/irq.c b/arch/s390/kernel/irq.c
index c7463aa..47e29be 100644
--- a/arch/s390/kernel/irq.c
+++ b/arch/s390/kernel/irq.c
@@ -90,9 +90,13 @@ static const struct irq_class 
irqclass_sub_desc[NR_ARCH_IRQS] = {
[CPU_RST]= {.name = "RST", .desc = "[CPU] CPU Restart"},
 };
 
+int arch_probe_early_allocate_nr_irqs(void)
+{
+   return THIN_INTERRUPT;
+}
+
 void __init init_IRQ(void)
 {
-   irq_reserve_irqs(0, THIN_INTERRUPT);
init_cio_interrupts();
init_airq_interrupts();
init_ext_interrupts();
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 10a0b1a..28cbd3e 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -624,6 +624,7 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned 
int cnt, int node,
 
 void irq_free_descs(unsigned int irq, unsigned int cnt);
 int irq_reserve_irqs(unsigned int from, unsigned int cnt);
+int arch_probe_early_allocate_nr_irqs(void);
 
 static inline void irq_free_desc(unsigned int irq)
 {
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index a7174617..dfb971c 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -248,10 +248,16 @@ struct irq_desc irq_desc[NR_IRQS] 
__cacheline_aligned_in_smp = {
}
 };
 
+int __weak arch_probe_early_allocate_nr_irqs(void)
+{
+   return 0;
+}
+
 int __init early_irq_init(void)
 {
int count, i, node = first_online_node;
struct irq_desc *desc;
+   int nr = arch_probe_early_allocate_nr_irqs();
 
init_irq_default_affinity();
 
@@ -267,6 +273,10 @@ int __init early_irq_init(void)
lockdep_set_class([i].lock, _desc_lock_class);
desc_set_defaults(i, [i], node, NULL);
}
+
+   for (i = 0; i < nr; i++)
+   set_bit(i, allocated_irqs);
+
return arch_early_irq_init();
 }
 
-- 
1.8.4.5

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

[PATCH v3 8/8] irq: Do not free unallocated irq descriptors

[Yinghai Lu]

Hot-added interrupt controllers can reserve a range of interrupt
numbers, but only allocate some of them. To simplify the release on
hot-remove allow them to iterate over the reserved range, let the
free_desc() code return early when the descriptor does not exist

-v2: changelog from tglx

Signed-off-by: Yinghai Lu 
---
 kernel/irq/irqdesc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 7b2b83a..b46ab9e 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -167,6 +167,9 @@ static void free_desc(unsigned int irq)
 {
struct irq_desc *desc = irq_to_desc(irq);
 
+   if (!desc)
+   return;
+
unregister_irq_proc(irq, desc);
 
mutex_lock(_irq_lock);
-- 
1.8.4.5

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

[PATCH v3 6/8] irq: Add new reserved_irqs clear/mark functions

[Yinghai Lu]

Prepare for ioapic hotplug.

-v2: Add reserved_or_allocated_irqs to simplify the code.

Signed-off-by: Yinghai Lu 
---
 include/linux/irq.h  |  3 +++
 kernel/irq/irqdesc.c | 65 
 2 files changed, 68 insertions(+)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 02dc0e4..2ba3245 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -603,6 +603,9 @@ static inline u32 irq_get_trigger_type(unsigned int irq)
return d ? irqd_get_trigger_type(d) : 0;
 }
 
+int irq_clear_reserved_irqs(unsigned int from, unsigned int cnt);
+int irq_mark_reserved_irqs(int irq, unsigned int from, unsigned int cnt);
+
 int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
struct module *owner);
 
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 49bf891..d55297a 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -98,6 +98,8 @@ EXPORT_SYMBOL_GPL(nr_irqs);
 
 static DEFINE_MUTEX(sparse_irq_lock);
 static DECLARE_BITMAP(allocated_irqs, IRQ_BITMAP_BITS);
+static DECLARE_BITMAP(reserved_irqs, IRQ_BITMAP_BITS);
+static DECLARE_BITMAP(reserved_or_allocated_irqs, IRQ_BITMAP_BITS);
 
 #ifdef CONFIG_SPARSE_IRQ
 
@@ -400,6 +402,69 @@ err:
 EXPORT_SYMBOL_GPL(__irq_alloc_descs);
 
 /**
+ * irq_clear_reserved_irqs - clear irqs reserved
+ * @from:  clear from irq number
+ * @cnt:   number of irqs to clear
+ *
+ * Returns 0 on success or an appropriate error code
+ */
+int irq_clear_reserved_irqs(unsigned int from, unsigned int cnt)
+{
+   if (!cnt || (from + cnt) > nr_irqs)
+   return -EINVAL;
+
+   mutex_lock(_irq_lock);
+   bitmap_clear(reserved_irqs, from, cnt);
+   mutex_unlock(_irq_lock);
+
+   return 0;
+}
+
+/**
+ * irq_mark_reserved_irqs - mark irqs reserved
+ * @irq:   Reserve for specific irq number if irq >= 0
+ * @from:  mark from irq number
+ * @cnt:   number of irqs to mark
+ *
+ * Returns the first irq number or error code
+ */
+int irq_mark_reserved_irqs(int irq, unsigned int from, unsigned int cnt)
+{
+   int start, ret;
+
+   if (!cnt)
+   return -EINVAL;
+
+   if (irq >= 0) {
+   if (from > irq)
+   return -EINVAL;
+   from = irq;
+   }
+
+   mutex_lock(_irq_lock);
+   bitmap_or(reserved_or_allocated_irqs, reserved_irqs, allocated_irqs,
+IRQ_BITMAP_BITS);
+   start = bitmap_find_next_zero_area(reserved_or_allocated_irqs,
+  IRQ_BITMAP_BITS, from, cnt, 0);
+   ret = -EEXIST;
+   if (irq >= 0 && start != irq)
+   goto err;
+
+   if (start + cnt > nr_irqs) {
+   ret = irq_expand_nr_irqs(start + cnt);
+   if (ret < 0)
+   goto err;
+   }
+
+   bitmap_set(reserved_irqs, start, cnt);
+   ret = start;
+
+err:
+   mutex_unlock(_irq_lock);
+   return ret;
+}
+
+/**
  * irq_get_next_irq - get next allocated irq number
  * @offset:where to start the search
  *
-- 
1.8.4.5

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

[PATCH v3 7/8] irq: Add irq_alloc_reserved_desc()

[Yinghai Lu]

For ioapic hot-add support, it would be easy if we have continuous
irq numbers for hot added ioapic controller.

We can reserve irq range at first, and later allocate desc for those
pre-reserved irqs when they are needed.

The reasons for not allocating them during reserving:
1. only several pins of one ioapic are used, allocate for all pins, will
   waste memory for not used pins.
2. allocate later when is needed could make sure irq_desc is allocated
   on local node ram, as dev->node is set at that point.

-v2: update changelog by adding reasons, requested by Konrad.
-v3: according to tglx:
   separate core code change with arch code change.
   change function name to irq_alloc_reserved_desc.
   kill __irq_is_reserved().
   remove not need exports.
 according to Sebastian:
   spare one comments by put two functions together.
-v4: Fix the bug that tglx pointed out.
 irq_alloc_descs() should avoid reserved irqs.

Signed-off-by: Yinghai Lu 
Cc: Joerg Roedel 
Cc: Konrad Rzeszutek Wilk 
Cc: Sebastian Andrzej Siewior 
---
 include/linux/irq.h  |  3 ++
 kernel/irq/irqdesc.c | 97 ++--
 2 files changed, 74 insertions(+), 26 deletions(-)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 2ba3245..97b60b9 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -608,10 +608,13 @@ int irq_mark_reserved_irqs(int irq, unsigned int from, 
unsigned int cnt);
 
 int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
struct module *owner);
+int __irq_alloc_reserved_desc(int at, int node, struct module *owner);
 
 /* use macros to avoid needing export.h for THIS_MODULE */
 #define irq_alloc_descs(irq, from, cnt, node)  \
__irq_alloc_descs(irq, from, cnt, node, THIS_MODULE)
+#define irq_alloc_reserved_desc_at(at, node)   \
+   __irq_alloc_reserved_desc(at, node, THIS_MODULE)
 
 #define irq_alloc_desc(node)   \
irq_alloc_descs(-1, 0, 1, node)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index d55297a..7b2b83a 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -352,21 +352,11 @@ void irq_free_descs(unsigned int from, unsigned int cnt)
 }
 EXPORT_SYMBOL_GPL(irq_free_descs);
 
-/**
- * irq_alloc_descs - allocate and initialize a range of irq descriptors
- * @irq:   Allocate for specific irq number if irq >= 0
- * @from:  Start the search from this irq number
- * @cnt:   Number of consecutive irqs to allocate.
- * @node:  Preferred node on which the irq descriptor should be allocated
- * @owner: Owning module (can be NULL)
- *
- * Returns the first irq number or error code
- */
-int __ref
-__irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
- struct module *owner)
+/* Should be used with sparse_irq_lock */
+static int __irq_mark_allocated_irqs(int irq, unsigned int from,
+unsigned int cnt, int avoid_reserved)
 {
-   int start, ret;
+   int start;
 
if (!cnt)
return -EINVAL;
@@ -377,26 +367,55 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned 
int cnt, int node,
from = irq;
}
 
-   mutex_lock(_irq_lock);
+   if (avoid_reserved) {
+   bitmap_or(reserved_or_allocated_irqs, reserved_irqs,
+ allocated_irqs, IRQ_BITMAP_BITS);
 
-   start = bitmap_find_next_zero_area(allocated_irqs, IRQ_BITMAP_BITS,
-  from, cnt, 0);
-   ret = -EEXIST;
-   if (irq >=0 && start != irq)
-   goto err;
+   start = bitmap_find_next_zero_area(reserved_or_allocated_irqs,
+   IRQ_BITMAP_BITS,
+   from, cnt, 0);
+   } else
+   start = bitmap_find_next_zero_area(allocated_irqs,
+   IRQ_BITMAP_BITS,
+   from, cnt, 0);
+
+   if (irq >= 0 && start != irq)
+   return -EEXIST;
 
if (start + cnt > nr_irqs) {
-   ret = irq_expand_nr_irqs(start + cnt);
-   if (ret)
-   goto err;
+   int ret = irq_expand_nr_irqs(start + cnt);
+
+   if (ret < 0)
+   return ret;
}
 
bitmap_set(allocated_irqs, start, cnt);
-   mutex_unlock(_irq_lock);
-   return alloc_descs(start, cnt, node, owner);
 
-err:
+   return start;
+}
+
+/**
+ * irq_alloc_descs - allocate and initialize a range of irq descriptors
+ * @irq:   Allocate for specific irq number if irq >= 0
+ * @from:  Start the search from this irq number
+ * @cnt:   Number of consecutive irqs to allocate.
+ * @node:  Preferred node on which the irq descriptor should be allocated
+ * @owner: 

Re: [PATCH 4/4] test: validate sysctl_writes_strict

[Kees Cook]

On Sat, May 3, 2014 at 7:42 AM, Randy Dunlap  wrote:
> On 05/01/2014 02:26 PM, Kees Cook wrote:
>>
>> This adds several behavioral tests to sysctl string and number writing
>> to detect unexpected cases that behaved differently when the sysctl
>> kernel.sysctl_writes_strict != 1.
>>
>>
>> Signed-off-by: Kees Cook 
>> ---
>>   kernel/sysctl.c |4 +-
>>   tools/testing/selftests/Makefile|1 +
>>   tools/testing/selftests/sysctl/Makefile |   19 
>>   tools/testing/selftests/sysctl/common_tests |  109
>> +++
>>   tools/testing/selftests/sysctl/run_numerictests |   10 +++
>>   tools/testing/selftests/sysctl/run_stringtests  |   77 
>>   6 files changed, 218 insertions(+), 2 deletions(-)
>>   create mode 100644 tools/testing/selftests/sysctl/Makefile
>>   create mode 100644 tools/testing/selftests/sysctl/common_tests
>>   create mode 100644 tools/testing/selftests/sysctl/run_numerictests
>>   create mode 100644 tools/testing/selftests/sysctl/run_stringtests
>>
>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>> index d5bee7949e4a..51bbf904d694 100644
>> --- a/kernel/sysctl.c
>> +++ b/kernel/sysctl.c
>> @@ -1783,8 +1783,8 @@ static int _proc_do_string(char *data, int maxlen,
>> int write,
>>
>>   static void warn_sysctl_write(struct ctl_table *table)
>>   {
>> -   pr_warn("%s wrote to %s when file position was not 0!\n",
>> -   current->task_comm, table->procname);
>> +   pr_warn("write to %s by %s used a non-zero file position!\n",
>> +   table->procname, current->comm);
>> pr_warn("This will not be supported in the future.\n");
>> pr_warn("To silence warning, set kernel.sysctl_writes_strict =
>> -1\n");
>>   }
>
>
> Why is this patch part of the test patch?

Oops, thanks. Yeah, that snuck into the wrong patch.

-Kees

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

Re: [PATCH v3 0/4] sysctl: fix incorrect write position handling

[Kees Cook]

On Mon, May 5, 2014 at 3:00 PM, Andrew Morton  wrote:
> On Thu,  1 May 2014 14:26:33 -0700 Kees Cook  wrote:
>
>> When writing to a sysctl string, each write, regardless of VFS position,
>> began writing the string from the start. This meant the contents of
>> the last write to the sysctl controlled the string contents instead of
>> the first.
>>
>> This misbehavior was featured in an exploit against Chrome OS. While it's
>> not in itself a vulnerability, it's a weirdness that isn't on the mind
>> of most auditors: "This filter looks correct, the first line written
>> would not be meaningful to sysctl" doesn't apply here, since the size
>> of the write and the contents of the final write are what matter when
>> writing to sysctls.
>>
>> This adds the sysctl kernel.sysctl_writes_strict to control the write
>> behavior. The default (0) reports when VFS position is non-0 on a write,
>> but retains legacy behavior, -1 disables the warning, and 1 enables the
>> position-respecting behavior.
>>
>
> OK, let's try that.  I added this paragraph to the patchset's overall
> changelog:
>
> : The long-term plan here is to wait for userspace to be fixed in response
> : to the new warning and to then switch the default kernel behavior to the
> : new position-respecting behavior.

Great, thanks!

> I'm thinking we should use pr_warn_once() in warn_sysctl_write()?  Otherwise
> people will go and shut the thing up permanently and we'll lose the benefits.

I was worried we'd miss different processed tripping it later. On the
other hand, I didn't like the idea of being able to spam dmesg. Do you
want me to send a patch to replace that with pr_warn_once()?

-Kees

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

Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

[Rusty Russell]

Randy Dunlap  writes:
> All looks good to me except for 2 instances of "eg" which should be
> "e.g." (just above and about 4 paragraphs below here).

Thanks, fixed:

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 56a4c2d0c741..a42b9dd6b46b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -14,7 +14,7 @@ environment, others are passed as command line arguments to 
init.
 Everything after "--" is passed as an argument to init.
 
 Module parameters can be specified in two ways: via the kernel command
-line with a module name prefix, or via modprobe, eg:
+line with a module name prefix, or via modprobe, e.g.:
 
(kernel command line) usbcore.blinkenlights=1
(modprobe command line) modprobe usbcore blinkenlights=1
@@ -30,7 +30,7 @@ Hyphens (dashes) and underscores are equivalent in parameter 
names, so
 can also be entered as
log-buf-len=1M print_fatal_signals=1
 
-Double-quotes can be used to protect spaces in values, eg:
+Double-quotes can be used to protect spaces in values, e.g.:
param="spaces in here"
 
 This document may not be entirely up to date and comprehensive. The command
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sched: Move the wakeup tracepoint from ttwu_do_wakeup() to ttwu_activate().

[Dongsheng Yang]

ttwu_do_wakeup() is called when the task's state is switched back to
TASK_RUNNING, whether or not the task actually scheduled out. Tracing
the wakeup event when the task never scheduled out is quite confusing.
It should only trace the task wake up if the task actually did go to
sleep. Move the tracepoint from ttwu_do_wakeup() to ttwu_activate()
where it is called only if the task is really woken up and not just
have its state changed.

Signed-off-by: Dongsheng Yang 
---
 kernel/sched/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9074c6d..0cae994 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1420,6 +1420,7 @@ static void ttwu_activate(struct rq *rq, struct 
task_struct *p, int en_flags)
 {
activate_task(rq, p, en_flags);
p->on_rq = 1;
+   trace_sched_wakeup(p, true);
 
/* if a worker is waking up, notify workqueue */
if (p->flags & PF_WQ_WORKER)
@@ -1433,7 +1434,6 @@ static void
 ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
 {
check_preempt_curr(rq, p, wake_flags);
-   trace_sched_wakeup(p, true);
 
p->state = TASK_RUNNING;
 #ifdef CONFIG_SMP
-- 
1.8.2.1

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

Re: [PATCH v2] cpumask.h: silence warning with -Wsign-compare

[Rusty Russell]

Brian W Hart  writes:
> Silence the warning when building with -Wsign-compare when cpumask.h
> is included:
>
> include/linux/cpumask.h: In function ‘cpumask_parse’:
> include/linux/cpumask.h:603:26: warning: signed and unsigned type in 
> conditional
> +expression [-Wsign-compare]
>   int len = nl ? nl - buf : strlen(buf);
>   ^
>
> V2: Rusty pointed out that unsigned should be used instead.

Thanks, applied.

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

Re: [PATCH 2/2] kernel/cpuset.c: convert printk to pr_foo()

[Li Zefan]

On 2014/5/6 1:49, Fabian Frederick wrote:
> Cc: Li Zefan 
> Cc: Andrew Morton 
> Signed-off-by: Fabian Frederick 

Acked-by: Li Zefan 

> ---
>  kernel/cpuset.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
> index 1d8c047..7c0e8da 100644
> --- a/kernel/cpuset.c
> +++ b/kernel/cpuset.c
> @@ -696,11 +696,8 @@ restart:
>   if (nslot == ndoms) {
>   static int warnings = 10;
>   if (warnings) {
> - printk(KERN_WARNING
> -  "rebuild_sched_domains confused:"
> -   " nslot %d, ndoms %d, csn %d, i %d,"
> -   " apn %d\n",
> -   nslot, ndoms, csn, i, apn);
> + pr_warn("rebuild_sched_domains confused: nslot 
> %d, ndoms %d, csn %d, i %d, apn %d\n",
> + nslot, ndoms, csn, i, apn);
>   warnings--;
>   }
>   continue;
> @@ -2018,7 +2015,7 @@ static void remove_tasks_in_empty_cpuset(struct cpuset 
> *cs)
>   parent = parent_cs(parent);
>  
>   if (cgroup_transfer_tasks(parent->css.cgroup, cs->css.cgroup)) {
> - printk(KERN_ERR "cpuset: failed to transfer tasks out of empty 
> cpuset ");
> + pr_err("cpuset: failed to transfer tasks out of empty cpuset ");
>   pr_cont_cgroup_name(cs->css.cgroup);
>   pr_cont("\n");
>   }
> @@ -2555,7 +2552,7 @@ void cpuset_print_task_mems_allowed(struct task_struct 
> *tsk)
>   cgrp = task_cs(tsk)->css.cgroup;
>   nodelist_scnprintf(cpuset_nodelist, CPUSET_NODELIST_LEN,
>  tsk->mems_allowed);
> - printk(KERN_INFO "%s cpuset=", tsk->comm);
> + pr_info("%s cpuset=", tsk->comm);
>   pr_cont_cgroup_name(cgrp);
>   pr_cont(" mems_allowed=%s\n", cpuset_nodelist);
>  
> 

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

Re: [PATCH 1/2] kernel/cpuset.c: kernel-doc fixes

[Li Zefan]

On 2014/5/6 1:46, Fabian Frederick wrote:
> This patch also converts seq_printf to seq_puts
> 
> Cc: Li Zefan 
> Cc: Andrew Morton 
> Signed-off-by: Fabian Frederick 

Acked-by: Li Zefan 

> ---
>  kernel/cpuset.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
...
>  void cpuset_task_status_allowed(struct seq_file *m, struct task_struct *task)
>  {
> - seq_printf(m, "Mems_allowed:\t");
> + seq_puts(m, "Mems_allowed:\t");
>   seq_nodemask(m, >mems_allowed);
> - seq_printf(m, "\n");
> - seq_printf(m, "Mems_allowed_list:\t");
> + seq_puts(m, "\n");

will seq_putc() produce slightly smaller code?

> + seq_puts(m, "Mems_allowed_list:\t");
>   seq_nodemask_list(m, >mems_allowed);
> - seq_printf(m, "\n");
> + seq_puts(m, "\n");
>  }
> 

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

Re: [PATCH] sched: Move the wakeup tracepoint from ttwu_do_wakeup() to ttwu_activate().

[Dongsheng Yang]

On 05/05/2014 11:00 PM, Steven Rostedt wrote:

On Mon, 5 May 2014 15:34:07 +0900
Dongsheng Yang  wrote:


The original design of sched:sched_wakeup is to trace the event inserting
a task into run queue. It means we can know that the state of this task is
changed from "sleeping" to "waiting_cpu". Then we can calculate the delay time
from this task on_rq = 1 to running on cpu in `perf sched latency`.

But currently, sched:sched_wakeup event is tracing ttwu_do_wakeup() and this
function only set the p->state to TASK_RUNNING. This trace point can tell user
very little. When get a event of sched:sched_wakeup, user know that kernel call
ttwu_do_wakeup() once, but we can not say that task start to wait cpu from now
on. Maybe it did not dequeue at all, in this case we will get a wrong latency
time calculated by "sched_in_time - wakeup_time".

Anyway, current sched:sched_wakeup event can tell user very little.
When we get a sched:sched_wakeup:
* We can not say a task is inserted into run queue, it is also used for task
which is on_rq and only change the task->state to TASK_RUNNING.
* We can not say the task->state is changed from {UN}INTERRUPTABLE to RUNNING,
sometimes task->state is already changed to RUNNING by other cpu.

As explained above, this patch move the trace point of sched:sched_wakeup from
ttwu_do_wakeup() to ttwu_activate(), then when we get an event of sched_wakeup,
we can say that a task enqueued and started waiting cpu to run.


tldr;


Yes, it is really lng, sorry for my terrible expression in english. :(


ttwu_do_wakeup() is called when the task's state is switched back to
TASK_RUNNING, whether or not the task actually scheduled out. Tracing
the wakeup event when the task never scheduled out is quite confusing.
It should only trace the task wake up if the task actually did go to
sleep. Move the tracepoint from ttwu_do_wakeup() to ttwu_activate()
where it is called only if the task is really woken up and not just
have its state changed.


Thanx for your kind comment here, it looks shorter and more clear to me.
I will update my commit message with your suggestion.

Thank you very much! :)


-- Steve



Signed-off-by: Dongsheng Yang 
---
  kernel/sched/core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9074c6d..0cae994 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1420,6 +1420,7 @@ static void ttwu_activate(struct rq *rq, struct 
task_struct *p, int en_flags)
  {
activate_task(rq, p, en_flags);
p->on_rq = 1;
+   trace_sched_wakeup(p, true);
  
  	/* if a worker is waking up, notify workqueue */

if (p->flags & PF_WQ_WORKER)
@@ -1433,7 +1434,6 @@ static void
  ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
  {
check_preempt_curr(rq, p, wake_flags);
-   trace_sched_wakeup(p, true);
  
  	p->state = TASK_RUNNING;

  #ifdef CONFIG_SMP

.



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