Re: [PATCH 7/8] cgroup: Add documentation for cgroup namespaces

[Serge Hallyn]

On Mon Dec 28 2015 09:47:35 AM PST, Tejun Heo  wrote:

> Hello,
> 
> I did some heavy editing of the documentation.  How does this look?

Thanks Tejun, just three things (which come from my version):

> Did I miss anything?
> 
> Thanks.
> ---
>  Documentation/cgroup.txt |  146
> +++ 1 file changed, 146
> insertions(+)
> 
> --- a/Documentation/cgroup.txt
> +++ b/Documentation/cgroup.txt
> @@ -47,6 +47,11 @@ CONTENTS
>      5-3. IO
>          5-3-1. IO Interface Files
>          5-3-2. Writeback
> +6. Namespace
> +  6-1. Basics
> +  6-2. The Root and Views
> +  6-3. Migration and setns(2)
> +  6-4. Interaction with Other Namespaces
>  P. Information on Kernel Programming
>      P-1. Filesystem Support for Writeback
>  D. Deprecated v1 Core Features
> @@ -1013,6 +1018,147 @@ writeback as follows.
>      vm.dirty[_background]_ratio.
>  
>  
> +6. Namespace
> +
> +6-1. Basics
> +
> +cgroup namespace provides a mechanism to virtualize the view of the
> +"/proc/$PID/cgroup" file

and cgroup mounts

>.  The CLONE_NEWCGROUP clone flag can be used
> +with clone(2) and unshare(2) to create a new cgroup namespace.  The
> +process running inside the cgroup namespace will have its
> +"/proc/$PID/cgroup" output restricted to cgroupns root.  The cgroupns
> +root is the cgroup of the process at the time of creation of the
> +cgroup namespace.
> +
> +Without cgroup namespace, the "/proc/$PID/cgroup" file shows the
> +complete path of the cgroup of a process.  In a container setup where
> +a set of cgroups and namespaces are intended to isolate processes the
> +"/proc/$PID/cgroup" file may leak potential system level information
> +to the isolated processes.  For Example:
> +
> +  # cat /proc/self/cgroup
> +  0::/batchjobs/container_id1
> +
> +The path '/batchjobs/container_id1' can be considered as system-data
> +and undesirable to expose to the isolated processes.  cgroup namespace
> +can be used to restrict visibility of this path.  For example, before
> +creating a cgroup namespace, one would see:
> +
> +  # ls -l /proc/self/ns/cgroup
> +  lrwxrwxrwx 1 root root 0 2014-07-15 10:37 /proc/self/ns/cgroup ->
> cgroup:[4026531835] +  # cat /proc/self/cgroup
> +  0::/batchjobs/container_id1
> +
> +After unsharing a new namespace, the view changes.
> +
> +  # ls -l /proc/self/ns/cgroup
> +  lrwxrwxrwx 1 root root 0 2014-07-15 10:35 /proc/self/ns/cgroup ->
> cgroup:[4026532183] +  # cat /proc/self/cgroup
> +  0::/
> +
> +When some thread from a multi-threaded process unshares its cgroup
> +namespace, the new cgroupns gets applied to the entire process (all
> +the threads).  This is natural for the v2 hierarchy; however, for the
> +legacy hierarchies, this may be unexpected.
> +
> +A cgroup namespace is alive as long as there are processes inside it.

Or mounts pinning it.

> +When the last process exits

or the last mount is umounted,

>, the cgroup namespace is destroyed.  The
> +cgroupns root and the actual cgroups remain.
> +
> +
> +6-2. The Root and Views
> +
> +The 'cgroupns root' for a cgroup namespace is the cgroup in which the
> +process calling unshare(2) is running.  For example, if a process in
> +/batchjobs/container_id1 cgroup calls unshare, cgroup
> +/batchjobs/container_id1 becomes the cgroupns root.  For the
> +init_cgroup_ns, this is the real root ('/') cgroup.
> +
> +The cgroupns root cgroup does not change even if the namespace creator
> +process later moves to a different cgroup.
> +
> +  # ~/unshare -c # unshare cgroupns in some cgroup
> +  # cat /proc/self/cgroup
> +  0::/
> +  # mkdir sub_cgrp_1
> +  # echo 0 > sub_cgrp_1/cgroup.procs
> +  # cat /proc/self/cgroup
> +  0::/sub_cgrp_1
> +
> +Each process gets its namespace-specific view of "/proc/$PID/cgroup"
> +
> +Processes running inside the cgroup namespace will be able to see
> +cgroup paths (in /proc/self/cgroup) only inside their root cgroup.
> +From within an unshared cgroupns:
> +
> +  # sleep 10 &
> +  [1] 7353
> +  # echo 7353 > sub_cgrp_1/cgroup.procs
> +  # cat /proc/7353/cgroup
> +  0::/sub_cgrp_1
> +
> +From the initial cgroup namespace, the real cgroup path will be
> +visible:
> +
> +  $ cat /proc/7353/cgroup
> +  0::/batchjobs/container_id1/sub_cgrp_1
> +
> +From a sibling cgroup namespace (that is, a namespace rooted at a
> +different cgroup), the cgroup path relative to its own cgroup
> +namespace root will be shown.  For instance, if PID 7353's cgroup
> +namespace root is at '/batchjobs/container_id2', then it will see
> +
> +  # cat /proc/7353/cgroup
> +  0::/../container_id2/sub_cgrp_1
> +
> +Note that the relative path always starts with '/' to indicate that
> +its relative to the cgroup namespace root of the caller.
> +
> +
> +6-3. Migration and setns(2)
> +

Re: [PATCH v2] usb: gadget: fix double mem free for usb_request caused by wild pointers

[Laurent Pinchart]

Hi Changbin,

Thank you for the patch.

On Monday 28 December 2015 14:25:50 changbin...@intel.com wrote:
> From: "Du, Changbin" 
> 
> acm, ecm, hid, ncm, phonet, rndis and uvc functions all have double
> memory free issue. Set pointers to NULL after freed to avoid this.

For drivers/usb/gadget/function/f_uvc.c,

Reviewed-by: Laurent Pinchart 

> Here explain how it happen on acm function, others has analogical case.
> 
> If acm_bind fails before allocate notification and acm->notify_req is
> not set to NULL after freed last time, double free will happen.
> 
> kernel BUG at mm/slub.c:3392!
> invalid opcode:  [#1] PREEMPT SMP
> EIP is at kfree+0x172/0x180
> Call Trace:
> [<80c0e3b6>] ? usb_ep_autoconfig_ss+0x86/0x170
> [<80c13345>] gs_free_req+0x15/0x30
> [<80c12df1>] acm_bind+0x1c1/0x2d0
> [<80c0e9be>] usb_add_function+0x6e/0x120
> [<80c213cb>] acm_function_bind_config+0x2b/0x90
> 
> Signed-off-by: Du, Changbin 
> ---
> changes from v1:
>   1. add same fix for ecm, hid, ncm... fucntions
>   2. patch title changed
> ---
>  drivers/usb/gadget/function/f_acm.c|  8 ++--
>  drivers/usb/gadget/function/f_ecm.c|  2 ++
>  drivers/usb/gadget/function/f_hid.c|  5 -
>  drivers/usb/gadget/function/f_ncm.c|  2 ++
>  drivers/usb/gadget/function/f_phonet.c | 11 ---
>  drivers/usb/gadget/function/f_rndis.c  |  2 ++
>  drivers/usb/gadget/function/f_uvc.c|  5 -
>  7 files changed, 28 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_acm.c
> b/drivers/usb/gadget/function/f_acm.c index 2fa1e80..e10c8d4 100644
> --- a/drivers/usb/gadget/function/f_acm.c
> +++ b/drivers/usb/gadget/function/f_acm.c
> @@ -699,8 +699,10 @@ acm_bind(struct usb_configuration *c, struct
> usb_function *f) return 0;
> 
>  fail:
> - if (acm->notify_req)
> + if (acm->notify_req) {
>   gs_free_req(acm->notify, acm->notify_req);
> + acm->notify_req = NULL;
> + }
> 
>   ERROR(cdev, "%s/%p: can't bind, err %d\n", f->name, f, status);
> 
> @@ -713,8 +715,10 @@ static void acm_unbind(struct usb_configuration *c,
> struct usb_function *f)
> 
>   acm_string_defs[0].id = 0;
>   usb_free_all_descriptors(f);
> - if (acm->notify_req)
> + if (acm->notify_req) {
>   gs_free_req(acm->notify, acm->notify_req);
> + acm->notify_req = NULL;
> + }
>  }
> 
>  static void acm_free_func(struct usb_function *f)
> diff --git a/drivers/usb/gadget/function/f_ecm.c
> b/drivers/usb/gadget/function/f_ecm.c index 7ad60ee..23092a2 100644
> --- a/drivers/usb/gadget/function/f_ecm.c
> +++ b/drivers/usb/gadget/function/f_ecm.c
> @@ -809,6 +809,7 @@ fail:
>   if (ecm->notify_req) {
>   kfree(ecm->notify_req->buf);
>   usb_ep_free_request(ecm->notify, ecm->notify_req);
> + ecm->notify_req = NULL;
>   }
> 
>   ERROR(cdev, "%s: can't bind, err %d\n", f->name, status);
> @@ -907,6 +908,7 @@ static void ecm_unbind(struct usb_configuration *c,
> struct usb_function *f)
> 
>   kfree(ecm->notify_req->buf);
>   usb_ep_free_request(ecm->notify, ecm->notify_req);
> + ecm->notify_req = NULL;
>  }
> 
>  static struct usb_function *ecm_alloc(struct usb_function_instance *fi)
> diff --git a/drivers/usb/gadget/function/f_hid.c
> b/drivers/usb/gadget/function/f_hid.c index 99285b4..827e385 100644
> --- a/drivers/usb/gadget/function/f_hid.c
> +++ b/drivers/usb/gadget/function/f_hid.c
> @@ -679,8 +679,10 @@ fail:
>   ERROR(f->config->cdev, "hidg_bind FAILED\n");
>   if (hidg->req != NULL) {
>   kfree(hidg->req->buf);
> - if (hidg->in_ep != NULL)
> + if (hidg->in_ep != NULL) {
>   usb_ep_free_request(hidg->in_ep, hidg->req);
> + hidg->req = NULL;
> + }
>   }
> 
>   return status;
> @@ -912,6 +914,7 @@ static void hidg_unbind(struct usb_configuration *c,
> struct usb_function *f) usb_ep_disable(hidg->in_ep);
>   kfree(hidg->req->buf);
>   usb_ep_free_request(hidg->in_ep, hidg->req);
> + hidg->req = NULL;
> 
>   usb_free_all_descriptors(f);
>  }
> diff --git a/drivers/usb/gadget/function/f_ncm.c
> b/drivers/usb/gadget/function/f_ncm.c index 7ad798a..510d1d7 100644
> --- a/drivers/usb/gadget/function/f_ncm.c
> +++ b/drivers/usb/gadget/function/f_ncm.c
> @@ -1459,6 +1459,7 @@ fail:
>   if (ncm->notify_req) {
>   kfree(ncm->notify_req->buf);
>   usb_ep_free_request(ncm->notify, ncm->notify_req);
> + ncm->notify_req = NULL;
>   }
> 
>   ERROR(cdev, "%s: can't bind, err %d\n", f->name, status);
> @@ -1561,6 +1562,7 @@ static void ncm_unbind(struct usb_configuration *c,
> struct usb_function *f)
> 
>   kfree(ncm->notify_req->buf);
>   usb_ep_free_request(ncm->notify, ncm->notify_req);
> + ncm->notify_req = NULL;
>  }
> 
>  static struct 

Re: [PATCH v2 09/16] drivers: Initialize resource entry to zero

[Simon Horman]

On Fri, Dec 25, 2015 at 03:09:18PM -0700, Toshi Kani wrote:
> I/O resource descriptor, 'desc' added to struct resource, needs
> to be initialized to zero by default.  Some drivers call kmalloc()
> to allocate a resource entry, but does not initialize it to zero
> by memset().  Change these drivers to call kzalloc(), instead.
> 
> Cc: linux-a...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Signed-off-by: Toshi Kani 
> ---
>  drivers/acpi/acpi_platform.c   |2 +-
>  drivers/parisc/eisa_enumerator.c   |4 ++--
>  drivers/rapidio/rio.c  |8 
>  drivers/sh/superhyway/superhyway.c |2 +-
>  4 files changed, 8 insertions(+), 8 deletions(-)

drivers/sh/ portion:

Acked-by: Simon Horman 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Compensation Fund Payment Of $700,000.00 12/28/2015

[Compensation]

Season Greetings from Mr. Kirk Johnson, 

This is to inform you that your ATM CARD payment worth of $700,000.00 was found 
after a routine clean up of our records and files. The ATM CARD was supposed to 
have been long shipped to you but the previous supervisor handling such 
services was sacked for gross misconduct.

I believe this must have been the case with your ATM CARD, be informed that 
this man never remitted any payment concerning your shipment to the officials 
at the airport Terminal and this was why your ATM CARD is still in our custody.

I need you to reconfirm your current shipping address as stated below as we 
have a available flight enroute your city.

To process your shipment and delivery of your ATM CARD as contracted, we 
request you to reconfirm:

Current Residence/Shipping Address: #...

Full Name: #

Telephone: # .

Verify that your shipping/delivery address above as accurate to process the 
shipment, while we await your prompt compliance to commence the delivery.

Be you informed that you should send the sum $120 for terminal charges to 
enable us clear the ATM CARD from the terminal and ship it to your give 
address. You should send the money through our terminal officers name below:

RECEIVER'S NAME: Gloria Jones
ADDRESS: POMPANO BEACH, FL 33069 U.S.A
Amount: $120
MTCN NO:...

The Estimated Time of Arrival of the 1st Class Express shipment to your 
delivery address is 12hours - upon the confirmation and receipt of the Terminal 
Charge billed in your name.

Give us a call +1 716 948 2802 as soon as you send the money and the requested 
information.

Regards,

Mr. Kirk Johnson
+1 716 948 2802
kirkjohnson...@mynet.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] cgroup: Add documentation for cgroup namespaces

[Tejun Heo]

Hello, Serge.

I applied your suggestions and applied the following to
cgroup/for-4.5.  Let's improve it from here.

Thanks!

-- 8< --
>From 5dddabce1171af2990160e1cb90f69a1440dcfb7 Mon Sep 17 00:00:00 2001
From: Aditya Kali 
Date: Tue, 22 Dec 2015 22:23:28 -0600

tj: Reorganized to better fit the documentation.

Signed-off-by: Aditya Kali 
Signed-off-by: Serge Hallyn 
Signed-off-by: Tejun Heo 
---
 Documentation/cgroup.txt | 147 +++
 1 file changed, 147 insertions(+)

diff --git a/Documentation/cgroup.txt b/Documentation/cgroup.txt
index 31d1f7b..983ba63 100644
--- a/Documentation/cgroup.txt
+++ b/Documentation/cgroup.txt
@@ -47,6 +47,11 @@ CONTENTS
   5-3. IO
 5-3-1. IO Interface Files
 5-3-2. Writeback
+6. Namespace
+  6-1. Basics
+  6-2. The Root and Views
+  6-3. Migration and setns(2)
+  6-4. Interaction with Other Namespaces
 P. Information on Kernel Programming
   P-1. Filesystem Support for Writeback
 D. Deprecated v1 Core Features
@@ -1013,6 +1018,148 @@ writeback as follows.
vm.dirty[_background]_ratio.
 
 
+6. Namespace
+
+6-1. Basics
+
+cgroup namespace provides a mechanism to virtualize the view of the
+"/proc/$PID/cgroup" file and cgroup mounts.  The CLONE_NEWCGROUP clone
+flag can be used with clone(2) and unshare(2) to create a new cgroup
+namespace.  The process running inside the cgroup namespace will have
+its "/proc/$PID/cgroup" output restricted to cgroupns root.  The
+cgroupns root is the cgroup of the process at the time of creation of
+the cgroup namespace.
+
+Without cgroup namespace, the "/proc/$PID/cgroup" file shows the
+complete path of the cgroup of a process.  In a container setup where
+a set of cgroups and namespaces are intended to isolate processes the
+"/proc/$PID/cgroup" file may leak potential system level information
+to the isolated processes.  For Example:
+
+  # cat /proc/self/cgroup
+  0::/batchjobs/container_id1
+
+The path '/batchjobs/container_id1' can be considered as system-data
+and undesirable to expose to the isolated processes.  cgroup namespace
+can be used to restrict visibility of this path.  For example, before
+creating a cgroup namespace, one would see:
+
+  # ls -l /proc/self/ns/cgroup
+  lrwxrwxrwx 1 root root 0 2014-07-15 10:37 /proc/self/ns/cgroup -> 
cgroup:[4026531835]
+  # cat /proc/self/cgroup
+  0::/batchjobs/container_id1
+
+After unsharing a new namespace, the view changes.
+
+  # ls -l /proc/self/ns/cgroup
+  lrwxrwxrwx 1 root root 0 2014-07-15 10:35 /proc/self/ns/cgroup -> 
cgroup:[4026532183]
+  # cat /proc/self/cgroup
+  0::/
+
+When some thread from a multi-threaded process unshares its cgroup
+namespace, the new cgroupns gets applied to the entire process (all
+the threads).  This is natural for the v2 hierarchy; however, for the
+legacy hierarchies, this may be unexpected.
+
+A cgroup namespace is alive as long as there are processes inside or
+mounts pinning it.  When the last usage goes away, the cgroup
+namespace is destroyed.  The cgroupns root and the actual cgroups
+remain.
+
+
+6-2. The Root and Views
+
+The 'cgroupns root' for a cgroup namespace is the cgroup in which the
+process calling unshare(2) is running.  For example, if a process in
+/batchjobs/container_id1 cgroup calls unshare, cgroup
+/batchjobs/container_id1 becomes the cgroupns root.  For the
+init_cgroup_ns, this is the real root ('/') cgroup.
+
+The cgroupns root cgroup does not change even if the namespace creator
+process later moves to a different cgroup.
+
+  # ~/unshare -c # unshare cgroupns in some cgroup
+  # cat /proc/self/cgroup
+  0::/
+  # mkdir sub_cgrp_1
+  # echo 0 > sub_cgrp_1/cgroup.procs
+  # cat /proc/self/cgroup
+  0::/sub_cgrp_1
+
+Each process gets its namespace-specific view of "/proc/$PID/cgroup"
+
+Processes running inside the cgroup namespace will be able to see
+cgroup paths (in /proc/self/cgroup) only inside their root cgroup.
+From within an unshared cgroupns:
+
+  # sleep 10 &
+  [1] 7353
+  # echo 7353 > sub_cgrp_1/cgroup.procs
+  # cat /proc/7353/cgroup
+  0::/sub_cgrp_1
+
+From the initial cgroup namespace, the real cgroup path will be
+visible:
+
+  $ cat /proc/7353/cgroup
+  0::/batchjobs/container_id1/sub_cgrp_1
+
+From a sibling cgroup namespace (that is, a namespace rooted at a
+different cgroup), the cgroup path relative to its own cgroup
+namespace root will be shown.  For instance, if PID 7353's cgroup
+namespace root is at '/batchjobs/container_id2', then it will see
+
+  # cat /proc/7353/cgroup
+  0::/../container_id2/sub_cgrp_1
+
+Note that the relative path always starts with '/' to indicate that
+its relative to the cgroup namespace root of the caller.
+
+
+6-3. Migration and setns(2)
+
+Processes inside a cgroup namespace can move into and out of the
+namespace root if they have proper access to external cgroups.  For
+example, from inside a namespace 

Re: [PATCH v4] watchdog: add support for Sigma Designs SMP86xx/SMP87xx

[Wim Van Sebroeck]

Hi,

> This adds support for the Sigma Designs SMP86xx/SMP87xx family built-in
> watchdog.
> 
> Signed-off-by: Mans Rullgard 
> ---
> Changes:
> - #include bitops.h
> - clk_disable_unprepare() on failure
> ---
>  drivers/watchdog/Kconfig  |  10 ++
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/tangox_wdt.c | 225 
> ++
>  3 files changed, 236 insertions(+)
>  create mode 100644 drivers/watchdog/tangox_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 7a8a6c6..f43ff7a 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -135,6 +135,16 @@ config MENF21BMC_WATCHDOG
> This driver can also be built as a module. If so the module
> will be called menf21bmc_wdt.
>  
> +config TANGOX_WATCHDOG
> + tristate "Sigma Designs SMP86xx/SMP87xx watchdog"
> + select WATCHDOG_CORE
> + depends on ARCH_TANGOX || COMPILE_TEST
> + help
> +   Support for the watchdog in Sigma Designs SMP86xx (tango3)
> +   and SMP87xx (tango4) family chips.
> +
> +   This driver can be built as a module. The module name is tangox_wdt.
> +
>  config WM831X_WATCHDOG
>   tristate "WM831x watchdog"
>   depends on MFD_WM831X
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 53d4827..46cb387 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -187,6 +187,7 @@ obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
>  obj-$(CONFIG_DA9062_WATCHDOG) += da9062_wdt.o
>  obj-$(CONFIG_DA9063_WATCHDOG) += da9063_wdt.o
>  obj-$(CONFIG_GPIO_WATCHDOG)  += gpio_wdt.o
> +obj-$(CONFIG_TANGOX_WATCHDOG) += tangox_wdt.o
>  obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
>  obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
>  obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
> diff --git a/drivers/watchdog/tangox_wdt.c b/drivers/watchdog/tangox_wdt.c
> new file mode 100644
> index 000..b9ee624
> --- /dev/null
> +++ b/drivers/watchdog/tangox_wdt.c
> @@ -0,0 +1,225 @@
> +/*
> + *  Copyright (C) 2015 Mans Rullgard 
> + *  SMP86xx/SMP87xx Watchdog driver
> + *
> + *  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 
> +#include 
> +#include 
> +
> +#define DEFAULT_TIMEOUT 30
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, 0);
> +MODULE_PARM_DESC(nowayout,
> +  "Watchdog cannot be stopped once started (default="
> +  __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +static unsigned int timeout;
> +module_param(timeout, int, 0);
> +MODULE_PARM_DESC(timeout, "Watchdog timeout");
> +
> +/*
> + * Counter counts down from programmed value.  Reset asserts when
> + * the counter reaches 1.
> + */
> +#define WD_COUNTER   0
> +
> +#define WD_CONFIG4
> +#define WD_CONFIG_XTAL_INBIT(0)
> +#define WD_CONFIG_DISABLEBIT(31)
> +
> +struct tangox_wdt_device {
> + struct watchdog_device wdt;
> + void __iomem *base;
> + unsigned long clk_rate;
> + struct clk *clk;
> + struct notifier_block restart;
> +};
> +
> +static int tangox_wdt_set_timeout(struct watchdog_device *wdt,
> +   unsigned int new_timeout)
> +{
> + wdt->timeout = new_timeout;
> +
> + return 0;
> +}
> +
> +static int tangox_wdt_start(struct watchdog_device *wdt)
> +{
> + struct tangox_wdt_device *dev = watchdog_get_drvdata(wdt);
> + u32 ticks;
> +
> + ticks = 1 + wdt->timeout * dev->clk_rate;
> + writel(ticks, dev->base + WD_COUNTER);
> +
> + return 0;
> +}
> +
> +static int tangox_wdt_stop(struct watchdog_device *wdt)
> +{
> + struct tangox_wdt_device *dev = watchdog_get_drvdata(wdt);
> +
> + writel(0, dev->base + WD_COUNTER);
> +
> + return 0;
> +}
> +
> +static unsigned int tangox_wdt_get_timeleft(struct watchdog_device *wdt)
> +{
> + struct tangox_wdt_device *dev = watchdog_get_drvdata(wdt);
> + u32 count;
> +
> + count = readl(dev->base + WD_COUNTER);
> +
> + if (!count)
> + return 0;
> +
> + return (count - 1) / dev->clk_rate;
> +}
> +
> +static const struct watchdog_info tangox_wdt_info = {
> + .options  = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
> + .identity = "tangox watchdog",
> +};
> +
> +static const struct watchdog_ops tangox_wdt_ops = {
> + .start  = tangox_wdt_start,
> + .stop   = tangox_wdt_stop,
> + .set_timeout= tangox_wdt_set_timeout,
> + .get_timeleft   = tangox_wdt_get_timeleft,
> +};
> +
> +static int tangox_wdt_restart(struct notifier_block *nb, unsigned long 
> action,
> + 

Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"

[Arnd Bergmann]

On Monday 28 December 2015 13:01:22 Frank Rowand wrote:
> 
> Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision"
> property.
> 
> If the use of /revision is limited to being a location to hold an ATAG
> value to pass to the global variable system_rev, then it would make
> sense to just copy directly from the ATAG value into system_rev in the
> same board file where you are copying the ATAGs.

Agreed. That would be simpler, and avoid a situation where someone relies
on the /revision property in DT to be set from the atags compat code
(preventing an upgrade to a newer bootloader), or on the system_rev variable
to be the same across multiple boot loaders, in the absence of other
kernel code setting it.

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

Re: [PATCH v1 1/1] lib/vsprintf: refactor duplicate code to xnumber()

[Andy Shevchenko]

On Tue, Dec 29, 2015 at 12:20 AM, Rasmus Villemoes
 wrote:
> On Mon, Dec 28 2015, Rasmus Villemoes  wrote:
>
>>
>> Is there any aspect of the passed-through printf_spec which isn't
>> overridden in xnumber? The users are/will be various %p extensions,
>> which probably means that no-one passes a non-default precision (gcc
>> complains about %.*p), and the remaining possible flags (PLUS, LEFT,
>> SPACE) are useless and/or impossible to pass to %p
>
> Actually, LEFT can be passed to %p (or get set by passing a negative
> field width via %*p), which would be actively harmful: When LEFT is set,
> number() explicitly removes the ZEROPAD flag, so we'd get "0xabcdef  "
> instead of "0x00abcdef".

My opinion we have to establish strict rules what we print in case of
prefixed pointer (when #ifdef is false in some cases, e.g. struct clk)
or fixed type values, such as phys_addr_t. I mean to always have a
maximum width for the type on the running architecture.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI/AER: enable SERR# forwarding for bridges and switches

[Bjorn Helgaas]

Hi Sinan,

Sorry for the delay in responding; I was on vacation when you sent
this, and I missed it when I returned.

On Mon, Dec 14, 2015 at 01:22:39PM -0500, Sinan Kaya wrote:
> On 12/11/2015 6:30 PM, Sinan Kaya wrote:
> >> I think the best way to fix all the cases would be to do something in
> >> > in pci_configure_device().  Then we could drop the AER bus walk in
> >> > set_downstream_devices_error_reporting().  A bus walk like that is
> >> > always an issue for hotplug.
> >> > 
> > Let me read some code.
> 
> OK, If I understand it right; pci_configure_device is where
> program_hpp_type0 called. You also want to enable AER in this function.
> 
> Move the contents of set_device_error_reporting into
> pci_configure_device like this below ?
> 
> ...
> + int type = pci_pcie_type(dev);
> 
> pci_configure_mps(dev);
> 
> + if ((type == PCI_EXP_TYPE_ROOT_PORT) ||
> + (type == PCI_EXP_TYPE_UPSTREAM) ||
> + (type == PCI_EXP_TYPE_DOWNSTREAM)) {
> + pci_enable_pcie_error_reporting(dev);
> + }
> 
> + pcie_set_ecrc_checking(dev);

Yep, that's the sort of thing I'm thinking.

I think there are some subtleties to consider.

_HPP/_HPX can twiddle some of the same bits.  Should we allow _HPP to
clear a bit that pci_enable_pcie_error_reporting() would set?  What
about the reverse?

There are a ridiculous number of places that call
pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ERR).  We should
do it once and cache the result in struct pci_dev.

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

Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

[Andrew Morton]

On Wed,  9 Dec 2015 12:19:37 +0900 Taku Izumi  wrote:

> This patch extends existing "kernelcore" option and
> introduces kernelcore=mirror option. By specifying
> "mirror" instead of specifying the amount of memory,
> non-mirrored (non-reliable) region will be arranged
> into ZONE_MOVABLE.
> 
> v1 -> v2:
>  - Refine so that the following case also can be
>handled properly:
> 
>  Node X:  |MM--MM|
>(legend) M: mirrored  -: not mirrrored
> 
>  In this case, ZONE_NORMAL and ZONE_MOVABLE are
>  arranged like bellow:
> 
>  Node X:  |MM--MM|
>   |ooxxoo| ZONE_NORMAL
> |ooxx| ZONE_MOVABLE
>(legend) o: present  x: absent
> 
> ...
>
>
> @@ -5507,6 +5569,36 @@ static void __init 
> find_zone_movable_pfns_for_nodes(void)
>   }
>  
>   /*
> +  * If kernelcore=mirror is specified, ignore movablecore option
> +  */
> + if (mirrored_kernelcore) {
> + bool mem_below_4gb_not_mirrored = false;
> +
> + for_each_memblock(memory, r) {
> + if (memblock_is_mirror(r))
> + continue;
> +
> + nid = r->nid;
> +
> + usable_startpfn = memblock_region_memory_base_pfn(r);
> +
> + if (usable_startpfn < 0x10) {
> + mem_below_4gb_not_mirrored = true;
> + continue;
> + }
> +
> + zone_movable_pfn[nid] = zone_movable_pfn[nid] ?
> + min(usable_startpfn, zone_movable_pfn[nid]) :
> + usable_startpfn;
> + }
> +
> + if (mem_below_4gb_not_mirrored)
> + pr_warn("This configuration results in unmirrored 
> kernel memory.");

This looks a bit strange.

What's the code actually doing?  Checking to see that all memory at
physical addresses < 0x1 is mirrored, I think?

If so, what's up with that hard-wired 0x10?  That's not going to
work on PAGE_SIZE>4k machines, and this is generic code.

Also, I don't think the magical 0x1 is necessarily going to be
relevant for other architectures (presumably powerpc will be next...)

I guess this is all OK as an "initial implementation for x86_64 only"
for now, and this stuff will be changed later if/when another
architecture comes along.  However it would be nice to make things more
generic from the outset, to provide a guide for how things should be
implemented by other architectures.



Separately, what feedback does the user get about the success of the
kernelcore=mirror comment?  We didn't include an explicit printk which
displays the outcome, so how is the user to find out that it all worked
OK and that the kernel is now using mirrored memory?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: debugfs_remove_recursive() while a file is in use by userspace

[Rajat Jain]

>
> The current state is that both question are to be answered with "no",
> i.e. debugfs file removal is racy.
>

Ouch! :-(. Thanks for confirming!

Somewhat related, is my understanding correct that the behaviour of
character device layer w.r.t. the two questions that I asked the
answer to my questions would be "yes"?

i.e. cdev_del() would wait

>> (1) until all the currently executing file operation methods
>> (read/write/map etc) have returned?

AND

>> (2) until the user has given up all references (descriptors) to the
>> files (i.e. until release() method has been
>> called)?

Thanks,

Rajat


On Mon, Dec 28, 2015 at 12:42 PM, Nicolai Stange  wrote:
> Hi Rajat,
>
> Rajat Jain  writes:
>
>> Hi,
>>
>> I wanted to understand the behavior taken when a module calls
>> debugfs_remove_recursive() on a directory, while files under that
>> directory may still be in use by the userspace (for instance an
>> ongoing read / write operation).
>>
>> Does the function wait
>>
>> (1) until all the currently executing file operation methods
>> (read/write/map etc) have returned?
>> OR
>> (2) until the user has given up all references (descriptors) to the
>> files under the directory (i.e. until release() method has been
>> called)?
>
> The current state is that both question are to be answered with "no",
> i.e. debugfs file removal is racy.
>
> I've recently sent a patch addressing this issue:
>   https://lkml.kernel.org/g/87y4dfukzy@gmail.com
>
> Basically, it turns the answer to your first question into "yes".
> Subsequent reads/writes will return a -EIO.
>
> That patch (series) is still under review though.
>
> Further reference can be found in the *sub*-thread rooted at
>   http://thread.gmane.org/gmane.linux.kernel/1452470/focus=1467314
>
> Best,
>
> Nicolai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: debugfs_remove_recursive() while a file is in use by userspace

[Greg Kroah-Hartman]

On Mon, Dec 28, 2015 at 12:51:32PM -0800, Rajat Jain wrote:
> Thanks Greg and Al for the quick turnaround.
> 
> Essentially I have a device that supports something called "contexts"
> that can be "created" and "destroyed" during the life of the device. I
> want to expose some debug files for the context when it is created,
> and destroy the files when the context is destroyed. However, I'm not
> sure how do I ensure that the user is not in the middle of reading /
> writing / mmaping to those files. Also how do I know that user is
> still not holding a reference to the file structure.

You don't.

> It seems like debugfs is currently not a good choice for this? Would
> you recommend me to any other fs or subsystem that I should use for
> this?

What exactly do you need to export to userspace and for what purpose?
For debugging-only stuff, sure, use debugfs, but don't rely on it for
any "real" tools, only your own debugging.

> Would hanging those files under the sysfs node for the device sound
> any better (by representing each "context" using an embedded kobject)?

That would ensure that things work properly.  But you don't need a whole
kobject, just use a named group and a subdir will be created properly
for you.

good luck,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: debugfs_remove_recursive() while a file is in use by userspace

[Rajat Jain]

On Mon, Dec 28, 2015 at 12:58 PM, Greg Kroah-Hartman  wrote:
> On Mon, Dec 28, 2015 at 12:51:32PM -0800, Rajat Jain wrote:
>> Thanks Greg and Al for the quick turnaround.
>>
>> Essentially I have a device that supports something called "contexts"
>> that can be "created" and "destroyed" during the life of the device. I
>> want to expose some debug files for the context when it is created,
>> and destroy the files when the context is destroyed. However, I'm not
>> sure how do I ensure that the user is not in the middle of reading /
>> writing / mmaping to those files. Also how do I know that user is
>> still not holding a reference to the file structure.
>
> You don't.
>
>> It seems like debugfs is currently not a good choice for this? Would
>> you recommend me to any other fs or subsystem that I should use for
>> this?
>
> What exactly do you need to export to userspace and for what purpose?
> For debugging-only stuff, sure, use debugfs, but don't rely on it for
> any "real" tools, only your own debugging.

I'm actually writing a driver that would expose a "dummy device" to a
real driver. The dummy driver relies on user space to feed in the
device attributes (no of supported contexts etc). I am now thinking
that a character device interface to user space may actually be a
better choice. Question: Does cdev_del() ensure that all references to
the file are dropped before it returns?

Thanks,

Rajat

>
>> Would hanging those files under the sysfs node for the device sound
>> any better (by representing each "context" using an embedded kobject)?
>
> That would ensure that things work properly.  But you don't need a whole
> kobject, just use a named group and a subdir will be created properly
> for you.
>
> good luck,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC 3/3] xen/Kconfig: add XEN_TIME_VSYSCALL option

[Joao Martins]

This option enables support for pvclock vsyscall/vdso
support on Xen. Default is off, since Xen doesn't
expose yet the PVCLOCK_TSC_STABLE_BIT flag.

Signed-off-by: Joao Martins 
---
 arch/x86/xen/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index c7b15f3..636eaeb 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -37,6 +37,11 @@ config XEN_512GB
  It is always possible to change the default via specifying the
  boot parameter "xen_512gb_limit".
 
+config XEN_TIME_VSYSCALL
+   bool "Enable Xen support for pvclock vsyscall/vdso"
+   depends on XEN && PARAVIRT_CLOCK
+   def_bool n
+
 config XEN_SAVE_RESTORE
bool
depends on XEN
-- 
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 RFC 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

[Joao Martins]

Right now there is only a pvclock_pvti_cpu0_va() which is defined on
kvmclock since:

commit dac16fba6fc5
("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")

The only user of this interface so far is kvm. This commit adds a setter
function for the pvti page and moves pvclock_pvti_cpu0_va to pvclock, which
is a more generic place to have it; and would allow other PV clocksources
to use it, such as Xen. 

Signed-off-by: Joao Martins 
---
 arch/x86/include/asm/pvclock.h | 22 +-
 arch/x86/kernel/kvmclock.c |  6 +-
 arch/x86/kernel/pvclock.c  | 11 +++
 3 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 66df22b..cfb1bb6 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -4,15 +4,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_PARAVIRT_CLOCK
-extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
-#else
-static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
-   return NULL;
-}
-#endif
-
 /* some helper functions for xen and kvm pv clock sources */
 cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src);
 u8 pvclock_read_flags(struct pvclock_vcpu_time_info *src);
@@ -101,4 +92,17 @@ struct pvclock_vsyscall_time_info {
 
 #define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
 
+#ifdef CONFIG_PARAVIRT_CLOCK
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti);
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
+#else
+static inline void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info 
*)
+{
+}
+static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+   return NULL;
+}
+#endif
+
 #endif /* _ASM_X86_PVCLOCK_H */
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 72cef58..02a5d9e6 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -45,11 +45,6 @@ early_param("no-kvmclock", parse_no_kvmclock);
 static struct pvclock_vsyscall_time_info *hv_clock;
 static struct pvclock_wall_clock wall_clock;
 
-struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
-   return hv_clock;
-}
-
 /*
  * The wallclock is the time of day when we booted. Since then, some time may
  * have elapsed since the hypervisor wrote the data. So we try to account for
@@ -329,6 +324,7 @@ int __init kvm_setup_vsyscall_timeinfo(void)
return 1;
}
 
+   pvclock_set_pvti_cpu0_va(hv_clock);
put_cpu();
 
kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 99bfc02..da6fbe2 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -25,6 +25,7 @@
 #include 
 
 static u8 valid_flags __read_mostly = 0;
+static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly;
 
 void pvclock_set_flags(u8 flags)
 {
@@ -140,3 +141,13 @@ void pvclock_read_wallclock(struct pvclock_wall_clock 
*wall_clock,
 
set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
 }
+
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
+{
+   pvti_cpu0_va = pvti;
+}
+
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+   return pvti_cpu0_va;
+}
-- 
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 RFC 2/3] x86/xen/time: setup vcpu 0 time info page

[Joao Martins]

In order to support pvclock vdso on xen we need to setup the
time info page for vcpu 0 and register the page with Xen using
the VCPUOP_register_vcpu_time_memory_area hypercall. This
hypercall will also forcefully update the pvti which will set
some of the necessary flags for vdso. Afterwards we check if it
supports the PVCLOCK_TSC_STABLE_BIT flag which is mandatory for
having vdso/vsyscall support. And if so, it will set the cpu 0
pvti that will be later on used when mapping the vdso image.

The xen headers are also updated to include the new hypercall for
registering the secondary vcpu_time_info copy.

Signed-off-by: Joao Martins 
---
 arch/x86/xen/time.c  | 66 
 include/xen/interface/vcpu.h | 28 +++
 2 files changed, 94 insertions(+)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..c17b1b2 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -403,6 +404,69 @@ static const struct pv_time_ops xen_time_ops __initconst = 
{
.sched_clock = xen_clocksource_read,
 };
 
+#ifdef CONFIG_XEN_TIME_VSYSCALL
+static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
+
+static int xen_setup_vsyscall_time_info(int cpu)
+{
+   struct pvclock_vsyscall_time_info *ti;
+   struct vcpu_register_time_memory_area t;
+   struct pvclock_vcpu_time_info *pvti;
+   unsigned long mem;
+   int ret, size;
+   u8 flags;
+
+   ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
+cpu, NULL);
+   if (ret == -ENOSYS) {
+   pr_debug("xen: vcpu_time_info placement not supported\n");
+   return -ENOTSUPP;
+   }
+
+   size = PAGE_ALIGN(sizeof(struct pvclock_vsyscall_time_info));
+   mem = memblock_alloc(size, PAGE_SIZE);
+   if (!mem)
+   return -ENOMEM;
+
+   ti = __va(mem);
+   memset(ti, 0, size);
+
+   t.addr.v = [cpu].pvti;
+
+   ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
+cpu, );
+
+   if (ret) {
+   pr_debug("xen: cannot register vcpu_time_info err %d\n", ret);
+   memblock_free(mem, size);
+   return ret;
+   }
+
+   pvti = [cpu].pvti;
+   flags = pvti->flags;
+
+   if (!(flags & PVCLOCK_TSC_STABLE_BIT)) {
+   pr_debug("xen: VCLOCK_PVCLOCK not supported\n");
+   memblock_free(mem, size);
+   return -ENOTSUPP;
+   }
+
+   xen_clock = ti;
+   pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT);
+   pvclock_set_pvti_cpu0_va(xen_clock);
+
+   xen_clocksource.archdata.vclock_mode = VCLOCK_PVCLOCK;
+
+   return 0;
+}
+#else
+static int xen_setup_vsyscall_time_info(int cpu)
+{
+   return -1;
+}
+
+#endif /* CONFIG_XEN_TIME_VSYSCALL */
+
 static void __init xen_time_init(void)
 {
int cpu = smp_processor_id();
@@ -431,6 +495,8 @@ static void __init xen_time_init(void)
xen_setup_timer(cpu);
xen_setup_cpu_clockevents();
 
+   xen_setup_vsyscall_time_info(cpu);
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
 }
diff --git a/include/xen/interface/vcpu.h b/include/xen/interface/vcpu.h
index b05288c..902b59e 100644
--- a/include/xen/interface/vcpu.h
+++ b/include/xen/interface/vcpu.h
@@ -172,4 +172,32 @@ DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_vcpu_info);
 
 /* Send an NMI to the specified VCPU. @extra_arg == NULL. */
 #define VCPUOP_send_nmi 11
+
+/*
+ * Register a memory location to get a secondary copy of the vcpu time
+ * parameters.  The master copy still exists as part of the vcpu shared
+ * memory area, and this secondary copy is updated whenever the master copy
+ * is updated (and using the same versioning scheme for synchronisation).
+ *
+ * The intent is that this copy may be mapped (RO) into userspace so
+ * that usermode can compute system time using the time info and the
+ * tsc.  Usermode will see an array of vcpu_time_info structures, one
+ * for each vcpu, and choose the right one by an existing mechanism
+ * which allows it to get the current vcpu number (such as via a
+ * segment limit).  It can then apply the normal algorithm to compute
+ * system time from the tsc.
+ *
+ * @extra_arg == pointer to vcpu_register_time_info_memory_area structure.
+ */
+#define VCPUOP_register_vcpu_time_memory_area   13
+DEFINE_GUEST_HANDLE_STRUCT(vcpu_time_info_t);
+struct vcpu_register_time_memory_area {
+   union {
+   GUEST_HANDLE(vcpu_time_info_t) h;
+   struct pvclock_vcpu_time_info *v;
+   uint64_t p;
+   } addr;
+};
+DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_time_memory_area_t);
+
 #endif /* __XEN_PUBLIC_VCPU_H__ */
-- 
2.1.4

--
To unsubscribe from this list: send the line 

[PATCH RFC 0/3] x86/xen: pvclock vdso support

[Joao Martins]

Hey!

This series proposes support for pvclock vdso under Xen: Patch 1 adds
setting cpu 0 pvti page; Patch 2 registers the pvti page with Xen and sets
it accordingly in pvclock and Patch 3 adds a Kconfig option since Xen
doesn't yet support the PVCLOCK_TSC_STABLE_BIT flag. Though its support
will probably be discussed in another RFC I sent[0].

Any comments or suggestions are welcome!

Thanks,
Joao

[0] http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02835.html

Joao Martins (3):
  x86/pvclock: add setter for pvclock_pvti_cpu0_va
  x86/xen/time: setup vcpu 0 time info page
  xen/Kconfig: add XEN_TIME_VSYSCALL option

 arch/x86/include/asm/pvclock.h | 22 --
 arch/x86/kernel/kvmclock.c |  6 +---
 arch/x86/kernel/pvclock.c  | 11 +++
 arch/x86/xen/Kconfig   |  5 
 arch/x86/xen/time.c| 66 ++
 include/xen/interface/vcpu.h   | 28 ++
 6 files changed, 124 insertions(+), 14 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] [media] au0828: Refactoring for start_urb_transfer()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 28 Dec 2015 22:52:48 +0100

This issue was detected by using the Coccinelle software.

1. Let us return directly if a buffer allocation failed.

2. Delete the jump label "err" then.

3. Drop the explicit initialisation for the variable "ret"
   at the beginning.

4. Return zero as a constant at the end.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/au0828/au0828-dvb.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-dvb.c 
b/drivers/media/usb/au0828/au0828-dvb.c
index cd542b4..e5f1e20 100644
--- a/drivers/media/usb/au0828/au0828-dvb.c
+++ b/drivers/media/usb/au0828/au0828-dvb.c
@@ -181,7 +181,7 @@ static int stop_urb_transfer(struct au0828_dev *dev)
 static int start_urb_transfer(struct au0828_dev *dev)
 {
struct urb *purb;
-   int i, ret = -ENOMEM;
+   int i, ret;
 
dprintk(2, "%s()\n", __func__);
 
@@ -194,7 +194,7 @@ static int start_urb_transfer(struct au0828_dev *dev)
 
dev->urbs[i] = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->urbs[i])
-   goto err;
+   return -ENOMEM;
 
purb = dev->urbs[i];
 
@@ -207,9 +207,10 @@ static int start_urb_transfer(struct au0828_dev *dev)
if (!purb->transfer_buffer) {
usb_free_urb(purb);
dev->urbs[i] = NULL;
+   ret = -ENOMEM;
pr_err("%s: failed big buffer allocation, err = %d\n",
   __func__, ret);
-   goto err;
+   return ret;
}
 
purb->status = -EINPROGRESS;
@@ -235,10 +236,7 @@ static int start_urb_transfer(struct au0828_dev *dev)
}
 
dev->urb_streaming = true;
-   ret = 0;
-
-err:
-   return ret;
+   return 0;
 }
 
 static void au0828_start_transport(struct au0828_dev *dev)
-- 
2.6.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] usb: gadget: fix double mem free for usb_request caused by wild pointers

[Robert Baldyga]

Hi,

On 12/28/2015 07:25 AM, changbin...@intel.com wrote:
> From: "Du, Changbin" 
> 
> acm, ecm, hid, ncm, phonet, rndis and uvc functions all have double
> memory free issue. Set pointers to NULL after freed to avoid this.
> 
> Here explain how it happen on acm function, others has analogical case.
> 
> If acm_bind fails before allocate notification and acm->notify_req is
> not set to NULL after freed last time, double free will happen.
> 
> kernel BUG at mm/slub.c:3392!
> invalid opcode:  [#1] PREEMPT SMP
> EIP is at kfree+0x172/0x180
> Call Trace:
> [<80c0e3b6>] ? usb_ep_autoconfig_ss+0x86/0x170
> [<80c13345>] gs_free_req+0x15/0x30
> [<80c12df1>] acm_bind+0x1c1/0x2d0
> [<80c0e9be>] usb_add_function+0x6e/0x120
> [<80c213cb>] acm_function_bind_config+0x2b/0x90
> 

Looks good to me again :)

Reviewed-by: Robert Baldyga 

Thanks,
Robert Baldyga

> Signed-off-by: Du, Changbin 
> ---
> changes from v1: 
>   1. add same fix for ecm, hid, ncm... fucntions
>   2. patch title changed
> ---
>  drivers/usb/gadget/function/f_acm.c|  8 ++--
>  drivers/usb/gadget/function/f_ecm.c|  2 ++
>  drivers/usb/gadget/function/f_hid.c|  5 -
>  drivers/usb/gadget/function/f_ncm.c|  2 ++
>  drivers/usb/gadget/function/f_phonet.c | 11 ---
>  drivers/usb/gadget/function/f_rndis.c  |  2 ++
>  drivers/usb/gadget/function/f_uvc.c|  5 -
>  7 files changed, 28 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_acm.c 
> b/drivers/usb/gadget/function/f_acm.c
> index 2fa1e80..e10c8d4 100644
> --- a/drivers/usb/gadget/function/f_acm.c
> +++ b/drivers/usb/gadget/function/f_acm.c
> @@ -699,8 +699,10 @@ acm_bind(struct usb_configuration *c, struct 
> usb_function *f)
>   return 0;
>  
>  fail:
> - if (acm->notify_req)
> + if (acm->notify_req) {
>   gs_free_req(acm->notify, acm->notify_req);
> + acm->notify_req = NULL;
> + }
>  
>   ERROR(cdev, "%s/%p: can't bind, err %d\n", f->name, f, status);
>  
> @@ -713,8 +715,10 @@ static void acm_unbind(struct usb_configuration *c, 
> struct usb_function *f)
>  
>   acm_string_defs[0].id = 0;
>   usb_free_all_descriptors(f);
> - if (acm->notify_req)
> + if (acm->notify_req) {
>   gs_free_req(acm->notify, acm->notify_req);
> + acm->notify_req = NULL;
> + }
>  }
>  
>  static void acm_free_func(struct usb_function *f)
> diff --git a/drivers/usb/gadget/function/f_ecm.c 
> b/drivers/usb/gadget/function/f_ecm.c
> index 7ad60ee..23092a2 100644
> --- a/drivers/usb/gadget/function/f_ecm.c
> +++ b/drivers/usb/gadget/function/f_ecm.c
> @@ -809,6 +809,7 @@ fail:
>   if (ecm->notify_req) {
>   kfree(ecm->notify_req->buf);
>   usb_ep_free_request(ecm->notify, ecm->notify_req);
> + ecm->notify_req = NULL;
>   }
>  
>   ERROR(cdev, "%s: can't bind, err %d\n", f->name, status);
> @@ -907,6 +908,7 @@ static void ecm_unbind(struct usb_configuration *c, 
> struct usb_function *f)
>  
>   kfree(ecm->notify_req->buf);
>   usb_ep_free_request(ecm->notify, ecm->notify_req);
> + ecm->notify_req = NULL;
>  }
>  
>  static struct usb_function *ecm_alloc(struct usb_function_instance *fi)
> diff --git a/drivers/usb/gadget/function/f_hid.c 
> b/drivers/usb/gadget/function/f_hid.c
> index 99285b4..827e385 100644
> --- a/drivers/usb/gadget/function/f_hid.c
> +++ b/drivers/usb/gadget/function/f_hid.c
> @@ -679,8 +679,10 @@ fail:
>   ERROR(f->config->cdev, "hidg_bind FAILED\n");
>   if (hidg->req != NULL) {
>   kfree(hidg->req->buf);
> - if (hidg->in_ep != NULL)
> + if (hidg->in_ep != NULL) {
>   usb_ep_free_request(hidg->in_ep, hidg->req);
> + hidg->req = NULL;
> + }
>   }
>  
>   return status;
> @@ -912,6 +914,7 @@ static void hidg_unbind(struct usb_configuration *c, 
> struct usb_function *f)
>   usb_ep_disable(hidg->in_ep);
>   kfree(hidg->req->buf);
>   usb_ep_free_request(hidg->in_ep, hidg->req);
> + hidg->req = NULL;
>  
>   usb_free_all_descriptors(f);
>  }
> diff --git a/drivers/usb/gadget/function/f_ncm.c 
> b/drivers/usb/gadget/function/f_ncm.c
> index 7ad798a..510d1d7 100644
> --- a/drivers/usb/gadget/function/f_ncm.c
> +++ b/drivers/usb/gadget/function/f_ncm.c
> @@ -1459,6 +1459,7 @@ fail:
>   if (ncm->notify_req) {
>   kfree(ncm->notify_req->buf);
>   usb_ep_free_request(ncm->notify, ncm->notify_req);
> + ncm->notify_req = NULL;
>   }
>  
>   ERROR(cdev, "%s: can't bind, err %d\n", f->name, status);
> @@ -1561,6 +1562,7 @@ static void ncm_unbind(struct usb_configuration *c, 
> struct usb_function *f)
>  
>   kfree(ncm->notify_req->buf);
>   usb_ep_free_request(ncm->notify, ncm->notify_req);
> + ncm->notify_req = NULL;
>  }
>  
>  static struct 

Re: [PATCH v2 0/5] watchdog: Do not use 'dev' from watchdog_device in watchdog drivers

[Wim Van Sebroeck]

Hi Guenter,

> The 'dev' variable in watchdog drivers has a different lifetime than the
> watchdog character device and should therefore not be used by watchdog
> drivers.
> 
> Some of the drivers use the variable to print kernel messages. Those
> messages are either dropped or changed to use the parent device.
> One driver sets the variable during initialization to the watchdog
> driver's parent device, which is wrong and was removed.
> 
> v2: Use parent device for dev_XXX messages instead of pr_XXX.

This patchset has been added to linux-watchdog-next.

Kind regards,
Wim.

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

Charity Donation

[Jeff Skoll]

Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the 
largest private foundations in the world. I believe strongly in ‘giving while 
living.’ I had one idea that never changed in my mind — that you should use 
your wealth to help people and I have decided to secretly give USD2.498 Million 
to a randomly selected individual. On receipt of this email, you should count 
yourself as the individual. Kindly get back to me at your earliest convenience, 
so I know your email address is valid.

Visit the web page to know more about me: 
http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/
 or you can read an article of me on Wikipedia.

Regards,
Jeffrey Skoll.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAINTAINERS: Add Guenter Roeck as reviewer of watchdog drivers

[Wim Van Sebroeck]

Hi Guenter,

> I have been reviewing watchdog drivers for years, so we might
> as well make it official.
> 
> Signed-off-by: Guenter Roeck 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cba790b42f23..b1e3da7dc393 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11602,6 +11602,7 @@ F:drivers/input/tablet/wacom_serial4.c
>  
>  WATCHDOG DEVICE DRIVERS
>  M:   Wim Van Sebroeck 
> +R:   Guenter Roeck 
>  L:   linux-watch...@vger.kernel.org
>  W:   http://www.linux-watchdog.org/
>  T:   git git://www.linux-watchdog.org/linux-watchdog.git
> -- 
> 2.1.4
> 

I think I forgot to tell you that this patch was added in linux-watchdog-next,
but I am sure you allready saw it :-).

Kind regards,
Wim.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 1/1] lib/vsprintf: refactor duplicate code to xnumber()

[Andy Shevchenko]

On Mon, Dec 28, 2015 at 11:42 PM, Rasmus Villemoes
 wrote:
> On Mon, Dec 28 2015, Joe Perches  wrote:
>
>> On Mon, 2015-12-28 at 20:18 +0200, Andy Shevchenko wrote:
>>> xnumber() is a special helper to print a fixed size type in a hex format 
>>> with
>>> '0x' prefix with padding and reduced size. In the module we have already
>>> several copies of such code. Consolidate them under xnumber() helper.
>>>
>>> There are couple of differences though.
>>>
>>> It seems nobody cared about the output in case of CONFIG_KALLSYMS=n when
>>> printing symbol address because the asked width is not enough to care either
>>> prefix or last byte. Fixed here.
>
> ok, though I'm curious what 'last byte' refers to here?

The last byte ('78') as it appears in the string carrying the number
'0x12345678'. Yeah, might be confusing, I'm open for suggestion how to
phrase it.

>
>>> The %pNF specifier used to be allowed with a specific field width, though 
>>> there
>>> is neither any user of it nor mention in the documentation.
>>>
>>> Signed-off-by: Andy Shevchenko 
>>> ---
>>>  lib/vsprintf.c | 43 +++
>>>  1 file changed, 15 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>>> index dcf5646..e971549 100644
>>> --- a/lib/vsprintf.c
>>> +++ b/lib/vsprintf.c
>>> @@ -514,6 +514,16 @@ char *number(char *buf, char *end, unsigned long long 
>>> num,
>>>  return buf;
>>>  }
>>>
>>> +static noinline_for_stack
>>> +char *xnumber(char *buf, char *end, unsigned long long value, unsigned int 
>>> type,
>>> +  struct printf_spec spec)
>
> Is there any aspect of the passed-through printf_spec which isn't
> overridden in xnumber? The users are/will be various %p extensions,
> which probably means that no-one passes a non-default precision (gcc
> complains about %.*p), and the remaining possible flags (PLUS, LEFT,
> SPACE) are useless and/or impossible to pass to %p without gcc
> complaining. In other words, why pass the spec at all instead of just
> building it inside xnumber?

Wow, good catch!
I slightly suspected something like that, but didn't made up my mind
to check this.

>
>> xnumber isn't a great name.
>
> Maybe 'hexnumber'.

We already have similar for %*ph. And as you noticed below…

> That's a bit further away from 'number', and 'x'
> might stand for something other than hex.

…isn't only about hex. I don't know how to play on words the all three
flags including 16 base.

>
>> unsigned int type should probably be size_t size
>
> Compromise: 'unsigned int size'. The name should be size since it's
> supposed to be the size of the actual type being printed. But the type
> carrying that information need not be 8 bytes wide on 64bits.

Exactly, the result anyway as for now only 8 bits as a part of unsigned int.

>
>>> static noinline_for_stack
>>>  char *address_val(char *buf, char *end, const void *addr,
>>>struct printf_spec spec, const char *fmt)
>>>  {
>>> -unsigned long long num;
>>> -
>>> -spec.flags |= SPECIAL | SMALL | ZEROPAD;
>>> -spec.base = 16;
>>> -
>>>  switch (fmt[1]) {
>>>  case 'd':
>>> -num = *(const dma_addr_t *)addr;
>>> -spec.field_width = sizeof(dma_addr_t) * 2 + 2;
>>> -break;
>>> +return xnumber(buf, end, *(const dma_addr_t *)addr, 
>>> sizeof(dma_addr_t), spec);
>>>  case 'p':
>>>  default:
>>> -num = *(const phys_addr_t *)addr;
>>> -spec.field_width = sizeof(phys_addr_t) * 2 + 2;
>>> -break;
>>> +return xnumber(buf, end, *(const phys_addr_t *)addr, 
>>> sizeof(phys_addr_t), spec);
>>>  }
>>> -
>>> -return number(buf, end, num, spec);
>>>  }
>
> Nit: I think it would be a bit easier to read if the cast+dereference
> are kept outside the function calls. I'd suggest just introducing
> 'unsigned int size', assign the appropriate value in the two cases, and
> fall through to a common 'xnumber(buf, end, num, size);'. It'll even
> line up nicely ;-)

Will try that.

>
> num = *(const dma_addr_t *)addr;
> size = sizeof(dma_addr_t);

Thanks, Rasmus, for review.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC] mm: Rework virtual memory accounting

[Linus Torvalds]

On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov  wrote:
> Really sorry for delays. Konstantin, I slightly updated the
> changelog (to point where problem came from). Linus are you
> fine with accounting not only anonymous memory in VmData?

The patch looks ok to me. I guess if somebody relies on old behavior
we may have to tweak it a bit, but on the whole this looks sane and
I'd be happy to merge it in the 4.5 merge window (and maybe even have
it marked for stable if it works out)

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

Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

[Andrew Morton]

On Wed,  9 Dec 2015 12:19:37 +0900 Taku Izumi  wrote:

> This patch extends existing "kernelcore" option and
> introduces kernelcore=mirror option. By specifying
> "mirror" instead of specifying the amount of memory,
> non-mirrored (non-reliable) region will be arranged
> into ZONE_MOVABLE.
> 
> v1 -> v2:
>  - Refine so that the following case also can be
>handled properly:
> 
>  Node X:  |MM--MM|
>(legend) M: mirrored  -: not mirrrored
> 
>  In this case, ZONE_NORMAL and ZONE_MOVABLE are
>  arranged like bellow:
> 
>  Node X:  |MM--MM|
>   |ooxxoo| ZONE_NORMAL
> |ooxx| ZONE_MOVABLE
>(legend) o: present  x: absent
> 
> v2 -> v3:
>  - change the option name from kernelcore=reliable
>into kernelcore=mirror
>  - documentation fix so that users can understand
>nn[KMS] and mirror are exclusive

My earlier concern with this approach is the assumption that *all* of
the mirrored memory will be used to kernelcore.  The user might want to
use half the machine's mirrored memory for kernelcore and half for
regular memory but cannot do so.

However I think what I'm seeing from the discussion is that in this
case, the user can alter the amount of mirrored memory via EFI to
achieve the same effect.

Is this correct?  If so, should we document this somewhere and provide
our users with instructions on how to make the required EFI changes? 
Or is this all so totally obvious to them that there is no need?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 1/1] lib/vsprintf: refactor duplicate code to xnumber()

[Rasmus Villemoes]

On Mon, Dec 28 2015, Rasmus Villemoes  wrote:

>
> Is there any aspect of the passed-through printf_spec which isn't
> overridden in xnumber? The users are/will be various %p extensions,
> which probably means that no-one passes a non-default precision (gcc
> complains about %.*p), and the remaining possible flags (PLUS, LEFT,
> SPACE) are useless and/or impossible to pass to %p

Actually, LEFT can be passed to %p (or get set by passing a negative
field width via %*p), which would be actively harmful: When LEFT is set,
number() explicitly removes the ZEROPAD flag, so we'd get "0xabcdef  "
instead of "0x00abcdef".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] extcon: Add the EXTCON_CHG_USB_SDP to support SDP charing port

[Krzysztof Kozlowski]

On 29.12.2015 09:37, Chanwoo Choi wrote:
> This patch adds the new EXTCON_CHG_USB_SDP connector to support SDP (Standard
> Downstream Port) USB charging port. The commit 11eecf910bd8 ("extcon: Modify
> the id and name of external connector") add the new EXTCON_CHG_USB_SDP
> connector which support the both data transfer and usb charging at the same
> time.
> 
> Cc: Krzysztof Kozlowski 
> Cc: MyungJoo Ham 
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/extcon/extcon-max14577.c |  3 +++
>  drivers/extcon/extcon-max77693.c | 12 ++--
>  drivers/extcon/extcon-max77843.c |  3 +++
>  drivers/extcon/extcon-max8997.c  |  3 +++
>  drivers/extcon/extcon-rt8973a.c  |  4 
>  drivers/extcon/extcon-sm5502.c   |  4 
>  6 files changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-max14577.c 
> b/drivers/extcon/extcon-max14577.c
> index b30ab97ce75f..852a7112f451 100644
> --- a/drivers/extcon/extcon-max14577.c
> +++ b/drivers/extcon/extcon-max14577.c
> @@ -150,6 +150,7 @@ enum max14577_muic_acc_type {
>  
>  static const unsigned int max14577_extcon_cable[] = {
>   EXTCON_USB,
> + EXTCON_CHG_USB_SDP,
>   EXTCON_CHG_USB_DCP,
>   EXTCON_CHG_USB_FAST,
>   EXTCON_CHG_USB_SLOW,
> @@ -454,6 +455,8 @@ static int max14577_muic_chg_handler(struct 
> max14577_muic_info *info)
>   return ret;
>  
>   extcon_set_cable_state_(info->edev, EXTCON_USB, attached);
> + extcon_set_cable_state_(info->edev, EXTCON_CHG_USB_SDP,
> + attached);
>   break;
>   case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
>   extcon_set_cable_state_(info->edev, EXTCON_CHG_USB_DCP,
> diff --git a/drivers/extcon/extcon-max77693.c 
> b/drivers/extcon/extcon-max77693.c
> index fdf8f5d4d4e9..b472f2405534 100644
> --- a/drivers/extcon/extcon-max77693.c
> +++ b/drivers/extcon/extcon-max77693.c
> @@ -204,6 +204,7 @@ enum max77693_muic_acc_type {
>  static const unsigned int max77693_extcon_cable[] = {
>   EXTCON_USB,
>   EXTCON_USB_HOST,
> + EXTCON_CHG_USB_SDP,
>   EXTCON_CHG_USB_DCP,
>   EXTCON_CHG_USB_FAST,
>   EXTCON_CHG_USB_SLOW,
> @@ -512,8 +513,11 @@ static int max77693_muic_dock_handler(struct 
> max77693_muic_info *info,
>   break;
>   case MAX77693_MUIC_ADC_AV_CABLE_NOLOAD: /* Dock-Audio */
>   dock_id = EXTCON_DOCK;
> - if (!attached)
> + if (!attached) {
>   extcon_set_cable_state_(info->edev, EXTCON_USB, false);
> + extcon_set_cable_state_(info->edev, EXTCON_CHG_USB_SDP,
> + false);
> + }
>   break;
>   default:
>   dev_err(info->dev, "failed to detect %s dock device\n",
> @@ -601,6 +605,8 @@ static int max77693_muic_adc_ground_handler(struct 
> max77693_muic_info *info)
>   if (ret < 0)
>   return ret;
>   extcon_set_cable_state_(info->edev, EXTCON_USB, attached);
> + extcon_set_cable_state_(info->edev, EXTCON_CHG_USB_SDP,
> + attached);
>   break;
>   case MAX77693_MUIC_GND_MHL:
>   case MAX77693_MUIC_GND_MHL_VB:
> @@ -830,6 +836,8 @@ static int max77693_muic_chg_handler(struct 
> max77693_muic_info *info)
>*/
>   extcon_set_cable_state_(info->edev, EXTCON_USB,
>   attached);
> + extcon_set_cable_state_(info->edev, EXTCON_CHG_USB_SDP,
> + attached);
>  
>   if (!cable_attached)
>   extcon_set_cable_state_(info->edev, EXTCON_DOCK,
> @@ -897,7 +905,7 @@ static int max77693_muic_chg_handler(struct 
> max77693_muic_info *info)
>   if (ret < 0)
>   return ret;
>  
> - extcon_set_cable_state_(info->edev, EXTCON_USB,
> + extcon_set_cable_state_(info->edev, EXTCON_CHG_USB_SDP,
>   attached);


Why for MAX77693_CHARGER_TYPE_USB you are not setting the EXTCON_USB
type? From the description and max14577 code I would suspect that you
want to set both: USB and SDP.

>   break;
>   case MAX77693_CHARGER_TYPE_DEDICATED_CHG:
> diff --git a/drivers/extcon/extcon-max77843.c 
> b/drivers/extcon/extcon-max77843.c
> index 74dfb7f4f277..7bbc30097771 100644
> --- a/drivers/extcon/extcon-max77843.c
> +++ b/drivers/extcon/extcon-max77843.c
> @@ -122,6 +122,7 @@ enum max77843_muic_charger_type {
>  static const unsigned int max77843_extcon_cable[] = {
>   EXTCON_USB,
>   EXTCON_USB_HOST,
> + EXTCON_CHG_USB_SDP,
>   EXTCON_CHG_USB_DCP,
>   

[PATCH 1/1] kernel booting messages, first line

[Alexandru GOIA]

For -rc8 ,

Hoping that someone DO cares about the aesthetic of kernel messages at boot :

 
What it does : first line of booting kernel, as seen in dmesg(1), will be the 
Linux kernel signature
(version, compiler, compiler hostname).

What it solves : it appers ahead of cgroup messages at booting.


This ugliness, since 3.10.x kernel.


So :

Instead of the unaesthetic lines :

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 4 ...


... We will have :


Linux version 4 ...
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct


As normal .


In file linux-4.4-rc7/init/main.c  :



--- main.c  2015-12-28 04:17:37.0 +0200
+++ main+.c 2015-12-29 03:18:59.896820046 +0200
@@ -512,6 +512,7 @@
  * Set up the the initial canary ASAP:
  */
 boot_init_stack_canary();
+   pr_notice("%s", linux_banner);
 
 cgroup_init_early();
 
@@ -524,7 +525,6 @@
  */
 boot_cpu_init();
 page_address_init();
-   pr_notice("%s", linux_banner);
 setup_arch(_line);
 mm_init_cpumask(_mm);
 setup_command_line(command_line);




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

Charity Donation

[Jeff Skoll]

Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the 
largest private foundations in the world. I believe strongly in ‘giving while 
living.’ I had one idea that never changed in my mind — that you should use 
your wealth to help people and I have decided to secretly give USD2.498 Million 
to a randomly selected individual. On receipt of this email, you should count 
yourself as the individual. Kindly get back to me at your earliest convenience, 
so I know your email address is valid.

Visit the web page to know more about me: 
http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/
 or you can read an article of me on Wikipedia.

Regards,
Jeffrey Skoll.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [f2fs-dev] [PATCH 1/3] f2fs: early check broken symlink length in the encrypted case

[Chao Yu]

Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, December 29, 2015 7:32 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 1/3] f2fs: early check broken symlink length in 
> the encrypted case
> 
> If link is broken, its len is zero, and we don't need to move forward.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/namei.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index fb41c80..5cc4128 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -931,7 +931,7 @@ static const char *f2fs_encrypted_follow_link(struct 
> dentry *dentry, void
> **cook
>  {
>   struct page *cpage = NULL;
>   char *caddr, *paddr = NULL;
> - struct f2fs_str cstr;
> + struct f2fs_str cstr = FSTR_INIT(NULL, 0);
>   struct f2fs_str pstr = FSTR_INIT(NULL, 0);
>   struct inode *inode = d_inode(dentry);
>   struct f2fs_encrypted_symlink_data *sd;
> @@ -952,6 +952,12 @@ static const char *f2fs_encrypted_follow_link(struct 
> dentry *dentry, void
> **cook
>   /* Symlink is encrypted */
>   sd = (struct f2fs_encrypted_symlink_data *)caddr;
>   cstr.len = le16_to_cpu(sd->len);
> +
> + /* this is broken symlink case */
> + if (cstr.len == 0) {

This case seems rare, can we add unlikely here?

> + res = -ENOENT;
> + goto errout;
> + }
>   cstr.name = kmalloc(cstr.len, GFP_NOFS);
>   if (!cstr.name) {
>   res = -ENOMEM;
> @@ -960,7 +966,7 @@ static const char *f2fs_encrypted_follow_link(struct 
> dentry *dentry, void
> **cook
>   memcpy(cstr.name, sd->encrypted_path, cstr.len);
> 
>   /* this is broken symlink case */
> - if (cstr.name[0] == 0 && cstr.len == 0) {
> + if (cstr.name[0] == 0) {

ditto.

Thanks,

>   res = -ENOENT;
>   goto errout;
>   }
> --
> 2.5.4 (Apple Git-61)
> 
> 
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: bindings: add dt documentation for Rockchip eMMC PHY

[Shawn Lin]

This patch adds a binding that describes the Rockchip eMMC PHYs
found on Rockchip SoCs eMMC interface.

Signed-off-by: Shawn Lin 
---

 .../devicetree/bindings/phy/rockchip-emmc-phy.txt | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
new file mode 100644
index 000..61916f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
@@ -0,0 +1,19 @@
+Rockchip EMMC PHY
+---
+
+Required properties:
+ - compatible: rockchip,rk3399-emmc-phy
+ - rockchip,grf : phandle to the syscon managing the "general
+   register files"
+ - #phy-cells: must be 0
+ - reg: PHY configure reg address offset in "general
+   register files"
+
+Example:
+
+emmcphy: phy {
+   compatible = "rockchip,rk3399-emmc-phy";
+   rockchip,grf = <>;
+   reg = <0xf780>;
+   #phy-cells = <0>;
+};
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] phy: add a driver for the Rockchip SoC internal eMMC PHY

[Shawn Lin]

This patch to add a generic PHY driver for ROCKCHIP eMMC PHY.
Access the PHY via registers provided by GRF (general register
files) module.

Signed-off-by: Shawn Lin 
---

 drivers/phy/Kconfig |   7 ++
 drivers/phy/Makefile|   1 +
 drivers/phy/phy-rockchip-emmc.c | 256 
 3 files changed, 264 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-emmc.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 03cb3ea..47d16e3 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -320,6 +320,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_EMMC
+   tristate "Rockchip EMMC PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip EMMC PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..ed8f175 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-emmc.c b/drivers/phy/phy-rockchip-emmc.c
new file mode 100644
index 000..78f51a2
--- /dev/null
+++ b/drivers/phy/phy-rockchip-emmc.c
@@ -0,0 +1,256 @@
+/*
+ * Rockchip emmc PHY driver
+ *
+ * Copyright (C) 2015 Shawn Lin 
+ * Copyright (C) 2015 ROCKCHIP, Inc.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The higher 16-bit of this register is used for write protection
+ * only if BIT(x + 16) set to 1 the BIT(x) can be written.
+ */
+#define HIWORD_UPDATE(val, mask, shift) \
+   ((val) << (shift) | (mask) << ((shift) + 16))
+
+/* Register definition */
+#define GRF_EMMCPHY_CON0   0x0
+#define GRF_EMMCPHY_CON1   0x4
+#define GRF_EMMCPHY_CON2   0x8
+#define GRF_EMMCPHY_CON3   0xc
+#define GRF_EMMCPHY_CON4   0x10
+#define GRF_EMMCPHY_CON5   0x14
+#define GRF_EMMCPHY_CON6   0x18
+#define GRF_EMMCPHY_STATUS 0x20
+
+#define PHYCTRL_PDB_MASK   0x1
+#define PHYCTRL_PDB_SHIFT  0x0
+#define PHYCTRL_PDB_PWR_ON 0x1
+#define PHYCTRL_PDB_PWR_OFF0x0
+#define PHYCTRL_ENDLL_MASK 0x1
+#define PHYCTRL_ENDLL_SHIFT 0x1
+#define PHYCTRL_ENDLL_ENABLE   0x1
+#define PHYCTRL_ENDLL_DISABLE  0x0
+#define PHYCTRL_CALDONE_MASK   0x1
+#define PHYCTRL_CALDONE_SHIFT   0x6
+#define PHYCTRL_CALDONE_DONE   0x1
+#define PHYCTRL_CALDONE_GOING  0x0
+#define PHYCTRL_DLLRDY_MASK0x1
+#define PHYCTRL_DLLRDY_SHIFT   0x5
+#define PHYCTRL_DLLRDY_DONE0x1
+#define PHYCTRL_DLLRDY_GOING   0x0
+
+struct rockchip_emmc_phy {
+   unsigned intreg_offset;
+   struct regmap   *reg_base;
+   struct phy  *phy;
+   boolstate;
+};
+
+static int rockchip_emmc_phy_power(struct rockchip_emmc_phy *rk_phy,
+  bool on_off)
+{
+   unsigned int caldone;
+   unsigned int dllrdy;
+
+   /*
+* Keep phyctrl_pdb and phyctrl_endll low to allow
+* initialization of CALIO state M/C DFFs
+*/
+   regmap_write(rk_phy->reg_base,
+rk_phy->reg_offset + GRF_EMMCPHY_CON6,
+HIWORD_UPDATE(PHYCTRL_PDB_PWR_OFF,
+  PHYCTRL_PDB_MASK,
+  PHYCTRL_PDB_SHIFT));
+   regmap_write(rk_phy->reg_base,
+rk_phy->reg_offset + GRF_EMMCPHY_CON6,
+HIWORD_UPDATE(PHYCTRL_ENDLL_DISABLE,
+  PHYCTRL_ENDLL_MASK,
+  PHYCTRL_ENDLL_SHIFT));
+
+   /* Already finish power_off above */
+   if (on_off == PHYCTRL_PDB_PWR_OFF)
+   return 0;
+
+   /*
+* According to the user manual, calpad calibration
+* cycle takes more than 2us without the minimal recommended
+   

Re: [RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock

[Yakir Yang]

Hi Heiko,

On 12/28/2015 08:41 PM, Heiko Stübner wrote:

Hi,

Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:

Due to referred old version TRM, there is incorrect emac clock node,
we should fix it. The SEL_21_9 is the parent of SEL_21_4.

In the emac driver, we need to refer HCLK_MAC, and  because There are
only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
GPLL, and it is unable to provide the accurate rate for mac_ref which
need to 50MHz probability, we should let it under the APLL and are
able to set the freq which integer multiples of 50MHz, so we add these
emac node for reference.

I don't really follow here. While I do understand that the emac needs 50MHz, I
don't think using the APLL as source is helpful.

The APLL is the main clocksource for the cpu-cores, including frequency
scaling, and while it currently only lists 816MHz as sole frequency, you're
pretty much guaranteed to not get your correct multiple of 50MHz from there
either. And limiting the cpu to just do 600MHz to get the mac working sounds
pretty bad ;-) .


In the rk3036 cru-node the gpll gets set to 594MHz. Is there a special reason
why it needs to be 594MHz and cannot be a round 600MHz? Because that would
also provide your 50MHz-multiple nicely.


Yes, this magic 594MHz would help to support the standard HDMI 
resolutions, here are the math:


1920x1080-60Hz DCLK = 148.5MHz = 594MHz / 4
1280x720-60Hz DCLK = 74.25MHz = 594MHz / 8
720x480-60Hz DCLK = 27MHz = 594MHz / 22

Thanks,
- Yakir


Signed-off-by: Xing Zheng 
---

  drivers/clk/rockchip/clk-rk3036.c  |   11 ++-
  include/dt-bindings/clock/rk3036-cru.h |2 ++
  2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3036.c
b/drivers/clk/rockchip/clk-rk3036.c index 7420cbe..7863c4d 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -328,13 +328,14 @@ static struct rockchip_clk_branch
rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2, MFLAGS,
2, 5, DFLAGS,
RK2928_CLKGATE_CON(10), 5, GFLAGS),

-   COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
-   RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 4, 5, DFLAGS),
+   MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
+   RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
+   DIV(0, "mac_pll_src", "mac_pll_pre", 0,
+   RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
MUX(SCLK_MACREF, "mac_clk_ref", mux_mac_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(21), 3, 1, MFLAGS),
-
COMPOSITE_NOMUX(SCLK_MAC, "mac_clk", "mac_clk_ref", 0,
-   RK2928_CLKSEL_CON(21), 9, 5, DFLAGS,
+   RK2928_CLKSEL_CON(21), 4, 5, DFLAGS,
RK2928_CLKGATE_CON(2), 6, GFLAGS),

MUX(SCLK_HDMI, "dclk_hdmi", mux_dclk_p, 0,
@@ -389,7 +390,7 @@ static struct rockchip_clk_branch rk3036_clk_branches[]
__initdata = { GATE(HCLK_OTG1, "hclk_otg1", "hclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(7), 3, GFLAGS), GATE(HCLK_I2S, "hclk_i2s", "hclk_peri",
0, RK2928_CLKGATE_CON(7), 2, GFLAGS), GATE(0, "hclk_sfc", "hclk_peri",
CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 14, GFLAGS), -GATE(0,
"hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 15,
GFLAGS), +  GATE(HCLK_MAC, "hclk_mac", "hclk_peri", 0,
RK2928_CLKGATE_CON(3), 5, GFLAGS),

/* pclk_peri gates */
GATE(0, "pclk_peri_matrix", "pclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(4), 1, GFLAGS), diff --git
a/include/dt-bindings/clock/rk3036-cru.h
b/include/dt-bindings/clock/rk3036-cru.h index ebc7a7b..de44109 100644
--- a/include/dt-bindings/clock/rk3036-cru.h
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -54,6 +54,7 @@
  #define SCLK_PVTM_VIDEO   125
  #define SCLK_MAC  151
  #define SCLK_MACREF   152
+#define SCLK_MACPLL153
  #define SCLK_SFC  160

  /* aclk gates */
@@ -92,6 +93,7 @@

please separate the hclk addition into two separate patches:
patch1: add the clock-id to the dt-binding header
patch2: use the clock in the clock-driver


  #define HCLK_SDMMC456
  #define HCLK_SDIO 457
  #define HCLK_EMMC 459
+#define HCLK_MAC   460
  #define HCLK_I2S  462
  #define HCLK_LCDC 465
  #define HCLK_ROM  467


Thanks
Heiko

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip






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

Assalam o Alaikum

[Zahra Robert]

Cordial greeting message from Eva Zahra, I am seeking for your help,I will
be very glad if you do assist me to relocate a sum of (US$4 Million
Dollars)into your Bank account in your country for the benefit of both of
us i want to use this money for investment. I will give you more details
as you reply Yours Eva Zahra Robert

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

[PATCH 1/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Commit 69fb4dcada77 ("power: Add an axp20x-usb-power driver") introduced a new
driver for the USB power supply used on various Allwinner based SBCs. However,
the driver was not added to sunxi_defconfig which breaks USB support for some
boards (e.g. LeMaker BananaPi) as the kernel will now turn off the USB power
supply during boot by default if the driver isn't present. (This was not the
case in linux 4.3 or lower where the USB power was always left on.)

Hence, add the driver to sunxi_defconfig in order to keep USB support working
on those boards that require it.

Signed-off-by: Timo Sigurdsson 
Reported-by: David Tulloh 
Tested-by: David Tulloh 
Tested-by: Timo Sigurdsson 
---
 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..b503a89 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -84,6 +84,7 @@ CONFIG_SPI_SUN4I=y
 CONFIG_SPI_SUN6I=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_POWER_SUPPLY=y
+CONFIG_AXP20X_POWER=y
 CONFIG_THERMAL=y
 CONFIG_CPU_THERMAL=y
 CONFIG_WATCHDOG=y
-- 
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 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this   
could make it into 4.4 in order to avoid unpleasent surprises (and
subsequent questions) with builds based on sunxi_defconfig. At the moment,
some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports
as a newly added driver is required to power them.

Timo Sigurdsson (1):
  ARM: Fix broken USB support in sunxi_defconfig

 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

-- 
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: [LKP] [lkp] [ses] 3417c1b5cb: WARNING: CPU: 2 PID: 2013 at fs/xfs/xfs_file.c:772 xfs_file_dio_aio_write+0x2a2/0x320()

[James Bottomley]

On Mon, 2015-12-28 at 16:04 +0800, Huang, Ying wrote:
> James Bottomley  writes:
> 
> > [cc to linux-scsi added]
> > On Mon, 2015-12-28 at 09:43 +0800, kernel test robot wrote:
> > > FYI, we noticed the below changes on
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi
> > > t ma
> > > ster
> > > commit 3417c1b5cb1fdc10261dbed42b05cc93166a78fd ("ses: Fix
> > > problems
> > > with simple enclosures")
> > > 
> > > This may be the intended behavior, we found after your commit,
> > > the
> > > following new message appears in kernel log:
> > > 
> > > [   40.804515] scsi 8:0:12:0: Wrong diagnostic page; asked for 7
> > > got
> > > 0
> > > 
> > > To reproduce:
> > > 
> > > git clone
> > > git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > > cd lkp-tests
> > > bin/lkp install job.yaml  # job file is attached in this
> > > email
> > > bin/lkp run job.yaml
> > 
> > OK, so what is the enclosure device at host 8?  And what happens
> > when
> > you use sg_ses to ask for page 7?
> 
> We run xfstests on the test machine.  You can check the dmesg
> (kmsg.xz)
> attached in the original reporting email for information about scsi
> host
> 8.

It's not a test failure, it's a problem with your hardware, which looks
to be a Promise SAS expander with enclosure services. 

can you run sg_ses  on it followed by sg_ses --page=7 --hex ?
 To get the sg device run sg_map -i and it should tell you what the
mappings are.

Thanks,

James
 

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

Re: [RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock

[Xing Zheng]

On 2015年12月29日 09:59, Yakir Yang wrote:

Hi Heiko,

On 12/28/2015 08:41 PM, Heiko Stübner wrote:

Hi,

Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:

Due to referred old version TRM, there is incorrect emac clock node,
we should fix it. The SEL_21_9 is the parent of SEL_21_4.

In the emac driver, we need to refer HCLK_MAC, and because There are
only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
GPLL, and it is unable to provide the accurate rate for mac_ref which
need to 50MHz probability, we should let it under the APLL and are
able to set the freq which integer multiples of 50MHz, so we add these
emac node for reference.
I don't really follow here. While I do understand that the emac needs 
50MHz, I

don't think using the APLL as source is helpful.

The APLL is the main clocksource for the cpu-cores, including frequency
scaling, and while it currently only lists 816MHz as sole frequency, 
you're
pretty much guaranteed to not get your correct multiple of 50MHz from 
there
either. And limiting the cpu to just do 600MHz to get the mac working 
sounds

pretty bad ;-) .


In the rk3036 cru-node the gpll gets set to 594MHz. Is there a 
special reason
why it needs to be 594MHz and cannot be a round 600MHz? Because that 
would

also provide your 50MHz-multiple nicely.


Yes, this magic 594MHz would help to support the standard HDMI 
resolutions, here are the math:


1920x1080-60Hz DCLK = 148.5MHz = 594MHz / 4
1280x720-60Hz DCLK = 74.25MHz = 594MHz / 8
720x480-60Hz DCLK = 27MHz = 594MHz / 22

Thanks,
- Yakir

Thanks Yakir.

Hi Heiko,
From the above, do you have better idea for the RK3036's emac without 
ext-oscillator?


Thanks. :-)



Signed-off-by: Xing Zheng 
---

drivers/clk/rockchip/clk-rk3036.c | 11 ++-
include/dt-bindings/clock/rk3036-cru.h | 2 ++
2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3036.c
b/drivers/clk/rockchip/clk-rk3036.c index 7420cbe..7863c4d 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -328,13 +328,14 @@ static struct rockchip_clk_branch
rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2, 
MFLAGS,

2, 5, DFLAGS,
RK2928_CLKGATE_CON(10), 5, GFLAGS),

- COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
- RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 4, 5, DFLAGS),
+ MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
+ RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
+ DIV(0, "mac_pll_src", "mac_pll_pre", 0,
+ RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
MUX(SCLK_MACREF, "mac_clk_ref", mux_mac_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(21), 3, 1, MFLAGS),
-
COMPOSITE_NOMUX(SCLK_MAC, "mac_clk", "mac_clk_ref", 0,
- RK2928_CLKSEL_CON(21), 9, 5, DFLAGS,
+ RK2928_CLKSEL_CON(21), 4, 5, DFLAGS,
RK2928_CLKGATE_CON(2), 6, GFLAGS),

MUX(SCLK_HDMI, "dclk_hdmi", mux_dclk_p, 0,
@@ -389,7 +390,7 @@ static struct rockchip_clk_branch 
rk3036_clk_branches[]
__initdata = { GATE(HCLK_OTG1, "hclk_otg1", "hclk_peri", 
CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(7), 3, GFLAGS), GATE(HCLK_I2S, "hclk_i2s", 
"hclk_peri",

0, RK2928_CLKGATE_CON(7), 2, GFLAGS), GATE(0, "hclk_sfc", "hclk_peri",
CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 14, GFLAGS), - GATE(0,
"hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 15,
GFLAGS), + GATE(HCLK_MAC, "hclk_mac", "hclk_peri", 0,
RK2928_CLKGATE_CON(3), 5, GFLAGS),

/* pclk_peri gates */
GATE(0, "pclk_peri_matrix", "pclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(4), 1, GFLAGS), diff --git
a/include/dt-bindings/clock/rk3036-cru.h
b/include/dt-bindings/clock/rk3036-cru.h index ebc7a7b..de44109 100644
--- a/include/dt-bindings/clock/rk3036-cru.h
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -54,6 +54,7 @@
#define SCLK_PVTM_VIDEO 125
#define SCLK_MAC 151
#define SCLK_MACREF 152
+#define SCLK_MACPLL 153
#define SCLK_SFC 160

/* aclk gates */
@@ -92,6 +93,7 @@

please separate the hclk addition into two separate patches:
patch1: add the clock-id to the dt-binding header
patch2: use the clock in the clock-driver

Done.



#define HCLK_SDMMC 456
#define HCLK_SDIO 457
#define HCLK_EMMC 459
+#define HCLK_MAC 460
#define HCLK_I2S 462
#define HCLK_LCDC 465
#define HCLK_ROM 467


Thanks
Heiko

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip










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

Re: 4.4-rc, intel dri i915, regular hangs and corruptions

[Chris Bainbridge]

On 17 December 2015 at 18:34, Norbert Preining  wrote:
> * font corruption
>   sometime sets of glyphs, or practically all glyphs disappear
>   related probably to bug
>   https://bugs.freedesktop.org/show_bug.cgi?id=55500
>   I have sent some info there already, without response
>
>   Currently my font displays some kind of strange symbols instead of
>   an m ... looks a bit like a Kanji.

I remember a similar bug around 2.99.917 but that tag is over a year
old now and there have been many bug fixes since. You'll need to
verify you can still reproduce your issue with the latest from
git://anongit.freedesktop.org/xorg/driver/xf86-video-intel and if so
do a bisect from the previous working kernel or xf86-video-intel to
identify the problematic commit.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 04/20] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead

[Zhangjian (Bamvor)]

Fix the title.

On 16:43 2015/12/28, Bamvor Jian Zhang wrote:

I feel we need something like this to avoid the failure of compiling
when build with ARM64_ILP32(which will select COMPAT) and
ARMV8_DEPRECATED (which depends on the opcodes.o).

 From f8b8ffdb449491ecf8ba465238bbdb4625a74ac0 Mon Sep 17 00:00:00 2001
From: Bamvor Jian Zhang 
Date: Mon, 28 Dec 2015 12:57:46 +0800
Subject: [PATCH] arm64: compat: fix wrong dependency of ARMV8_DEPRECATED

When compile with ARM64_ILP32, ARMV8_DEPRECATED will be selected due
to the dependency of COMPAT. It leads to the following error:
 LD  init/built-in.o
 arch/arm64/kernel/built-in.o: In function `cp15barrier_handler':
 
/home/bamvor/works/source/kernel/linux_ilp32/arch/arm64/kernel/armv8_deprecated.c:467:
 undefined reference to `arm_check_condition'
 
/home/bamvor/works/source/kernel/linux_ilp32/arch/arm64/kernel/armv8_deprecated.c:467:
 undefined reference to `arm_check_condition'
 arch/arm64/kernel/built-in.o: In function `swp_handler':
 
/home/bamvor/works/source/kernel/linux_ilp32/arch/arm64/kernel/armv8_deprecated.c:386:
 undefined reference to `arm_check_condition'
 
/home/bamvor/works/source/kernel/linux_ilp32/arch/arm64/kernel/armv8_deprecated.c:386:
 undefined reference to `arm_check_condition'
 Makefile:927: recipe for target 'vmlinux' failed
 make: *** [vmlinux] Error 1

This patch fix this by updating the dependency from COMPAT to
AARCH32_EL0.

Signed-off-by: Bamvor Jian Zhang 
---
  arch/arm64/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index deec37a..e52fd03 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -509,7 +509,7 @@ config FORCE_MAX_ZONEORDER

  menuconfig ARMV8_DEPRECATED
bool "Emulate deprecated/obsolete ARMv8 instructions"
-   depends on COMPAT
+   depends on AARCH32_EL0
help
  Legacy software support may require certain instructions
  that have been deprecated or obsoleted in the architecture.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection

[Julia Lawall]

On Mon, 28 Dec 2015, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Mon, 28 Dec 2015 10:10:34 +0100
>
> This issue was detected by using the Coccinelle software.
>
> Move the jump label directly before the desired log statement
> so that the variable "ret" will not be checked once more
> after it was determined that a function call failed.

Why not avoid both unnecessary ifs and the enormous ugliness of a label
inside an if by making two returns: a return 0 for success and a dev_dbg
and return ret for failure?

julia


> Signed-off-by: Markus Elfring 
> ---
>  drivers/media/tuners/m88rs6000t.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/tuners/m88rs6000t.c 
> b/drivers/media/tuners/m88rs6000t.c
> index 504bfbc..b45594e 100644
> --- a/drivers/media/tuners/m88rs6000t.c
> +++ b/drivers/media/tuners/m88rs6000t.c
> @@ -510,27 +510,27 @@ static int m88rs6000t_get_rf_strength(struct 
> dvb_frontend *fe, u16 *strength)
>
>   ret = regmap_read(dev->regmap, 0x5A, );
>   if (ret)
> - goto err;
> + goto report_failure;
>   RF_GC = val & 0x0f;
>
>   ret = regmap_read(dev->regmap, 0x5F, );
>   if (ret)
> - goto err;
> + goto report_failure;
>   IF_GC = val & 0x0f;
>
>   ret = regmap_read(dev->regmap, 0x3F, );
>   if (ret)
> - goto err;
> + goto report_failure;
>   TIA_GC = (val >> 4) & 0x07;
>
>   ret = regmap_read(dev->regmap, 0x77, );
>   if (ret)
> - goto err;
> + goto report_failure;
>   BB_GC = (val >> 4) & 0x0f;
>
>   ret = regmap_read(dev->regmap, 0x76, );
>   if (ret)
> - goto err;
> + goto report_failure;
>   PGA2_GC = val & 0x3f;
>   PGA2_cri = PGA2_GC >> 2;
>   PGA2_crf = PGA2_GC & 0x03;
> @@ -562,9 +562,11 @@ static int m88rs6000t_get_rf_strength(struct 
> dvb_frontend *fe, u16 *strength)
>   /* scale value to 0x-0x */
>   gain = clamp_val(gain, 1000U, 10500U);
>   *strength = (10500 - gain) * 0x / (10500 - 1000);
> -err:
> - if (ret)
> +
> + if (ret) {
> +report_failure:
>   dev_dbg(>client->dev, "failed=%d\n", ret);
> + }
>   return ret;
>  }
>
> --
> 2.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/23] Unrestricted media entity ID range support

[Mauro Carvalho Chehab]

Em Sun, 27 Dec 2015 19:11:36 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Wednesday 23 December 2015 10:32:42 Mauro Carvalho Chehab wrote:
> > Em Wed, 16 Dec 2015 16:03:01 +0200 Sakari Ailus escreveu:
> > > On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote:
> > > > This is the third version of the unrestricted media entity ID range
> > > > support set. I've taken Mauro's comments into account and fixed a number
> > > > of bugs as well (omap3isp memory leak and omap4iss stream start).
> > > 
> > > Javier: Mauro told me you might have OMAP4 hardware. Would you be able to
> > > test the OMAP4 ISS with these patches?
> > > 
> > > Thanks.
> > 
> > Sakari,
> > 
> > Testing with OMAP4 is not possible. The driver is broken: it doesn't
> > support DT, and the required pdata definition is missing.
> 
> What do you mean by missing ? struct iss_platform_data is defined in 
> include/media/omap4iss.h.
> 

As this driver is not DT, the platform data has to be part of the Kernel
tree for the driver to work. However, there are no board-specific data nor
any documentation about how to do that inside the Kernel tree. 
That means  that this driver won't work without some OOT patch.

So, on its current state, it is broken. It should either be
converted to DT and have the needed board definitions added to the
existing dts files or be removed.

Another possible approach would be to have a patch like the one
Javier and I tried to craft by adding the needed platform data
into arch/arm/mach-omap2/pdata-quirks.c, but I guess it is better
to just use DT instead.

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

[RFC PATCH 1/2] f2fs: enhance multithread dio write performance

[Chao Yu]

When performing big dio writes concurrently, our performace will be low
because of Thread A's allocation of multi continuous blocks will be
interrupted by Thread B, there are two cases as below:
 - In Thread B, we may change current segment to a new segment for LFS
   allocation if we dio write in the beginning of the file.
 - In Thread B, we may allocate blocks in the middle of Thread A's
   allocation, which make blocks allocated in Thread A being inconsecutive.

This patch adds writepages mutex lock to make block allocation in dio write
being atomic to avoid above issues.

Test environment 1:
ubuntu os with linux kernel 4.4-rc4, intel i7-3770, 16g memory,
32g kingston sd card.

fio --name seqw --ioengine=sync --invalidate=1 --rw=write --directory=/mnt/f2fs 
--filesize=256m --size=16m --bs=2m --direct=1
--numjobs=10

before:
  WRITE: io=163840KB, aggrb=5125KB/s, minb=512KB/s, maxb=776KB/s, 
mint=21105msec, maxt=31967msec
patched:
  WRITE: io=163840KB, aggrb=10424KB/s, minb=1042KB/s, maxb=1172KB/s, 
mint=13975msec, maxt=15717msec

Test environment 2:
Note4 eMMC

fio --name seqw --ioengine=sync --invalidate=1 --rw=write 
--directory=/data/test/ --filesize=256m --size=64m --bs=2m --direct=1
--numjobs=16

before:
  WRITE: io=1024.0MB, aggrb=103583KB/s, minb=6473KB/s, maxb=8806KB/s, 
mint=7442msec, maxt=10123msec
patched:
  WRITE: io=1024.0MB, aggrb=124860KB/s, minb=7803KB/s, maxb=9315KB/s, 
mint=7035msec, maxt=8398msec

Signed-off-by: Chao Yu 
---
 fs/f2fs/data.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 5c43b2d..6b24446 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1640,7 +1640,9 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct 
iov_iter *iter,
struct file *file = iocb->ki_filp;
struct address_space *mapping = file->f_mapping;
struct inode *inode = mapping->host;
+   struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
size_t count = iov_iter_count(iter);
+   int rw = iov_iter_rw(iter);
int err;
 
/* we don't need to use inline_data strictly */
@@ -1655,20 +1657,26 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, 
struct iov_iter *iter,
if (err)
return err;
 
-   trace_f2fs_direct_IO_enter(inode, offset, count, iov_iter_rw(iter));
+   trace_f2fs_direct_IO_enter(inode, offset, count, rw);
+
+   if (rw == WRITE) {
+   bool serialized = (F2FS_BYTES_TO_BLK(count) >= 64);
 
-   if (iov_iter_rw(iter) == WRITE) {
+   if (serialized)
+   mutex_lock(>writepages);
err = __allocate_data_blocks(inode, offset, count);
+   if (serialized)
+   mutex_unlock(>writepages);
if (err)
goto out;
}
 
err = blockdev_direct_IO(iocb, inode, iter, offset, get_data_block_dio);
 out:
-   if (err < 0 && iov_iter_rw(iter) == WRITE)
+   if (err < 0 && rw == WRITE)
f2fs_write_failed(mapping, offset + count);
 
-   trace_f2fs_direct_IO_exit(inode, offset, count, iov_iter_rw(iter), err);
+   trace_f2fs_direct_IO_exit(inode, offset, count, rw, err);
 
return err;
 }
-- 
2.6.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/

[RFC PATCH 2/2] f2fs: export a threshold in sysfs for controlling dio serialization

[Chao Yu]

As Yunlei He reported when he test with the patch ("f2fs: enhance
multithread dio write performance"):
"Does share writepages mutex lock have an effect on cache write?
Here is AndroBench result on my phone:

Before patch:
1R1W8R8W16R16W
Sequential Write161.31  163.85  154.67
Random  Write   9.4817.66   18.09

After patch:
1R1W8R8W16R16W
Sequential Write159.61  157.24  160.11
Random  Write   9.178.518.8

Unit:Mb/s, File size: 64M, Buffer size: 4k"

The turth is androidbench uses single thread with dio write to test performance
of sequential write, and use multi-threads with dio write to test performance
of random write. so we can not see any improvement in sequentail write test
since serializing dio page allocation can only improve performance in
multi-thread scenario, and there is a regression in multi-thread test with 4k
dio write, this is because grabbing sbi->writepages lock for serializing block
allocation stop the concurrency, so that less small dio bios could be merged,
moreover, when there are huge number of small dio writes, grabbing mutex lock
per dio increases the overhead.

After all, serializing dio could only be used for concurrent scenario of
big dio, so this patch introduces a threshold in sysfs to provide user the
interface of defining 'a big dio' with specified page number, which could
be used to control wthether serialize or not that kind of dio with specified
page number.

Though, this is only RFC patch since the optimization works in rare scenario.

Signed-off-by: Chao Yu 
---
 Documentation/ABI/testing/sysfs-fs-f2fs | 12 
 fs/f2fs/data.c  |  3 ++-
 fs/f2fs/f2fs.h  |  3 +++
 fs/f2fs/super.c |  3 +++
 4 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 0345f2d..560a4f1 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -92,3 +92,15 @@ Date:October 2015
 Contact:   "Chao Yu" 
 Description:
 Controls the count of nid pages to be readaheaded.
+
+What:  /sys/fs/f2fs//serialized_dio_pages
+Date:  December 2015
+Contact:   "Chao Yu" 
+Description:
+It is a threshold with the unit of page size.
+ If DIO page count is equal or big than the threshold,
+ whole process of block address allocation of dio pages
+ will become atomic like buffered write.
+ It is used to maximize bandwidth utilization in the
+ scenario of concurrent write with dio vs buffered or
+ dio vs dio.
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 6b24446..abcd100 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1660,7 +1660,8 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct 
iov_iter *iter,
trace_f2fs_direct_IO_enter(inode, offset, count, rw);
 
if (rw == WRITE) {
-   bool serialized = (F2FS_BYTES_TO_BLK(count) >= 64);
+   bool serialized = (F2FS_BYTES_TO_BLK(count) >=
+   sbi->serialized_dio_pages);
 
if (serialized)
mutex_lock(>writepages);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 3406e99..8f35dd7 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -333,6 +333,8 @@ enum {
 
 #define MAX_DIR_RA_PAGES   4   /* maximum ra pages of dir */
 
+#define DEF_SERIALIZED_DIO_PAGES   64  /* default serialized dio pages 
*/
+
 /* vector size for gang look-up from extent cache that consists of radix tree 
*/
 #define EXT_TREE_VEC_SIZE  64
 
@@ -784,6 +786,7 @@ struct f2fs_sb_info {
unsigned int total_valid_inode_count;   /* valid inode count */
int active_logs;/* # of active logs */
int dir_level;  /* directory level */
+   int serialized_dio_pages;   /* serialized direct IO pages */
 
block_t user_block_count;   /* # of user blocks */
block_t total_valid_block_count;/* # of valid blocks */
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 75704d9..ebe9bd4 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -218,6 +218,7 @@ F2FS_RW_ATTR(NM_INFO, f2fs_nm_info, ram_thresh, ram_thresh);
 F2FS_RW_ATTR(NM_INFO, f2fs_nm_info, ra_nid_pages, ra_nid_pages);
 F2FS_RW_ATTR(F2FS_SBI, f2fs_sb_info, max_victim_search, max_victim_search);
 F2FS_RW_ATTR(F2FS_SBI, f2fs_sb_info, dir_level, dir_level);
+F2FS_RW_ATTR(F2FS_SBI, f2fs_sb_info, serialized_dio_pages, 
serialized_dio_pages);
 

Re: [PATCH 1/8] mm: Add optional support for PUD-sized transparent hugepages

[Kirill A. Shutemov]

On Thu, Dec 24, 2015 at 11:20:30AM -0500, Matthew Wilcox wrote:
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 4bf3811..e14634f 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1958,6 +1977,17 @@ static inline spinlock_t *pmd_lock(struct mm_struct 
> *mm, pmd_t *pmd)
>   return ptl;
>  }
>  
> +/*
> + * No scalability reason to split PUD locks yet, but follow the same pattern
> + * as the PMD locks to make it easier if we have to.
> + */

I don't think it makes any good unless you convert all other places where
we use page_table_lock to protect pud table (like __pud_alloc()) to the
same API.
I think this would deserve separate patch.

> +static inline spinlock_t *pud_lock(struct mm_struct *mm, pud_t *pud)
> +{
> + spinlock_t *ptl = >page_table_lock;
> + spin_lock(ptl);
> + return ptl;
> +}
> +
>  extern void free_area_init(unsigned long * zones_size);
>  extern void free_area_init_node(int nid, unsigned long * zones_size,
>   unsigned long zone_start_pfn, unsigned long *zholes_size);

...

> diff --git a/mm/memory.c b/mm/memory.c
> index 416b129..7328df0 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1220,9 +1220,27 @@ static inline unsigned long zap_pud_range(struct 
> mmu_gather *tlb,
>   pud = pud_offset(pgd, addr);
>   do {
>   next = pud_addr_end(addr, end);
> + if (pud_trans_huge(*pud) || pud_devmap(*pud)) {
> + if (next - addr != HPAGE_PUD_SIZE) {
> +#ifdef CONFIG_DEBUG_VM

IS_ENABLED(CONFIG_DEBUG_VM) ?

> + if (!rwsem_is_locked(>mm->mmap_sem)) {
> + pr_err("%s: mmap_sem is unlocked! 
> addr=0x%lx end=0x%lx vma->vm_start=0x%lx vma->vm_end=0x%lx\n",
> + __func__, addr, end,
> + vma->vm_start,
> + vma->vm_end);

dump_vma(), I guess.

> + BUG();
> + }
> +#endif
> + split_huge_pud(vma, pud, addr);
> + } else if (zap_huge_pud(tlb, vma, pud, addr))
> + goto next;
> + /* fall through */
> + }
>   if (pud_none_or_clear_bad(pud))
>   continue;
>   next = zap_pmd_range(tlb, vma, pud, addr, next, details);
> +next:
> + cond_resched();
>   } while (pud++, addr = next, addr != end);
>  
>   return addr;
-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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,RESEND] clk: uniphier: add clock drivers for UniPhier SoCs

[Masahiro Yamada]

This is the initial commit for the UniPhier clock drivers, including
support for PH1-sLD3, PH1-LD4, PH1-Pro4, PH1-sLD8, PH1-Pro5, and
ProXstream2/PH1-LD6b.

To improve the code maintainability, the driver consists of common
functions (clk-uniphier-core.c) and clock data arrays needed to
support each SoC.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - split emmc_hw_reset
  - make SD clock rate-controllable
  - add CLK_SET_RATE_PARENT flag to mux, gate, fixed-factor clocks

 MAINTAINERS  |   1 +
 drivers/clk/Kconfig  |   1 +
 drivers/clk/Makefile |   1 +
 drivers/clk/uniphier/Kconfig |  35 
 drivers/clk/uniphier/Makefile|  10 +
 drivers/clk/uniphier/clk-ph1-ld4.c   | 117 
 drivers/clk/uniphier/clk-ph1-pro4.c  | 117 
 drivers/clk/uniphier/clk-ph1-pro5.c  | 107 +++
 drivers/clk/uniphier/clk-ph1-sld3.c  | 117 
 drivers/clk/uniphier/clk-ph1-sld8.c  | 107 +++
 drivers/clk/uniphier/clk-proxstream2.c   |  88 +
 drivers/clk/uniphier/clk-uniphier-core.c | 151 +++
 drivers/clk/uniphier/clk-uniphier-mio.c  | 315 +++
 drivers/clk/uniphier/clk-uniphier-peri.c | 175 +
 drivers/clk/uniphier/clk-uniphier.h  |  68 +++
 15 files changed, 1410 insertions(+)
 create mode 100644 drivers/clk/uniphier/Kconfig
 create mode 100644 drivers/clk/uniphier/Makefile
 create mode 100644 drivers/clk/uniphier/clk-ph1-ld4.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-pro4.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-pro5.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-sld3.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-sld8.c
 create mode 100644 drivers/clk/uniphier/clk-proxstream2.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier-core.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier-mio.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier-peri.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier.h

diff --git a/MAINTAINERS b/MAINTAINERS
index fc08493..6c10e9b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1644,6 +1644,7 @@ F:arch/arm/mach-uniphier/
 F: arch/arm/mm/cache-uniphier.c
 F: arch/arm64/boot/dts/socionext/
 F: drivers/bus/uniphier-system-bus.c
+F: drivers/clk/uniphier/
 F: drivers/i2c/busses/i2c-uniphier*
 F: drivers/pinctrl/uniphier/
 F: drivers/tty/serial/8250/8250_uniphier.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02..7580323 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -191,6 +191,7 @@ config COMMON_CLK_CDCE706
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
 source "drivers/clk/qcom/Kconfig"
+source "drivers/clk/uniphier/Kconfig"
 
 endmenu
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 820714c..ab9d1bd 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_ARCH_STI)+= st/
 obj-$(CONFIG_ARCH_SUNXI)   += sunxi/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-$(CONFIG_ARCH_OMAP2PLUS)   += ti/
+obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
 obj-$(CONFIG_ARCH_U8500)   += ux500/
 obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
 obj-$(CONFIG_X86)  += x86/
diff --git a/drivers/clk/uniphier/Kconfig b/drivers/clk/uniphier/Kconfig
new file mode 100644
index 000..7606f27
--- /dev/null
+++ b/drivers/clk/uniphier/Kconfig
@@ -0,0 +1,35 @@
+menuconfig CLK_UNIPHIER
+   bool "Clock drivers for UniPhier SoCs"
+   depends on ARCH_UNIPHIER
+   depends on OF
+   default y
+   help
+ Supports clock drivers for UniPhier SoCs.
+
+if CLK_UNIPHIER
+
+config CLK_UNIPHIER_PH1_SLD3
+   bool "Clock driver for UniPhier PH1-sLD3 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_LD4
+   bool "Clock driver for UniPhier PH1-LD4 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_PRO4
+   bool "Clock driver for UniPhier PH1-Pro4 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_SLD8
+   bool "Clock driver for UniPhier PH1-sLD8 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_PRO5
+   bool "Clock driver for UniPhier PH1-Pro5 SoC"
+   default y
+
+config CLK_UNIPHIER_PROXSTREAM2
+   bool "Clock driver for UniPhier ProXstream2/PH1-LD6b SoC"
+   default y
+
+endif
diff --git a/drivers/clk/uniphier/Makefile b/drivers/clk/uniphier/Makefile
new file mode 100644
index 000..3be1a17
--- /dev/null
+++ b/drivers/clk/uniphier/Makefile
@@ -0,0 +1,10 @@
+obj-y += clk-uniphier-core.o
+obj-y += clk-uniphier-peri.o
+obj-y += clk-uniphier-mio.o
+
+obj-$(CONFIG_CLK_UNIPHIER_PH1_SLD3)+= clk-ph1-sld3.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_LD4) += clk-ph1-ld4.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_PRO4)+= clk-ph1-pro4.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_SLD8)   

[PATCH 1/7][v5]usb:fsl:otg: Make fsl otg driver as tristate

[Ramneek Mehresh]

Provide option to load fsl otg driver as loadable module.

Signed-off-by: Ramneek Mehresh 
---
 drivers/usb/phy/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 22e8ecb..b6de4a7 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -19,7 +19,7 @@ config AB8500_USB
  in host mode, low speed.
 
 config FSL_USB2_OTG
-   bool "Freescale USB OTG Transceiver Driver"
+   tristate "Freescale USB OTG Transceiver Driver"
depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM
select USB_PHY
help
-- 
1.8.3.1

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

Re: [PATCH 1/2] compat ABI: use non-compat openat and open_by_handle_at variants

[Arnd Bergmann]

On Saturday 26 December 2015 19:06:39 Yury Norov wrote:
> The only difference is that non-compat version forces O_LARGEFILE,
> and it should be the default behaviour for all architectures, as
> we don't support 32-bit off_t. The only exception is tile32, that
> continues with compat version of syscalls.
> 
> Signed-off-by: Yury Norov 

Looks good,

Acked-by: Arnd Bergmann 

(adding Chris to Cc a well, in case he has further comments)

>  arch/tile/kernel/compat.c | 3 +++
>  include/uapi/asm-generic/unistd.h | 5 ++---
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/tile/kernel/compat.c b/arch/tile/kernel/compat.c
> index 4912084..489ae19 100644
> --- a/arch/tile/kernel/compat.c
> +++ b/arch/tile/kernel/compat.c
> @@ -94,6 +94,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned 
> int, offset_high,
>  #define compat_sys_readahead sys32_readahead
>  #define sys_llseek compat_sys_llseek
>  
> +#define sys_openat   compat_sys_openat
> +#define sys_open_by_handle_atcompat_sys_open_by_handle_at
> +
>  /* Call the assembly trampolines where necessary. */
>  #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
>  #define sys_clone _sys_clone
> diff --git a/include/uapi/asm-generic/unistd.h 
> b/include/uapi/asm-generic/unistd.h
> index 1324b02..07761e5 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -175,7 +175,7 @@ __SYSCALL(__NR_fchownat, sys_fchownat)
>  #define __NR_fchown 55
>  __SYSCALL(__NR_fchown, sys_fchown)
>  #define __NR_openat 56
> -__SC_COMP(__NR_openat, sys_openat, compat_sys_openat)
> +__SYSCALL(__NR_openat, sys_openat)
>  #define __NR_close 57
>  __SYSCALL(__NR_close, sys_close)
>  #define __NR_vhangup 58
> @@ -673,8 +673,7 @@ __SYSCALL(__NR_fanotify_mark, sys_fanotify_mark)
>  #define __NR_name_to_handle_at 264
>  __SYSCALL(__NR_name_to_handle_at, sys_name_to_handle_at)
>  #define __NR_open_by_handle_at 265
> -__SC_COMP(__NR_open_by_handle_at, sys_open_by_handle_at, \
> -   compat_sys_open_by_handle_at)
> +__SYSCALL(__NR_open_by_handle_at, sys_open_by_handle_at)
>  #define __NR_clock_adjtime 266
>  __SC_COMP(__NR_clock_adjtime, sys_clock_adjtime, compat_sys_clock_adjtime)
>  #define __NR_syncfs 267
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kexec: Provide arch_kexec_protect(unprotect)_crashkres()

[Minfei Huang]

On 12/28/15 at 08:14pm, Minfei Huang wrote:
> On 12/28/15 at 02:32pm, Xunlei Pang wrote:
> > On 12/24/2015 at 02:44 PM, Xunlei Pang wrote:
> > > +static void kexec_mark_crashkres(bool protect)
> > > +{
> > > + unsigned long control;
> > > +
> > > + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, 
> > > protect);
> > > +
> > > + /* Don't touch the control code page used in crash_kexec().*/
> > > + control = 
> > > PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
> > > + /* Control code page is located in the 2nd page. */
> > > + control = control + PAGE_SIZE;
> > >> Though it works because the control code is less than 1 page, but use 
> > >> the macro
> > >> of KEXEC_CONTROL_PAGE_SIZE looks better..
> > 
> > The 1st page is pagetable, control code page locates at the 2nd page.
> > The following kexec_mark_range() wants to mark ro from crashk_res.start
> > to the 1st page(included), so here we must use PAGE_SIZE.
> > 
> > >>
> > > + kexec_mark_range(crashk_res.start, control - 1, protect);
> > > + kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
> >  X86 kexec will copy the page while kexecing, could you check if we can 
> >  move
> >  that copying to earliyer while kexec loading, maybe 
> >  machine_kexec_prepare so
> >  that we can make a arch-independent implementation.
> > >>> For some arch, may use huge tlb directly to do the kernel mapping,
> > >>> in such cases, we can't implement this function. So I think it should
> > >>> be arch-dependent.
> > >> Ok, that's fine.
> > > At least moving the x86 control-copying code into arch-related
> > > machine_kexec_prepare() should work, and this can omit the
> > > special treatment of the control code page.
> > 
> > The "relocate_kernel" routine in "relocate_kernel_64.S" will use it as
> > a temp storage "for jumping back"(as its comment), so we can't mark
> > it readonly.
> 
> kexec will copy the relocate_kernel binary to control_code_page in
> function machine_kexec. This is a major reason to set the region
> control_code_page to control_code_page + PAGE_SIZE with mode read/write.

Fix it.
The region is from control_code_page + PAGE_SIZE to
control_code_page + PAGE_SIZE + PAGE_SIZE.

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

Makefile:610: arch/m32r/Makefile: No such file or directory

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   74bf8efb5fa6e958d2d7c7917b8bb672085ec0c6
commit: a436bb7b806383ae0593cab53d17fc9676270cd3 kbuild: use relative path more 
to include Makefile
date:   9 months ago
config: m32r-m32104ut_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a436bb7b806383ae0593cab53d17fc9676270cd3
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All errors (new ones prefixed by >>):

   Makefile:350: scripts/Kbuild.include: No such file or directory
>> Makefile:610: arch/m32r/Makefile: No such file or directory
   Makefile:782: scripts/Makefile.kasan: No such file or directory
   Makefile:783: scripts/Makefile.extrawarn: No such file or directory
   make[1]: *** No rule to make target 'scripts/Makefile.extrawarn'.
   make[1]: *** No rule to make target 'scripts/Makefile.kasan'.
>> make[1]: *** No rule to make target 'arch/m32r/Makefile'.
   make[1]: Failed to remake makefile 'scripts/Makefile.extrawarn'.
   make[1]: Failed to remake makefile 'scripts/Makefile.kasan'.
   make[1]: Failed to remake makefile 'arch/m32r/Makefile'.
   make: *** empty variable name.  Stop.
   make[1]: *** [scripts_basic] Error 2
   scripts/Makefile.asm-generic:11: scripts/Kbuild.include: No such file or 
directory
   make[2]: *** No rule to make target 'scripts/Kbuild.include'.
   make[2]: Failed to remake makefile 'scripts/Kbuild.include'.
   make[1]: *** [asm-generic] Error 2
   make[1]: Target 'headers_install' not remade because of errors.
   make: *** [sub-make] Error 2

vim +610 Makefile

   594  echo >&2 ;  
\
   595  /bin/false)
   596  
   597  endif # KBUILD_EXTMOD
   598  
   599  else
   600  # Dummy target needed, because used as prerequisite
   601  include/config/auto.conf: ;
   602  endif # $(dot-config)
   603  
   604  # The all: target is the default when no target is given on the
   605  # command line.
   606  # This allow a user to issue only 'make' to build a kernel including 
modules
   607  # Defaults to vmlinux, but the arch makefile usually adds further 
targets
   608  all: vmlinux
   609  
 > 610  include arch/$(SRCARCH)/Makefile
   611  
   612  KBUILD_CFLAGS   += $(call cc-option,-fno-delete-null-pointer-checks,)
   613  
   614  ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
   615  KBUILD_CFLAGS   += -Os $(call cc-disable-warning,maybe-uninitialized,)
   616  else
   617  KBUILD_CFLAGS   += -O2
   618  endif

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile

[Bamvor Jian Zhang]

I feel we need something like this to avoid the failure of compiling
when build with ARM64_ILP32(which will select COMPAT) and
ARMV8_DEPRECATED (which depends on the opcodes.o).

>From f8b8ffdb449491ecf8ba465238bbdb4625a74ac0 Mon Sep 17 00:00:00 2001
From: Bamvor Jian Zhang 
Date: Mon, 28 Dec 2015 12:57:46 +0800
Subject: [PATCH] arm64: compat: fix wrong dependency of ARMV8_DEPRECATED

When compile with ARM64_ILP32, ARMV8_DEPRECATED will be selected due
to the dependency of COMPAT. It leads to the following error:
LD  init/built-in.o
arch/arm64/kernel/built-in.o: In function `cp15barrier_handler':

/home/bamvor/works/source/kernel/linux_ilp32/arch/arm64/kernel/armv8_deprecated.c:467:
 undefined reference to `arm_check_condition'

/home/bamvor/works/source/kernel/linux_ilp32/arch/arm64/kernel/armv8_deprecated.c:467:
 undefined reference to `arm_check_condition'
arch/arm64/kernel/built-in.o: In function `swp_handler':

/home/bamvor/works/source/kernel/linux_ilp32/arch/arm64/kernel/armv8_deprecated.c:386:
 undefined reference to `arm_check_condition'

/home/bamvor/works/source/kernel/linux_ilp32/arch/arm64/kernel/armv8_deprecated.c:386:
 undefined reference to `arm_check_condition'
Makefile:927: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

This patch fix this by updating the dependency from COMPAT to
AARCH32_EL0.

Signed-off-by: Bamvor Jian Zhang 
---
 arch/arm64/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index deec37a..e52fd03 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -509,7 +509,7 @@ config FORCE_MAX_ZONEORDER
 
 menuconfig ARMV8_DEPRECATED
bool "Emulate deprecated/obsolete ARMv8 instructions"
-   depends on COMPAT
+   depends on AARCH32_EL0
help
  Legacy software support may require certain instructions
  that have been deprecated or obsoleted in the architecture.
-- 
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 1/3] bpf: hash: use atomic count

[Daniel Borkmann]

On 12/26/2015 10:31 AM, Ming Lei wrote:

Preparing for removing global per-hashtable lock, so
the counter need to be defined as aotmic_t first.

Signed-off-by: Ming Lei 


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

Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver

[Thierry Reding]

On Tue, Dec 15, 2015 at 09:38:41PM +0100, Arnd Bergmann wrote:
> On Tuesday 15 December 2015 18:42:36 Thierry Reding wrote:
> > On Tue, Dec 15, 2015 at 05:34:00PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 15 December 2015 17:31:22 Thierry Reding wrote:
> > > > On Mon, Dec 14, 2015 at 12:39:44PM +0100, Arnd Bergmann wrote:
> > > > > On Wednesday 18 November 2015 17:56:22 Andy Yan wrote:
> > > > > > 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 
> > > > > 
> > > > > Adding John Stultz to Cc
> > > > > 
> > > > > I just saw this thread pop up again, and had to think of John's recent
> > > > > patch to unify this across platforms.
> > > > > 
> > > > > John, can you have a look at this driver too, and see how it fits in?
> > > > > I think this is yet another variant, using an MMIO register rather 
> > > > > than
> > > > > RAM (as HTC / NVIDIA does) or SRAM (as Qualcomm does), but otherwise
> > > > > it conceptually fits in with what you had.
> > > > 
> > > > FWIW, Tegra typically does use an MMIO register as well. See
> > > > drivers/soc/tegra/pmc.c:tegra_pmc_restart_notify(). I don't know what
> > > > HTC does, but if it's writing somewhere in RAM it isn't using the
> > > > standard way of resetting the SoC. There's early boot ROM code which I
> > > > think evaluates the PMC_SCRATCH0 register on Tegra to determine which
> > > > mode to boot into. That's before even any firmware gets the chance of
> > > > doing anything.
> 
> 
> I just checked the android lollipop tree, and I could not find a 
> pmc_restart_notify
> function, only this file
> 
> https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/drivers/htc_debug/stability/reboot_params.c
> 
> with the device that stores into RAM. It looks like HTC ported over
> a driver that they were already using on some Qualcomm MSM8960 device,
> as in 
> 
> https://gitlab.com/MaC/android_kernel_htc_msm8960/blob/859977fc723f59a6b707df1d70e80826ee1dccc4/arch/arm/mach-msm/htc/htc_restart_handler.c
> 
> On Android marshmallow (Flounder), that file again does not exist, and
> I don't see how it's done.
> 
> > > HTC apparently uses a separate RAM area to pass the reboot reason,
> > > and they have a driver to store that, which is separate from the
> > > driver that they use for actually rebooting the machine.
> > 
> > I wasn't very clear, but the PMC_SCRATCH0 register is used to store the
> > reset reason. It supports the recovery mode, which I think is really an
> > Android thing, "bootloader" will typically cause the bootloader not to
> > boot anything, and "forced-recovery" will go into a recovery mode that
> > is used to bootstrap the device (usually by uploading a "miniloader"
> > that initializes RAM, downloads a bootloader for booting or flashing an
> > operating system, ...).
> > 
> > The write that resets the SoC is to a different register.
> 
> So is this scratch register interpreted by some maskrom code, or by code that
> can be provided by the OEM?

My understanding is that its interpreted both by what's called BootROM
on Tegra (I guess that's what you call "maskrom code") and the system's
bootloader. The BootROM cannot typically be replaced by the OEM, but it
is quite typical for the bootloader to differ between devices.

The BootROM will interpret a subset of the bits in that register. Most
notable the "force recovery" bit. That will cause the BootROM to go into
a mode which can be used to bootstrap the device. It implements a simple
protocol (RCM) which can be used to upload a loader (usually referred to
as mini-loader) to the device's IRAM which in turn will initialize the
memory and which can download a proper bootloader (such as U-Boot) to
memory using a slightly more complex protocol (the standard protocol is
called nv3p, but the particular choice of protocol no longer matters at
this point).

The bootloader can also access this register and will interpret the
"bootloader" and "recovery" bits. On the, argueably small, sample of
Android devices I've worked with, the "bootloader" bit will make the
bootloader go into fastboot mode, whereas the "recovery" bit will make
it initiate the RCK mode, which is used to update through OTA.

There are a couple of other bits in this register, but they are badly
documented and don't seem to relate to reboot.

Thierry


signature.asc
Description: PGP signature

[PATCH v2 16/16] clk: slightly optimize clk_core_set_parent()

[Masahiro Yamada]

If clk_fetch_parent_index() fails, p_rate is unused.  Move the
assignment after the error checking.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

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

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 5b9aec0..e81301b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1730,13 +1730,13 @@ static int clk_core_set_parent(struct clk_core *core, 
struct clk_core *parent)
/* try finding the new parent index */
if (parent) {
p_index = clk_fetch_parent_index(core, parent);
-   p_rate = parent->rate;
if (p_index < 0) {
pr_debug("%s: clk %s can not be parent of clk %s\n",
__func__, parent->name, core->name);
ret = p_index;
goto out;
}
+   p_rate = parent->rate;
}
 
/* propagate PRE_RATE_CHANGE notifications */
-- 
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 v2 11/16] clk: simplify __clk_init_parent()

[Masahiro Yamada]

The translation from the index into clk_core is done by
clk_core_get_parent_by_index().  The if-block for num_parents == 1
case is duplicating the code in the clk_core_get_parent_by_index().

Drop the "if (num_parents == 1)" from the special case.  Instead,
set the index to zero if .get_parent() is missing.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 38 --
 1 file changed, 4 insertions(+), 34 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 4ad0a36..03b87d8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1651,44 +1651,14 @@ struct clk *clk_get_parent(struct clk *clk)
 }
 EXPORT_SYMBOL_GPL(clk_get_parent);
 
-/*
- * .get_parent is mandatory for clocks with multiple possible parents.  It is
- * optional for single-parent clocks.  Always call .get_parent if it is
- * available and WARN if it is missing for multi-parent clocks.
- *
- * For single-parent clocks without .get_parent, first check to see if the
- * .parents array exists, and if so use it to avoid an expensive tree
- * traversal.  If .parents does not exist then walk the tree.
- */
 static struct clk_core *__clk_init_parent(struct clk_core *core)
 {
-   struct clk_core *ret = NULL;
-   u8 index;
-
-   /* handle the trivial cases */
+   u8 index = 0;
 
-   if (!core->num_parents)
-   goto out;
-
-   if (core->num_parents == 1) {
-   if (IS_ERR_OR_NULL(core->parent))
-   core->parent = clk_core_lookup(core->parent_names[0]);
-   ret = core->parent;
-   goto out;
-   }
+   if (core->ops->get_parent)
+   index = core->ops->get_parent(core->hw);
 
-   /*
-* Do our best to cache parent clocks in core->parents.  This prevents
-* unnecessary and expensive lookups.  We don't set core->parent here;
-* that is done by the calling function.
-*/
-
-   index = core->ops->get_parent(core->hw);
-
-   ret = clk_core_get_parent_by_index(core, index);
-
-out:
-   return ret;
+   return clk_core_get_parent_by_index(core, index);
 }
 
 static void clk_core_reparent(struct clk_core *core,
-- 
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 v2 06/16] clk: move core->parents allocation to clk_register()

[Masahiro Yamada]

Currently, __clk_core_init() allows failure of the kcalloc() for the
core->parents.  So, clk_fetch_parent_index() and __clk_init_parent()
also try to allocate core->parents in case it has not been allocated
yet.  Scattering memory allocation here and there makes things
complicated.

Like other clk_core members, allocate core->parents in clk_register()
and let it fail in case of memory shortage.  If we cannot allocate
such a small piece of memory, the system is already insane.  There is
no point to postpone the memory allocation.

Also, allocate core->parents regardless of core->num_parents.  We want
it even if core->num_parents == 1 because clk_fetch_parent_index()
might be called against the clk_core with a single parent.

If core->num_parents == 0, core->parents is set to ZERO_SIZE_PTR. It
is harmless because no access happens to core->parents in such a case.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 51 +++
 1 file changed, 19 insertions(+), 32 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 98745c3..b5be02a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1067,13 +1067,6 @@ static int clk_fetch_parent_index(struct clk_core *core,
 {
int i;
 
-   if (!core->parents) {
-   core->parents = kcalloc(core->num_parents,
-   sizeof(*core->parents), GFP_KERNEL);
-   if (!core->parents)
-   return -ENOMEM;
-   }
-
/*
 * find index of new parent clock using cached parent ptrs,
 * or if not yet cached, use string name comparison and cache
@@ -1700,11 +1693,6 @@ static struct clk_core *__clk_init_parent(struct 
clk_core *core)
 
index = core->ops->get_parent(core->hw);
 
-   if (!core->parents)
-   core->parents =
-   kcalloc(core->num_parents, sizeof(*core->parents),
-   GFP_KERNEL);
-
ret = clk_core_get_parent_by_index(core, index);
 
 out:
@@ -2343,26 +2331,15 @@ static int __clk_core_init(struct clk_core *core)
__func__, core->name);
 
/*
-* Allocate an array of struct clk *'s to avoid unnecessary string
-* look-ups of clk's possible parents.  This can fail for clocks passed
-* in to clk_init during early boot; thus any access to core->parents[]
-* must always check for a NULL pointer and try to populate it if
-* necessary.
+* clk_core_lookup returns NULL for parents that have not been
+* clk_init'd; thus any access to clk->parents[] must check
+* for a NULL pointer.  We can always perform lazy lookups for
+* missing parents later on.
 */
-   if (core->num_parents > 1) {
-   core->parents = kcalloc(core->num_parents,
-   sizeof(*core->parents), GFP_KERNEL);
-   /*
-* clk_core_lookup returns NULL for parents that have not been
-* clk_init'd; thus any access to clk->parents[] must check
-* for a NULL pointer.  We can always perform lazy lookups for
-* missing parents later on.
-*/
-   if (core->parents)
-   for (i = 0; i < core->num_parents; i++)
-   core->parents[i] =
-   clk_core_lookup(core->parent_names[i]);
-   }
+   if (core->parents)
+   for (i = 0; i < core->num_parents; i++)
+   core->parents[i] =
+   clk_core_lookup(core->parent_names[i]);
 
core->parent = __clk_init_parent(core);
 
@@ -2560,12 +2537,20 @@ struct clk *clk_register(struct device *dev, struct 
clk_hw *hw)
}
}
 
+   /* avoid unnecessary string look-ups of clk_core's possible parents. */
+   core->parents = kcalloc(core->num_parents, sizeof(*core->parents),
+   GFP_KERNEL);
+   if (!core->parents) {
+   ret = -ENOMEM;
+   goto fail_parents;
+   };
+
INIT_HLIST_HEAD(>clks);
 
hw->clk = __clk_create_clk(hw, NULL, NULL);
if (IS_ERR(hw->clk)) {
ret = PTR_ERR(hw->clk);
-   goto fail_parent_names_copy;
+   goto fail_parents;
}
 
ret = __clk_core_init(core);
@@ -2575,6 +2560,8 @@ struct clk *clk_register(struct device *dev, struct 
clk_hw *hw)
__clk_free_clk(hw->clk);
hw->clk = NULL;
 
+fail_parents:
+   kfree(core->parents);
 fail_parent_names_copy:
while (--i >= 0)
kfree_const(core->parent_names[i]);
-- 
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 

[PATCH v2 15/16] clk: simplify clk_fetch_parent_index() function

[Masahiro Yamada]

The clk_core_get_parent_by_index can be used as a helper function
to simplify the implementation of clk_fetch_parent_index().

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 151cbe8..5b9aec0 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1069,23 +1069,9 @@ static int clk_fetch_parent_index(struct clk_core *core,
if (!parent)
return -EINVAL;
 
-   /*
-* find index of new parent clock using cached parent ptrs,
-* or if not yet cached, use string name comparison and cache
-* them now to avoid future calls to clk_core_lookup.
-*/
-   for (i = 0; i < core->num_parents; i++) {
-   if (core->parents[i] == parent)
-   return i;
-
-   if (core->parents[i])
-   continue;
-
-   if (!strcmp(core->parent_names[i], parent->name)) {
-   core->parents[i] = clk_core_lookup(parent->name);
+   for (i = 0; i < core->num_parents; i++)
+   if (clk_core_get_parent_by_index(core, i) == parent)
return i;
-   }
-   }
 
return -EINVAL;
 }
-- 
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 v2 01/16] clk: remove unused first argument of __clk_init()

[Masahiro Yamada]

The "struct device *dev" is not used at all in this function.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

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

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 3fba5ac..897e5ae 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2286,13 +2286,12 @@ static inline void clk_debug_unregister(struct clk_core 
*core)
 
 /**
  * __clk_init - initialize the data structures in a struct clk
- * @dev:   device initializing this clk, placeholder for now
  * @clk:   clk being initialized
  *
  * Initializes the lists in struct clk_core, queries the hardware for the
  * parent and rate and sets them both.
  */
-static int __clk_init(struct device *dev, struct clk *clk_user)
+static int __clk_init(struct clk *clk_user)
 {
int i, ret = 0;
struct clk_core *orphan;
@@ -2575,7 +2574,7 @@ struct clk *clk_register(struct device *dev, struct 
clk_hw *hw)
goto fail_parent_names_copy;
}
 
-   ret = __clk_init(dev, hw->clk);
+   ret = __clk_init(hw->clk);
if (!ret)
return hw->clk;
 
-- 
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 v2 08/16] clk: drop the initial core->parents look-ups from __clk_core_init()

[Masahiro Yamada]

The core->parents is a cache to save expensive clock parent look-ups.
It will be filled as needed later.  We do not have to do it here.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ca7849a..3215b2b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2329,17 +2329,6 @@ static int __clk_core_init(struct clk_core *core)
"%s: invalid NULL in %s's .parent_names\n",
__func__, core->name);
 
-   /*
-* clk_core_lookup returns NULL for parents that have not been
-* clk_init'd; thus any access to clk->parents[] must check
-* for a NULL pointer.  We can always perform lazy lookups for
-* missing parents later on.
-*/
-   if (core->parents)
-   for (i = 0; i < core->num_parents; i++)
-   core->parents[i] =
-   clk_core_lookup(core->parent_names[i]);
-
core->parent = __clk_init_parent(core);
 
/*
-- 
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 v2 09/16] clk: replace pr_warn() with pr_err() for fatal cases

[Masahiro Yamada]

These three cases let clk_register() fail.  They should be considered
as error messages.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 3215b2b..e6e10f5 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2302,22 +2302,22 @@ static int __clk_core_init(struct clk_core *core)
if (core->ops->set_rate &&
!((core->ops->round_rate || core->ops->determine_rate) &&
  core->ops->recalc_rate)) {
-   pr_warning("%s: %s must implement .round_rate or 
.determine_rate in addition to .recalc_rate\n",
-   __func__, core->name);
+   pr_err("%s: %s must implement .round_rate or .determine_rate in 
addition to .recalc_rate\n",
+  __func__, core->name);
ret = -EINVAL;
goto out;
}
 
if (core->ops->set_parent && !core->ops->get_parent) {
-   pr_warning("%s: %s must implement .get_parent & .set_parent\n",
-   __func__, core->name);
+   pr_err("%s: %s must implement .get_parent & .set_parent\n",
+  __func__, core->name);
ret = -EINVAL;
goto out;
}
 
if (core->ops->set_rate_and_parent &&
!(core->ops->set_parent && core->ops->set_rate)) {
-   pr_warn("%s: %s must implement .set_parent & .set_rate\n",
+   pr_err("%s: %s must implement .set_parent & .set_rate\n",
__func__, core->name);
ret = -EINVAL;
goto out;
-- 
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 v2 04/16] clk: remove unnecessary !core->parents conditional

[Masahiro Yamada]

This if-block has been here since the introduction of the common
clock framework.  Now no clock drivers are statically initialized.
core->parent is always NULL at this point.  Drop the redundant
check and the confusing comment.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 41179f3..30c0bbc 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2348,11 +2348,8 @@ static int __clk_core_init(struct clk_core *core)
 * in to clk_init during early boot; thus any access to core->parents[]
 * must always check for a NULL pointer and try to populate it if
 * necessary.
-*
-* If core->parents is not NULL we skip this entire block.  This allows
-* for clock drivers to statically initialize core->parents.
 */
-   if (core->num_parents > 1 && !core->parents) {
+   if (core->num_parents > 1) {
core->parents = kcalloc(core->num_parents, sizeof(struct clk *),
GFP_KERNEL);
/*
-- 
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 v2 07/16] clk: simplify clk_core_get_parent_by_index()

[Masahiro Yamada]

Drop the "if (!core->parents)" case and refactor the function a bit
because core->parents is always allocated.  (Strictly speaking, it is
ZERO_SIZE_PTR if core->num_parents == 0, but such a case is omitted
by the if-conditional above.)

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b5be02a..ca7849a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -350,13 +350,12 @@ static struct clk_core 
*clk_core_get_parent_by_index(struct clk_core *core,
 {
if (!core || index >= core->num_parents)
return NULL;
-   else if (!core->parents)
-   return clk_core_lookup(core->parent_names[index]);
-   else if (!core->parents[index])
-   return core->parents[index] =
-   clk_core_lookup(core->parent_names[index]);
-   else
-   return core->parents[index];
+
+   if (!core->parents[index])
+   core->parents[index] =
+   clk_core_lookup(core->parent_names[index]);
+
+   return core->parents[index];
 }
 
 struct clk_hw *
-- 
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 v2 10/16] clk: move checking .git_parent to __clk_core_init()

[Masahiro Yamada]

The .git_parent is mandatory for multi-parent clocks.  Move the check
to __clk_core_init(), like other callback checkings.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index e6e10f5..4ad0a36 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1677,13 +1677,6 @@ static struct clk_core *__clk_init_parent(struct 
clk_core *core)
goto out;
}
 
-   if (!core->ops->get_parent) {
-   WARN(!core->ops->get_parent,
-   "%s: multi-parent clocks must implement .get_parent\n",
-   __func__);
-   goto out;
-   }
-
/*
 * Do our best to cache parent clocks in core->parents.  This prevents
 * unnecessary and expensive lookups.  We don't set core->parent here;
@@ -2315,6 +2308,11 @@ static int __clk_core_init(struct clk_core *core)
goto out;
}
 
+   if (core->num_parents > 1 && !core->ops->get_parent) {
+   pr_err("%s: %s must implement .get_parent as it has multi 
parents\n",
+  __func__, core->name);
+   }
+
if (core->ops->set_rate_and_parent &&
!(core->ops->set_parent && core->ops->set_rate)) {
pr_err("%s: %s must implement .set_parent & .set_rate\n",
-- 
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 v2 12/16] clk: avoid circular clock topology

[Masahiro Yamada]

Currently, clk_register() never checks a circular parent looping,
but clock providers could register such an insane clock topology.
For example, "clk_a" could have "clk_b" as a parent, and vice versa.
In this case, clk_core_reparent() creates a circular parent list
and __clk_recalc_accuracies() calls itself recursively forever.

The core infrastructure should be kind enough to bail out, showing
an appropriate error message in such a case.  This helps to easily
find a bug in clock providers.  (uh, I made such a silly mistake
when I was implementing my clock providers first.  I was upset
because the kernel did not respond, without any error message.)

This commit adds a new helper function, __clk_is_ancestor().  It
returns true if the second argument is a possible ancestor of the
first one.  If a clock core is a possible ancestor of itself, it
would make a loop when it were registered.  That should be detected
as an error.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 03b87d8..a4f66fe 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2235,6 +2235,38 @@ static inline void clk_debug_unregister(struct clk_core 
*core)
 #endif
 
 /**
+ * __clk_is_ancestor - check if a clk_core is a possible ancestor of another
+ * @core: clock core
+ * @ancestor: ancestor clock core
+ *
+ * Returns true if there is a possibility that @ancestor can be an ancestor
+ * of @core, false otherwise.
+ *
+ * This function can be used against @core or @ancestor that has not been
+ * registered yet.
+ */
+static bool __clk_is_ancestor(struct clk_core *core, struct clk_core *ancestor)
+{
+   struct clk_core *parent;
+   int i;
+
+   for (i = 0; i < core->num_parents; i++) {
+   parent = clk_core_get_parent_by_index(core, i);
+   /*
+* If ancestor has not been added to clk_{root,orphan}_list
+* yet, clk_core_lookup() cannot find it.  If parent is NULL,
+* compare the name strings, too.
+*/
+   if ((parent && (parent == ancestor ||
+   __clk_is_ancestor(parent, ancestor))) ||
+   (!parent && !strcmp(core->parent_names[i], ancestor->name)))
+   return true;
+   }
+
+   return false;
+}
+
+/**
  * __clk_core_init - initialize the data structures in a struct clk_core
  * @core:  clk_core being initialized
  *
@@ -2297,6 +2329,14 @@ static int __clk_core_init(struct clk_core *core)
"%s: invalid NULL in %s's .parent_names\n",
__func__, core->name);
 
+   /* If core is an ancestor of itself, it would make a loop. */
+   if (__clk_is_ancestor(core, core)) {
+   pr_err("%s: %s would create circular parent\n", __func__,
+  core->name);
+   ret = -EINVAL;
+   goto out;
+   }
+
core->parent = __clk_init_parent(core);
 
/*
-- 
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 v2 00/16] clk: a collection of various clean-ups and improvements

[Masahiro Yamada]

Many refactoring, with detection of circular parent looping.


Changes in v2:
  - Fix a bug.  Return -EINVAL when parent _is_ NULL.

Masahiro Yamada (16):
  clk: remove unused first argument of __clk_init()
  clk: change the argument of __clk_init() into pointer to clk_core
  clk: rename __clk_init() into __clk_core_init()
  clk: remove unnecessary !core->parents conditional
  clk: change sizeof(struct clk *) to sizeof(*core->parents)
  clk: move core->parents allocation to clk_register()
  clk: simplify clk_core_get_parent_by_index()
  clk: drop the initial core->parents look-ups from __clk_core_init()
  clk: replace pr_warn() with pr_err() for fatal cases
  clk: move checking .git_parent to __clk_core_init()
  clk: simplify __clk_init_parent()
  clk: avoid circular clock topology
  clk: walk the orphan clock list more simply
  clk: make sure parent is not NULL in clk_fetch_parent_index()
  clk: simplify clk_fetch_parent_index() function
  clk: slightly optimize clk_core_set_parent()

 drivers/clk/clk.c | 214 ++
 1 file changed, 85 insertions(+), 129 deletions(-)

-- 
1.9.1

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

[PATCH] f2fs: fix to stop recovering dot dentries in a readonly fs

[Chao Yu]

If filesystem is readonly, don't recover inline dot inode.

Signed-off-by: Chao Yu 
---
 fs/f2fs/namei.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 5cc4128..b4a5836 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -269,7 +269,7 @@ static struct dentry *f2fs_lookup(struct inode *dir, struct 
dentry *dentry,
if (IS_ERR(inode))
return ERR_CAST(inode);
 
-   if (f2fs_has_inline_dots(inode)) {
+   if (f2fs_has_inline_dots(inode) && !f2fs_readonly(dir->i_sb)) {
err = __recover_dot_dentries(inode, dir->i_ino);
if (err)
goto err_out;
-- 
2.6.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/

[RESEND PATCH v2 03/16] clk: rename __clk_init() into __clk_core_init()

[Masahiro Yamada]

Now this function takes clk_core as its argument.  __clk_core_init()
would be more suitable for the name of this function.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 623838f..41179f3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2285,13 +2285,13 @@ static inline void clk_debug_unregister(struct clk_core 
*core)
 #endif
 
 /**
- * __clk_init - initialize the data structures in a struct clk_core
+ * __clk_core_init - initialize the data structures in a struct clk_core
  * @core:  clk_core being initialized
  *
  * Initializes the lists in struct clk_core, queries the hardware for the
  * parent and rate and sets them both.
  */
-static int __clk_init(struct clk_core *core)
+static int __clk_core_init(struct clk_core *core)
 {
int i, ret = 0;
struct clk_core *orphan;
@@ -2571,7 +2571,7 @@ struct clk *clk_register(struct device *dev, struct 
clk_hw *hw)
goto fail_parent_names_copy;
}
 
-   ret = __clk_init(core);
+   ret = __clk_core_init(core);
if (!ret)
return hw->clk;
 
-- 
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/

[RESEND PATCH v2 00/16] clk: a collection of various clean-ups and improvements

[Masahiro Yamada]

Many refactoring, with detection of circular parent looping.


Changes in v2:
  - Fix a bug.  Return -EINVAL when parent _is_ NULL.

Masahiro Yamada (16):
  clk: remove unused first argument of __clk_init()
  clk: change the argument of __clk_init() into pointer to clk_core
  clk: rename __clk_init() into __clk_core_init()
  clk: remove unnecessary !core->parents conditional
  clk: change sizeof(struct clk *) to sizeof(*core->parents)
  clk: move core->parents allocation to clk_register()
  clk: simplify clk_core_get_parent_by_index()
  clk: drop the initial core->parents look-ups from __clk_core_init()
  clk: replace pr_warn() with pr_err() for fatal cases
  clk: move checking .git_parent to __clk_core_init()
  clk: simplify __clk_init_parent()
  clk: avoid circular clock topology
  clk: walk the orphan clock list more simply
  clk: make sure parent is not NULL in clk_fetch_parent_index()
  clk: simplify clk_fetch_parent_index() function
  clk: slightly optimize clk_core_set_parent()

 drivers/clk/clk.c | 214 ++
 1 file changed, 85 insertions(+), 129 deletions(-)

-- 
1.9.1

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

Re: [PATCH 2/2] [media] media-device: split media initialization and registration

[Mauro Carvalho Chehab]

Em Mon, 28 Dec 2015 03:14:53 +0200
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Tue, Dec 15, 2015 at 09:13:42AM -0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 10 Sep 2015 20:14:04 +0300
> > Sakari Ailus  escreveu:
> > 
> > > Hi Javier,
> > > 
> > > Thanks for the set! A few comments below.
> > > 
> > > 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.
> > > 
> > > I'd simply replace the WARN_ON() below with BUG().
> > 
> > That sounds like bad idea to me, and it is against the current
> > Kernel policy of using BUG() only when there's no other way, e. g. on
> > event so severe that the Kernel has no other thing to do except to
> > stop running.
> > 
> > For sure, this is not the case here. Also, all drivers have already
> > a logic that checks if the device init happened. So, they should already
> > be doing the right thing.
> 
> My point is that it's simply counter-productive to require the caller to
> perform error handling in cases such as the only possible source of the
> 

[RESEND PATCH v2 07/16] clk: simplify clk_core_get_parent_by_index()

[Masahiro Yamada]

Drop the "if (!core->parents)" case and refactor the function a bit
because core->parents is always allocated.  (Strictly speaking, it is
ZERO_SIZE_PTR if core->num_parents == 0, but such a case is omitted
by the if-conditional above.)

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b5be02a..ca7849a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -350,13 +350,12 @@ static struct clk_core 
*clk_core_get_parent_by_index(struct clk_core *core,
 {
if (!core || index >= core->num_parents)
return NULL;
-   else if (!core->parents)
-   return clk_core_lookup(core->parent_names[index]);
-   else if (!core->parents[index])
-   return core->parents[index] =
-   clk_core_lookup(core->parent_names[index]);
-   else
-   return core->parents[index];
+
+   if (!core->parents[index])
+   core->parents[index] =
+   clk_core_lookup(core->parent_names[index]);
+
+   return core->parents[index];
 }
 
 struct clk_hw *
-- 
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/

[RESEND PATCH v2 11/16] clk: simplify __clk_init_parent()

[Masahiro Yamada]

The translation from the index into clk_core is done by
clk_core_get_parent_by_index().  The if-block for num_parents == 1
case is duplicating the code in the clk_core_get_parent_by_index().

Drop the "if (num_parents == 1)" from the special case.  Instead,
set the index to zero if .get_parent() is missing.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 38 --
 1 file changed, 4 insertions(+), 34 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 4ad0a36..03b87d8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1651,44 +1651,14 @@ struct clk *clk_get_parent(struct clk *clk)
 }
 EXPORT_SYMBOL_GPL(clk_get_parent);
 
-/*
- * .get_parent is mandatory for clocks with multiple possible parents.  It is
- * optional for single-parent clocks.  Always call .get_parent if it is
- * available and WARN if it is missing for multi-parent clocks.
- *
- * For single-parent clocks without .get_parent, first check to see if the
- * .parents array exists, and if so use it to avoid an expensive tree
- * traversal.  If .parents does not exist then walk the tree.
- */
 static struct clk_core *__clk_init_parent(struct clk_core *core)
 {
-   struct clk_core *ret = NULL;
-   u8 index;
-
-   /* handle the trivial cases */
+   u8 index = 0;
 
-   if (!core->num_parents)
-   goto out;
-
-   if (core->num_parents == 1) {
-   if (IS_ERR_OR_NULL(core->parent))
-   core->parent = clk_core_lookup(core->parent_names[0]);
-   ret = core->parent;
-   goto out;
-   }
+   if (core->ops->get_parent)
+   index = core->ops->get_parent(core->hw);
 
-   /*
-* Do our best to cache parent clocks in core->parents.  This prevents
-* unnecessary and expensive lookups.  We don't set core->parent here;
-* that is done by the calling function.
-*/
-
-   index = core->ops->get_parent(core->hw);
-
-   ret = clk_core_get_parent_by_index(core, index);
-
-out:
-   return ret;
+   return clk_core_get_parent_by_index(core, index);
 }
 
 static void clk_core_reparent(struct clk_core *core,
-- 
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/

[RESEND PATCH v2 09/16] clk: replace pr_warn() with pr_err() for fatal cases

[Masahiro Yamada]

These three cases let clk_register() fail.  They should be considered
as error messages.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 3215b2b..e6e10f5 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2302,22 +2302,22 @@ static int __clk_core_init(struct clk_core *core)
if (core->ops->set_rate &&
!((core->ops->round_rate || core->ops->determine_rate) &&
  core->ops->recalc_rate)) {
-   pr_warning("%s: %s must implement .round_rate or 
.determine_rate in addition to .recalc_rate\n",
-   __func__, core->name);
+   pr_err("%s: %s must implement .round_rate or .determine_rate in 
addition to .recalc_rate\n",
+  __func__, core->name);
ret = -EINVAL;
goto out;
}
 
if (core->ops->set_parent && !core->ops->get_parent) {
-   pr_warning("%s: %s must implement .get_parent & .set_parent\n",
-   __func__, core->name);
+   pr_err("%s: %s must implement .get_parent & .set_parent\n",
+  __func__, core->name);
ret = -EINVAL;
goto out;
}
 
if (core->ops->set_rate_and_parent &&
!(core->ops->set_parent && core->ops->set_rate)) {
-   pr_warn("%s: %s must implement .set_parent & .set_rate\n",
+   pr_err("%s: %s must implement .set_parent & .set_rate\n",
__func__, core->name);
ret = -EINVAL;
goto out;
-- 
1.9.1

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

Re: [PATCH 2/2] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option

[Arnd Bergmann]

On Saturday 26 December 2015 19:06:40 Yury Norov wrote:
> All new 32-bit architectures should have 64-bit off_t type, but existing
> architectures has 32-bit ones.

It's worth mentioning here that ever the architectures that only have
64-bit off_t in the kernel ( arc, c6x, h8300, hexagon, metag, nios2, opernrisc,
tile32 and unicore32) may use a libc with 32-bit off_t in their libc,
and therefore want to limit the file size to 4GB unless specified differently
in the open flags.

> To handle it, new config option is added to arch/Kconfig that defaults
> ARCH_32BIT_OFF_T to be disabled by default. All existing 32-bit architectures
> enable it explicitly here.
> 
> New option affects force_o_largefile() behaviour. Namely, if off_t is
> 64-bits long, we have no reason to reject user to open big files.
> 
> Signed-off-by: Yury Norov 

The patch looks mostly right, just a few stylistic comments:


> diff --git a/arch/Kconfig b/arch/Kconfig
> index 4e949e5..1e5e6c8 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -233,6 +233,10 @@ config ARCH_THREAD_INFO_ALLOCATOR
>  config ARCH_WANTS_DYNAMIC_TASK_STRUCT
>   bool
>  
> +config ARCH_32BIT_OFF_T
> + def_bool n
> + depends on !64BIT

'bool' is the same as 'def_bool n', and the former is more common, so please
use that.

> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -11,6 +11,7 @@ menu "Processor type and features"
>  
>  config IA64
>   bool
> + select ARCH_32BIT_OFF_T if !64BIT
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   select ARCH_MIGHT_HAVE_PC_SERIO
>   select PCI if (!IA64_HP_SIM)

No need to patch IA64, we don't support 32-bit kernels on that architecture

> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index db49e0d..2026a9e 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -7,6 +7,7 @@ config PPC32
>  config 32BIT
>   bool
>   default y if PPC32
> + select ARCH_32BIT_OFF_T
>  
>  config 64BIT
>   bool

It seems the preferred way of writing this in powerpc is to put

select ARCH_32BIT_OFF_T if PPC32

under config PPC

> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 3a55f49..d05a143 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -64,6 +64,7 @@ config ARCH_SUPPORTS_UPROBES
>  
>  config S390
>   def_bool y
> + select ARCH_32BIT_OFF_T if !64BIT
>   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>   select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
>   select ARCH_HAS_ELF_RANDOMIZE

32-bit s390 support was removed some time ago, so this is no longer
needed.

> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index 76ce329..2e27443 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -5,7 +5,8 @@
>  
>  
>  #ifndef force_o_largefile
> -#define force_o_largefile() (BITS_PER_LONG != 32)
> +#define force_o_largefile() ((BITS_PER_LONG != 32)   \
> + || !IS_ENABLED(CONFIG_ARCH_32BIT_OFF_T))
>  #endif
>  
>  #if BITS_PER_LONG == 32

I just realized that while I suggested the expression you wrote here, the
BITS_PER_LONG check isn't actually needed, we can just make it

#define force_o_largefile() (!IS_ENABLED(CONFIG_ARCH_32BIT_OFF_T))

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

Re: [PATCH] arm: kernel: utilize hrtimer based broadcast

[Arnd Bergmann]

On Monday 28 December 2015 07:18:58 Huan Wang wrote:
> Hi, Arnd,
> 
>   Could you help to review the following patch? Thanks.
> 

Hi Alison,

I'm sorry but I understand very little of this particular area of the kernel.

I've added Daniel Lezcano, John Stultz and Thomas Gleixner to Cc, they all
know this much better than I do and one of them should be able to comment after
their Christmas break.

Arnd

> > On Fri, Jul 17, 2015 at 10:11:52AM +0100, Alison Wang wrote:
> > > Hrtimer based broadcast is used on ARM platform. It can be registered
> > > as the tick broadcast device in the absence of a real external clock
> > > device.
> > >
> > > Signed-off-by: Alison Wang 
> > 
> > This looks sensible to me. FWIW:
> > 
> > Acked-by: Mark Rutland 
> > 
> > Thanks,
> > Mark.
> > 
> > > ---
> > >  arch/arm/kernel/time.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index
> > > a66e37e..a9bc73c 100644
> > > --- a/arch/arm/kernel/time.c
> > > +++ b/arch/arm/kernel/time.c
> > > @@ -12,6 +12,7 @@
> > >   *  reading the RTC at bootup, etc...
> > >   */
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -121,5 +122,7 @@ void __init time_init(void)
> > >   of_clk_init(NULL);
> > >  #endif
> > >   clocksource_of_init();
> > > +
> > > + tick_setup_hrtimer_broadcast();
> > >   }
> > >  }


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

Build regressions/improvements in v4.4-rc7

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v4.4-rc7[1] compared to v4.3[2].

Summarized:
  - build errors: +22/-11
  - build warnings: +290/-103

JFYI, when comparing v4.4-rc7[1] to v4.4-rc6[3], the summaries are:
  - build errors: +14/-3
  - build warnings: +176/-60

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

As I haven't mastered kup yet, there's no verbose summary at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.4-rc7.summary.gz

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] http://kisskb.ellerman.id.au/kisskb/head/9745/ (258 out of 259 configs)
[2] http://kisskb.ellerman.id.au/kisskb/head/9535/ (256 out of 259 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/9734/ (all 259 configs)


*** ERRORS ***

22 error regressions:
  + /home/kisskb/slave/src/include/linux/workqueue.h: error: dereferencing 
type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]: 
 => 186:2
  + /home/kisskb/slave/src/net/sched/sch_dsmark.c: error: unrecognizable insn:: 
 => 316:1
  + /tmp/cc5veAi5.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 49, 378
  + /tmp/cc6DopGj.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 43
  + /tmp/cc7GEfIa.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 43
  + /tmp/ccGsoCyO.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 49, 366
  + /tmp/ccH1dW0f.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 43
  + /tmp/ccP7l3ug.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 43
  + /tmp/ccSlbKej.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 43
  + /tmp/ccemCHRe.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 326, 50
  + /tmp/cckgYy8k.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 50, 329
  + /tmp/cclNaAGh.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 49, 366
  + /tmp/ccmqbWag.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 43
  + /tmp/cczzZNSV.s: Error: can't resolve `_start' {*UND* section} - `L0
' 
{.text section}:  => 41, 403
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.kfree' defined in .text section in mm/built-in.o:  => (.text+0x1ff8398)
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.netif_carrier_off' defined in .text section in net/built-in.o:  => 
(.text+0x1ff9188), (.text+0x1ff6f0c)
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.netif_device_attach' defined in .text section in net/built-in.o:  => 
(.text+0x1ff9688)
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.netif_device_detach' defined in .text section in net/built-in.o:  => 
(.text+0x1ff83fc)
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_restgpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ff8e68)
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_savegpr0_29' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ff95e0), (.text+0x1ff8e70)
  + error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.netif_tx_wake_queue' defined in .text section in net/built-in.o:  => 
(.text+0x1ff9540)
  + error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`_savegpr0_29' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ff9448)

11 error improvements:
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'early_init_dt_scan_nodes' 
[-Werror=implicit-function-declaration]: 244:2 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'early_init_dt_verify' 
[-Werror=implicit-function-declaration]: 215:2 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'of_flat_dt_match_machine' 
[-Werror=implicit-function-declaration]: 218:2 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'of_get_flat_dt_prop' 
[-Werror=implicit-function-declaration]: 229:3 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'of_get_flat_dt_root' 
[-Werror=implicit-function-declaration]: 228:3 => 
  - /home/kisskb/slave/src/drivers/scsi/advansys.c: error: implicit declaration 
of function 'free_dma' [-Werror=implicit-function-declaration]: 11384:3 => 
  - /home/kisskb/slave/src/drivers/scsi/advansys.c: error: implicit declaration 
of function 'request_dma' 

Re: [PATCH v3 4/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for mt2701

[Yingjoe Chen]

On Mon, 2015-12-28 at 15:09 +0800, Biao Huang wrote:
> Add mt2701 support using mediatek common pinctrl driver.
> MT2701 have some special pins need an extra setting register
> than other ICs, so adding this support to common code.
> 
> Signed-off-by: Biao Huang 
> Acked-by: Yingjoe Chen 
<...>
> +
> +static struct platform_driver mtk_pinctrl_driver = {
> + .probe = mt2701_pinctrl_probe,
> + .driver = {
> + .name = "mediatek-mt2701-pinctrl",
> + .owner = THIS_MODULE,
> + .of_match_table = mt2701_pctrl_match,
> + },
> +};
> +
> +static int __init mtk_pinctrl_init(void)
> +{
> + return platform_driver_register(_pinctrl_driver);
> +}
> +
> +arch_initcall(mtk_pinctrl_init);


As discussed in
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003350.html
we should use subsys_initcall() instead.


> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index f307f1d..76279f0 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
<...>
> @@ -347,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev 
> *pctldev,
>   ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
>   break;
>   case PIN_CONFIG_INPUT_ENABLE:
> + mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
>   ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
>   break;
>   case PIN_CONFIG_OUTPUT:
> @@ -354,6 +360,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev 
> *pctldev,
>   ret = mtk_pmx_gpio_set_direction(pctldev, NULL, pin, false);
>   break;
>   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> + mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
>   ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
>   break;
>   case PIN_CONFIG_DRIVE_STRENGTH:

This change is not directly related to adding mt2710 support and change
behavior for all MTK pinctrl drivers, please create a separate patch for
this.

Joe.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 v5 04/20] clocksource: Add NPS400 timers driver

[Daniel Lezcano]

On 12/27/2015 10:41 PM, Noam Camus wrote:

From: kbuild test robot 
Sent: Sunday, December 27, 2015 4:55 PM



[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]
Hi Noam,



[auto build test ERROR on arc/for-next]
[also build test ERROR on v4.4-rc6 next-20151223]



url:
https://github.com/0day-ci/linux/commits/Noam-Camus/Adding-plat-eznps-to-ARC/20151227-220433
base:   https://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc for-next
config: i386-allmodconfig (attached as .config)
reproduce:
   # save the attached .config to linux build tree
  make ARCH=i386


This is meant for ARC only (not i386), I will add to the Kconfig file a 
dependency on my platform.


Hi Noam,

for compilation test coverage it would be nice to not restrict the to 
ARC only but change the write_aux_reg to a common name across the 
different arch if possible.


  -- Daniel


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

[PATCH] Documentation: fix typo in CodingStyle

[Manuel Pégourié-Gonnard]

Simple typo: "it" for "is".

Signed-off-by: Manuel Pégourié-Gonnard 
Cc: Trivial Patch Monkey 
---
 Documentation/CodingStyle | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index c06f817b3091..db653774c0b7 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -430,7 +430,7 @@ The rationale for using gotos is:
return result;
}
 
-A common type of bug to be aware of it "one err bugs" which look like this:
+A common type of bug to be aware of is "one err bugs" which look like this:
 
err:
kfree(foo->bar);
-- 
2.6.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] clk: change sizeof(struct clk *) to sizeof(*core->parents)

[Masahiro Yamada]

Now, the clock parent is not "struct clk *", but "struct clk_core *".
Of course, the size of a pointer is always same, but strictly speaking,
sizeof(struct clk *) should be sizeof(struct clk_core *) here.

This mismatch happened when we split the structure into struct clk
and struct clk_core.  For the potential possibility of future renaming,
sizeof(*core->parents) would be better.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 30c0bbc..98745c3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1069,7 +1069,7 @@ static int clk_fetch_parent_index(struct clk_core *core,
 
if (!core->parents) {
core->parents = kcalloc(core->num_parents,
-   sizeof(struct clk *), GFP_KERNEL);
+   sizeof(*core->parents), GFP_KERNEL);
if (!core->parents)
return -ENOMEM;
}
@@ -1702,7 +1702,7 @@ static struct clk_core *__clk_init_parent(struct clk_core 
*core)
 
if (!core->parents)
core->parents =
-   kcalloc(core->num_parents, sizeof(struct clk *),
+   kcalloc(core->num_parents, sizeof(*core->parents),
GFP_KERNEL);
 
ret = clk_core_get_parent_by_index(core, index);
@@ -2350,8 +2350,8 @@ static int __clk_core_init(struct clk_core *core)
 * necessary.
 */
if (core->num_parents > 1) {
-   core->parents = kcalloc(core->num_parents, sizeof(struct clk *),
-   GFP_KERNEL);
+   core->parents = kcalloc(core->num_parents,
+   sizeof(*core->parents), GFP_KERNEL);
/*
 * clk_core_lookup returns NULL for parents that have not been
 * clk_init'd; thus any access to clk->parents[] must check
-- 
1.9.1

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

Re: [PATCH v2 0/9] ARM: dts: Add compatible property to "partitions" node

[Geert Uytterhoeven]

Hi Simon,

On Mon, Dec 28, 2015 at 6:01 AM, Simon Horman  wrote:
> On Mon, Dec 21, 2015 at 11:33:44AM +0100, Geert Uytterhoeven wrote:
>> As of commit e488ca9f8d4f62c2 ("doc: dt: mtd: partitions: add compatible
>> property to "partitions" node"), which is in v4.4-rc6, the "partitions"
>> subnode of an SPI FLASH device node must have a compatible property. The
>> partitions are no longer detected if it is not present.
>>
>> However, several DTSes in -next have already been converted to the
>> "partitions" subnode without "compatible" property, introduced by
>> commits 5cfdedb7b9a0fe38 ("mtd: ofpart: move ofpart partitions to a
>> dedicated dt node") and fe2585e9c29a650a ("doc: dt: mtd: support
>> partitions in a special 'partitions' subnode"). Hence all of these are
>> now broken in -next, and will be broken in upstream during the merge
>> window.
>>
>> This series fixes all users in next-20151221.
>> Tested on r8a7791/koelsch.
>>
>> Changes since v1:
>>   - Add Acked-by,
>>   - Fix new users in -next (kirkwood, ci20).
>>
>> Most of these are in arm-soc/for-next. Exceptions are kirkwood (in
>> mvebu/for-next), and ci20 (in mips/mips-for-linux-next).
>>
>> Given we're late in the v4.4-rc cycle, perhaps it's easiest if the
>> arm-soc maintainers take all applicable patches directly, bypassing the
>> mvebu and shmobile maintainers?
>>
>> Thanks for queuing for v4.5!
>>
>> Geert Uytterhoeven (9):
>>   ARM: mvebu: ix4-300d: Add compatible property to "partitions" node
>>   ARM: mvebu: kirkwood: Add compatible property to "partitions" node
>>   ARM: shmobile: bockw dts: Add compatible property to "partitions" node
>>   ARM: shmobile: lager dts: Add compatible property to "partitions" node
>>   ARM: shmobile: koelsch dts: Add compatible property to "partitions"
>> node
>>   ARM: shmobile: porter dts: Add compatible property to "partitions"
>> node
>>   ARM: shmobile: gose dts: Add compatible property to "partitions" node
>>   ARM: shmobile: silk dts: Add compatible property to "partitions" node
>
> Thanks, I have queued up the above "shmobile" patches for v4.6.

I'm afraid v4.6 is too late, leaving all SPI FLASHes broken in v4.5.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection

[Julia Lawall]

On Mon, 28 Dec 2015, SF Markus Elfring wrote:

> >> Move the jump label directly before the desired log statement
> >> so that the variable "ret" will not be checked once more
> >> after it was determined that a function call failed.
> >
> > Why not avoid both unnecessary ifs
>
> I would find such a fine-tuning also nice in principle at more source code 
> places.
>
>
> > and the enormous ugliness of a label inside an if by making two returns:
> > a return 0 for success and a dev_dbg and return ret for failure?
>
> How should your suggestion finally work when the desired execution success
> can be determined for such functions only after several other calls succeeded?

Not idea what this means, but immediate return 0 followed by various code
for reacting to an error is very common, so it looks like it should be
possible here.

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

Re: [PATCH v5 09/20] ARC: IRQ: use device tree to get timer device configuration

[Vineet Gupta]

On Sunday 27 December 2015 06:53 PM, Noam Camus wrote:
> From: Noam Camus 
> 
> We've designated:
> TIMER0 for events (clockevents)
> TIMER1 for free running (clocksource)
> 
> Till now timer configuration was done on arch/arc/kernel/time.c
> with constant values.
> 
> This commit add device tree support so we can do this work
> at dedicated clocksource driver which parse the DT blob.
> 
> Such driver will get clocksource rate as well as interrupt line
> from DT and use them for setting clocksourcse and clockevents.
> 
> Note that lately called of_clk_init() is moved before we call
> clocksource_probe() since at that time device from DT
> need a "provider" (clocks) which will be available only after
> we call to of_clk_init().
> 
> Signed-off-by: Noam Camus 
> Acked-by: Vineet Gupta 

For patches which change semantically, ACK should not be copied over from prev
version. I do have some reservation with this patch.

I think we should just fix ARC once and for all by removing the legacy
registration. This would be a flag day change but I think we should be fine !
No point in keeping 2 implementations !

@Noam let me take a stab at it - OK !

-Vineet



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

Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region

[Arnd Bergmann]

On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote:
> @@ -75,8 +76,13 @@
>   * private definitions which should NOT be used outside memory.h
>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
>   */
> -#define __virt_to_phys(x)  (((phys_addr_t)(x) - PAGE_OFFSET + 
> PHYS_OFFSET))
> +#define __virt_to_phys(x) ({   \
> +   phys_addr_t __x = (phys_addr_t)(x); \
> +   __x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :\
> +(__x - KIMAGE_VADDR + PHYS_OFFSET); })
> +
>  #define __phys_to_virt(x)  ((unsigned long)((x) - PHYS_OFFSET + 
> PAGE_OFFSET))
> +#define __phys_to_kimg(x)  ((unsigned long)((x) - PHYS_OFFSET + 
> KIMAGE_VADDR))

Having a conditional here is a bit unfortunate.

IIRC KASLR means something different depending on the architecture, we either 
randomize
the physical address, or the virtual address, or both, and that addresses 
different
attack scenarios. You seem to leave the physical address unchanged, which means 
that
an attacker that has gained access to a DMA master device can potentially still 
modify
the kernel without knowing the virtual address.
Similarly, you seem to leave the kernel mapped at the original virtual address 
and
just add a second map (or your __phys_to_virt is wrong), so if someone has the
ability to access a kernel virtual memory address from user space, they also 
don't
need the relocated address because they can potentially access the kernel .text
and .data through the linear mapping.

How about a different approach that keeps the relocatable kernel, but moves it 
in
physical memory with the same random offset as the virtual address? That way, 
both
would be random, and you can keep the simple virt_to_phys() function.

I suppose the downside of that is that the number of random bits is then limited
by the size of the first memblock, which is smaller than the vmalloc area.

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

Re: [PATCH 0/3] OOM detection rework v4

[Tetsuo Handa]

Tetsuo Handa wrote:
> I got OOM killers while running heavy disk I/O (extracting kernel source,
> running lxr's genxref command). (Environ: 4 CPUs / 2048MB RAM / no swap / XFS)
> Do you think these OOM killers reasonable? Too weak against fragmentation?

Well, current patch invokes OOM killers when more than 75% of memory is used
for file cache (active_file: + inactive_file:). I think this is a surprising
thing for administrators and we want to retry more harder (but not forever,
please).

Complete log is at http://I-love.SAKURA.ne.jp/tmp/serial-20151228.txt.xz .
--
[  277.863985] Node 0 DMA32 free:20128kB min:5564kB low:6952kB high:8344kB 
active_anon:108332kB inactive_anon:8252kB active_file:985160kB 
inactive_file:615436kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
present:2080640kB managed:2021100kB mlocked:0kB dirty:4kB writeback:0kB 
mapped:5904kB shmem:8524kB slab_reclaimable:52088kB slab_unreclaimable:59748kB 
kernel_stack:31280kB pagetables:55708kB unstable:0kB bounce:0kB free_pcp:1056kB 
local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? 
no
[  277.884512] Node 0 DMA32: 3438*4kB (UME) 791*8kB (UME) 3*16kB (UM) 0*32kB 
0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 20128kB
[  291.331040] Node 0 DMA32 free:29500kB min:5564kB low:6952kB high:8344kB 
active_anon:126756kB inactive_anon:8252kB active_file:821500kB 
inactive_file:604016kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
present:2080640kB managed:2021100kB mlocked:0kB dirty:0kB writeback:0kB 
mapped:12684kB shmem:8524kB slab_reclaimable:56808kB slab_unreclaimable:99804kB 
kernel_stack:58448kB pagetables:92552kB unstable:0kB bounce:0kB free_pcp:2004kB 
local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? 
no
[  291.349097] Node 0 DMA32: 4221*4kB (UME) 1971*8kB (UME) 436*16kB (UME) 
141*32kB (UME) 8*64kB (UM) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 
44652kB
[  302.897985] Node 0 DMA32 free:28240kB min:5564kB low:6952kB high:8344kB 
active_anon:79344kB inactive_anon:8248kB active_file:1016568kB 
inactive_file:604696kB unevictable:0kB isolated(anon):0kB isolated(file):120kB 
present:2080640kB managed:2021100kB mlocked:0kB dirty:80kB writeback:0kB 
mapped:13004kB shmem:8520kB slab_reclaimable:52076kB slab_unreclaimable:64064kB 
kernel_stack:35168kB pagetables:48552kB unstable:0kB bounce:0kB free_pcp:1384kB 
local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? 
no
[  302.916334] Node 0 DMA32: 4304*4kB (UM) 1181*8kB (UME) 59*16kB (UME) 7*32kB 
(ME) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 27832kB
[  311.014501] Node 0 DMA32 free:22820kB min:5564kB low:6952kB high:8344kB 
active_anon:56852kB inactive_anon:11976kB active_file:1142936kB 
inactive_file:582040kB unevictable:0kB isolated(anon):0kB isolated(file):116kB 
present:2080640kB managed:2021100kB mlocked:0kB dirty:160kB writeback:0kB 
mapped:10796kB shmem:16640kB slab_reclaimable:48608kB 
slab_unreclaimable:41912kB kernel_stack:16560kB pagetables:30876kB unstable:0kB 
bounce:0kB free_pcp:948kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB 
pages_scanned:128 all_unreclaimable? no
[  311.034251] Node 0 DMA32: 6*4kB (U) 2401*8kB (ME) 0*16kB 0*32kB 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 19232kB
[  314.293371] Node 0 DMA32 free:15244kB min:5564kB low:6952kB high:8344kB 
active_anon:82496kB inactive_anon:11976kB active_file:1110984kB 
inactive_file:467400kB unevictable:0kB isolated(anon):0kB isolated(file):88kB 
present:2080640kB managed:2021100kB mlocked:0kB dirty:4kB writeback:0kB 
mapped:9440kB shmem:16640kB slab_reclaimable:53684kB slab_unreclaimable:72536kB 
kernel_stack:40048kB pagetables:67672kB unstable:0kB bounce:0kB free_pcp:1076kB 
local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:12 
all_unreclaimable? no
[  314.314336] Node 0 DMA32: 1180*4kB (UM) 1449*8kB (UME) 0*16kB 0*32kB 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 16312kB
[  322.774181] Node 0 DMA32 free:19780kB min:5564kB low:6952kB high:8344kB 
active_anon:68264kB inactive_anon:17816kB active_file:1155724kB 
inactive_file:470216kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
present:2080640kB managed:2021100kB mlocked:0kB dirty:8kB writeback:0kB 
mapped:9744kB shmem:24708kB slab_reclaimable:52540kB slab_unreclaimable:63216kB 
kernel_stack:32464kB pagetables:51856kB unstable:0kB bounce:0kB free_pcp:1076kB 
local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? 
no
[  322.796256] Node 0 DMA32: 86*4kB (UME) 2474*8kB (UME) 0*16kB 0*32kB 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 20136kB
[  330.804341] Node 0 DMA32 free:22076kB min:5564kB low:6952kB high:8344kB 
active_anon:47616kB inactive_anon:17816kB active_file:1063272kB 
inactive_file:685848kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
present:2080640kB managed:2021100kB mlocked:0kB dirty:216kB writeback:0k

Re: [PATCH 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()

[Minfei Huang]

On 12/28/15 at 02:32pm, Xunlei Pang wrote:
> On 12/24/2015 at 02:44 PM, Xunlei Pang wrote:
> > +static void kexec_mark_crashkres(bool protect)
> > +{
> > +   unsigned long control;
> > +
> > +   kexec_mark_range(crashk_low_res.start, crashk_low_res.end, 
> > protect);
> > +
> > +   /* Don't touch the control code page used in crash_kexec().*/
> > +   control = 
> > PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
> > +   /* Control code page is located in the 2nd page. */
> > +   control = control + PAGE_SIZE;
> >> Though it works because the control code is less than 1 page, but use the 
> >> macro
> >> of KEXEC_CONTROL_PAGE_SIZE looks better..
> 
> The 1st page is pagetable, control code page locates at the 2nd page.
> The following kexec_mark_range() wants to mark ro from crashk_res.start
> to the 1st page(included), so here we must use PAGE_SIZE.
> 
> >>
> > +   kexec_mark_range(crashk_res.start, control - 1, protect);
> > +   kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
>  X86 kexec will copy the page while kexecing, could you check if we can 
>  move
>  that copying to earliyer while kexec loading, maybe 
>  machine_kexec_prepare so
>  that we can make a arch-independent implementation.
> >>> For some arch, may use huge tlb directly to do the kernel mapping,
> >>> in such cases, we can't implement this function. So I think it should
> >>> be arch-dependent.
> >> Ok, that's fine.
> > At least moving the x86 control-copying code into arch-related
> > machine_kexec_prepare() should work, and this can omit the
> > special treatment of the control code page.
> 
> The "relocate_kernel" routine in "relocate_kernel_64.S" will use it as
> a temp storage "for jumping back"(as its comment), so we can't mark
> it readonly.

kexec will copy the relocate_kernel binary to control_code_page in
function machine_kexec. This is a major reason to set the region
control_code_page to control_code_page + PAGE_SIZE with mode read/write.

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

[RESEND PATCH v1 3/4] clk: rockchip: rk3036: rename emac ext source clock

[Xing Zheng]

There is only support rmii in the RK3036, so we should use the correct
ext clock name.

Signed-off-by: Xing Zheng 
---

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

diff --git a/drivers/clk/rockchip/clk-rk3036.c 
b/drivers/clk/rockchip/clk-rk3036.c
index 47fe35b..7420cbe 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -133,7 +133,7 @@ PNAME(mux_spdif_p)  = { "spdif_src", "spdif_frac", "xin12m" 
};
 PNAME(mux_uart0_p) = { "uart0_src", "uart0_frac", "xin24m" };
 PNAME(mux_uart1_p) = { "uart1_src", "uart1_frac", "xin24m" };
 PNAME(mux_uart2_p) = { "uart2_src", "uart2_frac", "xin24m" };
-PNAME(mux_mac_p)   = { "mac_pll_src", "ext_gmac" };
+PNAME(mux_mac_p)   = { "mac_pll_src", "rmii_clkin" };
 PNAME(mux_dclk_p)  = { "dclk_lcdc", "dclk_cru" };
 
 static struct rockchip_pll_clock rk3036_pll_clks[] __initdata = {
-- 
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/

[RESEND PATCH v1 2/4] clk: rockchip: rk3036: fix uarts clock error

[Xing Zheng]

Due to a copy-paste error the uart1 and uart2 clock div set
incorrect, we should to fix it.

Signed-off-by: Xing Zheng 
---

 drivers/clk/rockchip/clk-rk3036.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3036.c 
b/drivers/clk/rockchip/clk-rk3036.c
index d4ea7b6..47fe35b 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -222,11 +222,11 @@ static struct rockchip_clk_branch rk3036_clk_branches[] 
__initdata = {
RK2928_CLKSEL_CON(13), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(1), 8, GFLAGS),
COMPOSITE_NOMUX(0, "uart1_src", "uart_pll_clk", 0,
-   RK2928_CLKSEL_CON(13), 0, 7, DFLAGS,
-   RK2928_CLKGATE_CON(1), 8, GFLAGS),
+   RK2928_CLKSEL_CON(14), 0, 7, DFLAGS,
+   RK2928_CLKGATE_CON(1), 10, GFLAGS),
COMPOSITE_NOMUX(0, "uart2_src", "uart_pll_clk", 0,
-   RK2928_CLKSEL_CON(13), 0, 7, DFLAGS,
-   RK2928_CLKGATE_CON(1), 8, GFLAGS),
+   RK2928_CLKSEL_CON(15), 0, 7, DFLAGS,
+   RK2928_CLKGATE_CON(1), 12, GFLAGS),
COMPOSITE_FRAC(0, "uart0_frac", "uart0_src", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(17), 0,
RK2928_CLKGATE_CON(1), 9, GFLAGS),
-- 
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/

[RESEND PATCH v1 1/4] clk: rockchip: rk3036: fix the FLAGs for clock mux

[Xing Zheng]

The DFLAGS are used for the clock dividers, the CLKSEL_CON flags
of COMPOSITE_NODIV type should be MFLAGS.

Signed-off-by: Xing Zheng 
---

 drivers/clk/rockchip/clk-rk3036.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3036.c 
b/drivers/clk/rockchip/clk-rk3036.c
index 7333b053..d4ea7b6 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -204,16 +204,16 @@ static struct rockchip_clk_branch rk3036_clk_branches[] 
__initdata = {
RK2928_CLKGATE_CON(2), 2, GFLAGS),
 
COMPOSITE_NODIV(SCLK_TIMER0, "sclk_timer0", mux_timer_p, 
CLK_IGNORE_UNUSED,
-   RK2928_CLKSEL_CON(2), 4, 1, DFLAGS,
+   RK2928_CLKSEL_CON(2), 4, 1, MFLAGS,
RK2928_CLKGATE_CON(1), 0, GFLAGS),
COMPOSITE_NODIV(SCLK_TIMER1, "sclk_timer1", mux_timer_p, 
CLK_IGNORE_UNUSED,
-   RK2928_CLKSEL_CON(2), 5, 1, DFLAGS,
+   RK2928_CLKSEL_CON(2), 5, 1, MFLAGS,
RK2928_CLKGATE_CON(1), 1, GFLAGS),
COMPOSITE_NODIV(SCLK_TIMER2, "sclk_timer2", mux_timer_p, 
CLK_IGNORE_UNUSED,
-   RK2928_CLKSEL_CON(2), 6, 1, DFLAGS,
+   RK2928_CLKSEL_CON(2), 6, 1, MFLAGS,
RK2928_CLKGATE_CON(2), 4, GFLAGS),
COMPOSITE_NODIV(SCLK_TIMER3, "sclk_timer3", mux_timer_p, 
CLK_IGNORE_UNUSED,
-   RK2928_CLKSEL_CON(2), 7, 1, DFLAGS,
+   RK2928_CLKSEL_CON(2), 7, 1, MFLAGS,
RK2928_CLKGATE_CON(2), 5, GFLAGS),
 
MUX(0, "uart_pll_clk", mux_pll_src_apll_dpll_gpll_usb480m_p, 0,
@@ -262,13 +262,13 @@ static struct rockchip_clk_branch rk3036_clk_branches[] 
__initdata = {
RK2928_CLKGATE_CON(3), 2, GFLAGS),
 
COMPOSITE_NODIV(0, "sclk_sdmmc_src", mux_mmc_src_p, 0,
-   RK2928_CLKSEL_CON(12), 8, 2, DFLAGS,
+   RK2928_CLKSEL_CON(12), 8, 2, MFLAGS,
RK2928_CLKGATE_CON(2), 11, GFLAGS),
DIV(SCLK_SDMMC, "sclk_sdmmc", "sclk_sdmmc_src", 0,
RK2928_CLKSEL_CON(11), 0, 7, DFLAGS),
 
COMPOSITE_NODIV(0, "sclk_sdio_src", mux_mmc_src_p, 0,
-   RK2928_CLKSEL_CON(12), 10, 2, DFLAGS,
+   RK2928_CLKSEL_CON(12), 10, 2, MFLAGS,
RK2928_CLKGATE_CON(2), 13, GFLAGS),
DIV(SCLK_SDIO, "sclk_sdio", "sclk_sdio_src", 0,
RK2928_CLKSEL_CON(11), 8, 7, DFLAGS),
-- 
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 2/3] bpf: hash: move select_bucket() out of htab's spinlock

[Daniel Borkmann]

On 12/26/2015 10:31 AM, Ming Lei wrote:

The spinlock is just used for protecting the per-bucket
hlist, so it isn't needed for selecting bucket.

Signed-off-by: Ming Lei 


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

[RESEND PATCH v1 0/4] fix some clock configuration for the RK3036 platform

[Xing Zheng]

Hi:
  In the development work, we found that some of the previous incorrect
clock configuration on the RK3036 platform, we should fix them.



Xing Zheng (4):
  clk: rockchip: rk3036: fix the FLAGs for clock mux
  clk: rockchip: rk3036: fix uarts clock error
  clk: rockchip: rk3036: rename emac ext source clock
  clk: rockchip: rk3036: fix and add node id for emac clock

 drivers/clk/rockchip/clk-rk3036.c  |   33 
 include/dt-bindings/clock/rk3036-cru.h |2 ++
 2 files changed, 19 insertions(+), 16 deletions(-)

-- 
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 v2 02/16] clk: change the argument of __clk_init() into pointer to clk_core

[Masahiro Yamada]

The argument clk_user is used only for the clk_user->core.  The rest
of this function only takes care of clk_core.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/clk/clk.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 897e5ae..623838f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2285,25 +2285,22 @@ static inline void clk_debug_unregister(struct clk_core 
*core)
 #endif
 
 /**
- * __clk_init - initialize the data structures in a struct clk
- * @clk:   clk being initialized
+ * __clk_init - initialize the data structures in a struct clk_core
+ * @core:  clk_core being initialized
  *
  * Initializes the lists in struct clk_core, queries the hardware for the
  * parent and rate and sets them both.
  */
-static int __clk_init(struct clk *clk_user)
+static int __clk_init(struct clk_core *core)
 {
int i, ret = 0;
struct clk_core *orphan;
struct hlist_node *tmp2;
-   struct clk_core *core;
unsigned long rate;
 
-   if (!clk_user)
+   if (!core)
return -EINVAL;
 
-   core = clk_user->core;
-
clk_prepare_lock();
 
/* check to see if a clock with this name is already registered */
@@ -2574,7 +2571,7 @@ struct clk *clk_register(struct device *dev, struct 
clk_hw *hw)
goto fail_parent_names_copy;
}
 
-   ret = __clk_init(hw->clk);
+   ret = __clk_init(core);
if (!ret)
return hw->clk;
 
-- 
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 v2] clk: uniphier: add clock drivers for UniPhier SoCs

[Masahiro Yamada]

This is the initial commit for the UniPhier clock drivers, including
support for PH1-sLD3, PH1-LD4, PH1-Pro4, PH1-sLD8, PH1-Pro5, and
ProXstream2/PH1-LD6b.

To improve the code maintainability, the driver consists of common
functions (clk-uniphier-core.c) and clock data arrays needed to
support each SoC.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - split emmc_hw_reset
  - make SD clock rate-controllable
  - add CLK_SET_RATE_PARENT flag to mux, gate, fixed-factor clocks

 MAINTAINERS  |   1 +
 drivers/clk/Kconfig  |   1 +
 drivers/clk/Makefile |   1 +
 drivers/clk/uniphier/Kconfig |  35 
 drivers/clk/uniphier/Makefile|  10 +
 drivers/clk/uniphier/clk-ph1-ld4.c   | 117 
 drivers/clk/uniphier/clk-ph1-pro4.c  | 117 
 drivers/clk/uniphier/clk-ph1-pro5.c  | 107 +++
 drivers/clk/uniphier/clk-ph1-sld3.c  | 117 
 drivers/clk/uniphier/clk-ph1-sld8.c  | 107 +++
 drivers/clk/uniphier/clk-proxstream2.c   |  88 +
 drivers/clk/uniphier/clk-uniphier-core.c | 151 +++
 drivers/clk/uniphier/clk-uniphier-mio.c  | 315 +++
 drivers/clk/uniphier/clk-uniphier-peri.c | 175 +
 drivers/clk/uniphier/clk-uniphier.h  |  68 +++
 15 files changed, 1410 insertions(+)
 create mode 100644 drivers/clk/uniphier/Kconfig
 create mode 100644 drivers/clk/uniphier/Makefile
 create mode 100644 drivers/clk/uniphier/clk-ph1-ld4.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-pro4.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-pro5.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-sld3.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-sld8.c
 create mode 100644 drivers/clk/uniphier/clk-proxstream2.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier-core.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier-mio.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier-peri.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier.h

diff --git a/MAINTAINERS b/MAINTAINERS
index fc08493..6c10e9b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1644,6 +1644,7 @@ F:arch/arm/mach-uniphier/
 F: arch/arm/mm/cache-uniphier.c
 F: arch/arm64/boot/dts/socionext/
 F: drivers/bus/uniphier-system-bus.c
+F: drivers/clk/uniphier/
 F: drivers/i2c/busses/i2c-uniphier*
 F: drivers/pinctrl/uniphier/
 F: drivers/tty/serial/8250/8250_uniphier.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02..7580323 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -191,6 +191,7 @@ config COMMON_CLK_CDCE706
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
 source "drivers/clk/qcom/Kconfig"
+source "drivers/clk/uniphier/Kconfig"
 
 endmenu
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 820714c..ab9d1bd 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_ARCH_STI)+= st/
 obj-$(CONFIG_ARCH_SUNXI)   += sunxi/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-$(CONFIG_ARCH_OMAP2PLUS)   += ti/
+obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
 obj-$(CONFIG_ARCH_U8500)   += ux500/
 obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
 obj-$(CONFIG_X86)  += x86/
diff --git a/drivers/clk/uniphier/Kconfig b/drivers/clk/uniphier/Kconfig
new file mode 100644
index 000..7606f27
--- /dev/null
+++ b/drivers/clk/uniphier/Kconfig
@@ -0,0 +1,35 @@
+menuconfig CLK_UNIPHIER
+   bool "Clock drivers for UniPhier SoCs"
+   depends on ARCH_UNIPHIER
+   depends on OF
+   default y
+   help
+ Supports clock drivers for UniPhier SoCs.
+
+if CLK_UNIPHIER
+
+config CLK_UNIPHIER_PH1_SLD3
+   bool "Clock driver for UniPhier PH1-sLD3 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_LD4
+   bool "Clock driver for UniPhier PH1-LD4 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_PRO4
+   bool "Clock driver for UniPhier PH1-Pro4 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_SLD8
+   bool "Clock driver for UniPhier PH1-sLD8 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_PRO5
+   bool "Clock driver for UniPhier PH1-Pro5 SoC"
+   default y
+
+config CLK_UNIPHIER_PROXSTREAM2
+   bool "Clock driver for UniPhier ProXstream2/PH1-LD6b SoC"
+   default y
+
+endif
diff --git a/drivers/clk/uniphier/Makefile b/drivers/clk/uniphier/Makefile
new file mode 100644
index 000..3be1a17
--- /dev/null
+++ b/drivers/clk/uniphier/Makefile
@@ -0,0 +1,10 @@
+obj-y += clk-uniphier-core.o
+obj-y += clk-uniphier-peri.o
+obj-y += clk-uniphier-mio.o
+
+obj-$(CONFIG_CLK_UNIPHIER_PH1_SLD3)+= clk-ph1-sld3.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_LD4) += clk-ph1-ld4.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_PRO4)+= clk-ph1-pro4.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_SLD8)   

[PATCH] Docs: fix missing word in REPORTING-BUGS

[Manuel Pégourié-Gonnard]

The kernel versions, not the bugs, are listed on kernel.org

Signed-off-by: Manuel Pégourié-Gonnard 
Cc: triv...@kernel.org
---
scripts/get_maintainers.pl only pointed to the main list, so I took the
liberty to add the documentation list and maintainer. Please let me know
if that was a bad idea.
---
 REPORTING-BUGS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index 0cb8cdfa63bc..914baf9cf5fa 100644
--- a/REPORTING-BUGS
+++ b/REPORTING-BUGS
@@ -9,7 +9,7 @@ Please see https://www.kernel.org/ for a list of supported 
kernels.  Any
 kernel marked with [EOL] is "end of life" and will not have any fixes
 backported to it.
 
-If you've found a bug on a kernel version isn't listed on kernel.org,
+If you've found a bug on a kernel version that isn't listed on kernel.org,
 contact your Linux distribution or embedded vendor for support.
 Alternatively, you can attempt to run one of the supported stable or -rc
 kernels, and see if you can reproduce the bug on that.  It's preferable
-- 
2.6.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 0/7][v5]Add OTG support for FSL socs

[Ramneek Mehresh]

Add support for otg for all freescale socs having internal
usb phy.

Ramneek Mehresh (7):
  usb:fsl:otg: Make fsl otg driver as tristate
  usb:fsl:otg: Add controller version based ULPI and UTMI phy
  usb:fsl:otg: Add support to add/remove usb host driver
  usb:fsl:otg: Signal host drv when host is otg
  usb:fsl:otg: Modify otg_event to start host drv
  usb:fsl:otg: Combine host/gadget start/resume for ID change
  usb:fsl:otg: Add host-gadget drv sync delay

 drivers/usb/host/ehci-fsl.c   | 73 +++
 drivers/usb/host/ehci-fsl.h   | 16 ++
 drivers/usb/phy/Kconfig   |  2 +-
 drivers/usb/phy/phy-fsl-usb.c | 58 +-
 drivers/usb/phy/phy-fsl-usb.h |  7 +
 include/linux/usb.h   |  1 +
 6 files changed, 122 insertions(+), 35 deletions(-)

--
Changes for v5:
- moved "is_otg" definition from 4/7 to 3/7
  in order to fix compilation issue.
1.8.3.1

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

Re: [PATCH 3/3] bpf: hash: use per-bucket spinlock

[Ming Lei]

On Mon, Dec 28, 2015 at 5:13 PM, Daniel Borkmann  wrote:
> On 12/26/2015 10:31 AM, Ming Lei wrote:
>>
>> From: Ming Lei 
>>
>> Both htab_map_update_elem() and htab_map_delete_elem() can be
>> called from eBPF program, and they may be in kernel hot path,
>> so it isn't efficient to use a per-hashtable lock in this two
>> helpers.
>>
>> The per-hashtable spinlock is used just for protecting bucket's
>> hlist, and per-bucket lock should be enough. This patch converts
>> the per-hashtable lock into per-bucket spinlock, so that contention
>> can be decreased a lot.
>>
>> Signed-off-by: Ming Lei 
>> ---
>>   kernel/bpf/hashtab.c | 35 +--
>>   1 file changed, 25 insertions(+), 10 deletions(-)
>>
>> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
>> index d857fcb..66bad7a 100644
>> --- a/kernel/bpf/hashtab.c
>> +++ b/kernel/bpf/hashtab.c
>> @@ -14,9 +14,14 @@
>>   #include 
>>   #include 
>>
>> +struct bucket {
>> +   struct hlist_head head;
>> +   raw_spinlock_t lock;
>> +};
>> +
>>   struct bpf_htab {
>> struct bpf_map map;
>> -   struct hlist_head *buckets;
>> +   struct bucket *buckets;
>> raw_spinlock_t lock;
>
>
> Shouldn't the lock member be removed from here?

Hammm, looks this one is a bad version, sorry for that, and will resend it.

>
>
>> atomic_t count; /* number of elements in this hashtable */
>> u32 n_buckets;  /* number of hash buckets */
>> @@ -88,24 +93,25 @@ static struct bpf_map *htab_map_alloc(union bpf_attr
>> *attr)
>> /* make sure page count doesn't overflow */
>> goto free_htab;
>>
>> -   htab->map.pages = round_up(htab->n_buckets * sizeof(struct
>> hlist_head) +
>> +   htab->map.pages = round_up(htab->n_buckets * sizeof(struct bucket)
>> +
>>htab->elem_size *
>> htab->map.max_entries,
>>PAGE_SIZE) >> PAGE_SHIFT;
>>
>> err = -ENOMEM;
>> -   htab->buckets = kmalloc_array(htab->n_buckets, sizeof(struct
>> hlist_head),
>> +   htab->buckets = kmalloc_array(htab->n_buckets, sizeof(struct
>> bucket),
>>   GFP_USER | __GFP_NOWARN);
>>
>> if (!htab->buckets) {
>> -   htab->buckets = vmalloc(htab->n_buckets * sizeof(struct
>> hlist_head));
>> +   htab->buckets = vmalloc(htab->n_buckets * sizeof(struct
>> bucket));
>> if (!htab->buckets)
>> goto free_htab;
>> }
>>
>> -   for (i = 0; i < htab->n_buckets; i++)
>> -   INIT_HLIST_HEAD(>buckets[i]);
>> +   for (i = 0; i < htab->n_buckets; i++) {
>> +   INIT_HLIST_HEAD(>buckets[i].head);
>> +   raw_spin_lock_init(>buckets[i].lock);
>> +   }
>>
>> -   raw_spin_lock_init(>lock);
>> atomic_set(>count, 0);
>>
>> return >map;
>> @@ -120,11 +126,16 @@ static inline u32 htab_map_hash(const void *key, u32
>> key_len)
>> return jhash(key, key_len, 0);
>>   }
>>
>> -static inline struct hlist_head *select_bucket(struct bpf_htab *htab, u32
>> hash)
>> +static inline struct bucket *__select_bucket(struct bpf_htab *htab, u32
>> hash)
>>   {
>> return >buckets[hash & (htab->n_buckets - 1)];
>>   }
>>
>> +static inline struct hlist_head *select_bucket(struct bpf_htab *htab, u32
>> hash)
>> +{
>> +   return &__select_bucket(htab, hash)->head;
>> +}
>> +
>>   static struct htab_elem *lookup_elem_raw(struct hlist_head *head, u32
>> hash,
>>  void *key, u32 key_size)
>>   {
>> @@ -227,6 +238,7 @@ static int htab_map_update_elem(struct bpf_map *map,
>> void *key, void *value,
>> struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
>> struct htab_elem *l_new, *l_old;
>> struct hlist_head *head;
>> +   struct bucket *b;
>> unsigned long flags;
>> u32 key_size;
>> int ret;
>> @@ -248,7 +260,8 @@ static int htab_map_update_elem(struct bpf_map *map,
>> void *key, void *value,
>> memcpy(l_new->key + round_up(key_size, 8), value,
>> map->value_size);
>>
>> l_new->hash = htab_map_hash(l_new->key, key_size);
>> -   head = select_bucket(htab, l_new->hash);
>> +   b = __select_bucket(htab, l_new->hash);
>> +   head = >head;
>>
>> /* bpf_map_update_elem() can be called in_irq() */
>> raw_spin_lock_irqsave(>lock, flags);
>
>
> I am a bit confused on this one, though.
>
> The raw spin lock is still per hashtable (htab->lock), and has not been
> converted in
> this patch to the per bucket one (as opposed to what the commit message
> says), so
> this patch seems to go into the right direction, but is a bit incomplete?
> Shouldn't
> the above f.e. take b->lock, etc?
>
>> @@ -299,6 +312,7 @@ static int htab_map_delete_elem(struct bpf_map *map,
>> void *key)
>>   {

Re: [PATCH v10 2/3] mtd: nand: jz4780: driver for NAND devices on JZ4780 SoCs

[Boris Brezillon]

Hi Harvey,

I found a few remaining issues. Once fixed you can add my

Reviewed-by: Boris Brezillon 

On Thu, 24 Dec 2015 12:20:14 +
Harvey Hunt  wrote:

> From: Alex Smith 
> 
> Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as
> well as the hardware BCH controller. DMA is not currently implemented.
> 
> While older 47xx SoCs also have a BCH controller, they are incompatible
> with the one in the 4780 due to differing register/bit positions, which
> would make implementing a common driver for them quite messy.
> 
> Signed-off-by: Alex Smith 
> Cc: Zubair Lutfullah Kakakhel 
> Cc: David Woodhouse 
> Cc: Brian Norris 
> Cc: linux-...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Harvey Hunt 
> ---
> v9 -> v10:
>  - Replace uint{8,32}_t with u{8,32}.
>  - Only set IO_ADDR_{R,W} during chip init.
>  - Check that ECC layout fits into OOB area.
>  - Rebase onto l2-mtd/master and use its new functions.
>  - Remove mtd field from jz4780_nand_chip.
>  - Tidied up jz4780_nand_cmd_ctrl.
>  - Corrected ECC mode print statement.
>  - Refactor BCH code.
>  - Implement of_jz4780_bch_get.
>  - Update Authorship.
>  - Use a mutex to protect accesses to BCH controller.
>  - Update code documentation.
>  - Checkpatch cleanup.
> 
> v8 -> v9:
>  - No change.
> 
> v7 -> v8:
>  - Rebase to 4.4-rc3.
>  - Add _US suffixes to time constants.
>  - Add locking to BCH hardware accesses.
>  - Don't print ECC info if ECC is not being used.
>  - Default to No ECC.
>  - Let the NAND core handle ECC layout in certain cases.
>  - Use the gpio_desc consumer interface.
>  - Removed gpio active low flags.
>  - Check for the BCH controller before initialising a chip.
>  - Add a jz4780_nand_controller struct.
>  - Initialise chips by iterating over DT child nodes. 
> 
> v6 -> v7:
>  - Add nand-ecc-mode to DT bindings.
>  - Add nand-on-flash-bbt to DT bindings.
> 
> v5 -> v6:
>  - No change.
> 
> v4 -> v5:
>  - Rename ingenic,bch-device to ingenic,bch-controller to fit with
>existing convention.
> 
> v3 -> v4:
>  - No change
> 
> v2 -> v3:
>  - Rebase to 4.0-rc6
>  - Changed ingenic,ecc-size to common nand-ecc-step-size
>  - Changed ingenic,ecc-strength to common nand-ecc-strength
>  - Changed ingenic,busy-gpio to common rb-gpios
>  - Changed ingenic,wp-gpio to common wp-gpios
> 
> v1 -> v2:
>  - Rebase to 4.0-rc3
> 
>  drivers/mtd/nand/Kconfig   |   7 +
>  drivers/mtd/nand/Makefile  |   1 +
>  drivers/mtd/nand/jz4780_bch.c  | 381 +
>  drivers/mtd/nand/jz4780_bch.h  |  44 +
>  drivers/mtd/nand/jz4780_nand.c | 416 
> +
>  5 files changed, 849 insertions(+)
>  create mode 100644 drivers/mtd/nand/jz4780_bch.c
>  create mode 100644 drivers/mtd/nand/jz4780_bch.h
>  create mode 100644 drivers/mtd/nand/jz4780_nand.c
> 
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 2896640..b742adc 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -519,6 +519,13 @@ config MTD_NAND_JZ4740
>   help
>   Enables support for NAND Flash on JZ4740 SoC based boards.
>  
> +config MTD_NAND_JZ4780
> + tristate "Support for NAND on JZ4780 SoC"
> + depends on MACH_JZ4780 && JZ4780_NEMC
> + help
> +   Enables support for NAND Flash connected to the NEMC on JZ4780 SoC
> +   based boards, using the BCH controller for hardware error correction.
> +
>  config MTD_NAND_FSMC
>   tristate "Support for NAND on ST Micros FSMC"
>   depends on PLAT_SPEAR || ARCH_NOMADIK || ARCH_U8500 || MACH_U300
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 2c7f014..9e36233 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -49,6 +49,7 @@ obj-$(CONFIG_MTD_NAND_MPC5121_NFC)  += mpc5121_nfc.o
>  obj-$(CONFIG_MTD_NAND_VF610_NFC) += vf610_nfc.o
>  obj-$(CONFIG_MTD_NAND_RICOH) += r852.o
>  obj-$(CONFIG_MTD_NAND_JZ4740)+= jz4740_nand.o
> +obj-$(CONFIG_MTD_NAND_JZ4780)+= jz4780_nand.o jz4780_bch.o
>  obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/
>  obj-$(CONFIG_MTD_NAND_XWAY)  += xway_nand.o
>  obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/
> diff --git a/drivers/mtd/nand/jz4780_bch.c b/drivers/mtd/nand/jz4780_bch.c
> new file mode 100644
> index 000..22d3729
> --- /dev/null
> +++ b/drivers/mtd/nand/jz4780_bch.c
> @@ -0,0 +1,381 @@
> +/*
> + * JZ4780 BCH controller
> + *
> + * Copyright (c) 2015 Imagination Technologies
> + * Author: Alex Smith 
> + *
> + * 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 

Re: [Bugfix v2 1/5] x86/irq: Do not reuse struct apic_chip_data.old_domain as temporary buffer

[Jiang Liu]

On 2015/12/24 13:15, Jeremiah Mahler wrote:
> Jiang,
> 
> On Wed, Dec 23, 2015 at 10:13:26PM +0800, Jiang Liu wrote:
>> Function __assign_irq_vector() makes use of apic_chip_data.old_domain
>> as a temporary buffer, which causes trouble to rollback logic in case of
>> failure. So use a dedicated temporary buffer for __assign_irq_vector().
>>
>> Signed-off-by: Jiang Liu 
>> ---
>>  arch/x86/kernel/apic/vector.c |9 +
>>  1 file changed, 5 insertions(+), 4 deletions(-)
> [...]
> 
> I tried this patch and the rest in the series but unfortunately
> the bug is still present.
> 
>   [   10.184649] wlan0: authenticated
>   [   10.187883] wlan0: associate with 02:1a:11:fb:90:1c (try 1/3)
>   [   10.191574] do_IRQ: 0.35 No irq handler for vector
>   [   10.191589] do_IRQ: 0.35 No irq handler for vector
>   [   10.198159] do_IRQ: 0.35 No irq handler for vector
>   [   10.198165] do_IRQ: 0.35 No irq handler for vector
>   [   10.200534] wlan0: RX AssocResp from 02:1a:11:fb:90:1c (capab=0x431
>   status=0 aid=1)
>   [   10.204611] wlan0: associated
>   [   10.238883] do_IRQ: 0.35 No irq handler for vector
>   [   10.238892] do_IRQ: 0.35 No irq handler for vector
>   [   10.280716] do_IRQ: 0.35 No irq handler for vector
>   [   10.281083] do_IRQ: 0.35 No irq handler for vector
>   [   10.286484] do_IRQ: 0.35 No irq handler for vector
>   ...
> 
Hi Jeremiah,
Could you please help to confirm which commit caused the
regression?
1) x86/irq: Do not reuse struct apic_chip_data.old_domain as temporary
buffer
2) x86/irq: Fix a race condition between vector assigning and cleanup

Thanks,
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bpf: hash: use per-bucket spinlock

[Daniel Borkmann]

On 12/26/2015 10:31 AM, Ming Lei wrote:

From: Ming Lei 

Both htab_map_update_elem() and htab_map_delete_elem() can be
called from eBPF program, and they may be in kernel hot path,
so it isn't efficient to use a per-hashtable lock in this two
helpers.

The per-hashtable spinlock is used just for protecting bucket's
hlist, and per-bucket lock should be enough. This patch converts
the per-hashtable lock into per-bucket spinlock, so that contention
can be decreased a lot.

Signed-off-by: Ming Lei 
---
  kernel/bpf/hashtab.c | 35 +--
  1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index d857fcb..66bad7a 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -14,9 +14,14 @@
  #include 
  #include 

+struct bucket {
+   struct hlist_head head;
+   raw_spinlock_t lock;
+};
+
  struct bpf_htab {
struct bpf_map map;
-   struct hlist_head *buckets;
+   struct bucket *buckets;
raw_spinlock_t lock;


Shouldn't the lock member be removed from here?


atomic_t count; /* number of elements in this hashtable */
u32 n_buckets;  /* number of hash buckets */
@@ -88,24 +93,25 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
/* make sure page count doesn't overflow */
goto free_htab;

-   htab->map.pages = round_up(htab->n_buckets * sizeof(struct hlist_head) +
+   htab->map.pages = round_up(htab->n_buckets * sizeof(struct bucket) +
   htab->elem_size * htab->map.max_entries,
   PAGE_SIZE) >> PAGE_SHIFT;

err = -ENOMEM;
-   htab->buckets = kmalloc_array(htab->n_buckets, sizeof(struct 
hlist_head),
+   htab->buckets = kmalloc_array(htab->n_buckets, sizeof(struct bucket),
  GFP_USER | __GFP_NOWARN);

if (!htab->buckets) {
-   htab->buckets = vmalloc(htab->n_buckets * sizeof(struct 
hlist_head));
+   htab->buckets = vmalloc(htab->n_buckets * sizeof(struct 
bucket));
if (!htab->buckets)
goto free_htab;
}

-   for (i = 0; i < htab->n_buckets; i++)
-   INIT_HLIST_HEAD(>buckets[i]);
+   for (i = 0; i < htab->n_buckets; i++) {
+   INIT_HLIST_HEAD(>buckets[i].head);
+   raw_spin_lock_init(>buckets[i].lock);
+   }

-   raw_spin_lock_init(>lock);
atomic_set(>count, 0);

return >map;
@@ -120,11 +126,16 @@ static inline u32 htab_map_hash(const void *key, u32 
key_len)
return jhash(key, key_len, 0);
  }

-static inline struct hlist_head *select_bucket(struct bpf_htab *htab, u32 hash)
+static inline struct bucket *__select_bucket(struct bpf_htab *htab, u32 hash)
  {
return >buckets[hash & (htab->n_buckets - 1)];
  }

+static inline struct hlist_head *select_bucket(struct bpf_htab *htab, u32 hash)
+{
+   return &__select_bucket(htab, hash)->head;
+}
+
  static struct htab_elem *lookup_elem_raw(struct hlist_head *head, u32 hash,
 void *key, u32 key_size)
  {
@@ -227,6 +238,7 @@ static int htab_map_update_elem(struct bpf_map *map, void 
*key, void *value,
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
struct htab_elem *l_new, *l_old;
struct hlist_head *head;
+   struct bucket *b;
unsigned long flags;
u32 key_size;
int ret;
@@ -248,7 +260,8 @@ static int htab_map_update_elem(struct bpf_map *map, void 
*key, void *value,
memcpy(l_new->key + round_up(key_size, 8), value, map->value_size);

l_new->hash = htab_map_hash(l_new->key, key_size);
-   head = select_bucket(htab, l_new->hash);
+   b = __select_bucket(htab, l_new->hash);
+   head = >head;

/* bpf_map_update_elem() can be called in_irq() */
raw_spin_lock_irqsave(>lock, flags);


I am a bit confused on this one, though.

The raw spin lock is still per hashtable (htab->lock), and has not been 
converted in
this patch to the per bucket one (as opposed to what the commit message says), 
so
this patch seems to go into the right direction, but is a bit incomplete? 
Shouldn't
the above f.e. take b->lock, etc?


@@ -299,6 +312,7 @@ static int htab_map_delete_elem(struct bpf_map *map, void 
*key)
  {
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
struct hlist_head *head;
+   struct bucket *b;
struct htab_elem *l;
unsigned long flags;
u32 hash, key_size;
@@ -309,7 +323,8 @@ static int htab_map_delete_elem(struct bpf_map *map, void 
*key)
key_size = map->key_size;

hash = htab_map_hash(key, key_size);
-   head = select_bucket(htab, hash);
+   b = __select_bucket(htab, hash);
+   head = >head;

raw_spin_lock_irqsave(>lock, 

MCTP Protocol driver

[Umesh A]

 I need to implement firmware download software on MCTP( Management
Component Transport Protocol) protocol & PLDM .
I am not sure whether any driver/software available in linux on MCTP.
Please letme know any driver software available in Linux.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection

[SF Markus Elfring]

>> Move the jump label directly before the desired log statement
>> so that the variable "ret" will not be checked once more
>> after it was determined that a function call failed.
> 
> Why not avoid both unnecessary ifs

I would find such a fine-tuning also nice in principle at more source code 
places.


> and the enormous ugliness of a label inside an if by making two returns:
> a return 0 for success and a dev_dbg and return ret for failure?

How should your suggestion finally work when the desired execution success
can be determined for such functions only after several other calls succeeded?

Is consistent checking of failure predicates usually required?

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