Re: [PATCH] dmatest: masking tests for channel capabilities

[Andy Shevchenko]

On Tue, Jun 18, 2013 at 12:12 AM, Dan Williams  wrote:
> On Mon, Jun 17, 2013 at 2:10 PM, Dan Williams  wrote:
>>> +Example to perform only MEMCPY and PQ mode tests (0x01 | 0x04 = 0x05):
>>> +
>>> +% modprobe dmatest
>>> +% echo dma0chan0 > /sys/kernel/debug/dmatest/channel
>>> +% echo 5  > /sys/kernel/debug/dmatest/cap_mask
>>> +% echo 1 > /sys/kernel/debug/dmatest/iterations
>>> +% echo 1 > /sys/kernel/debug/dmatest/run
>>
>>
>> Hmmm, I should have paid more attention when the debugfs support was
>> initially proposed for dmatest.  As it is I see duplication and
>> configuration parameters getting out of sync with their module parameter
>> equivalents versus just having all configuration go through module
>> parameters.  module_param_call() can be used for the more complex options.
>> Debugfs at this point looks like overkill for what amounts to some simple
>> configuration variables and a result line.

There two main issues we fight against:
 - test automation, where we can collect results and use them later
 - annoying modprobe / modprobe -r for each test case

The module parameters were left to support old behaviour of the module.

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

Re: [PATCH] usb: host: Faraday fotg210-hcd driver

[Yuan-Hsin Chen]

Hi,

On Tue, Jun 18, 2013 at 11:07 AM, Sarah Sharp
 wrote:
> On Tue, Jun 18, 2013 at 10:42:09AM +0800, Yuan-Hsin Chen wrote:
>> Hi,
>>
>> On Tue, Jun 18, 2013 at 4:39 AM, Greg KH  wrote:
>> > On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote:
>> >> FOTG210 is an OTG controller which can be configured as an
>> >> USB2.0 host. FOTG210 host is an ehci-like controller with
>> >> some differences. First, register layout of FOTG210 is
>> >> incompatible with EHCI. Furthermore, FOTG210 is lack of
>> >> siTDs which means iTDs are used for both HS and FS ISO
>> >> transfer.
>> >>
>> >> Signed-off-by: Yuan-Hsin Chen 
>> >> ---
>> >>  drivers/usb/Makefile   |1 +
>> >>  drivers/usb/host/Kconfig   |   12 +
>> >>  drivers/usb/host/Makefile  |1 +
>> >>  drivers/usb/host/fotg210-hcd.c | 5967 
>> >> 
>> >>  drivers/usb/host/fotg210.h |  746 +
>> >>  5 files changed, 6727 insertions(+), 0 deletions(-)
>> >>  create mode 100644 drivers/usb/host/fotg210-hcd.c
>> >>  create mode 100644 drivers/usb/host/fotg210.h
>> >
>> > You obviously didn't even run this through checkpatch.pl, did you?
>> >
>> > $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1
>> > total: 138 errors, 618 warnings, 6742 lines checked
>> >
>> > Please fix all of these if you wish us to at least start reviewing the
>> > patch.  Your internal Q/A should have caught this first, please be more
>> > careful in the future.
>> >
>>
>> Actually I did run checkpatch.pl and found that almost all errors and
>> warnings are from ehci core (ehci-hcd.c, ehci-hub.c and so on) where
>> my driver borrowed most of code.
>>
>> $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hub.c | tail -n 1
>> total: 18 errors, 69 warnings, 1138 lines checked
>>
>> $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hcd.c | tail -n 1
>> total: 17 errors, 78 warnings, 1403 lines checked
>>
>> So you're saying that I should fix them, is that right?
>
> In that case, no, you should be figuring out how to refactor and reuse
> the EHCI code instead of copying it straight into your driver.

I was trying to use ehci-platform.c, anonymous union/struct, and quirk
flags to avoid copying EHCI code.
But there are too big incompatibilities between fotg210/fusbh200
controller and EHCI.
That's why Alan agreed that I could create a stand-alone driver for
fusbh200 host controller.
Since fotg210 and fusbh200 have the same issue,  fotg210 hcd is
supposed to be stand-alone.
More details please refer to mail sequence
http://www.spinics.net/lists/linux-usb/msg83812.html

Thanks,

Yuan-Hsin

>
> Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tcp: Modify the condition for the first skb to collapse

[Eric Dumazet]

On Tue, 2013-06-18 at 05:52 -0400, Jun Chen wrote:
> > 
> There are many warning for tcp_recvmsg before this crash. I can't find
> other memory warning in the logs, but I'm not sure whether there are
> memory issues because of the length limitation of saved logs. I think
> this logs will give you more information.
> 
> <4>[ 7736.343742] [ cut here ]
> 
> <4>[ 7736.343759] WARNING:
> at /data/buildbot/workdir/jb/kernel/net/ipv4/tcp.c:1496 tcp_recvmsg
> +0x3bf/0x910()
> 
> <4>[ 7736.343775] recvmsg bug: copied AB57C870 seq AB57CD95 rcvnxt
> AB57F19F fl 0
> 
> <4>[ 7736.343845] Call Trace:
> 
> <4>[ 7736.343865]  [] warn_slowpath_common+0x72/0xa0
> 
> <4>[ 7736.343888]  [] ? tcp_recvmsg+0x3bf/0x910
> 
> <4>[ 7736.343902]  [] ? tcp_recvmsg+0x3bf/0x910
> 
> <4>[ 7736.343922]  [] warn_slowpath_fmt+0x33/0x40
> 
> <4>[ 7736.343944]  [] tcp_recvmsg+0x3bf/0x910
> 
> <4>[ 7736.343968]  [] inet_recvmsg+0x85/0xa0
> 
> <4>[ 7736.343992]  [] sock_aio_read+0x140/0x160
> 
> <4>[ 7736.344016]  [] ? set_next_entity+0xc1/0xf0
> 
> <4>[ 7736.344039]  [] do_sync_read+0xb7/0xf0
> 
> <4>[ 7736.344064]  [] ? rw_verify_area+0x6c/0x120
> 
> <4>[ 7736.344077]  [] ? sys_epoll_wait+0x68/0x360
> 
> <4>[ 7736.344098]  [] vfs_read+0x149/0x160
> 
> <4>[ 7736.344120]  [] ? fget_light+0x58/0xd0
> 
> <4>[ 7736.344142]  [] sys_read+0x3d/0x70
> 
> <4>[ 7736.344164]  [] syscall_call+0x7/0xb
> 
> <4>[ 7736.344187]  [] ? perf_cpu_notify+0x45/0x89
> 
> <4>[ 7736.344205] ---[ end trace b3c5b245ce7ff5b5 ]---
> 

Thats exactly the interesting stuff ;)

This was fixed, or should be fixed if still happening on more recent
kernels.

Basically, once we are in this state, there is nothing we can do to
prevent a crash.

Please try to reproduce the issue using 3.9 or David trees (net-next or
net )

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 v10 0/8] DMA Engine support for AM33XX

[Sekhar Nori]

Joel,

When you respin this, please base on top of Prabhakar's clean-up titled:
"ARM: edma: Convert to devm_* api".

Or better still, include his patch in your series.

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

Re: [PATCH RESEND v5] fat: editions to support fat_fallocate

[Namjae Jeon]

Hi, OGAWA.

We checked several cases with respect to your questions. But we cannot
find any issue.
Also, We compare the results with Ext4. It is same.
>cluster size == 512b

>1) create new file
>2) fallocate 100MB
>3) write(2) data for each 512b

>With this, write_begin() will be called for each 512b data. When we
>allocates new page for this file, write_begin() writes data 0-512. Then,
>we have to initialize 512-4096 by zero. Because mmap read maps 0-4096,
>even if i_size == 512.

>Who is initializing area for 512-4096?
When we checked, we found that page which is allocated to mmap is
already filled with zeros. And 512byte is filled in this page. If we
try to read mmap beyond the file size of 512 bytes , nulls are
returned . Hence , mmap works correctly in such cases .

>From other view, I guess fat_zero_falloc_area() is for filling zero for
>0-1, in the following case?

> 1) create new file
> 2) lseek(1)
> 3) write data by write(2)

>This job is for cont_write_begin(). If example is correct, why
>cont_write_begin() doesn't work? I guess, because get_block() doesn't
>set buffer_new() for those area.
If we will not call fallocate with keep size flags, cont_write_begin
will work and zero out on lseek area (this works like expanding
truncate).

>If above is correct, right implement to change get_block().
Now when we try to write in the fallocated region ( with keep size) in
the fat_write_begin when it is called first time it checks that the
mismatch is present between the mmu_private and mmu_actual , and hence
zero out the region ; since buffer_new is not set for fallocated
region by fat_get_block , we explicitly zero out the lseeked region
using “fat_zero_falloc_area” and normal write occurs beyond that , and
i_size is updated accordingly , and as such there is no need to move
the code to fat_get_block .
>I'm ok as start if it works.
>
>But from this discussion, discard at last close(2) doesn't look like
>working for your requirement. Since you want to discard at last close of
>inode, so, rather, I guess you actually want to discard at last
>dereference of inode.
We also moved the release of fallocated clusters from the
“fat_file_release” to “fat_evict_inode” and on the basis of i_count so
that the fallocated clusters are released at the last reference of the
inode.

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/

linux-next: manual merge of the irqdomain tree with the tree

[Stephen Rothwell]

Hi Grant,

Today's linux-next merge of the irqdomain tree got a conflict in
kernel/irq/irqdomain.c between commit c5cdc67a58a2 ("irqdomain: Remove
temporary MIPS workaround code") from the mips tree and commit
bd4641e31e90 ("irq: fix checkpatch error") from the irqdomain tree.

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

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

diff --cc kernel/irq/irqdomain.c
index a341b3d,13f2654..000
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@@ -665,8 -475,20 +475,8 @@@ unsigned int irq_create_of_mapping(stru
  
domain = controller ? irq_find_host(controller) : irq_default_domain;
if (!domain) {
-   pr_warning("no irq domain found for %s !\n",
-  of_node_full_name(controller));
 -#ifdef CONFIG_MIPS
 -  /*
 -   * Workaround to avoid breaking interrupt controller drivers
 -   * that don't yet register an irq_domain.  This is temporary
 -   * code. ~~~gcl, Feb 24, 2012
 -   *
 -   * Scheduled for removal in Linux v3.6.  That should be enough
 -   * time.
 -   */
 -  if (intsize > 0)
 -  return intspec[0];
 -#endif
+   pr_warn("no irq domain found for %s !\n",
+   of_node_full_name(controller));
return 0;
}
  


pgpwDUecySNMf.pgp
Description: PGP signature

Re: [Part1 PATCH v5 00/22] x86, ACPI, numa: Parse numa info earlier

[Tang Chen]

Hi tj,

On 06/18/2013 10:03 AM, Tejun Heo wrote:
..


So, can you please explain why you're doing the above?  What are you
trying to achieve in the end and why is this the best approach?  This
is all for memory hotplug, right?


Yes, this is all for memory hotplug.

[why]
At early boot time (before parsing SRAT), memblock will allocate memory
for kernel to use. But the memory could be hotpluggable memory because
at such an early time, we don't know which memory is hotpluggable. This
will cause hotpluggable memory un-hotpluggable. What we are trying to
do is to prevent memblock from allocating hotpluggable memory.

[approach]
Parse SRAT earlier before memblock starts to work, because there is a
bit in SRAT specifying which memory is hotpluggable.

I'm not saying this is the best approach. I can also see that this
patch-set touches a lot of boot code. But i think parsing SRAT earlier
is reasonable because this is the only way for now to know which memory
is hotpluggable from firmware.



I can understand the part where you're move NUMA discovery before
initializations which will get allocated permanent addresses in the
wrong nodes, but trying to do the same with memblock itself is making
the code extremely fragile.  It's nasty because there's nothing
apparent which seems to necessitate such ordering.  The ordering looks
rather arbitrary but changing the orders will subtly break memory
hotplug support, which is a really bad way to structure the code.

Can't you just move memblock arrays after NUMA init is complete?
That'd be a lot simpler and way more robust than the proposed changes,
no?


Sorry, I don't quite understand the approach you are suggesting. If we
move memblock arrays, we need to update all the pointers pointing to
the moved memory. How can we do this ?

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] Initial support for Allwinner's Security ID fuses

[Andy Shevchenko]

On Mon, Jun 17, 2013 at 11:59 PM, Oliver Schinagl
 wrote:
> From: Oliver Schinagl 
>
> Allwinner has electric fuses (efuse) on their line of chips. This driver
> reads those fuses, seeds the kernel entropy and exports them as a sysfs node.
>
> These fuses are most likly to be programmed at the factory, encoding
> things like Chip ID, some sort of serial number etc and appear to be
> reasonable unique.
> While in theory, these should be writeable by the user, it will probably
> be inconvinient to do so. Allwinner recommends that a certain input pin,
> labeled 'efuse_vddq', be connected to GND. To write these fuses, 2.5 V
> needs to be applied to this pin.
>
> Even so, they can still be used to generate a board-unique mac from, board
> unique RSA key and seed the kernel RNG.
>

> +++ b/drivers/misc/eeprom/sunxi_sid.c
> @@ -0,0 +1,147 @@

> +#include 

I don't think you have to use this header explicitly.

> +#define DRV_NAME "sunxi-sid"

> +   if (size > (SID_SIZE - pos))

Useless internal braces.

> +static int sunxi_sid_remove(struct platform_device *pdev)
> +{
> +   device_remove_bin_file(>dev, _bin_attr);
> +   dev_dbg(>dev, "%s driver unloaded\n", DRV_NAME);

It's useless to use DRV_NAME in conjunction with dev_* macros. dev_*
will print driver name as a prefix.

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

Re: [PATCH] clocksource: sh_cmt: 32-bit control register support

[Magnus Damm]

Hi Laurent,

On Tue, Jun 18, 2013 at 3:37 AM, Laurent Pinchart
 wrote:
> Hi Magnus,
>
> Thanks for the patch.
>
> On Monday 17 June 2013 15:40:52 Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Add support for CMT hardware with 32-bit control and counter
>> registers, as found on r8a73a4 and r8a7790. To use the CMT
>> with 32-bit hardware a second I/O memory resource needs to
>> point out the CMSTR register and it needs to be 32 bit wide.
>
> Is a memory second resource required ? Can't we use a single resource that
> will contain all the registers ?

The CMT hardware block comes with a shared timer start stop register
that historically has been left out of the resource. The location of
this register has so far been pointed out by the "channel offset"
platform data member, together with information about which bit that
happens to be assigned to the timer channel. This start stop register
has happened to be kept in the same page of I/O memory as the main
timer channel resource, so at this point we're sort of "lucky" that a
single ioremap() has covered all cases.

With this patch it becomes optional to instead of platform data use a
second resource to point out the timer start/stop register. While we
do that we can also use the size of that resource to determine the I/O
access width, which happens to be something that is needed to enable
the driver on certain SoCs.

> Time to switch to devm_* managed functions ? :-)

Yes, indeed. That among other things, like converting the driver to in
a more optimal way support clock source only or clock event only
configurations. Also, some more modern CMT hardware versions have
extended registers with 48-bit counters, and we can also often use
more high frequency clocks to improve timer resolution.

As you can tell, in general there are many things that can be improved
with this driver. I thought a first shot could be to make it actually
work on more recent CMT hardware with 32-bit only registers. So that's
what this patch does!

Cheers,

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

Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos

[Jingoo Han]

On Monday, June 17, 2013 9:45 PM, Arnd Bergmann wrote:
> On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
> > On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
> > >
[.]
> > > > > > +static int __exit exynos_pcie_remove(struct platform_device *pdev)
> > > > > > +{
> > > > > > +   struct pcie_port *pp = platform_get_drvdata(pdev);
> > > > > > +
> > > > > > +   clk_disable_unprepare(pp->bus_clk);
> > > > > > +   clk_disable_unprepare(pp->clk);
> > > > > > +
> > > > > > +   return 0;
> > > > > > +}
> > > > >
> > > > > You also don't remove the PCI devices here, as mentioned in an earlier
> > > > > review.
> > > >
> > > > I reviewed Marvell PCIe driver and Tegra PCIe driver; however,
> > > > I cannot know what you mean.
> > > >
> > > > Could let me know which additional functions are needed?
> > >
> > > The mvebu driver does not allow module unload. I haven't looked at the
> > > tegra driver. If you allow unloading the driver and provide a 'remove'
> > > callback, that callback needs to clean up the entire bus and remove
> > > all child devices that were added as well as undo everything the
> > > probe function did. I think it would be great if you can do that, although
> > > it might not be easy. The simplest solution would be to not support
> > > unloading though.
> >
> > As the mvebu driver uses platform_driver_probe(), the Exynos driver uses
> > platform_driver_probe(). Thus, I will not provide a 'remove' callback.
> 
> Well, the important part is not to provide a module_exit() function, which
> will ensure the driver cannot be unloaded.

Aha, I see.
I will not provide a module_exit() function), as the mvebu driver does.

Best regards,
Jingoo Han

> 
>   Arnd

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

[PATCH 4/4] idr: Percpu ida

[Kent Overstreet]

Percpu frontend for allocating ids. With percpu allocation (that works),
it's impossible to guarantee it will always be possible to allocate all
nr_tags - typically, some will be stuck on a remote percpu freelist
where the current job can't get to them.

We do guarantee that it will always be possible to allocate at least
(nr_tags / 2) tags - this is done by keeping track of which and how many
cpus have tags on their percpu freelists. On allocation failure if
enough cpus have tags that there could potentially be (nr_tags / 2) tags
stuck on remote percpu freelists, we then pick a remote cpu at random to
steal from.

Note that the synchronization is _definitely_ tricky - we're using
xchg()/cmpxchg() on the percpu lists, to synchronize between
steal_tags().

The alternative would've been adding a spinlock to protect the percpu
freelists, but that would've required some different tricky code to
avoid deadlock because of the lock ordering.

Note that there's no cpu hotplug notifier - we don't care, because
steal_tags() will eventually get the down cpu's tags. We _could_ satisfy
more allocations if we had a notifier - but we'll still meet our
guarantees and it's absolutely not a correctness issue, so I don't think
it's worth the extra code.

Signed-off-by: Kent Overstreet 
Cc: Tejun Heo 
Cc: Oleg Nesterov 
Cc: Christoph Lameter 
Cc: Ingo Molnar 
Cc: Andi Kleen 
Cc: Jens Axboe 
Cc: "Nicholas A. Bellinger" 
---
 include/linux/idr.h |  48 
 lib/idr.c   | 312 ++--
 2 files changed, 352 insertions(+), 8 deletions(-)

diff --git a/include/linux/idr.h b/include/linux/idr.h
index 9169e18..afaa071 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* IDA */
 
@@ -97,6 +99,52 @@ static inline void ida_init(struct ida *ida)
ida_init_prealloc(ida, 0);
 }
 
+/* Percpu IDA/tag allocator */
+
+struct percpu_ida_cpu;
+
+struct percpu_ida {
+   /*
+* number of tags available to be allocated, as passed to
+* percpu_ida_init()
+*/
+   unsignednr_tags;
+
+   struct percpu_ida_cpu __percpu  *tag_cpu;
+
+   /*
+* Bitmap of cpus that (may) have tags on their percpu freelists:
+* steal_tags() uses this to decide when to steal tags, and which cpus
+* to try stealing from.
+*
+* It's ok for a freelist to be empty when its bit is set - steal_tags()
+* will just keep looking - but the bitmap _must_ be set whenever a
+* percpu freelist does have tags.
+*/
+   unsigned long   *cpus_have_tags;
+
+   struct {
+   /*
+* When we go to steal tags from another cpu (see steal_tags()),
+* we want to pick a cpu at random. Cycling through them every
+* time we steal is a bit easier and more or less equivalent:
+*/
+   unsignedcpu_last_stolen;
+
+   /* For sleeping on allocation failure */
+   wait_queue_head_t   wait;
+
+   /* Global freelist */
+   struct ida  ida;
+   } cacheline_aligned_in_smp;
+};
+
+int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp);
+void percpu_ida_free(struct percpu_ida *pool, unsigned tag);
+
+void percpu_ida_destroy(struct percpu_ida *pool);
+int percpu_ida_init(struct percpu_ida *pool, unsigned long nr_tags);
+
 /* IDR */
 
 /*
diff --git a/lib/idr.c b/lib/idr.c
index 7d89587..401933f 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -28,17 +28,20 @@
  * with the slab allocator.
  */
 
-#ifndef TEST// to test in user space...
-#include 
-#include 
-#include 
-#endif
+#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #define IDA_TREE_ARY   BITS_PER_LONG
 
@@ -527,6 +530,299 @@ int ida_init_prealloc(struct ida *ida, unsigned prealloc)
 }
 EXPORT_SYMBOL(ida_init_prealloc);
 
+/* Percpu IDA */
+
+/*
+ * Number of tags we move between the percpu freelist and the global freelist 
at
+ * a time
+ */
+#define TAG_CPU_BATCH_MOVE 32U
+
+/* Max size of percpu freelist, */
+#define TAG_CPU_SIZE   (TAG_CPU_BATCH_MOVE + TAG_CPU_BATCH_MOVE / 2)
+
+struct percpu_ida_cpu {
+   spinlock_t  lock;
+   unsignednr_free;
+   unsignedfreelist[];
+};
+
+/*
+ * Try to steal tags from a remote cpu's percpu freelist.
+ *
+ * We first check how many percpu freelists have tags - we don't steal tags
+ * unless enough percpu freelists have tags on them that it's possible more 
than
+ * half the total tags could be stuck on remote percpu freelists.
+ *
+ * Then we iterate through the cpus until we find some tags - we don't 

[PATCH 3/4] idr: Rewrite ida

[Kent Overstreet]

This is a new, from scratch implementation of ida that should be
simpler, faster and more space efficient.

Two primary reasons for the rewrite:
 * A future patch will reimplement idr on top of this ida implementation +
   radix trees. Once that's done, the end result will be ~1k fewer lines
   of code, much simpler and easier to understand and it should be quite
   a bit faster.

 * The performance improvements and addition of ganged allocation should
   make ida more suitable for use by a percpu id/tag allocator, which
   would then act as a frontend to this allocator.

The old ida implementation was done with the idr data structures - this
was IMO backwards. I'll soon be reimplementing idr on top of this new
ida implementation and radix trees - using a separate dedicated data
structure for the free ID bitmap should actually make idr faster, and
the end result is _significantly_ less code.

This implementation conceptually isn't that different from the old one -
it's a tree of bitmaps, where one bit in a given node indicates whether
or not there are free bits in a child node.

The main difference (and advantage) over the old version is that the
tree isn't implemented with pointers - it's implemented in an array,
like how heaps are implemented, which both better space efficiency and
it'll be faster since there's no pointer chasing.

This does mean that the entire bitmap is stored in one contiguous memory
allocation - and as currently implemented we won't be able to allocate
_quite_ as many ids as with the previous implementation.

I don't expect this to be an issue in practice since anywhere this is
used, an id corresponds to a struct allocation somewher else - we can't
allocate an unbounded number of ids, we'll run out of memory somewhere
else eventually, and I expect that to be the limiting factor in
practice.

If a user/use case does come up where this matters I can add some
sharding (or perhaps add a separate big_ida implementation) - but the
extra complexity would adversely affect performance for the users that
don't need > millions of ids, so I intend to leave the implementation as
is until if and when this becomes an issue.

Signed-off-by: Kent Overstreet 
Cc: Andrew Morton 
Cc: Tejun Heo 
Cc: Stephen Rothwell 
Cc: Fengguang Wu 
---
 include/linux/idr.h | 118 +---
 lib/idr.c   | 776 +---
 2 files changed, 573 insertions(+), 321 deletions(-)

diff --git a/include/linux/idr.h b/include/linux/idr.h
index c0e0c54..9169e18 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -17,6 +17,88 @@
 #include 
 #include 
 
+/* IDA */
+
+#define IDA_INLINE_NODES   4
+
+struct ida {
+   spinlock_t  lock;
+
+   /*
+* cur_id and allocated_ids are for ida_alloc_cyclic. For cyclic
+* allocations we search for new ids to allocate starting from the last
+* id allocated - cur_id is the next id to try allocating.
+*
+* But we also don't want the allocated ids to be arbitrarily sparse -
+* the memory usage for the bitmap could be arbitrarily bad, and if
+* they're used as keys in a radix tree the memory overhead of the radix
+* tree could be quite bad as well. So we use allocated_ids to decide
+* when to restart cur_id from 0, and bound how sparse the bitmap can
+* be.
+*/
+   unsignedcur_id;
+   unsignedallocated_ids;
+
+   /* size of ida->tree */
+   unsignednodes;
+
+   /*
+* Index of first leaf node in ida->tree; equal to the number of non
+* leaf nodes, ida->nodes - ida->first_leaf == number of leaf nodes
+*/
+   unsignedfirst_leaf;
+
+   unsigned long   *tree;
+   unsigned long   inline_nodes[IDA_INLINE_NODES];
+};
+
+#define IDA_INIT(name) \
+{  \
+   .lock   = __SPIN_LOCK_UNLOCKED(name.lock),  \
+   .nodes  = IDA_INLINE_NODES, \
+   .first_leaf = 1,\
+   .tree   = name.inline_nodes,\
+}
+#define DEFINE_IDA(name)   struct ida name = IDA_INIT(name)
+
+void ida_remove(struct ida *ida, unsigned id);
+int ida_alloc_range(struct ida *ida, unsigned int start,
+ unsigned int end, gfp_t gfp);
+int ida_alloc_cyclic(struct ida *ida, unsigned start, unsigned end, gfp_t gfp);
+void ida_destroy(struct ida *ida);
+int ida_init_prealloc(struct ida *ida, unsigned prealloc);
+
+/**
+ * ida_alloc_range - allocate a new id.
+ * @ida: the (initialized) ida.
+ * @gfp_mask: memory allocation flags
+ *
+ * Allocates an id in the range [0, INT_MAX]. Returns -ENOSPC if no ids are
+ * available, or -ENOMEM on memory allocation failure.
+ *
+ * Returns the smallest available id
+ *
+ * Use 

RE: [PATCH 1/4] MFD: Palmas: Add Interrupt feature

[J, KEERTHY]

Hi Mark,

Thanks for the review.

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Monday, June 17, 2013 9:46 PM
> To: J, KEERTHY
> Cc: linux-o...@vger.kernel.org; ldewan...@nvidia.com;
> sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> g...@slimlogic.co.uk
> Subject: Re: [PATCH 1/4] MFD: Palmas: Add Interrupt feature
> 
> On Mon, Jun 17, 2013 at 05:39:11PM +0530, J Keerthy wrote:
> 
> > Palmas PMICs have an INT line. This line is one single Interrupt line
> > to the application processor. The interrupt feature enables to
> > selectively request irq for only those specific chips which have INT
> > line connected to a valid IRQ line of the application processor.
> 
> Does the support for the interrupt line need to be explicitly flagged
> like this or can the driver not simply support an interrupt line not
> being configured?  That would also support cases where the hardware has
> an interrupt line but the system integrator has opeted not to connect
> it for some reason which seems generally more flexible than doing
> things on a chip ID basis.
> 

I understand your point. The IRQ is passed from device tree node.
Say if the chip for some reason is not connected to any valid
IRQ line the driver might end up requesting for a wrong IRQ line.

So should I be validating the irq entry populated from  device tree?

Explicitly checking on chip ID helps to avoid wrongly populated
Device tree data. 

> > +/**
> > + * DOC: Palmas PMIC feature types
> > + *
> 
> Is "DOC: " normal kerneldoc?

Normal kerneldoc I shall remove "DOC:"

Regards,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers: hv: switch to use mb() instead of smp_mb()

[Jason Wang]

Even if guest were compiled without SMP support, it could not assume that host
wasn't. So switch to use mb() instead of smp_mb() to force memory barriers for
UP guest.

Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: sta...@vger.kernel.org
Signed-off-by: Jason Wang 
---
 drivers/hv/ring_buffer.c |   10 +-
 drivers/hv/vmbus_drv.c   |2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index d6fbb57..791f45d 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -32,7 +32,7 @@
 void hv_begin_read(struct hv_ring_buffer_info *rbi)
 {
rbi->ring_buffer->interrupt_mask = 1;
-   smp_mb();
+   mb();
 }
 
 u32 hv_end_read(struct hv_ring_buffer_info *rbi)
@@ -41,7 +41,7 @@ u32 hv_end_read(struct hv_ring_buffer_info *rbi)
u32 write;
 
rbi->ring_buffer->interrupt_mask = 0;
-   smp_mb();
+   mb();
 
/*
 * Now check to see if the ring buffer is still empty.
@@ -71,7 +71,7 @@ u32 hv_end_read(struct hv_ring_buffer_info *rbi)
 
 static bool hv_need_to_signal(u32 old_write, struct hv_ring_buffer_info *rbi)
 {
-   smp_mb();
+   mb();
if (rbi->ring_buffer->interrupt_mask)
return false;
 
@@ -442,7 +442,7 @@ int hv_ringbuffer_write(struct hv_ring_buffer_info 
*outring_info,
 sizeof(u64));
 
/* Issue a full memory barrier before updating the write index */
-   smp_mb();
+   mb();
 
/* Now, update the write location */
hv_set_next_write_location(outring_info, next_write_location);
@@ -549,7 +549,7 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info, void *buffer,
/* Make sure all reads are done before we update the read index since */
/* the writer may start writing to the read area once the read index */
/*is updated */
-   smp_mb();
+   mb();
 
/* Update the read index */
hv_set_next_read_location(inring_info, next_read_location);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bf421e0..4004e54 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -434,7 +434,7 @@ static void vmbus_on_msg_dpc(unsigned long data)
 * will not deliver any more messages since there is
 * no empty slot
 */
-   smp_mb();
+   mb();
 
if (msg->header.message_flags.msg_pending) {
/*
-- 
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] Allow binding drivers/uio/uio_pdrv_genirq.c to devices using command line option

[Sachin Kamat]

Hi Greg,

On 17 June 2013 23:07, Greg KH  wrote:
> On Mon, Jun 17, 2013 at 03:47:41PM +0200, Pavel Machek wrote:
>> Hi!
>>
>> > This adds ability to bind uio driver to given open firmware device
>> > using command line option. Thus, userspace driver can be developed and
>> > used without modifying the kernel.
>> >
>> > Signed-off-by: Pavel Machek 
>>
>> Ping? Greg, could you apply this patch? Or is there someone else I
>> should ask to apply it?
>
> Ugh, Hans seems to have dropped off of the net for a long time now, so I
> guess I'll start queueing up UIO patches again.  Care to resend this?
>

Even I have a couple of outstanding UIO patches [1-2]. Shall I resend
them as well?

[1] https://lkml.org/lkml/2013/3/14/154
[2] https://patchwork.kernel.org/patch/2268921/


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

[RESEND PATCH v1 2/3] spi: s3c64xx: Added provision for dedicated cs pin

[girishks2000]

From: Girish K S 

The existing driver supports gpio based /cs signal.
For controller's that have one device per controller,
the slave device's /cs signal might be internally controlled
by the chip select bit of slave select register. They are not
externally asserted/deasserted using gpio pin.

This patch adds support for controllers with dedicated /cs pin.
if "cs-gpio" property doesnt exist in a spi dts node, the controller
would treat the /cs pin as dedicated.

Signed-off-by: Girish K S 
---
changes in v1:
Added the missing data structure that caused the
compilation error

 drivers/spi/spi-s3c64xx.c |   34 ++
 1 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 0a80692..eaf9e1c 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -208,6 +208,7 @@ struct s3c64xx_spi_driver_data {
struct s3c64xx_spi_port_config  *port_conf;
unsigned intport_id;
unsigned long   gpios[4];
+   boolcs_gpio;
 };
 
 static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
@@ -570,14 +571,16 @@ static inline void enable_cs(struct 
s3c64xx_spi_driver_data *sdd,
if (sdd->tgl_spi != spi) { /* if last mssg on diff device */
/* Deselect the last toggled device */
cs = sdd->tgl_spi->controller_data;
-   gpio_set_value(cs->line,
-   spi->mode & SPI_CS_HIGH ? 0 : 1);
+   if (sdd->cs_gpio)
+   gpio_set_value(cs->line,
+   spi->mode & SPI_CS_HIGH ? 0 : 1);
}
sdd->tgl_spi = NULL;
}
 
cs = spi->controller_data;
-   gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+   if (sdd->cs_gpio)
+   gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
 
/* Start the signals */
writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -709,7 +712,8 @@ static inline void disable_cs(struct 
s3c64xx_spi_driver_data *sdd,
if (sdd->tgl_spi == spi)
sdd->tgl_spi = NULL;
 
-   gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
+   if (sdd->cs_gpio)
+   gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
 
/* Quiese the signals */
writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -997,8 +1001,10 @@ static struct s3c64xx_spi_csinfo 
*s3c64xx_get_slave_ctrldata(
 {
struct s3c64xx_spi_csinfo *cs;
struct device_node *slave_np, *data_np = NULL;
+   struct s3c64xx_spi_driver_data *sdd;
u32 fb_delay = 0;
 
+   sdd = spi_master_get_devdata(spi->master);
slave_np = spi->dev.of_node;
if (!slave_np) {
dev_err(>dev, "device node not found\n");
@@ -1018,7 +1024,10 @@ static struct s3c64xx_spi_csinfo 
*s3c64xx_get_slave_ctrldata(
return ERR_PTR(-ENOMEM);
}
 
-   cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+   /* The CS line is asserted/deasserted by the gpio pin */
+   if (sdd->cs_gpio)
+   cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+
if (!gpio_is_valid(cs->line)) {
dev_err(>dev, "chip select gpio is not specified or 
invalid\n");
kfree(cs);
@@ -1058,7 +1067,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
return -ENODEV;
}
 
-   if (!spi_get_ctldata(spi)) {
+   /* Request gpio only if cs line is asserted by gpio pins */
+   if (sdd->cs_gpio) {
err = gpio_request_one(cs->line, GPIOF_OUT_INIT_HIGH,
   dev_name(>dev));
if (err) {
@@ -1067,9 +1077,11 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
cs->line, err);
goto err_gpio_req;
}
-   spi_set_ctldata(spi, cs);
}
 
+   if (!spi_get_ctldata(spi))
+   spi_set_ctldata(spi, cs);
+
sci = sdd->cntrlr_info;
 
spin_lock_irqsave(>lock, flags);
@@ -1147,8 +1159,10 @@ err_gpio_req:
 static void s3c64xx_spi_cleanup(struct spi_device *spi)
 {
struct s3c64xx_spi_csinfo *cs = spi_get_ctldata(spi);
+   struct s3c64xx_spi_driver_data *sdd;
 
-   if (cs) {
+   sdd = spi_master_get_devdata(spi->master);
+   if (cs && sdd->cs_gpio) {
gpio_free(cs->line);
if (spi->dev.of_node)
kfree(cs);
@@ -1325,7 +1339,11 @@ static int s3c64xx_spi_probe(struct platform_device 
*pdev)
sdd->cntrlr_info = sci;
sdd->pdev = pdev;
sdd->sfr_start = mem_res->start;
+   sdd->cs_gpio = false;
if (pdev->dev.of_node) {
+   if 

[RESEND PATCH v1 1/3] spi: s3c64xx: added support for polling mode

[girishks2000]

From: Girish K S 

The 64xx spi driver supports partial polling mode.
Only the last chunk of the transfer length is transferred
or recieved in polling mode.

Some SoC's that adopt this controller might not have have dma
interface. This patch adds support for complete polling mode
and gives flexibity for the user to select poll/dma mode.

Signed-off-by: Girish K S 
---
changes in v1:
Addressed the performance issue reported by Mark Brown
caused due to this patch. The wait_for_timeout function is modified to
address this issue in dma mode.

 drivers/spi/spi-s3c64xx.c |  153 ++--
 1 files changed, 104 insertions(+), 49 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 5000586..0a80692 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -39,6 +39,7 @@
 #endif
 
 #define MAX_SPI_PORTS  3
+#define S3C64XX_SPI_QUIRK_POLL (1 << 0)
 
 /* Registers and bit-fields */
 
@@ -130,6 +131,7 @@
 #define S3C64XX_SPI_TRAILCNT   S3C64XX_SPI_MAX_TRAILCNT
 
 #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
+#define is_polling(x)  (x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
 
 #define RXBUSY(1<<2)
 #define TXBUSY(1<<3)
@@ -158,6 +160,7 @@ struct s3c64xx_spi_port_config {
int fifo_lvl_mask[MAX_SPI_PORTS];
int rx_lvl_offset;
int tx_st_done;
+   int quirks;
boolhigh_speed;
boolclk_from_cmu;
 };
@@ -344,8 +347,12 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master 
*spi)
 {
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
-   /* Acquire DMA channels */
-   while (!acquire_dma(sdd))
+   /*
+* If DMA resource was not available during
+* probe, no need to continue with dma requests
+* else Acquire DMA channels
+*/
+   while (!is_polling(sdd) && !acquire_dma(sdd))
usleep_range(1, 11000);
 
pm_runtime_get_sync(>pdev->dev);
@@ -358,9 +365,12 @@ static int s3c64xx_spi_unprepare_transfer(struct 
spi_master *spi)
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
/* Free DMA channels */
-   sdd->ops->release((enum dma_ch)sdd->rx_dma.ch, _spi_dma_client);
-   sdd->ops->release((enum dma_ch)sdd->tx_dma.ch, _spi_dma_client);
-
+   if (!is_polling(sdd)) {
+   sdd->ops->release((enum dma_ch)sdd->rx_dma.ch,
+   _spi_dma_client);
+   sdd->ops->release((enum dma_ch)sdd->tx_dma.ch,
+   _spi_dma_client);
+   }
pm_runtime_put(>pdev->dev);
 
return 0;
@@ -464,8 +474,10 @@ static int s3c64xx_spi_unprepare_transfer(struct 
spi_master *spi)
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
/* Free DMA channels */
-   dma_release_channel(sdd->rx_dma.ch);
-   dma_release_channel(sdd->tx_dma.ch);
+   if (!is_polling(sdd)) {
+   dma_release_channel(sdd->rx_dma.ch);
+   dma_release_channel(sdd->tx_dma.ch);
+   }
 
pm_runtime_put(>pdev->dev);
return 0;
@@ -566,6 +578,30 @@ static inline void enable_cs(struct 
s3c64xx_spi_driver_data *sdd,
 
cs = spi->controller_data;
gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+
+   /* Start the signals */
+   writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+}
+
+static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
+   int timeout_ms)
+{
+   void __iomem *regs = sdd->regs;
+   unsigned long val = 1;
+   u32 status;
+
+   /* max fifo depth available */
+   u32 max_fifo = (FIFO_LVL_MASK(sdd) >> 1) + 1;
+
+   if (timeout_ms)
+   val = msecs_to_loops(timeout_ms);
+
+   do {
+   status = readl(regs + S3C64XX_SPI_STATUS);
+   } while (RX_FIFO_LVL(status, sdd) < max_fifo && --val);
+
+   /* return the actual received data length */
+   return RX_FIFO_LVL(status, sdd);
 }
 
 static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -590,20 +626,19 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data 
*sdd,
} while (RX_FIFO_LVL(status, sdd) < xfer->len && --val);
}
 
-   if (!val)
-   return -EIO;
-
if (dma_mode) {
u32 status;
 
/*
+* If the previous xfer was completed within timeout, then
+* proceed further else return -EIO.
 * DmaTx returns after simply writing data in the FIFO,
 * w/o waiting for real transmission on the bus to finish.
 * DmaRx returns only after Dma read data from FIFO which
 * needs bus transmission to finish, so we don't worry if
 * Xfer involved Rx(with or without Tx).
 

[RESEND PATCH v1 0/3] Polling support for s3c64xx spi controller

[girishks2000]

From: Girish K S 

This patch series adds support for the polling mode only. Also 2nd patch
in the series adds support for dedicated cs pin. After Thomas's patch for
using default gpio is merged(commit id: 00ab539), one of the patch in this
series is dropped and new series is generated.

Girish K S (3):
  spi: s3c64xx: added support for polling mode
  spi: s3c64xx: Added provision for dedicated cs pin
  spi: s3c64xx: Added support for exynos5440 spi

 drivers/spi/spi-s3c64xx.c |  197 -
 1 files changed, 140 insertions(+), 57 deletions(-)

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

[RESEND PATCH v1 3/3] spi: s3c64xx: Added support for exynos5440 spi

[girishks2000]

From: Girish K S 

This patch adds support for the exynos5440 spi controller.
The integration of the spi IP in exynos5440 is different from
other SoC's. The I/O pins are no more configured via gpio, they
have dedicated pins.

Signed-off-by: Girish K S 
---
 drivers/spi/spi-s3c64xx.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index eaf9e1c..bd43888 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1608,6 +1608,15 @@ static struct s3c64xx_spi_port_config 
exynos4_spi_port_config = {
.clk_from_cmu   = true,
 };
 
+static struct s3c64xx_spi_port_config exynos5440_spi_port_config = {
+   .fifo_lvl_mask  = { 0x1ff },
+   .rx_lvl_offset  = 15,
+   .tx_st_done = 25,
+   .high_speed = true,
+   .clk_from_cmu   = true,
+   .quirks = S3C64XX_SPI_QUIRK_POLL,
+};
+
 static struct platform_device_id s3c64xx_spi_driver_ids[] = {
{
.name   = "s3c2443-spi",
@@ -1636,6 +1645,9 @@ static const struct of_device_id s3c64xx_spi_dt_match[] = 
{
{ .compatible = "samsung,exynos4210-spi",
.data = (void *)_spi_port_config,
},
+   { .compatible = "samsung,exynos5440-spi",
+   .data = (void *)_spi_port_config,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, s3c64xx_spi_dt_match);
-- 
1.7.5.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: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

[Alex Shi]

On 06/07/2013 03:29 PM, Alex Shi wrote:
> Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
> smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
> vaiables to describe them. unsigned long is more efficient and convenience.
> 

update with a a bit clean up in tg_load_down()
---

>From e78ccc55dff1a5ef406a100f6453d0b8c86ca310 Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Thu, 6 Jun 2013 20:12:36 +0800
Subject: [PATCH 1/5] sched: change cfs_rq load avg to unsigned long

Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
variables to describe them. unsigned long is more efficient and convenience.

Signed-off-by: Alex Shi 
Reviewed-by: Paul Turner 
Tested-by: Vincent Guittot 
---
 kernel/sched/debug.c | 4 ++--
 kernel/sched/fair.c  | 7 ++-
 kernel/sched/sched.h | 2 +-
 3 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 75024a6..160afdc 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -211,9 +211,9 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct 
cfs_rq *cfs_rq)
SEQ_printf(m, "  .%-30s: %ld\n", "load", cfs_rq->load.weight);
 #ifdef CONFIG_FAIR_GROUP_SCHED
 #ifdef CONFIG_SMP
-   SEQ_printf(m, "  .%-30s: %lld\n", "runnable_load_avg",
+   SEQ_printf(m, "  .%-30s: %ld\n", "runnable_load_avg",
cfs_rq->runnable_load_avg);
-   SEQ_printf(m, "  .%-30s: %lld\n", "blocked_load_avg",
+   SEQ_printf(m, "  .%-30s: %ld\n", "blocked_load_avg",
cfs_rq->blocked_load_avg);
SEQ_printf(m, "  .%-30s: %lld\n", "tg_load_avg",
(unsigned long 
long)atomic64_read(_rq->tg->load_avg));
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 395f57c..39a5bae 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4186,12 +4186,9 @@ static int tg_load_down(struct task_group *tg, void 
*data)
if (!tg->parent) {
load = cpu_rq(cpu)->avg.load_avg_contrib;
} else {
-   unsigned long tmp_rla;
-   tmp_rla = tg->parent->cfs_rq[cpu]->runnable_load_avg + 1;
-
load = tg->parent->cfs_rq[cpu]->h_load;
-   load *= tg->se[cpu]->avg.load_avg_contrib;
-   load /= tmp_rla;
+   load = div64_ul(load * tg->se[cpu]->avg.load_avg_contrib,
+   tg->parent->cfs_rq[cpu]->runnable_load_avg + 1);
}
 
tg->cfs_rq[cpu]->h_load = load;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 0684c26..762fa63 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -277,7 +277,7 @@ struct cfs_rq {
 * This allows for the description of both thread and group usage (in
 * the FAIR_GROUP_SCHED case).
 */
-   u64 runnable_load_avg, blocked_load_avg;
+   unsigned long runnable_load_avg, blocked_load_avg;
atomic64_t decay_counter, removed_load;
u64 last_decay;
 
-- 
1.7.12

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

linux-next: manual merge of the staging tree with the usb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/serqt_usb2/serqt_usb2.c between commit 1143832eca8f
("USB: serial: ports: add minor and port number") from the usb tree and
commit d68edc2881b1 ("staging: serqt_usb2: Fixed coding style
CamelCases") from the staging tree.

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

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

diff --cc drivers/staging/serqt_usb2/serqt_usb2.c
index 880f5c0,39de5e0..000
--- a/drivers/staging/serqt_usb2/serqt_usb2.c
+++ b/drivers/staging/serqt_usb2/serqt_usb2.c
@@@ -870,10 -870,10 +870,10 @@@ static int qt_open(struct tty_struct *t
usb_clear_halt(serial->dev, port->read_urb->pipe);
port0->open_ports++;
  
-   result = qt_get_device(serial, >DeviceData);
+   result = qt_get_device(serial, >device_data);
  
/* Port specific setups */
-   result = qt_open_channel(serial, port->port_number, );
 -  result = qt_open_channel(serial, port->number, _data);
++  result = qt_open_channel(serial, port->port_number, _data);
if (result < 0) {
dev_dbg(>dev, "qt_open_channel failed\n");
return result;
@@@ -1239,23 -1245,25 +1239,23 @@@ static void qt_set_termios(struct tty_s
  
/* Now determine flow control */
if (cflag & CRTSCTS) {
 -  dev_dbg(>dev, "%s - Enabling HW flow control port %d\n",
 -  __func__, port->number);
 +  dev_dbg(>dev, "%s - Enabling HW flow control\n", 
__func__);
  
/* Enable RTS/CTS flow control */
-   status = BoxSetHW_FlowCtrl(port->serial, index, 1);
+   status = box_set_hw_flow_ctrl(port->serial, index, 1);
  
if (status < 0) {
-   dev_dbg(>dev, "BoxSetHW_FlowCtrl failed\n");
+   dev_dbg(>dev, "box_set_hw_flow_ctrl failed\n");
return;
}
} else {
/* Disable RTS/CTS flow control */
dev_dbg(>dev,
 -  "%s - disabling HW flow control port %d\n",
 -  __func__, port->number);
 +  "%s - disabling HW flow control\n", __func__);
  
-   status = BoxSetHW_FlowCtrl(port->serial, index, 0);
+   status = box_set_hw_flow_ctrl(port->serial, index, 0);
if (status < 0) {
-   dev_dbg(>dev, "BoxSetHW_FlowCtrl failed\n");
+   dev_dbg(>dev, "box_set_hw_flow_ctrl failed\n");
return;
}
  
@@@ -1324,12 -1332,12 +1324,12 @@@ static inline int qt_real_tiocmget(stru
int status;
unsigned int index;
  
 -  index = tty->index - serial->minor;
 +  index = port->port_number;
status =
-   BoxGetRegister(port->serial, index, MODEM_CONTROL_REGISTER, );
+   box_get_register(port->serial, index, MODEM_CONTROL_REGISTER, );
if (status >= 0) {
status =
-   BoxGetRegister(port->serial, index,
+   box_get_register(port->serial, index,
   MODEM_STATUS_REGISTER, );
  
}
@@@ -1363,9 -1371,9 +1363,9 @@@ static inline int qt_real_tiocmset(stru
int status;
unsigned int index;
  
 -  index = tty->index - serial->minor;
 +  index = port->port_number;
status =
-   BoxGetRegister(port->serial, index, MODEM_CONTROL_REGISTER, );
+   box_get_register(port->serial, index, MODEM_CONTROL_REGISTER, );
if (status < 0)
return -ESPIPE;
  


pgpN_pQeyeEEz.pgp
Description: PGP signature

Re: Build regressions/improvements in v3.10-rc6

[Michael Ellerman]

On Mon, Jun 17, 2013 at 09:19:51PM +0200, Geert Uytterhoeven wrote:
> On Mon, 17 Jun 2013, Geert Uytterhoeven wrote:
> 
> powerpc-randconfig

>   + arch/powerpc/include/asm/mmu-hash64.h: error: control reaches end of 
> non-void function [-Werror=return-type]:  => 180:1

This is running past a BUG(), which must mean we have CONFIG_BUG=n.
BUG() turning into nothing is a bug in the CONFIG_BUG=n implementation IMHO.
There was a discussion about this recently, I didn't see what the resolution
was.

>   + arch/powerpc/kvm/book3s_hv.c: error: 'vcpus_to_update[need_vpa_update]' 
> may be used uninitialized in this function [-Werror=uninitialized]:  => 
> 1187:22

This looks bogus to me:

  if (need_vpa_update) {
spin_unlock(>lock);
for (i = 0; i < need_vpa_update; ++i) 
kvmppc_update_vpas(vcpus_to_update[i]);

I fail to see how that accesses vcpus_to_update[need_vpa_update].

>   + arch/powerpc/platforms/cell/beat_iommu.c: error: 'dma_base' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 69:11
>   + arch/powerpc/platforms/cell/beat_iommu.c: error: 'dma_size' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 68:2
>   + arch/powerpc/platforms/cell/beat_iommu.c: error: 'io_page_size' may be 
> used uninitialized in this function [-Werror=uninitialized]:  => 68:54
>   + arch/powerpc/platforms/cell/beat_wrapper.h: error: 'io_space_id' may be 
> used uninitialized in this function [-Werror=uninitialized]:  => 249:2
>   + arch/powerpc/platforms/cell/beat_wrapper.h: error: 'ioid' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 249:2

The above are all false warnings AFAICS.

> We need more randconfig builds to divert attention from powerpc ;-)

Or we could just drop them, with all the false positives from -Wuninitialized
it's hard to spot any real problems.

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

Re: [PATCH v2 2/2] mmc: dw_mmc: Add the ability to set the ciu clock frequency

[Jaehoon Chung]

Hi Doug,

I have one question for using .
I found the fixed-rate-clocks feature.
If we want to set , then can we use the fixed-rate-clocks?
i'm not sure how use the fixed-rate-clocks. but it seems to set fixed-rate 
value for clock frequency.

clk_set_rate() didn't ensure to set the  value.

Best Regards,
Jaehoon Chung

On 06/08/2013 02:28 AM, Doug Anderson wrote:
> As of now we rely on code outside of the driver to set the ciu clock
> frequency.  There's no reason to do that.  Add support for setting up
> the clock in the driver during probe.
> 
> Signed-off-by: Doug Anderson 
> Acked-by: Jaehoon Chung 
> ---
> Changes in v2:
> - Added example as per Jaehoon.
> 
>  .../devicetree/bindings/mmc/synopsis-dw-mshc.txt| 16 
>  drivers/mmc/host/dw_mmc.c   | 17 
> +
>  2 files changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt 
> b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
> index d5cc94e..dd31b00 100644
> --- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
> @@ -39,6 +39,19 @@ Required Properties:
>  
>  Optional properties:
>  
> +* clocks: from common clock binding: handle to biu and ciu clocks for the
> +  bus interface unit clock and the card interface unit clock.
> +
> +* clock-names: from common clock binding: Shall be "biu" and "ciu".
> +  If the biu clock is missing we'll simply skip enabling it.  If the
> +  ciu clock is missing we'll just assume that the clock is running at
> +  clock-frequency.  It is an error to omit both the ciu clock and the
> +  clock-frequency.
> +
> +* clock-frequency: should be the frequency (in Hz) of the ciu clock.  If this
> +  is specified and the ciu clock is specified then we'll try to set the ciu
> +  clock to this at probe time.
> +
>  * num-slots: specifies the number of slots supported by the controller.
>The number of physical slots actually used could be equal or less than the
>value specified by num-slots. If this property is not specified, the value
> @@ -70,6 +83,8 @@ board specific portions as listed below.
>  
>   dwmmc0@1220 {
>   compatible = "snps,dw-mshc";
> + clocks = < 351>, < 132>;
> + clock-names = "biu", "ciu";
>   reg = <0x1220 0x1000>;
>   interrupts = <0 75 0>;
>   #address-cells = <1>;
> @@ -77,6 +92,7 @@ board specific portions as listed below.
>   };
>  
>   dwmmc0@1220 {
> + clock-frequency = <4>;
>   num-slots = <1>;
>   supports-highspeed;
>   broken-cd;
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index ab5642d..b8a2f16 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2107,6 +2107,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
> dw_mci *host)
>   struct device_node *np = dev->of_node;
>   const struct dw_mci_drv_data *drv_data = host->drv_data;
>   int idx, ret;
> + u32 clock_frequency;
>  
>   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>   if (!pdata) {
> @@ -2133,6 +2134,9 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
> dw_mci *host)
>  
>   of_property_read_u32(np, "card-detect-delay", >detect_delay_ms);
>  
> + if (!of_property_read_u32(np, "clock-frequency", _frequency))
> + pdata->bus_hz = clock_frequency;
> +
>   if (drv_data && drv_data->parse_dt) {
>   ret = drv_data->parse_dt(host);
>   if (ret)
> @@ -2190,18 +2194,23 @@ int dw_mci_probe(struct dw_mci *host)
>   host->ciu_clk = devm_clk_get(host->dev, "ciu");
>   if (IS_ERR(host->ciu_clk)) {
>   dev_dbg(host->dev, "ciu clock not available\n");
> + host->bus_hz = host->pdata->bus_hz;
>   } else {
>   ret = clk_prepare_enable(host->ciu_clk);
>   if (ret) {
>   dev_err(host->dev, "failed to enable ciu clock\n");
>   goto err_clk_biu;
>   }
> - }
>  
> - if (IS_ERR(host->ciu_clk))
> - host->bus_hz = host->pdata->bus_hz;
> - else
> + if (host->pdata->bus_hz) {
> + ret = clk_set_rate(host->ciu_clk, host->pdata->bus_hz);
> + if (ret)
> + dev_warn(host->dev,
> +  "Unable to set bus rate to %ul\n",
> +  host->pdata->bus_hz);
> + }
>   host->bus_hz = clk_get_rate(host->ciu_clk);
> + }
>  
>   if (drv_data && drv_data->setup_clock) {
>   ret = drv_data->setup_clock(host);
> 

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

Re: [PATCH] build some drivers only when compile-testing

[Michal Marek]

Dne 17.6.2013 22:05, Jiri Slaby napsal(a):
> On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
>> On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
>>> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
 Some drivers can be built on more platforms than they run on. This
 causes users and distributors packaging burden when they have to
 manually deselect some drivers from their allmodconfigs. Or sometimes
 it is even impossible to disable the drivers without patching the
 kernel.

 Introduce a new config option COMPILE_TEST and make all those drivers
 to depend on the platform they run on, or on the COMPILE_TEST option.
 Now, when users/distributors choose COMPILE_TEST=n they will not have
 the drivers in their allmodconfig setups, but developers still can
 compile-test them with COMPILE_TEST=y.
>>>
>>> I understand the urge, and it's getting hard for distros to handle these
>>> drivers that just don't work on other architectures, but it's really
>>> valuable to ensure that they build properly, for those of us that don't
>>> have many/any cross compilers set up.
> 
> But this is exactly what COMPILE_TEST will give us when set to "y", or
> am I missing something?
> 
 Now the drivers where we use this new option:
 * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
   processors so it should depend on x86.
 * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
 * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
   systems -- which do not actually support the hardware via that
   method.
>>>
>>> This seems ripe to start to get really messy, really quickly.  Shouldn't
>>> "default configs" handle if this "should" be enabled for a platform or
>>> not, and let the rest of us just build them with no problems?
>>
>> If every time a new Kconfig option is added, corresponding default
>> config updates come with it, sure. I just don't see that happening,
>> especially when it can be done much more clearly in the Kconfig while
>> the developer is writing the driver.
>>
>>> What problems is this causing you?  Are you running out of space in
>>> kernel packages with drivers that will never be actually used?
>>
>> Wasted build resources. Wasted disk space on /every/ system the kernel
>> package is installed on. We're all trying to pare down the kernel
>> packages to eliminate wasted space and doing it manually means a bunch
>> of research, sometimes with incorrect assumptions about the results,
>> needs to be done by someone not usually associated with that code. That
>> research gets repeated by people maintaining kernel packages for pretty
>> much every distro.
> 
> I second all the above.
> 
 +config COMPILE_TEST
 +  bool "Compile also drivers which will not load" if EXPERT
>>>
>>> EXPERT is getting to be the "let's hide it here" option, isn't it...
>>>
>>> I don't know, if no one else strongly objects, I can be convinced that
>>> this is needed, but so far, I don't see why it really is, or what this
>>> is going to help with.
>>
>> I'm not convinced adding a || COMPILE_TEST option to every driver that
>> may be arch specific is the best way to go either. Perhaps adding a new
>> Kconfig verb called "archdepends on" or something that will evaluate as
>> true if COMPILE_TEST is enabled but will evaluate the conditional if
>> not. *waves hands*
> 
> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want
> to extend the kconfig language for this purpose (which I support). That
> a config option is fine and sufficient in this case [1]. Except he
> called the config option "SHOW_ALL_DRIVERS". Adding the current
> maintainer to CCs ;).

I agree with Sam. 'depends on XY || COMPILE_TEST' is quite
self-explanatory. And even if it's not, you can look up the help text
for COMPILE_TEST. With "archdepends on" or "available on", you need to
know what to look for to override the dependency.

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

Re: [PATCH V2 Resend 4/4] timer: Migrate running timer

[Viresh Kumar]

On 31 May 2013 16:19, Viresh Kumar  wrote:
> On 22 May 2013 14:04, Viresh Kumar  wrote:
>> Sorry for being late in replying to your queries.
>>
>> On 13 May 2013 16:05, Thomas Gleixner  wrote:
>>> Which mechanism is migrating the timer away?
>>
>> It will be the same: get_nohz_timer_target() which will decide target
>> cpu for migration.
>>
>>> I have no objections to the functionality per se, but the proposed
>>> solution is not going to fly.
>>>
>>> Aside of bloating the data structure you're changing the semantics of
>>> __mod_timer(). No __mod_timer() caller can deal with -EBUSY. So you'd
>>> break the world and some more.
>>
>> Ahh.. That idea was dropped already.
>>
>>> Here is a list of questions:
>>>
>>>   - Which mechanism migrates timers?
>>>
>>>   - How is that mechanism triggered?
>>
>> The mechanism remains the same as is for non-rearmed timers.
>> i.e. get_nohz_timer_target()..
>>
>> We are just trying to give a approach with which we can migrate
>> running timers. i.e. those which re-arm themselves from their
>> handlers.
>>
>>>   - How does that deal with CPU bound timers?
>>
>> We will still check 'Pinned' for this timer as is done for any other
>> normal timer. So, we don't migrate them.
>>
>> So, this is the clean draft for the idea I had.. (Naming is poor for
>> now):
>>
>> diff --git a/include/linux/timer.h b/include/linux/timer.h
>> index 8c5a197..ad00ebe 100644
>> --- a/include/linux/timer.h
>> +++ b/include/linux/timer.h
>> @@ -20,6 +20,7 @@ struct timer_list {
>>
>> void (*function)(unsigned long);
>> unsigned long data;
>> +   int wait_for_migration_to_complete;
>>
>> int slack;
>>
>> diff --git a/kernel/timer.c b/kernel/timer.c
>> index a860bba..7791f28 100644
>> --- a/kernel/timer.c
>> +++ b/kernel/timer.c
>> @@ -746,21 +746,15 @@ __mod_timer(struct timer_list *timer, unsigned
>> long expires,
>> new_base = per_cpu(tvec_bases, cpu);
>>
>> if (base != new_base) {
>> -   /*
>> -* We are trying to schedule the timer on the local CPU.
>> -* However we can't change timer's base while it is running,
>> -* otherwise del_timer_sync() can't detect that the timer's
>> -* handler yet has not finished. This also guarantees that
>> -* the timer is serialized wrt itself.
>> -*/
>> -   if (likely(base->running_timer != timer)) {
>> -   /* See the comment in lock_timer_base() */
>> -   timer_set_base(timer, NULL);
>> -   spin_unlock(>lock);
>> -   base = new_base;
>> -   spin_lock(>lock);
>> -   timer_set_base(timer, base);
>> -   }
>> +   if (base->running_timer == timer)
>> +   timer->wait_for_migration_to_complete = 1;
>> +
>> +   /* See the comment in lock_timer_base() */
>> +   timer_set_base(timer, NULL);
>> +   spin_unlock(>lock);
>> +   base = new_base;
>> +   spin_lock(>lock);
>> +   timer_set_base(timer, base);
>> }
>>
>> timer->expires = expires;
>> @@ -990,7 +984,8 @@ int try_to_del_timer_sync(struct timer_list *timer)
>>
>> base = lock_timer_base(timer, );
>>
>> -   if (base->running_timer != timer) {
>> +   if ((base->running_timer != timer) &&
>> +   !timer->wait_for_migration_to_complete) {
>> timer_stats_timer_clear_start_info(timer);
>> ret = detach_if_pending(timer, base, true);
>> }
>> @@ -1183,6 +1178,8 @@ static inline void __run_timers(struct tvec_base *base)
>> call_timer_fn(timer, fn, data);
>> spin_lock_irq(>lock);
>> }
>> +   if (timer->wait_for_migration_to_complete)
>> +   timer->wait_for_migration_to_complete = 0;
>> }
>> }
>> base->running_timer = NULL;
>>
>>
>> Please see if it a junk idea or has some light of hope :)
>
> Ping!!

Ping!!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: userspace: Simplify governor

[Viresh Kumar]

On 5 June 2013 18:38, Viresh Kumar  wrote:
> To be honest with the amount of experience I have now, my log was
> poor :(
>
> I have used following log in the attached patch:
>
> Subject: [PATCH] cpufreq: userspace: Simplify governor
>
> Userspace governor has got more code than what it needs for its functioning.
> Lets simplify it. Portions of code removed are:
> - Extra header files which aren't required anymore (rearranged them as well)
> - cpu_{max|min|cur|set}_freq, as they are always same as policy->{max|min|cur}
> - userspace_cpufreq_notifier_block as we don't need to set cpu_cur_freq 
> anymore
> - cpus_using_userspace_governor as it was for notifier code
>
> Signed-off-by: Viresh Kumar 

Hi Rafael,

Are you happy with the log & description of this patch now?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding

[Sekhar Nori]

On 6/17/2013 9:10 PM, Fernandes, Joel A wrote:
> Hi Arnd,
> 
>> -Original Message-
>> From: Arnd Bergmann [mailto:a...@arndb.de]
>> Sent: Monday, June 17, 2013 6:13 AM
>> To: Fernandes, Joel A
>> Cc: Tony Lindgren; Nori, Sekhar; Matt Porter; Grant Likely; Rob Herring; 
>> Vinod
>> Koul; Mark Brown; Cousson, Benoit; Russell King; Rob Landley; Andrew
>> Morton; Jason Kridner; Koen Kooi; Devicetree Discuss; Linux OMAP List; Linux
>> ARM Kernel List; Linux DaVinci Kernel List; Linux Kernel Mailing List; Linux
>> Documentation List; Linux MMC List; Linux SPI Devel List
>> Subject: Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree
>> binding
>>
>> On Friday 14 June 2013 21:32:47 Joel A Fernandes wrote:
>>>
>>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> new file mode 100644
>>> index 000..ada0018
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> @@ -0,0 +1,26 @@
>>> +TI EDMA
>>> +
>>> +Required properties:
>>> +- compatible : "ti,edma3"
>>> +- ti,hwmods: Name of the hwmods associated to the EDMA
>>> +- ti,edma-regions: Number of regions
>>> +- ti,edma-slots: Number of slots
>>> +
>>> +Optional properties:
>>> +- ti,edma-xbar-event-map: Crossbar event to channel map
>>
>> You need to list #dma-cells as required here, and which values are accepted
>> by the driver (I suppose only <1>). You should also explain the format of the
>> dma-specifier for a slave here for each possible value of #dma-cells.
>>
>> For each of the standard properties (reg, interrupts, dma-channels), list
>> whether they are optional or required. Since the example has three
>> interrupts, you should probably list how many interrupts need to be specified
>> (minimum and maximum if the number is variable) and in what order to
>> expect them.
>  
> [Joel] Thanks for the suggestion, I updated it and it looks like this now:
>   
>
> Required properties:  
>  
> - compatible : "ti,edma3" 
>  
> - ti,hwmods: Name of the hwmods associated to the EDMA  

I have already asked for ti,hwmods to be made optional. Please see my
comment from yesterday.

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

[PATCH] input/joystick: Fix for xpad driver support of "Mad Catz Street Fighter IV FightPad" controllers

[Shawn]

From: shawn joseph 

Added MAP_TRIGGERS_TO_BUTTONS for Mad Catz Street Fighter IV FightPad
device. This controller model was already supported by the xpad
driver, but none of the buttons work correctly without this change.
Tested on kernel version 3.9.5.
Signed-off-by: shawn joseph 
---
--- linux-3.9.5/drivers/input/
joystick/xpad.c.orig  2013-06-16 15:09:47.974170141 -0400
+++ linux-3.9.5/drivers/input/joystick/xpad.c   2013-06-16
15:10:24.070611282 -0400
@@ -137,7 +137,7 @@ static const struct xpad_device {
{ 0x0738, 0x4540, "Mad Catz Beat Pad", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX },
{ 0x0738, 0x4556, "Mad Catz Lynx Wireless Controller", 0, XTYPE_XBOX },
{ 0x0738, 0x4716, "Mad Catz Wired Xbox 360 Controller", 0,
XTYPE_XBOX360 },
-   { 0x0738, 0x4728, "Mad Catz Street Fighter IV FightPad",
XTYPE_XBOX360 },
+   { 0x0738, 0x4728, "Mad Catz Street Fighter IV FightPad",
MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x0738, 0x4738, "Mad Catz Wired Xbox 360 Controller (SFIV)",
MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x0738, 0x6040, "Mad Catz Beat Pad Pro",
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x0738, 0xbeef, "Mad Catz JOYTECH NEO SE Advanced GamePad",
XTYPE_XBOX360 },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] KVM: PPC: Add support for IOMMU in-kernel handling

[Benjamin Herrenschmidt]

On Mon, 2013-06-17 at 20:32 -0600, Alex Williamson wrote:

> Right, we don't want to create dependencies across modules.  I don't
> have a vision for how this should work.  This is effectively a complete
> side-band to vfio, so we're really just dealing in the iommu group
> space.  Maybe there needs to be some kind of registration of ownership
> for the group using some kind of token.  It would need to include some
> kind of notification when that ownership ends.  That might also be a
> convenient tag to toggle driver probing off for devices in the group.
> Other ideas?  Thanks,

All of that smells nasty like it will need a pile of bloody
infrastructure which makes me think it's too complicated and not the
right approach.

How does access control work today on x86/VFIO ? Can you give me a bit
more details ? I didn't get a good grasp in your previous email

>From the look of it, the VFIO file descriptor is what has the "access
control" to the underlying iommu, is this right ? So we somewhat need to
transfer (or copy) that ownership from the VFIO fd to the KVM VM.

I don't see a way to do that without some cross-layering here...

Rusty, are you aware of some kernel mechanism we can use for that ?

Cheers,
Ben.


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

[PATCH V2 11/15] regulator: ti-abb: Convert to use devm_ioremap_resource

[Tushar Behera]

Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
introduced devm_ioremap_resource() and deprecated the use of
devm_request_and_ioremap().

While at it, remove the error message as devm_ioremap_resource prints a similar
error message.

Signed-off-by: Tushar Behera 
CC: Mark Brown 
CC: Liam Girdwood 
---
Changes for V2:
* Removed error messages from devm_ioremap_resource exit path

 drivers/regulator/ti-abb-regulator.c |   14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/ti-abb-regulator.c 
b/drivers/regulator/ti-abb-regulator.c
index 870d209..3753ed0 100644
--- a/drivers/regulator/ti-abb-regulator.c
+++ b/drivers/regulator/ti-abb-regulator.c
@@ -722,10 +722,9 @@ static int ti_abb_probe(struct platform_device *pdev)
ret = -ENODEV;
goto err;
}
-   abb->base = devm_request_and_ioremap(dev, res);
-   if (!abb->base) {
-   dev_err(dev, "Unable to map '%s'\n", pname);
-   ret = -ENOMEM;
+   abb->base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(abb->base)) {
+   ret = PTR_ERR(abb->base);
goto err;
}
 
@@ -776,10 +775,9 @@ static int ti_abb_probe(struct platform_device *pdev)
ret = -ENODEV;
goto skip_opt;
}
-   abb->ldo_base = devm_request_and_ioremap(dev, res);
-   if (!abb->ldo_base) {
-   dev_err(dev, "Unable to map '%s'\n", pname);
-   ret = -ENOMEM;
+   abb->ldo_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(abb->ldo_base)) {
+   ret = PTR_ERR(abb->ldo_base);
goto err;
}
 
-- 
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 -next] pinctrl: core: fix missing unlock on error in pinctrl_find_gpio_range_from_pin()

[Wei Yongjun]

From: Wei Yongjun 

Add the missing unlock before return from function 
pinctrl_find_gpio_range_from_pin()
in the error handling case.

Introduced by commit 2ff3477efd7086544b9e298fc63afab0645921b4.
(pinctrl: add pin list based GPIO ranges)

Signed-off-by: Wei Yongjun 
---
 drivers/pinctrl/core.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 33710b5..28a3f7b 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -465,7 +465,7 @@ struct pinctrl_gpio_range *
 pinctrl_find_gpio_range_from_pin(struct pinctrl_dev *pctldev,
 unsigned int pin)
 {
-   struct pinctrl_gpio_range *range = NULL;
+   struct pinctrl_gpio_range *range;
 
mutex_lock(>mutex);
/* Loop over the ranges */
@@ -475,17 +475,16 @@ pinctrl_find_gpio_range_from_pin(struct pinctrl_dev 
*pctldev,
int a;
for (a = 0; a < range->npins; a++) {
if (range->pins[a] == pin)
-   return range;
+   goto out;
}
} else if (pin >= range->pin_base &&
-  pin < range->pin_base + range->npins) {
-   mutex_unlock(>mutex);
-   return range;
-   }
+  pin < range->pin_base + range->npins)
+   goto out;
}
+   range = NULL;
+out:
mutex_unlock(>mutex);
-
-   return NULL;
+   return range;
 }
 EXPORT_SYMBOL_GPL(pinctrl_find_gpio_range_from_pin);
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

[Nicolas Pitre]

On Mon, 17 Jun 2013, Lorenzo Pieralisi wrote:

> The TC2 versatile express core tile integrates a logic block that provides the
> interface between the dual cluster test-chip and the M3 microcontroller that
> carries out power management. The logic block, called Serial Power Controller
> (SPC), contains several memory mapped registers to control among other things
> low-power states, operating points and reset control.

[...]

I slightly modified the following before committing this patch to my TC2 
branch:

> +/**
> + * ve_spc_cpu_wakeup_irq()
> + *
> + * Function to set/clear per-CPU wake-up IRQs. Not protected by locking since
> + * it might be used in code paths where normal cacheable locks are not
> + * working. Locking must be provided by the caller to ensure atomicity.
> + *
> + * @cpu: mpidr[7:0] bitfield describing cpu affinity level
> + * @cluster: mpidr[15:8] bitfield describing cluster affinity level
> + * @set: if true, wake-up IRQs are set, if false they are cleared
> + */
> +void ve_spc_cpu_wakeup_irq(u32 cpu, u32 cluster, bool set)
> +{

I made cluster first then cpu.  All the other functions have the cluster 
argument first, and ve_spc_set_resume_addr() already uses that order.

[...]
> +#ifdef CONFIG_VEXPRESS_SPC
> +int ve_spc_probe(void);
> +int ve_spc_get_freq(u32 cluster);
> +int ve_spc_set_freq(u32 cluster, u32 freq);
> +int ve_spc_get_freq_table(u32 cluster, const u32 **fptr);
> +void ve_spc_global_wakeup_irq(bool set);
> +void ve_spc_cpu_wakeup_irq(u32 cpu, u32 cluster, bool set);
> +void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr);
> +u32 ve_spc_get_nr_cpus(u32 cluster);
> +void ve_spc_powerdown(u32 cluster, bool enable);
> +#else
> +static inline bool ve_spc_probe(void) { return -ENODEV; }

s/bool/int/


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] x86, efi: retry ExitBootServices() on failure

[Zachary Bobroff]

The timer is shutdown before callbacks on exitbootservices are called.  The 
bios should be entirely single threaded at this point unless Linux has started 
some other CPUs.  So exitbootservices will not return until each until each 
callback is complete.  In short, then it would return the status of failure if 
the memory map has changed, success otherwise.  The callbacks are not called on 
any subsequent call to exitbootservices, so the map should stay the same then.

Sent from my iPhone

On Jun 17, 2013, at 10:48 PM, "joeyli"  wrote:

> Hi Zach, 
> 
> 於 二，2013-06-18 於 00:18 +，Zachary Bobroff 提到：
>> All,
>> 
 Why a single retry is having reasonable guarantees to work when the
>> original one failed (nothing prevents an event handler to do another
>> allocation the next time through).
>> 
>> This patch is being submitted because of the potential issues that
>> occur when 3rd party option ROMs are signaled by the ExitBootServices
>> event. At the time they are signaled, they can perform any number of
>> actions that would change the EFI Memory map.  This wasn't actually
>> seen with our default implementation of our firmware, it was seen when
>> this plug-in card's option rom was run.
>> 
>> We only need to retry once because of what is in the UEFI
>> specification 2.3.1 Errata C.  The exact verbiage is as follows:
>> 
>> The ExitBootServices() function is called by the currently executing
>> EFI OS loader image to terminate all boot services. On success, the
>> loader becomes responsible for the continued operation of the system.
>> All events of type EVT_SIGNAL_EXIT_BOOT_SERVICES must be signaled
>> before ExitBootServices() returns EFI_SUCCESS. The events are only
>> signaled once even if ExitBootServices() is called multiple times.
>> 
>> Since the firmware will only signal the ExitBootServices event once,
>> the code that has the potential to change the memory map will only be
>> signaled on the first call to exit boot services. 
> 
> Does it possible have any delay time of 3rd party ROMs to change EFI
> memory map after they are signaled?
> or ExitBootServices() will wait all 3rd party ROMs updated memory map
> finished then return true/false to kernel?
> 
> 
> Thanks a lot!
> Joey Lee
> 

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] firmware loader: fix use-after-free by double abort

[Ming Lei]

On Tue, Jun 18, 2013 at 12:05 PM, Guenter Roeck  wrote:
>>
> I may be missing something, but why would mainline not need it ?
> Or do you mean "mainline plus 3.9" ?

Yes, mainline need it of course, sorry for not mentioning that explicitly.

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] Volatile Ranges (v8?)

[Minchan Kim]

Hello Dhaval,

On Mon, Jun 17, 2013 at 12:24:07PM -0400, Dhaval Giani wrote:
> Hi John,
> 
> I have been giving your git tree a whirl, and in order to simulate a
> limited memory environment, I was using memory cgroups.
> 
> The program I was using to test is attached here. It is your test
> code, with some changes (changing the syscall interface, reducing
> the memory pressure to be generated).
> 
> I trapped it in a memory cgroup with 1MB memory.limit_in_bytes and hit this,
> 
> [  406.207612] [ cut here ]
> [  406.207621] kernel BUG at mm/vrange.c:523!
> [  406.207626] invalid opcode:  [#1] SMP
> [  406.207631] Modules linked in:
> [  406.207637] CPU: 0 PID: 1579 Comm: volatile-test Not tainted

Thanks for the testing!
Does below patch fix your problem?

diff --git a/mm/swapfile.c b/mm/swapfile.c
index d41c63f..1f6c80e 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -751,7 +751,7 @@ int __free_swap_and_cache(swp_entry_t entry)
page = find_get_page(swap_address_space(entry),
entry.val);
}
-   spin_unlock(_lock);
+   spin_unlock(>lock);
}
 
if (page) {
diff --git a/mm/vrange.c b/mm/vrange.c
index fa965fb..dc32cfa 100644
--- a/mm/vrange.c
+++ b/mm/vrange.c
@@ -485,7 +485,7 @@ int try_to_discard_one(struct vrange_root *vroot, struct 
page *page,
 {
struct mm_struct *mm = vma->vm_mm;
pte_t *pte;
-   pte_t pteval;
+   pte_t pteval, pteswap;
spinlock_t *ptl;
int ret = 0;
bool present;
@@ -505,7 +505,7 @@ int try_to_discard_one(struct vrange_root *vroot, struct 
page *page,
present = pte_present(*pte);
flush_cache_page(vma, address, page_to_pfn(page));
 
-   ptep_clear_flush(vma, address, pte);
+   pteswap = ptep_clear_flush(vma, address, pte);
pteval = pte_mkvrange(*pte);
 
update_hiwater_rss(mm);
@@ -517,10 +517,11 @@ int try_to_discard_one(struct vrange_root *vroot, struct 
page *page,
page_remove_rmap(page);
page_cache_release(page);
if (!present) {
-   swp_entry_t entry = pte_to_swp_entry(*pte);
+   swp_entry_t entry = pte_to_swp_entry(pteswap);
dec_mm_counter(mm, MM_SWAPENTS);
-   if (unlikely(!__free_swap_and_cache(entry)))
+   if (unlikely(!__free_swap_and_cache(entry))) {
BUG_ON(1);
+   }
}
 
set_pte_at(mm, address, pte, pteval);
-- 
1.7.9.5

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

[x86] only print out DR registers if they are not power-on defaults.

[Dave Jones]

The DR registers are rarely useful when decoding oopses.
With screen real estate during oopses at a premium, we can save two lines
by only printing out these registers when they are set to something other
than they power-on state.

Signed-off-by: Dave Jones 

diff -durpN '--exclude-from=/home/davej/.exclude' 
/home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c 
linux-dj/arch/x86/kernel/process_64.c
--- /home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c 
2013-05-01 10:02:52.064151923 -0400
+++ linux-dj/arch/x86/kernel/process_64.c   2013-05-06 20:35:09.219868881 
-0400
@@ -105,11 +105,18 @@ void __show_regs(struct pt_regs *regs, i
get_debugreg(d0, 0);
get_debugreg(d1, 1);
get_debugreg(d2, 2);
-   printk(KERN_DEFAULT "DR0: %016lx DR1: %016lx DR2: %016lx\n", d0, d1, 
d2);
get_debugreg(d3, 3);
get_debugreg(d6, 6);
get_debugreg(d7, 7);
+
+   /* Only print out debug registers if they are in their non-default 
state. */
+   if ((d0 == 0) && (d1 == 0) && (d2 == 0) && (d3 == 0) &&
+   (d6 & ~DR6_RESERVED) && (d7 == 0x400))
+   return;
+
+   printk(KERN_DEFAULT "DR0: %016lx DR1: %016lx DR2: %016lx\n", d0, d1, 
d2);
printk(KERN_DEFAULT "DR3: %016lx DR6: %016lx DR7: %016lx\n", d3, d6, 
d7);
+
 }
 
 void release_thread(struct task_struct *dead_task)

diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 7305f7d..5905dc5 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -110,11 +110,16 @@ void __show_regs(struct pt_regs *regs, int all)
get_debugreg(d1, 1);
get_debugreg(d2, 2);
get_debugreg(d3, 3);
-   printk(KERN_DEFAULT "DR0: %08lx DR1: %08lx DR2: %08lx DR3: %08lx\n",
-   d0, d1, d2, d3);
-
get_debugreg(d6, 6);
get_debugreg(d7, 7);
+
+   /* Only print out debug registers if they are in their non-default 
state. */
+   if ((d0 == 0) && (d1 == 0) && (d2 == 0) && (d3 == 0) &&
+   (d6 & ~DR6_RESERVED) && (d7 == 0x400))
+   return;
+
+   printk(KERN_DEFAULT "DR0: %08lx DR1: %08lx DR2: %08lx DR3: %08lx\n",
+   d0, d1, d2, d3);
printk(KERN_DEFAULT "DR6: %08lx DR7: %08lx\n",
d6, d7);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: fec: Fix build for MCF5272

[Guenter Roeck]

On Mon, Jun 17, 2013 at 04:11:51PM -0700, David Miller wrote:
> From: Guenter Roeck 
> Date: Mon, 17 Jun 2013 13:16:19 -0700
> 
> > Commits 4c09eed9 (net: fec: Enable imx6 enet checksum acceleration) and
> > baa70a5c (net: fec: enable pause frame to improve rx prefomance for 1G
> > network) introduced functionality into the FEC driver which is not
> > supported on MCF5272. As result, building images for MCF5272 fails,
> > complaining about several undefined symbols.
> > 
> > Disabled the added functionality for MCF5272 builds.
> > 
> > Cc: Frank Li 
> > Cc: Jim Baxter 
> > Signed-off-by: Guenter Roeck 
> > ---
> > Sorry for the added ifdefs. If anyone has a better idea on how to fix
> > the problems, let me know.
> > 
> > This problem exists in 3.9 as well.
> 
> Does the M5272 not have these registers, or have you simply not added
> defines for where there offsets are in that silicon instance?
> 
> I'd much rather you add the register offset defines than pepper the
> entire driver with ifdefs.
> 
I agree, and that would have been my preferred solution as well.
Unfortunately, according to the user manual (MCF5272 ColdFire
Integrated Microprocessor User's Manual), the registers do not exist
on this chip.

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] firmware loader: fix use-after-free by double abort

[Guenter Roeck]

On Tue, Jun 18, 2013 at 08:33:55AM +0800, Ming Lei wrote:
> On Tue, Jun 18, 2013 at 7:59 AM, Greg Kroah-Hartman
>  wrote:
> > On Sat, Jun 15, 2013 at 04:36:38PM +0800, Ming Lei wrote:
> >> fw_priv->buf is accessed in both request_firmware_load() and
> >> writing to sysfs file of 'loading' context, but not protected
> >> by 'fw_lock' entirely. The patch makes sure that access on
> >> 'fw_priv->buf' is protected by the lock.
> >>
> >> So fixes the double abort problem reported by nirinA raseliarison:
> >>
> >>   http://lkml.org/lkml/2013/6/14/188
> >>
> >> Reported-and-tested-by: nirinA raseliarison 
> >> Cc: Guenter Roeck 
> >> Cc: Bjorn Helgaas 
> >> Cc: stable 
> >> Signed-off-by: Ming Lei 
> >
> > So this is a 3.9-stable thing?  Anything newer than that?
> 
> Yes, only 3.9-stable need this.
> 
I may be missing something, but why would mainline not need it ?
Or do you mean "mainline plus 3.9" ?

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

Re: [GIT PULL] extcon for 3.11

[Chanwoo Choi]

On 06/18/2013 08:03 AM, Greg KH wrote:
> On Mon, Jun 17, 2013 at 04:01:19PM -0700, Greg KH wrote:
>> On Fri, Jun 14, 2013 at 09:39:13PM +0900, Chanwoo Choi wrote:
>>> Hi Greg,
>>>
>>> First of all, I'm so sorry about previous wrong pull-request.
>>> I will be careful and not to make same mistakes
>>>
>>> This is extcon-next pull request for 3.11
>>> Please pull extcon with following updates.
>>>
>>> I combined the patch of small fix and new drivers becasue
>>> 3.10-rc version is large.
>>>
>>> Best Regards,
>>> Chanwoo Choi
>>>
>>> The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10:
>>>
>>>   Linux 3.10-rc5 (2013-06-08 17:41:04 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
>>> tags/extcon-next-for-3.11
>>>
>>> for you to fetch changes up to f7ae906806279e5b57bfd302b945e1bcdddce95b:
>>>
>>>   extcon: Add an API to get extcon device from dt node (2013-06-14 18:36:34 
>>> +0900)
>>>
>>> 
>>> Update extcon for 3.11
>>>
>>> This patchset modify small fix of extcon core driver and add new extcon
>>> driver for Palmas device which is USB tranceiver device. Also, support
>>> OF helper API to get the name of extcon device(producer driver) on extcon
>>> consumer driver.
>>>
>>> Detailed description for patchset:
>>> 1. Modify extcon-class driver
>>> - Change permission 'state' sysfs entry(rw->r)
>>> - Use EXPORT_SYMBOL_GPL for exported functions
>>> - Fix bug null pointer when call extcon_unregister_interest
>>>
>>> 2. Modify Kconfig of extcon
>>> - Change the extcon config type to bool from module. If extcon
>>> is built as module and then extcon consumer driver uses API of,
>>> extcon, compiler happen "undefined reference to" build error.
>>>
>>> 3. Add new extcon driver for Palmas device and OF helper API
>>> - Add new extcon drvier for Palmas which is USB tranceiver device
>>> - Add OF(Open Firmware) Helper API which is of_extcon_get_extcon_dev()
>>>   This helper API get the extcon device name on extcon consumer device.
>>>
>>> 
>>> Chanwoo Choi (1):
>>>   extcon: Change permission 'state' sysfs entry (rw -> r)
>>>
>>> Graeme Gregory (1):
>>>   extcon: Palmas Extcon Driver
>>>
>>> Jonghwa Lee (1):
>>>   extcon: class: Add NULL pointer checking for removing notifier block.
>>>
>>> Kishon Vijay Abraham I (3):
>>>   extcon: Kconfig: Make extcon config type as bool
>>
>> Why is this change made?  Why can't I have the extcon core as a module?
>> What changed to prevent this?
> 
> And hint, I know why you did this, and it's not the correct way, please
> fix it up properly...

OK, I fix this issue by using the following way:
- The extcon consumer driver must have the dependency of CONFIG_EXTCON
on consumer driver's Kconfig. If extcon core is built as module,
all of the extcon consumer driver will be built as moduel too.

Thanks for your comment.

Best Regards,
Chanwoo Choi


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/5] arm: mmp: use matrix_keymap for all boards

[Chao Xie]

Compile passed for the configuration

pxa168_defconfig
  aspenite.c(MACH_ASPENITE), teton_bgs.c(MACH_TENTON_BGA)

Signed-off-by: Chao Xie 
---
 arch/arm/mach-mmp/aspenite.c  |   10 +++---
 arch/arm/mach-mmp/teton_bga.c |   10 +++---
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mmp/aspenite.c b/arch/arm/mach-mmp/aspenite.c
index 9f64d56..1e23346 100644
--- a/arch/arm/mach-mmp/aspenite.c
+++ b/arch/arm/mach-mmp/aspenite.c
@@ -205,7 +205,7 @@ struct pxa168fb_mach_info aspenite_lcd_info = {
.invert_pixclock= 0,
 };
 
-static unsigned int aspenite_matrix_key_map[] = {
+static const unsigned int aspenite_matrix_key_map[] = {
KEY(0, 6, KEY_UP),  /* SW 4 */
KEY(0, 7, KEY_DOWN),/* SW 5 */
KEY(1, 6, KEY_LEFT),/* SW 6 */
@@ -214,11 +214,15 @@ static unsigned int aspenite_matrix_key_map[] = {
KEY(4, 7, KEY_ESC), /* SW 9 */
 };
 
+static struct matrix_keymap_data aspenite_matrix_keymap_data = {
+   .keymap = aspenite_matrix_key_map,
+   .keymap_size= ARRAY_SIZE(aspenite_matrix_key_map),
+};
+
 static struct pxa27x_keypad_platform_data aspenite_keypad_info __initdata = {
.matrix_key_rows= 5,
.matrix_key_cols= 8,
-   .matrix_key_map = aspenite_matrix_key_map,
-   .matrix_key_map_size= ARRAY_SIZE(aspenite_matrix_key_map),
+   .matrix_keymap_data = _matrix_keymap_data,
.debounce_interval  = 30,
 };
 
diff --git a/arch/arm/mach-mmp/teton_bga.c b/arch/arm/mach-mmp/teton_bga.c
index 8609967..2021769 100644
--- a/arch/arm/mach-mmp/teton_bga.c
+++ b/arch/arm/mach-mmp/teton_bga.c
@@ -49,18 +49,22 @@ static unsigned long teton_bga_pin_config[] __initdata = {
GPIO78_GPIO,
 };
 
-static unsigned int teton_bga_matrix_key_map[] = {
+static const unsigned int teton_bga_matrix_key_map[] = {
KEY(0, 6, KEY_ESC),
KEY(0, 7, KEY_ENTER),
KEY(1, 6, KEY_LEFT),
KEY(1, 7, KEY_RIGHT),
 };
 
+static struct matrix_keymap_data teton_bga_matrix_keymap_data = {
+   .keymap = teton_bga_matrix_key_map,
+   .keymap_size= ARRAY_SIZE(teton_bga_matrix_key_map),
+};
+
 static struct pxa27x_keypad_platform_data teton_bga_keypad_info __initdata = {
.matrix_key_rows= 2,
.matrix_key_cols= 8,
-   .matrix_key_map = teton_bga_matrix_key_map,
-   .matrix_key_map_size= ARRAY_SIZE(teton_bga_matrix_key_map),
+   .matrix_keymap_data = _bga_matrix_keymap_data,
.debounce_interval  = 30,
 };
 
-- 
1.7.4.1

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

[PATCH V3 0/5] input: pxa27x-keypad: enhancement and device tree support

[Chao Xie]

The patches include 2 parts
1. use matrix_keypad for matrix keyes support
2. add device tree support for pxa27x-keypad

V2->V1:
Do not copy the members from pdata. For device tree support,
directly allocate the pdata structure.

V3->V2
add matrix_keypad changes for all boards using pxa27x-keypad
under mach-pxa.
The patch "arm: pxa: use matrix_keymap for all boards" is new.
The patch "arm: mmp: use matrix_keymap for all boards" merges
previous changes for aspenite and teton_bga.
All other patches are not modified.

Chao Xie (5):
  input: pxa27x-keypad: use matrix_keymap for matrix keyes
  arm: mmp: use matrix_keymap for all boards
  arm: pxa: use matrix_keymap for all boards
  input: pxa27x-keypad: remove the unused members at platform data
  input: pxa27x-keypad: add device tree support

 .../devicetree/bindings/input/pxa27x-keypad.txt|   60 +
 arch/arm/mach-mmp/aspenite.c   |   10 +-
 arch/arm/mach-mmp/teton_bga.c  |   10 +-
 arch/arm/mach-pxa/em-x270.c|   20 +-
 arch/arm/mach-pxa/ezx.c|   60 +++--
 arch/arm/mach-pxa/littleton.c  |   10 +-
 arch/arm/mach-pxa/mainstone.c  |   10 +-
 arch/arm/mach-pxa/mioa701.c|   11 +-
 arch/arm/mach-pxa/palmld.c |   10 +-
 arch/arm/mach-pxa/palmt5.c |   10 +-
 arch/arm/mach-pxa/palmtreo.c   |   23 ++-
 arch/arm/mach-pxa/palmtx.c |   10 +-
 arch/arm/mach-pxa/palmz72.c|   10 +-
 arch/arm/mach-pxa/tavorevb.c   |   10 +-
 arch/arm/mach-pxa/z2.c |   10 +-
 arch/arm/mach-pxa/zylonite.c   |   10 +-
 drivers/input/keyboard/Kconfig |1 +
 drivers/input/keyboard/pxa27x_keypad.c |  266 ++--
 include/linux/platform_data/keypad-pxa27x.h|3 +-
 19 files changed, 468 insertions(+), 86 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/pxa27x-keypad.txt

-- 
1.7.4.1

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

[PATCH V3 3/5] arm: pxa: use matrix_keymap for all boards

[Chao Xie]

Compile passed for configurations

em_x270_defconfig
  em_x270x.c(MACH_EM_X270, MACH_EXEDA)

ezx_defconfig
  ezx.c(MACH_EZX_A780, MACH_EZX_E680, MACH_EZX_A1200,
MACH_EZX_A910, MACH_EZX_E6, MACH_EZX_E2)

palmz72_defconfig
  palmld.c(MACH_PALMLD), palmtreo.c(PALM_TREO),
  palmtx.c(MACH_PALMTX), palmz72.c(MACH_PALMZ72),
  palmt5.c(MACH_PALMT5)

pxa3xx_defconfig
  littleton.c(MACH_LITTLETON), tarvorevb.c(MACH_TAVOREVB),
  zylonite.c(MACH_ZYLONITE320), mioa701.c(MACH_MIOA701),
  z2.c(MACH_ZIPIT2)

mainstone_defconfig
  maintone.c(MACH_MAINSTONE)

Signed-off-by: Chao Xie 
---
 arch/arm/mach-pxa/em-x270.c   |   20 +
 arch/arm/mach-pxa/ezx.c   |   60 
 arch/arm/mach-pxa/littleton.c |   10 +--
 arch/arm/mach-pxa/mainstone.c |   10 +--
 arch/arm/mach-pxa/mioa701.c   |   11 +--
 arch/arm/mach-pxa/palmld.c|   10 +--
 arch/arm/mach-pxa/palmt5.c|   10 +--
 arch/arm/mach-pxa/palmtreo.c  |   23 ++-
 arch/arm/mach-pxa/palmtx.c|   10 +--
 arch/arm/mach-pxa/palmz72.c   |   10 +--
 arch/arm/mach-pxa/tavorevb.c  |   10 +--
 arch/arm/mach-pxa/z2.c|   10 +--
 arch/arm/mach-pxa/zylonite.c  |   10 +--
 13 files changed, 142 insertions(+), 62 deletions(-)

diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index 446563a..f6726bb 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -833,21 +833,25 @@ static inline void em_x270_init_ac97(void) {}
 #endif
 
 #if defined(CONFIG_KEYBOARD_PXA27x) || defined(CONFIG_KEYBOARD_PXA27x_MODULE)
-static unsigned int em_x270_module_matrix_keys[] = {
+static const unsigned int em_x270_module_matrix_keys[] = {
KEY(0, 0, KEY_A), KEY(1, 0, KEY_UP), KEY(2, 1, KEY_B),
KEY(0, 2, KEY_LEFT), KEY(1, 1, KEY_ENTER), KEY(2, 0, KEY_RIGHT),
KEY(0, 1, KEY_C), KEY(1, 2, KEY_DOWN), KEY(2, 2, KEY_D),
 };
 
+static struct matrix_keymap_data em_x270_matrix_keymap_data = {
+   .keymap = em_x270_module_matrix_keys,
+   .keymap_size= ARRAY_SIZE(em_x270_module_matrix_keys),
+};
+
 struct pxa27x_keypad_platform_data em_x270_module_keypad_info = {
/* code map for the matrix keys */
.matrix_key_rows= 3,
.matrix_key_cols= 3,
-   .matrix_key_map = em_x270_module_matrix_keys,
-   .matrix_key_map_size= ARRAY_SIZE(em_x270_module_matrix_keys),
+   .matrix_keymap_data = _x270_matrix_keymap_data,
 };
 
-static unsigned int em_x270_exeda_matrix_keys[] = {
+static const unsigned int em_x270_exeda_matrix_keys[] = {
KEY(0, 0, KEY_RIGHTSHIFT), KEY(0, 1, KEY_RIGHTCTRL),
KEY(0, 2, KEY_RIGHTALT), KEY(0, 3, KEY_SPACE),
KEY(0, 4, KEY_LEFTALT), KEY(0, 5, KEY_LEFTCTRL),
@@ -889,12 +893,16 @@ static unsigned int em_x270_exeda_matrix_keys[] = {
KEY(7, 6, 0), KEY(7, 7, 0),
 };
 
+static struct matrix_keymap_data em_x270_exeda_matrix_keymap_data = {
+   .keymap = em_x270_exeda_matrix_keys,
+   .keymap_size= ARRAY_SIZE(em_x270_exeda_matrix_keys),
+};
+
 struct pxa27x_keypad_platform_data em_x270_exeda_keypad_info = {
/* code map for the matrix keys */
.matrix_key_rows= 8,
.matrix_key_cols= 8,
-   .matrix_key_map = em_x270_exeda_matrix_keys,
-   .matrix_key_map_size= ARRAY_SIZE(em_x270_exeda_matrix_keys),
+   .matrix_keymap_data = _x270_exeda_matrix_keymap_data,
 };
 
 static void __init em_x270_init_keypad(void)
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index dca1070..fe2eb83 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -392,7 +392,7 @@ static unsigned long e6_pin_config[] __initdata = {
 
 /* KEYPAD */
 #ifdef CONFIG_MACH_EZX_A780
-static unsigned int a780_key_map[] = {
+static const unsigned int a780_key_map[] = {
KEY(0, 0, KEY_SEND),
KEY(0, 1, KEY_BACK),
KEY(0, 2, KEY_END),
@@ -424,11 +424,15 @@ static unsigned int a780_key_map[] = {
KEY(4, 4, KEY_DOWN),
 };
 
+static struct matrix_keymap_data a780_matrix_keymap_data = {
+   .keymap = a780_key_map,
+   .keymap_size= ARRAY_SIZE(a780_key_map),
+};
+
 static struct pxa27x_keypad_platform_data a780_keypad_platform_data = {
.matrix_key_rows = 5,
.matrix_key_cols = 5,
-   .matrix_key_map = a780_key_map,
-   .matrix_key_map_size = ARRAY_SIZE(a780_key_map),
+   .matrix_keymap_data = _matrix_keymap_data,
 
.direct_key_map = { KEY_CAMERA },
.direct_key_num = 1,
@@ -438,7 +442,7 @@ static struct pxa27x_keypad_platform_data 
a780_keypad_platform_data = {
 #endif /* CONFIG_MACH_EZX_A780 */
 
 #ifdef CONFIG_MACH_EZX_E680
-static unsigned int e680_key_map[] = {
+static const unsigned int e680_key_map[] = {
KEY(0, 0, KEY_UP),
KEY(0, 1, KEY_RIGHT),
KEY(0, 2, KEY_RESERVED),
@@ -455,11 +459,15 @@ 

[PATCH V3 5/5] input: pxa27x-keypad: add device tree support

[Chao Xie]

Signed-off-by: Chao Xie 
---
 .../devicetree/bindings/input/pxa27x-keypad.txt|   60 +
 drivers/input/keyboard/pxa27x_keypad.c |  232 +++-
 2 files changed, 288 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/pxa27x-keypad.txt

diff --git a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt 
b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
new file mode 100644
index 000..f8674f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
@@ -0,0 +1,60 @@
+* Marvell PXA Keypad controller
+
+Required Properties
+- compatible : should be "marvell,pxa27x-keypad"
+- reg : Address and length of the register set for the device
+- interrupts : The interrupt for the keypad controller
+- marvell,debounce-interval : How long time the key will be
+  recognized when it is pressed. It is a u32 value, and bit[31:16]
+  is debounce interval for direct key and bit[15:0] is debounce
+  interval for matrix key. The value is in binary number of 2ms
+
+Optional Properties For Matrix Keyes
+Please refer to matrix-keymap.txt
+
+Optional Properties for Direct Keyes
+- marvell,direct-key-count : How many direct keyes are used.
+- marvell,direct-key-mask : The mask indicates which keyes
+  are used. If bit[X] of the mask is set, the direct key X
+  is used.
+- marvell,direct-key-low-active : Direct key status register
+  tells the level of pins that connects to the direct keyes.
+  When this property is set, it means that when the pin level
+  is low, the key is pressed(active).
+- marvell,direct-key-map : It is a u16 array. Each item indicates
+  the linux key-code for the direct key.
+
+Optional Properties For Rotary
+- marvell,rotary0 : It is a u32 value. Bit[31:16] is the
+  linux key-code for rotary up. Bit[15:0] is the linux key-code
+  for rotary down. It is for rotary 0.
+- marvell,rotary1 : Same as marvell,rotary0. It is for rotary 1.
+- marvell,rotary-rel-key : When rotary is used for relative axes
+  in the device, the value indicates the key-code for relative
+  axes measurement in the device. It is a u32 value. Bit[31:16]
+  is for rotary 1, and Bit[15:0] is for rotary 0.
+
+Examples:
+   keypad: keypad@d4012000 {
+   keypad,num-rows = <3>;
+   keypad,num-columns = <5>;
+   linux,keymap = <0x000e  /* KEY_BACKSPACE */
+   0x0001006b  /* KEY_END */
+   0x00020061  /* KEY_RIGHTCTRL */
+   0x0003000b  /* KEY_0 */
+   0x00040002  /* KEY_1 */
+   0x018b  /* KEY_MENU */
+   0x01010066  /* KEY_HOME */
+   0x010200e7  /* KEY_SEND */
+   0x01030009  /* KEY_8 */
+   0x0104000a  /* KEY_9 */
+   0x02000160  /* KEY_OK */
+   0x02010003  /* KEY_2 */
+   0x02020004  /* KEY_3 */
+   0x02030005  /* KEY_4 */
+   0x02040006>;/* KEY_5 */
+   marvell,rotary0 = <0x006c0067>; /* KEY_UP & KEY_DOWN */
+   marvell,direct-key-count = <1>;
+   marvell,direct-key-map = <0x001c>;
+   marvell,debounce-interval = <0x001e001e>;
+   };
diff --git a/drivers/input/keyboard/pxa27x_keypad.c 
b/drivers/input/keyboard/pxa27x_keypad.c
index 947d657..16cf9a5 100644
--- a/drivers/input/keyboard/pxa27x_keypad.c
+++ b/drivers/input/keyboard/pxa27x_keypad.c
@@ -118,6 +118,217 @@ struct pxa27x_keypad {
unsigned int direct_key_mask;
 };
 
+static int pxa27x_keypad_matrix_key_parse_dt(struct pxa27x_keypad *keypad)
+{
+   int ret;
+   u32 rows, cols;
+   struct input_dev *input_dev = keypad->input_dev;
+   struct device *dev = input_dev->dev.parent;
+   struct pxa27x_keypad_platform_data *pdata = keypad->pdata;
+
+   ret = matrix_keypad_parse_of_params(dev, , );
+   if (ret)
+   return ret;
+
+   if (rows > MAX_MATRIX_KEY_ROWS || cols > MAX_MATRIX_KEY_COLS) {
+   dev_err(dev, "rows or cols exceeds maximum value\n");
+   return -EINVAL;
+   }
+
+   pdata->matrix_key_rows = rows;
+   pdata->matrix_key_cols = cols;
+
+   ret = matrix_keypad_build_keymap(NULL, NULL,
+pdata->matrix_key_rows,
+pdata->matrix_key_cols,
+keypad->keycodes, input_dev);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int pxa27x_keypad_direct_key_parse_dt(struct pxa27x_keypad *keypad)
+{
+   const __be16 *prop;
+   unsigned short code;
+   int i, ret;
+   unsigned int proplen, size;
+ 

[PATCH V3 4/5] input: pxa27x-keypad: remove the unused members at platform data

[Chao Xie]

Now pxa27x-keypad make use matrix_keymap for matrix keyes, so
remove the unused members in platform data.

Signed-off-by: Chao Xie 
---
 include/linux/platform_data/keypad-pxa27x.h |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/linux/platform_data/keypad-pxa27x.h 
b/include/linux/platform_data/keypad-pxa27x.h
index 0db423b..2462556 100644
--- a/include/linux/platform_data/keypad-pxa27x.h
+++ b/include/linux/platform_data/keypad-pxa27x.h
@@ -39,8 +39,6 @@ struct pxa27x_keypad_platform_data {
const struct matrix_keymap_data *matrix_keymap_data;
unsigned intmatrix_key_rows;
unsigned intmatrix_key_cols;
-   unsigned int*matrix_key_map;
-   int matrix_key_map_size;
 
/* direct keys */
int direct_key_num;
-- 
1.7.4.1

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

[PATCH V3 1/5] input: pxa27x-keypad: use matrix_keymap for matrix keyes

[Chao Xie]

pxa27x-keypad includes matrix keyes. Make use of matrix_keymap
for the matrix keyes.

Signed-off-by: Chao Xie 
---
 drivers/input/keyboard/Kconfig  |1 +
 drivers/input/keyboard/pxa27x_keypad.c  |   36 +-
 include/linux/platform_data/keypad-pxa27x.h |1 +
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 37c3666..706e11b 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -451,6 +451,7 @@ config KEYBOARD_OPENCORES
 config KEYBOARD_PXA27x
tristate "PXA27x/PXA3xx keypad support"
depends on PXA27x || PXA3xx || ARCH_MMP
+   select INPUT_MATRIXKMAP
help
  Enable support for PXA27x/PXA3xx keypad controller.
 
diff --git a/drivers/input/keyboard/pxa27x_keypad.c 
b/drivers/input/keyboard/pxa27x_keypad.c
index b674e7a..947d657 100644
--- a/drivers/input/keyboard/pxa27x_keypad.c
+++ b/drivers/input/keyboard/pxa27x_keypad.c
@@ -118,25 +118,29 @@ struct pxa27x_keypad {
unsigned int direct_key_mask;
 };
 
-static void pxa27x_keypad_build_keycode(struct pxa27x_keypad *keypad)
+static int pxa27x_keypad_build_keycode(struct pxa27x_keypad *keypad)
 {
struct pxa27x_keypad_platform_data *pdata = keypad->pdata;
struct input_dev *input_dev = keypad->input_dev;
unsigned short keycode;
-   int i;
+   int ret, i;
+   const struct matrix_keymap_data *keymap_data =
+   pdata ? pdata->matrix_keymap_data : NULL;
 
-   for (i = 0; i < pdata->matrix_key_map_size; i++) {
-   unsigned int key = pdata->matrix_key_map[i];
-   unsigned int row = KEY_ROW(key);
-   unsigned int col = KEY_COL(key);
-   unsigned int scancode = MATRIX_SCAN_CODE(row, col,
-MATRIX_ROW_SHIFT);
+   ret = matrix_keypad_build_keymap(keymap_data, NULL,
+pdata->matrix_key_rows,
+pdata->matrix_key_cols,
+keypad->keycodes, input_dev);
+   if (ret)
+   return ret;
 
-   keycode = KEY_VAL(key);
-   keypad->keycodes[scancode] = keycode;
-   __set_bit(keycode, input_dev->keybit);
-   }
+   /*
+* The keycodes may not only includes matrix key but also the direct
+* key or rotary key.
+*/
+   input_dev->keycodemax = ARRAY_SIZE(keypad->keycodes);
 
+   /* For direct key. */
for (i = 0; i < pdata->direct_key_num; i++) {
keycode = pdata->direct_key_map[i];
keypad->keycodes[MAX_MATRIX_KEY_NUM + i] = keycode;
@@ -178,6 +182,8 @@ static void pxa27x_keypad_build_keycode(struct 
pxa27x_keypad *keypad)
}
 
__clear_bit(KEY_RESERVED, input_dev->keybit);
+
+   return 0;
 }
 
 static void pxa27x_keypad_scan_matrix(struct pxa27x_keypad *keypad)
@@ -555,7 +561,11 @@ static int pxa27x_keypad_probe(struct platform_device 
*pdev)
input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
input_set_capability(input_dev, EV_MSC, MSC_SCAN);
 
-   pxa27x_keypad_build_keycode(keypad);
+   error  = pxa27x_keypad_build_keycode(keypad);
+   if (error) {
+   dev_err(>dev, "failed to build keycode\n");
+   goto failed_put_clk;
+   }
 
if ((pdata->enable_rotary0 && keypad->rotary_rel_code[0] != -1) ||
(pdata->enable_rotary1 && keypad->rotary_rel_code[1] != -1)) {
diff --git a/include/linux/platform_data/keypad-pxa27x.h 
b/include/linux/platform_data/keypad-pxa27x.h
index 5ce8d5e6..0db423b 100644
--- a/include/linux/platform_data/keypad-pxa27x.h
+++ b/include/linux/platform_data/keypad-pxa27x.h
@@ -36,6 +36,7 @@
 struct pxa27x_keypad_platform_data {
 
/* code map for the matrix keys */
+   const struct matrix_keymap_data *matrix_keymap_data;
unsigned intmatrix_key_rows;
unsigned intmatrix_key_cols;
unsigned int*matrix_key_map;
-- 
1.7.4.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 V5 1/3] pci: Add PCIe driver for Samsung Exynos

[Jingoo Han]

On Monday, June 17, 2013 9:45 PM, Arnd Bergmann wrote:
> On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
> > On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
> > >
> > > Please look up the documentation about inbound viewport and describe
> > > in a code comment what it does. I /assume/ that this is how DMA accesses
> > > from the bus get translated into AXI bus transactions. If so, you have
> > > to let the window translate addresses from RAM. If it's something else,
> > > then you should document what it is and how it needs to be set up.
> >
> > One of our hardware engineer confirmed it.
> > He said that these inbound functions are unnecessary.
> > Also, I checked that PCIe works properly without these functions.
> > So, I will remove these inbound functions.
> 
> Ok, good. So DMA just gets translated 1:1 independent of the
> inbound viewport? Have you tested this with PCI device using
> DMA?

According to our hardware engineer,
He said that
"That's correct. We tested it by doing a memory write from the device.
A device DMA is a series of memory r/w so I expect it to work same way."

Also, he thought that I already tested too, since it works after removing
the functions.

> 
> > static int exynos_pcie_setup(int nr, struct pci_sys_data *sys)
> > {
> > struct pcie_port *pp;
> >
> > pp = sys_to_pcie(sys);
> >
> > if (!pp)
> > return 0;
> >
> > if (global_io_offset < SZ_1M && pp->config.io_size > 0) {
> > sys->io_offset = global_io_offset - pp->config.io_bus_addr; /* 
> > normally 0 */
> > pci_ioremap_io(sys->io_offset, pp->io.start);
> > global_io_offset += SZ_64K;
> > }
> >
> > sys->mem_offset = pp->mem.start - pp->config.mem_bus_addr; /* normally 
> > 0 */
> >
> > pci_add_resource_offset(>resources, >io, sys->io_offset);
> > pci_add_resource_offset(>resources, >mem, sys->mem_offset);
> >
> > return 1;
> > }
> 
> This is what I meant, yes.
> 
> > In this case, boot message is as below:
> >
> > PCI host bridge to bus :00
> > pci_bus :00: root bus resource [io  0x40001000-0x40010fff]
> > pci_bus :00: root bus resource [mem 0x40011000-0x5fff]
> > pci_bus :00: No busn resource found for root bus, will use [bus 00-ff]
> > pci :00:00.0: [144d:a549] type 01 class 0x060400
> > [.]
> > PCI host bridge to bus 0001:00
> > pci_bus 0001:00: root bus resource [io  0x60001000-0x60010fff] (bus address 
> > [0x5fff1000-0x6000
> > 0fff])
> > pci_bus 0001:00: root bus resource [mem 0x60011000-0x7fff]
> > pci_bus 0001:00: No busn resource found for root bus, will use [bus 00-ff]
> > pci 0001:00:00.0: [144d:a549] type 01 class 0x060400
> 
> The io resources here look wrong. I would have expected
> 
> pci_bus :00: root bus resource [io  0x001000-0x00]
> pci_bus 0001:00: root bus resource [io  0x01-0x01] (bus address 
> [0x00-0x00])
> 
> Please have a look at the pci-mvebu driver and how it calculates its
> 'realio' resource.

I looked at the pci-mvebu driver,
Then I fixed it as the pci-mvebu driver did.
Also, I added 'global_io_offset'.

@@ -909,6 +909,12 @@ static int __init exynos_pcie_probe(struct platform_device 
*pdev)
if (restype == IORESOURCE_IO) {
of_pci_range_to_resource(, np, >io);
pp->io.name = "I/O";
+   pp->io.start = max_t(resource_size_t,
+   PCIBIOS_MIN_IO,
+   range.pci_addr + 
global_io_offset);
+   pp->io.end = min_t(resource_size_t,
+   IO_SPACE_LIMIT,
+   range.pci_addr + range.size + 
global_io_offset);
pp->config.io_size = resource_size(>io);
pp->config.io_bus_addr = range.pci_addr;

In this case, boot message is as below:

PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x1000-0x1]
pci_bus :00: root bus resource [mem 0x40011000-0x5fff]
[.]
PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [io  0x1-0x2] (bus address 
[0x-0x1])
pci_bus 0001:00: root bus resource [mem 0x60011000-0x7fff]



> 
> > > > > > +static int __exit exynos_pcie_remove(struct platform_device *pdev)
> > > > > > +{
> > > > > > +   struct pcie_port *pp = platform_get_drvdata(pdev);
> > > > > > +
> > > > > > +   clk_disable_unprepare(pp->bus_clk);
> > > > > > +   clk_disable_unprepare(pp->clk);
> > > > > > +
> > > > > > +   return 0;
> > > > > > +}
> > > > >
> > > > > You also don't remove the PCI devices here, as mentioned in an earlier
> > > > > review.
> > > >
> > > > I reviewed Marvell PCIe driver and Tegra PCIe driver; however,
> > > > I cannot know what you mean.
> > > >
> > > > Could let me know which additional functions are needed?
> > >
> > > The mvebu driver does not allow module 

Re: [patch v8 6/9] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task

[Alex Shi]

On 06/18/2013 07:00 AM, Paul Turner wrote:
> On Mon, Jun 17, 2013 at 6:57 AM, Alex Shi  wrote:
>> > On 06/17/2013 08:17 PM, Paul Turner wrote:
>>> >> On Mon, Jun 17, 2013 at 3:51 AM, Paul Turner  wrote:
 >>> On Fri, Jun 7, 2013 at 12:20 AM, Alex Shi  wrote:
>  They are the base values in load balance, update them with rq 
>  runnable
>  load average, then the load balance will consider runnable load avg
>  naturally.
> 
>  We also try to include the blocked_load_avg as cpu load in balancing,
>  but that cause kbuild performance drop 6% on every Intel machine, and
>  aim7/oltp drop on some of 4 CPU sockets machines.
> 
 >>>
 >>> This looks fine.
 >>>
 >>> Did you try including blocked_load_avg in only get_rq_runnable_load()
 >>> [ and not weighted_cpuload() which is called by new-idle ]?
>>> >>
>>> >> Looking at this more this feels less correct since you're taking
>>> >> averages of averages.
>>> >>
>>> >> This was previously discussed at:
>>> >>   https://lkml.org/lkml/2013/5/6/109
>>> >>
>>> >> And  you later replied suggesting this didn't seem to hurt; what's the
>>> >> current status there?
>> >
>> > Yes, your example show the blocked_load_avg value.
>> > So I had given a patch for review at that time before do detailed
>> > testing. https://lkml.org/lkml/2013/5/7/66
>> >
>> > But in detailed testing, the patch cause a big performance regression.
>> > When I look into for details. I found some cpu in kbuild just had a big
>> > blocked_load_avg, with a very small runnable_load_avg value.
>> >
>> > Seems accumulating current blocked_load_avg into cpu load isn't a good
>> > idea. Because:
> So I think this describes an alternate implementation to the one suggested in:
>   https://lkml.org/lkml/2013/5/7/66
> 
> Specifically, we _don't_ want to accumulate into cpu-load.  Taking an
> "average of the average" loses the mobility that the new
> representation allows.
> 
>> > 1, The blocked_load_avg is decayed same as runnable load, sometime is
>> > far bigger than runnable load, that drive tasks to other idle or slight
>> > load cpu, than cause both performance and power issue. But if the
>> > blocked load is decayed too fast, it lose its effect.
> This is why the idea would be to use an instantaneous load in
> weighted_cpuload() and one that incorporated averages on (wants a
> rename) get_rq_runnable_load().
> 
> For non-instaneous load-indexes we're pulling for stability.

Paul, could I summary your point here:
keep current weighted_cpu_load, but add blocked load avg in
get_rq_runnable_load?

I will test this change.
> 
>> > 2, Another issue of blocked load is that when waking up task, we can not
>> > know blocked load proportion of the task on rq. So, the blocked load is
>> > meaningless in wake affine decision.
> I think this is confusing two things:
> 
> (a) A wake-idle wake-up
> (b) A wake-affine wake-up

what's I mean the wake affine is (b). Anyway, blocked load is no help on
the scenario.
> 
> In (a) we do not care about the blocked load proportion, only whether
> a cpu is idle.
> 
> But once (a) has failed we should absolutely care how much load is
> blocked in (b) as:
> - We know we're going to queue for bandwidth on the cpu [ otherwise
> we'd be in (a) ]
> - Blocked load predicts how much _other_ work is expected to also
> share the queue with us during the quantum
> 


-- 
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] tracing/kprobes: Kill probe_enable_lock

[Masami Hiramatsu]

(2013/06/18 0:18), Oleg Nesterov wrote:
>> because
>> those calls are the reason why I have introduced this lock.
> 
> Please do not hesitate to nack this patch if you think that we should
> keep probe_enable_lock for safety even if it is not currently needed.
> In this case I'd suggest to move lock/unlock into kprobe_register()
> but this is minor.

Oh, I agree with removing probe_enable_lock itself :)
I just concerned only about the exceptional case of __init test
function, which can mislead someone to use enable/disable_trace_probe
at other racy point.

Thank you,

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


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

Re: [PATCH v3] arch/*/asm/include/bitops.h: api issue, find_*_bit() defination are different with each other

[Chen Gang]

Hello related Maintainers:

Please help check this patch when you have time.

Thanks.

On 06/06/2013 05:37 PM, Chen Gang wrote:
> 
> For arm and m68k, they customize find_*_bit(), but the API is different
> with 'generic'.
> 
> avr32, s390, and unicore32 also customize find_*_bit(), but the API is
> the same with 'generic', and the left architectures all use 'generic'.
> 
> So need change arm and m68k related API to match the 'generic', then
> all another modules can face same public API for various architectures.
> 
> Also beautify code and comments to pass "./scripts/checkpatch.pl"
> 
> 
> Signed-off-by: Chen Gang 
> ---
>  arch/arm/include/asm/bitops.h  |   26 ++
>  arch/arm/lib/findbit.S |   14 ++
>  arch/m68k/include/asm/bitops.h |   25 ++---
>  3 files changed, 42 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
> index e691ec9..83e4d3a 100644
> --- a/arch/arm/include/asm/bitops.h
> +++ b/arch/arm/include/asm/bitops.h
> @@ -161,18 +161,28 @@ extern int _test_and_change_bit(int nr, volatile 
> unsigned long * p);
>  /*
>   * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
>   */
> -extern int _find_first_zero_bit_le(const void * p, unsigned size);
> -extern int _find_next_zero_bit_le(const void * p, int size, int offset);
> -extern int _find_first_bit_le(const unsigned long *p, unsigned size);
> -extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
> +extern unsigned long _find_first_zero_bit_le(const void *p,
> + unsigned long size);
> +extern unsigned long _find_next_zero_bit_le(const void *p, unsigned long 
> size,
> + unsigned long offset);
> +extern unsigned long _find_first_bit_le(const unsigned long *p,
> + unsigned long size);
> +extern unsigned long _find_next_bit_le(const unsigned long *p,
> + unsigned long size,
> + unsigned long offset);
>  
>  /*
>   * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
>   */
> -extern int _find_first_zero_bit_be(const void * p, unsigned size);
> -extern int _find_next_zero_bit_be(const void * p, int size, int offset);
> -extern int _find_first_bit_be(const unsigned long *p, unsigned size);
> -extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
> +extern unsigned long _find_first_zero_bit_be(const void *p,
> + unsigned long size);
> +extern unsigned long _find_next_zero_bit_be(const void *p, unsigned long 
> size,
> + unsigned long offset);
> +extern unsigned long _find_first_bit_be(const unsigned long *p,
> + unsigned long size);
> +extern unsigned long _find_next_bit_be(const unsigned long *p,
> + unsigned long size,
> + unsigned long offset);
>  
>  #ifndef CONFIG_SMP
>  /*
> diff --git a/arch/arm/lib/findbit.S b/arch/arm/lib/findbit.S
> index 64f6bc1..817dd70 100644
> --- a/arch/arm/lib/findbit.S
> +++ b/arch/arm/lib/findbit.S
> @@ -19,7 +19,8 @@
>  
>  /*
>   * Purpose  : Find a 'zero' bit
> - * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
> + * Prototype: unsigned long find_first_zero_bit(const void *p,
> + *   unsigned long size);
>   */
>  ENTRY(_find_first_zero_bit_le)
>   teq r1, #0  
> @@ -40,7 +41,9 @@ ENDPROC(_find_first_zero_bit_le)
>  
>  /*
>   * Purpose  : Find next 'zero' bit
> - * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int 
> offset)
> + * Prototype: unsigned long find_next_zero_bit(const void *p,
> + *   unsigned long size,
> + *   unsigned long offset);
>   */
>  ENTRY(_find_next_zero_bit_le)
>   teq r1, #0
> @@ -60,7 +63,8 @@ ENDPROC(_find_next_zero_bit_le)
>  
>  /*
>   * Purpose  : Find a 'one' bit
> - * Prototype: int find_first_bit(const unsigned long *addr, unsigned int 
> maxbit);
> + * Prototype: unsigned long find_first_bit(const unsigned long *p,
> + *   unsigned long size);
>   */
>  ENTRY(_find_first_bit_le)
>   teq r1, #0  
> @@ -81,7 +85,9 @@ ENDPROC(_find_first_bit_le)
>  
>  /*
>   * Purpose  : Find next 'one' bit
> - * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int 
> offset)
> + * Prototype: unsigned long find_next_bit(const unsigned long *p,
> + *   unsigned long size,
> + *   unsigned long offset);
>   */
>  ENTRY(_find_next_bit_le)
>   teq r1, #0
> diff 

[PATCH 3/4] Staging: silicom: move assignments out of if conditions

[Chad Williamson]

Remove a bunch of assignments from if-statement conditions in
bpctl_mod.c, resolving checkpatch.pl errors. (This isn't all of
them, but the patch is getting rather long...)

Signed-off-by: Chad Williamson 
---
 drivers/staging/silicom/bpctl_mod.c | 54 +++--
 1 file changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/silicom/bpctl_mod.c 
b/drivers/staging/silicom/bpctl_mod.c
index 893737a..19a9239 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -306,7 +306,8 @@ static void write_pulse(bpctl_dev_t *pbpctl_dev,
ctrl = BP10G_READ_REG(pbpctl_dev, ESDP);
 
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return;
ctrl = BP10G_READ_REG(pbpctl_dev_c, ESDP);
}
@@ -606,7 +607,8 @@ static int read_pulse(bpctl_dev_t *pbpctl_dev, unsigned int 
ctrl_ext,
if (pbpctl_dev->bp_540)
ctrl = BP10G_READ_REG(pbpctl_dev, ESDP);
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return -1;
ctrl = BP10G_READ_REG(pbpctl_dev_c, ESDP);
}
@@ -774,7 +776,8 @@ static void write_reg(bpctl_dev_t *pbpctl_dev, unsigned 
char value,
bpctl_dev_t *pbpctl_dev_c = NULL;
unsigned long flags;
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return;
}
if ((pbpctl_dev->wdt_status == WDT_STATUS_EN) &&
@@ -952,7 +955,8 @@ static int read_reg(bpctl_dev_t *pbpctl_dev, unsigned char 
addr)
atomic_set(_dev->wdt_busy, 1);
 #endif
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return -1;
}
 
@@ -1223,7 +1227,8 @@ static int wdt_pulse(bpctl_dev_t *pbpctl_dev)
return -1;
 #endif
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return -1;
}
 
@@ -1743,7 +1748,8 @@ static int write_data_int(bpctl_dev_t *pbpctl_dev, 
unsigned char value)
 {
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if (!(pbpctl_dev_b = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
return -1;
atomic_set(_dev->wdt_busy, 1);
write_data_port_int(pbpctl_dev, value & 0x3);
@@ -1961,7 +1967,8 @@ int tpl_hw_on(bpctl_dev_t *pbpctl_dev)
int ret = 0, ctrl = 0;
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if (!(pbpctl_dev_b = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
return BP_NOT_CAP;
 
if (pbpctl_dev->bp_caps_ex & TPL2_CAP_EX) {
@@ -1988,7 +1995,8 @@ int tpl_hw_off(bpctl_dev_t *pbpctl_dev)
int ret = 0, ctrl = 0;
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if (!(pbpctl_dev_b = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
return BP_NOT_CAP;
if (pbpctl_dev->bp_caps_ex & TPL2_CAP_EX) {
cmnd_on(pbpctl_dev);
@@ -3231,8 +3239,10 @@ int bypass_from_last_read(bpctl_dev_t *pbpctl_dev)
uint32_t ctrl_ext = 0;
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if ((pbpctl_dev->bp_caps & SW_CTL_CAP)
-   && (pbpctl_dev_b = get_status_port_fn(pbpctl_dev))) {
+   if (pbpctl_dev->bp_caps & SW_CTL_CAP) {
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
+   return BP_NOT_CAP;
ctrl_ext = BPCTL_READ_REG(pbpctl_dev_b, CTRL_EXT);
BPCTL_BP_WRITE_REG(pbpctl_dev_b, CTRL_EXT,
   (ctrl_ext & ~BPCTLI_CTRL_EXT_SDP7_DIR));
@@ -3248,9 +3258,10 @@ int bypass_status_clear(bpctl_dev_t *pbpctl_dev)
 {
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if ((pbpctl_dev->bp_caps & SW_CTL_CAP)
-   && (pbpctl_dev_b = get_status_port_fn(pbpctl_dev))) {
-
+   if (pbpctl_dev->bp_caps & SW_CTL_CAP) {
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
+   return BP_NOT_CAP;
send_bypass_clear_pulse(pbpctl_dev_b, 1);
return 

[PATCH 1/4] Staging: silicom: remove unnecessary braces in bpctl_mod.c

[Chad Williamson]

Remove unnecessary braces in bpctl_mod.c, resolving checkpatch.pl
warnings.

Signed-off-by: Chad Williamson 
---
 drivers/staging/silicom/bpctl_mod.c | 58 +++--
 1 file changed, 23 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/silicom/bpctl_mod.c 
b/drivers/staging/silicom/bpctl_mod.c
index 4c8fb86..c09dc02 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -720,16 +720,15 @@ static int read_pulse(bpctl_dev_t *pbpctl_dev, unsigned 
int ctrl_ext,
 BP10G_MDIO_DATA_OUT));
 
}
-   if (pbpctl_dev->bp_10g9) {
-   ctrl_ext = BP10G_READ_REG(pbpctl_dev, I2CCTL);
 
-   } else if ((pbpctl_dev->bp_fiber5) || (pbpctl_dev->bp_i80)) {
+   if (pbpctl_dev->bp_10g9)
+   ctrl_ext = BP10G_READ_REG(pbpctl_dev, I2CCTL);
+   else if ((pbpctl_dev->bp_fiber5) || (pbpctl_dev->bp_i80))
ctrl_ext = BPCTL_READ_REG(pbpctl_dev, CTRL);
-   } else if (pbpctl_dev->bp_540) {
+   else if (pbpctl_dev->bp_540)
ctrl_ext = BP10G_READ_REG(pbpctl_dev, ESDP);
-   } else if (pbpctl_dev->bp_10gb)
+   else if (pbpctl_dev->bp_10gb)
ctrl_ext = BP10GB_READ_REG(pbpctl_dev, MISC_REG_SPIO);
-
else if (!pbpctl_dev->bp_10g)
ctrl_ext = BPCTL_READ_REG(pbpctl_dev, CTRL_EXT);
else
@@ -1920,13 +1919,10 @@ int disc_port_on(bpctl_dev_t *pbpctl_dev)
return BP_NOT_CAP;
 
if (pbpctl_dev_m->bp_caps_ex & DISC_PORT_CAP_EX) {
-   if (is_bypass_fn(pbpctl_dev) == 1) {
-
+   if (is_bypass_fn(pbpctl_dev) == 1)
write_data(pbpctl_dev_m, TX_DISA);
-   } else {
-
+   else
write_data(pbpctl_dev_m, TX_DISB);
-   }
 
msec_delay_bp(LATCH_DELAY);
 
@@ -2017,9 +2013,9 @@ int wdt_off(bpctl_dev_t *pbpctl_dev)
int ret = BP_NOT_CAP;
 
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
-   if (INTEL_IF_SERIES(pbpctl_dev->subdevice)) {
+   if (INTEL_IF_SERIES(pbpctl_dev->subdevice))
bypass_off(pbpctl_dev);
-   } else if (pbpctl_dev->bp_ext_ver >= PXG2BPI_VER)
+   else if (pbpctl_dev->bp_ext_ver >= PXG2BPI_VER)
write_data(pbpctl_dev, WDT_OFF);
else
data_pulse(pbpctl_dev, WDT_OFF);
@@ -2404,12 +2400,10 @@ static int set_tx(bpctl_dev_t *pbpctl_dev, int tx_state)
}
 
}
-   if (pbpctl_dev->bp_fiber5) {
+   if (pbpctl_dev->bp_fiber5)
ctrl = BPCTL_READ_REG(pbpctl_dev, CTRL_EXT);
-
-   } else if (pbpctl_dev->bp_10gb)
+   else if (pbpctl_dev->bp_10gb)
ctrl = BP10GB_READ_REG(pbpctl_dev, MISC_REG_GPIO);
-
else if (!pbpctl_dev->bp_10g)
ctrl = BPCTL_READ_REG(pbpctl_dev, CTRL);
else
@@ -4054,9 +4048,8 @@ void bypass_caps_init(bpctl_dev_t *pbpctl_dev)
pbpctl_dev->bp_caps |=
(TX_CTL_CAP | TX_STATUS_CAP | TPL_CAP);
 
-   if (TPL_IF_SERIES(pbpctl_dev->subdevice)) {
+   if (TPL_IF_SERIES(pbpctl_dev->subdevice))
pbpctl_dev->bp_caps |= TPL_CAP;
-   }
 
if (INTEL_IF_SERIES(pbpctl_dev->subdevice)) {
pbpctl_dev->bp_caps |=
@@ -4196,9 +4189,9 @@ void bypass_caps_init(bpctl_dev_t *pbpctl_dev)
if (PEG5_IF_SERIES(pbpctl_dev->subdevice))
pbpctl_dev->bp_caps |= (TX_CTL_CAP | TX_STATUS_CAP);
 
-   if (BP10GB_IF_SERIES(pbpctl_dev->subdevice)) {
+   if (BP10GB_IF_SERIES(pbpctl_dev->subdevice))
pbpctl_dev->bp_caps &= ~(TX_CTL_CAP | TX_STATUS_CAP);
-   }
+
pbpctl_dev_m = get_master_port_fn(pbpctl_dev);
if (pbpctl_dev_m != NULL) {
int cap_reg = 0;
@@ -4327,10 +4320,9 @@ int set_bypass_wd_auto(bpctl_dev_t *pbpctl_dev, unsigned 
int param)
 
 int get_bypass_wd_auto(bpctl_dev_t *pbpctl_dev)
 {
-
-   if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
+   if (pbpctl_dev->bp_caps & WD_CTL_CAP)
return pbpctl_dev->reset_time;
-   }
+
return BP_NOT_CAP;
 }
 
@@ -5036,23 +5028,19 @@ static void bp_tpl_timer_fn(unsigned long param)
 
link2 = get_bypass_link_status(pbpctl_dev_b);
if ((link1) && (tx_status(pbpctl_dev))) {
-   if ((!link2) && (tx_status(pbpctl_dev_b))) {
+   if ((!link2) && (tx_status(pbpctl_dev_b)))
set_tx(pbpctl_dev, 0);
-   } else if (!tx_status(pbpctl_dev_b)) {
+   else if (!tx_status(pbpctl_dev_b))
  

[PATCH 0/4] Staging: silicom: coding style cleanup

[Chad Williamson]

More coding style cleanup in bpctl_mod.c, resolving many checkpatch.pl
warnings and errors. I've skipped a number of issues in functions that
are going to need to be split up/rewritten anyway, etc. Tearing out the
new typedefs is next on my todo list...

Chad Williamson (4):
  Staging: silicom: remove unnecessary braces in bpctl_mod.c
  Staging: silicom: whitespace fixes in bpctl_mod.c
  Staging: silicom: move assignments out of if conditions
  Staging: silicom: move more assignments out of if conditions

 drivers/staging/silicom/bpctl_mod.c | 171 
 1 file changed, 94 insertions(+), 77 deletions(-)

-- 
1.8.1.4

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

[PATCH 2/4] Staging: silicom: whitespace fixes in bpctl_mod.c

[Chad Williamson]

Two trivial whitespace fixes in bpctl_mod.c for the sake of
checkpatch.pl happiness, etc.

Signed-off-by: Chad Williamson 
---
 drivers/staging/silicom/bpctl_mod.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/silicom/bpctl_mod.c 
b/drivers/staging/silicom/bpctl_mod.c
index c09dc02..893737a 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -2028,8 +2028,8 @@ int wdt_off(bpctl_dev_t *pbpctl_dev)
 /* WDT_ON (0x10)*/
 
 /***Global***/
-static unsigned int
-wdt_val_array[] = { 1000, 1500, 2000, 3000, 4000, 8000, 16000, 32000, 0 };
+static unsigned int wdt_val_array[]
+   = { 1000, 1500, 2000, 3000, 4000, 8000, 16000, 32000, 0 };
 
 int wdt_on(bpctl_dev_t *pbpctl_dev, unsigned int timeout)
 {
@@ -6617,7 +6617,7 @@ static void find_fw(bpctl_dev_t *dev)
ioremap(mmio_start, mmio_len);
 
dev->bp_fw_ver = bypass_fw_ver(dev);
-   if (dev-> bp_fw_ver == 0xa8)
+   if (dev->bp_fw_ver == 0xa8)
break;
}
}
-- 
1.8.1.4

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

[PATCH 4/4] Staging: silicom: move more assignments out of if conditions

[Chad Williamson]

Remove more assignments from if-statement conditions in bpctl_mod.c,
resolving checkpatch.pl errors. Those that remain need more attention
than I'm presently prepared to give them.

Signed-off-by: Chad Williamson 
---
 drivers/staging/silicom/bpctl_mod.c | 53 -
 1 file changed, 34 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/silicom/bpctl_mod.c 
b/drivers/staging/silicom/bpctl_mod.c
index 19a9239..91a6afd 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -4222,9 +4222,8 @@ void bypass_caps_init(bpctl_dev_t *pbpctl_dev)
 
 int bypass_off_init(bpctl_dev_t *pbpctl_dev)
 {
-   int ret = 0;
-
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   int ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (INTEL_IF_SERIES(pbpctl_dev->subdevice))
return dis_bypass_cap(pbpctl_dev);
@@ -4409,7 +4408,8 @@ int set_bypass_fn(bpctl_dev_t *pbpctl_dev, int 
bypass_mode)
 
if (!(pbpctl_dev->bp_caps & BP_CAP))
return BP_NOT_CAP;
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (!bypass_mode)
ret = bypass_off(pbpctl_dev);
@@ -4441,7 +4441,8 @@ int set_dis_bypass_fn(bpctl_dev_t *pbpctl_dev, int 
dis_param)
 
if (!(pbpctl_dev->bp_caps & BP_DIS_CAP))
return BP_NOT_CAP;
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (dis_param)
ret = dis_bypass_cap(pbpctl_dev);
@@ -4467,7 +4468,8 @@ int set_bypass_pwoff_fn(bpctl_dev_t *pbpctl_dev, int 
bypass_mode)
 
if (!(pbpctl_dev->bp_caps & BP_PWOFF_CTL_CAP))
return BP_NOT_CAP;
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (bypass_mode)
ret = bypass_state_pwroff(pbpctl_dev);
@@ -4493,7 +4495,8 @@ int set_bypass_pwup_fn(bpctl_dev_t *pbpctl_dev, int 
bypass_mode)
 
if (!(pbpctl_dev->bp_caps & BP_PWUP_CTL_CAP))
return BP_NOT_CAP;
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (bypass_mode)
ret = bypass_state_pwron(pbpctl_dev);
@@ -4520,7 +4523,8 @@ int set_bypass_wd_fn(bpctl_dev_t *pbpctl_dev, int timeout)
if (!(pbpctl_dev->bp_caps & WD_CTL_CAP))
return BP_NOT_CAP;
 
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (!timeout)
ret = wdt_off(pbpctl_dev);
@@ -4589,7 +4593,8 @@ int set_std_nic_fn(bpctl_dev_t *pbpctl_dev, int nic_mode)
if (!(pbpctl_dev->bp_caps & STD_NIC_CAP))
return BP_NOT_CAP;
 
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (nic_mode)
ret = std_nic_on(pbpctl_dev);
@@ -4655,7 +4660,8 @@ int get_tap_pwup_fn(bpctl_dev_t *pbpctl_dev)
if (!pbpctl_dev)
return -1;
 
-   if ((ret = default_pwron_tap_status(pbpctl_dev)) < 0)
+   ret = default_pwron_tap_status(pbpctl_dev);
+   if (ret < 0)
return ret;
return ((ret == 0) ? 1 : 0);
 }
@@ -4830,7 +4836,8 @@ int get_disc_port_pwup_fn(bpctl_dev_t *pbpctl_dev)
if (!pbpctl_dev)
return -1;
 
-   if ((ret = default_pwron_disc_port_status(pbpctl_dev)) < 0)
+   ret = default_pwron_disc_port_status(pbpctl_dev);
+   if (ret < 0)
return ret;
return ((ret == 0) ? 1 : 0);
 }
@@ -4857,7 +4864,8 @@ int reset_cont_fn(bpctl_dev_t *pbpctl_dev)
if (!pbpctl_dev)
return -1;
 
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
return reset_cont(pbpctl_dev);
 }
@@ -4873,8 +4881,10 @@ int set_tx_fn(bpctl_dev_t *pbpctl_dev, int tx_state)
(pbpctl_dev->bp_caps & SW_CTL_CAP)) {
if ((pbpctl_dev->bp_tpl_flag))
return BP_NOT_CAP;
-   } else if ((pbpctl_dev_b = get_master_port_fn(pbpctl_dev))) {
-   if ((pbpctl_dev_b->bp_caps & TPL_CAP) &&
+   } else {
+   pbpctl_dev_b = get_master_port_fn(pbpctl_dev);
+   if (pbpctl_dev_b &&
+   (pbpctl_dev_b->bp_caps & TPL_CAP) &&
(pbpctl_dev_b->bp_tpl_flag))
return BP_NOT_CAP;
}
@@ -4990,8 +5000,10 @@ int get_tx_fn(bpctl_dev_t *pbpctl_dev)
(pbpctl_dev->bp_caps & SW_CTL_CAP)) {
if ((pbpctl_dev->bp_tpl_flag))
return BP_NOT_CAP;
-   } else if ((pbpctl_dev_b = 

[PATCH v3 3/3] sched: scale cpu load for judgment of group imbalance

[Lei Wen]

We cannot compare two load directly from two cpus, since the cpu power
over two cpu may vary largely.

Suppose we meet such two kind of cpus.
CPU A:
No real time work, and there are 3 task, with rq->load.weight
being 512.
CPU B:
Has real time work, and it take 3/4 of the cpu power, which
makes CFS only take 1/4, that is 1024/4=256 cpu power. And over its CFS
runqueue, there is only one task with weight as 128.

Since both cpu's CFS task take for half of the CFS's cpu power, it
should be considered as balanced in such case.

But original judgment like:
if ((max_cpu_load - min_cpu_load) >= avg_load_per_task &&
(max_nr_running - min_nr_running) > 1)
It makes (512-128)>=((512+128)/4), and lead to imbalance conclusion...

Make the load as scaled, to avoid such case.

Signed-off-by: Lei Wen 
---
 kernel/sched/fair.c |   19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6173095..12826f9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4434,7 +4434,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
int local_group, int *balance, struct sg_lb_stats *sgs)
 {
unsigned long nr_running, max_nr_running, min_nr_running;
-   unsigned long load, max_cpu_load, min_cpu_load;
+   unsigned long scaled_load, load, max_cpu_load, min_cpu_load;
unsigned int balance_cpu = -1, first_idle_cpu = 0;
unsigned long avg_load_per_task = 0;
int i;
@@ -4464,10 +4464,12 @@ static inline void update_sg_lb_stats(struct lb_env 
*env,
load = target_load(i, load_idx);
} else {
load = source_load(i, load_idx);
-   if (load > max_cpu_load)
-   max_cpu_load = load;
-   if (min_cpu_load > load)
-   min_cpu_load = load;
+   scaled_load = load * SCHED_POWER_SCALE
+   / cpu_rq(i)->cpu_power;
+   if (scaled_load > max_cpu_load)
+   max_cpu_load = scaled_load;
+   if (min_cpu_load > scaled_load)
+   min_cpu_load = scaled_load;
 
if (nr_running > max_nr_running)
max_nr_running = nr_running;
@@ -4511,8 +4513,11 @@ static inline void update_sg_lb_stats(struct lb_env *env,
 *  normalized nr_running number somewhere that negates
 *  the hierarchy?
 */
-   if (sgs->sum_nr_running)
-   avg_load_per_task = sgs->sum_weighted_load / 
sgs->sum_nr_running;
+   if (sgs->sum_nr_running) {
+   avg_load_per_task = sgs->sum_weighted_load * SCHED_POWER_SCALE
+   / group->sgp->power;
+   avg_load_per_task /= sgs->sum_nr_running;
+   }
 
if ((max_cpu_load - min_cpu_load) >= avg_load_per_task &&
(max_nr_running - min_nr_running) > 1)
-- 
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/

Re: ext4 extent status tree LRU locking

[Zheng Liu]

On Mon, Jun 17, 2013 at 10:51:34PM -0400, Theodore Ts'o wrote:
> On Tue, Jun 18, 2013 at 10:25:48AM +0800, Zheng Liu wrote:
> > Ah, sorry, I forgot to mention that this patch bases against ext4/master
> > branch.  Now ext4/dev branch has some regression when I run xfstests.
> 
> What regressions are you seeing?

generic/300.

When I try to test my patch, I know that there has a report that
invalidate page range patch set causes a regression, and I am not sure
whether invalidate page range patch set causes it or not.  So I decide
to generate my patch against ext4/master.  So, don't worry. :-)

BTW, I will run xfstests this week.  If I meet any regression, I will
let you know.

> 
> > Ted, I notice that now in ext4 tree we have 'dev', 'dev-with-revert',
> > and 'dev2' branches.  Which one is the best to generate a new patch for
> > the next merge window?
> 
> Either the dev branch or the master branch.   
> 
> The dev-with-revert and dev2 were branches that I had created when
> investigating a potential regression with the invalidage page range
> patch set.  I've since determined that it's a timing issue and it's
> not a new regression --- we've had xfstests failures with test
> generic/300 for a while now.

Thanks for pointing it out.

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

[PATCH v3 1/3] sched: reduce calculation effort in fix_small_imbalance

[Lei Wen]

Actually all below item could be repalced by scaled_busy_load_per_task
(sds->busiest_load_per_task * SCHED_POWER_SCALE)
/sds->busiest->sgp->power;

Signed-off-by: Lei Wen 
---
 kernel/sched/fair.c |   19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c61a614..28052fa 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4727,20 +4727,17 @@ void fix_small_imbalance(struct lb_env *env, struct 
sd_lb_stats *sds)
pwr_now /= SCHED_POWER_SCALE;
 
/* Amount of load we'd subtract */
-   tmp = (sds->busiest_load_per_task * SCHED_POWER_SCALE) /
-   sds->busiest->sgp->power;
-   if (sds->max_load > tmp)
+   if (sds->max_load > scaled_busy_load_per_task) {
pwr_move += sds->busiest->sgp->power *
-   min(sds->busiest_load_per_task, sds->max_load - tmp);
-
-   /* Amount of load we'd add */
-   if (sds->max_load * sds->busiest->sgp->power <
-   sds->busiest_load_per_task * SCHED_POWER_SCALE)
-   tmp = (sds->max_load * sds->busiest->sgp->power) /
-   sds->this->sgp->power;
-   else
+   min(sds->busiest_load_per_task,
+   sds->max_load - scaled_busy_load_per_task);
tmp = (sds->busiest_load_per_task * SCHED_POWER_SCALE) /
sds->this->sgp->power;
+   } else
+   tmp = (sds->max_load * sds->busiest->sgp->power) /
+   sds->this->sgp->power;
+
+   /* Amount of load we'd add */
pwr_move += sds->this->sgp->power *
min(sds->this_load_per_task, sds->this_load + tmp);
pwr_move /= SCHED_POWER_SCALE;
-- 
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/

Re: [PATCH] kernel: timer: looping issue, need reset variable 'found'

[Chen Gang]

Sorry again for replying late, and now I can focus on this patch, I will
see the related details again.


Thanks.

On 06/13/2013 11:39 AM, Chen Gang wrote:
> 
> Sorry for replying late during these days, firstly.
> 
> 
> On 06/10/2013 10:12 PM, Thomas Gleixner wrote:
>> On Sun, 9 Jun 2013, Chen Gang wrote:
>>

 According to __internal_add_timer(), in _next_timer_interrupt(), when
 'tv1.vec' find one, but need 'cascade bucket(s)', we still need find
 each slot of 'tv*.vec'.
>> No, we do not. We only need to scan the first cascade array after the
>> enqueued timer. If there is nothing in tv2 which might come before the
>> found timer, then any timer in tv3 will be later than the one we found
>> in the primary wheel.
>>
> 
> OK, thanks, I should read details to confirm it (at least now, I still
> not quite be sure about it).
> 
> 
 So need reset variable 'found', so can fully scan ''do {...} while()''
 for 'tv*.vec'.
>> And thereby lose the information, that we already found a timer in the
>> scan of the primary array.
> 
> Hmm..., I should read details.
> 
> 
> And excuse me, I also have to do another things during these days, so
> maybe reply late.
> 
> 
> Thanks.
> 


-- 
Chen Gang

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

[PATCH v3 0/3] small fix for scale usage

[Lei Wen]

Here are three patches which correct scale usage in both fix_small_imbalance
and update_sg_lb_stats.

And give out comment over when fix_small_imbalance would cause load change.

V2: fix scale usage for update_sg_lb_stats

V3: fix scale problem in comparing sds->busiest_load_per_task
and sds->avg_load when there is not balanced group inside the domain


Lei Wen (3):
  sched: reduce calculation effort in fix_small_imbalance
  sched: scale the busy and this queue's per-task load before compare
  sched: scale cpu load for judgment of group imbalance

 kernel/sched/fair.c |   64 +++
 1 file changed, 39 insertions(+), 25 deletions(-)

-- 
1.7.10.4

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

[PATCH v3 2/3] sched: scale the busy and this queue's per-task load before compare

[Lei Wen]

Since for max_load and this_load, they are the value that already be
scaled. It is not reasonble to get a minimum value between the scaled
and non-scaled value, like below example.
min(sds->busiest_load_per_task, sds->max_load);

Also add comment over in what condition, there would be cpu power gain
in move the load.

Signed-off-by: Lei Wen 
---
 kernel/sched/fair.c |   38 +-
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 28052fa..6173095 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4692,10 +4692,14 @@ void fix_small_imbalance(struct lb_env *env, struct 
sd_lb_stats *sds)
 {
unsigned long tmp, pwr_now = 0, pwr_move = 0;
unsigned int imbn = 2;
-   unsigned long scaled_busy_load_per_task;
 
if (sds->this_nr_running) {
sds->this_load_per_task /= sds->this_nr_running;
+
+   /* Scale this_load_per_task to local power not related */
+   sds->this_load_per_task <<= SCHED_POWER_SHIFT;
+   sds->this_load_per_task /= sds->this->sgp->power;
+
if (sds->busiest_load_per_task >
sds->this_load_per_task)
imbn = 1;
@@ -4704,12 +4708,8 @@ void fix_small_imbalance(struct lb_env *env, struct 
sd_lb_stats *sds)
cpu_avg_load_per_task(env->dst_cpu);
}
 
-   scaled_busy_load_per_task = sds->busiest_load_per_task
-* SCHED_POWER_SCALE;
-   scaled_busy_load_per_task /= sds->busiest->sgp->power;
-
-   if (sds->max_load - sds->this_load + scaled_busy_load_per_task >=
-   (scaled_busy_load_per_task * imbn)) {
+   if (sds->max_load - sds->this_load + sds->busiest_load_per_task >=
+   (sds->busiest_load_per_task * imbn)) {
env->imbalance = sds->busiest_load_per_task;
return;
}
@@ -4727,22 +4727,29 @@ void fix_small_imbalance(struct lb_env *env, struct 
sd_lb_stats *sds)
pwr_now /= SCHED_POWER_SCALE;
 
/* Amount of load we'd subtract */
-   if (sds->max_load > scaled_busy_load_per_task) {
+   if (sds->max_load > sds->busiest_load_per_task) {
pwr_move += sds->busiest->sgp->power *
min(sds->busiest_load_per_task,
-   sds->max_load - scaled_busy_load_per_task);
-   tmp = (sds->busiest_load_per_task * SCHED_POWER_SCALE) /
-   sds->this->sgp->power;
+   sds->max_load - sds->busiest_load_per_task);
+   tmp = sds->busiest_load_per_task;
} else
-   tmp = (sds->max_load * sds->busiest->sgp->power) /
-   sds->this->sgp->power;
+   tmp = sds->max_load;
 
+   /* Scale to this queue from busiest queue */
+   tmp = (tmp * sds->busiest->sgp->power) /
+   sds->this->sgp->power;
/* Amount of load we'd add */
pwr_move += sds->this->sgp->power *
min(sds->this_load_per_task, sds->this_load + tmp);
pwr_move /= SCHED_POWER_SCALE;
 
/* Move if we gain throughput */
+   /*
+* The only possibilty for below statement be true, is:
+* sds->max_load is larger than sds->busiest_load_per_task, while,
+* sds->busiest_load_per_task is larger than sds->this_load plus by
+* the scaled sds->busiest_load_per_task moved into this queue
+*/
if (pwr_move > pwr_now)
env->imbalance = sds->busiest_load_per_task;
 }
@@ -4758,6 +4765,11 @@ static inline void calculate_imbalance(struct lb_env 
*env, struct sd_lb_stats *s
unsigned long max_pull, load_above_capacity = ~0UL;
 
sds->busiest_load_per_task /= sds->busiest_nr_running;
+
+   /* Scale busiest_load_per_task to local power not related */
+   sds->busiest_load_per_task <<= SCHED_POWER_SHIFT;
+   sds->busiest_load_per_task /= sds->busiest->sgp->power;
+
if (sds->group_imb) {
sds->busiest_load_per_task =
min(sds->busiest_load_per_task, sds->avg_load);
-- 
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/

Re: [RFC 08/10] irqdomain: Refactor irq_domain_associate_many()

[Mike Qiu]

于 2013/6/10 8:49, Grant Likely 写道:

Originally, irq_domain_associate_many() was designed to unwind the
mapped irqs on a failure of any individual association. However, that
proved to be a problem with certain IRQ controllers. Some of them only
support a subset of irqs, and will fail when attempting to map a
reserved IRQ. In those cases we want to map as many IRQs as possible, so
instead it is better for irq_domain_associate_many() to make a
best-effort attempt to map irqs, but not fail if any or all of them
don't succeed. If a caller really cares about how many irqs got
associated, then it should instead go back and check that all of the
irqs is cares about were mapped.

The original design open-coded the individual association code into the
body of irq_domain_associate_many(), but with no longer needing to
unwind associations, the code becomes simpler to split out
irq_domain_associate() to contain the bulk of the logic, and
irq_domain_associate_many() to be a simple loop wrapper.

This patch also adds a new error check to the associate path to make
sure it isn't called for an irq larger than the controller can handle,
and adds locking so that the irq_domain_mutex is held while setting up a
new association.

Signed-off-by: Grant Likely 
---
  include/linux/irqdomain.h |  22 +++---
  kernel/irq/irqdomain.c| 185 +++---
  2 files changed, 101 insertions(+), 106 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index fd4b26f..f9e8e06 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -103,6 +103,7 @@ struct irq_domain {
struct irq_domain_chip_generic *gc;

/* reverse map data. The linear map gets appended to the irq_domain */
+   irq_hw_number_t hwirq_max;
unsigned int revmap_direct_max_irq;
unsigned int revmap_size;
struct radix_tree_root revmap_tree;
@@ -110,8 +111,8 @@ struct irq_domain {
  };

  #ifdef CONFIG_IRQ_DOMAIN
-struct irq_domain *__irq_domain_add(struct device_node *of_node,
-   int size, int direct_max,
+struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
+   irq_hw_number_t hwirq_max, int direct_max,
const struct irq_domain_ops *ops,
void *host_data);
  struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
@@ -140,14 +141,14 @@ static inline struct irq_domain 
*irq_domain_add_linear(struct device_node *of_no
 const struct irq_domain_ops *ops,
 void *host_data)
  {
-   return __irq_domain_add(of_node, size, 0, ops, host_data);
+   return __irq_domain_add(of_node, size, size, 0, ops, host_data);
  }
  static inline struct irq_domain *irq_domain_add_nomap(struct device_node 
*of_node,
 unsigned int max_irq,
 const struct irq_domain_ops *ops,
 void *host_data)
  {
-   return __irq_domain_add(of_node, 0, max_irq, ops, host_data);
+   return __irq_domain_add(of_node, 0, max_irq, max_irq, ops, host_data);
  }
  static inline struct irq_domain *irq_domain_add_legacy_isa(
struct device_node *of_node,
@@ -166,14 +167,11 @@ static inline struct irq_domain 
*irq_domain_add_tree(struct device_node *of_node

  extern void irq_domain_remove(struct irq_domain *host);

-extern int irq_domain_associate_many(struct irq_domain *domain,
-unsigned int irq_base,
-irq_hw_number_t hwirq_base, int count);
-static inline int irq_domain_associate(struct irq_domain *domain, unsigned int 
irq,
-   irq_hw_number_t hwirq)
-{
-   return irq_domain_associate_many(domain, irq, hwirq, 1);
-}
+extern int irq_domain_associate(struct irq_domain *domain, unsigned int irq,
+   irq_hw_number_t hwirq);
+extern void irq_domain_associate_many(struct irq_domain *domain,
+ unsigned int irq_base,
+ irq_hw_number_t hwirq_base, int count);

  extern unsigned int irq_create_mapping(struct irq_domain *host,
   irq_hw_number_t hwirq);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 280b804..80e9249 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -35,8 +35,8 @@ static struct irq_domain *irq_default_domain;
   * register allocated irq_domain with irq_domain_register().  Returns pointer
   * to IRQ domain, or NULL on failure.
   */
-struct irq_domain *__irq_domain_add(struct device_node *of_node,
-   int size, int direct_max,
+struct irq_domain *__irq_domain_add(struct 

Re: [PATCH] usb: host: Faraday fotg210-hcd driver

[Sarah Sharp]

On Tue, Jun 18, 2013 at 10:42:09AM +0800, Yuan-Hsin Chen wrote:
> Hi,
> 
> On Tue, Jun 18, 2013 at 4:39 AM, Greg KH  wrote:
> > On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote:
> >> FOTG210 is an OTG controller which can be configured as an
> >> USB2.0 host. FOTG210 host is an ehci-like controller with
> >> some differences. First, register layout of FOTG210 is
> >> incompatible with EHCI. Furthermore, FOTG210 is lack of
> >> siTDs which means iTDs are used for both HS and FS ISO
> >> transfer.
> >>
> >> Signed-off-by: Yuan-Hsin Chen 
> >> ---
> >>  drivers/usb/Makefile   |1 +
> >>  drivers/usb/host/Kconfig   |   12 +
> >>  drivers/usb/host/Makefile  |1 +
> >>  drivers/usb/host/fotg210-hcd.c | 5967 
> >> 
> >>  drivers/usb/host/fotg210.h |  746 +
> >>  5 files changed, 6727 insertions(+), 0 deletions(-)
> >>  create mode 100644 drivers/usb/host/fotg210-hcd.c
> >>  create mode 100644 drivers/usb/host/fotg210.h
> >
> > You obviously didn't even run this through checkpatch.pl, did you?
> >
> > $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1
> > total: 138 errors, 618 warnings, 6742 lines checked
> >
> > Please fix all of these if you wish us to at least start reviewing the
> > patch.  Your internal Q/A should have caught this first, please be more
> > careful in the future.
> >
> 
> Actually I did run checkpatch.pl and found that almost all errors and
> warnings are from ehci core (ehci-hcd.c, ehci-hub.c and so on) where
> my driver borrowed most of code.
> 
> $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hub.c | tail -n 1
> total: 18 errors, 69 warnings, 1138 lines checked
> 
> $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hcd.c | tail -n 1
> total: 17 errors, 78 warnings, 1403 lines checked
> 
> So you're saying that I should fix them, is that right?

In that case, no, you should be figuring out how to refactor and reuse
the EHCI code instead of copying it straight into your driver.

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

linux-next: manual merge of the drm-intel tree with the drm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_fb.c between commit b72447cdf129 ("drm/i915:
Drop bogus fbdev sprite disable code") from the drm tree and commit
b51b32cde175 ("drm/i915: s/drm_i915_private_t/struct drm_i915_private/")
from the drm-intel tree.

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

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

diff --cc drivers/gpu/drm/i915/intel_fb.c
index 3b03c3c,244060a..000
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@@ -291,7 -292,9 +292,7 @@@ void intel_fb_output_poll_changed(struc
  void intel_fb_restore_mode(struct drm_device *dev)
  {
int ret;
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
 -  struct drm_mode_config *config = >mode_config;
 -  struct drm_plane *plane;
  
if (INTEL_INFO(dev)->num_pipes == 0)
return;


pgp1v0yfFTF8K.pgp
Description: PGP signature

Re: ext4 extent status tree LRU locking

[Theodore Ts'o]

On Tue, Jun 18, 2013 at 10:25:48AM +0800, Zheng Liu wrote:
> Ah, sorry, I forgot to mention that this patch bases against ext4/master
> branch.  Now ext4/dev branch has some regression when I run xfstests.

What regressions are you seeing?

> Ted, I notice that now in ext4 tree we have 'dev', 'dev-with-revert',
> and 'dev2' branches.  Which one is the best to generate a new patch for
> the next merge window?

Either the dev branch or the master branch.   

The dev-with-revert and dev2 were branches that I had created when
investigating a potential regression with the invalidage page range
patch set.  I've since determined that it's a timing issue and it's
not a new regression --- we've had xfstests failures with test
generic/300 for a while now.

- 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 2/3] tracing/kprobes: Kill probe_enable_lock

[Masami Hiramatsu]

(2013/06/18 0:18), Oleg Nesterov wrote:
> On 06/17, Masami Hiramatsu wrote:
>>
>> (2013/06/17 2:21), Oleg Nesterov wrote:
>>> enable_trace_probe() and disable_trace_probe() should not worry about
>>> serialization, the caller (perf_trace_init or __ftrace_set_clr_event)
>>> holds event_mutex.
>>>
>>> They are also called by kprobe_trace_self_tests_init(), but this __init
>>> function can't race with itself or trace_events.c
>>
>> Right,
>> For safety, we should comment this at the caller side,
> 
> Which caller do you mean?

I meant the caller was kprobe_test_self_tests_init().
Since that function calls enable/disable_trace_probe()
without holding event_mutex, we need to notice that
(this is safe because there is no race) at the calling
places :)

Thank you,

> 
> The patch adds
> 
>   /*
>* This and enable_trace_probe/disable_trace_probe rely on event_mutex
>* held by the caller, __ftrace_set_clr_event().
>*/
> 
> above trace_probe_nr_files() but the next patch removes this function
> with the comment...
> 
> Will you agree with this patch if I add something like
> 
>   /*
>* called by perf_trace_init() or __ftrace_set_clr_event() under 
> event_mutex
>*/
> 
> above kprobe_register() ? Perhaps it makes sense to add
> lockdep_assert_held(_mutex) into the body?
> 
> And:
> 
>> because
>> those calls are the reason why I have introduced this lock.
> 
> Please do not hesitate to nack this patch if you think that we should
> keep probe_enable_lock for safety even if it is not currently needed.
> In this case I'd suggest to move lock/unlock into kprobe_register()
> but this is minor.
> 
> Oleg.
> 
> 


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


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

RE: [PATCH] x86, efi: retry ExitBootServices() on failure

[joeyli]

Hi Zach, 

於 二，2013-06-18 於 00:18 +，Zachary Bobroff 提到：
> All,
> 
> >> Why a single retry is having reasonable guarantees to work when the
> original one failed (nothing prevents an event handler to do another
> allocation the next time through).
> 
> This patch is being submitted because of the potential issues that
> occur when 3rd party option ROMs are signaled by the ExitBootServices
> event. At the time they are signaled, they can perform any number of
> actions that would change the EFI Memory map.  This wasn't actually
> seen with our default implementation of our firmware, it was seen when
> this plug-in card's option rom was run.
> 
> We only need to retry once because of what is in the UEFI
> specification 2.3.1 Errata C.  The exact verbiage is as follows:
> 
> The ExitBootServices() function is called by the currently executing
> EFI OS loader image to terminate all boot services. On success, the
> loader becomes responsible for the continued operation of the system.
> All events of type EVT_SIGNAL_EXIT_BOOT_SERVICES must be signaled
> before ExitBootServices() returns EFI_SUCCESS. The events are only
> signaled once even if ExitBootServices() is called multiple times.
> 
> Since the firmware will only signal the ExitBootServices event once,
> the code that has the potential to change the memory map will only be
> signaled on the first call to exit boot services. 

Does it possible have any delay time of 3rd party ROMs to change EFI
memory map after they are signaled?
or ExitBootServices() will wait all 3rd party ROMs updated memory map
finished then return true/false to kernel?


Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ext4 extent status tree LRU locking

[Theodore Ts'o]

> Subject: [PATCH v2] ext4: improve extent cache shrink mechanism to avoid to 
> burn CPU time
> 
> From: Zheng Liu 
> 
> Now we maintain an proper in-order LRU list in ext4 to reclaim entries
> from extent status tree when we are under heavy memory pressure.  For
> keeping this order, a spin lock is used to protect this list.  But this
> lock burns a lot of CPU time.  We can use the following steps to trigger
> it.
> 
>   % cd /dev/shm
>   % dd if=/dev/zero of=ext4-img bs=1M count=2k
>   % mkfs.ext4 ext4-img
>   % mount -t ext4 -o loop ext4-img /mnt
>   % cd /mnt
>   % for ((i=0;i<160;i++)); do truncate -s 64g $i; done
>   % for ((i=0;i<160;i++)); do cp $i /dev/null &; done
>   % perf record -a -g
>   % perf report
> 
> This commit tries to fix this problem.  Now a new member called
> i_touch_when is added into ext4_inode_info to record the last access
> time for an inode.  Meanwhile we never need to keep a proper in-order
> LRU list.  So this can avoid to burns some CPU time.  When we try to
> reclaim some entries from extent status tree, we use list_sort() to get
> a proper in-order list.  Then we traverse this list to discard some
> entries.  In ext4_sb_info, we use s_es_last_sorted to record the last
> time of sorting this list.  When we traverse the list, we skip the inode
> that is newer than this time, and move this inode to the tail of LRU
> list.  When the head of the list is newer than s_es_last_sorted, we will
> sort the LRU list again.
> 
> In this commit, we break the loop if s_extent_cache_cnt == 0 because
> that means that all extents in extent status tree have been reclaimed.
> 
> Meanwhile in this commit, ext4_es_{un}register_shrinker()'s prototype is
> changed to save a local variable in these functions.
> 
> Reported-by: Dave Hansen 
> Cc: "Theodore Ts'o" 
> Signed-off-by: Zheng Liu 

Applied, thanks.

- 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: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

[Dave Chinner]

On Tue, Jun 18, 2013 at 02:30:05AM +0400, Glauber Costa wrote:
> On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
> > On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa  wrote:
> > 
> > > > I managed to trigger:
> > > > [ 1015.776029] kernel BUG at mm/list_lru.c:92!
> > > > [ 1015.776029] invalid opcode:  [#1] SMP
> > > > with Linux next (next-20130607) with https://lkml.org/lkml/2013/6/17/203
> > > > on top. 
> > > > 
> > > > This is obviously BUG_ON(nlru->nr_items < 0) and 
> > > > 81122d0b:   48 85 c0test   %rax,%rax
> > > > 81122d0e:   49 89 44 24 18  mov%rax,0x18(%r12)
> > > > 81122d13:   0f 84 87 00 00 00   je 81122da0 
> > > > 
> > > > 81122d19:   49 83 7c 24 18 00   cmpq   $0x0,0x18(%r12)
> > > > 81122d1f:   78 7b   js 81122d9c 
> > > > 
> > > > [...]
> > > > 81122d9c:   0f 0b   ud2
> > > > 
> > > > RAX is -1UL.
> > > Yes, fearing those kind of imbalances, we decided to leave the counter as 
> > > a signed quantity
> > > and BUG, instead of an unsigned quantity.
> > > 
> > > > 
> > > > I assume that the current backtrace is of no use and it would most
> > > > probably be some shrinker which doesn't behave.
> > > > 
> > > There are currently 3 users of list_lru in tree: dentries, inodes and xfs.
> > > Assuming you are not using xfs, we are left with dentries and inodes.
> > > 
> > > The first thing to do is to find which one of them is misbehaving. You 
> > > can try finding
> > > this out by the address of the list_lru, and where it lays in the 
> > > superblock.
> > > 
> > > Once we know each of them is misbehaving, then we'll have to figure out 
> > > why.
> > 
> > The trace says shrink_slab_node->super_cache_scan->prune_icache_sb.  So
> > it's inodes?
> > 
> Assuming there is no memory corruption of any sort going on , let's check the 
> code.
> nr_item is only manipulated in 3 places:
> 
> 1) list_lru_add, where it is increased
> 2) list_lru_del, where it is decreased in case the user have voluntarily 
> removed the
>element from the list
> 3) list_lru_walk_node, where an element is removing during shrink.
> 
> All three excerpts seem to be correctly locked, so something like this 
> indicates an imbalance.

inode_lru_isolate() looks suspicious to me:

WARN_ON(inode->i_state & I_NEW);
inode->i_state |= I_FREEING;
spin_unlock(>i_lock);

list_move(>i_lru, freeable);
this_cpu_dec(nr_unused);
return LRU_REMOVED;
}

All the other cases where I_FREEING is set and the inode is removed
from the LRU are completely done under the inode->i_lock. i.e. from
an external POV, the state change to I_FREEING and removal from LRU
are supposed to be atomic, but they are not here.

I'm not sure this is the source of the problem, but it definitely
needs fixing.

> callers:
> iput_final, evict_inodes, invalidate_inodes.
> Both evict_inodes and invalidate_inodes will do the following pattern:
> 
> inode->i_state |= I_FREEING;  
>   
> inode_lru_list_del(inode);
> spin_unlock(>i_lock);
> list_add(>i_lru, );
> 
> IOW, they will remove the element from the LRU, and add it to the dispose 
> list.
> Both of them will also bail out if they see I_FREEING already set, so they 
> are safe
> against each other - because the flag is manipulated inside the lock.
> 
> But how about iput_final? It seems to me that if we are calling iput_final at 
> the
> same time as the other two, this *could* happen (maybe there is some extra 
> protection
> that can be seen from Australia but not from here. Dave?)

If I_FREEING is set before we enter iput_final(), then something
else is screwed up. I_FREEING is only set once the last reference
has gone away and we are killing the inode. All the other callers
that set I_FREEING check that the reference count on the inode is
zero before they set I_FREEING. Hence I_FREEING cannot be set on the
transition of i_count from 1 to 0 when iput_final() is called. So
the patch won't do anything to avoid the problem being seen.

Keep in mind that we this is actually a new warning on the count of
inodes on the LRU - we never had a check that it didn't go negative
before

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: [lttng-dev] [-stable 3.8.1 performance regression] madvise POSIX_FADV_DONTNEED

[Andrew Morton]

On Mon, 17 Jun 2013 22:15:28 -0400 Mathieu Desnoyers 
 wrote:

> * Andrew Morton (a...@linux-foundation.org) wrote:
> > On Mon, 17 Jun 2013 17:39:36 -0400 Rapha__l Beamonte 
> >  wrote:
> > 
> > > 2013/6/17 Andrew Morton 
> > > 
> > > > That change wasn't terribly efficient - if there are any unpopulated
> > > > pages in the range (which is quite likely), fadvise() will now always
> > > > call invalidate_mapping_pages() a second time.
> > > >
> > > > Perhaps this is fixable.  Say, make lru_add_drain_all() return a
> > > > success code, or even teach lru_add_drain_all() to return a code
> > > > indicating that one of the spilled pages was (or might have been) on a
> > > > particular mapping.
> > > >
> > > 
> > > Following our tests results, that was the call to lru_add_drain_all() that
> > > causes the problem. The second call to invalidate_mapping_pages() isn't
> > > really important. We tried to compile a kernel with the commit introducing
> > > this change but with the "lru_add_drain_all()" line removed, and the
> > > problem disappeared, even if we called two times 
> > > invalidate_mapping_pages()
> > > (as the rest of the commit was still here).
> > 
> > Ah, OK, schedule_on_each_cpu() could certainly do that - it has to wait
> > for every CPU to context switch and schedule the worker function.
> > 
> > There's a lot we could do here.  Such as not doing the schedule_work()
> > at all for a cpu which has an empty lru_add_pvec.
> 
> First approach proposed, submitted as RFC. Compile-tested only.
> 
> ...
>
> Second approach, submitted as RFC with some questions left unanswered
> in the code. Compile-tested only.
> 
> ---
>  include/linux/swap.h |1 
>  mm/fadvise.c |2 -
>  mm/swap.c|   62 
> +++
>  3 files changed, 64 insertions(+), 1 deletion(-)
> 
> Index: linux/include/linux/swap.h
> ===
> --- linux.orig/include/linux/swap.h
> +++ linux/include/linux/swap.h
> @@ -242,6 +242,7 @@ extern void mark_page_accessed(struct pa
>  extern void lru_add_drain(void);
>  extern void lru_add_drain_cpu(int cpu);
>  extern int lru_add_drain_all(void);
> +extern int lru_add_drain_mapping(struct address_space *mapping);
>  extern void rotate_reclaimable_page(struct page *page);
>  extern void deactivate_page(struct page *page);
>  extern void swap_setup(void);
> Index: linux/mm/swap.c
> ===
> --- linux.orig/mm/swap.c
> +++ linux/mm/swap.c
> @@ -689,6 +689,68 @@ int lru_add_drain_all(void)
>  }
>  
>  /*
> + * Returns 0 for success
> + */
> +int lru_add_drain_mapping(struct address_space *mapping)
> +{
> + int cpu;
> + struct work_struct __percpu *works;
> +
> + works = alloc_percpu(struct work_struct);
> + if (!works)
> + return -ENOMEM;
> +
> + get_online_cpus();
> +
> + for_each_online_cpu(cpu) {
> + struct pagevec *pvecs = per_cpu(lru_add_pvecs, cpu);
> + struct work_struct *work = per_cpu_ptr(works, cpu);
> + struct pagevec *pvec;
> + int lru;
> +
> + INIT_WORK(work, lru_add_drain_per_cpu);
> + for_each_lru(lru) {
> + int i;
> +
> + pvec = [lru - LRU_BASE];
> + /*
> +  * Race failure mode is to flush unnecessarily.
> +  * We use PAGEVEC_SIZE rather than pvec->nr to
> +  * stay on the safe-side wrt pvec resize.
> +  */
> + for (i = 0; i < PAGEVEC_SIZE; i++) {
> + struct page *page;
> +
> + /*
> +  * Racy access to page. TODO: is it OK
> +  * to access it from the remote CPU's
> +  * lru without any kind of ownership or
> +  * synchronization ?
> +  */

Almost.  The only problem I can think of is that the other CPU flushes
its pagevec then a page gets freed then a memory hot-unplug occurs and
the memory hotplug handler frees and then unmaps the memory which was
used to hold the page's `struct page' (I don't think the current
mem-hotplug code even does this) and now this cpu's page->mapping
access goes oops.  

IOW, not worth worrying for a prototype "hey lets test this and see if
it fixes things" patch.


> + page = ACCESS_ONCE(pvec->pages[i]);
> + if (!pvec->pages[i])
> + continue;
> + if (page->mapping == mapping) {
> + schedule_work_on(cpu, work);
> + goto next_cpu;
> + }
> + }
> + }
> + next_cpu: ; /* 

Re: [PATCH] usb: host: Faraday fotg210-hcd driver

[Yuan-Hsin Chen]

Hi,

On Tue, Jun 18, 2013 at 4:39 AM, Greg KH  wrote:
> On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote:
>> FOTG210 is an OTG controller which can be configured as an
>> USB2.0 host. FOTG210 host is an ehci-like controller with
>> some differences. First, register layout of FOTG210 is
>> incompatible with EHCI. Furthermore, FOTG210 is lack of
>> siTDs which means iTDs are used for both HS and FS ISO
>> transfer.
>>
>> Signed-off-by: Yuan-Hsin Chen 
>> ---
>>  drivers/usb/Makefile   |1 +
>>  drivers/usb/host/Kconfig   |   12 +
>>  drivers/usb/host/Makefile  |1 +
>>  drivers/usb/host/fotg210-hcd.c | 5967 
>> 
>>  drivers/usb/host/fotg210.h |  746 +
>>  5 files changed, 6727 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/usb/host/fotg210-hcd.c
>>  create mode 100644 drivers/usb/host/fotg210.h
>
> You obviously didn't even run this through checkpatch.pl, did you?
>
> $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1
> total: 138 errors, 618 warnings, 6742 lines checked
>
> Please fix all of these if you wish us to at least start reviewing the
> patch.  Your internal Q/A should have caught this first, please be more
> careful in the future.
>

Actually I did run checkpatch.pl and found that almost all errors and
warnings are from ehci core (ehci-hcd.c, ehci-hub.c and so on) where
my driver borrowed most of code.

$ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hub.c | tail -n 1
total: 18 errors, 69 warnings, 1138 lines checked

$ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hcd.c | tail -n 1
total: 17 errors, 78 warnings, 1403 lines checked

So you're saying that I should fix them, is that right?

thanks,

Yuan-Hsin

> 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: power-efficient scheduling design

[David Lang]

On Fri, 14 Jun 2013, Morten Rasmussen wrote:


Looking at the discussion it seems that people have slightly different
views, but most agree that the goal is an integrated scheduling,
frequency, and idle policy like you pointed out from the beginning.

What is less clear is how such design would look like. Catalin has
suggested two different approaches. Integrating cpufreq into the load
balancing, or let the scheduler focus on load balancing and extend
cpufreq to also restrict number of cpus available to the scheduler using
cpu_power. The former approach would increase the scheduler complexity
significantly as I already highlighted in my first reply. The latter
approach introduces a way to, at lease initially, separate load
balancing from capacity management, which I think is an interesting
approach. Based on this idea I propose the following design:

+-+
| | +--+
current load| Power scheduler |<+ cpufreq  |
 +->| sched/power.c   +>| driver   |
 |  | | +--+
 |  +---+-+
 | ^|
   +-+-+   ||
   |   |   || available capacity
   | Scheduler |<--++ (e.g. cpu_power)
   | sched/fair.c  |   |
   |   +--+|
   +---+  ||
  ^   ||
  |   v|
+-++  +--+
| task load metric |  | cpuidle  |
| arch/*   |  | driver   |
+--+  +--+

The intention is that the power scheduler will implement the (unified)
power policy. It gets the current load of the system from the scheduler.
Based on this information it will adjust the compute capacity available
to the scheduler and drive frequency changes such that enough compute
capacity is available to handle the current load. If the total load can
be handled by a subset of cpus, it will reduce the capacity of the
excess cpus to 0 (cpu_power=1). Likewise, if the load increases it will
increase capacity of one or more idle cpus to allow the scheduler to
spread the load. The power scheduler has knowledge about the power
topology and will guide the scheduler to idle the most optimum cpus by
reducing its capacity. Global idle decision will be handled by the power
scheduler, so cpuidle can over time be reduced to become just a driver,
once we have added C-state selection to the power scheduler.

The scheduler is left to focus on scheduling mechanics and finding the
best possible load balance on the cpu capacities set by the power
scheduler. It will share a detailed view of the current load with the
power scheduler to enable it to make the right capacity adjustments. The
scheduler will need some optimization to cope better with asymmetric
compute capacities. We may want to reduce capacity of some cpu to
increase their idle time while letting others take the majority of the
load.

Frequency scaling has a problematic impact on PJT's load metic, which
was pointed out a while ago by Chris Redpath
.  So I agree with Arjan's
suggestion to change the load calculation basis to something which is
frequency invariant. Use whatever counters that are available on the
specific platform.

I'm aware that the scheduler and power scheduler decisions may be
inextricably linked so we may decide to merge them. However, I think it
is worth trying to keep the power scheduling decisions out of the
scheduler until we have proven it infeasible.

We are going to start working on this design and see where it takes us.
We will post any results and suggested patches for folk to comment on.
As a starting point we are planning to create a power scheduler
(kernel/sched/power.c) similar to a cpufreq governor that does capacity
management, and then evolve the solution from there.


I don't think that you are passing nearly enough information around.

A fairly simple example

take a relatively modern 4-core system with turbo mode where speed controls 
affect two cores at a time (I don't know the details of the available CPUs to 
know if this is an exact fit to any existing system, but I think it's a 
reasonable fit)


If you are running with a loadave of 2, should you power down 2 cores and run 
the other two in turbo mode, power down 2 cores and not increase the speed, or 
leave all 4 cores running as is.


Depending on the mix of processes, I could see any one of the three being the 
right answer.


If you have a process that's maxing out it's cpu time on one core, going to 
turbo mode is the right thing as the other processes should fit on the other 
core and that process will use more CPU (theoretically getting done sooner)


If no process is close to maxing out the core, then if you are in power saving 
mode, you probably want to shut down two cores and run everything on the 

Re: [PATCH 4/4 v2] silicom: checkpatch: errors caused by macros

[Joe Perches]

On Mon, 2013-06-17 at 14:14 -0700, Greg KH wrote:
> On Mon, Jun 17, 2013 at 02:03:43PM -0700, Joe Perches wrote:
> > Generally I think it's better that new submitters patches
> > should go through more strict reviews and be as correct
> > as possible.  I think this is especially true for patches
> > that are just checkpatch driven.
> 
> I totally disagree, sorry.

I'm unsurprised.  We have different tastes.

While whitespace only cleanup patches have some use,
for these types of patches, I'm more interested in
educating others what sorts of patches have higher
value.

o defects
o style/readability
o whitespace

As always, ymmv.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] KVM: PPC: Add support for IOMMU in-kernel handling

[Alex Williamson]

On Mon, 2013-06-17 at 13:56 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2013-06-16 at 21:13 -0600, Alex Williamson wrote:
> 
> > IOMMU groups themselves don't provide security, they're accessed by
> > interfaces like VFIO, which provide the security.  Given a brief look, I
> > agree, this looks like a possible backdoor.  The typical VFIO way to
> > handle this would be to pass a VFIO file descriptor here to prove that
> > the process has access to the IOMMU group.  This is how /dev/vfio/vfio
> > gains the ability to setup an IOMMU domain an do mappings with the
> > SET_CONTAINER ioctl using a group fd.  Thanks,
> 
> How do you envision that in the kernel ? IE. I'm in KVM code, gets that
> vfio fd, what do I do with it ?
> 
> Basically, KVM needs to know that the user is allowed to use that iommu
> group. I don't think we want KVM however to call into VFIO directly
> right ?

Right, we don't want to create dependencies across modules.  I don't
have a vision for how this should work.  This is effectively a complete
side-band to vfio, so we're really just dealing in the iommu group
space.  Maybe there needs to be some kind of registration of ownership
for the group using some kind of token.  It would need to include some
kind of notification when that ownership ends.  That might also be a
convenient tag to toggle driver probing off for devices in the group.
Other ideas?  Thanks,

Alex

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

[PATCH 6/7] sound/usb/misc/ua101.c: convert __list_for_each usage to list_for_each

[Dave Jones]

Signed-off-by: Dave Jones 
---
 sound/usb/misc/ua101.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/usb/misc/ua101.c b/sound/usb/misc/ua101.c
index 6ad617b..8b5d2c5 100644
--- a/sound/usb/misc/ua101.c
+++ b/sound/usb/misc/ua101.c
@@ -1349,7 +1349,7 @@ static void ua101_disconnect(struct usb_interface 
*interface)
snd_card_disconnect(ua->card);
 
/* make sure that there are no pending USB requests */
-   __list_for_each(midi, >midi_list)
+   list_for_each(midi, >midi_list)
snd_usbmidi_disconnect(midi);
abort_alsa_playback(ua);
abort_alsa_capture(ua);
-- 
1.8.1.4

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

[PATCH 4/7] staging/rtl8187se: Convert __list_for_each use to list_for_each

[Dave Jones]

Also remove commented out list manipulation

Signed-off-by: Dave Jones 
---
 drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c
index e303159..d5df0d6 100644
--- a/drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c
@@ -399,8 +399,8 @@ static int is_duplicate_packet(struct ieee80211_device 
*ieee,
struct ieee_ibss_seq *entry = NULL;
u8 *mac = header->addr2;
int index = mac[5] % IEEE_IBSS_MAC_HASH_SIZE;
-   //for (pos = (head)->next; pos != (head); pos = pos->next)
-   __list_for_each(p, >ibss_mac_hash[index]) {
+
+   list_for_each(p, >ibss_mac_hash[index]) {
entry = list_entry(p, struct ieee_ibss_seq, list);
if (!memcmp(entry->mac, mac, ETH_ALEN))
break;
-- 
1.8.1.4

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

[PATCH 7/7] list: Remove __list_for_each

[Dave Jones]

__list_for_each used to be the non prefetch() aware list walking primitive.
When we removed the prefetch macros from the list routines, it became
redundant. Given it does exactly the same thing as list_for_each now,
we might as well remove it and call list_for_each directly.

Signed-off-by: Dave Jones 
---
 include/linux/list.h | 11 ---
 1 file changed, 11 deletions(-)

Note: Only to be merged after 1-6 are in Linus tree.

diff --git a/include/linux/list.h b/include/linux/list.h
index b83e565..f4d8a2f 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -381,17 +381,6 @@ static inline void list_splice_tail_init(struct list_head 
*list,
for (pos = (head)->next; pos != (head); pos = pos->next)
 
 /**
- * __list_for_each -   iterate over a list
- * @pos:   the  list_head to use as a loop cursor.
- * @head:  the head for your list.
- *
- * This variant doesn't differ from list_for_each() any more.
- * We don't do prefetching in either case.
- */
-#define __list_for_each(pos, head) \
-   for (pos = (head)->next; pos != (head); pos = pos->next)
-
-/**
  * list_for_each_prev  -   iterate over a list backwards
  * @pos:   the  list_head to use as a loop cursor.
  * @head:  the head for your list.
-- 
1.8.1.4

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

[PATCH 1/7] radeon: Remove redundant __list_for_each definition from mkregtable.c

[Dave Jones]

Signed-off-by: Dave Jones 
---
 drivers/gpu/drm/radeon/mkregtable.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/mkregtable.c 
b/drivers/gpu/drm/radeon/mkregtable.c
index 5a82b6b..af85299 100644
--- a/drivers/gpu/drm/radeon/mkregtable.c
+++ b/drivers/gpu/drm/radeon/mkregtable.c
@@ -373,19 +373,6 @@ static inline void list_splice_tail_init(struct list_head 
*list,
pos = pos->next)
 
 /**
- * __list_for_each -   iterate over a list
- * @pos:   the  list_head to use as a loop cursor.
- * @head:  the head for your list.
- *
- * This variant differs from list_for_each() in that it's the
- * simplest possible list iteration code, no prefetching is done.
- * Use this for code that knows the list to be very short (empty
- * or 1 entry) most of the time.
- */
-#define __list_for_each(pos, head) \
-   for (pos = (head)->next; pos != (head); pos = pos->next)
-
-/**
  * list_for_each_prev  -   iterate over a list backwards
  * @pos:   the  list_head to use as a loop cursor.
  * @head:  the head for your list.
-- 
1.8.1.4

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

[PATCH 3/7] staging/rtl8192u: remove commented out __list_for_each usage

[Dave Jones]

Also remove another commented out open-coded list manipulation while we're 
there.

Signed-off-by: Dave Jones 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index ee7ce5f..8d0b6c5 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -454,8 +454,7 @@ static int is_duplicate_packet(struct ieee80211_device 
*ieee,
struct ieee_ibss_seq *entry = NULL;
u8 *mac = header->addr2;
int index = mac[5] % IEEE_IBSS_MAC_HASH_SIZE;
-   //for (pos = (head)->next; pos != (head); pos = pos->next)
-   //__list_for_each(p, >ibss_mac_hash[index]) {
+
list_for_each(p, >ibss_mac_hash[index]) {
entry = list_entry(p, struct ieee_ibss_seq, list);
if (!memcmp(entry->mac, mac, ETH_ALEN))
-- 
1.8.1.4

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

[PATCH 5/7] sctp: Convert __list_for_each use to list_for_each

[Dave Jones]

Signed-off-by: Dave Jones 
---
 net/sctp/protocol.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

netdev: patches 1-4 & 6 are independant to this, and 7 won't be
merged until this one gets to Linus' tree.

diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index eaee00c..3b70b76 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -178,7 +178,7 @@ static void sctp_get_local_addr_list(struct net *net)
 
rcu_read_lock();
for_each_netdev_rcu(net, dev) {
-   __list_for_each(pos, _address_families) {
+   list_for_each(pos, _address_families) {
af = list_entry(pos, struct sctp_af, list);
af->copy_addrlist(>sctp.local_addr_list, dev);
}
-- 
1.8.1.4

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

[PATCH 2/7] ipw2200: Convert __list_for_each usage to list_for_each

[Dave Jones]

Signed-off-by: Dave Jones 
---
 drivers/net/wireless/ipw2x00/ipw2200.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c 
b/drivers/net/wireless/ipw2x00/ipw2200.c
index d96257b..4ed5e45 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -8256,7 +8256,7 @@ static  int is_duplicate_packet(struct ipw_priv *priv,
u8 *mac = header->addr2;
int index = mac[5] % IPW_IBSS_MAC_HASH_SIZE;
 
-   __list_for_each(p, >ibss_mac_hash[index]) {
+   list_for_each(p, >ibss_mac_hash[index]) {
entry =
list_entry(p, struct ipw_ibss_seq, list);
if (!memcmp(entry->mac, mac, ETH_ALEN))
-- 
1.8.1.4

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

Re: [lttng-dev] [-stable 3.8.1 performance regression] madvise POSIX_FADV_DONTNEED

[Mathieu Desnoyers]

* Andrew Morton (a...@linux-foundation.org) wrote:
> On Mon, 17 Jun 2013 17:39:36 -0400 Rapha__l Beamonte 
>  wrote:
> 
> > 2013/6/17 Andrew Morton 
> > 
> > > That change wasn't terribly efficient - if there are any unpopulated
> > > pages in the range (which is quite likely), fadvise() will now always
> > > call invalidate_mapping_pages() a second time.
> > >
> > > Perhaps this is fixable.  Say, make lru_add_drain_all() return a
> > > success code, or even teach lru_add_drain_all() to return a code
> > > indicating that one of the spilled pages was (or might have been) on a
> > > particular mapping.
> > >
> > 
> > Following our tests results, that was the call to lru_add_drain_all() that
> > causes the problem. The second call to invalidate_mapping_pages() isn't
> > really important. We tried to compile a kernel with the commit introducing
> > this change but with the "lru_add_drain_all()" line removed, and the
> > problem disappeared, even if we called two times invalidate_mapping_pages()
> > (as the rest of the commit was still here).
> 
> Ah, OK, schedule_on_each_cpu() could certainly do that - it has to wait
> for every CPU to context switch and schedule the worker function.
> 
> There's a lot we could do here.  Such as not doing the schedule_work()
> at all for a cpu which has an empty lru_add_pvec.

First approach proposed, submitted as RFC. Compile-tested only.

---
 mm/swap.c |   35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

Index: linux/mm/swap.c
===
--- linux.orig/mm/swap.c
+++ linux/mm/swap.c
@@ -652,7 +652,40 @@ static void lru_add_drain_per_cpu(struct
  */
 int lru_add_drain_all(void)
 {
-   return schedule_on_each_cpu(lru_add_drain_per_cpu);
+   int cpu;
+   struct work_struct __percpu *works;
+
+   works = alloc_percpu(struct work_struct);
+   if (!works)
+   return -ENOMEM;
+
+   get_online_cpus();
+
+   for_each_online_cpu(cpu) {
+   struct pagevec *pvecs = per_cpu(lru_add_pvecs, cpu);
+   struct work_struct *work = per_cpu_ptr(works, cpu);
+   struct pagevec *pvec;
+   int lru;
+
+   INIT_WORK(work, lru_add_drain_per_cpu);
+   for_each_lru(lru) {
+   pvec = [lru - LRU_BASE];
+   if (pagevec_count(pvec)) {
+   schedule_work_on(cpu, work);
+   break;
+   }
+   }
+   }
+
+   for_each_online_cpu(cpu) {
+   struct work_struct *work = per_cpu_ptr(works, cpu);
+   if (work_pending(work))
+   flush_work(work);
+   }
+
+   put_online_cpus();
+   free_percpu(works);
+   return 0;
 }
 
 /*

> Or even pass down
> the address_space and only schedule the work for CPUs which have a page
> from *this mapping* in their lru_add_pvec.  That will all be highly
> racy, but as long as the failure mode is "flushed unnecessarily" then
> that's OK.

Second approach, submitted as RFC with some questions left unanswered
in the code. Compile-tested only.

---
 include/linux/swap.h |1 
 mm/fadvise.c |2 -
 mm/swap.c|   62 +++
 3 files changed, 64 insertions(+), 1 deletion(-)

Index: linux/include/linux/swap.h
===
--- linux.orig/include/linux/swap.h
+++ linux/include/linux/swap.h
@@ -242,6 +242,7 @@ extern void mark_page_accessed(struct pa
 extern void lru_add_drain(void);
 extern void lru_add_drain_cpu(int cpu);
 extern int lru_add_drain_all(void);
+extern int lru_add_drain_mapping(struct address_space *mapping);
 extern void rotate_reclaimable_page(struct page *page);
 extern void deactivate_page(struct page *page);
 extern void swap_setup(void);
Index: linux/mm/swap.c
===
--- linux.orig/mm/swap.c
+++ linux/mm/swap.c
@@ -689,6 +689,68 @@ int lru_add_drain_all(void)
 }
 
 /*
+ * Returns 0 for success
+ */
+int lru_add_drain_mapping(struct address_space *mapping)
+{
+   int cpu;
+   struct work_struct __percpu *works;
+
+   works = alloc_percpu(struct work_struct);
+   if (!works)
+   return -ENOMEM;
+
+   get_online_cpus();
+
+   for_each_online_cpu(cpu) {
+   struct pagevec *pvecs = per_cpu(lru_add_pvecs, cpu);
+   struct work_struct *work = per_cpu_ptr(works, cpu);
+   struct pagevec *pvec;
+   int lru;
+
+   INIT_WORK(work, lru_add_drain_per_cpu);
+   for_each_lru(lru) {
+   int i;
+
+   pvec = [lru - LRU_BASE];
+   /*
+* Race failure mode is to flush unnecessarily.
+* We use PAGEVEC_SIZE 

Re: pm: System date and time set incorrectly after suspend/resume to disk

[John Stultz]

On Mon, Jun 17, 2013 at 6:30 PM, Shuah Khan  wrote:
> I am seeing a problem on my system after a suspend to disk in reboot or
> shutdown mode. When pm_trace is 0 (which is the default), I can't
> reproduce the problem easily. I have to run a few more suspend tests
> before I see the problem. When pm_trace is disabled, the problem showed
> up when I ran suspend in platform mode in a row. However when pm_ptrace
> is enabled, problem happens on the very first spend to disk in reboot mode.
>
> Steps to run into the issue:
>
> echo 1 > pm_print_times
> echo 1 > pm_trace
> echo reboot > disk
> echo disk > state
>
> or
>
> echo 1 > pm_print_times
> echo 1 > pm_trace
> echo shutdown > disk
> echo disk > state
>
> When system comes back up, system time set to incorrect time.

So I this is by design. Please see Documentation/power/s2ram.txt for details:

"pm_trace uses the system's Real Time Clock (RTC) to save the magic number.
Reason for this is that the RTC is the only reliably available piece of
hardware during resume operations where a value can be set that will
survive a reboot.

Consequence is that after a resume (even if it is successful) your system
clock will have a value corresponding to the magic number instead of the
correct date/time! It is therefore advisable to use a program like ntp-date
or rdate to reset the correct date/time from an external time source when
using this trace option."

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

Re: ext4 extent status tree LRU locking

[Zheng Liu]

On Mon, Jun 17, 2013 at 02:12:10PM -0700, Dave Hansen wrote:
> On 06/17/2013 03:10 AM, Zheng Liu wrote:
> > Dave, that would be great if you could do your testing again to confirm
> > this patch is useful.
> 
> I was able to apply this to Ted's
> 
>   https://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/
> 
> "ext4/dev" tree with a bit of fuzz.  What did you generate this against,
> btw?

Ah, sorry, I forgot to mention that this patch bases against ext4/master
branch.  Now ext4/dev branch has some regression when I run xfstests.
So I don't base against this branch to generate my patch.

Ted, I notice that now in ext4 tree we have 'dev', 'dev-with-revert',
and 'dev2' branches.  Which one is the best to generate a new patch for
the next merge window?

> 
> It does seem to be functioning OK for me, and passes the other tests
> that saw so much spinlock contention previously.  You can add my
> Tested-by if you like.

Thanks for your testing.

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

Không muốn nhận email bản tin!

[PHPList]

Không nhận thư bản tin!.

  Bạn đã bỏ đăng ký nhận tin từ chúng tôi thành công.

  Đây là email cuối cùng bạn sẽ nhận được từ chúng
tôi. Chúng tôi đã thêm bạn vào danh sách "không gửi email
bản tin", có nghĩa là hệ thống bản tin của chúng tôi,không
gửi cho bạn bất kỳ tin nhắn hơn nữa, mà không có sự can
thiệp của hướng dẫn sử dụng bởi người quản trị của
chúng tôi.

  Nếu có một lỗi trong thông tin này, bạn có thể tái
đăng ký: Bỏ khỏi danh sách gửi bản tin
https://bluecom.vn/mkt/?p=subscribe và làm theo các bước hướng
dẫn.

  Cảm ơn bạn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Part1 PATCH v5 00/22] x86, ACPI, numa: Parse numa info earlier

[Tejun Heo]

Hello,

On Thu, Jun 13, 2013 at 09:02:47PM +0800, Tang Chen wrote:
> One commit that tried to parse SRAT early get reverted before v3.9-rc1.
> 
> | commit e8d1955258091e4c92d5a975ebd7fd8a98f5d30f
> | Author: Tang Chen 
> | Date:   Fri Feb 22 16:33:44 2013 -0800
> |
> |acpi, memory-hotplug: parse SRAT before memblock is ready
> 
> It broke several things, like acpi override and fall back path etc.
> 
> This patchset is clean implementation that will parse numa info early.
> 1. keep the acpi table initrd override working by split finding with copying.
>finding is done at head_32.S and head64.c stage,
> in head_32.S, initrd is accessed in 32bit flat mode with phys addr.
> in head64.c, initrd is accessed via kernel low mapping address
> with help of #PF set page table.
>copying is done with early_ioremap just after memblock is setup.
> 2. keep fallback path working. numaq and ACPI and amd_nmua and dummy.
>seperate initmem_init to two stages.
>early_initmem_init will only extract numa info early into numa_meminfo.
>initmem_init will keep slit and emulation handling.
> 3. keep other old code flow untouched like relocate_initrd and initmem_init.
>early_initmem_init will take old init_mem_mapping position.
>it call early_x86_numa_init and init_mem_mapping for every nodes.
>For 64bit, we avoid having size limit on initrd, as relocate_initrd
>is still after init_mem_mapping for all memory.
> 4. last patch will try to put page table on local node, so that memory
>hotplug will be happy.
> 
> In short, early_initmem_init will parse numa info early and call
> init_mem_mapping to set page table for every nodes's mem.

So, can you please explain why you're doing the above?  What are you
trying to achieve in the end and why is this the best approach?  This
is all for memory hotplug, right?

I can understand the part where you're move NUMA discovery before
initializations which will get allocated permanent addresses in the
wrong nodes, but trying to do the same with memblock itself is making
the code extremely fragile.  It's nasty because there's nothing
apparent which seems to necessitate such ordering.  The ordering looks
rather arbitrary but changing the orders will subtly break memory
hotplug support, which is a really bad way to structure the code.

Can't you just move memblock arrays after NUMA init is complete?
That'd be a lot simpler and way more robust than the proposed changes,
no?

Thanks.

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

Re: Re: [PATCH] tracing/uprobes: Support ftrace_event_file base multibuffer

[Steven Rostedt]

On Tue, 2013-06-18 at 10:31 +0900, Masami Hiramatsu wrote:
> (2013/06/17 21:33), Steven Rostedt wrote:

> > The only reason ftrace function tracer uses the raw (and now
> > raw_notrace) version is because it is extremely invasive, and these
> > checks done at *every* function call can actually live lock the system.
> > But other places in tracing use the appropriate rcu_dereference_*()
> > functions. If they do not, then they need to be fixed too.
> 
> Oh, I see.
> Anyway, it will be completely replaced by the Oleg's patch.
> Or should I fix that before his work?

It's not that urgent. If Oleg's patch will replace it, I wouldn't
bother.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
 > 
 > > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
 > > loaded.
 > > (Note, no X running on that box)
 > > 
 > > Trace below shows trinity, but I can reproduce it with just cat
 > > /proc/dri/0/vma
 > 
 > How about this, lets just rip it all out.

That's one way to deal with it :)
If no programs use it, then yeah, sure, why not.

Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: BUG: rtc: rtc_device_unregister() broken in 3.10-rcN

[Jingoo Han]

On Tuesday, June 18, 2013 12:40 AM, Alexander Holler wrote:
> Am 14.06.2013 19:19, schrieb Alexander Holler:
> > Hello,
> >
> > I've just tested some things with 3.10-rc5+ and discovered that
> > rtc_device_unregister is broken. This is most likely because of the
> > switch to devm*. As 3.10 is already at -rc5, I'm posting this without

CC'ed Dmitry Torokhov, Sachin Kamat


Hi Alexander,

You are using 'drivers/rtc/rtc-hid-sensor-time.c', right?
If so, would you revert '479243b rtc: hid-sensor-time: use 
devm_rtc_device_register()',
and give the result?


Hi Dmitry, Sachin,
You can see the kernel debug message, when the problem happens.
(http://lists-archives.com/linux-kernel/27855385-bug-rtc-rtc_unregister_device-broken-in-3-10-rcn.html)


Best regards,
Jingoo Han

> 
> Just in case the question arises, this worked and works perfectly with
> 3.9.x, so maybe I should have named it REGRESSION rather than BUG.
> 
> Regards,
> 
> Alexander
> 
> PS: I changed typo in the subject from rtc_unregister_device to
> rtc_device_unregister

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Part1 PATCH v5 16/22] x86, mm, numa: Move numa emulation handling down.

[Tejun Heo]

On Thu, Jun 13, 2013 at 09:03:03PM +0800, Tang Chen wrote:
> From: Yinghai Lu 
> 
> numa_emulation() needs to allocate buffer for new numa_meminfo
> and distance matrix, so execute it later in x86_numa_init().
> 
> Also we change the behavoir:
>   - before this patch, if user input wrong data in command
> line, it will fall back to next numa probing or disabling
> numa.
>   - after this patch, if user input wrong data in command line,
> it will stay with numa info probed from previous probing,
> like ACPI SRAT or amd_numa.
> 
> We need to call numa_check_memblks to reject wrong user inputs early
> so that we can keep the original numa_meminfo not changed.

So, this is another very subtle ordering you're adding without any
comment and I'm not sure it even makes sense because the function can
fail after that point.

I'm getting really doubtful about this whole approach of carefully
splitting discovery and registration.  It's inherently fragile like
hell and the poor documentation makes it a lot worse.  I'm gonna reply
to the head message.

Thanks.

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

[RESEND PATCH] iommu: Split iommu_unmaps

[Alex Williamson]

iommu_map splits requests into pages that the iommu driver reports
that it can handle.  The iommu_unmap path does not do the same.  This
can cause problems not only from callers that might expect the same
behavior as the map path, but even from the failure path of iommu_map,
should it fail at a point where it has mapped and needs to unwind a
set of pages that the iommu driver cannot handle directly.  amd_iommu,
for example, will BUG_ON if asked to unmap a non power of 2 size.

Fix this by extracting and generalizing the sizing code from the
iommu_map path and use it for both map and unmap.

Signed-off-by: Alex Williamson 
---
 drivers/iommu/iommu.c |   63 +++--
 1 file changed, 35 insertions(+), 28 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d8f98b1..4b0b56b 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -754,6 +754,38 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
 }
 EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
 
+static size_t iommu_pgsize(struct iommu_domain *domain,
+  unsigned long addr_merge, size_t size)
+{
+   unsigned int pgsize_idx;
+   size_t pgsize;
+
+   /* Max page size that still fits into 'size' */
+   pgsize_idx = __fls(size);
+
+   /* need to consider alignment requirements ? */
+   if (likely(addr_merge)) {
+   /* Max page size allowed by address */
+   unsigned int align_pgsize_idx = __ffs(addr_merge);
+   pgsize_idx = min(pgsize_idx, align_pgsize_idx);
+   }
+
+   /* build a mask of acceptable page sizes */
+   pgsize = (1UL << (pgsize_idx + 1)) - 1;
+
+   /* throw away page sizes not supported by the hardware */
+   pgsize &= domain->ops->pgsize_bitmap;
+
+   /* make sure we're still sane */
+   BUG_ON(!pgsize);
+
+   /* pick the biggest page */
+   pgsize_idx = __fls(pgsize);
+   pgsize = 1UL << pgsize_idx;
+
+   return pgsize;
+}
+
 int iommu_map(struct iommu_domain *domain, unsigned long iova,
  phys_addr_t paddr, size_t size, int prot)
 {
@@ -785,32 +817,7 @@ int iommu_map(struct iommu_domain *domain, unsigned long 
iova,
(unsigned long)paddr, (unsigned long)size);
 
while (size) {
-   unsigned long pgsize, addr_merge = iova | paddr;
-   unsigned int pgsize_idx;
-
-   /* Max page size that still fits into 'size' */
-   pgsize_idx = __fls(size);
-
-   /* need to consider alignment requirements ? */
-   if (likely(addr_merge)) {
-   /* Max page size allowed by both iova and paddr */
-   unsigned int align_pgsize_idx = __ffs(addr_merge);
-
-   pgsize_idx = min(pgsize_idx, align_pgsize_idx);
-   }
-
-   /* build a mask of acceptable page sizes */
-   pgsize = (1UL << (pgsize_idx + 1)) - 1;
-
-   /* throw away page sizes not supported by the hardware */
-   pgsize &= domain->ops->pgsize_bitmap;
-
-   /* make sure we're still sane */
-   BUG_ON(!pgsize);
-
-   /* pick the biggest page */
-   pgsize_idx = __fls(pgsize);
-   pgsize = 1UL << pgsize_idx;
+   size_t pgsize = iommu_pgsize(domain, iova | paddr, size);
 
pr_debug("mapping: iova 0x%lx pa 0x%lx pgsize %lu\n", iova,
(unsigned long)paddr, pgsize);
@@ -863,9 +870,9 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned 
long iova, size_t size)
 * or we hit an area that isn't mapped.
 */
while (unmapped < size) {
-   size_t left = size - unmapped;
+   size_t pgsize = iommu_pgsize(domain, iova, size - unmapped);
 
-   unmapped_page = domain->ops->unmap(domain, iova, left);
+   unmapped_page = domain->ops->unmap(domain, iova, pgsize);
if (!unmapped_page)
break;
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tcp: Modify the condition for the first skb to collapse

[Jun Chen]

On Mon, 2013-06-17 at 06:21 -0700, Eric Dumazet wrote:
> On Mon, 2013-06-17 at 14:52 -0400, Jun Chen wrote:
> > On Mon, 2013-06-17 at 03:29 -0700, Eric Dumazet wrote:
> > > On Mon, 2013-06-17 at 13:29 -0400, Jun Chen wrote:
> > > > > 
> > > > hi,
> > > > When the condition of tcp_win_from_space(skb->truesize) > skb->len is
> > > > true but the before(start, TCP_SKB_CB(skb)->seq) is also true, the final
> > > > condition will be true. The follow line:
> > > > int offset = start - TCP_SKB_CB(skb)->seq;
> > > > BUG_ON(offset < 0);
> > > > this BUG_ON will be triggered.
> > > > 
> > > 
> > > Really this should never happen, we must track what's happening here.
> > It's very very rare, but the logic of codes have such a little hole.
> > > 
> > > Are you using a pristine kernel, without any patches ?
> > The based kernel version is 3.4.  
> > > 
> > > Are you able to reproduce this bug in a short amount of time ?
> > I can't reproduce it in short time, this log had just been found once
> > for long long time tests on many devices . 
> > > 
> > > What kind of driver is in use ? (your stack trace was truncated)
> > 
> > I attach the whole stack traces for you.
> > 

> Any other suspect messages before this, a memory allocation error for
> example ?
> 
> I believe we have a bug in tcp_collapse() if one alloc_skb() returns
> NULL while we were in the middle of collapsing a big GRO packet.
> 
> gro_skb needed 3 skb to be rebuilt, and only two skbs could be allocated
> 
> skb1: seq=X  end_seq=X+4000
> skb2: seq=X+4000 end_seq=X+8000
> 
> grp_skb: seq=X end_seq=X+16000
> 
> Next time we call tcp_collapse(), we might split again the GRO packet
> and get following incorrect queue :
> 
> skb1: seq=X  end_seq=X+4000
> skb2: seq=X+4000 end_seq=X+8000
> skb3: seq=X  end_seq=X+4000
> skb4: seq=X+4000 end_seq=X+8000
> skb5: seq=X+8000 end_seq=X+12000
> skb6: seq=X+12000 end_seq=X+16000
> 
> 
> I would use the following patch instead, to narrow the problem
> 
> If we really find in the ofo queue a skb with a lower seq than the
> previous one, we should complain instead of lowering @start, since
> this is going to crash later.
> 
> receive_queue / ofo_queue should contain monotonically increasing
> skb->seq.
> 
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 46271cdc..5507a09 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4513,8 +4513,10 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
>   start = TCP_SKB_CB(skb)->seq;
>   end = TCP_SKB_CB(skb)->end_seq;
>   } else {
> - if (before(TCP_SKB_CB(skb)->seq, start))
> - start = TCP_SKB_CB(skb)->seq;
> + if (before(TCP_SKB_CB(skb)->seq, start)) {
> + pr_err_once("tcp_collapse_ofo_queue() : seq 
> %08x before start %08X\n",
> + TCP_SKB_CB(skb)->seq, start);
> + }
>   if (after(TCP_SKB_CB(skb)->end_seq, end))
>   end = TCP_SKB_CB(skb)->end_seq;
>   }
> 
> 
There are many warning for tcp_recvmsg before this crash. I can't find
other memory warning in the logs, but I'm not sure whether there are
memory issues because of the length limitation of saved logs. I think
this logs will give you more information.

<4>[ 7736.343742] [ cut here ]

<4>[ 7736.343759] WARNING:
at /data/buildbot/workdir/jb/kernel/net/ipv4/tcp.c:1496 tcp_recvmsg
+0x3bf/0x910()

<4>[ 7736.343775] recvmsg bug: copied AB57C870 seq AB57CD95 rcvnxt
AB57F19F fl 0

<4>[ 7736.343845] Call Trace:

<4>[ 7736.343865]  [] warn_slowpath_common+0x72/0xa0

<4>[ 7736.343888]  [] ? tcp_recvmsg+0x3bf/0x910

<4>[ 7736.343902]  [] ? tcp_recvmsg+0x3bf/0x910

<4>[ 7736.343922]  [] warn_slowpath_fmt+0x33/0x40

<4>[ 7736.343944]  [] tcp_recvmsg+0x3bf/0x910

<4>[ 7736.343968]  [] inet_recvmsg+0x85/0xa0

<4>[ 7736.343992]  [] sock_aio_read+0x140/0x160

<4>[ 7736.344016]  [] ? set_next_entity+0xc1/0xf0

<4>[ 7736.344039]  [] do_sync_read+0xb7/0xf0

<4>[ 7736.344064]  [] ? rw_verify_area+0x6c/0x120

<4>[ 7736.344077]  [] ? sys_epoll_wait+0x68/0x360

<4>[ 7736.344098]  [] vfs_read+0x149/0x160

<4>[ 7736.344120]  [] ? fget_light+0x58/0xd0

<4>[ 7736.344142]  [] sys_read+0x3d/0x70

<4>[ 7736.344164]  [] syscall_call+0x7/0xb

<4>[ 7736.344187]  [] ? perf_cpu_notify+0x45/0x89

<4>[ 7736.344205] ---[ end trace b3c5b245ce7ff5b5 ]---



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] amd_iommu: Fix leak in free_pagetable()

[Alex Williamson]

AMD IOMMU initializes domains with a 3 level page table by default
and will dynamically size it up to a 6 level page table.  Sadly,
free_pagetable() ignores this feature and statically frees as if
it's a 3 level page table.  Add support for the extra levels.

Signed-off-by: Alex Williamson 
Cc: sta...@vger.kernel.org
---

Here's the flat version.  It's not terrible, but checkpatch whines
about the level of nesting.

 drivers/iommu/amd_iommu.c |   32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 565c745..95da421 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1908,23 +1908,47 @@ static void domain_id_free(int id)
 
 static void free_pagetable(struct protection_domain *domain)
 {
-   int i, j;
-   u64 *p1, *p2, *p3;
+   int i, j, k, l, m, depth = domain->mode;
+   u64 *p1, *p2, *p3, *p4, *p5, *p6;
 
p1 = domain->pt_root;
 
if (!p1)
return;
 
-   for (i = 0; i < 512; ++i) {
+   for (i = 0; depth > 1 && i < 512; ++i) {
if (!IOMMU_PTE_PRESENT(p1[i]))
continue;
 
p2 = IOMMU_PTE_PAGE(p1[i]);
-   for (j = 0; j < 512; ++j) {
+   for (j = 0; depth > 2 && j < 512; ++j) {
if (!IOMMU_PTE_PRESENT(p2[j]))
continue;
+
p3 = IOMMU_PTE_PAGE(p2[j]);
+   for (k = 0; depth > 3 && k < 512; ++k) {
+   if (!IOMMU_PTE_PRESENT(p3[k]))
+   continue;
+
+   p4 = IOMMU_PTE_PAGE(p3[k]);
+   for (l = 0; depth > 4 && l < 512; ++l) {
+   if (!IOMMU_PTE_PRESENT(p4[l]))
+   continue;
+
+   p5 = IOMMU_PTE_PAGE(p4[l]);
+   for (m = 0; depth > 5 && m < 512; ++m) {
+   if (!IOMMU_PTE_PRESENT(p5[m]))
+   continue;
+   p6 = IOMMU_PTE_PAGE(p5[m]);
+   free_page((unsigned long)p6);
+   }
+
+   free_page((unsigned long)p5);
+   }
+
+   free_page((unsigned long)p4);
+   }
+
free_page((unsigned long)p3);
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.10rc6] /proc/dri/0/vma broken on nouveau.

[David Airlie]

> Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> loaded.
> (Note, no X running on that box)
> 
> Trace below shows trinity, but I can reproduce it with just cat
> /proc/dri/0/vma

How about this, lets just rip it all out.

Dave.From 54f9605737437272f440bbc6cc4adf805334884b Mon Sep 17 00:00:00 2001
From: Dave Airlie 
Date: Tue, 18 Jun 2013 11:38:10 +1000
Subject: [PATCH] drm: remove vma debug code

This lists vma in /proc and is both crash prone and quite possible horribly
racy. Just nuke it I don't think I've used it in years and years.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_debugfs.c |  3 ---
 drivers/gpu/drm/drm_info.c| 54 ---
 drivers/gpu/drm/drm_proc.c|  3 ---
 include/drm/drmP.h|  4 
 4 files changed, 64 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index a05087c..595c8c1 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -48,9 +48,6 @@ static struct drm_info_list drm_debugfs_list[] = {
 	{"clients", drm_clients_info, 0},
 	{"bufs", drm_bufs_info, 0},
 	{"gem_names", drm_gem_name_info, DRIVER_GEM},
-#if DRM_DEBUG_CODE
-	{"vma", drm_vma_info, 0},
-#endif
 };
 #define DRM_DEBUGFS_ENTRIES ARRAY_SIZE(drm_debugfs_list)
 
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index d4b20ce..0d25f8d 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -222,57 +222,3 @@ int drm_gem_name_info(struct seq_file *m, void *data)
 	return 0;
 }
 
-#if DRM_DEBUG_CODE
-
-int drm_vma_info(struct seq_file *m, void *data)
-{
-	struct drm_info_node *node = (struct drm_info_node *) m->private;
-	struct drm_device *dev = node->minor->dev;
-	struct drm_vma_entry *pt;
-	struct vm_area_struct *vma;
-#if defined(__i386__)
-	unsigned int pgprot;
-#endif
-
-	mutex_lock(>struct_mutex);
-	seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
-		   atomic_read(>vma_count),
-		   high_memory, (void *)(unsigned long)virt_to_phys(high_memory));
-
-	list_for_each_entry(pt, >vmalist, head) {
-		vma = pt->vma;
-		if (!vma)
-			continue;
-		seq_printf(m,
-			   "\n%5d 0x%pK-0x%pK %c%c%c%c%c%c 0x%08lx000",
-			   pt->pid,
-			   (void *)vma->vm_start, (void *)vma->vm_end,
-			   vma->vm_flags & VM_READ ? 'r' : '-',
-			   vma->vm_flags & VM_WRITE ? 'w' : '-',
-			   vma->vm_flags & VM_EXEC ? 'x' : '-',
-			   vma->vm_flags & VM_MAYSHARE ? 's' : 'p',
-			   vma->vm_flags & VM_LOCKED ? 'l' : '-',
-			   vma->vm_flags & VM_IO ? 'i' : '-',
-			   vma->vm_pgoff);
-
-#if defined(__i386__)
-		pgprot = pgprot_val(vma->vm_page_prot);
-		seq_printf(m, " %c%c%c%c%c%c%c%c%c",
-			   pgprot & _PAGE_PRESENT ? 'p' : '-',
-			   pgprot & _PAGE_RW ? 'w' : 'r',
-			   pgprot & _PAGE_USER ? 'u' : 's',
-			   pgprot & _PAGE_PWT ? 't' : 'b',
-			   pgprot & _PAGE_PCD ? 'u' : 'c',
-			   pgprot & _PAGE_ACCESSED ? 'a' : '-',
-			   pgprot & _PAGE_DIRTY ? 'd' : '-',
-			   pgprot & _PAGE_PSE ? 'm' : 'k',
-			   pgprot & _PAGE_GLOBAL ? 'g' : 'l');
-#endif
-		seq_printf(m, "\n");
-	}
-	mutex_unlock(>struct_mutex);
-	return 0;
-}
-
-#endif
-
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index d7f2324..92e9abd 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -55,9 +55,6 @@ static const struct drm_info_list drm_proc_list[] = {
 	{"clients", drm_clients_info, 0},
 	{"bufs", drm_bufs_info, 0},
 	{"gem_names", drm_gem_name_info, DRIVER_GEM},
-#if DRM_DEBUG_CODE
-	{"vma", drm_vma_info, 0},
-#endif
 };
 #define DRM_PROC_ENTRIES ARRAY_SIZE(drm_proc_list)
 
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 63d17ee..849523d 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1600,10 +1600,6 @@ int drm_prime_add_dma_buf(struct drm_device *dev, struct drm_gem_object *obj);
 int drm_prime_lookup_obj(struct drm_device *dev, struct dma_buf *buf,
 			 struct drm_gem_object **obj);
 
-#if DRM_DEBUG_CODE
-extern int drm_vma_info(struct seq_file *m, void *data);
-#endif
-
 /* Scatter Gather Support (drm_scatter.h) */
 extern void drm_sg_cleanup(struct drm_sg_mem * entry);
 extern int drm_sg_alloc_ioctl(struct drm_device *dev, void *data,
-- 
1.8.1.2

[PATCH] amd_iommu: Fix leak in free_pagetable()

[Alex Williamson]

AMD IOMMU initializes domains with a 3 level page table by default
and will dynamically size it up to a 6 level page table.  Sadly,
free_pagetable() ignores this feature and statically frees as if
it's a 3 level page table.  Recurse through all the levels to
free everything.

Signed-off-by: Alex Williamson 
Cc: sta...@vger.kernel.org
---

This is obviously a version rewritten to be recursive.  I'll also
post a flat version, take your pick.

 drivers/iommu/amd_iommu.c |   36 +++-
 1 file changed, 15 insertions(+), 21 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 565c745..5496025 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1906,32 +1906,26 @@ static void domain_id_free(int id)
write_unlock_irqrestore(_iommu_devtable_lock, flags);
 }
 
-static void free_pagetable(struct protection_domain *domain)
+static void free_pagetable_level(int level, int max_level, u64 *pt)
 {
-   int i, j;
-   u64 *p1, *p2, *p3;
+   if (level < max_level) {
+   int i;
+   for (i = 0; i < 512; ++i) {
+   if (IOMMU_PTE_PRESENT(pt[i]))
+   free_pagetable_level(level + 1, max_level,
+IOMMU_PTE_PAGE(pt[i]));
+   }
+   }
 
-   p1 = domain->pt_root;
+   free_page((unsigned long)pt);
+}
 
-   if (!p1)
+static void free_pagetable(struct protection_domain *domain)
+{
+   if (!domain->pt_root)
return;
 
-   for (i = 0; i < 512; ++i) {
-   if (!IOMMU_PTE_PRESENT(p1[i]))
-   continue;
-
-   p2 = IOMMU_PTE_PAGE(p1[i]);
-   for (j = 0; j < 512; ++j) {
-   if (!IOMMU_PTE_PRESENT(p2[j]))
-   continue;
-   p3 = IOMMU_PTE_PAGE(p2[j]);
-   free_page((unsigned long)p3);
-   }
-
-   free_page((unsigned long)p2);
-   }
-
-   free_page((unsigned long)p1);
+   free_pagetable_level(PAGE_MODE_1_LEVEL, domain->mode, domain->pt_root);
 
domain->pt_root = NULL;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Part1 PATCH v5 14/22] x86, mm, numa: Set memblock nid later

[Tejun Heo]

On Thu, Jun 13, 2013 at 09:03:01PM +0800, Tang Chen wrote:
> From: Yinghai Lu 
> 
> In order to seperate parsing numa info procedure into two steps,

Short "why" would be nice.

> we need to set memblock nid later because it could change memblock
   ^
   in where?

> array, and possible doube memblock.memory array which will allocate
 ^
 possibly double

> buffer.

 which is bad why?

> Only set memblock nid once for successful path.
> 
> Also rename numa_register_memblks to numa_check_memblks() after
> moving out code of setting memblock nid.
> @@ -676,6 +669,11 @@ void __init x86_numa_init(void)
>  
>   early_x86_numa_init();
>  
> + for (i = 0; i < mi->nr_blks; i++) {
> + struct numa_memblk *mb = >blk[i];
> + memblock_set_node(mb->start, mb->end - mb->start, mb->nid);
> + }
> +

Can we please have some comments explaining the new ordering
requirements?  When reading code, how is one supposed to know that the
ordering of operations is all deliberate and fragile?

Thanks.

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

Re: [Part1 PATCH v5 13/22] x86, mm, numa: Use numa_meminfo to check node_map_pfn alignment

[Tejun Heo]

On Thu, Jun 13, 2013 at 09:03:00PM +0800, Tang Chen wrote:
> From: Yinghai Lu 
> 
> We could use numa_meminfo directly instead of memblock nid in
> node_map_pfn_alignment().
> 
> So we could do setting memblock nid later and only do it once
> for successful path.
> 
> -v2: according to tj, separate moving to another patch.

How about something like,

  Subject: x86, mm, NUMA: Use numa_meminfo instead of memblock in 
node_map_pfn_alignment()

  When sparsemem is used and page->flags doesn't have enough space to
  carry both the sparsemem section and node ID, NODE_NOT_IN_PAGE_FLAGS
  is set and the node is determined from section.  This requires that
  the NUMA nodes aren't more granular than sparsemem sections.
  node_map_pfn_alignment() is used to determine the maximum NUMA
  inter-node alignment which can distinguish all nodes to verify the
  above condition.

  The function currently assumes the NUMA node maps are populated and
  sorted and uses for_each_mem_pfn_range() to iterate memory regions.
  We want this to happen way earlier to support memory hotplug (maybe
  elaborate a bit more here).

  This patch updates node_map_pfn_alignment() so that it iterates over
  numa_meminfo instead and moves its invocation before memory regions
  are registered to memblock and node maps in numa_register_memblks().
  This will help memory hotplug (how...) and as a bonus we register
  memory regions only if the alignment check succeeds rather than
  registering and then failing.

Also, the comment on top of node_map_pfn_alignment() needs to be
updated, right?

Thanks.

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

Re: [PATCH v2 08/11] irqdomain: Refactor irq_domain_associate_many()

[Stephen Rothwell]

Hi all,

On Tue, 18 Jun 2013 11:25:34 +1000 Michael Neuling  wrote:
>
> Michael Neuling  wrote:
> 
> > In next-20130617 we are getting the below crash on POWER7.  Bisecting,
> > points to this patch (d39046ec72 in next)
> 
> Also, reverting just d39046ec72 fixes the crash in next-20130617.

I will revert that commit in linux-next today.

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


pgpH2n8DanCkV.pgp
Description: PGP signature

[3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau 
loaded.
(Note, no X running on that box)

Trace below shows trinity, but I can reproduce it with just cat /proc/dri/0/vma

[ cut here ]
kernel BUG at arch/x86/mm/physaddr.c:79!
invalid opcode:  [#1] PREEMPT SMP 
Modules linked in: tun cmtp kernelcapi rfcomm l2tp_ppp l2tp_netlink l2tp_core 
ipt_ULOG bnep can_bcm scsi_transport_iscsi nfnetlink rds atm bluetooth can_raw 
appletalk netrom pppoe af_key ipx rose p8023 pppox p8022 psnap ppp_generic ax25 
llc slhc af_802154 nfc can rfkill irda crc_ccitt phonet nfsv3 nfs_acl nfs lockd 
sunrpc fscache nouveau video mxm_wmi wmi i2c_algo_bit ttm drm_kms_helper drm 
i5000_edac edac_core tg3 iTCO_wdt iTCO_vendor_support lpc_ich ppdev pcspkr 
microcode mfd_core i2c_i801 i2c_core dcdbas serio_raw ptp i5k_amb pps_core 
shpchp parport_pc floppy parport xfs libcrc32c raid0
CPU: 3 PID: 26586 Comm: trinity-child3 Tainted: GW3.10.0-rc6+ #1 
Hardware name: Dell Inc. Precision WorkStation 490/0DT031, 
BIOS A08 04/25/2008
task: f12041a0 ti: eace4000 task.ti: eace4000
EIP: 0060:[] EFLAGS: 00010206 CPU: 3
EIP is at __phys_addr+0x72/0x76
EAX: 37bfe000 EBX: 37bfe000 ECX: 000c EDX: 37bfe000
ESI: eacc7870 EDI: eacc7870 EBP: eace5e98 ESP: eace5e94
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 80050033 CR2: 0a24116c CR3: 2cc22000 CR4: 07f0
DR0:  DR1:  DR2:  DR3: 
DR6: 0ff0 DR7: 0400
Stack:
 ee11ce30 eace5efc f868c42f c106a0ff 80070007 e6266700 0282 eace5efc
 c15a6ea6 00d0 f2403680 f2403680 eace5efc c115054d f2d40e50 ee11ce68
 f12041a0 eacc7870 10b0 eace4000 1000 c11841cf 00d0 eacc7870
Call Trace:
 [] drm_vma_info+0x39/0x26e [drm]
 [] ? __might_sleep+0x19/0x1ac
 [] ? mutex_lock_nested+0x286/0x39c
 [] ? kmem_cache_alloc_trace+0x282/0x2cc
 [] ? seq_read+0x24d/0x438
 [] seq_read+0xe6/0x438
 [] ? traverse.isra.6+0x256/0x256
 [] proc_reg_read+0x48/0x71
 [] ? proc_reg_write+0x71/0x71
 [] vfs_read+0x80/0x148
 [] SyS_read+0x49/0x7d
 [] sysenter_do_call+0x12/0x32
Code: 27 11 c2 8d 91 00 00 80 00 39 d0 72 cb 8b 0d 2c 27 81 c1 8d 91 00 00 c1 
ff 81 e2 00 00 e0 ff 81 ea 00 20 00 00 39 d0 73 af 0f 0b <0f> 0b 0f 0b 55 89 e5 
53 66 66 66 66 90 89 c2 31 c0 81 fa ff ff

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

pm: System date and time set incorrectly after suspend/resume to disk

[Shuah Khan]

I am seeing a problem on my system after a suspend to disk in reboot or 
shutdown mode. When pm_trace is 0 (which is the default), I can't 
reproduce the problem easily. I have to run a few more suspend tests 
before I see the problem. When pm_trace is disabled, the problem showed 
up when I ran suspend in platform mode in a row. However when pm_ptrace 
is enabled, problem happens on the very first spend to disk in reboot mode.

Steps to run into the issue:

echo 1 > pm_print_times
echo 1 > pm_trace
echo reboot > disk
echo disk > state

or

echo 1 > pm_print_times
echo 1 > pm_trace
echo shutdown > disk
echo disk > state

When system comes back up, system time set to incorrect time.

In this latest round of testing:

time before suspend was Mon Jun 17 16:27 MDT 2013
right after resume was Thu Oct 5 18:24:42 MDT 2028

I have NTP enabled on my system and I have to disable/re-enable NTP from 
Time and Date config menu.

rtc class suspend routine rtc_suspend() does adjustments to account for 
the time spent suspended. Is that the right one run in this case?

rtc_suspend() doesn't run because has_persistent_clock() returns true. 
rtc-cmos pnp driver suspend routines runs.

It is a possible race condition that is triggered when the conditions 
are right.

I have the following enabled in my config

CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

Looking for tips on debugging the problem.

thanks,
-- Shuah
Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research 
America (Silicon Valley) shuah...@samsung.com | (970) 672-0658


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tracing/uprobes: Support ftrace_event_file base multibuffer

[Masami Hiramatsu]

(2013/06/17 21:33), Steven Rostedt wrote:
> On Mon, 2013-06-17 at 11:54 +0900, Masami Hiramatsu wrote:
> 
>>> It makes a lot of sense to me, at least assuming no issues with the
>>> interrupts being disabled, but the checks not spotting this.  Here
>>> is the check:
>>>
>>> preempt_count() != 0 || irqs_disabled()
>>>
>>> (With additional elaboration for if lockdep is enabled.)
>>
>> OK, I see. So I'll convert all the rcu_dereference_raw() to
>> rcu_dereference_sched() except kprobe handler, because in the
>> kprobe handler above check always be true. :)
> 
> I would convert them all to rcu_dereference_sched(), the above check is
> only when CONFIG_DEBUG_LOCK_ALLOC is set. It also annotates what is
> protecting this variable. Please do not avoid a check because "it's
> always true here". You also get people copying that code (like for
> uprobes) and that will skip the check too.
> 
> The only reason ftrace function tracer uses the raw (and now
> raw_notrace) version is because it is extremely invasive, and these
> checks done at *every* function call can actually live lock the system.
> But other places in tracing use the appropriate rcu_dereference_*()
> functions. If they do not, then they need to be fixed too.

Oh, I see.
Anyway, it will be completely replaced by the Oleg's patch.
Or should I fix that before his work?

Thank you,

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


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