date:20150820

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
Acked-by: Peter Chen 
---
 drivers/power/wm831x_power.c |   69 ++
 include/linux/mfd/wm831x/pdata.h |3 ++
 2 files changed, 72 insertions(+)

diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index db11ae6..33ae27a 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_charger *usb_charger;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %dmA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   if (wm831x_pdata && wm831x_pdata->usb_gadget) {
+   power->usb_charger =
+   usb_charger_find_by_name(wm831x_pdata->usb_gadget);
+   if (IS_ERR(power->usb_charger)) {
+   ret = PTR_ERR(power->usb_charger);
+   dev_err(>dev,
+   "Failed to find USB gadget: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+   ret = usb_charger_register_notify(power->usb_charger,
+ >usb_notify);
+   if (ret != 0) {
+   dev_err(>dev,
+   "Failed to register notifier: %d\n", ret);
+   goto err_usb_charger;
+   }
+   }
+
return ret;
 
+err_usb_charger:
+   /* put_device on charger */
 err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_charger) {
+   usb_charger_unregister_notify(wm831x_power->usb_charger,
+ _power->usb_notify);
+   /* Free charger */
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index dcc9631..5af8399 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -126,6 +126,9 @@ struct wm831x_pdata {
/** The driver should initiate a power off sequence during shutdown */
bool soft_shutdown;
 
+   /** dev_name of USB charger gadget to integrate with */
+   const char *usb_gadget;
+
int irq_base;
int gpio_base;
int gpio_defaults[WM831X_GPIO_NUM];
-- 
1.7.9.5

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

[PATCH v4 3/5] gadget: Support for the usb charger framework

For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.

Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the usb charger type.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/udc/udc-core.c |8 
 include/linux/usb/gadget.h|2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index 4238fc3..370376e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct usb_udc - describes one usb device controller
@@ -437,8 +438,14 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
 
mutex_unlock(_lock);
 
+   ret = usb_charger_init(gadget);
+   if (ret)
+   goto err5;
+
return 0;
 
+err5:
+   device_del(>dev);
 err4:
list_del(>list);
mutex_unlock(_lock);
@@ -513,6 +520,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(>dev.kobj, KOBJ_REMOVE);
flush_work(>work);
device_unregister(>dev);
+   usb_charger_exit(gadget);
device_unregister(>dev);
 }
 EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 755e8bc..451ad32 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -537,6 +537,7 @@ struct usb_gadget_ops {
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
+   enum usb_charger_type (*get_charger_type)(struct usb_gadget *);
 };
 
 /**
@@ -611,6 +612,7 @@ struct usb_gadget {
struct usb_otg_caps *otg_caps;
struct raw_notifier_headnh;
struct mutexlock;
+   struct usb_charger  *charger;
 
unsignedsg_supported:1;
unsignedis_otg:1;
-- 
1.7.9.5

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

[PATCH v4 4/5] gadget: Integrate with the usb gadget supporting for usb charger

When the usb gadget supporting for usb charger is ready, the usb charger
should get the type by the 'get_charger_type' callback which is implemented
by the usb gadget operations, and get the usb charger pointer from struct
'usb_gadget'.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/charger.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
index 35b46c1..a919f38 100644
--- a/drivers/usb/gadget/charger.c
+++ b/drivers/usb/gadget/charger.c
@@ -181,6 +181,13 @@ int usb_charger_unregister_notify(struct usb_charger 
*uchger,
 enum usb_charger_type
 usb_charger_detect_type(struct usb_charger *uchger)
 {
+   if (uchger->gadget && uchger->gadget->ops
+   && uchger->gadget->ops->get_charger_type)
+   uchger->type =
+   uchger->gadget->ops->get_charger_type(uchger->gadget);
+   else
+   uchger->type = UNKNOWN_TYPE;
+
return uchger->type;
 }
 
@@ -313,7 +320,8 @@ static int
 usb_charger_plug_by_gadget(struct notifier_block *nb,
   unsigned long state, void *data)
 {
-   struct usb_charger *uchger = NULL;
+   struct usb_gadget *gadget = (struct usb_gadget *)data;
+   struct usb_charger *uchger = gadget->charger;
enum usb_charger_state uchger_state;
 
if (!uchger)
@@ -480,6 +488,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
 
/* register a notifier on a usb gadget device */
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = ugadget->state;
uchger->gadget_nb.notifier_call = usb_charger_plug_by_gadget;
usb_gadget_register_notify(ugadget, >gadget_nb);
@@ -503,7 +512,7 @@ fail:
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
-   struct usb_charger *uchger = NULL;
+   struct usb_charger *uchger = ugadget->charger;
 
if (!uchger)
return -EINVAL;
-- 
1.7.9.5

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

[ANNOUNCE] bcachefs - a general purpose COW filesystem

2015-08-20 Thread Kent Overstreet

For those who haven't kept up with bcache, the bcache codebase has been
evolving/metastasizing into a full blown, general purpose posix filesystem - a
modern COW filesystem with checksumming, compression, multiple devices, caching,
and eventually snapshots and all kinds of other nifty features.

"Yet another new filesystem? Why?"

Well, years ago (going back to when I was still at Google), I and the other
people working on bcache realized that what we were working on was, almost by
accident, a good chunk of the functionality of a full blown filesystem - and
there was a really clean and elegant design to be had there if we took it and
ran with it. And a fast one - the main goal of bcachefs to match ext4 and xfs on
performance and reliability, but with the features of btrfs/zfs.

It's taken a long time to get to this point - longer than I would have guessed
if you'd asked me back when we first started talking about it - but I'm pretty
damn proud of where it's at now.

CURRENT STATUS:

It's more or less feature complete - nothing critical should be missing. You can
try it out and play with it now, and I need more testers/users trying it out and
finding issues. It's in the bcache-dev branch, and you need the dev branch of
bcache-tools:

http://evilpiepirate.org/git/linux-bcache.git bcache-dev
http://evilpiepirate.org/git/bcache-tools.git dev

# bcacheadm format -C /dev/sda1
# mount -t bcache /dev/sda1 /mnt

(one annoyance: blkid recognizes the superblock when bcacheadm formats it, but
usually not after the first mount because it grows to over 4k after allocating
the journal, so after the first mount you need the -t bcache)

I've been focusing on stability and correctness for quite awhile now; xfstests
passes aside from a few relatively minor known issues. It probably won't eat
your data - but no promises.

Also note - the on disk format is NOT finalized yet, and won't be for awhile
though changes are infrequent at this point.

User documentation is still pretty sparse, but one thing I do want people to
look at is the internals documentation:
http://bcache.evilpiepirate.org/BcacheGuide/

FEATURES:
 - multiple devices
   (replication is like 80% done, but the recovery code still needs to be
   finished).

 - caching/tiering (naturally)
   you can format multiple devices at the same time with bcacheadm, and assign
   them to different tiers - right now only two tiers are supported, tier 0
   (default) is the fast tier and tier 1 is the slow tier. It'll effectively do
   writeback caching between tiers.

 - checksumming, compression: currently only zlib is supported for compression,
   and for checksumming there's crc32c and a 64 bit checksum. There's mount
   options for them:
   # mount -o data_checksum=crc32c,compression=gzip

   Caveat: don't try to use tiering and checksumming or compression at the same
   time yet, the read path needs to be reworked to handle both at the same time.

PLANNED FEATURES:
 - snapshots (might start on this soon)
 - erasure coding
 - native support for SMR drives, raw flash

PERFORMANCE:

I'm not really focusing on performance while there's still correctness issues to
work on - so there's lots of things that still need to be further optimized, but
the current performance numbers are still I think good enough to be interesting.

Here's some dbench numbers, running on a high end pcie flash device:

1 thread, O_SYNC:   Throughput  Max latency
bcache: 225.812 MB/sec  18.103 ms
ext4:   454.546 MB/sec  6.288 ms
xfs:268.81 MB/sec   1.094 ms
btrfs:  271.065 MB/sec  74.266 ms

20 threads, O_SYNC: Throughput  Max latency
bcache: 1050.03 MB/sec  6.614 ms
ext4:   2867.16 MB/sec  4.128 ms
xfs:3051.55 MB/sec  10.004 ms
btrfs:  665.995 MB/sec  1640.045 ms

60 threads, O_SYNC: Throughput  Max latency
bcache: 2143.45 MB/sec  15.315 ms
ext4:   2944.02 MB/sec  9.547 ms
xfs:2862.54 MB/sec  14.323 ms
btrfs:  501.248 MB/sec  8470.539 ms

1 thread:   Throughput  Max latency
bcache: 992.008 MB/sec  2.379 ms
ext4:   974.282 MB/sec  0.527 ms
xfs:715.219 MB/sec  0.527 ms
btrfs:  647.825 MB/sec  108.983 ms

20 threads: Throughput  Max latency
bcache: 3270.8 MB/sec   16.075 ms
ext4:   4879.15 MB/sec  11.098 ms
xfs:4904.26 MB/sec  20.290 ms
btrfs:  647.232 MB/sec  2679.483 ms

60 threads: Throughput  Max latency
bcache: 4644.24 MB/sec  130.980 ms
ext4:   4405.16

Re: [PATCH v3 02/11] lsm: /proc/$PID/attr/label_map file and getprocattr_seq hook

2015-08-20 Thread Paul Moore

On Fri, Jul 24, 2015 at 6:04 AM, Lukasz Pawelczyk
 wrote:
> This commit adds a new proc attribute, label_map that is required by an
> upcoming Smack namespace. In general it can be used to hold a map of
> labels, e.g. to be used in namespaces.
>
> Due to the nature of this file, the standard getprocattr hook might not
> be enough to handle it. The map's output can in principle be greater
> than page size to which the aforementioned hook is limited.
> To handle this properly a getprocattr_seq LSM hook has been added that
> makes it possible to handle any chosen proc attr by seq operations.
>
> See the documentation in the patch below for the details about how to
> use the hook.
>
> Signed-off-by: Lukasz Pawelczyk 
> ---
>  fs/proc/base.c| 81 
> +++
>  include/linux/lsm_hooks.h | 15 +
>  include/linux/security.h  |  9 ++
>  security/security.c   |  8 +
>  4 files changed, 107 insertions(+), 6 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index aa50d1a..e5ac827 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2338,20 +2338,77 @@ out:
>  }
>
>  #ifdef CONFIG_SECURITY
> +static int proc_pid_attr_open(struct inode *inode, struct file *file)
> +{
> +   const char *name = file->f_path.dentry->d_name.name;
> +   const struct seq_operations *ops;
> +   struct task_struct *task;
> +   struct seq_file *seq;
> +   int ret;
> +
> +   file->private_data = NULL;
> +
> +   task = get_proc_task(inode);
> +   if (!task)
> +   return -ESRCH;
> +
> +   /* don't use seq_ops if they are not provided by LSM */
> +   ret = security_getprocattr_seq(task, name, );
> +   if (ret == -EOPNOTSUPP) {
> +   put_task_struct(task);
> +   return 0;
> +   }
> +   if (ret) {
> +   put_task_struct(task);
> +   return ret;
> +   }
> +
> +   ret = seq_open(file, ops);
> +   if (ret) {
> +   put_task_struct(task);
> +   return ret;
> +   }
> +
> +   seq = file->private_data;
> +   seq->private = task;
> +
> +   return 0;
> +}

If you end up having to respin this patchset, you might consider
moving the "put_task_struct(...); return X;" code into a block at the
end of the function to simplify things a bit, for example:

static int proc_pid_attr_open(struct inode *inode, struct file *file)
{
   const char *name = file->f_path.dentry->d_name.name;
   const struct seq_operations *ops;
   struct task_struct *task;
   struct seq_file *seq;
   int ret;

   file->private_data = NULL;

   task = get_proc_task(inode);
   if (!task)
   return -ESRCH;

   /* don't use seq_ops if they are not provided by LSM */
   ret = security_getprocattr_seq(task, name, );
   if (ret == -EOPNOTSUPP) {
   ret = 0;
   goto put_task;
   }
   if (ret)
   goto put_task;

   ret = seq_open(file, ops);
   if (ret)
   goto put_task;

   seq = file->private_data;
   seq->private = task;

   return 0;

put_task:
   put_task_struct(task);
   return ret;
}

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

Re: [PATCH v3] pinctrl: mediatek: Fix multiple registration issue.

2015-08-20 Thread Axel Lin

2015-08-21 12:46 GMT+08:00 Hongzhou Yang :
> Since our common driver need support main chip and PMU
> at the same time, that means it will register two
> pinctrl device, and the pinctrl_desc structure should
> be used two times.
>
> But pinctrl_desc use global static definition, then
> the latest registered pinctrl device will overwrite
> the old one's, all members in pinctrl_desc will set to
> the new one's, such as name, pins and pins numbers, etc.
> This is a bug. Changing to use devm_kzalloc to fix it.
>
> Cc: sta...@vger.kernel.org # v4.1+
> Signed-off-by: Hongzhou Yang 
> ---
>  Use dynamic allocation to fix multiple registration issue.

The code looks good to me but the commit log needs fix.
You don't use devm_kzalloc now.
Just embedded struct pinctrl_desc pctl_desc to struct mtk_pinctrl.

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

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

2015-08-20 Thread Sascha Hauer

On Thu, Aug 20, 2015 at 03:20:52PM -0700, Eduardo Valentin wrote:
> On Thu, Aug 20, 2015 at 10:06:01AM +0200, Sascha Hauer wrote:
> > +
> > +   /*
> > +* These calibration values should finally be provided by the
> > +* firmware or fuses. For now use default values.
> > +*/
> > +   mt->calib_slope = -123;
> > +   mt->calib_offset = 465124;
> 
> Would it make sense to use the coefficients device tree property to
> describe the sensor slope and offset?
> 

The values shall ultimately be stored in fuses in the SoC. The current
bootloader cannot convert these values into device tree properties. Also
there is the new nvmem framework landing. This will allow us to put a
description into the device tree where in the fuses the calibration
values are found, rather than putting the calibration values themselves
into the device tree. This all needs some discussion and work, so I left
this topic for later.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/11] user_ns: 3 new LSM hooks for user namespace operations

2015-08-20 Thread Paul Moore

On Mon, Aug 3, 2015 at 9:38 PM, Kees Cook  wrote:
> On Mon, Aug 3, 2015 at 4:34 AM, Lukasz Pawelczyk
>  wrote:
>> On pią, 2015-07-31 at 22:48 -0500, Serge E. Hallyn wrote:
>>> On Fri, Jul 31, 2015 at 11:28:56AM +0200, Lukasz Pawelczyk wrote:
>>> > On czw, 2015-07-30 at 16:30 -0500, Serge E. Hallyn wrote:
>>> > > On Fri, Jul 24, 2015 at 12:04:35PM +0200, Lukasz Pawelczyk wrote:
>>> > > > @@ -969,6 +982,7 @@ static int userns_install(struct nsproxy
>>> > > > *nsproxy, struct ns_common *ns)
>>> > > >  {
>>> > > > struct user_namespace *user_ns = to_user_ns(ns);
>>> > > > struct cred *cred;
>>> > > > +   int err;
>>> > > >
>>> > > > /* Don't allow gaining capabilities by reentering
>>> > > >  * the same user namespace.
>>> > > > @@ -986,6 +1000,10 @@ static int userns_install(struct nsproxy
>>> > > > *nsproxy, struct ns_common *ns)
>>> > > > if (!ns_capable(user_ns, CAP_SYS_ADMIN))
>>> > > > return -EPERM;
>>> > > >
>>> > > > +   err = security_userns_setns(nsproxy, user_ns);
>>> > > > +   if (err)
>>> > > > +   return err;
>>> > >
>>> > > So at this point the LSM thinks current is in the new ns.  If
>>> > > prepare_creds() fails below, should it be informed of that?
>>> > > (Or am I over-thinking this?)
>>> > >
>>> > > > +
>>> > > > cred = prepare_creds();
>>> > > > if (!cred)
>>> > > > return -ENOMEM;
>>> >
>>> > Hmm, the use case for this hook I had in mind was just to allow or
>>> > disallow the operation based on the information passed in
>>> > arguments.
>>> > Not to register the current in any way so LSM can think it is or
>>> > isn't
>>> > in the new namespace.
>>> >
>>> > I think that any other LSM check that would like to know in what
>>> > namespace the current is, would just check that from current's
>>> > creds.
>>> > Not use some stale and duplicated information the above hook could
>>> > have
>>> > registered.
>>> >
>>> > I see no reason for this hook to change the LSM state, only to
>>> > answer
>>> > the question: allowed/disallowed (eventually return an error cause
>>> > it
>>> > is unable to give an answer which falls into the disallow
>>> > category).
>>>
>>> How about renaming it "security_userns_may_setns()" for clarity?
>>
>> I personally have nothing against it. However looking at already
>> existing hooks only one of them has "may" in the name (unix_may_send)
>> while a lot clearly have exactly this purpose (e.g. most of inode_*
>> family, some from file_* and task_*). So it seems the trend is against
>> it.
>>
>> What do you think? Anyone else has an opinion?
>
> Personally, I prefer that hooks be named as closely to their caller,
> or calling context, as possible. In this case, it seems like "may" is
> implied. It's an LSM like all the others, so it can fail, which would
> cause the caller to fail too, so "may" tends to be implicit. I would
> leave it as-is, but I could be convinced otherwise.

I agree with Kees, sticking as close as possible to the general format
of "security_" for LSM hooks makes it easier when
reading/reviewing code.

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

[PATCH] x86/traps: Weaken context tracking entry assertions

2015-08-20 Thread Andy Lutomirski

We were asserting that we were all the way in CONTEXT_KERNEL when
exception handlers were called.  While having this be true is, I
think, a nice goal (or maybe a variant in which we assert that we're
in CONTEXT_KERNEL or some new IRQ context), we're not quite there.

In particular, if an IRQ interrupts the SYSCALL prologue and the IRQ
handler in turn causes an exception, the exception entry will be
called in RCU IRQ mode but with CONTEXT_USER.

This is okay (nothing goes wrong), but until we fix up the SYSCALL
prologue, we need to avoid warning.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/traps.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 86a82eafb96f..45e8d9891fa3 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -112,7 +112,7 @@ static inline void preempt_conditional_cli(struct pt_regs 
*regs)
 void ist_enter(struct pt_regs *regs)
 {
if (user_mode(regs)) {
-   CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+   rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake 
RCU");
} else {
/*
 * We might have interrupted pretty much anything.  In
@@ -282,7 +282,7 @@ static void do_error_trap(struct pt_regs *regs, long 
error_code, char *str,
 {
siginfo_t info;
 
-   CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+   rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
 
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
NOTIFY_STOP) {
@@ -364,7 +364,7 @@ dotraplinkage void do_bounds(struct pt_regs *regs, long 
error_code)
const struct bndcsr *bndcsr;
siginfo_t *info;
 
-   CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+   rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
if (notify_die(DIE_TRAP, "bounds", regs, error_code,
X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP)
return;
@@ -442,7 +442,7 @@ do_general_protection(struct pt_regs *regs, long error_code)
 {
struct task_struct *tsk;
 
-   CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+   rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
conditional_sti(regs);
 
if (v8086_mode(regs)) {
@@ -496,7 +496,7 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, 
long error_code)
return;
 
ist_enter(regs);
-   CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+   rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
 #ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
SIGTRAP) == NOTIFY_STOP)
@@ -729,14 +729,14 @@ static void math_error(struct pt_regs *regs, int 
error_code, int trapnr)
 
 dotraplinkage void do_coprocessor_error(struct pt_regs *regs, long error_code)
 {
-   CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+   rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
math_error(regs, error_code, X86_TRAP_MF);
 }
 
 dotraplinkage void
 do_simd_coprocessor_error(struct pt_regs *regs, long error_code)
 {
-   CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+   rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
math_error(regs, error_code, X86_TRAP_XF);
 }
 
@@ -749,7 +749,7 @@ do_spurious_interrupt_bug(struct pt_regs *regs, long 
error_code)
 dotraplinkage void
 do_device_not_available(struct pt_regs *regs, long error_code)
 {
-   CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+   rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
BUG_ON(use_eager_fpu());
 
 #ifdef CONFIG_MATH_EMULATION
@@ -775,7 +775,7 @@ dotraplinkage void do_iret_error(struct pt_regs *regs, long 
error_code)
 {
siginfo_t info;
 
-   CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+   rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
local_irq_enable();
 
info.si_signo = SIGILL;
-- 
2.4.3

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

Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x

2015-08-20 Thread Varadarajan Narayanan

On Thu, Aug 20, 2015 at 08:54:55PM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 20, 2015 at 12:20:10PM -0500, Andy Gross wrote:
> > On Thu, Aug 20, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote:
> > > > RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used
> > > > for Shared Memory and the kernel can start from 0x4150.
> > >
> > > Why do people keep creating crap like this?  Each time something like
> > > this is created, it means that you _need_ to have a special kernel for
> > > your platform and you can't be part of the single zImage.
> > >
> > > Please, rather than creating crap like this, find a better way.
> >
> > In the case of the IPQ, we don't use the zImage because the decompress
> > requires a larger jump than we can do on that platform.  Having this
> > change at least gets us back 2MB of memory.
>
> Your argument about "a larger jump" makes no sense what so ever.  The
> branches between the decompressor and the main kernel are all done
> using a mov, which can jump to any 32-bit address.
>
> Even if you load the compressed kernel image at 0x4150, the
> decompressor will mask that with 0xf800, and decide that RAM
> starts at 0x4000.  It will then want to place the decompressed
> kernel image at 0x40008000.  Nothing there has anything to do with
> jump ranges.

With the qcom_defconfig, the kernel gets loaded at
0x40008000. This region is reserved for NSS.

> The only restriction that the ARM has as far as jump ranges are
> concerned is the 'b' or 'bl' instruction, which in ARM mode is
> limited to +/- 32MB.  That doesn't apply here since we don't use
> that to jump between the decompressor and the decompressed kernel
> image.
>
> So...
>
> Why is it necessary to have this 21MB block of shared memory at
> the start of RAM?  Why can't it be reserved by other means higher
> up in system memory?

The NSS subsystem needs memory to be reserved at 0x4000.
The Ubi32 cores (part of NSS) need low address memory close
to the Ubi32 address space to do short calls from what is
called Ubi32 On Chip Memory to DDR and back again.  Since
there isn't a way to circumvent this restriction had to
reserve at 0x4000.

-Varada

> It's up to the submitter to justify why any change is required, and
> in this case, part of that justification is why the shared memory is
> placed at the start of RAM, and why you need to be different from
> almost everyone else, and why you need to be a special case.  The
> justification also must make sense.
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] KVM: x86: add pcommit support

Pass PCOMMIT CPU feature to guest to enable PCOMMIT instruction

Currently we do not catch pcommit instruction for L1 guest and
allow L1 to catch this instruction for L2

The specification locates at:
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf

Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/vmx.h  |  2 +-
 arch/x86/include/uapi/asm/vmx.h |  4 +++-
 arch/x86/kvm/cpuid.c|  2 +-
 arch/x86/kvm/cpuid.h|  8 
 arch/x86/kvm/vmx.c  | 29 -
 5 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 9299ae5..e2ad08a 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -72,7 +72,7 @@
 #define SECONDARY_EXEC_SHADOW_VMCS  0x4000
 #define SECONDARY_EXEC_ENABLE_PML   0x0002
 #define SECONDARY_EXEC_XSAVES  0x0010
-
+#define SECONDARY_EXEC_PCOMMIT 0x0020
 
 #define PIN_BASED_EXT_INTR_MASK 0x0001
 #define PIN_BASED_NMI_EXITING   0x0008
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index 37fee27..5b15d94 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -78,6 +78,7 @@
 #define EXIT_REASON_PML_FULL62
 #define EXIT_REASON_XSAVES  63
 #define EXIT_REASON_XRSTORS 64
+#define EXIT_REASON_PCOMMIT 65
 
 #define VMX_EXIT_REASONS \
{ EXIT_REASON_EXCEPTION_NMI, "EXCEPTION_NMI" }, \
@@ -126,7 +127,8 @@
{ EXIT_REASON_INVVPID,   "INVVPID" }, \
{ EXIT_REASON_INVPCID,   "INVPCID" }, \
{ EXIT_REASON_XSAVES,"XSAVES" }, \
-   { EXIT_REASON_XRSTORS,   "XRSTORS" }
+   { EXIT_REASON_XRSTORS,   "XRSTORS" }, \
+   { EXIT_REASON_PCOMMIT,   "PCOMMIT" }
 
 #define VMX_ABORT_SAVE_GUEST_MSR_FAIL1
 #define VMX_ABORT_LOAD_HOST_MSR_FAIL 4
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 962fc7d..faeb0b3 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -348,7 +348,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
F(FSGSBASE) | F(BMI1) | F(HLE) | F(AVX2) | F(SMEP) |
F(BMI2) | F(ERMS) | f_invpcid | F(RTM) | f_mpx | F(RDSEED) |
F(ADX) | F(SMAP) | F(AVX512F) | F(AVX512PF) | F(AVX512ER) |
-   F(AVX512CD) | F(CLFLUSHOPT) | F(CLWB);
+   F(AVX512CD) | F(CLFLUSHOPT) | F(CLWB) | F(PCOMMIT);
 
/* cpuid 0xD.1.eax */
const u32 kvm_supported_word10_x86_features =
diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index dd05b9c..aed7bfe 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -133,4 +133,12 @@ static inline bool guest_cpuid_has_mpx(struct kvm_vcpu 
*vcpu)
best = kvm_find_cpuid_entry(vcpu, 7, 0);
return best && (best->ebx & bit(X86_FEATURE_MPX));
 }
+
+static inline bool guest_cpuid_has_pcommit(struct kvm_vcpu *vcpu)
+{
+   struct kvm_cpuid_entry2 *best;
+
+   best = kvm_find_cpuid_entry(vcpu, 7, 0);
+   return best && (best->ebx & bit(X86_FEATURE_PCOMMIT));
+}
 #endif
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4cf25b9..b526c61 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2474,7 +2474,8 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx 
*vmx)
SECONDARY_EXEC_APIC_REGISTER_VIRT |
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
SECONDARY_EXEC_WBINVD_EXITING |
-   SECONDARY_EXEC_XSAVES;
+   SECONDARY_EXEC_XSAVES |
+   SECONDARY_EXEC_PCOMMIT;
 
if (enable_ept) {
/* nested EPT: emulate EPT also to L1 */
@@ -3015,7 +3016,8 @@ static __init int setup_vmcs_config(struct vmcs_config 
*vmcs_conf)
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
SECONDARY_EXEC_SHADOW_VMCS |
SECONDARY_EXEC_XSAVES |
-   SECONDARY_EXEC_ENABLE_PML;
+   SECONDARY_EXEC_ENABLE_PML |
+   SECONDARY_EXEC_PCOMMIT;
if (adjust_vmx_controls(min2, opt2,
MSR_IA32_VMX_PROCBASED_CTLS2,
&_cpu_based_2nd_exec_control) < 0)
@@ -4570,6 +4572,9 @@ static u32 vmx_secondary_exec_control(struct vcpu_vmx 
*vmx)
/* PML is enabled/disabled in creating/destorying vcpu */
exec_control &= ~SECONDARY_EXEC_ENABLE_PML;
 
+   /* Currently, we allow L1 guest to directly run pcommit instruction. */
+   exec_control &= ~SECONDARY_EXEC_PCOMMIT;
+
return exec_control;
 }
 
@@ -4613,10 +4618,9 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)

[PATCH 5/9] KVM: VMX: simplify rdtscp handling in vmx_cpuid_update()

if vmx_rdtscp_supported() is true SECONDARY_EXEC_RDTSCP must
have already been set in current vmcs by
vmx_secondary_exec_control()

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/vmx.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index f7a721e..99f638e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8668,16 +8668,15 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
vmx->rdtscp_enabled = false;
if (vmx_rdtscp_supported()) {
exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
-   if (exec_control & SECONDARY_EXEC_RDTSCP) {
-   best = kvm_find_cpuid_entry(vcpu, 0x8001, 0);
-   if (best && (best->edx & bit(X86_FEATURE_RDTSCP)))
-   vmx->rdtscp_enabled = true;
-   else {
-   exec_control &= ~SECONDARY_EXEC_RDTSCP;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
-   exec_control);
-   }
+   best = kvm_find_cpuid_entry(vcpu, 0x8001, 0);
+   if (best && (best->edx & bit(X86_FEATURE_RDTSCP)))
+   vmx->rdtscp_enabled = true;
+   else {
+   exec_control &= ~SECONDARY_EXEC_RDTSCP;
+   vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
+   exec_control);
}
+
if (nested && !vmx->rdtscp_enabled)
vmx->nested.nested_vmx_secondary_ctls_high &=
~SECONDARY_EXEC_RDTSCP;
-- 
2.4.3

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

[PATCH 4/9] KVM: VMX: drop rdtscp_enabled check in prepare_vmcs02()

SECONDARY_EXEC_RDTSCP set for L2 guest comes from vmcs12

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/vmx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index b526c61..f7a721e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9313,8 +9313,7 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu, struct 
vmcs12 *vmcs12)
 
if (cpu_has_secondary_exec_ctrls()) {
exec_control = vmx_secondary_exec_control(vmx);
-   if (!vmx->rdtscp_enabled)
-   exec_control &= ~SECONDARY_EXEC_RDTSCP;
+
/* Take the following fields only from vmcs12 */
exec_control &= ~(SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
  SECONDARY_EXEC_RDTSCP |
-- 
2.4.3

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

[PATCH 6/9] KVM: VMX: simplify invpcid handling in vmx_cpuid_update()

If vmx_invpcid_supported() is true, second execution control
filed must be supported and SECONDARY_EXEC_ENABLE_INVPCID
must have already been set in current vmcs by
vmx_secondary_exec_control()

If vmx_invpcid_supported() is false, no need to clear
SECONDARY_EXEC_ENABLE_INVPCID

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/vmx.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 99f638e..0d68140 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8684,20 +8684,13 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
 
/* Exposing INVPCID only when PCID is exposed */
best = kvm_find_cpuid_entry(vcpu, 0x7, 0);
-   if (vmx_invpcid_supported() &&
-   best && (best->ebx & bit(X86_FEATURE_INVPCID)) &&
-   guest_cpuid_has_pcid(vcpu)) {
+   if (vmx_invpcid_supported() && (!best ||
+   !(best->ebx & bit(X86_FEATURE_INVPCID)) ||
+   !guest_cpuid_has_pcid(vcpu))) {
exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
-   exec_control |= SECONDARY_EXEC_ENABLE_INVPCID;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
-exec_control);
-   } else {
-   if (cpu_has_secondary_exec_ctrls()) {
-   exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
-   exec_control &= ~SECONDARY_EXEC_ENABLE_INVPCID;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
-exec_control);
-   }
+   exec_control &= ~SECONDARY_EXEC_ENABLE_INVPCID;
+   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
+
if (best)
best->ebx &= ~bit(X86_FEATURE_INVPCID);
}
-- 
2.4.3

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

[PATCH 8/9] KVM: VMX: introduce set_clear_2nd_exec_ctrl()

It's used to clean up the code

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/vmx.c | 42 +++---
 1 file changed, 19 insertions(+), 23 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4f238b7..58f7b89 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4589,6 +4589,18 @@ static void ept_set_mmio_spte_mask(void)
kvm_mmu_set_mmio_spte_mask((0x3ull << 62) | 0x6ull);
 }
 
+static void set_clear_2nd_exec_ctrl(u32 ctrls, bool set)
+{
+   u32 exec_ctrl = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
+
+   if (set)
+   exec_ctrl |= ctrls;
+   else
+   exec_ctrl &= ~ctrls;
+
+   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_ctrl);
+}
+
 #define VMX_XSS_EXIT_BITMAP 0
 /*
  * Sets up the vmcs for emulated real mode.
@@ -6632,7 +6644,6 @@ static int nested_vmx_check_permission(struct kvm_vcpu 
*vcpu)
 
 static inline void nested_release_vmcs12(struct vcpu_vmx *vmx)
 {
-   u32 exec_control;
if (vmx->nested.current_vmptr == -1ull)
return;
 
@@ -6645,9 +6656,7 @@ static inline void nested_release_vmcs12(struct vcpu_vmx 
*vmx)
   they were modified */
copy_shadow_to_vmcs12(vmx);
vmx->nested.sync_shadow_vmcs = false;
-   exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
-   exec_control &= ~SECONDARY_EXEC_SHADOW_VMCS;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
+   set_clear_2nd_exec_ctrl(SECONDARY_EXEC_SHADOW_VMCS, false);
vmcs_write64(VMCS_LINK_POINTER, -1ull);
}
vmx->nested.posted_intr_nv = -1;
@@ -7043,7 +7052,6 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
gpa_t vmptr;
-   u32 exec_control;
 
if (!nested_vmx_check_permission(vcpu))
return 1;
@@ -7075,9 +7083,8 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
vmx->nested.current_vmcs12 = new_vmcs12;
vmx->nested.current_vmcs12_page = page;
if (enable_shadow_vmcs) {
-   exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
-   exec_control |= SECONDARY_EXEC_SHADOW_VMCS;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
+   set_clear_2nd_exec_ctrl(SECONDARY_EXEC_SHADOW_VMCS,
+   true);
vmcs_write64(VMCS_LINK_POINTER,
 __pa(vmx->nested.current_shadow_vmcs));
vmx->nested.sync_shadow_vmcs = true;
@@ -7587,7 +7594,6 @@ static void vmx_get_exit_info(struct kvm_vcpu *vcpu, u64 
*info1, u64 *info2)
 static int vmx_enable_pml(struct vcpu_vmx *vmx)
 {
struct page *pml_pg;
-   u32 exec_control;
 
pml_pg = alloc_page(GFP_KERNEL | __GFP_ZERO);
if (!pml_pg)
@@ -7598,24 +7604,18 @@ static int vmx_enable_pml(struct vcpu_vmx *vmx)
vmcs_write64(PML_ADDRESS, page_to_phys(vmx->pml_pg));
vmcs_write16(GUEST_PML_INDEX, PML_ENTITY_NUM - 1);
 
-   exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
-   exec_control |= SECONDARY_EXEC_ENABLE_PML;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
+   set_clear_2nd_exec_ctrl(SECONDARY_EXEC_ENABLE_PML, true);
 
return 0;
 }
 
 static void vmx_disable_pml(struct vcpu_vmx *vmx)
 {
-   u32 exec_control;
-
ASSERT(vmx->pml_pg);
__free_page(vmx->pml_pg);
vmx->pml_pg = NULL;
 
-   exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
-   exec_control &= ~SECONDARY_EXEC_ENABLE_PML;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
+   set_clear_2nd_exec_ctrl(SECONDARY_EXEC_ENABLE_PML, false);
 }
 
 static void vmx_flush_pml_buffer(struct kvm_vcpu *vcpu)
@@ -8689,12 +8689,8 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
best->ebx &= ~bit(X86_FEATURE_INVPCID);
}
 
-   if (clear_exe_ctrl) {
-   u32 exec_ctl = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
-
-   exec_ctl &= ~clear_exe_ctrl;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_ctl);
-   }
+   if (clear_exe_ctrl)
+   set_clear_2nd_exec_ctrl(clear_exe_ctrl, false);
 
if (!guest_cpuid_has_pcommit(vcpu) && nested)
vmx->nested.nested_vmx_secondary_ctls_high &=
-- 
2.4.3

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

[PATCH 7/9] KVM: VMX: unify SECONDARY_VM_EXEC_CONTROL update

Unify the update in vmx_cpuid_update()

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/vmx.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 0d68140..4f238b7 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8663,19 +8663,15 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
 {
struct kvm_cpuid_entry2 *best;
struct vcpu_vmx *vmx = to_vmx(vcpu);
-   u32 exec_control;
+   u32 clear_exe_ctrl = 0;
 
vmx->rdtscp_enabled = false;
if (vmx_rdtscp_supported()) {
-   exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
best = kvm_find_cpuid_entry(vcpu, 0x8001, 0);
if (best && (best->edx & bit(X86_FEATURE_RDTSCP)))
vmx->rdtscp_enabled = true;
-   else {
-   exec_control &= ~SECONDARY_EXEC_RDTSCP;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
-   exec_control);
-   }
+   else
+   clear_exe_ctrl |= SECONDARY_EXEC_RDTSCP;
 
if (nested && !vmx->rdtscp_enabled)
vmx->nested.nested_vmx_secondary_ctls_high &=
@@ -8687,14 +8683,19 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
if (vmx_invpcid_supported() && (!best ||
!(best->ebx & bit(X86_FEATURE_INVPCID)) ||
!guest_cpuid_has_pcid(vcpu))) {
-   exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
-   exec_control &= ~SECONDARY_EXEC_ENABLE_INVPCID;
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
+   clear_exe_ctrl |= SECONDARY_EXEC_ENABLE_INVPCID;
 
if (best)
best->ebx &= ~bit(X86_FEATURE_INVPCID);
}
 
+   if (clear_exe_ctrl) {
+   u32 exec_ctl = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
+
+   exec_ctl &= ~clear_exe_ctrl;
+   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_ctl);
+   }
+
if (!guest_cpuid_has_pcommit(vcpu) && nested)
vmx->nested.nested_vmx_secondary_ctls_high &=
~SECONDARY_EXEC_PCOMMIT;
-- 
2.4.3

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

[PATCH 9/9] KVM: VMX: drop rdtscp_enabled field

Check cpuid bit instead of it

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/cpuid.h |  8 
 arch/x86/kvm/vmx.c   | 19 ++-
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index aed7bfe..d434ee9 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -141,4 +141,12 @@ static inline bool guest_cpuid_has_pcommit(struct kvm_vcpu 
*vcpu)
best = kvm_find_cpuid_entry(vcpu, 7, 0);
return best && (best->ebx & bit(X86_FEATURE_PCOMMIT));
 }
+
+static inline bool guest_cpuid_has_rdtscp(struct kvm_vcpu *vcpu)
+{
+   struct kvm_cpuid_entry2 *best;
+
+   best = kvm_find_cpuid_entry(vcpu, 0x8001, 0);
+   return best && (best->edx & bit(X86_FEATURE_RDTSCP));
+}
 #endif
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 58f7b89..d50fb48 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -532,8 +532,6 @@ struct vcpu_vmx {
s64 vnmi_blocked_time;
u32 exit_reason;
 
-   bool rdtscp_enabled;
-
/* Posted interrupt descriptor */
struct pi_desc pi_desc;
 
@@ -2207,7 +2205,7 @@ static void setup_msrs(struct vcpu_vmx *vmx)
if (index >= 0)
move_msr_up(vmx, index, save_nmsrs++);
index = __find_msr_index(vmx, MSR_TSC_AUX);
-   if (index >= 0 && vmx->rdtscp_enabled)
+   if (index >= 0 && guest_cpuid_has_rdtscp(>vcpu))
move_msr_up(vmx, index, save_nmsrs++);
/*
 * MSR_STAR is only needed on long mode guests, and only
@@ -2674,7 +2672,7 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
msr_info->data = vcpu->arch.ia32_xss;
break;
case MSR_TSC_AUX:
-   if (!to_vmx(vcpu)->rdtscp_enabled)
+   if (!guest_cpuid_has_rdtscp(vcpu))
return 1;
/* Otherwise falls through */
default:
@@ -2780,7 +2778,7 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
clear_atomic_switch_msr(vmx, MSR_IA32_XSS);
break;
case MSR_TSC_AUX:
-   if (!vmx->rdtscp_enabled)
+   if (!guest_cpuid_has_rdtscp(vcpu))
return 1;
/* Check reserved bit, higher 32 bits should be zero */
if ((data >> 32) != 0)
@@ -8665,15 +8663,10 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
struct vcpu_vmx *vmx = to_vmx(vcpu);
u32 clear_exe_ctrl = 0;
 
-   vmx->rdtscp_enabled = false;
-   if (vmx_rdtscp_supported()) {
-   best = kvm_find_cpuid_entry(vcpu, 0x8001, 0);
-   if (best && (best->edx & bit(X86_FEATURE_RDTSCP)))
-   vmx->rdtscp_enabled = true;
-   else
-   clear_exe_ctrl |= SECONDARY_EXEC_RDTSCP;
+   if (vmx_rdtscp_supported() && !guest_cpuid_has_rdtscp(vcpu)) {
+   clear_exe_ctrl |= SECONDARY_EXEC_RDTSCP;
 
-   if (nested && !vmx->rdtscp_enabled)
+   if (nested)
vmx->nested.nested_vmx_secondary_ctls_high &=
~SECONDARY_EXEC_RDTSCP;
}
-- 
2.4.3

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

[PATCH 0/9] KVM: x86: enable cflushopt/clwb/pcommit and simplify code

This pachset enables clfushopt, clwb and pcommit instructions for guest which
are used by NVDIMM.

The specification locates at:
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf

Patch 1 fixes a uninitialized value used in KVM MMU code,
patch 2 and patch 3 enable these three instructions for guest
patch 4 ~ patch 9 simplify current VMX code
 
Xiao Guangrong (9):
  KVM: MMU: fix use uninitialized value
  KVM: x86: allow guest to use cflushopt anc clwb
  KVM: x86: add pcommit support
  KVM: VMX: drop rdtscp_enabled check in prepare_vmcs02()
  KVM: VMX: simplify rdtscp handling in vmx_cpuid_update()
  KVM: VMX: simplify invpcid handling in vmx_cpuid_update()
  KVM: VMX: unify SECONDARY_VM_EXEC_CONTROL update
  KVM: VMX: introduce set_clear_2nd_exec_ctrl()
  KVM: VMX: drop rdtscp_enabled field

 arch/x86/include/asm/vmx.h  |   2 +-
 arch/x86/include/uapi/asm/vmx.h |   4 +-
 arch/x86/kvm/cpuid.c|   2 +-
 arch/x86/kvm/cpuid.h|  16 ++
 arch/x86/kvm/mmu.c  |   2 +-
 arch/x86/kvm/vmx.c  | 116 
 6 files changed, 80 insertions(+), 62 deletions(-)

-- 
2.4.3

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

[PATCH 1/9] KVM: MMU: fix use uninitialized value

GCC (gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)) complains
of this warning:

arch/x86/kvm//mmu.c:3332:9: warning: ‘leaf’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
   while (root >= leaf) {
 ^
arch/x86/kvm//mmu.c:3304:12: note: ‘leaf’ was declared here
  int root, leaf;

It's true as shadow_walk_init() may stop the loop

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 70c375f..a8a5b8d 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3301,7 +3301,7 @@ walk_shadow_page_get_mmio_spte(struct kvm_vcpu *vcpu, u64 
addr, u64 *sptep)
 {
struct kvm_shadow_walk_iterator iterator;
u64 sptes[PT64_ROOT_LEVEL], spte = 0ull;
-   int root, leaf;
+   int root, leaf = PT64_ROOT_LEVEL;
bool reserved = false;
 
if (!VALID_PAGE(vcpu->arch.mmu.root_hpa))
-- 
2.4.3

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

[PATCH 2/9] KVM: x86: allow guest to use cflushopt anc clwb

Pass its CPU feature to guest to enable them in guest

These are needed by nvdimm drivers

The specification locates at:
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/cpuid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 2fbea25..962fc7d 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -348,7 +348,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
F(FSGSBASE) | F(BMI1) | F(HLE) | F(AVX2) | F(SMEP) |
F(BMI2) | F(ERMS) | f_invpcid | F(RTM) | f_mpx | F(RDSEED) |
F(ADX) | F(SMAP) | F(AVX512F) | F(AVX512PF) | F(AVX512ER) |
-   F(AVX512CD);
+   F(AVX512CD) | F(CLFLUSHOPT) | F(CLWB);
 
/* cpuid 0xD.1.eax */
const u32 kvm_supported_word10_x86_features =
-- 
2.4.3

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

Re: RX packet loss on i.MX6Q running 4.2-rc7

2015-08-20 Thread Jon Nettleton

On Fri, Aug 21, 2015 at 12:30 AM, Clemens Gruber
 wrote:
> Hi,
>
> I am experiencing massive RX packet loss on my i.MX6Q (Chip rev 1.3) on Linux
> 4.2-rc7 with a Marvell 88E1510 Gigabit Ethernet PHY connected over RGMII.
> I noticed it when doing an UDP benchmark with iperf3. When sending UDP packets
> from a Debian PC to the i.MX6 with a rate of 100 Mbit/s, 99% of the packets 
> are
> lost. With a rate of 10 Mbit/s, we are still losing 93% of all packets. TCP RX
> does suffer from packet loss too, but still achieves about 211 Mbit/s.
> TX is not affected.
>
> Steps to reproduce:
> On the i.MX6: iperf3 -s
> On a desktop PC:  iperf3 -b 10M -u -c MX6IP
>
> The iperf3 results:
> [ ID] Interval   Transfer Bandwidth   JitterLost/Total
> [  4]   0.00-10.00  sec  11.8 MBytes  9.90 Mbits/sec  0.687 ms  1397/1497 
> (93%)
>
> During the 10 Mbit UDP test, the IEEE_rx_macerr counter increased to 5371.
> ifconfig eth0 shows:
>  RX packets:9216 errors:5248 dropped:170 overruns:5248 frame:5248
>  TX packets:83 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0
>
> Here are the TCP results with iperf3 -c MX6IP:
> [ ID] Interval   Transfer Bandwidth   Retr
> [  4]   0.00-10.00  sec   252 MBytes   211 Mbits/sec  4343 sender
> [  4]   0.00-10.00  sec   251 MBytes   211 Mbits/sec  receiver
>
> During the TCP test, IEEE_rx_macerr increased to 4059.
> ifconfig eth0 shows:
> RX packets:186368 errors:4206 dropped:50 overruns:4206 frame:4206
> TX packets:41861 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0
>
> Freescale errata entry ERR004512 did mention a RX FIFO overrun. Is this 
> related?
>
> Forcing pause frames via ethtool -A eth0 rx on tx on, does not improve it:
> Same amount of UDP packet loss with reduced TCP throughput of 190 Mbit/s.
> IEEE_rx_macerr increased up to 5232 during UDP 10Mbit and up to 4270 for TCP.
>
> I am already using the MX6QDL_PAD_GPIO_6__ENET_IRQ workaround, which solved 
> the
> ping latency issues from ERR006687 but not the packet loss problem.
>
> I read through the mailing list archives and found a discussion between 
> Russell
> King, Marek Vasut, Eric Nelson, Fugang Duan and others about a similar 
> problem.
> I therefore added you and contributors to fec_main.c to the CC.
>
> One suggestion I found, was adding udelay(210); to fec_enet_rx():
> https://lkml.org/lkml/2014/8/22/88
> But this also did not reduce the packet loss. (I added it to the fec_enet_rx
> function just before return pkt_received; but I still got 93% packet loss)
>
> Does anyone have the equipment/setup to trace an i.MX6Q during UDP RX traffic
> from iperf3 to find the root cause of this packet loss problem?
>
> What else could we do to fix this?
>

This is a bug in iperf3's UDP tests.  Do the same test with iperf2 and
you will see expected performance.  I believe there is a bug open in
github about it.

-Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: mediatek: Fix multiple registration issue.

2015-08-20 Thread Hongzhou Yang

Since our common driver need support main chip and PMU
at the same time, that means it will register two
pinctrl device, and the pinctrl_desc structure should
be used two times.

But pinctrl_desc use global static definition, then
the latest registered pinctrl device will overwrite
the old one's, all members in pinctrl_desc will set to
the new one's, such as name, pins and pins numbers, etc.
This is a bug. Changing to use devm_kzalloc to fix it.

Cc: sta...@vger.kernel.org # v4.1+
Signed-off-by: Hongzhou Yang 
---
 Use dynamic allocation to fix multiple registration issue.

 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |   21 ++---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.h |1 +
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ad1ea16..4a52072 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1202,12 +1202,6 @@ static int mtk_pctrl_build_state(struct platform_device 
*pdev)
return 0;
 }
 
-static struct pinctrl_desc mtk_pctrl_desc = {
-   .confops= _pconf_ops,
-   .pctlops= _pctrl_ops,
-   .pmxops = _pmx_ops,
-};
-
 int mtk_pctrl_init(struct platform_device *pdev,
const struct mtk_pinctrl_devdata *data,
struct regmap *regmap)
@@ -1265,12 +1259,17 @@ int mtk_pctrl_init(struct platform_device *pdev,
 
for (i = 0; i < pctl->devdata->npins; i++)
pins[i] = pctl->devdata->pins[i].pin;
-   mtk_pctrl_desc.name = dev_name(>dev);
-   mtk_pctrl_desc.owner = THIS_MODULE;
-   mtk_pctrl_desc.pins = pins;
-   mtk_pctrl_desc.npins = pctl->devdata->npins;
+
+   pctl->pctl_desc.name = dev_name(>dev);
+   pctl->pctl_desc.owner = THIS_MODULE;
+   pctl->pctl_desc.pins = pins;
+   pctl->pctl_desc.npins = pctl->devdata->npins;
+   pctl->pctl_desc.confops = _pconf_ops;
+   pctl->pctl_desc.pctlops = _pctrl_ops;
+   pctl->pctl_desc.pmxops = _pmx_ops;
pctl->dev = >dev;
-   pctl->pctl_dev = pinctrl_register(_pctrl_desc, >dev, pctl);
+
+   pctl->pctl_dev = pinctrl_register(>pctl_desc, >dev, pctl);
if (IS_ERR(pctl->pctl_dev)) {
dev_err(>dev, "couldn't register pinctrl driver\n");
return PTR_ERR(pctl->pctl_dev);
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.h
index 30213e5..c532c23 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.h
@@ -256,6 +256,7 @@ struct mtk_pinctrl_devdata {
 struct mtk_pinctrl {
struct regmap   *regmap1;
struct regmap   *regmap2;
+   struct pinctrl_desc pctl_desc;
struct device   *dev;
struct gpio_chip*chip;
struct mtk_pinctrl_group*groups;
-- 
1.7.9.5

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

Re: [x86] copy_from{to}_user question

2015-08-20 Thread Borislav Petkov

On Thu, Aug 20, 2015 at 11:22:43AM -0700, H. Peter Anvin wrote:
> There is a valid reason to do this, which is that currently
> copy_{to,from}_user() effectively bypass SMAP as they don't verify that
> the kernel pointer is actually a kernel pointer.

Well, we do STAC before we copy but SMAP is checking for supervisor
access to *user* data. But you say "kernel pointers" which is supervisor
data. What am I missing?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: build failure after merge of the spi tree

Hi Mark,

After merging the spi tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from include/linux/clk.h:16:0,
 from drivers/spi/spi-sun4i.c:14:
drivers/spi/spi-sun4i.c: In function 'sun4i_spi_transfer_one':
drivers/spi/spi-sun4i.c:283:43: error: 'speed' undeclared (first use in this 
function)
  tx_time = max_t(int, tfr->len * 8 * 2 / (speed / 1000), 100);
   ^
include/linux/kernel.h:767:17: note: in definition of macro 'max_t'
  type __max1 = (x);   \
 ^
drivers/spi/spi-sun4i.c:283:43: note: each undeclared identifier is reported 
only once for each function it appears in
  tx_time = max_t(int, tfr->len * 8 * 2 / (speed / 1000), 100);
   ^
include/linux/kernel.h:767:17: note: in definition of macro 'max_t'
  type __max1 = (x);   \
 ^
In file included from include/linux/clk.h:16:0,
 from drivers/spi/spi-sun6i.c:14:
drivers/spi/spi-sun6i.c: In function 'sun6i_spi_transfer_one':
drivers/spi/spi-sun6i.c:273:43: error: 'speed' undeclared (first use in this 
function)
  tx_time = max_t(int, tfr->len * 8 * 2 / (speed / 1000), 100);
   ^
include/linux/kernel.h:767:17: note: in definition of macro 'max_t'
  type __max1 = (x);   \
 ^
drivers/spi/spi-sun6i.c:273:43: note: each undeclared identifier is reported 
only once for each function it appears in
  tx_time = max_t(int, tfr->len * 8 * 2 / (speed / 1000), 100);
   ^
include/linux/kernel.h:767:17: note: in definition of macro 'max_t'
  type __max1 = (x);   \
 ^

Caused by commit

  63d53d153b62 ("spi: sunxi: fix transfer timeout")

I have used the spi tree from next-20150820 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [4.2-rc7][Haswell] NMI soft lockup - try_to_del_timer_sync

2015-08-20 Thread Eric Dumazet

On Thu, 2015-08-20 at 22:43 -0400, Shawn Starr wrote:
> Hello folks,
> 
> I was just using KVM and doing some VM work on my laptop when it locked up 
> system fully, here is the kernel trace below (it repeats after the second 
> dump)
> 
> Since we're soon 'close' to 4.2 final, maybe someone can check if something 
> regressed? Never saw this in eariler -rcX builds.
> 
> Thanks,
> Shawn.

pull again your git tree.

This was fixed with
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af


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

Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device

2015-08-20 Thread Gabriel L. Somlo

On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote:
> On 19 August 2015 at 22:49, Gabriel L. Somlo  wrote:
> >> > From: "Gabriel L. Somlo" 
> >> >> Several different architectures supported by QEMU are set up with a
> >> >> "firmware configuration" (fw_cfg) device, used to pass configuration
> >> >> "blobs" into the guest by the host running QEMU.
> >> >>
> >> >> Historically, these config blobs were mostly of interest to the guest
> >> >> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
> >> >> the command line, which makes them potentially interesting to userspace
> >> >> (e.g. for passing early boot environment variables, etc.).
> >> >>
> >> >
> >> > Does 'potentially interesting' mean you have a use case? Could you 
> >> > elaborate?
> >
> > My personal one would be something like:
> >
> > cat > guestinfo.txt << EOT
> >   KEY1="val1"
> >   KEY2="val2"
> >   ...
> > EOT
> >
> > qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
> >
> > Then, from inside the guest:
> >
> >   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
> >
> >   do_something_with $KEY1 $KEY2
> >   ...
> >
> > But I'm thinking this is only one of the many positive things one
> > could do with the ability to access random host-supplied blobs from
> > guest userspace :)
> >
> 
> 'random host-supplied blobs' sounds awfully like files in a file
> system to me, and that is already supported by QEMU and works with any
> guest OS unmodified. If you are in control of the command line, surely
> you can add a -drive xxx,fat:path/to/blobs -device xxx pair that
> simply turns up as a volume.

That did come up, here's the start of original thread on the qemu mailing
list from a while back:

https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00371.html

To recap, the main advantages to transfering data this way are:

1. Asynchronous

   The host can simply pass data via the qemu command line, and
   not have to care if/when the guest is ready to accept the
   data (i.e. has made it far enough to e.g. start a guest agent)

2. Out-of-band

   I don't have to take over a user-visible element such as a
   disk drive. Same reason VSOCK (or VMWare VMCI for that matter)
   exist and are NOT actual Ethernet/TCP-IP network interfaces :)

> > DT on ARM is fine, and I'm certainly happy to learn how to do it (even
> > though my main focus is, for now, x86). The unfortunate thing though
> > is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into
> > first adding it in on the host side, before I can rewrite the guest side
> > driver to look it up in there :)
> >
> >> > I am not sure how relevant sun4 and ppc/mac are for what you are trying 
> >> > to
> >> > accomplish, but perhaps it would be best to focus on x86 and ARM for now
> >> > and do it correctly. If the probing is actually needed, you can always 
> >> > add
> >> > it later.
> >
> > I guess that's the direction things seem to be headed, although it would
> > make me a bit sad to leave out sun and ppc right from the very beginning :)
> >
> 
> Sorry to be blunt, but I am not convinced there is a need for this
> driver anyway.

See above (hopefully I'm being sufficiently persuasive :) )

In VMWare one would fetch similar "guestinfo" variables via something like

FOO=$(vmware-tools --getinfo "FOO")

but I thought exposing fw_cfg in /sys/firmware/... would make access to
*any* blobs (including, but not limited to my particular use case) even
easier and more generic than that.

> > PS. If you have one .c file in the kernel which does any of the DT-on-arm
> > boilerplate I'm supposed to immitate, I'd appreciate the shortcut :)
> >
> 
> Check out drivers/tty/serial/amba-pl011.c

I'll check it out.

Thanks much!
--Gabriel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/compaction: correct to flush migrated pages if pageblock skip happens

2015-08-20 Thread Joonsoo Kim

We cache isolate_start_pfn before entering isolate_migratepages().
If pageblock is skipped in isolate_migratepages() due to whatever reason,
cc->migrate_pfn could be far from isolate_start_pfn hence flushing pages
that were freed happens. For example, following scenario can be possible.

- assume order-9 compaction, pageblock order is 9
- start_isolate_pfn is 0x200
- isolate_migratepages()
  - skip a number of pageblocks
  - start to isolate from pfn 0x600
  - cc->migrate_pfn = 0x620
  - return
- last_migrated_pfn is set to 0x200
- check flushing condition
  - current_block_start is set to 0x600
  - last_migrated_pfn < current_block_start then do useless flush

This wrong flush would not help the performance and success rate so
this patch try to fix it. One simple way to know exact position
where we start to isolate migratable pages is that we cache it
in isolate_migratepages() before entering actual isolation. This patch
implements it and fix the problem.

Signed-off-by: Joonsoo Kim 
---
 mm/compaction.c | 30 +++---
 mm/internal.h   |  1 +
 2 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 86f04e5..4cae0f6 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1112,6 +1112,7 @@ static isolate_migrate_t isolate_migratepages(struct zone 
*zone,
struct compact_control *cc)
 {
unsigned long low_pfn, end_pfn;
+   unsigned long isolate_start_pfn;
struct page *page;
const isolate_mode_t isolate_mode =
(sysctl_compact_unevictable_allowed ? ISOLATE_UNEVICTABLE : 0) |
@@ -1160,6 +1161,7 @@ static isolate_migrate_t isolate_migratepages(struct zone 
*zone,
continue;
 
/* Perform the isolation */
+   isolate_start_pfn = low_pfn;
low_pfn = isolate_migratepages_block(cc, low_pfn, end_pfn,
isolate_mode);
 
@@ -1169,6 +1171,15 @@ static isolate_migrate_t isolate_migratepages(struct 
zone *zone,
}
 
/*
+* Record where we could have freed pages by migration and not
+* yet flushed them to buddy allocator.
+* - this is the lowest page that could have been isolated and
+* then freed by migration.
+*/
+   if (cc->nr_migratepages && !cc->last_migrated_pfn)
+   cc->last_migrated_pfn = isolate_start_pfn;
+
+   /*
 * Either we isolated something and proceed with migration. Or
 * we failed and compact_zone should decide if we should
 * continue or not.
@@ -1339,7 +1350,6 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
unsigned long end_pfn = zone_end_pfn(zone);
const int migratetype = gfpflags_to_migratetype(cc->gfp_mask);
const bool sync = cc->mode != MIGRATE_ASYNC;
-   unsigned long last_migrated_pfn = 0;
 
ret = compaction_suitable(zone, cc->order, cc->alloc_flags,
cc->classzone_idx);
@@ -1377,6 +1387,7 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
zone->compact_cached_migrate_pfn[0] = cc->migrate_pfn;
zone->compact_cached_migrate_pfn[1] = cc->migrate_pfn;
}
+   cc->last_migrated_pfn = 0;
 
trace_mm_compaction_begin(start_pfn, cc->migrate_pfn,
cc->free_pfn, end_pfn, sync);
@@ -1386,7 +1397,6 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
while ((ret = compact_finished(zone, cc, migratetype)) ==
COMPACT_CONTINUE) {
int err;
-   unsigned long isolate_start_pfn = cc->migrate_pfn;
 
switch (isolate_migratepages(zone, cc)) {
case ISOLATE_ABORT:
@@ -1426,16 +1436,6 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
}
}
 
-   /*
-* Record where we could have freed pages by migration and not
-* yet flushed them to buddy allocator. We use the pfn that
-* isolate_migratepages() started from in this loop iteration
-* - this is the lowest page that could have been isolated and
-* then freed by migration.
-*/
-   if (!last_migrated_pfn)
-   last_migrated_pfn = isolate_start_pfn;
-
 check_drain:
/*
 * Has the migration scanner moved away from the previous
@@ -1444,18 +1444,18 @@ check_drain:
 * compact_finished() can detect immediately if allocation
 * would succeed.
 */
-   if (cc->order > 0

[PATCH] arm64: enable generic idle loop

2015-08-20 Thread Leo Yan

Enable generic idle loop for ARM64, so can support for hlt/nohlt
command line options to override default idle loop behavior.

Signed-off-by: Leo Yan 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0f6edb1..c404e74 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -31,6 +31,7 @@ config ARM64
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
+   select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
-- 
1.9.1

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

[RFC V2] fbdev/nvidia:change reverse_order() macro

2015-08-20 Thread yalin wang

This change reverse_order() to swab32(bitrev32()), so that
it can have better performance on some platforms.

Signed-off-by: yalin wang 
---
 drivers/video/fbdev/nvidia/nv_local.h | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/nvidia/nv_local.h 
b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..2c6baa1 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,19 @@
 
 #ifdef __LITTLE_ENDIAN
 
+#include 
 #include 
+static inline void reverse_order(u32 *data)
+{
+   *data = swab32(bitrev32(*data));
+}
 
-#define reverse_order(l)\
-do {\
-   u8 *a = (u8 *)(l);  \
-   a[0] = bitrev8(a[0]);   \
-   a[1] = bitrev8(a[1]);   \
-   a[2] = bitrev8(a[2]);   \
-   a[3] = bitrev8(a[3]);   \
-} while(0)
 #else
-#define reverse_order(l) do { } while(0)
-#endif  /* __LITTLE_ENDIAN */
 
+static inline void reverse_order(u32 *data)
+{
+
+}
+
+#endif  /* __LITTLE_ENDIAN */
 #endif /* __NV_LOCAL_H__ */
-- 
1.9.1

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

[PATCH v5 1/2] efi: export efi_capsule_supported() function symbol

2015-08-20 Thread Kweh, Hock Leong

From: "Kweh, Hock Leong" 

This patch export efi_capsule_supported() function symbol for capsule
kernel module to use.

Cc: Matt Fleming 
Signed-off-by: Kweh, Hock Leong 
---
 drivers/firmware/efi/capsule.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware/efi/capsule.c
index d8cd75c0..738d437 100644
--- a/drivers/firmware/efi/capsule.c
+++ b/drivers/firmware/efi/capsule.c
@@ -101,6 +101,7 @@ out:
kfree(capsule);
return rv;
 }
+EXPORT_SYMBOL_GPL(efi_capsule_supported);
 
 /**
  * efi_capsule_update - send a capsule to the firmware
-- 
1.7.9.5

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

[PATCH v5 2/2] efi: a misc char interface for user to update efi firmware

2015-08-20 Thread Kweh, Hock Leong

From: "Kweh, Hock Leong" 

Introducing a kernel module to expose capsule loader interface
(misc char device file note) for user to upload capsule binaries.

Example method to load the capsule binary:
cat firmware.bin > /dev/efi_capsule_loader

Cc: Matt Fleming 
Signed-off-by: Kweh, Hock Leong 
---
 drivers/firmware/efi/Kconfig  |   10 ++
 drivers/firmware/efi/Makefile |1 +
 drivers/firmware/efi/efi-capsule-loader.c |  218 +
 3 files changed, 229 insertions(+)
 create mode 100644 drivers/firmware/efi/efi-capsule-loader.c

diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index f712d47..0be8ee3 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -60,6 +60,16 @@ config EFI_RUNTIME_WRAPPERS
 config EFI_ARMSTUB
bool
 
+config EFI_CAPSULE_LOADER
+   tristate "EFI capsule loader"
+   depends on EFI
+   help
+ This option exposes a loader interface "/dev/efi_capsule_loader" for
+ user to load EFI capsule binary and update the EFI firmware through
+ system reboot.
+
+ If unsure, say N.
+
 endmenu
 
 config UEFI_CPER
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 698846e..5ab031a 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_UEFI_CPER) += cper.o
 obj-$(CONFIG_EFI_RUNTIME_MAP)  += runtime-map.o
 obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
 obj-$(CONFIG_EFI_STUB) += libstub/
+obj-$(CONFIG_EFI_CAPSULE_LOADER)   += efi-capsule-loader.o
diff --git a/drivers/firmware/efi/efi-capsule-loader.c 
b/drivers/firmware/efi/efi-capsule-loader.c
new file mode 100644
index 000..1da8608
--- /dev/null
+++ b/drivers/firmware/efi/efi-capsule-loader.c
@@ -0,0 +1,218 @@
+/*
+ * EFI capsule loader driver.
+ *
+ * Copyright 2015 Intel Corporation
+ *
+ * This file is part of the Linux kernel, and is made available under
+ * the terms of the GNU General Public License version 2.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEV_NAME "efi_capsule_loader"
+
+struct capsule_info {
+   int curr_index;
+   int curr_size;
+   int total_size;
+   struct page **pages;
+};
+
+static DEFINE_MUTEX(capsule_loader_lock);
+
+/*
+ * This function will store the capsule binary and pass it to
+ * efi_capsule_update() API in capsule.c
+ */
+static ssize_t efi_capsule_write(struct file *file, const char __user *buff,
+size_t count, loff_t *offp)
+{
+   int ret = 0;
+   struct capsule_info *cap_info = file->private_data;
+   struct page *kbuff_page;
+   void *kbuff;
+
+   pr_debug("%s: Entering Write()\n", __func__);
+   if (count == 0)
+   return 0;
+
+   if (cap_info->curr_index == -1)
+   return count;
+
+   kbuff_page = alloc_page(GFP_KERNEL);
+   if (!kbuff_page) {
+   pr_err("%s: alloc_page() failed\n", __func__);
+   if (!cap_info->curr_index)
+   return -ENOMEM;
+   ret = -ENOMEM;
+   goto failed;
+   }
+
+   kbuff = kmap(kbuff_page);
+   if (!kbuff) {
+   pr_err("%s: kmap() failed\n", __func__);
+   if (cap_info->curr_index)
+   cap_info->pages[cap_info->curr_index++] = kbuff_page;
+   ret = -EFAULT;
+   goto failed;
+   }
+
+   /* copy capsule binary data from user space to kernel space buffer */
+   if (copy_from_user(kbuff, buff, min_t(size_t, count, PAGE_SIZE))) {
+   pr_err("%s: copy_from_user() failed\n", __func__);
+   if (cap_info->curr_index)
+   cap_info->pages[cap_info->curr_index++] = kbuff_page;
+   kunmap(kbuff_page);
+   ret = -EFAULT;
+   goto failed;
+   }
+
+   /* setup capsule binary info structure */
+   if (cap_info->curr_index == 0) {
+   efi_capsule_header_t *cap_hdr = kbuff;
+   int reset_type;
+   int pages_needed = ALIGN(cap_hdr->imagesize, PAGE_SIZE) >>
+   PAGE_SHIFT;
+
+   if (pages_needed <= 0) {
+   pr_err("%s: pages count invalid\n", __func__);
+   ret = -EINVAL;
+   kunmap(kbuff_page);
+   goto failed;
+   }
+
+   /* check if the capsule binary supported */
+   ret = efi_capsule_supported(cap_hdr->guid, cap_hdr->flags,
+   cap_hdr->imagesize, _type);
+   if (ret) {
+   pr_err("%s: efi_capsule_supported() failed\n",
+

[PATCH v5 0/2] Enable capsule loader interface for efi firmware

2015-08-20 Thread Kweh, Hock Leong

From: "Kweh, Hock Leong" 

Dear maintainers & communities,

This patchset is created on top of Matt's patchset:
1.)https://lkml.org/lkml/2014/10/7/390
"[PATCH 1/2] efi: Move efi_status_to_err() to efi.h"
2.)https://lkml.org/lkml/2014/10/7/391
"[PATCH 2/2] efi: Capsule update support"

It expose a misc char interface for user to upload the capsule binary and
calling efi_capsule_update() API to pass the binary to EFI firmware.

The steps to update efi firmware are:
1.) cat firmware.cap > /dev/efi_capsule_loader
2.) reboot

Any failed upload error message will be returned while doing "cat" through
Write() function call.

Tested the code with Intel Quark Galileo platform.

Thanks.

---
changelog v5:
* changed to new design without leveraging firmware_class API
* use misc_char device interface instead of sysfs
* error return through file Write() function call


Kweh, Hock Leong (2):
  efi: export efi_capsule_supported() function symbol
  efi: a misc char interface for user to update efi firmware

 drivers/firmware/efi/Kconfig  |   10 ++
 drivers/firmware/efi/Makefile |1
 drivers/firmware/efi/capsule.c|1
 drivers/firmware/efi/efi-capsule-loader.c |  218 +
 4 files changed, 230 insertions(+)
 create mode 100644 drivers/firmware/efi/efi-capsule-loader.c

-- 
1.7.9.5

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

答复： Re: [PATCH] drbd: Support zeroout device instead of initial full sync

2015-08-20 Thread Nick Wang

Hi Lars,

> I still think this does not belong into the kernel at all.
> I may not yet have properly explained why.
> 
   Thanks for your information. 
   I tried blkdiscard on my test machine, but unfortunately the 
underlying block device i used doesn't support discard...
(/sys/block//queue/discard_max_bytes == 0)
However, i think blkscard could work well for SSDs and 
thinly-provisioned support storage as a workaround.

> This is a lot of stuff to add to the DRBD module,
> introducing write protocol incompatibility/protocol version bump.
> 
> For no good reason.
> 
  Yes, it is not a mandatory feature, more like a enhancement 
"convenience patch" for some edge cases. User can choose 
zeroout/discard devices via drbd tools, in case the storage
does not support discard, it will using zeroout instead of only 
throw an "not support" error to output.

  Implement this function to drbd also help to sync the status 
between nodes, convenience for auto deploy or monitor by admin.
Also have the possibility to implement a resume broken 
zeroout/discard in future.

  And i can understand your concern and any decision, many thanks 
for your and Philipp's help and review:)

Best regards,
Nick 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] jump_label: introduce DEFINE_STATIC_KEY_{TRUE,FALSE}_ARRAY macros

2015-08-20 Thread Kevin Hao

On Thu, Aug 20, 2015 at 08:31:58PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 20, 2015 at 08:14:31PM +0800, Kevin Hao wrote:
> > These are used to define a static_key_{true,false} array.
> 
> Yes but why...
> 
> there might have been some clue in the patches you didn't send me, but
> since you didn't send them, I'm left wondering.

Sorry for the confusion. In order to use jump label for the
{cpu,mmu}_has_feature() functions on powerpc, we need to declare an array of
32 or 64 static_key_true (one static_key_true for each cpu or mmu feature).
The following are the two patches which depends on this patch.
  https://lkml.org/lkml/2015/8/20/355
  https://lkml.org/lkml/2015/8/20/356

So far only DEFINE_STATIC_KEY_TRUE_ARRAY macro is used, but I think it may seem
canonical to define the macros for both true or false keys at the same time.

Thanks,
Kevin

pgpcD5zZ9lU7u.pgp
Description: PGP signature

[PATCH] Add some typo-words in patch into spelling.txt

2015-08-20 Thread Zhao Lei

I write a small script to show word-pair from all linux spelling-typo
commits, and get following result by sort | uniq -c:
181 occured -> occurred
 78 transfered -> transferred
 67 recieved -> received
 65 dependant -> dependent
 58 wether -> whether
 56 accomodate -> accommodate
 54 occured -> occurred
 51 recieve -> receive
 47 cant -> can't
 40 sucessfully -> successfully
 ...

Some of them are not in spelling.txt, this patch add mostly-appeared
word-pairs into spelling.txt.

Please review them because Englist is not my mother language.

Signed-off-by: Zhao Lei 
---
 scripts/spelling.txt | 24 
 1 file changed, 24 insertions(+)

diff --git a/scripts/spelling.txt b/scripts/spelling.txt
index bb8e4d0..40a0b8d 100644
--- a/scripts/spelling.txt
+++ b/scripts/spelling.txt
@@ -32,6 +32,7 @@ accoring||according
 accout||account
 accquire||acquire
 accquired||acquired
+accross||across
 acessable||accessible
 acess||access
 achitecture||architecture
@@ -100,8 +101,10 @@ appropiate||appropriate
 appropriatly||appropriately
 approriate||appropriate
 approriately||appropriately
+apropriate||appropriate
 aquainted||acquainted
 aquired||acquired
+aquisition||acquisition
 arbitary||arbitrary
 architechture||architecture
 arguement||argument
@@ -111,6 +114,8 @@ arne't||aren't
 arraival||arrival
 artifical||artificial
 artillary||artillery
+asign||assign
+assertation||assertion
 assiged||assigned
 assigment||assignment
 assigments||assignments
@@ -136,6 +141,7 @@ automatize||automate
 automatized||automated
 automatizes||automates
 autonymous||autonomous
+auxillary||auxiliary
 auxilliary||auxiliary
 avaiable||available
 avaible||available
@@ -231,6 +237,8 @@ compatability||compatibility
 compatable||compatible
 compatibiliy||compatibility
 compatibilty||compatibility
+compatiblity||compatibility
+competion||completion
 compilant||compliant
 compleatly||completely
 completly||completely
@@ -291,6 +299,7 @@ defferred||deferred
 definate||definite
 definately||definitely
 defintion||definition
+defintions||definitions
 defualt||default
 defult||default
 deivce||device
@@ -306,6 +315,7 @@ depreacted||deprecated
 depreacte||deprecate
 desactivate||deactivate
 desciptors||descriptors
+descripton||description
 descrition||description
 descritptor||descriptor
 desctiptor||descriptor
@@ -327,6 +337,7 @@ devided||divided
 deviece||device
 diable||disable
 dictionnary||dictionary
+didnt||didn't
 diferent||different
 differrence||difference
 difinition||definition
@@ -344,6 +355,7 @@ docuentation||documentation
 documantation||documentation
 documentaion||documentation
 documment||document
+doesnt||doesn't
 dorp||drop
 dosen||doesn
 downlad||download
@@ -450,11 +462,13 @@ grahical||graphical
 grahpical||graphical
 grapic||graphic
 guage||gauge
+guarenteed||guaranteed
 guarentee||guarantee
 halfs||halves
 hander||handler
 handfull||handful
 hanled||handled
+happend||happened
 harware||hardware
 heirarchically||hierarchically
 helpfull||helpful
@@ -512,6 +526,7 @@ initialzed||initialized
 initilization||initialization
 initilize||initialize
 inofficial||unofficial
+insititute||institute
 instal||install
 inteface||interface
 integreated||integrated
@@ -546,6 +561,7 @@ invididual||individual
 invokation||invocation
 invokations||invocations
 irrelevent||irrelevant
+isnt||isn't
 isssue||issue
 itslef||itself
 jave||java
@@ -558,6 +574,7 @@ langauage||language
 langauge||language
 langugage||language
 lauch||launch
+layed||laid
 leightweight||lightweight
 lengh||length
 lenght||length
@@ -714,6 +731,7 @@ preceeding||preceding
 preceed||precede
 precendence||precedence
 precission||precision
+preemptable||preemptible
 prefered||preferred
 prefferably||preferably
 premption||preemption
@@ -744,6 +762,7 @@ programers||programmers
 programm||program
 programms||programs
 progresss||progress
+promiscous||promiscuous
 promps||prompts
 pronnounced||pronounced
 prononciation||pronunciation
@@ -817,6 +836,7 @@ reseting||resetting
 resizeable||resizable
 resouces||resources
 resoures||resources
+responce||response
 ressizes||resizes
 ressource||resource
 ressources||resources
@@ -869,6 +889,7 @@ setts||sets
 settting||setting
 shotdown||shutdown
 shoud||should
+shouldnt||shouldn't
 shoule||should
 shrinked||shrunk
 siginificantly||significantly
@@ -913,9 +934,11 @@ straming||streaming
 struc||struct
 structres||structures
 stuct||struct
+stucture||structure
 sturcture||structure
 subdirectoires||subdirectories
 suble||subtle
+substract||subtract
 succesfully||successfully
 succesful||successful
 successfull||successful
@@ -1027,6 +1050,7 @@ virtiual||virtual
 visiters||visitors
 vitual||virtual
 wating||waiting
+wether||whether
 whataver||whatever
 whenver||whenever
 wheter||whether
-- 
1.8.5.1

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

RE: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform

2015-08-20 Thread Wang Dongsheng

Hi Walleij and Russell,

I will drop this patch. Thanks for your review.

[PATCH v2 1/2] soc/fsl: add freescale dir for SOC specific drivers

But the 1/2 of the patches also need, because there has another patch(Freescale 
FPGA driver) need 1/2 patch.
Need I push the 1/2 patch with another patches(Freescale FPGA driver) or push 
1/2 standalone without another
patch? 

Regards,
-Dongsheng

> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: Friday, August 14, 2015 6:07 PM
> To: Wang Dongsheng-B40534; John Stultz
> Cc: Alessandro Zummo; Alexandre Belloni; Shawn Guo; Nair, Sandeep; Hans de 
> Goede;
> Wang Huan-B18965; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; rtc-li...@googlegroups.com
> Subject: Re: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform
> 
> On Fri, Aug 14, 2015 at 5:12 AM, Wang Dongsheng
>  wrote:
> >> On Wed, Aug 12, 2015 at 7:53 AM, Dongsheng Wang
> >>  wrote:
> >>
> >> > From: Wang Dongsheng 
> >> >
> >> > Only Ftm0 can be used when system going to deep sleep. So this driver
> >> > to support ftm0 as a wakeup source.
> >> >
> >> > Signed-off-by: Wang Dongsheng 
> >> > ---
> >> > *V2*
> >> > Change Copyright 2014 to 2015.
> >> (...)
> >> > +config FTM_ALARM
> >> > +   bool "FTM alarm driver"
> >> > +   depends on SOC_LS1021A
> >> > +   default n
> >> > +   help
> >> > + Say y here to enable FTM alarm support.  The FTM alarm provides
> >> > + alarm functions for wakeup system from deep sleep.  There is 
> >> > only
> >> > + one FTM can be used in ALARM(FTM 0).
> >> (...)
> >> > +static u32 time_to_cycle(unsigned long time)
> >> > +static u32 cycle_to_time(u32 cycle)
> >> > +static int ftm_set_alarm(u64 cycle)
> >> > +static irqreturn_t ftm_alarm_interrupt(int irq, void *dev_id)
> >> > +static ssize_t ftm_alarm_show(struct device *dev,
> >> > + struct device_attribute *attr,
> >> > + char *buf)
> >> > +static ssize_t ftm_alarm_store(struct device *dev,
> >> > +  struct device_attribute *attr,
> >> > +  const char *buf, size_t count)
> >> (...)
> >> > +static struct device_attribute ftm_alarm_attributes = __ATTR(ftm_alarm,
> 0644,
> >> > +   ftm_alarm_show, ftm_alarm_store);
> >>
> >> If you're gonna invent ABIs, document then in Documentation/ABI/testing/*.
> >>
> >> But I don't get it. Why is this driver not in drivers/rtc?
> >>
> >> It does a subset of what an RTC does. The ioctl()'s of an RTC
> >> can do what you want to do. And much much more.
> >>
> >> If it can't do all an RTC can do, surely the RTC subsystem
> >> can be augmented to host it anyway. It's way to close to
> >> an RTC to have it's own random sysfs driver like this.
> >>
> >> Unless I'm totally off, rewrite this to an RTC driver and post
> >> it to the RTC maintainers.
> >
> > FlexTimer is not a RTC device and not have any rtc deivce function. They
> belong to
> > different devices, why we need to register this to RTC framework? I am
> confused about this.
> >
> > Now in freescale layerscape platform this driver is only for FlexTimer0, and
> not
> > fit for each flextimer. Because only FlexTimer0 still turn-on when system in
> the Deep Sleep.
> >
> > If the "alarm" make you feel confused or mislead you think this is a RTC
> devices. I think
> > I need to change the "alarm" to "timer".
> 
> I think it is an RTC, it is just that the hardware engineer
> designed it with a wakeup usecase in mind and did not call
> it an RTC. Wakeup is one of the things RTCs do.
> 
> If you inspect a few drivers in drivers/rtc such as drivers/rtc/rtc-pl030.c
> you will find that they are just as crude as this "alarm" thing.
> 
> It has a counter that counts cycles, it has a comparator
> and an alarm function. It is an on-chip RTC, just like PL030
> no matter what the datasheet or hardware engineer thinks it
> should be called, the Linux kernel calls this an RTC, and it
> has a subsystem for handling it, so we should use it and
> not invent random new stuff.
> 
> If the hardware is really so strange that the counter can only
> be started if you also put an alarm at the same time (I doubt
> it, but OK if you say so) it is a subset of an RTC that can
> only be used for alarms but not timekeeping, but it should
> *still* live in drivers/rtc.
> 
> Think for a moment on the huge effort that John Stultz put into
> integrating Android alarm timers with POSIX and the RTC
> subsystem and fixing it all from the smallest handset to
> the largest S360 supercomputer. The approach of a custom
> device just throws all of that out the window and reinvents the
> mechanism in userspace, forcing all standardized userspace to
> have special code to handle this special alarm with its
> special sysfs ABI.
> 
> Check
> commit ff3ead96d17f47ee70c294a5cc2cce9b61e82f0f
> "timers: Introduce in-kernel alarm-timer interface"

Re: [PATCH 1/8] jump_label: no need to acquire the jump_label_mutex in jump_lable_init()

2015-08-20 Thread Kevin Hao

On Thu, Aug 20, 2015 at 08:29:03PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 20, 2015 at 08:14:29PM +0800, Kevin Hao wrote:
> > The jump_label_init() run in a very early stage, even before the
> > sched_init(). So there is no chance for concurrent access of the
> > jump label table.
> 
> It also doesn't hurt to have it. Its better to be consistent and
> conservative with locking unless there is a pressing need.

Yes, it has no real hurt. IMHO it may cause confusion that the function
jump_label_init() may run in two different thread context simultaneously. 
Anyway if you guys don't think so, I can drop this patch.

Thanks,
Kevin


pgp_4f4fGgWfN.pgp
Description: PGP signature

Re: [PATCH v2 3/3] media: atmel-isi: add sanity check for supported formats in set_fmt()

2015-08-20 Thread Josh Wu


Hi, Laurent

Thanks for the review.

On 8/21/2015 2:30 AM, Laurent Pinchart wrote:

Hi Josh,

Thank you for the patch.

On Wednesday 05 August 2015 11:26:29 Josh Wu wrote:

After adding the format check in set_fmt(), we don't need any format check
in configure_geometry(). So make configure_geometry() as void type.

Signed-off-by: Josh Wu 
---

Changes in v2:
- new added patch

  drivers/media/platform/soc_camera/atmel-isi.c | 39 ++--
  1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c index cb46aec..d0df518
100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -103,17 +103,19 @@ static u32 isi_readl(struct atmel_isi *isi, u32 reg)
return readl(isi->regs + reg);
  }

-static int configure_geometry(struct atmel_isi *isi, u32 width,
+static void configure_geometry(struct atmel_isi *isi, u32 width,
u32 height, u32 code)
  {
u32 cfg2;

/* According to sensor's output format to set cfg2 */
switch (code) {
-   /* YUV, including grey */
+   default:
+   /* Grey */
case MEDIA_BUS_FMT_Y8_1X8:
cfg2 = ISI_CFG2_GRAYSCALE;
break;
+   /* YUV */
case MEDIA_BUS_FMT_VYUY8_2X8:
cfg2 = ISI_CFG2_YCC_SWAP_MODE_3;
break;
@@ -127,8 +129,6 @@ static int configure_geometry(struct atmel_isi *isi, u32
width, cfg2 = ISI_CFG2_YCC_SWAP_DEFAULT;
break;
/* RGB, TODO */
-   default:
-   return -EINVAL;
}

isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
@@ -139,8 +139,29 @@ static int configure_geometry(struct atmel_isi *isi,
u32 width, cfg2 |= ((height - 1) << ISI_CFG2_IM_VSIZE_OFFSET)
& ISI_CFG2_IM_VSIZE_MASK;
isi_writel(isi, ISI_CFG2, cfg2);
+}

-   return 0;
+static bool is_supported(struct soc_camera_device *icd,
+   const struct soc_camera_format_xlate *xlate)
+{
+   bool ret = true;
+
+   switch (xlate->code) {
+   /* YUV, including grey */
+   case MEDIA_BUS_FMT_Y8_1X8:
+   case MEDIA_BUS_FMT_VYUY8_2X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_YVYU8_2X8:
+   case MEDIA_BUS_FMT_YUYV8_2X8:

I would just return true here and false below, and remove the ret variable.

Ok.




+   break;
+   /* RGB, TODO */
+   default:
+   dev_err(icd->parent, "not supported format: %d\n",
+   xlate->code);

If this can happen when userspace asks for an unsupported format I don't think
you should print an error message to the kernel log.


ok, I will remove this.




+   ret = false;
+   }
+
+   return ret;
  }

  static irqreturn_t atmel_isi_handle_streaming(struct atmel_isi *isi)
@@ -391,10 +412,8 @@ static int start_streaming(struct vb2_queue *vq,
unsigned int count) /* Disable all interrupts */
isi_writel(isi, ISI_INTDIS, (u32)~0UL);

-   ret = configure_geometry(isi, icd->user_width, icd->user_height,
+   configure_geometry(isi, icd->user_width, icd->user_height,
icd->current_fmt->code);
-   if (ret < 0)
-   return ret;

spin_lock_irq(>lock);
/* Clear any pending interrupt */
@@ -515,6 +534,10 @@ static int isi_camera_set_fmt(struct soc_camera_device
*icd, if (mf->code != xlate->code)
return -EINVAL;

+   /* check with atmel-isi support format */
+   if (!is_supported(icd, xlate))
+   return -EINVAL;
+

S_FMT is supposed to pick a suitable default format when the requested format
isn't supported. It shouldn't return an error.


So I will move this check to beginning of S_FMT and if format not 
support, I will select a default format for it.


Best Regards,
Josh Wu




pix->width   = mf->width;
pix->height  = mf->height;
pix->field   = mf->field;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] t104xd4rdb: add DS26522 nodes to device tree

2015-08-20 Thread Zhao Qiang

DS26522 is used for tdm, configured by SPI bus.
Add nodes under spi node to t104xd4rdb.dtsi.

Signed-off-by: Zhao Qiang 
---
 Documentation/devicetree/bindings/net/maxim,ds26522.txt | 13 +
 arch/powerpc/boot/dts/t104xd4rdb.dtsi   | 10 ++
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/maxim,ds26522.txt

diff --git a/Documentation/devicetree/bindings/net/maxim,ds26522.txt 
b/Documentation/devicetree/bindings/net/maxim,ds26522.txt
new file mode 100644
index 000..ee8bb72
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/maxim,ds26522.txt
@@ -0,0 +1,13 @@
+* Maxim (Dallas) DS26522 Dual T1/E1/J1 Transceiver
+
+Required properties:
+- compatible: Should contain "maxim,ds26522".
+- reg: SPI CS.
+- spi-max-frequency: SPI clock.
+
+Example:
+   slic@1 {
+   compatible = "maxim,ds26522";
+   reg = <1>;
+   spi-max-frequency = <200>; /* input clock */
+   };
diff --git a/arch/powerpc/boot/dts/t104xd4rdb.dtsi 
b/arch/powerpc/boot/dts/t104xd4rdb.dtsi
index 491367b..3f6d7c6 100644
--- a/arch/powerpc/boot/dts/t104xd4rdb.dtsi
+++ b/arch/powerpc/boot/dts/t104xd4rdb.dtsi
@@ -109,6 +109,16 @@
/* input clock */
spi-max-frequency = <1000>;
};
+   slic@1 {
+   compatible = "maxim,ds26522";
+   reg = <1>;
+   spi-max-frequency = <200>; /* input clock */
+   };
+   slic@2 {
+   compatible = "maxim,ds26522";
+   reg = <2>;
+   spi-max-frequency = <200>; /* input clock */
+   };
};
i2c@118000 {
hwmon@4c {
-- 
2.1.0.27.g96db324

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

[4.2-rc7][Haswell] NMI soft lockup - try_to_del_timer_sync

2015-08-20 Thread Shawn Starr

Hello folks,

I was just using KVM and doing some VM work on my laptop when it locked up 
system fully, here is the kernel trace below (it repeats after the second dump)

Since we're soon 'close' to 4.2 final, maybe someone can check if something 
regressed? Never saw this in eariler -rcX builds.

Thanks,
Shawn.


[69399.505355] kvm: zapping shadow pages for mmio generation wraparound
[69405.611747] kvm [24415]: vcpu0 unhandled rdmsr: 0x641
[69411.477997] Bridge: port 2(vnet0) entered forwarding state
[70844.574880] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! 
[swapper/3:0]
[70844.575264] Modules linked in: vhost_net vhost macvtap macvlan tun 
ebtable_filter ebtables ip6table_filter ip6_tables bridge vfat fat intel_rapl 
iosf_mbi x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul 
crc32_pclmul crc32c_intel ghash_clmulni_intel uvcvideo videobuf2_vmalloc 
videobuf2_core videobuf2_memops arc4 iwlmvm v4l2_common mac80211 videodev 
snd_usb_audio snd_usbmidi_lib snd_rawmidi media iwlwifi dell_laptop cfg80211 
snd_hda_codec_realtek dell_wmi snd_soc_rt5640 iTCO_wdt iTCO_vendor_support 
joydev lpc_ich dcdbas sparse_keymap ppdev dell_smm_hwmon mei_me 
snd_hda_codec_generic snd_soc_rl6231 snd_hda_codec_hdmi mei ie31200_edac 
edac_core dw_dmac snd_soc_core parport_pc parport snd_compress 
snd_pcm_dmaengine shpchp video ac97_bus dw_dmac_core i2c_i801 
i2c_designware_platform i2c_designware_core
[70844.579376]  snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq 
snd_seq_device snd_pcm snd_timer snd soundcore snd_soc_sst_acpi dell_rbtn 
rfkill wmi dell_smo8800 nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc 
8021q garp stp llc mrp amdkfd amd_iommu_v2 radeon i2c_algo_bit drm_kms_helper 
ttm e1000e drm serio_raw sdhci_pci ptp sdhci_acpi pps_core sdhci mmc_core 
i2c_hid
[70844.581351] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 
4.2.0-0.rc7.git0.1.fc23.x86_64 #1
[70844.581804] Hardware name: Dell Inc. Precision M6800/05NG6V, BIOS A14 
05/24/2015
[70844.582198] task: 880809f6c4c0 ti: 88080990 task.ti: 
88080990
[70844.582555] RIP: 0010:[]  [] 
try_to_del_timer_sync+0xb/0x90
[70844.583042] RSP: 0018:88082dcc3da0  EFLAGS: 0286
[70844.583296] RAX:  RBX: 0296 RCX: 
[70844.583637] RDX: 0001 RSI: 0296 RDI: 8800bc0612e0
[70844.584037] RBP: 88082dcc3da8 R08: 0101 R09: 0003
[70844.584373] R10: 0002 R11: 0004 R12: 88082dcc3d18
[70844.584771] R13: 8177818b R14: 88082dcc3da8 R15: 8800bc0612e0
[70844.585139] FS:  () GS:88082dcc() 
knlGS:
[70844.585524] CS:  0010 DS:  ES:  CR0: 80050033
[70844.585833] CR2: 140a84048000 CR3: 01c0b000 CR4: 001426e0
[70844.586200] Stack:
[70844.586301]  8807650fe800 88082dcc3dc8 8110379c 
88082dcc3dc8
[70844.586687]  8800bc061248 88082dcc3df8 816ac35c 
000167c0
[70844.587187]  8800bc061248 8807650fe800 8807ec9c5000 
88082dcc3e38
[70844.587631] Call Trace:
[70844.587784]   
[70844.587884]  [] del_timer_sync+0x4c/0x60
[70844.588188]  [] inet_csk_reqsk_queue_drop+0x6c/0x1d0
[70844.588499]  [] reqsk_timer_handler+0xd9/0x2a0
[70844.588817]  [] ? inet_csk_reqsk_queue_drop+0x1d0/0x1d0
[70844.589158]  [] call_timer_fn+0x39/0xf0
[70844.589432]  [] ? inet_csk_reqsk_queue_drop+0x1d0/0x1d0
[70844.589774]  [] run_timer_softirq+0x20f/0x2c0
[70844.590105]  [] __do_softirq+0xfb/0x290
[70844.590365]  [] irq_exit+0x119/0x120
[70844.590618]  [] smp_apic_timer_interrupt+0x46/0x60
[70844.590929]  [] apic_timer_interrupt+0x6b/0x70
[70844.591222]   
[70844.591322]  [] ? hrtimer_start_range_ns+0x1bf/0x3b0
[70844.591656]  [] ? cpuidle_enter_state+0x130/0x270
[70844.591961]  [] ? cpuidle_enter_state+0x10b/0x270
[70844.592265]  [] cpuidle_enter+0x17/0x20
[70844.592527]  [] call_cpuidle+0x32/0x60
[70844.592787]  [] ? cpuidle_select+0x13/0x20
[70844.593060]  [] cpu_startup_entry+0x268/0x320
[70844.593347]  [] start_secondary+0x186/0x1c0
[70844.593623] Code: 00 00 44 89 e0 75 0b 48 83 c4 18 5b 41 5c 41 5d 5d c3 e8 
79 ab f9 ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 <53> 48 
8d 75 e0 48 89 fb 48 83 c7 28 48 83 ec 10 65 48 8b 04 25 
[70872.581083] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! 
[swapper/3:0]
[70872.581462] Modules linked in: vhost_net vhost macvtap macvlan tun 
ebtable_filter ebtables ip6table_filter ip6_tables bridge vfat fat intel_rapl 
iosf_mbi x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul 
crc32_pclmul crc32c_intel ghash_clmulni_intel uvcvideo videobuf2_vmalloc 
videobuf2_core videobuf2_memops arc4 iwlmvm v4l2_common mac80211 videodev 
snd_usb_audio snd_usbmidi_lib snd_rawmidi media iwlwifi dell_laptop cfg80211 
snd_hda_codec_realtek dell_wmi snd_soc_rt5640 iTCO_wdt iTCO_vendor_support 
joydev lpc_ich dcdbas sparse_keymap ppdev

€950,000.00 EURO

2015-08-20 Thread Qatar Foundation

Dear Beneficiary,
 d
You have been selected to receive €950,000.00 EURO as charity donations / aid 
of the Qatar Foundation. Reply back for more information and claims.

Yours sincerely,
Engineer Saad Al Muhannadi.

Reply to:qatarfu...@163.com

--

Lieber Zuschussempfänger,

Sie wurden ausgewählt, um € 950.000,00 EURO als Charity-Spenden / Hilfe der 
Qatar Foundation erhalten. Antwort zurück, um weitere Informationen und 
Ansprüche.

Antwort auf: qatarfu...@163.com

Mit freundlichen Grüßen,
Ingenieur Saad Al Muhannadi.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

On 20 August 2015 at 17:02, David Laight  wrote:
> From: Baolin Wang
>> Sent: 14 August 2015 10:48
>> +/* In miliamps */
>
> Spelling police: "milliamps"
>

Hi David,

I'll correct it in next patch series. Thanks for your comments.

>> +static unsigned int wm831x_usb_limits[] = {
>> + 0,
>> + 2,
>> + 100,
>> + 500,
>> + 900,
>> + 1500,
>> + 1800,
>> + 550,
>> +};
>
> David
>



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc/ds3232: fix ds3232 get a WARNING trace in resume function

2015-08-20 Thread Dongsheng Wang

From: Wang Dongsheng 

If ds3232 work on some platform that is not implementation
irq_set_wake, ds3232 will get a WARNING trace in resume.
So fix ds3232->suspended state to false when irq_set_irq_wake
return error.

Signed-off-by: Wang Dongsheng 
---
*v3*
- Remove kernel trace in commit message.
- s/Can not/Cannot/
*v2*
- Use dev_warn_once to instead of dev_info

diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
index 7e48e53..3554970 100644
--- a/drivers/rtc/rtc-ds3232.c
+++ b/drivers/rtc/rtc-ds3232.c
@@ -463,7 +463,10 @@ static int ds3232_suspend(struct device *dev)
 
if (device_can_wakeup(dev)) {
ds3232->suspended = true;
-   irq_set_irq_wake(client->irq, 1);
+   if (irq_set_irq_wake(client->irq, 1)) {
+   dev_warn_once(dev, "Cannot set wakeup sources\n");
+   ds3232->suspended = false;
+   }
}
 
return 0;
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: dts: UniPhier: fix PPI interrupt CPU mask of timer nodes

2015-08-20 Thread Olof Johansson

On Wed, Aug 19, 2015 at 02:49:26PM +0900, Masahiro Yamada wrote:
> This SoC is integrated with 4 Cortex-A9 cores.  The GIC bindings
> document says that the bits[15:8] of the 3rd cell of the interrupts
> property represents PPI interrupt CPU mask.  Because the timer
> interrupts are wired to all of the 4 cores, bits[15:8] should be set
> to 0xf.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v2:
>   - Fix git-description

Thanks, applied.


-Olof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: multi_v7_defconfig: Enable CROS_EC_PROTO for ChromeOS EC mfd driver

2015-08-20 Thread Olof Johansson

On Wed, Aug 19, 2015 at 12:28:37AM +0200, Javier Martinez Canillas wrote:
> Hello Olof,
> 
> On 08/18/2015 11:46 PM, Olof Johansson wrote:
> > On Tue, Aug 18, 2015 at 09:10:27AM +0200, Javier Martinez Canillas wrote:
> >> The ChromeOS mfd driver (MFD_CROS_EC) select the CROS_EC_PROTO config
> >> symbol because the driver uses some communication helper functions in
> >> drivers/platform/chrome/cros_ec_proto.c but other drivers depends on
> >> CROS_EC_PROTO instead. Mixing select and depends can lead to circular
> >> Kconfig dependencies so the MFD_CROS_EC select should be changed to a
> >> depends on CROS_EC_PROTO instead.
> >>
> >> But doing so will break git bisect-ability since MFD_CROS_EC will not
> >> be enabled anymore unless the default configs first explicitly enable
> >> the CROS_EC_PROTO dependency.
> >>
> >> Signed-off-by: Javier Martinez Canillas 
> > 
> > Applied to cros/ec-config in arm-soc, which will stay stable in case others
> > need to bring in as a prereq.
> >
> 
> Thanks but Bartolomiej's feedback [0] on my patch that made CROS_EC_PROTO
> a user selectable option was to leave it as a non-visible option and instead
> change the other Kconfig symbols to select CROS_EC_PROTO consistently.
> 
> So tomorrow I'll post a new patch series along those lines that will make
> this patch obsolete since no defconfig changes will be needed.
> 
> IOW, please drop this patch and sorry for the inconvenience.

Done.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm:memory hot-add: memory can not been added to movable zone

2015-08-20 Thread Changsheng Liu



On 08/20/201515:41, Vlastimil Babka wrote:

On 08/20/2015 09:28 AM, Changsheng Liu wrote:

From: Changsheng Liu 

When memory is hot added, should_add_memory_movable() always returns 0
because the movable zone is empty, so the memory that was hot added will
add to the normal zone even if we want to remove the memory.


I'm not expert on memory hot-plug, but since you CC'd me, I wonder... 
the function has this comment: " * If movable zone has already been 
setup, newly added memory should be check."


So I read it like "if you want movable memory *at all*, you should do 
some setup first" (but don't ask me what setup). After your patch, 
every hot-added memory would be automatically movable? Isn't that 
silently changing behavior against user expectations? What about those 
that don't want to hot-remove and don't want movable zones (which 
limit what kind of allocations are possible), is there a way to 
prevent memory being movable after your patch?
After the system startup, we hot added one cpu with memory, The 
function arch_add_memory() will add the memory to
normal zone defaultly but now all zones including normal zone and 
movable zone are empty.So If we want to add the memory

to movable zone we need change should_add_memory_movable().



So we change should_add_memory_movable(): if the user config
CONFIG_MOVABLE_NODE it will return 1 when the movable zone is empty.

Reviewed-by: Andrew Morton 
Signed-off-by: Changsheng Liu 
Tested-by: Dongdong Fan 
---
  mm/memory_hotplug.c |3 +--
  1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 26fbba7..ff658f2 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1199,8 +1199,7 @@ static int should_add_memory_movable(int nid, 
u64 start, u64 size)

  struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE;

  if (zone_is_empty(movable_zone))
-return 0;
-
+return IS_ENABLED(CONFIG_MOVABLE_NODE);
  if (movable_zone->zone_start_pfn <= start_pfn)
  return 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] rtc/ds3232: fix ds3232 get a WARNING trace in resume function

2015-08-20 Thread Wang Dongsheng

Thanks, I will push v3 to fix them.

Regards,
-Dongsheng

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: Friday, August 21, 2015 7:22 AM
> To: Wang Dongsheng-B40534; Krzysztof Kozlowski
> Cc: a.zu...@towertech.it; rtc-li...@googlegroups.com; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2] rtc/ds3232: fix ds3232 get a WARNING trace in resume
> function
> 
> On 12/08/2015 at 17:14:13 +0800, Dongsheng Wang wrote :
> > From: Wang Dongsheng 
> >
> > If ds3232 work on some platform that is not implementation
> > irq_set_wake, ds3232 will get a WARNING trace in resume.
> > So fix ds3232->suspended state to false when irq_set_irq_wake return
> > error.
> >
> > [ cut here ]
> > WARNING: CPU: 0 PID: 729 at kernel/irq/manage.c:604
> > irq_set_irq_wake+0x4b/0x8c()
> > Unbalanced IRQ 201 wake disable
> > Modules linked in:
> > CPU: 0 PID: 729 Comm: sh Not tainted 3.12.19-rt30+ #25 [<800107d9>]
> > (unwind_backtrace+0x1/0x88) from [<8000e4ef>]
> > (show_stack+0xb/0xc)
> > [<8000e4ef>] (show_stack+0xb/0xc) from [<802b5fa9>]
> > (dump_stack+0x4d/0x60)
> > [<802b5fa9>] (dump_stack+0x4d/0x60) from [<800186dd>]
> > (warn_slowpath_common+0x45/0x64)
> > [<800186dd>] (warn_slowpath_common+0x45/0x64) from [<80018717>]
> > (warn_slowpath_fmt+0x1b/0x24)
> > [<80018717>] (warn_slowpath_fmt+0x1b/0x24) from [<8003a8d3>]
> > (irq_set_irq_wake+0x4b/0x8c)
> > [<8003a8d3>] (irq_set_irq_wake+0x4b/0x8c) from [<80204fcb>]
> > (ds3232_resume+0x2d/0x36)
> > [<80204fcb>] (ds3232_resume+0x2d/0x36) from [<801954c7>]
> > (dpm_run_callback.isra.13+0xb/0x28)
> > [<801954c7>] (dpm_run_callback.isra.13+0xb/0x28) from [<80195b1b>]
> > (device_resume+0x7b/0xa2)
> > [<80195b1b>] (device_resume+0x7b/0xa2) from [<80195f0f>]
> > (dpm_resume+0xbb/0x19c)
> > [<80195f0f>] (dpm_resume+0xbb/0x19c) from [<801960d9>]
> > (dpm_resume_end+0x9/0x12)
> > [<801960d9>] (dpm_resume_end+0x9/0x12) from [<80037e1d>]
> > (suspend_devices_and_enter+0x17d/0x1d0)
> > [<80037e1d>] (suspend_devices_and_enter+0x17d/0x1d0) from [<80037ee1>]
> > (pm_suspend+0x71/0x128)
> > [<80037ee1>] (pm_suspend+0x71/0x128) from [<80037449>]
> > (state_store+0x6d/0x80)
> > [<80037449>] (state_store+0x6d/0x80) from [<800af4d5>]
> > (sysfs_write_file+0x9f/0xde)
> > [<800af4d5>] (sysfs_write_file+0x9f/0xde) from [<8007a437>]
> > (vfs_write+0x7b/0x104)
> > [<8007a437>] (vfs_write+0x7b/0x104) from [<8007a7f7>]
> > (SyS_write+0x27/0x48)
> > [<8007a7f7>] (SyS_write+0x27/0x48) from [<8000c121>]
> > (ret_fast_syscall+0x1/0x44)
> > ---[ end trace 640959d2e8de6ccc ]---
> >
> > Signed-off-by: Wang Dongsheng 
> > ---
> > *v2*
> > - Use dev_warn_once to instead of dev_info
> >
> 
> Applied, after fixing the kernel trace and the message like suggested by
> Krzysztof.
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] video: fbdev: s3c-fb: Constify platform_device_id

On 20.08.2015 18:16, Tomi Valkeinen wrote:
> 
> 
> On 24/07/15 09:12, Krzysztof Kozlowski wrote:
>> 2015-07-08 13:34 GMT+09:00 Jingoo Han :
>>>
>>> On 2015. 7. 7., at PM 10:00, Krzysztof Kozlowski  
>>> wrote:

 The platform_device_id is not modified by the driver and core uses it as
 const.

 Signed-off-by: Krzysztof Kozlowski 
>>>
>>> Acked-by: Jingoo Han 
>>>
>>> Best regards,
>>> Jingoo Han
>>
>> Seems nobody is picking it up, so I merge it through Samsung-SoC tree.
>> If there are any objections please let me know.
> 
> I can pick this up if you didn't already do that.

Could you? It would be great.
Kukjin did not pick it up so it is still waiting for some attention. :)

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver

2015-08-20 Thread Viet Nga Dao

On Fri, Aug 21, 2015 at 4:37 AM, Brian Norris
 wrote:
> On Thu, Aug 20, 2015 at 05:18:14PM +0800, Viet Nga Dao wrote:
>> You might misunderstand the hardware problem i mention here. This soft
>> IP controller is able to provide the ID for our Altera EPCS/EPCQ flash
>> chips, which are non JEDEC chips. As from EPCQ device data sheet
>> (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf),
>> the device ID is 8 bit data.
>
> 8 bits of data is vastly insufficient for uniquely identifying a flash.
> This is not extendible and is not really a candidate for inclusion in
> mainline, unless it's somehow guaranteed that these flash can only be
> used with your controller (and I'm not sure how you would do that).
> Otherwise, you need to augment every flash with more out-of-band
> device-tree information.
>
>> The remaining problem here is that this
>> controller is able to support Micron chips but it currently has
>> limitation in providing only 8 bit ID, which is not full JEDEC ID for
>> Micron chips.
>
> You're just proving my point. I will not support "READ ID" detection
> that is based on only 8 bits of ID.
>
>> Hence, we are asking hardware engineer to find out the
>> solution so that the driver does not need to do any dirty hacking.
>
> OK, then I wish your hardware team great speed.
>
>> And
>> so, this table should still be here even hardware fix will take place
>> or not.
>
> I'm not sure how you come to this conclusion.
>

I have this conclusion is because Altera EPCQ/EPCS flashes are non
JEDEC. Thus on the spi_device_id table,
the ID in the INFO struct must be filled up with zeros in order to
matches the current framework.
However, since i still persist to have the device id check in my
driver, as suggested by Rash,
I should implement it locally in my driver. And this table is the look
up table for the device ID of supported flashes.

Or maybe you can give me any other better idea?

> BTW, to reiterate one other question that I feel wasn't adequately
> answered: what does the full ID string look like for these EPCS/EPCQ
> flash chips? Not the ID as seen by your limited controller, but the ID
> that can be reported by the flash chip. Is it really only an 8-bit
> number? Or does it have a longer string that your controller just can't
> read?
>

Yes, As you can refer to page 32 of EPCQ flash datasheet
(https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf),
 "This operation reads the 8-bit device identification of the EPCQ
device from the DATA1 output pin".
Table 29 lists the EPCQ device identifications

Nga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] drivers: soc: add support for exynos SROM driver

On 20.08.2015 20:34, Pankaj Dubey wrote:
> Hi Krzysztof,
> 
> Sorry for delay in reply, as I got busy in some other official
> assignments and could not take this series further at that time.
> 
> On Wednesday 27 May 2015 05:22 PM, Krzysztof Kozlowski wrote:
>> W dniu 29.04.2015 o 17:38, Pankaj Dubey pisze:
>>> This patch adds Exynos SROM controller driver which will handle
>>> save restore of SROM registers during S2R.
>>>
>>> Change-Id: Iaddaaebc1d7090c9889e948e68e886519562c43c
>>
>> Please remove it.
> 
> Will do it.
> 
>>
>>> Signed-off-by: Pankaj Dubey 
>>> ---
>>>   drivers/soc/Kconfig   |   1 +
>>>   drivers/soc/Makefile  |   1 +
>>>   drivers/soc/samsung/Kconfig   |  14 
>>>   drivers/soc/samsung/Makefile  |   1 +
>>>   drivers/soc/samsung/exynos-srom.c | 142
>>> ++
>>>   drivers/soc/samsung/exynos-srom.h |  51 ++
>>>   6 files changed, 210 insertions(+)
>>>   create mode 100644 drivers/soc/samsung/Kconfig
>>>   create mode 100644 drivers/soc/samsung/Makefile
>>>   create mode 100644 drivers/soc/samsung/exynos-srom.c
>>>   create mode 100644 drivers/soc/samsung/exynos-srom.h
>>>
>>> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
>>> index 76d6bd4..c3abfbe 100644
>>> --- a/drivers/soc/Kconfig
>>> +++ b/drivers/soc/Kconfig
>>> @@ -1,6 +1,7 @@
>>>   menu "SOC (System On Chip) specific Drivers"
>>>
>>>   source "drivers/soc/qcom/Kconfig"
>>> +source "drivers/soc/samsung/Kconfig"
>>>   source "drivers/soc/ti/Kconfig"
>>>   source "drivers/soc/versatile/Kconfig"
>>>
>>> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
>>> index 063113d..620366f 100644
>>> --- a/drivers/soc/Makefile
>>> +++ b/drivers/soc/Makefile
>>> @@ -3,6 +3,7 @@
>>>   #
>>>
>>>   obj-$(CONFIG_ARCH_QCOM)+= qcom/
>>> +obj-$(CONFIG_SOC_SAMSUNG)+= samsung/
>>>   obj-$(CONFIG_ARCH_TEGRA)+= tegra/
>>>   obj-$(CONFIG_SOC_TI)+= ti/
>>>   obj-$(CONFIG_PLAT_VERSATILE)+= versatile/
>>> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
>>> new file mode 100644
>>> index 000..b6fa4e6
>>> --- /dev/null
>>> +++ b/drivers/soc/samsung/Kconfig
>>> @@ -0,0 +1,14 @@
>>> +#
>>> +# SAMSUNG SoC drivers
>>> +#
>>> +menu "Samsung SOC driver support"
>>> +
>>> +config SOC_SAMSUNG
>>> +bool
>>
>> Any reason for not using menuconfig?
>>
> 
> For one of my Exynos PMU patchset [1] this suggestion came from Russel
> King, not to use user-visible sysmbol if not required.
> [1]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/304451.html

Okay, thanks. I'm fine with that.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc: s5m: fix to update ctrl register

On 21.08.2015 10:00, Joonyoung Shim wrote:
> On 08/21/2015 09:44 AM, Krzysztof Kozlowski wrote:
>> On 21.08.2015 08:15, Alexandre Belloni wrote:
>>> Hi,
>>>
>>> On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
 According to datasheet, the S2MPS13X and S2MPS14X should update write
 buffer via setting WUDR bit to high after ctrl register is updated.

 If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
 tools/testing/selftests/timers/rtctest.c test program and hour format is
 used to 12 hour mode in Odroid-XU3 board.

>>>
>>> >From what I understood, I should expect a v2 of tihat patch also setting
>>> RUDR, is that right? OR would you prefer that I apply that one and then
>>> fix RUDR in a following patch?
>>
>> Right, I would expect that as well... or a comment if this is not needed.
>>
> 
> Hmm, the driver only writes control register now, so i don't feel the
> need of patch setting RUDR for control register.

Yes, you're right. There is only regmap_write() (not
remap_update_bits()) so your patch is completely fine. Thanks for
explanation.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

> 
>> Best regards,
>> Krzysztof
>>
>>
>>>
 Signed-off-by: Joonyoung Shim 
 Cc: 
>>>
>>> can you update the stable tag with the kernel version introducing the
>>> issue?
> 
> Sure, i think it should be v3.16.
> 
>>>
 ---
  drivers/rtc/rtc-s5m.c | 12 
  1 file changed, 12 insertions(+)
>>>
 diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
 index 8c70d78..03828bb 100644
 --- a/drivers/rtc/rtc-s5m.c
 +++ b/drivers/rtc/rtc-s5m.c
 @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
 *info)
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
 +  if (ret < 0)
 +  break;
 +
 +  ret = regmap_update_bits(info->regmap,
 +  info->regs->rtc_udr_update,
 +  info->regs->rtc_udr_mask,
 +  info->regs->rtc_udr_mask);
>>>
>>> Very small indentation issue here, it should be aligned with the open
>>> parenthesis.
> 
> OK, i will.
> 
> 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/

€950,000.00 EURO

2015-08-20 Thread Qatar Foundation

Dear Beneficiary,
 d
You have been selected to receive €950,000.00 EURO as charity donations / aid 
of the Qatar Foundation. Reply back for more information and claims.

Yours sincerely,
Engineer Saad Al Muhannadi.

Reply to:qatarfu...@163.com

--

Lieber Zuschussempfänger,

Sie wurden ausgewählt, um € 950.000,00 EURO als Charity-Spenden / Hilfe der 
Qatar Foundation erhalten. Antwort zurück, um weitere Informationen und 
Ansprüche.

Antwort auf: qatarfu...@163.com

Mit freundlichen Grüßen,
Ingenieur Saad Al Muhannadi.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RESEND PATCH] dmaengine: Add Xilinx AXI Direct Memory Access Engine driver support

2015-08-20 Thread Moritz Fischer

Hi,

your MUA produces funny messages somehow ...
The driver did not probe for me in it's current form as the bindings
were missing interrupt parents for the interrupts...

On Thu, Aug 20, 2015 at 12:01 AM, Appana Durga Kedareswara Rao
 wrote:
> Hi ,
>
>> -Original Message-
>> From: dmaengine-ow...@vger.kernel.org [mailto:dmaengine-
>> ow...@vger.kernel.org] On Behalf Of Appana Durga Kedareswara Rao
>> Sent: Thursday, August 20, 2015 11:11 AM
>> To: Moritz Fischer
>> Cc: vinod.k...@intel.com; dan.j.willi...@intel.com; Michal Simek; Soren
>> Brinkmann; aniru...@xilinx.com; dmaeng...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; linux-arm-kernel
>> Subject: RE: [RESEND PATCH] dmaengine: Add Xilinx AXI Direct Memory Access
>> Engine driver support
>>
>> Hi Moritz Fischer,
>>
>>   Thanks for reviewing the patch.
>>
>> > -Original Message-
>> > From: Moritz Fischer [mailto:moritz.fisc...@ettus.com]
>> > Sent: Thursday, August 20, 2015 3:21 AM
>> > To: Appana Durga Kedareswara Rao
>> > Cc: vinod.k...@intel.com; dan.j.willi...@intel.com; Michal Simek;
>> > Soren Brinkmann; Appana Durga Kedareswara Rao; aniru...@xilinx.com;
>> > dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> > linux-arm-kernel; Srikanth Thokala
>> > Subject: Re: [RESEND PATCH] dmaengine: Add Xilinx AXI Direct Memory
>> > Access Engine driver support
>> >
>> > Hi there,
>> >
>> > see comment below. I just did a quick compile test. Will take another
>> > look once I synthesized an image.
>> >
>> > On Mon, Aug 17, 2015 at 8:31 AM, Kedareswara rao Appana
>> >  wrote:
>> > > This is the driver for the AXI Direct Memory Access (AXI DMA) core,
>> > > which is a soft Xilinx IP core that provides high- bandwidth direct
>> > > memory access between memory and AXI4-Stream type target peripherals.
>> > >
>> > > Signed-off-by: Srikanth Thokala 
>> > > Signed-off-by: Kedareswara rao Appana 
>> > > ---
>> > > The deivce tree doc got applied in the slave-dmaengine.git.
>> > >
>> > > Forgot to include dmaeng...@vger.kernel.org in the cc list resending
>> > > the patch.
>> > >
>> > > Changes in v8:
>> > > - Updated the SG handling as suggested by Nicolae Rosia.
>> > > - Removed the unnecessary xilinx_dma_channel_set_config API the
>> properties
>> > >   in this API is not being used by the driver.
>> > > Changes in v7:
>> > > - Updated license in the driver as suggested by Paul.
>> > > - Corrected return value in is_idle funtion.
>> > > Changes in v6:
>> > > - Fixed Odd indention in the Kconfig.
>> > > - used GFP_NOWAIT instead of GFP_KERNEL during the desc allocation
>> > > - Calculated residue in the tx_status instead of complete_descriptor.
>> > > - Update copy right to 2015.
>> > > - Modified spin_lock handling moved the spin_lock to the appropriate
>> > > functions (instead of xilinx_dma_start_transfer doing it
>> > xilinx_dma_issue_pending api).
>> > > - device_control and declare slave caps updated as per newer APi's.
>> > > Changes in v5:
>> > > - Modified the xilinx_dma.h header file location to the
>> > >   include/linux/dma/xilinx_dma.h
>> > > Changes in v4:
>> > > - Add direction field to DMA descriptor structure and removed from
>> > >   channel structure to avoid duplication.
>> > > - Check for DMA idle condition before changing the configuration.
>> > > - Residue is being calculated in complete_descriptor() and is reported
>> > >   to slave driver.
>> > > Changes in v3:
>> > > - Rebased on 3.16-rc7
>> > > Changes in v2:
>> > > - Simplified the logic to set SOP and APP words in prep_slave_sg().
>> > > - Corrected function description comments to match the return type.
>> > > - Fixed some minor comments as suggested by Andy.
>> > >
>> > >  drivers/dma/Kconfig |   13 +
>> > >  drivers/dma/xilinx/Makefile |1 +
>> > >  drivers/dma/xilinx/xilinx_dma.c | 1179
>> > > +++
>> > >  3 files changed, 1193 insertions(+)  create mode 100644
>> > > drivers/dma/xilinx/xilinx_dma.c
>> > >
>> > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index
>> > > 88d474b..5e95f07 100644
>> > > --- a/drivers/dma/Kconfig
>> > > +++ b/drivers/dma/Kconfig
>> > > @@ -507,4 +507,17 @@ config QCOM_BAM_DMA
>> > >   Enable support for the QCOM BAM DMA controller.  This 
>> > > controller
>> > >   provides DMA capabilities for a variety of on-chip devices.
>> > >
>> > > +config XILINX_DMA
>> > > +tristate "Xilinx AXI DMA Engine"
>> > > +depends on (ARCH_ZYNQ || MICROBLAZE)
>> > > +select DMA_ENGINE
>> > > +help
>> > > +  Enable support for Xilinx AXI DMA Soft IP.
>> > > +
>> > > +  This engine provides high-bandwidth direct memory access
>> > > +  between memory and AXI4-Stream type target peripherals.
>> > > +  It has two stream interfaces/channels, Memory Mapped to
>> > > +  Stream (MM2S) and Stream to Memory Mapped (S2MM) for the
>> > > +  data transfers.
>> > > +
>> > >  endif
>> > >

Re: [PATCH v3] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()

2015-08-20 Thread John Youn

On 8/19/2015 5:22 AM, Yunzhi Li wrote:
> We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
> be called before dwc2_get_hwparams() to reset core registers to
> default value. Without this the FIFO setting might be incorrect
> because calculating FIFO size need power-on value of
> GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers.
> 
> This patch could avoid warnning massage like in rk3288 platform:
> [2.074764] dwc2 ff58.usb: 256 invalid for
> host_perio_tx_fifo_size. Check HW configuration.
> 
> Signed-off-by: Yunzhi Li 
> 
> ---
> 
>  drivers/usb/dwc2/core.c |  2 +-
>  drivers/usb/dwc2/core.h |  1 +
>  drivers/usb/dwc2/platform.c | 21 -
>  3 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index c3cc1a7..86d1d65 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -474,7 +474,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg 
> *hsotg)
>   * Do core a soft reset of the core.  Be careful with this because it
>   * resets all the internal state machines of the core.
>   */
> -static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
> +int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>  {
>   u32 greset;
>   int count = 0;
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 0ed87620..5d95aec 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -846,6 +846,7 @@ enum dwc2_halt_status {
>   * The following functions support initialization of the core driver 
> component
>   * and the DWC_otg controller
>   */
> +extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
>  extern void dwc2_core_host_init(struct dwc2_hsotg *hsotg);
>  extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
>  extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 9093530..55d378a 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -166,7 +166,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
>   struct phy *phy;
>   struct usb_phy *uphy;
>   int retval;
> - int irq;
> + int irq, count = 0;
> + u32 greset;
>  
>   match = of_match_device(dwc2_of_match_table, >dev);
>   if (match && match->data) {
> @@ -243,6 +244,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
>   spin_lock_init(>lock);
>   mutex_init(>init_mutex);
>  
> + /*
> +  * Reset before dwc2_get_hwparams() then it could get power-on real
> +  * reset value form registers.
> +  */
> + count = 0;
> + greset |= GRSTCTL_CSFTRST;
> + writel(greset, hsotg->regs + GRSTCTL);
> + do {
> + usleep_range(2, 4);
> + greset = readl(hsotg->regs + GRSTCTL);
> + if (++count > 50) {
> + dev_warn(hsotg->dev,
> +  "%s() HANG! Soft Reset GRSTCTL=%0x\n",
> +  __func__, greset);
> + return -EBUSY;
> + }
> + } while (greset & GRSTCTL_CSFTRST);
> +


Could you move this out to a separate function so
that we don't have duplicate code?

Thanks,
John








--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc: s5m: fix to update ctrl register

2015-08-20 Thread Joonyoung Shim

On 08/21/2015 09:44 AM, Krzysztof Kozlowski wrote:
> On 21.08.2015 08:15, Alexandre Belloni wrote:
>> Hi,
>>
>> On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
>>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>>> buffer via setting WUDR bit to high after ctrl register is updated.
>>>
>>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>>> used to 12 hour mode in Odroid-XU3 board.
>>>
>>
>> >From what I understood, I should expect a v2 of tihat patch also setting
>> RUDR, is that right? OR would you prefer that I apply that one and then
>> fix RUDR in a following patch?
> 
> Right, I would expect that as well... or a comment if this is not needed.
> 

Hmm, the driver only writes control register now, so i don't feel the
need of patch setting RUDR for control register.

> Best regards,
> Krzysztof
> 
> 
>>
>>> Signed-off-by: Joonyoung Shim 
>>> Cc: 
>>
>> can you update the stable tag with the kernel version introducing the
>> issue?

Sure, i think it should be v3.16.

>>
>>> ---
>>>  drivers/rtc/rtc-s5m.c | 12 
>>>  1 file changed, 12 insertions(+)
>>
>>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>>> index 8c70d78..03828bb 100644
>>> --- a/drivers/rtc/rtc-s5m.c
>>> +++ b/drivers/rtc/rtc-s5m.c
>>> @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
>>> *info)
>>> case S2MPS13X:
>>> data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
>>> ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
>>> +   if (ret < 0)
>>> +   break;
>>> +
>>> +   ret = regmap_update_bits(info->regmap,
>>> +   info->regs->rtc_udr_update,
>>> +   info->regs->rtc_udr_mask,
>>> +   info->regs->rtc_udr_mask);
>>
>> Very small indentation issue here, it should be aligned with the open
>> parenthesis.

OK, i will.

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

Re: [PATCH] ASoC: Samsung: Remove redundant arndale_audio_remove

On 21.08.2015 01:41, Vaishali Thakkar wrote:
> There is no use of snd_soc_unregister_card in remove function
> as devm_snd_soc_register_card in probe function automatically
> handles it. So, remove use of snd_soc_unregister_card and with
> this change remove arndale_audio_remove as it is now redundant.
> 
> Signed-off-by: Vaishali Thakkar z
> ---
>  sound/soc/samsung/arndale_rt5631.c | 10 --
>  1 file changed, 10 deletions(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4 net-next 10/10] openvswitch: Allow attaching helpers to ct action

2015-08-20 Thread Joe Stringer

On 19 August 2015 at 15:57, Pravin Shelar  wrote:
> On Tue, Aug 18, 2015 at 4:39 PM, Joe Stringer  wrote:
>> Add support for using conntrack helpers to assist protocol detection.
>> The new OVS_CT_ATTR_HELPER attribute of the ct action specifies a helper
>> to be used for this connection.
>>
>> Example ODP flows allowing FTP connections from ports 1->2:
>> in_port=1,tcp,action=ct(helper=ftp,commit),2
>> in_port=2,tcp,ct_state=-trk,action=ct(),recirc(1)
>> recirc_id=1,in_port=2,tcp,ct_state=+trk-new+est,action=1
>> recirc_id=1,in_port=2,tcp,ct_state=+trk+rel,action=1
>>
>> Signed-off-by: Joe Stringer 
>> ---
>> v2-v3: No change.
>> v4: Change error code for unknown helper ENOENT->EINVAL.
>
> I got following compilation warning :
>
> net/openvswitch/conntrack.c:352:42: error: incompatible types in
> comparison expression (different address spaces)

Is this made available via another sparse flag? It looks like it's
related to the __rcu as you've mentioned below, but I'm not seeing
this (latest sparse, gcc-4.9.2)

>> +static int ovs_ct_add_helper(struct ovs_conntrack_info *info, const char 
>> *name,
>> +const struct sw_flow_key *key, bool log)
>> +{
>> +   struct nf_conntrack_helper *helper;
>> +   struct nf_conn_help *help;
>> +
>> +   helper = nf_conntrack_helper_try_module_get(name, info->family,
>> +   key->ip.proto);
>> +   if (!helper) {
>> +   OVS_NLERR(log, "Unknown helper \"%s\"", name);
>> +   return -EINVAL;
>> +   }
>> +
>> +   help = nf_ct_helper_ext_add(info->ct, helper, GFP_KERNEL);
>> +   if (!help) {
>> +   module_put(helper->me);
>> +   return -ENOMEM;
>> +   }
>> +
>> +   help->helper = helper;
> helper is rcu pointer so need to use rcu API to set the value. I know
> it is not required here, but it is still cleaner to use the API.

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

Re: linux-next conflict resolution branch for btrfs

Hi Chris,

On Thu, 20 Aug 2015 13:39:18 -0400 Chris Mason  wrote:
>
> There are a few conflicts for btrfs in linux-next this time.  They are
> small, but I pushed out the merge commit I'm using here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git next-merge

Thanks for that.  It seems to have merged OK but maybe it conflicts
with something later in linux-next.  Unfortunately see my other email
about a build problem.  I will keep this example merge in mind for
later.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc: s5m: fix to update ctrl register

On 21.08.2015 08:15, Alexandre Belloni wrote:
> Hi,
> 
> On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>> buffer via setting WUDR bit to high after ctrl register is updated.
>>
>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>> used to 12 hour mode in Odroid-XU3 board.
>>
> 
>>From what I understood, I should expect a v2 of tihat patch also setting
> RUDR, is that right? OR would you prefer that I apply that one and then
> fix RUDR in a following patch?

Right, I would expect that as well... or a comment if this is not needed.

Best regards,
Krzysztof


> 
>> Signed-off-by: Joonyoung Shim 
>> Cc: 
> 
> can you update the stable tag with the kernel version introducing the
> issue?
> 
>> ---
>>  drivers/rtc/rtc-s5m.c | 12 
>>  1 file changed, 12 insertions(+)
> 
>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>> index 8c70d78..03828bb 100644
>> --- a/drivers/rtc/rtc-s5m.c
>> +++ b/drivers/rtc/rtc-s5m.c
>> @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
>> *info)
>>  case S2MPS13X:
>>  data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
>>  ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
>> +if (ret < 0)
>> +break;
>> +
>> +ret = regmap_update_bits(info->regmap,
>> +info->regs->rtc_udr_update,
>> +info->regs->rtc_udr_mask,
>> +info->regs->rtc_udr_mask);
> 
> Very small indentation issue here, it should be aligned with the open
> parenthesis.
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] joystick/zhenhua: remove zhenhua_bitreverse()

2015-08-20 Thread Dmitry Torokhov

On Tue, Aug 11, 2015 at 01:49:34PM +0800, yalin wang wrote:
> This change remove zhenhua_bitreverse() function, use generic
> bitrev8() function instead.
> 
> Signed-off-by: yalin wang 

Applied, thank you.

> ---
>  drivers/input/joystick/zhenhua.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/input/joystick/zhenhua.c 
> b/drivers/input/joystick/zhenhua.c
> index 30af2e8..4a8258b 100644
> --- a/drivers/input/joystick/zhenhua.c
> +++ b/drivers/input/joystick/zhenhua.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -72,16 +73,6 @@ struct zhenhua {
>   char phys[32];
>  };
>  
> -
> -/* bits in all incoming bytes needs to be "reversed" */
> -static int zhenhua_bitreverse(int x)
> -{
> - x = ((x & 0xaa) >> 1) | ((x & 0x55) << 1);
> - x = ((x & 0xcc) >> 2) | ((x & 0x33) << 2);
> - x = ((x & 0xf0) >> 4) | ((x & 0x0f) << 4);
> - return x;
> -}
> -
>  /*
>   * zhenhua_process_packet() decodes packets the driver receives from the
>   * RC transmitter. It updates the data accordingly.
> @@ -120,7 +111,7 @@ static irqreturn_t zhenhua_interrupt(struct serio *serio, 
> unsigned char data, un
>   return IRQ_HANDLED; /* wrong MSB -- ignore this byte */
>  
>   if (zhenhua->idx < ZHENHUA_MAX_LENGTH)
> - zhenhua->data[zhenhua->idx++] = zhenhua_bitreverse(data);
> + zhenhua->data[zhenhua->idx++] = bitrev8(data);
>  
>   if (zhenhua->idx == ZHENHUA_MAX_LENGTH) {
>   zhenhua_process_packet(zhenhua);
> -- 
> 1.9.1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

linux-next: build failure after merge of the btrfs tree

Hi all,

After merging the btrfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/btrfs/extent_io.c: In function 'btrfs_bio_clone':
fs/btrfs/extent_io.c:2734:10: error: 'struct bio' has no member named 'bi_css'
   if (bio->bi_css)
  ^
fs/btrfs/extent_io.c:2735:32: error: 'struct bio' has no member named 'bi_css'
bio_associate_blkcg(new, bio->bi_css);
^
fs/btrfs/volumes.c: In function 'breakup_stripe_bio':
fs/btrfs/volumes.c:5958:15: error: 'struct bio' has no member named 'bi_ioc'
  if (first_bio->bi_ioc) {
   ^
fs/btrfs/volumes.c:5959:34: error: 'struct bio' has no member named 'bi_ioc'
   get_io_context_active(first_bio->bi_ioc);
  ^
fs/btrfs/volumes.c:5960:6: error: 'struct bio' has no member named 'bi_ioc'
   bio->bi_ioc = first_bio->bi_ioc;
  ^
fs/btrfs/volumes.c:5960:26: error: 'struct bio' has no member named 'bi_ioc'
   bio->bi_ioc = first_bio->bi_ioc;
  ^
fs/btrfs/volumes.c:5962:15: error: 'struct bio' has no member named 'bi_css'
  if (first_bio->bi_css) {
   ^
fs/btrfs/volumes.c:5963:20: error: 'struct bio' has no member named 'bi_css'
   css_get(first_bio->bi_css);
^
fs/btrfs/volumes.c:5964:6: error: 'struct bio' has no member named 'bi_css'
   bio->bi_css = first_bio->bi_css;
  ^
fs/btrfs/volumes.c:5964:26: error: 'struct bio' has no member named 'bi_css'
   bio->bi_css = first_bio->bi_css;
  ^

Caused by commit

  da2f0f74cf7d ("Btrfs: add support for blkio controllers")

This build does ont have CONFIG_BLK_CGROUP set.

I have used the btrfs tree from next-20150820 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4 net-next 06/10] openvswitch: Allow matching on conntrack mark

2015-08-20 Thread Joe Stringer

On 19 August 2015 at 13:47, Pravin Shelar  wrote:
> On Tue, Aug 18, 2015 at 4:39 PM, Joe Stringer  wrote:
>> Allow matching and setting the conntrack mark field. As with conntrack
>> state and zone, these are populated when the CT action is executed,
>> and are made available for matching via RECIRC. To write to this field,
>> a value and optional mark can be passed as part of the conntrack action.
>>
>> E.g.: actions:ct(zone=0),ct(zone=1,mark=1)
>>
>> This will perform conntrack lookup in zone 0, then lookup in zone 1,
>> then modify the mark for the entry in zone 1. The conntrack entry itself
>> must be committed using the "commit" flag in the conntrack action flags
>> for this change to persist.
>>
>> Signed-off-by: Justin Pettit 
>> Signed-off-by: Joe Stringer 
>> ---
>> v1-v3: No change.
>> v4: Only allow setting conntrack mark via ct action.
>> Documentation tweaks.
>> ---
>>  include/uapi/linux/openvswitch.h |  5 
>>  net/openvswitch/actions.c|  1 +
>>  net/openvswitch/conntrack.c  | 61 
>> ++--
>>  net/openvswitch/conntrack.h  |  1 +
>>  net/openvswitch/flow.h   |  1 +
>>  net/openvswitch/flow_netlink.c   | 15 +-
>>  6 files changed, 80 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/uapi/linux/openvswitch.h 
>> b/include/uapi/linux/openvswitch.h
>> index 55f5997..7a185b5 100644
>> --- a/include/uapi/linux/openvswitch.h
>> +++ b/include/uapi/linux/openvswitch.h
>> @@ -325,6 +325,7 @@ enum ovs_key_attr {
>>  * the accepted length of the array. */
>> OVS_KEY_ATTR_CT_STATE,  /* u8 bitmask of OVS_CS_F_* */
>> OVS_KEY_ATTR_CT_ZONE,   /* u16 connection tracking zone. */
>> +   OVS_KEY_ATTR_CT_MARK,   /* u32 connection tracking mark */
>>
>>  #ifdef __KERNEL__
>> OVS_KEY_ATTR_TUNNEL_INFO,  /* struct ip_tunnel_info */
>> @@ -613,11 +614,15 @@ struct ovs_action_hash {
>>   * enum ovs_ct_attr - Attributes for %OVS_ACTION_ATTR_CT action.
>>   * @OVS_CT_ATTR_FLAGS: u32 connection tracking flags.
>>   * @OVS_CT_ATTR_ZONE: u16 connection tracking zone.
>> + * @OVS_CT_ATTR_MARK: u32 value followed by u32 mask. For each bit set in 
>> the
>> + * mask, the corresponding bit in the value is copied to the connection
>> + * tracking mark field in the connection.
>>   */
>>  enum ovs_ct_attr {
>> OVS_CT_ATTR_UNSPEC,
>> OVS_CT_ATTR_FLAGS,  /* u8 bitmask of OVS_CT_F_*. */
>> OVS_CT_ATTR_ZONE,   /* u16 zone id. */
>> +   OVS_CT_ATTR_MARK,   /* mark to associate with this connection. */
>> __OVS_CT_ATTR_MAX
>>  };
>>
> ovs_ct_action_to_attr() is not updated to return complete datapath
> action back to userpsace. same issue exist in set label patch.

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

Re: [PATCHv4 net-next 09/10] openvswitch: Allow matching on conntrack label

2015-08-20 Thread Joe Stringer

On 20 August 2015 at 14:01, Pravin Shelar  wrote:
> On Thu, Aug 20, 2015 at 12:13 PM, Joe Stringer  wrote:
>> On 20 August 2015 at 08:45, Pravin Shelar  wrote:
>>> On Wed, Aug 19, 2015 at 4:04 PM, Joe Stringer  
>>> wrote:
 Thanks for the review,

 On 19 August 2015 at 14:24, Pravin Shelar  wrote:
> On Tue, Aug 18, 2015 at 4:39 PM, Joe Stringer  
> wrote:
>> Allow matching and setting the conntrack label field. As with ct_mark,
>> this is populated by executing the CT action, and is a writable field.
>> Specifying a label and optional mask allows the label to be modified,
>> which takes effect on the entry found by the lookup of the CT action.
>>
>> E.g.: actions:ct(zone=1,label=1)
>>
>> This will perform conntrack lookup in zone 1, then modify the label for
>> that entry. The conntrack entry itself must be committed using the
>> "commit" flag in the conntrack action flags for this change to persist.
>>
>>>

>> return false;
>>  }
>> @@ -508,8 +601,12 @@ void ovs_ct_free_action(const struct nlattr *a)
>>
>>  void ovs_ct_init(struct net *net, struct ovs_ct_perdp_data *data)
>>  {
>> +   unsigned int n_bits = sizeof(struct ovs_key_ct_label) * 
>> BITS_PER_BYTE;
>> +
>> data->xt_v4 = !nf_ct_l3proto_try_module_get(PF_INET);
>> data->xt_v6 = !nf_ct_l3proto_try_module_get(PF_INET6);
>> +   if (nf_connlabels_get(net, n_bits);
>> +   OVS_NLERR(true, "Failed to set connlabel length");
>>  }
>>
> In case of error should we reject conntrack label actions? Otherwise
> user will never see any error. But action could drop packets.

 I suspect that currently errors would be seen from ovs_ct_set_label():

>...if (!cl || cl->words * sizeof(long) < OVS_CT_LABEL_LEN)
>...>...return -ENOSPC;

 So, for cmd_execute, userspace would see this. For regular handling,
 pipeline processing would stop (so, drop).

 However, I agree it would be more friendly to have the attribute
 rejected up-front. Just means we'll pass the datapath all the way
 down:
 ovs_nla_get_match()
 --> ovs_key_from_nlattrs()
 --> metadata_from_nlattrs()
 --> ovs_ct_verify()
>>
>> Incidentally, we generally don't have the datapath by this point
>> (ovs_nla_get_match()). There'd need to be a bit of rearranging in the
>> ovs_flow_cmd_* functions, which would include holding the locks for
>> longer. Given that the two most common cases are that either A) The
>> kernel is configured with connlabel support, and built with support
>> for at least 128 bits of label, or B) the kernel is configured without
>> connlabel, and this is handled already in ovs_ct_verify(), I don't
>> think it's worth making this particular change.
>
> Actually I do not see need for this to be per datapath property.
> infact there is no need to have struct ovs_ct_perdp_data.
> ovs_ct_init can be called from ovs-module init.
> nf-connlabel bit length is per net-namespace property. So
> nf_connlabels_get()  should be called from ovs namespace init. This
> way you can move xt_label flag to ovs_net. ovs_net can be accessed
> from ovs_flow_cmd_* functions.

That sounds like a tidier approach, I'll roll it into the next version.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] [media] staging: omap4iss: get entity ID using media_entity_id()

2015-08-20 Thread Javier Martinez Canillas

Hello Laurent,

On 08/21/2015 02:15 AM, Laurent Pinchart wrote:
> Hi Javier,
> 
> On Friday 21 August 2015 02:14:05 Javier Martinez Canillas wrote:
>> On 08/20/2015 08:37 PM, Laurent Pinchart wrote:
>>> On Wednesday 19 August 2015 17:35:19 Javier Martinez Canillas wrote:
 The struct media_entity does not have an .id field anymore since
 now the entity ID is stored in the embedded struct media_gobj.

 This caused the omap4iss driver fail to build. Fix by using the
 media_entity_id() macro to obtain the entity ID.

 Signed-off-by: Javier Martinez Canillas 
>>>
>>> This looks fine to me. The patch needs to be moved between Mauro's 1/8 and
>>> 2/8 patches to avoid breaking bisection with patch 3/8. I'd squash this
>>> patch and 2/4 into a single "media: Use media_entity_id() in drivers"
>>> patch.
>>
>> Yes, Hans and Mauro already mentioned it and I completely agree that
>> should be squashed with Mauro's patch to maintain git bisect-ability.
> 
> I wouldn't squash patches 1/4 and 2/4 into Mauro's 3/8 patch as Hans 
> proposed, 
> but instead squashing them together into a single patch and move the result 
> as 
> 1.5/8 in Mauro's series.
> 

I see. I don't mind either option tbh, I'm OK with whatever works better.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] [media] staging: omap4iss: get entity ID using media_entity_id()

2015-08-20 Thread Laurent Pinchart

Hi Javier,

On Friday 21 August 2015 02:14:05 Javier Martinez Canillas wrote:
> On 08/20/2015 08:37 PM, Laurent Pinchart wrote:
> > On Wednesday 19 August 2015 17:35:19 Javier Martinez Canillas wrote:
> >> The struct media_entity does not have an .id field anymore since
> >> now the entity ID is stored in the embedded struct media_gobj.
> >> 
> >> This caused the omap4iss driver fail to build. Fix by using the
> >> media_entity_id() macro to obtain the entity ID.
> >> 
> >> Signed-off-by: Javier Martinez Canillas 
> > 
> > This looks fine to me. The patch needs to be moved between Mauro's 1/8 and
> > 2/8 patches to avoid breaking bisection with patch 3/8. I'd squash this
> > patch and 2/4 into a single "media: Use media_entity_id() in drivers"
> > patch.
>
> Yes, Hans and Mauro already mentioned it and I completely agree that
> should be squashed with Mauro's patch to maintain git bisect-ability.

I wouldn't squash patches 1/4 and 2/4 into Mauro's 3/8 patch as Hans proposed, 
but instead squashing them together into a single patch and move the result as 
1.5/8 in Mauro's series.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/4] [media] staging: omap4iss: get entity ID using media_entity_id()

2015-08-20 Thread Javier Martinez Canillas

Hello Laurent,

On 08/20/2015 08:37 PM, Laurent Pinchart wrote:
> Hi Javier,
> 
> Thank you for the patch.
> 
> On Wednesday 19 August 2015 17:35:19 Javier Martinez Canillas wrote:
>> The struct media_entity does not have an .id field anymore since
>> now the entity ID is stored in the embedded struct media_gobj.
>>
>> This caused the omap4iss driver fail to build. Fix by using the
>> media_entity_id() macro to obtain the entity ID.
>>
>> Signed-off-by: Javier Martinez Canillas 
> 
> This looks fine to me. The patch needs to be moved between Mauro's 1/8 and 
> 2/8 
> patches to avoid breaking bisection with patch 3/8. I'd squash this patch and 
> 2/4 into a single "media: Use media_entity_id() in drivers" patch.
> 

Yes, Hans and Mauro already mentioned it and I completely agree that
should be squashed with Mauro's patch to maintain git bisect-ability.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management

2015-08-20 Thread Vikas Shivappa




On Thu, 20 Aug 2015, Vikas Shivappa wrote:




On Mon, 17 Aug 2015, Marcelo Tosatti wrote:


Vikas, Tejun,

This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
covers.

Let me know what you think. I'll proceed to writing
the test applications.

Usage model:


This document details how CAT technology is
exposed to userspace.

Each task has a list of task cache reservation entries (TCRE list).

The init process is created with empty TCRE list.

There is a system-wide unique ID space, each TCRE is assigned
an ID from this space. ID's can be reused (but no two TCREs
have the same ID at one time).

The interface accomodates transient and independent cache allocation
adjustments from applications, as well as static cache partitioning
schemes.

Allocation:
Usage of the system calls require CAP_SYS_CACHE_RESERVATION capability.

A configurable percentage is reserved to tasks with empty TCRE list.


And how do you think you will do this without a system controlled mechanism ? 
Everytime in your proposal you include these caveats which actually mean to 
include a system controlled interface in the background ,
and your below interfaces make no mention of this really ! Why do we want to 
confuse ourselves like this ?


syscall only interface does not seem to work on its own for the cache 
allocation scenario. This can only be a nice to have interface on top of a 
system controlled mechanism like cgroup interface. Sure you can do all the 
things you did with cgroup with the same with syscall interface but the point 
is what are the use cases that cant be done with this syscall only interface. 
(ex: to deal with cases you brought up earlier like when an app does cache 
intensive work for some time and later changes - it could use the syscall 
interface to quickly reqlinquish the cache lines or change a clos associated 
with it)


I have repeatedly listed the use cases that can be dealt with , with this 

big typo - 'use cases that cannot be dealt with'

interface. How will you address the cases like 1.1 and 1.2 with your syscall 
only interface ? So we expect all the millions of apps like SAP, oracle etc 
and etc and all the millions of app developers to magically learn our new 
syscall interface and also cooperate between themselves to decide a cache 
allocation that is agreeable to all ?  (which btw the interface doesnt list 
below how to do it) and then by some godly powers the noisly neighbour will 
decide himself to give up the cache ? (that should be first ever app to not 
request more resource in the world for himself and hurt his own performance - 
they surely dont want to do social service !)


And how do we do the case 1.5 where the administrator want to assign cache to 
specific VMs in a cloud etc - with the hypothetical syscall interface we now 
should expect all the apps to do the above and now they also need to know 
where they run (what VM , what socket etc) and then decide and cooperate an 
allocation : compare this to a container environment like rancher where today 
the admin can convinetly use docker underneath to allocate 
mem/storage/compute to containers and easily extend this to include shared 
l3.


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

without addressing the above the details of the interface below is irrelavant 
-


Your initial request was to extend the cgroup interface to include rounding 
off the size of cache (which can easily be done with a bash script on top of 
cgroup interface !) and now you are proposing a syscall only interface ? this 
is very confusing and will only unnecessarily delay the process without 
adding any value.


however like i mentioned the syscall interface or user/app being able to 
modify the cache alloc could be used to address some very specific use cases 
on top an existing system managed interface. This is not really a common case 
in cloud or container environment and neither a feasible deployable solution.
Just consider the millions of apps that have to transition to such an 
interface to even use it - if thats the only way to do it, thats dead on 
arrival.


Also please donot include kernel automatically adjusting resources in your 
reply as thats totally irrelavent and again more confusing as we have already 
exchanged some >100 emails on this same patch version without meaning 
anything so far.


The debate is purely between a syscall only interface and a system manageable 
interface(like cgroup where admin or a central entity controls the 
resources). If not define what is it first before going into details.


Thanks,
Vikas



On fork, the child inherits the TCR from its parent.

Semantics:
Once a TCRE is created and assigned to a task, that task has
guaranteed reservation on any CPU where its scheduled in,
for the lifetime of the TCRE.

A task can have its TCR list modified without notification.

FIXME: Add a per-task flag to not copy the TCR list of a task but

Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management

2015-08-20 Thread Vikas Shivappa

On Mon, 17 Aug 2015, Marcelo Tosatti wrote:

Vikas, Tejun,

This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
covers.

Let me know what you think. I'll proceed to writing
the test applications.

Usage model:

This document details how CAT technology is
exposed to userspace.

Each task has a list of task cache reservation entries (TCRE list).

The init process is created with empty TCRE list.

There is a system-wide unique ID space, each TCRE is assigned
an ID from this space. ID's can be reused (but no two TCREs
have the same ID at one time).

The interface accomodates transient and independent cache allocation
adjustments from applications, as well as static cache partitioning
schemes.

Allocation:
Usage of the system calls require CAP_SYS_CACHE_RESERVATION capability.

A configurable percentage is reserved to tasks with empty TCRE list.

And how do you think you will do this without a system controlled mechanism ?
Everytime in your proposal you include these caveats which actually mean to
include a system controlled interface in the background ,
and your below interfaces make no mention of this really ! Why do we want to
confuse ourselves like this ?

syscall only interface does not seem to work on its own for the cache
allocation scenario. This can only be a nice
to have interface on top of a system controlled mechanism like cgroup interface.
Sure you can do all the things you did with cgroup with the same with syscall
interface but the point is what are the use cases that cant be done with this
syscall only interface. (ex: to deal with cases you brought up earlier like when
an app does cache intensive work for some time and later changes - it could use
the syscall interface to quickly reqlinquish the cache lines or change a clos
associated with it)

I have repeatedly listed the use cases that can be dealt with , with this
interface. How will you address the cases like 1.1 and 1.2 with your syscall
only interface ? So we expect all the millions of apps like SAP, oracle etc and
etc and all the millions of app developers to magically learn our new syscall
interface and also cooperate between themselves to decide a cache allocation
that is agreeable to all ? (which btw the interface doesnt list below how to do
it) and then by some godly powers the noisly neighbour will decide himself to
give up the cache ? (that should be first ever app to not request more resource
in the world for himself and hurt his own performance - they surely dont want
to do social service !)

And how do we do the case 1.5 where the administrator want to assign cache to
specific VMs in a cloud etc - with the hypothetical syscall interface we now
should expect all the apps to do the above and now they also need to know where they run (what
VM , what socket etc) and then decide and cooperate an allocation : compare this
to a container environment like rancher where today the admin can convinetly use
docker underneath to allocate mem/storage/compute to containers and easily
extend this to include shared l3.

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

without addressing the above the details of the interface below is irrelavant -

Your initial request was to extend the cgroup interface to include rounding off
the size of cache (which can easily be done with a bash script on top of cgroup
interface !) and now you are proposing a syscall only interface ? this is
very confusing and will only unnecessarily delay the process without adding any
value.

however like i mentioned the syscall interface or user/app being able to modify
the cache alloc could be used to address some very specific use
cases on top an existing system managed interface. This is not really a common
case in cloud or container environment and neither a feasible deployable
solution.
Just consider the millions of apps that have to transition to such an interface
to even use it - if thats the only way to do it, thats dead on arrival.

Also please donot include kernel automatically adjusting resources in your reply
as thats totally irrelavent and again more confusing as we have already
exchanged some >100 emails on this same patch version without meaning anything
so far.

The debate is purely between a syscall only
interface and a system manageable interface(like cgroup where admin or a central
entity controls the resources). If not define what is it first before going into
details.

Thanks,
Vikas

On fork, the child inherits the TCR from its parent.

Semantics:
Once a TCRE is created and assigned to a task, that task has
guaranteed reservation on any CPU where its scheduled in,
for the lifetime of the TCRE.

A task can have its TCR list modified without notification.

FIXME: Add a per-task flag to not copy the TCR list of a task but delete
all TCR's on fork.

Interface:

enum cache_rsvt_flags {
CACHE_RSVT_ROUND_DOWN = (1

Re: [RFC] fs/kcore: change copy_to_user to copy_in_user

2015-08-20 Thread Linus Torvalds

On Thu, Aug 20, 2015 at 1:59 AM, yalin wang  wrote:
> -
> -   n = copy_to_user(buffer, (char *)start, tsz);
> +   if ((start + tsz < tsz) ||
> +   (start + tsz) > TASK_SIZE)
> +   return -EFAULT;

This is wrong. You apparently want to have

if (!access_ok(start, tsz))
return -EFAULT;

> +   set_fs(KERNEL_DS);
> +   n = copy_in_user(buffer, (char *)start, tsz);
> +   set_fs(USER_DS);

.. and this is actually worse and even less portable than what we have
now, in that it's actively wrong on platforms that may have a user
address and a kernel address with the same value (ie they have
explicitly separate kernel/user address spaces).

Now, that's admittedly unusual, but I think sparc32 actually can do that.

Anyway, I absolutely detest this patch. It replaces one piece of code
that admittedly doesn't work on all architectures because kernel
memory is accessed without testing, with another hack that happens to
work on other architectures and is fragile and prone to be a security
issue.

In other words, I think the end result is _worse_ than the current situation.

You probably want to use "probe_kernel_read()" and do it into a
temporary buffer, and then just do the copy_to_user() from the
temporary buffer. Sure, it's less efficient, but at least it's not
actively wrong and a possible security problem in the long run.

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: [GIT PULL] TTY/Serial patches for 4.3-rc1

2015-08-20 Thread Fabio Estevam

Hi Stephen,

On Thu, Aug 20, 2015 at 8:57 PM, Stephen Rothwell  wrote:
> Hi Greg,
>
> On Thu, 20 Aug 2015 12:11:21 -0700 Greg KH  wrote:
>>
>> All have been in linux-next with no reported issues.
>
> Except see below.
>
>> Eduardo Valentin (4):
>>   serial: imx: introduce serial_imx_enable_wakeup()
>
> I reported that this commit breaks the arm multi_v7_defconfig build and
> I have seen no fix applied.
>
> I have been applying the following patch for a few days but do not know
> if it is the correct resolution:

This is the correct solution as there is really no imx6sl-fox-p1.dts file.

Regards,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] at91: defconfig for 4.3 #2

2015-08-20 Thread Olof Johansson

On Thu, Aug 20, 2015 at 4:58 PM, Alexandre Belloni
 wrote:
> Hi,
>
> On 18/08/2015 at 23:49:30 +0200, Olof Johansson wrote :
>> > The only thing now is that since the at91 tree is in linux-next as well
>> > as the arm-soc tree, those patches appear twice there and there is a
>> > conflict (easy to fix, but a pain).  The solution here is to update the
>> > at91 tree to be somewhere in the arm-soc tree (probably just reset to
>> > the point where the two trees match in patches but not commits).  This
>> > has the downside that the at91 tree will be rebased which will affect
>> > any development work that is based on that.
>> >
>> > If there was just one patch in common, it maybe have been better to
>> > just merge the at91 tree and fix the conflict in the merge.
>>
>> Yeah, this is a somewhat frustrating situation for us. I wonder if we
>> should essentially tag the downstream ARM platform trees in -next such
>> that if they conflict with arm-soc, you can drop them for a day if
>> needed.
>>
>> It's really useful for us to be able to occasionally adjust a pull
>> request instead of always merging them exactly as they're presented to
>> us. It saves a roundtrip to the maintainer for trivial stuff, we can
>> take care of it and not have to look at it again. We often do send it
>> back to the maintainers to respin, but in this particular case it
>> seemed appropriate to just deal with it locally for us.
>>
>> The downstream users vs rebasing git trees is of course another
>> aspect. Here I'm mostly relying on subplatform maintainers to know
>> well how many people actually develop on top of their trees. I think
>> for most platforms it's a fairly limited use. Interesting enough, I
>> can't remember last time someone told me they couldn't respin a pull
>> request to fix something up due to downstream developers (not that we
>> have _all_ that many of those requests).
>>
>
> I think there is no issue to rebase at91-next apart from Nicolas being
> on holiday and the fact that I don't have access to it.
>
>> The other way to handle this would be to only apply patches directly
>> and not do merges. Most other high-volume maintainers have exactly
>> this workflow. We've been able to avoid reverting to that, thankfully
>> (since we can delegate most of the reviews and patch applications this
>> way).
>>
>
> On an other topic but not completely unrelated, I see that you are
> adding your SoB only on merge commits so basically, when the merge is a
> fast forward, your SoB doesn't appear at all.
> For now, I've chosen to apply PRs as patches to add my SoB, is that
> something I can avoid?

Right, we can't add a S-o-b on non-merge commits since that would in
effect be a rebase.

Also, we never do ff merges in our tree, since it hides the merge path
and we want to make it possible to determine who merged the code.

The fact that we add S-o-b on the merge commit is sort of nonstandard,
but it shows which one of us did the merge (the commit author would
too, but it does happen that we rebase).


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

Re: [PATCH v3 0/5] sync a se with its cfs_rq when att(det)aching it

2015-08-20 Thread Byungchul Park

On Thu, Aug 20, 2015 at 11:11:31PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 20, 2015 at 07:46:09PM +0900, Byungchul Park wrote:
> > On Thu, Aug 20, 2015 at 05:38:41PM +0900, Byungchul Park wrote:
> > > On Thu, Aug 20, 2015 at 03:17:21AM +0200, Peter Zijlstra wrote:
> > > > 
> > > > I did something like this on top.. please have a look at the XXX and
> > > > integrate.
> > > 
> > > i am not sure, what do you intend for me to do.
> > > 
> > > do you mean that i am supposed to integrate this cleanup patch you gave me
> > > including the XXX comment?
> 
> No, the intent was for you to think about the point marked XXX, which
> you've done below.
> 
> > > > +*
> > > > +* XXX this appears wrong!! check history, 
> > > > +* we appear to always set queued and RUNNING under the same 
> > > > lock instance
> > > > +* might be from before TASK_WAKING ?
> > > >  */
> > > 
> > > is it impossible to happen to check if vruntime is normalized, when doing
> > > something like e.g. active load balance where queued != TASK_ON_RQ_QUEUED
> > > and p->state == TASK_RUNNING?
> > 
> > furthermore, in any migration by load balance, it seems to be possible..
> > 
> > > 
> > > i think it can happen..
> 
> OK, then we need to change the comment to reflect the actual reason the
> test is needed. Because I think the currently described scenario is
> incorrect.

what is the currently described scenario to need to change?

then.. did i change patches as what you suggested, in v4?

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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: [GIT PULL] at91: defconfig for 4.3 #2

Hi,

On 18/08/2015 at 23:49:30 +0200, Olof Johansson wrote :
> > The only thing now is that since the at91 tree is in linux-next as well
> > as the arm-soc tree, those patches appear twice there and there is a
> > conflict (easy to fix, but a pain).  The solution here is to update the
> > at91 tree to be somewhere in the arm-soc tree (probably just reset to
> > the point where the two trees match in patches but not commits).  This
> > has the downside that the at91 tree will be rebased which will affect
> > any development work that is based on that.
> >
> > If there was just one patch in common, it maybe have been better to
> > just merge the at91 tree and fix the conflict in the merge.
> 
> Yeah, this is a somewhat frustrating situation for us. I wonder if we
> should essentially tag the downstream ARM platform trees in -next such
> that if they conflict with arm-soc, you can drop them for a day if
> needed.
> 
> It's really useful for us to be able to occasionally adjust a pull
> request instead of always merging them exactly as they're presented to
> us. It saves a roundtrip to the maintainer for trivial stuff, we can
> take care of it and not have to look at it again. We often do send it
> back to the maintainers to respin, but in this particular case it
> seemed appropriate to just deal with it locally for us.
> 
> The downstream users vs rebasing git trees is of course another
> aspect. Here I'm mostly relying on subplatform maintainers to know
> well how many people actually develop on top of their trees. I think
> for most platforms it's a fairly limited use. Interesting enough, I
> can't remember last time someone told me they couldn't respin a pull
> request to fix something up due to downstream developers (not that we
> have _all_ that many of those requests).
> 

I think there is no issue to rebase at91-next apart from Nicolas being
on holiday and the fact that I don't have access to it.

> The other way to handle this would be to only apply patches directly
> and not do merges. Most other high-volume maintainers have exactly
> this workflow. We've been able to avoid reverting to that, thankfully
> (since we can delegate most of the reviews and patch applications this
> way).
> 

On an other topic but not completely unrelated, I see that you are
adding your SoB only on merge commits so basically, when the merge is a
fast forward, your SoB doesn't appear at all.
For now, I've chosen to apply PRs as patches to add my SoB, is that
something I can avoid?

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

Re: [GIT PULL] TTY/Serial patches for 4.3-rc1

Hi Greg,

On Thu, 20 Aug 2015 12:11:21 -0700 Greg KH  wrote:
>
> All have been in linux-next with no reported issues.

Except see below.

> Eduardo Valentin (4):
>   serial: imx: introduce serial_imx_enable_wakeup()

I reported that this commit breaks the arm multi_v7_defconfig build and
I have seen no fix applied.

I have been applying the following patch for a few days but do not know
if it is the correct resolution:

From: Stephen Rothwell 
Date: Tue, 18 Aug 2015 15:56:40 +1000
Subject: [PATCH] serial: imx: partial revert of "introduce 
serial_imx_enable_wakeup()"

This reverts the part of commit 189550b8644e that affects
arch/arm/boot/dts/Makefile

Signed-off-by: Stephen Rothwell 
---
 arch/arm/boot/dts/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d3ee1f01ffc7..233159d2eaab 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -330,7 +330,6 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-wandboard-revb1.dtb
 dtb-$(CONFIG_SOC_IMX6SL) += \
imx6sl-evk.dtb \
-   imx6sl-fox-p1.dtb \
imx6sl-warp.dtb
 dtb-$(CONFIG_SOC_IMX6SX) += \
imx6sx-sabreauto.dtb \
-- 
2.5.0

-- 
Cheers,
Stephen Rothwell
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] sched: sync a se with its cfs_rq when switching sched class to fair class

2015-08-20 Thread Byungchul Park

On Thu, Aug 20, 2015 at 11:13:23PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 20, 2015 at 04:11:06AM +0800, Yuyang Du wrote:
> > On Wed, Aug 19, 2015 at 07:12:41PM +0200, Peter Zijlstra wrote:
> > > On Wed, Aug 19, 2015 at 03:47:15PM +0900, byungchul.p...@lge.com wrote:
> > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > > index 1be042a..3419f6c 100644
> > > > --- a/kernel/sched/fair.c
> > > > +++ b/kernel/sched/fair.c
> > > > @@ -2711,6 +2711,17 @@ static inline void update_load_avg(struct 
> > > > sched_entity *se, int update_tg)
> > > >  
> > > >  static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> > > > sched_entity *se)
> > > >  {
> > > > +   /*
> > > > +* in case of migration and cgroup-change, more care should be 
> > > > taken
> > > > +* because se's cfs_rq was changed, that means calling 
> > > > __update_load_avg
> > > > +* with new cfs_rq->avg.last_update_time is meaningless. so we 
> > > > skip the
> > > > +* update here. we have to update it with prev cfs_rq just 
> > > > before changing
> > > > +* se's cfs_rq, and get here soon.
> > > > +*/
> > > > +   if (se->avg.last_update_time)
> > > > +   __update_load_avg(cfs_rq->avg.last_update_time, 
> > > > cpu_of(rq_of(cfs_rq)),
> > > > +   >avg, 0, 0, NULL);
> > > > +
> > > > se->avg.last_update_time = cfs_rq->avg.last_update_time;
> > > > cfs_rq->avg.load_avg += se->avg.load_avg;
> > > > cfs_rq->avg.load_sum += se->avg.load_sum;
> > > 
> > > you seem to have forgotten to remove the same logic from
> > > enqueue_entity_load_avg(), which will now call __update_load_avg()
> > > twice.
> > 
> > In case of enqueue_entity_load_avg(), that seems to be ok.
> > 
> > However, the problem is that he made it "entangled":
> > 
> > In enqueue_entity_load_avg():
> > 
> > if (migrated)
> > attach_entity_load_avg();
> > 
> > while in attach_entity_load_avg():
> > 
> > if (!migrated)
> > __update_load_avg();
> > 
> > so, if attach() is called from enqueue(), that if() is never true.
> 
> Right, I noticed the same yesterday when I took a second look at that
> stuff. It was a little confusing indeed.

don't couple functions to each other between functions. i believe it's
acceptable if you look at each function itself.

in other words, attach_entity_load_avg() must call __update_load_avg()
with the condition, whoever calls attach_entity_load_avg(). and
enqueue_entity_load_avg(), too.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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: Persistent Reservation API V2

2015-08-20 Thread Keith Busch


On Tue, 11 Aug 2015, Christoph Hellwig wrote:

This series adds support for a simplified Persistent Reservation API
to the block layer.  The intent is that both in-kernel and userspace
consumers can use the API instead of having to hand craft SCSI or NVMe
command through the various pass through interfaces.  It also adds
DM support as getting reservations through dm-multipath is a major
pain with the current scheme.

NVMe support currently isn't included as I don't have a multihost
NVMe setup to test on, but Keith offered to test it and I'll have
a patch for it shortly.


Hi Christoph,

I wrote an nvme implementation and it seems to work as expected with your
pr-tests (minor modification to open an nvme target). While API appears to
work as designed, there are a few features of NVMe that are unreachable
with it. For example, NVMe can ignore existing keys when acquiring a
reservation in addition to registering a new key. NVMe can also specify
if whether or not a reservation should persist through power-loss.

Anyway, I don't think SCSI has these same options. Should this new IOCTL
API accommodate the common subset to maintain its simplicity, or make
it more expressive for all features? The more important question might
be if there are any users requiring these features, and I honestly don't
know that right 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 13/18] iio: adc: mcp320x: Set struct spi_driver .of_match_table

2015-08-20 Thread Michael Welling

On Fri, Aug 21, 2015 at 12:48:23AM +0200, Javier Martinez Canillas wrote:
> Hello Michael,
> 
> On 08/21/2015 12:29 AM, Michael Welling wrote:
> > On Fri, Aug 21, 2015 at 12:02:40AM +0200, Javier Martinez Canillas wrote:
> >> Hello Michael,
> >>
> >> On 08/20/2015 10:09 PM, Michael Welling wrote:
> >>> On Thu, Aug 20, 2015 at 09:07:26AM +0200, Javier Martinez Canillas wrote:
>  The driver has an OF id table but the .of_match_table is not set so
>  the SPI core can't do an OF style match and the table was unused.
> 
> >>>
> >>> Is an OF style match necessary?
> >>>
> >>
> >> Did you read the cover letter [0] on which I explain why is needed to
> >> avoid breaking module autoloading in the future? Once the SPI core is
> >> changed by RFC patch 18/18? (you were cc'ed in the cover letter BTW).
> > 
> > Well I have read it now. :)
> >
> 
> Great :)
>  
> >>
> >>> I have been using devicetree and it matches based on the .id_table.
> >>>
> >>
> >> Yes it fallbacks to the .id_table or the driver name but the correct
> >> thing to do for devices registered by OF, is to match using the
> >> compatible string.
> >>
> >>> Couldn't we just remove the mcp320x_dt_ids table instead?
> >>>
> >>
> >> No, that is the wrong thing to do IMHO since the compatible string
> >> contains both vendor and device name whle the .id_table only contains
> >> a device name.
> >>
> >> So it makes sense to match using the compatible string and also report
> >> the OF modalias information to user-space.
> >>
> >> Otherwise what's the point of the vendor in the compatible string for
> >> SPI devices? You can just use "bar" instead of "foo,bar" as a string.
> >>
> > 
> > Well then shouldn't the patch include adding the vendor to the compatible
> > string?
> >
> 
> Well, I was talking in general. You are right that this specific driver does
> not have a vendor prefix for the compatible strings. This is incorrect
> according to the ePAPR document [0].
> 
> However, these compatible strings are already documented as a DT binding doc
> in Documentation/devicetree/bindings/iio/adc/mcp320x.txt so I don't know
> what is the correct thing to do in this situation.
> 
> Changing the compatible string will break old DTB with newer kernels and that
> is a no go. But that doesn't invalidate what I said since once the SPI core
> is changed and report OF modalias, you will need a MODULE_DEVICE_TABLE(of,...)
> regardless if the compatible string has a vendor prefix or not.
>

Okay.

Acked-by: Michael Welling 
 
> [0]: https://www.power.org/documentation/epapr-version-1-1/
> 
> Best regards,
> -- 
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

2015-08-20 Thread Javier Martinez Canillas

Hello Mark,

On 08/21/2015 01:25 AM, Mark Brown wrote:
> On Thu, Aug 20, 2015 at 11:45:09PM +0200, Javier Martinez Canillas wrote:
>> On 08/20/2015 11:08 PM, Brian Norris wrote:
> 
 This is tagged as something that can't be applied but you've not
 explained why it can't be applied or what comments might be useful :(
> 
>> As Brian pointed out it was in the cover letter so I thought it would
>> just be duplicated information. But you are right, I should had added
>> a brief note as well just to make the patch self contained.
> 
> Right, a big part of what I was looking for was something about why this
> is an incompatible change in the changelog so that once it gets applied
> someone with out of tree code which gets broken can see what happens.

Yes, you are absolutely right. When I finally post this as a proper
patch I'll make sure to have a big NOTE so people can track module
autoload issues for OF drivers down to this commit.

> Plus...
> 
>>> I believe that's mostly addressed in the cover letter [1].
> 
>>>   Patch #18 changes the logic of spi_uevent() to report an OF modalias
>>>   if the device was registered using OF. But this patch is included in
>>>   the series only as an RFC for illustration purposes since changing
>>>   that without first applying all the other patches in this series, will
>>>   break module autoloading for the drivers of devices registered using
>>>   OF but that lacks an of_match_table. I'll repost patch #18 once all
>>>   the patches in this series have landed.
> 
>>> IOW, it's labeled as such mostly for safety, since it has quite a few
>>> distributed dependencies.
> 
> Are there really only 17 drivers that are missing an explict of_table?
> That seems like a low number.
>

In fact the 17 patches are the combination of the SPI drivers that:

a) Have a .id_table but not a MODULE_DEVICE_TABLE(spi,...)
b) Have a .of_match_table but no a MODULE_DEVICE_TABLE(of,...)
c) Don't have a .of_match_table but have a DT binding document

Maybe there are more SPI drivers out there that only have a .id_table
and don't have a .of_match_table nor a DT binding doc. But in that case
there isn't too much I can do since I've no information that these are
drivers are actually used in systems booted with OF.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] regmap: i2c block support

2015-08-20 Thread Mark Brown

On Thu, Aug 20, 2015 at 12:00:03PM +0200, Markus Pargmann wrote:
> Hi,
> 
> This series adds support for i2c block read/writes. To support the maximum 32
> byte read/write operations, the regmap core is extended by max_raw_read and
> max_raw_write. bulk operations are splitted depending of the size of
> max_raw_read/write.

This looks basically fine but depends on the previous fixes series
AFAICT.


signature.asc
Description: Digital signature

Re: [V3 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

On Thu, Aug 06, 2015 at 02:45:43PM +0900, Hidehiro Kawai wrote:
> diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
> index d05bd2e..dcd4038 100644
> --- a/arch/x86/kernel/nmi.c
> +++ b/arch/x86/kernel/nmi.c
> @@ -231,7 +231,7 @@ void unregister_nmi_handler(unsigned int type, const char 
> *name)
>  #endif
>  
>   if (panic_on_unrecovered_nmi)
> - panic("NMI: Not continuing");
> + nmi_panic("NMI: Not continuing");
>  
>   pr_emerg("Dazed and confused, but trying to continue\n");
>  

What tree is this again.. my tree (-tip) doesn't have
panic_on_unrecovered_nmi nonsense.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/8] scsi: ufs: make the UFS variant a platform device

2015-08-20 Thread Akinobu Mita

2015-08-20 22:59 GMT+09:00 Yaniv Gardi :
> @@ -1036,7 +1037,7 @@ void ufs_qcom_clk_scale_notify(struct ufs_hba *hba)
>   * The variant operations configure the necessary controller and PHY
>   * handshake during initialization.
>   */
> -static const struct ufs_hba_variant_ops ufs_hba_qcom_vops = {
> +static struct ufs_hba_variant_ops ufs_hba_qcom_vops = {

It's better to keep const.  In order to do this, we also need to put
const to 'vops' member in struct ufs_hba and the second argument of
ufshcd_pltfrm_init().

> +static void ufs_qcom_shutdown(struct platform_device *pdev)
> +{
> +   ufshcd_shutdown((struct ufs_hba *)platform_get_drvdata(pdev));
> +}

We don't need this function anymore since we have
ufshcd_pltfrm_shutdown() now.

> -static void ufshcd_pltfrm_shutdown(struct platform_device *pdev)
> +void ufshcd_pltfrm_shutdown(struct platform_device *pdev)
>  {
> -   ufshcd_shutdown((struct ufs_hba *)platform_get_drvdata(pdev));
> +   ufshcd_shutdown((struct ufs_hba *)platform_get_drvdata(pdev));

Whitespace is used as code indent.  There are same issues in
this patch series, so I recommend running checkpatch.pl before
sending patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/8] scsi: ufs-qcom: add debug prints for test bus

2015-08-20 Thread Akinobu Mita

2015-08-20 22:59 GMT+09:00 Yaniv Gardi :
> @@ -30,6 +48,14 @@ static void ufs_qcom_get_speed_mode(struct 
> ufs_pa_layer_attr *p, char *result);
>  static int ufs_qcom_get_bus_vote(struct ufs_qcom_host *host,
> const char *speed_mode);
>  static int ufs_qcom_set_bus_vote(struct ufs_qcom_host *host, int vote);
> +static void ufs_qcom_get_default_testbus_cfg(struct ufs_qcom_host *host);
> +static void ufs_qcom_dump_regs(struct ufs_hba *hba, int offset, int len,
> +   char *prefix)
> +{
> +   print_hex_dump(KERN_ERR, prefix,
> +   len > 4 ? DUMP_PREFIX_OFFSET : DUMP_PREFIX_NONE,
> +   16, 4, hba->mmio_base + offset, len * 4, false);
> +}

This causes a sparse warning as __iomem pointer is passed to
print_hex_dump().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3 0/5] Fix compound_head() race

On Thu, 20 Aug 2015 15:31:07 +0300 "Kirill A. Shutemov"  
wrote:

> On Wed, Aug 19, 2015 at 12:21:41PM +0300, Kirill A. Shutemov wrote:
> > Here's my attempt on fixing recently discovered race in compound_head().
> > It should make compound_head() reliable in all contexts.
> > 
> > The patchset is against Linus' tree. Let me know if it need to be rebased
> > onto different baseline.
> > 
> > It's expected to have conflicts with my page-flags patchset and probably
> > should be applied before it.
> > 
> > v3:
> >- Fix build without hugetlb;
> >- Drop page->first_page;
> >- Update comment for free_compound_page();
> >- Use 'unsigned int' for page order;
> > 
> > v2: Per Hugh's suggestion page->compound_head is moved into third double
> > word. This way we can avoid memory overhead which v1 had in some
> > cases.
> > 
> > This place in struct page is rather overloaded. More testing is
> > required to make sure we don't collide with anyone.
> 
> Andrew, can we have the patchset applied, if nobody has objections?

I've been hoping to hear from Hugh and I wasn't planning on processing
these before the 4.2 release.


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

Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status

2015-08-20 Thread Naoya Horiguchi

On Thu, Aug 20, 2015 at 01:00:05PM +0200, Michal Hocko wrote:
> On Thu 20-08-15 08:26:27, Naoya Horiguchi wrote:
> > Currently there's no easy way to get per-process usage of hugetlb pages,
> 
> Is this really the case after your previous patch? You have both 
> HugetlbPages and KernelPageSize which should be sufficient no?

We can calcurate it from these info, so saying "no easy way" was incorrect :(

> Reading a single file is, of course, easier but is it really worth the
> additional code? I haven't really looked at the patch so I might be
> missing something but what would be an advantage over reading
> /proc//smaps and extracting the information from there?

My first idea was just "users should feel it useful", but permission as David
commented sounds a good technical reason to me.

Thanks,
Naoya Horiguchi

Re: [PATCHv3 4/5] mm: make compound_head() robust

On Wed, 19 Aug 2015 12:21:45 +0300 "Kirill A. Shutemov" 
 wrote:

> Hugh has pointed that compound_head() call can be unsafe in some
> context. There's one example:
> 
>   CPU0CPU1
> 
> isolate_migratepages_block()
>   page_count()
> compound_head()
>   !!PageTail() == true
>   put_page()
> tail->first_page = NULL
>   head = tail->first_page
>   alloc_pages(__GFP_COMP)
>  prep_compound_page()
>tail->first_page = head
>__SetPageTail(p);
>   !!PageTail() == true
> 
> 
> The race is pure theoretical. I don't it's possible to trigger it in
> practice. But who knows.
> 
> We can fix the race by changing how encode PageTail() and compound_head()
> within struct page to be able to update them in one shot.
> 
> The patch introduces page->compound_head into third double word block in
> front of compound_dtor and compound_order. That means it shares storage
> space with:
> 
>  - page->lru.next;
>  - page->next;
>  - page->rcu_head.next;
>  - page->pmd_huge_pte;
> 
> That's too long list to be absolutely sure, but looks like nobody uses
> bit 0 of the word. It can be used to encode PageTail(). And if the bit
> set, rest of the word is pointer to head page.

So nothing else which participates in the union in the "Third double
word block" is allowed to use bit zero of the first word.

Is this really true?  For example if it's a slab page, will that page
ever be inspected by code which is looking for the PageTail bit?


Anyway, this is quite subtle and there's a risk that people will
accidentally break it later on.  I don't think the patch puts
sufficient documentation in place to prevent this.  And even
documentation might not be enough to prevent accidents.

>
> ...
>
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -120,7 +120,12 @@ struct page {
>   };
>   };
>  
> - /* Third double word block */
> + /*
> +  * Third double word block
> +  *
> +  * WARNING: bit 0 of the first word encode PageTail and *must* be 0
> +  * for non-tail pages.
> +  */
>   union {
>   struct list_head lru;   /* Pageout list, eg. active_list
>* protected by zone->lru_lock !
> @@ -143,6 +148,7 @@ struct page {
>*/
>   /* First tail page of compound page */
>   struct {
> + unsigned long compound_head; /* If bit zero is set */

I think the comments around here should have more details and should
be louder!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3 3/5] mm: pack compound_dtor and compound_order into one word in struct page

On Wed, 19 Aug 2015 12:21:44 +0300 "Kirill A. Shutemov" 
 wrote:

> The patch halves space occupied by compound_dtor and compound_order in
> struct page.
> 
> For compound_order, it's trivial long -> int/short conversion.
> 
> For get_compound_page_dtor(), we now use hardcoded table for destructor
> lookup and store its index in the struct page instead of direct pointer
> to destructor. It shouldn't be a big trouble to maintain the table: we
> have only two destructor and NULL currently.
> 
> This patch free up one word in tail pages for reuse. This is preparation
> for the next patch.
> 
> ...
>
> @@ -145,8 +143,13 @@ struct page {
>*/
>   /* First tail page of compound page */
>   struct {
> - compound_page_dtor *compound_dtor;
> - unsigned long compound_order;
> +#ifdef CONFIG_64BIT
> + unsigned int compound_dtor;
> + unsigned int compound_order;
> +#else
> + unsigned short int compound_dtor;
> + unsigned short int compound_order;
> +#endif

Why not use ushort for 64-bit as well?

It would be clearer if that new enum had a name, so we use "enum
compound_dtor_id" everywhere instead of a bare uint.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

2015-08-20 Thread Mark Brown

On Thu, Aug 20, 2015 at 11:45:09PM +0200, Javier Martinez Canillas wrote:
> On 08/20/2015 11:08 PM, Brian Norris wrote:

> >> This is tagged as something that can't be applied but you've not
> >> explained why it can't be applied or what comments might be useful :(

> As Brian pointed out it was in the cover letter so I thought it would
> just be duplicated information. But you are right, I should had added
> a brief note as well just to make the patch self contained.

Right, a big part of what I was looking for was something about why this
is an incompatible change in the changelog so that once it gets applied
someone with out of tree code which gets broken can see what happens.
Plus...

> > I believe that's mostly addressed in the cover letter [1].

> >   Patch #18 changes the logic of spi_uevent() to report an OF modalias
> >   if the device was registered using OF. But this patch is included in
> >   the series only as an RFC for illustration purposes since changing
> >   that without first applying all the other patches in this series, will
> >   break module autoloading for the drivers of devices registered using
> >   OF but that lacks an of_match_table. I'll repost patch #18 once all
> >   the patches in this series have landed.

> > IOW, it's labeled as such mostly for safety, since it has quite a few
> > distributed dependencies.

Are there really only 17 drivers that are missing an explict of_table?
That seems like a low number.


signature.asc
Description: Digital signature

Re: [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps

2015-08-20 Thread Naoya Horiguchi

On Thu, Aug 20, 2015 at 12:49:29PM +0200, Michal Hocko wrote:
> On Thu 20-08-15 08:26:26, Naoya Horiguchi wrote:
> > Currently /proc/PID/smaps provides no usage info for vma(VM_HUGETLB), which
> > is inconvenient when we want to know per-task or per-vma base hugetlb usage.
> > To solve this, this patch adds a new line for hugetlb usage like below:
> > 
> >   Size:  20480 kB
> >   Rss:   0 kB
> >   Pss:   0 kB
> >   Shared_Clean:  0 kB
> >   Shared_Dirty:  0 kB
> >   Private_Clean: 0 kB
> >   Private_Dirty: 0 kB
> >   Referenced:0 kB
> >   Anonymous: 0 kB
> >   AnonHugePages: 0 kB
> >   HugetlbPages:  18432 kB
> >   Swap:  0 kB
> >   KernelPageSize: 2048 kB
> >   MMUPageSize:2048 kB
> >   Locked:0 kB
> >   VmFlags: rd wr mr mw me de ht
> 
> I have only now got to this thread. This is indeed very helpful. I would
> just suggest to update Documentation/filesystems/proc.txt to be explicit
> that Rss: doesn't count hugetlb pages for historical reasons.

I agree, I want the following diff to be folded to this patch.

>  
> > Signed-off-by: Naoya Horiguchi 
> > Acked-by: Joern Engel 
> > Acked-by: David Rientjes 
> 
> Acked-by: Michal Hocko 

Thank you.
Naoya Horiguchi
---
From: Naoya Horiguchi 
Date: Fri, 21 Aug 2015 08:13:31 +0900
Subject: [PATCH] Documentation/filesystems/proc.txt: give additional comment
 about hugetlb usage

---
 Documentation/filesystems/proc.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index f561fc46e41b..b775b6faaeda 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -446,7 +446,8 @@ indicates the amount of memory currently marked as 
referenced or accessed.
 a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
 and a page is modified, the file page is replaced by a private anonymous copy.
 "AnonHugePages" shows the ammount of memory backed by transparent hugepage.
-"HugetlbPages" shows the ammount of memory backed by hugetlbfs page.
+"HugetlbPages" shows the ammount of memory backed by hugetlbfs page (which is
+not counted in "Rss" or "Pss" field for historical reasons.)
 "Swap" shows how much would-be-anonymous memory is also used, but out on swap.
 
 "VmFlags" field deserves a separate description. This member represents the 
kernel
-- 
2.4.3

Re: [PATCH v2] rtc/ds3232: fix ds3232 get a WARNING trace in resume function

On 12/08/2015 at 17:14:13 +0800, Dongsheng Wang wrote :
> From: Wang Dongsheng 
> 
> If ds3232 work on some platform that is not implementation
> irq_set_wake, ds3232 will get a WARNING trace in resume.
> So fix ds3232->suspended state to false when irq_set_irq_wake
> return error.
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 729 at kernel/irq/manage.c:604
> irq_set_irq_wake+0x4b/0x8c()
> Unbalanced IRQ 201 wake disable
> Modules linked in:
> CPU: 0 PID: 729 Comm: sh Not tainted 3.12.19-rt30+ #25
> [<800107d9>] (unwind_backtrace+0x1/0x88) from [<8000e4ef>]
> (show_stack+0xb/0xc)
> [<8000e4ef>] (show_stack+0xb/0xc) from [<802b5fa9>]
> (dump_stack+0x4d/0x60)
> [<802b5fa9>] (dump_stack+0x4d/0x60) from [<800186dd>]
> (warn_slowpath_common+0x45/0x64)
> [<800186dd>] (warn_slowpath_common+0x45/0x64) from [<80018717>]
> (warn_slowpath_fmt+0x1b/0x24)
> [<80018717>] (warn_slowpath_fmt+0x1b/0x24) from [<8003a8d3>]
> (irq_set_irq_wake+0x4b/0x8c)
> [<8003a8d3>] (irq_set_irq_wake+0x4b/0x8c) from [<80204fcb>]
> (ds3232_resume+0x2d/0x36)
> [<80204fcb>] (ds3232_resume+0x2d/0x36) from [<801954c7>]
> (dpm_run_callback.isra.13+0xb/0x28)
> [<801954c7>] (dpm_run_callback.isra.13+0xb/0x28) from [<80195b1b>]
> (device_resume+0x7b/0xa2)
> [<80195b1b>] (device_resume+0x7b/0xa2) from [<80195f0f>]
> (dpm_resume+0xbb/0x19c)
> [<80195f0f>] (dpm_resume+0xbb/0x19c) from [<801960d9>]
> (dpm_resume_end+0x9/0x12)
> [<801960d9>] (dpm_resume_end+0x9/0x12) from [<80037e1d>]
> (suspend_devices_and_enter+0x17d/0x1d0)
> [<80037e1d>] (suspend_devices_and_enter+0x17d/0x1d0) from [<80037ee1>]
> (pm_suspend+0x71/0x128)
> [<80037ee1>] (pm_suspend+0x71/0x128) from [<80037449>]
> (state_store+0x6d/0x80)
> [<80037449>] (state_store+0x6d/0x80) from [<800af4d5>]
> (sysfs_write_file+0x9f/0xde)
> [<800af4d5>] (sysfs_write_file+0x9f/0xde) from [<8007a437>]
> (vfs_write+0x7b/0x104)
> [<8007a437>] (vfs_write+0x7b/0x104) from [<8007a7f7>]
> (SyS_write+0x27/0x48)
> [<8007a7f7>] (SyS_write+0x27/0x48) from [<8000c121>]
> (ret_fast_syscall+0x1/0x44)
> ---[ end trace 640959d2e8de6ccc ]---
> 
> Signed-off-by: Wang Dongsheng 
> ---
> *v2*
> - Use dev_warn_once to instead of dev_info
> 

Applied, after fixing the kernel trace and the message like suggested by
Krzysztof.

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

Re: [V3 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

On Thu, Aug 06, 2015 at 02:45:43PM +0900, Hidehiro Kawai wrote:
> When cpu-A panics on NMI just after cpu-B has panicked, cpu-A loops
> infinitely in NMI context.  Especially for x86, cpu-B issues NMI IPI
> to other cpus to save their register states and do some cleanups if
> kdump is enabled, but cpu-A can't handle the NMI and fails to save
> register states.
> 
> To solve thie issue, we wait for the timing of the NMI IPI, then
> call the NMI handler which saves register states.

Sorry, I don't follow, what?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V3 PATCH 0/4] Fix race issues among panic, NMI and crash_kexec


User-Agent: StGit/0.16

Fwiw, stgit is broken wrt sending email, all your emails have the exact
same timestamp, which means that the emails will be ordered on received
timestamp when threaded and generate the below mess:


 Aug 06 Hidehiro Kawai  (1.9K) [V3 PATCH 0/4] Fix race issues among panic, NMI 
and crash_kexec
 Aug 06 Hidehiro Kawai  (2.4K) ├─>[V3 PATCH 3/4] kexec: Fix race between 
panic() and crash_kexec() called directly
 Aug 06 Hidehiro Kawai  (4.9K) ├─>[V3 PATCH 1/4] panic/x86: Fix re-entrance 
problem due to panic on NMI
 Aug 06 Hidehiro Kawai  (5.3K) ├─>[V3 PATCH 2/4] panic/x86: Allow cpus to save 
registers even if they are looping in NMI context
 Aug 06 Hidehiro Kawai  (2.5K) ├─>[V3 PATCH 4/4] x86/apic: Introduce noextnmi 
boot option


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Question on adding a firmware ihex file in the kernel source

2015-08-20 Thread David Woodhouse

On Thu, 2015-08-20 at 17:46 -0400, Murali Karicheri wrote:
> All,
> 
> Please help me understand the procedure to add a firmware ihex file to 
> kernel source tree under firmware/ folder. The README.AddingFirmware 
> file explains that file should be added to 
> git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git and 
> the patch for the same to be send to linux-firmw...@kernel.org. And this 
> requires it to be in binary form. How does then that end up in the 
> firmware/ folder of the Linux source tree as an ihex file? 

You cannot do that. The old firmware/ directory in the source tree is
incomplete, out of date and scheduled for deletion.

Firmware should *only* go into the separate linux-firmware.git
repository.

> I would like to have one of the  firmware statically built into the 
> kernel as it is needed to be loaded even before file system is 
> initialized in kernel (network driver firmware).

Do not do that. It is believed by many to be a violation of the GPL.

If the firmware is needed to mount the root file system, then you can
put it into an initramfs and load it that way, rather than building it
into the GPL'd kernel image.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] rtc: s5m: fix to update ctrl register

Hi,

On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
> According to datasheet, the S2MPS13X and S2MPS14X should update write
> buffer via setting WUDR bit to high after ctrl register is updated.
> 
> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
> tools/testing/selftests/timers/rtctest.c test program and hour format is
> used to 12 hour mode in Odroid-XU3 board.
> 

>From what I understood, I should expect a v2 of tihat patch also setting
RUDR, is that right? OR would you prefer that I apply that one and then
fix RUDR in a following patch?

> Signed-off-by: Joonyoung Shim 
> Cc: 

can you update the stable tag with the kernel version introducing the
issue?

> ---
>  drivers/rtc/rtc-s5m.c | 12 
>  1 file changed, 12 insertions(+)

> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
> index 8c70d78..03828bb 100644
> --- a/drivers/rtc/rtc-s5m.c
> +++ b/drivers/rtc/rtc-s5m.c
> @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
> *info)
>   case S2MPS13X:
>   data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
>   ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
> + if (ret < 0)
> + break;
> +
> + ret = regmap_update_bits(info->regmap,
> + info->regs->rtc_udr_update,
> + info->regs->rtc_udr_mask,
> + info->regs->rtc_udr_mask);

Very small indentation issue here, it should be aligned with the open
parenthesis.


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

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

2015-08-20 Thread Daniel Lezcano


On 08/20/2015 10:06 AM, Sascha Hauer wrote:

This adds support for the Mediatek thermal controller found on MT8173
and likely other SoCs.
The controller is a bit special. It does not have its own ADC, instead
it controls the on-SoC AUXADC via AHB bus accesses. For this reason
we need the physical address of the AUXADC. Also it controls a mux
using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.

Signed-off-by: Sascha Hauer 
---


[ ... ]


diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
new file mode 100644
index 000..06d52ef
--- /dev/null
+++ b/drivers/thermal/mtk_thermal.c
@@ -0,0 +1,582 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.


2015 ?


+ * Author: Hanyi.Wu 


Hanyi Wu ?

[ ... ]

-->


+#define TEMP_MONINTSTS 0x010
+#define TEMP_MONIDET0  0x014
+#define TEMP_MONIDET1  0x018
+#define TEMP_MONIDET2  0x01c
+#define TEMP_H2NTHRE   0x024
+#define TEMP_HTHRE 0x028
+#define TEMP_CTHRE 0x02c
+#define TEMP_OFFSETH   0x030
+#define TEMP_OFFSETL   0x034
+#define TEMP_MSRCTL1   0x03c
+#define TEMP_ADCEXT0x058
+#define TEMP_ADCEXT1   0x05c
+#define TEMP_ADCEXTADDR0x06c
+#define TEMP_ADCEXT1ADDR   0x070
+#define TEMP_IMMD0 0x0a0
+#define TEMP_IMMD1 0x0a4
+#define TEMP_IMMD2 0x0a8
+#define TEMP_PROTCTL   0x0c0
+#define TEMP_PROTTA0x0c4
+#define TEMP_PROTTB0x0c8
+#define TEMP_PROTTC0x0cc
+#define TEMP_SPARE10x0f4
+#define TEMP_SPARE20x0f8
+#define TEMP_SPARE30x0fc
+#define THERMINTST 0x404
+#define PTPODINTST 0x408
+#define THSTAGE0ST 0x40c
+#define THSTAGE1ST 0x410
+#define THSTAGE2ST 0x414
+#define THAHBST0   0x418
+#define THAHBST1   0x41c   /* Only for DE debug */
+#define PTPSPARE0  0x420
+#define PTPSPARE1  0x424
+#define PTPSPARE2  0x428
+#define PTPSPARE3  0x42c
+#define THSLPEVEB  0x430
+#define TEMP_MONINT_COLD(sp)   (BIT(0) << ((sp) * 5))
+#define TEMP_MONINT_HOT(sp)(BIT(1) << ((sp) * 5))
+#define TEMP_MONINT_LOW_OFS(sp)(BIT(2) << ((sp) * 5))
+#define TEMP_MONINT_HIGH_OFS(sp)   (BIT(3) << ((sp) * 5))
+#define TEMP_MONINT_HOT_TO_NORM(sp)(BIT(4) << ((sp) * 5))
+#define TEMP_MONINT_TIMEOUTBIT(15)
+#define TEMP_MONINT_IMMEDIATE_SENSE(sp)BIT(16 + (sp))
+#define TEMP_MONINT_FILTER_SENSE(sp)   BIT(19 + (sp))
+#define TEMP_ADCWRITECTRL_ADC_EXTRA_WRITE  BIT(2)
+#define TEMP_ADCWRITECTRL_ADC_EXTRA1_WRITE BIT(3)
+#define TEMP_PROTCTL_AVERAGE   (0 << 16)
+#define TEMP_PROTCTL_MAXIMUM   (1 << 16)
+#define TEMP_PROTCTL_SELECTED  (2 << 16)


<-- Not used.


  -- Daniel


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -mm] mm, oom: add global access to memory reserves on livelock

On Thu, 20 Aug 2015 14:00:36 -0700 (PDT) David Rientjes  
wrote:

> On system oom, a process may fail to exit if its thread depends on a lock
> held by another allocating process.
> 
> In this case, we can detect an oom kill livelock that requires memory
> allocation to be successful to resolve.
> 
> This patch introduces an oom expiration, set to 5s, that defines how long
> a thread has to exit after being oom killed.
> 
> When this period elapses, it is assumed that the thread cannot make
> forward progress without help.  The only help the VM may provide is to
> allow pending allocations to succeed, so it grants all allocators access
> to memory reserves after reclaim and compaction have failed.
> 
> This patch does not allow global access to memory reserves on memcg oom
> kill, but the functionality is there if extended.

I'm struggling a bit to understand how this works.  afaict what happens
is that if some other (non-oom-killed) thread is spinning in the page
allocator and then __alloc_pages_may_oom() decides to oom-kill this
not-yet-oom-killed thread, out_of_memory() will then tell this process
"you can access page reserves", rather than oom-killing it.

I think.

If so, the "provide all threads" comment over the OOM_EXPIRE_MSECS
definition is a bit incomplete.

Also, there are a whole bunch of reasons why a caller to
out_of_memory() won't call into select_bad_process(), where all the
magic happens.  Such as task_will_free_mem(), !oom_unkillable_task(),
etc.  Can't those thing prevent those threads from getting permission
to use page reserves?

I suspect I'm just not understanding the implementation here.  A fuller
explanation (preferably in the .c files!) would help.

Also...  the hard-wired 5 second delay is of course problematic.  What
goes wrong if this is reduced to zero?  ie, let non-oom-killed threads
access page reserves immediately?

>
> ...
>
> @@ -254,8 +263,57 @@ static enum oom_constraint constrained_alloc(struct 
> oom_control *oc,
>  }
>  #endif
>  
> +#ifdef CONFIG_STACKTRACE
> +#define MAX_STACK_TRACE_ENTRIES  (64)
> +static unsigned long stack_trace_entries[MAX_STACK_TRACE_ENTRIES *
> +  sizeof(unsigned long)];
> +static DEFINE_MUTEX(stack_trace_mutex);
> +
> +static void print_stacks_expired(struct task_struct *task)
> +{
> + /* One set of stack traces every OOM_EXPIRE_MS */
> + static DEFINE_RATELIMIT_STATE(expire_rs, OOM_EXPIRE_MSECS / 1000 * HZ,
> +   1);
> + struct stack_trace trace = {
> + .nr_entries = 0,
> + .max_entries = ARRAY_SIZE(stack_trace_entries),
> + .entries = stack_trace_entries,
> + .skip = 2,
> + };
> +
> + if (!__ratelimit(_rs))
> + return;
> +
> + WARN(true,
> +  "%s (%d) has failed to exit -- global access to memory reserves 
> started\n",
> +  task->comm, task->pid);
> +
> + /*
> +  * If cred_guard_mutex can't be acquired, this may be a mutex that is
> +  * being held causing the livelock.  Return without printing the stack.
> +  */
> + if (!mutex_trylock(>signal->cred_guard_mutex))
> + return;
> +
> + mutex_lock(_trace_mutex);
> + save_stack_trace_tsk(task, );
> +
> + pr_info("Call Trace of %s/%d:\n", task->comm, task->pid);
> + print_stack_trace(, 0);
> +
> + mutex_unlock(_trace_mutex);
> + mutex_unlock(>signal->cred_guard_mutex);
> +}
> +#else
> +static inline void print_stacks_expired(struct task_struct *task)
> +{
> +}
> +#endif /* CONFIG_STACKTRACE */

That ""%s (%d) has failed to exit" warning is still useful if
CONFIG_STACKTRACE=n and I suggest it be moved into the caller.

Alternatively, make that message in exit_mm() dependent on
CONFIG_STACKTRACE as well - it's a bit odd to print the "ended" message
without having printed the "started" message.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V3 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

On Thu, Aug 06, 2015 at 02:45:43PM +0900, Hidehiro Kawai wrote:
>  void crash_kexec(struct pt_regs *regs)
>  {
> + int old_cpu, this_cpu;
> +
> + /*
> +  * `old_cpu == -1' means we are the first comer and crash_kexec()
> +  * was called without entering panic().
> +  * `old_cpu == this_cpu' means crash_kexec() was called from panic().
> +  */
> + this_cpu = raw_smp_processor_id();
> + old_cpu = atomic_cmpxchg(_cpu, -1, this_cpu);
> + if (old_cpu != -1 && old_cpu != this_cpu)
> + return;

This allows recursive calling of crash_kexec(), the Changelog did not
mention that. Is this really required?

> +
>   /* Take the kexec_mutex here to prevent sys_kexec_load
>* running on one cpu from replacing the crash kernel
>* we are using after a panic on a different cpu.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] rtc: s3c: remove unnecessary NULL assignment

On 11/08/2015 at 20:28:20 +0900, Joonyoung Shim wrote :
> It's unnecessary the code that assigns info->rtc_clk to NULL in
> s3c_rtc_remove.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/rtc/rtc-s3c.c | 1 -
>  1 file changed, 1 deletion(-)
> 
Applied, thanks.

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

Re: [PATCH 1/4] rtc: s3c: add missing clk control