Re: [PATCH v2 2/4] serial: samsung: remove unneded 'ignore_char' label

2015-09-10 Thread Krzysztof Kozlowski
On 10.09.2015 22:41, Robert Baldyga wrote:
> This label does nothing special and we don't need to have it anymore.
> 
> Signed-off-by: Robert Baldyga 
> ---
>  drivers/tty/serial/samsung.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 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: [PATCH 2/2] [media] media-device: split media initialization and registration

2015-09-10 Thread Sakari Ailus

Hi Javier,

Javier Martinez Canillas wrote:

Hello Sakari,

On 09/10/2015 07:14 PM, Sakari Ailus wrote:

Hi Javier,

Thanks for the set! A few comments below.



Thanks to you for your feedback.


Javier Martinez Canillas wrote:

The media device node is registered and so made visible to user-space
before entities are registered and links created which means that the
media graph obtained by user-space could be only partially enumerated
if that happens too early before all the graph has been created.

To avoid this race condition, split the media init and registration
in separate functions and only register the media device node when
all the pending subdevices have been registered, either explicitly
by the driver or asynchronously using v4l2_async_register_subdev().

Also, add a media_entity_cleanup() function that will destroy the
graph_mutex that is initialized in media_entity_init().

Suggested-by: Sakari Ailus 
Signed-off-by: Javier Martinez Canillas 

---

  drivers/media/common/siano/smsdvb-main.c  |  1 +
  drivers/media/media-device.c  | 38 +++
  drivers/media/platform/exynos4-is/media-dev.c | 12 ++---
  drivers/media/platform/omap3isp/isp.c | 11 +---
  drivers/media/platform/s3c-camif/camif-core.c | 13 ++---
  drivers/media/platform/vsp1/vsp1_drv.c| 19 ++
  drivers/media/platform/xilinx/xilinx-vipp.c   | 11 +---
  drivers/media/usb/au0828/au0828-core.c| 26 +-
  drivers/media/usb/cx231xx/cx231xx-cards.c | 22 +++-
  drivers/media/usb/dvb-usb-v2/dvb_usb_core.c   | 11 +---
  drivers/media/usb/dvb-usb/dvb-usb-dvb.c   | 13 ++---
  drivers/media/usb/siano/smsusb.c  | 14 --
  drivers/media/usb/uvc/uvc_driver.c|  9 +--
  include/media/media-device.h  |  2 ++
  14 files changed, 156 insertions(+), 46 deletions(-)

diff --git a/drivers/media/common/siano/smsdvb-main.c 
b/drivers/media/common/siano/smsdvb-main.c
index ab345490a43a..8a1ea2192439 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct 
smsdvb_client_t *client)
if (!coredev->media_dev)
return;
media_device_unregister(coredev->media_dev);
+   media_device_cleanup(coredev->media_dev);
kfree(coredev->media_dev);
coredev->media_dev = NULL;
  #endif
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 745defb34b33..a8beb0b445a6 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode *mdev)
  }

  /**
- * media_device_register - register a media device
+ * media_device_init() - initialize a media device
   * @mdev: The media device
   *
   * The caller is responsible for initializing the media device before
@@ -534,12 +534,11 @@ static void media_device_release(struct media_devnode 
*mdev)
   *
   * - dev must point to the parent device
   * - model must be filled with the device model name
+ *
+ * returns zero on success or a negative error code.
   */
-int __must_check __media_device_register(struct media_device *mdev,
-struct module *owner)
+int __must_check media_device_init(struct media_device *mdev)


I think I suggested making media_device_init() return void as the only
remaining source of errors would be driver bugs.



Yes you did and I think I explained why I preferred to leave it as
is and I thought we agreed :)


I thought we agreed, too. But my understanding was that the agreement 
was different. ;-)




Currently media_device_register() is failing gracefully if a buggy
driver is not setting mdev->dev. So changing media_device_init() to
return void instead, would be a semantic change and if drivers are
not checking that anymore, can lead to NULL pointer dereference bugs.


Do we have such drivers? Would they ever have worked in the first place, 
as media device registration would have failed?





I'd simply replace the WARN_ON() below with BUG().



Sorry but I disagree, I think that BUG() should only be used for
exceptional cases in which execution can't really continue without
causing data corruption or something like that, so bringing down
the machine is the safest and least bad option.


I think it's also fine to use that for basic sanity checks on code paths 
that will be run early and every time.


To support what I'm saying, just do this:

$ grep BUG_ON drivers/media/v4l2-core/*

Even though most of that is in videobuf, V4L2 core does that, too, and 
there's a case of especially delicious usage in v4l2_subdev_init(). :-)




But that's not the case here, if there is a buggy driver then the
worst thing that would happen is that a driver probe function is
going to fail. It is true that drivers may not be 

Re: [RFC 3/5] acpi/serial: add DBG2 earlycon support

2015-09-10 Thread Rob Herring
On Tue, Sep 8, 2015 at 12:03 PM, Leif Lindholm  wrote:
> On Tue, Sep 08, 2015 at 02:09:51PM +0100, Mark Rutland wrote:
>> On Tue, Sep 08, 2015 at 01:43:35PM +0100, Leif Lindholm wrote:
>> > The ACPI DBG2 table defines a debug console. Add support for parsing it
>> > and using it to select earlycon destination when no arguments provided.
>> >
>> > Signed-off-by: Leif Lindholm 
>>
>> [...]
>>
>> > diff --git a/drivers/acpi/console.c b/drivers/acpi/console.c
>> > new file mode 100644
>> > index 000..a985890
>> > --- /dev/null
>> > +++ b/drivers/acpi/console.c
>> > @@ -0,0 +1,103 @@
>> > +/*
>> > + * Copyright (c) 2012, Intel Corporation
>> > + * Copyright (c) 2015, Linaro Ltd.
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License version 2 as
>> > + * published by the Free Software Foundation.
>> > + *
>> > + */
>> > +
>> > +#define DEBUG
>>
>> Why?
>
> Kept around from Lv Zheng's 2012 set. Will drop.
>
>> > +#define pr_fmt(fmt) "ACPI: " KBUILD_MODNAME ": " fmt
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>> > +#define NUM_ELEMS(x) (sizeof(x) / sizeof(*x))
>>
>> Use ARRAY_SIZE (from kernel.h).
>
> I was sure there was something like that, but my grep-fu failed me.
> Will fix.
>
>> > +
>> > +#ifdef CONFIG_SERIAL_EARLYCON
>> > +static int use_earlycon __initdata;
>> > +static int __init setup_acpi_earlycon(char *buf)
>> > +{
>> > +   if (!buf)
>> > +   use_earlycon = 1;
>> > +
>> > +   return 0;
>> > +}
>> > +early_param("earlycon", setup_acpi_earlycon);
>>
>> It seems a shame to add this after folding the OF case into the earlycon
>> code. What necessitates this being a separate early_param? Why is it too
>> early to parse DBG2?
>
> Currently, we don't even know where our ACPI tables are  at this point
> (efi_init() is called two functions after parse_early_param() in
> setup_arch). More specifically, because acpi_boot_table_init() is
> called even later than that.
>
> If we moved both of those earlier, we could drop the extra earlycon
> param handling for ACPI. That would of course reduce the ability to
> have dynamically configurable debug messages for both of these.

Personally, I liked that we don't have to have the early_param
handling globally located. I'm not sure I see the benefit of
centralizing it especially if it doesn't even help for your case.

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


[PATCH v2 09/16] Staging: lustre: obdclass: obd_config.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Change in v2-
 No change

 .../staging/lustre/lustre/obdclass/obd_config.c| 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/obd_config.c 
b/drivers/staging/lustre/lustre/obdclass/obd_config.c
index e0470c0..fb432e8 100644
--- a/drivers/staging/lustre/lustre/obdclass/obd_config.c
+++ b/drivers/staging/lustre/lustre/obdclass/obd_config.c
@@ -61,7 +61,7 @@ int class_find_param(char *buf, char *key, char **valp)
return 1;
 
ptr = strstr(buf, key);
-   if (ptr == NULL)
+   if (!ptr)
return 1;
 
if (valp)
@@ -92,11 +92,11 @@ struct cfg_interop_param *class_find_old_param(const char 
*param,
char *value = NULL;
int   name_len = 0;
 
-   if (param == NULL || ptr == NULL)
+   if (!param || !ptr)
return NULL;
 
value = strchr(param, '=');
-   if (value == NULL)
+   if (!value)
name_len = strlen(param);
else
name_len = value - param;
@@ -144,7 +144,7 @@ int class_get_next_param(char **params, char *copy)
 
while (1) {
q1 = strpbrk(str, " '\"");
-   if (q1 == NULL) {
+   if (!q1) {
len = strlen(str);
memcpy(copy, str, len);
copy[len] = '\0';
@@ -165,7 +165,7 @@ int class_get_next_param(char **params, char *copy)
/* search for the matching closing quote */
str = q1 + 1;
q2 = strchr(str, *q1);
-   if (q2 == NULL) {
+   if (!q2) {
CERROR("Unbalanced quota in parameters: \"%s\"\n",
   *params);
return -EINVAL;
@@ -243,7 +243,7 @@ static int class_parse_value(char *buf, int opc, void 
*value, char **endh,
 
/* nid separators or end of nids */
endp = strpbrk(buf, ",: /");
-   if (endp == NULL)
+   if (!endp)
endp = buf + strlen(buf);
 
tmp = *endp;
@@ -841,14 +841,14 @@ int class_add_profile(int proflen, char *prof, int 
osclen, char *osc,
 
LASSERT(proflen == (strlen(prof) + 1));
lprof->lp_profile = kmemdup(prof, proflen, GFP_NOFS);
-   if (lprof->lp_profile == NULL) {
+   if (!lprof->lp_profile) {
err = -ENOMEM;
goto free_lprof;
}
 
LASSERT(osclen == (strlen(osc) + 1));
lprof->lp_dt = kmemdup(osc, osclen, GFP_NOFS);
-   if (lprof->lp_dt == NULL) {
+   if (!lprof->lp_dt) {
err = -ENOMEM;
goto free_lp_profile;
}
@@ -856,7 +856,7 @@ int class_add_profile(int proflen, char *prof, int osclen, 
char *osc,
if (mdclen > 0) {
LASSERT(mdclen == (strlen(mdc) + 1));
lprof->lp_md = kmemdup(mdc, mdclen, GFP_NOFS);
-   if (lprof->lp_md == NULL) {
+   if (!lprof->lp_md) {
err = -ENOMEM;
goto free_lp_dt;
}
@@ -963,15 +963,15 @@ struct lustre_cfg *lustre_cfg_rename(struct lustre_cfg 
*cfg,
int  name_len = 0;
int  new_len = 0;
 
-   if (cfg == NULL || new_name == NULL)
+   if (!cfg || !new_name)
return ERR_PTR(-EINVAL);
 
param = lustre_cfg_string(cfg, 1);
-   if (param == NULL)
+   if (!param)
return ERR_PTR(-EINVAL);
 
value = strchr(param, '=');
-   if (value == NULL)
+   if (!value)
name_len = strlen(param);
else
name_len = value - param;
@@ -1000,7 +1000,7 @@ struct lustre_cfg *lustre_cfg_rename(struct lustre_cfg 
*cfg,
 
kfree(new_param);
kfree(bufs);
-   if (new_cfg == NULL)
+   if (!new_cfg)
return ERR_PTR(-ENOMEM);
 
new_cfg->lcfg_num = cfg->lcfg_num;
@@ -1178,7 +1178,7 @@ int class_process_config(struct lustre_cfg *lcfg)
}
/* Commands that require a device */
obd = class_name2obd(lustre_cfg_string(lcfg, 0));
-   if (obd == NULL) {
+   if (!obd) {
if (!LUSTRE_CFG_BUFLEN(lcfg, 0))
CERROR("this lcfg command requires a device name\n");
else
@@ -1481,7 +1481,7 @@ int class_config_llog_handler(const struct lu_env *env,
 * moving them to index [1] and [2], and insert MGC's
 * obdname at index [0].
 */
-   if (clli && clli->cfg_instance == NULL &&
+   if (clli && !clli->cfg_instance &&
lcfg->lcfg_command == LCFG_SPTLRPC_CONF) {
lustre_cfg_bufs_set(, 

[PATCH v2 10/16] Staging: lustre: obdclass: genops.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Changes in v2-
 Considering cases with != NULL also

 drivers/staging/lustre/lustre/obdclass/genops.c | 54 -
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c 
b/drivers/staging/lustre/lustre/obdclass/genops.c
index c12ebd5..6112df9 100644
--- a/drivers/staging/lustre/lustre/obdclass/genops.c
+++ b/drivers/staging/lustre/lustre/obdclass/genops.c
@@ -178,9 +178,9 @@ int class_register_type(struct obd_ops *dt_ops, struct 
md_ops *md_ops,
type->typ_md_ops = kzalloc(sizeof(*type->typ_md_ops), GFP_NOFS);
type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS);
 
-   if (type->typ_dt_ops == NULL ||
-   type->typ_md_ops == NULL ||
-   type->typ_name == NULL)
+   if (!type->typ_dt_ops ||
+   !type->typ_md_ops ||
+   !type->typ_name)
goto failed;
 
*(type->typ_dt_ops) = *dt_ops;
@@ -293,13 +293,13 @@ struct obd_device *class_newdev(const char *type_name, 
const char *name)
}
 
type = class_get_type(type_name);
-   if (type == NULL) {
+   if (!type) {
CERROR("OBD: unknown type: %s\n", type_name);
return ERR_PTR(-ENODEV);
}
 
newdev = obd_device_alloc();
-   if (newdev == NULL) {
+   if (!newdev) {
result = ERR_PTR(-ENOMEM);
goto out_type;
}
@@ -339,7 +339,7 @@ struct obd_device *class_newdev(const char *type_name, 
const char *name)
}
write_unlock(_dev_lock);
 
-   if (result == NULL && i >= class_devno_max()) {
+   if (!result && i >= class_devno_max()) {
CERROR("all %u OBD devices used, increase MAX_OBD_DEVICES\n",
   class_devno_max());
result = ERR_PTR(-EOVERFLOW);
@@ -463,7 +463,7 @@ struct obd_device *class_num2obd(int num)
 
if (num < class_devno_max()) {
obd = obd_devs[num];
-   if (obd == NULL)
+   if (!obd)
return NULL;
 
LASSERTF(obd->obd_magic == OBD_DEVICE_MAGIC,
@@ -509,7 +509,7 @@ void class_obd_list(void)
for (i = 0; i < class_devno_max(); i++) {
struct obd_device *obd = class_num2obd(i);
 
-   if (obd == NULL)
+   if (!obd)
continue;
if (obd->obd_stopping)
status = "ST";
@@ -540,7 +540,7 @@ struct obd_device *class_find_client_obd(struct obd_uuid 
*tgt_uuid,
for (i = 0; i < class_devno_max(); i++) {
struct obd_device *obd = class_num2obd(i);
 
-   if (obd == NULL)
+   if (!obd)
continue;
if ((strncmp(obd->obd_type->typ_name, typ_name,
 strlen(typ_name)) == 0)) {
@@ -567,7 +567,7 @@ struct obd_device *class_devices_in_group(struct obd_uuid 
*grp_uuid, int *next)
 {
int i;
 
-   if (next == NULL)
+   if (!next)
i = 0;
else if (*next >= 0 && *next < class_devno_max())
i = *next;
@@ -578,10 +578,10 @@ struct obd_device *class_devices_in_group(struct obd_uuid 
*grp_uuid, int *next)
for (; i < class_devno_max(); i++) {
struct obd_device *obd = class_num2obd(i);
 
-   if (obd == NULL)
+   if (!obd)
continue;
if (obd_uuid_equals(grp_uuid, >obd_uuid)) {
-   if (next != NULL)
+   if (next)
*next = i+1;
read_unlock(_dev_lock);
return obd;
@@ -609,7 +609,7 @@ int class_notify_sptlrpc_conf(const char *fsname, int 
namelen)
for (i = 0; i < class_devno_max(); i++) {
obd = class_num2obd(i);
 
-   if (obd == NULL || obd->obd_set_up == 0 || obd->obd_stopping)
+   if (!obd || obd->obd_set_up == 0 || obd->obd_stopping)
continue;
 
/* only notify mdc, osc, mdt, ost */
@@ -659,27 +659,27 @@ void obd_cleanup_caches(void)
 
 int obd_init_caches(void)
 {
-   LASSERT(obd_device_cachep == NULL);
+   LASSERT(!obd_device_cachep);
obd_device_cachep = kmem_cache_create("ll_obd_dev_cache",
 sizeof(struct obd_device),
 0, 0, NULL);
if (!obd_device_cachep)
goto out;
 
-   LASSERT(obdo_cachep == NULL);
+   LASSERT(!obdo_cachep);
obdo_cachep = kmem_cache_create("ll_obdo_cache", sizeof(struct obdo),
   0, 0, NULL);
if (!obdo_cachep)

[PATCH v2 08/16] Staging: lustre: libcfs: libcfs_mem.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Change in v2-
 No change

 drivers/staging/lustre/lustre/libcfs/libcfs_mem.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_mem.c 
b/drivers/staging/lustre/lustre/libcfs/libcfs_mem.c
index 1debdda..f4e08da 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_mem.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_mem.c
@@ -84,7 +84,7 @@ cfs_percpt_alloc(struct cfs_cpt_table *cptab, unsigned int 
size)
count = cfs_cpt_number(cptab);
 
LIBCFS_ALLOC(arr, offsetof(struct cfs_var_array, va_ptrs[count]));
-   if (arr == NULL)
+   if (!arr)
return NULL;
 
arr->va_size= size = L1_CACHE_ALIGN(size);
@@ -93,7 +93,7 @@ cfs_percpt_alloc(struct cfs_cpt_table *cptab, unsigned int 
size)
 
for (i = 0; i < count; i++) {
LIBCFS_CPT_ALLOC(arr->va_ptrs[i], cptab, i, size);
-   if (arr->va_ptrs[i] == NULL) {
+   if (!arr->va_ptrs[i]) {
cfs_percpt_free((void *)>va_ptrs[0]);
return NULL;
}
@@ -160,7 +160,7 @@ cfs_array_free(void *vars)
arr = container_of(vars, struct cfs_var_array, va_ptrs[0]);
 
for (i = 0; i < arr->va_count; i++) {
-   if (arr->va_ptrs[i] == NULL)
+   if (!arr->va_ptrs[i])
continue;
 
LIBCFS_FREE(arr->va_ptrs[i], arr->va_size);
@@ -182,7 +182,7 @@ cfs_array_alloc(int count, unsigned int size)
int i;
 
LIBCFS_ALLOC(arr, offsetof(struct cfs_var_array, va_ptrs[count]));
-   if (arr == NULL)
+   if (!arr)
return NULL;
 
arr->va_count   = count;
@@ -191,7 +191,7 @@ cfs_array_alloc(int count, unsigned int size)
for (i = 0; i < count; i++) {
LIBCFS_ALLOC(arr->va_ptrs[i], size);
 
-   if (arr->va_ptrs[i] == NULL) {
+   if (!arr->va_ptrs[i]) {
cfs_array_free((void *)>va_ptrs[0]);
return NULL;
}
-- 
2.1.4

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


[PATCH v2 07/16] Staging: lustre: libcfs: libcfs_lock.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Change in v2-
 No change

 drivers/staging/lustre/lustre/libcfs/libcfs_lock.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c 
b/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c
index 2c199c7..29308ba 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c
@@ -63,12 +63,12 @@ cfs_percpt_lock_alloc(struct cfs_cpt_table *cptab)
 
/* NB: cptab can be NULL, pcl will be for HW CPUs on that case */
LIBCFS_ALLOC(pcl, sizeof(*pcl));
-   if (pcl == NULL)
+   if (!pcl)
return NULL;
 
pcl->pcl_cptab = cptab;
pcl->pcl_locks = cfs_percpt_alloc(cptab, sizeof(*lock));
-   if (pcl->pcl_locks == NULL) {
+   if (!pcl->pcl_locks) {
LIBCFS_FREE(pcl, sizeof(*pcl));
return NULL;
}
@@ -164,7 +164,7 @@ cfs_percpt_atomic_alloc(struct cfs_cpt_table *cptab, int 
init_val)
int i;
 
refs = cfs_percpt_alloc(cptab, sizeof(*ref));
-   if (refs == NULL)
+   if (!refs)
return NULL;
 
cfs_percpt_for_each(ref, i, refs)
-- 
2.1.4

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


RE: [PATCH] ahci: qoriq: fixed using uninitialized variable warnings

2015-09-10 Thread Yuantian Tang
Hi Tejun,

Could you please take the version 1 patch?
The version 2 patch can't address these warnings, and the version 1 can 
definitely remove them.
In this case, that would cause any hidden bugs, so no worries.

Regards,
Yuantian

> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo
> Sent: Wednesday, September 09, 2015 10:02 PM
> To: Tang Yuantian-B29983 
> Cc: hdego...@redhat.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH] ahci: qoriq: fixed using uninitialized variable warnings
> 
> On Wed, Sep 09, 2015 at 05:16:22PM +0800, yuantian.t...@freescale.com
> wrote:
> > From: Tang Yuantian 
> >
> > kbuild test robot reports the warnings:
> > drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
> > >> include/asm-generic/io.h:163:2: warning: 'px_is' may be used
> > >> uninitialized in this function [-Wuninitialized]
> > drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here
> > >> include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used
> > >> uninitialized in this function [-Wuninitialized]
> > drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here
> >
> > This patch fixed it by assigning 0 to px_is and px_cmd variables.
> > This patch also remove line 'struct ccsr_ahci *reg_base' which is not
> > referred by any other codes and thus a dead one.
> 
> Hmm... I think the problem here is that the complier can't know whether
> qoriq_priv->type would change across intervening function calls.  Maybe a
> better solution is caching the type in a local variable so that the compiler 
> can
> tell that those two tests will always move together?  It generally isn't a 
> good
> idea to clear variables unnecessarily as that can hide actual bugs that 
> compiler
> can detect.
> 
> Thanks.
> 
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


平时最多也就联系了三千家,全球还有十几万客户在哪里?

2015-09-10 Thread iSayor
您好:
您还在用ali平台开发外贸客户?
   还在使用展会宣传企业和产品?
 你out了!!!
 当前外贸客户开发难,您是否也在寻找展会,B2B之外好的渠道? 
 行业全球十几万客户,平时最多也就联系了三千家,您是否想把剩下的也开发到?
 加QQ2652697913给您演示下主动开发客户的方法,先用先受益,已经有近万家企业领先您使用!!。
 广东省商业联合会推荐,主动开发客户第一品牌,近万家企业正在获益。您可以没有使用,但是不能没有了解。

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


[PATCH v2 11/16] Staging: rtl8188eu: hal: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Change in v2-
 No change

 drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c 
b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
index 06d1e65..d6d009a 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
@@ -43,7 +43,7 @@ int   rtl8188eu_init_recv_priv(struct adapter *padapter)
 
precvpriv->pallocated_recv_buf =
kcalloc(NR_RECVBUFF, sizeof(struct recv_buf), GFP_KERNEL);
-   if (precvpriv->pallocated_recv_buf == NULL) {
+   if (!precvpriv->pallocated_recv_buf) {
res = _FAIL;
RT_TRACE(_module_rtl871x_recv_c_, _drv_err_,
("alloc recv_buf fail!\n"));
-- 
2.1.4

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


[PATCH v2 16/16] Staging: rtl8188eu: os_dep: osdep_service.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Change in v2-
 No change

 drivers/staging/rtl8188eu/os_dep/osdep_service.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/osdep_service.c 
b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
index acb4eb1..466cd76 100644
--- a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
@@ -52,7 +52,7 @@ void *rtw_malloc2d(int h, int w, int size)
int j;
 
void **a = kzalloc(h*sizeof(void *) + h*w*size, GFP_KERNEL);
-   if (a == NULL) {
+   if (!a) {
pr_info("%s: alloc memory fail!\n", __func__);
return NULL;
}
-- 
2.1.4

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


[PATCH v2 14/16] Staging: rtl8188eu: os_dep: recv_linux.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Change in v2-
 No change

 drivers/staging/rtl8188eu/os_dep/recv_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/recv_linux.c 
b/drivers/staging/rtl8188eu/os_dep/recv_linux.c
index 3ebb8b2..d4734baf 100644
--- a/drivers/staging/rtl8188eu/os_dep/recv_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/recv_linux.c
@@ -94,7 +94,7 @@ int rtw_recv_indicatepkt(struct adapter *padapter,
pfree_recv_queue = &(precvpriv->free_recv_queue);
 
skb = precv_frame->pkt;
-   if (skb == NULL) {
+   if (!skb) {
RT_TRACE(_module_recv_osdep_c_, _drv_err_,
 ("rtw_recv_indicatepkt():skb == NULL something 
wrong\n"));
goto _recv_indicatepkt_drop;
-- 
2.1.4

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


[PATCH v2 15/16] Staging: rtl8188eu: os_dep: mlme_linux.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Change in v2-
 No changes

 drivers/staging/rtl8188eu/os_dep/mlme_linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/mlme_linux.c 
b/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
index 218adaa..eb8ecb7 100644
--- a/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
@@ -152,7 +152,7 @@ void rtw_indicate_sta_assoc_event(struct adapter *padapter, 
struct sta_info *pst
union iwreq_data wrqu;
struct sta_priv *pstapriv = >stapriv;
 
-   if (psta == NULL)
+   if (!psta)
return;
 
if (psta->aid > NUM_STA)
@@ -176,7 +176,7 @@ void rtw_indicate_sta_disassoc_event(struct adapter 
*padapter, struct sta_info *
union iwreq_data wrqu;
struct sta_priv *pstapriv = >stapriv;
 
-   if (psta == NULL)
+   if (!psta)
return;
 
if (psta->aid > NUM_STA)
-- 
2.1.4

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


[PATCH v2 13/16] Staging: rtl8188eu: hal: rtl8188eu_xmit.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Changes in v2-
 No change

 drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c 
b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
index 594c1da..4433560 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
@@ -649,7 +649,7 @@ static s32 pre_xmitframe(struct adapter *adapt, struct 
xmit_frame *pxmitframe)
goto enqueue;
 
pxmitbuf = rtw_alloc_xmitbuf(pxmitpriv);
-   if (pxmitbuf == NULL)
+   if (!pxmitbuf)
goto enqueue;
 
spin_unlock_bh(>lock);
-- 
2.1.4

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


[PATCH v2 05/16] Staging: rtl8188eu: core: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Changes in v2-
 No change

 drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c 
b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
index b340e4a..497fb06 100644
--- a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
@@ -273,7 +273,7 @@ u32 rtw_free_stainfo(struct adapter *padapter, struct 
sta_info *psta)
struct  sta_priv *pstapriv = >stapriv;
 
 
-   if (psta == NULL)
+   if (!psta)
goto exit;
 
pfree_sta_queue = >free_sta_queue;
@@ -433,7 +433,7 @@ struct sta_info *rtw_get_stainfo(struct sta_priv *pstapriv, 
u8 *hwaddr)
u8 bc_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
 
 
-   if (hwaddr == NULL)
+   if (!hwaddr)
return NULL;
 
if (IS_MCAST(hwaddr))
@@ -473,7 +473,7 @@ u32 rtw_init_bcmc_stainfo(struct adapter *padapter)
 
psta = rtw_alloc_stainfo(pstapriv, bcast_addr);
 
-   if (psta == NULL) {
+   if (!psta) {
res = _FAIL;
RT_TRACE(_module_rtl871x_sta_mgt_c_, _drv_err_, 
("rtw_alloc_stainfo fail"));
goto exit;
-- 
2.1.4

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


[PATCH v2 06/16] Staging: rtl8188eu: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Change in v2-
  No change.

 drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
index 0a62bfa..d528140 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
@@ -467,7 +467,7 @@ static void SetFwRsvdPagePkt(struct adapter *adapt, bool 
bDLFinished)
 
DBG_88E("%s\n", __func__);
ReservedPagePacket = kzalloc(1000, GFP_KERNEL);
-   if (ReservedPagePacket == NULL) {
+   if (!ReservedPagePacket) {
DBG_88E("%s: alloc ReservedPagePacket fail!\n", __func__);
return;
}
@@ -537,7 +537,7 @@ static void SetFwRsvdPagePkt(struct adapter *adapt, bool 
bDLFinished)
 
TotalPacketLen = BufIndex + QosNullLength;
pmgntframe = alloc_mgtxmitframe(pxmitpriv);
-   if (pmgntframe == NULL)
+   if (!pmgntframe)
goto exit;
 
/*  update attribute */
-- 
2.1.4

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


[PATCH v2 12/16] Staging: rtl8188eu: hal: Hal8188ERateAdaptive.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
Change in v2-
 No change

 drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c 
b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
index 2633a13..a108e80 100644
--- a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
+++ b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
@@ -127,7 +127,7 @@ static int odm_RateDown_8188E(struct odm_dm_struct *dm_odm,
 
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
ODM_DBG_TRACE, ("=>odm_RateDown_8188E()\n"));
-   if (NULL == pRaInfo) {
+   if (!pRaInfo) {
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
("odm_RateDown_8188E(): pRaInfo is NULL\n"));
return -1;
@@ -193,7 +193,7 @@ static int odm_RateUp_8188E(
 
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
ODM_DBG_TRACE, ("=>odm_RateUp_8188E()\n"));
-   if (NULL == pRaInfo) {
+   if (!pRaInfo) {
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
("odm_RateUp_8188E(): pRaInfo is NULL\n"));
return -1;
@@ -624,7 +624,7 @@ int ODM_RAInfo_Init_all(struct odm_dm_struct *dm_odm)
 
 u8 ODM_RA_GetShortGI_8188E(struct odm_dm_struct *dm_odm, u8 macid)
 {
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return 0;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
 ("macid =%d SGI =%d\n", macid, 
dm_odm->RAInfo[macid].RateSGI));
@@ -635,7 +635,7 @@ u8 ODM_RA_GetDecisionRate_8188E(struct odm_dm_struct 
*dm_odm, u8 macid)
 {
u8 DecisionRate = 0;
 
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return 0;
DecisionRate = dm_odm->RAInfo[macid].DecisionRate;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
@@ -647,7 +647,7 @@ u8 ODM_RA_GetHwPwrStatus_8188E(struct odm_dm_struct 
*dm_odm, u8 macid)
 {
u8 PTStage = 5;
 
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return 0;
PTStage = dm_odm->RAInfo[macid].PTStage;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
@@ -659,7 +659,7 @@ void ODM_RA_UpdateRateInfo_8188E(struct odm_dm_struct 
*dm_odm, u8 macid, u8 Rate
 {
struct odm_ra_info *pRaInfo = NULL;
 
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
 ("macid =%d RateID = 0x%x RateMask = 0x%x SGIEnable =%d\n",
@@ -676,7 +676,7 @@ void ODM_RA_SetRSSI_8188E(struct odm_dm_struct *dm_odm, u8 
macid, u8 Rssi)
 {
struct odm_ra_info *pRaInfo = NULL;
 
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
 (" macid =%d Rssi =%d\n", macid, Rssi));
-- 
2.1.4

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


Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support

2015-09-10 Thread Krzysztof Kozlowski
On 10.09.2015 22:42, Javier Martinez Canillas wrote:
> The simplefb driver allows the kernel to render on a pre-allocated
> buffer that's been initialized by firmware before the kernel boots.
> 
> This option was enabled to have display working on the Exynos5250
> Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig
> update") since proper DRM/KMS support did not exist at that time.
> 
> But now that the Exynos DRM driver has support for this hardware,
> there is no need to have simplefb enabled. In fact, if a user has
> a u-boot that injects the simplefb dev node to the FDT before pass
> it to the kernel, display won't be properly initialized and only a
> blank screen will be shown since there isn't a proper handoff from
> the simplefb driver to the Exynos DRM driver.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  arch/arm/configs/exynos_defconfig | 1 -
>  1 file changed, 1 deletion(-)

Seems logical. None of the boards use simple-framebuffer compatible
anyway. I understand that on Snow simplefb was needed along with change
in Uboot like this one:
https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2

and now none of Exynos boards use simplefb anymore?

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/


[PATCH] perf tools: Fix segfault in 'perf top'

2015-09-10 Thread Wang Nan
'perf top' segfaults with following operation:

 # perf top -e page-faults -p 15173 # 15173 never generate page-fault

Then on the resulting empty interface, press right key:

 # ./perf top -e page-faults -p 11400
 perf: Segmentation fault
  backtrace 
 ./perf[0x535428]
 /lib64/libc.so.6(+0x3545f)[0x7f0dd360745f]
 ./perf[0x531d46]
 ./perf(perf_evlist__tui_browse_hists+0x96)[0x5340d6]
 ./perf[0x44ba2f]
 /lib64/libpthread.so.0(+0x81d0)[0x7f0dd49dc1d0]
 /lib64/libc.so.6(clone+0x6c)[0x7f0dd36b90dc]

The bug reside in perf_evsel__hists_browse() that, in the above circumstance
browser->selection can be NULL, but code after skip_annotation doesn't consider
it.

This patch fix it by checing browser->selection before fetching
browser->selection->map and browser->selection->sym.

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index e4fd40f..b00fa92 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -2017,7 +2017,8 @@ skip_annotation:
  [nr_options], dso);
nr_options += add_map_opt(browser, [nr_options],
  [nr_options],
- browser->selection->map);
+ browser->selection ?
+   browser->selection->map : NULL);
nr_options += add_socket_opt(browser, [nr_options],
 [nr_options],
 socket);
@@ -2030,7 +2031,10 @@ skip_annotation:
nr_options += add_script_opt(browser,
 [nr_options],
 [nr_options],
-NULL, 
browser->selection->sym);
+NULL,
+browser->selection ?
+   browser->selection->sym 
:
+   NULL);
}
nr_options += add_script_opt(browser, [nr_options],
 [nr_options], NULL, NULL);
-- 
1.8.3.4

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


linux-next: Tree for Sep 11

2015-09-10 Thread Stephen Rothwell
Hi all,

Please do not add material for v4.4 until after v4.3-rc1 is out.

Changes since 20150910:

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto something very old :-(

The kvm tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1012
 1000 files changed, 68065 insertions(+), 9023 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 226 trees (counting Linus' and 33 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (b8889c4fc6ba Merge tag 'tty-4.3-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (e21347a1c717 Merge branch 'uaccess' into fixes)
Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather 
than duplicating its implementation)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (daebaabb5cfb powerpc/pseries: Release DRC when 
configure_connector fails)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (30927520dbae tcp_cubic: better follow cubic curve after 
idle period)
Merging ipsec/master (93efac3f2e03 ipv6: Fix IPsec pre-encap fragmentation 
check)
Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal 
PCM order)
Merging pci-current/for-linus (45ea2a5fed6d PCI: Don't use 64-bit bus addresses 
on PA-RISC)
Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module 
parameter for MSI interrupts)
Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4)
Merging tty.current/tty-linus (b8889c4fc6ba Merge tag 'tty-4.3-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty)
Merging usb.current/usb-linus (f7644cbfcdf0 Linux 4.2-rc6)
Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() 
call to error pathway)
Merging usb-serial-fixes/usb-linus (d071a3cdd2e1 USB: qcserial: add HP lt4111 
LTE/EV-DO/HSPA+ Gobi 4G Module)
Merging staging.current/staging-linus (a794b4f32921 Merge tag 'for-linus-4.3' 
of git://git.code.sf.net/p/openipmi/linux-ipmi)
Merging char-misc.current/char-misc-linus (f7644cbfcdf0 Linux 4.2-rc6)
Merging input-current/for-linus (01b944fe1cd4 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (9da75de030bb crypto: sunxi-ss - Fix a possible 
driver hang with ciphers)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix 
futex_cmp_requeue_pi() error handling)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 

Re: [PATCH] PM / devfreq: Fix incorrect type issue.

2015-09-10 Thread MyungJoo Ham
  
> time_in_state in struct devfreq is defined as unsigned long, so
> devm_kzalloc should use sizeof(unsigned long) as argument instead
> of sizeof(unsigned int), otherwise it will cause unexpected result
> in 64bit system.
> 
> Signed-off-by: Xiaolong Ye 
> Signed-off-by: Kevin Liu 

Thanks!

Signed-off-by: MyungJoo Ham 


Which SoC are you working with?
Are you going to upstream your 64bit devfreq driver soon?


Cheers,
MyungJoo

> ---
>  drivers/devfreq/devfreq.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index ca1b362..ac9845a 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -482,7 +482,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
>   devfreq->profile->max_state *
>   devfreq->profile->max_state,
>   GFP_KERNEL);
> - devfreq->time_in_state = devm_kzalloc(dev, sizeof(unsigned int) *
> + devfreq->time_in_state = devm_kzalloc(dev, sizeof(unsigned long) *
>   devfreq->profile->max_state,
>   GFP_KERNEL);
>   devfreq->last_stat_updated = jiffies;
> -- 
> 1.7.9.5


Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

2015-09-10 Thread Parav Pandit
On Fri, Sep 11, 2015 at 9:34 AM, Tejun Heo  wrote:
> Hello, Parav.
>
> On Fri, Sep 11, 2015 at 09:09:58AM +0530, Parav Pandit wrote:
>> The fact is that user level application uses hardware resources.
>> Verbs layer is software abstraction for it. Drivers are hiding how
>> they implement this QP or CQ or whatever hardware resource they
>> project via API layer.
>> For all of the userland on top of verb layer I mentioned above, the
>> common resource abstraction is these resources AH, QP, CQ, MR etc.
>> Hardware (and driver) might have different view of this resource in
>> their real implementation.
>> For example, verb layer can say that it has 100 QPs, but hardware
>> might actually have 20 QPs that driver decide how to efficiently use
>> it.
>
> My uneducated suspicion is that the abstraction is just not developed
> enough.  It should be possible to virtualize these resources through,
> most likely, time-sharing to the level where userland simply says "I
> want this chunk transferred there" and OS schedules the transfer
> prioritizing competing requests.

Tejun,
That is such a perfect abstraction to have at OS level, but not sure
how much close it can be to bare metal RDMA it can be.
I have started discussion on that front as well as part of other
thread, but its certainly long way to go.
Most want to enjoy the performance benefit of the bare metal
interfaces it provides.

Such abstraction that you mentioned, exists, the only difference is
instead of its OS as central entity, its the higher level libraries,
drivers and hw together does it today for the applications.


>
> It could be that given the use cases rdma might not need such level of
> abstraction - e.g. most users want to be and are pretty close to bare
> metal, but, if that's true, it also kinda is weird to build
> hierarchical resource distribution scheme on top of such bare
> abstraction.
>
> ...
>> > I don't know.  What's proposed in this thread seems way too low level
>> > to be useful anywhere else.  Also, what if there are multiple devices?
>> > Is that a problem to worry about?
>>
>> o.k. It doesn't have to be useful anywhere else. If it suffice the
>> need of RDMA applications, its fine for near future.
>> This patch allows limiting resources across multiple devices.
>> As we go along the path, and if requirement come up to have knob on
>> per device basis, thats something we can extend in future.
>
> You kinda have to decide that upfront cuz it gets baked into the
> interface.

Well, all the interfaces are not yet defined. Except the test and
benchmark utilities, real world applications wouldn't really bother
much about which device are they are going through.
so I expect that per device level control would nice for very specific
applications, but I don't anticipate that in first place.
If others have different view, I would be happy to hear that.

Even if we extend per device control, I would expect per cgroup
control at top level without which its uncontrolled access.

>
>> > I'm kinda doubtful we're gonna have too many of these.  Hardware
>> > details being exposed to userland this directly isn't common.
>>
>> Its common in RDMA applications. Again they may not be real hardware
>> resource, its just API layer which defines those RDMA constructs.
>
> It's still a very low level of abstraction which pretty much gets
> decided by what the hardware and driver decide to do.
>
>> > I'd say keep it simple and do the minimum. :)
>>
>> o.k. In that case new rdma cgroup controller which does rdma resource
>> accounting is possibly the most simplest form?
>> Make sense?
>
> So, this fits cgroup's purpose to certain level but it feels like
> we're trying to build too much on top of something which hasn't
> developed sufficiently.  I suppose it could be that this is the level
> of development that rdma is gonna reach and dumb cgroup controller can
> be useful for some use cases.  I don't know, so, yeah, let's keep it
> simple and avoid doing crazy stuff.
>

o.k. thanks. I would wait for some more time to collect more feedback.
In absence of that,

I will send updated patch V1 which will include,
(a) functionality of this patch in new rdma cgroup as you recommended,
(b) fixes for comments from Haggai for this patch
(c) more fixes which I have done in mean time

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


Re: [PATCH] xhci: create one unified function to calculate TRB TD remainder.

2015-09-10 Thread chunfeng yun
Hi,

It works ok when I add MTK's quirk into xhci_td_remainder(), and test it
by usb camera, udisk, usb ethernet adapter, and hub.


On Tue, 2015-09-08 at 14:09 +0300, Mathias Nyman wrote:
> xhci versions 1.0 and later report the untransferred data remaining in a
> TD a bit differently than older hosts.
> 
> We used to have separate functions for these, and needed to check host
>  version before calling the right function.
> 
> Now Mediatek host has an additional quirk on how it uses the TD Size
> field for remaining data. To prevent yet another function for calculating
> remainder we instead want to make one quirk friendly unified function.
> 
> Signed-off-by: Mathias Nyman 
> ---
>  drivers/usb/host/xhci-ring.c | 106 
> ++-
>  drivers/usb/host/xhci.h  |   2 +
>  2 files changed, 46 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index a47a1e8..57f40a1 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3020,21 +3020,6 @@ int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t 
> mem_flags,
>  }
>  
>  /*
> - * The TD size is the number of bytes remaining in the TD (including this 
> TRB),
> - * right shifted by 10.
> - * It must fit in bits 21:17, so it can't be bigger than 31.
> - */
> -static u32 xhci_td_remainder(unsigned int remainder)
> -{
> - u32 max = (1 << (21 - 17 + 1)) - 1;
> -
> - if ((remainder >> 10) >= max)
> - return max << 17;
> - else
> - return (remainder >> 10) << 17;
> -}
> -
> -/*
>   * For xHCI 1.0 host controllers, TD size is the number of max packet sized
>   * packets remaining in the TD (*not* including this TRB).
>   *
> @@ -3046,30 +3031,36 @@ static u32 xhci_td_remainder(unsigned int remainder)
>   *
>   * TD size = total_packet_count - packets_transferred
>   *
> - * It must fit in bits 21:17, so it can't be bigger than 31.
> + * For xHCI 0.96 and older, TD size field should be the remaining bytes
> + * including this TRB, right shifted by 10
> + *
> + * For all hosts it must fit in bits 21:17, so it can't be bigger than 31.
> + * This is taken care of in the TRB_TD_SIZE() macro
> + *
>   * The last TRB in a TD must have the TD size set to zero.
>   */
> -static u32 xhci_v1_0_td_remainder(int running_total, int trb_buff_len,
> - unsigned int total_packet_count, struct urb *urb,
> - unsigned int num_trbs_left)
> +static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,
> +   int trb_buff_len, unsigned int td_total_len,
> +   struct urb *urb, unsigned int num_trbs_left)
>  {
> - int packets_transferred;
> + u32 maxp, total_packet_count;
> +
> + if (xhci->hci_version < 0x100)
> + return ((td_total_len - transferred) >> 10);
> +
> + maxp = GET_MAX_PACKET(usb_endpoint_maxp(>ep->desc));
> + total_packet_count = DIV_ROUND_UP(td_total_len, maxp);
>  
>   /* One TRB with a zero-length data packet. */
> - if (num_trbs_left == 0 || (running_total == 0 && trb_buff_len == 0))
> + if (num_trbs_left == 0 || (transferred == 0 && trb_buff_len == 0) ||
> + trb_buff_len == td_total_len)
>   return 0;
>  
> - /* All the TRB queueing functions don't count the current TRB in
> -  * running_total.
> -  */
> - packets_transferred = (running_total + trb_buff_len) /
> - GET_MAX_PACKET(usb_endpoint_maxp(>ep->desc));
> -
> - if ((total_packet_count - packets_transferred) > 31)
> - return 31 << 17;
> - return (total_packet_count - packets_transferred) << 17;
> + /* Queueing functions don't count the current TRB into transferred */
> + return (total_packet_count - ((transferred + trb_buff_len) / maxp));
>  }
>  
> +
>  static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
>   struct urb *urb, int slot_id, unsigned int ep_index)
>  {
> @@ -3191,17 +3182,12 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, 
> gfp_t mem_flags,
>   }
>  
>   /* Set the TRB length, TD size, and interrupter fields. */
> - if (xhci->hci_version < 0x100) {
> - remainder = xhci_td_remainder(
> - urb->transfer_buffer_length -
> - running_total);
> - } else {
> - remainder = xhci_v1_0_td_remainder(running_total,
> - trb_buff_len, total_packet_count, urb,
> - num_trbs - 1);
> - }
> + remainder = xhci_td_remainder(xhci, running_total, trb_buff_len,
> +urb->transfer_buffer_length,
> +urb, num_trbs - 1);
> +
>   length_field = TRB_LEN(trb_buff_len) |
> - remainder |
> + 

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

2015-09-10 Thread Doug Ledford
On 09/11/2015 12:04 AM, Tejun Heo wrote:
> Hello, Parav.
> 
> On Fri, Sep 11, 2015 at 09:09:58AM +0530, Parav Pandit wrote:
>> The fact is that user level application uses hardware resources.
>> Verbs layer is software abstraction for it. Drivers are hiding how
>> they implement this QP or CQ or whatever hardware resource they
>> project via API layer.
>> For all of the userland on top of verb layer I mentioned above, the
>> common resource abstraction is these resources AH, QP, CQ, MR etc.
>> Hardware (and driver) might have different view of this resource in
>> their real implementation.
>> For example, verb layer can say that it has 100 QPs, but hardware
>> might actually have 20 QPs that driver decide how to efficiently use
>> it.
> 
> My uneducated suspicion is that the abstraction is just not developed
> enough.

The abstraction is 10+ years old.  It has had plenty of time to ferment
and something better for the specific use case has not emerged.

>  It should be possible to virtualize these resources through,
> most likely, time-sharing to the level where userland simply says "I
> want this chunk transferred there" and OS schedules the transfer
> prioritizing competing requests.

No.  And if you think this, then you miss the *entire* point of RDMA
technologies.  An analogy that I have used many times in presentations
is that, in the networking world, the kernel is both a postman and a
copy machine.  It receives all incoming packets and must sort them to
the right recipient (the postman job) and when the user space
application is ready to use the information it must copy it into the
user's VM space because it couldn't just put the user's data buffer on
the RX buffer list since each buffer might belong to anyone (the copy
machine).  In the RDMA world, you create a new queue pair, it is often a
long lived connection (like a socket), but it belongs now to the app and
the app can directly queue both send and receive buffers to the card and
on incoming packets the card will be able to know that the packet
belongs to a specific queue pair and will immediately go to that apps
buffer.  You can *not* do this with TCP without moving to complete TCP
offload on the card, registration of specific sockets on the card, and
then allowing the application to pre-register receive buffers for a
specific socket to the card so that incoming data on the wire can go
straight to the right place.  If you ever get to the point of "OS
schedules the transfer" then you might as well throw RDMA out the window
because you have totally trashed the benefit it provides.

> It could be that given the use cases rdma might not need such level of
> abstraction - e.g. most users want to be and are pretty close to bare
> metal, but, if that's true, it also kinda is weird to build
> hierarchical resource distribution scheme on top of such bare
> abstraction.

Not really.  If you are going to have a bare abstraction, this one isn't
really a bad one.  You have devices.  On a device, you allocate
protection domains (PDs).  If you don't care about cross connection
issues, you ignore this and only use one.  If you do care, this acts
like a process's unique VM space only for RDMA buffers, it is a domain
to protect the data of one connection from another.  Then you have queue
pairs (QPs) which are roughly the equivalent of a socket.  Each QP has
at least one Completion Queue where you get the events that tell you
things have completed (although they often use two, one for send
completions and one for receive completions).  And then you use some
number of memory registrations (MRs) and address handles (AHs) depending
on your usage.  Since RDMA stands for Remote Direct Memory Access, as
you can imagine, giving a remote machine free reign to access all of the
physical memory in your machine is a security issue.  The MRs help to
control what memory the remote host on a specific QP has access to.  The
AHs control how we actually route packets from ourselves to the remote host.

Here's the deal.  You might be able to create an abstraction above this
that hides *some* of this.  But it can't hide even nearly all of it
without loosing significant functionality.  The problem here is that you
are thinking about RDMA connections like sockets.  They aren't.  Not
even close.  They are "how do I allow a remote machine to directly read
and write into my machines physical memory in an even remotely close to
secure manner?"  These resources aren't hardware resources, they are the
abstraction resources needed to answer that question.

> ...
>>> I don't know.  What's proposed in this thread seems way too low level
>>> to be useful anywhere else.  Also, what if there are multiple devices?
>>> Is that a problem to worry about?
>>
>> o.k. It doesn't have to be useful anywhere else. If it suffice the
>> need of RDMA applications, its fine for near future.
>> This patch allows limiting resources across multiple devices.
>> As we go along the path, and if requirement come 

Re: [PATCH] cpufreq: imx: update the clock swith flow to support imx6ul

2015-09-10 Thread Viresh Kumar
On 11-09-15, 19:23, Bai Ping wrote:
> @@ -331,6 +365,10 @@ put_clk:
>   clk_put(step_clk);
>   if (!IS_ERR(pll2_pfd2_396m_clk))
>   clk_put(pll2_pfd2_396m_clk);
> + if (!IS_ERR(pll2_bus_clk))
> + clk_put(pll2_bus_clk);
> + if (!IS_ERR(secondary_sel_clk))
> + clk_put(secondary_sel_clk);
>   of_node_put(np);
>   return ret;
>  }

You missed performing same steps in imx6q_cpufreq_remove() ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xhci: create one unified function to calculate TRB TD remainder.

2015-09-10 Thread chunfeng yun
Hi,
On Tue, 2015-09-08 at 14:09 +0300, Mathias Nyman wrote:
> xhci versions 1.0 and later report the untransferred data remaining in a
> TD a bit differently than older hosts.
> 
> We used to have separate functions for these, and needed to check host
>  version before calling the right function.
> 
> Now Mediatek host has an additional quirk on how it uses the TD Size
> field for remaining data. To prevent yet another function for calculating
> remainder we instead want to make one quirk friendly unified function.
> 
> Signed-off-by: Mathias Nyman 
> ---
>  drivers/usb/host/xhci-ring.c | 106 
> ++-
>  drivers/usb/host/xhci.h  |   2 +
>  2 files changed, 46 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index a47a1e8..57f40a1 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3020,21 +3020,6 @@ int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t 
> mem_flags,
>  }
>  
>  /*
> - * The TD size is the number of bytes remaining in the TD (including this 
> TRB),
> - * right shifted by 10.
> - * It must fit in bits 21:17, so it can't be bigger than 31.
> - */
> -static u32 xhci_td_remainder(unsigned int remainder)
> -{
> - u32 max = (1 << (21 - 17 + 1)) - 1;
> -
> - if ((remainder >> 10) >= max)
> - return max << 17;
> - else
> - return (remainder >> 10) << 17;
> -}
> -
> -/*
>   * For xHCI 1.0 host controllers, TD size is the number of max packet sized
>   * packets remaining in the TD (*not* including this TRB).
>   *
> @@ -3046,30 +3031,36 @@ static u32 xhci_td_remainder(unsigned int remainder)
>   *
>   * TD size = total_packet_count - packets_transferred
>   *
> - * It must fit in bits 21:17, so it can't be bigger than 31.
> + * For xHCI 0.96 and older, TD size field should be the remaining bytes
> + * including this TRB, right shifted by 10
> + *
> + * For all hosts it must fit in bits 21:17, so it can't be bigger than 31.
> + * This is taken care of in the TRB_TD_SIZE() macro
> + *
>   * The last TRB in a TD must have the TD size set to zero.
>   */
> -static u32 xhci_v1_0_td_remainder(int running_total, int trb_buff_len,
> - unsigned int total_packet_count, struct urb *urb,
> - unsigned int num_trbs_left)
> +static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,
> +   int trb_buff_len, unsigned int td_total_len,
> +   struct urb *urb, unsigned int num_trbs_left)
>  {
> - int packets_transferred;
> + u32 maxp, total_packet_count;
> +
> + if (xhci->hci_version < 0x100)
> + return ((td_total_len - transferred) >> 10);
> +
> + maxp = GET_MAX_PACKET(usb_endpoint_maxp(>ep->desc));
> + total_packet_count = DIV_ROUND_UP(td_total_len, maxp);
>  
>   /* One TRB with a zero-length data packet. */
> - if (num_trbs_left == 0 || (running_total == 0 && trb_buff_len == 0))
> + if (num_trbs_left == 0 || (transferred == 0 && trb_buff_len == 0) ||
> + trb_buff_len == td_total_len)
>   return 0;
>  
I think when trb_buff_len == td_total_len, the TD only needs one trb, so
num_trbs_left will equal to 0; that means no need add this condition.

> - /* All the TRB queueing functions don't count the current TRB in
> -  * running_total.
> -  */
> - packets_transferred = (running_total + trb_buff_len) /
> - GET_MAX_PACKET(usb_endpoint_maxp(>ep->desc));
> -
> - if ((total_packet_count - packets_transferred) > 31)
> - return 31 << 17;
> - return (total_packet_count - packets_transferred) << 17;
> + /* Queueing functions don't count the current TRB into transferred */
> + return (total_packet_count - ((transferred + trb_buff_len) / maxp));
>  }
>  
> +
>  static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
>   struct urb *urb, int slot_id, unsigned int ep_index)
>  {
> @@ -3191,17 +3182,12 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, 
> gfp_t mem_flags,
>   }
>  
>   /* Set the TRB length, TD size, and interrupter fields. */
> - if (xhci->hci_version < 0x100) {
> - remainder = xhci_td_remainder(
> - urb->transfer_buffer_length -
> - running_total);
> - } else {
> - remainder = xhci_v1_0_td_remainder(running_total,
> - trb_buff_len, total_packet_count, urb,
> - num_trbs - 1);
> - }
> + remainder = xhci_td_remainder(xhci, running_total, trb_buff_len,
> +urb->transfer_buffer_length,
> +urb, num_trbs - 1);
> +
>   length_field = TRB_LEN(trb_buff_len) |
> - 

[PATCH] clockevents: Kill (unused) set_mode() callbacks

2015-09-10 Thread Viresh Kumar
All the users are migrated to the per-state callbacks, get rid of the
unused interface.

Signed-off-by: Viresh Kumar 
---
Hi Thomas,

This applies on top of linus/master, to which all my pending set-state
patches are applied now.

--
viresh

 include/linux/clockchips.h | 29 +
 kernel/time/clockevents.c  | 42 +---
 kernel/time/tick-common.c  |  1 -
 kernel/time/timer_list.c   | 54 +-
 4 files changed, 30 insertions(+), 96 deletions(-)

diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
index 31ce435981fe..bdcf358dfce2 100644
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@ -18,15 +18,6 @@
 struct clock_event_device;
 struct module;
 
-/* Clock event mode commands for legacy ->set_mode(): OBSOLETE */
-enum clock_event_mode {
-   CLOCK_EVT_MODE_UNUSED,
-   CLOCK_EVT_MODE_SHUTDOWN,
-   CLOCK_EVT_MODE_PERIODIC,
-   CLOCK_EVT_MODE_ONESHOT,
-   CLOCK_EVT_MODE_RESUME,
-};
-
 /*
  * Possible states of a clock event device.
  *
@@ -86,16 +77,14 @@ enum clock_event_state {
  * @min_delta_ns:  minimum delta value in ns
  * @mult:  nanosecond to cycles multiplier
  * @shift: nanoseconds to cycles divisor (power of two)
- * @mode:  operating mode, relevant only to ->set_mode(), OBSOLETE
  * @state_use_accessors:current state of the device, assigned by the core code
  * @features:  features
  * @retries:   number of forced programming retries
- * @set_mode:  legacy set mode function, only for modes <= 
CLOCK_EVT_MODE_RESUME.
- * @set_state_periodic:switch state to periodic, if !set_mode
- * @set_state_oneshot: switch state to oneshot, if !set_mode
- * @set_state_oneshot_stopped: switch state to oneshot_stopped, if !set_mode
- * @set_state_shutdown:switch state to shutdown, if !set_mode
- * @tick_resume:   resume clkevt device, if !set_mode
+ * @set_state_periodic:switch state to periodic
+ * @set_state_oneshot: switch state to oneshot
+ * @set_state_oneshot_stopped: switch state to oneshot_stopped
+ * @set_state_shutdown:switch state to shutdown
+ * @tick_resume:   resume clkevt device
  * @broadcast: function to broadcast events
  * @min_delta_ticks:   minimum delta value in ticks stored for reconfiguration
  * @max_delta_ticks:   maximum delta value in ticks stored for reconfiguration
@@ -116,18 +105,10 @@ struct clock_event_device {
u64 min_delta_ns;
u32 mult;
u32 shift;
-   enum clock_event_mode   mode;
enum clock_event_state  state_use_accessors;
unsigned intfeatures;
unsigned long   retries;
 
-   /*
-* State transition callback(s): Only one of the two groups should be
-* defined:
-* - set_mode(), only for modes <= CLOCK_EVT_MODE_RESUME.
-* - set_state_{shutdown|periodic|oneshot|oneshot_stopped}(), 
tick_resume().
-*/
-   void(*set_mode)(enum clock_event_mode mode, struct 
clock_event_device *);
int (*set_state_periodic)(struct clock_event_device 
*);
int (*set_state_oneshot)(struct clock_event_device 
*);
int (*set_state_oneshot_stopped)(struct 
clock_event_device *);
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 50eb107f1198..a9b76a40319e 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -97,20 +97,6 @@ EXPORT_SYMBOL_GPL(clockevent_delta2ns);
 static int __clockevents_switch_state(struct clock_event_device *dev,
  enum clock_event_state state)
 {
-   /* Transition with legacy set_mode() callback */
-   if (dev->set_mode) {
-   /* Legacy callback doesn't support new modes */
-   if (state > CLOCK_EVT_STATE_ONESHOT)
-   return -ENOSYS;
-   /*
-* 'clock_event_state' and 'clock_event_mode' have 1-to-1
-* mapping until *_ONESHOT, and so a simple cast will work.
-*/
-   dev->set_mode((enum clock_event_mode)state, dev);
-   dev->mode = (enum clock_event_mode)state;
-   return 0;
-   }
-
if (dev->features & CLOCK_EVT_FEAT_DUMMY)
return 0;
 
@@ -204,12 +190,8 @@ int clockevents_tick_resume(struct clock_event_device *dev)
 {
int ret = 0;
 
-   if (dev->set_mode) {
-   dev->set_mode(CLOCK_EVT_MODE_RESUME, dev);
-   dev->mode = CLOCK_EVT_MODE_RESUME;
-   } else if (dev->tick_resume) {
+   if (dev->tick_resume)
ret = dev->tick_resume(dev);
-   }
 
return ret;
 }
@@ -460,26 +442,6 @@ int clockevents_unbind_device(struct clock_event_device 
*ced, int cpu)

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

2015-09-10 Thread Tejun Heo
Hello, Parav.

On Fri, Sep 11, 2015 at 09:09:58AM +0530, Parav Pandit wrote:
> The fact is that user level application uses hardware resources.
> Verbs layer is software abstraction for it. Drivers are hiding how
> they implement this QP or CQ or whatever hardware resource they
> project via API layer.
> For all of the userland on top of verb layer I mentioned above, the
> common resource abstraction is these resources AH, QP, CQ, MR etc.
> Hardware (and driver) might have different view of this resource in
> their real implementation.
> For example, verb layer can say that it has 100 QPs, but hardware
> might actually have 20 QPs that driver decide how to efficiently use
> it.

My uneducated suspicion is that the abstraction is just not developed
enough.  It should be possible to virtualize these resources through,
most likely, time-sharing to the level where userland simply says "I
want this chunk transferred there" and OS schedules the transfer
prioritizing competing requests.

It could be that given the use cases rdma might not need such level of
abstraction - e.g. most users want to be and are pretty close to bare
metal, but, if that's true, it also kinda is weird to build
hierarchical resource distribution scheme on top of such bare
abstraction.

...
> > I don't know.  What's proposed in this thread seems way too low level
> > to be useful anywhere else.  Also, what if there are multiple devices?
> > Is that a problem to worry about?
>
> o.k. It doesn't have to be useful anywhere else. If it suffice the
> need of RDMA applications, its fine for near future.
> This patch allows limiting resources across multiple devices.
> As we go along the path, and if requirement come up to have knob on
> per device basis, thats something we can extend in future.

You kinda have to decide that upfront cuz it gets baked into the
interface.

> > I'm kinda doubtful we're gonna have too many of these.  Hardware
> > details being exposed to userland this directly isn't common.
> 
> Its common in RDMA applications. Again they may not be real hardware
> resource, its just API layer which defines those RDMA constructs.

It's still a very low level of abstraction which pretty much gets
decided by what the hardware and driver decide to do.

> > I'd say keep it simple and do the minimum. :)
>
> o.k. In that case new rdma cgroup controller which does rdma resource
> accounting is possibly the most simplest form?
> Make sense?

So, this fits cgroup's purpose to certain level but it feels like
we're trying to build too much on top of something which hasn't
developed sufficiently.  I suppose it could be that this is the level
of development that rdma is gonna reach and dumb cgroup controller can
be useful for some use cases.  I don't know, so, yeah, let's keep it
simple and avoid doing crazy stuff.

Thanks.

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


Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

2015-09-10 Thread Parav Pandit
On Fri, Sep 11, 2015 at 1:52 AM, Tejun Heo  wrote:
> Hello, Parav.
>
> On Thu, Sep 10, 2015 at 11:16:49PM +0530, Parav Pandit wrote:
>> >> These resources include are-  QP (queue pair) to transfer data, CQ
>> >> (Completion queue) to indicate completion of data transfer operation,
>> >> MR (memory region) to represent user application memory as source or
>> >> destination for data transfer.
>> >> Common resources are QP, SRQ (shared received queue), CQ, MR, AH
>> >> (Address handle), FLOW, PD (protection domain), user context etc.
>> >
>> > It's kinda bothering that all these are disparate resources.
>>
>> Actually not. They are linked resources. Every QP needs associated one
>> or two CQ, one PD.
>> Every QP will use few MRs for data transfer.
>
> So, if that's the case, let's please implement something higher level.
> The goal is providing reasonable isolation or protection.  If that can
> be achieved at a higher level of abstraction, please do that.
>
>> Here is the good programming guide of the RDMA APIs exposed to the
>> user space application.
>>
>> http://www.mellanox.com/related-docs/prod_software/RDMA_Aware_Programming_user_manual.pdf
>> So first version of the cgroups patch will address the control
>> operation for section 3.4.
>>
>> > I suppose that each restriction comes from the underlying hardware and
>> > there's no accepted higher level abstraction for these things?
>>
>> There is higher level abstraction which is through the verbs layer
>> currently which does actually expose the hardware resource but in
>> vendor agnostic way.
>> There are many vendors who support these verbs layer, some of them
>> which I know are Mellanox, Intel, Chelsio, Avago/Emulex whose drivers
>> which support these verbs are in  kernel tree.
>>
>> There is higher level APIs above the verb layer, such as MPI,
>> libfabric, rsocket, rds, pgas, dapl which uses underlying verbs layer.
>> They all rely on the hardware resource. All of these higher level
>> abstraction is accepted and well used by certain application class. It
>> would be long discussion to go over them here.
>
> Well, the programming interface that userland builds on top doesn't
> matter too much here but if there is a common resource abstraction
> which can be made in terms of constructs that consumers of the
> facility would care about, that likely is a better choice than
> exposing whatever hardware exposes.
>

Tejun,
The fact is that user level application uses hardware resources.
Verbs layer is software abstraction for it. Drivers are hiding how
they implement this QP or CQ or whatever hardware resource they
project via API layer.
For all of the userland on top of verb layer I mentioned above, the
common resource abstraction is these resources AH, QP, CQ, MR etc.
Hardware (and driver) might have different view of this resource in
their real implementation.
For example, verb layer can say that it has 100 QPs, but hardware
might actually have 20 QPs that driver decide how to efficiently use
it.

>> > I'm doubtful that these things are gonna be mainstream w/o building up
>> > higher level abstractions on top and if we ever get there we won't be
>> > talking about MR or CQ or whatever.
>>
>> Some of the higher level examples I gave above will adapt to resource
>> allocation failure. Some are actually adaptive to few resource
>> allocation failure, they do query resources. But its not completely
>> there yet. Once we have this notion of limited resource in place,
>> abstraction layer would adapt to relatively smaller value of such
>> resource.
>>
>> These higher level abstraction is mainstream. Its shipped at least in
>> Redhat Enterprise Linux.
>
> Again, I was talking more about resource abstraction - e.g. something
> along the line of "I want N command buffers".
>

Yes. We are still talking of resource abstraction here.
RDMA and IBTA defines these resources. On top of these resources
various frameworks are build.
so for example,
User land is tuning environment deploying for MPI application,
it would configure:
10 processes from the PID controller,
10 CPUs in cpuset controller,
1 PD, 20 CQ, 10 QP, 100 MRs in rdma controller,

say user land is tuning environment for deploying rsocket application
for 100 connections,
it would configure, 100 PD, 100 QP, 200 MR.
When verb layer see failure with it, they will adapt to live with what
they have at lower performance.

Since every higher level which I mentioned in different in the way, it
uses RDMA resources, we cannot generalize it as "N command buffers".
That generalization in my mind is the - rdma resources - central common entity.

>> > Also, whatever next-gen is
>> > unlikely to have enough commonalities when the proposed resource knobs
>> > are this low level,
>>
>> I agree that resource won't be common in next-gen other transport
>> whenever they arrive.
>> But with my existing background working on some of those transport,
>> they appear similar in nature and it might seek similar knobs.
>
> I don't 

Re: [PATCH v2] ARM: rockchip: add reboot notifier

2015-09-10 Thread Andy Yan

Hi Eddie:

On 2015年09月11日 10:01, Eddie Cai wrote:

Hi Andy

2015-09-10 19:04 GMT+08:00 Andy Yan :

rockchip platform have a protocol to pass the kernel reboot
mode to bootloader by some special registers when system reboot.
By this way the bootloader can take different action according
to the different kernel reboot mode, for example, command
"reboot loader" will reboot the board to rockusb mode, this is
a very convenient way to get the board enter download mode.

Signed-off-by: Andy Yan 
---

Changes in v2:
   - check cpu dt node
   - remove a unnecessary of_put_node in function rockchip_get_pmu_regmap
   - fix a align issue
   - use reboot_notifier instead of restart_handler

  arch/arm/mach-rockchip/Makefile |   2 +-
  arch/arm/mach-rockchip/loader.h |  22 
  arch/arm/mach-rockchip/reboot.c | 111 
  3 files changed, 134 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/mach-rockchip/loader.h
  create mode 100644 arch/arm/mach-rockchip/reboot.c

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 5c3a9b2..cd291e3 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -1,5 +1,5 @@
  CFLAGS_platsmp.o := -march=armv7-a

-obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o
+obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o reboot.o
  obj-$(CONFIG_PM_SLEEP) += pm.o sleep.o
  obj-$(CONFIG_SMP) += headsmp.o platsmp.o
diff --git a/arch/arm/mach-rockchip/loader.h b/arch/arm/mach-rockchip/loader.h
new file mode 100644
index 000..bf51baa
--- /dev/null
+++ b/arch/arm/mach-rockchip/loader.h
@@ -0,0 +1,22 @@
+#ifndef __MACH_ROCKCHIP_LOADER_H
+#define __MACH_ROCKCHIP_LOADER_H
+
+/*high 24 bits is tag, low 8 bits is type*/
+#define SYS_LOADER_REBOOT_FLAG   0x5242C300
+
+enum {
+   BOOT_NORMAL = 0, /* normal boot */
+   BOOT_LOADER, /* enter loader rockusb mode */
+   BOOT_MASKROM,/* enter maskrom rockusb mode (not support now) */
+   BOOT_RECOVER,/* enter recover */
+   BOOT_NORECOVER,  /* do not enter recover */
+   BOOT_SECONDOS,   /* boot second OS (not support now)*/
+   BOOT_WIPEDATA,   /* enter recover and wipe data. */
+   BOOT_WIPEALL,/* enter recover and wipe all data. */
+   BOOT_CHECKIMG,   /* check firmware img with backup part*/
+   BOOT_FASTBOOT,   /* enter fast boot mode */
+   BOOT_SECUREBOOT_DISABLE,
+   BOOT_CHARGING,   /* enter charge mode */
+   BOOT_MAX /* MAX VALID BOOT TYPE.*/
+};
+#endif
diff --git a/arch/arm/mach-rockchip/reboot.c b/arch/arm/mach-rockchip/reboot.c
new file mode 100644
index 000..c29f031e
--- /dev/null
+++ b/arch/arm/mach-rockchip/reboot.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "loader.h"
+
+#define RK3188_PMU_SYS_REG0 0x40
+#define RK3288_PMU_SYS_REG0 0x94

I think RK3066 and RK3368 also supported in upstream kernel. And the
protocol is the same. So it would be better to support it here.
   RK3066 is supported, please see function 
rockchip_get_reboot_flag_regmap bellow

   it uses the same register offset as rk3188

   RK3368 related code is under arm64, I don't know how to handle it.
   Heiko, do you have any suggestion?

+
+struct regmap *regmap;
+int flag_reg;
+
+static int rockchip_get_pmu_regmap(void)
+{
+   struct device_node *node;
+
+   node = of_find_node_by_path("/cpus");
+   if (!node)
+   return -ENODEV;
+
+   regmap = syscon_regmap_lookup_by_phandle(node, "rockchip,pmu");
+   of_node_put(node);
+   if (!IS_ERR(regmap))
+   return 0;
+
+   regmap = syscon_regmap_lookup_by_compatible("rockchip,rk3066-pmu");
+   if (!IS_ERR(regmap))
+   return 0;
+
+   return -ENODEV;
+}
+
+static int rockchip_get_reboot_flag_regmap(void)
+{
+   int ret = rockchip_get_pmu_regmap();
+
+   if (ret < 0)
+   return ret;
+
+   if (of_machine_is_compatible("rockchip,rk3288")) {
+   flag_reg = RK3288_PMU_SYS_REG0;
+   return 0;
+   } else if (of_machine_is_compatible("rockchip,rk3066a") ||
+  of_machine_is_compatible("rockchip,rk3066b") ||
+  of_machine_is_compatible("rockchip,rk3188")) {
+   flag_reg = RK3188_PMU_SYS_REG0;
+   return 0;
+   }
+
+   return -ENODEV;
+}
+
+static void rockchip_get_reboot_flag(const char *cmd, u32 *flag)
+{
+   *flag = SYS_LOADER_REBOOT_FLAG + BOOT_NORMAL;
+
+   if (cmd) {
+   if (!strcmp(cmd, "loader") || !strcmp(cmd, "bootloader"))
+   

Re: [PATCH v7 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

2015-09-10 Thread chunfeng yun
On Tue, 2015-09-08 at 19:30 -0500, Rob Herring wrote:
> On 09/08/2015 01:18 AM, Chunfeng Yun wrote:
> > add a DT binding documentation of xHCI host controller for the
> > MT8173 SoC from Mediatek.
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/usb/mt8173-xhci.txt| 52 
> > ++
> >  1 file changed, 52 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
> > b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > new file mode 100644
> > index 000..d851bf1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > @@ -0,0 +1,52 @@
> > +MT8173 xHCI
> > +
> > +The device node for Mediatek SOC USB3.0 host controller
> > +
> > +Required properties:
> > + - compatible : should contain "mediatek,mt8173-xhci"
> > + - reg : specifies physical base address and size of the registers,
> > +   the first one for MAC, the second for IPPC
> > + - interrupts : interrupt used by the controller
> > + - power-domains : a phandle to USB power domain node to control USB's
> > +   mtcmos
> > + - vusb33-supply : regulator of USB avdd3.3v
> > +
> > + - clocks : a list of phandle + clock-specifier pairs, one for each
> > +   entry in clock-names
> > + - clock-names : must contain
> > +   "sys_ck": for clock of xHCI MAC
> > +   "wakeup_deb_p0": for USB wakeup debounce clock of port0
> > +   "wakeup_deb_p0": for USB wakeup debounce clock of port1
> > +
> > + - phys : a list of phandle + phy specifier pairs
> > + - usb3-lpm-capable : supports USB3.0 LPM
> > + - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
> > +   control register
> 
> Wake-up should probably be done in some generic way. That said, I don't
> have a specific suggestion other than make it optional.
> 
> > + - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
> > +   mode; Others means don't enable wakeup source of USB
> 
> This should be optional rather than any other value meaning disabled.
> 
Ok, "mediatek,wakeup-src" and "mediatek,syscon-wakeup" properties will
be put into optional.

Thanks a lot
> > +
> > +Optional properties:
> > + - vbus-supply : reference to the VBUS regulator;
> > +
> > +Example:
> > +usb30: usb@1127 {
> > +   compatible = "mediatek,mt8173-xhci";
> > +   reg = <0 0x1127 0 0x1000>,
> > + <0 0x11280700 0 0x0100>;
> > +   interrupts = ;
> > +   power-domains = < MT8173_POWER_DOMAIN_USB>;
> > +   clocks = < CLK_TOP_USB30_SEL>,
> > +< CLK_PERI_USB0>,
> > +< CLK_PERI_USB1>;
> > +   clock-names = "sys_ck",
> > + "wakeup_deb_p0",
> > + "wakeup_deb_p1";
> > +   phys = <_port0 PHY_TYPE_USB3>,
> > +  <_port1 PHY_TYPE_USB2>;
> > +   vusb33-supply = <_vusb_reg>;
> > +   vbus-supply = <_p1_vbus>;
> > +   usb3-lpm-capable;
> > +   mediatek,syscon-wakeup = <>;
> > +   mediatek,wakeup-src = <1>;
> > +   status = "okay";
> > +};
> > 
> 


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


Re: [PATCH v7 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs

2015-09-10 Thread chunfeng yun
Hi,
On Tue, 2015-09-08 at 19:16 -0500, Rob Herring wrote:
> On 09/08/2015 01:17 AM, Chunfeng Yun wrote:
> > add a DT binding documentation of usb3.0 phy for MT65xx
> > SoCs from Mediatek.
> > 
> > Signed-off-by: Chunfeng Yun 
> 
> One comment, otherwise:
> 
> Acked-by: Rob Herring 
> 
> > ---
> >  .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 
> > ++
> >  1 file changed, 69 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> > b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > new file mode 100644
> > index 000..5812d20
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > @@ -0,0 +1,69 @@
> > +mt65xx USB3.0 PHY binding
> > +--
> > +
> > +This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
> > +
> > +Required properties (controller (parent) node):
> > + - compatible  : should be "mediatek,mt8173-u3phy"
> > + - reg : offset and length of register for phy, exclude port's
> > + register.
> > + - clocks  : a list of phandle + clock-specifier pairs, one for each
> > + entry in clock-names
> > + - clock-names : must contain
> > + "u3phya_ref": for reference clock of usb3.0 analog phy.
> > +
> > +Required nodes : a sub-node is required for each port the controller
> > + provides. Address range information including the usual
> > + 'reg' property is used inside these nodes to describe
> > + the controller's topology. These nodes are translated
> > + by the driver's .xlate() function.
> 
> The last sentence is Linux specific. Please remove.
> 
Ok, I will remove it later. Thanks
> > +
> > +Required properties (port (child) node):
> > +- reg  : address and length of the register set for the port.
> > +- #phy-cells   : should be 1 (See second example)
> > + cell after port phandle is phy type from:
> > +   - PHY_TYPE_USB2
> > +   - PHY_TYPE_USB3
> > +
> > +Example:
> > +
> > +u3phy: usb-phy@1129 {
> > +   compatible = "mediatek,mt8173-u3phy";
> > +   reg = <0 0x1129 0 0x800>;
> > +   clocks = < CLK_APMIXED_REF2USB_TX>;
> > +   clock-names = "u3phya_ref";
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +   ranges;
> > +   status = "okay";
> > +
> > +   phy_port0: port@11290800 {
> > +   reg = <0 0x11290800 0 0x800>;
> > +   #phy-cells = <1>;
> > +   status = "okay";
> > +   };
> > +
> > +   phy_port1: port@11291000 {
> > +   reg = <0 0x11291000 0 0x800>;
> > +   #phy-cells = <1>;
> > +   status = "okay";
> > +   };
> > +};
> > +
> > +Specifying phy control of devices
> > +-
> > +
> > +Device nodes should specify the configuration required in their "phys"
> > +property, containing a phandle to the phy port node and a device type;
> > +phy-names for each port are optional.
> > +
> > +Example:
> > +
> > +#include 
> > +
> > +usb30: usb@1127 {
> > +   ...
> > +   phys = <_port0 PHY_TYPE_USB3>;
> > +   phy-names = "usb3-0";
> > +   ...
> > +};
> > 
> 


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


Re: [PATCH v2] ahci: qoriq: fixed using uninitialized variable warnings

2015-09-10 Thread Fengguang Wu
Hi Tejun, Yuantian,

On Thu, Sep 10, 2015 at 10:22:14AM -0400, Tejun Heo wrote:
> (cc'ing Fengguang, hi!)
> 
> Fengguang, this is about kbuild test robot warning titled
> "drivers/ata/ahci_qoriq.c:70:6: warning: 'px_cmd' may be used
> uninitialized in this function".  Yuantian can't reproduce the warning
> and I'm wondering whether the below patch would make the warning go
> away.  Which gcc was the build bot using?

It's gcc-4.5.1-or32-1.0rc1. The reproduce steps are:

  wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout ecfb4598512a7c3e21df2941db58c10461583bb9

# this command will auto download/install openrisc cross compiler

  make.cross ARCH=openrisc allyesconfig
  make.cross ARCH=openrisc drivers/ata/ahci_qoriq.o

> Would it be possible to
> verify that the following patch makes the warning go away?

With the patch applied, the warnings are still there:

wfg@inn ~/linux/obj-compiletest% make ARCH=openrisc drivers/ata/ahci_qoriq.o
/usr/bin/make -C source O=/home/wfg/linux/obj-compiletest ARCH=openrisc 
CROSS_COMPILE=/usr/local/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux- -j32 
ARCH=openrisc drivers/
ata/ahci_qoriq.o

make: Entering directory '/c/wfg/linux'
make[1]: Entering directory '/c/wfg/linux/obj-compiletest'
  CHK include/config/kernel.release
  GEN ./Makefile
  CHK include/generated/uapi/linux/version.h
  UPD include/config/kernel.release
  Using .. as source for kernel
  CHK include/generated/utsrelease.h
  UPD include/generated/utsrelease.h
  CHK include/generated/timeconst.h
  CHK include/generated/bounds.h
  CHK include/generated/asm-offsets.h
  CALL../scripts/checksyscalls.sh
:1298:2: warning: #warning syscall userfaultfd not implemented
  CC  drivers/ata/ahci_qoriq.o
../drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
../drivers/ata/ahci_qoriq.c:70:6: warning: 'px_cmd' may be used uninitialized 
in this function
../drivers/ata/ahci_qoriq.c:70:14: warning: 'px_is' may be used uninitialized 
in this function
make[1]: Leaving directory '/c/wfg/linux/obj-compiletest'
make: Leaving directory '/c/wfg/linux'

Thanks,
Fengguang

> On Thu, Sep 10, 2015 at 03:13:32PM +0800, yuantian.t...@freescale.com wrote:
> > From: Tang Yuantian 
> > 
> > kbuild test robot reports the warnings:
> > drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
> > >> include/asm-generic/io.h:163:2: warning: 'px_is' may be used
> > >> uninitialized in this function [-Wuninitialized]
> > drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here
> > >> include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used
> > >> uninitialized in this function [-Wuninitialized]
> > drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here
> > 
> > This patch fixed it by making type as a local variable.
> > 
> > Signed-off-by: Tang Yuantian 
> > ---
> > v2:
> > - try another way to fix the warnings
> > - remove clean up code
> > 
> >  drivers/ata/ahci_qoriq.c | 13 ++---
> >  1 file changed, 6 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
> > index e5e4988..0d06e76 100644
> > --- a/drivers/ata/ahci_qoriq.c
> > +++ b/drivers/ata/ahci_qoriq.c
> > @@ -48,9 +48,9 @@ enum ahci_qoriq_type {
> > AHCI_LS2085A,
> >  };
> >  
> > +enum ahci_qoriq_type type;
> >  struct ahci_qoriq_priv {
> > struct ccsr_ahci *reg_base;
> > -   enum ahci_qoriq_type type;
> > void __iomem *ecc_addr;
> >  };
> >  
> > @@ -71,7 +71,6 @@ static int ahci_qoriq_hardreset(struct ata_link *link, 
> > unsigned int *class,
> > struct ata_port *ap = link->ap;
> > struct ahci_port_priv *pp = ap->private_data;
> > struct ahci_host_priv *hpriv = ap->host->private_data;
> > -   struct ahci_qoriq_priv *qoriq_priv = hpriv->plat_data;
> > u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
> > struct ata_taskfile tf;
> > bool online;
> > @@ -92,7 +91,7 @@ static int ahci_qoriq_hardreset(struct ata_link *link, 
> > unsigned int *class,
> >  * After the sequence is complete, software should restore the
> >  * PxCMD and PxIS with the stored values.
> >  */
> > -   if (qoriq_priv->type == AHCI_LS1021A) {
> > +   if (type == AHCI_LS1021A) {
> > px_cmd = readl(port_mmio + PORT_CMD);
> > px_is = readl(port_mmio + PORT_IRQ_STAT);
> > }
> > @@ -106,7 +105,7 @@ static int ahci_qoriq_hardreset(struct ata_link *link, 
> > unsigned int *class,
> >  ahci_check_ready);
> >  
> > /* restore the PxCMD and PxIS on ls1021 */
> > -   if (qoriq_priv->type == AHCI_LS1021A) {
> > +   if (type == AHCI_LS1021A) {
> > px_val = readl(port_mmio + PORT_CMD);
> > if (px_val != px_cmd)
> >

Re: [PATCH v2] Input: edt-ft5x06 - Switch to newer gpio framework

2015-09-10 Thread Franklin S Cooper Jr.
ping

On 08/31/2015 06:25 PM, Franklin S Cooper Jr wrote:
> The current/old gpio framework used doesn't properly listen to
> ACTIVE_LOW and ACTIVE_HIGH flags. The newer gpio framework takes into
> account these flags when setting gpio values.
>
> Since the values being outputed were base on voltage and not logic the
> values being outputted must change to refect this difference. Also use
> gpiod_set_value_cansleep since wake and reset pins can be provided by
> bus based io expanders.
>
> Switch from msleep(5) to udelay_range(5000,6000) to avoid check patch
> warning.
>
> Signed-off-by: Franklin S Cooper Jr 
> ---
> Version 2 changes:
>
> Change output value to properly reflect logic low and logic high signals of
> /RST and WAKE.
>
> Use usleep_range instead of msleep since it is not precise below 20 ms and
> also generates a checkpatch error.
>
> Remove edt_ft5x06_ts_reset since it really serves no purpose especially since
> there are no failure error codes to return using the new gpio apis.
>
>  .../bindings/input/touchscreen/edt-ft5x06.txt  |   4 +-
>  drivers/input/touchscreen/edt-ft5x06.c | 132 
> +++--
>  include/linux/input/edt-ft5x06.h   |   4 +-
>  3 files changed, 47 insertions(+), 93 deletions(-)
>
> diff --git 
> a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> index 76db967..9330d4d 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> @@ -50,6 +50,6 @@ Example:
>   pinctrl-0 = <_ft5x06_pins>;
>   interrupt-parent = <>;
>   interrupts = <5 0>;
> - reset-gpios = < 6 1>;
> - wake-gpios = < 9 0>;
> + reset-gpios = < 6 GPIO_ACTIVE_LOW>;
> + wake-gpios = < 9 GPIO_ACTIVE_HIGH>;
>   };
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> b/drivers/input/touchscreen/edt-ft5x06.c
> index 394b1de..d64d29a 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -91,9 +91,9 @@ struct edt_ft5x06_ts_data {
>   u16 num_x;
>   u16 num_y;
>  
> - int reset_pin;
> - int irq_pin;
> - int wake_pin;
> + struct gpio_desc *reset_pin;
> + struct gpio_desc *wake_pin;
> + struct gpio_desc *irq_pin;
>  
>  #if defined(CONFIG_DEBUG_FS)
>   struct dentry *debug_dir;
> @@ -752,45 +752,6 @@ edt_ft5x06_ts_teardown_debugfs(struct edt_ft5x06_ts_data 
> *tsdata)
>  
>  #endif /* CONFIG_DEBUGFS */
>  
> -static int edt_ft5x06_ts_reset(struct i2c_client *client,
> - struct edt_ft5x06_ts_data *tsdata)
> -{
> - int error;
> -
> - if (gpio_is_valid(tsdata->wake_pin)) {
> - error = devm_gpio_request_one(>dev,
> - tsdata->wake_pin, GPIOF_OUT_INIT_LOW,
> - "edt-ft5x06 wake");
> - if (error) {
> - dev_err(>dev,
> - "Failed to request GPIO %d as wake pin, error 
> %d\n",
> - tsdata->wake_pin, error);
> - return error;
> - }
> -
> - msleep(5);
> - gpio_set_value(tsdata->wake_pin, 1);
> - }
> - if (gpio_is_valid(tsdata->reset_pin)) {
> - /* this pulls reset down, enabling the low active reset */
> - error = devm_gpio_request_one(>dev,
> - tsdata->reset_pin, GPIOF_OUT_INIT_LOW,
> - "edt-ft5x06 reset");
> - if (error) {
> - dev_err(>dev,
> - "Failed to request GPIO %d as reset pin, error 
> %d\n",
> - tsdata->reset_pin, error);
> - return error;
> - }
> -
> - msleep(5);
> - gpio_set_value(tsdata->reset_pin, 1);
> - msleep(300);
> - }
> -
> - return 0;
> -}
> -
>  static int edt_ft5x06_ts_identify(struct i2c_client *client,
>   struct edt_ft5x06_ts_data *tsdata,
>   char *fw_version)
> @@ -931,30 +892,6 @@ edt_ft5x06_ts_set_regs(struct edt_ft5x06_ts_data *tsdata)
>   }
>  }
>  
> -#ifdef CONFIG_OF
> -static int edt_ft5x06_i2c_ts_probe_dt(struct device *dev,
> - struct edt_ft5x06_ts_data *tsdata)
> -{
> - struct device_node *np = dev->of_node;
> -
> - /*
> -  * irq_pin is not needed for DT setup.
> -  * irq is associated via 'interrupts' property in DT
> -  */
> - tsdata->irq_pin = -EINVAL;
> - tsdata->reset_pin = of_get_named_gpio(np, "reset-gpios", 0);
> - tsdata->wake_pin = of_get_named_gpio(np, "wake-gpios", 0);
> -
> - return 0;
> -}
> -#else
> -static inline int 

[PATCH] cpufreq: imx: update the clock swith flow to support imx6ul

2015-09-10 Thread Bai Ping
For I.MX6UL, the clock change flow is slightly different from
other I.MX6 SOCs. It has a 'secondary_sel' clk that will be used
when the CPU freq is higher than 396MHz. So the clock change flow in
'set_target' callback need to update to support i.MX6UL in the common
I.MX6 SOC cpufreq driver.

Signed-off-by: Bai Ping 
---
 drivers/cpufreq/imx6q-cpufreq.c | 48 -
 1 file changed, 43 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 380a90d..2431b6d 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -30,6 +30,10 @@ static struct clk *pll1_sw_clk;
 static struct clk *step_clk;
 static struct clk *pll2_pfd2_396m_clk;
 
+/* clk used by i.MX6UL */
+static struct clk *pll2_bus_clk;
+static struct clk *secondary_sel_clk;
+
 static struct device *cpu_dev;
 static bool free_opp;
 static struct cpufreq_frequency_table *freq_table;
@@ -91,16 +95,36 @@ static int imx6q_set_target(struct cpufreq_policy *policy, 
unsigned int index)
 * The setpoints are selected per PLL/PDF frequencies, so we need to
 * reprogram PLL for frequency scaling.  The procedure of reprogramming
 * PLL1 is as below.
-*
+* For i.MX6UL, it has a secondary clk mux, the cpu frequency change
+* flow is slightly different from other i.MX6 OSC.
+* The cpu frequeny change flow for i.MX6(except i.MX6UL) is as below:
 *  - Enable pll2_pfd2_396m_clk and reparent pll1_sw_clk to it
 *  - Reprogram pll1_sys_clk and reparent pll1_sw_clk back to it
 *  - Disable pll2_pfd2_396m_clk
 */
-   clk_set_parent(step_clk, pll2_pfd2_396m_clk);
-   clk_set_parent(pll1_sw_clk, step_clk);
-   if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk)) {
-   clk_set_rate(pll1_sys_clk, new_freq * 1000);
+   if (of_machine_is_compatible("fsl,imx6ul")) {
+   /*
+* When changing pll1_sw_clk's parent to pll1_sys_clk,
+* CPU may run at higher than 528MHz, this will lead to
+* the system unstable if the voltage is lower than the
+* voltage of 528MHz, so lower the CPU frequency to one
+* half before changing CPU frequency.
+*/
+   clk_set_rate(arm_clk, (old_freq >> 1) * 1000);
clk_set_parent(pll1_sw_clk, pll1_sys_clk);
+   if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk))
+   clk_set_parent(secondary_sel_clk, pll2_bus_clk);
+   else
+   clk_set_parent(secondary_sel_clk, pll2_pfd2_396m_clk);
+   clk_set_parent(step_clk, secondary_sel_clk);
+   clk_set_parent(pll1_sw_clk, step_clk);
+   } else {
+   clk_set_parent(step_clk, pll2_pfd2_396m_clk);
+   clk_set_parent(pll1_sw_clk, step_clk);
+   if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk)) {
+   clk_set_rate(pll1_sys_clk, new_freq * 1000);
+   clk_set_parent(pll1_sw_clk, pll1_sys_clk);
+   }
}
 
/* Ensure the arm clock divider is what we expect */
@@ -186,6 +210,16 @@ static int imx6q_cpufreq_probe(struct platform_device 
*pdev)
goto put_clk;
}
 
+   if (of_machine_is_compatible("fsl,imx6ul")) {
+   pll2_bus_clk = clk_get(cpu_dev, "pll2_bus");
+   secondary_sel_clk = clk_get(cpu_dev, "secondary_sel");
+   if (IS_ERR(pll2_bus_clk) || IS_ERR(secondary_sel_clk)) {
+   dev_err(cpu_dev, "failed to get clocks specific to 
imx6ul\n");
+   ret = -ENOENT;
+   goto put_clk;
+   }
+   }
+
arm_reg = regulator_get(cpu_dev, "arm");
pu_reg = regulator_get_optional(cpu_dev, "pu");
soc_reg = regulator_get(cpu_dev, "soc");
@@ -331,6 +365,10 @@ put_clk:
clk_put(step_clk);
if (!IS_ERR(pll2_pfd2_396m_clk))
clk_put(pll2_pfd2_396m_clk);
+   if (!IS_ERR(pll2_bus_clk))
+   clk_put(pll2_bus_clk);
+   if (!IS_ERR(secondary_sel_clk))
+   clk_put(secondary_sel_clk);
of_node_put(np);
return ret;
 }
-- 
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 V4 2/4] kvm: fix double free for fast mmio eventfd

2015-09-10 Thread Jason Wang
We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS
and another is KVM_FAST_MMIO_BUS but with a single iodev
instance. This will lead an issue: kvm_io_bus_destroy() knows nothing
about the devices on two buses points to a single dev. Which will lead
double free[1] during exit. Fixing this by using allocate two
instances of iodevs then register one on KVM_MMIO_BUS and another on
KVM_FAST_MMIO_BUS.

CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic #28-Ubuntu
Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013
task: 88009ae0c4b0 ti: 88020e7f task.ti: 88020e7f
RIP: 0010:[]  [] 
ioeventfd_release+0x28/0x60 [kvm]
RSP: 0018:88020e7f3bc8  EFLAGS: 00010292
RAX: dead00200200 RBX: 8801ec19c900 RCX: 00018200016d
RDX: 8801ec19cf80 RSI: ea0008bf1d40 RDI: 8801ec19c900
RBP: 88020e7f3bd8 R08: 2fc75a01 R09: 00018200016d
R10: c07df6ae R11: 88022fc75a98 R12: 88021e7cc000
R13: 88021e7cca48 R14: 88021e7cca50 R15: 8801ec19c880
FS:  7fc1ee3e6700() GS:88023e24() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f8f389d8000 CR3: 00023dc13000 CR4: 001427e0
Stack:
88021e7cc000  88020e7f3be8 c07e2622
88020e7f3c38 c07df69a 880232524160 88020e792d80
  880219b78c00 0008 8802321686a8
Call Trace:
[] ioeventfd_destructor+0x12/0x20 [kvm]
[] kvm_put_kvm+0xca/0x210 [kvm]
[] kvm_vcpu_release+0x18/0x20 [kvm]
[] __fput+0xe7/0x250
[] fput+0xe/0x10
[] task_work_run+0xd4/0xf0
[] do_exit+0x368/0xa50
[] ? recalc_sigpending+0x1f/0x60
[] do_group_exit+0x45/0xb0
[] get_signal+0x291/0x750
[] do_signal+0x28/0xab0
[] ? do_futex+0xdb/0x5d0
[] ? __wake_up_locked_key+0x18/0x20
[] ? SyS_futex+0x76/0x170
[] do_notify_resume+0x69/0xb0
[] int_signal+0x12/0x17
Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f 20 
e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48 b8 00 01 
10 00 00
 RIP  [] ioeventfd_release+0x28/0x60 [kvm]
 RSP 

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
 virt/kvm/eventfd.c | 111 -
 1 file changed, 59 insertions(+), 52 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 163258d..1a023ac 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -817,16 +817,6 @@ static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
if (ret < 0)
goto unlock_fail;
 
-   /* When length is ignored, MMIO is also put on a separate bus, for
-* faster lookups.
-*/
-   if (!args->len && !(args->flags & KVM_IOEVENTFD_FLAG_PIO)) {
-   ret = kvm_io_bus_register_dev(kvm, KVM_FAST_MMIO_BUS,
- p->addr, 0, >dev);
-   if (ret < 0)
-   goto register_fail;
-   }
-
kvm->buses[bus_idx]->ioeventfd_count++;
list_add_tail(>list, >ioeventfds);
 
@@ -834,8 +824,6 @@ static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
 
return 0;
 
-register_fail:
-   kvm_io_bus_unregister_dev(kvm, bus_idx, >dev);
 unlock_fail:
mutex_unlock(>slots_lock);
 
@@ -847,41 +835,6 @@ fail:
 }
 
 static int
-kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
-{
-   enum kvm_bus  bus_idx;
-
-   bus_idx = ioeventfd_bus_from_flags(args->flags);
-   /* must be natural-word sized, or 0 to ignore length */
-   switch (args->len) {
-   case 0:
-   case 1:
-   case 2:
-   case 4:
-   case 8:
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   /* check for range overflow */
-   if (args->addr + args->len < args->addr)
-   return -EINVAL;
-
-   /* check for extra flags that we don't understand */
-   if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
-   return -EINVAL;
-
-   /* ioeventfd with no length can't be combined with DATAMATCH */
-   if (!args->len &&
-   args->flags & (KVM_IOEVENTFD_FLAG_PIO |
-  KVM_IOEVENTFD_FLAG_DATAMATCH))
-   return -EINVAL;
-
-   return kvm_assign_ioeventfd_idx(kvm, bus_idx, args);
-}
-
-static int
 kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus bus_idx,
   struct kvm_ioeventfd *args)
 {
@@ -909,10 +862,6 @@ kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus 
bus_idx,
continue;
 
kvm_io_bus_unregister_dev(kvm, bus_idx, >dev);
-   if (!p->length) {
-   kvm_io_bus_unregister_dev(kvm, KVM_FAST_MMIO_BUS,
- >dev);
-   }
kvm->buses[bus_idx]->ioeventfd_count--;

[PATCH V4 4/4] kvm: add tracepoint for fast mmio

2015-09-10 Thread Jason Wang
Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
---
 arch/x86/kvm/trace.h | 18 ++
 arch/x86/kvm/vmx.c   |  1 +
 arch/x86/kvm/x86.c   |  1 +
 3 files changed, 20 insertions(+)

diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 4eae7c3..ce4abe3 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -129,6 +129,24 @@ TRACE_EVENT(kvm_pio,
 );
 
 /*
+ * Tracepoint for fast mmio.
+ */
+TRACE_EVENT(kvm_fast_mmio,
+   TP_PROTO(u64 gpa),
+   TP_ARGS(gpa),
+
+   TP_STRUCT__entry(
+   __field(u64,gpa)
+   ),
+
+   TP_fast_assign(
+   __entry->gpa= gpa;
+   ),
+
+   TP_printk("fast mmio at gpa 0x%llx", __entry->gpa)
+);
+
+/*
  * Tracepoint for cpuid.
  */
 TRACE_EVENT(kvm_cpuid,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4a4eec30..cb505b9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5767,6 +5767,7 @@ static int handle_ept_misconfig(struct kvm_vcpu *vcpu)
gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS);
if (!kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) {
skip_emulated_instruction(vcpu);
+   trace_kvm_fast_mmio(gpa);
return 1;
}
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1e7e76e..f7c4042 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8013,6 +8013,7 @@ bool kvm_arch_has_noncoherent_dma(struct kvm *kvm)
 EXPORT_SYMBOL_GPL(kvm_arch_has_noncoherent_dma);
 
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_exit);
+EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_fast_mmio);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_msr);
-- 
2.1.4

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


[PATCH V4 0/4] Fast MMIO eventfd fixes

2015-09-10 Thread Jason Wang
Hi:

This series fixes two issues of fast mmio eventfd:

1) A single iodev instance were registerd on two buses: KVM_MMIO_BUS
   and KVM_FAST_MMIO_BUS. This will cause double in
   ioeventfd_destructor()
2) A zero length iodev on KVM_MMIO_BUS will never be found but
   kvm_io_bus_cmp(). This will lead e.g the eventfd will be trapped by
   qemu instead of host.

1 is fixed by allocating two instances of iodev. 2 is fixed by ignore
the actual length if the length of iodev is zero in kvm_io_bus_cmp().

Please review.

Changes from V3:

- Don't do search on two buses when trying to do write on
  KVM_MMIO_BUS. This fixes a small regression found by vmexit.flat.
- Since we don't do search on two buses, change kvm_io_bus_cmp() to
  let it can find zero length iodevs.
- Fix the unnecessary lines in tracepoint patch.

Changes from V2:
- Tweak styles and comment suggested by Cornelia.

Changes from v1:
- change ioeventfd_bus_from_flags() to return KVM_FAST_MMIO_BUS when
  needed to save lots of unnecessary changes.

Jason Wang (4):
  kvm: factor out core eventfd assign/deassign logic
  kvm: fix double free for fast mmio eventfd
  kvm: fix zero length mmio searching
  kvm: add tracepoint for fast mmio

 arch/x86/kvm/trace.h |  18 
 arch/x86/kvm/vmx.c   |   1 +
 arch/x86/kvm/x86.c   |   1 +
 virt/kvm/eventfd.c   | 124 ++-
 virt/kvm/kvm_main.c  |   4 +-
 5 files changed, 96 insertions(+), 52 deletions(-)

-- 
2.1.4

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


[PATCH V4 1/4] kvm: factor out core eventfd assign/deassign logic

2015-09-10 Thread Jason Wang
This patch factors out core eventfd assign/deassign logic and leave
the argument checking and bus index selection to callers.

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
---
 virt/kvm/eventfd.c | 83 --
 1 file changed, 49 insertions(+), 34 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 9ff4193..163258d 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -771,40 +771,14 @@ static enum kvm_bus ioeventfd_bus_from_flags(__u32 flags)
return KVM_MMIO_BUS;
 }
 
-static int
-kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
+static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
+   enum kvm_bus bus_idx,
+   struct kvm_ioeventfd *args)
 {
-   enum kvm_bus  bus_idx;
-   struct _ioeventfd*p;
-   struct eventfd_ctx   *eventfd;
-   int   ret;
-
-   bus_idx = ioeventfd_bus_from_flags(args->flags);
-   /* must be natural-word sized, or 0 to ignore length */
-   switch (args->len) {
-   case 0:
-   case 1:
-   case 2:
-   case 4:
-   case 8:
-   break;
-   default:
-   return -EINVAL;
-   }
 
-   /* check for range overflow */
-   if (args->addr + args->len < args->addr)
-   return -EINVAL;
-
-   /* check for extra flags that we don't understand */
-   if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
-   return -EINVAL;
-
-   /* ioeventfd with no length can't be combined with DATAMATCH */
-   if (!args->len &&
-   args->flags & (KVM_IOEVENTFD_FLAG_PIO |
-  KVM_IOEVENTFD_FLAG_DATAMATCH))
-   return -EINVAL;
+   struct eventfd_ctx *eventfd;
+   struct _ioeventfd *p;
+   int ret;
 
eventfd = eventfd_ctx_fdget(args->fd);
if (IS_ERR(eventfd))
@@ -873,14 +847,48 @@ fail:
 }
 
 static int
-kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
+kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
 {
enum kvm_bus  bus_idx;
+
+   bus_idx = ioeventfd_bus_from_flags(args->flags);
+   /* must be natural-word sized, or 0 to ignore length */
+   switch (args->len) {
+   case 0:
+   case 1:
+   case 2:
+   case 4:
+   case 8:
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   /* check for range overflow */
+   if (args->addr + args->len < args->addr)
+   return -EINVAL;
+
+   /* check for extra flags that we don't understand */
+   if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
+   return -EINVAL;
+
+   /* ioeventfd with no length can't be combined with DATAMATCH */
+   if (!args->len &&
+   args->flags & (KVM_IOEVENTFD_FLAG_PIO |
+  KVM_IOEVENTFD_FLAG_DATAMATCH))
+   return -EINVAL;
+
+   return kvm_assign_ioeventfd_idx(kvm, bus_idx, args);
+}
+
+static int
+kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus bus_idx,
+  struct kvm_ioeventfd *args)
+{
struct _ioeventfd*p, *tmp;
struct eventfd_ctx   *eventfd;
int   ret = -ENOENT;
 
-   bus_idx = ioeventfd_bus_from_flags(args->flags);
eventfd = eventfd_ctx_fdget(args->fd);
if (IS_ERR(eventfd))
return PTR_ERR(eventfd);
@@ -918,6 +926,13 @@ kvm_deassign_ioeventfd(struct kvm *kvm, struct 
kvm_ioeventfd *args)
return ret;
 }
 
+static int kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
+{
+   enum kvm_bus bus_idx = ioeventfd_bus_from_flags(args->flags);
+
+   return kvm_deassign_ioeventfd_idx(kvm, bus_idx, args);
+}
+
 int
 kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
 {
-- 
2.1.4

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


[PATCH V4 3/4] kvm: fix zero length mmio searching

2015-09-10 Thread Jason Wang
Currently, if we had a zero length mmio eventfd assigned on
KVM_MMIO_BUS. It will never found by kvm_io_bus_cmp() since it always
compare the kvm_io_range() with the length that guest wrote. This will
lead e.g for vhost, kick will be trapped by qemu userspace instead of
vhost. Fixing this by using zero length if an iodevice is zero length.

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
---
 virt/kvm/kvm_main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d8db2f8f..d4c3b66 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3071,9 +3071,11 @@ static void kvm_io_bus_destroy(struct kvm_io_bus *bus)
 static inline int kvm_io_bus_cmp(const struct kvm_io_range *r1,
 const struct kvm_io_range *r2)
 {
+   int len = r2->len ? r1->len : 0;
+
if (r1->addr < r2->addr)
return -1;
-   if (r1->addr + r1->len > r2->addr + r2->len)
+   if (r1->addr + len > r2->addr + r2->len)
return 1;
return 0;
 }
-- 
2.1.4

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


[PATCH] fix incorrect initialization code for trans_stat of devfreq

2015-09-10 Thread Xiaolong Ye
Hi,

I met trans_stat abnormal issue while debugging devfreq feature for ddr in 
arm64 system, cat trans_stat 
would get extremely large time value which is unreasonable, I checked the code 
and found it was caused by
incorrect initialization code, time_in_state is initialized by devm_kzalloc and 
wrongly use sizeof(unsigned int)
as argument, but time_in_state which is defined in struct devfreq actually is 
defined as unsigned long, so
it is ok for 32 bit system, but will cause unexpected result in 64 bit system.

Xiaolong Ye (1):
  PM / devfreq: Fix incorrect type issue.

 drivers/devfreq/devfreq.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
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] PM / devfreq: Fix incorrect type issue.

2015-09-10 Thread Xiaolong Ye
time_in_state in struct devfreq is defined as unsigned long, so
devm_kzalloc should use sizeof(unsigned long) as argument instead
of sizeof(unsigned int), otherwise it will cause unexpected result
in 64bit system.

Signed-off-by: Xiaolong Ye 
Signed-off-by: Kevin Liu 
---
 drivers/devfreq/devfreq.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index ca1b362..ac9845a 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -482,7 +482,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
devfreq->profile->max_state *
devfreq->profile->max_state,
GFP_KERNEL);
-   devfreq->time_in_state = devm_kzalloc(dev, sizeof(unsigned int) *
+   devfreq->time_in_state = devm_kzalloc(dev, sizeof(unsigned long) *
devfreq->profile->max_state,
GFP_KERNEL);
devfreq->last_stat_updated = jiffies;
-- 
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 v4 07/13] usb: otg: add OTG core

2015-09-10 Thread Peter Chen
On Thu, Sep 10, 2015 at 05:17:36PM +0300, Roger Quadros wrote:
> On 10/09/15 08:35, Peter Chen wrote:
> > On Wed, Sep 09, 2015 at 01:21:50PM +0300, Roger Quadros wrote:
> >> On 09/09/15 11:45, Peter Chen wrote:
> >>> On Wed, Sep 09, 2015 at 12:33:20PM +0300, Roger Quadros wrote:
>  On 09/09/15 11:13, Peter Chen wrote:
> > On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
> >> On 09/09/15 05:21, Peter Chen wrote:
> >>> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
> 
> 
>  On 08/09/15 11:31, Peter Chen wrote:
> > On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
> >> On 07/09/15 04:23, Peter Chen wrote:
> >>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>  + * This is used by the USB Host stack to register the Host 
>  controller
>  + * to the OTG core. Host controller must not be started by the
>  + * caller as it is left upto the OTG state machine to do so.
>  + *
>  + * Returns: 0 on success, error value otherwise.
>  + */
>  +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int 
>  irqnum,
>  + unsigned long irqflags, struct 
>  otg_hcd_ops *ops)
>  +{
>  +struct usb_otg *otgd;
>  +struct device *hcd_dev = hcd->self.controller;
>  +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>  +
> >>>
> >>> One big problem here is: there are two designs for current (IP) 
> >>> driver
> >>> code, one creates dedicated hcd device as roothub's parent, like 
> >>> dwc3.
> >>> Another one doesn't do this, roothub's parent is core device (or 
> >>> otg device
> >>> in your patch), like chipidea and dwc2.
> >>>
> >>> Then, otg_dev will be glue layer device for chipidea after that.
> >>
> >> OK. Let's add a way for the otg controller driver to provide the 
> >> host and gadget
> >> information to the otg core for such devices like chipidea and 
> >> dwc2.
> >>
> >
> > Roger, not only chipidea and dwc2, I think the musb uses the same
> > hierarchy. If the host, device, and otg share the same register
> > region, host part can't be a platform driver since we don't want
> > to remap the same register region again.
> >
> > So, in the design, we may need to consider both situations, one
> > is otg/host/device has its own register region, and host is a
> > separate platform device (A), the other is three parts share the
> > same register region, there is only one platform driver (B).
> >
> > A:
> >
> > IP core device 
> > |
> > |
> >   |-|-|
> >   gadget   host platform device 
> > |
> > roothub
> >
> > B:
> >
> > IP core device
> > |
> > |
> >   |-|-|
> >   gadget roothub
> > 
> >
> >> This API must be called before the hcd/gadget-driver is added so 
> >> that the otg
> >> core knows it's linked to an OTG controller.
> >>
> >> Any better idea?
> >>
> >
> > A flag stands for this hcd controller is the same with otg 
> > controller
> > can be used, this flag can be stored at struct usb_otg_config.
> 
>  What if there is another architecture like so?
> 
>  C:
>   [Parent]
>  |
>  |
>   |--|--|
>   [OTG core]  [gadget][host]
> 
>  We need a more flexible mechanism to link the gadget and
>  host device to the otg core for non DT case.
> 
>  How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> 
>  e.g.
>  int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, 
>  ..)
> 
>  If otg is NULL it will try DT otg-controller property or parent to
>  get the otg controller.
> >>>
> >>> How usb_otg_register_hcd get struct usb_otg, from where?
> >>
> >> This only works when the parent driver creating the hcd has registered 
> >> the
> >> otg controller too.
> >>
> >
> > 

Re: [PATCH v2 1/1] ARM: dts: sun7i: Enable axp209 driver on olinuxino lime2

2015-09-10 Thread Chen-Yu Tsai
On Fri, Sep 11, 2015 at 2:13 AM, Maxime Ripard
 wrote:
> Hi Oliver,
>
> On Wed, Sep 09, 2015 at 03:26:44PM +0200, Olliver Schinagl wrote:
>> The Olimex OLinuXino Lime2 uses the same AXP209 as was recently
>> introduced this driver for its power regulation.
>>
>> Signed-off-by: Olliver Schinagl 
>> ---
>>  arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 87 
>> +
>>  1 file changed, 31 insertions(+), 56 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts 
>> b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
>> index d5c796c..dd90a1d 100644
>> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
>> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
>> @@ -71,14 +71,6 @@
>>   default-state = "on";
>>   };
>>   };
>> -
>> - reg_axp_ipsout: axp_ipsout {
>> - compatible = "regulator-fixed";
>> - regulator-name = "axp-ipsout";
>> - regulator-min-microvolt = <500>;
>> - regulator-max-microvolt = <500>;
>> - regulator-always-on;
>> - };
>
> Why are you removing that regulator?

This is really just a placeholder, rather than an actual regulator.

>From the bindings:

- -supply: a phandle to the regulator supply node. May be omitted if
  inputs are unregulated, such as using the IPSOUT output
  from the PMIC.


>>  };
>>
>>   {
>> @@ -86,6 +78,10 @@
>>   status = "okay";
>>  };
>>
>> + {
>> + cpu-supply = <_dcdc2>;
>> +};
>> +
>>   {
>>   status = "okay";
>>  };
>> @@ -112,57 +108,9 @@
>>   status = "okay";
>>
>>   axp209: pmic@34 {
>> - compatible = "x-powers,axp209";
>>   reg = <0x34>;
>>   interrupt-parent = <_intc>;
>>   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> -
>> - interrupt-controller;
>> - #interrupt-cells = <1>;
>> -
>> - acin-supply = <_axp_ipsout>;
>> - vin2-supply = <_axp_ipsout>;
>> - vin3-supply = <_axp_ipsout>;
>> - ldo24in-supply = <_axp_ipsout>;
>> - ldo3in-supply = <_axp_ipsout>;
>
> And these supplies?
>
>> - regulators {
>> - vdd_rtc: ldo1 {
>> - regulator-min-microvolt = <130>;
>> - regulator-max-microvolt = <130>;
>> - regulator-always-on;
>> - };
>> -
>> - avcc: ldo2 {
>> - regulator-min-microvolt = <180>;
>> - regulator-max-microvolt = <330>;
>> - regulator-always-on;
>> - };
>> -
>> - vcc_csi0: ldo3 {
>> - regulator-min-microvolt = <70>;
>> - regulator-max-microvolt = <350>;
>> - regulator-always-on;
>> - };
>> -
>> - vcc_csi1: ldo4 {
>> - regulator-min-microvolt = <125>;
>> - regulator-max-microvolt = <330>;
>> - regulator-always-on;
>> - };
>> -
>> - vdd_cpu: dcdc2 {
>> - regulator-min-microvolt = <70>;
>> - regulator-max-microvolt = <2275000>;
>> - regulator-always-on;
>> - };
>> -
>> - vdd_int: dcdc3 {
>> - regulator-min-microvolt = <70>;
>> - regulator-max-microvolt = <350>;
>> - regulator-always-on;
>> - };
>> - };
>>   };
>>  };
>>
>> @@ -243,6 +191,33 @@
>>   status = "okay";
>>  };
>>
>> +#include "axp209.dtsi"
>> +
>> +_dcdc2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <100>;
>> + regulator-max-microvolt = <145>;
>
> This is outside of the operating voltages of the CPU.
>
>> + regulator-name = "vdd-cpu";
>> +};
>> +
>> +_dcdc3 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <100>;
>> + regulator-max-microvolt = <140>;
>> + regulator-name = "vdd-int-dll";
>> +};
>> +
>> +_ldo1 {
>> + regulator-name = "vdd-rtc";
>> +};
>> +
>> +_ldo2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <300>;
>> + regulator-max-microvolt = <300>;
>> + regulator-name = "avcc";
>
> You're changing the boundaries, why?

The old boundaries seem to be from a very old dts, where we were
listing the regulators' supported voltage range, instead of what
the SoC could take.

Olliver you should explain all this in the commit log, probably
starting with something like "update the dts to use axp209.dtsi
, comply with axp20x bindings, and set proper voltage 

[GIT PULL] Thermal management updates for v4.3-rc1

2015-09-10 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for 4.3-rc1 with
top-most commit 5a924a07f882e866f2337bf65048be357956691a:

  Merge branches 'thermal-core' and 'thermal-intel' of .git into next
(2015-09-02 10:08:02 +0800)

on top of commit 64291f7db5bd8150a74ad2036f1037e6a0428df2:

  Linux 4.2 (2015-08-30 11:34:09 -0700)


Specifics:

- use int instead of unsigned long to represent temperature to avoid
bogus overheat detection when negative temperature reported. From:
Sascha Hauer.

- export available thermal governors information to user space via
sysfs. From: Wei Ni.

- introduce new thermal driver for Wildcat Point platform controller
hub, which uses PCH thermal sensor and associated critical and hot trip
points. From: Tushar Dave.

- add suuport for Intel Skylake and Denlow platforms in powerclamp
driver.

- some small cleanups in thermal core.

thanks,
rui


Jacob Pan (1):
  thermal/powerclamp: add cpu id for denlow platform

Ni Wade (1):
  thermal: add available policies sysfs attribute

Radivoje Jovanovic (2):
  thermal/powerclamp: add cpu id for skylake h/s
  thermal/powerclamp: add cpu id for Skylake u/y

Sascha Hauer (5):
  thermal: consistently use int for temperatures
  thermal: trivial: fix typo in comment
  thermal: remove unnecessary call to
thermal_zone_device_set_polling
  thermal: Use IS_ENABLED instead of #ifdef
  thermal: Add comment explaining test for critical temperature

Tushar Dave (1):
  thermal: Add Intel PCH thermal driver

Zhang Rui (1):
  Merge branches 'thermal-core' and 'thermal-intel' of .git into
next

 Documentation/thermal/sysfs-api.txt|   6 +
 drivers/acpi/thermal.c |  12 +-
 drivers/hwmon/lm75.c   |   2 +-
 drivers/hwmon/ntc_thermistor.c |   2 +-
 drivers/hwmon/tmp102.c |   2 +-
 drivers/input/touchscreen/sun4i-ts.c   |   8 +-
 drivers/platform/x86/acerhdf.c |   9 +-
 drivers/platform/x86/intel_mid_thermal.c   |   9 +-
 drivers/power/charger-manager.c|   2 +-
 drivers/power/power_supply_core.c  |   2 +-
 drivers/thermal/Kconfig|   8 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/armada_thermal.c   |   2 +-
 drivers/thermal/db8500_thermal.c   |   7 +-
 drivers/thermal/dove_thermal.c |   2 +-
 drivers/thermal/fair_share.c   |   2 +-
 drivers/thermal/gov_bang_bang.c|   5 +-
 drivers/thermal/hisi_thermal.c |   4 +-
 drivers/thermal/imx_thermal.c  |  27 +-
 drivers/thermal/int340x_thermal/int3400_thermal.c  |   2 +-
 .../thermal/int340x_thermal/int340x_thermal_zone.c |  10 +-
 .../thermal/int340x_thermal/int340x_thermal_zone.h |   8 +-
 .../int340x_thermal/processor_thermal_device.c |   4 +-
 drivers/thermal/intel_pch_thermal.c| 286
+
 drivers/thermal/intel_powerclamp.c |   3 +
 drivers/thermal/intel_quark_dts_thermal.c  |  13 +-
 drivers/thermal/intel_soc_dts_iosf.c   |   8 +-
 drivers/thermal/kirkwood_thermal.c |   2 +-
 drivers/thermal/of-thermal.c   |  14 +-
 drivers/thermal/power_allocator.c  |  16 +-
 drivers/thermal/qcom-spmi-temp-alarm.c |   2 +-
 drivers/thermal/rcar_thermal.c |   7 +-
 drivers/thermal/rockchip_thermal.c |  10 +-
 drivers/thermal/samsung/exynos_tmu.c   |  23 +-
 drivers/thermal/spear_thermal.c|   2 +-
 drivers/thermal/st/st_thermal.c|   5 +-
 drivers/thermal/step_wise.c|   4 +-
 drivers/thermal/tegra_soctherm.c   |   4 +-
 drivers/thermal/thermal_core.c | 109 
 drivers/thermal/thermal_hwmon.c|  10 +-
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  10 +-
 drivers/thermal/x86_pkg_temp_thermal.c |  10 +-
 include/linux/thermal.h|  26 +-
 include/trace/events/thermal_power_allocator.h |   6 +-
 44 files changed, 509 insertions(+), 197 deletions(-)
 create mode 100644 drivers/thermal/intel_pch_thermal.c


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


Re: [PATCH 10/16] Staging: lustre: obdclass: genops.c: Remove explicit NULL comparison

2015-09-10 Thread Joe Perches
On Fri, 2015-09-11 at 07:34 +0530, Shraddha Barke wrote:
> Remove explicit NULL comparison and write it in its simpler form.
> Replacement done with coccinelle:

Hi Shraddha.

If you are going to do these conversions, please
also do the equivalent != NULL conversions:

- e != NULL
+ e

> diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c 
> b/drivers/staging/lustre/lustre/obdclass/genops.c
[]
> @@ -178,9 +178,9 @@ int class_register_type(struct obd_ops *dt_ops, struct 
> md_ops *md_ops,
> - if (type->typ_dt_ops == NULL ||
> - type->typ_md_ops == NULL ||
> - type->typ_name == NULL)
> + if (!type->typ_dt_ops ||
> + !type->typ_md_ops ||
> + !type->typ_name)


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


Re: v2 of seccomp filter c/r patches

2015-09-10 Thread Alexei Starovoitov
On Thu, Sep 10, 2015 at 06:20:57PM -0600, Tycho Andersen wrote:
> Hi all,
> 
> Here is v2 of the seccomp filter c/r set. The patch notes have individual
> changes from the last series, but there are two points not noted:
> 
> * The series still does not allow us to correctly restore state for programs
>   that will use SECCOMP_FILTER_FLAG_TSYNC in the future. Given that we want to
>   keep seccomp_filter's identity, I think something along the lines of another
>   seccomp command like SECCOMP_INHERIT_PARENT is needed (although I'm not sure
>   if this can even be done yet). In addition, we'll need a kcmp command for
>   figuring out if filters are the same, although this too needs to compare
>   seccomp_filter objects, so it's a little screwy. Any thoughts on how to do
>   this nicely are welcome.
> 
> * I've dropped the bpf converter bug from the set and will submit it
>   separately.
> 
> Alexei mentioned that this should go via net-next to minimize cross-tree
> conflicts. Does that make sense here?

Having looked at the set again I already see conflicts in net/core/filter.c
and in linux/bpf.h with things myself and others are working on for net-next.
So I think it makes the most sense to get the whole set via net-next,
since seccomp bits look limited comparing to bpf changes.
Otherwise the merge window will be unpleasant.

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


Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver

2015-09-10 Thread Guenter Roeck

On 09/10/2015 03:29 PM, Jon Masters wrote:

On 08/24/2015 01:01 PM, fu@linaro.org wrote:


+   /*
+* Get the frequency of system counter from the cp15 interface of ARM
+* Generic timer. We don't need to check it, because if it returns "0",
+* system would panic in very early stage.
+*/
+   gwdt->clk = arch_timer_get_cntfrq();


Just thinking out loud...

What happens later if we virtualize this device within KVM/QEMU/Xen and
then live migrate to another system in which the frequency changes?



Thinking about it, this scenario would cause severe trouble. I think clocks
(like I would assume pretty much all other hardware parameters / registers)
need to be virtualized and must not change.

Example: clock is set to 100 kHz on original system, and 400 kHz on new
system. Timeout is set to 30s, and registers are programmed accordingly.
User space sends heartbeats every 15 seconds.

In this scenario, the watchdog would time out after 30/4 = 7.5 seconds
on the new system, or in other words almost immediately.

This would be even worse if the original system had a clock of, say,
10 kHz and the new system would use 400 kHz. This just doesn't work.

Guenter

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


Its me Michela

2015-09-10 Thread Michela Peterson



--
Hello dear,

My name is Michela, i am 26yrs old, i'm a free minded,open hearted 
girl, i like to take life as easy as i could, i'm one of the few that 
still believes in friendship, love, trust and signs, am very much single 
and ready to mingle. was browsing through your page, i like to be your 
friend if you don't mind, i hope you will not take my request for 
granted,feel free to email me,i will appreciate it if you can send me 
some pics to my private email address, i look forward to hear from you 
soon.


Merhaba canım,

İsmim i hala dostluk, sevgi, güven ve işaretler inanır birkaç biriyim, 
ben geldiğince kolay hayat almak ister, ben özgür bir fikirli, açık 
yürekli kızım, 26yrs yaşlıyım, Michela olduğunu çok tek ve karıştırmak 
için hazırım. sayfanıza üzerinden tarama oldu, ben size benim özel bana 
bazı pics gönderebilirsiniz eğer ben bunu takdir edecektir, ben bana 
e-posta çekinmeyin, hafife sen benim isteği almayacağız umuyoruz, 
sakıncası yoksa arkadaşın olmak istiyorum E-posta adresi, sana yakında 
duymak için sabırsızlanıyoruz.



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

2015-09-10 Thread Peter Chen
On Thu, Sep 10, 2015 at 02:57:49PM +, Punnaiah Choudary Kalluri wrote:
> 
> 
> > -Original Message-
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Thursday, September 10, 2015 8:14 PM
> > To: Subbaraya Sundeep Bhatta
> > Cc: Peter Chen; ba...@ti.com; linux-...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Greg Kroah-Hartman
> > (gre...@linuxfoundation.org); kis...@ti.com; Punnaiah Choudary Kalluri
> > Subject: Re: Chipidea ULPI driver
> > 
> > (break your lines at 80-characters)
> > 
> > On Thu, Sep 10, 2015 at 12:44:58PM +, Subbaraya Sundeep Bhatta wrote:
> > > Hi Peter,
> > >
> > > We are using NOP transceiver driver for USB3320 ULPI PHY with ChipIdea
> > > controller.
> > >
> > > Recently we found that one of the boards (zedboard) requires PHY
> > > register access to set VBUS.
> > >
> > > Note that our local driver we had before migrating to ChipIdea driver
> > > calls otg_ulpi_create with flags  ULPI_OTG_DRVVBUS |
> > > ULPI_OTG_DRVVBUS_EXT so that VBUS is enabled at initialization.
> > >
> > > Can you please let me know how to do this with ChipIdea case? I see
> > > the following solutions:
> > >
> > > 1. Write ULPI driver for USB3320 similar to tusb1210.
> > 
> > this
> 
> How about extending the phy-ulpi driver to use it as platform driver?
> So that boards that are using the ulpi compatible phy and driving vbus from 
> the phy
> can use this driver.
> 

Yes, you can improve phy-ulpi driver, and it can not depend on
NOP transceiver driver.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] ebpf: add a way to dump an eBPF program

2015-09-10 Thread Alexei Starovoitov
On Thu, Sep 10, 2015 at 06:21:00PM -0600, Tycho Andersen wrote:
> +static int bpf_prog_dump(union bpf_attr *attr, union bpf_attr __user *uattr)
> +{
> + int ufd = attr->prog_fd;
> + struct fd f = fdget(ufd);
> + struct bpf_prog *prog;
> + int ret = -EINVAL;
> +
> + prog = get_prog(f);
> + if (IS_ERR(prog))
> + return PTR_ERR(prog);
> +
> + /* For now, let's refuse to dump anything that isn't a seccomp program.
> +  * Other program types have support for maps, which our current dump
> +  * code doesn't support.
> +  */
> + if (prog->type != BPF_PROG_TYPE_SECCOMP)
> + goto out;
> +
> + ret = -EFAULT;
> + if (put_user(prog->len, >dump_insn_cnt))
> + goto out;
> +
> + if (put_user((u8) prog->gpl_compatible, >gpl_compatible))
> + goto out;
> +
> + if (attr->dump_insns) {
> + u32 len = prog->len * sizeof(struct bpf_insn);
> +
> + if (copy_to_user(u64_to_ptr(attr->dump_insns),
> +  prog->insns, len) != 0)
> + goto out;
> + }
> +
> + ret = 0;
> +out:
> + return ret;

fdput() is missing in all error paths.

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


[PATCH 2/2] regulator: da9063: Remove unneeded semicolon

2015-09-10 Thread Javier Martinez Canillas
It's clearly a typo error that just creates a null statement so remove it.

Signed-off-by: Javier Martinez Canillas 

---

 drivers/regulator/da9063-regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/da9063-regulator.c 
b/drivers/regulator/da9063-regulator.c
index aed1ad3dc964..536e931eb921 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -698,7 +698,7 @@ static struct da9063_regulators_pdata 
*da9063_parse_regulators_dt(
rdata->initdata = da9063_matches[i].init_data;
 
n++;
-   };
+   }
 
*da9063_reg_matches = da9063_matches;
return pdata;
-- 
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/2] regulator: bcm590xx: Remove unneeded semicolon

2015-09-10 Thread Javier Martinez Canillas
It's clearly a typo error that just creates a null statement so remove it.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/regulator/bcm590xx-regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/bcm590xx-regulator.c 
b/drivers/regulator/bcm590xx-regulator.c
index 628430bdc312..76b01835dcb4 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -244,7 +244,7 @@ static int bcm590xx_get_enable_register(int id)
break;
case BCM590XX_REG_VBUS:
reg = BCM590XX_OTG_CTRL;
-   };
+   }
 
 
return reg;
-- 
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 V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc

2015-09-10 Thread Zhao Qiang
On Fri, 2015-09-11 at 10:15AM -0500, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 11, 2015 10:15 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Thu, 2015-09-10 at 21:09 -0500, Zhao Qiang-B45475 wrote:
> > On Fri, 2015-09-11 at 06:07AM -0500, Wood Scott-B07421 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, September 11, 2015 6:07 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > Li Yang-Leo-R58472; pau...@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Wed, 2015-09-09 at 21:26 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, September 10, 2015 12:38 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > lau...@codeaurora.org; Xie Xiaobo-R63061;
> > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> > > > > > On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > > > > To: Zhao Qiang-B45475
> > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > linuxppc-...@lists.ozlabs.org; lau...@codeaurora.org; Xie
> > > > > > > Xiaobo-R63061; b...@kernel.crashing.org; Li Yang-Leo-R58472;
> > > > > > > pau...@samba.org
> > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > >
> > > > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421
> wrote:
> > > > > > > > > -Original Message-
> > > > > > > > > From: Wood Scott-B07421
> > > > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > > > > To: Zhao Qiang-B45475
> > > > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > > > linuxppc-...@lists.ozlabs.org; lau...@codeaurora.org;
> > > > > > > > > Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> > > > > > > > > Yang-Leo-R58472; pau...@samba.org
> > > > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > > > >
> > > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > > > > Bytes alignment is required to manage some special
> > > > > > > > > > RAM, so add gen_pool_first_fit_align to genalloc,
> > > > > > > > > > meanwhile add gen_pool_alloc_data to pass data to
> > > > > > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a
> > > > > > > > > > wrapper)
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Zhao Qiang 
> > > > > > > > > > ---
> > > > > > > > > > Changes for v6:
> > > > > > > > > >   - patches set v6 include a new patch because of
> using
> > > > > > > > > >   - genalloc to manage QE MURAM, patch 0001 is the
> new
> > > > > > > > > >   - patch, adding bytes alignment for allocation
> > > > > > > > > > for
> > > use.
> > > > > > > > > > Changes for v7:
> > > > > > > > > >   - cpm muram also need to use genalloc to manage,
> > > > > > > > > > it
> > > has
> > > > > > > > > > a function to reserve a specific region of
> muram,
> > > > > > > > > > add offset to genpool_data for start addr to
> > > > > > > > > > be
> > > > > allocated.
> > > > > > > > >
> > > > > > > > > This seems to be describing more than just the changes
> > > > > > > > > in this
> > > > > patch.
> > > > > > > > > What does also handling cpm have to do with this patch?
> > > > > > > > > Are you adding support for reserving a specific region
> > > > > > > > > in this patch?  I don't see it, and in any case it
> > > > > > > > > should go in a
> > > different patch.
> > > > > > > >
> > > > > > > > Yes, I added. The code below can support the function.
> > > > > > > >   offset_bit = (alignment->offset + (1UL << order) -
> > > > > > > > 1) >>
> > > > > order;
> > > > > > > >   return bitmap_find_next_zero_area(map, size, start +
> > > > > > > > offset_bit,
> > > > > > > nr,
> > > > > > > > align_mask);
> > > > > > > >
> > > > > > > 

Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram

2015-09-10 Thread Scott Wood
On Thu, 2015-09-10 at 20:59 -0500, Zhao Qiang-B45475 wrote:
> On Mon, 2015-09-11 at 06:09 -0500, Wood Scott-B07421 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, September 11, 2015 6:09 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> > Yang-Leo-R58472; pau...@samba.org
> > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> > muram
> > 
> > On Wed, 2015-09-09 at 21:34 -0500, Zhao Qiang-B45475 wrote:
> > > On Mon, 2015-09-10 at 12:39 -0500, Wood Scott-B07421 wrote:
> > > 
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, September 10, 2015 12:39 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; pau...@samba.org
> > > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to
> > > > manage muram
> > > > 
> > > > On Sun, 2015-09-06 at 01:37 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Mon, 2015-09-2 at 8:34 +0800, Wood Scott-B07421 wrote:
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 02, 2015 8:34 AM
> > > > > > To: Zhao Qiang-B45475
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061;
> > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org
> > > > > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions
> > > > > > to manage muram
> > > > > > 
> > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > 
> > > > > > > @@ -187,12 +190,25 @@ static inline int
> > > > > > > qe_alive_during_sleep(void)  }
> > > > > > > 
> > > > > > >  /* we actually use cpm_muram implementation, define this for
> > > > > > > convenience */ -#define qe_muram_init cpm_muram_init -#define
> > > > > > > qe_muram_alloc cpm_muram_alloc -#define qe_muram_alloc_fixed
> > > > > > > cpm_muram_alloc_fixed -#define qe_muram_free cpm_muram_free
> > > > > > > -#define qe_muram_addr cpm_muram_addr -#define qe_muram_offset
> > > > > > > cpm_muram_offset
> > > > > > > +#define cpm_muram_init qe_muram_init #define cpm_muram_alloc
> > > > > > > +qe_muram_alloc #define cpm_muram_alloc_fixed
> > > > > > > +qe_muram_alloc_fixed #define cpm_muram_free qe_muram_free
> > > > > > > +#define cpm_muram_addr qe_muram_addr #define cpm_muram_offset
> > > > > > > +qe_muram_offset
> > > > > > 
> > > > > > Why?  This is unnecessary churn.
> > > > > > 
> > > > > This is necessary. QE is on both ARM and PowerPC, its code is
> > > > > under public code.
> > > > > But CPM is only on PowerPC and its code is under PowerPC.
> > > > > So when build ARM, QE will not find cpm_muram_* function.
> > > > 
> > > > If you move the cpm_muram functions to drivers/soc, then ARM will
> > > > find them.
> > > > There is no need to rename them.
> > > 
> > > Yes, moving cpm_muram can handle this issue. However, cpm is not
> > > necessary To move to public code, and a churn is simpler than moving
> > cpm_muram.
> > > Please consider my suggestion, Thank you!
> > 
> > What do you mean by "public code"?  You're already moving cpm_muram.  I'm
> > just asking that you not rename it while you do so.  If it absolutely
> > must be renamed, do it in a different patch from the one that moves the
> > code, though I don't see why the rename is helpful.
> 
> "Public code" is "driver/soc" here. I moved the qe_muram into driver/soc, 
> not cpm_muram,

They are the same thing.

> And the functions are named qe_muram_*, 

Only after you renamed them.  Before that they were just #defined aliases.

> and removed cpm_muram_*, let cpm_muram
> Use the same functions code with qe_muram, and define cpm_muram_* 
> qe_muram_*. 
> 
> Previously, cpm/qe-muram functions are named cpm_muram_* because CPM is the 
> predecessor
> Of QE,

Yes, and just because marketing decided they wanted to change the name when 
they came out with a new version doesn't mean we need to rename 
infrastructure that is common between them.  E.g. we still classify PPC QorIQ 
chips as "mpc85xx".

Again, if you really want to do the rename, at least do it in a separate 
patch from moving the code, so that git will detect the code movement and we 
can see if anything else changed during the move.

-Scott

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


Re: [rcu] kernel BUG at include/linux/pagemap.h:149!

2015-09-10 Thread Boqun Feng
Hi Paul

On Thu, Sep 10, 2015 at 10:16:49AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 10, 2015 at 06:25:13PM +0800, Boqun Feng wrote:
[snip]
> > 
> > Code here is:
> > 
> > #ifdef CONFIG_TINY_RCU
> > # ifdef CONFIG_PREEMPT_COUNT
> > VM_BUG_ON(!in_atomic()); <-- BUG triggered here.
> > # endif
> > ...
> > #endif
> > 
> > This indicates that CONFIG_TINY_RCU and CONFIG_PREEMPT_COUNT are both y.
> > Normally, IIUC, this is not possible or meaningless, because TINY_RCU is
> > for !PREEMPT kernel. However, according to commmit e8f7c70f4 ("sched:
> > Make sleeping inside spinlock detection working in !CONFIG_PREEMPT"),
> > maintaining preempt counts in !PREEMPT kernel makes sense for finding
> > preempt-related bugs.
> 
> Good analysis, thank you!
> 
> > So a possible fix would be still counting preempt_count in
> > rcu_read_lock and rcu_read_unlock if PREEMPT_COUNT is y for debug
> > purpose:
> > 
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 07f9b95..887bf5f 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -297,10 +297,16 @@ void synchronize_rcu(void);
> > 
> >  static inline void __rcu_read_lock(void)
> >  {
> > +#ifdef CONFIG_PREEMPT_COUNT
> > +   preempt_disable();
> > +#endif
> 
> We can save a line as follows:
> 
>   if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
>   preempt_disable();
> 
> This approach also has the advantage of letting the compiler look at
> more of the code, so that compiler errors in strange combinations of
> configurations are less likely to be missed.
> 

Good idea, plus better readability IMO.


> >  }
> > 
> >  static inline void __rcu_read_unlock(void)
> >  {
> > +#ifdef CONFIG_PREEMPT_COUNT
> > +   preempt_enable();
> > +#endif
> >  }
> > 
> > I did a simple booting test with the some configuration on a guest on
> > x86, didn't see this error again.
> > 
> > (Also add Frederic Weisbecker to CCed)
> 
> Would you like to send me a replacement patch?
> 

Not sure I'm handling the Signed-off-by right.., but here it is:

(The rest on dev.2015.09.01a branch can be applied on this cleanly, and
I did a simple booting test with the same configuration on a guest on
x86, didn't see the reported error again)


--->8
Subject: [PATCH 01/27] rcu: Don't disable preemption for Tiny and Tree RCU
 readers

Because preempt_disable() maps to barrier() for non-debug builds,
it forces the compiler to spill and reload registers.  Because Tree
RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
barrier() instances generate needless extra code for each instance of
rcu_read_lock() and rcu_read_unlock().  This extra code slows down Tree
RCU and bloats Tiny RCU.

This commit therefore removes the preempt_disable() and preempt_enable()
from the non-preemptible implementations of __rcu_read_lock() and
__rcu_read_unlock(), respectively.

For debug purposes, preempt_disable() and preempt_enable() are still
kept if CONFIG_PREEMPT_COUNT=y, which makes the detection of sleeping
inside atomic sections still work in non-preemptible kernels.

Signed-off-by: Boqun Feng 
Signed-off-by: Paul E. McKenney 
---
 include/linux/rcupdate.h | 6 --
 include/linux/rcutiny.h  | 1 +
 kernel/rcu/tree.c| 9 +
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index d63bb77..6c3cece 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -297,12 +297,14 @@ void synchronize_rcu(void);
 
 static inline void __rcu_read_lock(void)
 {
-   preempt_disable();
+   if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
+   preempt_disable();
 }
 
 static inline void __rcu_read_unlock(void)
 {
-   preempt_enable();
+   if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
+   preempt_enable();
 }
 
 static inline void synchronize_rcu(void)
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index c8a0722..4c1aaf9 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -216,6 +216,7 @@ static inline bool rcu_is_watching(void)
 
 static inline void rcu_all_qs(void)
 {
+   barrier(); /* Avoid RCU read-side critical sections leaking across. */
 }
 
 #endif /* __LINUX_RCUTINY_H */
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index ce43fac..b4882f8 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -337,12 +337,14 @@ static void rcu_momentary_dyntick_idle(void)
  */
 void rcu_note_context_switch(void)
 {
+   barrier(); /* Avoid RCU read-side critical sections leaking down. */
trace_rcu_utilization(TPS("Start context switch"));
rcu_sched_qs();
rcu_preempt_note_context_switch();
if (unlikely(raw_cpu_read(rcu_sched_qs_mask)))
rcu_momentary_dyntick_idle();
trace_rcu_utilization(TPS("End context switch"));
+   barrier(); /* Avoid RCU read-side critical sections leaking up. */
 }
 EXPORT_SYMBOL_GPL(rcu_note_context_switch);
 
@@ 

Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc

2015-09-10 Thread Scott Wood
On Thu, 2015-09-10 at 21:09 -0500, Zhao Qiang-B45475 wrote:
> On Fri, 2015-09-11 at 06:07AM -0500, Wood Scott-B07421 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, September 11, 2015 6:07 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> > Yang-Leo-R58472; pau...@samba.org
> > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > bytes-alignment to genalloc
> > 
> > On Wed, 2015-09-09 at 21:26 -0500, Zhao Qiang-B45475 wrote:
> > > On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, September 10, 2015 12:38 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; pau...@samba.org
> > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > > bytes-alignment to genalloc
> > > > 
> > > > On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > > > To: Zhao Qiang-B45475
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061;
> > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org
> > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > > with bytes-alignment to genalloc
> > > > > > 
> > > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: Wood Scott-B07421
> > > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > > > To: Zhao Qiang-B45475
> > > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > > linuxppc-...@lists.ozlabs.org; lau...@codeaurora.org; Xie
> > > > > > > > Xiaobo-R63061; b...@kernel.crashing.org; Li Yang-Leo-R58472;
> > > > > > > > pau...@samba.org
> > > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > > > 
> > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > > > Bytes alignment is required to manage some special RAM, so
> > > > > > > > > add gen_pool_first_fit_align to genalloc, meanwhile add
> > > > > > > > > gen_pool_alloc_data to pass data to
> > > > > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a
> > > > > > > > > wrapper)
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Zhao Qiang 
> > > > > > > > > ---
> > > > > > > > > Changes for v6:
> > > > > > > > >   - patches set v6 include a new patch because of using
> > > > > > > > >   - genalloc to manage QE MURAM, patch 0001 is the new
> > > > > > > > >   - patch, adding bytes alignment for allocation for
> > use.
> > > > > > > > > Changes for v7:
> > > > > > > > >   - cpm muram also need to use genalloc to manage, it
> > has
> > > > > > > > > a function to reserve a specific region of muram,
> > > > > > > > > add offset to genpool_data for start addr to be
> > > > allocated.
> > > > > > > > 
> > > > > > > > This seems to be describing more than just the changes in
> > > > > > > > this
> > > > patch.
> > > > > > > > What does also handling cpm have to do with this patch?  Are
> > > > > > > > you adding support for reserving a specific region in this
> > > > > > > > patch?  I don't see it, and in any case it should go in a
> > different patch.
> > > > > > > 
> > > > > > > Yes, I added. The code below can support the function.
> > > > > > >   offset_bit = (alignment->offset + (1UL << order) - 1) >>
> > > > order;
> > > > > > >   return bitmap_find_next_zero_area(map, size, start +
> > > > > > > offset_bit,
> > > > > > nr,
> > > > > > > align_mask);
> > > > > > > 
> > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > > > > muram from a Specific offset. So I add the code and add offset
> > > > > > > to
> > > > struct data.
> > > > > > 
> > > > > > I thought the offset was related to the previous discussion of
> > > > > > checking for allocation failure.  Are you using it to implement
> > > > > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > > > > implementation (what does it logically have to do with
> > > > > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > > > > - what happens with multiple chunks?  What happens if part of
> > > > > > the region the caller is trying to reserve is already taken?
> > > > > > Implement a proper function 

[PATCH 06/16] Staging: rtl8188eu: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
index 0a62bfa..d528140 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
@@ -467,7 +467,7 @@ static void SetFwRsvdPagePkt(struct adapter *adapt, bool 
bDLFinished)
 
DBG_88E("%s\n", __func__);
ReservedPagePacket = kzalloc(1000, GFP_KERNEL);
-   if (ReservedPagePacket == NULL) {
+   if (!ReservedPagePacket) {
DBG_88E("%s: alloc ReservedPagePacket fail!\n", __func__);
return;
}
@@ -537,7 +537,7 @@ static void SetFwRsvdPagePkt(struct adapter *adapt, bool 
bDLFinished)
 
TotalPacketLen = BufIndex + QosNullLength;
pmgntframe = alloc_mgtxmitframe(pxmitpriv);
-   if (pmgntframe == NULL)
+   if (!pmgntframe)
goto exit;
 
/*  update attribute */
-- 
2.1.4

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


[PATCH 14/16] Staging: rtl8188eu: os_dep: recv_linux.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/rtl8188eu/os_dep/recv_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/recv_linux.c 
b/drivers/staging/rtl8188eu/os_dep/recv_linux.c
index 3ebb8b2..d4734baf 100644
--- a/drivers/staging/rtl8188eu/os_dep/recv_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/recv_linux.c
@@ -94,7 +94,7 @@ int rtw_recv_indicatepkt(struct adapter *padapter,
pfree_recv_queue = &(precvpriv->free_recv_queue);
 
skb = precv_frame->pkt;
-   if (skb == NULL) {
+   if (!skb) {
RT_TRACE(_module_recv_osdep_c_, _drv_err_,
 ("rtw_recv_indicatepkt():skb == NULL something 
wrong\n"));
goto _recv_indicatepkt_drop;
-- 
2.1.4

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


[PATCH 16/16] Staging: rtl8188eu: os_dep: osdep_service.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/rtl8188eu/os_dep/osdep_service.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/osdep_service.c 
b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
index acb4eb1..466cd76 100644
--- a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
@@ -52,7 +52,7 @@ void *rtw_malloc2d(int h, int w, int size)
int j;
 
void **a = kzalloc(h*sizeof(void *) + h*w*size, GFP_KERNEL);
-   if (a == NULL) {
+   if (!a) {
pr_info("%s: alloc memory fail!\n", __func__);
return NULL;
}
-- 
2.1.4

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


[PATCH 12/16] Staging: rtl8188eu: hal: Hal8188ERateAdaptive.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c 
b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
index 2633a13..a108e80 100644
--- a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
+++ b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
@@ -127,7 +127,7 @@ static int odm_RateDown_8188E(struct odm_dm_struct *dm_odm,
 
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
ODM_DBG_TRACE, ("=>odm_RateDown_8188E()\n"));
-   if (NULL == pRaInfo) {
+   if (!pRaInfo) {
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
("odm_RateDown_8188E(): pRaInfo is NULL\n"));
return -1;
@@ -193,7 +193,7 @@ static int odm_RateUp_8188E(
 
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
ODM_DBG_TRACE, ("=>odm_RateUp_8188E()\n"));
-   if (NULL == pRaInfo) {
+   if (!pRaInfo) {
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
("odm_RateUp_8188E(): pRaInfo is NULL\n"));
return -1;
@@ -624,7 +624,7 @@ int ODM_RAInfo_Init_all(struct odm_dm_struct *dm_odm)
 
 u8 ODM_RA_GetShortGI_8188E(struct odm_dm_struct *dm_odm, u8 macid)
 {
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return 0;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
 ("macid =%d SGI =%d\n", macid, 
dm_odm->RAInfo[macid].RateSGI));
@@ -635,7 +635,7 @@ u8 ODM_RA_GetDecisionRate_8188E(struct odm_dm_struct 
*dm_odm, u8 macid)
 {
u8 DecisionRate = 0;
 
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return 0;
DecisionRate = dm_odm->RAInfo[macid].DecisionRate;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
@@ -647,7 +647,7 @@ u8 ODM_RA_GetHwPwrStatus_8188E(struct odm_dm_struct 
*dm_odm, u8 macid)
 {
u8 PTStage = 5;
 
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return 0;
PTStage = dm_odm->RAInfo[macid].PTStage;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
@@ -659,7 +659,7 @@ void ODM_RA_UpdateRateInfo_8188E(struct odm_dm_struct 
*dm_odm, u8 macid, u8 Rate
 {
struct odm_ra_info *pRaInfo = NULL;
 
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
 ("macid =%d RateID = 0x%x RateMask = 0x%x SGIEnable =%d\n",
@@ -676,7 +676,7 @@ void ODM_RA_SetRSSI_8188E(struct odm_dm_struct *dm_odm, u8 
macid, u8 Rssi)
 {
struct odm_ra_info *pRaInfo = NULL;
 
-   if ((NULL == dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
+   if ((!dm_odm) || (macid >= ASSOCIATE_ENTRY_NUM))
return;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
 (" macid =%d Rssi =%d\n", macid, Rssi));
-- 
2.1.4

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


[PATCH 15/16] Staging: rtl8188eu: os_dep: mlme_linux.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/rtl8188eu/os_dep/mlme_linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/mlme_linux.c 
b/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
index 218adaa..eb8ecb7 100644
--- a/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
@@ -152,7 +152,7 @@ void rtw_indicate_sta_assoc_event(struct adapter *padapter, 
struct sta_info *pst
union iwreq_data wrqu;
struct sta_priv *pstapriv = >stapriv;
 
-   if (psta == NULL)
+   if (!psta)
return;
 
if (psta->aid > NUM_STA)
@@ -176,7 +176,7 @@ void rtw_indicate_sta_disassoc_event(struct adapter 
*padapter, struct sta_info *
union iwreq_data wrqu;
struct sta_priv *pstapriv = >stapriv;
 
-   if (psta == NULL)
+   if (!psta)
return;
 
if (psta->aid > NUM_STA)
-- 
2.1.4

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


RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc

2015-09-10 Thread Zhao Qiang
On Fri, 2015-09-11 at 06:07AM -0500, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 11, 2015 6:07 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Wed, 2015-09-09 at 21:26 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, September 10, 2015 12:38 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > Li Yang-Leo-R58472; pau...@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > lau...@codeaurora.org; Xie Xiaobo-R63061;
> > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > > To: Zhao Qiang-B45475
> > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > linuxppc-...@lists.ozlabs.org; lau...@codeaurora.org; Xie
> > > > > > > Xiaobo-R63061; b...@kernel.crashing.org; Li Yang-Leo-R58472;
> > > > > > > pau...@samba.org
> > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > >
> > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > > Bytes alignment is required to manage some special RAM, so
> > > > > > > > add gen_pool_first_fit_align to genalloc, meanwhile add
> > > > > > > > gen_pool_alloc_data to pass data to
> > > > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a
> > > > > > > > wrapper)
> > > > > > > >
> > > > > > > > Signed-off-by: Zhao Qiang 
> > > > > > > > ---
> > > > > > > > Changes for v6:
> > > > > > > >   - patches set v6 include a new patch because of using
> > > > > > > >   - genalloc to manage QE MURAM, patch 0001 is the new
> > > > > > > >   - patch, adding bytes alignment for allocation for
> use.
> > > > > > > > Changes for v7:
> > > > > > > >   - cpm muram also need to use genalloc to manage, it
> has
> > > > > > > > a function to reserve a specific region of muram,
> > > > > > > > add offset to genpool_data for start addr to be
> > > allocated.
> > > > > > >
> > > > > > > This seems to be describing more than just the changes in
> > > > > > > this
> > > patch.
> > > > > > > What does also handling cpm have to do with this patch?  Are
> > > > > > > you adding support for reserving a specific region in this
> > > > > > > patch?  I don't see it, and in any case it should go in a
> different patch.
> > > > > >
> > > > > > Yes, I added. The code below can support the function.
> > > > > >   offset_bit = (alignment->offset + (1UL << order) - 1) >>
> > > order;
> > > > > >   return bitmap_find_next_zero_area(map, size, start +
> > > > > > offset_bit,
> > > > > nr,
> > > > > > align_mask);
> > > > > >
> > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > > > muram from a Specific offset. So I add the code and add offset
> > > > > > to
> > > struct data.
> > > > >
> > > > > I thought the offset was related to the previous discussion of
> > > > > checking for allocation failure.  Are you using it to implement
> > > > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > > > implementation (what does it logically have to do with
> > > > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > > > - what happens with multiple chunks?  What happens if part of
> > > > > the region the caller is trying to reserve is already taken?
> > > > > Implement a proper function to reserve a fixed genalloc region.
> > > > >
> > > > The offset is which allocation block address need to be larger
> > > > than, Not equal to, it really like the parameter start of the
> > > > algo(the bitnumber To start searching at).
> > >
> > > 

[PATCH 13/16] Staging: rtl8188eu: hal: rtl8188eu_xmit.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c 
b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
index 594c1da..4433560 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
@@ -649,7 +649,7 @@ static s32 pre_xmitframe(struct adapter *adapt, struct 
xmit_frame *pxmitframe)
goto enqueue;
 
pxmitbuf = rtw_alloc_xmitbuf(pxmitpriv);
-   if (pxmitbuf == NULL)
+   if (!pxmitbuf)
goto enqueue;
 
spin_unlock_bh(>lock);
-- 
2.1.4

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


[PATCH 05/16] Staging: rtl8188eu: core: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c 
b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
index b340e4a..497fb06 100644
--- a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
@@ -273,7 +273,7 @@ u32 rtw_free_stainfo(struct adapter *padapter, struct 
sta_info *psta)
struct  sta_priv *pstapriv = >stapriv;
 
 
-   if (psta == NULL)
+   if (!psta)
goto exit;
 
pfree_sta_queue = >free_sta_queue;
@@ -433,7 +433,7 @@ struct sta_info *rtw_get_stainfo(struct sta_priv *pstapriv, 
u8 *hwaddr)
u8 bc_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
 
 
-   if (hwaddr == NULL)
+   if (!hwaddr)
return NULL;
 
if (IS_MCAST(hwaddr))
@@ -473,7 +473,7 @@ u32 rtw_init_bcmc_stainfo(struct adapter *padapter)
 
psta = rtw_alloc_stainfo(pstapriv, bcast_addr);
 
-   if (psta == NULL) {
+   if (!psta) {
res = _FAIL;
RT_TRACE(_module_rtl871x_sta_mgt_c_, _drv_err_, 
("rtw_alloc_stainfo fail"));
goto exit;
-- 
2.1.4

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


[PATCH 11/16] Staging: rtl8188eu: hal: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c 
b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
index 06d1e65..d6d009a 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
@@ -43,7 +43,7 @@ int   rtl8188eu_init_recv_priv(struct adapter *padapter)
 
precvpriv->pallocated_recv_buf =
kcalloc(NR_RECVBUFF, sizeof(struct recv_buf), GFP_KERNEL);
-   if (precvpriv->pallocated_recv_buf == NULL) {
+   if (!precvpriv->pallocated_recv_buf) {
res = _FAIL;
RT_TRACE(_module_rtl871x_recv_c_, _drv_err_,
("alloc recv_buf fail!\n"));
-- 
2.1.4

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


Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver

2015-09-10 Thread Guenter Roeck
On Thu, Sep 10, 2015 at 06:29:53PM -0400, Jon Masters wrote:
> On 08/24/2015 01:01 PM, fu@linaro.org wrote:
> 
> > +   /*
> > +* Get the frequency of system counter from the cp15 interface of ARM
> > +* Generic timer. We don't need to check it, because if it returns "0",
> > +* system would panic in very early stage.
> > +*/
> > +   gwdt->clk = arch_timer_get_cntfrq();
> 
> Just thinking out loud...
> 
> What happens later if we virtualize this device within KVM/QEMU/Xen and
> then live migrate to another system in which the frequency changes?
> 
I don't know, but I would suspect that we might end up in all kinds of
trouble if clocks can change like that, and not just in this driver.
Many drivers make the assumption that clock rates are not changed
under the hood. If it can happen, shouldn't there be a callback into
the drivers using the affected clock(s) ?

Also, it seems to me that changing a clock like that would be inherently
unsafe. For example, what will happen if the system is stopped and migrated
right after the clock frequency is read, but before the returned value
is used ? Can that happen ? Or does it only happen during suspend/resume
cycles, if it happens ?

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


[PATCH] kasan: use IS_ALIGNED in memory_is_poisoned_8()

2015-09-10 Thread Xishi Qiu
Use IS_ALIGNED() to determine whether the shadow span two bytes.
It generates less code and more readable.

Signed-off-by: Xishi Qiu 
---
 mm/kasan/kasan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 7b28e9c..c6ddff1 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -120,7 +120,7 @@ static __always_inline bool memory_is_poisoned_8(unsigned 
long addr)
if (memory_is_poisoned_1(addr + 7))
return true;
 
-   if (likely(((addr + 7) & KASAN_SHADOW_MASK) >= 7))
+   if (likely(IS_ALIGNED(addr, 8)))
return false;
 
return unlikely(*(u8 *)shadow_addr);
-- 
2.0.0


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


[PATCH 09/16] Staging: lustre: obdclass: obd_config.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 .../staging/lustre/lustre/obdclass/obd_config.c| 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/obd_config.c 
b/drivers/staging/lustre/lustre/obdclass/obd_config.c
index e0470c0..fb432e8 100644
--- a/drivers/staging/lustre/lustre/obdclass/obd_config.c
+++ b/drivers/staging/lustre/lustre/obdclass/obd_config.c
@@ -61,7 +61,7 @@ int class_find_param(char *buf, char *key, char **valp)
return 1;
 
ptr = strstr(buf, key);
-   if (ptr == NULL)
+   if (!ptr)
return 1;
 
if (valp)
@@ -92,11 +92,11 @@ struct cfg_interop_param *class_find_old_param(const char 
*param,
char *value = NULL;
int   name_len = 0;
 
-   if (param == NULL || ptr == NULL)
+   if (!param || !ptr)
return NULL;
 
value = strchr(param, '=');
-   if (value == NULL)
+   if (!value)
name_len = strlen(param);
else
name_len = value - param;
@@ -144,7 +144,7 @@ int class_get_next_param(char **params, char *copy)
 
while (1) {
q1 = strpbrk(str, " '\"");
-   if (q1 == NULL) {
+   if (!q1) {
len = strlen(str);
memcpy(copy, str, len);
copy[len] = '\0';
@@ -165,7 +165,7 @@ int class_get_next_param(char **params, char *copy)
/* search for the matching closing quote */
str = q1 + 1;
q2 = strchr(str, *q1);
-   if (q2 == NULL) {
+   if (!q2) {
CERROR("Unbalanced quota in parameters: \"%s\"\n",
   *params);
return -EINVAL;
@@ -243,7 +243,7 @@ static int class_parse_value(char *buf, int opc, void 
*value, char **endh,
 
/* nid separators or end of nids */
endp = strpbrk(buf, ",: /");
-   if (endp == NULL)
+   if (!endp)
endp = buf + strlen(buf);
 
tmp = *endp;
@@ -841,14 +841,14 @@ int class_add_profile(int proflen, char *prof, int 
osclen, char *osc,
 
LASSERT(proflen == (strlen(prof) + 1));
lprof->lp_profile = kmemdup(prof, proflen, GFP_NOFS);
-   if (lprof->lp_profile == NULL) {
+   if (!lprof->lp_profile) {
err = -ENOMEM;
goto free_lprof;
}
 
LASSERT(osclen == (strlen(osc) + 1));
lprof->lp_dt = kmemdup(osc, osclen, GFP_NOFS);
-   if (lprof->lp_dt == NULL) {
+   if (!lprof->lp_dt) {
err = -ENOMEM;
goto free_lp_profile;
}
@@ -856,7 +856,7 @@ int class_add_profile(int proflen, char *prof, int osclen, 
char *osc,
if (mdclen > 0) {
LASSERT(mdclen == (strlen(mdc) + 1));
lprof->lp_md = kmemdup(mdc, mdclen, GFP_NOFS);
-   if (lprof->lp_md == NULL) {
+   if (!lprof->lp_md) {
err = -ENOMEM;
goto free_lp_dt;
}
@@ -963,15 +963,15 @@ struct lustre_cfg *lustre_cfg_rename(struct lustre_cfg 
*cfg,
int  name_len = 0;
int  new_len = 0;
 
-   if (cfg == NULL || new_name == NULL)
+   if (!cfg || !new_name)
return ERR_PTR(-EINVAL);
 
param = lustre_cfg_string(cfg, 1);
-   if (param == NULL)
+   if (!param)
return ERR_PTR(-EINVAL);
 
value = strchr(param, '=');
-   if (value == NULL)
+   if (!value)
name_len = strlen(param);
else
name_len = value - param;
@@ -1000,7 +1000,7 @@ struct lustre_cfg *lustre_cfg_rename(struct lustre_cfg 
*cfg,
 
kfree(new_param);
kfree(bufs);
-   if (new_cfg == NULL)
+   if (!new_cfg)
return ERR_PTR(-ENOMEM);
 
new_cfg->lcfg_num = cfg->lcfg_num;
@@ -1178,7 +1178,7 @@ int class_process_config(struct lustre_cfg *lcfg)
}
/* Commands that require a device */
obd = class_name2obd(lustre_cfg_string(lcfg, 0));
-   if (obd == NULL) {
+   if (!obd) {
if (!LUSTRE_CFG_BUFLEN(lcfg, 0))
CERROR("this lcfg command requires a device name\n");
else
@@ -1481,7 +1481,7 @@ int class_config_llog_handler(const struct lu_env *env,
 * moving them to index [1] and [2], and insert MGC's
 * obdname at index [0].
 */
-   if (clli && clli->cfg_instance == NULL &&
+   if (clli && !clli->cfg_instance &&
lcfg->lcfg_command == LCFG_SPTLRPC_CONF) {
lustre_cfg_bufs_set(, 2, bufs.lcfg_buf[1],
 

[PATCH 10/16] Staging: lustre: obdclass: genops.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/lustre/lustre/obdclass/genops.c | 52 -
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c 
b/drivers/staging/lustre/lustre/obdclass/genops.c
index c12ebd5..1248835 100644
--- a/drivers/staging/lustre/lustre/obdclass/genops.c
+++ b/drivers/staging/lustre/lustre/obdclass/genops.c
@@ -178,9 +178,9 @@ int class_register_type(struct obd_ops *dt_ops, struct 
md_ops *md_ops,
type->typ_md_ops = kzalloc(sizeof(*type->typ_md_ops), GFP_NOFS);
type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS);
 
-   if (type->typ_dt_ops == NULL ||
-   type->typ_md_ops == NULL ||
-   type->typ_name == NULL)
+   if (!type->typ_dt_ops ||
+   !type->typ_md_ops ||
+   !type->typ_name)
goto failed;
 
*(type->typ_dt_ops) = *dt_ops;
@@ -293,13 +293,13 @@ struct obd_device *class_newdev(const char *type_name, 
const char *name)
}
 
type = class_get_type(type_name);
-   if (type == NULL) {
+   if (!type) {
CERROR("OBD: unknown type: %s\n", type_name);
return ERR_PTR(-ENODEV);
}
 
newdev = obd_device_alloc();
-   if (newdev == NULL) {
+   if (!newdev) {
result = ERR_PTR(-ENOMEM);
goto out_type;
}
@@ -339,7 +339,7 @@ struct obd_device *class_newdev(const char *type_name, 
const char *name)
}
write_unlock(_dev_lock);
 
-   if (result == NULL && i >= class_devno_max()) {
+   if (!result && i >= class_devno_max()) {
CERROR("all %u OBD devices used, increase MAX_OBD_DEVICES\n",
   class_devno_max());
result = ERR_PTR(-EOVERFLOW);
@@ -463,7 +463,7 @@ struct obd_device *class_num2obd(int num)
 
if (num < class_devno_max()) {
obd = obd_devs[num];
-   if (obd == NULL)
+   if (!obd)
return NULL;
 
LASSERTF(obd->obd_magic == OBD_DEVICE_MAGIC,
@@ -509,7 +509,7 @@ void class_obd_list(void)
for (i = 0; i < class_devno_max(); i++) {
struct obd_device *obd = class_num2obd(i);
 
-   if (obd == NULL)
+   if (!obd)
continue;
if (obd->obd_stopping)
status = "ST";
@@ -540,7 +540,7 @@ struct obd_device *class_find_client_obd(struct obd_uuid 
*tgt_uuid,
for (i = 0; i < class_devno_max(); i++) {
struct obd_device *obd = class_num2obd(i);
 
-   if (obd == NULL)
+   if (!obd)
continue;
if ((strncmp(obd->obd_type->typ_name, typ_name,
 strlen(typ_name)) == 0)) {
@@ -567,7 +567,7 @@ struct obd_device *class_devices_in_group(struct obd_uuid 
*grp_uuid, int *next)
 {
int i;
 
-   if (next == NULL)
+   if (!next)
i = 0;
else if (*next >= 0 && *next < class_devno_max())
i = *next;
@@ -578,7 +578,7 @@ struct obd_device *class_devices_in_group(struct obd_uuid 
*grp_uuid, int *next)
for (; i < class_devno_max(); i++) {
struct obd_device *obd = class_num2obd(i);
 
-   if (obd == NULL)
+   if (!obd)
continue;
if (obd_uuid_equals(grp_uuid, >obd_uuid)) {
if (next != NULL)
@@ -609,7 +609,7 @@ int class_notify_sptlrpc_conf(const char *fsname, int 
namelen)
for (i = 0; i < class_devno_max(); i++) {
obd = class_num2obd(i);
 
-   if (obd == NULL || obd->obd_set_up == 0 || obd->obd_stopping)
+   if (!obd || obd->obd_set_up == 0 || obd->obd_stopping)
continue;
 
/* only notify mdc, osc, mdt, ost */
@@ -659,27 +659,27 @@ void obd_cleanup_caches(void)
 
 int obd_init_caches(void)
 {
-   LASSERT(obd_device_cachep == NULL);
+   LASSERT(!obd_device_cachep);
obd_device_cachep = kmem_cache_create("ll_obd_dev_cache",
 sizeof(struct obd_device),
 0, 0, NULL);
if (!obd_device_cachep)
goto out;
 
-   LASSERT(obdo_cachep == NULL);
+   LASSERT(!obdo_cachep);
obdo_cachep = kmem_cache_create("ll_obdo_cache", sizeof(struct obdo),
   0, 0, NULL);
if (!obdo_cachep)
goto out;
 
-   LASSERT(import_cachep == NULL);
+   LASSERT(!import_cachep);
import_cachep = kmem_cache_create("ll_import_cache",
 sizeof(struct obd_import),

[PATCH 07/16] Staging: lustre: libcfs: libcfs_lock.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/lustre/lustre/libcfs/libcfs_lock.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c 
b/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c
index 2c199c7..29308ba 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c
@@ -63,12 +63,12 @@ cfs_percpt_lock_alloc(struct cfs_cpt_table *cptab)
 
/* NB: cptab can be NULL, pcl will be for HW CPUs on that case */
LIBCFS_ALLOC(pcl, sizeof(*pcl));
-   if (pcl == NULL)
+   if (!pcl)
return NULL;
 
pcl->pcl_cptab = cptab;
pcl->pcl_locks = cfs_percpt_alloc(cptab, sizeof(*lock));
-   if (pcl->pcl_locks == NULL) {
+   if (!pcl->pcl_locks) {
LIBCFS_FREE(pcl, sizeof(*pcl));
return NULL;
}
@@ -164,7 +164,7 @@ cfs_percpt_atomic_alloc(struct cfs_cpt_table *cptab, int 
init_val)
int i;
 
refs = cfs_percpt_alloc(cptab, sizeof(*ref));
-   if (refs == NULL)
+   if (!refs)
return NULL;
 
cfs_percpt_for_each(ref, i, refs)
-- 
2.1.4

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


[PATCH 08/16] Staging: lustre: libcfs: libcfs_mem.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/lustre/lustre/libcfs/libcfs_mem.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_mem.c 
b/drivers/staging/lustre/lustre/libcfs/libcfs_mem.c
index 1debdda..f4e08da 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_mem.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_mem.c
@@ -84,7 +84,7 @@ cfs_percpt_alloc(struct cfs_cpt_table *cptab, unsigned int 
size)
count = cfs_cpt_number(cptab);
 
LIBCFS_ALLOC(arr, offsetof(struct cfs_var_array, va_ptrs[count]));
-   if (arr == NULL)
+   if (!arr)
return NULL;
 
arr->va_size= size = L1_CACHE_ALIGN(size);
@@ -93,7 +93,7 @@ cfs_percpt_alloc(struct cfs_cpt_table *cptab, unsigned int 
size)
 
for (i = 0; i < count; i++) {
LIBCFS_CPT_ALLOC(arr->va_ptrs[i], cptab, i, size);
-   if (arr->va_ptrs[i] == NULL) {
+   if (!arr->va_ptrs[i]) {
cfs_percpt_free((void *)>va_ptrs[0]);
return NULL;
}
@@ -160,7 +160,7 @@ cfs_array_free(void *vars)
arr = container_of(vars, struct cfs_var_array, va_ptrs[0]);
 
for (i = 0; i < arr->va_count; i++) {
-   if (arr->va_ptrs[i] == NULL)
+   if (!arr->va_ptrs[i])
continue;
 
LIBCFS_FREE(arr->va_ptrs[i], arr->va_size);
@@ -182,7 +182,7 @@ cfs_array_alloc(int count, unsigned int size)
int i;
 
LIBCFS_ALLOC(arr, offsetof(struct cfs_var_array, va_ptrs[count]));
-   if (arr == NULL)
+   if (!arr)
return NULL;
 
arr->va_count   = count;
@@ -191,7 +191,7 @@ cfs_array_alloc(int count, unsigned int size)
for (i = 0; i < count; i++) {
LIBCFS_ALLOC(arr->va_ptrs[i], size);
 
-   if (arr->va_ptrs[i] == NULL) {
+   if (!arr->va_ptrs[i]) {
cfs_array_free((void *)>va_ptrs[0]);
return NULL;
}
-- 
2.1.4

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


Re: [PATCH v2] ARM: rockchip: add reboot notifier

2015-09-10 Thread Eddie Cai
Hi Andy

2015-09-10 19:04 GMT+08:00 Andy Yan :
> rockchip platform have a protocol to pass the kernel reboot
> mode to bootloader by some special registers when system reboot.
> By this way the bootloader can take different action according
> to the different kernel reboot mode, for example, command
> "reboot loader" will reboot the board to rockusb mode, this is
> a very convenient way to get the board enter download mode.
>
> Signed-off-by: Andy Yan 
> ---
>
> Changes in v2:
>   - check cpu dt node
>   - remove a unnecessary of_put_node in function rockchip_get_pmu_regmap
>   - fix a align issue
>   - use reboot_notifier instead of restart_handler
>
>  arch/arm/mach-rockchip/Makefile |   2 +-
>  arch/arm/mach-rockchip/loader.h |  22 
>  arch/arm/mach-rockchip/reboot.c | 111 
> 
>  3 files changed, 134 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/mach-rockchip/loader.h
>  create mode 100644 arch/arm/mach-rockchip/reboot.c
>
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 5c3a9b2..cd291e3 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -1,5 +1,5 @@
>  CFLAGS_platsmp.o := -march=armv7-a
>
> -obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o
> +obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o reboot.o
>  obj-$(CONFIG_PM_SLEEP) += pm.o sleep.o
>  obj-$(CONFIG_SMP) += headsmp.o platsmp.o
> diff --git a/arch/arm/mach-rockchip/loader.h b/arch/arm/mach-rockchip/loader.h
> new file mode 100644
> index 000..bf51baa
> --- /dev/null
> +++ b/arch/arm/mach-rockchip/loader.h
> @@ -0,0 +1,22 @@
> +#ifndef __MACH_ROCKCHIP_LOADER_H
> +#define __MACH_ROCKCHIP_LOADER_H
> +
> +/*high 24 bits is tag, low 8 bits is type*/
> +#define SYS_LOADER_REBOOT_FLAG   0x5242C300
> +
> +enum {
> +   BOOT_NORMAL = 0, /* normal boot */
> +   BOOT_LOADER, /* enter loader rockusb mode */
> +   BOOT_MASKROM,/* enter maskrom rockusb mode (not support now) */
> +   BOOT_RECOVER,/* enter recover */
> +   BOOT_NORECOVER,  /* do not enter recover */
> +   BOOT_SECONDOS,   /* boot second OS (not support now)*/
> +   BOOT_WIPEDATA,   /* enter recover and wipe data. */
> +   BOOT_WIPEALL,/* enter recover and wipe all data. */
> +   BOOT_CHECKIMG,   /* check firmware img with backup part*/
> +   BOOT_FASTBOOT,   /* enter fast boot mode */
> +   BOOT_SECUREBOOT_DISABLE,
> +   BOOT_CHARGING,   /* enter charge mode */
> +   BOOT_MAX /* MAX VALID BOOT TYPE.*/
> +};
> +#endif
> diff --git a/arch/arm/mach-rockchip/reboot.c b/arch/arm/mach-rockchip/reboot.c
> new file mode 100644
> index 000..c29f031e
> --- /dev/null
> +++ b/arch/arm/mach-rockchip/reboot.c
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "loader.h"
> +
> +#define RK3188_PMU_SYS_REG0 0x40
> +#define RK3288_PMU_SYS_REG0 0x94

I think RK3066 and RK3368 also supported in upstream kernel. And the
protocol is the same. So it would be better to support it here.
> +
> +struct regmap *regmap;
> +int flag_reg;
> +
> +static int rockchip_get_pmu_regmap(void)
> +{
> +   struct device_node *node;
> +
> +   node = of_find_node_by_path("/cpus");
> +   if (!node)
> +   return -ENODEV;
> +
> +   regmap = syscon_regmap_lookup_by_phandle(node, "rockchip,pmu");
> +   of_node_put(node);
> +   if (!IS_ERR(regmap))
> +   return 0;
> +
> +   regmap = syscon_regmap_lookup_by_compatible("rockchip,rk3066-pmu");
> +   if (!IS_ERR(regmap))
> +   return 0;
> +
> +   return -ENODEV;
> +}
> +
> +static int rockchip_get_reboot_flag_regmap(void)
> +{
> +   int ret = rockchip_get_pmu_regmap();
> +
> +   if (ret < 0)
> +   return ret;
> +
> +   if (of_machine_is_compatible("rockchip,rk3288")) {
> +   flag_reg = RK3288_PMU_SYS_REG0;
> +   return 0;
> +   } else if (of_machine_is_compatible("rockchip,rk3066a") ||
> +  of_machine_is_compatible("rockchip,rk3066b") ||
> +  of_machine_is_compatible("rockchip,rk3188")) {
> +   flag_reg = RK3188_PMU_SYS_REG0;
> +   return 0;
> +   }
> +
> +   return -ENODEV;
> +}
> +
> +static void rockchip_get_reboot_flag(const char *cmd, u32 *flag)
> +{
> +   *flag = SYS_LOADER_REBOOT_FLAG + BOOT_NORMAL;
> +
> +   if (cmd) {
> +   if (!strcmp(cmd, "loader") || !strcmp(cmd, "bootloader"))
> +   *flag = 

RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram

2015-09-10 Thread Zhao Qiang
On Mon, 2015-09-11 at 06:09 -0500, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 11, 2015 6:09 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> muram
> 
> On Wed, 2015-09-09 at 21:34 -0500, Zhao Qiang-B45475 wrote:
> > On Mon, 2015-09-10 at 12:39 -0500, Wood Scott-B07421 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, September 10, 2015 12:39 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > Li Yang-Leo-R58472; pau...@samba.org
> > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to
> > > manage muram
> > >
> > > On Sun, 2015-09-06 at 01:37 -0500, Zhao Qiang-B45475 wrote:
> > > > On Mon, 2015-09-2 at 8:34 +0800, Wood Scott-B07421 wrote:
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 02, 2015 8:34 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > lau...@codeaurora.org; Xie Xiaobo-R63061;
> > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org
> > > > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions
> > > > > to manage muram
> > > > >
> > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > >
> > > > > > @@ -187,12 +190,25 @@ static inline int
> > > > > > qe_alive_during_sleep(void)  }
> > > > > >
> > > > > >  /* we actually use cpm_muram implementation, define this for
> > > > > > convenience */ -#define qe_muram_init cpm_muram_init -#define
> > > > > > qe_muram_alloc cpm_muram_alloc -#define qe_muram_alloc_fixed
> > > > > > cpm_muram_alloc_fixed -#define qe_muram_free cpm_muram_free
> > > > > > -#define qe_muram_addr cpm_muram_addr -#define qe_muram_offset
> > > > > > cpm_muram_offset
> > > > > > +#define cpm_muram_init qe_muram_init #define cpm_muram_alloc
> > > > > > +qe_muram_alloc #define cpm_muram_alloc_fixed
> > > > > > +qe_muram_alloc_fixed #define cpm_muram_free qe_muram_free
> > > > > > +#define cpm_muram_addr qe_muram_addr #define cpm_muram_offset
> > > > > > +qe_muram_offset
> > > > >
> > > > > Why?  This is unnecessary churn.
> > > > >
> > > > This is necessary. QE is on both ARM and PowerPC, its code is
> > > > under public code.
> > > > But CPM is only on PowerPC and its code is under PowerPC.
> > > > So when build ARM, QE will not find cpm_muram_* function.
> > >
> > > If you move the cpm_muram functions to drivers/soc, then ARM will
> > > find them.
> > > There is no need to rename them.
> >
> > Yes, moving cpm_muram can handle this issue. However, cpm is not
> > necessary To move to public code, and a churn is simpler than moving
> cpm_muram.
> > Please consider my suggestion, Thank you!
> 
> What do you mean by "public code"?  You're already moving cpm_muram.  I'm
> just asking that you not rename it while you do so.  If it absolutely
> must be renamed, do it in a different patch from the one that moves the
> code, though I don't see why the rename is helpful.

"Public code" is "driver/soc" here. I moved the qe_muram into driver/soc, not 
cpm_muram,
And the functions are named qe_muram_*, and removed cpm_muram_*, let cpm_muram
Use the same functions code with qe_muram, and define cpm_muram_* qe_muram_*. 

Previously, cpm/qe-muram functions are named cpm_muram_* because CPM is the 
predecessor
Of QE, and "define qe_muram_* cpm_muram_*". Now, because QE support both ARM 
and PowerPC,
move qe to driver/soc, and move the cpm/qe-muram functions to drver/soc too. So 
name the 
functions qe_muram_*, and "define cpm_muram_* qe_muram_*"

> 
> -Scott
> 

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH 03/16] Staging: speakup: serialio.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/speakup/serialio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index 66ac999..3b5835b 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -101,7 +101,7 @@ static void start_serial_interrupt(int irq)
 {
int rv;
 
-   if (synth->read_buff_add == NULL)
+   if (!synth->read_buff_add)
return;
 
rv = request_irq(irq, synth_readbuf_handler, IRQF_SHARED,
@@ -127,7 +127,7 @@ void spk_stop_serial_interrupt(void)
if (speakup_info.port_tts == 0)
return;
 
-   if (synth->read_buff_add == NULL)
+   if (!synth->read_buff_add)
return;
 
/* Turn off interrupts */
-- 
2.1.4

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


[PATCH 04/16] Staging: speakup: kobjects.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/speakup/kobjects.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index 958add4..fdfeb42 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -368,7 +368,7 @@ static ssize_t synth_show(struct kobject *kobj, struct 
kobj_attribute *attr,
 {
int rv;
 
-   if (synth == NULL)
+   if (!synth)
rv = sprintf(buf, "%s\n", "none");
else
rv = sprintf(buf, "%s\n", synth->name);
@@ -459,14 +459,14 @@ static ssize_t punc_show(struct kobject *kobj, struct 
kobj_attribute *attr,
unsigned long flags;
 
p_header = spk_var_header_by_name(attr->attr.name);
-   if (p_header == NULL) {
+   if (!p_header) {
pr_warn("p_header is null, attr->attr.name is %s\n",
attr->attr.name);
return -EINVAL;
}
 
var = spk_get_punc_var(p_header->var_id);
-   if (var == NULL) {
+   if (!var) {
pr_warn("var is null, p_header->var_id is %i\n",
p_header->var_id);
return -EINVAL;
@@ -501,14 +501,14 @@ static ssize_t punc_store(struct kobject *kobj, struct 
kobj_attribute *attr,
return -EINVAL;
 
p_header = spk_var_header_by_name(attr->attr.name);
-   if (p_header == NULL) {
+   if (!p_header) {
pr_warn("p_header is null, attr->attr.name is %s\n",
attr->attr.name);
return -EINVAL;
}
 
var = spk_get_punc_var(p_header->var_id);
-   if (var == NULL) {
+   if (!var) {
pr_warn("var is null, p_header->var_id is %i\n",
p_header->var_id);
return -EINVAL;
@@ -546,7 +546,7 @@ ssize_t spk_var_show(struct kobject *kobj, struct 
kobj_attribute *attr,
unsigned long flags;
 
param = spk_var_header_by_name(attr->attr.name);
-   if (param == NULL)
+   if (!param)
return -EINVAL;
 
spin_lock_irqsave(_info.spinlock, flags);
@@ -622,9 +622,9 @@ ssize_t spk_var_store(struct kobject *kobj, struct 
kobj_attribute *attr,
unsigned long flags;
 
param = spk_var_header_by_name(attr->attr.name);
-   if (param == NULL)
+   if (!param)
return -EINVAL;
-   if (param->data == NULL)
+   if (!param->data)
return 0;
ret = 0;
cp = (char *)buf;
-- 
2.1.4

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


[PATCH 02/16] Staging: speakup: devsynth.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/speakup/devsynth.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/speakup/devsynth.c 
b/drivers/staging/speakup/devsynth.c
index 71c728a..d1ffdf4 100644
--- a/drivers/staging/speakup/devsynth.c
+++ b/drivers/staging/speakup/devsynth.c
@@ -22,7 +22,7 @@ static ssize_t speakup_file_write(struct file *fp, const char 
__user *buffer,
unsigned long flags;
u_char buf[256];
 
-   if (synth == NULL)
+   if (!synth)
return -ENODEV;
while (count > 0) {
bytes = min(count, sizeof(buf));
@@ -45,7 +45,7 @@ static ssize_t speakup_file_read(struct file *fp, char __user 
*buf,
 
 static int speakup_file_open(struct inode *ip, struct file *fp)
 {
-   if (synth == NULL)
+   if (!synth)
return -ENODEV;
if (xchg(_opened, 1))
return -EBUSY;
-- 
2.1.4

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


[PATCH 01/16] Staging: speakup: varhandlers.c: Remove explicit NULL comparison

2015-09-10 Thread Shraddha Barke
Remove explicit NULL comparison and write it in its simpler form.
Replacement done with coccinelle:

@replace_rule@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Shraddha Barke 
---
 drivers/staging/speakup/varhandlers.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index 75bf40c..64042c9 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -90,7 +90,7 @@ void speakup_register_var(struct var_t *var)
struct st_var_header *p_header;
 
BUG_ON(!var || var->var_id < 0 || var->var_id >= MAXVARS);
-   if (var_ptrs[0] == NULL) {
+   if (!var_ptrs[0]) {
for (i = 0; i < MAXVARS; i++) {
p_header = _headers[i];
var_ptrs[p_header->var_id] = p_header;
@@ -130,7 +130,7 @@ struct st_var_header *spk_get_var_header(enum var_id_t 
var_id)
if (var_id < 0 || var_id >= MAXVARS)
return NULL;
p_header = var_ptrs[var_id];
-   if (p_header->data == NULL)
+   if (!p_header->data)
return NULL;
return p_header;
 }
@@ -163,7 +163,7 @@ struct punc_var_t *spk_get_punc_var(enum var_id_t var_id)
struct punc_var_t *where;
 
where = punc_vars;
-   while ((where->var_id != -1) && (rv == NULL)) {
+   while ((where->var_id != -1) && (!rv)) {
if (where->var_id == var_id)
rv = where;
else
@@ -183,7 +183,7 @@ int spk_set_num_var(int input, struct st_var_header *var, 
int how)
char *cp;
struct var_t *var_data = var->data;
 
-   if (var_data == NULL)
+   if (!var_data)
return -ENODATA;
 
if (how == E_NEW_DEFAULT) {
@@ -221,7 +221,7 @@ int spk_set_num_var(int input, struct st_var_header *var, 
int how)
if (var_data->u.n.multiplier != 0)
val *= var_data->u.n.multiplier;
val += var_data->u.n.offset;
-   if (var->var_id < FIRST_SYNTH_VAR || synth == NULL)
+   if (var->var_id < FIRST_SYNTH_VAR || !synth)
return ret;
if (synth->synth_adjust != NULL) {
int status = synth->synth_adjust(var);
@@ -247,7 +247,7 @@ int spk_set_string_var(const char *page, struct 
st_var_header *var, int len)
 {
struct var_t *var_data = var->data;
 
-   if (var_data == NULL)
+   if (!var_data)
return -ENODATA;
if (len > MAXVARLEN)
return -E2BIG;
@@ -313,7 +313,7 @@ char *spk_strlwr(char *s)
 {
char *p;
 
-   if (s == NULL)
+   if (!s)
return NULL;
 
for (p = s; *p; p++)
-- 
2.1.4

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


Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel

2015-09-10 Thread Petr Cvek
Dne 10.9.2015 v 13:14 Robert Jarzmik napsal(a):
> Petr Cvek  writes:
> 
>> Dne 9.9.2015 v 08:25 Robert Jarzmik napsal(a):
>>> Petr Cvek  writes:
>>>
 Dne 8.9.2015 v 22:24 Petr Cvek napsal(a):
>
> Did you defined resources somewhere? Actual resources are in
> "pxa_ir_resources" variable at:
>>> I have them in patch [1], which is exactly the patch you have made yourself.
>>
>> Is there a mailing list for this specific patch? It seems I did not get any
>> mail with it.
> Should have been posted to linux arm kernel mailing list, unless my mailer
> failed ...
> 
Searching for:

"ARM: pxa: add resources to pxaficp_ir"

did not found anything, same was for "ficp" in the 
linux-arm-kernel/netdev/linux-kernel
mailing list archive.

>> BTW This patch required update of my kernel repo. It seems that my:
>>
>>  magician.c patches + ficp patch + new dma engine
>>
>> does not work for me at all. Kernel throws some panic about interrupts and 
>> then
>> it ends in an infinite stack dumping loop. Fault occurs before rootfs is
>> mounted, so probably around MMC init (with removed SD card it fails normally
>> with no rootfs found error).
> Could you send me (privately) the stack you're getting please. This is 
> something
> I'd like to catch up early in the -rc releases.

Well this will be problem as I cannot save anything to an SD card after and 
during the failure.
Only viable interfaces would be earlycon on an infraport or high speed camera 
on LCD :-). 

But I was able to revert this commit:

6464b71409511939efce1ae4fb4ec6e3483b11b2mmc: pxamci: switch 
over to dmaengine use

and after that I am able to boot.

> 
> Now with your stack, could you also give me the upstream commit id of the tip 
> of
> the tree you're using (before your patches) please ?

It is probably irelevant now, but for complete information:

Discovered on my working repo: mainline b8889c4fc6ba03e289cec6a4d692f6f080a55e53
Still present on fresh downloaded: linux-next 
22dc312d56ba077db27a9798b340e7d161f1df05

> 
> And it is true I have not tested the rootfs special case, where drivers are 
> not
> yet initialized (and more specifically gpio and interrupt chip). Your 
> backtrace
> should tell me if you fall into this category of issues ... but I digress, 
> this
> has no link with pxaficp.

Should I start new thread? (same bug can be present in the FICP too)

I will try to configure an initrd rootfs this should create more ways to save 
kernel log.


Anyway after mmc dma revert I was still not able to start FICP. There is an 
error:

Unable to handle kernel paging request at virtual address 32e4

from pxa_irda_startup() and it seems it is caused by register definitions. For 
example:

writel_relaxed((val), (irda)->stuart_base + (off));

is called by

stuart_writel(si, 0, STIER);

but STIER is not just an offset, but full register address:

__REG(0x4074)

So the definition should be changed, unless there is another patch I did not 
received (in that case, send me full patchset again please) :-).


Best regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] f2fs crypto: allocate buffer for decrypting filename

2015-09-10 Thread Jaegeuk Kim
We got dentry pages from high_mem, and its address space directly goes into the
decryption path via f2fs_fname_disk_to_usr.
But, sg_init_one assumes the address is not from high_mem, so we can get this
panic since it doesn't call kmap_high but kunmap_high is triggered at the end.

kernel BUG at ../../../../../../kernel/mm/highmem.c:290!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
...
 (kunmap_high+0xb0/0xb8) from [] (__kunmap_atomic+0xa0/0xa4)
 (__kunmap_atomic+0xa0/0xa4) from [] (blkcipher_walk_done+0x128/0x1ec)
 (blkcipher_walk_done+0x128/0x1ec) from [] 
(crypto_cbc_decrypt+0xc0/0x170)
 (crypto_cbc_decrypt+0xc0/0x170) from [] 
(crypto_cts_decrypt+0xc0/0x114)
 (crypto_cts_decrypt+0xc0/0x114) from [] (async_decrypt+0x40/0x48)
 (async_decrypt+0x40/0x48) from [] 
(f2fs_fname_disk_to_usr+0x124/0x304)
 (f2fs_fname_disk_to_usr+0x124/0x304) from [] 
(f2fs_fill_dentries+0xac/0x188)
 (f2fs_fill_dentries+0xac/0x188) from [] (f2fs_readdir+0x1f0/0x300)
 (f2fs_readdir+0x1f0/0x300) from [] (vfs_readdir+0x90/0xb4)
 (vfs_readdir+0x90/0xb4) from [] (SyS_getdents64+0x64/0xcc)
 (SyS_getdents64+0x64/0xcc) from [] (ret_fast_syscall+0x0/0x30)

Cc: 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/dir.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 8f15fc1..f3fe1a1 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -788,8 +788,9 @@ bool f2fs_fill_dentries(struct dir_context *ctx, struct 
f2fs_dentry_ptr *d,
d_type = DT_UNKNOWN;
 
/* encrypted case */
-   de_name.name = d->filename[bit_pos];
de_name.len = le16_to_cpu(de->name_len);
+   de_name.name = kmalloc(de_name.len, GFP_NOFS);
+   memcpy(de_name.name, d->filename[bit_pos], de_name.len);
 
if (f2fs_encrypted_inode(d->inode)) {
int save_len = fstr->len;
@@ -799,13 +800,18 @@ bool f2fs_fill_dentries(struct dir_context *ctx, struct 
f2fs_dentry_ptr *d,
_name, fstr);
de_name = *fstr;
fstr->len = save_len;
-   if (ret < 0)
+   if (ret < 0) {
+   kfree(de_name.name);
return true;
+   }
}
 
if (!dir_emit(ctx, de_name.name, de_name.len,
-   le32_to_cpu(de->ino), d_type))
+   le32_to_cpu(de->ino), d_type)) {
+   kfree(de_name.name);
return true;
+   }
+   kfree(de_name.name);
 
bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
ctx->pos = start_pos + bit_pos;
-- 
2.1.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] Input: snvs_pwrkey - remove duplicated semicolon

2015-09-10 Thread Javier Martinez Canillas
Remove the unneded semicolon since it is clearly a typo error.

Signed-off-by: Javier Martinez Canillas 

---

 drivers/input/keyboard/snvs_pwrkey.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/keyboard/snvs_pwrkey.c 
b/drivers/input/keyboard/snvs_pwrkey.c
index 78fd24ca3813..a4db65d67e1b 100644
--- a/drivers/input/keyboard/snvs_pwrkey.c
+++ b/drivers/input/keyboard/snvs_pwrkey.c
@@ -110,7 +110,7 @@ static int imx_snvs_pwrkey_probe(struct platform_device 
*pdev)
if (!pdata)
return -ENOMEM;
 
-   pdata->snvs = syscon_regmap_lookup_by_phandle(np, "regmap");;
+   pdata->snvs = syscon_regmap_lookup_by_phandle(np, "regmap");
 
if (!pdata->snvs) {
dev_err(>dev, "Can't get snvs syscon\n");
-- 
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 v2] powerpc32: memcpy/memset: only use dcbz once cache is enabled

2015-09-10 Thread Michael Ellerman
On Thu, 2015-09-10 at 17:05 -0500, Scott Wood wrote:
> On Thu, 2015-09-10 at 08:41 +0200, Christophe Leroy wrote:
> >  
> > +/* Cache related sections */
> > +#define BEGIN_CACHE_SECTION_NESTED(label)START_FTR_SECTION(label)
> > +#define BEGIN_CACHE_SECTION  START_FTR_SECTION(97)
> > +
> > +#define END_CACHE_SECTION_NESTED(msk, val, label)\
> > + FTR_SECTION_ELSE_NESTED(label)  \
> > + MAKE_FTR_SECTION_ENTRY(msk, val, label, __cache_fixup)
> > +
> > +#define END_CACHE_SECTION(msk, val)  \
> > + END_CACHE_SECTION_NESTED(msk, val, 97)
> > +
> > +#define END_CACHE_SECTION_IFSET(msk) END_CACHE_SECTION((msk), (msk))
> > +#define END_CACHE_SECTION_IFCLR(msk) END_CACHE_SECTION((msk), 0)
> > +
> > +/* CACHE feature sections with alternatives, use BEGIN_FTR_SECTION to 
> > start */
> > +#define CACHE_SECTION_ELSE_NESTED(label) FTR_SECTION_ELSE_NESTED(label)
> > +#define CACHE_SECTION_ELSE   CACHE_SECTION_ELSE_NESTED(97)
> > +#define ALT_CACHE_SECTION_END_NESTED(msk, val, label)\
> > + MAKE_FTR_SECTION_ENTRY(msk, val, label, __cache_fixup)
> > +#define ALT_CACHE_SECTION_END_NESTED_IFSET(msk, label)   \
> > + ALT_CACHE_SECTION_END_NESTED(msk, msk, label)
> > +#define ALT_CACHE_SECTION_END_NESTED_IFCLR(msk, label)   \
> > + ALT_CACHE_SECTION_END_NESTED(msk, 0, label)
> > +#define ALT_CACHE_SECTION_END(msk, val)  \
> > + ALT_CACHE_SECTION_END_NESTED(msk, val, 97)
> > +#define ALT_CACHE_SECTION_END_IFSET(msk) \
> > + ALT_CACHE_SECTION_END_NESTED_IFSET(msk, 97)
> > +#define ALT_CACHE_SECTION_END_IFCLR(msk) \
> > + ALT_CACHE_SECTION_END_NESTED_IFCLR(msk, 97)
> 
> I don't think this duplication is what Michael meant by "the normal cpu 
> feature sections".  What else is going to use this very specific 
> infrastructure?

Yeah, sorry, I was hoping you could do it with the existing cpu feature
mechanism.

It looks like the timing doesn't work, ie. you need to patch this stuff in
machine_init(), which is later than the regular patching which gets done in
early_init().

This is one of the festering differences we have between the 32 and 64-bit
initialisation code, ie. on 64-bit we do the patching much later.


So I think the cleanest solution is to have memcpy branch to generic_memcpy by
default, and then patch that to a nop once you're up and running. Something
like:

diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index bb02e9f6944e..1c1a4e8866ad 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DBG(fmt...)
 
@@ -119,6 +120,8 @@ notrace void __init machine_init(u64 dt_ptr)
/* Do some early initialization based on the flat device tree */
early_init_devtree(__va(dt_ptr));
 
+   patch_instruction((unsigned int *), 0x6000);
+
epapr_paravirt_early_init();
 
early_init_mmu();
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index 2ef50c629470..6446d2915e41 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -135,6 +135,7 @@ _GLOBAL(memmove)
/* fall through */
 
 _GLOBAL(memcpy)
+   b   generic_memcpy
add r7,r3,r5/* test if the src & dst overlap */
add r8,r4,r5
cmplw   0,r4,r7

cheers


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


Re: [PATCH] lib/string_helpers.c: fix infinite loop in string_get_size()

2015-09-10 Thread James Bottomley
On Fri, 2015-09-04 at 14:56 +0200, Vitaly Kuznetsov wrote:
> string_get_size(1, 512, 0, ..., ...) call results in an infinite loop. The
> problem is that if size == 0 when we start calculating sf_cap this loop
> will never end.
> 
> The caller causing the issue is sd_read_capacity(), the problem was noticed
> on Hyper-V.
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  lib/string_helpers.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/string_helpers.c b/lib/string_helpers.c
> index c98ae81..a155c7b 100644
> --- a/lib/string_helpers.c
> +++ b/lib/string_helpers.c
> @@ -76,7 +76,7 @@ void string_get_size(u64 size, u64 blk_size, const enum 
> string_size_units units,
>   i++;
>   }
>  
> - sf_cap = size;
> + sf_cap = size ? size : 1;

If size can become zero after the scale adjustment, then there's a fault
in the algorithm, and this probably isn't the right fix.  However, I did
a brief calculation, and I can't see how size becomes zero ... it might
be that I haven't looked at this long enough (I am on holiday).

James

>   for (j = 0; sf_cap*10 < 1000; j++)
>   sf_cap *= 10;
>  




Re: [PATCH 08/18] [media] s5c73m3: Export OF module alias information

2015-09-10 Thread Javier Martinez Canillas
Hello,

On 08/20/2015 09:07 AM, Javier Martinez Canillas wrote:
> The SPI core always reports the MODALIAS uevent as "spi:"
> regardless of the mechanism that was used to register the device
> (i.e: OF or board code) and the table that is used later to match
> the driver with the device (i.e: SPI id table or OF match table).
> 
> So drivers needs to export the SPI id table and this be built into
> the module or udev won't have the necessary information to autoload
> the needed driver module when the device is added.
> 
> But this means that OF-only drivers needs to have both OF and SPI id
> tables that have to be kept in sync and also the dev node compatible
> manufacturer prefix is stripped when reporting the MODALIAS. Which can
> lead to issues if two vendors use the same SPI device name for example.
> 
> To avoid the above, the SPI core behavior may be changed in the future
> to not require an SPI device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table even when
> is unused now to prevent breaking module loading when the core changes.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  drivers/media/i2c/s5c73m3/s5c73m3-spi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c 
> b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
> index fa4a5ebda6b2..9983635ec253 100644
> --- a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
> +++ b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
> @@ -31,6 +31,7 @@ static const struct of_device_id s5c73m3_spi_ids[] = {
>   { .compatible = "samsung,s5c73m3" },
>   { }
>  };
> +MODULE_DEVICE_TABLE(of, s5c73m3_spi_ids;);
>  
>  enum spi_direction {
>   SPI_DIR_RX,
> 

Any comments about this patch?

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/


[PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

2015-09-10 Thread Scott Branden
This patch contains a fix for a real world interop problem found
when using the Synopsis DWC2 USB controller with isochronous audio as
detailed in the commit message.

Changes from v2:
 - created s2c_hsotg_chage_ep_iso_parity function to call function in 3 places 
in code
 - used hsotg->num_of_eps instead of MAX_EPS_CHANNELS

Changes from v1:
 - Address code review comments as per previous responses:
 - renamed parity_set to has_correct_parity and reorder some logic


Roman Bacik (1):
  usb: dwc2: gadget: parity fix in isochronous mode

 drivers/usb/dwc2/core.h   |  1 +
 drivers/usb/dwc2/gadget.c | 58 ++-
 drivers/usb/dwc2/hw.h |  1 +
 3 files changed, 54 insertions(+), 6 deletions(-)

-- 
2.5.0

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


[PATCH v3 1/1] usb: dwc2: gadget: parity fix in isochronous mode

2015-09-10 Thread Scott Branden
From: Roman Bacik 

USB OTG driver in isochronous mode has to set the parity of the receiving
microframe. The parity is set to even by default. This causes problems for
an audio gadget, if the host starts transmitting on odd microframes.

This fix uses Incomplete Periodic Transfer interrupt to toggle between
even and odd parity until the Transfer Complete interrupt is received.

Signed-off-by: Roman Bacik 
Reviewed-by: Abhinav Ratna 
Reviewed-by: Srinath Mannam 
Signed-off-by: Scott Branden 
---
 drivers/usb/dwc2/core.h   |  1 +
 drivers/usb/dwc2/gadget.c | 58 ++-
 drivers/usb/dwc2/hw.h |  1 +
 3 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 0ed87620..a5634fd 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
unsigned intperiodic:1;
unsigned intisochronous:1;
unsigned intsend_zlp:1;
+   unsigned inthas_correct_parity:1;
 
charname[10];
 };
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 4d47b7c..efaab76 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1916,6 +1916,19 @@ static void s3c_hsotg_complete_in(struct dwc2_hsotg 
*hsotg,
s3c_hsotg_complete_request(hsotg, hs_ep, hs_req, 0);
 }
 
+static void s3c_hsotg_change_ep_iso_parity(struct dwc2_hsotg *hsotg,
+   u32 epctl_reg)
+{
+   u32 ctrl;
+
+   ctrl = readl(hsotg->regs + epctl_reg);
+   if (ctrl & DXEPCTL_EOFRNUM)
+   ctrl |= DXEPCTL_SETEVENFR;
+   else
+   ctrl |= DXEPCTL_SETODDFR;
+   writel(ctrl, hsotg->regs + epctl_reg);
+}
+
 /**
  * s3c_hsotg_epint - handle an in/out endpoint interrupt
  * @hsotg: The driver state
@@ -1954,12 +1967,9 @@ static void s3c_hsotg_epint(struct dwc2_hsotg *hsotg, 
unsigned int idx,
ints &= ~DXEPINT_XFERCOMPL;
 
if (ints & DXEPINT_XFERCOMPL) {
+   hs_ep->has_correct_parity = 1;
if (hs_ep->isochronous && hs_ep->interval == 1) {
-   if (ctrl & DXEPCTL_EOFRNUM)
-   ctrl |= DXEPCTL_SETEVENFR;
-   else
-   ctrl |= DXEPCTL_SETODDFR;
-   writel(ctrl, hsotg->regs + epctl_reg);
+   s3c_hsotg_change_ep_iso_parity(hsotg, epctl_reg);
}
 
dev_dbg(hsotg->dev,
@@ -2316,7 +2326,8 @@ void s3c_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
GINTSTS_RESETDET | GINTSTS_ENUMDONE |
GINTSTS_OTGINT | GINTSTS_USBSUSP |
-   GINTSTS_WKUPINT,
+   GINTSTS_WKUPINT |
+   GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
hsotg->regs + GINTMSK);
 
if (using_dma(hsotg))
@@ -2581,6 +2592,40 @@ irq_retry:
s3c_hsotg_dump(hsotg);
}
 
+   if (gintsts & GINTSTS_INCOMPL_SOIN) {
+   u32 idx, epctl_reg;
+   struct s3c_hsotg_ep *hs_ep;
+
+   dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n", __func__);
+   for (idx = 1; idx < hsotg->num_of_eps; idx++) {
+   hs_ep = hsotg->eps_in[idx];
+
+   if (!hs_ep->isochronous || hs_ep->has_correct_parity)
+   continue;
+
+   epctl_reg = DIEPCTL(idx);
+   s3c_hsotg_change_ep_iso_parity(hsotg, epctl_reg);
+   }
+   writel(GINTSTS_INCOMPL_SOIN, hsotg->regs + GINTSTS);
+   }
+
+   if (gintsts & GINTSTS_INCOMPL_SOOUT) {
+   u32 idx, epctl_reg;
+   struct s3c_hsotg_ep *hs_ep;
+
+   dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOOUT\n", __func__);
+   for (idx = 1; idx < hsotg->num_of_eps; idx++) {
+   hs_ep = hsotg->eps_out[idx];
+
+   if (!hs_ep->isochronous || hs_ep->has_correct_parity)
+   continue;
+
+   epctl_reg = DOEPCTL(idx);
+   s3c_hsotg_change_ep_iso_parity(hsotg, epctl_reg);
+   }
+   writel(GINTSTS_INCOMPL_SOOUT, hsotg->regs + GINTSTS);
+   }
+
/*
 * if we've had fifo events, we should try and go around the
 * loop again to see if there's any point in returning yet.
@@ -2667,6 +2712,7 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
hs_ep->periodic = 0;
hs_ep->halted = 0;
hs_ep->interval = desc->bInterval;
+   hs_ep->has_correct_parity = 0;
 
if (hs_ep->interval > 1 && hs_ep->mc > 1)
dev_err(hsotg->dev, "MC > 1 when interval is not 1\n");
diff --git a/drivers/usb/dwc2/hw.h 

Re: [PATCH 3/3] net/udevns: Netlink module to forward uevent to containers

2015-09-10 Thread Eric W. Biederman
"Michael J. Coss"  writes:

> New generic netlink module to provide an interface with the new
> forwarding interface for uevent.  The driver allows a user to
> direct a uevent as read from the kernel to a specific network
> namespace by providing the uevent message, and a target process id.
> The uapi header file provides the message format.

If we can't just pass the message thourgh I don't expect genetlink is a
particularly good interface for this.

It would be nice if we could open some appropriate thing and the act of
getting a file descriptor ould suppress all of the uevent broadcast
messages in that network namespace.

Further GENL_ADMIN_PERM is an unfortunate choice for a permission check.
I don't see it as exploitable but I am not certain CAP_SYS_ADMIN is the
best capability to check.Beyond that we probably want to arrange
things so that we can use ns_capable so we can allow containers to hand
off their devices to child containers.

Implementations that do not allow for containers to nest bother me.

> Signed-off-by: Michael J. Coss 
> ---
>  include/uapi/linux/Kbuild   |   1 +
>  include/uapi/linux/udevns.h |  19 
>  net/Kconfig |   1 +
>  net/Makefile|   1 +
>  net/udevns/Kconfig  |   9 
>  net/udevns/Makefile |   5 ++
>  net/udevns/udevns.c | 112 
> 
>  net/udevns/udevns.h |  19 
>  8 files changed, 167 insertions(+)
>  create mode 100644 include/uapi/linux/udevns.h
>  create mode 100644 net/udevns/Kconfig
>  create mode 100644 net/udevns/Makefile
>  create mode 100644 net/udevns/udevns.c
>  create mode 100644 net/udevns/udevns.h
>
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index 1ff9942..9fb9c59 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -404,6 +404,7 @@ header-y += toshiba.h
>  header-y += tty_flags.h
>  header-y += tty.h
>  header-y += types.h
> +header-y += udevns.h
>  header-y += udf_fs_i.h
>  header-y += udp.h
>  header-y += uhid.h
> diff --git a/include/uapi/linux/udevns.h b/include/uapi/linux/udevns.h
> new file mode 100644
> index 000..f5702f5
> --- /dev/null
> +++ b/include/uapi/linux/udevns.h
> @@ -0,0 +1,19 @@
> +#ifndef _UDEVNS_H_
> +#define _UDEVNS_H_
> +
> +enum udevns_msg_types {
> + UDEVNS_FORWARD_MSG = 0x1,
> + UDEVNS_CMD_MAX,
> +};
> +
> +enum udevns_attr {
> + UDEVNS_UNSPEC,
> + UDEVNS_PID,
> + UDEVNS_MSG,
> + __UDEVNS_ATTR_MAX,
> +};
> +
> +#define UDEVNS_ATTR_MAX (__UDEVNS_ATTR_MAX - 1)
> +#define UDEVNS_VERSION 0x1
> +
> +#endif
> diff --git a/net/Kconfig b/net/Kconfig
> index 57a7c5a..465e288 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -54,6 +54,7 @@ source "net/packet/Kconfig"
>  source "net/unix/Kconfig"
>  source "net/xfrm/Kconfig"
>  source "net/iucv/Kconfig"
> +source "net/udevns/Kconfig"
>  
>  config INET
>   bool "TCP/IP networking"
> diff --git a/net/Makefile b/net/Makefile
> index 3995613..bde7775 100644
> --- a/net/Makefile
> +++ b/net/Makefile
> @@ -74,3 +74,4 @@ obj-$(CONFIG_HSR)   += hsr/
>  ifneq ($(CONFIG_NET_SWITCHDEV),)
>  obj-y+= switchdev/
>  endif
> +obj-$(CONFIG_UDEVNS) += udevns/
> diff --git a/net/udevns/Kconfig b/net/udevns/Kconfig
> new file mode 100644
> index 000..367e650
> --- /dev/null
> +++ b/net/udevns/Kconfig
> @@ -0,0 +1,9 @@
> +config UDEVNS
> + tristate "UDEV namespace bridge"
> + depends on SYSFS
> + default n
> + help
> + This option enables support for explicit forwarding of UDEV 
> events to
> + other network namespaces
> +
> + If unsure, say N.
> diff --git a/net/udevns/Makefile b/net/udevns/Makefile
> new file mode 100644
> index 000..44c6b12
> --- /dev/null
> +++ b/net/udevns/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the uevent namespace aware forwarder
> +#
> +#
> +obj-$(CONFIG_UDEVNS) += udevns.o
> diff --git a/net/udevns/udevns.c b/net/udevns/udevns.c
> new file mode 100644
> index 000..8b23751
> --- /dev/null
> +++ b/net/udevns/udevns.c
> @@ -0,0 +1,112 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "udevns.h"
> +
> +#define DRIVER_AUTHOR "Michael J Coss "
> +#define DRIVER_DESC   "new udev namespace bridge"
> +#define DEVICE_NAME   "udevns"
> +
> +#ifdef MODULE
> +#define UDEVNS_NAME (THIS_MODULE->name)
> +#else
> +#define UDEVNS_NAME "udevns"
> +#endif
> +
> +#define UDEVNS_INFO(fmt, args...)   \
> + pr_info("[%s] " fmt, UDEVNS_NAME, ## args)
> +
> +#define UDEVNS_ERROR(fmt, args...)  \
> + pr_err("[ERROR:%s:%s] " fmt, UDEVNS_NAME, __func__, ## args)
> +
> +#define UDEVNS_WARNING(fmt, args...)\
> + pr_warn("[WARNING:%s:%s] " fmt, 

Re: [PATCH 2/3] lib/kobject_uevent.c: add uevent forwarding function

2015-09-10 Thread Eric W. Biederman
"Michael J. Coss"  writes:

> Adds capability to allow userspace programs to forward a given event to
> a specific network namespace as determined by the provided pid.  In
> addition, support for a per-namespace kobject_sequence counter was
> added.  Sysfs was modified to return the correct event counter based on
> the current network namespace.

So this patch is buggy.

> Signed-off-by: Michael J. Coss 
> ---
>  include/linux/kobject.h |  3 ++
>  include/net/net_namespace.h |  3 ++
>  kernel/ksysfs.c | 12 ++
>  lib/kobject_uevent.c| 90 
> +
>  4 files changed, 108 insertions(+)
>
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index 637f670..d1bb509 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -215,6 +215,9 @@ extern struct kobject *firmware_kobj;
>  int kobject_uevent(struct kobject *kobj, enum kobject_action action);
>  int kobject_uevent_env(struct kobject *kobj, enum kobject_action action,
>   char *envp[]);
> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> +int kobject_uevent_forward(char *buf, size_t len, pid_t pid);
> +#endif
>  
>  __printf(2, 3)
>  int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index e951453..a4013e5 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -134,6 +134,9 @@ struct net {
>  #if IS_ENABLED(CONFIG_MPLS)
>   struct netns_mpls   mpls;
>  #endif
> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> + u64 kevent_seqnum;
> +#endif
>   struct sock *diag_nlsk;
>   atomic_tfnhe_genid;
>  };
> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index 6683cce..4bc15fd 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -21,6 +21,9 @@
>  #include 
>  
>  #include   /* rcu_expedited */
> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> +#include 
> +#endif
>  
>  #define KERNEL_ATTR_RO(_name) \
>  static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
> @@ -33,6 +36,15 @@ static struct kobj_attribute _name##_attr = \
>  static ssize_t uevent_seqnum_show(struct kobject *kobj,
> struct kobj_attribute *attr, char *buf)
>  {
> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> + pid_t p = task_pid_vnr(current);
> + struct net *n = get_net_ns_by_pid(p);
> +
> + if (n != ERR_PTR(-ESRCH)) {
> + if (!net_eq(n, _net))
> + return sprintf(buf, "%llu\n", n->kevent_seqnum);
> + }
> +#endif

The test here is completely wrong.
a) Each sysfs instance already has a network namespace attached to it's
   superblock so using the pid of the caller is wrong.

b) You return kevent_seqnum even in network namespaces where you are not
   sending uevents from userspace which is concerning.

c) Is this all we need to do to sysfs?  Otherwise it may be best to
   simply fake this file, and remove the need to play games with the
   sequence number in kobject_uevent_forward.

>   return sprintf(buf, "%llu\n", (unsigned long long)uevent_seqnum);
>  }
>  KERNEL_ATTR_RO(uevent_seqnum);
> diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> index d791e33..7589745 100644
> --- a/lib/kobject_uevent.c
> +++ b/lib/kobject_uevent.c
> @@ -379,6 +379,96 @@ int kobject_uevent(struct kobject *kobj, enum 
> kobject_action action)
>  }
>  EXPORT_SYMBOL_GPL(kobject_uevent);
>  
> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> +/**
> + * kobject_uevent_forward - forward event to specified network namespace
> + *
> + * @buf: event buffer
> + * @len: event length
> + * @pid: pid of network namespace

This function should just take a network namespace all of the weird bits
should be left to the user/kernel interface.

The pid should be translated into a network namespace at the edge of
user space.  Not down here in a helper function.

> + * Returns 0 if kobject_uevent_forward() is completed with success or the
> + * corresponding error when it fails.
> + */
> +int kobject_uevent_forward(char *buf, size_t len, pid_t pid)
> +{
> + int retval = 0;
> +#if defined(CONFIG_NET)
> + struct uevent_sock *ue_sk;
> + struct net *pns;
> + char *p;
> + u64 num;
> +
> + /* grab the network namespace of the provided pid */
> + pns = get_net_ns_by_pid(pid);
> + if (pns == ERR_PTR(-ESRCH))
> + return -ESRCH;
> +
> + /* find sequence number in buffer */
> + p = buf;
> + num = 0;
> + while (p < (buf + len)) {
> + if (strncmp(p, "SEQNUM=", 7) == 0) {
> + int r;
> +
> + p += 7;
> + r = kstrtoull(p, 10, );
> + if (r) {
> + put_net(pns);
> + 

Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger

2015-09-10 Thread Krzysztof Kozlowski
On 11.09.2015 01:42, Andrew F. Davis wrote:
> On 09/09/2015 06:47 PM, Krzysztof Kozlowski wrote:
> +- ti,enable-user-write: boolean, if present driver will allow the
> user space
> +to control the charging current and voltage through sysfs;

 This is not DT property. It does not describe hardware.
>>> We needed a mechanism to enable the sysfs writes on certain properties.
>>> If DT is not the place where should it go?
>>
>> DT is not the place. As I discussed later with Andreas, if you really
>> need this and if mainline is a place for that then probably this should
>> be compile option (a Kconfig symbol).
>>
> 
> I think this would actually be a good use for module parameters, this way
> it could still be set at boot without re-compiling.
> 
> I think compile-time disabling sysfs properties because they are
> "dangerous" is
> a little bit too artificially restricting and controlling, you can set
> permissions
> so only root can change them already. The kernel should not be
> restricting root,
> I understand the fear of someone rooting a machine and remotely over
> charging
> a LiPo[1], but these physical limits are hardware descriptions and can
> and should
> be set by DT, beyond this root should have full control over their machine.


Indeed module parameters could be used for enabling/disabling debug
options... but as fair as I understand these are for purely development
purposes. That is why they got into DT initially, right? To allow the
developer to play with it on the development board?

This is why I am really not convinced that this should go to mainline.

Anyway if it goes, then maybe compiling it out is the safest choice?
What's the purpose of having it in kernel all the time? If this was a
debug option, than some experienced user could turn it on and report to
LKML with extended debug data. But it's not a debug but development option?

> Besides root can already just unbind your driver and issue raw I2C
> commands to do
> the same thing. 
> 
> [1] http://i.imgur.com/vszJJ.jpg

Oh, these weird sickos... That's why I am using IPoAC and always check
the bits by myself for weird looking I2C commands. :)

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 3/3] ibmvsci: Allow to configure maximum LUN

2015-09-10 Thread David Gibson
On Thu, 10 Sep 2015 11:23:14 +0200
Laurent Vivier  wrote:

> QEMU allows until 32 LUNs.
> 
> Signed-off-by: Laurent Vivier 

Reviewed-by: David Gibson 

> ---
>  drivers/scsi/ibmvscsi/ibmvscsi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c 
> b/drivers/scsi/ibmvscsi/ibmvscsi.c
> index f9d7ec4..e5478b0 100644
> --- a/drivers/scsi/ibmvscsi/ibmvscsi.c
> +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
> @@ -84,6 +84,7 @@
>   */
>  static int max_id = 64;
>  static int max_channel = 3;
> +static int max_lun = 8;
>  static int init_timeout = 300;
>  static int login_timeout = 60;
>  static int info_timeout = 30;
> @@ -117,6 +118,8 @@ module_param_named(fast_fail, fast_fail, int, S_IRUGO | 
> S_IWUSR);
>  MODULE_PARM_DESC(fast_fail, "Enable fast fail. [Default=1]");
>  module_param_named(client_reserve, client_reserve, int, S_IRUGO );
>  MODULE_PARM_DESC(client_reserve, "Attempt client managed reserve/release");
> +module_param(max_lun, int, S_IRUGO);
> +MODULE_PARM_DESC(max_lun, "Maximum LUN value [Default=8]");
>  
>  static void ibmvscsi_handle_crq(struct viosrp_crq *crq,
>   struct ibmvscsi_host_data *hostdata);
> @@ -2289,7 +2292,7 @@ static int ibmvscsi_probe(struct vio_dev *vdev, const 
> struct vio_device_id *id)
>   goto init_pool_failed;
>   }
>  
> - host->max_lun = 8;
> + host->max_lun = max_lun;
>   host->max_id = max_id;
>   host->max_channel = max_channel;
>   host->max_cmd_len = 16;
> -- 
> 2.1.0
> 


-- 
David Gibson 
Senior Software Engineer, Virtualization, Red Hat

-- 
David Gibson 
Senior Software Engineer, Virtualization, Red Hat


pgpEfjtj9S73m.pgp
Description: OpenPGP digital signature


Re: [PATCH 2/3] ibmvcsci: display default value for max_id, max_lun and max_channel.

2015-09-10 Thread David Gibson
On Thu, 10 Sep 2015 11:23:13 +0200
Laurent Vivier  wrote:

> As devices with values greater than that are silently ignored,
> this gives some hints to the sys admin to know why he doesn't see
> his devices...
> 
> Signed-off-by: Laurent Vivier 

Reviewed-by: David Gibson 

> ---
>  drivers/scsi/ibmvscsi/ibmvscsi.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c 
> b/drivers/scsi/ibmvscsi/ibmvscsi.c
> index 3e76490..f9d7ec4 100644
> --- a/drivers/scsi/ibmvscsi/ibmvscsi.c
> +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
> @@ -106,9 +106,9 @@ MODULE_LICENSE("GPL");
>  MODULE_VERSION(IBMVSCSI_VERSION);
>  
>  module_param_named(max_id, max_id, int, S_IRUGO);
> -MODULE_PARM_DESC(max_id, "Largest ID value for each channel");
> +MODULE_PARM_DESC(max_id, "Largest ID value for each channel [Default=64]");
>  module_param_named(max_channel, max_channel, int, S_IRUGO);
> -MODULE_PARM_DESC(max_channel, "Largest channel value");
> +MODULE_PARM_DESC(max_channel, "Largest channel value [Default=3]");
>  module_param_named(init_timeout, init_timeout, int, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(init_timeout, "Initialization timeout in seconds");
>  module_param_named(max_requests, max_requests, int, S_IRUGO);
> @@ -2294,6 +2294,10 @@ static int ibmvscsi_probe(struct vio_dev *vdev, const 
> struct vio_device_id *id)
>   host->max_channel = max_channel;
>   host->max_cmd_len = 16;
>  
> + dev_info(dev,
> +  "Maximum ID: %d Maximum LUN: %d Maximum Channel: %d\n",
> +  host->max_id, host->max_lun, host->max_channel);
> +
>   if (scsi_add_host(hostdata->host, hostdata->dev))
>   goto add_host_failed;
>  
> -- 
> 2.1.0
> 


-- 
David Gibson 
Senior Software Engineer, Virtualization, Red Hat


pgpJGdF6ot9pP.pgp
Description: OpenPGP digital signature


Re: [PATCH 1/3] ibmvsci: make parameters max_id and max_channel read-only

2015-09-10 Thread David Gibson
On Thu, 10 Sep 2015 11:23:12 +0200
Laurent Vivier  wrote:

> The value of the parameter is never re-read by the driver,
> so a new value is ignored. Let know the user he
> can't modify it by removing writable attribute.
> 
> Signed-off-by: Laurent Vivier 

Reviewed-by: David Gibson 

> ---
> I resend this patch as James was not cc'ed.
> 
>  drivers/scsi/ibmvscsi/ibmvscsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c 
> b/drivers/scsi/ibmvscsi/ibmvscsi.c
> index 6a41c36..3e76490 100644
> --- a/drivers/scsi/ibmvscsi/ibmvscsi.c
> +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
> @@ -105,9 +105,9 @@ MODULE_AUTHOR("Dave Boutcher");
>  MODULE_LICENSE("GPL");
>  MODULE_VERSION(IBMVSCSI_VERSION);
>  
> -module_param_named(max_id, max_id, int, S_IRUGO | S_IWUSR);
> +module_param_named(max_id, max_id, int, S_IRUGO);
>  MODULE_PARM_DESC(max_id, "Largest ID value for each channel");
> -module_param_named(max_channel, max_channel, int, S_IRUGO | S_IWUSR);
> +module_param_named(max_channel, max_channel, int, S_IRUGO);
>  MODULE_PARM_DESC(max_channel, "Largest channel value");
>  module_param_named(init_timeout, init_timeout, int, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(init_timeout, "Initialization timeout in seconds");
> -- 
> 2.1.0
> 


-- 
David Gibson 
Senior Software Engineer, Virtualization, Red Hat


pgp8FMjBxPoUU.pgp
Description: OpenPGP digital signature


Re: [PATCH 1/3] lib/kobject_uevent.c: disable broadcast of uevents to other namespaces

2015-09-10 Thread Eric W. Biederman
"Michael J. Coss"  writes:

> Restrict sending uevents to only those listeners operating in the same
> network namespace as the system init process.  This is the first step
> toward allowing policy control of the forwarding of events to other
> namespaces in userspace.

This limitation whould be better if we only skipped network namespaces
where you are sending spoofed uevents.

As it sits this has the possibility to break userspace.

Eric

> Signed-off-by: Michael J. Coss 
> ---
>  lib/kobject_uevent.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> index f6c2c1e..d791e33 100644
> --- a/lib/kobject_uevent.c
> +++ b/lib/kobject_uevent.c
> @@ -295,6 +295,10 @@ int kobject_uevent_env(struct kobject *kobj, enum 
> kobject_action action,
>   if (!netlink_has_listeners(uevent_sock, 1))
>   continue;
>  
> + /* forward event only to the host systems network namespaces */
> + if (!net_eq(sock_net(uevent_sock), _net))
> + continue;
> +
>   /* allocate message with the maximum possible size */
>   len = strlen(action_string) + strlen(devpath) + 2;
>   skb = alloc_skb(len + env->buflen, GFP_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/


RE: [PATCH] ARM: at91/dt: sama5d3 xplained: disable pmic

2015-09-10 Thread Yang, Wenyou


> -Original Message-
> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
> Sent: 2015年9月10日 22:59
> To: Yang, Wenyou; Alexandre Belloni; Jean-Christophe PLAGNIOL-VILLARD
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Ferre,
> Nicolas
> Subject: [PATCH] ARM: at91/dt: sama5d3 xplained: disable pmic
> 
> As PMIC act8865 can disturb communication on i2c1, and as it should be setup
> correctly then its i2c interface disabled by bootloader, we simply disregard 
> it in DT.
> 
> Signed-off-by: Nicolas Ferre 

Indeed,

Acked-by: Wenyou Yang 

> ---
>  arch/arm/boot/dts/at91-sama5d3_xplained.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts 
> b/arch/arm/boot/dts/at91-
> sama5d3_xplained.dts
> index d81474e0bcd6..8488ac53d22d 100644
> --- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> @@ -76,7 +76,7 @@
>   pmic: act8865@5b {
>   compatible = "active-semi,act8865";
>   reg = <0x5b>;
> - status = "okay";
> + status = "disabled";
> 
>   regulators {
>   vcc_1v8_reg: DCDC_REG1 {
> --
> 2.1.3

Best Regards,
Wenyou Yang


Re: mmotm 2015-09-10-16-30 uploaded

2015-09-10 Thread Stephen Rothwell
Hi Andrew,

On Thu, 10 Sep 2015 16:30:54 -0700 a...@linux-foundation.org wrote:
>
>   sys_membarrier-system-wide-memory-barrier-generic-x86.patch

Because that patch is not in the set for -next ...

> * mm-mlock-add-new-mlock-system-call.patch

This did not apply properly.  I ended up with:

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 477bfa6db370..41e72a50c2ed 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -381,3 +381,4 @@
 372i386recvmsg sys_recvmsg 
compat_sys_recvmsg
 373i386shutdownsys_shutdown
 374i386userfaultfd sys_userfaultfd
+375i386mlock2  sys_mlock2
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl 
b/arch/x86/entry/syscalls/syscall_64.tbl
index 81c490634db9..23669007b85d 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -330,6 +330,7 @@
 321common  bpf sys_bpf
 32264  execveatstub_execveat
 323common  userfaultfd sys_userfaultfd
+324common  mlock2  sys_mlock2
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 08001317aee7..890632cbf353 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -885,4 +885,6 @@ asmlinkage long sys_execveat(int dfd, const char __user 
*filename,
const char __user *const __user *argv,
const char __user *const __user *envp, int flags);
 
+asmlinkage long sys_mlock2(unsigned long start, size_t len, int flags);
+
 #endif
diff --git a/include/uapi/asm-generic/unistd.h 
b/include/uapi/asm-generic/unistd.h
index e016bd9b1a04..14a6013cbdac 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -709,9 +709,11 @@ __SYSCALL(__NR_memfd_create, sys_memfd_create)
 __SYSCALL(__NR_bpf, sys_bpf)
 #define __NR_execveat 281
 __SC_COMP(__NR_execveat, sys_execveat, compat_sys_execveat)
+#define __NR_mlock2 282
+__SYSCALL(__NR_mlock2, sys_mlock2)
 
 #undef __NR_syscalls
-#define __NR_syscalls 282
+#define __NR_syscalls 283
 
 /*
  * All syscalls below here should go away really,
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 03c3875d9958..8de5b2645796 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -194,6 +194,7 @@ cond_syscall(sys_mlock);
 cond_syscall(sys_munlock);
 cond_syscall(sys_mlockall);
 cond_syscall(sys_munlockall);
+cond_syscall(sys_mlock2);
 cond_syscall(sys_mincore);
 cond_syscall(sys_madvise);
 cond_syscall(sys_mremap);
diff --git a/mm/mlock.c b/mm/mlock.c
index c32ad8f6a9d1..fb6912f3efe6 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -644,6 +644,15 @@ SYSCALL_DEFINE2(mlock, unsigned long, start, size_t, len)
return do_mlock(start, len, VM_LOCKED);
 }
 
+SYSCALL_DEFINE3(mlock2, unsigned long, start, size_t, len, int, flags)
+{
+   vm_flags_t vm_flags = VM_LOCKED;
+   if (flags)
+   return -EINVAL;
+
+   return do_mlock(start, len, vm_flags);
+}
+
 SYSCALL_DEFINE2(munlock, unsigned long, start, size_t, len)
 {
int ret;

> * page-flags-introduce-page-flags-policies-wrt-compound-pages-fix.patch

That did not apply either because proc-add-kpageidle-file.patch is
not among the -next included stuff. I just dropped it.

Everything else applied fine ...
-- 
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/


[PATCH v2 1/5] ebpf: add a seccomp program type

2015-09-10 Thread Tycho Andersen
seccomp uses eBPF as its underlying storage and execution format, and eBPF
has features that seccomp would like to make use of in the future. This
patch adds a formal seccomp type to the eBPF verifier.

The current implementation of the seccomp eBPF type is very limited, and
doesn't support some interesting features (notably, maps) of eBPF. However,
the primary motivation for this patchset is to enable checkpoint/restore
for seccomp filters later in the series, to this limited feature set is ok
for now.

v2: * don't allow seccomp eBPF programs to call any functions
* get rid of superfluous seccomp_convert_ctx_access

Signed-off-by: Tycho Andersen 
CC: Kees Cook 
CC: Will Drewry 
CC: Oleg Nesterov 
CC: Andy Lutomirski 
CC: Pavel Emelyanov 
CC: Serge E. Hallyn 
CC: Alexei Starovoitov 
CC: Daniel Borkmann 
---
 include/uapi/linux/bpf.h |  1 +
 net/core/filter.c| 31 +++
 2 files changed, 32 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 92a48e2..631cdee 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -123,6 +123,7 @@ enum bpf_prog_type {
BPF_PROG_TYPE_KPROBE,
BPF_PROG_TYPE_SCHED_CLS,
BPF_PROG_TYPE_SCHED_ACT,
+   BPF_PROG_TYPE_SECCOMP,
 };
 
 #define BPF_PSEUDO_MAP_FD  1
diff --git a/net/core/filter.c b/net/core/filter.c
index 13079f0..faaae67 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1612,6 +1612,15 @@ tc_cls_act_func_proto(enum bpf_func_id func_id)
}
 }
 
+static const struct bpf_func_proto *
+seccomp_func_proto(enum bpf_func_id func_id)
+{
+   /* At some point in the future seccomp filters may grow support for
+* eBPF functions. For now, these are disabled.
+*/
+   return NULL;
+}
+
 static bool __is_valid_access(int off, int size, enum bpf_access_type type)
 {
/* check bounds */
@@ -1662,6 +1671,17 @@ static bool tc_cls_act_is_valid_access(int off, int size,
return __is_valid_access(off, size, type);
 }
 
+static bool seccomp_is_valid_access(int off, int size,
+   enum bpf_access_type type)
+{
+   if (type == BPF_WRITE)
+   return false;
+
+   if (off < 0 || off >= sizeof(struct seccomp_data) || off & 3)
+   return false;
+
+   return true;
+}
 static u32 bpf_net_convert_ctx_access(enum bpf_access_type type, int dst_reg,
  int src_reg, int ctx_off,
  struct bpf_insn *insn_buf)
@@ -1795,6 +1815,11 @@ static const struct bpf_verifier_ops tc_cls_act_ops = {
.convert_ctx_access = bpf_net_convert_ctx_access,
 };
 
+static const struct bpf_verifier_ops seccomp_ops = {
+   .get_func_proto = seccomp_func_proto,
+   .is_valid_access = seccomp_is_valid_access,
+};
+
 static struct bpf_prog_type_list sk_filter_type __read_mostly = {
.ops = _filter_ops,
.type = BPF_PROG_TYPE_SOCKET_FILTER,
@@ -1810,11 +1835,17 @@ static struct bpf_prog_type_list sched_act_type 
__read_mostly = {
.type = BPF_PROG_TYPE_SCHED_ACT,
 };
 
+static struct bpf_prog_type_list seccomp_type __read_mostly = {
+   .ops = _ops,
+   .type = BPF_PROG_TYPE_SECCOMP,
+};
+
 static int __init register_sk_filter_ops(void)
 {
bpf_register_prog_type(_filter_type);
bpf_register_prog_type(_cls_type);
bpf_register_prog_type(_act_type);
+   bpf_register_prog_type(_type);
 
return 0;
 }
-- 
2.1.4

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


[PATCH v2 2/5] seccomp: make underlying bpf ref counted as well

2015-09-10 Thread Tycho Andersen
In the next patch, we're going to add a way to access the underlying
filters via bpf fds. This means that we need to ref-count both the
struct seccomp_filter objects and the struct bpf_prog objects separately,
in case a process dies but a filter is still referred to by another
process.

Additionally, we mark classic converted seccomp filters as seccomp eBPF
programs, since they are a subset of what is supported in seccomp eBPF.

Signed-off-by: Tycho Andersen 
CC: Kees Cook 
CC: Will Drewry 
CC: Oleg Nesterov 
CC: Andy Lutomirski 
CC: Pavel Emelyanov 
CC: Serge E. Hallyn 
CC: Alexei Starovoitov 
CC: Daniel Borkmann 
---
 kernel/seccomp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 245df6b..afaeddf 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -378,6 +378,8 @@ static struct seccomp_filter *seccomp_prepare_filter(struct 
sock_fprog *fprog)
}
 
atomic_set(>usage, 1);
+   atomic_set(>prog->aux->refcnt, 1);
+   sfilter->prog->type = BPF_PROG_TYPE_SECCOMP;
 
return sfilter;
 }
@@ -470,7 +472,7 @@ void get_seccomp_filter(struct task_struct *tsk)
 static inline void seccomp_filter_free(struct seccomp_filter *filter)
 {
if (filter) {
-   bpf_prog_free(filter->prog);
+   bpf_prog_put(filter->prog);
kfree(filter);
}
 }
-- 
2.1.4

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


[PATCH v2 5/5] seccomp: add a way to attach a filter via eBPF fd

2015-09-10 Thread Tycho Andersen
This is the final bit needed to support seccomp filters created via the bpf
syscall. The patch adds a new seccomp operation SECCOMP_MODE_FILTER_EBPF,
which takes exactly one command (presumably to be expanded upon later when
seccomp EBPFs support more interesting things) and an argument struct
similar to that of bpf(), although the size is explicit in the struct to
avoid changing the signature of seccomp().

v2: Don't abuse seccomp's third argument; use a separate command and a
pointer to a structure instead.

Signed-off-by: Tycho Andersen 
CC: Kees Cook 
CC: Will Drewry 
CC: Oleg Nesterov 
CC: Andy Lutomirski 
CC: Pavel Emelyanov 
CC: Serge E. Hallyn 
CC: Alexei Starovoitov 
CC: Daniel Borkmann 
---
 include/uapi/linux/seccomp.h |  16 +
 kernel/seccomp.c | 135 ++-
 2 files changed, 138 insertions(+), 13 deletions(-)

diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index 0f238a4..a8694e2 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -13,10 +13,14 @@
 /* Valid operations for seccomp syscall. */
 #define SECCOMP_SET_MODE_STRICT0
 #define SECCOMP_SET_MODE_FILTER1
+#define SECCOMP_MODE_FILTER_EBPF   2
 
 /* Valid flags for SECCOMP_SET_MODE_FILTER */
 #define SECCOMP_FILTER_FLAG_TSYNC  1
 
+/* Valid cmds for SECCOMP_MODE_FILTER_EBPF */
+#define SECCOMP_EBPF_ADD_FD0
+
 /*
  * All BPF programs must return a 32-bit value.
  * The bottom 16-bits are for optional return data.
@@ -51,4 +55,16 @@ struct seccomp_data {
__u64 args[6];
 };
 
+struct seccomp_ebpf {
+   unsigned int size;
+
+   union {
+   /* SECCOMP_EBPF_ADD_FD */
+   struct {
+   unsigned intadd_flags;
+   __u32   add_fd;
+   };
+   };
+};
+
 #endif /* _UAPI_LINUX_SECCOMP_H */
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 1856f69..e78175a 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -65,6 +65,9 @@ struct seccomp_filter {
 /* Limit any path through the tree to 256KB worth of instructions. */
 #define MAX_INSNS_PER_PATH ((1 << 18) / sizeof(struct sock_filter))
 
+static long seccomp_install_filter(unsigned int flags,
+  struct seccomp_filter *prepared);
+
 /*
  * Endianness is explicitly ignored and left for BPF program authors to manage
  * as per the specific architecture.
@@ -356,17 +359,6 @@ static struct seccomp_filter 
*seccomp_prepare_filter(struct sock_fprog *fprog)
 
BUG_ON(INT_MAX / fprog->len < sizeof(struct sock_filter));
 
-   /*
-* Installing a seccomp filter requires that the task has
-* CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
-* This avoids scenarios where unprivileged tasks can affect the
-* behavior of privileged children.
-*/
-   if (!task_no_new_privs(current) &&
-   security_capable_noaudit(current_cred(), current_user_ns(),
-CAP_SYS_ADMIN) != 0)
-   return ERR_PTR(-EACCES);
-
/* Allocate a new seccomp_filter */
sfilter = kzalloc(sizeof(*sfilter), GFP_KERNEL | __GFP_NOWARN);
if (!sfilter)
@@ -510,8 +502,105 @@ static void seccomp_send_sigsys(int syscall, int reason)
info.si_syscall = syscall;
force_sig_info(SIGSYS, , current);
 }
+
 #endif /* CONFIG_SECCOMP_FILTER */
 
+#if defined(CONFIG_BPF_SYSCALL) && defined(CONFIG_SECCOMP_FILTER)
+static struct seccomp_filter *seccomp_prepare_ebpf(int fd)
+{
+   struct seccomp_filter *ret;
+   struct bpf_prog *prog;
+
+   prog = bpf_prog_get(fd);
+   if (IS_ERR(prog))
+   return (struct seccomp_filter *) prog;
+
+   if (prog->type != BPF_PROG_TYPE_SECCOMP) {
+   bpf_prog_put(prog);
+   return ERR_PTR(-EINVAL);
+   }
+
+   ret = kzalloc(sizeof(*ret), GFP_KERNEL | __GFP_NOWARN);
+   if (!ret) {
+   bpf_prog_put(prog);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   ret->prog = prog;
+   atomic_set(>usage, 1);
+
+   /* Intentionally don't bpf_prog_put() here, because the underlying prog
+* is refcounted too and we're holding a reference from the struct
+* seccomp_filter object.
+*/
+   return ret;
+}
+
+static long seccomp_ebpf_add_fd(struct seccomp_ebpf *ebpf)
+{
+   struct seccomp_filter *prepared;
+
+   prepared = seccomp_prepare_ebpf(ebpf->add_fd);
+   if (IS_ERR(prepared))
+   return PTR_ERR(prepared);
+
+   return seccomp_install_filter(ebpf->add_flags, prepared);
+}
+
+static long seccomp_mode_filter_ebpf(unsigned int cmd, const char __user 
*uargs)
+{
+   const struct seccomp_ebpf __user *uebpf;
+   struct seccomp_ebpf ebpf;
+   unsigned int size;
+   long ret = -EFAULT;
+
+   uebpf = (const struct seccomp_ebpf __user *) uargs;
+
+   if 

[PATCH v2 3/5] ebpf: add a way to dump an eBPF program

2015-09-10 Thread Tycho Andersen
This commit adds a way to dump eBPF programs. The initial implementation
doesn't support maps, and therefore only allows dumping seccomp ebpf
programs which themselves don't currently support maps.

v2: don't export a prog_id for the filter

Signed-off-by: Tycho Andersen 
CC: Kees Cook 
CC: Will Drewry 
CC: Oleg Nesterov 
CC: Andy Lutomirski 
CC: Pavel Emelyanov 
CC: Serge E. Hallyn 
CC: Alexei Starovoitov 
CC: Daniel Borkmann 
---
 include/uapi/linux/bpf.h | 14 ++
 kernel/bpf/syscall.c | 41 +
 2 files changed, 55 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 631cdee..e037a76 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -107,6 +107,13 @@ enum bpf_cmd {
 * returns fd or negative error
 */
BPF_PROG_LOAD,
+
+   /* dump an existing bpf
+* err = bpf(BPF_PROG_DUMP, union bpf_attr *attr, u32 size)
+* Using attr->prog_fd, attr->dump_insn_cnt, attr->dump_insns
+* returns zero or negative error
+*/
+   BPF_PROG_DUMP,
 };
 
 enum bpf_map_type {
@@ -161,6 +168,13 @@ union bpf_attr {
__aligned_u64   log_buf;/* user supplied buffer */
__u32   kern_version;   /* checked when 
prog_type=kprobe */
};
+
+   struct { /* anonymous struct used by BPF_PROG_DUMP command */
+   __u32   prog_fd;
+   __u32   dump_insn_cnt;
+   __aligned_u64   dump_insns; /* user supplied buffer */
+   __u8gpl_compatible;
+   };
 } __attribute__((aligned(8)));
 
 /* integer value in 'imm' field of BPF_CALL instruction selects which helper
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index dc9b464..58ae9f4 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -586,6 +586,44 @@ free_prog:
return err;
 }
 
+static int bpf_prog_dump(union bpf_attr *attr, union bpf_attr __user *uattr)
+{
+   int ufd = attr->prog_fd;
+   struct fd f = fdget(ufd);
+   struct bpf_prog *prog;
+   int ret = -EINVAL;
+
+   prog = get_prog(f);
+   if (IS_ERR(prog))
+   return PTR_ERR(prog);
+
+   /* For now, let's refuse to dump anything that isn't a seccomp program.
+* Other program types have support for maps, which our current dump
+* code doesn't support.
+*/
+   if (prog->type != BPF_PROG_TYPE_SECCOMP)
+   goto out;
+
+   ret = -EFAULT;
+   if (put_user(prog->len, >dump_insn_cnt))
+   goto out;
+
+   if (put_user((u8) prog->gpl_compatible, >gpl_compatible))
+   goto out;
+
+   if (attr->dump_insns) {
+   u32 len = prog->len * sizeof(struct bpf_insn);
+
+   if (copy_to_user(u64_to_ptr(attr->dump_insns),
+prog->insns, len) != 0)
+   goto out;
+   }
+
+   ret = 0;
+out:
+   return ret;
+}
+
 SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, 
size)
 {
union bpf_attr attr = {};
@@ -650,6 +688,9 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, 
uattr, unsigned int, siz
case BPF_PROG_LOAD:
err = bpf_prog_load();
break;
+   case BPF_PROG_DUMP:
+   err = bpf_prog_dump(, uattr);
+   break;
default:
err = -EINVAL;
break;
-- 
2.1.4

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


[PATCH v2 4/5] seccomp: add a way to access filters via bpf fds

2015-09-10 Thread Tycho Andersen
This patch adds a way for a process that is "real root" to access the
seccomp filters of another process. The process first does a
PTRACE_SECCOMP_GET_FILTER_FD to get an fd with that process' seccomp filter
attached, and then iterates on this with PTRACE_SECCOMP_NEXT_FILTER using
bpf(BPF_PROG_DUMP) to dump the actual program at each step.

Signed-off-by: Tycho Andersen 
CC: Kees Cook 
CC: Will Drewry 
CC: Oleg Nesterov 
CC: Andy Lutomirski 
CC: Pavel Emelyanov 
CC: Serge E. Hallyn 
CC: Alexei Starovoitov 
CC: Daniel Borkmann 
---
 include/linux/bpf.h | 12 ++
 include/linux/seccomp.h | 14 +++
 include/uapi/linux/ptrace.h |  3 +++
 kernel/bpf/syscall.c| 26 -
 kernel/ptrace.c |  7 ++
 kernel/seccomp.c| 57 +
 6 files changed, 118 insertions(+), 1 deletion(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index f57d7fe..bfd9cab 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -162,6 +162,8 @@ void bpf_register_prog_type(struct bpf_prog_type_list *tl);
 void bpf_register_map_type(struct bpf_map_type_list *tl);
 
 struct bpf_prog *bpf_prog_get(u32 ufd);
+int bpf_prog_set(u32 ufd, struct bpf_prog *new);
+int bpf_new_fd(struct bpf_prog *prog, int flags);
 void bpf_prog_put(struct bpf_prog *prog);
 void bpf_prog_put_rcu(struct bpf_prog *prog);
 
@@ -180,6 +182,16 @@ static inline struct bpf_prog *bpf_prog_get(u32 ufd)
return ERR_PTR(-EOPNOTSUPP);
 }
 
+static inline int bpf_prog_set(u32 ufd, struct bpf_prog *new)
+{
+   return -EINVAL;
+}
+
+static inline int bpf_new_fd(struct bpf_prog *prog, int flags)
+{
+   return -EINVAL;
+}
+
 static inline void bpf_prog_put(struct bpf_prog *prog)
 {
 }
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index a19ddac..41b083c 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -95,4 +95,18 @@ static inline void get_seccomp_filter(struct task_struct 
*tsk)
return;
 }
 #endif /* CONFIG_SECCOMP_FILTER */
+
+#if defined(CONFIG_SECCOMP_FILTER) && defined(CONFIG_CHECKPOINT_RESTORE)
+extern long seccomp_get_filter_fd(struct task_struct *child);
+extern long seccomp_next_filter(struct task_struct *child, u32 fd);
+#else
+static inline long seccomp_get_filter_fd(struct task_struct *child)
+{
+   return -EINVAL;
+}
+static inline long seccomp_next_filter(struct task_struct *child, u32 fd)
+{
+   return -EINVAL;
+}
+#endif /* CONFIG_SECCOMP_FILTER && CONFIG_CHECKPOINT_RESTORE */
 #endif /* _LINUX_SECCOMP_H */
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index cf1019e..041c3c3 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -23,6 +23,9 @@
 
 #define PTRACE_SYSCALL   24
 
+#define PTRACE_SECCOMP_GET_FILTER_FD   40
+#define PTRACE_SECCOMP_NEXT_FILTER 41
+
 /* 0x4200-0x4300 are reserved for architecture-independent additions.  */
 #define PTRACE_SETOPTIONS  0x4200
 #define PTRACE_GETEVENTMSG 0x4201
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 58ae9f4..ac3ed1c 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -506,6 +506,30 @@ struct bpf_prog *bpf_prog_get(u32 ufd)
 }
 EXPORT_SYMBOL_GPL(bpf_prog_get);
 
+int bpf_prog_set(u32 ufd, struct bpf_prog *new)
+{
+   struct fd f;
+   struct bpf_prog *prog;
+
+   f = fdget(ufd);
+
+   prog = get_prog(f);
+   if (!IS_ERR(prog) && prog)
+   bpf_prog_put(prog);
+
+   atomic_inc(>aux->refcnt);
+   f.file->private_data = new;
+   fdput(f);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(bpf_prog_set);
+
+int bpf_new_fd(struct bpf_prog *prog, int flags)
+{
+   return anon_inode_getfd("bpf-prog", _prog_fops, prog, flags);
+}
+EXPORT_SYMBOL_GPL(bpf_new_fd);
+
 /* last field in 'union bpf_attr' used by this command */
 #defineBPF_PROG_LOAD_LAST_FIELD kern_version
 
@@ -572,7 +596,7 @@ static int bpf_prog_load(union bpf_attr *attr)
if (err < 0)
goto free_used_maps;
 
-   err = anon_inode_getfd("bpf-prog", _prog_fops, prog, O_RDWR | 
O_CLOEXEC);
+   err = bpf_new_fd(prog, O_RDWR | O_CLOEXEC);
if (err < 0)
/* failed to allocate fd */
goto free_used_maps;
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index c8e0e05..a151c35 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -1003,6 +1003,13 @@ int ptrace_request(struct task_struct *child, long 
request,
break;
}
 #endif
+
+   case PTRACE_SECCOMP_GET_FILTER_FD:
+   return seccomp_get_filter_fd(child);
+
+   case PTRACE_SECCOMP_NEXT_FILTER:
+   return seccomp_next_filter(child, data);
+
default:
break;
}
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index afaeddf..1856f69 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -26,6 +26,8 @@
 #endif
 
 #ifdef CONFIG_SECCOMP_FILTER
+#include 

  1   2   3   4   5   6   7   8   9   10   >