Re: [RFC PATCH] mm/zsmalloc: remove unnecessary check

[Minchan Kim]

Hello Ganesh,

On Fri, Nov 21, 2014 at 10:56:10PM +0800, Ganesh Mahendran wrote:
> Hello Minchan
> 
> 2014-11-21 18:32 GMT+08:00 Minchan Kim :
> > On Fri, Nov 21, 2014 at 06:48:49AM +, Minchan Kim wrote:
> >> On Fri, Nov 21, 2014 at 01:33:26PM +0800, Ganesh Mahendran wrote:
> >> > Hello
> >> >
> >> > 2014-11-21 11:54 GMT+08:00 Minchan Kim :
> >> > > On Thu, Nov 20, 2014 at 09:21:56PM +0800, Mahendran Ganesh wrote:
> >> > >> ZS_SIZE_CLASSES is calc by:
> >> > >>   ((ZS_MAX_ALLOC_SIZE - ZS_MIN_ALLOC_SIZE) / ZS_SIZE_CLASS_DELTA + 1)
> >> > >>
> >> > >> So when i is in [0, ZS_SIZE_CLASSES - 1), the size:
> >> > >>   size = ZS_MIN_ALLOC_SIZE + i * ZS_SIZE_CLASS_DELTA
> >> > >> will not be greater than ZS_MAX_ALLOC_SIZE
> >> > >>
> >> > >> This patch removes the unnecessary check.
> >> > >
> >> > > It depends on ZS_MIN_ALLOC_SIZE.
> >> > > For example, we would change min to 8 but MAX is still 4096.
> >> > > ZS_SIZE_CLASSES is (4096 - 8) / 16 + 1 = 256 so 8 + 255 * 16 = 4088,
> >> > > which exceeds the max.
> >> > Here, 4088 is less than MAX(4096).
> >> >
> >> > ZS_SIZE_CLASSES = (MAX - MIN) / Delta + 1
> >> > So, I think the value of
> >> > MIN + (ZS_SIZE_CLASSES - 1) * Delta =
> >> > MIN + ((MAX - MIN) / Delta) * Delta =
> >> > MAX
> >> > will not exceed the MAX
> >>
> >> You're right. It was complext math for me.
> >> I should go back to elementary school.
> >>
> >> Thanks!
> >>
> >> Acked-by: Minchan Kim 
> >
> > I catch a nasty cold but above my poor math makes me think more.
> > ZS_SIZE_CLASSES is broken. In above my example, current code cannot
> > allocate 4096 size class so we should correct ZS_SIZE_CLASSES
> > at first.
> >
> > zs_size_classes = zs_max - zs_min / delta + 1;
> > if ((zs_max - zs_min) % delta)
> > zs_size_classes += 1;
> Yes, you are right.
> When the zs_min is less than delta, we can not allocate PAGE_SIZE size class.
> 
> >
> > Then, we need to code piece you removed.
> > As well, we need to fix below.
> >
> > - area->vm_buf = (char *)__get_free_page(GFP_KERNEL);
> > + area->vm_buf = kmalloc(ZS_MAX_ALLOC_SIZE);
> If our purpose is to allocate the max obj size as len of PAGE_SIZE, we
> do not need to
> change this line. Since the ZS_MAX_ALLOC_SIZE will always be PAGE_SIZE

No, please don't assume ZS_MAX_ALLOC_SIZE is PAGE_SIZE forever.
Some reason could make buffer larger than PAGE_SIZE.
For example, we might put allocator's metadata into each object's head/tail.

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-net 0/4] Increase the limit of tuntap queues

[Michael S. Tsirkin]

On Mon, Nov 24, 2014 at 11:23:05AM +0800, Jason Wang wrote:
> On 11/23/2014 06:46 PM, Michael S. Tsirkin wrote:
> > On Wed, Nov 19, 2014 at 10:44:27PM +0200, Michael S. Tsirkin wrote:
> >> > On Wed, Nov 19, 2014 at 03:16:28PM -0500, David Miller wrote:
> >>> > > From: Pankaj Gupta 
> >>> > > Date: Tue, 18 Nov 2014 21:52:54 +0530
> >>> > > 
>  > > > - Accept maximum number of queues as sysctl param so that any user 
>  > > > space 
>  > > >   application like libvirt can use this value to limit number of 
>  > > > queues. Also
>  > > >   Administrators can specify maximum number of queues by updating 
>  > > > this sysctl
>  > > >   entry.
> >>> > > 
> >>> > > This is the only part I don't like.
> >>> > > 
> >>> > > Just let whoever has privileges to configure the tun device shoot
> >>> > > themselves in the foot if they want to by configuring "too many"
> >>> > > queues.
> >>> > > 
> >>> > > If the virtual entity runs itself out of resources by doing something
> >>> > > stupid, it's purely their problem.
> >> > 
> >> > Well it will run host out of kernel, no?
> > To clarify:
> >
> > At the moment attaching/detaching queues is an unpriveledged operation.
> >
> > Shouldn't we worry that an application can cause large
> > allocations, and provide a way to limit these?
> 
> But creating new queues (TUNSETIFF) is privileged. There's no way for
> unprivileged user to allocate more resources. So we are safe here?

Hmm, that's true, I think I was confused.
Thanks for setting me straight.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block

[Dexuan Cui]

> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, November 24, 2014 15:28 PM
> To: Dexuan Cui; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> driverdev-de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; KY Srinivasan
> Cc: Haiyang Zhang
> Subject: Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of
> 2MB memory block
> 
> On 11/24/2014 02:08 PM, Dexuan Cui wrote:
> >> -Original Message-
> >> > From: Jason Wang [mailto:jasow...@redhat.com]
> >> > Sent: Monday, November 24, 2014 13:18 PM
> >> > To: Dexuan Cui; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org;
> >> > driverdev-de...@linuxdriverproject.org; o...@aepfle.de;
> >> > a...@canonical.com; KY Srinivasan
> >> > Cc: Haiyang Zhang
> >> > Subject: Re: [PATCH] hv: hv_balloon: avoid memory leak on
> alloc_error of
> >> > 2MB memory block
> >> >
> >> > On 11/24/2014 01:56 PM, Dexuan Cui wrote:
> >>> > > If num_ballooned is not 0, we shouldn't neglect the already-
> allocated
> >> > 2MB
> >>> > > memory block(s).
> >>> > >
> >>> > > Cc: K. Y. Srinivasan 
> >>> > > Cc: 
> >>> > > Signed-off-by: Dexuan Cui 
> >>> > > ---
> >>> > >  drivers/hv/hv_balloon.c | 4 +++-
> >>> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> >>> > >
> >>> > > diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> >>> > > index 5e90c5d..cba2d3b 100644
> >>> > > --- a/drivers/hv/hv_balloon.c
> >>> > > +++ b/drivers/hv/hv_balloon.c
> >>> > > @@ -1091,6 +1091,8 @@ static void balloon_up(struct
> work_struct
> >> > *dummy)
> >>> > >   bool done = false;
> >>> > >   int i;
> >>> > >
> >>> > > + /* The host does balloon_up in 2MB. */
> >>> > > + WARN_ON(num_pages % PAGES_IN_2M != 0);
> >>> > >
> >>> > >   /*
> >>> > >* We will attempt 2M allocations. However, if we fail to
> >>> > > @@ -,7 +1113,7 @@ static void balloon_up(struct
> work_struct
> >> > *dummy)
> >>> > >   bl_resp, alloc_unit,
> >>> > >_error);
> >>> > >
> >>> > > - if ((alloc_error) && (alloc_unit != 1)) {
> >>> > > + if (alloc_error && (alloc_unit != 1) &&
> num_ballooned == 0)
> >> > {
> >>> > >   alloc_unit = 1;
> >>> > >   continue;
> >>> > >   }
> >> >
> >> > Before the change, we may retry the 4K allocation when part or all 2M
> >> > allocations were failed. This makes sense when memory is fragmented.
> But
> > Yes, but all the partially-allocated 2MB memory blocks are lost(mem leak).
> >
> >> > after the change, if part of 2M allocation were failed, we won't retry
> >> > 4K allocation. Is this expected?
> > Hi Jason,
> > The patch doesn't break the "try 2MB first; then try 4K" logic:
> >
> > With the change, we'll retry the 2MB allocation in the next iteration of the
> > same while (!done) loop -- we expect this retry will cause
> > "alloc_error && (alloc_unit != 1) && num_ballooned == 0" to be true,
> > so we'll later try 4K allocation, as we did before.
> 
> If I read the code correctly, if part of 2M allocation fails.
> alloc_balloon_pages() will have a non zero return value with alloc_error
> set. Then it will match the following check:
> 
> if ((alloc_error) || (num_ballooned == num_pages))
> {
> 
> which will set done to true. So there's no second iteration of while
> (!done) loop?
Oh... I see the issue in my patch.
Thanks for pointing this out, Jason!

> Probably you need something like:
> 
> if ((alloc_unit != 1) && (num_ballooned == 0)) {
> alloc_unit = 1;
> continue;
> }
> 
> if ((alloc_unit == 1) || (num_ballooned == num_pages)) {
> ...
> }
Your code is good, except for one thing:
alloc_balloon_pages() can return due to:

if (bl_resp->hdr.size + sizeof(union dm_mem_page_range) >
 PAGE_SIZE)
return i * alloc_unit;

In this case, "alloc_unit == 1" is true, but we shouldn't run "done = true". 

How do you like this? I made a few changes based on your code.

@@ -1086,16 +1088,18 @@ static void balloon_up(struct work_struct *dummy)
num_pages -= num_ballooned;
+   alloc_error = false;
num_ballooned = alloc_balloon_pages(_device, num_pages,
bl_resp, alloc_unit,
 _error);

-   if ((alloc_error) && (alloc_unit != 1)) {
+   if (alloc_unit != 1 && num_ballooned == 0) {
alloc_unit = 1;
continue;
}

-   if ((alloc_error) || (num_ballooned == num_pages)) {
+   if ((alloc_unit == 1 && alloc_error) ||
+   (num_ballooned == num_pages)) {
bl_resp->more_pages = 0;
done = true;
dm_device.state = 

Re: [PATCH] xen-pciback: drop SR-IOV VFs when PF driver unloads

[Jan Beulich]

>>> On 21.11.14 at 23:03,  wrote:
> I rewrote it a bit to be more in the style of pciback:
>[...]
> [v2: Removed the switch statement, moved it about]

What you don't mention here is that you also removed the outer
loop, yet that breaks functionality afaict: There can (and I suppose
normally will) be multiple VFs needing device_release_driver() called
when a single PF goes away.

Also I'm not really happy for a patch with my S-o-b underneath to
introduce goto-s without real need.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2 v2] intel_pstate: skip this driver if hit Sun X86 servers

[Ethan Zhao]

Oracle Sun servers(X86) have power capping features that work via ACPI _PPC 
method,
patch No.1 is used to skip this driver if Oracle Sun server and _PPC detected. 
Patch No.2 introduces a kernel command line  parameter for those who would like
to enable intel_pstate on Sun X86 servers and be aware of the risk.


Compiled and tested with stable-3.18-rc5 on Oracle Sun server X4-2.
--
Ethan Zhao (2):
  intel_pstate: skip this driver if Sun server has _PPC method
  intel_pstate: add kernel parameter to enable loading on Sun X86
servers.

 Documentation/kernel-parameters.txt |  3 +++
 drivers/cpufreq/intel_pstate.c  | 24 
 2 files changed, 27 insertions(+)

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

[PATCH 2/2 v2] intel_pstate: add kernel parameter to enable loading on Sun X86 servers.

[Ethan Zhao]

To force loading on Oracle Sun X86 servers, provide one kernel command line
parameter

  intel_pstate = onora

For those who be aware of the risk doing so.

Signed-off-by: Ethan Zhao 

v2: change the command line parameter naming to specific to Oracle Sun servers.
---
 Documentation/kernel-parameters.txt | 3 +++
 drivers/cpufreq/intel_pstate.c  | 6 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 479f332..e4b1b81 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1446,6 +1446,9 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
   disable
 Do not enable intel_pstate as the default
 scaling driver for the supported processors
+  onora
+Enable loading intel_pstate on Oracle Sun Servers(X86).
+only for those who be aware of the risk.
 
intremap=   [X86-64, Intel-IOMMU]
on  enable Interrupt Remapping (default)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index dacc15a..f28c725 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -866,6 +866,7 @@ static struct cpufreq_driver intel_pstate_driver = {
 };
 
 static int __initdata no_load;
+static unsigned int  load_on_sun;
 
 static int intel_pstate_msrs_not_valid(void)
 {
@@ -987,7 +988,8 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
return true;
}
if (!strncmp(hdr.oem_id, vendor_info[1].oem_id, ACPI_OEM_ID_SIZE) &&
-   intel_pstate_has_acpi_ppc())
+   intel_pstate_has_acpi_ppc() &&
+   !load_on_sun)
return true;
 
return false;
@@ -1061,6 +1063,8 @@ static int __init intel_pstate_setup(char *str)
 
if (!strcmp(str, "disable"))
no_load = 1;
+   if (!strcmp(str, "onora"))
+   load_on_sun = 1;
return 0;
 }
 early_param("intel_pstate", intel_pstate_setup);
-- 
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/

[char-misc-next] mei: bus: use ssize_t as the return type for send and receive

[Tomas Winkler]

Mei bus receive and send function may return either number
of transmitted bytes or errno.  It is better to use ssize_t
type for that purpose that mixing size_t with int.

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 30 ++
 drivers/misc/mei/mei_dev.h |  6 +++---
 include/linux/mei_cl_bus.h |  4 ++--
 3 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index b2de93724f5b..be767f4db26a 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -224,13 +224,13 @@ void mei_cl_driver_unregister(struct mei_cl_driver 
*driver)
 }
 EXPORT_SYMBOL_GPL(mei_cl_driver_unregister);
 
-static int ___mei_cl_send(struct mei_cl *cl, u8 *buf, size_t length,
+static ssize_t ___mei_cl_send(struct mei_cl *cl, u8 *buf, size_t length,
bool blocking)
 {
struct mei_device *dev;
struct mei_me_client *me_cl = NULL;
struct mei_cl_cb *cb = NULL;
-   int rets;
+   ssize_t rets;
 
if (WARN_ON(!cl || !cl->dev))
return -ENODEV;
@@ -278,12 +278,12 @@ out:
return rets;
 }
 
-int __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t length)
+ssize_t __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t length)
 {
struct mei_device *dev;
struct mei_cl_cb *cb;
size_t r_length;
-   int err;
+   ssize_t rets;
 
if (WARN_ON(!cl || !cl->dev))
return -ENODEV;
@@ -293,11 +293,9 @@ int __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t 
length)
mutex_lock(>device_lock);
 
if (!cl->read_cb) {
-   err = mei_cl_read_start(cl, length);
-   if (err < 0) {
-   mutex_unlock(>device_lock);
-   return err;
-   }
+   rets = mei_cl_read_start(cl, length);
+   if (rets < 0)
+   goto out;
}
 
if (cl->reading_state != MEI_READ_COMPLETE &&
@@ -320,13 +318,13 @@ int __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t 
length)
cb = cl->read_cb;
 
if (cl->reading_state != MEI_READ_COMPLETE) {
-   r_length = 0;
+   rets = 0;
goto out;
}
 
r_length = min_t(size_t, length, cb->buf_idx);
-
memcpy(buf, cb->response_buffer.data, r_length);
+   rets = r_length;
 
mei_io_cb_free(cb);
cl->reading_state = MEI_IDLE;
@@ -335,20 +333,20 @@ int __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t 
length)
 out:
mutex_unlock(>device_lock);
 
-   return r_length;
+   return rets;
 }
 
-inline int __mei_cl_async_send(struct mei_cl *cl, u8 *buf, size_t length)
+inline ssize_t __mei_cl_async_send(struct mei_cl *cl, u8 *buf, size_t length)
 {
return ___mei_cl_send(cl, buf, length, 0);
 }
 
-inline int __mei_cl_send(struct mei_cl *cl, u8 *buf, size_t length)
+inline ssize_t __mei_cl_send(struct mei_cl *cl, u8 *buf, size_t length)
 {
return ___mei_cl_send(cl, buf, length, 1);
 }
 
-int mei_cl_send(struct mei_cl_device *device, u8 *buf, size_t length)
+ssize_t mei_cl_send(struct mei_cl_device *device, u8 *buf, size_t length)
 {
struct mei_cl *cl = device->cl;
 
@@ -362,7 +360,7 @@ int mei_cl_send(struct mei_cl_device *device, u8 *buf, 
size_t length)
 }
 EXPORT_SYMBOL_GPL(mei_cl_send);
 
-int mei_cl_recv(struct mei_cl_device *device, u8 *buf, size_t length)
+ssize_t mei_cl_recv(struct mei_cl_device *device, u8 *buf, size_t length)
 {
struct mei_cl *cl =  device->cl;
 
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 49c033158d43..363c093a7772 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -347,9 +347,9 @@ struct mei_cl_device *mei_cl_add_device(struct mei_device 
*dev,
struct mei_cl_ops *ops);
 void mei_cl_remove_device(struct mei_cl_device *device);
 
-int __mei_cl_async_send(struct mei_cl *cl, u8 *buf, size_t length);
-int __mei_cl_send(struct mei_cl *cl, u8 *buf, size_t length);
-int __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t length);
+ssize_t __mei_cl_async_send(struct mei_cl *cl, u8 *buf, size_t length);
+ssize_t __mei_cl_send(struct mei_cl *cl, u8 *buf, size_t length);
+ssize_t __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t length);
 void mei_cl_bus_rx_event(struct mei_cl *cl);
 void mei_cl_bus_remove_devices(struct mei_device *dev);
 int mei_cl_bus_init(void);
diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index 164aad1f9f12..0819d36a3a74 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -25,8 +25,8 @@ int __mei_cl_driver_register(struct mei_cl_driver *driver,
 
 void mei_cl_driver_unregister(struct mei_cl_driver *driver);
 
-int mei_cl_send(struct mei_cl_device *device, u8 *buf, size_t length);
-int mei_cl_recv(struct mei_cl_device *device, u8 *buf, size_t length);
+ssize_t mei_cl_send(struct 

[PATCH 1/2 v2] intel_pstate: skip this driver if Sun server has _PPC method

[Ethan Zhao]

Oracle Sun X86 servers have dynamic power capping capability that works via
ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
enabled.

Signed-off-by: Ethan Zhao 

v2: only match ORACLE oem id.
---
 drivers/cpufreq/intel_pstate.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 27bb6d3..dacc15a 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -943,6 +943,21 @@ static bool intel_pstate_no_acpi_pss(void)
return true;
 }
 
+static bool intel_pstate_has_acpi_ppc(void)
+{
+   int i;
+
+   for_each_possible_cpu(i) {
+   struct acpi_processor *pr = per_cpu(processors, i);
+
+   if (!pr)
+   continue;
+   if (acpi_has_method(pr->handle, "_PPC"))
+   return true;
+   }
+   return false;
+}
+
 struct hw_vendor_info {
u16  valid;
char oem_id[ACPI_OEM_ID_SIZE];
@@ -952,6 +967,7 @@ struct hw_vendor_info {
 /* Hardware vendor-specific info that has its own power management modes */
 static struct hw_vendor_info vendor_info[] = {
{1, "HP", "ProLiant"},
+   {1, "ORACLE", ""},
{0, "", ""},
 };
 
@@ -970,11 +986,15 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
intel_pstate_no_acpi_pss())
return true;
}
+   if (!strncmp(hdr.oem_id, vendor_info[1].oem_id, ACPI_OEM_ID_SIZE) &&
+   intel_pstate_has_acpi_ppc())
+   return true;
 
return false;
 }
 #else /* CONFIG_ACPI not enabled */
 static inline bool intel_pstate_platform_pwr_mgmt_exists(void) { return false; 
}
+static inline bool intel_pstate_has_acpi_ppc(void) { return false; }
 #endif /* CONFIG_ACPI */
 
 static int __init intel_pstate_init(void)
-- 
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 v2] mm/zsmalloc: avoid duplicate assignment of prev_class

[Minchan Kim]

On Fri, Nov 21, 2014 at 09:43:23PM +0800, Mahendran Ganesh wrote:
> In zs_create_pool(), prev_class is assigned (ZS_SIZE_CLASSES - 1)
> times. And the prev_class only references to the previous size_class.
> So we do not need unnecessary assignement.
> 
> This patch assigns *prev_class* when a new size_class structure
> is allocated and uses prev_class to check whether the first class
> has been allocated.
> 
> Signed-off-by: Mahendran Ganesh 
Acked-by: Minchan Kim 

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: FIX ME in xsysace.c

[Michal Simek]

Hi,

On 11/24/2014 05:19 AM, nick wrote:
> Greetings Michal and others,
> I am wondering about the FIX ME in xsysace.c as it seems not correct due to 
> my knowledge of most hardware protocols using a predetermined bit wide and 
> therefore this could be hard coded. If someone can respond on if I am correct 
> in removing this fix me it would be greatly appreciated.

I think that will be the best to c that fixme which you are talking about.
Definitely feel free to fix whatever fixme is there and send the patch
for fixing it.

Thanks,
Michal

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Implement lbr-as-callgraph v10

[Namhyung Kim]

Hi Andi and Arnaldo,

On Sat, 22 Nov 2014 02:25:19 +0100, Andi Kleen wrote:
>>  f1 tcall.c:9
>>  main tcall.c:17
>>  main tcall.c:17
>>  main tcall.c:16
>>  main tcall.c:16
>>  f1 tcall.c:12
>>  f1 tcall.c:12
>>  f2 tcall.c:6
>>  f2 tcall.c:4
>>  f1 tcall.c:11
>>  f1 tcall.c:11
>>  f2 tcall.c:6
>>  f2 tcall.c:4
>>  f1 tcall.c:10
>>  f1 tcall.c:9
>>  main tcall.c:17
>> 
>> 
>> 
>> Do you see the diff?  The 87.65% and 12.35% doesn't appear on the --tui
>> output.
>
> I see the problem. It's some issue in hist_browser__show_callchain.
> --stdio doesn't show it because it doesn't seem to use that (?)
>
> With this patch it shows percent for the first entry
>
> @@ -791,7 +791,7 @@ static int hist_browser__show_entry(struct hist_browser 
> *browser,
> };
>  
> printed += hist_browser__show_callchain(browser,
> -   >sorted_chain, 1, row, total,
> +   >sorted_chain, 2, row, total,
> hist_browser__show_callchain_entry, 
> ,
> hist_browser__check_output_full);
>
> But the numbers are still different from what --stdio outputs,
> so there are some deeper issues.
>
> I doubt I caused this, probably some latent bug that just got triggered.
>
> Namhyung?

I think it's an old bug even before my callchain cleanup patch series.
It only prints percent if the level is greater than 1 which I guess it
assumes there's only a single callchain path for the first level.

I'll post a patch for that soon.

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

linux-next: manual merge of the driver-core tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
drivers/staging/media/omap24xx/omap24xxcam.c between commit
db85a0403be4 ("[media] omap24xx/tcm825x: remove deprecated omap2 camera
drivers") from the v4l-dvb tree and commit 8c5bd8111b45 ("staging:
media: omap24xx: drop owner assignment from platform_drivers") from the
driver-core tree.

I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary (no action is required).

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


pgpt7d053_WzU.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the driver-core tree with the tegra tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
drivers/memory/tegra30-mc.c between commit a2257374a4bd ("memory: Add
NVIDIA Tegra memory controller support") from the tegra tree and commit
0f0d7e7b022b ("memory: drop owner assignment from platform_drivers")
from the driver-core tree.

I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary (no action is required).

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


pgpxi2PuGMkVN.pgp
Description: OpenPGP digital signature

Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block

[Jason Wang]

On 11/24/2014 02:08 PM, Dexuan Cui wrote:
>> -Original Message-
>> > From: Jason Wang [mailto:jasow...@redhat.com]
>> > Sent: Monday, November 24, 2014 13:18 PM
>> > To: Dexuan Cui; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
>> > driverdev-de...@linuxdriverproject.org; o...@aepfle.de;
>> > a...@canonical.com; KY Srinivasan
>> > Cc: Haiyang Zhang
>> > Subject: Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of
>> > 2MB memory block
>> > 
>> > On 11/24/2014 01:56 PM, Dexuan Cui wrote:
>>> > > If num_ballooned is not 0, we shouldn't neglect the already-allocated
>> > 2MB
>>> > > memory block(s).
>>> > >
>>> > > Cc: K. Y. Srinivasan 
>>> > > Cc: 
>>> > > Signed-off-by: Dexuan Cui 
>>> > > ---
>>> > >  drivers/hv/hv_balloon.c | 4 +++-
>>> > >  1 file changed, 3 insertions(+), 1 deletion(-)
>>> > >
>>> > > diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
>>> > > index 5e90c5d..cba2d3b 100644
>>> > > --- a/drivers/hv/hv_balloon.c
>>> > > +++ b/drivers/hv/hv_balloon.c
>>> > > @@ -1091,6 +1091,8 @@ static void balloon_up(struct work_struct
>> > *dummy)
>>> > > bool done = false;
>>> > > int i;
>>> > >
>>> > > +   /* The host does balloon_up in 2MB. */
>>> > > +   WARN_ON(num_pages % PAGES_IN_2M != 0);
>>> > >
>>> > > /*
>>> > >  * We will attempt 2M allocations. However, if we fail to
>>> > > @@ -,7 +1113,7 @@ static void balloon_up(struct work_struct
>> > *dummy)
>>> > > bl_resp, alloc_unit,
>>> > >  _error);
>>> > >
>>> > > -   if ((alloc_error) && (alloc_unit != 1)) {
>>> > > +   if (alloc_error && (alloc_unit != 1) && num_ballooned 
>>> > > == 0)
>> > {
>>> > > alloc_unit = 1;
>>> > > continue;
>>> > > }
>> > 
>> > Before the change, we may retry the 4K allocation when part or all 2M
>> > allocations were failed. This makes sense when memory is fragmented. But
> Yes, but all the partially-allocated 2MB memory blocks are lost(mem leak).
>
>> > after the change, if part of 2M allocation were failed, we won't retry
>> > 4K allocation. Is this expected?
> Hi Jason,
> The patch doesn't break the "try 2MB first; then try 4K" logic:
>
> With the change, we'll retry the 2MB allocation in the next iteration of the
> same while (!done) loop -- we expect this retry will cause
> "alloc_error && (alloc_unit != 1) && num_ballooned == 0" to be true,
> so we'll later try 4K allocation, as we did before.

If I read the code correctly, if part of 2M allocation fails.
alloc_balloon_pages() will have a non zero return value with alloc_error
set. Then it will match the following check:

if ((alloc_error) || (num_ballooned == num_pages))
{   

which will set done to true. So there's no second iteration of while
(!done) loop?

Probably you need something like:

if ((alloc_unit != 1) && (num_ballooned == 0)) {
alloc_unit = 1;
continue;
}

if ((alloc_unit == 1) || (num_ballooned = num_pages)) {
...
}

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

linux-next: manual merge of the driver-core tree with the tegra tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
drivers/iommu/tegra-smmu.c between commit a2257374a4bd ("memory: Add
NVIDIA Tegra memory controller support") from the tegra tree and commit
98b773cf7b6b ("iommu: drop owner assignment from platform_drivers")
from the driver-core tree.

I fixed it up (the former removed the code modified by the latter) and
can carry the fix as necessary (no action is required).

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


pgpSpj34Ta6rn.pgp
Description: OpenPGP digital signature

Re: crypto: user - crypto_alg_match removal

[Steffen Klassert]

Hi Stephan.

On Sat, Nov 22, 2014 at 11:25:05PM +0100, Stephan Mueller wrote:
> Hi Steffen, Herbert,
> 
> may I ask for the reasons why crypto_alg_match exists? Doesn't it 
> implement crypto_alg_lookup -- and that not even complete? Is there a 
> particular reason why this exact flag of crypto_alg_match is really 
> needed in the context of crypto_user?
> 
> Unless there is such valid reason, may I ask whether we can remove 
> crypto_alg_match and simply use crypto_alg_lookup in all instances where 
> crypto_alg_match is invoked using the following replacement:
> 
> alg = crypto_alg_lookup(p->cru_name, p->cru_type, p->cru_mask)
> 
> The only problem with this replacement is that p->cru_driver_name is not 
> considered with that. 

With crypto_alg_lookup() we don't know whether the match is based on
the driver or the algorithm name. That's why we have crypto_alg_match(),
here we can ask for a driver or an algorithm match. In some situations it
is important to have an exact match on the crypto driver name. For example
if a user wants to instantiate or delete a certain inplementation of an
algorithm. In this case we need to know whether this exact algorithm
driver is registered in the system.

> Do you think a double invocation of 
> crypto_alg_lookup should be done or that even the user space interface 
> should be changed such that cru_driver_name is removed from it?

Whatever we do, we can't remove cru_driver_name as this is exported
to userspace and tools already use it.

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

Re: Hierarchical irqdomains - Status update

[Jiang Liu]

On 2014/11/24 3:03, Thomas Gleixner wrote:
> Folks,
> 
> I've rebased the hierarchical irqdomain code on top of Bjorns
> msi_controller rework.
> 
> Changes versus the previous version:
> 
>- Bjorns new pci/mci branch. See also:
> http://lkml.kernel.org/r/20141121172018.ga6...@google.com
> 
>  Thanks Bjorn for fixing that just before your vacation!
> 
>- Rename of msi_mask/unmask_irq et al so it's clear that these
>  functions are PCI related and cannot be used for non PCI based
>  MSI functionality.
> 
>- Folded back fixup patches
> 
>- Added the missing parent check as reported by Suravee
> 
> The branch is now immutable and you can base your patches on it.
> 
> If you need to pull the branch into your tree, please let me know.
> 
> Patches which are mostly touching drivers/irqchip should go through
> Jason. Please post them against irq/irqdomain. We'll either create a
> seperate branch for them or merge irq/irqdomain into irq/core.
> 
> Thanks for the fruitful discussions, testing, rebasing and patience.
Thanks for your great support to enable hierarchy irqdomain.
Learned much about how to organize patches:)

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

Re: [PATCH] Repeated fork() causes SLAB to grow without bound

[Konstantin Khlebnikov]

On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov  wrote:
> On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11/20/2014 09:42 AM, Konstantin Khlebnikov wrote:
>>
>>> I'm thinking about limitation for reusing anon_vmas which might
>>> increase performance without breaking asymptotic estimation of
>>> count anon_vma in the worst case. For example this heuristic: allow
>>> to reuse only anon_vma with single direct descendant. It seems
>>> there will be arount up to two times more anon_vmas but
>>> false-aliasing must be much lower.

Done. RFC patch in attachment.

This patch adds heuristic which decides to reuse existing anon_vma instead
of forking new one. It counts vmas and direct descendants for each anon_vma.
Anon_vma with degree lower than two will be reused at next fork.
As a result each anon_vma has either alive vma or at least two descendants,
endless chains are no longer possible and count of anon_vmas is no more than
two times more than count of vmas.


>>
>> It may even be possible to not create a child anon_vma for the
>> first child a parent forks, but only create a new anon_vma once
>> the parent clones a second child (alive at the same time as the
>> first child).
>>
>> That still takes care of things like apache or sendmail, but
>> would not create infinite anon_vmas for a task that keeps forking
>> itself to infinite depth without calling exec...
>
> But this scheme is still exploitable. Malicious software easily could create
> sequence of forks and exits which leads to infinite chain of anon_vmas.
>
>>
>> - --
>> All rights reversed
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJUbf+hAAoJEM553pKExN6DxhQH/1QL+9GdhaSx7EQnRcbDRcHi
>> GuEfMU0g9Kv4ad+oPSQnH/L7vJMJAYeh5ZJGH+rOykWHp3sGReqDZOnzpXRAe11z
>> 1cSC1BJsndzrv9wX8niFpuKpYbF0IP+ckv3qaEzWtm5yCRyhHVZfr6b794Y4K9jF
>> z2EPPu1vAAldbkx1VlYTwofBA5lESL5UmrFvH4ouI7BeWYSEe6BgVCbvK+K5fANT
>> ketdA5R08xyUAcXDa+28qpBYkdWnxNhwqseDoXCW8SOFNwWbLDI6GRfrsCNku13i
>> Gi41h3uEuIAGDf+AU/GMjiymgwutCOGq+cfZlszELaRvHmDpNGYdPv1llghNg7Q=
>> =Vk+H
>> -END PGP SIGNATURE-


mm-prevent-endless-growth-of-anon_vma-hierarchy
Description: Binary data

[PATCH v5] clocksource: arch_timer: Fix code to use physical timers when requested

[Sonny Rao]

This is a bug fix for using physical arch timers when
the arch_timer_use_virtual boolean is false.  It restores the
arch_counter_get_cntpct() function after removal in

0d651e4e "clocksource: arch_timer: use virtual counters"

We need this on certain ARMv7 systems which are architected like this:

* The firmware doesn't know and doesn't care about hypervisor mode and
  we don't want to add the complexity of hypervisor there.

* The firmware isn't involved in SMP bringup or resume.

* The ARCH timer come up with an uninitialized offset between the
  virtual and physical counters.  Each core gets a different random
  offset.

* The device boots in "Secure SVC" mode.

* Nothing has touched the reset value of CNTHCTL.PL1PCEN or
  CNTHCTL.PL1PCTEN (both default to 1 at reset)

One example of such as system is RK3288 where it is much simpler to
use the physical counter since there's nobody managing the offset and
each time a core goes down and comes back up it will get reinitialized
to some other random value.

Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters")
Cc: sta...@vger.kernel.org
Signed-off-by: Sonny Rao 
Acked-by: Olof Johansson 
---
v2: Add fixes tag to commit message, cc stable, copy Doug's
description of the systems which need this in commit message.
v3: Don't change the memory-mapped physical timer/counter code
v4: remove the memory-mapped physical counter code since it's not used
v5: rebase and make AArch64 version of arch_counter_get_cntpct call BUG()
---
 arch/arm/include/asm/arch_timer.h| 9 +
 arch/arm64/include/asm/arch_timer.h  | 9 +
 drivers/clocksource/arm_arch_timer.c | 5 -
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch_timer.h 
b/arch/arm/include/asm/arch_timer.h
index 92793ba..d4ebf56 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -78,6 +78,15 @@ static inline u32 arch_timer_get_cntfrq(void)
return val;
 }
 
+static inline u64 arch_counter_get_cntpct(void)
+{
+   u64 cval;
+
+   isb();
+   asm volatile("mrrc p15, 0, %Q0, %R0, c14" : "=r" (cval));
+   return cval;
+}
+
 static inline u64 arch_counter_get_cntvct(void)
 {
u64 cval;
diff --git a/arch/arm64/include/asm/arch_timer.h 
b/arch/arm64/include/asm/arch_timer.h
index f190971..b1fa4e6 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -104,6 +104,15 @@ static inline void arch_timer_set_cntkctl(u32 cntkctl)
asm volatile("msr   cntkctl_el1, %0" : : "r" (cntkctl));
 }
 
+static inline u64 arch_counter_get_cntpct(void)
+{
+   /*
+* AArch64 kernel and user space mandate the use of CNTVCT.
+*/
+   BUG();
+   return 0;
+}
+
 static inline u64 arch_counter_get_cntvct(void)
 {
u64 cval;
diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 43005d4..1fa2af9 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -462,7 +462,10 @@ static void __init arch_counter_register(unsigned type)
 
/* Register the CP15 based counter if we have one */
if (type & ARCH_CP15_TIMER) {
-   arch_timer_read_counter = arch_counter_get_cntvct;
+   if (arch_timer_use_virtual)
+   arch_timer_read_counter = arch_counter_get_cntvct;
+   else
+   arch_timer_read_counter = arch_counter_get_cntpct;
} else {
arch_timer_read_counter = arch_counter_get_cntvct_mem;
 
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] serial: samsung: wait for transfer completion before clock disable

[Robert Baldyga]

This patch adds waiting until transmit buffer and shifter will be empty
before clock disabling.

Without this fix it's possible to have clock disabled while data was
not transmited yet, which causes unproper state of TX line and problems
in following data transfers.

Cc:  # v2.6.26+
Signed-off-by: Robert Baldyga 
---
 drivers/tty/serial/samsung.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index c78f43a..587d63b 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -559,11 +559,15 @@ static void s3c24xx_serial_pm(struct uart_port *port, 
unsigned int level,
  unsigned int old)
 {
struct s3c24xx_uart_port *ourport = to_ourport(port);
+   int timeout = 1;
 
ourport->pm_level = level;
 
switch (level) {
case 3:
+   while (--timeout && !s3c24xx_serial_txempty_nofifo(port))
+   udelay(100);
+
if (!IS_ERR(ourport->baudclk))
clk_disable_unprepare(ourport->baudclk);
 
-- 
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 3/4] serial: samsung: prefer to use fifosize from driver data

[Robert Baldyga]

If we have fifosize set in driver data we prefer to use it instead of default
fifosize value (which is always 16). If there is defined fifosize for particular
serial we prefer to use it, otherwise we use value from info, which is
common for all serials on given platform.

Signed-off-by: Robert Baldyga 
---
 drivers/tty/serial/samsung.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d05c32c..8808490 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1310,11 +1310,10 @@ static int s3c24xx_serial_probe(struct platform_device 
*pdev)
of_property_read_u32(np,
"samsung,uart-fifosize", >port.fifosize);
 
-   if (!ourport->port.fifosize) {
-   ourport->port.fifosize = (ourport->info->fifosize) ?
-   ourport->info->fifosize :
-   ourport->drv_data->fifosize[index];
-   }
+   if (ourport->drv_data->fifosize[index])
+   ourport->port.fifosize = ourport->drv_data->fifosize[index];
+   else if (ourport->info->fifosize)
+   ourport->port.fifosize = ourport->info->fifosize;
 
probe_index++;
 
-- 
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 0/4] serial: samsung: fixes for serial driver

[Robert Baldyga]

Hi,

This series contains fixes for samsung serial driver. There is one patch
with important fix, which, I think, should be also applied to stable
trees, two patches fixing FIFO handling (they are not critical but,
they can provide better FIFO usage) and one patch with code cleanup.

Best regards,
Robert Baldyga

Robert Baldyga (4):
  serial: samsung: wait for transfer completion before clock disable
  serial: samsung: fix style problems
  serial: samsung: prefer to use fifosize from driver data
  serial: samsung: use port->fifosize instead of hardcoded values

 drivers/tty/serial/samsung.c | 63 ++--
 1 file changed, 38 insertions(+), 25 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 2/4] serial: samsung: fix style problems

[Robert Baldyga]

Split lines longer than 80 chars and remove unnecessary whitespaces.

Signed-off-by: Robert Baldyga 
---
 drivers/tty/serial/samsung.c | 46 +++-
 1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 587d63b..d05c32c 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -199,12 +199,14 @@ static void s3c24xx_serial_stop_rx(struct uart_port *port)
}
 }
 
-static inline struct s3c24xx_uart_info *s3c24xx_port_to_info(struct uart_port 
*port)
+static inline struct s3c24xx_uart_info
+   *s3c24xx_port_to_info(struct uart_port *port)
 {
return to_ourport(port)->info;
 }
 
-static inline struct s3c2410_uartcfg *s3c24xx_port_to_cfg(struct uart_port 
*port)
+static inline struct s3c2410_uartcfg
+   *s3c24xx_port_to_cfg(struct uart_port *port)
 {
struct s3c24xx_uart_port *ourport;
 
@@ -311,14 +313,14 @@ s3c24xx_serial_rx_chars(int irq, void *dev_id)
uart_insert_char(port, uerstat, S3C2410_UERSTAT_OVERRUN,
 ch, flag);
 
- ignore_char:
+ignore_char:
continue;
}
 
spin_unlock_irqrestore(>lock, flags);
tty_flip_buffer_push(>state->port);
 
- out:
+out:
return IRQ_HANDLED;
 }
 
@@ -368,7 +370,7 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, void 
*id)
if (uart_circ_empty(xmit))
s3c24xx_serial_stop_tx(port);
 
- out:
+out:
spin_unlock_irqrestore(>lock, flags);
return IRQ_HANDLED;
 }
@@ -519,7 +521,7 @@ static int s3c24xx_serial_startup(struct uart_port *port)
 
return ret;
 
- err:
+err:
s3c24xx_serial_shutdown(port);
return ret;
 }
@@ -845,8 +847,8 @@ static void s3c24xx_serial_set_termios(struct uart_port 
*port,
 */
port->read_status_mask = S3C2410_UERSTAT_OVERRUN;
if (termios->c_iflag & INPCK)
-   port->read_status_mask |= S3C2410_UERSTAT_FRAME | 
S3C2410_UERSTAT_PARITY;
-
+   port->read_status_mask |= S3C2410_UERSTAT_FRAME |
+   S3C2410_UERSTAT_PARITY;
/*
 * Which character status flags should we ignore?
 */
@@ -973,10 +975,13 @@ static struct uart_driver s3c24xx_uart_drv = {
.minor  = S3C24XX_SERIAL_MINOR,
 };
 
-static struct s3c24xx_uart_port 
s3c24xx_serial_ports[CONFIG_SERIAL_SAMSUNG_UARTS] = {
+#define __PORT_LOCK_UNLOCKED(i) \
+   __SPIN_LOCK_UNLOCKED(s3c24xx_serial_ports[i].port.lock)
+static struct s3c24xx_uart_port
+s3c24xx_serial_ports[CONFIG_SERIAL_SAMSUNG_UARTS] = {
[0] = {
.port = {
-   .lock   = 
__SPIN_LOCK_UNLOCKED(s3c24xx_serial_ports[0].port.lock),
+   .lock   = __PORT_LOCK_UNLOCKED(0),
.iotype = UPIO_MEM,
.uartclk= 0,
.fifosize   = 16,
@@ -987,7 +992,7 @@ static struct s3c24xx_uart_port 
s3c24xx_serial_ports[CONFIG_SERIAL_SAMSUNG_UARTS
},
[1] = {
.port = {
-   .lock   = 
__SPIN_LOCK_UNLOCKED(s3c24xx_serial_ports[1].port.lock),
+   .lock   = __PORT_LOCK_UNLOCKED(1),
.iotype = UPIO_MEM,
.uartclk= 0,
.fifosize   = 16,
@@ -1000,7 +1005,7 @@ static struct s3c24xx_uart_port 
s3c24xx_serial_ports[CONFIG_SERIAL_SAMSUNG_UARTS
 
[2] = {
.port = {
-   .lock   = 
__SPIN_LOCK_UNLOCKED(s3c24xx_serial_ports[2].port.lock),
+   .lock   = __PORT_LOCK_UNLOCKED(2),
.iotype = UPIO_MEM,
.uartclk= 0,
.fifosize   = 16,
@@ -1013,7 +1018,7 @@ static struct s3c24xx_uart_port 
s3c24xx_serial_ports[CONFIG_SERIAL_SAMSUNG_UARTS
 #if CONFIG_SERIAL_SAMSUNG_UARTS > 3
[3] = {
.port = {
-   .lock   = 
__SPIN_LOCK_UNLOCKED(s3c24xx_serial_ports[3].port.lock),
+   .lock   = __PORT_LOCK_UNLOCKED(3),
.iotype = UPIO_MEM,
.uartclk= 0,
.fifosize   = 16,
@@ -1024,6 +1029,7 @@ static struct s3c24xx_uart_port 
s3c24xx_serial_ports[CONFIG_SERIAL_SAMSUNG_UARTS
}
 #endif
 };
+#undef __PORT_LOCK_UNLOCKED
 
 /* s3c24xx_serial_resetport
  *
@@ -1106,11 +1112,12 @@ static int s3c24xx_serial_cpufreq_transition(struct 
notifier_block *nb,
s3c24xx_serial_set_termios(uport, termios, NULL);
}
 
- exit:
+exit:
return 0;
 }
 
-static inline int s3c24xx_serial_cpufreq_register(struct s3c24xx_uart_port 
*port)
+static inline int
+s3c24xx_serial_cpufreq_register(struct s3c24xx_uart_port 

[PATCH 4/4] serial: samsung: use port->fifosize instead of hardcoded values

[Robert Baldyga]

Hardcoded FIFO size can cause hardware performance limitation.
Using real size value provides better FIFO usage.

Signed-off-by: Robert Baldyga 
---
 drivers/tty/serial/samsung.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 8808490..c622cf1 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -239,7 +239,7 @@ s3c24xx_serial_rx_chars(int irq, void *dev_id)
struct uart_port *port = >port;
unsigned int ufcon, ch, flag, ufstat, uerstat;
unsigned long flags;
-   int max_count = 64;
+   int max_count = port->fifosize;
 
spin_lock_irqsave(>lock, flags);
 
@@ -330,7 +330,7 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, void 
*id)
struct uart_port *port = >port;
struct circ_buf *xmit = >state->xmit;
unsigned long flags;
-   int count = 256;
+   int count = port->fifosize;
 
spin_lock_irqsave(>lock, flags);
 
-- 
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] net: introduce helper macra CMSG_FOREACH_HDR

[Gu Zheng]

Hi David,
On 11/24/2014 01:55 PM, David Miller wrote:

> 
> Your postings do not make it to the mailing list, in fact they don't
> even make it to the list server itself.

Thanks for your reminder.

> 
> Generally speaking, sites in China have this problem off and on, and
> in unpredictable ways.

Seems we should say thanks to GFW... 

> 
> You need to sort this out because I will not apply patches that don't
> hit the mailing list for review.

I'll confirm it first, and resent the patches once the problem is gone.

Regards,
Gu

> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block

[Dexuan Cui]

> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, November 24, 2014 13:18 PM
> To: Dexuan Cui; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> driverdev-de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; KY Srinivasan
> Cc: Haiyang Zhang
> Subject: Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of
> 2MB memory block
> 
> On 11/24/2014 01:56 PM, Dexuan Cui wrote:
> > If num_ballooned is not 0, we shouldn't neglect the already-allocated
> 2MB
> > memory block(s).
> >
> > Cc: K. Y. Srinivasan 
> > Cc: 
> > Signed-off-by: Dexuan Cui 
> > ---
> >  drivers/hv/hv_balloon.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> > index 5e90c5d..cba2d3b 100644
> > --- a/drivers/hv/hv_balloon.c
> > +++ b/drivers/hv/hv_balloon.c
> > @@ -1091,6 +1091,8 @@ static void balloon_up(struct work_struct
> *dummy)
> > bool done = false;
> > int i;
> >
> > +   /* The host does balloon_up in 2MB. */
> > +   WARN_ON(num_pages % PAGES_IN_2M != 0);
> >
> > /*
> >  * We will attempt 2M allocations. However, if we fail to
> > @@ -,7 +1113,7 @@ static void balloon_up(struct work_struct
> *dummy)
> > bl_resp, alloc_unit,
> >  _error);
> >
> > -   if ((alloc_error) && (alloc_unit != 1)) {
> > +   if (alloc_error && (alloc_unit != 1) && num_ballooned == 0)
> {
> > alloc_unit = 1;
> > continue;
> > }
> 
> Before the change, we may retry the 4K allocation when part or all 2M
> allocations were failed. This makes sense when memory is fragmented. But
Yes, but all the partially-allocated 2MB memory blocks are lost(mem leak).

> after the change, if part of 2M allocation were failed, we won't retry
> 4K allocation. Is this expected?
Hi Jason,
The patch doesn't break the "try 2MB first; then try 4K" logic:

With the change, we'll retry the 2MB allocation in the next iteration of the
same while (!done) loop -- we expect this retry will cause
"alloc_error && (alloc_unit != 1) && num_ballooned == 0" to be true,
so we'll later try 4K allocation, as we did before.


> Btw, can host just require 1M? If yes, should alloc_balloon_pages() set
Hi KY,
Can you please clarify this?
You know the host much more than me. :-)

> alloc_error if num_pages < alloc_unit for caller to catch this and retry
> 4K allocation?
 
-- Dexuan

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

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

[Stephen Rothwell]

Hi all,

After merging the kvm tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "get_xsave_addr" [arch/x86/kvm/kvm.ko] undefined!

Caused by commit 1d7fe1d1fb18 ("KVM: x86: support XSAVES usage in the
host").

I have used the kvm tree from next-20141121 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpqDT7TIv5eu.pgp
Description: OpenPGP digital signature

[PATCH v6 2/10] xfs: Add support FALLOC_FL_INSERT_RANGE for fallocate

[Namjae Jeon]

This patch implements fallocate's FALLOC_FL_INSERT_RANGE for XFS.

1) Make sure that both offset and len are block size aligned.
2) Update the i_size of inode by len bytes.
3) Compute the file's logical block number against offset. If the computed
   block number is not the starting block of the extent, split the extent
   such that the block number is the starting block of the extent.
4) Shift all the extents which are lying bewteen [offset, last allocated extent]
   towards right by len bytes. This step will make a hole of len bytes
   at offset.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
Changelog

v6:
 - This version is based upon Brian's changes to collapse paths.
 - Instead of having seperate functions for shifting extents left/right, the
   current extent shift function is made generic to shift in both directions.

v5:
 - remove allocation part.

v4:
 - set cur->bc_private.b.allocated to zero before calling xfs_btree_del_cursor.

v3:
 - remove XFS_TRANS_RESERVE and assert.
 - update the comment of blockcount calculation.
 - use 'if(blockcount)' instead of 'if (got.br_blockcount < blockcount)'.
 - move insert_file_space() calling under xfs_setattr_size to avoid code 
duplicate.

v2:
 - remove reserved enable.
 - add xfs_qm_dqattach.
 - reset blockcount in xfs_bmap_shift_extents_right.
 - update i_size to avoid data loss before insert_file_space() is called.
 - use in-memory extent array size that delayed allocation extents

 fs/xfs/libxfs/xfs_bmap.c | 368 +--
 fs/xfs/libxfs/xfs_bmap.h |  14 +-
 fs/xfs/xfs_bmap_util.c   | 118 +++
 fs/xfs/xfs_bmap_util.h   |   2 +
 fs/xfs/xfs_file.c|  38 -
 fs/xfs/xfs_trace.h   |   1 +
 6 files changed, 463 insertions(+), 78 deletions(-)

diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
index 79c9819..da01890 100644
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -5528,56 +5528,87 @@ xfs_bmse_shift_one(
int *current_ext,
struct xfs_bmbt_rec_host*gotp,
struct xfs_btree_cur*cur,
-   int *logflags)
+   int *logflags,
+   enum SHIFT_DIRECTIONSHIFT)
 {
struct xfs_ifork*ifp;
xfs_fileoff_t   startoff;
-   struct xfs_bmbt_rec_host*leftp;
+   struct xfs_bmbt_rec_host*contp;
struct xfs_bmbt_irecgot;
-   struct xfs_bmbt_irecleft;
+   struct xfs_bmbt_ireccont;
int error;
int i;
+   int total_extents;
 
ifp = XFS_IFORK_PTR(ip, whichfork);
+   total_extents = ifp->if_bytes / sizeof(xfs_bmbt_rec_t);
 
xfs_bmbt_get_all(gotp, );
-   startoff = got.br_startoff - offset_shift_fsb;
 
/* delalloc extents should be prevented by caller */
XFS_WANT_CORRUPTED_GOTO(!isnullstartblock(got.br_startblock),
out_error);
 
-   /*
-* If this is the first extent in the file, make sure there's enough
-* room at the start of the file and jump right to the shift as there's
-* no left extent to merge.
-*/
-   if (*current_ext == 0) {
-   if (got.br_startoff < offset_shift_fsb)
+   if (SHIFT == SHIFT_LEFT) {
+   startoff = got.br_startoff - offset_shift_fsb;
+   /*
+* If this is the first extent in the file, make sure there's
+* enough room at the start of the file and jump right to the
+* shift as there's no left extent to merge.
+*/
+   if (*current_ext == 0) {
+   if (got.br_startoff < offset_shift_fsb)
+   return -EINVAL;
+   goto shift_extent;
+   }
+
+   /* grab the left extent and check for a large enough hole */
+   contp = xfs_iext_get_ext(ifp, *current_ext - 1);
+   xfs_bmbt_get_all(contp, );
+
+   if (startoff < cont.br_startoff + cont.br_blockcount)
return -EINVAL;
-   goto shift_extent;
-   }
 
-   /* grab the left extent and check for a large enough hole */
-   leftp = xfs_iext_get_ext(ifp, *current_ext - 1);
-   xfs_bmbt_get_all(leftp, );
+   /* check whether to merge the extent or shift it down */
+   if (!xfs_bmse_can_merge(, , offset_shift_fsb))
+   goto shift_extent;
 
-   if (startoff < left.br_startoff + left.br_blockcount)
-   return -EINVAL;
+   return xfs_bmse_merge(ip, whichfork, offset_shift_fsb,
+ *current_ext, gotp, contp, cur, logflags);
+   } else {
+   

[PATCH v6 7/10] xfstests: generic/040: Multi insert range tests

[Namjae Jeon]

This testcase(040) tries to test various corner cases with pre-existing holes
for finsert range functionality over different type of extents.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 tests/generic/040 | 65 +
 tests/generic/040.out | 80 +++
 tests/generic/group   |  1 +
 3 files changed, 146 insertions(+)
 create mode 100644 tests/generic/040
 create mode 100644 tests/generic/040.out

diff --git a/tests/generic/040 b/tests/generic/040
new file mode 100644
index 000..df1c92f
--- /dev/null
+++ b/tests/generic/040
@@ -0,0 +1,65 @@
+#! /bin/bash
+# FS QA Test No. generic/040
+#
+# Multi insert range tests
+# This testcase is one of the 4 testcases which tries to
+# test various corner cases for finsert range functionality over different
+# type of extents. These tests are based on generic/255 test case.
+# For the type of tests, check the description of _test_generic_punch
+# in common/rc.
+#---
+# Copyright (c) 2013 Samsung Electronics.  All Rights Reserved.
+#
+# 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.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1   # failure is the default!
+
+_cleanup()
+{
+rm -f $tmp.*
+}
+
+trap "_cleanup ; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+# we need to include common/punch to get defination fo filter functions
+. ./common/rc
+. ./common/filter
+. ./common/punch
+
+# real QA test starts here
+_supported_fs generic
+_supported_os Linux
+
+_require_xfs_io_command "fpunch"
+_require_xfs_io_command "falloc"
+_require_xfs_io_command "fiemap"
+_require_xfs_io_command "finsert"
+
+testfile=$TEST_DIR/$seq.$$
+
+_test_generic_punch -k falloc fpunch finsert fiemap _filter_hole_fiemap 
$testfile
+_check_test_fs
+
+status=0
+exit
diff --git a/tests/generic/040.out b/tests/generic/040.out
new file mode 100644
index 000..c901e10
--- /dev/null
+++ b/tests/generic/040.out
@@ -0,0 +1,80 @@
+QA output created by 040
+   1. into a hole
+cf845a781c107ec1346e849c9dd1b7e8
+   2. into allocated space
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..55]: extent
+64e72217eebcbdf31b1b058f9f5f476a
+   3. into unwritten space
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..55]: extent
+22b7303d274481990b5401b6263effe0
+   4. hole -> data
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..55]: extent
+c4fef62ba1de9d91a977cfeec6632f19
+   5. hole -> unwritten
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..55]: extent
+1ca74f7572a0f4ab477fdbb5682e5f61
+   6. data -> hole
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..31]: extent
+3: [32..47]: hole
+4: [48..55]: extent
+be0f35d4292a20040766d87883b0abd1
+   7. data -> unwritten
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..47]: extent
+3: [48..55]: hole
+bddb1f3895268acce30d516a99cb0f2f
+   8. unwritten -> hole
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..31]: extent
+3: [32..39]: hole
+4: [40..55]: extent
+f8fc47adc45b7cf72f988b3ddf5bff64
+   9. unwritten -> data
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..47]: extent
+3: [48..55]: hole
+c4fef62ba1de9d91a977cfeec6632f19
+   10. hole -> data -> hole
+0: [0..7]: extent
+1: [8..39]: hole
+2: [40..63]: extent
+52af1bfcbf43f28af2328de32e0567e5
+   11. data -> hole -> data
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..39]: extent
+3: [40..47]: hole
+4: [48..63]: extent
+e3a8d52acc4d91a8ed19d7b6f4f26a71
+   12. unwritten -> data -> unwritten
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..63]: extent
+52af1bfcbf43f28af2328de32e0567e5
+   13. data -> unwritten -> data
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..63]: extent
+2b22165f4a24a2c36fd05ef00b41df88
+   14. data -> hole @ EOF
+0: [0..23]: extent
+1: [24..39]: hole
+2: [40..55]: extent
+aa0f20d1edcdbce60d8ef82700ba30c3
+   15. data -> hole @ 0
+0: [0..15]: hole
+1: [16..55]: extent
+86c9d033be2761385c9cfa203c426bb2
diff --git a/tests/generic/group b/tests/generic/group
index 4beb27f..9d5f72d 100644
--- a/tests/generic/group
+++ b/tests/generic/group
@@ -42,6 +42,7 @@
 037 metadata auto quick
 038 auto quick prealloc
 039 auto quick prealloc
+040 auto 

[PATCH v6 4/10] xfsprogs: xfs_io: add finsert command for insert range via fallocate

[Namjae Jeon]

Add finsert command for fallocate FALLOC_FL_INSERT_RANGE flag.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 io/prealloc.c | 39 ++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/io/prealloc.c b/io/prealloc.c
index aba6b44..11b1e12 100644
--- a/io/prealloc.c
+++ b/io/prealloc.c
@@ -37,6 +37,10 @@
 #define FALLOC_FL_ZERO_RANGE 0x10
 #endif
 
+#ifndef FALLOC_FL_INSERT_RANGE
+#define FALLOC_FL_INSERT_RANGE 0x20
+#endif
+
 static cmdinfo_t allocsp_cmd;
 static cmdinfo_t freesp_cmd;
 static cmdinfo_t resvsp_cmd;
@@ -46,6 +50,7 @@ static cmdinfo_t zero_cmd;
 static cmdinfo_t falloc_cmd;
 static cmdinfo_t fpunch_cmd;
 static cmdinfo_t fcollapse_cmd;
+static cmdinfo_t finsert_cmd;
 static cmdinfo_t fzero_cmd;
 #endif
 
@@ -169,11 +174,14 @@ fallocate_f(
int mode = 0;
int c;
 
-   while ((c = getopt(argc, argv, "ckp")) != EOF) {
+   while ((c = getopt(argc, argv, "cikp")) != EOF) {
switch (c) {
case 'c':
mode = FALLOC_FL_COLLAPSE_RANGE;
break;
+   case 'i':
+   mode = FALLOC_FL_INSERT_RANGE;
+   break;
case 'k':
mode = FALLOC_FL_KEEP_SIZE;
break;
@@ -237,6 +245,25 @@ fcollapse_f(
 }
 
 static int
+finsert_f(
+   int argc,
+   char**argv)
+{
+   xfs_flock64_t   segment;
+   int mode = FALLOC_FL_INSERT_RANGE;
+
+   if (!offset_length(argv[1], argv[2], ))
+   return 0;
+
+   if (fallocate(file->fd, mode,
+   segment.l_start, segment.l_len)) {
+   perror("fallocate");
+   return 0;
+   }
+   return 0;
+}
+
+static int
 fzero_f(
int argc,
char**argv)
@@ -345,6 +372,16 @@ prealloc_init(void)
_("de-allocates space and eliminates the hole by shifting extents");
add_command(_cmd);
 
+   finsert_cmd.name = "finsert";
+   finsert_cmd.cfunc = finsert_f;
+   finsert_cmd.argmin = 2;
+   finsert_cmd.argmax = 2;
+   finsert_cmd.flags = CMD_NOMAP_OK | CMD_FOREIGN_OK;
+   finsert_cmd.args = _("off len");
+   finsert_cmd.oneline =
+   _("creates new space for writing within file by shifting extents");
+   add_command(_cmd);
+
fzero_cmd.name = "fzero";
fzero_cmd.cfunc = fzero_f;
fzero_cmd.argmin = 2;
-- 
1.7.11-rc0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 8/10] xfstests: generic/041: Delayed allocation multi insert

[Namjae Jeon]

This testcase(041) tries to test various corner cases with delayed extents and
pre-existing holes for finsert range functionality over different type of
extents.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 tests/generic/041 | 65 +
 tests/generic/041.out | 80 +++
 tests/generic/group   |  1 +
 3 files changed, 146 insertions(+)
 create mode 100644 tests/generic/041
 create mode 100644 tests/generic/041.out

diff --git a/tests/generic/041 b/tests/generic/041
new file mode 100644
index 000..abaa2f4
--- /dev/null
+++ b/tests/generic/041
@@ -0,0 +1,65 @@
+#! /bin/bash
+# FS QA Test No. generic/041
+#
+# Delayed allocation multi insert range tests
+# This testcase is one of the 4 testcases which tries to
+# test various corner cases for finsert range functionality over different
+# type of extents. These tests are based on generic/255 test case.
+# For the type of tests, check the description of _test_generic_punch
+# in common/rc.
+#---
+# Copyright (c) 2013 Samsung Electronics.  All Rights Reserved.
+#
+# 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.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1   # failure is the default!
+
+_cleanup()
+{
+rm -f $tmp.*
+}
+
+trap "_cleanup ; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+# we need to include common/punch to get defination fo filter functions
+. ./common/rc
+. ./common/filter
+. ./common/punch
+
+# real QA test starts here
+_supported_fs generic
+_supported_os Linux
+
+_require_xfs_io_command "fpunch"
+_require_xfs_io_command "falloc"
+_require_xfs_io_command "fiemap"
+_require_xfs_io_command "finsert"
+
+testfile=$TEST_DIR/$seq.$$
+
+_test_generic_punch -d -k falloc fpunch finsert fiemap _filter_hole_fiemap 
$testfile
+_check_test_fs
+
+status=0
+exit
diff --git a/tests/generic/041.out b/tests/generic/041.out
new file mode 100644
index 000..5fe3c5e
--- /dev/null
+++ b/tests/generic/041.out
@@ -0,0 +1,80 @@
+QA output created by 041
+   1. into a hole
+cf845a781c107ec1346e849c9dd1b7e8
+   2. into allocated space
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..55]: extent
+64e72217eebcbdf31b1b058f9f5f476a
+   3. into unwritten space
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..55]: extent
+22b7303d274481990b5401b6263effe0
+   4. hole -> data
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..55]: extent
+c4fef62ba1de9d91a977cfeec6632f19
+   5. hole -> unwritten
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..55]: extent
+1ca74f7572a0f4ab477fdbb5682e5f61
+   6. data -> hole
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..31]: extent
+3: [32..47]: hole
+4: [48..55]: extent
+be0f35d4292a20040766d87883b0abd1
+   7. data -> unwritten
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..47]: extent
+3: [48..55]: hole
+bddb1f3895268acce30d516a99cb0f2f
+   8. unwritten -> hole
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..31]: extent
+3: [32..39]: hole
+4: [40..55]: extent
+f8fc47adc45b7cf72f988b3ddf5bff64
+   9. unwritten -> data
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..47]: extent
+3: [48..55]: hole
+c4fef62ba1de9d91a977cfeec6632f19
+   10. hole -> data -> hole
+0: [0..7]: extent
+1: [8..39]: hole
+2: [40..63]: extent
+52af1bfcbf43f28af2328de32e0567e5
+   11. data -> hole -> data
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..39]: extent
+3: [40..47]: hole
+4: [48..63]: extent
+e3a8d52acc4d91a8ed19d7b6f4f26a71
+   12. unwritten -> data -> unwritten
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..63]: extent
+52af1bfcbf43f28af2328de32e0567e5
+   13. data -> unwritten -> data
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..63]: extent
+2b22165f4a24a2c36fd05ef00b41df88
+   14. data -> hole @ EOF
+0: [0..23]: extent
+1: [24..39]: hole
+2: [40..55]: extent
+aa0f20d1edcdbce60d8ef82700ba30c3
+   15. data -> hole @ 0
+0: [0..15]: hole
+1: [16..55]: extent
+86c9d033be2761385c9cfa203c426bb2
diff --git a/tests/generic/group b/tests/generic/group
index 9d5f72d..34e223d 100644
--- a/tests/generic/group
+++ b/tests/generic/group
@@ -43,6 +43,7 @@
 038 auto quick prealloc
 039 auto quick 

[PATCH v6 9/10] xfstests: fsstress: Add fallocate insert range

[Namjae Jeon]

This commit adds insert operation support for fsstress, which is
meant to exercise fallocate FALLOC_FL_INSERT_RANGE support.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 ltp/fsstress.c | 19 ---
 src/global.h   |  4 
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/ltp/fsstress.c b/ltp/fsstress.c
index b56fe5c..aa3e0c3 100644
--- a/ltp/fsstress.c
+++ b/ltp/fsstress.c
@@ -72,6 +72,7 @@ typedef enum {
OP_PUNCH,
OP_ZERO,
OP_COLLAPSE,
+   OP_INSERT,
OP_READ,
OP_READLINK,
OP_RENAME,
@@ -170,6 +171,7 @@ voidmknod_f(int, long);
 void   punch_f(int, long);
 void   zero_f(int, long);
 void   collapse_f(int, long);
+void   insert_f(int, long);
 void   read_f(int, long);
 void   readlink_f(int, long);
 void   rename_f(int, long);
@@ -209,6 +211,7 @@ opdesc_tops[] = {
{ OP_PUNCH, "punch", punch_f, 1, 1 },
{ OP_ZERO, "zero", zero_f, 1, 1 },
{ OP_COLLAPSE, "collapse", collapse_f, 1, 1 },
+   { OP_INSERT, "insert", insert_f, 1, 1 },
{ OP_READ, "read", read_f, 1, 0 },
{ OP_READLINK, "readlink", readlink_f, 1, 0 },
{ OP_RENAME, "rename", rename_f, 2, 1 },
@@ -2176,6 +2179,7 @@ struct print_flags falloc_flags [] = {
{ FALLOC_FL_NO_HIDE_STALE, "NO_HIDE_STALE"},
{ FALLOC_FL_COLLAPSE_RANGE, "COLLAPSE_RANGE"},
{ FALLOC_FL_ZERO_RANGE, "ZERO_RANGE"},
+   { FALLOC_FL_INSERT_RANGE, "INSERT_RANGE"},
{ -1, NULL}
 };
 
@@ -2227,10 +2231,11 @@ do_fallocate(int opno, long r, int mode)
off %= maxfsize;
len = (off64_t)(random() % (1024 * 1024));
/*
-* Collapse range requires off and len to be block aligned, make it
-* more likely to be the case.
+* Collapse/insert range requires off and len to be block aligned,
+* make it more likely to be the case.
 */
-   if ((mode & FALLOC_FL_COLLAPSE_RANGE) && (opno % 2)) {
+   if ((mode & (FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_INSERT_RANGE)) &&
+   (opno % 2)) {
off = ((off + stb.st_blksize - 1) & ~(stb.st_blksize - 1));
len = ((len + stb.st_blksize - 1) & ~(stb.st_blksize - 1));
}
@@ -2656,6 +2661,14 @@ collapse_f(int opno, long r)
 }
 
 void
+insert_f(int opno, long r)
+{
+#ifdef HAVE_LINUX_FALLOC_H
+   do_fallocate(opno, r, FALLOC_FL_INSERT_RANGE);
+#endif
+}
+
+void
 read_f(int opno, long r)
 {
char*buf;
diff --git a/src/global.h b/src/global.h
index 8180f66..f63246b 100644
--- a/src/global.h
+++ b/src/global.h
@@ -172,6 +172,10 @@
 #define FALLOC_FL_ZERO_RANGE   0x10
 #endif
 
+#ifndef FALLOC_FL_INSERT_RANGE
+#define FALLOC_FL_INSERT_RANGE 0x20
+#endif
+
 #endif /* HAVE_LINUX_FALLOC_H */
 
 #endif /* GLOBAL_H */
-- 
1.7.11-rc0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 10/10] xfstests: fsx: Add fallocate insert range operation

[Namjae Jeon]

This commit adds fallocate FALLOC_FL_INSERT_RANGE support for fsx.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 ltp/fsx.c | 96 +--
 1 file changed, 94 insertions(+), 2 deletions(-)

diff --git a/ltp/fsx.c b/ltp/fsx.c
index 47d3ee8..9dc1655 100644
--- a/ltp/fsx.c
+++ b/ltp/fsx.c
@@ -95,7 +95,8 @@ int   logcount = 0;   /* total ops */
 #define OP_PUNCH_HOLE  6
 #define OP_ZERO_RANGE  7
 #define OP_COLLAPSE_RANGE  8
-#define OP_MAX_FULL9
+#define OP_INSERT_RANGE9
+#define OP_MAX_FULL10
 
 /* operation modifiers */
 #define OP_CLOSEOPEN   100
@@ -145,6 +146,7 @@ int fallocate_calls = 1;/* -F flag disables 
*/
 int punch_hole_calls = 1;   /* -H flag disables */
 int zero_range_calls = 1;   /* -z flag disables */
 intcollapse_range_calls = 1;   /* -C flag disables */
+intinsert_range_calls = 1; /* -i flag disables */
 intmapped_reads = 1;   /* -R flag disables it */
 intfsxgoodfd = 0;
 into_direct;   /* -Z */
@@ -339,6 +341,14 @@ logdump(void)
 lp->args[0] + lp->args[1])
prt("\t**");
break;
+   case OP_INSERT_RANGE:
+   prt("INSERT 0x%x thru 0x%x\t(0x%x bytes)",
+   lp->args[0], lp->args[0] + lp->args[1] - 1,
+   lp->args[1]);
+   if (badoff >= lp->args[0] && badoff <
+lp->args[0] + lp->args[1])
+   prt("\t**");
+   break;
case OP_SKIPPED:
prt("SKIPPED (no operation)");
break;
@@ -1012,6 +1022,59 @@ do_collapse_range(unsigned offset, unsigned length)
 }
 #endif
 
+#ifdef FALLOC_FL_INSERT_RANGE
+void
+do_insert_range(unsigned offset, unsigned length)
+{
+   unsigned end_offset;
+   int mode = FALLOC_FL_INSERT_RANGE;
+
+   if (length == 0) {
+   if (!quiet && testcalls > simulatedopcount)
+   prt("skipping zero length insert range\n");
+   log4(OP_SKIPPED, OP_INSERT_RANGE, offset, length);
+   return;
+   }
+
+   if ((loff_t)offset >= file_size) {
+   if (!quiet && testcalls > simulatedopcount)
+   prt("skipping insert range behind EOF\n");
+   log4(OP_SKIPPED, OP_INSERT_RANGE, offset, length);
+   return;
+   }
+
+   log4(OP_INSERT_RANGE, offset, length, 0);
+
+   if (testcalls <= simulatedopcount)
+   return;
+
+   end_offset = offset + length;
+   if ((progressinterval && testcalls % progressinterval == 0) ||
+   (debug && (monitorstart == -1 || monitorend == -1 ||
+ end_offset <= monitorend))) {
+   prt("%lu insert\tfrom 0x%x to 0x%x, (0x%x bytes)\n", testcalls,
+   offset, offset+length, length);
+   }
+   if (fallocate(fd, mode, (loff_t)offset, (loff_t)length) == -1) {
+   prt("insert range: %x to %x\n", offset, length);
+   prterr("do_insert_range: fallocate");
+   report_failure(161);
+   }
+
+   memmove(good_buf + end_offset, good_buf + offset,
+   file_size - offset);
+   memset(good_buf + offset, '\0', length);
+   file_size += length;
+}
+
+#else
+void
+do_insert_range(unsigned offset, unsigned length)
+{
+   return;
+}
+#endif
+
 #ifdef HAVE_LINUX_FALLOC_H
 /* fallocate is basically a no-op unless extending, then a lot like a truncate 
*/
 void
@@ -1192,6 +1255,12 @@ test(void)
goto out;
}
break;
+   case OP_INSERT_RANGE:
+   if (!insert_range_calls) {
+   log4(OP_SKIPPED, OP_INSERT_RANGE, offset, size);
+   goto out;
+   }
+   break;
}
 
switch (op) {
@@ -1244,6 +1313,21 @@ test(void)
}
do_collapse_range(offset, size);
break;
+   case OP_INSERT_RANGE:
+   TRIM_OFF_LEN(offset, size, (maxfilelen - 1) - file_size);
+   offset = offset & ~(block_size - 1);
+   size = size & ~(block_size - 1);
+   if (size == 0) {
+   log4(OP_SKIPPED, OP_INSERT_RANGE, offset, size);
+   goto out;
+   }
+   if (file_size + size > maxfilelen) {
+   log4(OP_SKIPPED, OP_INSERT_RANGE, offset, size);
+   goto out;
+   }
+
+   do_insert_range(offset, size);
+   break;
default:
prterr("test: unknown 

[PATCH v6 6/10] xfstests: generic/039: Delayed allocation insert range

[Namjae Jeon]

This testcase(039) tries to test various corner cases with delayed extents
for finsert range functionality over different type of extents.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 tests/generic/039 | 65 ++
 tests/generic/039.out | 78 +++
 tests/generic/group   |  1 +
 3 files changed, 144 insertions(+)
 create mode 100644 tests/generic/039
 create mode 100644 tests/generic/039.out

diff --git a/tests/generic/039 b/tests/generic/039
new file mode 100644
index 000..3421f93
--- /dev/null
+++ b/tests/generic/039
@@ -0,0 +1,65 @@
+#! /bin/bash
+# FS QA Test No. generic/039
+#
+# Delayed allocation insert range tests
+# This testcase is one of the 4 testcases which tries to
+# test various corner cases for finsert range functionality over different
+# type of extents. These tests are based on generic/255 test case.
+# For the type of tests, check the description of _test_generic_punch
+# in common/rc.
+#---
+# Copyright (c) 2013 Samsung Electronics.  All Rights Reserved.
+#
+# 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.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1   # failure is the default!
+
+_cleanup()
+{
+rm -f $tmp.*
+}
+
+trap "_cleanup ; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+# we need to include common/punch to get defination fo filter functions
+. ./common/rc
+. ./common/filter
+. ./common/punch
+
+# real QA test starts here
+_supported_fs generic
+_supported_os Linux
+
+_require_xfs_io_command "fpunch"
+_require_xfs_io_command "falloc"
+_require_xfs_io_command "fiemap"
+_require_xfs_io_command "finsert"
+
+testfile=$TEST_DIR/$seq.$$
+
+_test_generic_punch -d falloc fpunch finsert fiemap _filter_hole_fiemap 
$testfile
+_check_test_fs
+
+status=0
+exit
diff --git a/tests/generic/039.out b/tests/generic/039.out
new file mode 100644
index 000..d1e8320
--- /dev/null
+++ b/tests/generic/039.out
@@ -0,0 +1,78 @@
+QA output created by 039
+   1. into a hole
+cf845a781c107ec1346e849c9dd1b7e8
+   2. into allocated space
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..55]: extent
+64e72217eebcbdf31b1b058f9f5f476a
+   3. into unwritten space
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..55]: extent
+cf845a781c107ec1346e849c9dd1b7e8
+   4. hole -> data
+0: [0..31]: hole
+1: [32..47]: extent
+2: [48..55]: hole
+adb08a6d94a3b5eff90fdfebb2366d31
+   5. hole -> unwritten
+0: [0..31]: hole
+1: [32..47]: extent
+2: [48..55]: hole
+cf845a781c107ec1346e849c9dd1b7e8
+   6. data -> hole
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..31]: extent
+3: [32..55]: hole
+be0f35d4292a20040766d87883b0abd1
+   7. data -> unwritten
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..47]: extent
+3: [48..55]: hole
+be0f35d4292a20040766d87883b0abd1
+   8. unwritten -> hole
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..31]: extent
+3: [32..55]: hole
+cf845a781c107ec1346e849c9dd1b7e8
+   9. unwritten -> data
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..47]: extent
+3: [48..55]: hole
+adb08a6d94a3b5eff90fdfebb2366d31
+   10. hole -> data -> hole
+0: [0..39]: hole
+1: [40..47]: extent
+2: [48..63]: hole
+0487b3c52810f994c541aa166215375f
+   11. data -> hole -> data
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..39]: extent
+3: [40..47]: hole
+4: [48..63]: extent
+e3a8d52acc4d91a8ed19d7b6f4f26a71
+   12. unwritten -> data -> unwritten
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..63]: extent
+0487b3c52810f994c541aa166215375f
+   13. data -> unwritten -> data
+0: [0..7]: extent
+1: [8..31]: hole
+2: [32..63]: extent
+2b22165f4a24a2c36fd05ef00b41df88
+   14. data -> hole @ EOF
+0: [0..23]: extent
+1: [24..39]: hole
+2: [40..55]: extent
+aa0f20d1edcdbce60d8ef82700ba30c3
+   15. data -> hole @ 0
+0: [0..15]: hole
+1: [16..55]: extent
+86c9d033be2761385c9cfa203c426bb2
diff --git a/tests/generic/group b/tests/generic/group
index 7d6f227..4beb27f 100644
--- a/tests/generic/group
+++ b/tests/generic/group
@@ -41,6 +41,7 @@
 036 auto aio rw stress
 037 metadata auto quick
 038 auto quick prealloc
+039 auto quick prealloc
 053 acl repair 

[PATCH v6 5/10] xfstests: generic/038: Standard insert range tests

[Namjae Jeon]

This testcase(038) tries to test various corner cases for finsert range
functionality over different type of extents.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 common/punch  |  5 
 common/rc |  2 +-
 tests/generic/038 | 65 ++
 tests/generic/038.out | 78 +++
 tests/generic/group   |  1 +
 5 files changed, 150 insertions(+), 1 deletion(-)
 create mode 100644 tests/generic/038
 create mode 100644 tests/generic/038.out

diff --git a/common/punch b/common/punch
index 237b4d8..a75f4cf 100644
--- a/common/punch
+++ b/common/punch
@@ -527,6 +527,11 @@ _test_generic_punch()
return
fi
 
+   # If zero_cmd is finsert, don't check unaligned offsets
+   if [ "$zero_cmd" == "finsert" ]; then
+   return
+   fi
+
echo "  16. data -> cache cold ->hole"
if [ "$remove_testfile" ]; then
rm -f $testfile
diff --git a/common/rc b/common/rc
index d5e3aff..ca4177f 100644
--- a/common/rc
+++ b/common/rc
@@ -1486,7 +1486,7 @@ _require_xfs_io_command()
"falloc" )
testio=`$XFS_IO_PROG -F -f -c "falloc 0 1m" $testfile 2>&1`
;;
-   "fpunch" | "fcollapse" | "zero" | "fzero" )
+   "fpunch" | "fcollapse" | "zero" | "fzero" | "finsert" )
testio=`$XFS_IO_PROG -F -f -c "pwrite 0 20k" -c "fsync" \
-c "$command 4k 8k" $testfile 2>&1`
;;
diff --git a/tests/generic/038 b/tests/generic/038
new file mode 100644
index 000..0ce0e61
--- /dev/null
+++ b/tests/generic/038
@@ -0,0 +1,65 @@
+#! /bin/bash
+# FS QA Test No. generic/038
+#
+# Standard insert range tests
+# This testcase is one of the 4 testcases which tries to
+# test various corner cases for finsert range functionality over different
+# type of extents. These tests are based on generic/255 test case.
+# For the type of tests, check the description of _test_generic_punch
+# in common/rc.
+#---
+# Copyright (c) 2013 Samsung Electronics.  All Rights Reserved.
+#
+# 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.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1   # failure is the default!
+
+_cleanup()
+{
+rm -f $tmp.*
+}
+
+trap "_cleanup ; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+# we need to include common/punch to get defination fo filter functions
+. ./common/rc
+. ./common/filter
+. ./common/punch
+
+# real QA test starts here
+_supported_fs generic
+_supported_os Linux
+
+_require_xfs_io_command "fpunch"
+_require_xfs_io_command "falloc"
+_require_xfs_io_command "fiemap"
+_require_xfs_io_command "finsert"
+
+testfile=$TEST_DIR/$seq.$$
+
+_test_generic_punch falloc fpunch finsert fiemap _filter_hole_fiemap $testfile
+_check_test_fs
+
+status=0
+exit
diff --git a/tests/generic/038.out b/tests/generic/038.out
new file mode 100644
index 000..3ebdb43
--- /dev/null
+++ b/tests/generic/038.out
@@ -0,0 +1,78 @@
+QA output created by 038
+   1. into a hole
+cf845a781c107ec1346e849c9dd1b7e8
+   2. into allocated space
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..55]: extent
+64e72217eebcbdf31b1b058f9f5f476a
+   3. into unwritten space
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..55]: extent
+cf845a781c107ec1346e849c9dd1b7e8
+   4. hole -> data
+0: [0..31]: hole
+1: [32..47]: extent
+2: [48..55]: hole
+adb08a6d94a3b5eff90fdfebb2366d31
+   5. hole -> unwritten
+0: [0..31]: hole
+1: [32..47]: extent
+2: [48..55]: hole
+cf845a781c107ec1346e849c9dd1b7e8
+   6. data -> hole
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..31]: extent
+3: [32..55]: hole
+be0f35d4292a20040766d87883b0abd1
+   7. data -> unwritten
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..47]: extent
+3: [48..55]: hole
+be0f35d4292a20040766d87883b0abd1
+   8. unwritten -> hole
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..31]: extent
+3: [32..55]: hole
+cf845a781c107ec1346e849c9dd1b7e8
+   9. unwritten -> data
+0: [0..7]: extent
+1: [8..23]: hole
+2: [24..47]: extent
+3: [48..55]: hole
+adb08a6d94a3b5eff90fdfebb2366d31
+   10. hole -> data -> 

[PATCH v6 1/10] fs: Add support FALLOC_FL_INSERT_RANGE for fallocate

[Namjae Jeon]

FALLOC_FL_INSERT_RANGE command is the opposite command of
FALLOC_FL_COLLAPSE_RANGE that is needed for advertisers or someone who want to
add some data in the middle of file. FALLOC_FL_INSERT_RANGE will create space
for writing new data within a file after shifting extents to right as given
length. and this command also has same limitation as FALLOC_FL_COLLAPSE_RANGE,
that is block boundary and use ftruncate(2) for crosses EOF.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 fs/open.c   |  8 +++-
 include/uapi/linux/falloc.h | 15 +++
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/fs/open.c b/fs/open.c
index 36662d0..74ed498 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -232,7 +232,8 @@ int do_fallocate(struct file *file, int mode, loff_t 
offset, loff_t len)
 
/* Return error if mode is not supported */
if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
-FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE))
+FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE |
+FALLOC_FL_INSERT_RANGE))
return -EOPNOTSUPP;
 
/* Punch hole and zero range are mutually exclusive */
@@ -250,6 +251,11 @@ int do_fallocate(struct file *file, int mode, loff_t 
offset, loff_t len)
(mode & ~FALLOC_FL_COLLAPSE_RANGE))
return -EINVAL;
 
+   /* Insert range should only be used exclusively. */
+   if ((mode & FALLOC_FL_INSERT_RANGE) &&
+   (mode & ~FALLOC_FL_INSERT_RANGE))
+   return -EINVAL;
+
if (!(file->f_mode & FMODE_WRITE))
return -EBADF;
 
diff --git a/include/uapi/linux/falloc.h b/include/uapi/linux/falloc.h
index d1197ae..1f20723 100644
--- a/include/uapi/linux/falloc.h
+++ b/include/uapi/linux/falloc.h
@@ -41,4 +41,19 @@
  */
 #define FALLOC_FL_ZERO_RANGE   0x10
 
+/*
+ * FALLOC_FL_INSERT_RANGE is use to insert space within the file size without
+ * overwriting any existing data. The contents of the file beyond offset are
+ * shifted towards right by len bytes to create a hole.  As such, this
+ * operation will increase the size of the file by len bytes.
+ * Different filesystems may implement different limitations on the granularity
+ * of the operation. Most will limit operations to filesystem block size
+ * boundaries, but this boundary may be larger or smaller depending on
+ * the filesystem and/or the configuration of the filesystem or file.
+ * Attempting to insert space using this flag at OR beyond the end of
+ * the file is considered an illegal operation - just use ftruncate(2) or
+ * fallocate(2) with mode 0 for such type of operations.
+ */
+#define FALLOC_FL_INSERT_RANGE 0x20
+
 #endif /* _UAPI_FALLOC_H_ */
-- 
1.7.11-rc0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 0/10] fs: Introduce FALLOC_FL_INSERT_RANGE for fallocate

[Namjae Jeon]

In continuation of the work of making the process of non linear editing of
media files faster, we introduce here the new flag FALLOC_FL_INSERT_RANGE
for fallocate.

This flag will work opposite to the FALLOC_FL_COLLAPSE_RANGE flag.
As such, specifying FALLOC_FL_INSERT_RANGE flag will create new space inside 
file
by inserting a hole within the range specified by offset and len. 
User can write new data in this space. e.g. ads.
Like collapse range, currently we have the limitation that offset and len should
be block size aligned for both XFS and Ext4.

The semantics of the flag are :
1) It creates space within file by inserting a hole of  len bytes starting
   at offset byte without overwriting any existing data. All the data blocks
   from offset to EOF are shifted towards right to make hole space.
2) It should be used exclusively. No other fallocate flag in combination.
3) Offset and length supplied to fallocate should be fs block size aligned
   in case of xfs and ext4.
4) Insert range does not work for the case when offset is overlapping/beyond
   i_size. If the user wants to insert space at the end of file they are
   advised to use either ftruncate(2) or fallocate(2) with mode 0.
5) It increses the size of file by len bytes.


Namjae Jeon (10):
 fs: Add support FALLOC_FL_INSERT_RANGE for fallocate
 xfs: Add support FALLOC_FL_INSERT_RANGE for fallocate
 ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate
 xfsprogs: xfs_io: add finsert command for insert range via fallocate
 xfstests: generic/038: Standard insert range tests
 xfstests: generic/039: Delayed allocation insert range
 xfstests: generic/040: Multi insert range tests
 xfstests: generic/041: Delayed allocation multi insert
 xfstests: fsstress: Add fallocate insert range operation
 xfstests: fsx: Add fallocate insert range operation

-- 
1.7.11-rc0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 3/10] ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate

[Namjae Jeon]

This patch implements fallocate's FALLOC_FL_INSERT_RANGE for Ext4.

1) Make sure that both offset and len are block size aligned.
2) Update the i_size of inode by len bytes.
3) Compute the file's logical block number against offset. If the computed
   block number is not the starting block of the extent, split the extent
   such that the block number is the starting block of the extent.
4) Shift all the extents which are lying bewteen [offset, last allocated extent]
   towards right by len bytes. This step will make a hole of len bytes
   at offset.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
Changelog

v6:
 - Instead of having seperate functions for shifting extents left/right, the
   current extent shift function is made generic to shift in both directions.

v5:
 - remove allocation part.

 fs/ext4/ext4.h  |   6 +
 fs/ext4/extents.c   | 302 
 include/trace/events/ext4.h |  25 
 3 files changed, 282 insertions(+), 51 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index db3f772..0cf212a 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -90,6 +90,11 @@ typedef __u32 ext4_lblk_t;
 /* data type for block group number */
 typedef unsigned int ext4_group_t;
 
+enum SHIFT_DIRECTION {
+   SHIFT_LEFT = 0,
+   SHIFT_RIGHT,
+};
+
 /*
  * Flags used in mballoc's allocation_context flags field.
  *
@@ -2760,6 +2765,7 @@ extern int ext4_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
__u64 start, __u64 len);
 extern int ext4_ext_precache(struct inode *inode);
 extern int ext4_collapse_range(struct inode *inode, loff_t offset, loff_t len);
+extern int ext4_insert_range(struct inode *inode, loff_t offset, loff_t len);
 extern int ext4_swap_extents(handle_t *handle, struct inode *inode1,
struct inode *inode2, ext4_lblk_t lblk1,
 ext4_lblk_t lblk2,  ext4_lblk_t count,
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 0b16fb4..0baebc5 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4913,7 +4913,8 @@ long ext4_fallocate(struct file *file, int mode, loff_t 
offset, loff_t len)
 
/* Return error if mode is not supported */
if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
-FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE))
+FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE |
+FALLOC_FL_INSERT_RANGE))
return -EOPNOTSUPP;
 
if (mode & FALLOC_FL_PUNCH_HOLE)
@@ -4933,6 +4934,9 @@ long ext4_fallocate(struct file *file, int mode, loff_t 
offset, loff_t len)
if (mode & FALLOC_FL_COLLAPSE_RANGE)
return ext4_collapse_range(inode, offset, len);
 
+   if (mode & FALLOC_FL_INSERT_RANGE)
+   return ext4_insert_range(inode, offset, len);
+
if (mode & FALLOC_FL_ZERO_RANGE)
return ext4_zero_range(file, offset, len, mode);
 
@@ -5219,13 +5223,13 @@ ext4_access_path(handle_t *handle, struct inode *inode,
 /*
  * ext4_ext_shift_path_extents:
  * Shift the extents of a path structure lying between path[depth].p_ext
- * and EXT_LAST_EXTENT(path[depth].p_hdr) downwards, by subtracting shift
- * from starting block for each extent.
+ * and EXT_LAST_EXTENT(path[depth].p_hdr), by @shift blocks. @SHIFT tells
+ * if it is right shift or left shift operation.
  */
 static int
 ext4_ext_shift_path_extents(struct ext4_ext_path *path, ext4_lblk_t shift,
struct inode *inode, handle_t *handle,
-   ext4_lblk_t *start)
+   enum SHIFT_DIRECTION SHIFT)
 {
int depth, err = 0;
struct ext4_extent *ex_start, *ex_last;
@@ -5249,19 +5253,25 @@ ext4_ext_shift_path_extents(struct ext4_ext_path *path, 
ext4_lblk_t shift,
if (ex_start == EXT_FIRST_EXTENT(path[depth].p_hdr))
update = 1;
 
-   *start = le32_to_cpu(ex_last->ee_block) +
-   ext4_ext_get_actual_len(ex_last);
-
while (ex_start <= ex_last) {
-   le32_add_cpu(_start->ee_block, -shift);
-   /* Try to merge to the left. */
-   if ((ex_start >
-EXT_FIRST_EXTENT(path[depth].p_hdr)) &&
-   ext4_ext_try_to_merge_right(inode,
-   path, ex_start - 1))
+   if (SHIFT == SHIFT_LEFT) {
+   le32_add_cpu(_start->ee_block,
+   -shift);
+   /* Try to merge to the left. */
+   if ((ex_start >
+   

[PATCH 2/2] staging: lustre: lnet: lnet: trailing statements should be on next line

[Balavasu kuppusammyprathaban]

This patch fixes the checkpatch.pl issue
Error: trailing statements should be on next line

Signed-off-by: Balavasu kuppusammyprathaban
---
 drivers/staging/lustre/lnet/lnet/router.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/router.c 
b/drivers/staging/lustre/lnet/lnet/router.c
index cdeb246..0f569a0 100644
--- a/drivers/staging/lustre/lnet/lnet/router.c
+++ b/drivers/staging/lustre/lnet/lnet/router.c
@@ -1670,13 +1670,16 @@ lnet_get_tunables (void)
char *s;
 
s = getenv("LNET_ROUTER_PING_TIMEOUT");
-   if (s != NULL) router_ping_timeout = atoi(s);
+   if (s != NULL)
+   router_ping_timeout = atoi(s);
 
s = getenv("LNET_LIVE_ROUTER_CHECK_INTERVAL");
-   if (s != NULL) live_router_check_interval = atoi(s);
+   if (s != NULL)
+   live_router_check_interval = atoi(s);
 
s = getenv("LNET_DEAD_ROUTER_CHECK_INTERVAL");
-   if (s != NULL) dead_router_check_interval = atoi(s);
+   if (s != NULL)
+   dead_router_check_interval = atoi(s);
 
/* This replaces old lnd_notify mechanism */
check_routers_before_use = 1;
-- 
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: [f2fs-dev] [PATCH 1/3] f2fs: call flush_dcache_page when the page was updated

[Jaegeuk Kim]

On Mon, Nov 24, 2014 at 11:46:46AM +0900, Changman Lee wrote:
> Hi Simon,
> Thanks for your explanation kindly.
> 
> On Sun, Nov 23, 2014 at 11:08:54AM +0100, Simon Baatz wrote:
> > Hi Changman, Jaegeuk,
> > 
> > On Thu, Nov 20, 2014 at 05:47:29PM +0900, Changman Lee wrote:
> > > On Wed, Nov 19, 2014 at 10:45:33PM -0800, Jaegeuk Kim wrote:
> > > > On Thu, Nov 20, 2014 at 03:04:10PM +0900, Changman Lee wrote:
> > > > > Hi Jaegeuk,
> > > > > 
> > > > > We should call flush_dcache_page before kunmap because the purpose of 
> > > > > the cache flush is to address aliasing problem related to virtual 
> > > > > address.
> > > > 
> > > > Oh, I just followed zero_user_segments below.
> > > > 
> > > > static inline void zero_user_segments(struct page *page,
> > > > unsigned start1, unsigned end1,
> > > > unsigned start2, unsigned end2)
> > > > {
> > > > void *kaddr = kmap_atomic(page);
> > > > 
> > > > BUG_ON(end1 > PAGE_SIZE || end2 > PAGE_SIZE);
> > > > 
> > > > if (end1 > start1)
> > > > memset(kaddr + start1, 0, end1 - start1);
> > > > 
> > > > if (end2 > start2)
> > > > memset(kaddr + start2, 0, end2 - start2);
> > > > 
> > > > kunmap_atomic(kaddr);
> > > > flush_dcache_page(page);
> > > > }
> > > > 
> > > > Is this a wrong reference? Or, a bug?
> > > > 
> > > 
> > > Well.. Data in cache only have to be flushed until before other users 
> > > read the data.
> > > If so, it's not a bug.
> > > 
> > 
> > Yes, it is not a bug, since flush_dcache_page() needs to be able to
> > deal with non-kmapped pages. However, this may create overhead in
> > some situations.
> > 
> 
> Previously, I was vague but I thought that it should be different
> according to vaddr exists or not. So I told jaegeuk that it should
> be better to change an order between flush_dache_page and kunmap.
> But actually, it doesn't matter the order between them except
> the situation you said.
> Could you explain the situation that makes overhead by flushing after kummap.
> I can't imagine it by just seeing flush_dcache_page code.
> 
> > According to documentation (see Documentation/cachetlb.txt), this is
> > a use for flush_kernel_dcache_page(), since the page has been
> > modified by the kernel only.  In contrast to flush_dcache_page(),
> > this function must be called before kunmap().
> > 
> > flush_kernel_dcache_page() does not need to flush the user space
> > aliases.  Additionally, at least on ARM, it does not flush at all
> > when called within kmap_atomic()/kunmap_atomic(), when
> > kunmap_atomic() is going to flush the page anyway.  (I know that
> > almost no one uses flush_kernel_dcache_page() (probably because
> > almost no one knows when to use which of the two functions), but it
> > may save a few cache flushes on architectures which are affected by
> > aliasing)
> > 
> > 
> > > > Anyway I modified as below.
> > > > 
> > > > Thanks,
> > > > 
> > > > >From 7cb7b27c8cd2efc8a31d79239bef5b41c6e79216 Mon Sep 17 00:00:00 2001
> > > > From: Jaegeuk Kim 
> > > > Date: Tue, 18 Nov 2014 10:50:21 -0800
> > > > Subject: [PATCH] f2fs: call flush_dcache_page when the page was updated
> > > > 
> > > > Whenever f2fs updates mapped pages, it needs to call flush_dcache_page.
> > > > 
> > > > Signed-off-by: Jaegeuk Kim 
> > > > ---
> > > >  fs/f2fs/dir.c| 7 ++-
> > > >  fs/f2fs/inline.c | 2 ++
> > > >  2 files changed, 8 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > > > index 5a49995..fabf4ee 100644
> > > > --- a/fs/f2fs/dir.c
> > > > +++ b/fs/f2fs/dir.c
> > > > @@ -287,8 +287,10 @@ void f2fs_set_link(struct inode *dir, struct 
> > > > f2fs_dir_entry *de,
> > > > f2fs_wait_on_page_writeback(page, type);
> > > > de->ino = cpu_to_le32(inode->i_ino);
> > > > set_de_type(de, inode);
> > > > -   if (!f2fs_has_inline_dentry(dir))
> > > > +   if (!f2fs_has_inline_dentry(dir)) {
> > > > +   flush_dcache_page(page);
> > > > kunmap(page);
> > > > +   }
> > 
> > Is this a page that may be mapped into user space? (I may be
> > completely wrong here, since I have no idea how this code works.  But
> > it looks like as if the answer is "no" ;-) ).
> > 
> > It is not necessary to flush pages that cannot be seen by user space
> > (see also the NOTE in the documentation of flush_dcache_page() in
> > cachetlb.txt). Thus, if you know that a page will not be mapped into
> > user space, please don't create the overhead of flushing it.
> > 
> 
> In the case of dentry unlike inline data, this is not mapped to user space, 
> so dcache flush
> makes overhead. Do you mean that?
> 
> Best regard,
> Changman

Hi Changman,

This would be ok though.

>From 5c1c46d31452a59a37c96f6dcae600776a8002e3 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Tue, 18 Nov 2014 10:50:21 -0800
Subject: [PATCH v2] f2fs: call flush_dcache_page when the page was updated

Change log from v1:
 o 

[PATCH 1/2] staging: lustre: lnet: lnet: do not initialise statics to 0 or NULL

[Balavasu kuppusammyprathaban]

This patch fixes the checkpatch.pl issue
Error: do not initialise statics to 0 or NULL 

Signed-off-by: Balavasu kuppusammyprathaban
---
 drivers/staging/lustre/lnet/lnet/router.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/router.c 
b/drivers/staging/lustre/lnet/lnet/router.c
index b5b8fb5..cdeb246 100644
--- a/drivers/staging/lustre/lnet/lnet/router.c
+++ b/drivers/staging/lustre/lnet/lnet/router.c
@@ -46,7 +46,7 @@ MODULE_PARM_DESC(small_router_buffers, "# of small (1 page) 
messages to buffer i
 static int large_router_buffers;
 module_param(large_router_buffers, int, 0444);
 MODULE_PARM_DESC(large_router_buffers, "# of large messages to buffer in the 
router");
-static int peer_buffer_credits = 0;
+static int peer_buffer_credits;
 module_param(peer_buffer_credits, int, 0444);
 MODULE_PARM_DESC(peer_buffer_credits, "# router buffer credits per peer");
 
@@ -80,7 +80,7 @@ lnet_peer_buffer_credits(lnet_ni_t *ni)
 
 #endif
 
-static int check_routers_before_use = 0;
+static int check_routers_before_use;
 module_param(check_routers_before_use, int, 0444);
 MODULE_PARM_DESC(check_routers_before_use, "Assume routers are down and ping 
them before use");
 
@@ -245,7 +245,7 @@ lnet_find_net_locked (__u32 net)
 
 static void lnet_shuffle_seed(void)
 {
-   static int seeded = 0;
+   static int seeded;
int lnd_type, seed[2];
struct timeval tv;
lnet_ni_t *ni;
@@ -1584,8 +1584,8 @@ lnet_notify (lnet_ni_t *ni, lnet_nid_t nid, int alive, 
unsigned long when)
 void
 lnet_router_checker (void)
 {
-   static time_t last = 0;
-   static intrunning = 0;
+   static time_t last;
+   static intrunning;
 
time_t  now = get_seconds();
intinterval = now - last;
-- 
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 v3 3/3] ACPI / PMIC: AXP288: support virtual GPIO in ACPI table

[Aaron Lu]

On 11/24/2014 09:06 AM, Rafael J. Wysocki wrote:
> On Friday, November 21, 2014 03:11:51 PM Aaron Lu wrote:
>> The same virtual GPIO strategy is also used for the AXP288 PMIC in that
>> various control methods that are used to do power rail handling and
>> sensor reading/setting will touch GPIO fields defined under the PMIC
>> device. The GPIO fileds are only defined by the ACPI code while the
>> actual hardware doesn't really have a GPIO controller, but to make those
>> control method execution succeed, we have to install a GPIO handler for
>> the PMIC device handle. Since we do not need the virtual GPIO strategy,
>> we can simply do nothing in that handler.
>>
>> Signed-off-by: Aaron Lu 
>> ---
>>  drivers/acpi/pmic/intel_pmic_xpower.c | 27 +++
>>  1 file changed, 23 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/acpi/pmic/intel_pmic_xpower.c 
>> b/drivers/acpi/pmic/intel_pmic_xpower.c
>> index 6c4d6ce0cff1..480c41c36444 100644
>> --- a/drivers/acpi/pmic/intel_pmic_xpower.c
>> +++ b/drivers/acpi/pmic/intel_pmic_xpower.c
>> @@ -251,13 +251,32 @@ static struct intel_pmic_opregion_data 
>> intel_xpower_pmic_opregion_data = {
>>  .thermal_table_count = ARRAY_SIZE(thermal_table),
>>  };
>>  
>> +static acpi_status intel_xpower_pmic_gpio_handler(u32 function,
>> +acpi_physical_address address, u32 bit_width, u64 *value,
>> +void *handler_context, void *region_context)
>> +{
>> +return AE_OK;
>> +}
>>  
>>  static int intel_xpower_pmic_opregion_probe(struct platform_device *pdev)
>>  {
>> -struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
>> -return intel_pmic_install_opregion_handler(>dev,
>> -ACPI_HANDLE(pdev->dev.parent), axp20x->regmap,
>> -_xpower_pmic_opregion_data);
>> +struct device *parent = pdev->dev.parent;
>> +struct axp20x_dev *axp20x = dev_get_drvdata(parent);
>> +acpi_status status;
>> +int result;
>> +
>> +result = intel_pmic_install_opregion_handler(>dev,
>> +ACPI_HANDLE(parent), axp20x->regmap,
>> +_xpower_pmic_opregion_data);
>> +if (!result) {
>> +status = acpi_install_address_space_handler(
>> +ACPI_HANDLE(parent), ACPI_ADR_SPACE_GPIO,
>> +intel_xpower_pmic_gpio_handler, NULL, NULL);
> 
> So here we have a problem, because we can't unregister the opregion handler
> registered above if this fails.  Not nice.

I'll add a remove_opregion_handler call if the above install failed, the
chance the remove_opregion_handler will trigger a problem during init time
is pretty low.

If that is not desired, I can install the operation region handler for
the virtual GPIO first and then the real PMIC operation region handler,
the cost of leaving a virtual GPIO operation region handler is essential
zero I think.

Thanks,
Aaron

> 
>> +if (ACPI_FAILURE(status))
>> +result = -ENODEV;
>> +}
>> +
>> +return result;
>>  }
>>  
>>  static struct platform_driver intel_xpower_pmic_opregion_driver = {
>>
> 

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

[PATCH v2 1/2] arm: ls1: add CPU hotplug platform support

[Zhuoyu Zhang]

From: Zhang Zhuoyu 

This implements CPU hotplug for ls1. When cpu is down, it will be put
in WFI state. When cpu is up, it will always soft reset and boots up
the same path as a cold boot.

Signed-off-by: Zhang Zhuoyu 
---
 arch/arm/mach-imx/common.h  |   4 ++
 arch/arm/mach-imx/hotplug.c |  25 +
 arch/arm/mach-imx/platsmp.c | 132 +++-
 arch/arm/mach-imx/src.c |  21 +++
 4 files changed, 169 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 59ce8f3..f7d2be5 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -92,6 +92,7 @@ void imx_print_silicon_rev(const char *cpu, int srev);
 void imx_enable_cpu(int cpu, bool enable);
 void imx_set_cpu_jump(int cpu, void *jump_addr);
 u32 imx_get_cpu_arg(int cpu);
+u32 ls1_get_cpu_arg(int cpu);
 void imx_set_cpu_arg(int cpu, u32 arg);
 #ifdef CONFIG_SMP
 void v7_secondary_startup(void);
@@ -134,6 +135,9 @@ void imx6sl_pm_init(void);
 void imx6sx_pm_init(void);
 void imx6q_pm_set_ccm_base(void __iomem *base);
 
+extern void ls1021a_cpu_die(unsigned int cpu);
+extern int ls1021a_cpu_kill(unsigned int cpu);
+
 #ifdef CONFIG_PM
 void imx51_pm_init(void);
 void imx53_pm_init(void);
diff --git a/arch/arm/mach-imx/hotplug.c b/arch/arm/mach-imx/hotplug.c
index b35e99c..2ee5e46 100644
--- a/arch/arm/mach-imx/hotplug.c
+++ b/arch/arm/mach-imx/hotplug.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "common.h"
 
@@ -68,3 +69,27 @@ int imx_cpu_kill(unsigned int cpu)
imx_set_cpu_arg(cpu, 0);
return 1;
 }
+
+/*
+ * For LS102x platforms, shutdowning a CPU is not supported by hardware.
+ * So we just put the offline CPU into lower-power state here.
+ */
+void __ref ls1021a_cpu_die(unsigned int cpu)
+{
+   v7_exit_coherency_flush(louis);
+
+   /* LS1021a platform can't really power down a CPU, so we
+* just put it into WFI state here.
+*/
+   wfi();
+}
+
+int ls1021a_cpu_kill(unsigned int cpu)
+{
+   unsigned long timeout = jiffies + msecs_to_jiffies(50);
+
+   while (!ls1_get_cpu_arg(cpu))
+   if (time_after(jiffies, timeout))
+   return 0;
+   return 1;
+}
diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 7f27001..7735ebb 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -23,8 +24,24 @@
 #include "common.h"
 #include "hardware.h"
 
+#defineSCFG_CORE0_SFT_RST  0x130
+#defineSCFG_REVCR  0x200
+#defineSCFG_CORESRENCR 0x204
+#defineSCFG_SPARECR4   0x50C
+
+#defineDCFG_CCSR_BRR   0x0E4
+#defineDCFG_CCSR_SCRATCHRW10x200
+
+#defineDCSR_RCPM2_DEBUG1   0x400
+#defineDCSR_RCPM2_DEBUG2   0x414
+
+#defineSTRIDE_4B   4
+
 u32 g_diag_reg;
 static void __iomem *scu_base;
+static void __iomem *dcfg_base;
+static void __iomem *scfg_base;
+static u32 secondary_pre_boot_entry;
 
 static struct map_desc scu_io_desc __initdata = {
/* .virtual and .pfn are run-time assigned */
@@ -98,32 +115,121 @@ struct smp_operations  imx_smp_ops __initdata = {
 #endif
 };
 
-#define DCFG_CCSR_SCRATCHRW1   0x200
-
-static int ls1021a_boot_secondary(unsigned int cpu, struct task_struct *idle)
+static int ls1021a_secondary_iomap(void)
 {
-   arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+   struct device_node *np;
+   int ret;
+
+   np = of_find_compatible_node(NULL, NULL, "fsl,ls1021a-dcfg");
+   if (!np) {
+   pr_err("%s: failed to find dcfg node.\n", __func__);
+   ret = -EINVAL;
+   goto dcfg_err;
+   }
+
+   dcfg_base = of_iomap(np, 0);
+   of_node_put(np);
+   if (!dcfg_base) {
+   pr_err("%s: failed to map dcfg.\n", __func__);
+   ret = -ENOMEM;
+   goto dcfg_err;
+   }
+
+   np = of_find_compatible_node(NULL, NULL, "fsl,ls1021a-scfg");
+   if (!np) {
+   pr_err("%s: failed to find scfg node.\n", __func__);
+   ret = -EINVAL;
+   goto scfg_err;
+   }
+
+   scfg_base = of_iomap(np, 0);
+   of_node_put(np);
+   if (!scfg_base) {
+   pr_err("%s: failed to map scfg.\n", __func__);
+   ret = -ENOMEM;
+   goto scfg_err;
+   }
 
return 0;
+
+scfg_err:
+   iounmap(dcfg_base);
+dcfg_err:
+   return ret;
 }
 
-static void __init ls1021a_smp_prepare_cpus(unsigned int max_cpus)
+void ls1021a_set_secondary_entry(void)
 {
-   struct device_node *np;
-   void __iomem *dcfg_base;
unsigned long paddr;
 
-   np = of_find_compatible_node(NULL, NULL, "fsl,ls1021a-dcfg");
-   dcfg_base = of_iomap(np, 0);
-   BUG_ON(!dcfg_base);
+   

Re: [f2fs-dev] [PATCH 1/3] f2fs: call flush_dcache_page when the page was updated

[Jaegeuk Kim]

On Sun, Nov 23, 2014 at 11:08:54AM +0100, Simon Baatz wrote:
> Hi Changman, Jaegeuk,

Hi Simon,

> 
> On Thu, Nov 20, 2014 at 05:47:29PM +0900, Changman Lee wrote:
> > On Wed, Nov 19, 2014 at 10:45:33PM -0800, Jaegeuk Kim wrote:
> > > On Thu, Nov 20, 2014 at 03:04:10PM +0900, Changman Lee wrote:
> > > > Hi Jaegeuk,
> > > > 
> > > > We should call flush_dcache_page before kunmap because the purpose of 
> > > > the cache flush is to address aliasing problem related to virtual 
> > > > address.
> > > 
> > > Oh, I just followed zero_user_segments below.
> > > 
> > > static inline void zero_user_segments(struct page *page,
> > >   unsigned start1, unsigned end1,
> > >   unsigned start2, unsigned end2)
> > > {
> > >   void *kaddr = kmap_atomic(page);
> > > 
> > >   BUG_ON(end1 > PAGE_SIZE || end2 > PAGE_SIZE);
> > > 
> > >   if (end1 > start1)
> > >   memset(kaddr + start1, 0, end1 - start1);
> > > 
> > >   if (end2 > start2)
> > >   memset(kaddr + start2, 0, end2 - start2);
> > > 
> > >   kunmap_atomic(kaddr);
> > >   flush_dcache_page(page);
> > > }
> > > 
> > > Is this a wrong reference? Or, a bug?
> > > 
> > 
> > Well.. Data in cache only have to be flushed until before other users read 
> > the data.
> > If so, it's not a bug.
> > 
> 
> Yes, it is not a bug, since flush_dcache_page() needs to be able to
> deal with non-kmapped pages. However, this may create overhead in
> some situations.

Ok.

> 
> According to documentation (see Documentation/cachetlb.txt), this is
> a use for flush_kernel_dcache_page(), since the page has been
> modified by the kernel only.  In contrast to flush_dcache_page(),
> this function must be called before kunmap().
> 
> flush_kernel_dcache_page() does not need to flush the user space
> aliases.  Additionally, at least on ARM, it does not flush at all
> when called within kmap_atomic()/kunmap_atomic(), when
> kunmap_atomic() is going to flush the page anyway.  (I know that
> almost no one uses flush_kernel_dcache_page() (probably because
> almost no one knows when to use which of the two functions), but it
> may save a few cache flushes on architectures which are affected by
> aliasing)

Thank you very much for the explanation. :)

> 
> 
> > > Anyway I modified as below.
> > > 
> > > Thanks,
> > > 
> > > >From 7cb7b27c8cd2efc8a31d79239bef5b41c6e79216 Mon Sep 17 00:00:00 2001
> > > From: Jaegeuk Kim 
> > > Date: Tue, 18 Nov 2014 10:50:21 -0800
> > > Subject: [PATCH] f2fs: call flush_dcache_page when the page was updated
> > > 
> > > Whenever f2fs updates mapped pages, it needs to call flush_dcache_page.
> > > 
> > > Signed-off-by: Jaegeuk Kim 
> > > ---
> > >  fs/f2fs/dir.c| 7 ++-
> > >  fs/f2fs/inline.c | 2 ++
> > >  2 files changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > > index 5a49995..fabf4ee 100644
> > > --- a/fs/f2fs/dir.c
> > > +++ b/fs/f2fs/dir.c
> > > @@ -287,8 +287,10 @@ void f2fs_set_link(struct inode *dir, struct 
> > > f2fs_dir_entry *de,
> > >   f2fs_wait_on_page_writeback(page, type);
> > >   de->ino = cpu_to_le32(inode->i_ino);
> > >   set_de_type(de, inode);
> > > - if (!f2fs_has_inline_dentry(dir))
> > > + if (!f2fs_has_inline_dentry(dir)) {
> > > + flush_dcache_page(page);
> > >   kunmap(page);
> > > + }
> 
> Is this a page that may be mapped into user space? (I may be
> completely wrong here, since I have no idea how this code works.  But
> it looks like as if the answer is "no" ;-) ).
> 
> It is not necessary to flush pages that cannot be seen by user space
> (see also the NOTE in the documentation of flush_dcache_page() in
> cachetlb.txt). Thus, if you know that a page will not be mapped into
> user space, please don't create the overhead of flushing it.

Right, users do not modify directory entry pages, so I should remove flushing
them. The only thing that I have to do is our inlined data, which are file-
backed pages likely modified by users.

Thanks,

> 
> 
> - Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: introduce helper macra CMSG_FOREACH_HDR

[David Miller]

Your postings do not make it to the mailing list, in fact they don't
even make it to the list server itself.

Generally speaking, sites in China have this problem off and on, and
in unpredictable ways.

You need to sort this out because I will not apply patches that don't
hit the mailing list for review.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] ACPI / PMIC: support PMIC operation region for CrystalCove

[Aaron Lu]

On 11/24/2014 08:59 AM, Rafael J. Wysocki wrote:
> On Friday, November 21, 2014 03:11:49 PM Aaron Lu wrote:
>> The Baytrail-T platform firmware has defined two customized operation
>> regions for PMIC chip Crystal Cove - one is for power resource handling
>> and one is for thermal: sensor temperature reporting, trip point setting,
>> etc. This patch adds support for them on top of the existing Crystal Cove
>> PMIC driver.
>>
>> The reason to split code into a separate file intel_pmic.c is that there
>> are more PMIC drivers with ACPI operation region support coming and we can
>> re-use those code. The intel_pmic_opregion_data structure is created also
>> for this purpose: when we need to support a new PMIC's operation region,
>> we just need to fill those callbacks and the two register mapping tables.
>>
>> Signed-off-by: Aaron Lu 
>> Acked-by: Lee Jones  for the MFD part
> 
> Thanks for resending, looks better to me.
> 
> Some nitpicking below.

Thaks for taking a look at them, some response below.

> 
>> ---
>>  drivers/acpi/Kconfig   |  17 ++
>>  drivers/acpi/Makefile  |   3 +
>>  drivers/acpi/pmic/intel_pmic.c | 339 
>> +
>>  drivers/acpi/pmic/intel_pmic.h |  34 
>>  drivers/acpi/pmic/intel_pmic_crc.c | 216 +++
>>  drivers/mfd/intel_soc_pmic_crc.c   |   3 +
>>  6 files changed, 612 insertions(+)
>>  create mode 100644 drivers/acpi/pmic/intel_pmic.c
>>  create mode 100644 drivers/acpi/pmic/intel_pmic.h
>>  create mode 100644 drivers/acpi/pmic/intel_pmic_crc.c
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 79078b8f5697..3e5f2056f946 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -393,4 +393,21 @@ config ACPI_EXTLOG
>>driver adds support for that functionality with corresponding
>>tracepoint which carries that information to userspace.
>>  
>> +menuconfig PMIC_OPREGION
>> +bool "PMIC (Power Management Integrated Circuit) operation region 
>> support"
>> +help
>> +  Select this option to enable support for ACPI operation
>> +  region of the PMIC chip. The operation region can be used
>> +  to control power rails and sensor reading/writing on the
>> +  PMIC chip.
>> +
>> +if PMIC_OPREGION
>> +config CRC_PMIC_OPREGION
> 
> If that is the only possible choice for PMIC_OPREGION, it should be selected
> automatically.  Alternatively, PMIC_OPREGION should be selected automatically
> if CRC_PMIC_OPREGION is set.

It is not the only possible choice, currently we have two(see patch 2/3):
CRC_PMIC_OPREGION and XPOWER_PMIC_OPREGION. I would assume this is a
increasing list with more and more PMIC opregion support added. I can
use select for PMIC_OPREGION for all those PMIC operation region drivers,
but it seems easier to use a "if PMIC_OPREGION ... endif" between them.
Please let me know if this is OK?

> 
>> +bool "ACPI operation region support for CrystalCove PMIC"
>> +depends on INTEL_SOC_PMIC
>> +help
>> +  This config adds ACPI operation region support for CrystalCove PMIC.
>> +
>> +endif
>> +
>>  endif   # ACPI
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 6d11522f0e48..f5938399ac14 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -88,3 +88,6 @@ obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
>>  obj-$(CONFIG_ACPI_APEI) += apei/
>>  
>>  obj-$(CONFIG_ACPI_EXTLOG)   += acpi_extlog.o
>> +
>> +obj-$(CONFIG_PMIC_OPREGION) += pmic/intel_pmic.o
>> +obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
>> diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
>> new file mode 100644
>> index ..5dbc0fb4d536
>> --- /dev/null
>> +++ b/drivers/acpi/pmic/intel_pmic.c
>> @@ -0,0 +1,339 @@
>> +/*
>> + * intel_pmic.c - Intel PMIC operation region driver
>> + *
>> + * Copyright (C) 2014 Intel Corporation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License version
>> + * 2 as published by the Free Software Foundation.
>> + *
>> + * 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 "intel_pmic.h"
>> +
>> +#define PMIC_PMOP_OPREGION_ID   0x8d
>> +#define PMIC_THERMAL_OPREGION_ID0x8c
>> +
>> +struct acpi_lpat {
>> +int temp;
>> +int raw;
>> +};
>> +
>> +struct intel_pmic_opregion {
>> +struct mutex lock;
>> +struct acpi_lpat *lpat;
>> +int lpat_count;
>> +struct regmap *regmap;
>> +struct intel_pmic_opregion_data *data;
>> +};
>> +
>> +static struct pmic_pwr_reg *
>> +pmic_get_pwr_reg(int address, struct 

Re: [PATCH v4 6/7] ARM: mvebu: add PHY support to the dts for the USB controllers on Armada 375

[Kishon Vijay Abraham I]

Hi,

On Saturday 22 November 2014 02:50 PM, Gregory CLEMENT wrote:
> Hi Jason,
> 
> On 22/11/2014 03:08, Jason Cooper wrote:
>> On Thu, Nov 13, 2014 at 12:47:48PM +0100, Gregory CLEMENT wrote:
>>> Now that the USB cluster node has been added, use it as a PHY provider
>>> for the USB controller linked to it: the first EHCI and the xHCI.
>>>
>>> Signed-off-by: Gregory CLEMENT 
>>> ---
>>>  arch/arm/boot/dts/armada-375.dtsi | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/armada-375.dtsi 
>>> b/arch/arm/boot/dts/armada-375.dtsi
>>> index 8f45cf5d2a50..f344ec420c95 100644
>>> --- a/arch/arm/boot/dts/armada-375.dtsi
>>> +++ b/arch/arm/boot/dts/armada-375.dtsi
>>> @@ -14,6 +14,7 @@
>>>  #include "skeleton.dtsi"
>>>  #include 
>>>  #include 
>>> +#include 
>>
>> Odd.  The previous patch in this series simply adds a line to phy.h,
>> however, I get the following error during 'make dtbs':
>>
>> 
>>   DTC arch/arm/boot/dts/armada-375-db.dtb
>> In file included from 
>> arch/arm/boot/dts/armada-375-db.dts:17:0:arch/arm/boot/dts/armada-375.dtsi:17:33:
>> fatal error: dt-bindings/phy/phy.h: No such file or directory
>>  #include 
>>  ^
>> compilation terminated.
>> scripts/Makefile.lib:282: recipe for target 'arch/arm/boot/dts/armada-37 
>> 5-db.dtb' failed
>> 
>>
>> mvebu/dt is based on v3.18-rc1.  Is there a missing dependency
>> somewhere?  Perhaps we should let Kishon take the whole series and
>> handle the (hopefully trivial) merge conflict?
> 
> Actually Kishon asked me to use the dt-bindings/phy/phy.h file which
> was introduced by the patch "phy: Add PHY header file for DT x Driver
> defines". So indeed I had to have a dependency on the phy_dt_header
> branch (which is based on v3.18-rc4 and have only this single commit).
> The git tree is located at
> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git

right, I have a immutable tag @
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
phy-dt-header which is based on 3.18-rc4 (I should have based it on -rc1 as
pointed out by Maxime but it is too late now).

So they have based their branch on -rc4 and them merged phy-dt-header. Can you
do something similar?

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] f2fs: fix livelock calling f2fs_iget during f2fs_evict_inode

[Jaegeuk Kim]

In f2fs_evict_inode,
 commit_inmemory_pages
   f2fs_gc
 f2fs_iget
   iget_locked
 -> wait for inode free

Here, if the inode is same as the one to be evicted, f2fs should wait forever.
Actually, we should not call f2fs_balance_fs during f2fs_evict_inode to avoid
this.

But, the commit_inmem_pages calls f2fs_balance_fs by default, even if
f2fs_evict_inode wants to free inmemory pages only.

Hence, this patch adds to trigger f2fs_balance_fs only when there is something
to write.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 9de857f..9a33e34 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -230,7 +230,16 @@ void commit_inmem_pages(struct inode *inode, bool abort)
.rw = WRITE_SYNC,
};
 
-   f2fs_balance_fs(sbi);
+   /*
+* The abort is true only when f2fs_evict_inode is called.
+* Basically, the f2fs_evict_inode doesn't produce any data writes, so
+* that we don't need to call f2fs_balance_fs.
+* Otherwise, f2fs_gc in f2fs_balance_fs can wait forever until this
+* inode becomes free by iget_locked in f2fs_iget.
+*/
+   if (!abort)
+   f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
 
mutex_lock(>inmem_lock);
-- 
2.1.1

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

[PATCH 1/2] f2fs: introduce f2fs_dentry_kunmap to clean up

[Jaegeuk Kim]

This patch introduces f2fs_dentry_kunmap to clean up dirty codes.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/dir.c  |  3 +--
 fs/f2fs/f2fs.h |  6 ++
 fs/f2fs/namei.c| 30 ++
 fs/f2fs/recovery.c |  3 +--
 4 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 5a49995..b1a7d57 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -271,8 +271,7 @@ ino_t f2fs_inode_by_name(struct inode *dir, struct qstr 
*qstr)
de = f2fs_find_entry(dir, qstr, );
if (de) {
res = le32_to_cpu(de->ino);
-   if (!f2fs_has_inline_dentry(dir))
-   kunmap(page);
+   f2fs_dentry_kunmap(dir, page);
f2fs_put_page(page, 0);
}
 
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 418c852..d042813 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1229,6 +1229,12 @@ static inline void *inline_dentry_addr(struct page *page)
return (void *)&(ri->i_addr[1]);
 }
 
+static inline void f2fs_dentry_kunmap(struct inode *dir, struct page *page)
+{
+   if (!f2fs_has_inline_dentry(dir))
+   kunmap(page);
+}
+
 static inline int f2fs_readonly(struct super_block *sb)
 {
return sb->s_flags & MS_RDONLY;
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 2bee559..547a2de 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -200,8 +200,7 @@ static struct dentry *f2fs_lookup(struct inode *dir, struct 
dentry *dentry,
de = f2fs_find_entry(dir, >d_name, );
if (de) {
nid_t ino = le32_to_cpu(de->ino);
-   if (!f2fs_has_inline_dentry(dir))
-   kunmap(page);
+   f2fs_dentry_kunmap(dir, page);
f2fs_put_page(page, 0);
 
inode = f2fs_iget(dir->i_sb, ino);
@@ -231,8 +230,7 @@ static int f2fs_unlink(struct inode *dir, struct dentry 
*dentry)
err = acquire_orphan_inode(sbi);
if (err) {
f2fs_unlock_op(sbi);
-   if (!f2fs_has_inline_dentry(dir))
-   kunmap(page);
+   f2fs_dentry_kunmap(dir, page);
f2fs_put_page(page, 0);
goto fail;
}
@@ -469,8 +467,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry 
*old_dentry,
old_dir_page, new_dir);
update_inode_page(old_inode);
} else {
-   if (!f2fs_has_inline_dentry(old_inode))
-   kunmap(old_dir_page);
+   f2fs_dentry_kunmap(old_inode, old_dir_page);
f2fs_put_page(old_dir_page, 0);
}
drop_nlink(old_dir);
@@ -486,18 +483,15 @@ static int f2fs_rename(struct inode *old_dir, struct 
dentry *old_dentry,
 
 put_out_dir:
f2fs_unlock_op(sbi);
-   if (!f2fs_has_inline_dentry(new_dir))
-   kunmap(new_page);
+   f2fs_dentry_kunmap(new_dir, new_page);
f2fs_put_page(new_page, 0);
 out_dir:
if (old_dir_entry) {
-   if (!f2fs_has_inline_dentry(old_inode))
-   kunmap(old_dir_page);
+   f2fs_dentry_kunmap(old_inode, old_dir_page);
f2fs_put_page(old_dir_page, 0);
}
 out_old:
-   if (!f2fs_has_inline_dentry(old_dir))
-   kunmap(old_page);
+   f2fs_dentry_kunmap(old_dir, old_page);
f2fs_put_page(old_page, 0);
 out:
return err;
@@ -632,23 +626,19 @@ out_unlock:
f2fs_unlock_op(sbi);
 out_new_dir:
if (new_dir_entry) {
-   if (!f2fs_has_inline_dentry(new_inode))
-   kunmap(new_dir_page);
+   f2fs_dentry_kunmap(new_inode, new_dir_page);
f2fs_put_page(new_dir_page, 0);
}
 out_old_dir:
if (old_dir_entry) {
-   if (!f2fs_has_inline_dentry(old_inode))
-   kunmap(old_dir_page);
+   f2fs_dentry_kunmap(old_inode, old_dir_page);
f2fs_put_page(old_dir_page, 0);
}
 out_new:
-   if (!f2fs_has_inline_dentry(new_dir))
-   kunmap(new_page);
+   f2fs_dentry_kunmap(new_dir, new_page);
f2fs_put_page(new_page, 0);
 out_old:
-   if (!f2fs_has_inline_dentry(old_dir))
-   kunmap(old_page);
+   f2fs_dentry_kunmap(old_dir, old_page);
f2fs_put_page(old_page, 0);
 out:
return err;
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 4b180bb..9a93a6e 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -129,8 +129,7 @@ retry:
goto out;
 
 out_unmap_put:
-   if (!f2fs_has_inline_dentry(dir))
-   kunmap(page);
+   f2fs_dentry_kunmap(dir, page);
f2fs_put_page(page, 0);
 out_err:
iput(dir);
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

[PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

[Vivek Gautam]

DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.

Signed-off-by: Vivek Gautam 
Reviewed-by: Jingoo Han 
Tested-by: Javier Martinez Canillas 
Cc: Kukjin Kim 
---
 arch/arm/boot/dts/exynos5250.dtsi |2 +-
 arch/arm/boot/dts/exynos5420.dtsi |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a588b4..bebd099 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@
 
dp_phy: video-phy@10040720 {
compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040720 4>;
+   samsung,pmu-syscon = <_system_controller>;
#phy-cells = <0>;
};
 
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a03..1353a09 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};
 
dp_phy: video-phy@10040728 {
-   compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040728 4>;
+   compatible = "samsung,exynos5420-dp-video-phy";
+   samsung,pmu-syscon = <_system_controller>;
#phy-cells = <0>;
};
 
-- 
1.7.10.4

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

[PATCH v2 2/2] arm: ls1: provide a workaround for core soft reset

[Zhuoyu Zhang]

From: Zhang Zhuoyu 

Due to a hardware erratum, after core soft reset, core state machine
registers need to force release manually.

Signed-off-by: Zhang Zhuoyu 
---
 arch/arm/mach-imx/platsmp.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 7735ebb..73c2289 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -41,6 +41,7 @@ u32 g_diag_reg;
 static void __iomem *scu_base;
 static void __iomem *dcfg_base;
 static void __iomem *scfg_base;
+static void __iomem *dcsr_rcpm2_base;
 static u32 secondary_pre_boot_entry;
 
 static struct map_desc scu_io_desc __initdata = {
@@ -150,8 +151,25 @@ static int ls1021a_secondary_iomap(void)
goto scfg_err;
}
 
+   np = of_find_compatible_node(NULL, NULL, "fsl,ls1021a-dcsr-rcpm");
+   if (!np) {
+   pr_err("%s: failed to find dcsr node.\n", __func__);
+   ret = -EINVAL;
+   goto dcsr_err;
+   }
+
+   dcsr_rcpm2_base = of_iomap(np, 1);
+   of_node_put(np);
+   if (!dcsr_rcpm2_base) {
+   pr_err("%s: failed to map dcsr.\n", __func__);
+   ret = -ENOMEM;
+   goto dcsr_err;
+   }
+
return 0;
 
+dcsr_err:
+   iounmap(scfg_base);
 scfg_err:
iounmap(dcfg_base);
 dcfg_err:
@@ -176,7 +194,7 @@ static int ls1021a_reset_secondary(unsigned int cpu)
 {
u32 tmp;
 
-   if (!scfg_base || !dcfg_base)
+   if (!scfg_base || !dcfg_base || !dcsr_rcpm2_base)
return -ENOMEM;
 
writel_relaxed(secondary_pre_boot_entry,
@@ -190,6 +208,15 @@ static int ls1021a_reset_secondary(unsigned int cpu)
iowrite32be(0x8000, scfg_base + SCFG_CORESRENCR);
iowrite32be(0x8000, scfg_base +
SCFG_CORE0_SFT_RST + STRIDE_4B * cpu);
+   mdelay(10);
+
+   /* LS1021a errata. after reset, core state machine registers
+* need to force release manually.
+*/
+   iowrite32be(0x0080, dcsr_rcpm2_base + DCSR_RCPM2_DEBUG1);
+   iowrite32be(0x0080, dcsr_rcpm2_base + DCSR_RCPM2_DEBUG2);
+   iowrite32be(0, dcsr_rcpm2_base + DCSR_RCPM2_DEBUG1);
+   iowrite32be(0, dcsr_rcpm2_base + DCSR_RCPM2_DEBUG2);
 
/* Release secondary core */
iowrite32be(1 << cpu, dcfg_base + DCFG_CCSR_BRR);
-- 
2.1.0.27.g96db324

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

Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block

[Jason Wang]

On 11/24/2014 01:56 PM, Dexuan Cui wrote:
> If num_ballooned is not 0, we shouldn't neglect the already-allocated 2MB
> memory block(s).
>
> Cc: K. Y. Srinivasan 
> Cc: 
> Signed-off-by: Dexuan Cui 
> ---
>  drivers/hv/hv_balloon.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 5e90c5d..cba2d3b 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -1091,6 +1091,8 @@ static void balloon_up(struct work_struct *dummy)
>   bool done = false;
>   int i;
>  
> + /* The host does balloon_up in 2MB. */
> + WARN_ON(num_pages % PAGES_IN_2M != 0);
>  
>   /*
>* We will attempt 2M allocations. However, if we fail to
> @@ -,7 +1113,7 @@ static void balloon_up(struct work_struct *dummy)
>   bl_resp, alloc_unit,
>_error);
>  
> - if ((alloc_error) && (alloc_unit != 1)) {
> + if (alloc_error && (alloc_unit != 1) && num_ballooned == 0) {
>   alloc_unit = 1;
>   continue;
>   }

Before the change, we may retry the 4K allocation when part or all 2M
allocations were failed. This makes sense when memory is fragmented. But
after the change, if part of 2M allocation were failed, we won't retry
4K allocation. Is this expected?

Btw, can host just require 1M? If yes, should alloc_balloon_pages() set
alloc_error if num_pages < alloc_unit for caller to catch this and retry
4K allocation?

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

Re: [PATCH 07/17] new helpers: skb_copy_datagram_from_iter() and zerocopy_sg_from_iter()

[Jason Wang]

On 11/24/2014 08:02 AM, Ben Hutchings wrote:
> On Sat, 2014-11-22 at 04:33 +, Al Viro wrote:
> [...]
>> --- a/net/core/datagram.c
>> +++ b/net/core/datagram.c
>> @@ -572,6 +572,77 @@ fault:
>>  }
>>  EXPORT_SYMBOL(skb_copy_datagram_from_iovec);
>>  
> Missing kernel-doc.
>
>> +int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,
>> + struct iov_iter *from,
>> + int len)
>> +{
>> +int start = skb_headlen(skb);
>> +int i, copy = start - offset;
>> +struct sk_buff *frag_iter;
>> +
>> +/* Copy header. */
>> +if (copy > 0) {
>> +if (copy > len)
>> +copy = len;
>> +if (copy_from_iter(skb->data + offset, copy, from) != copy)
>> +goto fault;
>> +if ((len -= copy) == 0)
>> +return 0;
>> +offset += copy;
>> +}
>> +
>> +/* Copy paged appendix. Hmm... why does this look so complicated? */
>> +for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>> +int end;
>> +const skb_frag_t *frag = _shinfo(skb)->frags[i];
>> +
>> +WARN_ON(start > offset + len);
>> +
>> +end = start + skb_frag_size(frag);
>> +if ((copy = end - offset) > 0) {
>> +size_t copied;
> Blank line needed after a declaration.
>
>> +if (copy > len)
>> +copy = len;
>> +copied = copy_page_from_iter(skb_frag_page(frag),
>> +  frag->page_offset + offset - start,
>> +  copy, from);
>> +if (copied != copy)
>> +goto fault;
>> +
>> +if (!(len -= copy))
>> +return 0;
> The other two instances of this condition are written as:
>
>   if ((len -= copy) == 0)
>
> Similarly in skb_copy_bits().
>
>> +offset += copy;
>> +}
>> +start = end;
>> +}
>> +
>> +skb_walk_frags(skb, frag_iter) {
>> +int end;
>> +
>> +WARN_ON(start > offset + len);
>> +
>> +end = start + frag_iter->len;
>> +if ((copy = end - offset) > 0) {
>> +if (copy > len)
>> +copy = len;
>> +if (skb_copy_datagram_from_iter(frag_iter,
>> +offset - start,
>> +from, copy))
>> +goto fault;
>> +if ((len -= copy) == 0)
>> +return 0;
>> +offset += copy;
>> +}
>> +start = end;
>> +}
>> +if (!len)
>> +return 0;
>> +
>> +fault:
>> +return -EFAULT;
>> +}
>> +EXPORT_SYMBOL(skb_copy_datagram_from_iter);
>> +
>>  /**
>>   *  zerocopy_sg_from_iovec - Build a zerocopy datagram from an iovec
>>   *  @skb: buffer to copy
>> @@ -643,6 +714,50 @@ int zerocopy_sg_from_iovec(struct sk_buff *skb, const 
>> struct iovec *from,
>>  }
>>  EXPORT_SYMBOL(zerocopy_sg_from_iovec);
>>  
> Missing kernel-doc.
>
>> +int zerocopy_sg_from_iter(struct sk_buff *skb, struct iov_iter *from)
>> +{
>> +int len = iov_iter_count(from);
>> +int copy = min_t(int, skb_headlen(skb), len);
>> +int i = 0;
>> +
>> +/* copy up to skb headlen */
>> +if (skb_copy_datagram_from_iter(skb, 0, from, copy))
>> +return -EFAULT;
>> +
>> +while (iov_iter_count(from)) {
>> +struct page *pages[MAX_SKB_FRAGS];
>> +size_t start;
>> +ssize_t copied;
>> +unsigned long truesize;
>> +int n = 0;
>> +
>> +copied = iov_iter_get_pages(from, pages, ~0U, MAX_SKB_FRAGS, 
>> );
>> +if (copied < 0)
>> +return -EFAULT;
>> +
>> +truesize = DIV_ROUND_UP(copied + start, PAGE_SIZE) * PAGE_SIZE;
> PAGE_ALIGN(copied + start) ?
>
>> +skb->data_len += copied;
>> +skb->len += copied;
>> +skb->truesize += truesize;
>> +atomic_add(truesize, >sk->sk_wmem_alloc);
>> +while (copied) {
>> +int off = start;
> This variable seems redundant.  Can't we use start directly and move the
> 'start = 0' to the bottom of the loop?
>
>> +int size = min_t(int, copied, PAGE_SIZE - off);
>> +start = 0;
>> +if (i < MAX_SKB_FRAGS)
>> +skb_fill_page_desc(skb, i, pages[n], off, size);
>> +else
>> +put_page(pages[n]);
> Why is this condition needed, given we told iov_iter_get_pages() to
> limit to MAX_SKB_FRAGS pages?

We don't want to send truncated packets and there's no other way to put
those pages since it was not in 

Re: [PATCH V3] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA

[Michael Shigorin]

On Mon, Nov 24, 2014 at 10:39:55AM +0800, Li, Aubrey wrote:
> Well, Can we explicitly tied this up with ASUS T100TA in the code?

It works for me on Aava Inari 8 too.

-- 
  WBR, Michael Shigorin / http://altlinux.org
  -- http://opennet.ru / http://anna-news.info
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: linuxppc-dev list

[Benjamin Herrenschmidt]

On Mon, 2014-11-24 at 16:08 +1100, Benjamin Herrenschmidt wrote:
> Hi Linus !
> 
> This series fix a nasty issue with radeon adapters on powerpc servers,
> it's all CC'ed stable and has the relevant maintainers ack's/reviews.

Hrm... git request-pull can't find the commit on the server (it's been
quite a while now, maybe some mirroring issue), so didn't put the
branch name in properly.

The branch name is "merge", ie:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge

Cheers
Ben.

> Basically, some (radeon) adapters have issues with MSI addresses above
> 1T (only support 40-bits). We had powerpc specific quirk but it only
> listed a specific revision of an adapter that we shipped with our
> machines and didn't properly handle the audio function which some distros
> enable nowadays.
> 
> So we made the quirk generic and fixed both the graphic and audio drivers
> properly to use it.
> 
> Without that, ppc64 server machines will crash at boot with a radeon adapter.
> 
> Note: This has been brewing for a while, it just needed a last respin which
> got delayed due to us moving ozlabs to a new location in town and other such
> things taking priority.
> 
> Cheers,
> Ben.


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

linux-next: manual merge of the tip tree with the pci tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/pci/host/pcie-rcar.c between commit 3c70637f7569 ("PCI: rcar:
Make rcar_pci static") from the pci tree and commit 7c35c8cc32f3 ("PCI:
rcar: Save MSI controller in pci_sys_data") from the tip tree.

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

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

diff --cc drivers/pci/host/pcie-rcar.c
index 0df9b2941221,c1177cd55ce3..
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@@ -380,16 -380,7 +380,7 @@@ static int rcar_pcie_setup(int nr, stru
return 1;
  }
  
- static void rcar_pcie_add_bus(struct pci_bus *bus)
- {
-   if (IS_ENABLED(CONFIG_PCI_MSI)) {
-   struct rcar_pcie *pcie = sys_to_pcie(bus->sysdata);
- 
-   bus->msi = >msi.chip;
-   }
- }
- 
 -struct hw_pci rcar_pci = {
 +static struct hw_pci rcar_pci = {
.setup  = rcar_pcie_setup,
.map_irq= of_irq_parse_and_map_pci,
.ops= _pcie_ops,


pgpiIWOZQWOMG.pgp
Description: OpenPGP digital signature

linuxppc-dev list

[Benjamin Herrenschmidt]

Hi Linus !

This series fix a nasty issue with radeon adapters on powerpc servers,
it's all CC'ed stable and has the relevant maintainers ack's/reviews.

Basically, some (radeon) adapters have issues with MSI addresses above
1T (only support 40-bits). We had powerpc specific quirk but it only
listed a specific revision of an adapter that we shipped with our
machines and didn't properly handle the audio function which some distros
enable nowadays.

So we made the quirk generic and fixed both the graphic and audio drivers
properly to use it.

Without that, ppc64 server machines will crash at boot with a radeon adapter.

Note: This has been brewing for a while, it just needed a last respin which
got delayed due to us moving ozlabs to a new location in town and other such
things taking priority.

Cheers,
Ben.

The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:

  Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git 

for you to fetch changes up to 31345e1a071e4e5f2fa8b6be5ca7d1cbce20cfca:

  powerpc/pci: Remove unused force_32bit_msi quirk (2014-11-24 14:36:02 +1100)


Benjamin Herrenschmidt (6):
  PCI/MSI: Add device flag indicating that 64-bit MSIs don't work
  gpu/radeon: Set flag to indicate broken 64-bit MSI
  sound/radeon: Move 64-bit MSI quirk from arch to driver
  powerpc/powernv: Honor the generic "no_64bit_msi" flag
  powerpc/pseries: Honor the generic "no_64bit_msi" flag
  powerpc/pci: Remove unused force_32bit_msi quirk

Takashi Iwai (1):
  ALSA: hda - Limit 40bit DMA for AMD HDMI controllers

 arch/powerpc/include/asm/pci-bridge.h |  2 --
 arch/powerpc/kernel/pci_64.c  | 10 --
 arch/powerpc/platforms/powernv/pci-ioda.c |  3 +--
 arch/powerpc/platforms/powernv/pci.c  |  3 +--
 arch/powerpc/platforms/pseries/msi.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_irq_kms.c   | 10 ++
 drivers/pci/msi.c | 26 ++
 include/linux/pci.h   |  1 +
 sound/pci/hda/hda_intel.c | 24 +++-
 sound/pci/hda/hda_priv.h  |  1 +
 10 files changed, 60 insertions(+), 22 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v19 1/5] dt-bindings: document Rockchip thermal

[Caesar Wang]

This add the necessary binding documentation for the thermal
found on Rockchip SoCs

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 .../bindings/thermal/rockchip-thermal.txt  | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
new file mode 100644
index 000..ef802de
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,68 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible : "rockchip,rk3288-tsadc"
+- reg : physical base address of the controller and length of memory mapped
+   region.
+- interrupts : The interrupt number to the cpu. The interrupt specifier format
+  depends on the interrupt controller.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Shall be "tsadc" for the converter-clock, and "apb_pclk" for
+   the peripheral clock.
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the name "tsadc-apb".
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+- rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value.
+- rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
+- rockchip,hw-tshut-polarity : The hardware-controlled active polarity 0:LOW
+  1:HIGH.
+
+Exiample:
+tsadc: tsadc@ff28 {
+   compatible = "rockchip,rk3288-tsadc";
+   reg = <0xff28 0x100>;
+   interrupts = ;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   resets = < SRST_TSADC>;
+   reset-names = "tsadc-apb";
+   pinctrl-names = "default";
+   pinctrl-0 = <_out>;
+   #thermal-sensor-cells = <1>;
+   rockchip,hw-tshut-temp = <95000>;
+   rockchip,hw-tshut-mode = <0>;
+   rockchip,hw-tshut-polarity = <0>;
+};
+
+Example: referring to thermal sensors:
+thermal-zones {
+   cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <   1>;
+
+   trips {
+   cpu_alert0: cpu_alert {
+   temperature = <7>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_crit: cpu_crit {
+   temperature = <9>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device =
+   < THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+   };
+};
-- 
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 v19 2/5] thermal: rockchip: add driver for thermal

[Caesar Wang]

Thermal is TS-ADC Controller module supports
user-defined mode and automatic mode.

User-defined mode refers,TSADC all the control signals entirely by
software writing to register for direct control.

Automaic mode refers to the module automatically poll TSADC output,
and the results were checked.If you find that the temperature High
in a period of time,an interrupt is generated to the processor
down-measures taken;If the temperature over a period of time High,
the resulting TSHUT gave CRU module,let it reset the entire chip,
or via GPIO give PMIC.

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 drivers/thermal/Kconfig|  10 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/rockchip_thermal.c | 693 +
 3 files changed, 704 insertions(+)
 create mode 100644 drivers/thermal/rockchip_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index ef5587f..527632d 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -133,6 +133,16 @@ config SPEAR_THERMAL
  Enable this to plug the SPEAr thermal sensor driver into the Linux
  thermal framework.
 
+config ROCKCHIP_THERMAL
+   tristate "Rockchip thermal driver"
+   depends on ARCH_ROCKCHIP
+   depends on RESET_CONTROLLER
+   help
+ Rockchip thermal driver provides support for Temperature sensor
+ ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
+ trip point. Cpufreq is used as the cooling device and will throttle
+ CPUs when the Temperature crosses the passive trip point.
+
 config RCAR_THERMAL
tristate "Renesas R-Car thermal driver"
depends on ARCH_SHMOBILE || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 31e232f..21da0a8 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -19,6 +19,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
 
 # platform thermal drivers
 obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
 obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
 obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
 obj-y  += samsung/
diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
new file mode 100644
index 000..1bcddfc
--- /dev/null
+++ b/drivers/thermal/rockchip_thermal.c
@@ -0,0 +1,693 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+#include 
+#include 
+
+/**
+ * If the temperature over a period of time High,
+ * the resulting TSHUT gave CRU module,let it reset the entire chip,
+ * or via GPIO give PMIC.
+ */
+enum tshut_mode {
+   TSHUT_MODE_CRU = 0,
+   TSHUT_MODE_GPIO,
+};
+
+/**
+ * the system Temperature Sensors tshut(tshut) polarity
+ * the bit 8 is tshut polarity.
+ * 0: low active, 1: high active
+ */
+enum tshut_polarity {
+   TSHUT_LOW_ACTIVE = 0,
+   TSHUT_HIGH_ACTIVE,
+};
+
+/**
+ * The system has three Temperature Sensors.  channel 0 is reserved,
+ * channel 1 is for CPU, and channel 2 is for GPU.
+ */
+enum sensor_id {
+   SENSOR_CPU = 1,
+   SENSOR_GPU,
+};
+
+struct rockchip_tsadc_chip {
+   /* The hardware-controlled tshut property */
+   long tshut_temp;
+   enum tshut_mode tshut_mode;
+   enum tshut_polarity tshut_polarity;
+
+   /* Chip-wide methods */
+   void (*initialize)(void __iomem *reg, enum tshut_polarity p);
+   void (*irq_ack)(void __iomem *reg);
+   void (*control)(void __iomem *reg, bool on);
+
+   /* Per-sensor methods */
+   int (*get_temp)(int chn, void __iomem *reg, long *temp);
+   void (*set_tshut_temp)(int chn, void __iomem *reg, long temp);
+   void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m);
+};
+
+struct rockchip_thermal_sensor {
+   struct rockchip_thermal_data *thermal;
+   struct thermal_zone_device *tzd;
+   enum sensor_id id;
+};
+
+#define NUM_SENSORS2 /* Ignore unused sensor 0 */
+
+struct rockchip_thermal_data {
+   const struct rockchip_tsadc_chip *chip;
+   struct platform_device *pdev;
+   struct reset_control *reset;
+
+   struct rockchip_thermal_sensor sensors[NUM_SENSORS];
+
+   struct clk *clk;
+   struct clk *pclk;
+
+   void __iomem *regs;
+
+   long tshut_temp;
+   enum 

[PATCH v19 4/5] ARM: dts: add main Thermal info to rk3288

[Caesar Wang]

This patch is depend on rk3288-thermal.dtsi,or
it will compile error.

If for some reason we are unable to shut it down
in orderly fashion (kernel is stuck holding a lock or
similar), then hardware TSHUT will reset it.

If the temperature over a period of time High,over 95C
the resulting TSHUT gave CRU module,let it reset
the entire chip,or via GPIO give PMIC.

Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 arch/arm/boot/dts/rk3288.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 9cd269a..c7a2691 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -66,6 +67,7 @@
 216000  90
 126000  90
>;
+   #cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
};
@@ -346,6 +348,25 @@
status = "disabled";
};
 
+   thermal-zones {
+   #include "rk3288-thermal.dtsi"
+   };
+
+   tsadc: tsadc@ff28 {
+   compatible = "rockchip,rk3288-tsadc";
+   reg = <0xff28 0x100>;
+   interrupts = ;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   resets = < SRST_TSADC>;
+   reset-names = "tsadc-apb";
+   pinctrl-names = "default";
+   pinctrl-0 = <_out>;
+   #thermal-sensor-cells = <1>;
+   rockchip,hw-tshut-temp = <95000>;
+   status = "disabled";
+   };
+
usb_host0_ehci: usb@ff50 {
compatible = "generic-ehci";
reg = <0xff50 0x100>;
@@ -965,6 +986,12 @@
};
};
 
+   tsadc {
+   otp_out: otp-out {
+   rockchip,pins = <0 10 RK_FUNC_1 
_pull_none>;
+   };
+   };
+
pwm0 {
pwm0_pin: pwm0-pin {
rockchip,pins = <7 0 RK_FUNC_1 _pull_none>;
-- 
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 v19 3/5] ARM: dts: add RK3288 Thermal data

[Caesar Wang]

This patch changes a dtsi file to contain the thermal data
on RK3288 and later SoCs. This data will
enable a thermal shutdown over 90C.

Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 arch/arm/boot/dts/rk3288-thermal.dtsi | 78 +++
 1 file changed, 78 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3288-thermal.dtsi

diff --git a/arch/arm/boot/dts/rk3288-thermal.dtsi 
b/arch/arm/boot/dts/rk3288-thermal.dtsi
new file mode 100644
index 000..a8a5ea7
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-thermal.dtsi
@@ -0,0 +1,78 @@
+/*
+ * Device Tree Source for RK3288 SoC thermal
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include 
+
+reserve_thermal: reserve_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <   0>;
+
+};
+
+cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <   1>;
+
+   trips {
+   cpu_alert0: cpu_alert0 {
+   temperature = <7>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_crit: cpu_crit {
+   temperature = <9>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device =
+   < THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+};
+
+gpu_thermal: gpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <   2>;
+
+   trips {
+   gpu_alert0: gpu_alert0 {
+   temperature = <7>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   gpu_crit: gpu_crit {
+   temperature = <9>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device =
+   < THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+};
-- 
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 v19 5/5] ARM: dts: enable Thermal on rk3288-evb board

[Caesar Wang]

when a thermal temperature over TSHUT.Default to via
CRU reset the entire chip on rk3288-evb Board,
TSHUT is low active on rk3288-evb board.

Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 arch/arm/boot/dts/rk3288-evb.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index cb83cea..3e067dd 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -148,6 +148,12 @@
status = "okay";
 };
 
+ {
+   rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU 1:GPIO */
+   rockchip,hw-tshut-polarity = <0>; /* tshut polarity 0:LOW 1:HIGH */
+   status = "okay";
+};
+
  {
backlight {
bl_en: bl-en {
-- 
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 01/11] pinctrl: exynos: Add BUS1 pin controller for exynos7

[Vivek Gautam]

Hi Alim,


On Sat, Nov 22, 2014 at 7:07 PM, Alim Akhtar  wrote:
> Hi Vivek,
>
> On Fri, Nov 21, 2014 at 7:05 PM, Vivek Gautam  
> wrote:
>> USB and Power regulator on Exynos7 require gpios available
>> in BUS1 pin controller block.
>> So adding the BUS1 pinctrl support.
>>
>> Signed-off-by: Naveen Krishna Ch 
>> Signed-off-by: Vivek Gautam 
>> Cc: Linus Walleij 
>> ---
>>  drivers/pinctrl/samsung/pinctrl-exynos.c |   12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
>> b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> index d5d4cfc..caca5b5 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> @@ -1300,6 +1300,13 @@ static const struct samsung_pin_bank_data 
>> exynos7_pin_banks7[] __initconst = {
>> EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
>>  };
>>
>> +/* pin banks of exynos7 pin-controller - BUS1 */
>> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst 
>> = {
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
>> +   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
>> +};
>> +
> Looks like you are just trying to touch pin banks only related to USB
> stuffs, but as this patch does not have any dependencies on other
> patches in this series, will you consider adding other pin banks of
> BUS1, just for completeness of BUS1 pin-controller.

True, this just touches the USB related pinctrl.
Will add the rest pin banks of BUS1 for completeness.
Thanks for pointing out. :-)

[snip]



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v19 0/5] Rockchip soc thermal driver

[Caesar Wang]

This series patchs tested on rk3288 SDK board and pinky-v1,v2 board.
I believe the driver can be used on the rk3288-evb board.

Add this driver, The system will shutdown when
the thermal temperture over 100C.If for some reason we are unable to
shut it down in orderly fashion (kernel is stuck holding a lock or similar)
then hardware will reset it.

The patchs 1/5,2/5 can applay Eduardo's Branch
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
[branch "next-kernel"]
remote = origin
merge = refs/heads/next


The patchs 3/5,4/5,5/5 can apply Heiko's Branch 
https://github.com/mmind/linux-rockchip.git
[branch "3.19-armsoc/dts"]
remote = origin
merge = refs/heads/wip/v3.19-armsoc/dts

Changes in v19:
- update driver to fit Eduardo new API design.
https://patchwork.kernel.org/patch/5329801/

Changes in v18:
* address comments from Eduardo Valentin and Dmitry Torokhov.
- we need reset tsadc-controller before enable tsadc auto mode,
  when we add the thermal function in coreboot,we always enable tsadc 
controller.
  So we need reset tsadc-controller to avoid the TSADC is abnormal.
- put the document behind the driver.
- Tested on pinky1,2,jeffy board,we will fix cooling-map temperature 
from 80C to 70C,
  critical temperature from 100C to 90C.

Changes in v17:
* address comments from Heiko Stubner and .
- rename the tshut property
- the critiacal temperature only indeed 100C when add the cooling map,
  it's for the more secure,fix the temperature from 120C to 100C.

Changes in v16:
* address comments from Dmitry Torokhov.
- add thermal->chip->control(thermal->regs, false) in remove()
- adjust TSHUT in resume().

Changes in v15:
* address comments from Dmitry Torokhov.
- enable TSHUT move into rk_tsadcv2_tshut_temp().
- drop the id argument in rk_tsadcv2_control().

Changes in v14:
* address comments from Dmitry Torokhov.
- adjust-alarm-rate-depending-on-clock.
- 0001-rockchip-thermal-do-not-register-cpufreq-cooling-dev.

Changes in v13:
- add cooling-maps for cpu-thermal.
- put tshut polarity in device tree.

Changes in v12:
* address comments from Dmitry Torokhov and Vladimir Zapolskiy.
- split-sensor-handling.
- rename-rockchip_tsadc_platform_data.

Changes in v11:
* address comments from Vladimir Zapolskiy.
- fix cpufreq_cooling_unregister() to put in correct position.
- fix "data->chn",at least can get valid Tsensor temp.

Changes in v10:
* address comments from Doug Anderson.
- fix TSHUT polarity,ensure support TSHUT.
- add the decription for rk_tsadcv2_initialize().

Changes in v9:
* address comments from Dmitry Torokhov.
- fix some style be defined
- remove some unused code.
- clk_disable_unprepare->clk_disable in suspend()

Changes in v8:
* address comments from Dmitry Torokhov and Doug Anderson.
- add three Teperture Sensors.
- support CRU and GPIO reset chip.
- rename rk3xxx-cpu-thermal.dtsi as rk3288-thermal.dtsi
- alarm-temp via set_trips() callback
- remove "reset-gpios"

Changes in v7:
- fix get data->clk=0 when in probe() function.
- fix some style code.
- modify dts,main add rk3xxx-cpu-thermal.dtsi

Changes in v6:
* address comments from Tomeu Vizoso.
- use thermal's generic framework.

Changes in v5:
* address comments from Eduardo Valentin,rui.zhang and Heiko Stubner:
- with BIT() macro
- manage clocks in suspend/resume.
- license is fixed as GPLv2.
- #include "thermal_core.h"->#include 
- use the generic trip-points.the hw-shut-temp isn't generic 
trip-points.
- The method of binding and unbinding be fixed.
- The pin-name tsadc->otp_out

Changes in v4:
* address comments from Jonathan Cameron,huangtao and zhaoyifeng:
- this series thermal driver still be put in driver/thermal/
- modify the thermal driver description.

Changes in v3:(add dts configure)
* address comments from Dmitry Torokhov and Arnd Bergmann:
- fix clock-names in rockchip-thermal.txt
- remove rockchip_thermal_control() in rockchip_set_mode()
- fix some code style.
- add dts configure.

Changes in v2:
* address comments from Heiko Stubner:
- fix dt-bindings in rockchip-thermal.txt
- remove Author mark
- rename TSADC_XXX->TSADCV2_XXX,it eill ready to merge compatible other 
SoCs.
- fix a identation
- remove clk_set_rate(),it's no necessary.
- fix the SIMPLE_DEV_PM_OPS() function  style.

Caesar Wang (5):
  thermal: rockchip: add driver for thermal
  dt-bindings: document Rockchip thermal
  ARM: dts: add RK3288 

Re: [PATCH net-next 0/2] r8152: use ECM mode for future chips

[David Miller]

From: Hayes Wang 
Date: Mon, 24 Nov 2014 11:09:47 +0800

> For the future chips which the r8152 doesn't support yet, we could
> still use ECM mode for basic transmission.

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

[GIT PULL] clk: fixes for 3.18

[Mike Turquette]

The following changes since commit 206c5f60a3d902bc4b56dab2de3e88de5eb06108:

  Linux 3.18-rc4 (2014-11-09 14:55:29 -0800)

are available in the git repository at:

  https://git.linaro.org/people/mike.turquette/linux.git 
tags/clk-fixes-for-linus

for you to fetch changes up to dcf3d458304aafda3d12413ade39fdf19740dbc3:

  clk: pxa: fix pxa27x CCCR bit usage (2014-11-17 11:25:29 -0800)


The fixes for the clock framework are all regressions in drivers, plus a
single fix in one of the basic clock templates. No fixes to the core
this time around. As with most clock driver fixes these run the gamut
from fixing a build warning to fixing wrecked memory timings, with a
little USB tossed in for fun. Please consider pulling.


Boris Brezillon (2):
  clk: at91: usb: fix at91rm9200 round and set rate
  clk: at91: usb: fix at91sam9x5 recalc, round and set rate

Georgi Djakov (1):
  clk: qcom: Fix duplicate rbcpr clock name

James Hogan (1):
  clk-divider: Fix READ_ONLY when divider > 1

Robert Jarzmik (1):
  clk: pxa: fix pxa27x CCCR bit usage

 drivers/clk/at91/clk-usb.c| 35 ++-
 drivers/clk/clk-divider.c | 18 +++---
 drivers/clk/pxa/clk-pxa27x.c  |  4 +--
 drivers/clk/qcom/mmcc-apq8084.c   |  2 +-
 drivers/clk/rockchip/clk.c|  4 +--
 include/dt-bindings/clock/qcom,mmcc-apq8084.h |  2 +-
 include/linux/clk-provider.h  |  1 -
 7 files changed, 32 insertions(+), 34 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block

[Dexuan Cui]

If num_ballooned is not 0, we shouldn't neglect the already-allocated 2MB
memory block(s).

Cc: K. Y. Srinivasan 
Cc: 
Signed-off-by: Dexuan Cui 
---
 drivers/hv/hv_balloon.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 5e90c5d..cba2d3b 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1091,6 +1091,8 @@ static void balloon_up(struct work_struct *dummy)
bool done = false;
int i;
 
+   /* The host does balloon_up in 2MB. */
+   WARN_ON(num_pages % PAGES_IN_2M != 0);
 
/*
 * We will attempt 2M allocations. However, if we fail to
@@ -,7 +1113,7 @@ static void balloon_up(struct work_struct *dummy)
bl_resp, alloc_unit,
 _error);
 
-   if ((alloc_error) && (alloc_unit != 1)) {
+   if (alloc_error && (alloc_unit != 1) && num_ballooned == 0) {
alloc_unit = 1;
continue;
}
-- 
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 3/6] md/bcache: use generic io stats accounting functions to simplify io stat accounting

[Kent Overstreet]

On Mon, Nov 24, 2014 at 11:05:24AM +0800, Gu Zheng wrote:
> Use generic io stats accounting help functions (generic_{start,end}_io_acct)
> to simplify io stat accounting.
> 
> Signed-off-by: Gu Zheng 

Cool!

Acked-by: Kent Overstreet 

> ---
>  drivers/md/bcache/request.c |   23 ++-
>  1 files changed, 6 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
> index 62e6e98..ab43fad 100644
> --- a/drivers/md/bcache/request.c
> +++ b/drivers/md/bcache/request.c
> @@ -601,13 +601,8 @@ static void request_endio(struct bio *bio, int error)
>  static void bio_complete(struct search *s)
>  {
>   if (s->orig_bio) {
> - int cpu, rw = bio_data_dir(s->orig_bio);
> - unsigned long duration = jiffies - s->start_time;
> -
> - cpu = part_stat_lock();
> - part_round_stats(cpu, >d->disk->part0);
> - part_stat_add(cpu, >d->disk->part0, ticks[rw], duration);
> - part_stat_unlock();
> + generic_end_io_acct(bio_data_dir(s->orig_bio),
> + >d->disk->part0, s->start_time);
>  
>   trace_bcache_request_end(s->d, s->orig_bio);
>   bio_endio(s->orig_bio, s->iop.error);
> @@ -959,12 +954,9 @@ static void cached_dev_make_request(struct request_queue 
> *q, struct bio *bio)
>   struct search *s;
>   struct bcache_device *d = bio->bi_bdev->bd_disk->private_data;
>   struct cached_dev *dc = container_of(d, struct cached_dev, disk);
> - int cpu, rw = bio_data_dir(bio);
> + int rw = bio_data_dir(bio);
>  
> - cpu = part_stat_lock();
> - part_stat_inc(cpu, >disk->part0, ios[rw]);
> - part_stat_add(cpu, >disk->part0, sectors[rw], bio_sectors(bio));
> - part_stat_unlock();
> + generic_start_io_acct(rw, bio_sectors(bio), >disk->part0);
>  
>   bio->bi_bdev = dc->bdev;
>   bio->bi_iter.bi_sector += dc->sb.data_offset;
> @@ -1074,12 +1066,9 @@ static void flash_dev_make_request(struct 
> request_queue *q, struct bio *bio)
>   struct search *s;
>   struct closure *cl;
>   struct bcache_device *d = bio->bi_bdev->bd_disk->private_data;
> - int cpu, rw = bio_data_dir(bio);
> + int rw = bio_data_dir(bio);
>  
> - cpu = part_stat_lock();
> - part_stat_inc(cpu, >disk->part0, ios[rw]);
> - part_stat_add(cpu, >disk->part0, sectors[rw], bio_sectors(bio));
> - part_stat_unlock();
> + generic_start_io_acct(rw, bio_sectors(bio), >disk->part0);
>  
>   s = search_alloc(bio, d);
>   cl = >cl;
> -- 
> 1.7.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/

Re: [RFC][PATCH 1/2] reduce the amount of boilerplate in iov_iter.c

[Al Viro]

On Mon, Nov 24, 2014 at 01:09:54AM +, Al Viro wrote:
> Specifically, it allows to add a new kind of iovecs (ITER_KVEC using
> straight memcpy instead of going through copy_..._user) at the cost of
> mere 74 extra lines (see the next patch) and allows to add the things
> like csum_and_copy_{from,to}_iter() without arseloads of extra code (also
> written, but I'd prefer to clean it up a bit more first).

FWIW, the current variant of csum_and_copy_..._iter (completely untested,
without any code in net/* that would use it, etc.) is this:

diff --git a/include/linux/uio.h b/include/linux/uio.h
index 6e16945..28ed2d9 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -124,6 +124,8 @@ static inline void iov_iter_reexpand(struct iov_iter *i, 
size_t count)
 {
i->count = count;
 }
+size_t csum_and_copy_to_iter(void *addr, size_t bytes, __wsum *csum, struct 
iov_iter *i);
+size_t csum_and_copy_from_iter(void *addr, size_t bytes, __wsum *csum, struct 
iov_iter *i);
 
 int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
 int memcpy_toiovec(struct iovec *iov, unsigned char *kdata, int len);
diff --git a/mm/iov_iter.c b/mm/iov_iter.c
index 89ed7cd..fa03b8d 100644
--- a/mm/iov_iter.c
+++ b/mm/iov_iter.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define iterate_iovec(i, n, __v, __p, skip, STEP) {\
size_t left;\
@@ -577,6 +578,76 @@ ssize_t iov_iter_get_pages_alloc(struct iov_iter *i,
 }
 EXPORT_SYMBOL(iov_iter_get_pages_alloc);
 
+size_t copy_and_csum_from_iter(void *addr, size_t bytes, __wsum *csum,
+  struct iov_iter *i)
+{
+   char *to = addr;
+   __wsum sum;
+   if (unlikely(bytes > i->count))
+   bytes = i->count;
+
+   if (unlikely(!bytes))
+   return 0;
+
+   sum = *csum;
+   iterate_all_kinds_shift(i, bytes, v, ({
+   int err = 0;
+   __wsum next;
+   next = csum_and_copy_from_user(v.iov_base, 
+  (to += v.iov_len) - v.iov_len,
+  v.iov_len, sum, );
+   err ? v.iov_len : (sum = next, 0);
+   }), ({
+   char *p = kmap_atomic(v.bv_page);
+   sum = csum_partial_copy_nocheck(p + v.bv_offset,
+   (to += v.bv_len) - v.bv_len,
+   v.bv_len, sum);
+   kunmap_atomic(p);
+   }),
+   sum = csum_partial_copy_nocheck(v.iov_base,
+   (to += v.iov_len) - v.iov_len,
+   v.iov_len, sum)
+   )
+   *csum = sum;
+   return bytes;
+}
+EXPORT_SYMBOL(csum_and_copy_from_iter);
+
+size_t copy_and_csum_to_iter(void *addr, size_t bytes, __wsum *csum,
+struct iov_iter *i)
+{
+   char *from = addr;
+   __wsum sum;
+   if (unlikely(bytes > i->count))
+   bytes = i->count;
+
+   if (unlikely(!bytes))
+   return 0;
+
+   sum = *csum;
+   iterate_all_kinds_shift(i, bytes, v, ({
+   int err = 0;
+   __wsum next;
+   next = csum_and_copy_to_user((from += v.iov_len) - v.iov_len,
+v.iov_base, 
+v.iov_len, sum, );
+   err ? v.iov_len : (sum = next, 0);
+   }), ({
+   char *p = kmap_atomic(v.bv_page);
+   sum = csum_partial_copy_nocheck((from += v.bv_len) - v.bv_len,
+   p + v.bv_offset,
+   v.bv_len, sum);
+   kunmap_atomic(p);
+   }),
+   sum = csum_partial_copy_nocheck((from += v.iov_len) - v.iov_len,
+   v.iov_base,
+   v.iov_len, sum)
+   )
+   *csum = sum;
+   return bytes;
+}
+EXPORT_SYMBOL(csum_and_copy_to_iter);
+
 int iov_iter_npages(const struct iov_iter *i, int maxpages)
 {
size_t size = i->count;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the iommu tree with the tegra tree

[Stephen Rothwell]

Hi Joerg,

Today's linux-next merge of the iommu tree got a conflict in
drivers/iommu/tegra-smmu.c between commit a2257374a4bd ("memory: Add
NVIDIA Tegra memory controller support") from the tegra tree and commit
315786ebbf4a ("iommu: Add iommu_map_sg() function") from the iommu tree.

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

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

diff --cc drivers/iommu/tegra-smmu.c
index 0909e0bae9ec,73e845a66925..
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@@ -535,187 -1049,248 +535,188 @@@ static int tegra_smmu_map(struct iommu_
return 0;
  }
  
 -static int smmu_debugfs_stats_open(struct inode *inode, struct file *file)
 +static size_t tegra_smmu_unmap(struct iommu_domain *domain, unsigned long 
iova,
 + size_t size)
  {
 -  return single_open(file, smmu_debugfs_stats_show, inode->i_private);
 -}
 +  struct tegra_smmu_as *as = domain->priv;
 +  struct tegra_smmu *smmu = as->smmu;
 +  unsigned long offset;
 +  struct page *page;
 +  u32 *pte;
  
 -static const struct file_operations smmu_debugfs_stats_fops = {
 -  .open   = smmu_debugfs_stats_open,
 -  .read   = seq_read,
 -  .llseek = seq_lseek,
 -  .release= single_release,
 -  .write  = smmu_debugfs_stats_write,
 -};
 +  pte = as_get_pte(as, iova, );
 +  if (!pte)
 +  return 0;
  
 -static void smmu_debugfs_delete(struct smmu_device *smmu)
 -{
 -  debugfs_remove_recursive(smmu->debugfs_root);
 -  kfree(smmu->debugfs_info);
 +  offset = offset_in_page(pte);
 +  as_put_pte(as, iova);
 +
 +  smmu->soc->ops->flush_dcache(page, offset, 4);
 +  smmu_flush_ptc(smmu, page, offset);
 +  smmu_flush_tlb_group(smmu, as->id, iova);
 +  smmu_flush(smmu);
 +
 +  return size;
  }
  
 -static void smmu_debugfs_create(struct smmu_device *smmu)
 +static phys_addr_t tegra_smmu_iova_to_phys(struct iommu_domain *domain,
 + dma_addr_t iova)
  {
 -  int i;
 -  size_t bytes;
 -  struct dentry *root;
 -
 -  bytes = ARRAY_SIZE(smmu_debugfs_mc) * ARRAY_SIZE(smmu_debugfs_cache) *
 -  sizeof(*smmu->debugfs_info);
 -  smmu->debugfs_info = kmalloc(bytes, GFP_KERNEL);
 -  if (!smmu->debugfs_info)
 -  return;
 -
 -  root = debugfs_create_dir(dev_name(smmu->dev), NULL);
 -  if (!root)
 -  goto err_out;
 -  smmu->debugfs_root = root;
 -
 -  for (i = 0; i < ARRAY_SIZE(smmu_debugfs_mc); i++) {
 -  int j;
 -  struct dentry *mc;
 -
 -  mc = debugfs_create_dir(smmu_debugfs_mc[i], root);
 -  if (!mc)
 -  goto err_out;
 -
 -  for (j = 0; j < ARRAY_SIZE(smmu_debugfs_cache); j++) {
 -  struct dentry *cache;
 -  struct smmu_debugfs_info *info;
 -
 -  info = smmu->debugfs_info;
 -  info += i * ARRAY_SIZE(smmu_debugfs_mc) + j;
 -  info->smmu = smmu;
 -  info->mc = i;
 -  info->cache = j;
 -
 -  cache = debugfs_create_file(smmu_debugfs_cache[j],
 -  S_IWUGO | S_IRUGO, mc,
 -  (void *)info,
 -  _debugfs_stats_fops);
 -  if (!cache)
 -  goto err_out;
 -  }
 -  }
 +  struct tegra_smmu_as *as = domain->priv;
 +  struct page *page;
 +  unsigned long pfn;
 +  u32 *pte;
  
 -  return;
 +  pte = as_get_pte(as, iova, );
 +  pfn = *pte & SMMU_PFN_MASK;
  
 -err_out:
 -  smmu_debugfs_delete(smmu);
 +  return PFN_PHYS(pfn);
  }
  
 -static int tegra_smmu_suspend(struct device *dev)
 +static struct tegra_smmu *tegra_smmu_find(struct device_node *np)
  {
 -  struct smmu_device *smmu = dev_get_drvdata(dev);
 +  struct platform_device *pdev;
 +  struct tegra_mc *mc;
  
 -  smmu->translation_enable_0 = smmu_read(smmu, SMMU_TRANSLATION_ENABLE_0);
 -  smmu->translation_enable_1 = smmu_read(smmu, SMMU_TRANSLATION_ENABLE_1);
 -  smmu->translation_enable_2 = smmu_read(smmu, SMMU_TRANSLATION_ENABLE_2);
 -  smmu->asid_security = smmu_read(smmu, SMMU_ASID_SECURITY);
 -  return 0;
 +  pdev = of_find_device_by_node(np);
 +  if (!pdev)
 +  return NULL;
 +
 +  mc = platform_get_drvdata(pdev);
 +  if (!mc)
 +  return NULL;
 +
 +  return mc->smmu;
  }
  
 -static int tegra_smmu_resume(struct device *dev)
 +static int tegra_smmu_add_device(struct device *dev)
  {
 -  struct smmu_device *smmu = dev_get_drvdata(dev);
 -  unsigned long flags;
 -  int err;

Re: [PATCH ftrace/core v6 5/5] kselftest, ftrace: Add ftrace IPMODIFY flag test

[Steven Rostedt]

On Mon, 24 Nov 2014 11:50:06 +0900
Masami Hiramatsu  wrote:

> (2014/11/22 6:03), Steven Rostedt wrote:
> > On Fri, 21 Nov 2014 05:25:37 -0500
> > Masami Hiramatsu  wrote:
> > 
> >> Add ftrace IPMODIFY flag test to selftest/ftrace. The
> >> test checks simple ftrace handler insertion and
> >> combinations of ftrace, kprobe, and jprobe.
> >> This test requires kernel build tree to build a test
> >> kernel module and root privilege to run.
> >>
> >> Signed-off-by: Masami Hiramatsu 
> >>
> >> ---
> > 
> > Can you make it so that make O=/path/to/build works?
> 
> Hmm, I always use "O=builddir" option in my build script...

But do you use O=builddir where builddir is where the kernel was built?
I don't.

Remember, I build on a server and install on a test box. The server
directory is read only. I can not have O= be the path to where the
kernel was built. I have to use a different directory.


> 
> > 
> > I tried running this on my test box, which has /home/rostedt mounted
> > read only from my build box, and I get this:
> 
> My case is just to keep the source tree clean, so source tree is
> still writable and builddir is under another directory in /home//.
> 
> 
> > [root@bxtest ftrace]# make O=/tmp
> > for TARGET in ipmodify; do \
> > make -C $TARGET; \
> > done;
> > make[1]: Entering directory 
> > `/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify'
> > make -C /lib/modules/3.18.0-rc1-test+/build 
> > M=/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify 
> > ipmodify.ko
> > make[2]: Entering directory `/home/rostedt/work/git/nobackup/bxtest/trace'
> >   CC [M]  
> > /work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify/ipmodify.o
> > /bin/sh: ./scripts/recordmcount: Permission denied
> 
> Hmm, this error looks odd, not ENOENT but EPERM??
> Could you run it again with V=1 ?

Sure, here's the output:

[root@bxtest ftrace]# make V=1 O=/tmp
for TARGET in ipmodify; do \
make -C $TARGET; \
done;
make[1]: Entering directory 
`/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify'
make -C /lib/modules/3.18.0-rc1-test+/build 
M=/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify ipmodify.ko
make[2]: Entering directory `/home/rostedt/work/git/nobackup/bxtest/trace'
make -C /home/rostedt/work/git/linux-trace.git 
O=/home/rostedt/work/git/nobackup/bxtest/trace/. ipmodify.ko
make -C /home/rostedt/work/git/nobackup/bxtest/trace 
KBUILD_SRC=/home/rostedt/work/git/linux-trace.git \
-f /home/rostedt/work/git/linux-trace.git/Makefile ipmodify.ko
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are 
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix 
it.";  \
echo >&2 ;  \
/bin/false)
mkdir -p 
/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify/.tmp_versions 
; rm -f 
/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify/.tmp_versions/*
make KBUILD_MODULES=1   \
-f /home/rostedt/work/git/linux-trace.git/scripts/Makefile.build 
obj=/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify ipmodify.o
  gcc 
-Wp,-MD,/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify/.ipmodify.o.d
  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include 
-I/home/rostedt/work/git/linux-trace.git/arch/x86/include 
-Iarch/x86/include/generated  -I/home/rostedt/work/git/linux-trace.git/include 
-Iinclude -I/home/rostedt/work/git/linux-trace.git/arch/x86/include/uapi 
-Iarch/x86/include/generated/uapi 
-I/home/rostedt/work/git/linux-trace.git/include/uapi -Iinclude/generated/uapi 
-include /home/rostedt/work/git/linux-trace.git/include/linux/kconfig.h   
-I/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify 
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs 
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration 
-Wno-format-security -m64 -mno-80387 -mno-fp-ret-in-387 -mtune=generic 
-mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args 
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 
-DCONFIG_AS_FXSAVE
 Q=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe 
-Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 
-mno-3dnow -mno-avx -fno-delete-null-pointer-checks -Os 
-Wno-maybe-uninitialized --param=allow-store-data-races=0 
-Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable 
-fno-omit-frame-pointer -fno-optimize-sibling-calls 
-fno-var-tracking-assignments -g -pg -mfentry -DCC_USING_FENTRY 
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow 
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes 

Re: [PATCH V3] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA

[Adam Williamson]

On Mon, 2014-11-24 at 10:39 +0800, Li, Aubrey wrote:
> On 2014/11/23 21:22, Lan Tianyu wrote:
> > ACPI 5.0 introduces _DEP to designate device objects that OSPM should
> > assign a higher priority in start ordering due to future operation region
> > accesses.
> > 
> > On Asus T100TA, ACPI battery info are read from a I2C slave device via
> > I2C operation region. Before I2C operation region handler is installed,
> > battery _STA always returns 0. There is a _DEP method of designating
> > start order under battery device node.
> > 
> > This patch is to implement _DEP feature to fix battery issue on the Asus 
> > T100TA.
> > Introducing acpi_dep_list and adding dep_unmet count in the struct
> > acpi_device. During ACPI namespace scan, create struct acpi_dep_data for a
> > valid pair of master (device pointed to by _DEP)/slave(device with _DEP), 
> > record
> > master's and slave's ACPI handle in it and put it into acpi_dep_list. The 
> > dep_unmet
> > count will increase by one if there is a device under its _DEP. Driver's 
> > probe() should
> > return EPROBE_DEFER when find dep_unmet is larger than 0. When I2C operation
> > region handler is installed, remove all struct acpi_dep_data on the 
> > acpi_dep_list
> > whose master is pointed to I2C host controller and decrease slave's 
> > dep_unmet.
> > When dep_unmet decreases to 0, all _DEP conditions are met and then do 
> > acpi_bus_attach()
> > for the device in order to resolve battery _STA issue on the Asus T100TA.
> 
> Well, Can we explicitly tied this up with ASUS T100TA in the code?
> If I understand correctly, the assumption in the patch is that the
> battery device only depends on I2C device, which is true on ASUS T100TA,
> but may not on the other platforms.
> 
> This patch does not work on a box I have, on it _DEP contains I2C and GPIO.
> 
> Device (BATC)
> {
> Name (_HID, EisaId ("PNP0C0A"))  // _HID: Hardware ID
> snip
> Name (_DEP, Package (0x03)  // _DEP: Dependencies
> {
> I2C1,
> GPO2,
> GPO0
> })
> 
> Thanks,
> -Aubrey

It certainly works for more than *just* the T100 - fedlet users have
reported working battery status on at least the Miix 2 and Venue 8 Pro
(I can personally confirm it works on the Venue 8 Pro). However, Bastien
Nocera reported failure on an Onda v975w with a slightly earlier version
of the patch in the bug report -
https://bugzilla.kernel.org/show_bug.cgi?id=69011#c58 , "Tested with the
same patch on a Onda v975w, and it tries very hard to detect the battery
but fails."
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Block layer projects that I haven't had time for

[Kent Overstreet]

Since I'm starting to resign myself to the fact that I'm probably not going to
have much time for upstream development again any time soon, I figured maybe I
should try writing down all the things I was working on or planning on working
on in case someone else is feeling ambitious and looking for things to work on.

If anyone wants to take up any of this stuff, feel free to take my half baked
code and do whatever you want with it, or ping me for ideas/guidance.

 - immutable biovecs went in, but what this was leading up to was making
   generic_make_request() accept arbitrary size bios, and pushing the splitting
   down to the drivers or wherever it's required.

   This is a performance win, and a big reduction in complexity and allows a lot
   of code to be deleted. The performance win is because bio_add_page() doesn't
   have to check anything except "does this page fit in the current bio" -
   checking queue limits is like multiple cache misses. That stuff isn't checked
   until the driver level - when the relevant stuff is going to be in cache
   anyways - and usually bios won't have to be split. If they do have to be
   split, it's quite cheap now.

   I actually benchmarked the impact of this with fio on a micron p320h, it's
   definitely a measurable impact.

   It's also the last thing needed for the dio rewrite I was working on (god,
   who knows when I'll have time for _that_, the code is mostly done :/) - and
   the performance impact of that is _very_ significant.

 - making generic_make_request() take arbitrary size bios means we can delete
   merge_bvec_fn, which deletes over 1k loc. This is done in my tree, needs
   rebasing and testing.

 - kill bio->bi_cnt

   I added bi_remaning and bio_chain() awhile back - but now we have two atomic
   refcounts in struct bio and really we don't need both, bi_remaining is more
   general.

   If you grep there aren't that many uses of bio_get(), most of them are
   straightforward to get rid of but there were one or two tricky ones. Don't
   remember which ones, though.

 - plugging

   that code in generic_make_request() that turns recursion into iteration - if
   you squint, what's really going on is that it's another plugging
   implementation.

   What I'd like to do (only started playing with this) is rework the existing
   plugging to work in terms of bios, not requests - I think this would simplify
   things, and would allow non request based drivers to take advantage of
   plugging (it'd be useful for icache if nothing else).

   Then, replace the open coded plugging in generic_make_request() with a normal
   plug, and in the scheduler hook (where right now we would recurse and
   potentially blow the stack if we did this) - check the current stack usage,
   and if it's over some threshold punt the bios to per request queue
   workqueues.

   If anyone remembers the hack I added to bio_alloc_bioset() awhile back (where
   if we're about to block on allocating from the mempool, we punt any bios
   stranded on current->bio_list to workqueues - so as to avoid deadlocking) -
   this would actually replace that hack.

 - multipage bvecs

   I did a lot of the work to implement this _ages_ ago, it turns out to not be
   that bad it terms of amount of code that has to be changed. The trick is, we
   just add a new bio_for_each_page() macro - analagous to
   bio_for_each_segment() - that iterates over each page in a bvec separately;
   that way we don't have to modify all the code that expects bios to contain
   single pages.

   One of the reasons this is nice is because we can move segment merging up to
   bio_add_page(). Conceptually, right now we're breaking an IO up into single
   page segments to submit it in only for the lower layers to undo that work,
   and merge the segments back together. It's a lot simpler to just submit IOs
   with segments already merged; this does mean that a driver (when it calls
   blk_bio_map_sg()) will potentially have to split segments that are too big
   for the device limits, but remember we want to push bio splitting down to the
   driver anyways so this is actually completely trivial - the model is just
   that the driver incrementally consumes the bio/request.

   This is nice for the upper layers in small ways too, and might help to enable
   other changes we want but I have only a hazy idea of what those might be.
 
 - my dio rewrite, if anyone is feeling really ambitious

If anyone wants to take a look at my (mostly mostly quite messy, and out of
date) in progress work - it's in a branch:

http://evilpiepirate.org/git/linux-bcache.git block_stuff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/md: use proper rcu accessor

[Mike Snitzer]

On Sun, Nov 23 2014 at 12:34pm -0500,
Eric Dumazet  wrote:

> From: Eric Dumazet 
> 
> rcu_dereference() should be used in sections protected by rcu_read_lock.
> 
> For writers, holding some kind of mutex or lock,
> rcu_dereference_protected() is the way to go, adding explicit lockdep
> bits.
> 
> In __unbind(), we are the last user of this mapped device, so can use
> the constant '1' instead of a lockdep_is_held(), not consistent with
> other uses of rcu_dereference_protected() which use md->suspend_lock
> mutex.
> 
> Reported-by: Kirill A. Shutemov 
> Signed-off-by: Eric Dumazet 
> Fixes: 33423974bfc1 ("dm: Use rcu_dereference() for accessing rcu pointer")
> Cc: Pranith Kumar 
> Cc: Mike Snitzer 

Thanks, I've staged this for 3.19:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-for-3.19=a12f5d48bdfeb5fe10157ac01c3de29269f457c6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] Btrfs deadlock fix

[Benjamin Herrenschmidt]

On Sun, 2014-11-23 at 19:27 -0500, Chris Mason wrote:
> This should be from CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y.  I do test
> with this on here, but I'll look it over for ppc related fun.
> 
> The deadlock fix from this pull shouldn't be related.  Just to make 
> sure I read your email right, this stall isn't new with rc6 is it?

No, I observed it with -rc4 which is the first 3.18 I tried on this
specific machine. I can try to bisect but it will take a while, it
didn't happen afaik with 3.17

Cheers,
Ben.


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

Re: [PATCH net-net 0/4] Increase the limit of tuntap queues

[Jason Wang]

On 11/23/2014 06:46 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 19, 2014 at 10:44:27PM +0200, Michael S. Tsirkin wrote:
>> > On Wed, Nov 19, 2014 at 03:16:28PM -0500, David Miller wrote:
>>> > > From: Pankaj Gupta 
>>> > > Date: Tue, 18 Nov 2014 21:52:54 +0530
>>> > > 
 > > > - Accept maximum number of queues as sysctl param so that any user 
 > > > space 
 > > >   application like libvirt can use this value to limit number of 
 > > > queues. Also
 > > >   Administrators can specify maximum number of queues by updating 
 > > > this sysctl
 > > >   entry.
>>> > > 
>>> > > This is the only part I don't like.
>>> > > 
>>> > > Just let whoever has privileges to configure the tun device shoot
>>> > > themselves in the foot if they want to by configuring "too many"
>>> > > queues.
>>> > > 
>>> > > If the virtual entity runs itself out of resources by doing something
>>> > > stupid, it's purely their problem.
>> > 
>> > Well it will run host out of kernel, no?
> To clarify:
>
> At the moment attaching/detaching queues is an unpriveledged operation.
>
> Shouldn't we worry that an application can cause large
> allocations, and provide a way to limit these?

But creating new queues (TUNSETIFF) is privileged. There's no way for
unprivileged user to allocate more resources. So we are safe here?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next 2/2] r8152: use ECM mode for unsupported chips

[Hayes Wang]

Use usbnet_cdc_bind to initialize the chips which the driver doesn't
support yet, if the cdc_ether is set.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 92 ++---
 1 file changed, 87 insertions(+), 5 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2d1c77e..9989e5b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -25,9 +25,10 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Version Information */
-#define DRIVER_VERSION "v1.07.0 (2014/10/09)"
+#define DRIVER_VERSION "v1.08.0 (2014/11/24)"
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
 #define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters"
 #define MODULENAME "r8152"
@@ -3219,12 +3220,24 @@ static void r8153_init(struct r8152 *tp)
rtl_tally_reset(tp);
 }
 
+static bool rtl_vendor_mode(struct usb_interface *intf)
+{
+   struct usb_host_interface *alt = intf->cur_altsetting;
+
+   return alt->desc.bInterfaceClass == USB_CLASS_VENDOR_SPEC;
+}
+
 static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
 {
struct r8152 *tp = usb_get_intfdata(intf);
struct net_device *netdev = tp->netdev;
int ret = 0;
 
+#if defined(CONFIG_USB_NET_CDCETHER) || defined(CONFIG_USB_NET_CDCETHER_MODULE)
+   if (!rtl_vendor_mode(intf))
+   return usbnet_suspend(intf, message);
+#endif /* CONFIG_USB_NET_CDCETHER */
+
mutex_lock(>control);
 
if (PMSG_IS_AUTO(message)) {
@@ -3261,6 +3274,11 @@ static int rtl8152_resume(struct usb_interface *intf)
 {
struct r8152 *tp = usb_get_intfdata(intf);
 
+#if defined(CONFIG_USB_NET_CDCETHER) || defined(CONFIG_USB_NET_CDCETHER_MODULE)
+   if (!rtl_vendor_mode(intf))
+   return usbnet_resume(intf);
+#endif /* CONFIG_USB_NET_CDCETHER */
+
mutex_lock(>control);
 
if (!test_bit(SELECTIVE_SUSPEND, >flags)) {
@@ -3742,6 +3760,17 @@ static void r8152b_get_version(struct r8152 *tp)
}
 }
 
+static bool rtl_supported(struct usb_device *udev)
+{
+   struct r8152 fake;
+
+   memset(, 0, sizeof(fake));
+   fake.udev = udev;
+   r8152b_get_version();
+
+   return fake.version != RTL_VER_UNKNOWN;
+}
+
 static void rtl8152_unload(struct r8152 *tp)
 {
if (test_bit(RTL8152_UNPLUG, >flags))
@@ -3803,13 +3832,28 @@ static int rtl8152_probe(struct usb_interface *intf,
 const struct usb_device_id *id)
 {
struct usb_device *udev = interface_to_usbdev(intf);
+   bool support = rtl_supported(udev);
struct r8152 *tp;
struct net_device *netdev;
-   int ret;
+   int ret = -ENODEV;
 
-   if (udev->actconfig->desc.bConfigurationValue != 1) {
-   usb_driver_set_configuration(udev, 1);
-   return -ENODEV;
+   if (!rtl_vendor_mode(intf)) {
+   if (support)
+   usb_driver_set_configuration(udev, 1);
+#if defined(CONFIG_USB_NET_CDCETHER) || defined(CONFIG_USB_NET_CDCETHER_MODULE)
+   else
+   ret = usbnet_probe(intf, id);
+#endif /* CONFIG_USB_NET_CDCETHER */
+
+   return ret;
+   } else if (!support) {
+   /* The driver doesn't support this chip yet.
+* Try to use cdc_ether.
+*/
+#if defined(CONFIG_USB_NET_CDCETHER) || defined(CONFIG_USB_NET_CDCETHER_MODULE)
+   usb_driver_set_configuration(udev, 2);
+#endif /* CONFIG_USB_NET_CDCETHER */
+   return ret;
}
 
usb_reset_device(udev);
@@ -3899,6 +3943,13 @@ static void rtl8152_disconnect(struct usb_interface 
*intf)
 {
struct r8152 *tp = usb_get_intfdata(intf);
 
+#if defined(CONFIG_USB_NET_CDCETHER) || defined(CONFIG_USB_NET_CDCETHER_MODULE)
+   if (!rtl_vendor_mode(intf)) {
+   usbnet_disconnect(intf);
+   return;
+   }
+#endif /* CONFIG_USB_NET_CDCETHER */
+
usb_set_intfdata(intf, NULL);
if (tp) {
struct usb_device *udev = tp->udev;
@@ -3913,6 +3964,35 @@ static void rtl8152_disconnect(struct usb_interface 
*intf)
}
 }
 
+#if defined(CONFIG_USB_NET_CDCETHER) || defined(CONFIG_USB_NET_CDCETHER_MODULE)
+static const struct driver_infocdc_info = {
+   .description =  "r815x CDC Ethernet Device",
+   .flags =FLAG_ETHER | FLAG_POINTTOPOINT,
+   .bind = usbnet_cdc_bind,
+   .unbind =   usbnet_cdc_unbind,
+   .status =   usbnet_cdc_status,
+   .manage_power = usbnet_manage_power,
+};
+
+#define REALTEK_USB_DEVICE(vend, prod) \
+   .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
+  USB_DEVICE_ID_MATCH_INT_CLASS, \
+   .idVendor = (vend), \
+   .idProduct = (prod), \
+   .bInterfaceClass = USB_CLASS_VENDOR_SPEC \
+}, \
+{ \
+   .match_flags = USB_DEVICE_ID_MATCH_INT_INFO | \
+  

[PATCH net-next 0/2] r8152: use ECM mode for future chips

[Hayes Wang]

For the future chips which the r8152 doesn't support yet, we could
still use ECM mode for basic transmission.

Hayes Wang (2):
  r8152: redefine REALTEK_USB_DEVICE
  r8152: use ECM mode for unsupported chips

 drivers/net/usb/r8152.c | 118 +++-
 1 file changed, 107 insertions(+), 11 deletions(-)

-- 
1.9.3

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

[PATCH net-next 1/2] r8152: redefine REALTEK_USB_DEVICE

[Hayes Wang]

Redefine REALTEK_USB_DEVICE for the desired USB interface for probe().
There are three USB interfaces for the device. USB_CLASS_COMM and
USB_CLASS_CDC_DATA are for ECM mode (config #2). USB_CLASS_VENDOR_SPEC
is for the vendor mode (config #1). However, we are not interesting
in USB_CLASS_CDC_DATA for probe(), so redefine REALTEK_USB_DEVICE
to ignore the USB interface class of USB_CLASS_CDC_DATA.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4a9ece0..2d1c77e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Version Information */
 #define DRIVER_VERSION "v1.07.0 (2014/10/09)"
@@ -466,9 +467,6 @@ enum rtl8152_flags {
 #define MCU_TYPE_PLA   0x0100
 #define MCU_TYPE_USB   0x
 
-#define REALTEK_USB_DEVICE(vend, prod) \
-   USB_DEVICE_INTERFACE_CLASS(vend, prod, USB_CLASS_VENDOR_SPEC)
-
 struct tally_counter {
__le64  tx_packets;
__le64  rx_packets;
@@ -3915,11 +3913,27 @@ static void rtl8152_disconnect(struct usb_interface 
*intf)
}
 }
 
+#define REALTEK_USB_DEVICE(vend, prod) \
+   .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
+  USB_DEVICE_ID_MATCH_INT_CLASS, \
+   .idVendor = (vend), \
+   .idProduct = (prod), \
+   .bInterfaceClass = USB_CLASS_VENDOR_SPEC \
+}, \
+{ \
+   .match_flags = USB_DEVICE_ID_MATCH_INT_INFO | \
+  USB_DEVICE_ID_MATCH_DEVICE, \
+   .idVendor = (vend), \
+   .idProduct = (prod), \
+   .bInterfaceClass = USB_CLASS_COMM, \
+   .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET, \
+   .bInterfaceProtocol = USB_CDC_PROTO_NONE
+
 /* table of devices that work with this driver */
 static struct usb_device_id rtl8152_table[] = {
-   {USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
-   {USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
-   {USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
{}
 };
 
-- 
1.9.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 7/7] mm/page_owner: correct owner information for early allocated pages

[Joonsoo Kim]

On Fri, Nov 21, 2014 at 03:38:41PM -0800, Andrew Morton wrote:
> On Fri, 21 Nov 2014 17:14:06 +0900 Joonsoo Kim  wrote:
> 
> > Extended memory to store page owner information is initialized some time
> > later than that page allocator starts. Until initialization, many pages
> > can be allocated and they have no owner information. This make debugging
> > using page owner harder, so some fixup will be helpful.
> > 
> > This patch fix up this situation by setting fake owner information
> > immediately after page extension is initialized. Information doesn't
> > tell the right owner, but, at least, it can tell whether page is
> > allocated or not, more correctly.
> > 
> > On my testing, this patch catches 13343 early allocated pages, although
> > they are mostly allocated from page extension feature. Anyway, after then,
> > there is no page left that it is allocated and has no page owner flag.
> 
> We really should have a Documentation/vm/page_owner.txt which explains
> all this stuff, provides examples, etc.

Okay. Will do in next spin.

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

RE: [PATCH v11 00/19] input: cyapa: instruction of cyapa patches

[Dudley Du]

Jeremiah,

Thank you very much for your information.
I will look into this issue.
Could you send me the system log if possible when you encounter this issue.

Thanks
Dudley

> -Original Message-
> From: Jeremiah Mahler [mailto:jmmah...@gmail.com]
> Sent: 2014?11?21? 16:56
> To: Dudley Du
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v11 00/19] input: cyapa: instruction of cyapa patches
> 
> Dudley,
> 
> On Wed, Nov 19, 2014 at 04:37:32PM +0800, Dudley Du wrote:
> > V11 patches have below main updates compared with v10 patches:
> > 1) Add add acpi device id supported for old gen3 and new gen5 trackpad
devices.
> > 2) Fix the unable to update firmware issue when cyapa_open is not called
> >which means the irq for firwmare update process is not enabled. This fix
> []
> 
> I am having a problem with an older patch which is currently in
> linux-next (20141120) and which might be related to this new patch set.
> 
> On an Acer C720 if a suspend and resume is performed the touchpad will
> stop working.  If the cyapa driver is reloaded it will begin working
> again.
> 
> I performed a bisect and found that the following patch was the cause.
> 
>   From b1cfa7b4388285c0f0b486f152ab0cb18612c779 Mon Sep 17 00:00:00 2001
>   From: Dudley Du 
>   Date: Sun, 9 Nov 2014 12:36:34 -0800
>   Subject: [PATCH] Input: cyapa - switch to using managed resources
> 
>   Use of managed resources simplifies error handling and device removal
>   code.
> 
>   Signed-off-by: Dudley Du 
>   [Dmitry: added open/close methods so cyapa_remove is no longer needed.]
>   Signed-off-by: Dmitry Torokhov 
> 
> If I can provide any other information that would be of help let me know.
> I will try out your new patchset if I get a chance.
> 
> --
> - Jeremiah Mahler

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

Re: [PATCH v2 6/7] mm/page_owner: keep track of page owners

[Joonsoo Kim]

On Fri, Nov 21, 2014 at 03:38:32PM -0800, Andrew Morton wrote:
> On Fri, 21 Nov 2014 17:14:05 +0900 Joonsoo Kim  wrote:
> 
> > This is the page owner tracking code which is introduced
> > so far ago. It is resident on Andrew's tree, though, nobody
> > tried to upstream so it remain as is. Our company uses this feature
> > actively to debug memory leak or to find a memory hogger so
> > I decide to upstream this feature.
> > 
> > This functionality help us to know who allocates the page.
> > When allocating a page, we store some information about
> > allocation in extra memory. Later, if we need to know
> > status of all pages, we can get and analyze it from this stored
> > information.
> > 
> > In previous version of this feature, extra memory is statically defined
> > in struct page, but, in this version, extra memory is allocated outside
> > of struct page. It enables us to turn on/off this feature at boottime
> > without considerable memory waste.
> > 
> > Although we already have tracepoint for tracing page allocation/free,
> > using it to analyze page owner is rather complex. We need to enlarge
> > the trace buffer for preventing overlapping until userspace program
> > launched. And, launched program continually dump out the trace buffer
> > for later analysis and it would change system behaviour with more
> > possibility rather than just keeping it in memory, so bad for debug.
> > 
> > Moreover, we can use page_owner feature further for various purposes.
> > For example, we can use it for fragmentation statistics implemented in
> > this patch. And, I also plan to implement some CMA failure debugging
> > feature using this interface.
> > 
> > I'd like to give the credit for all developers contributed this feature,
> > but, it's not easy because I don't know exact history. Sorry about that.
> > Below is people who has "Signed-off-by" in the patches in Andrew's tree.
> > 
> > ...
> >
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -884,6 +884,12 @@ bytes respectively. Such letter suffixes can also be 
> > entirely omitted.
> > MTRR settings.  This parameter disables that behavior,
> > possibly causing your machine to run very slowly.
> >  
> > +   disable_page_owner
> > +   [KNL] Disable to store the information who requests
> > +   the page.
> 
> How about "Disable storage of the information about who allocated each
> page".
> 
> It seems odd that we have a disable flag.  Wouldn't it be less
> surprising to disable it by default and only enable if the boot option
> is provided?

Okay. Will do.

> 
> What is the overhead of page_owner if it is runtime-disabled, btw? 
> Will it be feasible for lots of people to just leave it enabled in
> config and to only turn it on when they want to use it?  That would be
> nice.  Please add a paragraph on this point to the changelog and the
> yet-to-be-written documentation.

- Without page owner
   textdata bss dec hex filename
  406621493 644   42799a72f mm/page_alloc.o

- With page owner
   textdata bss dec hex filename
  408921493 644   43029a815 mm/page_alloc.o
   1427  24   81459 5b3 mm/page_ext.o
   2722  50   02772 ad4 mm/page_owner.o

Roughly, 4 KB code is added in total. No more runtime memory is needed if
runtime-disabled. Size of page_alloc.o is 200 bytes bigger than disabled one.
Page owner addes two 'if' statements in allocator hotpath and two 'if'
statements in coldpath. If runtime-disabled, allocation performance would not
be affected by these few unlikely branches.

Will write this to yet-to-be-written documentation.

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

[LKP] [nohz] 2a16fc93d2c:

[Yuanhan Liu]

FYI, we noticed the below changes on

commit 2a16fc93d2c9568e16d45db77c7b5f15e1921cf1 ("nohz: Avoid tick's double 
reprogramming in highres mode")


testbox/testcase/testparams: snb-drag/piglit/performance-igt-001

b5e995e671d8e4d7  2a16fc93d2c9568e16d45db77c  
  --  
   fail:runs  %reproductionfail:runs
   | | |
   :5  100%   5:5 
kmsg.drm:__gen6_gt_force_wake_get]*ERROR*Timed_out_waiting_for_forcewake_to_ack_request
   :5  100%   5:5 
piglit.igt/gem_ctx_exec/reset-pin-leak.dmesg-warn

snb-drag: Sandy Bridge
Memory: 6G


<3>[   90.915459] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   90.925094] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   90.934725] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   90.944347] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   90.953956] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   90.963559] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   90.973173] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   90.982793] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   90.992405] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   91.002008] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   91.011618] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   91.021222] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   91.030825] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   91.040430] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   91.050016] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   91.059593] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.
<3>[   91.069152] [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for 
forcewake to ack request.


To reproduce:

apt-get install ruby ruby-oj
git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local   job.yaml


Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.


--yliu
---
testcase: piglit
default_monitors:
  wait: pre-test
  vmstat: 
default_watchdogs:
  watch-oom: 
  watchdog: 
cpufreq_governor:
- performance
commit: 9bdebfefe1de2b6fa7e193c10411ef209b0ebc96
model: Sandy Bridge
memory: 6G
hdd_partitions: "/dev/disk/by-id/ata-ST3750528AS_6VP2W0PA-part5 
/dev/disk/by-id/ata-ST3750528AS_6VP2W0PA-part6
  /dev/disk/by-id/ata-ST3750528AS_6VP2W0PA-part7 
/dev/disk/by-id/ata-ST3750528AS_6VP2W0PA-part8
  /dev/disk/by-id/ata-ST3750528AS_6VP2W0PA-part9 
/dev/disk/by-id/ata-ST3750528AS_6VP2W0PA-part10"
swap_partitions: 
rootfs_partition: "/dev/disk/by-id/ata-ST3750528AS_6VP2W0PA-part2"
timeout: 30m
piglit:
  group:
  - igt-001
enqueue_time: 2014-10-27 03:51:37.871425766 +08:00
testbox: snb-drag
tbox_group: snb-drag
kconfig: x86_64-rhel
head_commit: 9bdebfefe1de2b6fa7e193c10411ef209b0ebc96
base_commit: cac7f2429872d3733dc3f9915857b1691da2eb2f
branch: linux-devel/devel-hourly-2014103002
kernel: 
"/kernel/x86_64-rhel/9bdebfefe1de2b6fa7e193c10411ef209b0ebc96/vmlinuz-3.18.0-rc2-g9bdebfe"
user: lkp
queue: cyclic
rootfs: debian-x86_64.cgz
result_root: 
"/result/snb-drag/piglit/performance-igt-001/debian-x86_64.cgz/x86_64-rhel/9bdebfefe1de2b6fa7e193c10411ef209b0ebc96/0"
job_file: 
"/lkp/scheduled/snb-drag/cyclic_piglit-performance-igt-001-x86_64-rhel-HEAD-9bdebfefe1de2b6fa7e193c10411ef209b0ebc96-0.yaml"
dequeue_time: 2014-10-30 03:46:50.534182476 +08:00
job_state: finished
loadavg: 0.62 0.46 0.25 1/96 9645
start_time: '1414612069'
end_time: '1414612536'
version: "/lkp/lkp/.src-20141029-214343"
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
piglit run igt -t igt/drv_hangman/error-state-capture-bsd 
/lkp/lkp/src/tmp/piglit-results-0
piglit summary console /lkp/lkp/src/tmp/piglit-results-0
piglit run igt -t 

Re: [PATCH v2 5/7] stacktrace: introduce snprint_stack_trace for buffer output

[Joonsoo Kim]

On Fri, Nov 21, 2014 at 03:37:59PM -0800, Andrew Morton wrote:
> On Fri, 21 Nov 2014 17:14:04 +0900 Joonsoo Kim  wrote:
> 
> > Current stacktrace only have the function for console output.
> > page_owner that will be introduced in following patch needs to print
> > the output of stacktrace into the buffer for our own output format
> > so so new function, snprint_stack_trace(), is needed.
> > 
> > ...
> >
> > --- a/include/linux/stacktrace.h
> > +++ b/include/linux/stacktrace.h
> > @@ -20,6 +20,8 @@ extern void save_stack_trace_tsk(struct task_struct *tsk,
> > struct stack_trace *trace);
> >  
> >  extern void print_stack_trace(struct stack_trace *trace, int spaces);
> > +extern int  snprint_stack_trace(char *buf, int buf_len,
> > +   struct stack_trace *trace, int spaces);
> >  
> >  #ifdef CONFIG_USER_STACKTRACE_SUPPORT
> >  extern void save_stack_trace_user(struct stack_trace *trace);
> > @@ -32,6 +34,7 @@ extern void save_stack_trace_user(struct stack_trace 
> > *trace);
> >  # define save_stack_trace_tsk(tsk, trace)  do { } while (0)
> >  # define save_stack_trace_user(trace)  do { } while (0)
> >  # define print_stack_trace(trace, spaces)  do { } while (0)
> > +# define snprint_stack_trace(buf, len, trace, spaces)  do { } while (0)
> 
> Doing this with macros instead of C functions is pretty crappy - it
> defeats typechecking and can lead to unused-var warnings when the
> feature is disabled.
> 
> Fixing this might not be practical if struct stack_trace isn't
> available, dunno.

struct stack_trace is defined only if CONFIG_STACKTRACE, and,
most call sites seems to be defined only if CONFIG_STACKTRACE.
I guess that removing all of them would works fine, but, dunno. :)

> 
> > --- a/kernel/stacktrace.c
> > +++ b/kernel/stacktrace.c
> > @@ -25,6 +25,30 @@ void print_stack_trace(struct stack_trace *trace, int 
> > spaces)
> >  }
> >  EXPORT_SYMBOL_GPL(print_stack_trace);
> >  
> > +int snprint_stack_trace(char *buf, int buf_len, struct stack_trace *trace,
> > +   int spaces)
> > +{
> > +   int i, printed;
> > +   unsigned long ip;
> > +   int ret = 0;
> > +
> > +   if (WARN_ON(!trace->entries))
> > +   return 0;
> > +
> > +   for (i = 0; i < trace->nr_entries && buf_len; i++) {
> > +   ip = trace->entries[i];
> > +   printed = snprintf(buf, buf_len, "%*c[<%p>] %pS\n",
> > +   1 + spaces, ' ', (void *) ip, (void *) ip);
> > +
> > +   buf_len -= printed;
> > +   ret += printed;
> > +   buf += printed;
> > +   }
> > +
> > +   return ret;
> > +}
> 
> I'm not liking this much.  The behaviour when the output buffer is too
> small is scary.  snprintf() will return "the number of characters which
> would be generated for the given input", so local variable `buf_len'
> will go negative and we pass a negative int into snprintf()'s `size_t
> size'.  snprintf() says "goody, lots and lots of buffer!" and your
> machine crashes.
> 
> buf_len should be a size_t and snprint_stack_trace() will need to be
> changed to handle this.

Okay. I will fix overflow problem. And, current implementation doesn't
comply snprint* functions sementic that returns generated string
length rather than printed string length. I will fix it, too.

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

[LKP] [x86, irq, ACPI] 5fcb864ef90: -3.3%(vm-scalability.throughput) +12.9%(turbostat.%c0)

[Yuanhan Liu]

Hi,

We noticed the below changes on(NOTE: I'm not sure the bisect is correct
or not, here I report it out JFYI).

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 5fcb864ef90df093d964171539c87ffa0ab49f0f ("x86, irq, ACPI: Implement 
interfaces to support ACPI based IOAPIC hot-removal")


testbox/testcase/testparams: 
lkp-nex06/vm-scalability/performance-300s-small-allocs-mt

ff6213974cd90e1e  5fcb864ef90df093d964171539  
  --  
   fail:runs  %reproductionfail:runs
   | | |
   :5   20%   1:5 
kmsg.CE:hpet_increased_min_delta_ns_to#nsec
 %stddev %change %stddev
 \  |\  
315326 ±  0%  -3.3% 304841 ±  0%  vm-scalability.throughput
 11.82 ±  0% +12.9%  13.34 ±  0%  turbostat.%c0
  1.34 ±  0%  +9.4%   1.46 ±  0%  turbostat.GHz
12 ± 47% +78.7% 21 ± 32%  sched_debug.cfs_rq[29]:/.load
   113 ± 26% +86.3%212 ± 28%  
sched_debug.cfs_rq[39]:/.tg_load_contrib
   106 ± 28% +89.5%202 ± 30%  
sched_debug.cfs_rq[39]:/.blocked_load_avg
66 ± 23%+120.6%145 ± 29%  
sched_debug.cfs_rq[40]:/.blocked_load_avg
70 ± 23%+113.0%150 ± 29%  
sched_debug.cfs_rq[40]:/.tg_load_contrib
 10145 ± 23% -38.3%   6255 ± 35%  numa-meminfo.node1.AnonPages
  2535 ± 23% -38.3%   1564 ± 35%  numa-vmstat.node1.nr_anon_pages
   605 ± 16% -22.0%471 ±  5%  
sched_debug.cpu#58.nr_uninterruptible
 58904 ±  7% -13.8%  50762 ±  7%  
sched_debug.cfs_rq[0]:/.min_vruntime
481299 ±  8% -13.4% 416975 ±  7%  sched_debug.cpu#0.sched_count
409009 ± 11% -15.7% 344638 ±  2%  sched_debug.cpu#4.sched_count
 52022 ± 10% -16.1%  43623 ±  2%  
sched_debug.cfs_rq[4]:/.min_vruntime
68 ±  3% -12.2% 60 ±  3%  
sched_debug.cfs_rq[4]:/.tg_runnable_contrib
  3175 ±  3% -12.1%   2791 ±  3%  
sched_debug.cfs_rq[4]:/.avg->runnable_avg_sum
 50060 ±  6% -12.3%  43914 ±  4%  
sched_debug.cfs_rq[29]:/.min_vruntime
  1751 ± 12% -15.5%   1480 ±  6%  
sched_debug.cpu#63.nr_uninterruptible
  2967 ±  6% -13.7%   2562 ±  4%  
sched_debug.cfs_rq[37]:/.avg->runnable_avg_sum
63 ±  6% -13.8% 55 ±  4%  
sched_debug.cfs_rq[37]:/.tg_runnable_contrib
  1.07 ±  2% -10.9%   0.95 ±  3%  
perf-profile.cpu-cycles.tick_nohz_restart.tick_nohz_idle_exit.cpu_startup_entry.start_secondary
  1.64 ±  2%  -8.4%   1.50 ±  4%  
perf-profile.cpu-cycles.__tick_nohz_idle_enter.tick_nohz_idle_enter.cpu_startup_entry.start_secondary
 35173 ±  5%  -9.1%  31983 ±  3%  
sched_debug.cfs_rq[56]:/.min_vruntime
  1.41 ±  2%  -8.3%   1.29 ±  4%  
perf-profile.cpu-cycles.tick_nohz_stop_sched_tick.__tick_nohz_idle_enter.tick_nohz_idle_enter.cpu_startup_entry.start_secondary
  1.63 ±  1%  -9.3%   1.48 ±  3%  
perf-profile.cpu-cycles.tick_nohz_idle_exit.cpu_startup_entry.start_secondary
 45161 ± 11% -12.8%  39358 ±  4%  
sched_debug.cfs_rq[25]:/.min_vruntime
 39201 ±  5% +17.3%  45969 ± 18%  
sched_debug.cfs_rq[8]:/.min_vruntime
  21071502 ±  0%  -3.3%   20379730 ±  0%  time.minor_page_faults
   299 ±  0%  -3.1%290 ±  0%  time.user_time
  21763267 ±  0%  -3.3%   21055329 ±  0%  time.voluntary_context_switches
142199 ±  0%  -3.1% 137732 ±  0%  vmstat.system.cs
   737 ±  0%  -2.1%721 ±  1%  time.system_time
   341 ±  0%  -2.5%333 ±  0%  time.percent_of_cpu_this_job_got

lkp-nex06: Nehalem-EX
Memory: 64G




   turbostat.%c0

14 ++---+
   |O   |
   |  O  O   O  O  O|
  13.5 O+   O O   O  O  O O  O  |
   |  O   OO   O O  |
   | O OO
13 ++   |
   ||
  12.5 ++   |
   ||
   ||
12 *+.*...*.. .*... |
   | *..*. *..  .*...*..*..*..*...  .*..*   |
   |  *.  *.|
  11.5 

Re: [PATCH ftrace/core v6 5/5] kselftest, ftrace: Add ftrace IPMODIFY flag test

[Masami Hiramatsu]

(2014/11/22 6:03), Steven Rostedt wrote:
> On Fri, 21 Nov 2014 05:25:37 -0500
> Masami Hiramatsu  wrote:
> 
>> Add ftrace IPMODIFY flag test to selftest/ftrace. The
>> test checks simple ftrace handler insertion and
>> combinations of ftrace, kprobe, and jprobe.
>> This test requires kernel build tree to build a test
>> kernel module and root privilege to run.
>>
>> Signed-off-by: Masami Hiramatsu 
>>
>> ---
> 
> Can you make it so that make O=/path/to/build works?

Hmm, I always use "O=builddir" option in my build script...

> 
> I tried running this on my test box, which has /home/rostedt mounted
> read only from my build box, and I get this:

My case is just to keep the source tree clean, so source tree is
still writable and builddir is under another directory in /home//.


> [root@bxtest ftrace]# make O=/tmp
> for TARGET in ipmodify; do \
>   make -C $TARGET; \
> done;
> make[1]: Entering directory 
> `/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify'
> make -C /lib/modules/3.18.0-rc1-test+/build 
> M=/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify 
> ipmodify.ko
> make[2]: Entering directory `/home/rostedt/work/git/nobackup/bxtest/trace'
>   CC [M]  
> /work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify/ipmodify.o
> /bin/sh: ./scripts/recordmcount: Permission denied

Hmm, this error looks odd, not ENOENT but EPERM??
Could you run it again with V=1 ?

Thank you,

> make[5]: *** 
> [/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify/ipmodify.o]
>  Error 1
> make[4]: *** [ipmodify.ko] Error 2
> make[3]: *** [sub-make] Error 2
> make[2]: *** [__sub-make] Error 2
> make[2]: Leaving directory `/home/rostedt/work/git/nobackup/bxtest/trace'
> make[1]: *** [ipmodify.ko] Error 2
> make[1]: Leaving directory 
> `/work/git/linux-trace.git/tools/testing/selftests/ftrace/ipmodify'
> make: *** [all] Error 2
> 
> -- Steve
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

RE: [UPDATE RFC PATCH 2] ACPICA: Events: Introduce ACPI_GPE_HANDLER_RAW to fix 2 issues for the current GPE APIs.

[Zheng, Lv]

Hi,

Adding people that were disturbed by my fault previously.

You should also reply in the same thread with this validation result.
As we might need this to be the motivation for the proposal that the GPE dead 
lock issue should be fixed in a higher priority way.
I've reported this at:
https://bugs.acpica.org/show_bug.cgi?id=1100

Thanks and best regards
-Lv

> From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
> Sent: Friday, November 21, 2014 8:41 PM
> 
> On Fri, Nov 21, 2014 at 01:05:40AM +, Zheng, Lv wrote:
> > Hi, Kirill
> >
> > Please help to check again to use the updated patch.
> > Sorry for my mistake.
> >
> > I originally used a patch that will unlock before invoking all handlers.
> > But as requested by maintainers, the new ACPICA part will use a 
> > ACPI_GPE_HANDLER_RAW flag, and I updated my patch in a hurry
> for you without updating the ec.c.
> >
> > It's my fault.
> > I can also do some local confirmation before disturbing you.
> > Could you tell me how can I reproduce this?
> 
> This one seems works
> 
> --
>  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/

Re: [f2fs-dev] [PATCH 1/3] f2fs: call flush_dcache_page when the page was updated

[Changman Lee]

Hi Simon,
Thanks for your explanation kindly.

On Sun, Nov 23, 2014 at 11:08:54AM +0100, Simon Baatz wrote:
> Hi Changman, Jaegeuk,
> 
> On Thu, Nov 20, 2014 at 05:47:29PM +0900, Changman Lee wrote:
> > On Wed, Nov 19, 2014 at 10:45:33PM -0800, Jaegeuk Kim wrote:
> > > On Thu, Nov 20, 2014 at 03:04:10PM +0900, Changman Lee wrote:
> > > > Hi Jaegeuk,
> > > > 
> > > > We should call flush_dcache_page before kunmap because the purpose of 
> > > > the cache flush is to address aliasing problem related to virtual 
> > > > address.
> > > 
> > > Oh, I just followed zero_user_segments below.
> > > 
> > > static inline void zero_user_segments(struct page *page,
> > >   unsigned start1, unsigned end1,
> > >   unsigned start2, unsigned end2)
> > > {
> > >   void *kaddr = kmap_atomic(page);
> > > 
> > >   BUG_ON(end1 > PAGE_SIZE || end2 > PAGE_SIZE);
> > > 
> > >   if (end1 > start1)
> > >   memset(kaddr + start1, 0, end1 - start1);
> > > 
> > >   if (end2 > start2)
> > >   memset(kaddr + start2, 0, end2 - start2);
> > > 
> > >   kunmap_atomic(kaddr);
> > >   flush_dcache_page(page);
> > > }
> > > 
> > > Is this a wrong reference? Or, a bug?
> > > 
> > 
> > Well.. Data in cache only have to be flushed until before other users read 
> > the data.
> > If so, it's not a bug.
> > 
> 
> Yes, it is not a bug, since flush_dcache_page() needs to be able to
> deal with non-kmapped pages. However, this may create overhead in
> some situations.
> 

Previously, I was vague but I thought that it should be different
according to vaddr exists or not. So I told jaegeuk that it should
be better to change an order between flush_dache_page and kunmap.
But actually, it doesn't matter the order between them except
the situation you said.
Could you explain the situation that makes overhead by flushing after kummap.
I can't imagine it by just seeing flush_dcache_page code.

> According to documentation (see Documentation/cachetlb.txt), this is
> a use for flush_kernel_dcache_page(), since the page has been
> modified by the kernel only.  In contrast to flush_dcache_page(),
> this function must be called before kunmap().
> 
> flush_kernel_dcache_page() does not need to flush the user space
> aliases.  Additionally, at least on ARM, it does not flush at all
> when called within kmap_atomic()/kunmap_atomic(), when
> kunmap_atomic() is going to flush the page anyway.  (I know that
> almost no one uses flush_kernel_dcache_page() (probably because
> almost no one knows when to use which of the two functions), but it
> may save a few cache flushes on architectures which are affected by
> aliasing)
> 
> 
> > > Anyway I modified as below.
> > > 
> > > Thanks,
> > > 
> > > >From 7cb7b27c8cd2efc8a31d79239bef5b41c6e79216 Mon Sep 17 00:00:00 2001
> > > From: Jaegeuk Kim 
> > > Date: Tue, 18 Nov 2014 10:50:21 -0800
> > > Subject: [PATCH] f2fs: call flush_dcache_page when the page was updated
> > > 
> > > Whenever f2fs updates mapped pages, it needs to call flush_dcache_page.
> > > 
> > > Signed-off-by: Jaegeuk Kim 
> > > ---
> > >  fs/f2fs/dir.c| 7 ++-
> > >  fs/f2fs/inline.c | 2 ++
> > >  2 files changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > > index 5a49995..fabf4ee 100644
> > > --- a/fs/f2fs/dir.c
> > > +++ b/fs/f2fs/dir.c
> > > @@ -287,8 +287,10 @@ void f2fs_set_link(struct inode *dir, struct 
> > > f2fs_dir_entry *de,
> > >   f2fs_wait_on_page_writeback(page, type);
> > >   de->ino = cpu_to_le32(inode->i_ino);
> > >   set_de_type(de, inode);
> > > - if (!f2fs_has_inline_dentry(dir))
> > > + if (!f2fs_has_inline_dentry(dir)) {
> > > + flush_dcache_page(page);
> > >   kunmap(page);
> > > + }
> 
> Is this a page that may be mapped into user space? (I may be
> completely wrong here, since I have no idea how this code works.  But
> it looks like as if the answer is "no" ;-) ).
> 
> It is not necessary to flush pages that cannot be seen by user space
> (see also the NOTE in the documentation of flush_dcache_page() in
> cachetlb.txt). Thus, if you know that a page will not be mapped into
> user space, please don't create the overhead of flushing it.
> 

In the case of dentry unlike inline data, this is not mapped to user space, so 
dcache flush
makes overhead. Do you mean that?

Best regard,
Changman

> 
> - Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/7] mm/page_ext: resurrect struct page extending code for debugging

[Joonsoo Kim]

On Fri, Nov 21, 2014 at 03:37:31PM -0800, Andrew Morton wrote:
> On Fri, 21 Nov 2014 17:14:00 +0900 Joonsoo Kim  wrote:
> 
> > When we debug something, we'd like to insert some information to
> > every page. For this purpose, we sometimes modify struct page itself.
> > But, this has drawbacks. First, it requires re-compile. This makes us
> > hesitate to use the powerful debug feature so development process is
> > slowed down. And, second, sometimes it is impossible to rebuild the kernel
> > due to third party module dependency. At third, system behaviour would be
> > largely different after re-compile, because it changes size of struct
> > page greatly and this structure is accessed by every part of kernel.
> > Keeping this as it is would be better to reproduce errornous situation.
> > 
> > This feature is intended to overcome above mentioned problems. This feature
> > allocates memory for extended data per page in certain place rather than
> > the struct page itself. This memory can be accessed by the accessor
> > functions provided by this code. During the boot process, it checks whether
> > allocation of huge chunk of memory is needed or not. If not, it avoids
> > allocating memory at all. With this advantage, we can include this feature
> > into the kernel in default and can avoid rebuild and solve related problems.
> > 
> > Until now, memcg uses this technique. But, now, memcg decides to embed
> > their variable to struct page itself and it's code to extend struct page
> > has been removed. I'd like to use this code to develop debug feature,
> > so this patch resurrect it.
> > 
> > To help these things to work well, this patch introduces two callbacks
> > for clients. One is the need callback which is mandatory if user wants
> > to avoid useless memory allocation at boot-time. The other is optional,
> > init callback, which is used to do proper initialization after memory
> > is allocated. Detailed explanation about purpose of these functions is
> > in code comment. Please refer it.
> > 
> > Others are completely same with previous extension code in memcg.
> >
> > ...
> >
> > +static bool __init invoke_need_callbacks(void)
> > +{
> > +   int i;
> > +   int entries = ARRAY_SIZE(page_ext_ops);
> > +
> > +   for (i = 0; i < entries; i++) {
> > +   if (page_ext_ops[i]->need && page_ext_ops[i]->need())
> > +   return true;
> > +   }
> > +
> > +   return false;
> > +}
> > +
> > +static void __init invoke_init_callbacks(void)
> > +{
> > +   int i;
> > +   int entries = sizeof(page_ext_ops) / sizeof(page_ext_ops[0]);
> 
> ARRAY_SIZE()

Oops... Sorry. I will fix it.

> 
> > +   for (i = 0; i < entries; i++) {
> > +   if (page_ext_ops[i]->init)
> > +   page_ext_ops[i]->init();
> > +   }
> > +}
> > +
> >
> > ...
> >
> > +void __init page_ext_init_flatmem(void)
> > +{
> > +
> > +   int nid, fail;
> > +
> > +   if (!invoke_need_callbacks)
> > +   return;
> > +
> > +   for_each_online_node(nid)  {
> > +   fail = alloc_node_page_ext(nid);
> > +   if (fail)
> > +   goto fail;
> > +   }
> > +   pr_info("allocated %ld bytes of page_ext\n", total_usage);
> > +   invoke_init_callbacks();
> > +   return;
> > +
> > +fail:
> > +   pr_crit("allocation of page_ext failed.\n");
> > +   panic("Out of memory");
> 
> Did we really need to panic the machine?  The situation should be
> pretty easily recoverable by disabling the clients.  I guess it's OK as
> long as page_ext is being used for kernel developer debug things.

I think that panic() would be better. If the feature is disabled silently
or with some printk output, user can't easily notice that situation
and will try to do real work for debugging. This would waste user's time
so panic() looks better to me.

> > +}
> > +
> 
> We'll need this to fix the build.  I'll queue it up.

Thank you!

> 
> 
> From: Andrew Morton 
> Subject: include/linux/kmemleak.h: needs slab.h
> 
> include/linux/kmemleak.h: In function 'kmemleak_alloc_recursive':
> include/linux/kmemleak.h:43: error: 'SLAB_NOLEAKTRACE' undeclared (first use 
> in this function)
> 
> --- a/include/linux/kmemleak.h~include-linux-kmemleakh-needs-slabh
> +++ a/include/linux/kmemleak.h
> @@ -21,6 +21,8 @@
>  #ifndef __KMEMLEAK_H
>  #define __KMEMLEAK_H
>  
> +#include 
> +
>  #ifdef CONFIG_DEBUG_KMEMLEAK
>  
>  extern void kmemleak_init(void) __ref;
> 
> 
> 
> And here are a couple of tweaks for this patch:

Okay. I will include below changes in next spin.

Thanks.

> 
> From: Andrew Morton 
> Subject: mm-page_ext-resurrect-struct-page-extending-code-for-debugging-fix
> 
> use ARRAY_SIZE, clean up 80-col tricks
> 
> --- 
> a/mm/page_ext.c~mm-page_ext-resurrect-struct-page-extending-code-for-debugging-fix
> +++ a/mm/page_ext.c
> @@ -71,7 +71,7 @@ static bool __init invoke_need_callbacks
>  static void __init invoke_init_callbacks(void)
>  {
>   int i;
> - int entries = sizeof(page_ext_ops) / sizeof(page_ext_ops[0]);
> + 

[PATCH V3 01/11] irqchip: Update docs regarding irq_domain_add_tree()

[Kevin Cernekee]

Several drivers now use this API, including the ARM GIC driver, so remove
the outdated comment.

Signed-off-by: Kevin Cernekee 
---
 Documentation/IRQ-domain.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
index 8a8b82c9ca53..0ccd7b7f6043 100644
--- a/Documentation/IRQ-domain.txt
+++ b/Documentation/IRQ-domain.txt
@@ -95,8 +95,7 @@ since it doesn't need to allocate a table as large as the 
largest
 hwirq number.  The disadvantage is that hwirq to IRQ number lookup is
 dependent on how many entries are in the table.
 
-Very few drivers should need this mapping.  At the moment, powerpc
-iseries is the only user.
+Very few drivers should need this mapping.
 
  No Map ===-
 irq_domain_add_nomap()
-- 
2.1.1

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

[PATCH V3 03/11] irqchip: brcmstb-l2: fix error handling of irq_of_parse_and_map

[Kevin Cernekee]

From: Dmitry Torokhov 

Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.

Signed-off-by: Dmitry Torokhov 
Acked-by: Florian Fainelli 
Tested-by: Kevin Cernekee 
---
 drivers/irqchip/irq-brcmstb-l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index 4edd27c486c4..d6bcc6be0777 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -143,9 +143,9 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
writel(0x, data->base + CPU_CLEAR);
 
data->parent_irq = irq_of_parse_and_map(np, 0);
-   if (data->parent_irq < 0) {
+   if (!data->parent_irq) {
pr_err("failed to find parent interrupt\n");
-   ret = data->parent_irq;
+   ret = -EINVAL;
goto out_unmap;
}
 
-- 
2.1.1

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

[PATCH V3 00/11] Multiplatform BMIPS kernel

[Kevin Cernekee]

This patch series REPLACES the following commits in Ralf's
mips-for-linux-next branch:

ab3e5d0647e3 Documentation: DT: Add entries for BCM3384 and its peripherals
1251d9964de5 MIPS: bcm3384: Initial commit of bcm3384 platform support
aff366c68e5c MAINTAINERS: Add entry for BCM33xx cable chips

(Ralf, if you just want to drop the above commits and target the new
platform for 3.20+, that's fine.)


V2->V3:

 - Omit the BMIPS updates that have already been accepted into Ralf's tree.
   They are still needed, but not reposted.

 - Make USB endian swap options conditional on "if CPU_BIG_ENDIAN".

 - Remove board listing from Documentation/devicetree/bindings/mips/brcm/soc.txt

 - Remove legacy device autodetection and chip ID decoding.  Legacy
   boards/bootloaders will be supported by selecting a single DTB file
   to compile into the kernel.

 - Refactor quirks code to match against DT "compatible" strings, not chip IDs.

 - Fix CPU1 boot (missing DT node) on 6329.

 - Remove @0 / addressing properties on non-reg nodes.

 - Remove bogus "brcm,bmips" bus registration.

 - Move UBUS peripherals onto a "simple-bus" and set DMA ranges for this
   bus on bcm3384_zephyr.

 - Fix base addresses on 6328/6368 for "periph_intc@1020".

 - Change the MIPS_L1_CACHE_SHIFT calculation so as to minimize the impact
   on other builds (like bcm63xx).


This series is based on mips-for-linux-next, minus the three 3384 patches
listed above, plus these non-MIPS patches:

http://patchwork.linux-mips.org/bundle/cernekee/bmips-multi-v3-deps/?state=%2a
http://marc.info/?l=linux-usb=141305106215886=2 (all 3/3)

These are queued for tty-next / irqchip-next / usb-next.


Re: irqchip patches in this series

These apply cleanly on top of earlier bcm7120/brcmstb commits currently
in irqchip-next.  The BMIPS commit in this series depends on both the
irqchip-next updates, and the irqchip updates in this series.


Re: syscon/reset

I have some patches ready for the brcmstb syscon/reset drivers, but will
submit them separately so we can get the basic platform support stuff
nailed down first.

I don't have a patch ready for gisb-arb support yet, but I have prototyped
the change.

These patches will also have interdependencies between the
arch/mips/boot/dts changes and the drivers/ changes.


Re: external (non-MIPS) timers:

I left this problem for a future submission.  There are a couple of
elements to consider:

 - Do we want to completely eliminate CSRC_R4K and CEVT_R4K in favor of an
   external timer, and leave mips_hpt_frequency unset?

 - If so, do all platforms have a suitable timer, and is it hooked up to an
   IRQ?  On STB we saw conflicts with other software when taking over one
   of the UPG timers; the alternative (WKTMR) doesn't have a suitable
   alarm/IRQ.

 - Or do we want to use another timer to calibrate mips_hpt_frequency?  In
   this case we may need to add part of that timer's driver under
   arch/mips/bmips instead of under drivers/, so it is available early in the
   boot process.  Unfortunately that might cause problems or redundancy
   sharing the code with ARM platforms.

 - And if we do wind up using CSRC_R4K / CEVT_R4K, we'll need a way to
   handle the complications caused by frequency scaling.  The brcmstb
   kernel sources posted on github do this, but it did require changes to
   other files under arch/mips/kernel/.


Re: dma-ranges

dma.c implements a minimal remapping scheme just for the current UBUS
peripherals.  The remapping is global, and it isn't the same mapping
needed for PCI(e).  A more comprehensive solution will be needed before
PCI support can be added.

On chips OTHER than 3384, remapping is only required on PCI (not UBUS or
"rdb").  Notably, BCM7445, an ARM platform currently supported upstream,
doesn't require dma-ranges for non-PCI devices.

I am hoping we can piggyback on top of the ARM dma-ranges code once it
is merged.  This will allow for eliminating my dma.c.


Brian Norris (1):
  irqchip: brcmstb-l2: don't clear wakeable interrupts at init time

Dmitry Torokhov (2):
  irqchip: brcmstb-l2: fix error handling of irq_of_parse_and_map
  irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map

Kevin Cernekee (8):
  irqchip: Update docs regarding irq_domain_add_tree()
  irqchip: bcm7120-l2: Refactor driver for arbitrary IRQEN/IRQSTAT
offsets
  irqchip: bcm7120-l2: Change DT binding to allow non-contiguous
IRQEN/IRQSTAT
  irqchip: Add new driver for BCM7038-style level 1 interrupt
controllers
  MIPS: Let __dt_register_buses accept a single bus type
  MIPS: Fall back to the generic restart notifier
  MIPS: Reorder MIPS_L1_CACHE_SHIFT priorities
  MIPS: Add multiplatform BMIPS target

 Documentation/IRQ-domain.txt   |   3 +-
 .../interrupt-controller/brcm,bcm7038-l1-intc.txt  |  52 
 .../interrupt-controller/brcm,bcm7120-l2-intc.txt  |   5 +-
 .../devicetree/bindings/mips/brcm/bmips.txt|   8 +
 .../devicetree/bindings/mips/brcm/soc.txt

[PATCH V3 06/11] irqchip: bcm7120-l2: Change DT binding to allow non-contiguous IRQEN/IRQSTAT

[Kevin Cernekee]

To date, all supported controllers have had the IRQEN register at offset
0x00 and the IRQSTAT register at 0x04.  So in DT we would typically see
something like:

reg = <0xf0406800 0x8>;

We still want to support this format, but we also need to support cases
where IRQEN and IRQSTAT aren't adjacent.  So, we will amend the driver to
accept an alternate format that looks like this:

reg = <0xf0406800 0x4 0xf0406804 0x4>;

i.e. if the first resource_size() == 4, assume that the first resource
points to IRQEN and that the next resource points to IRQSTAT.  If the
first resource_size() == 8, retain the current behavior.

Signed-off-by: Kevin Cernekee 
---
 .../interrupt-controller/brcm,bcm7120-l2-intc.txt  |  5 +-
 drivers/irqchip/irq-bcm7120-l2.c   | 76 +-
 2 files changed, 63 insertions(+), 18 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
index bae1f2187226..e3b0cba9489a 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
@@ -55,7 +55,10 @@ Required properties:
 - compatible: should be "brcm,bcm7120-l2-intc"
 - reg: specifies the base physical address and size of the registers;
   multiple pairs may be specified, with the first pair handling IRQ offsets
-  0..31 and the second pair handling 32..63
+  0..31 and the second pair handling 32..63. A register pair may be
+  specified as either , where IRQEN lives at base+0x00 and
+  IRQSTAT lives at base+0x04, or , where the
+  address of each register is listed independently.
 - interrupt-controller: identifies the node as an interrupt controller
 - #interrupt-cells: specifies the number of cells needed to encode an interrupt
   source, should be 1.
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index e8441ee7454c..576a92b34372 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,12 +31,8 @@
 
 #include "irqchip.h"
 
-/* Register offset in the L2 interrupt controller */
-#define IRQEN  0x00
-#define IRQSTAT0x04
-
 #define MAX_WORDS  4
-#define MAX_MAPPINGS   MAX_WORDS
+#define MAX_MAPPINGS   (MAX_WORDS * 2)
 #define IRQS_PER_WORD  32
 
 struct bcm7120_l2_intc_data {
@@ -128,6 +126,61 @@ static int bcm7120_l2_intc_init_one(struct device_node *dn,
return 0;
 }
 
+static int __init bcm7120_l2_intc_map_regs(struct device_node *dn,
+  struct bcm7120_l2_intc_data *data)
+{
+   unsigned int idx, n_regs = 0, gc_idx = 0;
+   void __iomem *en_reg = NULL, *stat_reg = NULL;
+
+   for (idx = 0; n_regs < MAX_WORDS * 2; idx++) {
+   struct resource res;
+   resource_size_t sz;
+   void __iomem *map_base;
+
+   if (of_address_to_resource(dn, idx, ))
+   break;
+   sz = resource_size();
+   map_base = data->map_base[idx] = ioremap(res.start, sz);
+   if (!map_base)
+   return -EINVAL;
+
+   if (n_regs % 2 == 0) {
+   /* Accept either enable + status, or just enable:
+* reg = <0x1024 0x8>;
+* reg = <0x1024 0x4 0x102c 0x4>;
+*/
+   en_reg = map_base;
+   if (sz == 8) {
+   stat_reg = map_base + 0x04;
+   n_regs += 2;
+   } else if (sz == 4) {
+   n_regs += 1;
+   continue;
+   } else {
+   return -EINVAL;
+   }
+   } else {
+   /* If the last register was enable, we're looking
+* for its corresponding status register
+*/
+   if (sz == 4) {
+   stat_reg = map_base;
+   n_regs += 1;
+   } else {
+   return -EINVAL;
+   }
+   }
+
+   data->pair_base[gc_idx] = min(en_reg, stat_reg);
+   data->en_offset[gc_idx] = en_reg - data->pair_base[gc_idx];
+   data->stat_offset[gc_idx] = stat_reg - data->pair_base[gc_idx];
+   gc_idx++;
+   }
+
+   data->n_words = gc_idx;
+   return gc_idx ? 0 : -ENOENT;
+}
+
 int __init bcm7120_l2_intc_of_init(struct device_node *dn,
 

[PATCH V3 07/11] irqchip: Add new driver for BCM7038-style level 1 interrupt controllers

[Kevin Cernekee]

This is the main peripheral IRQ controller on the BCM7xxx MIPS chips;
it has the following characteristics:

 - 64 to 160+ level IRQs
 - Atomic set/clear registers
 - Reasonably predictable register layout (N status words, then N
   mask status words, then N mask set words, then N mask clear words)
 - SMP affinity supported on most systems
 - Typically connected to MIPS IRQ 2,3,2,3 on CPUs 0,1,2,3

This driver registers one IRQ domain and one IRQ chip to cover all
instances of the block.  Up to 4 instances of the block may appear, as
it supports 4-way IRQ affinity on BCM7435.

The same block exists on the ARM BCM7xxx chips, but typically the ARM GIC
is used instead.  So this driver is primarily intended for MIPS STB chips.

Signed-off-by: Kevin Cernekee 
---
 .../interrupt-controller/brcm,bcm7038-l1-intc.txt  |  52 
 drivers/irqchip/Kconfig|   5 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-bcm7038-l1.c   | 335 +
 4 files changed, 393 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
 create mode 100644 drivers/irqchip/irq-bcm7038-l1.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
new file mode 100644
index ..cc217b22dccd
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
@@ -0,0 +1,52 @@
+Broadcom BCM7038-style Level 1 interrupt controller
+
+This block is a first level interrupt controller that is typically connected
+directly to one of the HW INT lines on each CPU.  Every BCM7xxx set-top chip
+since BCM7038 has contained this hardware.
+
+Key elements of the hardware design include:
+
+- 64, 96, 128, or 160 incoming level IRQ lines
+
+- Most onchip peripherals are wired directly to an L1 input
+
+- A separate instance of the register set for each CPU, allowing individual
+  peripheral IRQs to be routed to any CPU
+
+- Atomic mask/unmask operations
+
+- No polarity/level/edge settings
+
+- No FIFO or priority encoder logic; software is expected to read all
+  2-5 status words to determine which IRQs are pending
+
+Required properties:
+
+- compatible: should be "brcm,bcm7038-l1-intc"
+- reg: specifies the base physical address and size of the registers;
+  the number of supported IRQs is inferred from the size argument
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an interrupt
+  source, should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller(s)
+  this one is cascaded from
+- interrupts: specifies the interrupt line(s) in the interrupt-parent 
controller
+  node; valid values depend on the type of parent interrupt controller
+
+If multiple reg ranges and interrupt-parent entries are present on an SMP
+system, the driver will allow IRQ SMP affinity to be set up through the
+/proc/irq/ interface.  In the simplest possible configuration, only one
+reg range and one interrupt-parent is needed.
+
+Example:
+
+periph_intc: periph_intc@1041a400 {
+compatible = "brcm,bcm7038-l1-intc";
+reg = <0x1041a400 0x30 0x1041a600 0x30>;
+
+interrupt-controller;
+#interrupt-cells = <1>;
+
+interrupt-parent = <_intc>;
+interrupts = <2>, <3>;
+};
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 018f884aa3b0..89ee92b8b94c 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -48,6 +48,11 @@ config ATMEL_AIC5_IRQ
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
 
+config BCM7038_L1_IRQ
+   bool
+   select GENERIC_IRQ_CHIP
+   select IRQ_DOMAIN
+
 config BCM7120_L2_IRQ
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 4954a314c31e..446ae7a98f7a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_TB10X_IRQC)  += irq-tb10x.o
 obj-$(CONFIG_XTENSA)   += irq-xtensa-pic.o
 obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
 obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_BCM7038_L1_IRQ)   += irq-bcm7038-l1.o
 obj-$(CONFIG_BCM7120_L2_IRQ)   += irq-bcm7120-l2.o
 obj-$(CONFIG_BRCMSTB_L2_IRQ)   += irq-brcmstb-l2.o
 obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
diff --git a/drivers/irqchip/irq-bcm7038-l1.c b/drivers/irqchip/irq-bcm7038-l1.c
new file mode 100644
index ..d3b8c8be15f6
--- /dev/null
+++ b/drivers/irqchip/irq-bcm7038-l1.c
@@ -0,0 +1,335 @@
+/*
+ * Broadcom BCM7038 style Level 1 interrupt controller driver
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ * Author: Kevin Cernekee
+ *
+ * This program is free 

[PATCH V3 05/11] irqchip: bcm7120-l2: Refactor driver for arbitrary IRQEN/IRQSTAT offsets

[Kevin Cernekee]

Currently the driver assumes that REG_BASE+0x00 is the IRQ enable mask,
and REG_BASE+0x04 is the IRQ status mask.  This is true on BCM3384 and
BCM7xxx, but it is not true for some of the controllers found on BCM63xx
chips.  So we will change a couple of key assumptions:

 - Don't assume that both the IRQEN and IRQSTAT registers will be
   covered by a single ioremap() operation.

 - Don't assume any particular ordering (IRQSTAT might show up before
   IRQEN on some chips).

 - For an L2 controller with >=64 IRQs, don't assume that every
   IRQEN/IRQSTAT pair will use the same register spacing.

This patch changes the "plumbing" but doesn't yet provide a way for users
to instantiate a controller with arbitrary IRQEN/IRQSTAT offsets.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 41 +++-
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 8eec8e1201d9..e8441ee7454c 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -34,11 +34,15 @@
 #define IRQSTAT0x04
 
 #define MAX_WORDS  4
+#define MAX_MAPPINGS   MAX_WORDS
 #define IRQS_PER_WORD  32
 
 struct bcm7120_l2_intc_data {
unsigned int n_words;
-   void __iomem *base[MAX_WORDS];
+   void __iomem *map_base[MAX_MAPPINGS];
+   void __iomem *pair_base[MAX_WORDS];
+   int en_offset[MAX_WORDS];
+   int stat_offset[MAX_WORDS];
struct irq_domain *domain;
bool can_wake;
u32 irq_fwd_mask[MAX_WORDS];
@@ -61,7 +65,8 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
int hwirq;
 
irq_gc_lock(gc);
-   pending = irq_reg_readl(gc, IRQSTAT) & gc->mask_cache;
+   pending = irq_reg_readl(gc, b->stat_offset[idx]) &
+   gc->mask_cache;
irq_gc_unlock(gc);
 
for_each_set_bit(hwirq, , IRQS_PER_WORD) {
@@ -76,21 +81,24 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
 static void bcm7120_l2_intc_suspend(struct irq_data *d)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
struct bcm7120_l2_intc_data *b = gc->private;
 
irq_gc_lock(gc);
if (b->can_wake)
-   irq_reg_writel(gc, gc->mask_cache | gc->wake_active, IRQEN);
+   irq_reg_writel(gc, gc->mask_cache | gc->wake_active,
+  ct->regs.mask);
irq_gc_unlock(gc);
 }
 
 static void bcm7120_l2_intc_resume(struct irq_data *d)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
 
/* Restore the saved mask */
irq_gc_lock(gc);
-   irq_reg_writel(gc, gc->mask_cache, IRQEN);
+   irq_reg_writel(gc, gc->mask_cache, ct->regs.mask);
irq_gc_unlock(gc);
 }
 
@@ -137,9 +145,14 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
return -ENOMEM;
 
for (idx = 0; idx < MAX_WORDS; idx++) {
-   data->base[idx] = of_iomap(dn, idx);
-   if (!data->base[idx])
+   data->map_base[idx] = of_iomap(dn, idx);
+   if (!data->map_base[idx])
break;
+
+   data->pair_base[idx] = data->map_base[idx];
+   data->en_offset[idx] = IRQEN;
+   data->stat_offset[idx] = IRQSTAT;
+
data->n_words = idx + 1;
}
if (!data->n_words) {
@@ -157,7 +170,8 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
if (ret == 0 || ret == -EINVAL) {
for (idx = 0; idx < data->n_words; idx++)
__raw_writel(data->irq_fwd_mask[idx],
-data->base[idx] + IRQEN);
+data->pair_base[idx] +
+data->en_offset[idx]);
} else {
/* property exists but has the wrong number of words */
pr_err("invalid int-fwd-mask property\n");
@@ -215,11 +229,12 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
gc = irq_get_domain_generic_chip(data->domain, irq);
 
gc->unused = 0x & ~data->irq_map_mask[idx];
-   gc->reg_base = data->base[idx];
gc->private = data;
ct = gc->chip_types;
 
-   ct->regs.mask = IRQEN;
+   gc->reg_base = data->pair_base[idx];
+   ct->regs.mask = data->en_offset[idx];
+
ct->chip.irq_mask = irq_gc_mask_clr_bit;
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_ack = irq_gc_noop;
@@ -237,16 +252,16 @@ int __init 

[PATCH V3 09/11] MIPS: Fall back to the generic restart notifier

[Kevin Cernekee]

If the machine doesn't set its own _machine_restart callback, call the
common do_kernel_restart() instead.  This allows arch-independent reset
drivers from drivers/power/reset/ to be used to reboot the machine.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/reset.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 07fc5244aed4..cf23ab520701 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -29,6 +29,8 @@ void machine_restart(char *command)
 {
if (_machine_restart)
_machine_restart(command);
+   else
+   do_kernel_restart(command);
 }
 
 void machine_halt(void)
-- 
2.1.1

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

Re: [PATCH ftrace/core v6 4/5] kprobes: Set IPMODIFY flag only if the probe can change regs->ip

[Masami Hiramatsu]

(2014/11/22 5:15), Steven Rostedt wrote:
> On Fri, 21 Nov 2014 05:25:30 -0500
> Masami Hiramatsu  wrote:
> 
>> Set FTRACE_OPS_FL_IPMODIFY flag only for the probes which can change
>> regs->ip, which has kprobe->break_handler.
>> Currently we can not put jprobe and another ftrace handler which
>> changes regs->ip on the same function because all kprobes have
>> FTRACE_OPS_FL_IPMODIFY flag. This removes FTRACE_OPS_FL_IPMODIFY
>> flag from kprobes and only when the user uses jprobe (or the
>> kprobe.break_handler != NULL) we add additinal ftrace_ops with
>> FTRACE_OPS_FL_IPMODIFY on target function.
>>
>> Note about the implementation: This uses a dummy ftrace_ops to
>> reserve IPMODIFY flag on the given ftrace address, for the case
>> that we have a enabled kprobe on a function entry and a jprobe
>> is added on the same point. In that case, we already have a
>> ftrace_ops without IPMODIFY flag on the entry, and we have to
>> add another ftrace_ops with IPMODIFY on the same address.
>> If we put a same handler on both ftrace_ops, the handler can
>> be called twice on that entry until the first one is removed.
>> This means that the kprobe and the jprobe are called twice too,
>> and that will not what kprobes expected.
>> Thus I added a dummy ftrace_ops just for reserving IPMODIFY flag.
>>
>> Signed-off-by: Masami Hiramatsu 
>> Cc: Ananth N Mavinakayanahalli 
>> Cc: Steven Rostedt 
>> Cc: Josh Poimboeuf 
>> Cc: Namhyung Kim 
>> ---
>> Changes in v4:
>>  - Increment refcounter after succeeded to register ftrace_ops.
>>
>> Changes in v3:
>>  - Update __ftrace_add/remove_filter_ip() according to
>>Namhyng's comments (thanks!)
>>  - Split out regs->ip recovering code from this patch.
>> ---
>>  Documentation/kprobes.txt |   12 ++--
>>  kernel/kprobes.c  |  125 
>> +++--
>>  2 files changed, 114 insertions(+), 23 deletions(-)
>>
>> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
>> index 4227ec2..eb03efc 100644
>> --- a/Documentation/kprobes.txt
>> +++ b/Documentation/kprobes.txt
>> @@ -264,15 +264,13 @@ stop-machine method that ksplice uses for supporting a 
>> CONFIG_PREEMPT=y
>>  kernel.
>>  
>>  NOTE for geeks:
>> -The jump optimization changes the kprobe's pre_handler behavior.
>> -Without optimization, the pre_handler can change the kernel's execution
>> +The jump optimization (and ftrace-based kprobes) changes the kprobe's
>> +pre_handler behavior.
>> +Without optimizations, the pre_handler can change the kernel's execution
>>  path by changing regs->ip and returning 1.  However, when the probe
>>  is optimized, that modification is ignored.  Thus, if you want to
>> -tweak the kernel's execution path, you need to suppress optimization,
>> -using one of the following techniques:
>> -- Specify an empty function for the kprobe's post_handler or break_handler.
>> - or
>> -- Execute 'sysctl -w debug.kprobes_optimization=n'
>> +tweak the kernel's execution path, you need to suppress optimization or
>> +notify your handler will modify regs->ip by setting p->break_handler.
>>  
>>  1.5 Blacklist
>>  
>> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
>> index 831978c..4b4b7c5 100644
>> --- a/kernel/kprobes.c
>> +++ b/kernel/kprobes.c
>> @@ -915,10 +915,93 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe 
>> *p)
>>  #ifdef CONFIG_KPROBES_ON_FTRACE
>>  static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
>>  .func = kprobe_ftrace_handler,
>> -.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
>> +.flags = FTRACE_OPS_FL_SAVE_REGS,
>>  };
>>  static int kprobe_ftrace_enabled;
>>  
>> +static void kprobe_ftrace_stub(unsigned long a0, unsigned long a1,
>> +struct ftrace_ops *op, struct pt_regs *regs)
>> +{
>> +/* Do nothing. This is just a dummy handler */
>> +}
> 
> Feel free to just use ftrace_stub instead. That's what it's there for.

Ah, I didn't know that. OK :)

>> +
>> +/* This is only for checking conflict with other ftrace users */
>> +static struct ftrace_ops kprobe_ipmod_ftrace_ops __read_mostly = {
>> +.func = kprobe_ftrace_stub,
>> +.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
>> +};
>> +static int kprobe_ipmod_ftrace_enabled;
>> +
>> +static int __ftrace_add_filter_ip(struct ftrace_ops *ops, unsigned long ip,
>> +  int *ref)
>> +{
>> +int ret;
>> +
>> +/* Try to set given ip to filter */
>> +ret = ftrace_set_filter_ip(ops, ip, 0, 0);
>> +if (ret < 0)
>> +return ret;
>> +
>> +if (*ref == 0) {
>> +ret = register_ftrace_function(ops);
>> +if (ret < 0) {
>> +/* Rollback the filter */
>> +ftrace_set_filter_ip(ops, ip, 1, 0);
>> +goto out;
> 
> Why the goto out, and not just return ret?
> 
>> +}
>> +}
>> +(*ref)++;
>> +
>> +out:
>> +return ret;
> 
> Probably could just return 0 here.

Agreed.

> 

[PATCH V3 04/11] irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map

[Kevin Cernekee]

From: Dmitry Torokhov 

Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.

Signed-off-by: Dmitry Torokhov 
Acked-by: Florian Fainelli 
Tested-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index e7c6155b23b8..8eec8e1201d9 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -102,9 +102,9 @@ static int bcm7120_l2_intc_init_one(struct device_node *dn,
unsigned int idx;
 
parent_irq = irq_of_parse_and_map(dn, irq);
-   if (parent_irq < 0) {
+   if (!parent_irq) {
pr_err("failed to map interrupt %d\n", irq);
-   return parent_irq;
+   return -EINVAL;
}
 
/* For multiple parent IRQs with multiple words, this looks like:
-- 
2.1.1

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

[PATCH V3 11/11] MIPS: Add multiplatform BMIPS target

[Kevin Cernekee]

bmips_be_defconfig supports Linux running on the following CM and DSL
SoCs:

 - BCM3384 (BMIPS5000) cable modem application processor, BE, SMP
 - BCM3384 (BMIPS4355) cable modem "spare CPU"*, BE
 - BCM6328 (BMIPS4355) ADSL chip, BE
 - BCM6368 (BMIPS4350) ADSL chip, BE, SMP

*experimental; most configurations will require changing CONFIG_PHYSICAL_START

bmips_stb_defconfig supports Linux running on the (nominally LE) STB
chipsets:

 - BCM7125 (BMIPS4380) set-top box chip, LE, SMP
 - BCM7346 (BMIPS5000) set-top box chip, LE, SMP
 - BCM7360 (BMIPS3300) set-top box chip, LE
 - BCM7420 (BMIPS5000) set-top box chip, LE, SMP
 - BCM7425 (BMIPS5000) set-top box chip, LE, SMP

serial8250 and bcm63xx_uart do not currently coexist.  If/when this is
fixed, it will be also possible to boot the BE image on any supported STB
board configured for BE.  For now, each defconfig can only pick one UART
driver, and the BE defconfig enables bcm63xx_uart.

On these MIPS systems, endianness cannot be reconfigured at runtime.  On
STB it is sometimes offered as a board jumper or 0-ohm resistor, and
sometimes hardwired to LE only.  The CM and DSL systems always run BE.

Device Tree is used to configure the following items:

 - UART, USB, GENET peripherals
 - IRQ controllers
 - Early console base address (bcm63xx_uart only)
 - SMP or UP mode
 - MIPS counter frequency
 - Memory size / regions
 - DMA remappings
 - Kernel command line

The DT-enabled bootloader and build instructions for 3384 are posted at
https://github.com/Broadcom/aeolus .  The other chips use legacy non-DT
bootloaders, so they will need to select an appropriate builtin DTB at
compile time until the bootloader is updated.

Signed-off-by: Kevin Cernekee 
---
 .../devicetree/bindings/mips/brcm/bmips.txt|   8 +
 .../devicetree/bindings/mips/brcm/soc.txt  |  12 ++
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  36 
 arch/mips/bmips/Kconfig|  50 ++
 arch/mips/bmips/Makefile   |   1 +
 arch/mips/bmips/Platform   |   7 +
 arch/mips/bmips/dma.c  | 141 +++
 arch/mips/bmips/irq.c  |  38 
 arch/mips/bmips/setup.c| 195 +
 arch/mips/boot/dts/Makefile|   9 +
 arch/mips/boot/dts/bcm3384_viper.dtsi  | 108 
 arch/mips/boot/dts/bcm3384_zephyr.dtsi | 126 +
 arch/mips/boot/dts/bcm6328.dtsi|  87 +
 arch/mips/boot/dts/bcm6368.dtsi|  94 ++
 arch/mips/boot/dts/bcm7125.dtsi| 107 +++
 arch/mips/boot/dts/bcm7346.dtsi| 192 
 arch/mips/boot/dts/bcm7360.dtsi| 129 ++
 arch/mips/boot/dts/bcm7420.dtsi| 151 
 arch/mips/boot/dts/bcm7425.dtsi| 191 
 arch/mips/boot/dts/bcm93384wvg.dts |  25 +++
 arch/mips/boot/dts/bcm93384wvg_viper.dts   |  25 +++
 arch/mips/boot/dts/bcm96368mvwg.dts|  31 
 arch/mips/boot/dts/bcm97125cbmb.dts|  31 
 arch/mips/boot/dts/bcm97346dbsmb.dts   |  58 ++
 arch/mips/boot/dts/bcm97360svmb.dts|  34 
 arch/mips/boot/dts/bcm97420c.dts   |  45 +
 arch/mips/boot/dts/bcm97425svmb.dts|  60 +++
 arch/mips/boot/dts/bcm9ejtagprb.dts|  22 +++
 arch/mips/configs/bmips_be_defconfig   |  86 +
 arch/mips/configs/bmips_stb_defconfig  |  86 +
 arch/mips/include/asm/mach-bmips/dma-coherence.h   |  45 +
 arch/mips/include/asm/mach-bmips/spaces.h  |  17 ++
 arch/mips/include/asm/mach-bmips/war.h |  24 +++
 34 files changed, 2272 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/bmips.txt
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/soc.txt
 create mode 100644 arch/mips/bmips/Kconfig
 create mode 100644 arch/mips/bmips/Makefile
 create mode 100644 arch/mips/bmips/Platform
 create mode 100644 arch/mips/bmips/dma.c
 create mode 100644 arch/mips/bmips/irq.c
 create mode 100644 arch/mips/bmips/setup.c
 create mode 100644 arch/mips/boot/dts/bcm3384_viper.dtsi
 create mode 100644 arch/mips/boot/dts/bcm3384_zephyr.dtsi
 create mode 100644 arch/mips/boot/dts/bcm6328.dtsi
 create mode 100644 arch/mips/boot/dts/bcm6368.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7125.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7346.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7360.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7420.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7425.dtsi
 create mode 100644 arch/mips/boot/dts/bcm93384wvg.dts
 create mode 100644 

[PATCH V3 08/11] MIPS: Let __dt_register_buses accept a single bus type

[Kevin Cernekee]

Some machines only have one bus type to register (e.g. "simple-bus").

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/prom.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 452d4350ce42..e303cb1ef2f4 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -64,7 +64,10 @@ int __init __dt_register_buses(const char *bus0, const char 
*bus1)
panic("device tree not present");
 
strlcpy(of_ids[0].compatible, bus0, sizeof(of_ids[0].compatible));
-   strlcpy(of_ids[1].compatible, bus1, sizeof(of_ids[1].compatible));
+   if (bus1) {
+   strlcpy(of_ids[1].compatible, bus1,
+   sizeof(of_ids[1].compatible));
+   }
 
if (of_platform_populate(NULL, of_ids, NULL, NULL))
panic("failed to populate DT");
-- 
2.1.1

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