date:20141209

Hi Al,

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

fs/nsfs.c: In function 'ns_get_path':
fs/nsfs.c:83:2: error: implicit declaration of function 'current_kernel_time' 
[-Werror=implicit-function-declaration]
  inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
  ^
fs/nsfs.c:83:51: error: incompatible types when assigning to type 'struct 
timespec' from type 'int'
  inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
   ^

Caused by commit 87fb64a6c1f7 ("take the targets of /proc/*/ns/*
symlinks to separate fs").

I have applied the following patch for today.

From: Stephen Rothwell 
Date: Wed, 10 Dec 2014 18:37:32 +1100
Subject: [PATCH] nsfs: need include/ktime.h and timekeeping.h for CURRENT_TIME

Signed-off-by: Stephen Rothwell 
---
 fs/nsfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/nsfs.c b/fs/nsfs.c
index 0791d086804d..7d98db03c2ce 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -3,6 +3,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 static struct vfsmount *nsfs_mnt;
 
-- 
2.1.3

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


pgpyJLTLdYHSH.pgp
Description: OpenPGP digital signature

RE: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work

2014-12-09 Thread Dexuan Cui



Thanks,
-- Dexuan

> -Original Message-
> From: Dexuan Cui
> Sent: Wednesday, December 10, 2014 15:34 PM
> To: 'Vitaly Kuznetsov'
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; KY Srinivasan; Haiyang Zhang
> Subject: RE: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
> 
> > -Original Message-
> > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> > Sent: Tuesday, December 9, 2014 21:06 PM
> > To: Dexuan Cui
> > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> > jasow...@redhat.com; KY Srinivasan; Haiyang Zhang
> > Subject: Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
> >  ..
> > > +  * Here "dhcp_enabled" is only for IPv4 according to Hyper-V host
> > team.
> > > +  *
> > > +  * In the case the host only injects 1 IPv6 address:
> > > +  * new_val->dhcp_enabled is true, but we can't pass
> > BOOTPROTO=dhcp to
> > > +  * the script hv_set_ifconfig, because in some distros (like RHEL7)
> > > +  * BOOTPROTO=dhcp has a special meaning in the config file (e.g.,
> > > +  * /etc/sysconfig/network-scripts/ifcfg-eth0): the network init
> > program
> > > +  * ignores any static IP addr information once there is
> > > +  * BOOTPROTO=dhcp; as a result, IPv6-only injection can't work.
> > > +  *
> > > +  * In the case of IPv6-only injection, BOOTPROTO=dhcp doesn't affect
> > > +  * Ubuntu because it's ignored by the Ubuntu version of
> > > +  * hv_set_ifconfig and it doesn't seem to have special meaning in
> > > +  * Ubuntu.
> > > +  */
> >
> > I just checked and adding "IPV6ADDR=something" when
> "BOOTPROTO=dhcp"
> > works for me with both RHEL7 and Fedora21.
> It doesn't work in my side. :-(
> Running 'ifup eth0' shows some errors(I use "set -x")
> ...
> + /sbin/dhclient -H localhost -1 -q -lf 
> /var/lib/dhclient/dhclient--eth0.lease -pf
> /var/run/dhclient-eth0.pid eth0
> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
BTW, I run with root, and
'chown 777 /etc/sysconfig/network-scripts/ifcfg-eth0" doesn't help.

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

RE: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work

2014-12-09 Thread Dexuan Cui

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Tuesday, December 9, 2014 21:06 PM
> To: Dexuan Cui
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; KY Srinivasan; Haiyang Zhang
> Subject: Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
>  ..
> > +* Here "dhcp_enabled" is only for IPv4 according to Hyper-V host
> team.
> > +*
> > +* In the case the host only injects 1 IPv6 address:
> > +* new_val->dhcp_enabled is true, but we can't pass
> BOOTPROTO=dhcp to
> > +* the script hv_set_ifconfig, because in some distros (like RHEL7)
> > +* BOOTPROTO=dhcp has a special meaning in the config file (e.g.,
> > +* /etc/sysconfig/network-scripts/ifcfg-eth0): the network init
> program
> > +* ignores any static IP addr information once there is
> > +* BOOTPROTO=dhcp; as a result, IPv6-only injection can't work.
> > +*
> > +* In the case of IPv6-only injection, BOOTPROTO=dhcp doesn't affect
> > +* Ubuntu because it's ignored by the Ubuntu version of
> > +* hv_set_ifconfig and it doesn't seem to have special meaning in
> > +* Ubuntu.
> > +*/
> 
> I just checked and adding "IPV6ADDR=something" when "BOOTPROTO=dhcp"
> works for me with both RHEL7 and Fedora21.
It doesn't work in my side. :-(
Running 'ifup eth0' shows some errors(I use "set -x")
...
+ /sbin/dhclient -H localhost -1 -q -lf /var/lib/dhclient/dhclient--eth0.lease 
-pf /var/run/dhclient-eth0.pid eth0
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
done.

I'm trying to find out the cause.

> Other than that I think bringing distribution specifics into kernel.git
> is not a good idea. /etc/sysconfig/network-scripts/ifcfg-* format is
> distro-specific and not all Linux distros support it. Moreover,
I agree.

> different distros can treat setting differently. I think it was wrong to
> stick to this format in kvp daemon from very beginning.
We can also think the current format used in kvp daemon is already
distro-agnostic -- it just happens to look like the style of network config file
used in RHEL :-)

> 
> As a solution I would suggest doing the following: kvp daemon writes all
> received request details in distro-agnostic format in some temporary
> place and then calls distro-specific script to set things up. Actually,
> we already have such script: tools/hv/hv_set_ifconfig.sh
Yeah, this is exactly what we already have today.

> As for this bug I propose the following: remove skipping all
> IPADDR/MASK/... settings in case of "BOOTPROTO=dhcp" and let
> distro-specific script deal with the rest.
> --
>   Vitaly
OK, so the patch would be 1-line only:

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 22b0764..53fdaad 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1314,10 +1314,8 @@ static int kvp_set_ip_info(char *if_name, struct 
hv_kvp_ipaddr_value *new_val)
goto setval_error;

/*
-* We are done!.
+* We are not done... TODO: add comment here.
 */
-   goto setval_done;
-
} else {
error = kvp_write_file(file, "BOOTPROTO", "", "none");
if (error)

I'll send out a v2 after I resolve the "grep ... Permission dinied" issue.

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

[PATCH] scsi:storvsc enable reading from VPD pages on SPC-2

2014-12-09 Thread Long Li

MSFT targets currently claim SPC-2 compliance while they implement post SPC-2 
features. With this patch we can correctly handle WRITE_SAME_16 issues.

This patch fixes an issue where the flag is setup too late in drive 
initialization process.

Reviewed-by: K. Y. Srinivasan 
Signed-off-by: Long Li 
---
 drivers/scsi/scsi_devinfo.c |  1 +
 drivers/scsi/storvsc_drv.c  | 10 --
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index c1d04d4..f6fe0b2 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -211,6 +211,7 @@ static struct {
{"Medion", "Flash XL  MMC/SD", "2.6D", BLIST_FORCELUN},
{"MegaRAID", "LD", NULL, BLIST_FORCELUN},
{"MICROP", "4110", NULL, BLIST_NOTQ},
+   {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES},
{"MYLEX", "DACARMRB", "*", BLIST_REPORTLUN2},
{"nCipher", "Fastness Crypto", NULL, BLIST_FORCELUN},
{"NAKAMICH", "MJ-4.8S", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index e3ba251..2452bb4 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -327,8 +327,6 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size 
(bytes)");
  */
 static int storvsc_timeout = 180;
 
-static int msft_blist_flags = BLIST_TRY_VPD_PAGES;
-
 #define STORVSC_MAX_IO_REQUESTS200
 
 static void storvsc_on_channel_callback(void *context);
@@ -1439,14 +1437,6 @@ static int storvsc_device_configure(struct scsi_device 
*sdevice)
 
sdevice->no_write_same = 1;
 
-   /*
-* Add blist flags to permit the reading of the VPD pages even when
-* the target may claim SPC-2 compliance. MSFT targets currently
-* claim SPC-2 compliance while they implement post SPC-2 features.
-* With this patch we can correctly handle WRITE_SAME_16 issues.
-*/
-   sdevice->sdev_bflags |= msft_blist_flags;
-
return 0;
 }
 
-- 
2.1.0

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

RE: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

2014-12-09 Thread Tian, Kevin

> From: Song, Jike
> Sent: Wednesday, December 10, 2014 2:34 PM
> 
> CC Kevin.
> 
> 
> On 12/09/2014 05:54 PM, Jan Kiszka wrote:
> > On 2014-12-04 03:24, Jike Song wrote:
> >> Hi all,
> >>
> >>   We are pleased to announce the first release of KVMGT project. KVMGT
> is
> >> the implementation of Intel GVT-g technology, a full GPU virtualization
> >> solution. Under Intel GVT-g, a virtual GPU instance is maintained for
> >> each VM, with part of performance critical resources directly assigned.
> >> The capability of running native graphics driver inside a VM, without
> >> hypervisor intervention in performance critical paths, achieves a good
> >> balance of performance, feature, and sharing capability.
> >>
> >>
> >>   KVMGT is still in the early stage:
> >>
> >>- Basic functions of full GPU virtualization works, guest can see a
> >> full-featured vGPU.
> >>  We ran several 3D workloads such as lightsmark, nexuiz, urbanterror
> >> and warsow.
> >>
> >>- Only Linux guest supported so far, and PPGTT must be disabled in
> >> guest through a
> >>  kernel parameter(see README.kvmgt in QEMU).
> >>
> >>- This drop also includes some Xen specific changes, which will be
> >> cleaned up later.
> >>
> >>- Our end goal is to upstream both XenGT and KVMGT, which shares
> ~90%
> >> logic for vGPU
> >>  device model (will be part of i915 driver), with only difference in
> >> hypervisor
> >>  specific services
> >>
> >>- insufficient test coverage, so please bear with stability issues :)
> >>
> >>
> >>
> >>   There are things need to be improved, esp. the KVM interfacing part:
> >>
> >>  1a domid was added to each KVMGT guest
> >>
> >>  An ID is needed for foreground OS switching, e.g.
> >>
> >>  # echo >
> /sys/kernel/vgt/control/foreground_vm
> >>
> >>  domid 0 is reserved for host OS.
> >>
> >>
> >>   2SRCU workarounds.
> >>
> >>  Some KVM functions, such as:
> >>
> >>  kvm_io_bus_register_dev
> >>  install_new_memslots
> >>
> >>  must be called *without* >srcu read-locked. Otherwise it
> >> hangs.
> >>
> >>  In KVMGT, we need to register an iodev only *after* BAR
> >> registers are
> >>  written by guest. That means, we already have >srcu
> hold -
> >>  trapping/emulating PIO(BAR registers) makes us in such a
> condition.
> >>  That will make kvm_io_bus_register_dev hangs.
> >>
> >>  Currently we have to disable rcu_assign_pointer() in such
> >> functions.
> >>
> >>  These were dirty workarounds, your suggestions are high
> welcome!
> >>
> >>
> >>  3syscalls were called to access "/dev/mem" from kernel
> >>
> >>  An in-kernel memslot was added for aperture, but using syscalls
> >> like
> >>  open and mmap to open and access the character device
> "/dev/mem",
> >>  for pass-through.
> >>
> >>
> >>
> >>
> >> The source codes(kernel, qemu as well as seabios) are available at github:
> >>
> >>  git://github.com/01org/KVMGT-kernel
> >>  git://github.com/01org/KVMGT-qemu
> >>  git://github.com/01org/KVMGT-seabios
> >>
> >> In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred.
> >>
> >>
> >>
> >> More information about Intel GVT-g and KVMGT can be found at:
> >>
> >>
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tia
> n
> >>
> >>
> http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%2
> 0GPU%20Virtualization%20Solution_1.pdf
> >>
> >>
> >>
> >> Appreciate your comments, BUG reports, and contributions!
> >>
> >
> > There is an even increasing interest to keep KVM's in-kernel guest
> > interface as small as possible, specifically for security reasons. I'm
> > sure there are some good performance reasons to create a new in-kernel
> > device model, but I suppose those will need good evidences why things
> > are done in the way they finally should be - and not via a user-space
> > device model. This is likely not a binary decision (all userspace vs. no
> > userspace), it is more about the size and robustness of the in-kernel
> > model vs. its performance.

Thanks for explaining the background. We're not against the userspace
model if applied, but based on our analysis we figured out the in-kernel
model is the best suite, not just for performance reason, but also for
the tight couple to i915 functionalities (scheduling, interrupt, security, etc.)
and hypervisor functionalities (GPU shadow page table, etc.) which are 
best handled in kernel directly. Definitely we don't want to split it just for
performance reason, w/o a functionally clear separation, because that 
just creates unnecessary/messy user/kernel interfaces. And now we've
got i915 community's signal that they're willing to pick the core code
into i915 driver, which we're currently working on.

So, not to eliminate the possibility of user/kernel split, how about we first
look at

[RFC] mm:fix zero_page huge_zero_page rss/pss statistic

2014-12-09 Thread Wang, Yalin

smaps_pte_entry() doesn't ignore zero_huge_page,
but it ignore zero_page, because vm_normal_page() will
ignore it. We remove vm_normal_page() call, because walk_page_range()
have ignore VM_PFNMAP vma maps, it's safe to just use pfn_valid(),
so that we can also consider zero_page to be a valid page.

Another change is that we only add map_count >= 2 or mapcount == 1
pages into pss, because zero_page and huge_zero_page's _mapcount is
zero, this means pss will consider evey zero page as a PAGE_SIZE for
every process, this is not correct for pss statistic. We ignore
zero page for pss, just add zero page into rss statistic.

Signed-off-by: Yalin Wang 
---
 fs/proc/task_mmu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 4e0388c..ce503d3 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -458,7 +458,9 @@ static void smaps_pte_entry(pte_t ptent, unsigned long addr,
int mapcount;
 
if (pte_present(ptent)) {
-   page = vm_normal_page(vma, addr, ptent);
+   if (!pte_special(ptent) && pfn_valid(pte_pfn(ptent)))
+   page = pfn_to_page(pte_pfn(ptent));
+
} else if (is_swap_pte(ptent)) {
swp_entry_t swpent = pte_to_swp_entry(ptent);
 
@@ -491,7 +493,7 @@ static void smaps_pte_entry(pte_t ptent, unsigned long addr,
else
mss->shared_clean += ptent_size;
mss->pss += (ptent_size << PSS_SHIFT) / mapcount;
-   } else {
+   } else if (mapcount == 1){
if (pte_dirty(ptent) || PageDirty(page))
mss->private_dirty += ptent_size;
else
-- 
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH net-next 0/9] r8169:update hardware ephy parameter

2014-12-09 Thread Hau

> From: David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, December 10, 2014 7:36 AM
> To: Hau
> Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 0/9] r8169:update hardware ephy parameter
> 
> From: Chunhao Lin 
> Date: Wed, 10 Dec 2014 00:45:54 +0800
> 
> > Update hardware ephy parameter to improve pcie compatibility.
> 
> This really doesn't tell me anything, I really dislike patch series like this 
> one.
> 
> All of the programming is magic values to magic offsets.
> 
> You aren't even trying to describe in the commit log message exactly what
> kind of settings are being changed, and exactly how those changes achieve
> the stated goal.
> 
> Furthermore, the commit description makes no sense at all to me.
> 
> How can programming the ethernet MAC PHY have any influence on PCI-E
> bus compatability?  Or are you programming the PCI bus interface's PHY?
> 
> In what way are you adjusting which settings and in what way do those
> adjustments help improve PCI-E bus behavior?
> 
> You absolutely must describe exactly what the new programming is actually
> doing, precisely, and in detail.  I want to know if some kind of timings are
> being adjusted, and in what way.
> Are some fifo limits being changes?  If so, in what way, and why does that
> help.
> 
> You have to describe what you are doing. Short and non-informative commit
> log messages alongside random changes to undocumented magic constant
> registers is simply unacceptable.
> 

These series patch is an alignment with our latest hardware pcie ephy 
parameters. I will try to explain more on my next patch.

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

Re: [PATCHv4] INPUT: Route keyboard LEDs through the generic LEDs layer.

2014-12-09 Thread Andrew Morton

On Wed, 10 Dec 2014 08:01:00 +0100 John Crispin  wrote:

> Hi
> 
> On 10/12/2014 02:02, Samuel Thibault wrote:
> > This permits to reassign keyboard LEDs to something else than keyboard 
> > "leds"
> > state, by adding keyboard led and modifier triggers connected to a series
> > of VT input LEDs, themselves connected to VT input triggers, which
> > per-input device LEDs use by default.  Userland can thus easily change the 
> > LED
> > behavior of (a priori) all input devices, or of particular input devices.
> > 
> > This also permits to fix #7063 from userland by using a modifier to 
> > implement
> > proper CapsLock behavior and have the keyboard caps lock led show that 
> > modifier
> > state.
> > 
> > [ebro...@mokafive.com: Rebased to 3.2-rc1 or so, cleaned up some includes, 
> > and fixed some constants]
> > [blo...@openwrt.org: CONFIG_INPUT_LEDS stubs should be static inline]
> > [a...@linux-foundation.org: remove unneeded `extern', fix comment layout]
> > Signed-off-by: Samuel Thibault 
> > Signed-off-by: Evan Broder 
> > Reviewed-by: David Herrmann 
> > Tested-by: Pavel Machek 
> > Acked-by: Peter Korsgaard 
> > Signed-off-by: John Crispin 
> 
> I am not sure why my SoB was added. I originally sent a trivial fix up
> for a header file as linux-next was not building (this was a year or
> more ago). I never reviewed this patch nor have I tested it and I
> certainly was not involved in the development. the patch simply broke
> the compile of the Mips based Wifi and DSL SoCs that i maitain.
> 
> ...
>
> this #else part was added by me to make sure that linux-next was
> building again. this really does not qualify my SoB being added.
> 

The SOB is appropriate - you made a change to the code and (presumably)
attached your SOB to that.  The change is briefly described there:

> [blo...@openwrt.org: CONFIG_INPUT_LEDS stubs should be static inline]

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Compiled tridentfb hangs but distribution kernel works fine

2014-12-09 Thread Mike Galbraith

On Tue, 2014-12-09 at 22:33 +0100, Ondrej Zary wrote: 
> Hello,
> I'm doing some work on tridentfb driver but encountered a weird problem.
> 
> When I compile custom kernel with tridentfb, it hangs with Blade3D card (ID 
> 0x9880) in blade_image_blit(). The screen is blank with some artifacts and 
> machine does not respond to ping or keyboard. However, it can be rebooted by 
> Alt+SysRq+B. It works fine with other cards (3DImage 9750 and CyberBlade XP) 
> with no blit implementation. Commenting out contents of blade_image_blit() 
> function makes the hang go away (nothing useful on the screen, of course).
> 
> The weird thing is that the Blade3D card works fine when I load Debian 
> kernels! Debian 3.16-0.bpo.3-686-pae works fine but when I compile 3.16 
> kernel, it hangs.
> 
> Any ideas?

I'd start by looking for what Debian changed in source and/or config.

-Mike

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

Re: [regression] Boot crash with: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")

On Tue, Dec 09, 2014 at 08:50:32AM +, Russell King wrote:
> On Tue, Dec 09, 2014 at 04:55:42PM +0900, Joonsoo Kim wrote:
> > Could you manage this fix for above boot regression in x86?
> > Patch itself is so dirty, because __pa_nodebug() is implemented only
> > in x86. If someone knows better idea, please let me know.
> 
> > +#ifdef CONFIG_X86
> > +   /*
> > +* high_memory isn't direct mapped memory so retrieving it's
> > +* physical address isn't appropriate. But, it would be useful
> > +* to check physical address of highmem boundary so it's
> > +* justfiable to get physical address from it. In x86, there is
> > +* a validation check for this case, so following workaround is
> > +* needed to avoid it.
> > +*/
> > +   highmem_start = __pa_nodebug(high_memory);
> > +#else
> > +   highmem_start = __pa(high_memory);
> > +#endif
> 
> What about:
> 
>   highmem_start = __pa(high_memory - 1) + 1;
> 
> As "high_memory - 1" should be a valid lowmem address.

Thanks for suggestion.
It looks tricky but it would work. I think that this one need to be
fully tested, so the first dirty one is better for the stable tree.

I will check and test Russell's suggestion and send it as clean-up.

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] staging: lustre: Fix the warning messages about casting without __user macro

2014-12-09 Thread Al Viro

On Tue, Dec 09, 2014 at 10:56:12PM -0800, Shalin Mehta wrote:
> From: Shalin Mehta 
> 
> This issue is showed up while compiling with sparse. The iov_base in struct 
> iovec struct explicitly declares that the assigned value should be user space 
> pointer with __user macro. Where as here, the __user macro isn't used while 
> casting.

... and pointers are not user space ones at all.  Which is to say, quit
messing with casts; it's not struct iovec.  Proper fix is to replace
it here (and in almost all places throughout drivers/staging/lustre) with
struct kvec.  And yes, such a patch had been sent.  Still not applied,
AFAICS...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] perf/power/hv-24x7: Use kmem_cache_free() instead of kfree

2014-12-09 Thread Sukadev Bhattiprolu

>From 982bf5a660ae33fbe2f9187187caa6752c66783d Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu 
Date: Wed, 10 Dec 2014 01:43:34 -0500
Subject: [PATCH 2/2] power/perf: hv-24x7: Use kmem_cache_free() instead of
 kfree

Use kmem_cache_free() to free a buffer allocated with kmem_cache_alloc().

Signed-off-by: Sukadev Bhattiprolu 

p#  set2.log
---
 arch/powerpc/perf/hv-24x7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 18e1f49..a2c6211 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -177,7 +177,7 @@ static ssize_t _name##_show(struct device *dev, 
\
}   \
ret = sprintf(buf, _fmt, _expr);\
 e_free:\
-   kfree(page);\
+   kmem_cache_free(hv_page_cache, page);   \
return ret; \
 }  \
 static DEVICE_ATTR_RO(_name)
-- 
1.8.3.1

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

[PATCH 1/2] perf/powerpc/hv-24x7: Use per-cpu page buffer

2014-12-09 Thread Sukadev Bhattiprolu

>From 470c16c8955672103a9529c78dffbb239e9e27b8 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu 
Date: Tue, 9 Dec 2014 22:17:46 -0500
Subject: [PATCH 1/2] perf/poweprc/hv-24x7: Use per-cpu page buffer

The 24x7 counters are continuously running and not updated on an interrupt.
So we record the event counts when stopping the event or deleting it.

But to "read" a single counter in 24x7, we allocate a page and pass it
into the hypervisor (The HV returns the page full of counters from which
we extract the specific counter for this event).

We allocate a page using GFP_USER and when deleting the event, we end up
with the following warning because we are blocking in interrupt context.

[  698.641709] BUG: scheduling while atomic: swapper/0/0/0x1001

We could use GFP_ATOMIC but that could result in failures. Pre-allocate
a buffer so we don't have to allocate in interrupt context. Further as
Michael Ellerman suggested, use Per-CPU buffer so we only need to allocate
once per CPU.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index dba3408..18e1f49 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -217,11 +217,14 @@ static bool is_physical_domain(int domain)
domain == HV_24X7_PERF_DOMAIN_PHYSICAL_CORE;
 }
 
+DEFINE_PER_CPU(char, hv_24x7_reqb[4096]);
+DEFINE_PER_CPU(char, hv_24x7_resb[4096]);
+
 static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
 u16 lpar, u64 *res,
 bool success_expected)
 {
-   unsigned long ret = -ENOMEM;
+   unsigned long ret;
 
/*
 * request_buffer and result_buffer are not required to be 4k aligned,
@@ -243,13 +246,11 @@ static unsigned long single_24x7_request(u8 domain, u32 
offset, u16 ix,
BUILD_BUG_ON(sizeof(*request_buffer) > 4096);
BUILD_BUG_ON(sizeof(*result_buffer) > 4096);
 
-   request_buffer = kmem_cache_zalloc(hv_page_cache, GFP_USER);
-   if (!request_buffer)
-   goto out;
+   request_buffer = (void *)get_cpu_var(hv_24x7_reqb);
+   result_buffer = (void *)get_cpu_var(hv_24x7_resb);
 
-   result_buffer = kmem_cache_zalloc(hv_page_cache, GFP_USER);
-   if (!result_buffer)
-   goto out_free_request_buffer;
+   memset(request_buffer, 0, 4096);
+   memset(result_buffer, 0, 4096);
 
*request_buffer = (struct reqb) {
.buf = {
@@ -278,15 +279,11 @@ static unsigned long single_24x7_request(u8 domain, u32 
offset, u16 ix,
domain, offset, ix, lpar, ret, ret,
result_buffer->buf.detailed_rc,
result_buffer->buf.failing_request_ix);
-   goto out_free_result_buffer;
+   goto out;
}
 
*res = be64_to_cpu(result_buffer->result);
 
-out_free_result_buffer:
-   kfree(result_buffer);
-out_free_request_buffer:
-   kfree(request_buffer);
 out:
return ret;
 }
-- 
1.8.3.1

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

Re: [PATCHv4] INPUT: Route keyboard LEDs through the generic LEDs layer.

2014-12-09 Thread John Crispin

Hi

On 10/12/2014 02:02, Samuel Thibault wrote:
> This permits to reassign keyboard LEDs to something else than keyboard "leds"
> state, by adding keyboard led and modifier triggers connected to a series
> of VT input LEDs, themselves connected to VT input triggers, which
> per-input device LEDs use by default.  Userland can thus easily change the LED
> behavior of (a priori) all input devices, or of particular input devices.
> 
> This also permits to fix #7063 from userland by using a modifier to implement
> proper CapsLock behavior and have the keyboard caps lock led show that 
> modifier
> state.
> 
> [ebro...@mokafive.com: Rebased to 3.2-rc1 or so, cleaned up some includes, 
> and fixed some constants]
> [blo...@openwrt.org: CONFIG_INPUT_LEDS stubs should be static inline]
> [a...@linux-foundation.org: remove unneeded `extern', fix comment layout]
> Signed-off-by: Samuel Thibault 
> Signed-off-by: Evan Broder 
> Reviewed-by: David Herrmann 
> Tested-by: Pavel Machek 
> Acked-by: Peter Korsgaard 
> Signed-off-by: John Crispin 

I am not sure why my SoB was added. I originally sent a trivial fix up
for a header file as linux-next was not building (this was a year or
more ago). I never reviewed this patch nor have I tested it and I
certainly was not involved in the development. the patch simply broke
the compile of the Mips based Wifi and DSL SoCs that i maitain.

the code I touched is marked below

[snip]

> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -79,6 +79,7 @@ struct input_value {
>   * @led: reflects current state of device's LEDs
>   * @snd: reflects current state of sound effects
>   * @sw: reflects current state of device's switches
> + * @leds: leds objects for the device's LEDs
>   * @open: this method is called when the very first user calls
>   *   input_open_device(). The driver must prepare the device
>   *   to start generating events (start polling thread,
> @@ -164,6 +165,8 @@ struct input_dev {
>   unsigned long snd[BITS_TO_LONGS(SND_CNT)];
>   unsigned long sw[BITS_TO_LONGS(SW_CNT)];
>  
> + struct led_classdev *leds;
> +
>   int (*open)(struct input_dev *dev);
>   void (*close)(struct input_dev *dev);
>   int (*flush)(struct input_dev *dev, struct file *file);
> @@ -531,4 +534,29 @@ int input_ff_erase(struct input_dev *dev
>  int input_ff_create_memless(struct input_dev *dev, void *data,
>   int (*play_effect)(struct input_dev *, void *, struct ff_effect 
> *));
>  
> +#ifdef CONFIG_INPUT_LEDS
> +
> +void input_led_init(void);
> +void input_led_exit(void);
> +
> +int input_led_connect(struct input_dev *dev);
> +void input_led_disconnect(struct input_dev *dev);
> +
> +#else
> +
> +static inline void input_led_init(void) { }
> +
> +static inline void input_led_exit(void) { }
> +
> +static inline int input_led_connect(struct input_dev *dev)
> +{
> + return 0;
> +}
> +
> +static inline void input_led_disconnect(struct input_dev *dev)
> +{
> +}
> +
> +#endif
> +

this #else part was added by me to make sure that linux-next was
building again. this really does not qualify my SoB being added.

John















>  #endif
> --- /dev/null
> +++ b/drivers/input/leds.c
> @@ -0,0 +1,272 @@
> +/*
> + * LED support for the input layer
> + *
> + * Copyright 2010-2014 Samuel Thibault 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Keyboard LEDs are propagated by default like the following example:
> + *
> + * VT keyboard numlock trigger
> + * -> vt::numl VT LED
> + * -> vt-numl VT trigger
> + * -> per-device inputX::numl LED
> + *
> + * Userland can however choose the trigger for the vt::numl LED, or
> + * independently choose the trigger for any inputx::numl LED.
> + *
> + *
> + * VT LED classes and triggers are registered on-demand according to
> + * existing LED devices
> + */
> +
> +/* Handler for VT LEDs, just triggers the corresponding VT trigger. */
> +static void vt_led_set(struct led_classdev *cdev,
> +   enum led_brightness brightness);
> +static struct led_classdev vt_leds[LED_CNT] = {
> +#define DEFINE_INPUT_LED(vt_led, nam, deftrig) \
> + [vt_led] = { \
> + .name = "vt::"nam, \
> + .max_brightness = 1, \
> + .brightness_set = vt_led_set, \
> + .default_trigger = deftrig, \
> + }
> +/* Default triggers for the VT LEDs just correspond to the legacy
> + * usage. */
> + DEFINE_INPUT_LED(LED_NUML, "numl", "kbd-numlock"),
> + DEFINE_INPUT_LED(LED_CAPSL, "capsl", "kbd-capslock"),
> + DEFINE_INPUT_LED(LED_SCROLLL, "scrolll", "kbd-scrollock"),
> + DEFINE_INPUT_LED(LED_COMPOSE, "compose", NULL),
> + DEFINE_INPUT_LED(LED_KANA, "kana", "kbd-kanalock"),
> +

Re: [PATCH 4/4] mm/compaction: stop the isolation when we isolate enough freepage

On Mon, Dec 08, 2014 at 10:59:17AM +0100, Vlastimil Babka wrote:
> On 12/08/2014 08:16 AM, Joonsoo Kim wrote:
> >From: Joonsoo Kim 
> >
> >Currently, freepage isolation in one pageblock doesn't consider how many
> >freepages we isolate. When I traced flow of compaction, compaction
> >sometimes isolates more than 256 freepages to migrate just 32 pages.
> >
> >In this patch, freepage isolation is stopped at the point that we
> >have more isolated freepage than isolated page for migration. This
> >results in slowing down free page scanner and make compaction success
> >rate higher.
> >
> >stress-highalloc test in mmtests with non movable order 7 allocation shows
> >increase of compaction success rate and slight improvement of allocation
> >success rate.
> >
> >Allocation success rate on phase 1 (%)
> >62.70 : 64.00
> >
> >Compaction success rate (Compaction success * 100 / Compaction stalls, %)
> >35.13 : 41.50
> 
> This is weird. I could maybe understand that isolating too many

In fact, I also didn't fully understand why it results in this
result. :)

> freepages and then returning them is a waste of time if compaction
> terminates immediately after the following migration (otherwise we
> would keep those free pages for the future migrations within same
> compaction run). And wasting time could reduce success rates for
> async compaction terminating prematurely due to cond_resched(), but
> that should be all the difference, unless there's another subtle
> bug, no?

My guess is that there is bad effect when we release isolated
freepages. In asynchronous compaction, this happens quite easily.
In this case, freepages are returned to page allocator and, maybe,
they are on pcp list or front of buddy list so they would be used by
another user at first. This reduces freepages we can utilize so
compaction is finished earlier.

> 
> >pfn where both scanners meets on compaction complete
> >(separate test due to enormous tracepoint buffer)
> >(zone_start=4096, zone_end=1048576)
> >586034 : 654378
> 
> The difference here suggests that there is indeed another subtle bug
> related to where free scanner restarts, and we must be leaving the
> excessively isolated (and then returned) freepages behind. Otherwise
> I think the scanners should meet at the same place regardless of
> your patch.

I tried to find another subtle bug, but, can't find any critical one.
Hmm...

Anyway, regardless of the reason of result, this patch seems reasonable,
because we don't need to waste time to isolate unneeded freepages.

Thanks.

> 
> >Signed-off-by: Joonsoo Kim 
> >---
> >  mm/compaction.c |   17 ++---
> >  1 file changed, 10 insertions(+), 7 deletions(-)
> >
> >diff --git a/mm/compaction.c b/mm/compaction.c
> >index 2fd5f79..12223b9 100644
> >--- a/mm/compaction.c
> >+++ b/mm/compaction.c
> >@@ -422,6 +422,13 @@ static unsigned long isolate_freepages_block(struct 
> >compact_control *cc,
> >
> > /* If a page was split, advance to the end of it */
> > if (isolated) {
> >+cc->nr_freepages += isolated;
> >+if (!strict &&
> >+cc->nr_migratepages <= cc->nr_freepages) {
> >+blockpfn += isolated;
> >+break;
> >+}
> >+
> > blockpfn += isolated - 1;
> > cursor += isolated - 1;
> > continue;
> >@@ -831,7 +838,6 @@ static void isolate_freepages(struct compact_control *cc)
> > unsigned long isolate_start_pfn; /* exact pfn we start at */
> > unsigned long block_end_pfn;/* end of current pageblock */
> > unsigned long low_pfn;   /* lowest pfn scanner is able to scan */
> >-int nr_freepages = cc->nr_freepages;
> > struct list_head *freelist = >freepages;
> >
> > /*
> >@@ -856,11 +862,11 @@ static void isolate_freepages(struct compact_control 
> >*cc)
> >  * pages on cc->migratepages. We stop searching if the migrate
> >  * and free page scanners meet or enough free pages are isolated.
> >  */
> >-for (; block_start_pfn >= low_pfn && cc->nr_migratepages > nr_freepages;
> >+for (; block_start_pfn >= low_pfn &&
> >+cc->nr_migratepages > cc->nr_freepages;
> > block_end_pfn = block_start_pfn,
> > block_start_pfn -= pageblock_nr_pages,
> > isolate_start_pfn = block_start_pfn) {
> >-unsigned long isolated;
> >
> > /*
> >  * This can iterate a massively long zone without finding any
> >@@ -885,9 +891,8 @@ static void isolate_freepages(struct compact_control *cc)
> > continue;
> >
> > /* Found a block suitable for isolating free pages from. */
> >-isolated = isolate_freepages_block(cc, _start_pfn,
> >+isolate_freepages_block(cc, _start_pfn,
> >

Re: [PATCH v2] net: introduce helper macro for_each_cmsghdr

2014-12-09 Thread Joe Perches

On Wed, 2014-12-10 at 13:36 +0800, Gu Zheng wrote:
> Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating
> cmsghdr from msghdr, just cleanup. 

This looks nicer.
Ideally this would have used: [PATCH V3] as the subject

> Signed-off-by: Gu Zheng 
> ---
> v2: use the lower-case macro name as Joe suggested.

And a description of the v2->v3 change here.


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

[PATCH] staging: lustre: Fix the warning messages about casting without __user macro

2014-12-09 Thread Shalin Mehta

From: Shalin Mehta 

This issue is showed up while compiling with sparse. The iov_base in struct 
iovec struct explicitly declares that the assigned value should be user space 
pointer with __user macro. Where as here, the __user macro isn't used while 
casting.

Signed-off-by: Shalin Mehta 
---
 drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index d29f5f1..c40b7e0 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -131,7 +131,7 @@ ksocknal_send_iov (ksock_conn_t *conn, ksock_tx_t *tx)
LASSERT (tx->tx_niov > 0);
 
if (nob < (int) iov->iov_len) {
-   iov->iov_base = (void *)((char *)iov->iov_base + nob);
+   iov->iov_base = (void __user *)((char __user 
*)iov->iov_base + nob);
iov->iov_len -= nob;
return rc;
}
@@ -1052,7 +1052,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
case  KSOCK_PROTO_V3:
conn->ksnc_rx_state = SOCKNAL_RX_KSM_HEADER;
conn->ksnc_rx_iov = (struct iovec 
*)>ksnc_rx_iov_space;
-   conn->ksnc_rx_iov[0].iov_base = (char *)>ksnc_msg;
+   conn->ksnc_rx_iov[0].iov_base = (char __user 
*)>ksnc_msg;
 
conn->ksnc_rx_nob_wanted = offsetof(ksock_msg_t, ksm_u);
conn->ksnc_rx_nob_left = offsetof(ksock_msg_t, ksm_u);
@@ -1066,7 +1066,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
conn->ksnc_rx_nob_left = sizeof(lnet_hdr_t);
 
conn->ksnc_rx_iov = (struct iovec 
*)>ksnc_rx_iov_space;
-   conn->ksnc_rx_iov[0].iov_base = (char 
*)>ksnc_msg.ksm_u.lnetmsg;
+   conn->ksnc_rx_iov[0].iov_base = (char __user 
*)>ksnc_msg.ksm_u.lnetmsg;
conn->ksnc_rx_iov[0].iov_len  = sizeof (lnet_hdr_t);
break;
 
@@ -1093,7 +1093,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
do {
nob = MIN (nob_to_skip, sizeof (ksocknal_slop_buffer));
 
-   conn->ksnc_rx_iov[niov].iov_base = ksocknal_slop_buffer;
+   conn->ksnc_rx_iov[niov].iov_base = (void __user 
*)ksocknal_slop_buffer;
conn->ksnc_rx_iov[niov].iov_len  = nob;
niov++;
skipped += nob;
@@ -1218,7 +1218,7 @@ ksocknal_process_receive (ksock_conn_t *conn)
conn->ksnc_rx_nob_left = sizeof(ksock_lnet_msg_t);
 
conn->ksnc_rx_iov = (struct iovec *)>ksnc_rx_iov_space;
-   conn->ksnc_rx_iov[0].iov_base = (char 
*)>ksnc_msg.ksm_u.lnetmsg;
+   conn->ksnc_rx_iov[0].iov_base = (char __user 
*)>ksnc_msg.ksm_u.lnetmsg;
conn->ksnc_rx_iov[0].iov_len  = sizeof(ksock_lnet_msg_t);
 
conn->ksnc_rx_niov = 1;
-- 
1.9.1

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

Re: [PATCH V3 2/2] x86/mm: use min instead of min_t

2014-12-09 Thread Ingo Molnar


* Xishi Qiu  wrote:

> The type of "MAX_DMA_PFN" and "xXx_pfn" are both unsigned long now, so use
> min() instead of min_t().
> 
> Signed-off-by: Xishi Qiu 
> Suggested-by: Andrew Morton 
> ---
>  arch/x86/kernel/e820.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index 49f8864..dd2f07a 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -1114,8 +1114,8 @@ void __init memblock_find_dma_reserve(void)
>* at first, and assume boot_mem will not take below MAX_DMA_PFN
>*/
>   for_each_mem_pfn_range(i, MAX_NUMNODES, _pfn, _pfn, NULL) {
> - start_pfn = min_t(unsigned long, start_pfn, MAX_DMA_PFN);
> - end_pfn = min_t(unsigned long, end_pfn, MAX_DMA_PFN);
> + start_pfn = min(start_pfn, MAX_DMA_PFN);
> + end_pfn = min(end_pfn, MAX_DMA_PFN);
>   nr_pages += end_pfn - start_pfn;

Yes, harmonizing the types is a much nicer solution, it allows 
cleanups like this.

Thanks,

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

[RFC Patch V1 2/9] x86, apic: Correctly detect X2APIC status in function enable_IR()

X2APIC will be disabled if user specifies "nox2apic" on kernel command
line, even when x2apic_preenabled is true. So correctly detect X2APIC
status by using x2apic_enabled() instead of x2apic_preenabled.

Signed-off-by: Jiang Liu 
---
 arch/x86/kernel/apic/apic.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e7a426a589df..b6c473b97c5c 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1580,7 +1580,7 @@ int __init enable_IR(void)
return -1;
}
 
-   if (!x2apic_preenabled && skip_ioapic_setup) {
+   if (!x2apic_enabled() && skip_ioapic_setup) {
pr_info("Skipped enabling intr-remap because of skipping "
"io-apic setup\n");
return -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/

[RFC Patch V1 4/9] iommu/vt-d: Prepare for killing function irq_remapping_supported()

Prepare for killing function irq_remapping_supported() by moving code
from intel_irq_remapping_supported() into intel_prepare_irq_remapping().

Signed-off-by: Jiang Liu 
---
 drivers/iommu/intel_irq_remapping.c |   54 ++-
 1 file changed, 21 insertions(+), 33 deletions(-)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index ff35b0336d2b..9e102168d8ae 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -512,30 +512,6 @@ static int __init dmar_x2apic_optout(void)
 
 static int __init intel_irq_remapping_supported(void)
 {
-   struct dmar_drhd_unit *drhd;
-   struct intel_iommu *iommu;
-
-   if (disable_irq_remap)
-   return 0;
-   if (irq_remap_broken) {
-   printk(KERN_WARNING
-   "This system BIOS has enabled interrupt remapping\n"
-   "on a chipset that contains an erratum making that\n"
-   "feature unstable.  To maintain system stability\n"
-   "interrupt remapping is being disabled.  Please\n"
-   "contact your BIOS vendor for an update\n");
-   add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
-   disable_irq_remap = 1;
-   return 0;
-   }
-
-   if (!dmar_ir_support())
-   return 0;
-
-   for_each_iommu(iommu, drhd)
-   if (!ecap_ir_support(iommu->ecap))
-   return 0;
-
return 1;
 }
 
@@ -560,26 +536,38 @@ static int __init intel_prepare_irq_remapping(void)
struct dmar_drhd_unit *drhd;
struct intel_iommu *iommu;
 
+   if (irq_remap_broken) {
+   printk(KERN_WARNING
+   "This system BIOS has enabled interrupt remapping\n"
+   "on a chipset that contains an erratum making that\n"
+   "feature unstable.  To maintain system stability\n"
+   "interrupt remapping is being disabled.  Please\n"
+   "contact your BIOS vendor for an update\n");
+   add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
+   disable_irq_remap = 1;
+   return -ENODEV;
+   }
+
if (dmar_table_init() < 0)
-   return -1;
+   return -ENODEV;
+
+   if (!dmar_ir_support())
+   return -ENODEV;
 
if (parse_ioapics_under_ir() != 1) {
printk(KERN_INFO "Not enabling interrupt remapping\n");
goto error;
}
 
-   for_each_iommu(iommu, drhd) {
-   if (!ecap_ir_support(iommu->ecap))
-   continue;
-
-   /* Do the allocations early */
-   if (intel_setup_irq_remapping(iommu))
+   for_each_iommu(iommu, drhd)
+   if (!ecap_ir_support(iommu->ecap) ||
+   intel_setup_irq_remapping(iommu))
goto error;
-   }
return 0;
+
 error:
intel_cleanup_irq_remapping();
-   return -1;
+   return -ENODEV;
 }
 
 static int __init intel_enable_irq_remapping(void)
-- 
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/

[RFC Patch V1 6/9] iommu/irq_remapping: Refine function irq_remapping_prepare() for maintenance

Do not directly assign intel_irq_remap_ops to remap_ops.

Signed-off-by: Jiang Liu 
---
 drivers/iommu/irq_remapping.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 2d75f0d69b76..a28001af4e15 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -85,15 +85,15 @@ int __init irq_remapping_prepare(void)
if (disable_irq_remap)
return -ENOSYS;
 
-   remap_ops = _irq_remap_ops;
-
-#ifdef CONFIG_AMD_IOMMU
-   if (amd_iommu_irq_ops.prepare() == 0) {
+   if (intel_irq_remap_ops.prepare() == 0)
+   remap_ops = _irq_remap_ops;
+   else if (IS_ENABLED(CONFIG_AMD_IOMMU) &&
+amd_iommu_irq_ops.prepare() == 0)
remap_ops = _iommu_irq_ops;
-   return 0;
-   }
-#endif
-   return remap_ops->prepare();
+   else
+   return -ENOSYS;
+
+   return 0;
 }
 
 int __init irq_remapping_enable(void)
-- 
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/

[RFC Patch V1 5/9] iommu/irq_remapping: Kill function irq_remapping_supported() and related code

Simplify irq_remapping code by killing irq_remapping_supported() and
related interfaces.

Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/irq_remapping.h |2 --
 arch/x86/kernel/apic/apic.c  |7 +--
 drivers/iommu/amd_iommu.c|1 -
 drivers/iommu/amd_iommu_init.c   |5 -
 drivers/iommu/amd_iommu_proto.h  |1 -
 drivers/iommu/intel_irq_remapping.c  |6 --
 drivers/iommu/irq_remapping.c|   12 ++--
 drivers/iommu/irq_remapping.h|3 ---
 8 files changed, 3 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index ab3bd0f54ba9..f2f52a8bb14e 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -31,7 +31,6 @@ struct irq_alloc_info;
 
 #ifdef CONFIG_IRQ_REMAP
 
-extern int irq_remapping_supported(void);
 extern void set_irq_remapping_broken(void);
 extern int irq_remapping_prepare(void);
 extern int irq_remapping_enable(void);
@@ -57,7 +56,6 @@ static inline struct irq_domain 
*arch_get_ir_parent_domain(void)
 
 #else  /* CONFIG_IRQ_REMAP */
 
-static inline int irq_remapping_supported(void) { return 0; }
 static inline void set_irq_remapping_broken(void) { }
 static inline int irq_remapping_prepare(void) { return -ENODEV; }
 static inline int irq_remapping_enable(void) { return -ENODEV; }
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 2a9bac837be4..4549695b8df0 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1574,12 +1574,7 @@ void enable_x2apic(void)
 
 static int __init try_to_enable_IR(void)
 {
-#ifdef CONFIG_IRQ_REMAP
-   if (!irq_remapping_supported()) {
-   pr_debug("intr-remapping not supported\n");
-   return -1;
-   }
-
+#ifdef CONFIG_X86_IO_APIC
if (!x2apic_enabled() && skip_ioapic_setup) {
pr_info("Skipped enabling intr-remap because of skipping "
"io-apic setup\n");
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index a5c59b434c77..05ffb7c8bfe3 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -4114,7 +4114,6 @@ static struct irq_domain *get_irq_domain(struct 
irq_alloc_info *info)
 }
 
 struct irq_remap_ops amd_iommu_irq_ops = {
-   .supported  = amd_iommu_supported,
.prepare= amd_iommu_prepare,
.enable = amd_iommu_enable,
.disable= amd_iommu_disable,
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index de3390a7d345..fc047a4ee661 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2130,11 +2130,6 @@ int __init amd_iommu_prepare(void)
return iommu_go_to_state(IOMMU_ACPI_FINISHED);
 }
 
-int __init amd_iommu_supported(void)
-{
-   return amd_iommu_irq_remap ? 1 : 0;
-}
-
 int __init amd_iommu_enable(void)
 {
int ret;
diff --git a/drivers/iommu/amd_iommu_proto.h b/drivers/iommu/amd_iommu_proto.h
index 612a22192fa0..fcf61cae53d6 100644
--- a/drivers/iommu/amd_iommu_proto.h
+++ b/drivers/iommu/amd_iommu_proto.h
@@ -33,7 +33,6 @@ extern void amd_iommu_init_notifier(void);
 extern void amd_iommu_init_api(void);
 
 /* Needed for interrupt remapping */
-extern int amd_iommu_supported(void);
 extern int amd_iommu_prepare(void);
 extern int amd_iommu_enable(void);
 extern void amd_iommu_disable(void);
diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 9e102168d8ae..c2255927766b 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -510,11 +510,6 @@ static int __init dmar_x2apic_optout(void)
return dmar->flags & DMAR_X2APIC_OPT_OUT;
 }
 
-static int __init intel_irq_remapping_supported(void)
-{
-   return 1;
-}
-
 static void __init intel_cleanup_irq_remapping(void)
 {
struct dmar_drhd_unit *drhd;
@@ -958,7 +953,6 @@ static struct irq_domain *intel_get_irq_domain(struct 
irq_alloc_info *info)
 }
 
 struct irq_remap_ops intel_irq_remap_ops = {
-   .supported  = intel_irq_remapping_supported,
.prepare= intel_prepare_irq_remapping,
.enable = intel_enable_irq_remapping,
.disable= disable_irq_remapping,
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 66517e7d42f0..2d75f0d69b76 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -80,19 +80,11 @@ void set_irq_remapping_broken(void)
irq_remap_broken = 1;
 }
 
-int irq_remapping_supported(void)
+int __init irq_remapping_prepare(void)
 {
if (disable_irq_remap)
-   return 0;
-
-   if (!remap_ops || !remap_ops->supported)
-   return 0;
+   return -ENOSYS;
 
-   return remap_ops->supported();
-}
-
-int __init

[RFC Patch V1 9/9] iommu/irq_remapping: Kill unused function irq_remapping_print_chip()

Now there's no user of irq_remapping_print_chip(), so kill it.

Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/irq_remapping.h |2 --
 drivers/iommu/irq_remapping.c|   13 -
 2 files changed, 15 deletions(-)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index f2f52a8bb14e..022cb635c294 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -43,7 +43,6 @@ extern struct irq_domain *
 irq_remapping_get_ir_irq_domain( struct irq_alloc_info *info);
 extern struct irq_domain *
 irq_remapping_get_irq_domain(struct irq_alloc_info *info);
-extern void irq_remapping_print_chip(struct irq_data *data, struct seq_file 
*p);
 
 /* Create PCI MSI/MSIx irqdomain, use @parent as the parent irqdomain. */
 extern struct irq_domain *arch_create_msi_irq_domain(struct irq_domain 
*parent);
@@ -79,6 +78,5 @@ irq_remapping_get_irq_domain(struct irq_alloc_info *info)
return NULL;
 }
 
-#defineirq_remapping_print_chipNULL
 #endif /* CONFIG_IRQ_REMAP */
 #endif /* __X86_IRQ_REMAPPING_H */
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index c7ef51a2555a..981f068154de 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -146,19 +146,6 @@ void ir_ack_apic_edge(struct irq_data *data)
ack_APIC_irq();
 }
 
-void irq_remapping_print_chip(struct irq_data *data, struct seq_file *p)
-{
-   /*
-* Assume interrupt is remapped if the parent irqdomain isn't the
-* vector domain, which is true for MSI, HPET and IOAPIC on x86
-* platforms.
-*/
-   if (data->domain && data->domain->parent != arch_get_ir_parent_domain())
-   seq_printf(p, " IR-%s", data->chip->name);
-   else
-   seq_printf(p, " %s", data->chip->name);
-}
-
 /**
  * irq_remapping_get_ir_irq_domain - Get the irqdomain associated with the 
IOMMU
  *  device serving request @info
-- 
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/

[RFC Patch V1 8/9] iommu/irq_remapping: Normailize the way to detect whether IR is enabled

Refine code by normailizing the way to detect whether IR is enabled.

Signed-off-by: Jiang Liu 
---
 drivers/iommu/irq_remapping.c |   30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index fbd585e49ebd..c7ef51a2555a 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -112,22 +112,16 @@ int __init irq_remapping_enable(void)
 
 void irq_remapping_disable(void)
 {
-   if (!irq_remapping_enabled ||
-   !remap_ops ||
-   !remap_ops->disable)
-   return;
-
-   remap_ops->disable();
+   if (irq_remapping_enabled && remap_ops->disable)
+   remap_ops->disable();
 }
 
 int irq_remapping_reenable(int mode)
 {
-   if (!irq_remapping_enabled ||
-   !remap_ops ||
-   !remap_ops->reenable)
-   return 0;
+   if (irq_remapping_enabled && remap_ops->reenable)
+   return remap_ops->reenable(mode);
 
-   return remap_ops->reenable(mode);
+   return 0;
 }
 
 int __init irq_remap_enable_fault_handling(void)
@@ -135,7 +129,7 @@ int __init irq_remap_enable_fault_handling(void)
if (!irq_remapping_enabled)
return 0;
 
-   if (!remap_ops || !remap_ops->enable_faulting)
+   if (!remap_ops->enable_faulting)
return -ENODEV;
 
return remap_ops->enable_faulting();
@@ -176,10 +170,10 @@ void irq_remapping_print_chip(struct irq_data *data, 
struct seq_file *p)
 struct irq_domain *
 irq_remapping_get_ir_irq_domain(struct irq_alloc_info *info)
 {
-   if (!remap_ops || !remap_ops->get_ir_irq_domain)
-   return NULL;
+   if (irq_remapping_enabled && remap_ops->get_ir_irq_domain)
+   return remap_ops->get_ir_irq_domain(info);
 
-   return remap_ops->get_ir_irq_domain(info);
+   return NULL;
 }
 
 /**
@@ -194,8 +188,8 @@ irq_remapping_get_ir_irq_domain(struct irq_alloc_info *info)
 struct irq_domain *
 irq_remapping_get_irq_domain(struct irq_alloc_info *info)
 {
-   if (!remap_ops || !remap_ops->get_irq_domain)
-   return NULL;
+   if (irq_remapping_enabled && remap_ops->get_irq_domain)
+   return remap_ops->get_irq_domain(info);
 
-   return remap_ops->get_irq_domain(info);
+   return NULL;
 }
-- 
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/

[RFC Patch V1 3/9] x86, apic: Refine enable_IR_x2apic() and related functions

Refine enable_IR_x2apic() and related functions for better maintenence.
It also changes the way to treat IR in XAPIC mode as the same as IR is
disabled when enabling X2APIC.

Signed-off-by: Jiang Liu 
---
 arch/x86/kernel/apic/apic.c |   78 ---
 1 file changed, 37 insertions(+), 41 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index b6c473b97c5c..2a9bac837be4 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1572,7 +1572,7 @@ void enable_x2apic(void)
 }
 #endif /* CONFIG_X86_X2APIC */
 
-int __init enable_IR(void)
+static int __init try_to_enable_IR(void)
 {
 #ifdef CONFIG_IRQ_REMAP
if (!irq_remapping_supported()) {
@@ -1585,44 +1585,18 @@ int __init enable_IR(void)
"io-apic setup\n");
return -1;
}
+#endif
 
return irq_remapping_enable();
-#endif
-   return -1;
 }
 
-void __init enable_IR_x2apic(void)
+static __init void try_to_enable_x2apic(int ir_stat)
 {
-   unsigned long flags;
-   int ret;
-   int hardware_init_ret;
-
-   hardware_init_ret = irq_remapping_prepare();
-   if (hardware_init_ret && !x2apic_supported())
-   return;
-
-   ret = save_ioapic_entries();
-   if (ret) {
-   pr_info("Saving IO-APIC state failed: %d\n", ret);
-   return;
-   }
-
-   local_irq_save(flags);
-   legacy_pic->mask_all();
-   mask_ioapic_entries();
-
-   if (x2apic_preenabled && nox2apic)
-   disable_x2apic();
-
-   if (hardware_init_ret)
-   ret = -1;
-   else
-   ret = enable_IR();
-
+#ifdef CONFIG_X86_X2APIC
if (!x2apic_supported())
-   goto skip_x2apic;
+   return;
 
-   if (ret < 0) {
+   if (ir_stat != IRQ_REMAP_X2APIC_MODE) {
/* IR is required if there is APIC ID > 255 even when running
 * under KVM
 */
@@ -1630,8 +1604,9 @@ void __init enable_IR_x2apic(void)
!hypervisor_x2apic_available()) {
if (x2apic_preenabled)
disable_x2apic();
-   goto skip_x2apic;
+   return;
}
+
/*
 * without IR all CPUs can be addressed by IOAPIC/MSI
 * only in physical mode
@@ -1639,19 +1614,40 @@ void __init enable_IR_x2apic(void)
x2apic_force_phys();
}
 
-   if (ret == IRQ_REMAP_XAPIC_MODE) {
-   pr_info("x2apic not enabled, IRQ remapping is in xapic mode\n");
-   goto skip_x2apic;
-   }
-
-   if (x2apic_supported() && !x2apic_mode) {
+   if (!x2apic_mode) {
x2apic_mode = 1;
enable_x2apic();
pr_info("Enabled x2apic\n");
}
+#endif
+}
+
+void __init enable_IR_x2apic(void)
+{
+   unsigned long flags;
+   int ret, ir_stat;
+
+   ir_stat = irq_remapping_prepare();
+   if (ir_stat < 0 && !x2apic_supported())
+   return;
+
+   ret = save_ioapic_entries();
+   if (ret) {
+   pr_info("Saving IO-APIC state failed: %d\n", ret);
+   return;
+   }
+
+   local_irq_save(flags);
+   legacy_pic->mask_all();
+   mask_ioapic_entries();
+
+   if (x2apic_preenabled && nox2apic)
+   disable_x2apic();
+   if (ir_stat >= 0)
+   ir_stat = try_to_enable_IR();
+   try_to_enable_x2apic(ir_stat);
 
-skip_x2apic:
-   if (ret < 0) /* IR enabling failed */
+   if (ir_stat < 0) /* IR enabling failed */
restore_ioapic_entries();
legacy_pic->restore_mask();
local_irq_restore(flags);
-- 
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/

[RFC Patch V1 7/9] iommu/irq_remapping: Change variable disable_irq_remap to be static

Change variable disable_irq_remap to be static for easy maintenance.

Signed-off-by: Jiang Liu 
---
 drivers/iommu/amd_iommu_init.c  |5 ++---
 drivers/iommu/intel_irq_remapping.c |1 -
 drivers/iommu/irq_remapping.c   |3 +--
 drivers/iommu/irq_remapping.h   |2 --
 4 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index fc047a4ee661..e6c34966cdc2 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2018,9 +2018,6 @@ static bool detect_ivrs(void)
/* Make sure ACS will be enabled during PCI probe */
pci_request_acs();
 
-   if (!disable_irq_remap)
-   amd_iommu_irq_remap = true;
-
return true;
 }
 
@@ -2127,6 +2124,8 @@ static int __init iommu_go_to_state(enum iommu_init_state 
state)
 #ifdef CONFIG_IRQ_REMAP
 int __init amd_iommu_prepare(void)
 {
+   amd_iommu_irq_remap = true;
+
return iommu_go_to_state(IOMMU_ACPI_FINISHED);
 }
 
diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index c2255927766b..fba4f7f789a5 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -539,7 +539,6 @@ static int __init intel_prepare_irq_remapping(void)
"interrupt remapping is being disabled.  Please\n"
"contact your BIOS vendor for an update\n");
add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
-   disable_irq_remap = 1;
return -ENODEV;
}
 
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index a28001af4e15..fbd585e49ebd 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -18,12 +18,11 @@
 #include "irq_remapping.h"
 
 int irq_remapping_enabled;
-
-int disable_irq_remap;
 int irq_remap_broken;
 int disable_sourceid_checking;
 int no_x2apic_optout;
 
+static int disable_irq_remap;
 static struct irq_remap_ops *remap_ops;
 
 static void irq_remapping_disable_io_apic(void)
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index 961dc49305e1..8621173c7fcb 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -29,7 +29,6 @@ struct msi_msg;
 struct irq_domain;
 struct irq_alloc_info;
 
-extern int disable_irq_remap;
 extern int irq_remap_broken;
 extern int disable_sourceid_checking;
 extern int no_x2apic_optout;
@@ -66,7 +65,6 @@ extern void ir_ack_apic_edge(struct irq_data *data);
 #else  /* CONFIG_IRQ_REMAP */
 
 #define irq_remapping_enabled 0
-#define disable_irq_remap 1
 #define irq_remap_broken  0
 
 #endif /* CONFIG_IRQ_REMAP */
-- 
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/

[RFC Patch V1 1/9] x86, apic: Kill useless variable x2apic_enabled in function enable_IR_x2apic()

Local variable x2apic_enabled has been assigned to but never referred,
so kill it.

Signed-off-by: Jiang Liu 
---
 arch/x86/kernel/apic/apic.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 141f1031013d..e7a426a589df 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1594,7 +1594,7 @@ int __init enable_IR(void)
 void __init enable_IR_x2apic(void)
 {
unsigned long flags;
-   int ret, x2apic_enabled = 0;
+   int ret;
int hardware_init_ret;
 
hardware_init_ret = irq_remapping_prepare();
@@ -1644,8 +1644,6 @@ void __init enable_IR_x2apic(void)
goto skip_x2apic;
}
 
-   x2apic_enabled = 1;
-
if (x2apic_supported() && !x2apic_mode) {
x2apic_mode = 1;
enable_x2apic();
-- 
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/

[RFC Patch V1 0/9] Simplify initialization of IR on x86 platforms

This is a following-on patch set to simplify initialization of interrupt
remapping subsystem on x86 platforms. Please refer to
https://lkml.org/lkml/2014/12/5/114
for the whole story.

With this patch set applied, there are three steps to initialize IR on x86:
1) "Detect" stage to detect ACPI table for IR at early booting stage
2) "Prepare" stage to allocate resources for IR
3) "Enable" stage to program hardware device to enable IR

Patch 1-3 clean up the code to initialize IR and X2APIC on x86
Patch 4-5 kill the irq_remapping_supported() and related code
Patch 6-9 clean up IR code further.

It's based on tip/x86/apic branch and could be pulled from:
https://github.com/jiangliu/linux.git irq_remapping_v1

It has been tested on Intel platform with X2APIC enabled and disabled.
It also passes Fengguang's 0day test suite. Tests on AMD platform are
welcomed!

Jiang Liu (9):
  x86, apic: Kill useless variable x2apic_enabled in function
enable_IR_x2apic()
  x86, apic: Correctly detect X2APIC status in function enable_IR()
  x86, apic: Refine enable_IR_x2apic() and related functions
  iommu/vt-d: Prepare for killing function irq_remapping_supported()
  iommu/irq_remapping: Kill function irq_remapping_supported() and
related code
  iommu/irq_remapping: Refine function irq_remapping_prepare() for
maintenance
  iommu/irq_remapping: Change variable disable_irq_remap to be static
  iommu/irq_remapping: Normailize the way to detect whether IR is
enabled
  iommu/irq_remapping: Kill unused function irq_remapping_print_chip()

 arch/x86/include/asm/irq_remapping.h |4 --
 arch/x86/kernel/apic/apic.c  |   89 +++---
 drivers/iommu/amd_iommu.c|1 -
 drivers/iommu/amd_iommu_init.c   |   10 +---
 drivers/iommu/amd_iommu_proto.h  |1 -
 drivers/iommu/intel_irq_remapping.c  |   59 --
 drivers/iommu/irq_remapping.c|   74 +---
 drivers/iommu/irq_remapping.h|5 --
 8 files changed, 84 insertions(+), 159 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/

Re: [PATCH 3/4] mm/compaction: enhance compaction finish condition

On Mon, Dec 08, 2014 at 10:34:05AM +0100, Vlastimil Babka wrote:
> On 12/08/2014 08:16 AM, Joonsoo Kim wrote:
> >Compaction has anti fragmentation algorithm. It is that freepage
> >should be more than pageblock order to finish the compaction if we don't
> >find any freepage in requested migratetype buddy list. This is for
> >mitigating fragmentation, but, it is a lack of migratetype consideration
> >and too excessive.
> >
> >At first, it doesn't consider migratetype so there would be false positive
> >on compaction finish decision. For example, if allocation request is
> >for unmovable migratetype, freepage in CMA migratetype doesn't help that
> >allocation, so compaction should not be stopped. But, current logic
> >considers it as compaction is no longer needed and stop the compaction.
> >
> >Secondly, it is too excessive. We can steal freepage from other migratetype
> >and change pageblock migratetype on more relaxed conditions. In page
> >allocator, there is another conditions that can succeed to steal without
> >introducing fragmentation.
> >
> >To solve these problems, this patch borrows anti fragmentation logic from
> >page allocator. It will reduce premature compaction finish in some cases
> >and reduce excessive compaction work.
> >
> >stress-highalloc test in mmtests with non movable order 7 allocation shows
> >in allocation success rate on phase 1 and compaction success rate.
> >
> >Allocation success rate on phase 1 (%)
> >57.00 : 63.67
> >
> >Compaction success rate (Compaction success * 100 / Compaction stalls, %)
> >28.94 : 35.13
> >
> >Signed-off-by: Joonsoo Kim 
> >---
> >  include/linux/mmzone.h |3 +++
> >  mm/compaction.c|   31 +--
> >  mm/internal.h  |1 +
> >  mm/page_alloc.c|5 ++---
> >  4 files changed, 35 insertions(+), 5 deletions(-)
> >
> >diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> >index 2f0856d..87f5bb5 100644
> >--- a/include/linux/mmzone.h
> >+++ b/include/linux/mmzone.h
> >@@ -63,6 +63,9 @@ enum {
> > MIGRATE_TYPES
> >  };
> >
> >+#define FALLBACK_MIGRATETYPES (4)
> >+extern int fallbacks[MIGRATE_TYPES][FALLBACK_MIGRATETYPES];
> >+
> >  #ifdef CONFIG_CMA
> >  #  define is_migrate_cma(migratetype) unlikely((migratetype) == 
> > MIGRATE_CMA)
> >  #else
> >diff --git a/mm/compaction.c b/mm/compaction.c
> >index 1a5f465..2fd5f79 100644
> >--- a/mm/compaction.c
> >+++ b/mm/compaction.c
> >@@ -1054,6 +1054,30 @@ static isolate_migrate_t isolate_migratepages(struct 
> >zone *zone,
> > return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
> >  }
> >
> >+static bool can_steal_fallbacks(struct free_area *area,
> >+unsigned int order, int migratetype)
> >+{
> >+int i;
> >+int fallback_mt;
> >+
> >+if (area->nr_free == 0)
> >+return false;
> >+
> >+for (i = 0; i < FALLBACK_MIGRATETYPES; i++) {
> >+fallback_mt = fallbacks[migratetype][i];
> >+if (fallback_mt == MIGRATE_RESERVE)
> >+break;
> >+
> >+if (list_empty(>free_list[fallback_mt]))
> >+continue;
> >+
> >+if (can_steal_freepages(order, migratetype, fallback_mt))
> >+return true;
> >+}
> >+
> >+return false;
> >+}
> >+
> >  static int __compact_finished(struct zone *zone, struct compact_control 
> > *cc,
> > const int migratetype)
> >  {
> >@@ -1104,8 +1128,11 @@ static int __compact_finished(struct zone *zone, 
> >struct compact_control *cc,
> > if (!list_empty(>free_list[migratetype]))
> > return COMPACT_PARTIAL;
> >
> >-/* Job done if allocation would set block type */
> >-if (order >= pageblock_order && area->nr_free)
> 
> So, can_steal_fallbacks() -> can_steal_freepages() is quite involved
> way if in the end we just realize that order >= pageblock_order and
> we are stealing whole pageblock. Given that often compaction is done
> for THP, it would be better to check order >= pageblock_order and
> handle it upfront. This goes together with my comments on previous
> patch that order >= pageblock_order is better handled separately.

I'd like to keep this order check in can_steal_freepages(). At first, we
should first check migratetype before order checking. If high order page
is on CMA, we can't steal it. Secondly, I think that maintaining well
defined function to check whether we can steal or not is better than
separating logic. It would help future maintanance.

Thanks.

> 
> >+/*
> >+ * Job done if allocation would steal freepages from
> >+ * other migratetype buddy lists.
> >+ */
> >+if (can_steal_fallbacks(area, order, migratetype))
> > return COMPACT_PARTIAL;
> > }
> >
> >diff --git a/mm/internal.h b/mm/internal.h
> >index efad241..7028d83 100644
> >--- a/mm/internal.h
> >+++ b/mm/internal.h
> >@@ -179,6

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

2014-12-09 Thread Jike Song

CC Kevin.

On 12/09/2014 05:54 PM, Jan Kiszka wrote:

On 2014-12-04 03:24, Jike Song wrote:

Hi all,

We are pleased to announce the first release of KVMGT project. KVMGT is
the implementation of Intel GVT-g technology, a full GPU virtualization
solution. Under Intel GVT-g, a virtual GPU instance is maintained for
each VM, with part of performance critical resources directly assigned.
The capability of running native graphics driver inside a VM, without
hypervisor intervention in performance critical paths, achieves a good
balance of performance, feature, and sharing capability.

KVMGT is still in the early stage:

- Basic functions of full GPU virtualization works, guest can see a
full-featured vGPU.
We ran several 3D workloads such as lightsmark, nexuiz, urbanterror
and warsow.

- Only Linux guest supported so far, and PPGTT must be disabled in
guest through a
kernel parameter(see README.kvmgt in QEMU).

- This drop also includes some Xen specific changes, which will be
cleaned up later.

- Our end goal is to upstream both XenGT and KVMGT, which shares ~90%
logic for vGPU
device model (will be part of i915 driver), with only difference in
hypervisor
specific services

- insufficient test coverage, so please bear with stability issues :)

There are things need to be improved, esp. the KVM interfacing part:

1a domid was added to each KVMGT guest

An ID is needed for foreground OS switching, e.g.

# echo >/sys/kernel/vgt/control/foreground_vm

domid 0 is reserved for host OS.

2SRCU workarounds.

Some KVM functions, such as:

kvm_io_bus_register_dev
install_new_memslots

must be called *without* >srcu read-locked. Otherwise it
hangs.

In KVMGT, we need to register an iodev only *after* BAR
registers are
written by guest. That means, we already have >srcu hold -
trapping/emulating PIO(BAR registers) makes us in such a condition.
That will make kvm_io_bus_register_dev hangs.

Currently we have to disable rcu_assign_pointer() in such
functions.

These were dirty workarounds, your suggestions are high welcome!

3syscalls were called to access "/dev/mem" from kernel

An in-kernel memslot was added for aperture, but using syscalls
like
open and mmap to open and access the character device "/dev/mem",
for pass-through.

The source codes(kernel, qemu as well as seabios) are available at github:

git://github.com/01org/KVMGT-kernel
git://github.com/01org/KVMGT-qemu
git://github.com/01org/KVMGT-seabios

In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred.

More information about Intel GVT-g and KVMGT can be found at:

https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%20GPU%20Virtualization%20Solution_1.pdf

Appreciate your comments, BUG reports, and contributions!

There is an even increasing interest to keep KVM's in-kernel guest
interface as small as possible, specifically for security reasons. I'm
sure there are some good performance reasons to create a new in-kernel
device model, but I suppose those will need good evidences why things
are done in the way they finally should be - and not via a user-space
device model. This is likely not a binary decision (all userspace vs. no
userspace), it is more about the size and robustness of the in-kernel
model vs. its performance.

One aspect could also be important: Are there hardware improvements in
sight that will eventually help to reduce the in-kernel device model and
make the overall design even more robust? How will those changes fit
best into a proposed user/kernel split?

Jan

--
Thanks,
Jike
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] mm/page_alloc: expands broken freepage to proper buddy list when steal

On Mon, Dec 08, 2014 at 10:29:44AM +0100, Vlastimil Babka wrote:
> On 12/08/2014 08:16 AM, Joonsoo Kim wrote:
> >There is odd behaviour when we steal freepages from other migratetype
> >buddy list. In try_to_steal_freepages(), we move all freepages in
> >the pageblock that founded freepage is belong to to the request
> >migratetype in order to mitigate fragmentation. If the number of moved
> >pages are enough to change pageblock migratetype, there is no problem. If
> >not enough, we don't change pageblock migratetype and add broken freepages
> >to the original migratetype buddy list rather than request migratetype
> >one. For me, this is odd, because we already moved all freepages in this
> >pageblock to the request migratetype. This patch fixes this situation to
> >add broken freepages to the request migratetype buddy list in this case.
> 
> I'd rather split the fix from the refactoring. And maybe my
> description is longer, but easier to understand? (I guess somebody
> else should judge this)

Your patch is much better to understand than mine. :)
No need to judge from somebody else.
After your patch is merged, I will resubmit these on top of it.

> 
> >This patch introduce new function that can help to decide if we can
> >steal the page without resulting in fragmentation. It will be used in
> >following patch for compaction finish criteria.
> >
> >Signed-off-by: Joonsoo Kim 
> >---
> >  include/trace/events/kmem.h |7 +++--
> >  mm/page_alloc.c |   72 
> > +--
> >  2 files changed, 46 insertions(+), 33 deletions(-)
> >
> >diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> >index aece134..4ad10ba 100644
> >--- a/include/trace/events/kmem.h
> >+++ b/include/trace/events/kmem.h
> >@@ -268,11 +268,11 @@ TRACE_EVENT(mm_page_alloc_extfrag,
> >
> > TP_PROTO(struct page *page,
> > int alloc_order, int fallback_order,
> >-int alloc_migratetype, int fallback_migratetype, int 
> >new_migratetype),
> >+int alloc_migratetype, int fallback_migratetype),
> >
> > TP_ARGS(page,
> > alloc_order, fallback_order,
> >-alloc_migratetype, fallback_migratetype, new_migratetype),
> >+alloc_migratetype, fallback_migratetype),
> >
> > TP_STRUCT__entry(
> > __field(struct page *,  page)
> >@@ -289,7 +289,8 @@ TRACE_EVENT(mm_page_alloc_extfrag,
> > __entry->fallback_order = fallback_order;
> > __entry->alloc_migratetype  = alloc_migratetype;
> > __entry->fallback_migratetype   = fallback_migratetype;
> >-__entry->change_ownership   = (new_migratetype == 
> >alloc_migratetype);
> >+__entry->change_ownership   = (alloc_migratetype ==
> >+get_pageblock_migratetype(page));
> > ),
> >
> > TP_printk("page=%p pfn=%lu alloc_order=%d fallback_order=%d 
> > pageblock_order=%d alloc_migratetype=%d fallback_migratetype=%d 
> > fragmenting=%d change_ownership=%d",
> >diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >index 7c46d0f..7b4c9aa 100644
> >--- a/mm/page_alloc.c
> >+++ b/mm/page_alloc.c
> >@@ -1139,44 +1139,50 @@ static void change_pageblock_range(struct page 
> >*pageblock_page,
> >   * Returns the new migratetype of the pageblock (or the same old 
> > migratetype
> >   * if it was unchanged).
> >   */
> >-static int try_to_steal_freepages(struct zone *zone, struct page *page,
> >-  int start_type, int fallback_type)
> >+static void try_to_steal_freepages(struct zone *zone, struct page *page,
> >+int target_mt)
> >  {
> >+int pages;
> > int current_order = page_order(page);
> >
> >-/*
> >- * When borrowing from MIGRATE_CMA, we need to release the excess
> >- * buddy pages to CMA itself. We also ensure the freepage_migratetype
> >- * is set to CMA so it is returned to the correct freelist in case
> >- * the page ends up being not actually allocated from the pcp lists.
> >- */
> >-if (is_migrate_cma(fallback_type))
> >-return fallback_type;
> >-
> > /* Take ownership for orders >= pageblock_order */
> > if (current_order >= pageblock_order) {
> >-change_pageblock_range(page, current_order, start_type);
> >-return start_type;
> >+change_pageblock_range(page, current_order, target_mt);
> >+return;
> 
> So here's a (current_order >= pageblock_order) check.
> 
> > }
> >
> >-if (current_order >= pageblock_order / 2 ||
> >-start_type == MIGRATE_RECLAIMABLE ||
> >-page_group_by_mobility_disabled) {
> >-int pages;
> >+pages = move_freepages_block(zone, page, target_mt);
> >
> >-pages = move_freepages_block(zone, page, start_type);
> >+/* Claim the whole block if over half of it is free */
>

Re: [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

2014-12-09 Thread Jike Song

CC Kevin.

On 12/09/2014 05:54 PM, Jan Kiszka wrote:

On 2014-12-04 03:24, Jike Song wrote:

Hi all,

KVMGT is still in the early stage:

- Basic functions of full GPU virtualization works, guest can see a
full-featured vGPU.
We ran several 3D workloads such as lightsmark, nexuiz, urbanterror
and warsow.

- Only Linux guest supported so far, and PPGTT must be disabled in
guest through a
kernel parameter(see README.kvmgt in QEMU).

- This drop also includes some Xen specific changes, which will be
cleaned up later.

- Our end goal is to upstream both XenGT and KVMGT, which shares ~90%
logic for vGPU
device model (will be part of i915 driver), with only difference in
hypervisor
specific services

- insufficient test coverage, so please bear with stability issues :)

There are things need to be improved, esp. the KVM interfacing part:

1a domid was added to each KVMGT guest

An ID is needed for foreground OS switching, e.g.

# echo >/sys/kernel/vgt/control/foreground_vm

domid 0 is reserved for host OS.

2SRCU workarounds.

Some KVM functions, such as:

kvm_io_bus_register_dev
install_new_memslots

must be called *without* >srcu read-locked. Otherwise it
hangs.

Currently we have to disable rcu_assign_pointer() in such
functions.

These were dirty workarounds, your suggestions are high welcome!

3syscalls were called to access "/dev/mem" from kernel

An in-kernel memslot was added for aperture, but using syscalls
like
open and mmap to open and access the character device "/dev/mem",
for pass-through.

The source codes(kernel, qemu as well as seabios) are available at github:

git://github.com/01org/KVMGT-kernel
git://github.com/01org/KVMGT-qemu
git://github.com/01org/KVMGT-seabios

In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred.

More information about Intel GVT-g and KVMGT can be found at:

https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%20GPU%20Virtualization%20Solution_1.pdf

Appreciate your comments, BUG reports, and contributions!

Jan

--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] enhance compaction success rate

On Mon, Dec 08, 2014 at 10:16:34AM +0100, Vlastimil Babka wrote:
> On 12/08/2014 08:16 AM, Joonsoo Kim wrote:
> >This patchset aims at increase of compaction success rate. Changes are
> >related to compaction finish condition and freepage isolation condition.
> >
> > From these changes, I did stress highalloc test in mmtests with nonmovable
> >order 7 allocation configuration, and success rate (%) at phase 1 are,
> >
> >Base Patch-1 Patch-3 Patch-4
> >55.0057.00   62.67   64.00
> >
> >And, compaction success rate (%) on same test are,
> >
> >Base Patch-1 Patch-3 Patch-4
> >18.4728.94   35.13   41.50
> 
> Did you test Patch-2 separately? Any difference to Patch 1?

I didn't test it separately. I guess that there is no remarkable
difference because it just slightly changes page stealing logic, not
compaction logic. Compaction success rate would not be affected by
patch 2, but, I will check it next time.

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: [RFC PATCH 2/3] mm: more aggressive page stealing for UNMOVABLE allocations

On Tue, Dec 09, 2014 at 10:12:15AM +0100, Vlastimil Babka wrote:
> On 12/09/2014 09:28 AM, Joonsoo Kim wrote:
> >On Mon, Dec 08, 2014 at 11:27:27AM +0100, Vlastimil Babka wrote:
> >>On 12/08/2014 08:11 AM, Joonsoo Kim wrote:
> >>>
> >>>I'm not sure that this change is good. If we steal order 0 pages,
> >>>this may be good. But, sometimes, we try to steal high order page
> >>>and, in this case, there would be many order 0 freepages and blindly
> >>>stealing freepages in that pageblock make the system more fragmented.
> >>
> >>I don't understand. If we try to steal high order page
> >>(current_order >= pageblock_order / 2), then nothing changes, the
> >>condition for extra stealing is the same.
> >
> >More accureately, I means mid order page (current_order <
> >pageblock_order / 2), but, not order 0, such as order 2,3,4(?).
> >In this case, perhaps, the system has enough unmovable order 0 freepages,
> >so we don't need to worry about second kind of fragmentation you
> >mentioned below. Stealing one mid order freepage is enough to satify
> >request.
> 
> OK.
> 
> >>
> >>>MIGRATE_RECLAIMABLE is different case than MIGRATE_UNMOVABLE, because
> >>>it can be reclaimed so excessive migratetype movement doesn't result
> >>>in permanent fragmentation.
> >>
> >>There's two kinds of "fragmentation" IMHO. First, inside a
> >>pageblock, unmovable allocations can prevent merging of lower
> >>orders. This can get worse if we steal multiple pages from a single
> >>pageblock, but the pageblock itself is not marked as unmovable.
> >
> >So, what's the intention pageblock itself not marked as unmovable?
> >I guess that if many pages are moved to unmovable, they can't be easily
> >back and this pageblock is highly fragmented. So, processing more unmovable
> >requests from this pageblock by changing pageblock migratetype makes more
> >sense to me.
> 
> There's the danger that we mark too much pageblocks as unmovable in
> some unmovable allocation spike and even if the number of unmovable
> allocated pages later decreases, they will keep being allocated from
> many unmovable-marked pageblocks, and neither will become empty
> enough to be remarked back. If we don't mark pageblocks unmovable as
> aggressively, it's possible that the unmovable allocations in a
> partially-stolen pageblock will be eventually freed, and no more
> unmovable allocations will occur in that pageblock if it's not
> marked as unmovable.

Hmm... Yes, but, it seems to be really workload dependent. I'll check
the effect of changing pageblock migratetype aggressively on my test bed.

> 
> >>Second kind of fragmentation is when unmovable allocations spread
> >>over multiple pageblocks. Lower order allocations within each such
> >>pageblock might be still possible, but less pageblocks are able to
> >>compact to have whole pageblock free.
> >>
> >>I think the second kind is worse, so when do have to pollute a
> >>movable pageblock with unmovable allocation, we better take as much
> >>as possible, so we prevent polluting other pageblocks.
> >
> >I agree.
> >
> >>
> >>>What I'd like to do to prevent fragmentation is
> >>>1) check whether we can steal all or almost freepages and change
> >>>migratetype of pageblock.
> >>>2) If above condition isn't met, deny allocation and invoke compaction.
> >>
> >>Could work to some extend, but we need also to prevent excessive compaction.
> >
> >So, I suggest knob to control behaviour. In small memory system,
> >fragmentation occurs frequently so the system can't handle just order 2
> >request. In that system, excessive compaction is acceptable because
> >it it better than system down.
> 
> So you say that in these systems, order 2 requests fail because of
> page stealing?

Yes. At some point, system memory is highly fragmented and order 2
requests fail. It would be caused by page stealing but I didn't analyze it.

> >>
> >>We could also introduce a new pageblock migratetype, something like
> >>MIGRATE_MIXED. The idea is that once pageblock isn't used purely by
> >>MOVABLE allocations, it's marked as MIXED, until it either becomes
> >>marked UNMOVABLE or RECLAIMABLE by the existing mechanisms, or is
> >>fully freed. In more detail:
> >>
> >>- MIXED is preferred for fallback before any other migratetypes
> >>- if RECLAIMABLE/UNMOVABLE page allocation is stealing from MOVABLE
> >>pageblock and cannot mark pageblock as RECLAIMABLE/UNMOVABLE (by
> >>current rules), it marks it as MIXED instead.
> >>- if MOVABLE allocation is stealing from UNMOVABLE/RECLAIMABLE
> >>pageblocks, it will only mark it as MOVABLE if it was fully free.
> >>Otherwise, if current rules would result in marking it as MOVABLE
> >>(i.e. most of it was stolen, but not all) it will mark it as MIXED
> >>instead.
> >>
> >>This could in theory leave more MOVABLE pageblocks unspoiled by
> >>UNMOVABLE allocations.
> >
> >I guess that we can do it without introducing new migratetype pageblock.
> >Just always marking it as RECLAIMABLE/UNMOVABLE when
>

linux-next: manual merge of the userns tree with the vfs tree

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in
kernel/user_namespace.c between commits 3c0411846118 ("switch the rest
of proc_ns_operations to working with &...->ns") and 64964528b24e
("make proc_ns_operations work with struct ns_common * instead of void
*") from the vfs tree and commit 2b714ea67ed4 ("userns: Add a knob to
disable setgroups on a per user namespace basis") from the userns 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/user_namespace.c
index 1491ad00388f,1db950ec08ce..
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@@ -842,12 -851,99 +852,104 @@@ static bool new_idmap_permitted(const s
return false;
  }
  
 +static inline struct user_namespace *to_user_ns(struct ns_common *ns)
 +{
 +  return container_of(ns, struct user_namespace, ns);
 +}
 +
+ static void *setgroups_m_start(struct seq_file *seq, loff_t *ppos)
+ {
+   struct user_namespace *ns = seq->private;
+ 
+   return (*ppos == 0) ?  ns : NULL;
+ }
+ 
+ static void *setgroups_m_next(struct seq_file *seq, void *v, loff_t *ppos)
+ {
+   ++*ppos;
+   return NULL;
+ }
+ 
+ static void setgroups_m_stop(struct seq_file *seq, void *v)
+ {
+ }
+ 
+ static int setgroups_m_show(struct seq_file *seq, void *v)
+ {
+   struct user_namespace *ns = seq->private;
+ 
+   seq_printf(seq, "%s\n",
+  test_bit(USERNS_SETGROUPS_ALLOWED, >flags) ?
+  "allow" : "deny");
+   return 0;
+ }
+ 
+ const struct seq_operations proc_setgroups_seq_operations = {
+   .start  = setgroups_m_start,
+   .stop = setgroups_m_stop,
+   .next = setgroups_m_next,
+   .show = setgroups_m_show,
+ };
+ 
+ ssize_t proc_setgroups_write(struct file *file, const char __user *buf,
+size_t count, loff_t *ppos)
+ {
+   struct seq_file *seq = file->private_data;
+   struct user_namespace *ns = seq->private;
+   char kbuf[8], *pos;
+   bool setgroups_allowed;
+   ssize_t ret;
+ 
+   ret = -EACCES;
+   if (!file_ns_capable(file, ns, CAP_SYS_ADMIN))
+   goto out;
+ 
+   /* Only allow a very narrow range of strings to be written */
+   ret = -EINVAL;
+   if ((*ppos != 0) || (count >= sizeof(kbuf)))
+   goto out;
+ 
+   /* What was written? */
+   ret = -EFAULT;
+   if (copy_from_user(kbuf, buf, count))
+   goto out;
+   kbuf[count] = '\0';
+   pos = kbuf;
+ 
+   /* What is being requested? */
+   ret = -EINVAL;
+   if (strncmp(pos, "allow", 5) == 0) {
+   pos += 5;
+   setgroups_allowed = true;
+   }
+   else if (strncmp(pos, "deny", 4) == 0) {
+   pos += 4;
+   setgroups_allowed = false;
+   }
+   else
+   goto out;
+ 
+   /* Verify there is not trailing junk on the line */
+   pos = skip_spaces(pos);
+   if (*pos != '\0')
+   goto out;
+ 
+   if (setgroups_allowed) {
+   ret = -EPERM;
+   if (!userns_setgroups_allowed(ns))
+   goto out;
+   } else {
+   userns_disable_setgroups(ns);
+   }
+ 
+   /* Report a successful write */
+   *ppos = count;
+   ret = count;
+ out:
+   return ret;
+ }
+ 
 -static void *userns_get(struct task_struct *task)
 +static struct ns_common *userns_get(struct task_struct *task)
  {
struct user_namespace *user_ns;
  


pgpmLHHcHwows.pgp
Description: OpenPGP digital signature

Re: [PATCH] sched/fair: change where we report sched stats

2014-12-09 Thread Mike Galbraith

On Tue, 2014-12-09 at 13:21 -0500, Josef Bacik wrote:

> This patch moves stat stuff to after the schedule, right as we are waking up,

But sleep/block ends when the task is awakened/enqueued, not when it
gets the CPU.  You're adding scheduling latency, breaking accounting.

-Mike


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

linux-next: manual merge of the userns tree with the vfs tree

Hi Eric,

Today's linux-next merge of the userns tree got conflicts in
include/linux/user_namespace.h and kernel/user.c between commit
435d5f4bb2cc ("common object embedded into various struct ns") from
the vfs tree and commit 2b714ea67ed4 ("userns: Add a knob to disable
setgroups on a per user namespace basis") from the userns 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 include/linux/user_namespace.h
index 4cf06c140e21,6451c401dcf6..
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@@ -27,7 -32,8 +33,8 @@@ struct user_namespace 
int level;
kuid_t  owner;
kgid_t  group;
 -  unsigned intproc_inum;
 +  struct ns_commonns;
+   unsigned long   flags;
  
/* Register of per-UID persistent keyrings for this namespace */
  #ifdef CONFIG_PERSISTENT_KEYRINGS
diff --cc kernel/user.c
index 69b800aebf13,2d09940c9632..
--- a/kernel/user.c
+++ b/kernel/user.c
@@@ -50,10 -50,8 +50,11 @@@ struct user_namespace init_user_ns = 
.count = ATOMIC_INIT(3),
.owner = GLOBAL_ROOT_UID,
.group = GLOBAL_ROOT_GID,
 -  .proc_inum = PROC_USER_INIT_INO,
 +  .ns.inum = PROC_USER_INIT_INO,
 +#ifdef CONFIG_USER_NS
 +  .ns.ops = _operations,
 +#endif
+   .flags = USERNS_INIT_FLAGS,
  #ifdef CONFIG_PERSISTENT_KEYRINGS
.persistent_keyring_register_sem =
__RWSEM_INITIALIZER(init_user_ns.persistent_keyring_register_sem),


pgp0Z3DrgsTII.pgp
Description: OpenPGP digital signature

Re: [PATCH 6/6] pci, acpi: Share ACPI PCI config space accessors.

2014-12-09 Thread Tomasz Nowicki


W dniu 09.12.2014 o 22:50, Bjorn Helgaas pisze:

On Mon, Dec 8, 2014 at 12:13 AM, Tomasz Nowicki
 wrote:


What would be next steps regarding this patch set? I am not sure we have
reached a consensus on weak vs #ifdef choice.


I work through the list at
https://patchwork.ozlabs.org/project/linux-pci/list/ in FIFO order, so
you don't need to do anything else except poke me to move faster :)


Awesome! I guess I am good at poke people so you can count on me :)

Regards,
Tomasz



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

bcache blocking ops and lockdep warnings

2014-12-09 Thread Sitsofe Wheeler

Hi,

After doing
make-bcache -B /dev/sdf
make-bcache -C /dev/sdh
ls -l /sys/fs/bcache
echo 1110734d-230c-4b8f-a63d-dff472a0977b > /sys/block/bcache0/bcache/attach

the following warnings were produced with a 3.18.0.x86_64-01967-g86c6a2f
kernel:

[   75.218601] bcache: register_bdev() registered backing device sdf
[   82.616568] bcache: run_cache_set() invalidating existing data
[   82.621589] [ cut here ]
[   82.622890] WARNING: CPU: 1 PID: 979 at kernel/sched/core.c:7301 
__might_sleep+0x5c/0xa0()
[   82.624344] do not call blocking ops when !TASK_RUNNING; state=1 set at 
[] bch_allocator_thread+0xd8/0xe30
[   82.625979] CPU: 1 PID: 979 Comm: bcache_allocato Not tainted 
3.18.0.x86_64-01967-g86c6a2f #162
[   82.627468] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090006  05/23/2012
[   82.628949]  0009 8800da963ce8 816ea8af 
0001
[   82.634007]  8800da963d38 8800da963d28 81073f3c 
8800da963d28
[   82.639020]  819d431c 0038  
8800e468a680
[   82.643967] Call Trace:
[   82.645045]  [] dump_stack+0x4e/0x68
[   82.646345]  [] warn_slowpath_common+0x7c/0xa0
[   82.647622]  [] warn_slowpath_fmt+0x46/0x50
[   82.648954]  [] ? bch_allocator_thread+0xd8/0xe30
[   82.650338]  [] ? bch_allocator_thread+0xd8/0xe30
[   82.651667]  [] __might_sleep+0x5c/0xa0
[   82.652959]  [] bch_allocator_thread+0x1c7/0xe30
[   82.654335]  [] ? bch_invalidate_one_bucket+0x80/0x80
[   82.655672]  [] kthread+0x103/0x110
[   82.656939]  [] ? __kthread_unpark+0x50/0x50
[   82.658294]  [] ret_from_fork+0x7c/0xb0
[   82.659664]  [] ? __kthread_unpark+0x50/0x50
[   82.660970] ---[ end trace 15295ea1be01c8a2 ]---
[   82.683570] [ cut here ]
[   82.684559] WARNING: CPU: 7 PID: 974 at kernel/locking/lockdep.c:712 
__lock_acquire+0x21c/0x1c60()
[   82.684559] CPU: 7 PID: 974 Comm: bcache-register Tainted: GW  
3.18.0.x86_64-01967-g86c6a2f #162
[   82.684559] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090006  05/23/2012
[   82.684559]  0009 8800dac8f988 816ea8af 

[   82.684559]   8800dac8f9c8 81073f3c 
8800dac8f9c8
[   82.684559]  82668240  8800dac3da88 
0001
[   82.684559] Call Trace:
[   82.684559]  [] dump_stack+0x4e/0x68
[   82.684559]  [] warn_slowpath_common+0x7c/0xa0
[   82.684559]  [] warn_slowpath_null+0x1a/0x20
[   82.684559]  [] __lock_acquire+0x21c/0x1c60
[   82.684559]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[   82.684559]  [] ? rcu_irq_exit+0x8f/0xb0
[   82.684559]  [] ? __lock_acquire+0x1bc6/0x1c60
[   82.684559]  [] lock_acquire+0xfc/0x150
[   82.684559]  [] ? mca_reap+0x6c/0x170
[   82.684559]  [] down_write_trylock+0x61/0x80
[   82.684559]  [] ? mca_reap+0x6c/0x170
[   82.684559]  [] mca_reap+0x6c/0x170
[   82.684559]  [] mca_alloc+0xe0/0x4b0
[   82.684559]  [] __bch_btree_node_alloc+0xb3/0x240
[   82.684559]  [] run_cache_set+0x6ea/0x950
[   82.684559]  [] ? kernfs_add_one+0x10e/0x160
[   82.684559]  [] register_bcache+0x167f/0x19e0
[   82.684559]  [] kobj_attr_store+0xf/0x20
[   82.684559]  [] sysfs_kf_write+0x48/0x60
[   82.684559]  [] kernfs_fop_write+0xe7/0x170
[   82.684559]  [] vfs_write+0xcb/0x1d0
[   82.684559]  [] ? retint_swapgs+0x13/0x1b
[   82.684559]  [] SyS_write+0x49/0xb0
[   82.684559]  [] system_call_fastpath+0x12/0x17
[   82.684559] ---[ end trace 15295ea1be01c8a3 ]---
[   82.763919] bcache: register_cache() registered cache device sdh

-- 
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.

2014-12-09 Thread Pravin Shelar

On Tue, Dec 9, 2014 at 4:25 PM, Joe Stringer  wrote:
> On 9 December 2014 at 10:32, Pravin Shelar  wrote:
>> On Tue, Dec 2, 2014 at 6:56 PM, Joe Stringer  wrote:
>>> @@ -662,11 +664,18 @@ static void get_dp_stats(const struct datapath *dp, 
>>> struct ovs_dp_stats *stats,
>>> }
>>>  }

>>> +   error = ovs_nla_copy_ufid(a[OVS_FLOW_ATTR_UFID], , log);
>>> +   if (error)
>>> +   return error;
>>> +   if (a[OVS_FLOW_ATTR_KEY]) {
>>> +   ovs_match_init(, , );
>>> +   error = ovs_nla_get_match(, a[OVS_FLOW_ATTR_KEY],
>>> + a[OVS_FLOW_ATTR_MASK], log);
>>> +   } else if (!ufid) {
>>> OVS_NLERR(log, "Flow key attribute not present in set 
>>> flow.");
>>> -   goto error;
>>> +   error = -EINVAL;
>>> }
>>> -
>>> -   ovs_match_init(, , );
>>> -   error = ovs_nla_get_match(, a[OVS_FLOW_ATTR_KEY],
>>> - a[OVS_FLOW_ATTR_MASK], log);
>>> if (error)
>>> goto error;
>>>
>>> -   /* Validate actions. */
>>> -   if (a[OVS_FLOW_ATTR_ACTIONS]) {
>>> -   acts = get_flow_actions(a[OVS_FLOW_ATTR_ACTIONS], , 
>>> ,
>>> -   log);
>>> -   if (IS_ERR(acts)) {
>>> -   error = PTR_ERR(acts);
>>> -   goto error;
>>> -   }
>>> -
>>> -   /* Can allocate before locking if have acts. */
>>> -   reply = ovs_flow_cmd_alloc_info(acts, info, false);
>>> -   if (IS_ERR(reply)) {
>>> -   error = PTR_ERR(reply);
>>> -   goto err_kfree_acts;
>>> -   }
>>> -   }
>>> -
>> Why are you moving this action validation under ovs-lock?
>
> The thought was that flow_cmd_set may receive UFID and not key/mask.
> One could imagine a command that sends a UFID and actions, telling OVS
> kmod to update just the actions. Masked key is required for
> ovs_nla_copy_actions(), so in this case a lookup would be required to
> get a masked key.
>
> Perhaps the better alternative for the moment is to still require flow
> key and mask for this command (just as we do for flow_cmd_new). That
> would simplify this change greatly, and doesn't affect current OVS
> userspace.
>
sounds good.

>>> @@ -1194,9 +1254,18 @@ unlock:
>>>
>>>  static int ovs_flow_cmd_dump(struct sk_buff *skb, struct netlink_callback 
>>> *cb)
>>>  {
>>> +   struct nlattr *a[__OVS_FLOW_ATTR_MAX];
>>> struct ovs_header *ovs_header = genlmsg_data(nlmsg_data(cb->nlh));
>>> struct table_instance *ti;
>>> struct datapath *dp;
>>> +   u32 ufid_flags;
>>> +   int err;
>>> +
>>> +   err = nlmsg_parse(cb->nlh, GENL_HDRLEN + 
>>> dp_flow_genl_family.hdrsize,
>>> + a, dp_flow_genl_family.maxattr, flow_policy);
>>
>> Can you add genl helper function for this?
>
> OK.
>
>>> @@ -1235,6 +1304,8 @@ static const struct nla_policy 
>>> flow_policy[OVS_FLOW_ATTR_MAX + 1] = {
>>> [OVS_FLOW_ATTR_ACTIONS] = { .type = NLA_NESTED },
>>> [OVS_FLOW_ATTR_CLEAR] = { .type = NLA_FLAG },
>>> [OVS_FLOW_ATTR_PROBE] = { .type = NLA_FLAG },
>>> +   [OVS_FLOW_ATTR_UFID] = { .type = NLA_UNSPEC },
>>> +   [OVS_FLOW_ATTR_UFID_FLAGS] = { .type = NLA_U32 },
>>>  };
>>>
>>>  static const struct genl_ops dp_flow_genl_ops[] = {
>>> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
>>> index a8b30f3..7f31dbf 100644
>>> --- a/net/openvswitch/flow.h
>>> +++ b/net/openvswitch/flow.h
>>> @@ -197,6 +197,13 @@ struct sw_flow_match {
>>> struct sw_flow_mask *mask;
>>>  };
>>>
>>> +#define MAX_UFID_LENGTH 256
>>> +
>> For now we can limit this to 128 bits.
>
> Is there a reason beyond trying to avoid the warning in flow_cmd_set()?
> I suppose that its purpose as an identifier means that it's unlikely to
> need to be much bigger in future (indeed, the larger it gets, the more
> it would trade off the performance gains from using it).
>
I am also not sure why would we need ID larger than 128 bit. In such
unlikely scenario I think we can increase it later if we need it.


>>> @@ -213,13 +220,16 @@ struct flow_stats {
>>>
>>>  struct sw_flow {
>>> struct rcu_head rcu;
>>> -   struct hlist_node hash_node[2];
>>> -   u32 hash;
>>> +   struct {
>>> +   struct hlist_node node[2];
>>> +   u32 hash;
>>> +   } flow_hash, ufid_hash;
>> I am not sure about _hash suffix here, Can you explain it? I think
>> _table is better.
>
> Agreed, table is better.
>
>>> int stats_last_writer;  /* NUMA-node id of the last writer 
>>> on
>>>  * 'stats[0]'.
>>>  */
>>> struct sw_flow_key key;
>>> -   struct sw_flow_key unmasked_key;
>>> +   struct sw_flow_id *ufid;
>> Lets move this structure inside

Hi

2014-12-09 Thread Hong Zhanzhi

I have a lucrative and financial business proposal if interested contact me

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

2014-12-09 Thread Gu Zheng

Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating
cmsghdr from msghdr, just cleanup. 

Signed-off-by: Gu Zheng 
---
v2: use the lower-case macro name as Joe suggested.
---
 .../networking/timestamping/timestamping.c |4 +---
 .../networking/timestamping/txtimestamp.c  |4 +---
 crypto/af_alg.c|2 +-
 include/linux/socket.h |4 
 net/core/scm.c |3 +--
 net/dccp/proto.c   |5 ++---
 net/ipv4/ip_sockglue.c |2 +-
 net/ipv6/datagram.c|2 +-
 net/iucv/af_iucv.c |4 +---
 net/rds/send.c |4 ++--
 net/rxrpc/ar-output.c  |2 +-
 net/sctp/socket.c  |3 +--
 12 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/Documentation/networking/timestamping/timestamping.c 
b/Documentation/networking/timestamping/timestamping.c
index 5cdfd74..635a43a 100644
--- a/Documentation/networking/timestamping/timestamping.c
+++ b/Documentation/networking/timestamping/timestamping.c
@@ -169,9 +169,7 @@ static void printpacket(struct msghdr *msg, int res,
   res,
   inet_ntoa(from_addr->sin_addr),
   msg->msg_controllen);
-   for (cmsg = CMSG_FIRSTHDR(msg);
-cmsg;
-cmsg = CMSG_NXTHDR(msg, cmsg)) {
+   for_each_cmsghdr(cmsg, msg) {
printf("   cmsg len %zu: ", cmsg->cmsg_len);
switch (cmsg->cmsg_level) {
case SOL_SOCKET:
diff --git a/Documentation/networking/timestamping/txtimestamp.c 
b/Documentation/networking/timestamping/txtimestamp.c
index b32fc2a..f4fd9a2 100644
--- a/Documentation/networking/timestamping/txtimestamp.c
+++ b/Documentation/networking/timestamping/txtimestamp.c
@@ -149,9 +149,7 @@ static void __recv_errmsg_cmsg(struct msghdr *msg, int 
payload_len)
struct scm_timestamping *tss = NULL;
struct cmsghdr *cm;
 
-   for (cm = CMSG_FIRSTHDR(msg);
-cm && cm->cmsg_len;
-cm = CMSG_NXTHDR(msg, cm)) {
+   for_each_cmsghdr(cmsg, msg) {
if (cm->cmsg_level == SOL_SOCKET &&
cm->cmsg_type == SCM_TIMESTAMPING) {
tss = (void *) CMSG_DATA(cm);
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 6a3ad80..bc21f52 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -399,7 +399,7 @@ int af_alg_cmsg_send(struct msghdr *msg, struct 
af_alg_control *con)
 {
struct cmsghdr *cmsg;
 
-   for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+   for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
if (cmsg->cmsg_level != SOL_ALG)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index bb9b836..0e71278 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -94,6 +94,10 @@ struct cmsghdr {
 (cmsg)->cmsg_len <= (unsigned long) \
 ((mhdr)->msg_controllen - \
  ((char *)(cmsg) - (char *)(mhdr)->msg_control)))
+#define for_each_cmsghdr(cmsg, msg) \
+   for (cmsg = CMSG_FIRSTHDR(msg); \
+cmsg; \
+cmsg = CMSG_NXTHDR(msg, cmsg))
 
 /*
  * Get the next cmsg header
diff --git a/net/core/scm.c b/net/core/scm.c
index b442e7e..3b6899b 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -129,8 +129,7 @@ int __scm_send(struct socket *sock, struct msghdr *msg, 
struct scm_cookie *p)
struct cmsghdr *cmsg;
int err;
 
-   for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg))
-   {
+   for_each_cmsghdr(cmsg, msg) {
err = -EINVAL;
 
/* Verify that cmsg_len is at least sizeof(struct cmsghdr) */
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
index 5ab6627..e7413a9 100644
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -703,7 +703,7 @@ EXPORT_SYMBOL_GPL(compat_dccp_getsockopt);
 
 static int dccp_msghdr_parse(struct msghdr *msg, struct sk_buff *skb)
 {
-   struct cmsghdr *cmsg = CMSG_FIRSTHDR(msg);
+   struct cmsghdr *cmsg;
 
/*
 * Assign an (opaque) qpolicy priority value to skb->priority.
@@ -717,8 +717,7 @@ static int dccp_msghdr_parse(struct msghdr *msg, struct 
sk_buff *skb)
 */
skb->priority = 0;
 
-   for (; cmsg != NULL; cmsg = CMSG_NXTHDR(msg, cmsg)) {
-
+   for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
 
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 9daf217..839db9d 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -192,7 +192,7 @@ int ip_cmsg_send(struct net *net,

[PATCH] staging: vt6655: remove unused function in mac.c

2014-12-09 Thread Fred Chou

From: Fred Chou 

Removed the unused function MACvGetShortRetryLimit, which also
fixed the following sparse warning:
drivers/staging/vt6655/mac.c:162:6: warning: 
symbol 'MACvGetShortRetryLimit' was not declared. Should it be static?

Signed-off-by: Fred Chou 
---
 drivers/staging/vt6655/mac.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/drivers/staging/vt6655/mac.c b/drivers/staging/vt6655/mac.c
index 8f0d652..09a91d1 100644
--- a/drivers/staging/vt6655/mac.c
+++ b/drivers/staging/vt6655/mac.c
@@ -30,7 +30,6 @@
  *  MACbIsRegBitsOff - Test if All test Bits Off
  *  MACbIsIntDisable - Test if MAC interrupt disable
  *  MACvSetShortRetryLimit - Set 802.11 Short Retry limit
- *  MACvGetShortRetryLimit - Get 802.11 Short Retry limit
  *  MACvSetLongRetryLimit - Set 802.11 Long Retry limit
  *  MACvSetLoopbackMode - Set MAC Loopback Mode
  *  MACvSaveContext - Save Context of MAC Registers
@@ -146,24 +145,6 @@ void MACvSetShortRetryLimit(void __iomem *dwIoBase, 
unsigned char byRetryLimit)
VNSvOutPortB(dwIoBase + MAC_REG_SRT, byRetryLimit);
 }
 
-/*
- * Description:
- *  Get 802.11 Short Retry Limit
- *
- * Parameters:
- *  In:
- *  dwIoBase- Base Address for MAC
- *  Out:
- *  pbyRetryLimit   - Retry Limit Get
- *
- * Return Value: none
- *
- */
-void MACvGetShortRetryLimit(void __iomem *dwIoBase, unsigned char 
*pbyRetryLimit)
-{
-   // get SRT
-   VNSvInPortB(dwIoBase + MAC_REG_SRT, pbyRetryLimit);
-}
 
 /*
  * Description:
-- 
1.9.1

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

[GIT PULL] Mailbox changes for 3.19

2014-12-09 Thread Jassi Brar

Hi Linus,

The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4:

  Linux 3.18-rc3 (2014-11-02 15:01:51 -0800)

are available in the git repository at:

  http://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-devel

for you to fetch changes up to 86c22f8c9a3b71d42d38bfcd80372de72f573713:

  Mailbox: Add support for Platform Communication Channel (2014-11-27
12:51:09 +0530)


Andrew Bresticker (1):
  mailbox: Don't unnecessarily re-arm the polling timer

Ashwin Chaugule (1):
  Mailbox: Add support for Platform Communication Channel

Sudeep Holla (1):
  mailbox: add tx_prepare client callback

Suman Anna (1):
  mailbox/omap: adapt to the new mailbox framework

 .../devicetree/bindings/mailbox/omap-mailbox.txt   |  23 ++
 drivers/mailbox/Kconfig|  12 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/mailbox.c  |  19 +-
 drivers/mailbox/mailbox.h  |  14 +
 drivers/mailbox/omap-mailbox.c | 346 ++
 drivers/mailbox/pcc.c  | 403 +
 drivers/remoteproc/omap_remoteproc.c   |  51 +--
 include/linux/mailbox_client.h |   3 +
 include/linux/omap-mailbox.h   |  16 +-
 10 files changed, 701 insertions(+), 188 deletions(-)
 create mode 100644 drivers/mailbox/mailbox.h
 create mode 100644 drivers/mailbox/pcc.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Query] Spurious interrupts from clockevent device on X86 Ivybridge

2014-12-09 Thread Santosh Shukla

Hi Guys,

I have been chasing spurious clockevent interrupts (In HIGHRES mode) on my x86
IvyBridge server and stuck on some blockers (mostly due to lack of knowledge)
and need some help..

What does spurious mean ?
I take it as the case when a core is unnecessarily interrupted by the clockevent
device while we didn't wanted it to.

I tried to catch them with the help of few new trace points in
hrtimer_interrupt() when it didn't serviced any pending hrtimers..

The causes I could find:
- Clockevent device's counter overflow: When we need to program a clockevt
  device for times larger than it can handle, we program it for max time and
  then reprogram again on expiration. Because of hardware counter limitations we
  have to do it this way and this isn't really a spurious interrupt as we
  programmed it that way.

- Hardware timer firing before its expiration: Yes, its hard to digest but from
  my tests it looks like this does happen. Will circulate another mail once I am
  sure about it.

- Difference between time returned by hrtimer_update_base() and clockevt
  device's notion of time: Wanted to discuss this here..


An example of what I am witnessing in my tests:

clockevt device programmed to fire after 199 ms and it fires exactly after that
time (Verified with ftrace time-diff and tsc diff [tsc: timestamp counter
instructions for x86]).

But when hrtimer_interrupt() tries to find the hrtimer for which the event
occurred, it finds the value returned by hrtimer_update_base() being lesser than
the softexpires of the timer for which the event was programmed. And the diff is
approximately 1 us most of the times I see the spurious interrupt.

-0 [010] d...68.961171: clk_evt_program: delta:199933679
expires=6907100 /* programmed for 199 ms */
-0 [010] d...68.961171: lapic_next_deadline:
cur_tsc:365799488705427 new_tsc:365799907536051 delta:199443 usec /*
sets new_tsc */
-0 [010] d.h.69.161183: local_timer_entry: vector=239
-0 [010] d.h.69.161185: local_apic_timer_interrupt:
cur_tsc:365799907547595 delta:199448 usec /* Interrupt arrived
afterexactly 199 ms */
-0 [010] d.h.69.161187:
hrtimer_interrupt:function=tick_sched_timer expires=6907100
softexpires=6907100
basenow:69070997234 /* But Softexpires > basenow ?? */
-0 [010] d.h.69.161188: clk_evt_program: delta:1000
expires=6907100 /* new expiry value (1 us) */
-0 [010] d.h.69.161189: lapic_next_deadline:
cur_tsc:365799907556179 new_tsc:365799907558259 delta:0 usec /* sets
new tsc value */
-0 [010] d.h.69.161189: local_timer_exit: vector=239

Tested on: Ivybrdge V2, 12 core X86 server, though it occurs on ARM as well
(but not that frequent).

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf mem: perf mem report fails in TUI mode

2014-12-09 Thread David Ahern


On 12/9/14 9:15 PM, Stephane Eranian wrote:

Hi,

I was running a couple of tests with perf mem from tip.git and
found that perf mem -t load rep was failing only in TUI mode.
With --stdio, it works fine. I did a bit of investigation and found
out that the TUI mode is failing because some symbol (kernel)
is showing up with a huge (negative) size. I don't understand
the connection between the TUI vs. tty browser and symbols.

To reproduce:
 $ perf mem -t load rec my_test_program
 $ perf mem -t load rep
 $ perf mem -t load rep --stdio

Debugging with TUI is a pain, so I stopped.

I have a patch to improve perf mem a bit but I'd like to get this problem
fixed first.

Maybe you have a idea of what's going on.


I usually avoid the TUI by not installing slang-devel.

But, trying out Linus' current tip (a0e4467726c - post 3.18) this seems 
to work fine:

perf mem -t load rec ls
perf mem -t load rep

But kernel version for the box is 3.16.6-203.fc20.x86_64.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v13 00/12] input: cyapa: instruction of cyapa patches

2014-12-09 Thread Dudley Du

Jeremiah,

Thank you very much for your review, comments and test.
I will correct the spelling issues in next submit version.

Thanks,
Dudley

> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Jeremiah Mahler
> Sent: 2014?12?10? 12:10
> To: Dudley Du
> Cc: dmitry.torok...@gmail.com; rydb...@euromail.se; ble...@google.com;
> David Solda; linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v13 00/12] input: cyapa: instruction of cyapa patches
>
> Dudley, all,
>
> On Tue, Dec 09, 2014 at 05:11:32PM +0800, Dudley Du wrote:
> > V13 patches have below updates, details of other updates see history list:
> > 1) Remove all debugfs interface, including read_fw and raw_data interfaces.
> > 2) This patches are made based linux next-20141208.
> >
> [...]
>
> I tested this patch set on an Acer C720 and other than the minor
> problems I pointed out in other emails (CONFIG_CYAPA, spelling) it seems
> to work fine and there are no obvious problems.
>
> Reviewed-by: Jeremiah Mahler 
>
> --
> - Jeremiah Mahler
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

This message and any attachments may contain Cypress (or its subsidiaries) 
confidential information. If it has been received in error, please advise the 
sender and immediately delete this message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: VFS and LSM issues

2014-12-09 Thread Greg KH

On Mon, Dec 08, 2014 at 06:04:30PM +0100, Krzysztof Opasiak wrote:
> Dear All,
> 
> I'm Krzysztof Opasiak from SRPOL (Samsung). I'm working on USB support
> in Tizen and mainline. In those works we use two Virtual File Systems
> - ConfigFS and FunctionFS. Recently I have tried to use them with
> SMACK and I ran into a few issues. Most of them looks to be a generic
> problem with many FS and LSM. You can find description of those issues
> and my research just below in 3 points. I'm not a VFS/LSM specialist so
> your help is very welcome;)
> 
> 1) Issues with function FS
> 
> It's a VFS which allow to provide custom USB function as userspace
> program. I know that may be quite new for you so let's define this as
> a VFS which works as follow:
> 
> $ modprobe g_ffs
> $ mkdir /tmp/mount_root
> $ mount none -t functionfs /tmp/mount_root
> $ ls /tmp/mount_root
> ep0
> 
> # now we run our program which writes some data to ep0
> #  and based on this kernel creates epX
> # you can find one in tools/usb/ffs-test.c
> 
> $ ./my_program /tmp/mount_root &
> $ ls /tmp/mount_root
> ep0 ep1 ep2
> 
> Ok so now we would like to use this together with smack. Especially
> with smackfsdef mount option. First two steps go as above and then:
> 
> $ mount none -t functionfs -o smackfsdef=my_label /tmp/mount_root
> $ ls -Z /tmp/mount_root/
>  _ ep0
> 
> Ops! Some bug here we requested to use my_label but we got _. When we
> run our program, rest of epX will get desired label (my_label). I have
> started to dig in kernel to find what happen and probably I found out
> where is a problem. Let's look to mount_fs() code which is executed
> during mount:
> 
> struct dentry *
> mount_fs(struct file_system_type *type, int flags, const char *name,
> void *data)
> {
> (...)
>   root = type->mount(type, flags, name, data);
> (...)
>   error = security_sb_kern_mount(sb, flags, secdata);
> (...)
> }
> 
> So what is important here is the order of operations. First is
> executed mount ops provided by selected file system. During this mount
> procedure functionfs executes new_inode(sb) to allocate inode for ep0
> which should appear directly after mount. After returning from mount
> function we execute security_sb_kern_mount() where we *parse the mount
> options* and sets the value for lsm specific structures for example we
> store the label passed in smackfsdef.
> 
> The problem here is order of calls because first we call mount for
> given fs where we create a file and after this we fill security
> structures with security mount options. While creating file in mount
> callback super block is filled only with default values for security
> so ep0 has _ label. This looks like a generic issue for all VFS which
> creates indoes before or in their mount procedure.
> 
> I'm not sure if we can simply move security_sb_kern_mount() above
> mount for specific fs, do we?

No, I do not think you can, sorry.

> 2) Issues with ConfigFS
> 
> ConfigFS is a generic VFS which allows to create and manage kobjects
> from userspace. Each module which would like to allow for userland
> driven configuration register as ConfigFS client called
> subsystem. Each subsystem has its own directory in ConfigFS root
> dir. We use libcomposite which appear in ConfigFS as usb_gadget
> directory. In this dir you can create directories called gadgets. Some
> example:
> 
> # libcomposite and configfs compiled-in
> $ mount none -t configfs /sys/kernel/config
> $ ls /sys/kernel/config usb_gadget
> $ mkdir /sys/kernel/config/usb_gadget/g1
> $ ls /sys/kernel/config/usb_gadget/g1
> UDC  bDeviceSubClass  bcdUSB idProduct  strings
> bDeviceClass bMaxPacketSize0  configsidVendor
> bDeviceProtocol  bcdDevicefunctions  os_desc
> 
> 
> Now let's try to use smack with ConfigFS. First of all we run to
> similar issue as with FunctionFS so after mounting configfs with
> smackfsdef option we still get _ label on subsystem directories
> because they are created in configfs_register_subsystem() which is
> called in libcomposite module init so really erly. So in my opinion
> this looks quite similar to issue described in functionfs section.

Yes, "virtual" filesystems like these haven't probably ever been tested
with an LSM before, as you are finding out.

> Second issue related to Configfs is when we create the directory.
> Reproduction:
> 
> $ mount none -t configfs -o smackfsdef=my_label /sys/kernel/config
> $ ls -Z /sys/kernel/config
> _ usb_gadget
> $ chmod 777 /sys/kernel/config/usb_gadget
> $ chsmack -a my_label /sys/kernel/config/usb_gadget
> $ echo my_label > /proc/self/attr/current
> $ su my_user
> $ mkdir /sys/kernel/config/usb_gadget/g1
> $ ls -Z /sys/kernel/config/usb_gadget/
> _ g1
> 
> As you see our process had my_label label but created by him gadget
> has the _ label and the same with all files and subdirs created in
> g1. I have no idea why this happened but definetly something is
> wrong. Related to this is a policy of labeling

Re: [PATCH wq/for-3.19 3/3] workqueue: dump workqueues on sysrq-t

2014-12-09 Thread Greg Kroah-Hartman

On Mon, Dec 08, 2014 at 02:22:29PM -0500, Tejun Heo wrote:
> (cc'ing Greg for tty)
> 
> On Mon, Dec 08, 2014 at 11:05:15AM -0800, Andrew Morton wrote:
> > > Believe it or not, we already used up all alphanumerics if we count in
> > > the arch-specific ones.  Given that the workqueue information would
> > > primarily be useful in tracking down hangs and we'd want to see the
> > > dump of tasks in that case anyway, sysrq-t isn't a bad fit for
> > > appending workqueue dump.  If anybody has a better idea, I'm all ears.
> > 
> > Really.  Upper case?
> 
> Greg, would using uppercase chars for sysrq work over the different
> types of ttys?

I'm dragging in linux-serial@vger here also, but I think uppercase
characters will work from a tty standpoint.  I don't know about keyboard
scancodes, if they will do "odd" things wanting a shift with the sysrq
key at the same time.

Oh wait, I think that might be it, shift is needed for the sysrq key on
the keyboard to start with, right?  So there probably isn't a way to
test the difference of a lower/upper case key here.

I'm traveling this week, and don't have access to a "real" keyboard at
the moment, but this should be pretty easy for someone to test who has
one and cares about this type of thing {hint}.

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/

[PATCH] ftracetest: Replace usleep with sleep 0.000001

2014-12-09 Thread Michael Ellerman

usleep is a Fedoraism, it's not generally available on Debian based
systems AFAICS.

GNU sleep accepts a floating point argument, so use that instead.

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/ftrace/test.d/event/event-enable.tc | 6 +++---
 tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
index 668616d9bb03..c5343add3407 100644
--- a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
@@ -21,7 +21,7 @@ reset_tracer
 do_reset
 
 echo 'sched:sched_switch' > set_event
-usleep 1
+sleep 0.01
 
 count=`cat trace | grep sched_switch | wc -l`
 if [ $count -eq 0 ]; then
@@ -31,7 +31,7 @@ fi
 do_reset
 
 echo 1 > events/sched/sched_switch/enable
-usleep 1
+sleep 0.01
 
 count=`cat trace | grep sched_switch | wc -l`
 if [ $count -eq 0 ]; then
@@ -41,7 +41,7 @@ fi
 do_reset
 
 echo 0 > events/sched/sched_switch/enable
-usleep 1
+sleep 0.01
 
 count=`cat trace | grep sched_switch | wc -l`
 if [ $count -ne 0 ]; then
diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
index 655c415b6e7f..84a2020d4e7b 100644
--- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
@@ -21,7 +21,7 @@ reset_tracer
 do_reset
 
 echo 'sched:*' > set_event
-usleep 1
+sleep 0.01
 
 count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
 if [ $count -lt 3 ]; then
@@ -31,7 +31,7 @@ fi
 do_reset
 
 echo 1 > events/sched/enable
-usleep 1
+sleep 0.01
 
 count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
 if [ $count -lt 3 ]; then
@@ -41,7 +41,7 @@ fi
 do_reset
 
 echo 0 > events/sched/enable
-usleep 1
+sleep 0.01
 
 count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
 if [ $count -ne 0 ]; then
-- 
1.9.1

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

[BUG] perf mem: perf mem report fails in TUI mode

2014-12-09 Thread Stephane Eranian

Hi,

I was running a couple of tests with perf mem from tip.git and
found that perf mem -t load rep was failing only in TUI mode.
With --stdio, it works fine. I did a bit of investigation and found
out that the TUI mode is failing because some symbol (kernel)
is showing up with a huge (negative) size. I don't understand
the connection between the TUI vs. tty browser and symbols.

To reproduce:
$ perf mem -t load rec my_test_program
$ perf mem -t load rep
$ perf mem -t load rep --stdio

Debugging with TUI is a pain, so I stopped.

I have a patch to improve perf mem a bit but I'd like to get this problem
fixed first.

Maybe you have a idea of what's going on.

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: [RFC PATCH 0/8] Fix perf probe issues on powerpc

2014-12-09 Thread Ananth N Mavinakayanahalli

On Tue, Dec 09, 2014 at 11:03:58PM +0530, Naveen N. Rao wrote:
> This patchset fixes various issues with perf probe on powerpc
> across ABIv1 and ABIv2:
> - in the presence of DWARF debug-info,
> - in the absence of DWARF, but with the symbol table, and
> - in the absence of debug-info, but with kallsyms.
> 
> Applies cleanly on v3.18 and on -tip with minor changes to patch 6.
> Tested on ppc64 BE and LE.
> 
> - Naveen
> 
> Naveen N. Rao (8):
>   kprobes: Fix kallsyms lookup across powerpc ABIv1 and ABIv2
>   perf probe powerpc: Fix symbol fixup issues due to ELF type
>   perf probe: Improve detection of file/function name in the probe
> pattern
>   perf probe powerpc: Handle powerpc dot symbols
>   perf probe powerpc: Allow matching against dot symbols
>   perf tools powerpc: Fix PPC64 ELF ABIv2 symbol decoding
>   perf probe powerpc: Use DWARF info only if necessary
>   perf probe powerpc: Fixup function entry if using kallsyms lookup
> 
>  arch/powerpc/include/asm/code-patching.h  | 26 
>  arch/powerpc/include/asm/kprobes.h| 58 
> ++-
>  tools/perf/arch/powerpc/Makefile  |  1 +
>  tools/perf/arch/powerpc/util/elf-sym-decode.c | 27 +
>  tools/perf/config/Makefile|  1 +
>  tools/perf/util/elf_sym.h | 13 ++
>  tools/perf/util/probe-event.c | 57 --
>  tools/perf/util/symbol-elf.c  | 11 -
>  tools/perf/util/symbol.c  |  6 +++
>  9 files changed, 170 insertions(+), 30 deletions(-)
>  create mode 100644 tools/perf/arch/powerpc/util/elf-sym-decode.c
>  create mode 100644 tools/perf/util/elf_sym.h

For the full patchset...

Reviewed-by: Ananth N Mavinakayanahalli 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v13 00/12] input: cyapa: instruction of cyapa patches

Dudley, all,

On Tue, Dec 09, 2014 at 05:11:32PM +0800, Dudley Du wrote:
> V13 patches have below updates, details of other updates see history list:
> 1) Remove all debugfs interface, including read_fw and raw_data interfaces.
> 2) This patches are made based linux next-20141208.
> 
[...]

I tested this patch set on an Acer C720 and other than the minor
problems I pointed out in other emails (CONFIG_CYAPA, spelling) it seems
to work fine and there are no obvious problems.

Reviewed-by: Jeremiah Mahler 

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

Re: [RFC PATCH 8/8] perf probe powerpc: Fixup function entry if using kallsyms lookup

2014-12-09 Thread Ananth N Mavinakayanahalli

On Tue, Dec 09, 2014 at 06:14:00PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 09, 2014 at 11:04:06PM +0530, Naveen N. Rao escreveu:
> > On powerpc ABIv2, if no debug-info is found and we use kallsyms,
> > we need to fixup the function entry to point to the local entry point.
> > Use offset of 8 since current toolchains always generate 2
> > instructions (8 bytes).
> 
> Hi Michael and Ananth, may I have your Acked-by or Reviewed-by for these
> patches?
> 
> The ones, like this, that are affects only ppc I'm can assume was tested
> and applying it won't break other arch users, but having a/rev-by from
> ppc developers should speed up this process.

Hi Arnaldo,

Yes, I have reviewed the patches. So, for all patches...

Reviewed-by: Ananth N Mavinakayanahalli 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c

2014-12-09 Thread Yinghai Lu

On Mon, Nov 3, 2014 at 2:57 AM, tip-bot for Jiang Liu  wrote:
> Commit-ID:  e22ce93870deae0e9a54e1539f0088538f187780
> Gitweb: http://git.kernel.org/tip/e22ce93870deae0e9a54e1539f0088538f187780
> Author: Jiang Liu 
> AuthorDate: Mon, 27 Oct 2014 13:21:34 +0800
> Committer:  Thomas Gleixner 
> CommitDate: Mon, 3 Nov 2014 11:56:07 +0100
>
> x86, PCI, ACPI: Kill private function resource_to_addr() in 
> arch/x86/pci/acpi.c
>
> Private function resource_to_addr() is used to parse ACPI resources
> for PCI host bridge. There are public interfaces available for that
> purpose, so replace resource_to_addr() with public interfaces.
>
> Signed-off-by: Jiang Liu 
> Reviewed-by: Bjorn Helgaas 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tony Luck 
> Cc: Joerg Roedel 
> Cc: Greg Kroah-Hartman 
> Cc: Benjamin Herrenschmidt 
> Cc: Rafael J. Wysocki 
> Cc: Randy Dunlap 
> Cc: Yinghai Lu 
> Cc: Borislav Petkov 
> Link: 
> http://lkml.kernel.org/r/1414387308-27148-5-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/pci/acpi.c | 144 
> +++-
>  1 file changed, 53 insertions(+), 91 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index cfd1b13..3f72d93 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -218,114 +218,76 @@ static void teardown_mcfg_map(struct pci_root_info 
> *info)
>  }
>  #endif
>
> -static acpi_status resource_to_addr(struct acpi_resource *resource,
> -   struct acpi_resource_address64 *addr)
> -{
> -   acpi_status status;
> -   struct acpi_resource_memory24 *memory24;
> -   struct acpi_resource_memory32 *memory32;
> -   struct acpi_resource_fixed_memory32 *fixed_memory32;
> -
> -   memset(addr, 0, sizeof(*addr));
> -   switch (resource->type) {
> -   case ACPI_RESOURCE_TYPE_MEMORY24:
> -   memory24 = >data.memory24;
> -   addr->resource_type = ACPI_MEMORY_RANGE;
> -   addr->minimum = memory24->minimum;
> -   addr->address_length = memory24->address_length;
> -   addr->maximum = addr->minimum + addr->address_length - 1;
> -   return AE_OK;
> -   case ACPI_RESOURCE_TYPE_MEMORY32:
> -   memory32 = >data.memory32;
> -   addr->resource_type = ACPI_MEMORY_RANGE;
> -   addr->minimum = memory32->minimum;
> -   addr->address_length = memory32->address_length;
> -   addr->maximum = addr->minimum + addr->address_length - 1;
> -   return AE_OK;
> -   case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
> -   fixed_memory32 = >data.fixed_memory32;
> -   addr->resource_type = ACPI_MEMORY_RANGE;
> -   addr->minimum = fixed_memory32->address;
> -   addr->address_length = fixed_memory32->address_length;
> -   addr->maximum = addr->minimum + addr->address_length - 1;
> -   return AE_OK;
> -   case ACPI_RESOURCE_TYPE_ADDRESS16:
> -   case ACPI_RESOURCE_TYPE_ADDRESS32:
> -   case ACPI_RESOURCE_TYPE_ADDRESS64:
> -   status = acpi_resource_to_address64(resource, addr);
> -   if (ACPI_SUCCESS(status) &&
> -   (addr->resource_type == ACPI_MEMORY_RANGE ||
> -   addr->resource_type == ACPI_IO_RANGE) &&
> -   addr->address_length > 0) {
> -   return AE_OK;
> -   }
> -   break;
> -   }
> -   return AE_ERROR;
> -}
> -
>  static acpi_status count_resource(struct acpi_resource *acpi_res, void *data)
>  {
> struct pci_root_info *info = data;
> -   struct acpi_resource_address64 addr;
> -   acpi_status status;
> +   struct resource r = {
> +   .flags = 0
> +   };
>
> -   status = resource_to_addr(acpi_res, );
> -   if (ACPI_SUCCESS(status))
> +   if (!acpi_dev_resource_memory(acpi_res, ) &&
> +   !acpi_dev_resource_address_space(acpi_res, ))
> +   return AE_OK;
> +
> +   if ((r.flags & (IORESOURCE_IO | IORESOURCE_MEM)) && resource_size())
> info->res_num++;
> +
> return AE_OK;
>  }
>
>  static acpi_status setup_resource(struct acpi_resource *acpi_res, void *data)
>  {
> struct pci_root_info *info = data;
> -   struct resource *res;
> -   struct acpi_resource_address64 addr;
> -   acpi_status status;
> -   unsigned long flags;
> -   u64 start, orig_end, end;
> +   u64 translation_offset = 0;
> +   struct resource r = {
> +   .flags = 0
> +   };
> +
> +   if (acpi_dev_resource_memory(acpi_res, )) {
> +   r.flags &= IORESOURCE_MEM | IORESOURCE_IO;
> +   } else if (acpi_dev_resource_address_space(acpi_res, )) {
> +   u64 orig_end;
> +   struct acpi_resource_address64 addr;
> +
> +   r.flags &= IORESOURCE_MEM |

Re: [PATCH v13 11/12] input: cyapa: add gen5 trackpad device force re-calibrate function support

Dudley,

On Tue, Dec 09, 2014 at 05:11:43PM +0800, Dudley Du wrote:
> Add force re-calibrate function supported for gen5 trackpad device,
> it can be used through sysfs calibrate interface.
> TEST=test on Chromebooks.
> 
> Signed-off-by: Dudley Du 
> ---
>  drivers/input/mouse/cyapa_gen5.c | 65 
> 
>  1 file changed, 65 insertions(+)
> 
> diff --git a/drivers/input/mouse/cyapa_gen5.c 
> b/drivers/input/mouse/cyapa_gen5.c
> index 5bebee1..7d96904 100644
> --- a/drivers/input/mouse/cyapa_gen5.c
> +++ b/drivers/input/mouse/cyapa_gen5.c
> @@ -1581,6 +1581,70 @@ static int cyapa_gen5_suspend_scanning(struct cyapa 
> *cyapa)
>   return 0;
>  }
>  
> +static int cyapa_gen5_calibrate_pwcs(struct cyapa *cyapa,
> + u8 calibrate_sensing_mode_type)
> +{
> + u8 cmd[8];
> + u8 resp_data[6];
> + int resp_len;
> + int error;
> +
> + /* Try to dump all bufferred data before doing command. */
   ^
   buffered

[...]

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

Re: [PATCH v13 10/12] input: cyapa: add gen5 trackpad device read baseline function support

Dudley,

On Tue, Dec 09, 2014 at 05:11:42PM +0800, Dudley Du wrote:
> Add read baseline function supported for gen5 trackpad device,
> it can be used through sysfs baseline interface.
> TEST=test on Chromebooks.
> 
> Signed-off-by: Dudley Du 
> ---
[...]
>   return 0;
>  }
>  
> +static int cyapa_gen5_resume_scanning(struct cyapa *cyapa)
> +{
> + u8 cmd[7] = { 0x04, 0x00, 0x05, 0x00, 0x2f, 0x00, 0x04 };
> + u8 resp_data[6];
> + int resp_len;
> + int error;
> +
> + /* Try to dump all bufferred data before doing command. */
   ^
   buffered

And there are three more below.

> + cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
> +
> + resp_len = 6;
> + error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
> + cmd, 7,
> + resp_data, _len,
> + 500, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
> + if (error || !VALID_CMD_RESP_HEADER(resp_data, 0x04))
> + return -EINVAL;
> +
> + /* Try to dump all bufferred data when resuming scanning. */
> + cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
> +
> + return 0;
> +}
> +
> +static int cyapa_gen5_suspend_scanning(struct cyapa *cyapa)
> +{
> + u8 cmd[7] = { 0x04, 0x00, 0x05, 0x00, 0x2f, 0x00, 0x03 };
> + u8 resp_data[6];
> + int resp_len;
> + int error;
> +
> + /* Try to dump all bufferred data before doing command. */
> + cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
> +
> + resp_len = 6;
> + error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
> + cmd, 7,
> + resp_data, _len,
> + 500, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
> + if (error || !VALID_CMD_RESP_HEADER(resp_data, 0x03))
> + return -EINVAL;
> +
> + /* Try to dump all bufferred data when suspending scanning. */
> + cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
> +
> + return 0;
> +}
> +
[...]

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

Re: [PATCH v2 3/4] ARM: mach-bcm: Enable I2C support for iProc




On 12/9/2014 7:20 PM, Florian Fainelli wrote:

On 09/12/14 18:24, Ray Jui wrote:



On 12/9/2014 6:20 PM, Florian Fainelli wrote:

On 09/12/14 18:18, Ray Jui wrote:

Enable I2C driver support for Broadcom iProc family of SoCs by
selecting I2C_BCM_IPROC

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
   arch/arm/mach-bcm/Kconfig |1 +
   1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index aaeec78..86ee90b 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -19,6 +19,7 @@ config ARCH_BCM_IPROC
   select ARCH_REQUIRE_GPIOLIB
   select ARM_AMBA
   select PINCTRL
+select I2C_BCM_IPROC


One way to avoid having to modify mach-bcm/Kconfig would be to have your
i2c driver Kconfig do this:

default ARCH_BCM_IPROC

would that work?


Yes. So in which case it is better to select a driver from the
architecture specific Kconfig?


I suppose if your driver/subsystem is critical for system boot, like
powering a regulator or something that has a critical purpose, a select
is probably more appropriate here. If this is just exposing non-critical
devices, I would go with a depends on/default at the driver Kconfig level.

This is just how I see things, others would definitively have a
different view.

Okay. Thanks. I default the driver to y in patchset v3 just like some 
other I2C drivers in the same Kconfig. It already depends on 
ARCH_BCM_IPROC so it makes sense to set the default to y, i.e., it will 
be enabled by default for ARCH_BCM_IPROC platforms.





   help
 This enables support for systems based on Broadcom IPROC
architected SoCs.
 The IPROC complex contains one or more ARM CPUs along with
common






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] ARM: dts: add I2C device nodes for Broadcom Cygnus

Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
them disabled there. Individual I2C devices can be enabled in board
specific dts file when I2C slave devices are enabled in the future

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi |   20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5126f9e..f7d6c1d 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -70,6 +70,26 @@
};
};
 
+   i2c0: i2c@18008000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@1800b000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x1800b000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
uart0: serial@1802 {
compatible = "snps,dw-apb-uart";
reg = <0x1802 0x100>;
-- 
1.7.9.5

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

[PATCH v3 0/3] Add I2C support to Broadcom iProc

This patchset contains the initial I2C support for Broadcom iProc family of
SoCs.

The iProc I2C controller has separate internal TX and RX FIFOs, each has a
size of 64 bytes. The iProc I2C controller supports two bus speeds including
standard mode (100 kHz) and fast mode (400 kHz)

Changes from v2:
 - Have the I2C driver default to y so it does not need to be selected from
   ARCH_BCM_IPROC. This also helps to get rid of one patch. The driver still
   depends on ARCH_BCM_IPROC
 - Get rid of redundant check on resource returned by platform_get_resource

Changes from v1:
 - Fix function argument parenthesis
 - Get rid of redundant driver owner field

Ray Jui (3):
  i2c: iProc: define Broadcom iProc I2C binding
  i2c: iproc: Add Broadcom iProc I2C Driver
  ARM: dts: add I2C device nodes for Broadcom Cygnus

 .../devicetree/bindings/i2c/brcm,iproc-i2c.txt |   37 ++
 arch/arm/boot/dts/bcm-cygnus.dtsi  |   20 +
 drivers/i2c/busses/Kconfig |   10 +
 drivers/i2c/busses/Makefile|1 +
 drivers/i2c/busses/i2c-bcm-iproc.c |  500 
 5 files changed, 568 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
 create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c

-- 
1.7.9.5

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

[PATCH v3 1/3] i2c: iProc: define Broadcom iProc I2C binding

Document the I2C device tree binding for Broadcom iProc family of
SoCs

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../devicetree/bindings/i2c/brcm,iproc-i2c.txt |   37 
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt

diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt 
b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
new file mode 100644
index 000..81f982c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
@@ -0,0 +1,37 @@
+Broadcom iProc I2C controller
+
+Required properties:
+
+- compatible:
+Must be "brcm,iproc-i2c"
+
+- reg:
+Define the base and range of the I/O address space that contain the iProc
+I2C controller registers
+
+- interrupts:
+Should contain the I2C interrupt
+
+- clock-frequency:
+This is the I2C bus clock. Need to be either 10 or 40
+
+- #address-cells:
+Always 1 (for I2C addresses)
+
+- #size-cells:
+Always 0
+
+Example:
+   i2c0: i2c@18008000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+
+   codec: wm8750@1a {
+   compatible = "wlf,wm8750";
+   reg = <0x1a>;
+   };
+   };
-- 
1.7.9.5

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

[PATCH v3 2/3] i2c: iproc: Add Broadcom iProc I2C Driver

Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.

The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/i2c/busses/Kconfig |   10 +
 drivers/i2c/busses/Makefile|1 +
 drivers/i2c/busses/i2c-bcm-iproc.c |  500 
 3 files changed, 511 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c1351d9..df21366 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -372,6 +372,16 @@ config I2C_BCM2835
  This support is also available as a module.  If so, the module
  will be called i2c-bcm2835.
 
+config I2C_BCM_IPROC
+   tristate "Broadcom iProc I2C controller"
+   depends on ARCH_BCM_IPROC
+   default y
+   help
+ If you say yes to this option, support will be included for the
+ Broadcom iProc I2C controller.
+
+ If you don't know what to do here, say N.
+
 config I2C_BCM_KONA
tristate "BCM Kona I2C adapter"
depends on ARCH_BCM_MOBILE
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 5e6c822..216e7be 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_AT91)+= i2c-at91.o
 obj-$(CONFIG_I2C_AU1550)   += i2c-au1550.o
 obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
 obj-$(CONFIG_I2C_BCM2835)  += i2c-bcm2835.o
+obj-$(CONFIG_I2C_BCM_IPROC)+= i2c-bcm-iproc.o
 obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
 obj-$(CONFIG_I2C_CADENCE)  += i2c-cadence.o
 obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c 
b/drivers/i2c/busses/i2c-bcm-iproc.c
new file mode 100644
index 000..35ac497
--- /dev/null
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -0,0 +1,500 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CFG_OFFSET   0x00
+#define CFG_RESET_SHIFT  31
+#define CFG_EN_SHIFT 30
+#define CFG_M_RETRY_CNT_SHIFT16
+#define CFG_M_RETRY_CNT_MASK 0x0f
+
+#define TIM_CFG_OFFSET   0x04
+#define TIME_CFG_MODE_400_SHIFT  31
+
+#define M_FIFO_CTRL_OFFSET   0x0c
+#define M_FIFO_RX_FLUSH_SHIFT31
+#define M_FIFO_TX_FLUSH_SHIFT30
+#define M_FIFO_RX_CNT_SHIFT  16
+#define M_FIFO_RX_CNT_MASK   0x7f
+#define M_FIFO_RX_THLD_SHIFT 8
+#define M_FIFO_RX_THLD_MASK  0x3f
+
+#define M_CMD_OFFSET 0x30
+#define M_CMD_START_BUSY_SHIFT   31
+#define M_CMD_STATUS_SHIFT   25
+#define M_CMD_STATUS_MASK0x07
+#define M_CMD_STATUS_SUCCESS 0x0
+#define M_CMD_STATUS_LOST_ARB0x1
+#define M_CMD_STATUS_NACK_ADDR   0x2
+#define M_CMD_STATUS_NACK_DATA   0x3
+#define M_CMD_STATUS_TIMEOUT 0x4
+#define M_CMD_PROTOCOL_SHIFT 9
+#define M_CMD_PROTOCOL_MASK  0xf
+#define M_CMD_PROTOCOL_BLK_WR0x7
+#define M_CMD_PROTOCOL_BLK_RD0x8
+#define M_CMD_PEC_SHIFT  8
+#define M_CMD_RD_CNT_SHIFT   0
+#define M_CMD_RD_CNT_MASK0xff
+
+#define IE_OFFSET0x38
+#define IE_M_RX_FIFO_FULL_SHIFT  31
+#define IE_M_RX_THLD_SHIFT   30
+#define IE_M_START_BUSY_SHIFT28
+
+#define IS_OFFSET0x3c
+#define IS_M_RX_FIFO_FULL_SHIFT  31
+#define IS_M_RX_THLD_SHIFT   30
+#define IS_M_START_BUSY_SHIFT28
+
+#define M_TX_OFFSET  0x40
+#define M_TX_WR_STATUS_SHIFT 31
+#define M_TX_DATA_SHIFT  0
+#define M_TX_DATA_MASK   0xff
+
+#define M_RX_OFFSET  0x44
+#define M_RX_STATUS_SHIFT30
+#define M_RX_STATUS_MASK 0x03
+#define M_RX_PEC_ERR_SHIFT   29
+#define M_RX_DATA_SHIFT  0
+#define M_RX_DATA_MASK   0xff
+
+#define I2C_TIMEOUT_MESC 100
+#define M_TX_RX_FIFO_SIZE64
+
+enum bus_speed_index {
+   I2C_SPD_100K = 0,
+   I2C_SPD_400K,
+};
+
+struct bcm_iproc_i2c_dev {
+   struct device

Re: [PATCH v13 09/12] input: cyapa: add gen5 trackpad device firmware update function support

Dudley,

On Tue, Dec 09, 2014 at 05:11:41PM +0800, Dudley Du wrote:
> Add firmware image update function supported for gen5 trackpad device,
> it can be used through sysfs update_fw interface.
> TEST=test on Chromebooks.
> 
> Signed-off-by: Dudley Du 
> ---
>  drivers/input/mouse/Kconfig  |   2 +-
>  drivers/input/mouse/cyapa_gen5.c | 290 
> +++
>  2 files changed, 291 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
> index d8b46b0..63e8b40 100644
> --- a/drivers/input/mouse/Kconfig
> +++ b/drivers/input/mouse/Kconfig
> @@ -205,7 +205,7 @@ config MOUSE_BCM5974
>  
>  config MOUSE_CYAPA
>   tristate "Cypress APA I2C Trackpad support"
> - depends on I2C
> + depends on I2C && CRC_ITU_T
>   help
> This driver adds support for Cypress All Points Addressable (APA)
> I2C Trackpads, including the ones used in 2012 Samsung Chromebooks.
> diff --git a/drivers/input/mouse/cyapa_gen5.c 
> b/drivers/input/mouse/cyapa_gen5.c

My initial config had MOUSE_CYAPA=m and CRC_ITU_T=n.
I did a 'make oldconfig', no questions were asked, but it removed
MOUSE_CYAPA since CRC_ITU_T wasn't enabled.  Since the cyapa modules
were removed the touchpad no longer works.  Not a very good upgrade path :-(
To fix this I have to manually enable MOUSE_CYAPA and CRC_ITU_T to get
it working again.

[...]

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

Re: [PATCH 2/4] i2c: iproc: Add Broadcom iProc I2C Driver




On 12/9/2014 7:28 PM, Varka Bhadram wrote:



On Wed, Dec 10, 2014 at 8:51 AM, Varka Bhadram mailto:varkabhad...@gmail.com>> wrote:

On Wed, Dec 10, 2014 at 7:11 AM, Ray Jui mailto:r...@broadcom.com>> wrote:



On 12/9/2014 5:33 PM, Varka Bhadram wrote:


On Wednesday 10 December 2014 06:24 AM, Ray Jui wrote:

Add initial support to the Broadcom iProc I2C controller
found in the
iProc family of SoCs.

The iProc I2C controller has separate internal TX and RX
FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports
two bus speeds
including standard mode (100kHz) and fast mode (400kHz)

Signed-off-by: Ray Jui mailto:r...@broadcom.com>>
Reviewed-by: Scott Branden mailto:sbran...@broadcom.com>>
---
   drivers/i2c/busses/Kconfig |9 +
   drivers/i2c/busses/Makefile|1 +
   drivers/i2c/busses/i2c-bcm-iproc.c |  503

   3 files changed, 513 insertions(+)
   create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c

(...)

+static int bcm_iproc_i2c_probe(struct platform_device
*pdev)
+{
+int irq, ret = 0;
+struct bcm_iproc_i2c_dev *dev;
+struct i2c_adapter *adap;
+struct resource *res;
+
+dev = devm_kzalloc(>dev, sizeof(*dev),
GFP_KERNEL);
+if (!dev)
+return -ENOMEM;
+
+platform_set_drvdata(pdev, dev);
+dev->device = >dev;
+init_completion(>done);
+
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+if (!res)
+return -ENODEV;


We can remove this resource check. This checking will happen
with
devm_ioremap_resource()

Don't you need to obtain a valid resource and pass it into
devm_ioremap_resource? Without 'res' being assigned a valid
resource, devm_ioremap_resource will reject with "invalid resource".

platform_get_resource() will return a resource, checking on this
resource is happening at
http://lxr.free-electrons.com/source/lib/devres.c#L115. So no need
to check it explicitly.

If you check here it will be duplication of check with resource. Two
times we are checking on
the resource. No point of doing like that.

Thanks.
Sorry I misunderstood what you meant. Okay I'll get rid of if (!res) 
check there. Thanks.





See this: http://lxr.free-electrons.com/source/lib/devres.c#L102

--
Thanks and Regards,
Varka Bhadram.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clockevents: introduce ->set_dev_mode() which can return error

2014-12-09 Thread Preeti U Murthy

On 12/10/2014 03:33 AM, Kevin Hilman wrote:
> From: Viresh Kumar 
> 
> Currently, the ->set_mode() method of a clockevent device is not
> allowed to fail, so it has no return value.  In order to add new
> clockevent modes, and allow the setting of those modes to fail, we
> need the clockevent core to be able to detect when setting a mode
> fails.
> 
> To allow detection of mode setting failures, introduce a new method
> ->set_dev_mode() which can return an error if the given mode is not
> supported or fails.
> 
> Since all current modes are still not allowed to fail, the core code
> simply WARNs if any modes fail.  Future patches that add new mode
> support will add proper error recovery based on failure conditions.
> 
> Signed-off-by: Viresh Kumar 
> Reviewed-by: Kevin Hilman 
> [khilman: rework changelogs, minor formatting/checkpatch cleanups]
> Signed-off-by: Kevin Hilman 
> ---
>  include/linux/clockchips.h |  5 -
>  kernel/time/clockevents.c  | 21 ++---
>  kernel/time/timer_list.c   |  5 -
>  3 files changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
> index 2e4cb67f6e56..d969659cf688 100644
> --- a/include/linux/clockchips.h
> +++ b/include/linux/clockchips.h
> @@ -81,7 +81,8 @@ enum clock_event_mode {
>   * @mode:operating mode assigned by the management code
>   * @features:features
>   * @retries: number of forced programming retries
> - * @set_mode:set mode function
> + * @set_dev_mode:set dev mode function
> + * @set_mode:set mode function (deprecated, use set_dev_mode 
> instead)
>   * @broadcast:   function to broadcast events
>   * @min_delta_ticks: minimum delta value in ticks stored for reconfiguration
>   * @max_delta_ticks: maximum delta value in ticks stored for reconfiguration
> @@ -109,6 +110,8 @@ struct clock_event_device {
>   unsigned long   retries;
> 
>   void(*broadcast)(const struct cpumask *mask);
> + int (*set_dev_mode)(enum clock_event_mode mode,
> + struct clock_event_device *);
>   void(*set_mode)(enum clock_event_mode mode,
>   struct clock_event_device *);
>   void(*suspend)(struct clock_event_device *);
> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> index 55449909f114..f7614041240e 100644
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -105,7 +105,16 @@ void clockevents_set_mode(struct clock_event_device *dev,
>enum clock_event_mode mode)
>  {
>   if (dev->mode != mode) {
> - dev->set_mode(mode, dev);
> + if (dev->set_dev_mode) {
> + int ret = dev->set_dev_mode(mode, dev);
> +
> + /* Currently available modes shouldn't fail */
> + WARN_ONCE(ret, "Requested mode: %d, error: %d\n",
> +   mode, ret);
> + } else {
> + dev->set_mode(mode, dev);
> + }
> +
>   dev->mode = mode;
> 
>   /*
> @@ -448,8 +457,14 @@ int __clockevents_update_freq(struct clock_event_device 
> *dev, u32 freq)
>   if (dev->mode == CLOCK_EVT_MODE_ONESHOT)
>   return clockevents_program_event(dev, dev->next_event, false);
> 
> - if (dev->mode == CLOCK_EVT_MODE_PERIODIC)
> - dev->set_mode(CLOCK_EVT_MODE_PERIODIC, dev);
> + if (dev->mode == CLOCK_EVT_MODE_PERIODIC) {
> + /* Shouldn't fail while switching to PERIODIC MODE */
> + if (dev->set_dev_mode)
> + WARN_ON_ONCE(dev->set_dev_mode(CLOCK_EVT_MODE_PERIODIC,
> +dev));
> + else
> + dev->set_mode(CLOCK_EVT_MODE_PERIODIC, dev);
> + }
> 
>   return 0;
>  }
> diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
> index 61ed862cdd37..957a04951ef0 100644
> --- a/kernel/time/timer_list.c
> +++ b/kernel/time/timer_list.c
> @@ -229,7 +229,10 @@ print_tickdevice(struct seq_file *m, struct tick_device 
> *td, int cpu)
>   SEQ_printf(m, "\n");
> 
>   SEQ_printf(m, " set_mode:   ");
> - print_name_offset(m, dev->set_mode);
> + if (dev->set_dev_mode)
> + print_name_offset(m, dev->set_dev_mode);
> + else
> + print_name_offset(m, dev->set_mode);
>   SEQ_printf(m, "\n");
> 
>   SEQ_printf(m, " event_handler:  ");
> 
Reviewed-by: Preeti U Murthy 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] i2c: iProc: define Broadcom iProc I2C binding




On 12/9/2014 7:12 PM, Varka Bhadram wrote:



On Wed, Dec 10, 2014 at 7:05 AM, Ray Jui mailto:r...@broadcom.com>> wrote:



On 12/9/2014 5:27 PM, Varka Bhadram wrote:

Hi,

On Wednesday 10 December 2014 06:24 AM, Ray Jui wrote:

Document the I2C device tree binding for Broadcom iProc
family of
SoCs

Signed-off-by: Ray Jui mailto:r...@broadcom.com>>
Reviewed-by: Scott Branden mailto:sbran...@broadcom.com>>
---
   .../devicetree/bindings/i2c/__brcm,iproc-i2c.txt |   37

   1 file changed, 37 insertions(+)
   create mode 100644
Documentation/devicetree/__bindings/i2c/brcm,iproc-i2c.__txt

diff --git
a/Documentation/devicetree/__bindings/i2c/brcm,iproc-i2c.__txt
b/Documentation/devicetree/__bindings/i2c/brcm,iproc-i2c.__txt
new file mode 100644
index 000..81f982c
--- /dev/null
+++
b/Documentation/devicetree/__bindings/i2c/brcm,iproc-i2c.__txt
@@ -0,0 +1,37 @@
+Broadcom iProc I2C controller
+
+Required properties:
+
+- compatible:
+Must be "brcm,iproc-i2c"
+
+- reg:
+Define the base and range of the I/O address space that
contain
the iProc
+I2C controller registers
+
+- interrupts:
+Should contain the I2C interrupt
+
+- clock-frequency:
+This is the I2C bus clock. Need to be either 10 or
40
+
+- #address-cells:
+Always 1 (for I2C addresses)
+
+- #size-cells:
+Always 0
+


All the properties defined with two lines of statements.

Why cant they be with single line statement, like:

compatible:Must be "brcm,iproc-i2c"
reg:Define the base and range of the I/O address space that
  contain the iProc I2C controller registers




I thought making them two lines are more readable (and obviously
that's very subjective, :)). But more importantly, it matches the
format of other Broadcom iProc/Cygnus devicetree binding documents
that are currently in progress of upstreaming.


But max of the bindings over the kernel follows single line statements.

--
Thanks and Regards,
Varka Bhadram.
Is it a requirement for these property descriptions to be one line? If 
not, I prefer to stick with the way it is now. Thanks.

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

Re: [PATCH v2 3/4] ARM: mach-bcm: Enable I2C support for iProc

2014-12-09 Thread Florian Fainelli

On 09/12/14 18:24, Ray Jui wrote:
> 
> 
> On 12/9/2014 6:20 PM, Florian Fainelli wrote:
>> On 09/12/14 18:18, Ray Jui wrote:
>>> Enable I2C driver support for Broadcom iProc family of SoCs by
>>> selecting I2C_BCM_IPROC
>>>
>>> Signed-off-by: Ray Jui 
>>> Reviewed-by: Scott Branden 
>>> ---
>>>   arch/arm/mach-bcm/Kconfig |1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>>> index aaeec78..86ee90b 100644
>>> --- a/arch/arm/mach-bcm/Kconfig
>>> +++ b/arch/arm/mach-bcm/Kconfig
>>> @@ -19,6 +19,7 @@ config ARCH_BCM_IPROC
>>>   select ARCH_REQUIRE_GPIOLIB
>>>   select ARM_AMBA
>>>   select PINCTRL
>>> +select I2C_BCM_IPROC
>>
>> One way to avoid having to modify mach-bcm/Kconfig would be to have your
>> i2c driver Kconfig do this:
>>
>> default ARCH_BCM_IPROC
>>
>> would that work?
>>
> Yes. So in which case it is better to select a driver from the
> architecture specific Kconfig?

I suppose if your driver/subsystem is critical for system boot, like
powering a regulator or something that has a critical purpose, a select
is probably more appropriate here. If this is just exposing non-critical
devices, I would go with a depends on/default at the driver Kconfig level.

This is just how I see things, others would definitively have a
different view.

> 
>>>   help
>>> This enables support for systems based on Broadcom IPROC
>>> architected SoCs.
>>> The IPROC complex contains one or more ARM CPUs along with
>>> common
>>>
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CPU hotplug: active_writer not woken up in some cases - deadlock

2014-12-09 Thread Paul E. McKenney

On Wed, Dec 10, 2014 at 01:26:19AM +0100, Oleg Nesterov wrote:
> On 12/09, Paul E. McKenney wrote:
> >
> > Would wait_event()/wake_up() work for the wakeup-writer case?
> 
> Yes, and in this case we could probably kill this puts_pending logic
> and avoid cpu_hotplug.lock in put_online_cpus() altogether? Can't we
> just make cpu_hotplug.refcount atomic_t?

Seems like that should be possible.  That would certainly simplify the
wakeup logic from put_online_cpus().  It might even be possible to
avoid acquiring cpu_hotplug.lock in put_online_cpus(), though that
would of course require more luck than anyone deserves.

> Anyway, this makes me think again that this code should use percpu_rwsem.
> Perhaps I'll try to make a patch next week...
> 
> (we need down_write_recursive_readers(), and probably rcusync patches).

Careful!  You might end up re-introducing the deadlock that I used
puts_pending to get rid of.  ;-)

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hexagon: Fix build failures in linux-next

2014-12-09 Thread Guenter Roeck


On 12/09/2014 04:25 PM, rkuo wrote:

On Tue, Dec 09, 2014 at 02:21:45PM -0800, Guenter Roeck wrote:

hexagon:defconfig fails to build in linux-next since commit 332fd7c4fef5
("genirq: Generic chip: Change irq_reg_{readl,writel} arguments").

The primary build failure is

arch/hexagon/include/asm/cacheflush.h: In function 'copy_to_user_page':
arch/hexagon/include/asm/cacheflush.h:89:22: error: 'VM_EXEC' undeclared

This is the result of including of  from ,
which is now necessary due to the use of readl and writel from irq.h.
This causes recursive inclusions in hexagon code; cacheflush.h is included
from mm.h prior to the definition of VM_EXEC.

Fix the problem by moving copy_to_user_page from the hexagon include file to
arch/hexagon/mm/cache.c, similar to other architectures. After this change,
several redefinitions of readl and writel are reported. Those are caused
by recursive inclusions of io.h and asm/cacheflush.h. Fix those problems by
reducing the number of files included from those files. Also, it was necessary
to stop including asm-generic/cacheflush.h from asm/cacheflush.h. Instead,
functionality originally provided by asm-generic/cacheflush.h is now coded
in asm/cacheflush.h directly.

Cc: Kevin Cernekee 
Cc: Jason Cooper 
Signed-off-by: Guenter Roeck 
---
Compile tested only. Applies to linux-next as well as mainline.

  arch/hexagon/include/asm/cacheflush.h | 36 ++-
  arch/hexagon/include/asm/io.h |  5 -
  arch/hexagon/kernel/setup.c   |  1 +
  arch/hexagon/mm/cache.c   | 10 ++
  arch/hexagon/mm/ioremap.c |  1 +
  5 files changed, 31 insertions(+), 22 deletions(-)



Thanks for the cleanup; tested working on hardware.

I'm fine taking this into my tree, or it can go via another tree if more
expedient.


Hi Richard,

Your tree should be fine as long as you plan to push your changes to Linus
during the current release cycle.

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: [PATCH] x86: mce: Avoid timer double-add during CMCI interrupt storms.

2014-12-09 Thread Calvin Owens

On Tuesday 12/09 at 23:00 +, Luck, Tony wrote:
> > Right, so this polling thing once again proves its fragility to me - we
> > have had problems with it in the past so maybe we should think about
> > replacing it with something simpler and and much more robust instead of
> > this flaky dynamically adjustable polling thing.
> 
> Dynamic intervals for polling make sense for cpus that don't support
> CMCI.  We need to check occasionally to see if there are any corrected errors,
> but we don't want to waste a lot of cpu time doing that too often. There are
> almost never any errors to be found. So begin polling at 5 minute intervals
> (eternity on a multi-GHz cpu). If we do find an error, then look more 
> frequently,
> because there are several cases where a single error source might generate
> multiple errors (e.g. stuck bit).
> 
> But then we came along an co-opted this mechanism  for CMCI storm
> control.  And you are right that we made things needlessly complex
> by using the same variable rate mechanism.  If we had a storm, we know
> we are having a high rate of errors (15 in one second) ... so we just want
> to poll at a high-ish rate to collect a good sample of subsequent errors.
> Also to detect when the storm ends in a timely manner. So we don't
> gain much by tweaking the poll rate, and we have complex code.
> 
> > So I'm thinking of leaving the detection code as it is, when we detect
> > a storm on a CPU, we set CMCI_STORM_ACTIVE and start a kernel thread at
> > max freq HZ/100 and polling the MCA banks. No adjustable frequency, no
> > timers, no nothing. A stupid per-cpu thread which polls.
> 
> Go for it.

Just to make sure I understand what you're looking for:

When MCE is initialized, spawn a kthread for each CPU instead of the
current timers. If CMCI is supported, we just leave this thread parked,
and only process errors from the CMCI interrupt handler.

When a CMCI storm happens, we disable CMCI interrupts and kick the
kthread, which polls every HZ/100 until the storm has subsided, at which
point it re-enables CMCI interrupts and parks itself.

If CMCI isn't supported though, how is the polling done? You said the
dynamic interval is desirable, wouldn't that need to be in the kthread?
Having both the kthread and the timer around seems ugly, even if only
one is used on a given machine.

Thanks,
Calvin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/13] irqchip: GICv3: ITS command queue

2014-12-09 Thread Yun Wu (Abel)

On 2014/11/24 22:35, Marc Zyngier wrote:

[...]

> +static struct its_collection *its_build_mapd_cmd(struct its_cmd_block *cmd,
> +  struct its_cmd_desc *desc)
> +{
> + unsigned long itt_addr;
> + u8 size = order_base_2(desc->its_mapd_cmd.dev->nr_ites);

If @nr_ites is 1, then @size becomes 0, and... (see below)

> +
> + itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt);
> + itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN);
> +
> + its_encode_cmd(cmd, GITS_CMD_MAPD);
> + its_encode_devid(cmd, desc->its_mapd_cmd.dev->device_id);
> + its_encode_size(cmd, size - 1);

here (size - 1) becomes the value of ~0, which will exceed the maximum
supported bits of identifier.

Regards,
Abel

> + its_encode_itt(cmd, itt_addr);
> + its_encode_valid(cmd, desc->its_mapd_cmd.valid);
> +
> + its_fixup_cmd(cmd);
> +
> + return desc->its_mapd_cmd.dev->collection;
> +}
> +
> +static struct its_collection *its_build_mapc_cmd(struct its_cmd_block *cmd,
> +  struct its_cmd_desc *desc)
> +{
> + its_encode_cmd(cmd, GITS_CMD_MAPC);
> + its_encode_collection(cmd, desc->its_mapc_cmd.col->col_id);
> + its_encode_target(cmd, desc->its_mapc_cmd.col->target_address);
> + its_encode_valid(cmd, desc->its_mapc_cmd.valid);
> +
> + its_fixup_cmd(cmd);
> +
> + return desc->its_mapc_cmd.col;
> +}
> +
> +static struct its_collection *its_build_mapvi_cmd(struct its_cmd_block *cmd,
> +   struct its_cmd_desc *desc)
> +{
> + its_encode_cmd(cmd, GITS_CMD_MAPVI);
> + its_encode_devid(cmd, desc->its_mapvi_cmd.dev->device_id);
> + its_encode_event_id(cmd, desc->its_mapvi_cmd.event_id);
> + its_encode_phys_id(cmd, desc->its_mapvi_cmd.phys_id);
> + its_encode_collection(cmd, desc->its_mapvi_cmd.dev->collection->col_id);
> +
> + its_fixup_cmd(cmd);
> +
> + return desc->its_mapvi_cmd.dev->collection;
> +}
> +
> +static struct its_collection *its_build_movi_cmd(struct its_cmd_block *cmd,
> +  struct its_cmd_desc *desc)
> +{
> + its_encode_cmd(cmd, GITS_CMD_MOVI);
> + its_encode_devid(cmd, desc->its_movi_cmd.dev->device_id);
> + its_encode_event_id(cmd, desc->its_movi_cmd.id);
> + its_encode_collection(cmd, desc->its_movi_cmd.col->col_id);
> +
> + its_fixup_cmd(cmd);
> +
> + return desc->its_movi_cmd.dev->collection;
> +}
> +
> +static struct its_collection *its_build_discard_cmd(struct its_cmd_block 
> *cmd,
> + struct its_cmd_desc *desc)
> +{
> + its_encode_cmd(cmd, GITS_CMD_DISCARD);
> + its_encode_devid(cmd, desc->its_discard_cmd.dev->device_id);
> + its_encode_event_id(cmd, desc->its_discard_cmd.event_id);
> +
> + its_fixup_cmd(cmd);
> +
> + return desc->its_discard_cmd.dev->collection;
> +}
> +
> +static struct its_collection *its_build_inv_cmd(struct its_cmd_block *cmd,
> + struct its_cmd_desc *desc)
> +{
> + its_encode_cmd(cmd, GITS_CMD_INV);
> + its_encode_devid(cmd, desc->its_inv_cmd.dev->device_id);
> + its_encode_event_id(cmd, desc->its_inv_cmd.event_id);
> +
> + its_fixup_cmd(cmd);
> +
> + return desc->its_inv_cmd.dev->collection;
> +}
> +
> +static struct its_collection *its_build_invall_cmd(struct its_cmd_block *cmd,
> +struct its_cmd_desc *desc)
> +{
> + its_encode_cmd(cmd, GITS_CMD_INVALL);
> + its_encode_collection(cmd, desc->its_mapc_cmd.col->col_id);
> +
> + its_fixup_cmd(cmd);
> +
> + return NULL;
> +}
> +
> +static u64 its_cmd_ptr_to_offset(struct its_node *its,
> +  struct its_cmd_block *ptr)
> +{
> + return (ptr - its->cmd_base) * sizeof(*ptr);
> +}
> +
> +static int its_queue_full(struct its_node *its)
> +{
> + int widx;
> + int ridx;
> +
> + widx = its->cmd_write - its->cmd_base;
> + ridx = readl_relaxed(its->base + GITS_CREADR) / sizeof(struct 
> its_cmd_block);
> +
> + /* This is incredibly unlikely to happen, unless the ITS locks up. */
> + if (((widx + 1) % ITS_CMD_QUEUE_NR_ENTRIES) == ridx)
> + return 1;
> +
> + return 0;
> +}
> +
> +static struct its_cmd_block *its_allocate_entry(struct its_node *its)
> +{
> + struct its_cmd_block *cmd;
> + u32 count = 100;/* 1s! */
> +
> + while (its_queue_full(its)) {
> + count--;
> + if (!count) {
> + pr_err_ratelimited("ITS queue not draining\n");
> + return NULL;
> + }
> + cpu_relax();
> + udelay(1);
> + }
> +
> + cmd = its->cmd_write++;
> +
> + /* Handle queue wrapping */
> + if (its->cmd_write == (its->cmd_base + ITS_CMD_QUEUE_NR_ENTRIES))
> + its->cmd_write = its->cmd_base;
> +
> +

Re: [GIT PULL] arch/nios2 for v3.19

2014-12-09 Thread George Spelvin

> Actually, git already preserves the signed annotated tag.  That's the
> only way git show --show-signature can verify the tag's gpg signature.
> 
> You can see original signed annotated tag via a command like this:
> 
> git cat-file -p 18b34d9a7a085ba8f9cafa6a0d002e2cbac87c1f

TIL, thank you!

For the others watching in, as you know all commits have "headers"
which are normally not printed.  The above commit looks like

>  tree 939755a58a68aae5e1241b2a905ea612aeb2e589
>  parent 502fde1a0a2990ec54eab5241d3135c545da7372
>  parent bf40c92635d63fcc574c52649f7cda13e0418ac1
>  author Linus Torvalds  1405282495 -0700
>  committer Linus Torvalds  1405282495 -0700
>  mergetag object bf40c92635d63fcc574c52649f7cda13e0418ac1
>   type commit
>   tag ext4_for_linus_stable
>   tagger Theodore Ts'o  1405281748 -0400
>   
>   More bug fixes for ext4 -- most importantly, a fix for a bug
>   (introduced in 3.15) that can end up triggering a file system
>   corruption error after a journal replay.  (It shouldn't lead to any
>   actual data corruption, but it is scary and can force file systems to
>   be remounted read-only, etc.)
>   -BEGIN PGP SIGNATURE-

The "mergetag" header contains the original annotated tag, indented
by one space.

In this case, Ted included the same message (formatted slightly
differently) in the pull e-mail and Linus copied it into the
merge commit, so it worked out in the end.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] Tools: hv: fix compiler warnings and do minor cleanup

2014-12-09 Thread Dexuan Cui

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Tuesday, December 9, 2014 23:48 PM
> To: KY Srinivasan
> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; Dexuan Cui
> Subject: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup
> 
> When someone does 'make' in tools/hv/ issues appear:
> - hv_fcopy_daemon is not being built;
> - lots of compiler warnings.
> 
> This is just a cleanup. Compile-tested by myself on top of linux-next/master.
> 
> Piggyback this series and send "[PATCH 5/5] Tools: hv: do not add redundant
> '/'
>  in hv_start_fcopy()"
> 
> Vitaly Kuznetsov (5):
>   Tools: hv: add mising fcopyd to the Makefile
>   Tools: hv: remove unused bytes_written from kvp_update_file()
>   Tools: hv: address compiler warnings for hv_kvp_daemon.c
>   Tools: hv: address compiler warnings for hv_fcopy_daemon.c
>   Tools: hv: do not add redundant '/' in hv_start_fcopy()
> 
>  tools/hv/Makefile  |  4 ++--
>  tools/hv/hv_fcopy_daemon.c | 10 ++
>  tools/hv/hv_kvp_daemon.c   | 29 +
>  3 files changed, 17 insertions(+), 26 deletions(-)
> 
> --
> 1.9.3

Hi Vitaly,
Thanks for the patchset!

Acked-by: Dexuan Cui 

PS, I added Greg into the TO list.
The hv code in drivers/hv/ and tools/hv/ usually has to go into
Greg's tree first.

-- Dexuan

Re: [PATCH 0/20] fix misspelling of current function in string

2014-12-09 Thread Julian Calaby

Hi Julia,

On Mon, Dec 8, 2014 at 5:43 PM, Julia Lawall  wrote:
> On Mon, 8 Dec 2014, Julian Calaby wrote:
>
>> Hi Julia,
>>
>> On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall  wrote:
>> > These patches replace what appears to be a reference to the name of the
>> > current function but is misspelled in some way by either the name of the
>> > function itself, or by %s and then __func__ in an argument list.
>>
>> Would there be any value in doing this for _all_ cases where the
>> function name is written in a format string?
>
> Probably.  But there are a lot of them.  Even for the misspellings, I have
> only don about 1/3 of the cases.
>
> On the other hand, the misspelling have to be checked carefully, because a
> misspelling of one thing could be the correct spelling of the thing thst
> was actually intended.
>
> Joe, however, points out that a lot of these prints are just for function
> tracing, and could be removed.  I worked on another semantic patch that
> tries to do that.  It might be better to remove those prints completely,
> rather than sending one patch to transform them and then one patch to
> remove them after that.  That is why for this series I did only the ones
> where there was actually a problem.

Ok, that makes sense.

Either way though, this is a really interesting application of the
semantic patching. Nice work!

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fix suspicious rcu_dereference_check in net/sched/sch_fq_codel.c

2014-12-09 Thread David Miller

From: Valdis Kletnieks 
Date: Tue, 09 Dec 2014 16:15:50 -0500

> commit 46e5da40ae (net: qdisc: use rcu prefix and silence
>  sparse warnings) triggers a spurious warning:
> 
> net/sched/sch_fq_codel.c:97 suspicious rcu_dereference_check() usage!
> 
> The code should be using the _bh variant of rcu_dereference.
> 
> Signed-off-by: Valdis Kletnieks 

Applied and queued up for -stable, 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 security tree with the vfs tree

Hi James,

Today's linux-next merge of the security tree got a conflict in
init/main.c between commit 87fb64a6c1f7 ("take the targets
of /proc/*/ns/* symlinks to separate fs") from the vfs tree and commit
c9cd2ce2bc63 ("integrity: provide a hook to load keys when rootfs is
ready") from the security 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 init/main.c
index 40240c8e31e8,9fc795fe4b3b..
--- a/init/main.c
+++ b/init/main.c
@@@ -78,7 -78,7 +78,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  
  #include 
  #include 


pgp_LoY2KjbDb.pgp
Description: OpenPGP digital signature

Re: [PATCH V4] powerpc: add little endian flag to syscall_get_arch()

2014-12-09 Thread Richard Guy Briggs

On 14/12/10, Michael Ellerman wrote:
> On Tue, 2014-12-09 at 21:11 -0500, Paul Moore wrote:
> > On Tuesday, December 09, 2014 03:37:07 PM Richard Guy Briggs wrote:
> > > Since both ppc and ppc64 have LE variants which are now reported by uname,
> > > add that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add
> > > AUDIT_ARCH_PPC64LE variant.
> > > 
> > > Without this,  perf trace and auditctl fail.
> > > 
> > > Mainline kernel reports ppc64le (per a058801) but there is no matching
> > > AUDIT_ARCH_PPC64LE.
> > > 
> > > Since 32-bit PPC LE is not supported by audit, don't advertise it in
> > > AUDIT_ARCH_PPC* variants.
> > > 
> > > See:
> > >   https://www.redhat.com/archives/linux-audit/2014-August/msg00082.html
> > >   https://www.redhat.com/archives/linux-audit/2014-December/msg4.html
> > > 
> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > >  arch/powerpc/include/asm/syscall.h |6 +-
> > >  include/uapi/linux/audit.h |2 ++
> > >  2 files changed, 7 insertions(+), 1 deletions(-)
> > 
> > The audit changes look fine to me, but as I mentioned earlier, this should 
> > go 
> > in via the ppc tree and not the audit tree.
> > 
> > Acked-by: Paul Moore 
> 
> Thanks.
> 
> Yep I'll take it via the powerpc tree, I'll CC stable as well as presumably we
> want this to work in all versions that had LE support.

Yes, please!

(I was very tempted to change the #error to #warning, but figured the
placeholder comment in the uapi file was sufficient.)

> cheers

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] Audit patches for 3.19

2014-12-09 Thread Paul Moore

Hi Linus,

Two small patches from the audit next branch; only one of which has any real 
significant code changes, the other is simply a MAINTAINERS update for audit.  
The single code patch is pretty small and rather straightforward, it changes 
the audit "version" number reported to userspace from an integer to a bitmap 
which is used to indicate the functionality of the running kernel.  This 
really doesn't have much impact on the kernel, but it will make life easier 
for the audit userspace folks.  Thankfully we were still on a version number 
which allowed us to do this without breaking userspace.

For what it is worth, as of a few minutes ago, the branch below applied 
cleanly on top of your tree.

Thanks,
-Paul

---
The following changes since commit 799b601451b21ebe7af0e6e8f6e2ccd4683c5064:

  audit: keep inode pinned (2014-11-11 14:20:22 -0500)

are available in the git repository at:

  git://git.infradead.org/users/pcmoore/audit upstream

for you to fetch changes up to 0f7e94ee40d06f7a04e039392dfee8244bd8a7e0:

  Merge branch 'next' into upstream for v3.19 (2014-12-09 14:38:30 -0500)


Paul Moore (2):
  audit: add Paul Moore to the MAINTAINERS entry
  Merge branch 'next' into upstream for v3.19

Richard Guy Briggs (1):
  audit: convert status version to a feature bitmap

 MAINTAINERS|  5 +++--
 include/uapi/linux/audit.h | 17 +
 kernel/audit.c |  2 +-
 3 files changed, 17 insertions(+), 7 deletions(-)


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

[PATCH v2] smpboot: Check for successfull allocation of cpumask vars

2014-12-09 Thread Pranith Kumar

zalloc_cpumask_var() can return 0 on allocation failure when
CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and warn on failure
of an allocation in such cases. Also remove the cpus from cpu masks so
that they are not accessed later on.

Signed-off-by: Pranith Kumar 
---
 arch/x86/kernel/smpboot.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 7a8f584..35bc3f1 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1083,6 +1083,7 @@ static void __init smp_cpu_index_default(void)
 void __init native_smp_prepare_cpus(unsigned int max_cpus)
 {
unsigned int i;
+   bool ret = true;
 
preempt_disable();
smp_cpu_index_default();
@@ -1096,9 +1097,23 @@ void __init native_smp_prepare_cpus(unsigned int 
max_cpus)
 
current_thread_info()->cpu = 0;  /* needed? */
for_each_possible_cpu(i) {
-   zalloc_cpumask_var(_cpu(cpu_sibling_map, i), GFP_KERNEL);
-   zalloc_cpumask_var(_cpu(cpu_core_map, i), GFP_KERNEL);
-   zalloc_cpumask_var(_cpu(cpu_llc_shared_map, i), GFP_KERNEL);
+   ret &= zalloc_cpumask_var(_cpu(cpu_sibling_map, i), 
GFP_KERNEL);
+   ret &= zalloc_cpumask_var(_cpu(cpu_core_map, i), 
GFP_KERNEL);
+   ret &= zalloc_cpumask_var(_cpu(cpu_llc_shared_map, i), 
GFP_KERNEL);
+
+   if (!ret) {
+   /* cpumask allocation failed, remove this and next cpus 
from
+* possible/present/online/active masks
+*/
+   pr_warn("cpumask allocation failed!\n");
+   for (; i < nr_cpu_ids; i = cpumask_next(i, 
_possible_mask)) {
+   set_cpu_possible(i, false);
+   set_cpu_active(i, false);
+   set_cpu_online(i, false);
+   set_cpu_present(i, false);
+   }
+   break;
+   }
}
set_cpu_sibling_map(0);
 
-- 
1.9.1

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

Re: [PATCH v2 3/4] ARM: mach-bcm: Enable I2C support for iProc




On 12/9/2014 6:20 PM, Florian Fainelli wrote:

On 09/12/14 18:18, Ray Jui wrote:

Enable I2C driver support for Broadcom iProc family of SoCs by
selecting I2C_BCM_IPROC

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
  arch/arm/mach-bcm/Kconfig |1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index aaeec78..86ee90b 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -19,6 +19,7 @@ config ARCH_BCM_IPROC
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
select PINCTRL
+   select I2C_BCM_IPROC


One way to avoid having to modify mach-bcm/Kconfig would be to have your
i2c driver Kconfig do this:

default ARCH_BCM_IPROC

would that work?

Yes. So in which case it is better to select a driver from the 
architecture specific Kconfig?



help
  This enables support for systems based on Broadcom IPROC architected 
SoCs.
  The IPROC complex contains one or more ARM CPUs along with common




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mm: shmem: freeing mlocked page

2014-12-09 Thread Sasha Levin

(Apologies for spam, I've Cc'ed a few outdated emails in the previous mail)

On 12/09/2014 09:15 PM, Sasha Levin wrote:
> On 11/18/2014 04:58 PM, Andrew Morton wrote:
>>> [ 1026.994816] Modules linked in:
 [ 1026.995378] CPU: 7 PID: 7879 Comm: trinity-c374 Not tainted 
 3.18.0-rc4-next-20141113-sasha-00047-gd1763ce-dirty #1455
 [ 1026.996123] FAULT_INJECTION: forcing a failure.
 [ 1026.996123] name failslab, interval 100, probability 30, space 0, times 
 -1
 [ 1026.999050]    00b3d300 
 88061295bbd8
 [ 1027.000676]  92f71097  eab3d300 
 88061295bc08
 [ 1027.002020]  8197ef7a eab3d300 942dd148 
 dfffe900
 [ 1027.003359] Call Trace:
 [ 1027.003831] dump_stack (lib/dump_stack.c:52)
 [ 1027.004725] bad_page (mm/page_alloc.c:338)
 [ 1027.005623] free_pages_prepare (mm/page_alloc.c:657 mm/page_alloc.c:763)
 [ 1027.006761] free_hot_cold_page (mm/page_alloc.c:1438)
 [ 1027.007772] ? __page_cache_release (mm/swap.c:66)
 [ 1027.008815] put_page (mm/swap.c:270)
 [ 1027.009665] page_cache_pipe_buf_release (fs/splice.c:93)
 [ 1027.010888] __splice_from_pipe (fs/splice.c:784 fs/splice.c:886)
 [ 1027.011917] ? might_fault (./arch/x86/include/asm/current.h:14 
 mm/memory.c:3734)
 [ 1027.012856] ? pipe_lock (fs/pipe.c:69)
 [ 1027.013728] ? write_pipe_buf (fs/splice.c:1534)
 [ 1027.014756] vmsplice_to_user (fs/splice.c:1574)
 [ 1027.015725] ? rcu_read_lock_held (kernel/rcu/update.c:169)
 [ 1027.016757] ? __fget_light (include/linux/fdtable.h:80 fs/file.c:684)
 [ 1027.017782] SyS_vmsplice (fs/splice.c:1656 fs/splice.c:1639)
 [ 1027.018863] tracesys_phase2 (arch/x86/kernel/entry_64.S:529)

>> So what happened here?  Userspace fed some mlocked memory into splice()
>> and then, while splice() was running, userspace dropped its reference
>> to the memory, leaving splice() with the last reference.  Yet somehow,
>> that page was still marked as being mlocked.  I wouldn't expect the
>> kernel to permit userspace to drop its reference to the memory without
>> first clearing the mlocked state.
>>
>> Is it possible to work out from trinity sources what the exact sequence
>> was?  Which syscalls are being used, for example?
> 
> Phew, this took a long while but I've bisected it (with good confidence) down
> to:
> 
> commit a38246260912ba4a0f8b563704a965a7a97cf3c3
> Author: Davidlohr Bueso 
> Date:   Wed Dec 3 18:54:27 2014 +1100
> 
> mm/memory.c: share the i_mmap_rwsem
> 
> The unmap_mapping_range family of functions do the unmapping of user pages
> (ultimately via zap_page_range_single) without touching the actual
> interval tree, thus share the lock.
> 
> Signed-off-by: Davidlohr Bueso 
> Cc: "Kirill A. Shutemov" 
> Acked-by: Hugh Dickins 
> Cc: Oleg Nesterov 
> Cc: Peter Zijlstra (Intel) 
> Cc: Rik van Riel 
> Cc: Srikar Dronamraju 
> Acked-by: Mel Gorman 
> Signed-off-by: Andrew Morton 
> 
> 
> Thanks,
> Sasha
> 

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

Re: [PATCH v2 3/4] ARM: mach-bcm: Enable I2C support for iProc

2014-12-09 Thread Florian Fainelli

On 09/12/14 18:18, Ray Jui wrote:
> Enable I2C driver support for Broadcom iProc family of SoCs by
> selecting I2C_BCM_IPROC
> 
> Signed-off-by: Ray Jui 
> Reviewed-by: Scott Branden 
> ---
>  arch/arm/mach-bcm/Kconfig |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index aaeec78..86ee90b 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -19,6 +19,7 @@ config ARCH_BCM_IPROC
>   select ARCH_REQUIRE_GPIOLIB
>   select ARM_AMBA
>   select PINCTRL
> + select I2C_BCM_IPROC

One way to avoid having to modify mach-bcm/Kconfig would be to have your
i2c driver Kconfig do this:

default ARCH_BCM_IPROC

would that work?

>   help
> This enables support for systems based on Broadcom IPROC architected 
> SoCs.
> The IPROC complex contains one or more ARM CPUs along with common
> 

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

Re: [PATCH V4] powerpc: add little endian flag to syscall_get_arch()

2014-12-09 Thread Michael Ellerman

On Tue, 2014-12-09 at 21:11 -0500, Paul Moore wrote:
> On Tuesday, December 09, 2014 03:37:07 PM Richard Guy Briggs wrote:
> > Since both ppc and ppc64 have LE variants which are now reported by uname,
> > add that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add
> > AUDIT_ARCH_PPC64LE variant.
> > 
> > Without this,  perf trace and auditctl fail.
> > 
> > Mainline kernel reports ppc64le (per a058801) but there is no matching
> > AUDIT_ARCH_PPC64LE.
> > 
> > Since 32-bit PPC LE is not supported by audit, don't advertise it in
> > AUDIT_ARCH_PPC* variants.
> > 
> > See:
> > https://www.redhat.com/archives/linux-audit/2014-August/msg00082.html
> > https://www.redhat.com/archives/linux-audit/2014-December/msg4.html
> > 
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  arch/powerpc/include/asm/syscall.h |6 +-
> >  include/uapi/linux/audit.h |2 ++
> >  2 files changed, 7 insertions(+), 1 deletions(-)
> 
> The audit changes look fine to me, but as I mentioned earlier, this should go 
> in via the ppc tree and not the audit tree.
> 
> Acked-by: Paul Moore 

Thanks.

Yep I'll take it via the powerpc tree, I'll CC stable as well as presumably we
want this to work in all versions that had LE support.

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] net: introduce helper macro for_each_cmsghdr

2014-12-09 Thread Gu Zheng

Hi Joe,
On 12/10/2014 10:01 AM, Joe Perches wrote:

> On Wed, 2014-12-10 at 09:39 +0800, Gu Zheng wrote:
>> Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating
>> cmsghdr from msghdr, just cleanup. 
> 
> Does this even compile?
> 
> So which is it?
> 
>   for_each_cmsghdr
> or
>   for_each_cmsg_hdr?
> 
> The .h #defines for_each_cmsg_hdr
> but all the uses are for_each_cmsghdr

Thanks for your quick feedback.
There seems some problems with my send-patch script, it sent out the patch
before the test completed.

Thanks,
Gu

> 
>> diff --git a/Documentation/networking/timestamping/timestamping.c 
>> b/Documentation/networking/timestamping/timestamping.c
> []
>> @@ -169,9 +169,7 @@ static void printpacket(struct msghdr *msg, int res,
>> res,
>> inet_ntoa(from_addr->sin_addr),
>> msg->msg_controllen);
>> -for (cmsg = CMSG_FIRSTHDR(msg);
>> - cmsg;
>> - cmsg = CMSG_NXTHDR(msg, cmsg)) {
>> +for_each_cmsghdr(cmsg, msg) {
>>  printf("   cmsg len %zu: ", cmsg->cmsg_len);
>>  switch (cmsg->cmsg_level) {
>>  case SOL_SOCKET:
>> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> []
>> @@ -399,7 +399,7 @@ int af_alg_cmsg_send(struct msghdr *msg, struct 
>> af_alg_control *con)
>>  {
>>  struct cmsghdr *cmsg;
>>  
>> -for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
>> +for_each_cmsghdr(cmsg, msg) {
>>  if (!CMSG_OK(msg, cmsg))
>>  return -EINVAL;
>>  if (cmsg->cmsg_level != SOL_ALG)
>> diff --git a/include/linux/socket.h b/include/linux/socket.h
> []
>> @@ -94,6 +94,10 @@ struct cmsghdr {
>>   (cmsg)->cmsg_len <= (unsigned long) \
>>   ((mhdr)->msg_controllen - \
>>((char *)(cmsg) - (char *)(mhdr)->msg_control)))
>> +#define for_each_cmsg_hdr(cmsg, msg)  \
>> +for (cmsg = CMSG_FIRSTHDR(msg); \
>> + cmsg; \
>> + cmsg = CMSG_NXTHDR(msg, cmsg))
> 
> 
> 
> .
> 


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

[GIT PULL] f2fs updates for v3.19

2014-12-09 Thread Jaegeuk Kim

Hi Linus,

This patch-set includes lots of bug fixes based on clean-ups and refactored
codes. And inline_dir was introduced and two minor mount options were added.

Please, pull the following patches.

Thank you,

The following changes since commit f4ca536f71ad69d9a974d0156d43b24b3f3112de:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k (2014-11-03 
14:09:33 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git 
tags/for-f2fs-3.19

for you to fetch changes up to 635aee1fefef921ae4124b127fced62ea6008839:

  f2fs: avoid to ra unneeded blocks in recover flow (2014-12-08 14:19:09 -0800)


f2fs updates for v3.19

This series includes the following enhancement with refactored flows.
 o fix inmemory page operations
 o fix wrong inline_data & inline_dir logics
 o enhance memory and IO control under memory pressure
 o consider preemption on radix_tree operation
 o fix memory leaks and deadlocks

But also, there are a couple of new features:
 o support inline_dir to store dentries inside inode page
 o add -o fastboot to reduce booting time
 o implement -o dirsync

And a lot of clean-ups and minor bug fixes as well.


Changman Lee (8):
  f2fs: fix wrong data structure when create slab
  f2fs: check dirty_nat_cnt before flushing nat entries in journal
  f2fs: no more dirty_nat_entires when flushing
  f2fs: cleanup if-statement of phase in gc_data_segment
  f2fs: cleanup redundant macro
  f2fs: more fast lookup for gc_inode list
  f2fs: check if inode state is dirty at fsync
  f2fs: cleanup path to need cp at fsync

Chao Yu (14):
  f2fs: add infra struct and helper for inline dir
  f2fs: add a new mount option for inline dir
  f2fs: export dir operations for inline dir
  f2fs: add key function to handle inline dir
  f2fs: enable inline dir handling
  f2fs: update f2fs documentation for inline dir support
  f2fs: avoid unable to restart gc thread in remount
  f2fs: remove unneeded check code with option in f2fs_remount
  f2fs: introduce struct inode_management to wrap inner fields
  f2fs: fix to return correct error number in f2fs_write_begin
  f2fs: use atomic for counting inode with inline_{dir,inode} flag
  f2fs: fix to enable readahead for SSA/CP blocks
  f2fs: introduce is_valid_blkaddr to cleanup codes in ra_meta_pages
  f2fs: avoid to ra unneeded blocks in recover flow

Gu Zheng (6):
  f2fs: remove the seems unneeded argument 'type' from __get_victim
  f2fs: remove the redundant function cond_clear_inode_flag
  f2fs: introduce f2fs_change_bit to simplify the change bit logic
  f2fs: set raw_super default to NULL to avoid compile warning
  f2fs: rename f2fs_set/clear_bit to f2fs_test_and_set/clear_bit
  f2fs: use current_sit_addr to replace the open code

Jaegeuk Kim (56):
  f2fs: do not make dirty any inmemory pages
  f2fs: invalidate inmemory page
  f2fs: should truncate any allocated block for inline_data write
  f2fs: fix race conditon on truncation with inline_data
  f2fs: use highmem for directory pages
  f2fs: avoid to allocate when inline_data was written
  f2fs: fix to call f2fs_unlock_op
  f2fs: avoid build warning
  f2fs: avoid infinite loop at cp_error
  f2fs: reuse room_for_filename for inline dentry operation
  f2fs: reuse find_in_block code for find_in_inline_dir
  f2fs: fix to wait correct block type
  f2fs: avoid deadlock on init_inode_metadata
  f2fs: add stat info for inline_dentry inodes
  f2fs: fix counting inline_data inode numbers
  f2fs: reuse core function in f2fs_readdir for inline_dentry
  f2fs: should not truncate any inline_dentry
  f2fs: introduce f2fs_dentry_ptr structure for code clean-up
  f2fs: reuse make_empty_dir code for inline_dentry
  f2fs: use kmap_atomic instead of kmap
  f2fs: declare f2fs_convert_inline_dir as a static function
  f2fs: call write_checkpoint under disabled gc
  f2fs: flush_dcache_page for inline data
  f2fs: do not discard data protected by the previous checkpoint
  f2fs: revisit inline_data to avoid data races and potential bugs
  f2fs: send discard commands in larger extent
  f2fs: avoid race condition in handling wait_io
  f2fs: remove unnecessary macro
  f2fs: introduce -o fastboot for reducing booting time only
  f2fs: disable roll-forward when active_logs = 2
  f2fs: introduce the number of inode entries
  f2fs: control the memory footprint used by ino entries
  f2fs: write node pages if checkpoint is not doing
  f2fs: do not skip any writes under memory pressure
  f2fs: implement -o dirsync
  f2fs: reduce the number of inline_data inode before clearing it
  f2fs:

Re: Shorten efi regions output

2014-12-09 Thread Dave Young

On 12/09/14 at 10:58am, Borislav Petkov wrote:
> Hi guys,
> 
> so this decoded EFI regions output is nice but can we shorten it? It
> sticks too far out in the terminal more than anything else in dmesg and
> staring at it needs me to resize window and such. It probably is an even
> bigger problem if one's monitor hasn't switched to higher res early
> during boot.

I have same feeling with you, it is too long for most of people.

Since the printk code are for EFI_DEBUG, they are around the #ifdef 
so I would like to see a kernel param like efi_debug=on, so only efi_debug
is specified then these verbose messages are printed. Without the param
kernel can print some basic infomation about the memory ranges.

In arm64 code there's already a uefi_debug param it can be moved to general
code so that there will be a goable switch.


> 
> So here's what I'm seeing with the latest EDKII:
> 
> [0.00] efi: EFI v2.40 by EDK II
> [0.00] efi:  ACPI=0x7ff2d000  ACPI 2.0=0x7ff2d014 
> [0.00] efi: mem00: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x-0x1000) (0MB)
> [0.00] efi: mem01: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x1000-0x2000) (0MB)
> [0.00] efi: mem02: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x2000-0x0009f000) (0MB)
> [0.00] efi: mem03: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x0009f000-0x000a) (0MB)
> [0.00] efi: mem04: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x0010-0x0082) (7MB)
> [0.00] efi: mem05: [Boot Data  |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x0082-0x0100) (7MB)
> [0.00] efi: mem06: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x0100-0x03cbc000) (44MB)
> [0.00] efi: mem07: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x03cbc000-0x0400) (3MB)
> [0.00] efi: mem08: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x0400-0x05cbc000) (28MB)
> [0.00] efi: mem09: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x05cbc000-0x3fffc000) (931MB)
> [0.00] efi: mem10: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x3fffc000-0x4000) (0MB)
> [0.00] efi: mem11: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x4000-0x7c00) (960MB)
> [0.00] efi: mem12: [Boot Data  |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7c00-0x7c02) (0MB)
> [0.00] efi: mem13: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7c02-0x7ebc5000) (43MB)
> [0.00] efi: mem14: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ebc5000-0x7ebfe000) (0MB)
> [0.00] efi: mem15: [Boot Data  |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ebfe000-0x7ebff000) (0MB)
> [0.00] efi: mem16: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ebff000-0x7ec03000) (0MB)
> [0.00] efi: mem17: [Boot Data  |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ec03000-0x7ec05000) (0MB)
> [0.00] efi: mem18: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ec05000-0x7ec06000) (0MB)
> [0.00] efi: mem19: [Boot Data  |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ec06000-0x7ec07000) (0MB)
> [0.00] efi: mem20: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ec07000-0x7ec08000) (0MB)
> [0.00] efi: mem21: [Boot Data  |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ec08000-0x7ece7000) (0MB)
> [0.00] efi: mem22: [Boot Code  |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ece7000-0x7ee3b000) (1MB)
> [0.00] efi: mem23: [Runtime Data   |RUN|  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ee3b000-0x7ee4e000) (0MB)
> [0.00] efi: mem24: [Boot Data  |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ee4e000-0x7fd4e000) (15MB)
> [0.00] efi: mem25: [Boot Code  |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7fd4e000-0x7fece000) (1MB)
> [0.00] efi: mem26: [Runtime Code   |RUN|  |  |  |   |WB|WT|WC|UC] 
> range=[0x7fece000-0x7fefe000) (0MB)
> [0.00] efi: mem27: [Runtime Data   |RUN|  |  |  |   |WB|WT|WC|UC] 
> range=[0x7fefe000-0x7ff22000) (0MB)
> [0.00] efi: mem28: [Reserved   |   |  |  |  |   |WB|WT|WC|UC] 
> range=[0x7ff22000-0x7ff26000) (0MB)
> [0.00] efi: mem29: [ACPI Reclaim Memory|   |  |  |  |   |WB|WT|WC|UC]

[PATCH v2 1/4] i2c: iProc: define Broadcom iProc I2C binding

Document the I2C device tree binding for Broadcom iProc family of
SoCs

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../devicetree/bindings/i2c/brcm,iproc-i2c.txt |   37 
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt

diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt 
b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
new file mode 100644
index 000..81f982c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
@@ -0,0 +1,37 @@
+Broadcom iProc I2C controller
+
+Required properties:
+
+- compatible:
+Must be "brcm,iproc-i2c"
+
+- reg:
+Define the base and range of the I/O address space that contain the iProc
+I2C controller registers
+
+- interrupts:
+Should contain the I2C interrupt
+
+- clock-frequency:
+This is the I2C bus clock. Need to be either 10 or 40
+
+- #address-cells:
+Always 1 (for I2C addresses)
+
+- #size-cells:
+Always 0
+
+Example:
+   i2c0: i2c@18008000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+
+   codec: wm8750@1a {
+   compatible = "wlf,wm8750";
+   reg = <0x1a>;
+   };
+   };
-- 
1.7.9.5

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

[PATCH v2 2/4] i2c: iproc: Add Broadcom iProc I2C Driver

Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.

The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/i2c/busses/Kconfig |9 +
 drivers/i2c/busses/Makefile|1 +
 drivers/i2c/busses/i2c-bcm-iproc.c |  502 
 3 files changed, 512 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c1351d9..8a2eb7e 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -372,6 +372,15 @@ config I2C_BCM2835
  This support is also available as a module.  If so, the module
  will be called i2c-bcm2835.
 
+config I2C_BCM_IPROC
+   tristate "Broadcom iProc I2C controller"
+   depends on ARCH_BCM_IPROC
+   help
+ If you say yes to this option, support will be included for the
+ Broadcom iProc I2C controller.
+
+ If you don't know what to do here, say N.
+
 config I2C_BCM_KONA
tristate "BCM Kona I2C adapter"
depends on ARCH_BCM_MOBILE
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 5e6c822..216e7be 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_AT91)+= i2c-at91.o
 obj-$(CONFIG_I2C_AU1550)   += i2c-au1550.o
 obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
 obj-$(CONFIG_I2C_BCM2835)  += i2c-bcm2835.o
+obj-$(CONFIG_I2C_BCM_IPROC)+= i2c-bcm-iproc.o
 obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
 obj-$(CONFIG_I2C_CADENCE)  += i2c-cadence.o
 obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c 
b/drivers/i2c/busses/i2c-bcm-iproc.c
new file mode 100644
index 000..57f5f29
--- /dev/null
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -0,0 +1,502 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CFG_OFFSET   0x00
+#define CFG_RESET_SHIFT  31
+#define CFG_EN_SHIFT 30
+#define CFG_M_RETRY_CNT_SHIFT16
+#define CFG_M_RETRY_CNT_MASK 0x0f
+
+#define TIM_CFG_OFFSET   0x04
+#define TIME_CFG_MODE_400_SHIFT  31
+
+#define M_FIFO_CTRL_OFFSET   0x0c
+#define M_FIFO_RX_FLUSH_SHIFT31
+#define M_FIFO_TX_FLUSH_SHIFT30
+#define M_FIFO_RX_CNT_SHIFT  16
+#define M_FIFO_RX_CNT_MASK   0x7f
+#define M_FIFO_RX_THLD_SHIFT 8
+#define M_FIFO_RX_THLD_MASK  0x3f
+
+#define M_CMD_OFFSET 0x30
+#define M_CMD_START_BUSY_SHIFT   31
+#define M_CMD_STATUS_SHIFT   25
+#define M_CMD_STATUS_MASK0x07
+#define M_CMD_STATUS_SUCCESS 0x0
+#define M_CMD_STATUS_LOST_ARB0x1
+#define M_CMD_STATUS_NACK_ADDR   0x2
+#define M_CMD_STATUS_NACK_DATA   0x3
+#define M_CMD_STATUS_TIMEOUT 0x4
+#define M_CMD_PROTOCOL_SHIFT 9
+#define M_CMD_PROTOCOL_MASK  0xf
+#define M_CMD_PROTOCOL_BLK_WR0x7
+#define M_CMD_PROTOCOL_BLK_RD0x8
+#define M_CMD_PEC_SHIFT  8
+#define M_CMD_RD_CNT_SHIFT   0
+#define M_CMD_RD_CNT_MASK0xff
+
+#define IE_OFFSET0x38
+#define IE_M_RX_FIFO_FULL_SHIFT  31
+#define IE_M_RX_THLD_SHIFT   30
+#define IE_M_START_BUSY_SHIFT28
+
+#define IS_OFFSET0x3c
+#define IS_M_RX_FIFO_FULL_SHIFT  31
+#define IS_M_RX_THLD_SHIFT   30
+#define IS_M_START_BUSY_SHIFT28
+
+#define M_TX_OFFSET  0x40
+#define M_TX_WR_STATUS_SHIFT 31
+#define M_TX_DATA_SHIFT  0
+#define M_TX_DATA_MASK   0xff
+
+#define M_RX_OFFSET  0x44
+#define M_RX_STATUS_SHIFT30
+#define M_RX_STATUS_MASK 0x03
+#define M_RX_PEC_ERR_SHIFT   29
+#define M_RX_DATA_SHIFT  0
+#define M_RX_DATA_MASK   0xff
+
+#define I2C_TIMEOUT_MESC 100
+#define M_TX_RX_FIFO_SIZE64
+
+enum bus_speed_index {
+   I2C_SPD_100K = 0,
+   I2C_SPD_400K,
+};
+
+struct bcm_iproc_i2c_dev {
+   struct device *device;
+
+   void

[PATCH v2 3/4] ARM: mach-bcm: Enable I2C support for iProc

Enable I2C driver support for Broadcom iProc family of SoCs by
selecting I2C_BCM_IPROC

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/mach-bcm/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index aaeec78..86ee90b 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -19,6 +19,7 @@ config ARCH_BCM_IPROC
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
select PINCTRL
+   select I2C_BCM_IPROC
help
  This enables support for systems based on Broadcom IPROC architected 
SoCs.
  The IPROC complex contains one or more ARM CPUs along with common
-- 
1.7.9.5

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

Re: mm: shmem: freeing mlocked page

2014-12-09 Thread Sasha Levin

On 11/18/2014 04:58 PM, Andrew Morton wrote:
>> [ 1026.994816] Modules linked in:
>> > [ 1026.995378] CPU: 7 PID: 7879 Comm: trinity-c374 Not tainted 
>> > 3.18.0-rc4-next-20141113-sasha-00047-gd1763ce-dirty #1455
>> > [ 1026.996123] FAULT_INJECTION: forcing a failure.
>> > [ 1026.996123] name failslab, interval 100, probability 30, space 0, times 
>> > -1
>> > [ 1026.999050]    00b3d300 
>> > 88061295bbd8
>> > [ 1027.000676]  92f71097  eab3d300 
>> > 88061295bc08
>> > [ 1027.002020]  8197ef7a eab3d300 942dd148 
>> > dfffe900
>> > [ 1027.003359] Call Trace:
>> > [ 1027.003831] dump_stack (lib/dump_stack.c:52)
>> > [ 1027.004725] bad_page (mm/page_alloc.c:338)
>> > [ 1027.005623] free_pages_prepare (mm/page_alloc.c:657 mm/page_alloc.c:763)
>> > [ 1027.006761] free_hot_cold_page (mm/page_alloc.c:1438)
>> > [ 1027.007772] ? __page_cache_release (mm/swap.c:66)
>> > [ 1027.008815] put_page (mm/swap.c:270)
>> > [ 1027.009665] page_cache_pipe_buf_release (fs/splice.c:93)
>> > [ 1027.010888] __splice_from_pipe (fs/splice.c:784 fs/splice.c:886)
>> > [ 1027.011917] ? might_fault (./arch/x86/include/asm/current.h:14 
>> > mm/memory.c:3734)
>> > [ 1027.012856] ? pipe_lock (fs/pipe.c:69)
>> > [ 1027.013728] ? write_pipe_buf (fs/splice.c:1534)
>> > [ 1027.014756] vmsplice_to_user (fs/splice.c:1574)
>> > [ 1027.015725] ? rcu_read_lock_held (kernel/rcu/update.c:169)
>> > [ 1027.016757] ? __fget_light (include/linux/fdtable.h:80 fs/file.c:684)
>> > [ 1027.017782] SyS_vmsplice (fs/splice.c:1656 fs/splice.c:1639)
>> > [ 1027.018863] tracesys_phase2 (arch/x86/kernel/entry_64.S:529)
>> > 
> So what happened here?  Userspace fed some mlocked memory into splice()
> and then, while splice() was running, userspace dropped its reference
> to the memory, leaving splice() with the last reference.  Yet somehow,
> that page was still marked as being mlocked.  I wouldn't expect the
> kernel to permit userspace to drop its reference to the memory without
> first clearing the mlocked state.
> 
> Is it possible to work out from trinity sources what the exact sequence
> was?  Which syscalls are being used, for example?

Phew, this took a long while but I've bisected it (with good confidence) down
to:

commit a38246260912ba4a0f8b563704a965a7a97cf3c3
Author: Davidlohr Bueso 
Date:   Wed Dec 3 18:54:27 2014 +1100

mm/memory.c: share the i_mmap_rwsem

The unmap_mapping_range family of functions do the unmapping of user pages
(ultimately via zap_page_range_single) without touching the actual
interval tree, thus share the lock.

Signed-off-by: Davidlohr Bueso 
Cc: "Kirill A. Shutemov" 
Acked-by: Hugh Dickins 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra (Intel) 
Cc: Rik van Riel 
Cc: Srikar Dronamraju 
Acked-by: Mel Gorman 
Signed-off-by: Andrew Morton 


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

[PATCH v2 4/4] ARM: dts: add I2C device nodes for Broadcom Cygnus

Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
them disabled there. Individual I2C devices can be enabled in board
specific dts file when I2C slave devices are enabled in the future

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi |   20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5126f9e..f7d6c1d 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -70,6 +70,26 @@
};
};
 
+   i2c0: i2c@18008000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@1800b000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x1800b000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
uart0: serial@1802 {
compatible = "snps,dw-apb-uart";
reg = <0x1802 0x100>;
-- 
1.7.9.5

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

[PATCH v2 0/4] Add I2C support to Broadcom iProc