[PATCH] usb: phy: return -ENODEV on failure of try_module_get

[Arjun Sreedharan]

When __usb_find_phy_dev() does not return error and
try_module_get() fails, return -ENODEV.

Signed-off-by: Arjun Sreedharan 
---
 drivers/usb/phy/phy.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 36b6bce..fd0d7f1 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -232,6 +232,9 @@ struct usb_phy *usb_get_phy_dev(struct device *dev, u8 
index)
phy = __usb_find_phy_dev(dev, _bind_list, index);
if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
dev_dbg(dev, "unable to find transceiver\n");
+   if (!IS_ERR(phy))
+   phy = ERR_PTR(-ENODEV);
+
goto err0;
}
 
-- 
1.7.11.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/

Issue with clone() and CLONE_NEWUSER as unprivileged user

[Marcel Holtmann]

Hi,

I am trying to use clone() and CLONE_NEWUSER for creating a new user namespace 
as an unprivileged user. I always get an operation not permitted error. However 
when I used fork() + unshare() as unprivileged user, I can create the new user 
namespace just fine.

Is there something obvious that I am missing? My understand is that 
CLONE_NEWUSER should not require any special capabilities. I tried the sample 
code from the manpage and also from LWN.net, but both give me the same error.

Regards

Marcel

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

Re: [Intel-gfx] Usage of _PAGE_PCD et al in i915 driver

[Juergen Gross]

On 08/15/2014 12:21 PM, Ville Syrjälä wrote:

On Thu, Aug 14, 2014 at 05:55:11AM +0200, Juergen Gross wrote:

On 08/13/2014 05:07 PM, Jesse Barnes wrote:

On Fri, 8 Aug 2014 15:14:15 +0200
Daniel Vetter  wrote:


Adding relevant mailing lists.

On Fri, Aug 8, 2014 at 1:23 PM, Juergen Gross  wrote:

I'm just about to create a patch for full PAT support in the Linux
kernel, including Xen. For this purpose I introduce a translation
between cache modes and pte bits.

Scanning the kernel sources for usage of the cache mode bits in the
pte I discovered  drivers/gpu/drm/i915/i915_gem_gtt.h is using
_PAGE_PCD, _PAGE_PWT and _PAGE_PAT. I think those defines are used
to create ptes not for usage by the main processor, but for the
graphics processor. Is this true? In this case I'd suggest to define
i915-specific macros instead of using the x86 ones.


Yeah, those are gpu specific PAT tables, but the hw engineers
specifically designed this to match, and we've tried to follow the cpu
side to match it. Especially in the future that will be somewhat
important, since we want to fully share the entire address space
between cpu and gpu on the next platform. Jesse is working on that.


Right, we have an x86 compatible MMU in the GPU itself, so re-using the
defines makes sense.  I suppose with your work you'll move them and
make them a bit more opaque?  If so, we'll still want a way to get at
them directly, or access your mapping functions for generating PTE bits
for the GPU MMU.


Using the mapping functions I'm introducing should work, if the MMU has
an x86 compatible MSR_IA32_CR_PAT which is configured the same way as
on the x86 processor (be aware that Xen is using another MSR_IA32_CR_PAT
setting as the Linux kernel).


We have a PAT that is structured the same way as the x86 PAT. But the
contents of the PAT entries are obviously specific to the GPU so it's
not identical. But the pcd/pwt/pat bits index the PAT in exactly the
same way as on x86.

See bdw_setup_private_ppat() and chv_setup_private_ppat() for how we
set up the PAT.



So you are using the PAT bit in the ptes, but the semantic for the GPU
will be different as for the x86 processor, because the GPU PAT is set
up differently from the x86 one.

In case you are sharing ptes between GPU and x86 processor in future,
this might lead to problems when the x86 processor will use ptes with
the PAT bit set.


Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: [RFC PATCH 04/10] scsi/constants: Cleanup printk message in scsi_dump_sense_buffer()

[Yoshihiro YUNOMAE]

(2014/08/16 0:08), Ewan Milne wrote:

On Fri, 2014-08-08 at 11:50 +, Yoshihiro YUNOMAE wrote:

Unrecognized sense data should be output after linebuf is filled because
"[%s] Unrecognized sense data (in hex): %s" message is output many times in
loop.

Signed-off-by: Yoshihiro YUNOMAE 
Cc: Hannes Reinecke 
Cc: Doug Gilbert 
Cc: Martin K. Petersen 
Cc: Christoph Hellwig 
Cc: "James E.J. Bottomley" 
Cc: Hidehiro Kawai 
Cc: Masami Hiramatsu 
---
  drivers/scsi/constants.c |   13 +
  1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 5956d4d..6fad6b4 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -1385,16 +1385,13 @@ EXPORT_SYMBOL(scsi_print_sense_hdr);

  static void
  scsi_dump_sense_buffer(struct scsi_device *sdev, const char *prefix,
-  const unsigned char *sense_buffer, int sense_len,
-  struct scsi_sense_hdr *sshdr)
+  const unsigned char *sense_buffer, int sense_len)
  {
char linebuf[128];
int i, linelen, remaining;

if (sense_len < 32)
sense_len = 32;
-   sdev_printk(KERN_INFO, sdev,
-   "[%s] Unrecognized sense data (in hex):", prefix);

remaining = sense_len;
for (i = 0; i < sense_len; i += 16) {
@@ -1403,9 +1400,10 @@ scsi_dump_sense_buffer(struct scsi_device *sdev, const 
char *prefix,

hex_dump_to_buffer(sense_buffer + i, linelen, 16, 1,
   linebuf, sizeof(linebuf), false);
-   sdev_printk(KERN_INFO, sdev, "[%s] Sense: %s\n",
-   prefix, linebuf);
}
+   sdev_printk(KERN_INFO, sdev,
+   "[%s] Unrecognized sense data (in hex): %s",
+   prefix, linebuf);
  }


See my earlier comment regarding PATCH 03/10.

This doesn't look right -- In Hannes' tree what the code is doing is
printing out a separate line for each 16 bytes of the sense data.
Your change will cause only the last (partial?) 16 bytes to be printed.


That's true. We should not apply this as well.


The removal of the unused sshdr argument is fine, though.


Thanks!

Yoshihiro YUNOMAE


-Ewan



  static void
@@ -1467,8 +1465,7 @@ void __scsi_print_sense(struct scsi_device *sdev, const 
char *name,

if (!scsi_normalize_sense(sense_buffer, sense_len, )) {
/* this may be SCSI-1 sense data */
-   scsi_dump_sense_buffer(sdev, name, sense_buffer,
-  sense_len, );
+   scsi_dump_sense_buffer(sdev, name, sense_buffer, sense_len);
return;
}


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






--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@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: [RFC PATCH 03/10] scsi/constants: Cleanup printk message in __scsi_print_command()

[Yoshihiro YUNOMAE]

Hi Ewan,

Thank you for your review.

(2014/08/16 0:05), Ewan Milne wrote:

On Fri, 2014-08-08 at 11:50 +, Yoshihiro YUNOMAE wrote:

All bytes in CDB should be output after linebuf is filled because
"[%s] CDB: %s\n" message is output many times in loop.

Signed-off-by: Yoshihiro YUNOMAE 
Cc: Hannes Reinecke 
Cc: Doug Gilbert 
Cc: Martin K. Petersen 
Cc: Christoph Hellwig 
Cc: "James E.J. Bottomley" 
Cc: Hidehiro Kawai 
Cc: Masami Hiramatsu 
---
  drivers/scsi/constants.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 9c38b8d..5956d4d 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -413,9 +413,8 @@ void __scsi_print_command(struct scsi_device *sdev, const 
char *prefix,

hex_dump_to_buffer(cdb + i, linelen, 16, 1,
   linebuf, sizeof(linebuf), false);
-   sdev_printk(KERN_INFO, sdev, "[%s] CDB: %s\n",
-   prefix, linebuf);
}
+   sdev_printk(KERN_INFO, sdev, "[%s] CDB: %s\n", prefix, linebuf);
  }
  EXPORT_SYMBOL(__scsi_print_command);


This doesn't look right -- In Hannes' tree what the code is doing is
printing out a separate line for each 16 bytes of the CDB.  You change
will cause only the last (partial?) 16 bytes to be printed.


Ah, that's true. We should not apply this patch.

Thanks,
Yoshihiro YUNOMAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@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: [PATCH 0/2] new APIs to allocate buffer-cache for superblock in non-movable area

[Gioh Kim]

2014-08-18 오후 12:24, Theodore Ts'o 쓴 글:

On Mon, Aug 18, 2014 at 10:15:32AM +0900, Gioh Kim wrote:


My test platform has totally 1GB memory, 256MB for CMA and 768MB for normal.
I applied Joonsoo's patch: https://lkml.org/lkml/2014/5/28/64, so that
3/4 of allocation take place in normal area and 1/4 allocation take place in 
CMA area.

And my platform has 4 ext4 partitions. Each ext4 partition has 2 page caches 
for superblock that
are what this patch tries to move to out of CMA area.
Therefore there are 8 page caches (8 pages size) that can prevent page 
migration.


Yes, but are you actually *using* the ext4 partitions for anything?
If this is a realistic real world use case, file systems are used to
store, well, files, and that means there will be inodes and dentry
cache entries that will also be allocated.  Does your test scenario
reflect real world usage?


Yes. I'm working for LG Electronics.
My test platform is currently selling item in the market.
And also I test my patch when my platform is working as if real user uses it.

I think the page caches of the inodes and dentry are held for short time.
I can see pairs of get_bh and put_bh in inodes/dentry handling.

I think inodes is allocated by kmem_cache_alloc in ext4_alloc_inode().
It is non-movable area allocation.




Cheers,

- Ted


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] time,signal: protect resource use statistics with seqlock

[Mike Galbraith]

On Sat, 2014-08-16 at 19:50 +0200, Oleg Nesterov wrote: 
> On 08/16, Rik van Riel wrote:
> >
> > +   do {
> > +   seq = nextseq;
> > +   read_seqbegin_or_lock(>stats_lock, );
> > +   times->utime = sig->utime;
> > +   times->stime = sig->stime;
> > +   times->sum_exec_runtime = sig->sum_sched_runtime;
> > +
> > +   for_each_thread(tsk, t) {
> > +   task_cputime(t, , );
> > +   times->utime += utime;
> > +   times->stime += stime;
> > +   times->sum_exec_runtime += task_sched_runtime(t);
> > +   }
> > +   /* If lockless access failed, take the lock. */
> > +   nextseq = 1;
> 
> Yes, thanks, this answers my concerns.
> 
> Cough... can't resist, and I still think that we should take rcu_read_lock()
> only around for_each_thread() and the patch expands the critical section for
> no reason. But this is minor, I won't insist.

Hm.  Should traversal not also disable preemption to preserve the error
bound Peter mentioned?

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/9] gpiolib: add API to get gpio desc and flags

[Rafael J. Wysocki]

On Sunday, August 17, 2014 12:43:38 PM Darren Hart wrote:
> On 8/17/14, 6:00, "Grant Likely"  wrote:
> 
> >>
> >>+   /* Using device tree? */
> >>+   if (IS_ENABLED(CONFIG_OF) && dev->of_node)
> >>+   desc = of_find_gpio(dev, NULL, idx, flags);
> >
> >of_find_gpio() doesn't exist.
> 
> Hrm... As of 3.16.0 (e64df3ebe8262c8203d1fe4f541e0241c3112c01)
> 
> $ git blame -L1455,1456 drivers/gpio/gpiolib.c
> bae48da2 (Alexandre Courbot 2013-10-17 10:21:38 -0700 1455) static struct
> gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
> 
> Have we removed this in -next or something? (on the plane, will verify
> upon landing)

In 3.17-rc1:

rafael@vostro:~/src/linux-pm> grep -r of_find_gpio *
drivers/gpio/gpiolib.c:static struct gpio_desc *of_find_gpio(struct device 
*dev, const char *con_id,
drivers/gpio/gpiolib.c: desc = of_find_gpio(dev, con_id, idx, 
);

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/9] Driver core: Unified device properties interface for platform firmware

[Rafael J. Wysocki]

On Sunday, August 17, 2014 12:31:27 PM Darren Hart wrote:
> On 8/17/14, 5:49, "Grant Likely"  wrote:
> 
> >
> >Hi Mika and Rafael,
> >
> >Comments below...

[cut]

> ...
> 
> >> @@ -701,6 +702,7 @@ struct acpi_dev_node {
> >>   * @archdata: For arch-specific additions.
> >>   * @of_node:  Associated device tree node.
> >>   * @acpi_node:Associated ACPI device node.
> >> + * @property_ops: Firmware interface for device properties
> >>   * @devt: For creating the sysfs "dev".
> >>   * @id:   device instance
> >>   * @devres_lock: Spinlock to protect the resource of the device.
> >> @@ -777,6 +779,7 @@ struct device {
> >>  
> >>struct device_node  *of_node; /* associated device tree node */
> >>struct acpi_dev_nodeacpi_node; /* associated ACPI device node */
> >> +  struct dev_prop_ops *property_ops;
> >
> >There are only 2 users of this interface. I don't think adding an ops
> >pointer to each and every struct device is warrented when the wrapper
> >function can check if of_node or acpi_node is set and call the
> >appropriate helper. It is unlikely anything else will use this hook. It
> >will result in smaller memory footprint. Also smaller code when only one
> >of
> >CONFIG_OF and CONFIG_ACPI are selected, which is almost always. :-)
> >
> >It can be refactored later if that ever changes.
> 
> 
> Our intent was to eliminate the #ifdefery in every one of the accessors.
> It was my understanding the ops structures were preferable in such
> situations. For a 64-bit machine with 1000 devices (all of which use
> device properties) with one or the other of ACPI/OF enabled, the
> additional memory requirement here is what... Something like (8*1000 + 4)
> ~= 8KB ? That seems worth the arguably more maintainable code to me. Is
> there more to it than this, am I missing some more significant impact?

Also we wanted to avoid going throug the same sequence of checks every time
a property is accessed for a given device as the result those checks would
lead to every time was already known when the device was registered.

Arguably, if we decide that using DTs and ACPI on the same system at the same
time is a total no-go, then we'll need just one global ops pointer either to
the ACPI or to the DT set of callbacks, but I'm not sure whether or not that
is the way to go.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/9] Driver core: Unified device properties interface for platform firmware

[Rafael J. Wysocki]

On Sunday, August 17, 2014 01:49:13 PM Grant Likely wrote:
> 
> Hi Mika and Rafael,
> 
> Comments below...

[cut]

> > +enum dev_prop_type {
> > +   DEV_PROP_U8,
> > +   DEV_PROP_U16,
> > +   DEV_PROP_U32,
> > +   DEV_PROP_U64,
> > +   DEV_PROP_STRING,
> > +   DEV_PROP_MAX,
> > +};
> > +
> > +struct dev_prop_ops {
> > +   int (*get)(struct device *dev, const char *propname, void **valptr);
> > +   int (*read)(struct device *dev, const char *propname,
> > +   enum dev_prop_type proptype, void *val);
> > +   int (*read_array)(struct device *dev, const char *propname,
> > + enum dev_prop_type proptype, void *val, size_t nval);
> 
> The associated DT functions that implement property reads
> (of_property_read_*) were created in part to provide some type safety
> when reading properties. This proposed API throws that away by accepting
> a void* for the data field, which I don't want to do. This API either
> needs to have a separate accessor for each data type, or it needs some
> other mechanism (accessor macros?) to ensure the right type is passed
> in.

The intention is to add static inline functions like:

int device_property_read_u64(struct device *dev, const char *propname, u64 *val)
{
return device_property_read(dev, propname, DEV_PROP_U64, val);
}

and so on for the other property types.  They just have not been implemented in
this version of the patch.

> 
> > +   int (*child_count)(struct device *dev);
> > +};
> > +
> > +#ifdef CONFIG_ACPI
> > +extern struct dev_prop_ops acpi_property_ops;
> > +#endif
> 
> Rendered moot by my comment about eliminating the ops structure, but the
> above shouldn't appear here. acpi_property_ops shouldn't ever be visible
> outside ACPI core code, so it shouldn't be in this header.

It doesn't look like this has to be present here.  At least this particular
patch should compile just fine after removing the 3 lines above.

That seems to be a leftover from one of the previous versions of it.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] flush_icache_range: Export symbol to fix build errors

[Pranith Kumar]

Fix building errors occuring due to a missing export of flush_icache_range() in
architectures missing the export.

Signed-off-by: Pranith Kumar 
Reported-by: Geert Uytterhoeven 
CC: Andrew Morton 
---
 arch/arc/mm/cache_arc700.c |1 +
 arch/blackfin/include/asm/cacheflush.h |1 +
 arch/frv/include/asm/cacheflush.h  |1 +
 arch/hexagon/mm/cache.c|1 +
 arch/metag/include/asm/cacheflush.h|1 +
 arch/sh/mm/cache.c |1 +
 arch/tile/kernel/smp.c |1 +
 arch/xtensa/kernel/smp.c   |1 +
 8 files changed, 8 insertions(+)

diff --git a/arch/arc/mm/cache_arc700.c b/arch/arc/mm/cache_arc700.c
index 4670afc..e88ddbf 100644
--- a/arch/arc/mm/cache_arc700.c
+++ b/arch/arc/mm/cache_arc700.c
@@ -581,6 +581,7 @@ void flush_icache_range(unsigned long kstart, unsigned long 
kend)
tot_sz -= sz;
}
 }
+EXPORT_SYMBOL(flush_icache_range);
 
 /*
  * General purpose helper to make I and D cache lines consistent.
diff --git a/arch/blackfin/include/asm/cacheflush.h 
b/arch/blackfin/include/asm/cacheflush.h
index 9a5b2c5..0e2eb8c 100644
--- a/arch/blackfin/include/asm/cacheflush.h
+++ b/arch/blackfin/include/asm/cacheflush.h
@@ -70,6 +70,7 @@ static inline void flush_icache_range(unsigned start, 
unsigned end)
}
 #endif
 }
+EXPORT_SYMBOL(flush_icache_range);
 
 #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
 do { memcpy(dst, src, len);\
diff --git a/arch/frv/include/asm/cacheflush.h 
b/arch/frv/include/asm/cacheflush.h
index edbac54..07ee4b3 100644
--- a/arch/frv/include/asm/cacheflush.h
+++ b/arch/frv/include/asm/cacheflush.h
@@ -72,6 +72,7 @@ static inline void flush_icache_range(unsigned long start, 
unsigned long end)
 {
frv_cache_wback_inv(start, end);
 }
+EXPORT_SYMBOL(flush_icache_range);
 
 #ifdef CONFIG_MMU
 extern void flush_icache_user_range(struct vm_area_struct *vma, struct page 
*page,
diff --git a/arch/hexagon/mm/cache.c b/arch/hexagon/mm/cache.c
index fe14ccf..0c76c80 100644
--- a/arch/hexagon/mm/cache.c
+++ b/arch/hexagon/mm/cache.c
@@ -68,6 +68,7 @@ void flush_icache_range(unsigned long start, unsigned long 
end)
);
local_irq_restore(flags);
 }
+EXPORT_SYMBOL(flush_icache_range);
 
 void hexagon_clean_dcache_range(unsigned long start, unsigned long end)
 {
diff --git a/arch/metag/include/asm/cacheflush.h 
b/arch/metag/include/asm/cacheflush.h
index 7787ec5..117c212 100644
--- a/arch/metag/include/asm/cacheflush.h
+++ b/arch/metag/include/asm/cacheflush.h
@@ -124,6 +124,7 @@ static inline void flush_icache_range(unsigned long address,
metag_code_cache_flush((void *) address, endaddr - address);
 #endif
 }
+EXPORT_SYMBOL(flush_icache_range);
 
 static inline void flush_cache_sigtramp(unsigned long addr, int size)
 {
diff --git a/arch/sh/mm/cache.c b/arch/sh/mm/cache.c
index 097c2cd..f770e39 100644
--- a/arch/sh/mm/cache.c
+++ b/arch/sh/mm/cache.c
@@ -229,6 +229,7 @@ void flush_icache_range(unsigned long start, unsigned long 
end)
 
cacheop_on_each_cpu(local_flush_icache_range, (void *), 1);
 }
+EXPORT_SYMBOL(flush_icache_range);
 
 void flush_icache_page(struct vm_area_struct *vma, struct page *page)
 {
diff --git a/arch/tile/kernel/smp.c b/arch/tile/kernel/smp.c
index 01e8ab2..19eaa62 100644
--- a/arch/tile/kernel/smp.c
+++ b/arch/tile/kernel/smp.c
@@ -183,6 +183,7 @@ void flush_icache_range(unsigned long start, unsigned long 
end)
preempt_enable();
}
 }
+EXPORT_SYMBOL(flush_icache_range);
 
 
 /* Called when smp_send_reschedule() triggers IRQ_RESCHEDULE. */
diff --git a/arch/xtensa/kernel/smp.c b/arch/xtensa/kernel/smp.c
index 40b5a37..4d02e38 100644
--- a/arch/xtensa/kernel/smp.c
+++ b/arch/xtensa/kernel/smp.c
@@ -571,6 +571,7 @@ void flush_icache_range(unsigned long start, unsigned long 
end)
};
on_each_cpu(ipi_flush_icache_range, , 1);
 }
+EXPORT_SYMBOL(flush_icache_range);
 
 /* - */
 
-- 
1.7.9.5

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

RE: [PATCH] Input: hyperv-keyboard - implement Type Clipboard Text

[Dexuan Cui]

> -Original Message-
> From: Dmitry Torokhov
> Sent: Saturday, August 16, 2014 0:58 AM
> To: Dexuan Cui
> > For each char in the string, the host sends 2 events (key down/up with the
> > char's UNICODE value) to the guest.
> > The patch finds each char's scan codes of key down/up, and injects the
> > scan codes to the serio keyboard module.
> >
> > Known issues:
> > 1) Only printable ASCII chars are supported, and unsupported chars are
> > ignored. It seems unlikely to support generic UNICODE chars because there
> > is not a generic API to inject a UNICODE char to text mode console, KDE,
> > gnome, etc.
> >
> > 2) When we use the feature, make sure the CapsLock state of the VM's
> > (virtual) keyboard is OFF because this patch assumes it -- we'll try to
> > fix this later, probably by tracking the state of virtual CapsLock, because
> > it looks the keyboard module doesn't supply an API for us to query the
> state
> > of the keyboard.
> >
> No way. If you want to do this this way, do it in hypervisor code and keep
> feeding AT scan codes to hyperv-keyboard, although I am pretty sure users
Hi Dmitry,
Yeah, I had the same wish, but later I found this seems unlikely because IMO
the feature was firstly invented for Windows VM + generic UNICODE chars,
and we know there is no "scan code" for generic UNICODE chars... :-(

> of
> French, Czech and other keyboard layouts with numbers in upper register
> and
> symbols in lower will have a few choice words for you.
Sorry, I can't understand what these are.
Can you please give more details or a link to further info?

> If you want real cut-and-paste support in various DEs I'd recommend
> working
> with VMware on open-vm-tools package to see what can be shared/reused
> there.
> Consider this NACked with prejudice.
> Dmitry
Thanks for the suggestion!
Let me study open-vm-tools and report back.

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

Re: linux-next: Tree for Aug 18

[Stephen Rothwell]

Hi all,

On Mon, 18 Aug 2014 13:32:59 +1000 Stephen Rothwell  
wrote:
>
> Please do not add code intended for v3.18 until after v3.17-rc1 is
> released.

Which it is, of course ...

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


signature.asc
Description: PGP signature

[PATCH] staging: comedi: s626: remove unnecessary variable initialization

[Chase Southwood]

We initialize 'irqbit' to 0, only to properly set it immediately
afterwards.  Just remove the zero-initialization.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
 drivers/staging/comedi/drivers/s626.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 080608a..e42720c 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -1399,7 +1399,6 @@ static void s626_check_dio_interrupts(struct 
comedi_device *dev)
uint8_t group;
 
for (group = 0; group < S626_DIO_BANKS; group++) {
-   irqbit = 0;
/* read interrupt type */
irqbit = s626_debi_read(dev, S626_LP_RDCAPFLG(group));
 
-- 
2.0.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] staging: comedi: dt2801: change function return type to void

[Chase Southwood]

cppcheck was complaining that the variable 'stat' is being reassigned
before the old value is used.  Upon inspection, I found that
dt2801_writecmd() cannot fail, always returns 0, and most callers already
do not bother with assigning its return value anyway, so it makes sense to
just change the return type for this function from int to void, and remove
the two assignments to 'stat'.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
 drivers/staging/comedi/drivers/dt2801.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dt2801.c 
b/drivers/staging/comedi/drivers/dt2801.c
index ad8ba0b..c16d468 100644
--- a/drivers/staging/comedi/drivers/dt2801.c
+++ b/drivers/staging/comedi/drivers/dt2801.c
@@ -309,7 +309,7 @@ static int dt2801_wait_for_ready(struct comedi_device *dev)
return -ETIME;
 }
 
-static int dt2801_writecmd(struct comedi_device *dev, int command)
+static void dt2801_writecmd(struct comedi_device *dev, int command)
 {
int stat;
 
@@ -323,8 +323,6 @@ static int dt2801_writecmd(struct comedi_device *dev, int 
command)
if (!(stat & DT_S_READY))
dev_dbg(dev->class_dev, "!ready in %s, ignoring\n", __func__);
outb_p(command, dev->iobase + DT2801_CMD);
-
-   return 0;
 }
 
 static int dt2801_reset(struct comedi_device *dev)
@@ -380,7 +378,7 @@ static int probe_number_of_ai_chans(struct comedi_device 
*dev)
int data;
 
for (n_chans = 0; n_chans < 16; n_chans++) {
-   stat = dt2801_writecmd(dev, DT_C_READ_ADIM);
+   dt2801_writecmd(dev, DT_C_READ_ADIM);
dt2801_writedata(dev, 0);
dt2801_writedata(dev, n_chans);
stat = dt2801_readdata2(dev, );
@@ -451,7 +449,7 @@ static int dt2801_ai_insn_read(struct comedi_device *dev,
int i;
 
for (i = 0; i < insn->n; i++) {
-   stat = dt2801_writecmd(dev, DT_C_READ_ADIM);
+   dt2801_writecmd(dev, DT_C_READ_ADIM);
dt2801_writedata(dev, CR_RANGE(insn->chanspec));
dt2801_writedata(dev, CR_CHAN(insn->chanspec));
stat = dt2801_readdata2(dev, );
-- 
2.0.4

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

linux-next: Tree for Aug 18

[Stephen Rothwell]

Hi all,

Please do not add code intended for v3.18 until after v3.17-rc1 is
released.

Changes since 20140815:

The sound-asoc tree gained a build failure for which I reverted a commit.

The regulator tree gained a build failure so I used the verison from
next-20140815.

The staging tree gained a build failure for which I applied a fix patch.

Non-merge commits (relative to Linus' tree): 1010
 955 files changed, 25072 insertions(+), 21100 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (7d1311b93e58 Linux 3.17-rc1)
Merging fixes/master (23cf8d3ca0fd powerpc: Fix "attempt to move .org 
backwards" error)
Merging kbuild-current/rc-fixes (dd5a6752ae7d firmware: Create directories for 
external firmware)
Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4)
Merging arm-current/fixes (e57e41931134 ARM: wire up memfd_create syscall)
Merging m68k-current/for-linus (9117710a5997 m68k/sun3: Remove define statement 
no longer needed)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (08a9c3c9afcf MIPS: OCTEON: make 
get_system_type() thread-safe)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging sparc/master (c9d26423e56c Merge tag 'pm+acpi-3.17-rc1-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging net/master (21009686662f net: phy: smsc: move smsc_phy_config_init 
reset part in a soft_reset function)
Merging ipsec/master (a0e5ef53aac8 xfrm: Fix installation of AH IPsec SAs)
Merging sound-current/for-linus (f3ee07d8b6e0 ALSA: hda/realtek - Avoid setting 
wrong COEF on ALC269 & co)
Merging pci-current/for-linus (9baa3c34ac4e PCI: Remove DEFINE_PCI_DEVICE_TABLE 
macro use)
Merging wireless/master (77b2f2865956 iwlwifi: mvm: disable scheduled scan to 
prevent firmware crash)
Merging driver-core.current/driver-core-linus (7d1311b93e58 Linux 3.17-rc1)
Merging tty.current/tty-linus (7d1311b93e58 Linux 3.17-rc1)
Merging usb.current/usb-linus (7d1311b93e58 Linux 3.17-rc1)
Merging usb-gadget-fixes/fixes (a8a85b01d185 usb: musb/cppi41: call 
musb_ep_select() before accessing an endpoint's CSR)
CONFLICT (content): Merge conflict in drivers/usb/musb/musb_host.c
Merging usb-serial-fixes/usb-linus (7d1311b93e58 Linux 3.17-rc1)
Merging staging.current/staging-linus (eb29835fb3ae staging: android: fix a 
possible memory leak)
Merging char-misc.current/char-misc-linus (7d1311b93e58 Linux 3.17-rc1)
Merging input-current/for-linus (91167e191467 Merge branch 'next' into 
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (ce5481d01f67 crypto: drbg - fix failure of 
generating multiple of 2**16 bytes)
Merging ide/master (a53dae49b2fe ide: use module_platform_driver())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (5a12a597a862 arm: Add devicetree 
fixup machine function)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting 
module removal.)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging drm-intel-fixes/for-linux-next-fixes (103ae732ad26 drm/i915: Don't try 
to enable cursor from setplane when crtc is 

Re: [PATCH v2] memory-hotplug: add sysfs zones_online_to attribute

[Zhang Zhen]

On 2014/8/16 5:37, Toshi Kani wrote:
> On Wed, 2014-08-13 at 12:10 +0800, Zhang Zhen wrote:
>> Currently memory-hotplug has two limits:
>> 1. If the memory block is in ZONE_NORMAL, you can change it to
>> ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
>> 2. If the memory block is in ZONE_MOVABLE, you can change it to
>> ZONE_NORMAL, but this memory block must be adjacent to ZONE_NORMAL.
>>
>> With this patch, we can easy to know a memory block can be onlined to
>> which zone, and don't need to know the above two limits.
>>
>> Updated the related Documentation.
>>
>> Change v1 -> v2:
>> - optimize the implementation following Dave Hansen's suggestion
>>
>> Signed-off-by: Zhang Zhen 
>> ---
>>  Documentation/ABI/testing/sysfs-devices-memory |  8 
>>  Documentation/memory-hotplug.txt   |  4 +-
>>  drivers/base/memory.c  | 62 
>> ++
>>  include/linux/memory_hotplug.h |  1 +
>>  mm/memory_hotplug.c|  2 +-
>>  5 files changed, 75 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-devices-memory 
>> b/Documentation/ABI/testing/sysfs-devices-memory
>> index 7405de2..2b2a1d7 100644
>> --- a/Documentation/ABI/testing/sysfs-devices-memory
>> +++ b/Documentation/ABI/testing/sysfs-devices-memory
>> @@ -61,6 +61,14 @@ Users:hotplug memory remove tools
>>  
>> http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
>>
>>
>> +What:   /sys/devices/system/memory/memoryX/zones_online_to
> 
> I think this name is a bit confusing.  How about "valid_online_types"?
> 
Thanks for your suggestion.

This patch has been added to -mm tree.
If most people think so, i would like to modify the interface name.
If not, let's leave it as it is.

Best regards!
> Thanks,
> -Toshi
> 
> 
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> 
> 


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

Re: [PATCH 0/2] new APIs to allocate buffer-cache for superblock in non-movable area

[Theodore Ts'o]

On Mon, Aug 18, 2014 at 10:15:32AM +0900, Gioh Kim wrote:
> 
> My test platform has totally 1GB memory, 256MB for CMA and 768MB for normal.
> I applied Joonsoo's patch: https://lkml.org/lkml/2014/5/28/64, so that
> 3/4 of allocation take place in normal area and 1/4 allocation take place in 
> CMA area.
> 
> And my platform has 4 ext4 partitions. Each ext4 partition has 2 page caches 
> for superblock that
> are what this patch tries to move to out of CMA area.
> Therefore there are 8 page caches (8 pages size) that can prevent page 
> migration.

Yes, but are you actually *using* the ext4 partitions for anything?
If this is a realistic real world use case, file systems are used to
store, well, files, and that means there will be inodes and dentry
cache entries that will also be allocated.  Does your test scenario
reflect real world usage?

Cheers,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mem-hotplug: let memblock skip the hotpluggable memory regions in __next_mem_range()

[Xishi Qiu]

On 2014/8/18 9:13, tangchen wrote:

> Hi tj,
> 
> On 08/17/2014 07:08 PM, Tejun Heo wrote:
>> Hello,
>>
>> On Sat, Aug 16, 2014 at 10:36:41PM +0800, Xishi Qiu wrote:
>>> numa_clear_node_hotplug()? There is only numa_clear_kernel_node_hotplug().
>> Yeah, that one.
>>
>>> If we don't clear hotpluggable flag in free_low_memory_core_early(), the
>>> memory which marked hotpluggable flag will not free to buddy allocator.
>>> Because __next_mem_range() will skip them.
>>>
>>> free_low_memory_core_early
>>> for_each_free_mem_range
>>> for_each_mem_range
>>> __next_mem_range   
>> Ah, okay, so the patch fixes __next_mem_range() and thus makes
>> free_low_memory_core_early() to skip hotpluggable regions unlike
>> before.  Please explain things like that in the changelog.  Also,
>> what's its relationship with numa_clear_kernel_node_hotplug()?  Do we
>> still need them?  If so, what are the different roles that these two
>> separate places serve?
> 
> numa_clear_kernel_node_hotplug() only clears hotplug flags for the nodes
> the kernel resides in, not for hotpluggable nodes. The reason why we did
> this is to enable the kernel to allocate memory in case all the nodes are
> hotpluggable.
> 

Hi TangChen,

I find a problem in numa_init() (arch/x86/mm/numa.c)
numa_init()
...
ret = init_func();  // this will mark hotpluggable flag from SRAT
...
memblock_set_bottom_up(false);
...
ret = numa_register_memblks(_meminfo);  // this will alloc node 
data(pglist_data) 
...
numa_clear_kernel_node_hotplug();  // in case all the nodes are 
hotpluggable
...

If all the nodes are marked hotpluggable flag, alloc node data will fail.
Because __next_mem_range_rev() will skip the hotpluggable memory regions.
numa_register_memblks()
setup_node_data()
memblock_find_in_range_node()
__memblock_find_range_top_down()
for_each_mem_range_rev()
__next_mem_range_rev()

What do you think?
How about move numa_clear_kernel_node_hotplug() into numa_register_memblks(),
like this:

numa_register_memblks()

...
memblock_set_node(mb->start, mb->end - mb->start,
  , mb->nid);
}

+numa_clear_kernel_node_hotplug();

/*
 * If sections array is gonna be used for pfn -> nid mapping, check
...

Thanks,
Xishi Qiu

> And we clear hotplug flags for all the nodes in free_low_memory_core_early()
> is because if we do not, all hotpluggable memory won't be able to be freed
> to buddy after Qiu's patch.
> 
> 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] earlyprintk: re-enable earlyprintk calling early_param

[Sahara]

2014년 08월 16일 03:34, Rusty Russell 쓴 글:

kpark3...@gmail.com writes:

From: Sahara 

Although there are many obs_kernel_param and its names are
earlyprintk and also EARLY_PRINTK is also enabled, we could not
see the early_printk output properly until now. This patch
considers earlycon as well as earlyprintk.

Hmm, the initial "earlycon" hack slipped in when I wasn't looking.
I don't think we should extend it.

Why not make the thing(s) you want early_param()s?

Cheers,
Rusty.
The earlycon and the earlyprintk are scattered and used in many 
architectures.

It looks earlycon just could be a subset of earlyprintk.
The earlycon is for uart specific, while the earlyprintk is to support 
vga, efi, xen, serial, and so on. Especially ARM uses earlyprintk in 
many places. And, I am not sure if this is a good chance to replace all 
the earlyprintk with the earlycon. As of now, it's fair for both 
earlycon and earlyprintk.
Or perhaps removing case#2, see in my previous email to Andrew Morton, 
is better?, so users be forced to specify earlycon and earlyprintk in 
cmdline if they want to see early_printk() output.


Thanks.

Best Regards,
Sahara.




--- a/init/main.c
+++ b/init/main.c
@@ -426,7 +426,8 @@ static int __init do_early_param(char *param, char *val, 
const char *unused)
for (p = __setup_start; p < __setup_end; p++) {
if ((p->early && parameq(param, p->str)) ||
(strcmp(param, "console") == 0 &&
-strcmp(p->str, "earlycon") == 0)
+((strcmp(p->str, "earlycon") == 0) ||
+(strcmp(p->str, "earlyprintk") == 0)))
) {
if (p->setup_func(val) != 0)
pr_warn("Malformed early option '%s'\n", param);
--
1.7.9.5


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

Re: [PATCH net-next] vhost_net: stop rx net polling when possible

[Jason Wang]

On 08/17/2014 06:20 PM, Michael S. Tsirkin wrote:
> On Fri, Aug 15, 2014 at 11:40:08AM +0800, Jason Wang wrote:
>> After rx vq was enabled, we never stop polling its socket. This is sub 
>> optimal
>> when may lead unnecessary wake-ups after the rx net work has already been
>> queued. This could be optimized by stopping polling the rx net sock when
>> processing both rx and tx and restart it afterward. This could save 
>> unnecessary
>> wake-ups and even unnecessary spin locks acquiring with the help of commit
>> 9e641bdcfa4ef4d6e2fbaa59c1be0ad5d1551fd5 "net-tun: restructure tun_do_read 
>> for
>> better sleep/wakeup efficiency".
> OK so the point is to avoid expensive wake_up_process calls?
> It's a bit unfortunate that we are adding/removing things from wait
> queue which certainly does take extra spin-locks.

When nothing new were queued during vhost thread is running. This change
may add two more spin-locks which may not but optimal. But if several
packets were queued by tun during vhost thread is running, it may save
lots of unnecessary wake ups. So the patch helps the performance in the
heavy load case for sure. In light load case, it may hurt some
throughput but cpu and thru/cpu is still saved.

>
>
>
>> Test shows significant CPU% savings during almost all the cases:
>>
>> Guest rx stream:
>> size(B)/sessions/throughput/cpu/normalized thru/
>> 64/1/+0.7773%   -8.6224% +10.2866%
>> 64/2/+0.6335%   -13.9109%+16.8946%
>> 64/4/-0.8182%   -14.8336%+16.4565%
>> 64/8/+0.4830%   -13.7675%+16.5256%
>> 256/1/-7.0963%  -12.6880%+6.4043%
>> 256/2/-1.3982%  -11.5424%+11.4678%
>> 256/4/-0.0350%  -11.8323%+13.3806%
>> 256/8/-1.5830%  -12.7693%+12.8238%
>> 1024/1/-7.4895% -19.1449%   +14.4152%
>> 1024/2/-7.4575% -19.4018%   +14.8195%
>> 1024/4/-0.3881% -9.1183%+9.6061%
>> 1024/8/+0.4713% -11.0155%   +12.9087%
>> 4096/1/+0.8786%  -8.4050%+10.1355%
>> 4096/2/+0.0098%  -15.3094%   +18.0885%
>> 4096/4/+0.0445%  -10.8247%   +12.1886%
>> 4096/8/-2.1317%  -12.5111%   +11.8637%
>> 16384/1/-0.0008% -6.1891%+6.5966%
>> 16384/2/-0.0117% -16.2716%   +19.4198%
>> 16384/4/+0.0001% -5.9197%+6.2923%
>> 16384/8/+0.0173% -7.6681%+8.3236%
>> 65535/1/+0.0011% -10.3594%   +11.5578%
>> 65535/2/-0.4108%  -14.4304%   +16.3838%
>> 65535/4/+0.0011%  -10.3594%   +11.5578%
>> 65535/8/-0.4108%  -14.4304%   +16.3838%
>>
>> Guest tx stream:
>> size(B)/sessions/throughput/cpu/normalized thru/
>> 64/1/-0.6228% -2.1936% +1.6060%
>> 64/2/+0.8646% -3.5063% +4.5297%
>> 64/4/+0.8733% -3.2495% +4.2613%
>> 64/8/+1.4290% -3.5593% +5.1724%
>> 256/1/+7.2098%-3.1122% +10.6535%
>> 256/2/-10.1408%   -6.8230% -3.5607%
>> 256/4/-11.3531%   -6.7085% -4.9785%
>> 256/8/-10.2723%   -6.5628% -3.9701%
>> 1024/1/-18.9329%  -13.6162%-6.1547%
>> 1024/2/-0.3728%   -1.3181% +0.9580%
>> 1024/4/+0.0125%   -3.6338% +3.7838%
>> 1024/8/-0.0030%   -2.7282% +2.8017%
>> 4096/1/+16.9367%  -1.9435% +19.2543%
>> 4096/2/+0.0121%   -6.1682% +6.5866%
>> 4096/4/+0.0019%   -3.8510% +4.0072%
>> 4096/8/-0.0222%   -4.1368% +4.2922%
>> 16384/1/-0.0026%  -8.6892% +9.5132%
>> 16384/2/-0.0012%  -10.1676%+11.3171%
>> 16384/4/+0.0196%  -1.2551% +1.2908%
>> 16384/8/+0.1303%  -3.2634% +3.5082%
>> 65535/1/+0.0019%  -3.4694% +3.5961%
>> 65535/2/-0.0003%  -0.7635% +0.7690%
>> 65535/4/-0.0219%  -2.7875% +2.8448%
>> 65535/8/+0.1137%  -2.7922% +2.9894%
>>
>> TCP_RR:
>> size(B)/sessions/throughput/cpu/normalized thru/
>> 256/1/+1.9004%-4.7985% +7.0366%
>> 256/25/-4.7366%   -11.0809%+7.1349%
>> 256/50/+3.9808%   -5.2037% +9.6887%
>> 4096/1/+2.1619%   -0.7303% +2.9134%
>> 4096/25/-13.1836% -14.7298%+1.8134%
>> 4096/50/-11.1990% -15.4763%+5.0605%
>>
>> Signed-off-by: Jason Wang 
>
> Could you split RX/TX parts out please, and benchmark separately?
>
> They are really independent.

Ok.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: power supply gating with ltc2978

[Guenter Roeck]

On Sat, Aug 16, 2014 at 02:20:50PM +0100, Mark Brown wrote:
> On Fri, Aug 15, 2014 at 04:34:49PM -0500, atull wrote:
> 
> > I am interested in adding functionality to be able to gate power supplies 
> > going through a ltc2978.  I see that there is a hwmon driver already 
> > existing (hwmon/pmbus/ltc2978.c).  I see some of the other hwmon drivers 
> > have MFD's.  It looks like this ltc driver would need a MFD and a 
> > regulator driver added.  However I don't see other pmbus hwmon drivers
> > using MFD.
> 
> > So I am asking for recommendations and reservations on how to proceed here 
> > before I get too far with this.
> 
> Without knowing anything at all about pmbus or this particular hardware
> it's hard to comment but what you're saying here sounds sensible (though
> I do see that apparently splitting the drivers may not actually be
> sensible from Guenter's followup).

I had originally thought about converting the pmbus drivers to mfd with client
drivers, but I concluded that it would add a lot of complexity with little gain.
It makes sense to separate a driver into mfd and a number of client drivers
if a device has clear functional blocks for the different devices it supports.
With PMBus, this is not the case. Separating a PMBus driver would be a purely
artificial costruct, and there would be overlapping functionality. Separating
just a single driver out of the group of PMBus drivers, as seems to be suggested
above, makes even less sense as one simply can not separate the core PMBus
driver code from its front-end drivers.

On the other side, adding regulator support into the PMBus driver code would
make a lot of sense. It should also be quite straightforward.

Or anyway that is my opinion. If someone wants to spend the time and separate
the PMBus drivers into an MfD part and hwmon and regulator client drivers, I'll
be happy to look at the resulting patch set.

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

Re: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on sdio thread

[Fu, Zhonghui]

>From 21266249bbbaf9407c1e88cd5950e06ac88aeebf Mon Sep 17 00:00:00 2001
From: Fu Zhonghui 
Date: Mon, 18 Aug 2014 10:48:14 +0800
Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on sdio 
thread

781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
the use of our own custom threaded IRQ handler, but left in an
unconditional wake_up_process() on that handler at resume-time.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=80151

In addition, the check for MMC_CAP_SDIO_IRQ capability is added
before enable sdio IRQ.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Chris Ball 
Signed-off-by: Ulf Hansson 
Signed-off-by: Fu Zhonghui 
---
 drivers/mmc/core/sdio.c |   12 ++--
 drivers/mmc/core/sdio_irq.c |4 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index e636d9e..3fc40a7 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -992,8 +992,16 @@ static int mmc_sdio_resume(struct mmc_host *host)
}
}
 
-   if (!err && host->sdio_irqs)
-   wake_up_process(host->sdio_irq_thread);
+   if (!err && host->sdio_irqs) {
+   if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD)) {
+   wake_up_process(host->sdio_irq_thread);
+   } else if (host->caps & MMC_CAP_SDIO_IRQ) {
+   mmc_host_clk_hold(host);
+   host->ops->enable_sdio_irq(host, 1);
+   mmc_host_clk_release(host);
+   }
+   }
+
mmc_release_host(host);
 
host->pm_flags &= ~MMC_PM_KEEP_POWER;
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index 5cc13c8..696eca4 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -208,7 +208,7 @@ static int sdio_card_irq_get(struct mmc_card *card)
host->sdio_irqs--;
return err;
}
-   } else {
+   } else if (host->caps & MMC_CAP_SDIO_IRQ) {
mmc_host_clk_hold(host);
host->ops->enable_sdio_irq(host, 1);
mmc_host_clk_release(host);
@@ -229,7 +229,7 @@ static int sdio_card_irq_put(struct mmc_card *card)
if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD)) {
atomic_set(>sdio_irq_thread_abort, 1);
kthread_stop(host->sdio_irq_thread);
-   } else {
+   } else if (host->caps & MMC_CAP_SDIO_IRQ) {
mmc_host_clk_hold(host);
host->ops->enable_sdio_irq(host, 0);
mmc_host_clk_release(host);
-- 1.7.1

On 2014/8/12 18:23, Ulf Hansson wrote:
> On 11 August 2014 07:49, Fu, Zhonghui  wrote:
>> From 6cee984e1d76ba0a3320430f8cf4318ab65fcf06 Mon Sep 17 00:00:00 2001
>> From: Fu Zhonghui 
>> Date: Tue, 5 Aug 2014 12:44:38 +0800
>> Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on 
>> sdio thread
>>
>> 781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
>> bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
>> the use of our own custom threaded IRQ handler, but left in an
>> unconditional wake_up_process() on that handler at resume-time.
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=80151
>>
>> In addition, the check for MMC_CAP_SDIO_IRQ capability is added
>> before enable sdio IRQ.
>>
>> Signed-off-by: Jaehoon Chung 
>> Signed-off-by: Chris Ball 
>> Signed-off-by: Fu Zhonghui 
>> ---
>>  drivers/mmc/core/sdio.c |   14 --
>>  drivers/mmc/core/sdio_irq.c |4 ++--
>>  2 files changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
>> index e636d9e..e04a540 100644
>> --- a/drivers/mmc/core/sdio.c
>> +++ b/drivers/mmc/core/sdio.c
>> @@ -992,8 +992,18 @@ static int mmc_sdio_resume(struct mmc_host *host)
>> }
>> }
>>
>> -   if (!err && host->sdio_irqs)
>> -   wake_up_process(host->sdio_irq_thread);
>> +   if (!err && host->sdio_irqs) {
>> +   if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD)) {
>> +   wake_up_process(host->sdio_irq_thread);
>> +   } else if (host->caps & MMC_CAP_SDIO_IRQ) {
>> +   mmc_release_host(host);
> Why mmc_release_host() and the corresponding mmc_claim_host() below?
> Those shouldn't be needed I think.

You are right. These two functions shouldn't be invoked here. I made a new 
patch as above.


Thanks,
Zhonghui
>
>
>> +   mmc_host_clk_hold(host);
>> +   host->ops->enable_sdio_irq(host, 1);
>> +   mmc_host_clk_release(host);
>> +   mmc_claim_host(host);
>> +   }
>> +

Re: [PATCH] earlyprintk: re-enable earlyprintk calling early_param

[Sahara]

2014년 08월 15일 05:34, Andrew Morton 쓴 글:

On Thu, 14 Aug 2014 19:13:36 +0900 kpark3...@gmail.com wrote:


From: Sahara 

Although there are many obs_kernel_param and its names are
earlyprintk and also EARLY_PRINTK is also enabled, we could not
see the early_printk output properly until now. This patch
considers earlycon as well as earlyprintk.

Sorry, I just don't understand this description.

What does the patch actually do?  What was the kernel behaviour without
the patch and what is the kernel behaviour with the patch?


Without this patch,
- earlycon case -
if early_param("earlycon", ...) is defined and
case #1: if cmdline has "earlycon", then it satisfies the condition 
"(p->early && parameq(param, p->str))". You can see early_printk().
case #2: if cmdline has "console", then it satisfies the condition 
"strcmp(param, "console") == 0 && strcmp(p->str, "earlycon") == 0". You 
can see early_printk().


- earlyprintk case -
if early_param("earlyprintk", ...) is defined and
case #1: if cmdline has "earlyprintk", then it satisfies the condition 
"(p->early && parameq(param, p->str))". You can see early_printk().
case #2: if cmdline has "console", it does not satisfies the condition, 
because it only checks out "earlycon" only.


This patch fixes the case #2 problem of earlyprintk.

Thanks.

Best Regards,
Sahara.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 26/35] [PATCH 26/36] powerpc: Replace __get_cpu_var uses

[Christoph Lameter]

korg tester found an issue:


From: Christoph Lameter 
Subject: powerpc: Fix reference to opal_trace_depth.

depth is an address and not a scalar. Use & to determine the address.

Signed-off-by: Christoph Lameter 

Index: linux/arch/powerpc/platforms/powernv/opal-tracepoints.c
===
--- linux.orig/arch/powerpc/platforms/powernv/opal-tracepoints.c
+++ linux/arch/powerpc/platforms/powernv/opal-tracepoints.c
@@ -48,7 +48,7 @@ void __trace_opal_entry(unsigned long op

local_irq_save(flags);

-   depth = this_cpu_ptr(opal_trace_depth);
+   depth = this_cpu_ptr(_trace_depth);

if (*depth)
goto out;
@@ -69,7 +69,7 @@ void __trace_opal_exit(long opcode, unsi

local_irq_save(flags);

-   depth = this_cpu_ptr(opal_trace_depth);
+   depth = this_cpu_ptr(_trace_depth);

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

Re: [PATCH 1/3] of: Add of_match_machine helper

[Grant Likely]

On Fri, 8 Aug 2014 02:01:53 +0300, Tuomas Tynkkynen  
wrote:
> Add of_match_machine function to test the device tree root for an
> of_match array. This can be useful when testing SoC versions at runtime,
> for example.
> 
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  drivers/of/base.c  | 21 +
>  include/linux/of.h |  3 +++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d8574ad..37798ea 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -977,6 +977,27 @@ struct device_node 
> *of_find_matching_node_and_match(struct device_node *from,
>  EXPORT_SYMBOL(of_find_matching_node_and_match);
>  
>  /**
> + * of_match_machine - Tell if root of device tree has a matching of_match 
> struct
> + *   @matches:   array of of device match structures to search in
> + *
> + *   Returns the result of of_match_node for the root node.
> + */
> +const struct of_device_id *of_match_machine(const struct of_device_id 
> *matches)
> +{
> + const struct of_device_id *match;
> + struct device_node *root;
> +
> + root = of_find_node_by_path("/");
> + if (!root)
> + return NULL;
> +
> + match = of_match_node(matches, root);
> + of_node_put(root);
> + return match;
> +}
> +EXPORT_SYMBOL(of_match_machine);

Too wordy...

return of_match_node(matches, of_allnodes);

:-)

It could be a static inline, but I don't think it's even worth having a
helper. The callers could just open code the above.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: core: Fix build error due to const qualifier for ops

[Axel Lin]

Drop const qualifier for ops of struct regulator_desc.
Allow regulator drivers to update ops before registering regulator.

Fix below build error:
  CC [M]  drivers/regulator/mc13892-regulator.o
drivers/regulator/mc13892-regulator.c: In function 'mc13892_regulator_probe':
drivers/regulator/mc13892-regulator.c:586:3: error: assignment of member 
'set_mode' in read-only object
drivers/regulator/mc13892-regulator.c:588:3: error: assignment of member 
'get_mode' in read-only object
make[2]: *** [drivers/regulator/mc13892-regulator.o] Error 1
make[1]: *** [drivers/regulator] Error 2
make: *** [drivers] Error 2

Reported-by: Stephen Rothwell 
Signed-off-by: Axel Lin 
---
 include/linux/regulator/driver.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index efe058f..3abda75 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -246,7 +246,7 @@ struct regulator_desc {
int id;
bool continuous_voltage_range;
unsigned n_voltages;
-   const struct regulator_ops *ops;
+   struct regulator_ops *ops;
int irq;
enum regulator_type type;
struct module *owner;
-- 
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 1/3] of: Add of_match_machine helper

[Grant Likely]

On Fri, 8 Aug 2014 14:01:57 -0500, Rob Herring  wrote:
> On Fri, Aug 8, 2014 at 8:23 AM, Tuomas Tynkkynen  
> wrote:
> >
> >
> > On 08/08/14 12:41, Thierry Reding wrote:
> >>
> >>> +const struct of_device_id *of_match_machine(const struct of_device_id 
> >>> *matches)
> >>> +{
> >>> +const struct of_device_id *match;
> >>> +struct device_node *root;
> >>> +
> >>> +root = of_find_node_by_path("/");
> >>> +if (!root)
> >>> +return NULL;
> >>> +
> >>> +match = of_match_node(matches, root);
> >>> +of_node_put(root);
> >>> +return match;
> >>> +}
> >>> +EXPORT_SYMBOL(of_match_machine);
> >>
> >> I wonder if of_find_node_by_path("/") is somewhat overkill here. Perhaps
> >> simply of_node_get(of_allnodes) would be more appropriate here since the
> >> function is implemented in the core?
> >
> > of_machine_is_compatible() uses of_find_node_by_path("/") as well, 
> > of_allnodes
> > seems to be only used when during iterating. So I'd prefer to have them
> > consistent.
> 
> Agreed.

Disagreed. of_machine_is_compatible should be simplified.

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

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

[Nicolas Pitre]

On Sun, 17 Aug 2014, Jason Cooper wrote:

> On Sun, Aug 17, 2014 at 09:35:11PM -0400, Nicolas Pitre wrote:
> > On Sun, 17 Aug 2014, Jason Cooper wrote:
> > 
> > > On Sun, Aug 17, 2014 at 08:04:45PM -0400, Nicolas Pitre wrote:
> > > > On Sun, 17 Aug 2014, Jason Cooper wrote:
> > > > > On Sun, Aug 17, 2014 at 07:55:23PM +0100, Russell King - ARM Linux 
> > > > > wrote:
> > > > > > On Sun, Aug 17, 2014 at 01:32:36PM -0400, Jason Cooper wrote:
> > > > > > > Applied to irqchip/urgent with Nico's Ack.
> > > > > > 
> > > > > > Interesting, so I'm discussing this patch, and it gets applied 
> > > > > > anyway...
> > > > > > yes, that's great.
> > > > > 
> > > > > Quoting Nico:
> > > > > 
> > > > > "Of course it would be good to clarify things wrt Russell's remark
> > > > > independently from this patch."
> > > > > 
> > > > > I took 'independently' to mean "This patch is ok, *and* we need to
> > > > > address Russell's concerns in a follow-up patch."
> > > > > 
> > > > > Nico's Reviewed-by with that comment was sent August 13th.  The most
> > > > > recent activity on this thread was also August 13th.  After four 
> > > > > days, I
> > > > > reasoned there were no objections to his comment.
> > > > 
> > > > Well... I mentioned this patch is a nice cleanup independently of the 
> > > > reason why it was created in the first place.
> > > 
> > > Ah, fair enough.
> > > 
> > > > Maybe that shouldn't be sorted as "urgent" in that case, especially
> > > > when the code having problem with the current state of things is
> > > > living out of mainline.
> > > 
> > > hmmm, yes.  I've been grappling with the semantics of '/urgent' vice
> > > '/fixes'.  With mvebu, /fixes is the branch for all changes needing to go
> > > into the current -rcX cycle.  For irqchip, Thomas suggested /urgent for
> > > the equivalent branch.  To me, they serve the same purpose.
> > > Unfortunately, I occasionally hear "Well, it's not _urgent_ ...".  I
> > > suppose I'll put up with it for one more cycle and then change it to
> > > /fixes. :)
> > > 
> > > wrt this patch, I need to drop it anyway.  I was a bit rusty (it's been
> > > a few weeks) and forgot to add the Cc -stable and Fixes: tags.  I do
> > > agree, though, it's certainly not urgent.
> > 
> > Given the raised issue has to do with out-of-tree code, there is no need 
> > to CC stable in that case anyway.
> 
> I could go either way here.  On the one hand, a fix is a fix is a fix.
> On the other, if it can't be triggered in mainline, we shouldn't accept
> it at all.

For mainline, it should be accepted as a cleanup and minor optimization 
since no mainline code is currently affected by the absence of this 
patch.

If there is a real bug being fixed by this patch, and whether the best 
way to fix it is by relying on this patch, is still up for debate.

> Stephen, is the out of tree code that triggered this bound for mainline?

Maybe "mainline", but certainly not "stable".


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

Re: [PATCH] KVM: x86: Increase the number of fixed MTRR regs to 10

[Wanpeng Li]

Hi Nadav,
On Wed, Jun 18, 2014 at 05:21:19PM +0300, Nadav Amit wrote:
>Recent Intel CPUs have 10 variable range MTRRs. Since operating systems
>sometime make assumptions on CPUs while they ignore capability MSRs, it is
>better for KVM to be consistent with recent CPUs. Reporting more MTRRs than
>actually supported has no functional implications.
>
>Signed-off-by: Nadav Amit 
>---
> arch/x86/include/asm/kvm_host.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>index 4931415..0bab29d 100644
>--- a/arch/x86/include/asm/kvm_host.h
>+++ b/arch/x86/include/asm/kvm_host.h
>@@ -95,7 +95,7 @@ static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t base_gfn, 
>int level)
> #define KVM_REFILL_PAGES 25
> #define KVM_MAX_CPUID_ENTRIES 80
> #define KVM_NR_FIXED_MTRR_REGION 88
>-#define KVM_NR_VAR_MTRR 8
>+#define KVM_NR_VAR_MTRR 10
> 

We observed that there is obvious regression caused by this commit, 32bit 
win7 guest show blue screen during boot.

Regards,
Wanpeng Li 

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

[PATCH V2] mem-hotplug: let memblock skip the hotpluggable memory regions in __next_mem_range()

[Xishi Qiu]

Let memblock skip the hotpluggable memory regions in __next_mem_range(),
it is used to to prevent memblock from allocating hotpluggable memory 
for the kernel at early time. The code is the same as __next_mem_range_rev().

Clear hotpluggable flag before releasing free pages to the buddy allocator.
If we don't clear hotpluggable flag in free_low_memory_core_early(), the 
memory which marked hotpluggable flag will not free to buddy allocator.
Because __next_mem_range() will skip them.

free_low_memory_core_early
for_each_free_mem_range
for_each_mem_range
__next_mem_range

Signed-off-by: Xishi Qiu 
---
 mm/memblock.c  |4 
 mm/nobootmem.c |2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 6d2f219..5090050 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -817,6 +817,10 @@ void __init_memblock __next_mem_range(u64 *idx, int nid,
if (nid != NUMA_NO_NODE && nid != m_nid)
continue;
 
+   /* skip hotpluggable memory regions if needed */
+   if (movable_node_is_enabled() && memblock_is_hotpluggable(m))
+   continue;
+
if (!type_b) {
if (out_start)
*out_start = m_start;
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index 7ed5860..03de286 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -119,6 +119,8 @@ static unsigned long __init free_low_memory_core_early(void)
phys_addr_t start, end;
u64 i;
 
+   memblock_clear_hotplug(0, ULLONG_MAX);
+
for_each_free_mem_range(i, NUMA_NO_NODE, , , NULL)
count += __free_memory_core(start, end);
 
-- 1.7.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] mem-hotplug: let memblock skip the hotpluggable memory regions in __next_mem_range()

[Xishi Qiu]

On 2014/8/17 19:08, Tejun Heo wrote:

> Hello,
> 
> On Sat, Aug 16, 2014 at 10:36:41PM +0800, Xishi Qiu wrote:
>> numa_clear_node_hotplug()? There is only numa_clear_kernel_node_hotplug().
> 
> Yeah, that one.
> 
>> If we don't clear hotpluggable flag in free_low_memory_core_early(), the 
>> memory which marked hotpluggable flag will not free to buddy allocator.
>> Because __next_mem_range() will skip them.
>>
>> free_low_memory_core_early
>>  for_each_free_mem_range
>>  for_each_mem_range
>>  __next_mem_range
> 
> Ah, okay, so the patch fixes __next_mem_range() and thus makes
> free_low_memory_core_early() to skip hotpluggable regions unlike
> before.  Please explain things like that in the changelog.  Also,

OK, I will send V2.

Thanks,
Xishi Qiu

> what's its relationship with numa_clear_kernel_node_hotplug()?  Do we
> still need them?  If so, what are the different roles that these two
> separate places serve?
> 
> 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 V2] I2C: Rework kernel config I2C_ACPI

[Lan Tianyu]

On 2014年08月15日 19:03, Wolfram Sang wrote:
> On Fri, Aug 15, 2014 at 01:38:59PM +0800, Lan Tianyu wrote:
>> Commit da3c6647(I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI
>> config) adds a new kernel config I2C_ACPI and make I2C core built in
>> when the config is selected. This is wrong because distributions
>> etc generally compile I2C as a module and the commit broken that.
>> This patch is to rename I2C_ACPI to ACPI_I2C_OPREGION. New config
>> only controls ACPI I2C operation region code and depends on I2C=y.
>>
>> Signed-off-by: Lan Tianyu 
> 
> It looks good. What tests did you perform?
> 
> Thanks,
> 
>Wolfram
> 

Hi Wolfram:
The patch passed through Fengguang's 0-day autobuild test.

Following are config files tested.

configs tested: 122

pariscc3000_defconfig
parisc b180_defconfig
parisc  defconfig
alpha   defconfig
pariscallnoconfig
mips allmodconfig
mips   jz4740
mips  allnoconfig
mips  fuloong2e_defconfig
mips txx9
x86_64allnoconfig
x86_64lkp
x86_64   rhel
shtitan_defconfig
sh  rsk7269_defconfig
sh  sh7785lcr_32bit_defconfig
shallnoconfig
x86_64 randconfig-c3-0815
x86_64 randconfig-c1-0815
x86_64 randconfig-c0-0815
x86_64 randconfig-c2-0815
x86_64   allmodconfig
i386   randconfig-jx5
i386   randconfig-jx4
i386   randconfig-jx7
i386   randconfig-jx6
i386   randconfig-jx1
i386   randconfig-jx0
i386   randconfig-jx3
i386   randconfig-jx2
i386   randconfig-jx9
i386   randconfig-jx8
x86_64 randconfig-jx8
x86_64 randconfig-jx9
x86_64 randconfig-jx2
x86_64 randconfig-jx3
x86_64 randconfig-jx0
x86_64 randconfig-jx1
x86_64 randconfig-jx6
x86_64 randconfig-jx7
x86_64 randconfig-jx4
x86_64 randconfig-jx5
powerpc  chroma_defconfig
powerpc linkstation_defconfig
powerpc   powerpc
powerpc wii_defconfig
powerpcgamecube_defconfig
powerpc   corenet64_smp_defconfig
powerpc   mpc512x
powerpcppc44x
x86_64 randconfig-j0-0815
x86_64 randconfig-j1-0815
i386  randconfig-ha2-0815
i386  randconfig-ha5-0815
i386  randconfig-ha1-0815
i386  randconfig-ha0-0815
i386  randconfig-ha3-0815
i386  randconfig-ha4-0815
ia64 allmodconfig
ia64  allnoconfig
ia64defconfig
ia64 alldefconfig
sparc   defconfig
sparc64   allnoconfig
sparc64 defconfig
xtensa   common_defconfig
m32r   m32104ut_defconfig
xtensa  iss_defconfig
m32r opsput_defconfig
m32r   usrv_defconfig
m32r mappi3.smp_defconfig
microblaze  mmu_defconfig
microblazenommu_defconfig
microblaze   allyesconfig
i386 allyesconfig
cris etrax-100lx_v2_defconfig
blackfin  TCM-BF537_defconfig
blackfinBF561-EZKIT-SMP_defconfig
blackfinBF533-EZKIT_defconfig
blackfinBF526-EZBRD_defconfig
i386   randconfig-r1-0815
i386   randconfig-r2-0815
i386   randconfig-r3-0815
i386   randconfig-r0-0815
s390 allmodconfig
s390  allnoconfig
s390defconfig
mn10300 asb2364_defconfig
openriscor1ksim_defconfig
um   x86_64_defconfig
um i386_defconfig
avr32  

Re: [PATCH] usb: phy: return -ENODEV on failure of try_module_get

[Greg KH]

On Mon, Aug 18, 2014 at 12:04:42AM +0530, Arjun Sreedharan wrote:
> When __usb_find_phy_dev() does not return error and
> try_module_get() fails, return -ENODEV
> 
> Signed-off-by: Arjun Sreedharan 
> ---
>  drivers/usb/phy/phy.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
> index 36b6bce..8ad3638 100644
> --- a/drivers/usb/phy/phy.c
> +++ b/drivers/usb/phy/phy.c
> @@ -232,6 +232,7 @@ struct usb_phy *usb_get_phy_dev(struct device *dev, u8 
> index)
>   phy = __usb_find_phy_dev(dev, _bind_list, index);
>   if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
>   dev_dbg(dev, "unable to find transceiver\n");
> + phy = IS_ERR(phy) ? phy : ERR_PTR(-ENODEV);

Please just spell out the if () statement, don't use ? : unless
necessary.

thanks,

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

Re: [PATCH] usb: gadget: remove $(PWD) in ccflags-y

[Greg KH]

On Mon, Aug 18, 2014 at 12:08:07AM +0200, Philippe Reynes wrote:
> The variable $(PWD) is useless, and it may break the compilation.
> For example, it breaks the kernel compilation when it's done with
> buildroot :
> 
>   /home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/bin/ccache
> /home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
> -Wp,-MD,drivers/usb/gadget/legacy/.hid.o.d  -nostdinc -isystem
> /home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/include
> -I./arch/arm/include -Iarch/arm/include/generated  -Iinclude
> -I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi
> -I./include/uapi -Iinclude/generated/uapi -include
> ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef
> -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
> -Werror-implicit-function-declaration -Wno-format-security
> -fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp
> -funwind-tables -marm -D__LINUX_ARM_ARCH__=5 -march=armv5te
> -mtune=arm9tdmi -msoft-float -Uarm -fno-delete-null-pointer-checks -O2
> --param=allow-store-data-races=0 -Wframe-larger-than=1024
> -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer
> -fno-var-tracking-assignments -g -Wdeclaration-after-statement
> -Wno-pointer-sign -fno-strict-overflow -fconserve-stack
> -Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO
> -I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/
> -I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/udc/
> -I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/function/
> -DMODULE  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hid)"
> -D"KBUILD_MODNAME=KBUILD_STR(g_hid)" -c -o
> drivers/usb/gadget/legacy/hid.o drivers/usb/gadget/legacy/hid.c
> drivers/usb/gadget/epautoconf.c:23:26: erreur fatale: gadget_chips.h :
> Aucun fichier ou dossier de ce type
> 
> This compilation line include :
> /buildroot/driver/usb/gadget
> but the real path is :
> /buildroot/output/build/linux-3.17-rc1/driver/usb/gadget
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/usb/gadget/Makefile  |2 +-
>  drivers/usb/gadget/function/Makefile |4 ++--
>  drivers/usb/gadget/legacy/Makefile   |6 +++---
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
> index a186afe..9add915 100644
> --- a/drivers/usb/gadget/Makefile
> +++ b/drivers/usb/gadget/Makefile
> @@ -3,7 +3,7 @@
>  #
>  subdir-ccflags-$(CONFIG_USB_GADGET_DEBUG):= -DDEBUG
>  subdir-ccflags-$(CONFIG_USB_GADGET_VERBOSE)  += -DVERBOSE_DEBUG
> -ccflags-y+= -I$(PWD)/drivers/usb/gadget/udc
> +ccflags-y+= -Idrivers/usb/gadget/udc

Ick, why are these here at all, shouldn't you just use the proper
relative paths in the .c files for the include files?  That way just
building a .o file individually will work properly, otherwise, it will
not.

And getting rid of those other ccflags would be good to do as well, no
need for them to be in a Makefile.

thanks,

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

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

[Jason Cooper]

On Sun, Aug 17, 2014 at 09:35:11PM -0400, Nicolas Pitre wrote:
> On Sun, 17 Aug 2014, Jason Cooper wrote:
> 
> > On Sun, Aug 17, 2014 at 08:04:45PM -0400, Nicolas Pitre wrote:
> > > On Sun, 17 Aug 2014, Jason Cooper wrote:
> > > > On Sun, Aug 17, 2014 at 07:55:23PM +0100, Russell King - ARM Linux 
> > > > wrote:
> > > > > On Sun, Aug 17, 2014 at 01:32:36PM -0400, Jason Cooper wrote:
> > > > > > Applied to irqchip/urgent with Nico's Ack.
> > > > > 
> > > > > Interesting, so I'm discussing this patch, and it gets applied 
> > > > > anyway...
> > > > > yes, that's great.
> > > > 
> > > > Quoting Nico:
> > > > 
> > > > "Of course it would be good to clarify things wrt Russell's remark
> > > > independently from this patch."
> > > > 
> > > > I took 'independently' to mean "This patch is ok, *and* we need to
> > > > address Russell's concerns in a follow-up patch."
> > > > 
> > > > Nico's Reviewed-by with that comment was sent August 13th.  The most
> > > > recent activity on this thread was also August 13th.  After four days, I
> > > > reasoned there were no objections to his comment.
> > > 
> > > Well... I mentioned this patch is a nice cleanup independently of the 
> > > reason why it was created in the first place.
> > 
> > Ah, fair enough.
> > 
> > > Maybe that shouldn't be sorted as "urgent" in that case, especially
> > > when the code having problem with the current state of things is
> > > living out of mainline.
> > 
> > hmmm, yes.  I've been grappling with the semantics of '/urgent' vice
> > '/fixes'.  With mvebu, /fixes is the branch for all changes needing to go
> > into the current -rcX cycle.  For irqchip, Thomas suggested /urgent for
> > the equivalent branch.  To me, they serve the same purpose.
> > Unfortunately, I occasionally hear "Well, it's not _urgent_ ...".  I
> > suppose I'll put up with it for one more cycle and then change it to
> > /fixes. :)
> > 
> > wrt this patch, I need to drop it anyway.  I was a bit rusty (it's been
> > a few weeks) and forgot to add the Cc -stable and Fixes: tags.  I do
> > agree, though, it's certainly not urgent.
> 
> Given the raised issue has to do with out-of-tree code, there is no need 
> to CC stable in that case anyway.

I could go either way here.  On the one hand, a fix is a fix is a fix.
On the other, if it can't be triggered in mainline, we shouldn't accept
it at all.

Stephen, is the out of tree code that triggered this bound for mainline?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
>On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
>> On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
>> >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
>> >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
>> >> >Enhance the default implementation of pcibios_add_device() to
>> >> >parse and map the IRQ of the device if a DT binding is available.
>> >> >
>> >> >Cc: Bjorn Helgaas 
>> >> >Cc: Grant Likely 
>> >> >Cc: Rob Herring 
>> >> >Signed-off-by: Liviu Dudau 
>> >> >---
>> >> > drivers/pci/pci.c | 3 +++
>> >> > 1 file changed, 3 insertions(+)
>> >> >
>> >> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> >> >index 1c8592b..29d1775 100644
>> >> >--- a/drivers/pci/pci.c
>> >> >+++ b/drivers/pci/pci.c
>> >> >@@ -17,6 +17,7 @@
>> >> > #include 
>> >> > #include 
>> >> > #include 
>> >> >+#include 
>> >> > #include 
>> >> > #include 
>> >> > #include 
>> >> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
>> >> >  */
>> >> > int __weak pcibios_add_device(struct pci_dev *dev)
>> >> > {
>> >> >+dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>> >> >+
>> >> > return 0;
>> >> > }
>> >> 
>> >> Liviu,
>> >> 
>> >> For this, my suggestion is to add arch dependent function to setup the irq
>> >> line for pci devices. I can't find an obvious reason this won't work on 
>> >> other
>> >> archs, but maybe this will hurt some of them?
>> >
>> >Hi Wei,
>> >
>> >I'm not sure I understand your point. Architectures that support OF will 
>> >obviously
>> >benefit from this common approach, and for the other ones the function is 
>> >empty
>> >so it will not change existing behaviour. If you are suggesting that I 
>> >should
>> >create a new API that each architecture could go and implement for setting 
>> >up the
>> >IRQ line then I would agree that it would be nice to have that, but the 
>> >question
>> >is how many architectures are outside OF that need this?
>> 
>> My suggestion is to define the pcibios_add_device() for arm arch, like the 
>> one
>> in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
>> patch set address the pci bus setup mostly on arm arch.
>
>And also arm64 at the least.
>
>> 
>> For those archs not support OF, this function is empty and has no effect. I
>> agree on this one.
>> 
>> For those archs rely on OF, we still have two cases:
>> 1. they would have implement this function like powerpc
>
>Actually, powerpc seems to be the only OF platform reimplementing this 
>function.
>s390 and x86 are not OF platforms.
>
>> 2. have other way to fix it up,  otherwise how it works now?
>
>Don't forget that my patchset aims to replace existing house-made code with a 
>more
>generic version. When architectures and platforms switch to my code they will 
>have
>to add this back in their code if it's needed.
>
>> If my assumption is correct, this change will either have no effect, or fix 
>> up
>> the irq line the second time. Not harmful, but not necessary.
>
>Well, it will become necessary as old code gets dismantled and converted 
>towards
>this patchset. To give you an example that I'm familiar with, for arch/arm the
>host bridge drivers have moved into drivers/pci/host, but they still depend/use
>the bios32 infrastructure that takes care of setting up the irq. When they 
>switch
>to my version they would have to go and debug the "irq not being assigned" 
>issue
>and it is quite likely that some of the people doing the conversion will 
>complain
>about my code rather than understanding the issue. What I'm trying to do is to
>make switching to my patchset as painless as possible, with a cleanup to remove
>redundant operations coming after the switchover.
>

This means this is a temporary version for the switchover period and will be
reverted after switchover?

>Does that sound like a reasonable plan?
>
>Best regards,
>Liviu
>
>> 
>> I am not familiar with other arch, so the second case is my deduction. If 
>> this
>> is not correct, please let me know.
>> 
>> >
>> >If I understood you correctly, it is a nice idea but slightly outside the 
>> >scope
>> >of my current patchset.
>> >
>> >Best regards,
>> >Liviu
>> >
>> >> 
>> >> >
>> >> >-- 
>> >> >2.0.4
>> >> >
>> >> >--
>> >> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> >> >the body of a message to majord...@vger.kernel.org
>> >> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >> 
>> >> -- 
>> >> Richard Yang
>> >> Help you, Help me
>> >> 
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> >> the body of a message to majord...@vger.kernel.org
>> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >> 
>> >
>> 
>> -- 
>> Richard Yang
>> Help you, Help me
>> 
>> 
>
>-- 
>
>| I would like to |
>| fix the world,  |
>| but they're not |
>| giving me the   |
> \ source code!  /
> 

Re: [PATCH RFC 6/7] usb: host: ehci-exynos: Remove unnecessary usb-phy support

[Jingoo Han]

On Thursday, August 14, 2014 11:24 PM, Vivek Gautam wrote:
> 
> Now that we have completely moved from older USB-PHY drivers
> to newer GENERIC-PHY drivers for PHYs available with USB controllers
> on Exynos series of SoCs, we can remove the support for the same
> in our host drivers too.
> This should fix the issue on ehci-exynos, wherein in the absence of
> SAMSUNG_USB2PHY config symbol, we ended up getting the NOP_USB_XCEIV phy
> when the same is enabled. And thus the PHYs are not configured properly.
> 
> Reported-by: Sachin Kamat 
> Signed-off-by: Vivek Gautam 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/usb/host/ehci-exynos.c |   53 
> ++--
>  1 file changed, 8 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index cda0a2f..54944cc 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -21,11 +21,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
> -#include 
> 
>  #include "ehci.h"
> 
> @@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
> 
>  struct exynos_ehci_hcd {
>   struct clk *clk;
> - struct usb_phy *phy;
> - struct usb_otg *otg;
> - struct phy *phy_g[PHY_NUMBER];
> + struct phy *phy[PHY_NUMBER];
>  };
> 
>  #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd 
> *)(hcd_to_ehci(hcd)->priv)
> @@ -62,18 +57,6 @@ static int exynos_ehci_get_phy(struct device *dev,
>   int phy_number;
>   int ret = 0;
> 
> - exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> - if (IS_ERR(exynos_ehci->phy)) {
> - ret = PTR_ERR(exynos_ehci->phy);
> - if (ret != -ENXIO && ret != -ENODEV) {
> - dev_err(dev, "no usb2 phy configured\n");
> - return ret;
> - }
> - dev_dbg(dev, "Failed to get usb2 phy\n");
> - } else {
> - exynos_ehci->otg = exynos_ehci->phy->otg;
> - }
> -
>   for_each_available_child_of_node(dev->of_node, child) {
>   ret = of_property_read_u32(child, "reg", _number);
>   if (ret) {
> @@ -98,7 +81,7 @@ static int exynos_ehci_get_phy(struct device *dev,
>   }
>   dev_dbg(dev, "Failed to get usb2 phy\n");
>   }
> - exynos_ehci->phy_g[phy_number] = phy;
> + exynos_ehci->phy[phy_number] = phy;
>   }
> 
>   return ret;
> @@ -111,16 +94,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
>   int i;
>   int ret = 0;
> 
> - if (!IS_ERR(exynos_ehci->phy))
> - return usb_phy_init(exynos_ehci->phy);
> -
>   for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> - if (!IS_ERR(exynos_ehci->phy_g[i]))
> - ret = phy_power_on(exynos_ehci->phy_g[i]);
> + if (!IS_ERR(exynos_ehci->phy[i]))
> + ret = phy_power_on(exynos_ehci->phy[i]);
>   if (ret)
>   for (i--; i >= 0; i--)
> - if (!IS_ERR(exynos_ehci->phy_g[i]))
> - phy_power_off(exynos_ehci->phy_g[i]);
> + if (!IS_ERR(exynos_ehci->phy[i]))
> + phy_power_off(exynos_ehci->phy[i]);
> 
>   return ret;
>  }
> @@ -131,14 +111,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
>   struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
>   int i;
> 
> - if (!IS_ERR(exynos_ehci->phy)) {
> - usb_phy_shutdown(exynos_ehci->phy);
> - return;
> - }
> -
>   for (i = 0; i < PHY_NUMBER; i++)
> - if (!IS_ERR(exynos_ehci->phy_g[i]))
> - phy_power_off(exynos_ehci->phy_g[i]);
> + if (!IS_ERR(exynos_ehci->phy[i]))
> + phy_power_off(exynos_ehci->phy[i]);
>  }
> 
>  static void exynos_setup_vbus_gpio(struct device *dev)
> @@ -231,9 +206,6 @@ skip_phy:
>   goto fail_io;
>   }
> 
> - if (exynos_ehci->otg)
> - exynos_ehci->otg->set_host(exynos_ehci->otg, >self);
> -
>   err = exynos_ehci_phy_enable(>dev);
>   if (err) {
>   dev_err(>dev, "Failed to enable USB phy\n");
> @@ -273,9 +245,6 @@ static int exynos_ehci_remove(struct platform_device 
> *pdev)
> 
>   usb_remove_hcd(hcd);
> 
> - if (exynos_ehci->otg)
> - exynos_ehci->otg->set_host(exynos_ehci->otg, >self);
> -
>   exynos_ehci_phy_disable(>dev);
> 
>   clk_disable_unprepare(exynos_ehci->clk);
> @@ -298,9 +267,6 @@ static int exynos_ehci_suspend(struct device *dev)
>   if (rc)
>   return rc;
> 
> - if (exynos_ehci->otg)
> - exynos_ehci->otg->set_host(exynos_ehci->otg, >self);
> -
>   exynos_ehci_phy_disable(dev);
> 
>   clk_disable_unprepare(exynos_ehci->clk);
> @@ -316,9 +282,6 @@ static int 

Re: [PATCH RFC 7/7] usb: host: ohci-exynos: Remove unnecessary usb-phy support

[Jingoo Han]

On Thursday, August 14, 2014 11:24 PM, Vivek Gautam wrote:
> 
> Now that we have completely moved from older USB-PHY drivers
> to newer GENERIC-PHY drivers for PHYs available with USB controllers
> on Exynos series of SoCs, we can remove the support for the same
> in our host drivers too.
> This should fix the issue on ohci-exynos, wherein in the absence of
> SAMSUNG_USB2PHY config symbol, we ended up getting the NOP_USB_XCEIV phy
> when the same is enabled. And thus the PHYs are not configured properly.
> 
> Reported-by: Sachin Kamat 
> Signed-off-by: Vivek Gautam 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/usb/host/ohci-exynos.c |   64 
> ++--
>  1 file changed, 9 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index a72ab8f..0199a8b 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -19,11 +19,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
> -#include 
> 
>  #include "ohci.h"
> 
> @@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
> 
>  struct exynos_ohci_hcd {
>   struct clk *clk;
> - struct usb_phy *phy;
> - struct usb_otg *otg;
> - struct phy *phy_g[PHY_NUMBER];
> + struct phy *phy[PHY_NUMBER];
>  };
> 
>  static int exynos_ohci_get_phy(struct device *dev,
> @@ -51,28 +46,7 @@ static int exynos_ohci_get_phy(struct device *dev,
>   int phy_number;
>   int ret = 0;
> 
> - exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> - if (IS_ERR(exynos_ohci->phy)) {
> - ret = PTR_ERR(exynos_ohci->phy);
> - if (ret != -ENXIO && ret != -ENODEV) {
> - dev_err(dev, "no usb2 phy configured\n");
> - return ret;
> - }
> - dev_dbg(dev, "Failed to get usb2 phy\n");
> - } else {
> - exynos_ohci->otg = exynos_ohci->phy->otg;
> - }
> -
> - /*
> -  * Getting generic phy:
> -  * We are keeping both types of phys as a part of transiting OHCI
> -  * to generic phy framework, so as to maintain backward compatibilty
> -  * with old DTB.
> -  * If there are existing devices using DTB files built from them,
> -  * to remove the support for old bindings in this driver,
> -  * we need to make sure that such devices have their DTBs
> -  * updated to ones built from new DTS.
> -  */
> + /* Get the generic phys */
>   for_each_available_child_of_node(dev->of_node, child) {
>   ret = of_property_read_u32(child, "reg", _number);
>   if (ret) {
> @@ -97,7 +71,7 @@ static int exynos_ohci_get_phy(struct device *dev,
>   }
>   dev_dbg(dev, "Failed to get usb2 phy\n");
>   }
> - exynos_ohci->phy_g[phy_number] = phy;
> + exynos_ohci->phy[phy_number] = phy;
>   }
> 
>   return ret;
> @@ -110,16 +84,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
>   int i;
>   int ret = 0;
> 
> - if (!IS_ERR(exynos_ohci->phy))
> - return usb_phy_init(exynos_ohci->phy);
> -
>   for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> - if (!IS_ERR(exynos_ohci->phy_g[i]))
> - ret = phy_power_on(exynos_ohci->phy_g[i]);
> + if (!IS_ERR(exynos_ohci->phy[i]))
> + ret = phy_power_on(exynos_ohci->phy[i]);
>   if (ret)
>   for (i--; i >= 0; i--)
> - if (!IS_ERR(exynos_ohci->phy_g[i]))
> - phy_power_off(exynos_ohci->phy_g[i]);
> + if (!IS_ERR(exynos_ohci->phy[i]))
> + phy_power_off(exynos_ohci->phy[i]);
> 
>   return ret;
>  }
> @@ -130,14 +101,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
>   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
>   int i;
> 
> - if (!IS_ERR(exynos_ohci->phy)) {
> - usb_phy_shutdown(exynos_ohci->phy);
> - return;
> - }
> -
>   for (i = 0; i < PHY_NUMBER; i++)
> - if (!IS_ERR(exynos_ohci->phy_g[i]))
> - phy_power_off(exynos_ohci->phy_g[i]);
> + if (!IS_ERR(exynos_ohci->phy[i]))
> + phy_power_off(exynos_ohci->phy[i]);
>  }
> 
>  static int exynos_ohci_probe(struct platform_device *pdev)
> @@ -209,9 +175,6 @@ skip_phy:
>   goto fail_io;
>   }
> 
> - if (exynos_ohci->otg)
> - exynos_ohci->otg->set_host(exynos_ohci->otg, >self);
> -
>   platform_set_drvdata(pdev, hcd);
> 
>   err = exynos_ohci_phy_enable(>dev);
> @@ -244,9 +207,6 @@ static int exynos_ohci_remove(struct platform_device 
> *pdev)
> 
>   usb_remove_hcd(hcd);
> 
> - if (exynos_ohci->otg)
> - exynos_ohci->otg->set_host(exynos_ohci->otg, 

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

[Nicolas Pitre]

On Sun, 17 Aug 2014, Jason Cooper wrote:

> On Sun, Aug 17, 2014 at 08:04:45PM -0400, Nicolas Pitre wrote:
> > On Sun, 17 Aug 2014, Jason Cooper wrote:
> > > On Sun, Aug 17, 2014 at 07:55:23PM +0100, Russell King - ARM Linux wrote:
> > > > On Sun, Aug 17, 2014 at 01:32:36PM -0400, Jason Cooper wrote:
> > > > > Applied to irqchip/urgent with Nico's Ack.
> > > > 
> > > > Interesting, so I'm discussing this patch, and it gets applied anyway...
> > > > yes, that's great.
> > > 
> > > Quoting Nico:
> > > 
> > > "Of course it would be good to clarify things wrt Russell's remark
> > > independently from this patch."
> > > 
> > > I took 'independently' to mean "This patch is ok, *and* we need to
> > > address Russell's concerns in a follow-up patch."
> > > 
> > > Nico's Reviewed-by with that comment was sent August 13th.  The most
> > > recent activity on this thread was also August 13th.  After four days, I
> > > reasoned there were no objections to his comment.
> > 
> > Well... I mentioned this patch is a nice cleanup independently of the 
> > reason why it was created in the first place.
> 
> Ah, fair enough.
> 
> > Maybe that shouldn't be sorted as "urgent" in that case, especially
> > when the code having problem with the current state of things is
> > living out of mainline.
> 
> hmmm, yes.  I've been grappling with the semantics of '/urgent' vice
> '/fixes'.  With mvebu, /fixes is the branch for all changes needing to go
> into the current -rcX cycle.  For irqchip, Thomas suggested /urgent for
> the equivalent branch.  To me, they serve the same purpose.
> Unfortunately, I occasionally hear "Well, it's not _urgent_ ...".  I
> suppose I'll put up with it for one more cycle and then change it to
> /fixes. :)
> 
> wrt this patch, I need to drop it anyway.  I was a bit rusty (it's been
> a few weeks) and forgot to add the Cc -stable and Fixes: tags.  I do
> agree, though, it's certainly not urgent.

Given the raised issue has to do with out-of-tree code, there is no need 
to CC stable in that case anyway.


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

Re: [PATCH 1/7] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver

[Jingoo Han]

On Thursday, August 14, 2014 11:24 PM, Vivek Gautam wrote:
> 
> Removing this older USB 3.0 DRD controller PHY driver, since
> a new driver based on generic phy framework is now available.
> 
> Signed-off-by: Vivek Gautam 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/usb/phy/Kconfig|8 -
>  drivers/usb/phy/Makefile   |1 -
>  drivers/usb/phy/phy-samsung-usb.h  |   80 -
>  drivers/usb/phy/phy-samsung-usb3.c |  350 
> 
>  4 files changed, 439 deletions(-)
>  delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c

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

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

[Jason Cooper]

On Sun, Aug 17, 2014 at 10:41:23PM +0100, Russell King - ARM Linux wrote:
> On Sun, Aug 17, 2014 at 03:04:34PM -0400, Jason Cooper wrote:
> > Quoting Nico:
> > 
> > "Of course it would be good to clarify things wrt Russell's remark
> > independently from this patch."
> > 
> > I took 'independently' to mean "This patch is ok, *and* we need to
> > address Russell's concerns in a follow-up patch."
> > 
> > Nico's Reviewed-by with that comment was sent August 13th.  The most
> > recent activity on this thread was also August 13th.  After four days, I
> > reasoned there were no objections to his comment.
> 
> Right, during the merge window, and during merge windows, I tend to
> ignore almost all email now because people don't stop developing, and
> they don't take any notice where the mainline cycle is.  In fact, I go
> off and do non-kernel work during a merge window and only briefly scan
> for bug fixes.

Ok, now dropped.

thx,

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

[PATCH 5/7 update] arm64/efi: do not enter virtual mode in case booting with efi=noruntime or noefi

[Dave Young]

In case efi runtime disabled via noefi kernel cmdline arm64_enter_virtual_mode
should error out.

At the same time move early_memunmap(memmap.map, mapsize) to the beginning of
the function or it will leak early mem.

Signed-off-by: Dave Young 
---
 arch/arm64/kernel/efi.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 6ed0362..8f5db4a 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -392,11 +392,16 @@ static int __init arm64_enter_virtual_mode(void)
return -1;
}
 
-   pr_info("Remapping and enabling EFI services.\n");
-
-   /* replace early memmap mapping with permanent mapping */
mapsize = memmap.map_end - memmap.map;
early_memunmap(memmap.map, mapsize);
+
+   if (efi_runtime_disabled()) {
+   pr_info("EFI runtime services will be disabled.\n");
+   return -1;
+   }
+
+   pr_info("Remapping and enabling EFI services.\n");
+   /* replace early memmap mapping with permanent mapping */
memmap.map = (__force void *)ioremap_cache((phys_addr_t)memmap.phys_map,
   mapsize);
memmap.map_end = memmap.map + mapsize;
-- 
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 5/7] arm64/efi: do not enter virtual mode in case booting with efi=noruntime or noefi

[Dave Young]

On 08/15/14 at 04:09pm, Will Deacon wrote:
> On Thu, Aug 14, 2014 at 10:15:30AM +0100, Dave Young wrote:
> > In case efi runtime disabled via noefi kernel cmdline 
> > arm64_enter_virtual_mode
> > should error out.
> > 
> > At the same time move early_memunmap(memmap.map, mapsize) to the beginning 
> > of
> > the function or it will leak early mem.
> > 
> > Signed-off-by: Dave Young 
> > ---
> >  arch/arm64/kernel/efi.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> > index 6ed0362..309fab1 100644
> > --- a/arch/arm64/kernel/efi.c
> > +++ b/arch/arm64/kernel/efi.c
> > @@ -392,11 +392,16 @@ static int __init arm64_enter_virtual_mode(void)
> > return -1;
> > }
> >  
> > +   mapsize = memmap.map_end - memmap.map;
> > +   if (efi_runtime_disabled()) {
> > +   early_memunmap(memmap.map, mapsize);
> 
> Should this early_memunmap really be conditional? With this change, we no
> longer unmap it before setting up the permanent mapping below.

Ooops, I tested the right version but sent a wrong version for this arm64 patch.

Thanks for catch.

> 
> Will
> 
> > +   pr_info("EFI runtime services will be disabled.\n");
> > +   return -1;
> > +   }
> > +
> > pr_info("Remapping and enabling EFI services.\n");
> >  
> > /* replace early memmap mapping with permanent mapping */
> > -   mapsize = memmap.map_end - memmap.map;
> > -   early_memunmap(memmap.map, mapsize);
> > memmap.map = (__force void *)ioremap_cache((phys_addr_t)memmap.phys_map,
> >mapsize);
> > memmap.map_end = memmap.map + mapsize;
> > -- 
> > 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 v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

[Jason Cooper]

On Sun, Aug 17, 2014 at 08:04:45PM -0400, Nicolas Pitre wrote:
> On Sun, 17 Aug 2014, Jason Cooper wrote:
> > On Sun, Aug 17, 2014 at 07:55:23PM +0100, Russell King - ARM Linux wrote:
> > > On Sun, Aug 17, 2014 at 01:32:36PM -0400, Jason Cooper wrote:
> > > > Applied to irqchip/urgent with Nico's Ack.
> > > 
> > > Interesting, so I'm discussing this patch, and it gets applied anyway...
> > > yes, that's great.
> > 
> > Quoting Nico:
> > 
> > "Of course it would be good to clarify things wrt Russell's remark
> > independently from this patch."
> > 
> > I took 'independently' to mean "This patch is ok, *and* we need to
> > address Russell's concerns in a follow-up patch."
> > 
> > Nico's Reviewed-by with that comment was sent August 13th.  The most
> > recent activity on this thread was also August 13th.  After four days, I
> > reasoned there were no objections to his comment.
> 
> Well... I mentioned this patch is a nice cleanup independently of the 
> reason why it was created in the first place.

Ah, fair enough.

> Maybe that shouldn't be sorted as "urgent" in that case, especially
> when the code having problem with the current state of things is
> living out of mainline.

hmmm, yes.  I've been grappling with the semantics of '/urgent' vice
'/fixes'.  With mvebu, /fixes is the branch for all changes needing to go
into the current -rcX cycle.  For irqchip, Thomas suggested /urgent for
the equivalent branch.  To me, they serve the same purpose.
Unfortunately, I occasionally hear "Well, it's not _urgent_ ...".  I
suppose I'll put up with it for one more cycle and then change it to
/fixes. :)

wrt this patch, I need to drop it anyway.  I was a bit rusty (it's been
a few weeks) and forgot to add the Cc -stable and Fixes: tags.  I do
agree, though, it's certainly not urgent.

As Russell has raised more issues with this patch as well, I'll hold off
on re-applying until I see a new version.  Hopefully it'll meet with
everyones approval.

thx,

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

Re: [PATCH v1 5/9] block: loop: convert to blk-mq

[Ming Lei]

On Mon, Aug 18, 2014 at 1:48 AM, Jens Axboe  wrote:
> On 2014-08-16 02:06, Ming Lei wrote:
>>
>> On 8/16/14, Jens Axboe  wrote:
>>>
>>> On 08/15/2014 10:36 AM, Jens Axboe wrote:

 On 08/15/2014 10:31 AM, Christoph Hellwig wrote:
>>
>> +static void loop_queue_work(struct work_struct *work)
>
>
> Offloading work straight to a workqueue dosn't make much sense
> in the blk-mq model as we'll usually be called from one.  If you
> need to avoid the cases where we are called directly a flag for
> the blk-mq code to always schedule a workqueue sounds like a much
> better plan.


 That's a good point - would clean up this bit, and be pretty close to a
 one-liner to support in blk-mq for the drivers that always need blocking
 context.
>>>
>>>
>>> Something like this should do the trick - totally untested. But with
>>> that, loop would just need to add BLK_MQ_F_WQ_CONTEXT to it's tag set
>>> flags and it could always do the work inline from ->queue_rq().
>>
>>
>> I think it is a good idea.
>>
>> But for loop, there may be two problems:
>>
>> - default max_active for bound workqueue is 256, which means several slow
>> loop devices might slow down whole block system. With kernel AIO, it won't
>> be a big deal, but some block/fs may not support direct I/O and still
>> fallback to
>> workqueue
>>
>> - 6. Guidelines of Documentation/workqueue.txt
>> If there is dependency among multiple work items used during memory
>> reclaim, they should be queued to separate wq each with WQ_MEM_RECLAIM.
>
>
> Both are good points. But I think this mainly means that we should support
> this through a potentially per-dispatch queue workqueue, separate from
> kblockd. There's no reason blk-mq can't support this with a per-hctx
> workqueue, for drivers that need it.

Good idea, and per-device workqueue should be enough if
BLK_MQ_F_WQ_CONTEXT flag is set.

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 1/2] fs/buffer.c: allocate buffer cache from non-movable area

[Gioh Kim]

2014-08-15 오전 6:22, Andrew Morton 쓴 글:

On Thu, 14 Aug 2014 14:15:40 +0900 Gioh Kim  wrote:


A buffer cache is allocated from movable area
because it is referred for a while and released soon.
But some filesystems are taking buffer cache for a long time
and it can disturb page migration.

A new API should be introduced to allocate buffer cache from
non-movable area.


I think the API could and should be more flexible than this.

Rather than making the API be "movable or not movable", let's permit
callers to specify the gfp_t and leave it at that.  That way, if
someone later wants to allocate a buffer head with, I dunno,
__GFP_NOTRACK then they can do so.

So the word "movable" shouldn't appear in buffer.c at all, except in a
single place.


Absolutely I agree with you.
If filesystem developers agree this patch I will send 2nd patch that applies 
your ideas.

Thank you for your advices.




--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -993,7 +993,7 @@ init_page_buffers(struct page *page, struct block_device 
*bdev,
   */
  static int
  grow_dev_page(struct block_device *bdev, sector_t block,
-   pgoff_t index, int size, int sizebits)
+ pgoff_t index, int size, int sizebits, gfp_t movable_mask)


s/movable_mask/gfp/


I got it.




  {
 struct inode *inode = bdev->bd_inode;
 struct page *page;
@@ -1003,7 +1003,8 @@ grow_dev_page(struct block_device *bdev, sector_t block,
 gfp_t gfp_mask;

 gfp_mask = mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS;
-   gfp_mask |= __GFP_MOVABLE;
+   if (movable_mask & __GFP_MOVABLE)
+   gfp_mask |= __GFP_MOVABLE;


This becomes

gfp_mask |= gfp;


I got it.




 /*
  * XXX: __getblk_slow() can not really deal with failure and
  * will endlessly loop on improvised global reclaim.  Prefer
@@ -1058,7 +1059,8 @@ failed:
   * that page was dirty, the buffers are set dirty also.
   */
  static int
-grow_buffers(struct block_device *bdev, sector_t block, int size)
+grow_buffers(struct block_device *bdev, sector_t block,
+int size, gfp_t movable_mask)


gfp


  {
 pgoff_t index;
 int sizebits;
@@ -1085,11 +1087,12 @@ grow_buffers(struct block_device *bdev, sector_t block, 
int size)
 }

 /* Create a page with the proper size buffers.. */
-   return grow_dev_page(bdev, block, index, size, sizebits);
+   return grow_dev_page(bdev, block, index, size, sizebits, movable_mask);
  }

  static struct buffer_head *
-__getblk_slow(struct block_device *bdev, sector_t block, int size)
+__getblk_slow(struct block_device *bdev, sector_t block,
+ int size, gfp_t movable_mask)


gfp


  {
 /* Size must be multiple of hard sectorsize */
 if (unlikely(size & (bdev_logical_block_size(bdev)-1) ||
@@ -,7 +1114,7 @@ __getblk_slow(struct block_device *bdev, sector_t block, 
int size)
 if (bh)
 return bh;

-   ret = grow_buffers(bdev, block, size);
+   ret = grow_buffers(bdev, block, size, movable_mask);


gfp


 if (ret < 0)
 return NULL;
 if (ret == 0)
@@ -1385,11 +1388,34 @@ __getblk(struct block_device *bdev, sector_t block, 
unsigned size)

 might_sleep();
 if (bh == NULL)
-   bh = __getblk_slow(bdev, block, size);
+   bh = __getblk_slow(bdev, block, size, __GFP_MOVABLE);


Here is the place where buffer.c. mentions "movable".


I got it.




 return bh;
  }
  EXPORT_SYMBOL(__getblk);

+ /*
+ * __getblk_nonmovable will locate (and, if necessary, create) the buffer_head
+ * which corresponds to the passed block_device, block and size. The
+ * returned buffer has its reference count incremented.
+ *
+ * The page cache is allocated from non-movable area
+ * not to prevent page migration.
+ *
+ * __getblk()_nonmovable will lock up the machine
+ * if grow_dev_page's try_to_free_buffers() attempt is failing. FIXME, perhaps?
+ */
+struct buffer_head *
+__getblk_nonmovable(struct block_device *bdev, sector_t block, unsigned size)
+{
+   struct buffer_head *bh = __find_get_block(bdev, block, size);
+
+   might_sleep();
+   if (bh == NULL)
+   bh = __getblk_slow(bdev, block, size, 0);
+   return bh;
+}
+EXPORT_SYMBOL(__getblk_nonmovable);


Suggest this be called __getblk_gfp(bdev, block, size, gfp) and then
__getblk() be changed to call __getblk_gfp(..., __GFP_MOVABLE).

We could then write a __getblk_nonmovable() which calls __getblk_gfp()
(a static inlined one-line function) or we can just call
__getblk_gfp(..., 0) directly from filesystems.


I got it.





@@ -1423,6 +1450,28 @@ __bread(struct block_device *bdev, sector_t block, 
unsigned size)
  }
  EXPORT_SYMBOL(__bread);

+/**
+ *  __bread_nonmovable() - reads a specified block and returns the bh
+ *  @bdev: the block_device to read from
+ *  @block: number of block
+ *  

Re: [PATCH 0/2] new APIs to allocate buffer-cache for superblock in non-movable area

[Gioh Kim]

2014-08-17 오전 3:52, Jan Kara 쓴 글:

On Thu 14-08-14 14:26:10, Andrew Morton wrote:

On Thu, 14 Aug 2014 14:12:17 +0900 Gioh Kim  wrote:


This patch try to solve problem that a long-lasting page caches of
ext4 superblock and journaling of superblock disturb page migration.

I've been testing CMA feature on my ARM-based platform
and found that two page caches cannot be migrated.
They are page caches of superblock of ext4 filesystem and its journaling data.

Current ext4 reads superblock with sb_bread() that allocates page
from movable area. But the problem is that ext4 hold the page until
it is unmounted. If root filesystem is ext4 the page cannot be migrated forever.
And also the journaling data for the superblock cannot be migreated.

I introduce a new API for allocating page cache from non-movable area.
It is useful for ext4/ext3 and others that want to hold page cache for a long 
time.


All seems reasonable to me.  The additional overhead in buffer.c from
additional function arguments is regrettable but I don't see a
non-hacky alternative.

One vital question which the changelog doesn't really address (it
should): how important is this patch?  Is your test system presently
"completely dead in the water utterly unusable" or "occasionally not
quite as good as it could be".  Somewhere in between?

   I would be also interested in how much these patches make things better.
Because I would expect all metadata that is currently journalled to be
unmovable as well.

Honza



I'm so sorry for lacking of detail.

My test platform has totally 1GB memory, 256MB for CMA and 768MB for normal.
I applied Joonsoo's patch: https://lkml.org/lkml/2014/5/28/64, so that
3/4 of allocation take place in normal area and 1/4 allocation take place in 
CMA area.

And my platform has 4 ext4 partitions. Each ext4 partition has 2 page caches 
for superblock that
are what this patch tries to move to out of CMA area.
Therefore there are 8 page caches (8 pages size) that can prevent page 
migration.

My test scenario is trying to allocate all CMA area: repeating 16MB allocation 
until all CMA area are allocated.
In the most cases 2 pages are allocated from CMA area and one allocation among 
16 tries to allocation failed.
It is rare case that every allocation successes.

Applying this patch no page cache is allocation from CMA area and every 
allocation successes.

Please inform me if you need any information.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mem-hotplug: let memblock skip the hotpluggable memory regions in __next_mem_range()

[tangchen]

Hi tj,

On 08/17/2014 07:08 PM, Tejun Heo wrote:

Hello,

On Sat, Aug 16, 2014 at 10:36:41PM +0800, Xishi Qiu wrote:

numa_clear_node_hotplug()? There is only numa_clear_kernel_node_hotplug().

Yeah, that one.


If we don't clear hotpluggable flag in free_low_memory_core_early(), the
memory which marked hotpluggable flag will not free to buddy allocator.
Because __next_mem_range() will skip them.

free_low_memory_core_early
for_each_free_mem_range
for_each_mem_range
__next_mem_range

Ah, okay, so the patch fixes __next_mem_range() and thus makes
free_low_memory_core_early() to skip hotpluggable regions unlike
before.  Please explain things like that in the changelog.  Also,
what's its relationship with numa_clear_kernel_node_hotplug()?  Do we
still need them?  If so, what are the different roles that these two
separate places serve?


numa_clear_kernel_node_hotplug() only clears hotplug flags for the nodes
the kernel resides in, not for hotpluggable nodes. The reason why we did
this is to enable the kernel to allocate memory in case all the nodes are
hotpluggable.

And we clear hotplug flags for all the nodes in free_low_memory_core_early()
is because if we do not, all hotpluggable memory won't be able to be freed
to buddy after Qiu's patch.

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: 3.16-rcX crashes on resume from Suspend-To-RAM

[Zhang Rui]

On Sat, 2014-08-16 at 02:46 +0200, Rafael J. Wysocki wrote:
> On Friday, August 15, 2014 10:17:42 AM Markus Gutschke wrote:
> > Just wondering if any of you had any other ideas of what I could try
> > to help debug this problem?
> 
> My theory is that there is a device in your system that we don't have a driver
> for, but it had been enumerated as a PNP device before the change that 
> triggered
> the problem for you and we turned it off during suspend as part of the default
> ACPI PNP device handling.

I had the same assumption before, thus I checked the difference of
platform devices and pnp devices, and found that there are three devices
enumerated to platform bus instead of PNP bus after the ACPI enumeration
rework patches. They are PNP0800, PNP0200 and PNP0C04 devices, thus I
made a debug patch to add those ids to the acpi_pnp scan handler id list
so that they will stay in PNP bus. But the problem still exists after
applying the debug patch.
> 
> The reason why you're seeing a crash with the "platform" test level is most
> likely that the _WAK control method does something unusual on your system.
> 
an easy way to check this is to apply the debug patch attached and
re-test "platform" test level.

thanks,
rui
> The LNXSYBUS:00 thing from dmesg probably is a red herring.
> 
> I need the output of acpidump from the affected system, but please attach it
> to the bug entry at https://bugzilla.kernel.org/show_bug.cgi?id=80911 that
> Rui has created for this issue.
> 
> Also please check the list of PNP devices under
> 
> /sys/bus/pnp/devices/
> 
> before and after the commit you have found by bisection and let me know if
> there are any differences.
> 
> 
> > On Tue, Aug 12, 2014 at 9:11 AM, Markus Gutschke  
> > wrote:
> > > As I said earlier in this thread, echo'ing "devices" into "pm_test"
> > > does not result in a crash; but doing so for "platform" does.
> > >
> > > Markus
> > >
> > > On Aug 12, 2014 1:26 AM, "Zhang Rui"  wrote:
> > >>
> > >> On Sat, 2014-08-09 at 03:14 -0700, Markus Gutschke wrote:
> > >> > I am back and have physical access to the machine now.
> > >> >
> > >> great!
> > >>
> > >> > I re-ran the test just to be sure, and I can confirm that "platform"
> > >> > does in fact result in a crash.
> > >> >
> > >> what about "devices"?
> > >> I mean
> > >>
> > >> # echo devices > /sys/power/pm_test
> > >>
> > >> and see if that triggers the crash.
> > >>
> > >> > Furthermore, I ran the test that Rui asked for. I suspended, resumed,
> > >> > and upon crashing power-cycled the machine ASAP. "dmesg" suggests that
> > >> > the problem is with LNXSYBUS:00 That doesn't tell me much, but
> > >> > hopefully it makes sense to you guys.
> > >> >
> > >> [0.930093]   Magic number: 10:810:122
> > >> [0.930185] acpi LNXSYBUS:00: hash matches
> > >>
> > >> This looks weird, ACPI will do nothing for LNXSYBUS devices during
> > >> resume.
> > >> Rafael, any thought on this?
> > >>
> > >> thanks,
> > >> rui
> > >>
> 

>From 1a51cb80cf581a0aa228dd82aaf45f4e250d0d59 Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Mon, 18 Aug 2014 09:09:07 +0800
Subject: [PATCH] 80911: Debug patch to skip _WAK in platform pm_test mode

---
 kernel/power/suspend.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 6dadb25..402f0ca 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -270,11 +270,12 @@ static int suspend_enter(suspend_state_t state, bool *wakeup)
 		printk(KERN_ERR "PM: Some devices failed to power down\n");
 		goto Platform_finish;
 	}
-	error = platform_suspend_prepare_late(state);
-	if (error)
-		goto Platform_wake;
 
 	if (suspend_test(TEST_PLATFORM))
+		goto Platform_test;
+
+	error = platform_suspend_prepare_late(state);
+	if (error)
 		goto Platform_wake;
 
 	/*
@@ -319,8 +320,8 @@ static int suspend_enter(suspend_state_t state, bool *wakeup)
 
  Platform_wake:
 	platform_suspend_wake(state);
+ Platform_test:
 	dpm_resume_start(PMSG_RESUME);
-
  Platform_finish:
 	platform_suspend_finish(state);
 	return error;
-- 
1.8.3.2

rt_sigreturn rejects a substitute stack frame as invalid.

[Steven Stewart-Gallus]

Hello,

I'm not totally sure that GLibc's setcontext is safe to use in a
signal handler. So, I decided I was going to play things safe and let
rt_sigreturn switch stacks for me instead. However, rt_sigreturn seems
to reject my substitute stack frame as invalid and I'm not sure why.

Thank you,
Steven Stewart-Gallus

The code:

#include 
#include 
#include 
#include 

static ucontext_t alternate_context;

static char alternate_context_stack[SIGSTKSZ];

static char signal_stack[SIGSTKSZ];


static void alternate_context_func(void)
{
puts("alternate context!");
}

static void switch_stack(int signo, siginfo_t *infop, void *untyped_ucontextp)
{
ucontext_t * ucontextp = untyped_ucontextp;

/* I'm not sure if setcontext is async-signal-safe so set the
 * context using the return from the signal handler.
 */

*ucontextp = alternate_context;
#ifdef __linux__
ucontextp->uc_mcontext.fpregs = >__fpregs_mem;
#endif
}

int main(void)
{
{
stack_t stack = { 0 };

stack.ss_sp = signal_stack;
stack.ss_size = sizeof signal_stack;

sigaltstack(, NULL);
}

getcontext(_context);
alternate_context.uc_stack.ss_sp = alternate_context_stack;
alternate_context.uc_stack.ss_size = sizeof alternate_context_stack;
makecontext(_context, (void (*)(void))alternate_context_func, 0U);

{
struct sigaction action = { 0 };

action.sa_sigaction = switch_stack;
action.sa_flags = SA_SIGINFO;

sigfillset(_mask);

sigaction(SIGRTMIN, , NULL);
}

raise(SIGRTMIN);

}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 回复： Re: [PATCH] unicore32: Fix build error

[Xuetao Guan]

- Guenter Roeck  写道：
> On 08/15/2014 05:45 PM, Xuetao Guan  wrote:
> >
> > - Guenter Roeck  写道：
> >> On 08/10/2014 08:29 AM, Guenter Roeck wrote:
> >>> unicore32 builds fail with
> >>>
> >>> arch/unicore32/kernel/signal.c: In function ‘setup_frame’:
> >>> arch/unicore32/kernel/signal.c:257: error:
> >>>   ‘usig’ undeclared (first use in this function)
> >>> arch/unicore32/kernel/signal.c:279: error:
> >>>   ‘usig’ undeclared (first use in this function)
> >>> arch/unicore32/kernel/signal.c: In function ‘handle_signal’:
> >>> arch/unicore32/kernel/signal.c:306: warning: unused variable ‘tsk’
> >>> arch/unicore32/kernel/signal.c: In function ‘do_signal’:
> >>> arch/unicore32/kernel/signal.c:376: error:
> >>>   implicit declaration of function ‘get_signsl’
> >>> make[1]: *** [arch/unicore32/kernel/signal.o] Error 1
> >>> make: *** [arch/unicore32/kernel/signal.o] Error 2
> >>>
> >>> Bisect points to commit 649671c90eaf ("unicore32: Use get_signal()
> >>> signal_setup_done()").
> >>>
> >>> This code never even compiled. Reverting the patch does not work,
> >>> since previously used functions no longer exist, so try to fix it up.
> >>> Compile tested only.
> >>>
> >>> Cc: Richard Weinberger 
> >>> Signed-off-by: Guenter Roeck 
> >>
> >> ping ...
> >>
> >> Failure is still present in upstream kernel (v3.16-11383-gc9d2642).
> >>
> >> Guenter
> >>
> >
> > Thanks. I'll fix it.
> >
> 
> More a question of applying (and if possible testing) the patch I provided.
> 
> Thanks,
> Guenter
> 
> 
Ok, I'll do it.

Xuetao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v15 3/7] sparc: add pmd_[dirty|mkclean] for THP

[Minchan Kim]

MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.

This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.

Acked-by: David S. Miller 
Cc: sparcli...@vger.kernel.org
Signed-off-by: Minchan Kim 
---
 arch/sparc/include/asm/pgtable_64.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/sparc/include/asm/pgtable_64.h 
b/arch/sparc/include/asm/pgtable_64.h
index 3770bf5c6e1b..b80a309d7e00 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -666,6 +666,13 @@ static inline unsigned long pmd_young(pmd_t pmd)
return pte_young(pte);
 }
 
+static inline int pmd_dirty(pmd_t pmd)
+{
+   pte_t pte = __pte(pmd_val(pmd));
+
+   return pte_dirty(pte);
+}
+
 static inline unsigned long pmd_write(pmd_t pmd)
 {
pte_t pte = __pte(pmd_val(pmd));
@@ -723,6 +730,15 @@ static inline pmd_t pmd_mkdirty(pmd_t pmd)
return __pmd(pte_val(pte));
 }
 
+static inline pmd_t pmd_mkclean(pmd_t pmd)
+{
+   pte_t pte = __pte(pmd_val(pmd));
+
+   pte = pte_mkclean(pte);
+
+   return __pmd(pte_val(pte));
+}
+
 static inline pmd_t pmd_mkyoung(pmd_t pmd)
 {
pte_t pte = __pte(pmd_val(pmd));
-- 
2.0.0

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

[PATCH v15 1/7] mm: support madvise(MADV_FREE)

[Minchan Kim]

Linux doesn't have an ability to free pages lazy while other OS
already have been supported that named by madvise(MADV_FREE).

The gain is clear that kernel can discard freed pages rather than
swapping out or OOM if memory pressure happens.

Without memory pressure, freed pages would be reused by userspace
without another additional overhead(ex, page fault + allocation
+ zeroing).

How to work is following as.

When madvise syscall is called, VM clears dirty bit of ptes of
the range. If memory pressure happens, VM checks dirty bit of
page table and if it found still "clean", it means it's a
"lazyfree pages" so VM could discard the page instead of swapping out.
Once there was store operation for the page before VM peek a page
to reclaim, dirty bit is set so VM can swap out the page instead of
discarding.

Firstly, heavy users would be general allocators(ex, jemalloc,
tcmalloc and hope glibc supports it) and jemalloc/tcmalloc already
have supported the feature for other OS(ex, FreeBSD)

barrios@blaptop:~/benchmark/ebizzy$ lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):4
On-line CPU(s) list:   0-3
Thread(s) per core:2
Core(s) per socket:2
Socket(s): 1
NUMA node(s):  1
Vendor ID: GenuineIntel
CPU family:6
Model: 42
Stepping:  7
CPU MHz:   2801.000
BogoMIPS:  5581.64
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  4096K
NUMA node0 CPU(s): 0-3

ebizzy benchmark(./ebizzy -S 10 -n 512)

 vanilla-jemalloc   MADV_free-jemalloc

1 thread
records:  10  records:  10
avg:  7682.10 avg:  15306.10
std:  62.35(0.81%)std:  347.99(2.27%)
max:  7770.00 max:  15622.00
min:  7598.00 min:  14772.00

2 thread
records:  10  records:  10
avg:  12747.50avg:  24171.00
std:  792.06(6.21%)   std:  895.18(3.70%)
max:  13337.00max:  26023.00
min:  10535.00min:  23152.00

4 thread
records:  10  records:  10
avg:  16474.60avg:  33717.90
std:  1496.45(9.08%)  std:  2008.97(5.96%)
max:  17877.00max:  35958.00
min:  12224.00min:  29565.00

8 thread
records:  10  records:  10
avg:  16778.50avg:  33308.10
std:  825.53(4.92%)   std:  1668.30(5.01%)
max:  17543.00max:  36010.00
min:  14576.00min:  29577.00

16 thread
records:  10  records:  10
avg:  20614.40avg:  35516.30
std:  602.95(2.92%)   std:  1283.65(3.61%)
max:  21753.00max:  37178.00
min:  19605.00min:  33217.00

32 thread
records:  10  records:  10
avg:  22771.70avg:  36018.50
std:  598.94(2.63%)   std:  1046.76(2.91%)
max:  24035.00max:  37266.00
min:  22108.00min:  34149.00

In summary, MADV_FREE is about 2 time faster than MADV_DONTNEED.

Cc: Michael Kerrisk 
Cc: Linux API 
Cc: Hugh Dickins 
Cc: Johannes Weiner 
Cc: KOSAKI Motohiro 
Cc: Mel Gorman 
Cc: Jason Evans 
Acked-by: Kirill A. Shutemov 
Acked-by: Zhang Yanfei 
Acked-by: Rik van Riel 
Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h   |   9 ++-
 include/linux/vm_event_item.h  |   1 +
 include/uapi/asm-generic/mman-common.h |   1 +
 mm/madvise.c   | 140 +
 mm/rmap.c  |  42 +-
 mm/vmscan.c|  40 --
 mm/vmstat.c|   1 +
 7 files changed, 222 insertions(+), 12 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index be574506e6a9..0ba377b97a38 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -75,6 +75,7 @@ enum ttu_flags {
TTU_UNMAP = 1,  /* unmap mode */
TTU_MIGRATION = 2,  /* migration mode */
TTU_MUNLOCK = 4,/* munlock mode */
+   TTU_FREE = 8,   /* free mode */
 
TTU_IGNORE_MLOCK = (1 << 8),/* ignore mlock */
TTU_IGNORE_ACCESS = (1 << 9),   /* don't age */
@@ -181,7 +182,8 @@ static inline void page_dup_rmap(struct page *page)
  * Called from mm/vmscan.c to handle paging out
  */
 int page_referenced(struct page *, int is_locked,
-   struct mem_cgroup *memcg, unsigned long *vm_flags);
+   struct mem_cgroup *memcg, unsigned long *vm_flags,
+   int *is_dirty);
 
 #define TTU_ACTION(x) ((x) & TTU_ACTION_MASK)
 
@@ -260,9 +262,12 @@ int rmap_walk(struct page *page, struct rmap_walk_control 
*rwc);
 
 static inline int page_referenced(struct page *page, int 

[PATCH v15 4/7] powerpc: add pmd_[dirty|mkclean] for THP

[Minchan Kim]

MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.

This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: linuxppc-...@lists.ozlabs.org
Reviewed-by: Aneesh Kumar K.V 
Signed-off-by: Minchan Kim 
---
 arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h 
b/arch/powerpc/include/asm/pgtable-ppc64.h
index eb9261024f51..c9a4bbe8e179 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -468,9 +468,11 @@ static inline pte_t *pmdp_ptep(pmd_t *pmd)
 
 #define pmd_pfn(pmd)   pte_pfn(pmd_pte(pmd))
 #define pmd_young(pmd) pte_young(pmd_pte(pmd))
+#define pmd_dirty(pmd) pte_dirty(pmd_pte(pmd))
 #define pmd_mkold(pmd) pte_pmd(pte_mkold(pmd_pte(pmd)))
 #define pmd_wrprotect(pmd) pte_pmd(pte_wrprotect(pmd_pte(pmd)))
 #define pmd_mkdirty(pmd)   pte_pmd(pte_mkdirty(pmd_pte(pmd)))
+#define pmd_mkclean(pmd)   pte_pmd(pte_mkclean(pmd_pte(pmd)))
 #define pmd_mkyoung(pmd)   pte_pmd(pte_mkyoung(pmd_pte(pmd)))
 #define pmd_mkwrite(pmd)   pte_pmd(pte_mkwrite(pmd_pte(pmd)))
 
-- 
2.0.0

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

[PATCH v15 7/7] mm: Don't split THP page when syscall is called

[Minchan Kim]

We don't need to split THP page when MADV_FREE syscall is
called. It could be done when VM decide really frees it so
we could avoid unnecessary THP split.

Cc: Andrea Arcangeli 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 
---
 include/linux/huge_mm.h |  4 
 mm/huge_memory.c| 35 +++
 mm/madvise.c| 21 -
 mm/rmap.c   |  8 ++--
 mm/vmscan.c | 28 ++--
 5 files changed, 83 insertions(+), 13 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 63579cb8d3dc..25a961256d9f 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -19,6 +19,9 @@ extern struct page *follow_trans_huge_pmd(struct 
vm_area_struct *vma,
  unsigned long addr,
  pmd_t *pmd,
  unsigned int flags);
+extern int madvise_free_huge_pmd(struct mmu_gather *tlb,
+   struct vm_area_struct *vma,
+   pmd_t *pmd, unsigned long addr);
 extern int zap_huge_pmd(struct mmu_gather *tlb,
struct vm_area_struct *vma,
pmd_t *pmd, unsigned long addr);
@@ -56,6 +59,7 @@ extern pmd_t *page_check_address_pmd(struct page *page,
 unsigned long address,
 enum page_check_address_pmd_flag flag,
 spinlock_t **ptl);
+extern int pmd_freeable(pmd_t pmd);
 
 #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
 #define HPAGE_PMD_NR (1mmap_sem)) {
+   pr_err("%s: mmap_sem is unlocked! addr=0x%lx 
end=0x%lx vma->vm_start=0x%lx vma->vm_end=0x%lx\n",
+   __func__, addr, end,
+   vma->vm_start,
+   vma->vm_end);
+   BUG();
+   }
+#endif
+   split_huge_page_pmd(vma, addr, pmd);
+   } else if (!madvise_free_huge_pmd(tlb, vma, pmd, addr))
+   goto next;
+   /* fall through */
+   }
 
-   split_huge_page_pmd(vma, addr, pmd);
if (pmd_trans_unstable(pmd))
return 0;
 
@@ -316,6 +334,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long 
addr,
}
arch_leave_lazy_mmu_mode();
pte_unmap_unlock(pte - 1, ptl);
+next:
cond_resched();
return 0;
 }
diff --git a/mm/rmap.c b/mm/rmap.c
index 04c181133890..9c407576ff8e 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -704,9 +704,13 @@ static int page_referenced_one(struct page *page, struct 
vm_area_struct *vma,
referenced++;
 
/*
-* In this implmentation, MADV_FREE doesn't support THP free
+* Use pmd_freeable instead of raw pmd_dirty because in some
+* of architecture, pmd_dirty is not defined unless
+* CONFIG_TRANSPARNTE_HUGE is enabled
 */
-   dirty++;
+   if (!pmd_freeable(*pmd))
+   dirty++;
+
spin_unlock(ptl);
} else {
pte_t *pte;
diff --git 

[PATCH v15 5/7] arm: add pmd_mkclean for THP

[Minchan Kim]

MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.

This patch adds pmd_mkclean for THP page MADV_FREE support.

Cc: Catalin Marinas 
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Acked-by: Will Deacon 
Acked-by: Steve Capper 
Signed-off-by: Minchan Kim 
---
 arch/arm/include/asm/pgtable-3level.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/pgtable-3level.h 
b/arch/arm/include/asm/pgtable-3level.h
index 06e0bc0f8b00..bc913a065270 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -234,6 +234,7 @@ PMD_BIT_FUNC(mkold, &= ~PMD_SECT_AF);
 PMD_BIT_FUNC(mksplitting, |= L_PMD_SECT_SPLITTING);
 PMD_BIT_FUNC(mkwrite,   &= ~L_PMD_SECT_RDONLY);
 PMD_BIT_FUNC(mkdirty,   |= L_PMD_SECT_DIRTY);
+PMD_BIT_FUNC(mkclean,   &= ~L_PMD_SECT_DIRTY);
 PMD_BIT_FUNC(mkyoung,   |= PMD_SECT_AF);
 
 #define pmd_mkhuge(pmd)(__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
-- 
2.0.0

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

[PATCH v15 2/7] x86: add pmd_[dirty|mkclean] for THP

[Minchan Kim]

MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.

This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Acked-by: Zhang Yanfei 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 
---
 arch/x86/include/asm/pgtable.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 0ec056012618..329865799653 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -104,6 +104,11 @@ static inline int pmd_young(pmd_t pmd)
return pmd_flags(pmd) & _PAGE_ACCESSED;
 }
 
+static inline int pmd_dirty(pmd_t pmd)
+{
+   return pmd_flags(pmd) & _PAGE_DIRTY;
+}
+
 static inline int pte_write(pte_t pte)
 {
return pte_flags(pte) & _PAGE_RW;
@@ -267,6 +272,11 @@ static inline pmd_t pmd_mkold(pmd_t pmd)
return pmd_clear_flags(pmd, _PAGE_ACCESSED);
 }
 
+static inline pmd_t pmd_mkclean(pmd_t pmd)
+{
+   return pmd_clear_flags(pmd, _PAGE_DIRTY);
+}
+
 static inline pmd_t pmd_wrprotect(pmd_t pmd)
 {
return pmd_clear_flags(pmd, _PAGE_RW);
-- 
2.0.0

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

[PATCH v15 6/7] arm64: add pmd_[dirty|mkclean] for THP

[Minchan Kim]

MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.

This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.

Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Acked-by: Will Deacon 
Acked-by: Steve Capper 
Acked-by: Catalin Marinas 
Signed-off-by: Minchan Kim 
---
 arch/arm64/include/asm/pgtable.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index ffe1ba0506d1..efb1b2fc4d39 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -259,10 +259,12 @@ static inline pmd_t pte_pmd(pte_t pte)
 #endif
 
 #define pmd_young(pmd) pte_young(pmd_pte(pmd))
+#define pmd_dirty(pmd) pte_dirty(pmd_pte(pmd))
 #define pmd_wrprotect(pmd) pte_pmd(pte_wrprotect(pmd_pte(pmd)))
 #define pmd_mksplitting(pmd)   pte_pmd(pte_mkspecial(pmd_pte(pmd)))
 #define pmd_mkold(pmd) pte_pmd(pte_mkold(pmd_pte(pmd)))
 #define pmd_mkwrite(pmd)   pte_pmd(pte_mkwrite(pmd_pte(pmd)))
+#define pmd_mkclean(pmd)   pte_pmd(pte_mkclean(pmd_pte(pmd)))
 #define pmd_mkdirty(pmd)   pte_pmd(pte_mkdirty(pmd_pte(pmd)))
 #define pmd_mkyoung(pmd)   pte_pmd(pte_mkyoung(pmd_pte(pmd)))
 #define pmd_mknotpresent(pmd)  (__pmd(pmd_val(pmd) & ~PMD_TYPE_MASK))
-- 
2.0.0

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

[PATCH v15 0/7] MADV_FREE support

[Minchan Kim]

This patch enable MADV_FREE hint for madvise syscall, which have
been supported by other OSes. [PATCH 1] includes the details.

[1] support MADVISE_FREE for !THP page so if VM encounter
THP page in syscall context, it splits THP page.
[2-6] is to preparing to call madvise syscall without THP plitting
[7] enable THP page support for MADV_FREE.

* from v14
 * Add more Ackedy-by from arch people(sparc, arm64 and arm)
 * Drop s390 since pmd_dirty/clean was merged

* from v13
 * Add more Ackedy-by from arch people(arm, arm64 and ppc)
 * Rebased on mmotm 2014-08-13-14-29

* from v12
 * Fix - skip to mark free pte on try_to_free_swap failed page - Kirill
 * Add more Acked-by from arch maintainers and Kirill

* From v11
 * Fix arm build - Steve
 * Separate patch for arm and arm64 - Steve
 * Remove unnecessary check - Kirill
 * Skip non-vm_normal page - Kirill
 * Add Acked-by - Zhang
 * Sparc64 build fix
 * Pagetable walker THP handling fix

* From v10
 * Add Acked-by from arch stuff(x86, s390)
 * Pagewalker based pagetable working - Kirill
 * Fix try_to_unmap_one broken with hwpoison - Kirill
 * Use VM_BUG_ON_PAGE in madvise_free_pmd - Kirill
 * Fix pgtable-3level.h for arm - Steve

* From v9
 * Add Acked-by - Rik
 * Add THP page support - Kirill

* From v8
 * Rebased-on v3.16-rc2-mmotm-2014-06-25-16-44

* From v7
 * Rebased-on next-20140613

* From v6
 * Remove page from swapcache in syscal time
 * Move utility functions from memory.c to madvise.c - Johannes
 * Rename untilify functtions - Johannes
 * Remove unnecessary checks from vmscan.c - Johannes
 * Rebased-on v3.15-rc5-mmotm-2014-05-16-16-56
 * Drop Reviewe-by because there was some changes since then.

* From v5
 * Fix PPC problem which don't flush TLB - Rik
 * Remove unnecessary lazyfree_range stub function - Rik
 * Rebased on v3.15-rc5

* From v4
 * Add Reviewed-by: Zhang Yanfei
 * Rebase on v3.15-rc1-mmotm-2014-04-15-16-14

* From v3
 * Add "how to work part" in description - Zhang
 * Add page_discardable utility function - Zhang
 * Clean up

* From v2
 * Remove forceful dirty marking of swap-readed page - Johannes
 * Remove deactivation logic of lazyfreed page
 * Rebased on 3.14
 * Remove RFC tag

* From v1
 * Use custom page table walker for madvise_free - Johannes
 * Remove PG_lazypage flag - Johannes
 * Do madvise_dontneed instead of madvise_freein swapless system

Minchan Kim (7):
  mm: support madvise(MADV_FREE)
  x86: add pmd_[dirty|mkclean] for THP
  sparc: add pmd_[dirty|mkclean] for THP
  powerpc: add pmd_[dirty|mkclean] for THP
  arm: add pmd_mkclean for THP
  arm64: add pmd_[dirty|mkclean] for THP
  mm: Don't split THP page when syscall is called

 arch/arm/include/asm/pgtable-3level.h|   1 +
 arch/arm64/include/asm/pgtable.h |   2 +
 arch/powerpc/include/asm/pgtable-ppc64.h |   2 +
 arch/sparc/include/asm/pgtable_64.h  |  16 
 arch/x86/include/asm/pgtable.h   |  10 ++
 include/linux/huge_mm.h  |   4 +
 include/linux/rmap.h |   9 +-
 include/linux/vm_event_item.h|   1 +
 include/uapi/asm-generic/mman-common.h   |   1 +
 mm/huge_memory.c |  35 +++
 mm/madvise.c | 159 +++
 mm/rmap.c|  46 -
 mm/vmscan.c  |  64 +
 mm/vmstat.c  |   1 +
 14 files changed, 331 insertions(+), 20 deletions(-)

-- 
2.0.0

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

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

[Nicolas Pitre]

On Sun, 17 Aug 2014, Russell King - ARM Linux wrote:

> On Sun, Aug 17, 2014 at 03:04:34PM -0400, Jason Cooper wrote:
> > Quoting Nico:
> > 
> > "Of course it would be good to clarify things wrt Russell's remark
> > independently from this patch."
> > 
> > I took 'independently' to mean "This patch is ok, *and* we need to
> > address Russell's concerns in a follow-up patch."
> > 
> > Nico's Reviewed-by with that comment was sent August 13th.  The most
> > recent activity on this thread was also August 13th.  After four days, I
> > reasoned there were no objections to his comment.
> 
> Right, during the merge window, and during merge windows, I tend to
> ignore almost all email now because people don't stop developing, and
> they don't take any notice where the mainline cycle is.  In fact, I go
> off and do non-kernel work during a merge window and only briefly scan
> for bug fixes.
> 
> However, I have other concerns with this patch, which I've yet to air.
> For example, I don't like this crappy conditional locking that people
> keep dreaming up - that kind of stuff makes the kernel much harder to
> statically check that everything is correct.  It's an anti-lockdep
> strategy.
> 
> Secondly, I don't like this:
> 
> +   raw_spin_lock(_sgi_lock);
> +   /*
> +* Ensure that the gic_cpu_map update above is seen in
> +* gic_raise_softirq() before we redirect any pending SGIs that
> +* may have been raised for the outgoing CPU (cur_cpu_id)
> +*/
> +   smp_mb__after_unlock_lock();
> +   raw_spin_unlock(_sgi_lock);
> 
> That goes against the principle of locking, that you lock the data,
> not the code.

I admit I didn't understand the point of that construct on the first 
read.  Maybe I wouldn't be the only one.  Using Stephen's initial 
version for that hunk would be preferable as it is straight forward and 
would mean locking the data instead.

> I have no problem with changing gic_raise_softirq() to use a different
> lock, which gic_migrate_target(), and gic_set_affinity() can also use.
> There's no need for horrid locking here, because the only thing we're
> protecting is gic_map[] and the write to the register to trigger an
> IPI - and nothing using gic_arch_extn has any business knowing about
> SGIs.
> 
> No need for these crappy sgi_map_lock() macros and all the ifdeffery.

Those macros are there only to conditionalize the locking in 
gic_raise_softirq() because no locking what so ever is needed there when 
gic_migrate_target() is configured out.  I suggested the macros to cut 
down on the #ifdefery in the code.


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

RE: [PATCH 2/3] smp: re-implement the kick_all_cpus_sync() with wake_up_if_idle()

[Liu, Chuansheng]

Hello Andy,

> -Original Message-
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Friday, August 15, 2014 11:41 PM
> To: Liu, Chuansheng
> Cc: Peter Zijlstra; Daniel Lezcano; Rafael J. Wysocki; Ingo Molnar;
> linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Liu, Changcheng;
> Wang, Xiaoming; Chakravarty, Souvik K
> Subject: Re: [PATCH 2/3] smp: re-implement the kick_all_cpus_sync() with
> wake_up_if_idle()
> 
> On Fri, Aug 15, 2014 at 12:01 AM, Chuansheng Liu
>  wrote:
> > Currently using smp_call_function() just woke up the corresponding
> > cpu, but can not break the polling idle loop.
> >
> > Here using the new sched API wake_up_if_idle() to implement it.
> 
> kick_all_cpus_sync has other callers, and those other callers want the
> old behavior.  I think this should be a new function.
> 
Yes, seems some current users of kick_all_cpus_sync() need IPI indeed,
will try to send out patch V2 with one new function.

Re: [PATCH v14 5/8] s390: add pmd_[dirty|mkclean] for THP

[Minchan Kim]

Hello,

On Thu, Aug 14, 2014 at 09:16:14AM +0200, Martin Schwidefsky wrote:
> On Thu, 14 Aug 2014 10:53:29 +0900
> Minchan Kim  wrote:
> 
> > MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
> > overwrite of the contents since MADV_FREE syscall is called for
> > THP page but for s390 pmds only referenced bit is available
> > because there is no free bit left in the pmd entry for the
> > software dirty bit so this patch adds dumb pmd_dirty which
> > returns always true by suggesting by Martin.
> > 
> > They finally find a solution in future.
> > http://marc.info/?l=linux-api=140440328820808=2
> 
> The solution is already there, see git commit 152125b7a882df36.
> You can drop this patch.

Thanks for the heads up. I will drop it in next spin.
> 
> -- 
> blue skies,
>Martin.
> 
> "Reality continues to ruin my life." - Calvin.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
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 v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

[Nicolas Pitre]

On Sun, 17 Aug 2014, Jason Cooper wrote:

> Russell,
> 
> On Sun, Aug 17, 2014 at 07:55:23PM +0100, Russell King - ARM Linux wrote:
> > On Sun, Aug 17, 2014 at 01:32:36PM -0400, Jason Cooper wrote:
> > > Applied to irqchip/urgent with Nico's Ack.
> > 
> > Interesting, so I'm discussing this patch, and it gets applied anyway...
> > yes, that's great.
> 
> Quoting Nico:
> 
> "Of course it would be good to clarify things wrt Russell's remark
> independently from this patch."
> 
> I took 'independently' to mean "This patch is ok, *and* we need to
> address Russell's concerns in a follow-up patch."
> 
> Nico's Reviewed-by with that comment was sent August 13th.  The most
> recent activity on this thread was also August 13th.  After four days, I
> reasoned there were no objections to his comment.

Well... I mentioned this patch is a nice cleanup independently of the 
reason why it was created in the first place.  Maybe that shouldn't be 
sorted as "urgent" in that case, especially when the code having problem 
with the current state of things is living out of mainline.


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

Re: [PATCH 3/3] zram: add mem_used_max via sysfs

[Minchan Kim]

On Thu, Aug 14, 2014 at 11:32:36AM -0400, David Horner wrote:
> On Thu, Aug 14, 2014 at 11:09 AM, Dan Streetman  wrote:
> > On Wed, Aug 13, 2014 at 9:12 PM, Minchan Kim  wrote:
> >> -   if (zram->limit_bytes &&
> >> -   zs_get_total_size_bytes(meta->mem_pool) > 
> >> zram->limit_bytes) {
> >> +   total_bytes = zs_get_total_size_bytes(meta->mem_pool);
> >> +   if (zram->limit_bytes && total_bytes > zram->limit_bytes) {
> >
> > do you need to take the init_lock to read limit_bytes here?  It could
> > be getting changed between these checks...
> 
> There is no real danger in freeing with an error.
> It is more timing than a race.
> 
> The max calculation is still ok because committed allocations are
> added atomically.

There is one problem in below code piece.

zram->max_used_bytes = max(zram->max_used_bytes, total_bytes);

so we should consider this case.

if (zram->max_used_bytes < total_bytes)
zram->max_used_bytes = total_bytes;

And we could make the situation like this.


if (zram->max_used_bytes < total_bytes)
IRQ happen;
zram->max_used_bytes = total_bytes

During IRQ, other CPU could consume a lot of zsmalloc memory so that
zram->max_used_bytes would be increased under the foot so when IRQ is
finshed, zram->max_used_bytes could be reset with old total_bytes.

To prevent it, we should use the lock I posted RFC version or retry
logic with atomic opeartion(ie, cmpxchg) and my approach makes it simple
first and fix it if we see the trouble in future so my preference is
new spin lock at the moment.

Any comments?



> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
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 2/7] locking/rwsem: more aggressive use of optimistic spinning

[Dave Chinner]

On Fri, Aug 15, 2014 at 01:58:09PM -0400, Waiman Long wrote:
> On 08/14/2014 11:34 PM, Dave Chinner wrote:
> >
> >
> >xfs_io -f -c "truncate 500t" -c "extsize 1m" /path/to/vm/image/file

> 
> Thank for the testing recipe. I am afraid that I can't find a 500TB
> SSD for testing purpose.

Which bit of "sparse vm image file" didn't you understand?  I'm
using a 400GB of SSD for this testing

$ df -h /mnt/fast-ssd
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdf400G  275G  125G  69% /mnt/fast-ssd
$ ls -lh /mnt/fast-ssd/vm-500t.img
-rw--- 1 root root 500T Aug 15 13:21 /mnt/fast-ssd/vm-500t.img
$ du -sh /mnt/fast-ssd/vm-500t.img
275G/mnt/fast-ssd/vm-500t.img

That is on a Samsung 840 EVO SSD, which just about everyone should
be able to obtain. Do you *really* think I have 500TB of SSDs lying
around?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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: [RFC v3 0/2] vfs / btrfs: add support for ustat()

[Luis R. Rodriguez]

On Fri, Aug 15, 2014 at 10:29:50AM +0100, Al Viro wrote:
> On Thu, Aug 14, 2014 at 07:58:56PM -0700, Luis R. Rodriguez wrote:
> 
> > Christoph had noted that this seemed associated to the problem
> > that the btrfs uses different assignments for st_dev than s_dev,
> > but much as I'd like to see that changed based on discussions so
> > far its unclear if this is going to be possible unless strong
> > commitment is reached.
> 
> Explain, please.  Whose commitment and commitment to what, exactly?

There are two folks, one is the btrfs developers, and the others are
the VFS maintainers to provide proper guidance.

> Having different ->st_dev values for different files on the same
> fs is a bloody bad idea; why does btrfs do that at all?

With the disclosure of stating that I'm new to btrfs as I see its been
done to help cope with the copy on write mechanism, but I welcome btrfs
folks to chime in if there other reasons this was done from an
architectural point of view.

Provided all reasons why this was done are clarified what we'd need
then is proper guidance on what *would* be a much more reasonable
strategy to do what was desired, and finally commitmen from btrfs
folks to change btrfs to switch to this new agreed upon strategy.

> If nothing else,
> it breaks the usual "are those two files on the same fs?" tests...

It would seem that those tests need more context now with copy
on write, even the notion of disk space is all fucked up now, we
need to think of it in terms of different possibilities that the
new filesystems allow us to share data and different outcomes that
could be possible.

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

Re: [PATCH 3/3] zram: add mem_used_max via sysfs

[Minchan Kim]

Hello Dan,

On Thu, Aug 14, 2014 at 11:09:05AM -0400, Dan Streetman wrote:
> On Wed, Aug 13, 2014 at 9:12 PM, Minchan Kim  wrote:
> > Normally, zram user can get maximum memory zsmalloc consumed via
> > polling mem_used_total with sysfs in userspace.
> >
> > But it has a critical problem because user can miss peak memory
> > usage during update interval of polling. For avoiding that,
> > user should poll it frequently with mlocking to avoid delay
> > when memory pressure is heavy so it would be handy if the
> > kernel supports the function.
> >
> > This patch adds mem_used_max via sysfs.
> >
> > Signed-off-by: Minchan Kim 
> > ---
> >  Documentation/blockdev/zram.txt |  1 +
> >  drivers/block/zram/zram_drv.c   | 35 +--
> >  drivers/block/zram/zram_drv.h   |  2 ++
> >  3 files changed, 36 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/blockdev/zram.txt 
> > b/Documentation/blockdev/zram.txt
> > index 9f239ff8c444..3b2247c2d4cf 100644
> > --- a/Documentation/blockdev/zram.txt
> > +++ b/Documentation/blockdev/zram.txt
> > @@ -107,6 +107,7 @@ size of the disk when not in use so a huge zram is 
> > wasteful.
> > orig_data_size
> > compr_data_size
> > mem_used_total
> > +   mem_used_max
> >
> >  8) Deactivate:
> > swapoff /dev/zram0
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index b48a3d0e9031..311699f18bd5 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -109,6 +109,30 @@ static ssize_t mem_used_total_show(struct device *dev,
> > return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
> >  }
> >
> > +static ssize_t mem_used_max_reset(struct device *dev,
> > +   struct device_attribute *attr, const char *buf, size_t len)
> > +{
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   down_write(>init_lock);
> > +   zram->max_used_bytes = 0;
> > +   up_write(>init_lock);
> > +   return len;
> > +}
> > +
> > +static ssize_t mem_used_max_show(struct device *dev,
> > +   struct device_attribute *attr, char *buf)
> > +{
> > +   u64 max_used_bytes;
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   down_read(>init_lock);
> > +   max_used_bytes = zram->max_used_bytes;
> > +   up_read(>init_lock);
> > +
> > +   return scnprintf(buf, PAGE_SIZE, "%llu\n", max_used_bytes);
> > +}
> > +
> >  static ssize_t max_comp_streams_show(struct device *dev,
> > struct device_attribute *attr, char *buf)
> >  {
> > @@ -474,6 +498,7 @@ static int zram_bvec_write(struct zram *zram, struct 
> > bio_vec *bvec, u32 index,
> > struct zram_meta *meta = zram->meta;
> > struct zcomp_strm *zstrm;
> > bool locked = false;
> > +   u64 total_bytes;
> >
> > page = bvec->bv_page;
> > if (is_partial_io(bvec)) {
> > @@ -543,8 +568,8 @@ static int zram_bvec_write(struct zram *zram, struct 
> > bio_vec *bvec, u32 index,
> > goto out;
> > }
> >
> > -   if (zram->limit_bytes &&
> > -   zs_get_total_size_bytes(meta->mem_pool) > 
> > zram->limit_bytes) {
> > +   total_bytes = zs_get_total_size_bytes(meta->mem_pool);
> > +   if (zram->limit_bytes && total_bytes > zram->limit_bytes) {
> 
> do you need to take the init_lock to read limit_bytes here?  It could
> be getting changed between these checks...

The zram_bvec_write is protected by read-side init_lock while mem_limit_store
is proteced by write-side init_lock.

> 
> > zs_free(meta->mem_pool, handle);
> > ret = -ENOMEM;
> > goto out;
> > @@ -578,6 +603,8 @@ static int zram_bvec_write(struct zram *zram, struct 
> > bio_vec *bvec, u32 index,
> > /* Update stats */
> > atomic64_add(clen, >stats.compr_data_size);
> > atomic64_inc(>stats.pages_stored);
> > +
> > +   zram->max_used_bytes = max(zram->max_used_bytes, total_bytes);
> 
> shouldn't max_used_bytes be atomic64_t?  Or take the init_lock here?
> 
> >  out:
> > if (locked)
> > zcomp_strm_release(zram->comp, zstrm);
> > @@ -656,6 +683,7 @@ static void zram_reset_device(struct zram *zram, bool 
> > reset_capacity)
> > down_write(>init_lock);
> >
> > zram->limit_bytes = 0;
> > +   zram->max_used_bytes = 0;
> >
> > if (!init_done(zram)) {
> > up_write(>init_lock);
> > @@ -897,6 +925,8 @@ static DEVICE_ATTR(initstate, S_IRUGO, initstate_show, 
> > NULL);
> >  static DEVICE_ATTR(reset, S_IWUSR, NULL, reset_store);
> >  static DEVICE_ATTR(orig_data_size, S_IRUGO, orig_data_size_show, NULL);
> >  static DEVICE_ATTR(mem_used_total, S_IRUGO, mem_used_total_show, NULL);
> > +static DEVICE_ATTR(mem_used_max, S_IRUGO | S_IWUSR, mem_used_max_show,
> > +   mem_used_max_reset);
> >  static DEVICE_ATTR(mem_limit, S_IRUGO | S_IWUSR, 

Re: [PATCH 3/3] zram: add mem_used_max via sysfs

[Minchan Kim]

Hi David,

On Thu, Aug 14, 2014 at 06:29:17AM -0400, David Horner wrote:
> The introduction of a reset can cause the stale zero value to be
> retained in the show.
> Instead reset to current value.

It's better. I will do.
Thanks!

> 
> On Wed, Aug 13, 2014 at 9:12 PM, Minchan Kim  wrote:
> > Normally, zram user can get maximum memory zsmalloc consumed via
> > polling mem_used_total with sysfs in userspace.
> >
> > But it has a critical problem because user can miss peak memory
> > usage during update interval of polling. For avoiding that,
> > user should poll it frequently with mlocking to avoid delay
> > when memory pressure is heavy so it would be handy if the
> > kernel supports the function.
> >
> > This patch adds mem_used_max via sysfs.
> >
> > Signed-off-by: Minchan Kim 
> > ---
> >  Documentation/blockdev/zram.txt |  1 +
> >  drivers/block/zram/zram_drv.c   | 35 +--
> >  drivers/block/zram/zram_drv.h   |  2 ++
> >  3 files changed, 36 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/blockdev/zram.txt 
> > b/Documentation/blockdev/zram.txt
> > index 9f239ff8c444..3b2247c2d4cf 100644
> > --- a/Documentation/blockdev/zram.txt
> > +++ b/Documentation/blockdev/zram.txt
> > @@ -107,6 +107,7 @@ size of the disk when not in use so a huge zram is 
> > wasteful.
> > orig_data_size
> > compr_data_size
> > mem_used_total
> > +   mem_used_max
> >
> >  8) Deactivate:
> > swapoff /dev/zram0
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index b48a3d0e9031..311699f18bd5 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -109,6 +109,30 @@ static ssize_t mem_used_total_show(struct device *dev,
> > return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
> >  }
> >
> > +static ssize_t mem_used_max_reset(struct device *dev,
> > +   struct device_attribute *attr, const char *buf, size_t len)
> 
> perhaps these are local functions, but wouldn't the zs_ prefix still
> be appropriate?
> > +{
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   down_write(>init_lock);
> > +   zram->max_used_bytes = 0;
> 
>zram->max_used_bytes = zs_get_total_size_bytes(meta->mem_pool);
> 
>(where meta is set up as below  (beyond my skill level at
> the moment)).
> 
> > +   up_write(>init_lock);
> > +   return len;
> > +}
> > +
> > +static ssize_t mem_used_max_show(struct device *dev,
> > +   struct device_attribute *attr, char *buf)
> > +{
> > +   u64 max_used_bytes;
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   down_read(>init_lock);
> 
> if these are atomic operations, why the (read and write) locks?
> 
> > +   max_used_bytes = zram->max_used_bytes;
> > +   up_read(>init_lock);
> > +
> > +   return scnprintf(buf, PAGE_SIZE, "%llu\n", max_used_bytes);
> > +}
> > +
> >  static ssize_t max_comp_streams_show(struct device *dev,
> > struct device_attribute *attr, char *buf)
> >  {
> > @@ -474,6 +498,7 @@ static int zram_bvec_write(struct zram *zram, struct 
> > bio_vec *bvec, u32 index,
> > struct zram_meta *meta = zram->meta;
> > struct zcomp_strm *zstrm;
> > bool locked = false;
> > +   u64 total_bytes;
> >
> > page = bvec->bv_page;
> > if (is_partial_io(bvec)) {
> > @@ -543,8 +568,8 @@ static int zram_bvec_write(struct zram *zram, struct 
> > bio_vec *bvec, u32 index,
> > goto out;
> > }
> >
> > -   if (zram->limit_bytes &&
> > -   zs_get_total_size_bytes(meta->mem_pool) > 
> > zram->limit_bytes) {
> > +   total_bytes = zs_get_total_size_bytes(meta->mem_pool);
> > +   if (zram->limit_bytes && total_bytes > zram->limit_bytes) {
> > zs_free(meta->mem_pool, handle);
> > ret = -ENOMEM;
> > goto out;
> > @@ -578,6 +603,8 @@ static int zram_bvec_write(struct zram *zram, struct 
> > bio_vec *bvec, u32 index,
> > /* Update stats */
> > atomic64_add(clen, >stats.compr_data_size);
> > atomic64_inc(>stats.pages_stored);
> > +
> > +   zram->max_used_bytes = max(zram->max_used_bytes, total_bytes);
> >  out:
> > if (locked)
> > zcomp_strm_release(zram->comp, zstrm);
> > @@ -656,6 +683,7 @@ static void zram_reset_device(struct zram *zram, bool 
> > reset_capacity)
> > down_write(>init_lock);
> >
> > zram->limit_bytes = 0;
> > +   zram->max_used_bytes = 0;
> >
> > if (!init_done(zram)) {
> > up_write(>init_lock);
> > @@ -897,6 +925,8 @@ static DEVICE_ATTR(initstate, S_IRUGO, initstate_show, 
> > NULL);
> >  static DEVICE_ATTR(reset, S_IWUSR, NULL, reset_store);
> >  static DEVICE_ATTR(orig_data_size, S_IRUGO, orig_data_size_show, NULL);
> >  static DEVICE_ATTR(mem_used_total, S_IRUGO, 

Re: [RFC 3/3] zram: limit memory size for zram

[Minchan Kim]

Hello Sergey,

On Thu, Aug 14, 2014 at 10:29:53PM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
> 
> On (08/14/14 08:27), Minchan Kim wrote:
> > Date: Thu, 14 Aug 2014 08:27:19 +0900
> > From: Minchan Kim 
> > To: Sergey Senozhatsky 
> > Cc: linux...@kvack.org, Jerome Marchand ,
> >  linux-kernel@vger.kernel.org, juno.c...@lge.com, seungho1.p...@lge.com,
> >  Luigi Semenzato , Nitin Gupta 
> > Subject: Re: [RFC 3/3] zram: limit memory size for zram
> > User-Agent: Mutt/1.5.21 (2010-09-15)
> > 
> > Hey Sergey,
> > 
> > On Tue, Aug 05, 2014 at 10:16:15PM +0900, Sergey Senozhatsky wrote:
> > > Hello,
> > > 
> > > On (08/05/14 18:48), Minchan Kim wrote:
> > > > Another idea: we could define void zs_limit_mem(unsinged long nr_pages)
> > > > in zsmalloc and put the limit in zs_pool via new API from zram so that
> > > > zs_malloc could be failed as soon as it exceeds the limit.
> > > > 
> > > > In the end, zram doesn't need to call zs_get_total_size_bytes on every
> > > > write. It's more clean and right layer, IMHO.
> > > 
> > > yes, I think this one is better.
> > 
> > Although I suggested this new one, a few days ago I changed the decision
> > and was testing the new patchset.
> > 
> > If we add new API for zsmalloc, it adds unnecessary overhead for users who
> > doesn't care of limit. Although it's cheap, I'd like to avoid that.
> > 
> > The zsmalloc is just allocator so anybody can use it if they want.
> > But limitation is just requirement of zram who is a one of client
> > being able to use zsmalloc potentially so accouting should be on zram,
> > not zsmalloc.
> > 
> 
> my motivation was that zram does not use that much memory itself,
> zspool - does. zram is just a clueless client from that point of
> view: it recives some requests, do some things with supplied data,
> and asks zspool if the latter one can find some place to keep that
> data (and zram doesn't really care how that memory will be allocated
> or will not be).

Normally, when we consider malloc(3), malloc(3) doesn't give any API
to limit memory size for the process. It just exposes some API to
return the state like (ex, mallopt) to the user so it's user's role
to manage the memory. I thought it's same with zsmalloc.
zsmalloc already exposes zs_get_total_size_bytes so client can do it
if he want to limit and frequent API call(ex, zs_get_total_size_bytes)
should be his overhead while others who don't need to limit should
be no overhead.

> 
> I'm OK if we will have memory limitation in ZRAM. though conceptually,
> IMHO, it feels that such logic belongs to allocation layer. yet I admit
> the potential overhead issue.
> 
> > If we might have more users of zsmalloc in future and they all want this
> > feature that limit of zsmalloc memory usage, we might move the feature
> > from client to zsmalloc core so everybody would be happy for performance
> > and readability but opposite would be painful.
> > 
> > In summary, let's keep the accounting logic in client side of zsmalloc(ie,
> > zram) at the moment but we could move it into zsmalloc core possibly
> > in future.
> > 
> > Any thoughts?
> 
> agreed.

Thanks for the comment, Sergey!

> 
>   -ss
> 
> > > 
> > >   -ss
> > > 
> > > > On Tue, Aug 05, 2014 at 05:02:03PM +0900, Minchan Kim wrote:
> > > > > I have received a request several time from zram users.
> > > > > They want to limit memory size for zram because zram can consume
> > > > > lot of memory on system without limit so it makes memory management
> > > > > control hard.
> > > > > 
> > > > > This patch adds new knob to limit memory of zram.
> > > > > 
> > > > > Signed-off-by: Minchan Kim 
> > > > > ---
> > > > >  Documentation/blockdev/zram.txt |  1 +
> > > > >  drivers/block/zram/zram_drv.c   | 41 
> > > > > +
> > > > >  drivers/block/zram/zram_drv.h   |  1 +
> > > > >  3 files changed, 43 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/blockdev/zram.txt 
> > > > > b/Documentation/blockdev/zram.txt
> > > > > index d24534bee763..fcb0561dfe2e 100644
> > > > > --- a/Documentation/blockdev/zram.txt
> > > > > +++ b/Documentation/blockdev/zram.txt
> > > > > @@ -96,6 +96,7 @@ size of the disk when not in use so a huge zram is 
> > > > > wasteful.
> > > > >   compr_data_size
> > > > >   mem_used_total
> > > > >   mem_used_max
> > > > > + mem_limit
> > > > >  
> > > > >  7) Deactivate:
> > > > >   swapoff /dev/zram0
> > > > > diff --git a/drivers/block/zram/zram_drv.c 
> > > > > b/drivers/block/zram/zram_drv.c
> > > > > index a4d637b4db7d..47f68bbb2c44 100644
> > > > > --- a/drivers/block/zram/zram_drv.c
> > > > > +++ b/drivers/block/zram/zram_drv.c
> > > > > @@ -137,6 +137,37 @@ static ssize_t max_comp_streams_show(struct 
> > > > > device *dev,
> > > > >   return scnprintf(buf, PAGE_SIZE, "%d\n", val);
> > > > >  }
> > > > >  
> > > > > +static ssize_t mem_limit_show(struct device *dev,
> > > > > + struct 

Re: [PATCH 2/2] zram: limit memory size for zram

[Minchan Kim]

Hi Dan,

On Thu, Aug 14, 2014 at 10:33:29AM -0400, Dan Streetman wrote:
> On Wed, Aug 13, 2014 at 8:57 PM, Minchan Kim  wrote:
> > Since zram has no control feature to limit memory usage,
> > it makes hard to manage system memrory.
> >
> > This patch adds new knob "mem_limit" via sysfs to set up the
> > limit.
> >
> > Note: I added the logic in zram, not zsmalloc because the limit
> > is requirement of zram, not zsmalloc so I'd like to avoid
> > unnecessary branch in zsmalloc.
> >
> > Signed-off-by: Minchan Kim 
> > ---
> >  Documentation/blockdev/zram.txt | 20 +++
> >  drivers/block/zram/zram_drv.c   | 43 
> > +
> >  drivers/block/zram/zram_drv.h   |  1 +
> >  3 files changed, 60 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/blockdev/zram.txt 
> > b/Documentation/blockdev/zram.txt
> > index 0595c3f56ccf..9f239ff8c444 100644
> > --- a/Documentation/blockdev/zram.txt
> > +++ b/Documentation/blockdev/zram.txt
> > @@ -74,14 +74,26 @@ There is little point creating a zram of greater than 
> > twice the size of memory
> >  since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of 
> > the
> >  size of the disk when not in use so a huge zram is wasteful.
> >
> > -5) Activate:
> > +5) Set memory limit: Optional
> > +   Set memory limit by writing the value to sysfs node 'mem_limit'.
> > +   The value can be either in bytes or you can use mem suffixes.
> > +   Examples:
> > +   # limit /dev/zram0 with 50MB memory
> > +   echo $((50*1024*1024)) > /sys/block/zram0/mem_limit
> > +
> > +   # Using mem suffixes
> > +   echo 256K > /sys/block/zram0/mem_limit
> > +   echo 512M > /sys/block/zram0/mem_limit
> > +   echo 1G > /sys/block/zram0/mem_limit
> > +
> > +6) Activate:
> > mkswap /dev/zram0
> > swapon /dev/zram0
> >
> > mkfs.ext4 /dev/zram1
> > mount /dev/zram1 /tmp
> >
> > -6) Stats:
> > +7) Stats:
> > Per-device statistics are exported as various nodes under
> > /sys/block/zram/
> > disksize
> > @@ -96,11 +108,11 @@ size of the disk when not in use so a huge zram is 
> > wasteful.
> > compr_data_size
> > mem_used_total
> >
> > -7) Deactivate:
> > +8) Deactivate:
> > swapoff /dev/zram0
> > umount /dev/zram1
> >
> > -8) Reset:
> > +9) Reset:
> > Write any positive value to 'reset' sysfs node
> > echo 1 > /sys/block/zram0/reset
> > echo 1 > /sys/block/zram1/reset
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index d00831c3d731..b48a3d0e9031 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -122,6 +122,35 @@ static ssize_t max_comp_streams_show(struct device 
> > *dev,
> > return scnprintf(buf, PAGE_SIZE, "%d\n", val);
> >  }
> >
> > +static ssize_t mem_limit_show(struct device *dev,
> > +   struct device_attribute *attr, char *buf)
> > +{
> > +   u64 val;
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   down_read(>init_lock);
> > +   val = zram->limit_bytes;
> > +   up_read(>init_lock);
> > +
> > +   return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
> > +}
> > +
> > +static ssize_t mem_limit_store(struct device *dev,
> > +   struct device_attribute *attr, const char *buf, size_t len)
> > +{
> > +   u64 limit;
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   limit = memparse(buf, NULL);
> > +   if (!limit)
> > +   return -EINVAL;
> 
> Shouldn't passing a 0 limit be allowed, to disable the limit?

Sure. Will fix.
Thanks.

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

[PATCH v3 4/6] perf/tests: add interrupted state sample parsing test

[Stephane Eranian]

This patch updates the sample parsing test with support
for the sampling of machine interrupted state.

The patch modifies the do_test() code to sahred the sample
regts bitmask between user and intr regs.

Signed-off-by: Stephane Eranian 
---
 tools/perf/tests/sample-parsing.c |   55 +++--
 1 file changed, 40 insertions(+), 15 deletions(-)

diff --git a/tools/perf/tests/sample-parsing.c 
b/tools/perf/tests/sample-parsing.c
index ca292f9..4908c64 100644
--- a/tools/perf/tests/sample-parsing.c
+++ b/tools/perf/tests/sample-parsing.c
@@ -126,16 +126,28 @@ static bool samples_same(const struct perf_sample *s1,
if (type & PERF_SAMPLE_TRANSACTION)
COMP(transaction);
 
+   if (type & PERF_SAMPLE_REGS_INTR) {
+   size_t sz = hweight_long(s1->intr_regs.mask) * sizeof(u64);
+
+   COMP(intr_regs.mask);
+   COMP(intr_regs.abi);
+   if (s1->intr_regs.abi &&
+   (!s1->intr_regs.regs || !s2->intr_regs.regs ||
+memcmp(s1->intr_regs.regs, s2->intr_regs.regs, sz))) {
+   pr_debug("Samples differ at 'intr_regs'\n");
+   return false;
+   }
+   }
+
return true;
 }
 
-static int do_test(u64 sample_type, u64 sample_regs_user, u64 read_format)
+static int do_test(u64 sample_type, u64 sample_regs, u64 read_format)
 {
struct perf_evsel evsel = {
.needs_swap = false,
.attr = {
.sample_type = sample_type,
-   .sample_regs_user = sample_regs_user,
.read_format = read_format,
},
};
@@ -154,7 +166,7 @@ static int do_test(u64 sample_type, u64 sample_regs_user, 
u64 read_format)
/* 1 branch_entry */
.data = {1, 211, 212, 213},
};
-   u64 user_regs[64];
+   u64 regs[64];
const u64 raw_data[] = {0x123456780a0b0c0dULL, 0x1102030405060708ULL};
const u64 data[] = {0x2211443366558877ULL, 0, 0xaabbccddeeff4321ULL};
struct perf_sample sample = {
@@ -176,8 +188,8 @@ static int do_test(u64 sample_type, u64 sample_regs_user, 
u64 read_format)
.branch_stack   = _stack.branch_stack,
.user_regs  = {
.abi= PERF_SAMPLE_REGS_ABI_64,
-   .mask   = sample_regs_user,
-   .regs   = user_regs,
+   .mask   = sample_regs,
+   .regs   = regs,
},
.user_stack = {
.size   = sizeof(data),
@@ -187,14 +199,25 @@ static int do_test(u64 sample_type, u64 sample_regs_user, 
u64 read_format)
.time_enabled = 0x030a59d664fca7deULL,
.time_running = 0x011b6ae553eb98edULL,
},
+   .intr_regs  = {
+   .abi= PERF_SAMPLE_REGS_ABI_64,
+   .mask   = sample_regs,
+   .regs   = regs,
+   },
};
struct sample_read_value values[] = {{1, 5}, {9, 3}, {2, 7}, {6, 4},};
struct perf_sample sample_out;
size_t i, sz, bufsz;
int err, ret = -1;
 
-   for (i = 0; i < sizeof(user_regs); i++)
-   *(i + (u8 *)user_regs) = i & 0xfe;
+   if (sample_type & PERF_SAMPLE_REGS_USER)
+   evsel.attr.sample_regs_user = sample_regs;
+
+   if (sample_type & PERF_SAMPLE_REGS_INTR)
+   evsel.attr.sample_regs_intr = sample_regs;
+
+   for (i = 0; i < sizeof(regs); i++)
+   *(i + (u8 *)regs) = i & 0xfe;
 
if (read_format & PERF_FORMAT_GROUP) {
sample.read.group.nr = 4;
@@ -271,7 +294,7 @@ int test__sample_parsing(void)
 {
const u64 rf[] = {4, 5, 6, 7, 12, 13, 14, 15};
u64 sample_type;
-   u64 sample_regs_user;
+   u64 sample_regs;
size_t i;
int err;
 
@@ -280,7 +303,7 @@ int test__sample_parsing(void)
 * were added.  Please actually update the test rather than just change
 * the condition below.
 */
-   if (PERF_SAMPLE_MAX > PERF_SAMPLE_TRANSACTION << 1) {
+   if (PERF_SAMPLE_MAX > PERF_SAMPLE_REGS_INTR << 1) {
pr_debug("sample format has changed, some new PERF_SAMPLE_ bit 
was introduced - test needs updating\n");
return -1;
}
@@ -297,22 +320,24 @@ int test__sample_parsing(void)
}
continue;
}
+   sample_regs = 0;
 
if (sample_type == PERF_SAMPLE_REGS_USER)
-   sample_regs_user = 0x3fff;
-   else
-   sample_regs_user = 0;
+   sample_regs = 0x3fff;
+
+   if (sample_type == PERF_SAMPLE_REGS_INTR)
+   sample_regs = 0xff0fff;
 
-   

[PATCH v3 1/6] perf: add ability to sample machine state on interrupt

[Stephane Eranian]

Enable capture of interrupted machine state for each
sample.

Registers to sample are passed per event in the
sample_regs_intr bitmask.

To sample interrupt machine state, the
PERF_SAMPLE_INTR_REGS must be passed in
sample_type.

The list of available registers is arch
dependent and provided by asm/perf_regs.h

Registers are laid out as u64 in the order
of the bit order of sample_intr_regs.

Reviewed-by: Jiri Olsa 
Reviewed-by: Andi Kleen 
Signed-off-by: Stephane Eranian 
---
 include/linux/perf_event.h  |7 +--
 include/uapi/linux/perf_event.h |   14 -
 kernel/events/core.c|   44 +--
 3 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f0a1036..e043465 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -79,7 +79,7 @@ struct perf_branch_stack {
struct perf_branch_entryentries[0];
 };
 
-struct perf_regs_user {
+struct perf_regs {
__u64   abi;
struct pt_regs  *regs;
 };
@@ -599,7 +599,8 @@ struct perf_sample_data {
struct perf_callchain_entry *callchain;
struct perf_raw_record  *raw;
struct perf_branch_stack*br_stack;
-   struct perf_regs_user   regs_user;
+   struct perf_regsregs_user;
+   struct perf_regsregs_intr;
u64 stack_user_size;
u64 weight;
/*
@@ -629,6 +630,8 @@ static inline void perf_sample_data_init(struct 
perf_sample_data *data,
data->weight = 0;
data->data_src.val = PERF_MEM_NA;
data->txn = 0;
+   data->regs_intr.abi = PERF_SAMPLE_REGS_ABI_NONE;
+   data->regs_intr.regs = NULL;
 }
 
 extern void perf_output_sample(struct perf_output_handle *handle,
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 9269de2..8019505 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -137,8 +137,9 @@ enum perf_event_sample_format {
PERF_SAMPLE_DATA_SRC= 1U << 15,
PERF_SAMPLE_IDENTIFIER  = 1U << 16,
PERF_SAMPLE_TRANSACTION = 1U << 17,
+   PERF_SAMPLE_REGS_INTR   = 1U << 18,
 
-   PERF_SAMPLE_MAX = 1U << 18, /* non-ABI */
+   PERF_SAMPLE_MAX = 1U << 19, /* non-ABI */
 };
 
 /*
@@ -334,6 +335,15 @@ struct perf_event_attr {
 
/* Align to u64. */
__u32   __reserved_2;
+   /*
+* Defines set of regs to dump for each sample
+* state captured on:
+*  - precise = 0: PMU interrupt
+*  - precise > 0: sampled instruction
+*
+* See asm/perf_regs.h for details.
+*/
+   __u64   sample_regs_intr;
 };
 
 #define perf_flags(attr)   (*(&(attr)->read_format + 1))
@@ -686,6 +696,8 @@ enum perf_event_type {
 *  { u64   weight;   } && PERF_SAMPLE_WEIGHT
 *  { u64   data_src; } && PERF_SAMPLE_DATA_SRC
 *  { u64   transaction; } && 
PERF_SAMPLE_TRANSACTION
+*  { u64   abi; # enum perf_sample_regs_abi
+*u64   regs[weight(mask)]; } && 
PERF_SAMPLE_REGS_INTR
 * };
 */
PERF_RECORD_SAMPLE  = 9,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 2d7363a..5fa8b17 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4395,7 +4395,7 @@ perf_output_sample_regs(struct perf_output_handle *handle,
}
 }
 
-static void perf_sample_regs_user(struct perf_regs_user *regs_user,
+static void perf_sample_regs_user(struct perf_regs *regs_user,
  struct pt_regs *regs)
 {
if (!user_mode(regs)) {
@@ -4411,6 +4411,14 @@ static void perf_sample_regs_user(struct perf_regs_user 
*regs_user,
}
 }
 
+static void perf_sample_regs_intr(struct perf_regs *regs_intr,
+ struct pt_regs *regs)
+{
+   regs_intr->regs = regs;
+   regs_intr->abi  = perf_reg_abi(current);
+}
+
+
 /*
  * Get remaining task size from user stack pointer.
  *
@@ -4792,6 +4800,22 @@ void perf_output_sample(struct perf_output_handle 
*handle,
if (sample_type & PERF_SAMPLE_TRANSACTION)
perf_output_put(handle, data->txn);
 
+   if (sample_type & PERF_SAMPLE_REGS_INTR) {
+   u64 abi = data->regs_intr.abi;
+   /*
+* If there are no regs to dump, notice it through
+* first u64 being zero (PERF_SAMPLE_REGS_ABI_NONE).
+*/
+   perf_output_put(handle, abi);
+
+   if (abi) {
+   u64 mask = event->attr.sample_regs_intr;
+   perf_output_sample_regs(handle,
+   

[PATCH v3 6/6] perf: improve perf_sample_data struct layout

[Stephane Eranian]

From: Peter Zijlstra 

This patch reorders fields in the perf_sample_data
struct in order to minimize the number of cachelines
touched in perf_sample_data_init(). It also removes
some intializations which are redundant with the
code in kernel/events/core.c

Signed-off-by: Peter Zijlstra 
---
 include/linux/perf_event.h |   34 +-
 kernel/events/core.c   |5 -
 2 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index e043465..57b7efc 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -579,35 +579,40 @@ extern u64 perf_event_read_value(struct perf_event *event,
 
 
 struct perf_sample_data {
-   u64 type;
+   /*
+* Fields set by perf_sample_data_init(), group so as to
+* minimize the cachelines touched.
+*/
+   u64 addr;
+   struct perf_raw_record  *raw;
+   struct perf_branch_stack*br_stack;
+   u64 period;
+   u64 weight;
+   u64 txn;
+   union  perf_mem_data_srcdata_src;
 
+   /*
+* The other fields, optionally {set,used} by
+* perf_{prepare,output}_sample().
+*/
+   u64 type;
u64 ip;
struct {
u32 pid;
u32 tid;
}   tid_entry;
u64 time;
-   u64 addr;
u64 id;
u64 stream_id;
struct {
u32 cpu;
u32 reserved;
}   cpu_entry;
-   u64 period;
-   union  perf_mem_data_srcdata_src;
struct perf_callchain_entry *callchain;
-   struct perf_raw_record  *raw;
-   struct perf_branch_stack*br_stack;
struct perf_regsregs_user;
struct perf_regsregs_intr;
u64 stack_user_size;
-   u64 weight;
-   /*
-* Transaction flags for abort events:
-*/
-   u64 txn;
-};
+} cacheline_aligned;
 
 /* default value for data source */
 #define PERF_MEM_NA (PERF_MEM_S(OP, NA)   |\
@@ -624,14 +629,9 @@ static inline void perf_sample_data_init(struct 
perf_sample_data *data,
data->raw  = NULL;
data->br_stack = NULL;
data->period = period;
-   data->regs_user.abi = PERF_SAMPLE_REGS_ABI_NONE;
-   data->regs_user.regs = NULL;
-   data->stack_user_size = 0;
data->weight = 0;
data->data_src.val = PERF_MEM_NA;
data->txn = 0;
-   data->regs_intr.abi = PERF_SAMPLE_REGS_ABI_NONE;
-   data->regs_intr.regs = NULL;
 }
 
 extern void perf_output_sample(struct perf_output_handle *handle,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5fa8b17..696a778 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4406,8 +4406,11 @@ static void perf_sample_regs_user(struct perf_regs 
*regs_user,
}
 
if (regs) {
-   regs_user->regs = regs;
regs_user->abi  = perf_reg_abi(current);
+   regs_user->regs = regs;
+   } else {
+   regs_user->abi = PERF_SAMPLE_REGS_ABI_NONE;
+   regs_user->regs = NULL;
}
 }
 
-- 
1.7.9.5

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

[PATCH v3 3/6] perf tools: add core support for sampling intr machine state regs

[Stephane Eranian]

Add the infrastructure to setup, collect and report the interrupt
machine state regs which can be captured by the kernel.

Signed-off-by: Stephane Eranian 
---
 tools/perf/perf.h |1 +
 tools/perf/util/event.h   |1 +
 tools/perf/util/evsel.c   |   46 -
 tools/perf/util/session.c |   44 ++-
 4 files changed, 86 insertions(+), 6 deletions(-)

diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 510c65f..309d956 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -54,6 +54,7 @@ struct record_opts {
bool sample_weight;
bool sample_time;
bool period;
+   bool sample_intr_regs;
unsigned int freq;
unsigned int mmap_pages;
unsigned int user_freq;
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 7eb7107..d6e79f3 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -162,6 +162,7 @@ struct perf_sample {
struct ip_callchain *callchain;
struct branch_stack *branch_stack;
struct regs_dump  user_regs;
+   struct regs_dump  intr_regs;
struct stack_dump user_stack;
struct sample_read read;
 };
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 01ce14c..74b4268 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -628,6 +628,11 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts)
if (opts->call_graph_enabled && !evsel->no_aux_samples)
perf_evsel__config_callgraph(evsel, opts);
 
+   if (opts->sample_intr_regs) {
+   attr->sample_regs_intr = PERF_REGS_MASK;
+   perf_evsel__set_sample_bit(evsel, REGS_INTR);
+   }
+
if (target__has_cpu(>target))
perf_evsel__set_sample_bit(evsel, CPU);
 
@@ -1005,6 +1010,7 @@ static size_t perf_event_attr__fprintf(struct 
perf_event_attr *attr, FILE *fp)
ret += PRINT_ATTR_X64(branch_sample_type);
ret += PRINT_ATTR_X64(sample_regs_user);
ret += PRINT_ATTR_U32(sample_stack_user);
+   ret += PRINT_ATTR_X64(sample_regs_intr);
 
ret += fprintf(fp, "%.60s\n", graph_dotted_line);
 
@@ -1504,6 +1510,23 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel, 
union perf_event *event,
array++;
}
 
+   data->intr_regs.abi = PERF_SAMPLE_REGS_ABI_NONE;
+   if (type & PERF_SAMPLE_REGS_INTR) {
+   OVERFLOW_CHECK_u64(array);
+   data->intr_regs.abi = *array;
+   array++;
+
+   if (data->intr_regs.abi != PERF_SAMPLE_REGS_ABI_NONE) {
+   u64 mask = evsel->attr.sample_regs_intr;
+
+   sz = hweight_long(mask) * sizeof(u64);
+   OVERFLOW_CHECK(array, sz, max_size);
+   data->intr_regs.mask = mask;
+   data->intr_regs.regs = (u64 *)array;
+   array = (void *)array + sz;
+   }
+   }
+
return 0;
 }
 
@@ -1599,6 +1622,16 @@ size_t perf_event__sample_event_size(const struct 
perf_sample *sample, u64 type,
if (type & PERF_SAMPLE_TRANSACTION)
result += sizeof(u64);
 
+   if (type & PERF_SAMPLE_REGS_INTR) {
+   if (sample->intr_regs.abi) {
+   result += sizeof(u64);
+   sz = hweight_long(sample->intr_regs.mask) * sizeof(u64);
+   result += sz;
+   } else {
+   result += sizeof(u64);
+   }
+   }
+
return result;
 }
 
@@ -1777,6 +1810,17 @@ int perf_event__synthesize_sample(union perf_event 
*event, u64 type,
array++;
}
 
+   if (type & PERF_SAMPLE_REGS_INTR) {
+   if (sample->intr_regs.abi) {
+   *array++ = sample->intr_regs.abi;
+   sz = hweight_long(sample->intr_regs.mask) * sizeof(u64);
+   memcpy(array, sample->intr_regs.regs, sz);
+   array = (void *)array + sz;
+   } else {
+   *array++ = 0;
+   }
+   }
+
return 0;
 }
 
@@ -1906,7 +1950,7 @@ static int sample_type__fprintf(FILE *fp, bool *first, 
u64 value)
bit_name(READ), bit_name(CALLCHAIN), bit_name(ID), 
bit_name(CPU),
bit_name(PERIOD), bit_name(STREAM_ID), bit_name(RAW),
bit_name(BRANCH_STACK), bit_name(REGS_USER), 
bit_name(STACK_USER),
-   bit_name(IDENTIFIER),
+   bit_name(IDENTIFIER), bit_name(REGS_INTR),
{ .name = NULL, }
};
 #undef bit_name
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 6d2d50d..4eb8ca6 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -581,15 +581,46 @@ static void regs_dump__printf(u64 mask, u64 *regs)
  

[PATCH v3 2/6] perf/x86: add support for sampling PEBS machine state registers

[Stephane Eranian]

PEBS can capture machine state regs at retiremnt of the sampled
instructions. When precise sampling is enabled on an event, PEBS
is used, so substitute the interrupted state with the PEBS state.
Note that not all registers are captured by PEBS. Those missing
are replaced by the interrupt state counter-parts.

Signed-off-by: Stephane Eranian 
---
 arch/x86/kernel/cpu/perf_event_intel_ds.c |   17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 9dc4199..139a8a5 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -886,6 +886,23 @@ static void __intel_pmu_pebs_event(struct perf_event 
*event,
regs.bp = pebs->bp;
regs.sp = pebs->sp;
 
+   if (sample_type & PERF_SAMPLE_REGS_INTR) {
+   regs.ax = pebs->ax;
+   regs.bx = pebs->bx;
+   regs.cx = pebs->cx;
+   regs.si = pebs->si;
+   regs.di = pebs->di;
+
+   regs.r8 = pebs->r8;
+   regs.r9 = pebs->r9;
+   regs.r10 = pebs->r10;
+   regs.r11 = pebs->r11;
+   regs.r12 = pebs->r12;
+   regs.r13 = pebs->r13;
+   regs.r14 = pebs->r14;
+   regs.r14 = pebs->r15;
+   }
+
if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format >= 2) {
regs.ip = pebs->real_ip;
regs.flags |= PERF_EFLAGS_EXACT;
-- 
1.7.9.5

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

[PATCH v3 5/6] perf record: add new -I option to sample interrupted machine state

[Stephane Eranian]

Add -I/--intr-regs option to capture machine state registers at
interrupt.

Add the corresponding man page description

Signed-off-by: Stephane Eranian 
---
 tools/perf/Documentation/perf-record.txt |6 ++
 tools/perf/builtin-record.c  |2 ++
 2 files changed, 8 insertions(+)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index d460049..1a36259 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -214,6 +214,12 @@ if combined with -a or -C options.
 After starting the program, wait msecs before measuring. This is useful to
 filter out the startup phase of the program, which is often very different.
 
+-I::
+--intr-regs::
+Capture machine state (registers) at interrupt, i.e., on counter overflows for
+each sample. List of captured registers depends on the architecture. This 
option
+is off by default.
+
 SEE ALSO
 
 linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 4db670d..8dc1fd8 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -882,6 +882,8 @@ const struct option record_options[] = {
"sample transaction flags (special events only)"),
OPT_BOOLEAN(0, "per-thread", _thread,
"use per-thread mmaps"),
+   OPT_BOOLEAN('I', "intr-regs", _intr_regs,
+   "Sample machine registers on interrupt"),
OPT_END()
 };
 
-- 
1.7.9.5

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

[PATCH v3 0/6] perf: add ability to sample interrupted machine state

[Stephane Eranian]

This short patch series add the ability to sample the interrupted
machine state for each hardware sample. This is useful to analyze
the state after certain events, for instance for function value
profiling after a call instruction.

The patch extends the interface with a new PERF_SAMPLE_REGS_INTR 
smaple_type flag. The register to sample can be named in the
sample_regs_intr bitmask for each event. The name and bit
position for each register is architecture dependent and
provided, just like for PERF_SAMPLE_REGS_USER by asm/perf_regs.h.

The support is similar to PERF_SAMPLE_REGS_USER.

On Intel x86, the series includes support for capturing the
PEBS state as well. When precise sampling is used, the interrupted
state is collect from the PEBS records, at least partially.
The PEBS machine state is a subset of the machine state.

The series provides access to this new feature in perf record
with the -I option. It is possible to display the sampled
register values using perf report -D.

This patch series is the fundation for a future series adding
function value profiling.

In V2, we address the issues raised during reviews:
 - add sample parsing test
 - shorten perf record option to --intr-regs
 - added man page for perf record -I/--intr-regs option
 - refactor register printf code between user and intr regs
 - rebase to v3.16-rc3

In V3, we rebase to 3.16.0+ and made the modifications suggested
by PeterZ. We also integrated his patch to improve the layout
of perf_sample_data.


Peter Zijlstra (1):
  perf: improve perf_sample_data struct layout

Stephane Eranian (5):
  perf: add ability to sample machine state on interrupt
  perf/x86: add support for sampling PEBS machine state registers
  perf tools: add core support for sampling intr machine state regs
  perf/tests: add interrupted state sample parsing test
  perf record: add new -I option to sample interrupted machine state

 arch/x86/kernel/cpu/perf_event_intel_ds.c |   17 +
 include/linux/perf_event.h|   37 ++-
 include/uapi/linux/perf_event.h   |   14 +++-
 kernel/events/core.c  |   49 +++--
 tools/perf/Documentation/perf-record.txt  |6 
 tools/perf/builtin-record.c   |2 ++
 tools/perf/perf.h |1 +
 tools/perf/tests/sample-parsing.c |   55 +
 tools/perf/util/event.h   |1 +
 tools/perf/util/evsel.c   |   46 +++-
 tools/perf/util/session.c |   44 ---
 11 files changed, 230 insertions(+), 42 deletions(-)

-- 
1.7.9.5

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

Re: [RFC PATCH 6/9] gpiolib: add API to get gpio desc and flags

[Darren Hart]

On 8/17/14, 6:00, "Grant Likely"  wrote:

>>
>>+ /* Using device tree? */
>>+ if (IS_ENABLED(CONFIG_OF) && dev->of_node)
>>+ desc = of_find_gpio(dev, NULL, idx, flags);
>
>of_find_gpio() doesn't exist.

Hrm... As of 3.16.0 (e64df3ebe8262c8203d1fe4f541e0241c3112c01)

$ git blame -L1455,1456 drivers/gpio/gpiolib.c
bae48da2 (Alexandre Courbot 2013-10-17 10:21:38 -0700 1455) static struct
gpio_desc *of_find_gpio(struct device *dev, const char *con_id,

Have we removed this in -next or something? (on the plane, will verify
upon landing)



-- 
Darren Hart Open Source Technology Center
darren.h...@intel.com   Intel Corporation



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/9] Driver core: Unified device properties interface for platform firmware

[Darren Hart]

On 8/17/14, 5:49, "Grant Likely"  wrote:

>
>Hi Mika and Rafael,
>
>Comments below...
>
>On Sun, 17 Aug 2014 09:04:13 +0300, Mika Westerberg
> wrote:
>> From: "Rafael J. Wysocki" 
>> 
>> Add a uniform interface by which device drivers can request device
>> properties from the platform firmware by providing a property name
>> and the corresponding data type.
>> 
>> Three general helper functions, device_property_get(),
>> device_property_read() and device_property_read_array() are provided.
>> The first one allows the raw value of a given device property to be
>> accessed by the driver.  The remaining two allow the value of a numeric
>> or string property and multiple numeric or string values of one array
>> property to be acquired, respectively.
>> 
>> The interface is supposed to cover both ACPI and Device Trees,
>> although the ACPI part is only implemented at this time.
>
>Nit:
>s/at this time/in this change. The DT component is implemented in a
>subsequent patch./
>
>I almost complained that the DT portion must be implemented before this
>series can even be considered, but then I found it in patch 4/9.  :-)
>
>> 
>> Signed-off-by: Rafael J. Wysocki 
>> Signed-off-by: Aaron Lu 
>> Reviewed-by: Darren Hart 
>> Signed-off-by: Mika Westerberg 
>> ---
>>  drivers/acpi/glue.c  |   4 +-
>>  drivers/acpi/property.c  | 179
>>++-
>>  drivers/acpi/scan.c  |  12 +++-
>>  drivers/base/Makefile|   2 +-
>>  drivers/base/property.c  |  48 +
>>  include/acpi/acpi_bus.h  |   1 +
>>  include/linux/device.h   |   3 +
>>  include/linux/property.h |  50 +
>>  8 files changed, 293 insertions(+), 6 deletions(-)
>>  create mode 100644 drivers/base/property.c
>>  create mode 100644 include/linux/property.h
>> 

...

>>
>>  static void acpi_device_del(struct acpi_device *device)
>>  {
>>  mutex_lock(_device_lock);
>> -if (device->parent)
>> +if (device->parent) {
>>  list_del(>node);
>> +device->parent->child_count--;
>
>I worry about housekeeping like this. It is easy for bugs to slip in.
>Unless returning the child count is in a critical path (which it
>shouldn't be), I would drop the child_count member and simply count the
>number of items in the list when required.
>
>This of course is not my subsystem, so I won't ACK or NACK the patch over
>this.


This would be consistent with of_get_child_count() and is unlikely to be
called much more than once per device. The maintenance however is limited
to the add/del functions, so it doesn't seem difficult to maintain. I have
no objections to just walking the list though if that is preferable.

...

>> @@ -701,6 +702,7 @@ struct acpi_dev_node {
>>   * @archdata:   For arch-specific additions.
>>   * @of_node:Associated device tree node.
>>   * @acpi_node:  Associated ACPI device node.
>> + * @property_ops: Firmware interface for device properties
>>   * @devt:   For creating the sysfs "dev".
>>   * @id: device instance
>>   * @devres_lock: Spinlock to protect the resource of the device.
>> @@ -777,6 +779,7 @@ struct device {
>>  
>>  struct device_node  *of_node; /* associated device tree node */
>>  struct acpi_dev_nodeacpi_node; /* associated ACPI device node */
>> +struct dev_prop_ops *property_ops;
>
>There are only 2 users of this interface. I don't think adding an ops
>pointer to each and every struct device is warrented when the wrapper
>function can check if of_node or acpi_node is set and call the
>appropriate helper. It is unlikely anything else will use this hook. It
>will result in smaller memory footprint. Also smaller code when only one
>of
>CONFIG_OF and CONFIG_ACPI are selected, which is almost always. :-)
>
>It can be refactored later if that ever changes.


Our intent was to eliminate the #ifdefery in every one of the accessors.
It was my understanding the ops structures were preferable in such
situations. For a 64-bit machine with 1000 devices (all of which use
device properties) with one or the other of ACPI/OF enabled, the
additional memory requirement here is what... Something like (8*1000 + 4)
~= 8KB ? That seems worth the arguably more maintainable code to me. Is
there more to it than this, am I missing some more significant impact?

  
>>  dev_t   devt;   /* dev_t, creates the sysfs "dev" */
>>  u32 id; /* device instance */
>> diff --git a/include/linux/property.h b/include/linux/property.h
>> new file mode 100644
>> index ..52ea7fe7fe09
>> --- /dev/null
>> +++ b/include/linux/property.h
>> @@ -0,0 +1,50 @@
>> +/*
>> + * property.h - Unified device property interface.
>> + *
>> + * Copyright (C) 2014, Intel Corporation
>> + * Author: Rafael J. Wysocki 
>> + *
>> + * 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 

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

[Stephen Rothwell]

Hi Greg,

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

drivers/staging/built-in.o:(.opd+0xaab8): multiple definition of 
`rtl88e_phy_rf_config'
drivers/net/built-in.o:(.opd+0x78840): first defined here
drivers/staging/built-in.o:(.opd+0xa9f8): multiple definition of 
`rtl88e_download_fw'
drivers/net/built-in.o:(.opd+0x781b0): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_rf_config':
(.text+0xe0a00): multiple definition of `.rtl88e_phy_rf_config'
drivers/net/built-in.o:(.text+0xe85a48): first defined here
drivers/staging/built-in.o: In function `.rtl88e_download_fw':
(.text+0xdf28c): multiple definition of `.rtl88e_download_fw'
drivers/net/built-in.o:(.text+0xe6f330): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_mac_config':
(.text+0xdf984): multiple definition of `.rtl88e_phy_mac_config'
drivers/net/built-in.o:(.text+0xe84a8c): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_bb_config':
(.text+0xdfa2c): multiple definition of `.rtl88e_phy_bb_config'
drivers/net/built-in.o:(.text+0xe84d14): first defined here
drivers/staging/built-in.o:(.opd+0xaa58): multiple definition of 
`rtl88e_phy_bb_config'
drivers/net/built-in.o:(.opd+0x78828): first defined here
drivers/staging/built-in.o:(.opd+0xaa28): multiple definition of 
`rtl88e_phy_mac_config'

Caused by commits d6c28c23f89b ("staging: rtl8188eu: Cleanup firmware
initialization code") and 586b60877244 ("staging: rtl8188eu: Cleanup
and simplify RF configuration code") and probably others.

I applied this fix up patch:

From: Stephen Rothwell 
Date: Mon, 18 Aug 2014 08:40:48 +1000
Subject: [PATCH] staging: rtl8188eu: using unique names is good

fixes:

drivers/staging/built-in.o:(.opd+0xaab8): multiple definition of 
`rtl88e_phy_rf_config'
drivers/net/built-in.o:(.opd+0x78840): first defined here
drivers/staging/built-in.o:(.opd+0xa9f8): multiple definition of 
`rtl88e_download_fw'
drivers/net/built-in.o:(.opd+0x781b0): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_rf_config':
(.text+0xe0a00): multiple definition of `.rtl88e_phy_rf_config'
drivers/net/built-in.o:(.text+0xe85a48): first defined here
drivers/staging/built-in.o: In function `.rtl88e_download_fw':
(.text+0xdf28c): multiple definition of `.rtl88e_download_fw'
drivers/net/built-in.o:(.text+0xe6f330): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_mac_config':
(.text+0xdf984): multiple definition of `.rtl88e_phy_mac_config'
drivers/net/built-in.o:(.text+0xe84a8c): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_bb_config':
(.text+0xdfa2c): multiple definition of `.rtl88e_phy_bb_config'
drivers/net/built-in.o:(.text+0xe84d14): first defined here
drivers/staging/built-in.o:(.opd+0xaa58): multiple definition of 
`rtl88e_phy_bb_config'
drivers/net/built-in.o:(.opd+0x78828): first defined here
drivers/staging/built-in.o:(.opd+0xaa28): multiple definition of 
`rtl88e_phy_mac_config'

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c  | 2 +-
 drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c | 2 +-
 drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c  | 2 +-
 drivers/staging/rtl8188eu/hal/fw.c| 2 +-
 drivers/staging/rtl8188eu/hal/usb_halinit.c   | 8 
 drivers/staging/rtl8188eu/include/fw.h| 2 +-
 drivers/staging/rtl8188eu/include/phy.h   | 6 +++---
 7 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c 
b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c
index 00f9cd737193..0c5dc26fd5a2 100644
--- a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c
+++ b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c
@@ -687,7 +687,7 @@ static bool config_parafile(struct adapter *adapt)
return true;
 }
 
-bool rtl88e_phy_bb_config(struct adapter *adapt)
+bool rtl88eu_phy_bb_config(struct adapter *adapt)
 {
int rtstatus = true;
struct hal_data_8188e   *hal_data = GET_HAL_DATA(adapt);
diff --git a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c 
b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c
index ccca6a496b2b..7d22dd1abaed 100644
--- a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c
+++ b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c
@@ -116,7 +116,7 @@ static u32 array_MAC_REG_8188E[] = {
0x70B, 0x0087,
 };
 
-bool rtl88e_phy_mac_config(struct adapter *adapt)
+bool rtl88eu_phy_mac_config(struct adapter *adapt)
 {
u32 i;
u32 arraylength;
diff --git a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c 
b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c
index 2648840f9e20..94ee740efd1f 100644
--- a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c
+++ b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c
@@ -312,7 +312,7 @@ static bool rtl88e_phy_rf6052_config(struct adapter *adapt)
return 

Re: [PATCH] headers: remove fs.h from poll.h

[David Rientjes]

On Sun, 17 Aug 2014, Alexey Dobriyan wrote:

> > Doors this actually help anything? fs.h tends to get included other ways
> > anyway, and the double inclusion protection means that the compiler doesn't
> > even spend extra time on it..
> > 
> > IOW, I'd like to see "this improves compile times by xyz" or some other
> > explanation.
> 
> This particular patch doesn't change situation because it is so small and
> removes only one header from one file.
> 
> I can send bigger patch removing fs.h from many possible places.
> 

I extensively build tested your series before and reported the single 
point of failure.  Once that's fixed and the patches have appropriate 
changelogs and signed-off-by lines then I can build test and push them for 
either Andrew or Linus.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] infiniband: hw: cxgb3: cxio_hal.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/infiniband/hw/cxgb3/cxio_hal.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c 
b/drivers/infiniband/hw/cxgb3/cxio_hal.c
index de1c61b4..5fc04e4 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
+++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
@@ -933,6 +933,7 @@ int cxio_rdev_open(struct cxio_rdev *rdev_p)
netdev_p = rdev_p->t3cdev_p->lldev;
strncpy(rdev_p->dev_name, rdev_p->t3cdev_p->name,
T3_MAX_DEV_NAME_LEN);
+   rdev_p->dev_name[T3_MAX_DEV_NAME_LEN - 1] = '\0';
} else {
PDBG("%s t3cdev_p or dev_name must be set\n", __func__);
return -EINVAL;
-- 
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/

linux-next: build failure after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (powerpc 
allyesconfig)
failed like this:

sound/soc/fsl/imx-pcm-fiq.c:31:21: fatal error: asm/fiq.h: No such file or 
directory
 #include 
 ^

Caused by commit 7e7292dba215 ("ASoC: fsl: add imx-es8328 machine
driver").  Presumably it will only build on arm?

I reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

[PATCH] usb: gadget: remove $(PWD) in ccflags-y

[Philippe Reynes]

The variable $(PWD) is useless, and it may break the compilation.
For example, it breaks the kernel compilation when it's done with
buildroot :

  /home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/bin/ccache
/home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
-Wp,-MD,drivers/usb/gadget/legacy/.hid.o.d  -nostdinc -isystem
/home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/include
-I./arch/arm/include -Iarch/arm/include/generated  -Iinclude
-I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi
-I./include/uapi -Iinclude/generated/uapi -include
./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp
-funwind-tables -marm -D__LINUX_ARM_ARCH__=5 -march=armv5te
-mtune=arm9tdmi -msoft-float -Uarm -fno-delete-null-pointer-checks -O2
--param=allow-store-data-races=0 -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer
-fno-var-tracking-assignments -g -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack
-Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO
-I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/
-I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/udc/
-I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/function/
-DMODULE  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hid)"
-D"KBUILD_MODNAME=KBUILD_STR(g_hid)" -c -o
drivers/usb/gadget/legacy/hid.o drivers/usb/gadget/legacy/hid.c
drivers/usb/gadget/epautoconf.c:23:26: erreur fatale: gadget_chips.h :
Aucun fichier ou dossier de ce type

This compilation line include :
/buildroot/driver/usb/gadget
but the real path is :
/buildroot/output/build/linux-3.17-rc1/driver/usb/gadget

Signed-off-by: Philippe Reynes 
---
 drivers/usb/gadget/Makefile  |2 +-
 drivers/usb/gadget/function/Makefile |4 ++--
 drivers/usb/gadget/legacy/Makefile   |6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index a186afe..9add915 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -3,7 +3,7 @@
 #
 subdir-ccflags-$(CONFIG_USB_GADGET_DEBUG)  := -DDEBUG
 subdir-ccflags-$(CONFIG_USB_GADGET_VERBOSE)+= -DVERBOSE_DEBUG
-ccflags-y  += -I$(PWD)/drivers/usb/gadget/udc
+ccflags-y  += -Idrivers/usb/gadget/udc
 
 obj-$(CONFIG_USB_LIBCOMPOSITE) += libcomposite.o
 libcomposite-y := usbstring.o config.o epautoconf.o
diff --git a/drivers/usb/gadget/function/Makefile 
b/drivers/usb/gadget/function/Makefile
index 6d91f21..83ae106 100644
--- a/drivers/usb/gadget/function/Makefile
+++ b/drivers/usb/gadget/function/Makefile
@@ -2,8 +2,8 @@
 # USB peripheral controller drivers
 #
 
-ccflags-y  := -I$(PWD)/drivers/usb/gadget/
-ccflags-y  += -I$(PWD)/drivers/usb/gadget/udc/
+ccflags-y  := -Idrivers/usb/gadget/
+ccflags-y  += -Idrivers/usb/gadget/udc/
 
 # USB Functions
 usb_f_acm-y:= f_acm.o
diff --git a/drivers/usb/gadget/legacy/Makefile 
b/drivers/usb/gadget/legacy/Makefile
index a11aad5..edba2d1 100644
--- a/drivers/usb/gadget/legacy/Makefile
+++ b/drivers/usb/gadget/legacy/Makefile
@@ -2,9 +2,9 @@
 # USB gadget drivers
 #
 
-ccflags-y  := -I$(PWD)/drivers/usb/gadget/
-ccflags-y  += -I$(PWD)/drivers/usb/gadget/udc/
-ccflags-y  += -I$(PWD)/drivers/usb/gadget/function/
+ccflags-y  := -Idrivers/usb/gadget/
+ccflags-y  += -Idrivers/usb/gadget/udc/
+ccflags-y  += -Idrivers/usb/gadget/function/
 
 g_zero-y   := zero.o
 g_audio-y  := audio.o
-- 
1.7.4.4

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

Re: [RESEND PATCH] Support Xbox One controllers in xpad driver.

[Dmitry Torokhov]

On Fri, Aug 08, 2014 at 10:46:09AM -0400, Ted Mielczarek wrote:
> Xbox One controllers require an initialization message to start sending data,
> so xpad_init_output becomes a required function. The Xbox One controller does
> not have LEDs like the Xbox 360 controller, so that functionality is not
> implemented. The format of messages controlling rumble is currently
> undocumented, so rumble support is not yet implemented.
> 
> The only thing I'm not certain about in this patch is the check against 
> bInterfaceNumber in xpad_probe. The Xbox One controller advertises three 
> interfaces with the same interface class, subclass and protocol, and I 
> couldn't see any way to match just the first one using usb_device_id.
> 
> Signed-off-by: Ted Mielczarek 

Applied, thank you.

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

[PATCH 1/1] ath6kl: fix %d confusingly prefixed with 0x in format strings

[Hans Wennborg]

Signed-off-by: Hans Wennborg 
---
 drivers/net/wireless/ath/ath6kl/init.c | 2 +-
 drivers/net/wireless/ath/ath6kl/main.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/init.c 
b/drivers/net/wireless/ath/ath6kl/init.c
index fffd523..6e473fa 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -1049,7 +1049,7 @@ static int ath6kl_fetch_fw_apin(struct ath6kl *ar, const 
char *name)
ar->hw.reserved_ram_size = le32_to_cpup(val);
 
ath6kl_dbg(ATH6KL_DBG_BOOT,
-  "found reserved ram size ie 0x%d\n",
+  "found reserved ram size ie %d\n",
   ar->hw.reserved_ram_size);
break;
case ATH6KL_FW_IE_CAPABILITIES:
diff --git a/drivers/net/wireless/ath/ath6kl/main.c 
b/drivers/net/wireless/ath/ath6kl/main.c
index 21516bc..933aef0 100644
--- a/drivers/net/wireless/ath/ath6kl/main.c
+++ b/drivers/net/wireless/ath/ath6kl/main.c
@@ -225,7 +225,7 @@ int ath6kl_diag_write32(struct ath6kl *ar, u32 address, 
__le32 value)
ret = ath6kl_hif_diag_write32(ar, address, value);
 
if (ret) {
-   ath6kl_err("failed to write 0x%x during diagnose window to 
0x%d\n",
+   ath6kl_err("failed to write 0x%x during diagnose window to 
0x%x\n",
   address, value);
return ret;
}
-- 
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/

Re: Oops: 17 SMP ARM (v3.16-rc2)

[Fabio Estevam]

Iain,

On Sun, Aug 17, 2014 at 6:34 PM, Iain Paton  wrote:
> On 15/08/14 06:42, Mattis Lorentzon wrote:
>
>> We mostly run SSH with benchmarks using NFS, it can probably be
>> triggered by using only SSH with the following loop:
>>
>> # while : ; do ssh arm-card date; done
>
> Mattis,
>
> What sort of time does it take for you to see a problem?
>
> I've been running the above for nearly two days on 3.16.0 on a board
> with fec interrupts routed through gpio_6 and haven't seen a hint of
> a problem.

Thanks for testing.

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

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

[Russell King - ARM Linux]

On Sun, Aug 17, 2014 at 03:04:34PM -0400, Jason Cooper wrote:
> Quoting Nico:
> 
> "Of course it would be good to clarify things wrt Russell's remark
> independently from this patch."
> 
> I took 'independently' to mean "This patch is ok, *and* we need to
> address Russell's concerns in a follow-up patch."
> 
> Nico's Reviewed-by with that comment was sent August 13th.  The most
> recent activity on this thread was also August 13th.  After four days, I
> reasoned there were no objections to his comment.

Right, during the merge window, and during merge windows, I tend to
ignore almost all email now because people don't stop developing, and
they don't take any notice where the mainline cycle is.  In fact, I go
off and do non-kernel work during a merge window and only briefly scan
for bug fixes.

However, I have other concerns with this patch, which I've yet to air.
For example, I don't like this crappy conditional locking that people
keep dreaming up - that kind of stuff makes the kernel much harder to
statically check that everything is correct.  It's an anti-lockdep
strategy.

Secondly, I don't like this:

+   raw_spin_lock(_sgi_lock);
+   /*
+* Ensure that the gic_cpu_map update above is seen in
+* gic_raise_softirq() before we redirect any pending SGIs that
+* may have been raised for the outgoing CPU (cur_cpu_id)
+*/
+   smp_mb__after_unlock_lock();
+   raw_spin_unlock(_sgi_lock);

That goes against the principle of locking, that you lock the data,
not the code.

I have no problem with changing gic_raise_softirq() to use a different
lock, which gic_migrate_target(), and gic_set_affinity() can also use.
There's no need for horrid locking here, because the only thing we're
protecting is gic_map[] and the write to the register to trigger an
IPI - and nothing using gic_arch_extn has any business knowing about
SGIs.

No need for these crappy sgi_map_lock() macros and all the ifdeffery.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.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/

Re: Oops: 17 SMP ARM (v3.16-rc2)

[Iain Paton]

On 15/08/14 06:42, Mattis Lorentzon wrote:

> We mostly run SSH with benchmarks using NFS, it can probably be
> triggered by using only SSH with the following loop:
> 
> # while : ; do ssh arm-card date; done

Mattis,

What sort of time does it take for you to see a problem?

I've been running the above for nearly two days on 3.16.0 on a board 
with fec interrupts routed through gpio_6 and haven't seen a hint of 
a problem.

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

Re: [PATCH 0/2] sched: tasklist_lock cleanups (Was: don't use while_each_thread())

[Kirill Tkhai]

On 17.08.2014 19:25, Oleg Nesterov wrote:
> On 08/13, Oleg Nesterov wrote:
>>
>> Peter, could you take these simple patches ?
>>
>> Better later than never... per-file, but please feel free to join
>> them in a single patch.
>>
>> read_lock_irq*(tasklist_lock) in kernel/sched/ files looks strange.
>> Why? I'll recheck, but this looks unneeded.
> 
> Yes, please consider these minor cleanups on top of for_each_thread
> conversions.
> 
> read_lock_irq(tasklist) in normalize_rt_tasks() doesn't really hurt,
> but it looks confusing. If we really have a reason to disable irqs
> this (subtle) reason should be documented.
> 
> And I can't understand tg_has_rt_tasks(). Don't we need something
> like the patch below? If not, please do not ask me why I think so,
> I don't understand this black magic ;) But the usage of the global
> "runqueues" array looks suspicious.

This function searches RT task which is related to this tg. It's
opaquely because it looks that there is an error.

task_rq(p)->rt.tg is a task group of a top rt_rq, while the task may
be queued on a child rt_rq instead of this. So, your patch is a BUGFIX,
not a cleanup.

> --- x/kernel/sched/core.c
> +++ x/kernel/sched/core.c
> @@ -7354,7 +7354,7 @@ static inline int tg_has_rt_tasks(struct
>   struct task_struct *g, *p;
>  
>   for_each_process_thread(g, p) {
> - if (rt_task(p) && task_rq(p)->rt.tg == tg)
> + if (rt_task(p) && task_group(p) == tg)
>   return 1;
>   }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Build regressions/improvements in v3.17-rc1

[Geert Uytterhoeven]

On Sun, Aug 17, 2014 at 10:45 PM, Geert Uytterhoeven
 wrote:
> 16 regressions:
>   + /scratch/kisskb/src/arch/powerpc/include/asm/floppy.h: error: 
> 'isa_bridge_pcidev' undeclared (first use in this function):  => 142:20

powerpc-randconfig

>   + /scratch/kisskb/src/fs/hostfs/hostfs_user.c: error: 'AT_FDCWD' undeclared 
> (first use in this function):  => 378
>   + /scratch/kisskb/src/fs/hostfs/hostfs_user.c: error: (Each undeclared 
> identifier is reported only once:  => 378
>   + /scratch/kisskb/src/fs/hostfs/hostfs_user.c: error: for each function it 
> appears in.):  => 378

um-defconfig

>   + /scratch/kisskb/src/kernel/locking/mcs_spinlock.h: error: implicit 
> declaration of function 'cpu_relax_lowlatency' 
> [-Werror=implicit-function-declaration]:  => 87:2

frv-defconfig (somehow the fix never made it past Linus' mbox)

>   + error: "flush_icache_range" [drivers/misc/lkdtm.ko] undefined!:  => N/A

sh-allmodconfig (woohoo, this means it has reached the link phase!)

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Build regressions/improvements in v3.17-rc1

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v3.17-rc1[1] compared to v3.16[2].

Summarized:
  - build errors: +16/-14
  - build warnings: +150/-77

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

Happy fixing! ;-)

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

[1] http://kisskb.ellerman.id.au/kisskb/head/7787/ (all 119 configs)
[2] http://kisskb.ellerman.id.au/kisskb/head/7732/ (all 119 configs)


*** ERRORS ***

16 regressions:
  + /scratch/kisskb/src/arch/powerpc/include/asm/floppy.h: error: 
'isa_bridge_pcidev' undeclared (first use in this function):  => 142:20
  + /scratch/kisskb/src/fs/hostfs/hostfs_user.c: error: 'AT_FDCWD' undeclared 
(first use in this function):  => 378
  + /scratch/kisskb/src/fs/hostfs/hostfs_user.c: error: (Each undeclared 
identifier is reported only once:  => 378
  + /scratch/kisskb/src/fs/hostfs/hostfs_user.c: error: for each function it 
appears in.):  => 378
  + /scratch/kisskb/src/kernel/locking/mcs_spinlock.h: error: implicit 
declaration of function 'cpu_relax_lowlatency' 
[-Werror=implicit-function-declaration]:  => 87:2
  + error: "flush_icache_range" [drivers/misc/lkdtm.ko] undefined!:  => N/A
  + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.__dev_kfree_skb_irq' defined in .text section in net/built-in.o:  => 
(.text+0x1ff9c54)
  + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.add_timer' defined in .text section in kernel/built-in.o:  => 
(.text+0x1ff9e54)
  + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.alloc_etherdev_mqs' defined in .text section in net/built-in.o:  => 
(.text+0x1ffa260)
  + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.debug_dma_sync_single_for_device' defined in .text section in lib/built-in.o: 
 => (.text+0x1ff94f8)
  + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.memcpy' defined in .text section in arch/powerpc/lib/built-in.o:  => 
(.text+0x1ff9420)
  + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.netif_rx' defined in .text section in net/built-in.o:  => (.text+0x1ff965c)
  + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.pci_iounmap' defined in .text section in lib/built-in.o:  => (.text+0x1ffabfc)
  + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.register_netdev' defined in .text section in net/built-in.o:  => 
(.text+0x1ffa9a8)
  + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`_restgpr0_14' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ffac4c)
  + error: natsemi.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`_restgpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ffad34)

14 improvements:
  - /scratch/kisskb/src/drivers/net/wireless/libertas/if_cs.c: error: implicit 
declaration of function 'ioport_map' [-Werror=implicit-function-declaration]: 
878:2 => 
  - /scratch/kisskb/src/drivers/net/wireless/libertas/if_cs.c: error: implicit 
declaration of function 'ioport_unmap' [-Werror=implicit-function-declaration]: 
826:3 => 
  - /scratch/kisskb/src/drivers/net/wireless/orinoco/orinoco_cs.c: error: 
implicit declaration of function 'ioport_map' 
[-Werror=implicit-function-declaration]: 153:2 => 
  - /scratch/kisskb/src/drivers/net/wireless/orinoco/orinoco_cs.c: error: 
implicit declaration of function 'ioport_unmap' 
[-Werror=implicit-function-declaration]: 205:3 => 
  - /scratch/kisskb/src/drivers/net/wireless/orinoco/spectrum_cs.c: error: 
implicit declaration of function 'ioport_map' 
[-Werror=implicit-function-declaration]: 216:2 => 
  - /scratch/kisskb/src/drivers/net/wireless/orinoco/spectrum_cs.c: error: 
implicit declaration of function 'ioport_unmap' 
[-Werror=implicit-function-declaration]: 273:3 => 
  - error: stmmac_hwtstamp.c: relocation truncated to fit: R_PPC64_REL24 
against symbol `_restgpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ff9580), (.text+0x1ff9944) => 
  - error: stmmac_hwtstamp.c: relocation truncated to fit: R_PPC64_REL24 
against symbol `_savegpr0_26' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ff994c), (.text+0x1ff9d4c), 
(.text+0x1ffa0bc) => 
  - error: stmmac_ptp.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `._raw_spin_lock_irqsave' defined in .spinlock.text section in 
kernel/built-in.o: (.text+0x1ffa5d8), (.text+0x1ffa520) => 
  - error: stmmac_ptp.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_restgpr0_27' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ffa59c) => 
  - error: stmmac_ptp.c: relocation truncated to fit: R_PPC64_REL24 against 

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

[Stephen Rothwell]

Hi all,

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

drivers/regulator/mc13892-regulator.c: In function 'mc13892_regulator_probe':
drivers/regulator/mc13892-regulator.c:586:3: error: assignment of member 
'set_mode' in read-only object
   = mc13892_vcam_set_mode;
   ^
drivers/regulator/mc13892-regulator.c:588:3: error: assignment of member 
'get_mode' in read-only object
   = mc13892_vcam_get_mode;
   ^

Caused by commit 272e2315fac3 ("regulator: core: add const qualifier to
ops in struct regulator_desc").

I have used the regulator tree from next-20140815 for today.

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


signature.asc
Description: PGP signature

Re: [PATCH v7] 8250-core based serial driver for OMAP + DMA

[Sebastian Andrzej Siewior]

* Tony Lindgren | 2014-08-15 13:28:27 [-0700]:

>> It configured the trigger levels to 1 for RX and 16 for TX.
>
>Hmm that weird RX trigger level is a workaround for lost characters.
>
>See commit 0ba5f66836 (tty: serial: OMAP: use a 1-byte RX FIFO
>threshold in PIO mode :)
>
>There's paste test in that commit, I wonder if the 8250 drivers
>can deal with it any better?

I recall that I used it as a console and didn't see any missing chars.
I will try test but I am traveling this week…

>Regards,
>
>Tony

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv5 1/2] pwm: Add Allwinner SoC support

[jonsm...@gmail.com]

New version that adds better support for the A10 plus it fixes an
issue in the previous version.

Note that the A10 does not support the 24Mhz bypass mode.

-- 
Jon Smirl
jonsm...@gmail.com


pwm
Description: Binary data

[PATCH 3/5] staging: vt6655: remove PLICE_DEBUG where it is defined

[Malcolm Priestley]

Remove macro and directive leaving the code.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/rxtx.c |  4 +---
 drivers/staging/vt6655/wmgr.c | 12 
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index 869555a..635e88c 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -68,7 +68,6 @@
 /*-  Static Classes  */
 
 /*-  Static Variables  --*/
-#definePLICE_DEBUG
 
 /*-  Static Functions  --*/
 
@@ -1969,9 +1968,8 @@ vGenerateFIFOHeader(struct vnt_private *pDevice, unsigned 
char byPktType,
}
}
 
-#ifdef PLICE_DEBUG
RFbSetPower(pDevice, pDevice->wCurrentRate, pDevice->byCurrentCh);
-#endif
+
pTxBufHead->byTxPower = pDevice->byCurPwr;
 
*pcbHeaderSize = s_cbFillTxBufHead(pDevice, byPktType, pbyTxBufferAddr, 
cbPayloadSize,
diff --git a/drivers/staging/vt6655/wmgr.c b/drivers/staging/vt6655/wmgr.c
index c998a16..c3de107 100644
--- a/drivers/staging/vt6655/wmgr.c
+++ b/drivers/staging/vt6655/wmgr.c
@@ -80,8 +80,6 @@
 #include "rf.h"
 #include "iowpa.h"
 
-#definePLICE_DEBUG
-
 /*-  Static Definitions -*/
 
 /*-  Static Classes  */
@@ -692,9 +690,9 @@ s_vMgrRxAssocRequest(
// set max tx rate
pMgmt->sNodeDBTable[uNodeIndex].wTxDataRate =
pMgmt->sNodeDBTable[uNodeIndex].wMaxSuppRate;
-#ifdef PLICE_DEBUG
+
pr_debug("RxAssocRequest:wTxDataRate is %d\n", 
pMgmt->sNodeDBTable[uNodeIndex].wTxDataRate);
-#endif
+
// Todo: check sta preamble, if ap can't support, set status 
code
pMgmt->sNodeDBTable[uNodeIndex].bShortPreamble =
WLAN_GET_CAP_INFO_SHORTPREAMBLE(*sFrame.pwCapInfo);
@@ -840,9 +838,9 @@ s_vMgrRxReAssocRequest(
// set max tx rate
pMgmt->sNodeDBTable[uNodeIndex].wTxDataRate =
pMgmt->sNodeDBTable[uNodeIndex].wMaxSuppRate;
-#ifdef PLICE_DEBUG
+
pr_debug("RxReAssocRequest:TxDataRate is %d\n", 
pMgmt->sNodeDBTable[uNodeIndex].wTxDataRate);
-#endif
+
// Todo: check sta preamble, if ap can't support, set status 
code
pMgmt->sNodeDBTable[uNodeIndex].bShortPreamble =
WLAN_GET_CAP_INFO_SHORTPREAMBLE(*sFrame.pwCapInfo);
@@ -2097,11 +2095,9 @@ s_vMgrRxBeacon(

memcpy(pMgmt->sNodeDBTable[uNodeIndex].abyMACAddr, sFrame.pHdr->sA3.abyAddr2, 
WLAN_ADDR_LEN);
pMgmt->sNodeDBTable[uNodeIndex].bShortPreamble 
= WLAN_GET_CAP_INFO_SHORTPREAMBLE(*sFrame.pwCapInfo);
pMgmt->sNodeDBTable[uNodeIndex].wTxDataRate = 
pMgmt->sNodeDBTable[uNodeIndex].wMaxSuppRate;
-#ifdef PLICE_DEBUG
{
pr_debug("s_vMgrRxBeacon:TxDataRate is 
%d,Index is %d\n", pMgmt->sNodeDBTable[uNodeIndex].wTxDataRate, uNodeIndex);
}
-#endif
}
 
// if other stations joined, indicate connection to 
upper layer..
-- 
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 1/5] staging: vt6655: Use ether_crc in kernel.

[Malcolm Priestley]

ether_crc is already in kernel remove local code and
include linux/crc32.h

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/device.h  |  1 +
 drivers/staging/vt6655/device_main.c | 17 -
 2 files changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/staging/vt6655/device.h b/drivers/staging/vt6655/device.h
index e4c5292..fadebe9 100644
--- a/drivers/staging/vt6655/device.h
+++ b/drivers/staging/vt6655/device.h
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 //#include 
 #include 
 #include 
diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index a44233c..95460d4 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -2561,23 +2561,6 @@ static  irqreturn_t  device_intr(int irq,  void 
*dev_instance)
return IRQ_RETVAL(handled);
 }
 
-static unsigned const ethernet_polynomial = 0x04c11db7U;
-static inline u32 ether_crc(int length, unsigned char *data)
-{
-   int crc = -1;
-
-   while (--length >= 0) {
-   unsigned char current_octet = *data++;
-   int bit;
-
-   for (bit = 0; bit < 8; bit++, current_octet >>= 1) {
-   crc = (crc << 1) ^
-   ((crc < 0) ^ (current_octet & 1) ? 
ethernet_polynomial : 0);
-   }
-   }
-   return crc;
-}
-
 //2008-8-4  by chester
 static int Config_FileGetParameter(unsigned char *string,
   unsigned char *dest, unsigned char *source)
-- 
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/5] staging: vt6655: main_usb.c remove undefined PLICE_DEBUG code.

[Malcolm Priestley]

PLICE_DEBUG is not defined in any header for this file.

Remove code, references and directives.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/device_main.c | 40 
 1 file changed, 40 deletions(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 95460d4..3a2fd29 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -389,10 +389,7 @@ device_set_options(struct vnt_private *pDevice)
pDevice->bFixRate = true;
pDevice->byBBType = pDevice->sOpts.bbp_type;
pDevice->byPacketType = pDevice->byBBType;
-
-//PLICE_DEBUG->
pDevice->byAutoFBCtrl = AUTO_FB_0;
-//PLICE_DEBUG<-
pDevice->bUpdateBBVGA = true;
pDevice->byFOETuning = 0;
pDevice->wCTSDuration = 0;
@@ -933,15 +930,6 @@ vt6655_probe(struct pci_dev *pcid, const struct 
pci_device_id *ent)
}
 
dev->base_addr = pDevice->ioaddr;
-#ifdef PLICE_DEBUG
-   unsigned char value;
-
-   VNSvInPortB(pDevice->PortOffset+0x4F, );
-   pr_debug("Before write: value is %x\n", value);
-   VNSvOutPortB(pDevice->PortOffset, value);
-   VNSvInPortB(pDevice->PortOffset+0x4F, );
-   pr_debug("After write: value is %x\n", value);
-#endif
// do reset
if (!MACbSoftwareReset(pDevice->PortOffset)) {
pr_err(DEVICE_NAME ": Failed to access MAC hardware..\n");
@@ -1021,14 +1009,6 @@ static bool device_get_pci_info(struct vnt_private 
*pDevice,
u16 pci_cmd;
u8  b;
unsigned int cis_addr;
-#ifdef PLICE_DEBUG
-   unsigned char pci_config[256];
-   unsigned char value = 0x00;
-   int ii, j;
-   u16 max_lat = 0x;
-
-   memset(pci_config, 0x00, 256);
-#endif
 
pci_read_config_byte(pcid, PCI_REVISION_ID, >byRevId);
pci_read_config_word(pcid, PCI_SUBSYSTEM_ID, >SubSystemID);
@@ -1047,20 +1027,6 @@ static bool device_get_pci_info(struct vnt_private 
*pDevice,
pci_read_config_byte(pcid, PCI_COMMAND, );
pci_write_config_byte(pcid, PCI_COMMAND, (b|PCI_COMMAND_MASTER));
 
-#ifdef PLICE_DEBUG
-   for (ii = 0; ii < 0xFF; ii++) {
-   pci_read_config_byte(pcid, ii, );
-   pci_config[ii] = value;
-   }
-   for (ii = 0, j = 1; ii < 0x100; ii++, j++) {
-   if (j % 16 == 0) {
-   pr_debug("%x:", pci_config[ii]);
-   pr_debug("\n");
-   } else {
-   pr_debug("%x:", pci_config[ii]);
-   }
-   }
-#endif
return true;
 }
 
@@ -1720,8 +1686,6 @@ static int  device_close(struct net_device *dev)
 {
struct vnt_private *pDevice = netdev_priv(dev);
PSMgmtObject pMgmt = pDevice->pMgmt;
-   //PLICE_DEBUG->
-//PLICE_DEBUG<-
 //2007-1121-02by EinsnLiu
if (pDevice->bLinkPass) {
bScheduleCommand((void *)pDevice, WLAN_CMD_DISASSOCIATE, NULL);
@@ -2111,10 +2075,6 @@ static int  device_xmit(struct sk_buff *skb, struct 
net_device *dev) {
byPktType = (unsigned char)pDevice->byPacketType;
 
if (pDevice->bFixRate) {
-#ifdef PLICE_DEBUG
-   pr_debug("Fix Rate: PhyType is %d,ConnectionRate is %d\n", 
pDevice->eCurrentPHYType, pDevice->uConnectionRate);
-#endif
-
if (pDevice->eCurrentPHYType == PHY_TYPE_11B) {
if (pDevice->uConnectionRate >= RATE_11M)
pDevice->wCurrentRate = RATE_11M;
-- 
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 5/5] staging: vt6655: remove remaining comments of PLICE_DEBUG

[Malcolm Priestley]

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/device.h | 4 
 drivers/staging/vt6655/dpc.c| 7 +++
 2 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/vt6655/device.h b/drivers/staging/vt6655/device.h
index fadebe9..1abad5d 100644
--- a/drivers/staging/vt6655/device.h
+++ b/drivers/staging/vt6655/device.h
@@ -141,9 +141,7 @@
 
 #defineAVAIL_TD(p, q)  ((p)->sOpts.nTxDescs[(q)] - ((p)->iTDUsed[(q)]))
 
-//PLICE_DEBUG ->
 #defineNUM 64
-//PLICE_DEUBG <-
 
 #define PRIVATE_Message 0
 
@@ -404,11 +402,9 @@ struct vnt_private {
 
spinlock_t  lock;
 
-//PLICE_DEBUG ->
pid_t   MLMEThr_pid;
struct completion   notify;
struct semaphoremlme_semaphore;
-//PLICE_DEBUG <-
 
u32 rx_bytes;
 
diff --git a/drivers/staging/vt6655/dpc.c b/drivers/staging/vt6655/dpc.c
index 7589cb4..60eb129 100644
--- a/drivers/staging/vt6655/dpc.c
+++ b/drivers/staging/vt6655/dpc.c
@@ -312,10 +312,9 @@ device_receive_frame(
 
skb = pRDInfo->skb;
 
-//PLICE_DEBUG->
pci_unmap_single(pDevice->pcid, pRDInfo->skb_dma,
 pDevice->rx_buf_sz, PCI_DMA_FROMDEVICE);
-//PLICE_DEBUG<-
+
pwFrameSize = (unsigned short *)(skb->data + 2);
FrameSize = cpu_to_le16(pCurrRD->m_rd1RD1.wReqCount) - 
cpu_to_le16(pCurrRD->m_rd0RD0.wResCount);
 
@@ -344,7 +343,7 @@ device_receive_frame(
pr_debug("-- WRONG Length 2\n");
return false;
}
-//PLICE_DEBUG->
+
// update receive statistic counter
STAvUpdateRDStatCounter(>scStatistic,
*pbyRsr,
@@ -354,7 +353,7 @@ device_receive_frame(
FrameSize);
 
pMACHeader = (PS802_11Header)((unsigned char *)(skb->data) + 8);
-//PLICE_DEBUG<-
+
if (pDevice->bMeasureInProgress) {
if ((*pbyRsr & RSR_CRCOK) != 0)
pDevice->byBasicMap |= 0x01;
-- 
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/