Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

[Mat Martineau]

On Thu, 9 Jun 2016, Stephan Mueller wrote:


Am Donnerstag, 9. Juni 2016, 11:18:04 schrieb Mat Martineau:

Hi Mat,


Or is your concern that the user space interface restricts things too much
and thus prevents a valid use case?


The latter - my primary concern is the constraint this places on userspace
by forcing larger buffer sizes than might be necessary for the operation.
struct akcipher_request has separate members for src_len and dst_len, and
dst_len is documented as needing "to be at least as big as the expected
result depending on the operation". Not the maximum result, the expected
result. It's also documented that the cipher will generate an error if
dst_len is insufficient and update the value with the required size.

I'm updating some userspace TLS code that worked with an earlier, unmerged
patch set for AF_ALG akcipher (from last year). The read calls with
shorter buffers were the main porting problem.


I see -- are you proposing to drop that check entirely?


Yes.


Best regards,

--
Mat Martineau
Intel OTC

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

[Tom Lendacky]

On 06/08/2016 06:18 AM, Matt Fleming wrote:
> On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote:
>> The EFI tables are not encrypted and need to be accessed as such. Be sure
>> to memmap them without the encryption attribute set. For EFI support that
>> lives outside of the arch/x86 tree, create a routine that uses the __weak
>> attribute so that it can be overridden by an architecture specific routine.
>>
>> When freeing boot services related memory, since it has been mapped as
>> un-encrypted, be sure to change the mapping to encrypted for future use.
>>
>> Signed-off-by: Tom Lendacky 
>> ---
>>  arch/x86/include/asm/cacheflush.h  |3 +
>>  arch/x86/include/asm/mem_encrypt.h |   22 +++
>>  arch/x86/kernel/setup.c|6 +--
>>  arch/x86/mm/mem_encrypt.c  |   56 +++
>>  arch/x86/mm/pageattr.c |   75 
>> 
>>  arch/x86/platform/efi/efi.c|   26 +++-
>>  arch/x86/platform/efi/efi_64.c |9 +++-
>>  arch/x86/platform/efi/quirks.c |   12 +-
>>  drivers/firmware/efi/efi.c |   18 +++--
>>  drivers/firmware/efi/esrt.c|   12 +++---
>>  include/linux/efi.h|3 +
>>  11 files changed, 212 insertions(+), 30 deletions(-)
> 
> [...]
> 
>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
>> index 994a7df8..871b213 100644
>> --- a/arch/x86/platform/efi/efi.c
>> +++ b/arch/x86/platform/efi/efi.c
>> @@ -53,6 +53,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #define EFI_DEBUG
>>  
>> @@ -261,12 +262,12 @@ static int __init efi_systab_init(void *phys)
>>  u64 tmp = 0;
>>  
>>  if (efi_setup) {
>> -data = early_memremap(efi_setup, sizeof(*data));
>> +data = sme_early_memremap(efi_setup, sizeof(*data));
>>  if (!data)
>>  return -ENOMEM;
>>  }
> 
> Beware, this data comes from a previous kernel that kexec'd this
> kernel. Unless you've updated bzImage64_load() to allocate an
> unencrypted region 'efi_setup' will in fact be encrypted.

Yes, I missed the kexec path originally and need to take that into
account in general.

> 
>> @@ -690,6 +691,7 @@ static void *realloc_pages(void *old_memmap, int 
>> old_shift)
>>  ret = (void *)__get_free_pages(GFP_KERNEL, old_shift + 1);
>>  if (!ret)
>>  goto out;
>> +sme_set_mem_dec(ret, PAGE_SIZE << (old_shift + 1));
>>  
>>  /*
>>   * A first-time allocation doesn't have anything to copy.
> 
> I'm not sure why it's necessary to mark this region as unencrypted,
> because at this point the kernel controls the platform and when we
> call into the firmware it should be using our page tables. I wouldn't
> expect the firmware to mess with the SYSCFG MSR either.
> 
> Have you come across a situation where the above was required?

I was trying to play it safe here, but as you say, the firmware should
be using our page tables so we can get rid of this call. The problem
will actually be if we transition to a 32-bit efi. The encryption bit
will be lost in cr3 and so the pgd table will have to be un-encrypted.
The entries in the pgd can have the encryption bit set so I would only
need to worry about the pgd itself. I'll have to update the
efi_alloc_page_tables routine.

> 
>> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
>> index 49e4dd4..834a992 100644
>> --- a/arch/x86/platform/efi/efi_64.c
>> +++ b/arch/x86/platform/efi/efi_64.c
>> @@ -223,7 +223,7 @@ int __init efi_setup_page_tables(unsigned long 
>> pa_memmap, unsigned num_pages)
>>  if (efi_enabled(EFI_OLD_MEMMAP))
>>  return 0;
>>  
>> -efi_scratch.efi_pgt = (pgd_t *)__pa(efi_pgd);
>> +efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
>>  pgd = efi_pgd;
>>  
>>  /*
> 
> Huh? Why does __pa() now OR in sme_mas_mask? I thought SME only
> required the page table structures to be modified, not the end
> address?

The encryption bit in the cr3 register will indicate if the pgd table
is encrypted or not. Based on my comment above about the pgd having
to be un-encrypted in case we have to transition to 32-bit efi, this
can be removed.

> 
>> @@ -262,7 +262,8 @@ int __init efi_setup_page_tables(unsigned long 
>> pa_memmap, unsigned num_pages)
>>  pfn = md->phys_addr >> PAGE_SHIFT;
>>  npages = md->num_pages;
>>  
>> -if (kernel_map_pages_in_pgd(pgd, pfn, md->phys_addr, npages, 
>> _PAGE_RW)) {
>> +if (kernel_map_pages_in_pgd(pgd, pfn, md->phys_addr, npages,
>> +_PAGE_RW | _PAGE_ENC)) {
>>  pr_err("Failed to map 1:1 memory\n");
>>  return 1;
>>  }
> 
> Could you push the _PAGE_ENC addition down into
> kernel_map_pages_in_pgd()? Other flags are also handled that way, 

Re: [PATCH] staging: fbtft: do not allocate huge txbuf

[Noralf Trønnes]

[resending got rejected on the list for html format]

Den 09.06.2016 19:18, skrev Michal Suchanek:

Hello,

On 9 June 2016 at 18:20, Noralf Trønnes  wrote:

Den 09.06.2016 17:08, skrev Michal Suchanek:

txbuflen can be set to arbitrary value by user and it is also set
automagically to the maximum transfer size of the SPI master controller.


AFAICT this is a result of your previous patch. Please make a new version of
your previous patch with this fix in it. Also make a note in that thread
that

That patch is pretty much independent and just exposes this problem
under different circumstances. The txbuflen can be also set by the
user.


a new version is made so Greg doesn't pull it when he sees my ack. He
handles a large volume of patches so let's make it as easy as we can for
him.

Which would be letting in the patches separately imho.



Ok,

Acked-by: Noralf Trønnes 


Thanks

Michal

Re: [PATCH 3/7] kernel-doc-HOWTO: add kernel-doc specification

[Jani Nikula]

On Thu, 09 Jun 2016, Randy Dunlap  wrote:
> My only "requirement" (if I may have one) is that we not introduce big
> hurdles to kernel developers adding documentation.
>
> I'm not saying that this is a big hurdle.. I haven't looked at it enough
> yet.

I suggest you look at the series starting at [1] instead. We're looking
to *remove* hurdles in the process.

BR,
Jani.


[1] http://mid.gmane.org/cover.1465031816.git.jani.nik...@intel.com


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-wired-lan] [RFC PATCH net] e1000e: keep vlan interfaces functional after rxvlan off

[Jarod Wilson]

On Thu, Jun 09, 2016 at 06:17:45PM -0400, Jarod Wilson wrote:
> On Thu, Jun 09, 2016 at 04:55:01PM -0400, Jarod Wilson wrote:
> > On Thu, Jun 09, 2016 at 02:02:04PM -0400, Jarod Wilson wrote:
> > > On Wed, Jun 01, 2016 at 03:31:46PM -0700, Alexander Duyck wrote:
> > > > On Wed, Jun 1, 2016 at 12:27 PM, Jarod Wilson  wrote:
> > > > > On Wed, Jun 01, 2016 at 07:31:53AM -0700, Alexander Duyck wrote:
> > > > >> On Tue, May 17, 2016 at 12:03 PM, Jarod Wilson  
> > > > >> wrote:
> > > > >> > I've got a bug report about an e1000e interface, where a vlan 
> > > > >> > interface is
> > > > >> > set up on top of it:
> > > > >> >
> > > > >> > $ ip link add link ens1f0 name ens1f0.99 type vlan id 99
> > > > >> > $ ip link set ens1f0 up
> > > > >> > $ ip link set ens1f0.99 up
> > > > >> > $ ip addr add 192.168.99.92 dev ens1f0.99
> > > > >> >
> > > > >> > At this point, I can ping another host on vlan 99, ip 
> > > > >> > 192.168.99.91.
> > > > >> > However, if I do the following:
> > > > >> >
> > > > >> > $ ethtool -K ens1f0 rxvlan off
> > > > >> >
> > > > >> > Then no traffic passes on ens1f0.99. It comes back if I toggle 
> > > > >> > rxvlan on
> > > > >> > again. I'm not sure if this is actually intended behavior, or if 
> > > > >> > there's a
> > > > >> > lack of software vlan stripping fallback, or what, but things 
> > > > >> > continue to
> > > > >> > work if I simply don't call e1000e_vlan_strip_disable() if there 
> > > > >> > are
> > > > >> > active vlans (plagiarizing a function from the e1000 driver here) 
> > > > >> > on the
> > > > >> > interface.
...
> > Okay, so rxvlan is *supposed* to only impact the rx path, right? It's
> > looking like it is actually impacting the tx path too here. I actually
> > *do* see calls to skb_vlan_untag with rxvlan off, if I ping from an
> > external host, so it seems only the packets from the host with rxvlan
> > toggled off aren't escaping correctly for some reason.
> 
> And this leads me to believe maybe the bit in the e1000 driver that
> mentions explicitly that the hardware has no support for separate RX/TX
> vlan accel toggling rings true for e1000e as well, and thus both
> NETIF_F_HW_VLAN_CTAG_RX and NETIF_F_HW_VLAN_CTAG_TX need to be kept in
> sync. Testing this theory out shortly...

We have a winner. If I make sure the TX flag gets toggled too, ping
continues to work after disabling rxvlan.

$ ping 192.168.99.91
PING 192.168.99.91 (192.168.99.91) 56(84) bytes of data.
64 bytes from 192.168.99.91: icmp_seq=1 ttl=64 time=0.591 ms
64 bytes from 192.168.99.91: icmp_seq=2 ttl=64 time=0.335 ms
64 bytes from 192.168.99.91: icmp_seq=3 ttl=64 time=0.417 ms
^C
--- 192.168.99.91 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.335/0.447/0.591/0.109 ms

$ sudo ethtool -K ens1f0 rxvlan off
Actual changes:
rx-vlan-offload: off
tx-vlan-offload: off [requested on]

$ ping 192.168.99.91
PING 192.168.99.91 (192.168.99.91) 56(84) bytes of data.
64 bytes from 192.168.99.91: icmp_seq=1 ttl=64 time=0.327 ms
64 bytes from 192.168.99.91: icmp_seq=2 ttl=64 time=0.393 ms
64 bytes from 192.168.99.91: icmp_seq=3 ttl=64 time=0.424 ms
^C
--- 192.168.99.91 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.327/0.381/0.424/0.043 ms

I'll clean things up and submit a patch tonight or tomorrow.

-- 
Jarod Wilson
ja...@redhat.com

Re: [PATCH v2 0/3] Introduce the latent_entropy gcc plugin

[Emese Revfy]

On Thu, 9 Jun 2016 14:18:08 -0700
Kees Cook  wrote:

> By the way, as you work on v3, can you also be sure to put your
> patches through scripts/checkpatch.pl? There are a lot of >80
> character lines, and other nits. I'd like to minimize the warnings.

I only split those lines where the split doesn't make the code worse.
I checked it again and I made some changes:
https://github.com/ephox-gcc-plugins/latent_entropy/commit/e8e7c885b49db16903ea5bd4d6318ce1246f85f3

-- 
Emese

Re: [PATCHv3 0/2] target: make location of /var/targets configurable

[Lee Duncan]

Ping?

We really need to move the target database out of /var/target

On 04/14/2016 06:18 PM, Lee Duncan wrote:
> These patches make the location of "/var/target" configurable,
> though it still defauls to "/var/target".
> 
> This "target database directory" can only be changed
> after the target_core_mod loads but before any
> fabric drivers are loaded, and must be the pathname
> of an existing directory.
> 
> This configuration is accomplished via the configfs
> top-level target attribute "dbroot", i.e. dumping
> out "/sys/kernel/config/target/dbroot" will normally
> return "/var/target". Writing to this attribute
> changes the loation where the kernel looks for the
> target database.
> 
> The first patch creates this configurable value for
> the "dbroot", and the second patch modifies users
> of this directory to use this new attribute.
> 
> Changes from v2:
>  * Add locking around access to target driver list
> 
> Changes from v1:
>  * Only allow changing target DB root before it
>can be used by others
>  * Validate that new DB root is a valid directory
> 
> Lee Duncan (2):
>   target: make target db location configurable
>   target: use new "dbroot" target attribute
> 
>  drivers/target/target_core_alua.c |  6 ++--
>  drivers/target/target_core_configfs.c | 62 
> +++
>  drivers/target/target_core_internal.h |  6 
>  drivers/target/target_core_pr.c   |  2 +-
>  4 files changed, 72 insertions(+), 4 deletions(-)
> 

-- 
Lee Duncan
SUSE Labs

Re: [tip:x86/urgent] x86/quirks: Add early quirk to reset Apple AirPort card

[Yinghai Lu]

On 6/9/16, Lukas Wunner  wrote:
>
> Well, the PCI core would also scan such a bus twice AFAICS.
> And the performance penalty of scanning it twice seems negligible.
> Early quirks can prevent double execution by setting QFLAG_APPLY_ONCE.
> (Three quirks have set that flag already.)
>
> So I think this shouldn't be a concern.

I don't know. I would like see sth like following, and that is simple enough.

Index: linux-2.6/arch/x86/kernel/early-quirks.c
===
--- linux-2.6.orig/arch/x86/kernel/early-quirks.c
+++ linux-2.6/arch/x86/kernel/early-quirks.c
@@ -755,10 +755,16 @@ static int __init check_dev_quirk(int nu
return 0;
 }

+static unsigned char __initdata scanned[256];
 static void __init early_pci_scan_bus(int bus)
 {
int slot, func;

+   if (scanned[bus])
+   return;
+
+   scanned[bus] = 1;
+
/* Poor man's PCI discovery */
for (slot = 0; slot < 32; slot++)
for (func = 0; func < 8; func++) {

Re: [PATCH v2 4/6] drm/panel: simple: Add support for Samsung LSN122DL01-C01 2560x1600 panel

[Stéphane Marchesin]

On Wed, Jun 8, 2016 at 4:52 AM, Yakir Yang  wrote:
> The Samsung LSN122DL01-C01 is an 12.2" 2560x1600 (WQXGA) TFT-LCD panel
> connected using eDP interfaces.
>
> Signed-off-by: Yakir Yang 
> ---
> Changes in v2: None
>
>  drivers/gpu/drm/panel/panel-simple.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 41020e1..067a5c4 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1246,6 +1246,28 @@ static const struct panel_desc qd43003c0_40 = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
>  };
>
> +static const struct drm_display_mode samsung_lsn122dl01_c01_mode = {
> +   .clock = 271560,
> +   .hdisplay = 2560,
> +   .hsync_start = 2560 + 48,
> +   .hsync_end = 2560 + 48 + 32,
> +   .htotal = 2560 + 48 + 32 + 80,
> +   .vdisplay = 1600,
> +   .vsync_start = 1600 + 2,
> +   .vsync_end = 1600 + 2 + 5,
> +   .vtotal = 1600 + 2 + 5 + 57,
> +   .vrefresh = 60,
> +};
> +
> +static const struct panel_desc samsung_lsn122dl01_c01 = {
> +   .modes = _lsn122dl01_c01_mode,
> +   .num_modes = 1,
> +   .size = {
> +   .width = 2560,
> +   .height = 1600,

These are meant to be the physical dimensions (same thing for the
other patches btw).

Stéphane

> +   },
> +};
> +
>  static const struct drm_display_mode samsung_ltn101nt05_mode = {
> .clock = 54030,
> .hdisplay = 1024,
> @@ -1506,6 +1528,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "qiaodian,qd43003c0-40",
> .data = _40,
> }, {
> +   .compatible = "samsung,lsn122dl01-c01",
> +   .data = _lsn122dl01_c01,
> +   }, {
> .compatible = "samsung,ltn101nt05",
> .data = _ltn101nt05,
> }, {
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] Power management fixes for v4.7-rc3

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.7-rc3

to receive power management fixes for v4.7-rc3 with top-most commit
3681196ae568f97d534537c1c1102f4707ca11f9

 Merge branches 'pm-cpufreq-fixes' and 'pm-cpuidle'

on top of commit af8c34ce6ae32addda3788d54a7e340cad22516b

 Linux 4.7-rc2

Stable-candidate fixes for the intel_pstate driver and the
cpuidle core.

Specifics:

 - Fix two intel_pstate initialization issues, one of which was
   introduced during the 4.4 cycle (Srinivas Pandruvada).

 - Fix kernel build with CONFIG_UBSAN set and CONFIG_CPU_IDLE
   unset (Catalin Marinas).

Thanks!

---

Catalin Marinas (1):
  cpuidle: Do not access cpuidle_devices when !CONFIG_CPU_IDLE

Srinivas Pandruvada (2):
  cpufreq: intel_pstate: Fix code ordering in intel_pstate_set_policy()
  cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo

---

 drivers/cpufreq/intel_pstate.c | 12 +---
 include/linux/cpuidle.h|  3 +++
 kernel/sched/idle.c|  2 +-
 3 files changed, 13 insertions(+), 4 deletions(-)

Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps

[Steve Grubb]

On Thursday, June 09, 2016 07:59:43 PM Richard Guy Briggs wrote:
> On 16/06/09, Steve Grubb wrote:
> > On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
> > > struct timespec is not y2038 safe.
> > > Audit timestamps are recorded in string format into
> > > an audit buffer for a given context.
> > > These mark the entry timestamps for the syscalls.
> > > Use y2038 safe struct timespec64 to represent the times.
> > > The log strings can handle this transition as strings can
> > > hold upto 1024 characters.
> > 
> > Have you tested this with ausearch or any audit utilities? As an aside, a
> > time stamp that is up to 1024 characters long is terribly wasteful
> > considering how many events we get.
> 
> Steve,
> 
> I don't expect the size of the time stamp text to change since the
> format isn't being changed and I don't expect the date stamp text length
> to change until Y10K, but you never know what will happen in 8
> millenia...  (Who knows, maybe that damn Linux server in my basement
> will still be running then...)
> 
> Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)?

Bytes, yes. But I was thinking that if its going to get big we should consider 
switching from a base 10 representation to base 16. That would give us back a 
few bytes. We discuss this on the linux-audit list rather than the main list.

-Steve

Re: [PATCH trivial] include/linux/memcontrol.h: Clean up code only

[Chen Gang]

On 6/10/16 01:39, Rik van Riel wrote:
> On Thu, 2016-06-09 at 23:23 +0800, cheng...@emindsoft.com.cn wrote:
>> From: Chen Gang 
>>
>> Merge several statements to one return statement, since the new
>> return
>> statement is still simple enough.
> 
> This code is not simple, and any change that
> makes it harder to read needs a good reason.
> 
> At least in my opinion, your return statement
> merging thing makes the code harder to read.
>

For me, every member has his/her own taste, we need talk about it case
by case.

[...]
 
>>  
>>  static inline unsigned short mem_cgroup_id(struct mem_cgroup *memcg)
>>  {
>> -if (mem_cgroup_disabled())
>> -return 0;
>> -
>> -return memcg->css.id;
>> +return mem_cgroup_disabled() ? 0 : memcg->css.id;
>>  }
>>  

For me, this is the simplest way for using "? :", so it is easy enough (
I guess, Linux kernel does not completely reject "? :").

>>  /**
>> @@ -341,10 +338,7 @@ static inline unsigned short
>> mem_cgroup_id(struct mem_cgroup *memcg)
>>   */
>>  static inline struct mem_cgroup *mem_cgroup_from_id(unsigned short
>> id)
>>  {
>> -struct cgroup_subsys_state *css;
>> -
>> -css = css_from_id(id, _cgrp_subsys);
>> -return mem_cgroup_from_css(css);
>> +return mem_cgroup_from_css(css_from_id(id, _cgrp_subsys));
>>  }
>>  

For me, this case may depend on various members' tastes (although it is
simple enough to me -- it is in one line within 80 columns, and related
with 2 functions' call).

For this case, if any of another member suggests to keep original code
no touch, too, I shall send patch v2 for it (keep it no touch).

>>  /**
>> @@ -390,9 +384,7 @@ ino_t page_cgroup_ino(struct page *page);
>>  
>>  static inline bool mem_cgroup_online(struct mem_cgroup *memcg)
>>  {
>> -if (mem_cgroup_disabled())
>> -return true;
>> -return !!(memcg->css.flags & CSS_ONLINE);
>> +return mem_cgroup_disabled() || (memcg->css.flags & CSS_ONLINE);
>>  }
>>  

For me, this is almost the simplest way for using "||", we can find
this case in include/linux (60+ cases for '||', and 150+ for '&&'), and
the new return statement is in one line within 80 columns.

The new return statement is not the simplest, but it is still simple
enough (which should be better than original several lines statements).


Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.

Re: [PATCH v2 4/9] arm64: Add platform selection for BCM2835.

[Eric Anholt]

Catalin Marinas  writes:

> On Sat, Jun 04, 2016 at 12:55:15PM -0700, Eric Anholt wrote:
>> Catalin Marinas  writes:
>> > On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote:
>> >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> >> index 7ef1d05..ea88402 100644
>> >> --- a/arch/arm64/Kconfig.platforms
>> >> +++ b/arch/arm64/Kconfig.platforms
>> >> @@ -13,6 +13,19 @@ config ARCH_ALPINE
>> >> This enables support for the Annapurna Labs Alpine
>> >> Soc family.
>> >>  
>> >> +config ARCH_BCM2835
>> >> + bool "Broadcom BCM2835 family"
>> >> + select ARCH_REQUIRE_GPIOLIB
>> >> + select CLKSRC_OF
>> >> + select PINCTRL
>> >> + select PINCTRL_BCM2835
>> >> + select ARM_AMBA
>> >> + select ARM_TIMER_SP804
>> >> + select HAVE_ARM_ARCH_TIMER
>> >> + help
>> >> +   This enables support for the Broadcom BCM2837 SoC.
>
> Even the BCM number is inconsistent here.

Well, given the past chip numbers, we could call the family's Kconfig
ARCH_BCM283X, and for now arm64 would only do the 2837 in the family.
Back when I was doing 2836, other maintainers agreed that renaming all
of the ARCH_BCM2835 in the tree to BCM283X was pointless thrashing.

>> >> +   This SoC is used in the Raspberry Pi 3 device.
>> >
>> > I thought we would just use ARCH_BCM, or is it too generic?
>> 
>> Consensus last time around seemed to be to drop adding ARCH_BCM, in
>> favor of patch 1 of the series.
>
> I may have missed that discussion. My point was about consistency with
> existing ARCH_* definitions in the arm64 Kconfig.platforms. I can see
> why it's easier for you since some drivers are built based on
> ARCH_BCM2835. Looking at drivers/clk/bcm/Makefile, there is an
> inconsistent mix of CLK_BCM_* and ARCH_BCM_*. I would rather have a new
> CLK_BCM2835 that's selected/enabled accordingly (maybe simply depending
> on ARCH_BCM).

So I introduce a new ARCH_BCM here, that selects the just the 283x
family's core drivers?  That seems strange, but I'm willing if that's
what you want.


signature.asc
Description: PGP signature

[GIT PULL] ACPI fix for v4.7-rc3

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-4.7-rc3

to receive an ACPI update for v4.7-rc3 with top-most commit
bd6ac2abc9937eb7613aa194195fd98fe9312b38

 Merge branch 'acpi-ec'

on top of commit af8c34ce6ae32addda3788d54a7e340cad22516b

 Linux 4.7-rc2

A recently introduced boot regression related to the ACPI EC
initialization is addressed by restoring the previous behavior
(Lv Zheng).

Thanks!

---

Lv Zheng (1):
  ACPI / EC: Fix a boot EC regresion by restoring boot EC support
for the DSDT EC

---

 drivers/acpi/bus.c  |  2 +-
 drivers/acpi/ec.c   | 29 ++---
 drivers/acpi/internal.h |  2 +-
 3 files changed, 24 insertions(+), 9 deletions(-)

Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps

[Deepa Dinamani]

On Thu, Jun 9, 2016 at 7:31 AM, Steve Grubb  wrote:
> On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
>> Audit timestamps are recorded in string format into
>> an audit buffer for a given context.
>> These mark the entry timestamps for the syscalls.
>> Use y2038 safe struct timespec64 to represent the times.
>> The log strings can handle this transition as strings can
>> hold upto 1024 characters.
>
> Have you tested this with ausearch or any audit utilities? As an aside, a time
> stamp that is up to 1024 characters long is terribly wasteful considering how
> many events we get.

/* AUDIT_BUFSIZ is the size of the temporary buffer used for formatting
 * audit records.  Since printk uses a 1024 byte buffer, this buffer
 * should be at least that large. */
#define AUDIT_BUFSIZ 1024

The commit text is pointing out that the reserve space ensured in each
call to audit_log_vformat is already much more than is needed by this
call from audit_log_start.

Also, since struct timespec64 is already the same as struct timespec
on 64-bit systems, there is really no functional change except on
32-bit machines.

Let me know if you want me to try it out on a 32-bit system.

-Deepa

Re: [PATCH v3] powerpc: spinlock: Fix spin_unlock_wait()

[Michael Ellerman]

On Thu, 2016-06-09 at 19:50 +0200, Peter Zijlstra wrote:
> On Thu, Jun 09, 2016 at 10:23:28PM +1000, Michael Ellerman wrote:
> > Unfortunately the patch isn't 100%.
> 
> So what I'll do; since my patch is trying to ensure all implementations
> of spin_unlock_wait() provide ACQUIRE semantics, and this patch does
> indeed do so, is skip touching PPC entirely and hope this patch lands
> before 4.8.

OK.

I don't see any reason it wouldn't make 4.8, we just need to decide whether we
use the old "while (lock->slock)" or one of the other options Boqun proposed.

cheers

[PATCH] cpufreq: conservative: Do not use transition notifications

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The conservative governor registers a transition notifier so it
can update its internal requested_freq value if it falls out of the
policy->min...policy->max range, but that's not the most
straightforward way to achieve that.

To do it in a more straightforward way, first make sure that
cs_dbs_timer() will only set frequencies between min and max.

With that, note that requested_freq will always fall between min
and max unless either policy->min or policy->max changes and the
governor's ->limits() callback will be invoked then.

Using this observation, add a ->limits callback pointer to
struct dbs_governor, make cpufreq_dbs_governor_limits() invoke
that callback if present, implement that callback in the conservative
governor to update requested_freq if needed and drop the transition
notifier from it, which also makes it possible to drop the
struct cs_governor definition from there and simplify the code
accordingly.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/cpufreq_conservative.c |   85 +++--
 drivers/cpufreq/cpufreq_governor.c |4 +
 drivers/cpufreq/cpufreq_governor.h |1 
 3 files changed, 25 insertions(+), 65 deletions(-)

Index: linux-pm/drivers/cpufreq/cpufreq_conservative.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_conservative.c
+++ linux-pm/drivers/cpufreq/cpufreq_conservative.c
@@ -106,7 +106,8 @@ static unsigned int cs_dbs_timer(struct
goto out;
 
freq_target = get_freq_target(cs_tuners, policy);
-   if (dbs_info->requested_freq > freq_target)
+   if (dbs_info->requested_freq > freq_target
+   && dbs_info->requested_freq - freq_target > policy->min)
dbs_info->requested_freq -= freq_target;
else
dbs_info->requested_freq = policy->min;
@@ -119,13 +120,6 @@ static unsigned int cs_dbs_timer(struct
return dbs_data->sampling_rate;
 }
 
-static int dbs_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
-   void *data);
-
-static struct notifier_block cs_cpufreq_notifier_block = {
-   .notifier_call = dbs_cpufreq_notifier,
-};
-
 /** sysfs interface /
 
 static ssize_t store_sampling_down_factor(struct gov_attr_set *attr_set,
@@ -254,13 +248,6 @@ static struct attribute *cs_attributes[]
 
 /** sysfs end /
 
-struct cs_governor {
-   struct dbs_governor dbs_gov;
-   unsigned int usage_count;
-};
-
-static struct cs_governor cs_gov;
-
 static struct policy_dbs_info *cs_alloc(void)
 {
struct cs_policy_dbs_info *dbs_info;
@@ -294,25 +281,11 @@ static int cs_init(struct dbs_data *dbs_
dbs_data->min_sampling_rate = MIN_SAMPLING_RATE_RATIO *
jiffies_to_usecs(10);
 
-   /*
-* This function and cs_exit() are only called under gov_dbs_data_mutex
-* which is global, so the cs_gov.usage_count accesses are guaranteed
-* to be serialized.
-*/
-   if (!cs_gov.usage_count++)
-   cpufreq_register_notifier(_cpufreq_notifier_block,
- CPUFREQ_TRANSITION_NOTIFIER);
-
return 0;
 }
 
 static void cs_exit(struct dbs_data *dbs_data)
 {
-   /* Protected by gov_dbs_data_mutex - see the comment in cs_init(). */
-   if (!--cs_gov.usage_count)
-   cpufreq_unregister_notifier(_cpufreq_notifier_block,
-   CPUFREQ_TRANSITION_NOTIFIER);
-
kfree(dbs_data->tuners);
 }
 
@@ -324,47 +297,29 @@ static void cs_start(struct cpufreq_poli
dbs_info->requested_freq = policy->cur;
 }
 
-static struct cs_governor cs_gov = {
-   .dbs_gov = {
-   .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"),
-   .kobj_type = { .default_attrs = cs_attributes },
-   .gov_dbs_timer = cs_dbs_timer,
-   .alloc = cs_alloc,
-   .free = cs_free,
-   .init = cs_init,
-   .exit = cs_exit,
-   .start = cs_start,
-   },
-};
-
-#define CPU_FREQ_GOV_CONSERVATIVE  (_gov.dbs_gov.gov)
-
-static int dbs_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
-   void *data)
+static void cs_limits(struct cpufreq_policy *policy)
 {
-   struct cpufreq_freqs *freq = data;
-   struct cpufreq_policy *policy = cpufreq_cpu_get_raw(freq->cpu);
-   struct cs_policy_dbs_info *dbs_info;
-
-   if (!policy)
-   return 0;
-
-   /* policy isn't governed by conservative governor */
-   if (policy->governor != CPU_FREQ_GOV_CONSERVATIVE)
-   return 0;
+   struct cs_policy_dbs_info *dbs_info = 

Re: [PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading

[Rafael J. Wysocki]

On 5/20/2016 2:57 AM, Zheng, Lv wrote:

Hi, Rafael


From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of
Rafael J. Wysocki
Subject: Re: [PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table
loading

On Tue, May 17, 2016 at 2:29 AM, Zheng, Lv  wrote:

Hi, Rafael

Can we queue this up in linux-next?
ASLTS recursive tests are done in ACPICA upstream and no regressions can be

seen.

We need more tests around this experimental change from the real users to

have the chances to learn the unknown cases.

If they reported regressions, we could stop the regressions by reverting

[PATCH 4/4].

So it should be safe to do such experiments in the Linux upstream.
Thanks in advance.

There is a rule that during a merge window linux-next should only
contain material for that merge window.  That is, currently linux-next
should only contain material targeted at v4.7.

For this reason, I can't put the series into linux-next right now, but
I'll do that as soon as 4.7-rc1 is released.

[Lv Zheng]
Great!
Thanks for the information.


Unfortunately, it is reported that the series actually causes problems 
to happen.


I sent you a CC of my response to the report in question earlier today.

Thanks,
Rafael

Re: [PATCH] mmc: dw_mmc: remove UBSAN warning in dw_mci_setup_bus()

[Seung-Woo Kim]

Hi Jaehoon,

On 2016년 06월 09일 21:38, Jaehoon Chung wrote:
> Hi Seung-Woo,
> 
> On 06/08/2016 01:07 PM, Seung-Woo Kim wrote:
>> This patch removes following UBSAN warnings in dw_mci_setup_bus().
>> The warnings are caused because of shift with more than 31 on 32
>> bit variable, so this patch fixes to shift only for less than 32.
>>
>>   UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1102:14
>>   shift exponent 250 is too large for 32-bit type 'unsigned int'
>>   Call trace:
>>   [] dump_backtrace+0x0/0x380
>>   [] show_stack+0x14/0x20
>>   [] dump_stack+0xe0/0x120
>>   [] ubsan_epilogue+0x18/0x68
>>   [] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc
>>   [] dw_mci_setup_bus+0x3a0/0x438
>>   [...]
>>
>>   UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1132:27
>>   shift exponent 250 is too large for 32-bit type 'unsigned int'
>>   Call trace:
>>   [] dump_backtrace+0x0/0x380
>>   [] show_stack+0x14/0x20
>>   [] dump_stack+0xe0/0x120
>>   [] ubsan_epilogue+0x18/0x68
>>   [] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc
>>   [] dw_mci_setup_bus+0x384/0x438
> 
> The below message can be discarded.

You are right, like above message, below part can be replaced as [...].

> 
>>   [] dw_mci_set_ios+0x184/0x798
>>   [] mmc_power_up+0x11c/0x260
>>   [] mmc_start_host+0x88/0x100
>>   [] mmc_add_host+0x6c/0x128
>>   [] dw_mci_probe+0x1088/0x1750
>>   [] dw_mci_pltfm_register+0x108/0x178
>>   [] dw_mci_exynos_probe+0x4c/0x88
>>   [] platform_drv_probe+0x78/0x180
>>   [] driver_probe_device+0x144/0x460
>>   [] __driver_attach+0xf4/0x140
>>   [] bus_for_each_dev+0xf0/0x160
>>   [] driver_attach+0x34/0x58
>>   [] bus_add_driver+0x2c0/0x398
>>   [] driver_register+0xbc/0x1e0
>>   [] __platform_driver_register+0x84/0xa8
>>   [] dw_mci_exynos_pltfm_driver_init+0x18/0x20
>>   [] do_one_initcall+0xa0/0x2c8
>>   [] kernel_init_freeable+0x52c/0x5dc
>>   [] kernel_init+0x1c/0xf8
>>   [] ret_from_fork+0x10/0x40
>>
>> Signed-off-by: Seung-Woo Kim 
>> ---
>>  drivers/mmc/host/dw_mmc.c |5 +++--
>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 2cc6123..dff045e 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1099,7 +1099,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, 
>> bool force_clkinit)
>>  
>>  div = (host->bus_hz != clock) ? DIV_ROUND_UP(div, 2) : 0;
>>  
>> -if ((clock << div) != slot->__clk_old || force_clkinit)
>> +if (((div < 32) ? (clock << div) : 0) != slot->__clk_old ||
> 
> Well, we don't expect that clock is 0.
> if clock is 0, it should be passed to " if (!clock)"..
> 
> During initializing card, clock is 400KHz or less..I understood what you want 
> to fix.
> But I taught this is not correct.

It seems slot->__clk_old is not really clock but a kind of value to
store both clock and div in one variable. And at least, my compiler
calculates right shift with more than 32 as 0. I am not sure there is
other proper value for the case.

By the way, in my test environment, clock is calculated as like
following steps:
mmc_host mmc0: Bus speed (slot 0) = 2Hz (slot req 40Hz,
actual 40HZ div = 250)
mmc_host mmc0: Bus speed (slot 0) = 2Hz (slot req 2Hz,
actual 2HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 2Hz (slot req 5200Hz,
actual 5000HZ div = 2)
mmc_host mmc0: Bus speed (slot 0) = 4Hz (slot req 5200Hz,
actual 5000HZ div = 4)
mmc_host mmc0: Bus speed (slot 0) = 4Hz (slot req 2Hz,
actual 2HZ div = 1)

and only the first case is reported as the warning. If you let me know
any proper value, then I will fix with the value.

Thanks,
- Seung-Woo Kim


> 
> 
>> +force_clkinit)
>>  dev_info(>mmc->class_dev,
>>   "Bus speed (slot %d) = %dHz (slot req %dHz, 
>> actual %dHZ div = %d)\n",
>>   slot->id, host->bus_hz, clock,
>> @@ -1129,7 +1130,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, 
>> bool force_clkinit)
>>  mci_send_cmd(slot, sdmmc_cmd_bits, 0);
>>  
>>  /* keep the clock with reflecting clock dividor */
>> -slot->__clk_old = clock << div;
>> +slot->__clk_old = (div < 32) ? (clock << div) : 0;
> 
> Also, clock is not 0..
> 
> 
> Best Regards,
> Jaehoon Chung
> 
>>  }
>>  
>>  host->current_speed = clock;
>>
> 
> 
> 

-- 
Seung-Woo Kim
Samsung Software R Center
--

Re: [PATCH 3/3] power_supply: bq27xxx_battery: Group register mappings into one table

[Sebastian Reichel]

Hi,

On Tue, May 31, 2016 at 01:45:00PM -0500, Andrew F. Davis wrote:
> Currently for each device with a unique register map we have a named
> array that we then merge into a multidimensional array. Skip this
> middle step and apply the register arrays directly to the multi-array.

I applied the first two patches, but the third (this one) does not
compile for me:

  CC [M]  drivers/power/bq27xxx_battery.o
drivers/power/bq27xxx_battery.c:108:2: warning: braces around scalar initializer
  [BQ27000] = {
  ^
drivers/power/bq27xxx_battery.c:108:2: note: (near initialization for 
‘bq27xxx_regs[1]’)
drivers/power/bq27xxx_battery.c:109:4: error: array index in non-array 
initializer
   [BQ27XXX_REG_CTRL] = 0x00,
^
drivers/power/bq27xxx_battery.c:109:4: note: (near initialization for 
‘bq27xxx_regs[1]’)
drivers/power/bq27xxx_battery.c:110:4: error: array index in non-array 
initializer
   [BQ27XXX_REG_TEMP] = 0x06,
^
...

-- Sebastian


signature.asc
Description: PGP signature

[PATCH net-next] netvsc: Use the new in-place consumption APIs in the rx path

[K. Y. Srinivasan]

Use the new APIs for eliminating a copy on the receive path. These new APIs also
help in minimizing the number of memory barriers we end up issuing (in the
ringbuffer code) since we can better control when we want to expose the ring
state to the host.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
Tested-by: Dexuan Cui 
Tested-by: Simon Xiao 
---
 drivers/net/hyperv/netvsc.c |   88 +--
 1 files changed, 59 insertions(+), 29 deletions(-)

diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 719cb35..8cd4c19 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -1141,6 +1141,39 @@ static inline void netvsc_receive_inband(struct 
hv_device *hdev,
}
 }
 
+static void netvsc_process_raw_pkt(struct hv_device *device,
+  struct vmbus_channel *channel,
+  struct netvsc_device *net_device,
+  struct net_device *ndev,
+  u64 request_id,
+  struct vmpacket_descriptor *desc)
+{
+   struct nvsp_message *nvmsg;
+
+   nvmsg = (struct nvsp_message *)((unsigned long)
+   desc + (desc->offset8 << 3));
+
+   switch (desc->type) {
+   case VM_PKT_COMP:
+   netvsc_send_completion(net_device, channel, device, desc);
+   break;
+
+   case VM_PKT_DATA_USING_XFER_PAGES:
+   netvsc_receive(net_device, channel, device, desc);
+   break;
+
+   case VM_PKT_DATA_INBAND:
+   netvsc_receive_inband(device, net_device, nvmsg);
+   break;
+
+   default:
+   netdev_err(ndev, "unhandled packet type %d, tid %llx\n",
+  desc->type, request_id);
+   break;
+   }
+}
+
+
 void netvsc_channel_cb(void *context)
 {
int ret;
@@ -1153,7 +1186,7 @@ void netvsc_channel_cb(void *context)
unsigned char *buffer;
int bufferlen = NETVSC_PACKET_SIZE;
struct net_device *ndev;
-   struct nvsp_message *nvmsg;
+   bool need_to_commit = false;
 
if (channel->primary_channel != NULL)
device = channel->primary_channel->device_obj;
@@ -1167,39 +1200,36 @@ void netvsc_channel_cb(void *context)
buffer = get_per_channel_state(channel);
 
do {
+   desc = get_next_pkt_raw(channel);
+   if (desc != NULL) {
+   netvsc_process_raw_pkt(device,
+  channel,
+  net_device,
+  ndev,
+  desc->trans_id,
+  desc);
+
+   put_pkt_raw(channel, desc);
+   need_to_commit = true;
+   continue;
+   }
+   if (need_to_commit) {
+   need_to_commit = false;
+   commit_rd_index(channel);
+   }
+
ret = vmbus_recvpacket_raw(channel, buffer, bufferlen,
   _recvd, _id);
if (ret == 0) {
if (bytes_recvd > 0) {
desc = (struct vmpacket_descriptor *)buffer;
-   nvmsg = (struct nvsp_message *)((unsigned long)
-desc + (desc->offset8 << 3));
-   switch (desc->type) {
-   case VM_PKT_COMP:
-   netvsc_send_completion(net_device,
-   channel,
-   device, desc);
-   break;
-
-   case VM_PKT_DATA_USING_XFER_PAGES:
-   netvsc_receive(net_device, channel,
-  device, desc);
-   break;
-
-   case VM_PKT_DATA_INBAND:
-   netvsc_receive_inband(device,
- net_device,
- nvmsg);
-   break;
-
-   default:
-   netdev_err(ndev,
-  "unhandled packet type %d, "
-  "tid %llx len %d\n",
-  desc->type, request_id,
-

Re: [PATCH v2 1/9] pinctrl: walk into bcm subdir unconditionally

[Eric Anholt]

Linus Walleij  writes:

> On Fri, Jun 3, 2016 at 8:18 AM, Gerd Hoffmann  wrote:
>
>> There is no ARCH_BCM on arm64, and we need pinctrl-bcm2835 for the rpi3.
>>
>> Signed-off-by: Gerd Hoffmann 
>> ---
>>  drivers/pinctrl/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
>> index e4bc115..88586c0 100644
>> --- a/drivers/pinctrl/Makefile
>> +++ b/drivers/pinctrl/Makefile
>> @@ -35,7 +35,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
>>  obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
>>  obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
>>
>> -obj-$(CONFIG_ARCH_BCM) += bcm/
>> +obj-y  += bcm/
>
> Looks OK to me, but would like Stephen's or Eric's ACK?

It looks like this is the only instance of filtering the directory on
CONFIG_ARCH_BCM, so regardless of the patch 4 resolution,

Acked-by: Eric Anholt 


signature.asc
Description: PGP signature

RE: [PATCH net-next] netvsc: Use the new in-place consumption APIs in the rx path

[KY Srinivasan]

> -Original Message-
> From: Linus Torvalds [mailto:torva...@linux-foundation.org]
> Sent: Thursday, June 9, 2016 5:12 PM
> To: KY Srinivasan 
> Cc: da...@davemloft.net; net...@vger.kernel.org; lkml  ker...@vger.kernel.org>; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com;
> leann.ogasaw...@canonical.com
> Subject: Re: [PATCH net-next] netvsc: Use the new in-place consumption APIs in
> the rx path
> 
> Srinivasan,
> 
>  these are all sent through linuxonhyperv.com, and fail DMARC because
> they have a microsoft.com address but no valid DKIM.
> 
> Please fix your email setup.  You need to go through the real
> microsoft smtp servers if you use a microsoft.com address. Or you need
> to get linuxonhyperv.com fixed as a smtp server with the proper MS
> email signing.
> 
>Linus

Thanks Linus, we will fix our email setup.

Regards,

K. Y
> 
> On Thu, Jun 9, 2016 at 6:34 PM, K. Y. Srinivasan  wrote:
> > Use the new APIs for eliminating a copy on the receive path. These new APIs
> also
> > help in minimizing the number of memory barriers we end up issuing (in the
> > ringbuffer code) since we can better control when we want to expose the ring
> > state to the host.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > Reviewed-by: Haiyang Zhang 
> > Tested-by: Dexuan Cui 
> > Tested-by: Simon Xiao 
> > ---
> >  drivers/net/hyperv/netvsc.c |   88 +-
> -
> >  1 files changed, 59 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> > index 719cb35..8cd4c19 100644
> > --- a/drivers/net/hyperv/netvsc.c
> > +++ b/drivers/net/hyperv/netvsc.c
> > @@ -1141,6 +1141,39 @@ static inline void netvsc_receive_inband(struct
> hv_device *hdev,
> > }
> >  }
> >
> > +static void netvsc_process_raw_pkt(struct hv_device *device,
> > +  struct vmbus_channel *channel,
> > +  struct netvsc_device *net_device,
> > +  struct net_device *ndev,
> > +  u64 request_id,
> > +  struct vmpacket_descriptor *desc)
> > +{
> > +   struct nvsp_message *nvmsg;
> > +
> > +   nvmsg = (struct nvsp_message *)((unsigned long)
> > +   desc + (desc->offset8 << 3));
> > +
> > +   switch (desc->type) {
> > +   case VM_PKT_COMP:
> > +   netvsc_send_completion(net_device, channel, device, desc);
> > +   break;
> > +
> > +   case VM_PKT_DATA_USING_XFER_PAGES:
> > +   netvsc_receive(net_device, channel, device, desc);
> > +   break;
> > +
> > +   case VM_PKT_DATA_INBAND:
> > +   netvsc_receive_inband(device, net_device, nvmsg);
> > +   break;
> > +
> > +   default:
> > +   netdev_err(ndev, "unhandled packet type %d, tid %llx\n",
> > +  desc->type, request_id);
> > +   break;
> > +   }
> > +}
> > +
> > +
> >  void netvsc_channel_cb(void *context)
> >  {
> > int ret;
> > @@ -1153,7 +1186,7 @@ void netvsc_channel_cb(void *context)
> > unsigned char *buffer;
> > int bufferlen = NETVSC_PACKET_SIZE;
> > struct net_device *ndev;
> > -   struct nvsp_message *nvmsg;
> > +   bool need_to_commit = false;
> >
> > if (channel->primary_channel != NULL)
> > device = channel->primary_channel->device_obj;
> > @@ -1167,39 +1200,36 @@ void netvsc_channel_cb(void *context)
> > buffer = get_per_channel_state(channel);
> >
> > do {
> > +   desc = get_next_pkt_raw(channel);
> > +   if (desc != NULL) {
> > +   netvsc_process_raw_pkt(device,
> > +  channel,
> > +  net_device,
> > +  ndev,
> > +  desc->trans_id,
> > +  desc);
> > +
> > +   put_pkt_raw(channel, desc);
> > +   need_to_commit = true;
> > +   continue;
> > +   }
> > +   if (need_to_commit) {
> > +   need_to_commit = false;
> > +   commit_rd_index(channel);
> > +   }
> > +
> > ret = vmbus_recvpacket_raw(channel, buffer, bufferlen,
> >_recvd, _id);
> > if (ret == 0) {
> > if (bytes_recvd > 0) {
> > desc = (struct vmpacket_descriptor *)buffer;
> > -   nvmsg = (struct nvsp_message *)((unsigned 
> > 

Re: [PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

[Javier Martinez Canillas]

Hello Inki,

On Thu, Jun 9, 2016 at 6:35 PM, Inki Dae  wrote:

[snip]

>> I know that removing .trg_type is enough but I also removed those lines
>> because the fields are not used if .trg_type != I80_HW_TRG. So there is
>> no point to leave a set for unused fields.
>>
>> We can latter add those one HW trigger support is fixed for Exynos5420.
>>
>
> As of now, I can merge it but I think it would be not reasonable solution 
> because potential problem still exists even we use SW trigger mode in default 
> - ie., in case of using HW trigger mode at bootloader, same problem would 
> happen as long as we don't support PSR mode support.
>

Yes, I understand that the problem will show again if the bootloader
uses HW trigger mode and that we need proper Panel Self Refresh
support but I think that's a separate issue. That's why I said that
those can be addressed for v4.8 but revert to SW trigger for v4.7 as a
short term fix for the regression.

In other words, enabling HW trigger mode breaks the display for the
Exynos5420 and Exynos5800 Peach Pi Chromebooks with the shipped
bootloaders (which are probably the most popular Exynos5 devices with
display and mainline support so is likely to affect users).

Best regards,
Javier

Re: [PATCH 2/4] ASoC: sunxi: Add Allwinner A10 Digital Audio driver

[Mark Brown]

On Thu, Jun 09, 2016 at 11:05:15PM +0200, Maxime Ripard wrote:
> On Thu, Jun 02, 2016 at 11:26:51AM +0100, Mark Brown wrote:
> > > +static int sun4i_i2s_params_to_sr(struct snd_pcm_hw_params *params)
> > > +{
> > > + switch (params_width(params)) {
> > > + case 16:
> > > + return 0;
> > > + }
> > > +
> > > + return -EINVAL;
> > > +}

> > The switch statement here and in the _wss() function look weird because
> > they don't have default cases.  Since there's only one user of both
> > functions it seems better to have the switch statements inline anyway.

> I don't know, maybe it's just me, but I really find it cleaner that
> way, and the compiler will probably inline it anyway. If you insist,
> I'll change it though.

Yes, it's really not helping here.

> > > + for (i = 0; sun4i_i2s_mclk_div[i].div; i++) {
> > > + const struct sun4i_i2s_clk_div *mdiv = sun4i_i2s_mclk_div + i;

> > Why not just write these as normal array lookups?

> By normal, you mean using ARRAY_SIZE()?

array[index].

> > > +static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
> > > +{
> > > + struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);

> > > + /* Enable the whole hardware block */
> > > + regmap_write(i2s->regmap, SUN4I_I2S_CTRL_REG,
> > > +  SUN4I_I2S_CTRL_GL_EN);

> > Runtime PM?  It also seems like this is something that ought to be
> > covered in the suspend and resume callbacks.

> runtime_pm is supported, and uses the regmap cache to keep those
> changes.

No, my point is that I'd expect to see the block powered off on suspend.


signature.asc
Description: PGP signature

Re: NFS/d_splice_alias breakage

[Oleg Drokin]

On Jun 6, 2016, at 7:36 PM, Oleg Drokin wrote:

> Well, I have some bad news.
> 
> This patch does not fix the issue 100% of the time apparently, I just hit it 
> again.

Ok, so now finally a piece of good news.
Whatever was causing this other much harder to hit crash is gone in -rc2, gone 
are
some other disturbing things I saw.

Hopefully this patch will get propagated everywhere soonish.

[PATCH 4.2.y-ckt 184/206] MIPS: BMIPS: BMIPS5000 has I cache filing from D cache

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Florian Fainelli 

commit c130d2fd3d59fbd5d269f7d5827bd4ed1d94aec6 upstream.

BMIPS5000 and BMIPS52000 processors have their I-cache filling from the
D-cache. Since BMIPS_GENERIC does not provide (yet) a
cpu-feature-overrides.h file, this was not set anywhere, so make sure
the R4K cache detection takes care of that.

Fixes: d74b0172e4e2c ("MIPS: BMIPS: Add special cache handling in c-r4k.c")
Signed-off-by: Florian Fainelli 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13010/
Signed-off-by: Ralf Baechle 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/mm/c-r4k.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index fbea443..b2c1685 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1305,6 +1305,10 @@ static void probe_pcache(void)
c->icache.flags |= MIPS_CACHE_IC_F_DC;
break;
 
+   case CPU_BMIPS5000:
+   c->icache.flags |= MIPS_CACHE_IC_F_DC;
+   break;
+
case CPU_LOONGSON2:
/*
 * LOONGSON2 has 4 way icache, but when using indexed cache op,
-- 
2.7.4

[PATCH 4.2.y-ckt 185/206] MIPS: BMIPS: Clear MIPS_CACHE_ALIASES earlier

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Florian Fainelli 

commit 73c4ca047f440c79f545bc6133e3033f754cd239 upstream.

BMIPS5000 and BMIPS5200 processor have no D cache aliases, and this is
properly handled by the per-CPU override added at the end of
r4k_cache_init(), the problem is that the output of probe_pcache()
disagrees with that, since this is too late:

Primary instruction cache 32kB, VIPT, 4-way, linesize 64 bytes.
Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes

With the change moved earlier, we now have a consistent output with the
settings we are intending to have:

Primary instruction cache 32kB, VIPT, 4-way, linesize 64 bytes.
Primary data cache 32kB, 4-way, VIPT, no aliases, linesize 32 bytes

Fixes: d74b0172e4e2c ("MIPS: BMIPS: Add special cache handling in c-r4k.c")
Signed-off-by: Florian Fainelli 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13011/
Signed-off-by: Ralf Baechle 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/mm/c-r4k.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index b2c1685..f22809f 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1307,6 +1307,8 @@ static void probe_pcache(void)
 
case CPU_BMIPS5000:
c->icache.flags |= MIPS_CACHE_IC_F_DC;
+   /* Cache aliases are handled in hardware; allow HIGHMEM */
+   c->dcache.flags &= ~MIPS_CACHE_ALIASES;
break;
 
case CPU_LOONGSON2:
@@ -1746,8 +1748,6 @@ void r4k_cache_init(void)
flush_icache_range = (void *)b5k_instruction_hazard;
local_flush_icache_range = (void *)b5k_instruction_hazard;
 
-   /* Cache aliases are handled in hardware; allow HIGHMEM */
-   current_cpu_data.dcache.flags &= ~MIPS_CACHE_ALIASES;
 
/* Optimization: an L2 flush implicitly flushes the L1 */
current_cpu_data.options |= MIPS_CPU_INCLUSIVE_CACHES;
-- 
2.7.4

[PATCH 4.2.y-ckt 183/206] powerpc/sstep: Fix sstep.c compile on powerpcspe

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Lennart Sorensen 

commit dd21731022faf43c1250050e5d28d11add599149 upstream.

Commit be96f63375a1 ("powerpc: Split out instruction analysis part of
emulate_step()") introduced ldarx and stdcx into the instructions in
sstep.c, which are not accepted by the assembler on powerpcspe, but does
seem to be accepted by the normal powerpc assembler even in 32 bit mode.

Wrap these two instructions in a __powerpc64__ check like it is
everywhere else in the file.

Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of 
emulate_step()")
Signed-off-by: Len Sorensen 
Signed-off-by: Michael Ellerman 
Signed-off-by: Kamal Mostafa 
---
 arch/powerpc/lib/sstep.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index dc885b3..6d34310 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1818,9 +1818,11 @@ int __kprobes emulate_step(struct pt_regs *regs, 
unsigned int instr)
case 4:
__get_user_asmx(val, op.ea, err, "lwarx");
break;
+#ifdef __powerpc64__
case 8:
__get_user_asmx(val, op.ea, err, "ldarx");
break;
+#endif
default:
return 0;
}
@@ -1841,9 +1843,11 @@ int __kprobes emulate_step(struct pt_regs *regs, 
unsigned int instr)
case 4:
__put_user_asmx(op.val, op.ea, err, "stwcx.", cr);
break;
+#ifdef __powerpc64__
case 8:
__put_user_asmx(op.val, op.ea, err, "stdcx.", cr);
break;
+#endif
default:
return 0;
}
-- 
2.7.4

[PATCH 4.2.y-ckt 182/206] perf tools: Fix perf regs mask generation

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: "Naveen N. Rao" 

commit f47822078dece7189cad0a5f472f148e5e916736 upstream.

On some architectures (powerpc in particular), the number of registers
exceeds what can be represented in an integer bitmask. Ensure we
generate the proper bitmask on such platforms.

Fixes: 71ad0f5e4 ("perf tools: Support for DWARF CFI unwinding on post 
processing")
Signed-off-by: Naveen N. Rao 
Acked-by: Arnaldo Carvalho de Melo 
Signed-off-by: Michael Ellerman 
Signed-off-by: Kamal Mostafa 
---
 tools/perf/util/perf_regs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/perf_regs.c b/tools/perf/util/perf_regs.c
index 43168fb..2fb6f2a 100644
--- a/tools/perf/util/perf_regs.c
+++ b/tools/perf/util/perf_regs.c
@@ -7,18 +7,18 @@ int perf_reg_value(u64 *valp, struct regs_dump *regs, int id)
int i, idx = 0;
u64 mask = regs->mask;
 
-   if (regs->cache_mask & (1 << id))
+   if (regs->cache_mask & (1ULL << id))
goto out;
 
-   if (!(mask & (1 << id)))
+   if (!(mask & (1ULL << id)))
return -EINVAL;
 
for (i = 0; i < id; i++) {
-   if (mask & (1 << i))
+   if (mask & (1ULL << i))
idx++;
}
 
-   regs->cache_mask |= (1 << id);
+   regs->cache_mask |= (1ULL << id);
regs->cache_regs[id] = regs->regs[idx];
 
 out:
-- 
2.7.4

[PATCH 4.2.y-ckt 178/206] MIPS: BMIPS: Fix PRID_IMP_BMIPS5000 masking for BMIPS5200

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Florian Fainelli 

commit cbbda6e7c9c3e4532bd70a73ff9d5e6655c894dc upstream.

BMIPS5000 have a PrID value of 0x5A00 and BMIPS5200 have a PrID value of
0x5B00, which, masked with 0x5A00, returns 0x5A00. Update all conditionals on
the PrID to cover both variants since we are going to need this to enable
BMIPS5200 SMP. The existing check, masking with 0xFF00 would not cover
BMIPS5200 at all.

Fixes: 68e6a78373a6d ("MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)")
Fixes: 6465460c92a85 ("MIPS: BMIPS: change compile time checks to runtime 
checks")
Signed-off-by: Florian Fainelli 
Cc: j...@phrozen.org
Cc: cerne...@gmail.com
Cc: j...@openwrt.org
Cc: jaedon.s...@gmail.com
Cc: jfra...@broadcom.com
Cc: pgynt...@google.com
Cc: dragan.stance...@gmail.com
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12279/
Signed-off-by: Ralf Baechle 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/kernel/bmips_vec.S | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/mips/kernel/bmips_vec.S b/arch/mips/kernel/bmips_vec.S
index 8649507..d9495f3 100644
--- a/arch/mips/kernel/bmips_vec.S
+++ b/arch/mips/kernel/bmips_vec.S
@@ -93,7 +93,8 @@ NESTED(bmips_reset_nmi_vec, PT_SIZE, sp)
 #if defined(CONFIG_CPU_BMIPS5000)
mfc0k0, CP0_PRID
li  k1, PRID_IMP_BMIPS5000
-   andik0, 0xff00
+   /* mask with PRID_IMP_BMIPS5000 to cover both variants */
+   andik0, PRID_IMP_BMIPS5000
bne k0, k1, 1f
 
/* if we're not on core 0, this must be the SMP boot signal */
@@ -166,10 +167,12 @@ bmips_smp_entry:
 2:
 #endif /* CONFIG_CPU_BMIPS4350 || CONFIG_CPU_BMIPS4380 */
 #if defined(CONFIG_CPU_BMIPS5000)
-   /* set exception vector base */
+   /* mask with PRID_IMP_BMIPS5000 to cover both variants */
li  k1, PRID_IMP_BMIPS5000
+   andik0, PRID_IMP_BMIPS5000
bne k0, k1, 3f
 
+   /* set exception vector base */
la  k0, ebase
lw  k0, 0(k0)
mtc0k0, $15, 1
@@ -263,6 +266,8 @@ LEAF(bmips_enable_xks01)
 #endif /* CONFIG_CPU_BMIPS4380 */
 #if defined(CONFIG_CPU_BMIPS5000)
li  t1, PRID_IMP_BMIPS5000
+   /* mask with PRID_IMP_BMIPS5000 to cover both variants */
+   andit2, PRID_IMP_BMIPS5000
bne t2, t1, 2f
 
mfc0t0, $22, 5
-- 
2.7.4

[PATCH 4.2.y-ckt 186/206] MIPS: BMIPS: local_r4k___flush_cache_all needs to blast S-cache

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Florian Fainelli 

commit f675843ddfdfdf467d08cc922201614a149e439e upstream.

local_r4k___flush_cache_all() is missing a special check for BMIPS5000
processors, we need to blast the S-cache, just like other MTI processors
since we have an inclusive cache. We also need an additional __sync() to
make sure this is completed.

Fixes: d74b0172e4e2c ("MIPS: BMIPS: Add special cache handling in c-r4k.c")
Signed-off-by: Florian Fainelli 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13012/
Signed-off-by: Ralf Baechle 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/mm/c-r4k.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index f22809f..a50011a 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -447,6 +447,11 @@ static inline void local_r4k___flush_cache_all(void * args)
r4k_blast_scache();
break;
 
+   case CPU_BMIPS5000:
+   r4k_blast_scache();
+   __sync();
+   break;
+
default:
r4k_blast_dcache();
r4k_blast_icache();
-- 
2.7.4

[PATCH 4.2.y-ckt 187/206] MIPS: BMIPS: Pretty print BMIPS5200 processor name

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Florian Fainelli 

commit 37808d62afcdc420d98875c4b514c178d56f6815 upstream.

Just to ease debugging of multiplatform kernel, make sure we print
"Broadcom BMIPS5200" for the BMIPS5200 implementation instead of
Broadcom BMIPS5000.

Fixes: 68e6a78373a6d ("MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)")
Signed-off-by: Florian Fainelli 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13014/
Signed-off-by: Ralf Baechle 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/kernel/cpu-probe.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index dbe0792..cbd4c43 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1248,7 +1248,10 @@ static inline void cpu_probe_broadcom(struct 
cpuinfo_mips *c, unsigned int cpu)
case PRID_IMP_BMIPS5000:
case PRID_IMP_BMIPS5200:
c->cputype = CPU_BMIPS5000;
-   __cpu_name[cpu] = "Broadcom BMIPS5000";
+   if ((c->processor_id & PRID_IMP_MASK) == PRID_IMP_BMIPS5200)
+   __cpu_name[cpu] = "Broadcom BMIPS5200";
+   else
+   __cpu_name[cpu] = "Broadcom BMIPS5000";
set_elf_platform(cpu, "bmips5000");
c->options |= MIPS_CPU_ULRI;
break;
-- 
2.7.4

[PATCH 4.2.y-ckt 192/206] IB/IWPM: Fix a potential skb leak

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Mark Bloch 

commit 5ed935e861a4cbf2158ad3386d6d26edd60d2658 upstream.

In case ibnl_put_msg fails in send_nlmsg_done,
the function returns with -ENOMEM without freeing.

This patch fixes this behavior.

Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space 
service")
Signed-off-by: Mark Bloch 
Reviewed-by: Leon Romanovsky 
Signed-off-by: Leon Romanovsky 
Reviewed-by: Steve Wise 
Signed-off-by: Doug Ledford 
Signed-off-by: Kamal Mostafa 
---
 drivers/infiniband/core/iwpm_util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/core/iwpm_util.c 
b/drivers/infiniband/core/iwpm_util.c
index 5fb089e..fb43a24 100644
--- a/drivers/infiniband/core/iwpm_util.c
+++ b/drivers/infiniband/core/iwpm_util.c
@@ -634,6 +634,7 @@ static int send_nlmsg_done(struct sk_buff *skb, u8 
nl_client, int iwpm_pid)
if (!(ibnl_put_msg(skb, , 0, 0, nl_client,
   RDMA_NL_IWPM_MAPINFO, NLM_F_MULTI))) {
pr_warn("%s Unable to put NLMSG_DONE\n", __func__);
+   dev_kfree_skb(skb);
return -ENOMEM;
}
nlh->nlmsg_type = NLMSG_DONE;
-- 
2.7.4

[PATCH 4.2.y-ckt 138/206] xen/events: Don't move disabled irqs

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Ross Lagerwall 

commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.

Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc->lock. Fix it by adding in a check for disabled
IRQs.

The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode:  [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: 88003d75ee00 ti: 88003d7bc000 task.ti: 88003d7bc000
RIP: 0010:[]  [] 
irq_move_masked_irq+0xd2/0xe0
RSP: 0018:88003d7bfc50  EFLAGS: 00010046
RAX:  RBX: 88003d40ba00 RCX: 0001
RDX: 0001 RSI: 0100 RDI: 88003d40bad8
RBP: 88003d7bfc68 R08:  R09: 88003d00
R10:  R11: 023c R12: 88003d40bad0
R13: 81f3a4a0 R14: 0010 R15: 
FS:  () GS:88003da0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fd4264de624 CR3: 37922000 CR4: 003406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Stack:
 88003d40ba38 0024  88003d7bfca0
 814c8d92 0010813ef89d 805ea732 0009
 0024 88003cc39b80 88003d7bfce0 814c8f66
Call Trace:
 [] eoi_pirq+0xb2/0xf0
 [] __startup_pirq+0xe6/0x150
 [] xen_irq_resume+0x319/0x360
 [] xen_suspend+0xb5/0x180
 [] multi_cpu_stop+0xb5/0xe0
 [] ? cpu_stop_queue_work+0x80/0x80
 [] cpu_stopper_thread+0xb0/0x140
 [] ? finish_task_switch+0x76/0x220
 [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [] smpboot_thread_fn+0x105/0x160
 [] ? sort_range+0x30/0x30
 [] kthread+0xd8/0xf0
 [] ? kthread_create_on_node+0x1e0/0x1e0
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x1e0/0x1e0

Signed-off-by: Ross Lagerwall 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: David Vrabel 
Signed-off-by: Kamal Mostafa 
---
 drivers/xen/events/events_base.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index d90302e..89e801f 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -487,7 +487,8 @@ static void eoi_pirq(struct irq_data *data)
if (!VALID_EVTCHN(evtchn))
return;
 
-   if (unlikely(irqd_is_setaffinity_pending(data))) {
+   if (unlikely(irqd_is_setaffinity_pending(data)) &&
+   likely(!irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
 
clear_evtchn(evtchn);
@@ -1374,7 +1375,8 @@ static void ack_dynirq(struct irq_data *data)
if (!VALID_EVTCHN(evtchn))
return;
 
-   if (unlikely(irqd_is_setaffinity_pending(data))) {
+   if (unlikely(irqd_is_setaffinity_pending(data)) &&
+   likely(!irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
 
clear_evtchn(evtchn);
-- 
2.7.4

[PATCH 4.2.y-ckt 139/206] UBI: Fix static volume checks when Fastmap is used

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Richard Weinberger 

commit 1900149c835ab5b48bea31a823ea5e5a401fb560 upstream.

Ezequiel reported that he's facing UBI going into read-only
mode after power cut. It turned out that this behavior happens
only when updating a static volume is interrupted and Fastmap is
used.

A possible trace can look like:
ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 
0xFF bytes
ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
Hardware name: SAMSUNG ELECTRONICS CO., LTD. 
300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
0286 eba949bd 8800c45a7b38 8140d841
8801964be000 88018eaa4800 8800c45a7bb8 a003abf6
850e2ac0 8163 8801850e2ac0 8801850e2ac0
Call Trace:
[] dump_stack+0x63/0x82
[] ubi_eba_read_leb+0x486/0x4a0 [ubi]
[] ubi_check_volume+0x83/0xf0 [ubi]
[] ubi_open_volume+0x177/0x350 [ubi]
[] vol_cdev_open+0x58/0xb0 [ubi]
[] chrdev_open+0xae/0x1d0
[] do_dentry_open+0x1ff/0x300
[] ? cdev_put+0x30/0x30
[] vfs_open+0x56/0x60
[] path_openat+0x4f4/0x1190
[] do_filp_open+0x91/0x100
[] ? __alloc_fd+0xc7/0x190
[] do_sys_open+0x13f/0x210
[] SyS_open+0x1e/0x20
[] entry_SYSCALL_64_fastpath+0x1a/0xa4

UBI checks static volumes for data consistency and reads the
whole volume upon first open. If the volume is found erroneous
users of UBI cannot read from it, but another volume update is
possible to fix it. The check is performed by running
ubi_eba_read_leb() on every allocated LEB of the volume.
For static volumes ubi_eba_read_leb() computes the checksum of all
data stored in a LEB. To verify the computed checksum it has to read
the LEB's volume header which stores the original checksum.
If the volume header is not found UBI treats this as fatal internal
error and switches to RO mode. If the UBI device was attached via a
full scan the assumption is correct, the volume header has to be
present as it had to be there while scanning to get known as mapped.
If the attach operation happened via Fastmap the assumption is no
longer correct. When attaching via Fastmap UBI learns the mapping
table from Fastmap's snapshot of the system state and not via a full
scan. It can happen that a LEB got unmapped after a Fastmap was
written to the flash. Then UBI can learn the LEB still as mapped and
accessing it returns only 0xFF bytes. As UBI is not a FTL it is
allowed to have mappings to empty PEBs, it assumes that the layer
above takes care of LEB accounting and referencing.
UBIFS does so using the LEB property tree (LPT).
For static volumes UBI blindly assumes that all LEBs are present and
therefore special actions have to be taken.

The described situation can happen when updating a static volume is
interrupted, either by a user or a power cut.
The volume update code first unmaps all LEBs of a volume and then
writes LEB by LEB. If the sequence of operations is interrupted UBI
detects this either by the absence of LEBs, no volume header present
at scan time, or corrupted payload, detected via checksum.
In the Fastmap case the former method won't trigger as no scan
happened and UBI automatically thinks all LEBs are present.
Only by reading data from a LEB it detects that the volume header is
missing and incorrectly treats this as fatal error.
To deal with the situation ubi_eba_read_leb() from now on checks
whether we attached via Fastmap and handles the absence of a
volume header like a data corruption error.
This way interrupted static volume updates will correctly get detected
also when Fastmap is used.

Reported-by: Ezequiel Garcia 
Tested-by: Ezequiel Garcia 
Signed-off-by: Richard Weinberger 
Signed-off-by: Kamal Mostafa 
---
 drivers/mtd/ubi/eba.c | 21 +++--
 drivers/mtd/ubi/fastmap.c |  1 +
 drivers/mtd/ubi/ubi.h |  2 ++
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
index 51bca03..1c73ba6 100644
--- a/drivers/mtd/ubi/eba.c
+++ b/drivers/mtd/ubi/eba.c
@@ -426,8 +426,25 @@ retry:
 pnum, vol_id, lnum);
err = -EBADMSG;
} else {
-   err = -EINVAL;
-   ubi_ro_mode(ubi);
+   /*
+* Ending up here in the non-Fastmap 
case
+* is a clear bug as the VID header had 
to
+* be present at scan time to have it 
referenced.
+* 

[PATCH 4.2.y-ckt 128/206] PM / sleep: Handle failures in device_suspend_late() consistently

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: "Rafael J. Wysocki" 

commit 3a17fb329da68cb00558721aff876a80bba2fdb9 upstream.

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko 
Tested-by: Grygorii Strashko 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Kamal Mostafa 
---
 drivers/base/power/main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 30b7bbf..964d5e4 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1262,14 +1262,15 @@ int dpm_suspend_late(pm_message_t state)
error = device_suspend_late(dev);
 
mutex_lock(_list_mtx);
+   if (!list_empty(>power.entry))
+   list_move(>power.entry, _late_early_list);
+
if (error) {
pm_dev_err(dev, state, " late", error);
dpm_save_failed_dev(dev_name(dev));
put_device(dev);
break;
}
-   if (!list_empty(>power.entry))
-   list_move(>power.entry, _late_early_list);
put_device(dev);
 
if (async_error)
-- 
2.7.4

[PATCH 4.2.y-ckt 130/206] locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Peter Zijlstra 

commit 54cf809b9512be95f53ed4a5e3b631d1ac42f0fa upstream.

Similar to commits:

  51d7d5205d33 ("powerpc: Add smp_mb() to arch_spin_is_locked()")
  d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against concurrent 
lockers")

qspinlock suffers from the fact that the _Q_LOCKED_VAL store is
unordered inside the ACQUIRE of the lock.

And while this is not a problem for the regular mutual exclusive
critical section usage of spinlocks, it breaks creative locking like:

spin_lock(A)spin_lock(B)
spin_unlock_wait(B) if (!spin_is_locked(A))
do_something()do_something()

In that both CPUs can end up running do_something at the same time,
because our _Q_LOCKED_VAL store can drop past the spin_unlock_wait()
spin_is_locked() loads (even on x86!!).

To avoid making the normal case slower, add smp_mb()s to the less used
spin_unlock_wait() / spin_is_locked() side of things to avoid this
problem.

Reported-and-tested-by: Davidlohr Bueso 
Reported-by: Giovanni Gherdovich 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 include/asm-generic/qspinlock.h | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
index e2aadbc..7d633f1 100644
--- a/include/asm-generic/qspinlock.h
+++ b/include/asm-generic/qspinlock.h
@@ -27,7 +27,30 @@
  */
 static __always_inline int queued_spin_is_locked(struct qspinlock *lock)
 {
-   return atomic_read(>val);
+   /*
+* queued_spin_lock_slowpath() can ACQUIRE the lock before
+* issuing the unordered store that sets _Q_LOCKED_VAL.
+*
+* See both smp_cond_acquire() sites for more detail.
+*
+* This however means that in code like:
+*
+*   spin_lock(A)   spin_lock(B)
+*   spin_unlock_wait(B)spin_is_locked(A)
+*   do_something() do_something()
+*
+* Both CPUs can end up running do_something() because the store
+* setting _Q_LOCKED_VAL will pass through the loads in
+* spin_unlock_wait() and/or spin_is_locked().
+*
+* Avoid this by issuing a full memory barrier between the spin_lock()
+* and the loads in spin_unlock_wait() and spin_is_locked().
+*
+* Note that regular mutual exclusion doesn't care about this
+* delayed store.
+*/
+   smp_mb();
+   return atomic_read(>val) & _Q_LOCKED_MASK;
 }
 
 /**
@@ -107,6 +130,8 @@ static __always_inline void queued_spin_unlock(struct 
qspinlock *lock)
  */
 static inline void queued_spin_unlock_wait(struct qspinlock *lock)
 {
+   /* See queued_spin_is_locked() */
+   smp_mb();
while (atomic_read(>val) & _Q_LOCKED_MASK)
cpu_relax();
 }
-- 
2.7.4

[PATCH 4.2.y-ckt 136/206] wait/ptrace: assume __WALL if the child is traced

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Oleg Nesterov 

commit bf959931ddb88c4e4366e96dd22e68fa0db9527c upstream.

The following program (simplified version of generated by syzkaller)

#include 
#include 
#include 
#include 
#include 

void *thread_func(void *arg)
{
ptrace(PTRACE_TRACEME, 0,0,0);
return 0;
}

int main(void)
{
pthread_t thread;

if (fork())
return 0;

while (getppid() != 1)
;

pthread_create(, NULL, thread_func, NULL);
pthread_join(thread, NULL);
return 0;
}

creates an unreapable zombie if /sbin/init doesn't use __WALL.

This is not a kernel bug, at least in a sense that everything works as
expected: debugger should reap a traced sub-thread before it can reap the
leader, but without __WALL/__WCLONE do_wait() ignores sub-threads.

Unfortunately, it seems that /sbin/init in most (all?) distributions
doesn't use it and we have to change the kernel to avoid the problem.
Note also that most init's use sys_waitid() which doesn't allow __WALL, so
the necessary user-space fix is not that trivial.

This patch just adds the "ptrace" check into eligible_child().  To some
degree this matches the "tsk->ptrace" in exit_notify(), ->exit_signal is
mostly ignored when the tracee reports to debugger.  Or WSTOPPED, the
tracer doesn't need to set this flag to wait for the stopped tracee.

This obviously means the user-visible change: __WCLONE and __WALL no
longer have any meaning for debugger.  And I can only hope that this won't
break something, but at least strace/gdb won't suffer.

We could make a more conservative change.  Say, we can take __WCLONE into
account, or !thread_group_leader().  But it would be nice to not
complicate these historical/confusing checks.

Signed-off-by: Oleg Nesterov 
Reported-by: Dmitry Vyukov 
Cc: Denys Vlasenko 
Cc: Jan Kratochvil 
Cc: "Michael Kerrisk (man-pages)" 
Cc: Pedro Alves 
Cc: Roland McGrath 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 kernel/exit.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 031325e..269831c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -914,17 +914,28 @@ static int eligible_pid(struct wait_opts *wo, struct 
task_struct *p)
task_pid_type(p, wo->wo_type) == wo->wo_pid;
 }
 
-static int eligible_child(struct wait_opts *wo, struct task_struct *p)
+static int
+eligible_child(struct wait_opts *wo, bool ptrace, struct task_struct *p)
 {
if (!eligible_pid(wo, p))
return 0;
-   /* Wait for all children (clone and not) if __WALL is set;
-* otherwise, wait for clone children *only* if __WCLONE is
-* set; otherwise, wait for non-clone children *only*.  (Note:
-* A "clone" child here is one that reports to its parent
-* using a signal other than SIGCHLD.) */
-   if (((p->exit_signal != SIGCHLD) ^ !!(wo->wo_flags & __WCLONE))
-   && !(wo->wo_flags & __WALL))
+
+   /*
+* Wait for all children (clone and not) if __WALL is set or
+* if it is traced by us.
+*/
+   if (ptrace || (wo->wo_flags & __WALL))
+   return 1;
+
+   /*
+* Otherwise, wait for clone children *only* if __WCLONE is set;
+* otherwise, wait for non-clone children *only*.
+*
+* Note: a "clone" child here is one that reports to its parent
+* using a signal other than SIGCHLD, or a non-leader thread which
+* we can only see if it is traced by us.
+*/
+   if ((p->exit_signal != SIGCHLD) ^ !!(wo->wo_flags & __WCLONE))
return 0;
 
return 1;
@@ -1297,7 +1308,7 @@ static int wait_consider_task(struct wait_opts *wo, int 
ptrace,
if (unlikely(exit_state == EXIT_DEAD))
return 0;
 
-   ret = eligible_child(wo, p);
+   ret = eligible_child(wo, ptrace, p);
if (!ret)
return ret;
 
-- 
2.7.4

[PATCH 4.2.y-ckt 135/206] sunrpc: fix stripping of padded MIC tokens

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: =?UTF-8?q?Tom=C3=A1=C5=A1=20Trnka?= 

commit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 upstream.

The length of the GSS MIC token need not be a multiple of four bytes.
It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data()
would previously only trim mic.len + 4 B. The remaining up to three
bytes would then trigger a check in nfs4svc_decode_compoundargs(),
leading to a "garbage args" error and mount failure:

nfs4svc_decode_compoundargs: compound not properly padded!
nfsd: failed to decode arguments!

This would prevent older clients using the pre-RFC 4121 MIC format
(37-byte MIC including a 9-byte OID) from mounting exports from v3.9+
servers using krb5i.

The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off
trailing checksum before returning decrypted or integrity authenticated
buffer").

Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..."
Signed-off-by: Tomáš Trnka 
Acked-by: Jeff Layton 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Kamal Mostafa 
---
 net/sunrpc/auth_gss/svcauth_gss.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/auth_gss/svcauth_gss.c 
b/net/sunrpc/auth_gss/svcauth_gss.c
index 1095be9..4605dc7 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -857,8 +857,8 @@ unwrap_integ_data(struct svc_rqst *rqstp, struct xdr_buf 
*buf, u32 seq, struct g
goto out;
if (svc_getnl(>head[0]) != seq)
goto out;
-   /* trim off the mic at the end before returning */
-   xdr_buf_trim(buf, mic.len + 4);
+   /* trim off the mic and padding at the end before returning */
+   xdr_buf_trim(buf, round_up_to_quad(mic.len) + 4);
stat = 0;
 out:
kfree(mic.data);
-- 
2.7.4

[PATCH 4.2.y-ckt 140/206] drm/amdgpu: Fix hdmi deep color support.

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Mario Kleiner 

commit 9d746ab68163d642dae13756b2b3145b2e38cb65 upstream.

When porting the hdmi deep color detection code from
radeon-kms to amdgpu-kms apparently some kind of
copy and paste error happened, attaching an else
branch to the wrong if statement.

The result is that hdmi deep color mode is always
disabled, regardless of gpu and display capabilities and
user wishes, as the code mistakenly thinks that the display
doesn't provide the required max_tmds_clock limit and falls
back to 8 bpc.

This patch fixes deep color support, as tested on a
R9 380 Tonga Pro + suitable display, and should be
backported to all kernels with amdgpu-kms support.

Signed-off-by: Mario Kleiner 
Cc: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 119cdc2..7ef2c13 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -194,12 +194,12 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector 
*connector)
bpc = 8;
DRM_DEBUG("%s: HDMI deep color 10 bpc exceeds 
max tmds clock. Using %d bpc.\n",
  connector->name, bpc);
-   } else if (bpc > 8) {
-   /* max_tmds_clock missing, but hdmi spec 
mandates it for deep color. */
-   DRM_DEBUG("%s: Required max tmds clock for HDMI 
deep color missing. Using 8 bpc.\n",
- connector->name);
-   bpc = 8;
}
+   } else if (bpc > 8) {
+   /* max_tmds_clock missing, but hdmi spec mandates it 
for deep color. */
+   DRM_DEBUG("%s: Required max tmds clock for HDMI deep 
color missing. Using 8 bpc.\n",
+ connector->name);
+   bpc = 8;
}
}
 
-- 
2.7.4

[PATCH 4.2.y-ckt 137/206] xen/x86: actually allocate legacy interrupts on PV guests

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Stefano Stabellini 

commit 702f926067d2a4b28c10a3c41a1172dd62d9e735 upstream.

b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
of legacy interrupts when actually nr_legacy_irqs() returns 0 after
probe_8259A(). Use NR_IRQS_LEGACY instead.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/pci/xen.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index d22f4b5..6b8b107 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -488,8 +488,11 @@ int __init pci_xen_initial_domain(void)
 #endif
__acpi_register_gsi = acpi_register_gsi_xen;
__acpi_unregister_gsi = NULL;
-   /* Pre-allocate legacy irqs */
-   for (irq = 0; irq < nr_legacy_irqs(); irq++) {
+   /*
+* Pre-allocate the legacy IRQs.  Use NR_LEGACY_IRQS here
+* because we don't have a PIC and thus nr_legacy_irqs() is zero.
+*/
+   for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
int trigger, polarity;
 
if (acpi_get_override_irq(irq, , ) == -1)
-- 
2.7.4

[PATCH 4.2.y-ckt 112/206] drm/fb_helper: Fix references to dev->mode_config.num_connector

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Lyude 

commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 upstream.

During boot, MST hotplugs are generally expected (even if no physical
hotplugging occurs) and result in DRM's connector topology changing.
This means that using num_connector from the current mode configuration
can lead to the number of connectors changing under us. This can lead to
some nasty scenarios in fbcon:

- We allocate an array to the size of dev->mode_config.num_connectors.
- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value
  of dev->mode_config.num_connectors, and end up going out of bounds
  since dev->mode_config.num_connectors is now larger then the array we
  allocated.

fb_helper->connector_count however, will always remain consistent while
we do a modeset in fb_helper.

Note: This is just polish for 4.7, Dave Airlie's drm_connector
refcounting fixed these bugs for real. But it's good enough duct-tape
for stable kernel backporting, since backporting the refcounting
changes is way too invasive.

Signed-off-by: Lyude 
[danvet: Clarify why we need this. Also remove the now unused "dev"
local variable to appease gcc.]
Signed-off-by: Daniel Vetter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cp...@redhat.com
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/drm_fb_helper.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cac4229..c8b90b3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1549,7 +1549,6 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
  int n, int width, int height)
 {
int c, o;
-   struct drm_device *dev = fb_helper->dev;
struct drm_connector *connector;
const struct drm_connector_helper_funcs *connector_funcs;
struct drm_encoder *encoder;
@@ -1568,7 +1567,7 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
if (modes[n] == NULL)
return best_score;
 
-   crtcs = kzalloc(dev->mode_config.num_connector *
+   crtcs = kzalloc(fb_helper->connector_count *
sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
if (!crtcs)
return best_score;
@@ -1614,7 +1613,7 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
if (score > best_score) {
best_score = score;
memcpy(best_crtcs, crtcs,
-  dev->mode_config.num_connector *
+  fb_helper->connector_count *
   sizeof(struct drm_fb_helper_crtc *));
}
}
-- 
2.7.4

[PATCH 4.2.y-ckt 091/206] rtlwifi: Fix logic error in enter/exit power-save mode

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: wang yanqing 

commit 873ffe154ae074c46ed2d72dbd9a2a99f06f55b4 upstream.

In commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and
rtl_lps_enter() to use work queue"), the tests for enter/exit
power-save mode were inverted. With this change applied, the
wifi connection becomes much more stable.

Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to 
use work queue")
Signed-off-by: Wang YanQing 
Acked-by: Larry Finger 
Signed-off-by: Kalle Valo 
[ kamal: backport to 4.2-stable: files moved ]
Signed-off-by: Kamal Mostafa 
---
 drivers/net/wireless/rtlwifi/base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/base.c 
b/drivers/net/wireless/rtlwifi/base.c
index 0517a4f..7a40d8d 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1660,9 +1660,9 @@ void rtl_watchdog_wq_callback(void *data)
if (((rtlpriv->link_info.num_rx_inperiod +
  rtlpriv->link_info.num_tx_inperiod) > 8) ||
(rtlpriv->link_info.num_rx_inperiod > 2))
-   rtl_lps_enter(hw);
-   else
rtl_lps_leave(hw);
+   else
+   rtl_lps_enter(hw);
}
 
rtlpriv->link_info.num_rx_inperiod = 0;
-- 
2.7.4

[PATCH 4.2.y-ckt 089/206] arm64: cpuinfo: Missing NULL terminator in compat_hwcap_str

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Julien Grall 

commit f228b494e56d949be8d8ea09d4f973d1979201bf upstream.

The loop that browses the array compat_hwcap_str will stop when a NULL
is encountered, however NULL is missing at the end of array. This will
lead to overrun until a NULL is found somewhere in the following memory.
In reality, this works out because the compat_hwcap2_str array tends to
follow immediately in memory, and that *is* terminated correctly.
Furthermore, the unsigned int compat_elf_hwcap is checked before
printing each capability, so we end up doing the right thing because
the size of the two arrays is less than 32. Still, this is an obvious
mistake and should be fixed.

Note for backporting: commit 12d11817eaafa414 ("arm64: Move
/proc/cpuinfo handling code") moved this code in v4.4. Prior to that
commit, the same change should be made in arch/arm64/kernel/setup.c.

Fixes: 44b82b7700d0 "arm64: Fix up /proc/cpuinfo"
Signed-off-by: Julien Grall 
Signed-off-by: Will Deacon 
[ kamal: backport to 4.2-stable: applied to setup.c ]
Signed-off-by: Kamal Mostafa 
---
 arch/arm64/kernel/setup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index f3067d4..448b501 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -482,7 +482,8 @@ static const char *compat_hwcap_str[] = {
"idivt",
"vfpd32",
"lpae",
-   "evtstrm"
+   "evtstrm",
+   NULL
 };
 
 static const char *compat_hwcap2_str[] = {
-- 
2.7.4

[PATCH] m32r: add __ucmpdi2 to fix build failure

[Sudip Mukherjee]

We are having build failure with m32r and the error message being:
ERROR: "__ucmpdi2" [lib/842/842_decompress.ko] undefined!
ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!
ERROR: "__ucmpdi2" [drivers/media/i2c/adv7842.ko] undefined!
ERROR: "__ucmpdi2" [drivers/md/bcache/bcache.ko] undefined!
ERROR: "__ucmpdi2" [drivers/iio/imu/inv_mpu6050/inv-mpu6050.ko] undefined!

__ucmpdi2 is introduced to m32r architecture taking example from other
architectures like h8300, microblaze, mips.

Signed-off-by: Sudip Mukherjee 
---

Can some one please tell me how can i get a board of this architecture?
I am only testing for builds, but i dont know if anyone actually test it
on board. After all its orphan.

 arch/m32r/kernel/m32r_ksyms.c |  3 +++
 arch/m32r/lib/Makefile|  4 ++--
 arch/m32r/lib/libgcc.h| 24 
 arch/m32r/lib/ucmpdi2.c   | 17 +
 4 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 arch/m32r/lib/libgcc.h
 create mode 100644 arch/m32r/lib/ucmpdi2.c

diff --git a/arch/m32r/kernel/m32r_ksyms.c b/arch/m32r/kernel/m32r_ksyms.c
index b727e69..23f26f4a 100644
--- a/arch/m32r/kernel/m32r_ksyms.c
+++ b/arch/m32r/kernel/m32r_ksyms.c
@@ -41,6 +41,9 @@ EXPORT_SYMBOL(cpu_data);
 EXPORT_SYMBOL(smp_flush_tlb_page);
 #endif
 
+extern int __ucmpdi2(unsigned long long a, unsigned long long b);
+EXPORT_SYMBOL(__ucmpdi2);
+
 /* compiler generated symbol */
 extern void __ashldi3(void);
 extern void __ashrdi3(void);
diff --git a/arch/m32r/lib/Makefile b/arch/m32r/lib/Makefile
index d16b4e4..5889eb9 100644
--- a/arch/m32r/lib/Makefile
+++ b/arch/m32r/lib/Makefile
@@ -3,5 +3,5 @@
 #
 
 lib-y  := checksum.o ashxdi3.o memset.o memcpy.o \
- delay.o strlen.o usercopy.o csum_partial_copy.o
-
+ delay.o strlen.o usercopy.o csum_partial_copy.o \
+ ucmpdi2.o
diff --git a/arch/m32r/lib/libgcc.h b/arch/m32r/lib/libgcc.h
new file mode 100644
index 000..b2f45d0
--- /dev/null
+++ b/arch/m32r/lib/libgcc.h
@@ -0,0 +1,24 @@
+#ifndef __ASM_LIBGCC_H
+#define __ASM_LIBGCC_H
+
+#include 
+
+#ifdef __BIG_ENDIAN
+struct DWstruct {
+   int high, low;
+};
+#elif defined(__LITTLE_ENDIAN)
+struct DWstruct {
+   int low, high;
+};
+#else
+#error I feel sick.
+#endif
+
+typedef union {
+   struct DWstruct s;
+   long long ll;
+} DWunion;
+
+#endif /* __ASM_LIBGCC_H */
+
diff --git a/arch/m32r/lib/ucmpdi2.c b/arch/m32r/lib/ucmpdi2.c
new file mode 100644
index 000..d212b7f
--- /dev/null
+++ b/arch/m32r/lib/ucmpdi2.c
@@ -0,0 +1,17 @@
+#include "libgcc.h"
+
+int __ucmpdi2(unsigned long long a, unsigned long long b)
+{
+   const DWunion au = {.ll = a};
+   const DWunion bu = {.ll = b};
+
+   if ((unsigned int)au.s.high < (unsigned int)bu.s.high)
+   return 0;
+   else if ((unsigned int)au.s.high > (unsigned int)bu.s.high)
+   return 2;
+   if ((unsigned int)au.s.low < (unsigned int)bu.s.low)
+   return 0;
+   else if ((unsigned int)au.s.low > (unsigned int)bu.s.low)
+   return 2;
+   return 1;
+}
-- 
1.9.1

[PATCH 4.2.y-ckt 084/206] MIPS: KVM: Fix timer IRQ race when freezing timer

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: James Hogan 

commit 4355c44f063d3de4f072d796604c7f4ba4085cc3 upstream.

There's a particularly narrow and subtle race condition when the
software emulated guest timer is frozen which can allow a guest timer
interrupt to be missed.

This happens due to the hrtimer expiry being inexact, so very
occasionally the freeze time will be after the moment when the emulated
CP0_Count transitions to the same value as CP0_Compare (so an IRQ should
be generated), but before the moment when the hrtimer is due to expire
(so no IRQ is generated). The IRQ won't be generated when the timer is
resumed either, since the resume CP0_Count will already match CP0_Compare.

With VZ guests in particular this is far more likely to happen, since
the soft timer may be frozen frequently in order to restore the timer
state to the hardware guest timer. This happens after 5-10 hours of
guest soak testing, resulting in an overflow in guest kernel timekeeping
calculations, hanging the guest. A more focussed test case to
intentionally hit the race (with the help of a new hypcall to cause the
timer state to migrated between hardware & software) hits the condition
fairly reliably within around 30 seconds.

Instead of relying purely on the inexact hrtimer expiry to determine
whether an IRQ should be generated, read the guest CP0_Compare and
directly check whether the freeze time is before or after it. Only if
CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to
determine whether the last IRQ has already been generated (which will
have pushed back the expiry by one timer period).

Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
Cc: k...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/kvm/emulate.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c
index 41b1b09..eaf77b5 100644
--- a/arch/mips/kvm/emulate.c
+++ b/arch/mips/kvm/emulate.c
@@ -302,12 +302,31 @@ static inline ktime_t kvm_mips_count_time(struct kvm_vcpu 
*vcpu)
  */
 static uint32_t kvm_mips_read_count_running(struct kvm_vcpu *vcpu, ktime_t now)
 {
-   ktime_t expires;
+   struct mips_coproc *cop0 = vcpu->arch.cop0;
+   ktime_t expires, threshold;
+   uint32_t count, compare;
int running;
 
-   /* Is the hrtimer pending? */
+   /* Calculate the biased and scaled guest CP0_Count */
+   count = vcpu->arch.count_bias + kvm_mips_ktime_to_count(vcpu, now);
+   compare = kvm_read_c0_guest_compare(cop0);
+
+   /*
+* Find whether CP0_Count has reached the closest timer interrupt. If
+* not, we shouldn't inject it.
+*/
+   if ((int32_t)(count - compare) < 0)
+   return count;
+
+   /*
+* The CP0_Count we're going to return has already reached the closest
+* timer interrupt. Quickly check if it really is a new interrupt by
+* looking at whether the interval until the hrtimer expiry time is
+* less than 1/4 of the timer period.
+*/
expires = hrtimer_get_expires(>arch.comparecount_timer);
-   if (ktime_compare(now, expires) >= 0) {
+   threshold = ktime_add_ns(now, vcpu->arch.count_period / 4);
+   if (ktime_before(expires, threshold)) {
/*
 * Cancel it while we handle it so there's no chance of
 * interference with the timeout handler.
@@ -329,8 +348,7 @@ static uint32_t kvm_mips_read_count_running(struct kvm_vcpu 
*vcpu, ktime_t now)
}
}
 
-   /* Return the biased and scaled guest CP0_Count */
-   return vcpu->arch.count_bias + kvm_mips_ktime_to_count(vcpu, now);
+   return count;
 }
 
 /**
-- 
2.7.4

Re: [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target driver

[Ming Lin]

On Thu, Jun 9, 2016 at 2:42 PM, Steve Wise  wrote:

> Should the above error path actually goto a block that frees the rsps?  Like
> this?
>
> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> index c184ee5..8aaa36f 100644
> --- a/drivers/nvme/target/rdma.c
> +++ b/drivers/nvme/target/rdma.c
> @@ -1053,7 +1053,7 @@ nvmet_rdma_alloc_queue(struct nvmet_rdma_device *ndev,
> !queue->host_qid);
> if (IS_ERR(queue->cmds)) {
> ret = NVME_RDMA_CM_NO_RSC;
> -   goto out_free_cmds;
> +   goto out_free_responses;
> }
> }
>
> @@ -1073,6 +1073,8 @@ out_free_cmds:
> queue->recv_queue_size,
> !queue->host_qid);
> }
> +out_free_responses:
> +nvmet_rdma_free_rsps(queue);
>  out_ida_remove:
> ida_simple_remove(_rdma_queue_ida, queue->idx);
>  out_destroy_sq:

Yes. Nice catch.

[PATCH 4.2.y-ckt 090/206] kbuild: move -Wunused-const-variable to W=1 warning level

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Arnd Bergmann 

commit c9c6837d39311b0cc14cdbe7c18e815ab44aefb1 upstream.

gcc-6 started warning by default about variables that are not
used anywhere and that are marked 'const', generating many
false positives in an allmodconfig build, e.g.:

arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 
'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=]
arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but 
not used [-Wunused-const-variable=]
drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined 
but not used [-Wunused-const-variable=]
drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but 
not used [-Wunused-const-variable=]
drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' 
defined but not used [-Wunused-const-variable=]
drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used 
[-Wunused-const-variable=]

This is similar to the existing -Wunused-but-set-variable warning
that was added in an earlier release and that we disable by default
now and only enable when W=1 is set, so it makes sense to do
the same here. Once we have eliminated the majority of the
warnings for both, we can put them back into the default list.

We probably want this in backport kernels as well, to allow building
them with gcc-6 without introducing extra warnings.

Signed-off-by: Arnd Bergmann 
Acked-by: Olof Johansson 
Acked-by: Lee Jones 
Signed-off-by: Michal Marek 
Signed-off-by: Kamal Mostafa 
---
 Makefile   | 5 +++--
 scripts/Makefile.extrawarn | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 70e04ba..6a1001b 100644
--- a/Makefile
+++ b/Makefile
@@ -688,9 +688,10 @@ KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
 KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
 else
 
-# This warning generated too much noise in a regular build.
-# Use make W=1 to enable this warning (see scripts/Makefile.build)
+# These warnings generated too much noise in a regular build.
+# Use make W=1 to enable them (see scripts/Makefile.build)
 KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
+KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable)
 endif
 
 ifdef CONFIG_FRAME_POINTER
diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 0f8ba77..7339c39 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -24,6 +24,7 @@ warning-1 += $(call cc-option, -Wmissing-prototypes)
 warning-1 += -Wold-style-definition
 warning-1 += $(call cc-option, -Wmissing-include-dirs)
 warning-1 += $(call cc-option, -Wunused-but-set-variable)
+warning-1 += $(call cc-option, -Wunused-const-variable)
 warning-1 += $(call cc-disable-warning, missing-field-initializers)
 warning-1 += $(call cc-disable-warning, sign-compare)
 
-- 
2.7.4

[PATCH 4.2.y-ckt 077/206] mfd: omap-usb-tll: Fix scheduling while atomic BUG

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Roger Quadros 

commit b49b927f16acee626c56a1af4ab4cb062f75b5df upstream.

We shouldn't be calling clk_prepare_enable()/clk_prepare_disable()
in an atomic context.

Fixes the following issue:

[5.830970] ehci-omap: OMAP-EHCI Host Controller driver
[5.830974] driver_register 'ehci-omap'
[5.895849] driver_register 'wl1271_sdio'
[5.896870] BUG: scheduling while atomic: udevd/994/0x0002
[5.896876] 4 locks held by udevd/994:
[5.896904]  #0:  (>mutex){..}, at: [] 
__driver_attach+0x60/0xac
[5.896923]  #1:  (>mutex){..}, at: [] 
__driver_attach+0x70/0xac
[5.896946]  #2:  (tll_lock){+.+...}, at: [] 
omap_tll_enable+0x2c/0xd0
[5.896966]  #3:  (prepare_lock){+.+...}, at: [] 
clk_prepare_lock+0x48/0xe0
[5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap 
snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery 
bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra 
gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) 
bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp 
snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine
[5.897048] Preemption disabled at:[<  (null)>]   (null)
[5.897051]
[5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ #233
[5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree)
[5.897076] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[5.897087] [] (show_stack) from [] 
(dump_stack+0x88/0xc0)
[5.897099] [] (dump_stack) from [] 
(__schedule_bug+0xac/0xd0)
[5.897111] [] (__schedule_bug) from [] 
(__schedule+0x88/0x7e4)
[5.897120] [] (__schedule) from [] (schedule+0x9c/0xc0)
[5.897129] [] (schedule) from [] 
(schedule_preempt_disabled+0x14/0x20)
[5.897140] [] (schedule_preempt_disabled) from [] 
(mutex_lock_nested+0x258/0x43c)
[5.897150] [] (mutex_lock_nested) from [] 
(clk_prepare_lock+0x48/0xe0)
[5.897160] [] (clk_prepare_lock) from [] 
(clk_prepare+0x10/0x28)
[5.897169] [] (clk_prepare) from [] 
(omap_tll_enable+0x64/0xd0)
[5.897180] [] (omap_tll_enable) from [] 
(usbhs_runtime_resume+0x18/0x17c)
[5.897192] [] (usbhs_runtime_resume) from [] 
(pm_generic_runtime_resume+0x2c/0x40)
[5.897202] [] (pm_generic_runtime_resume) from [] 
(__rpm_callback+0x38/0x68)
[5.897210] [] (__rpm_callback) from [] 
(rpm_callback+0x70/0x88)
[5.897218] [] (rpm_callback) from [] 
(rpm_resume+0x4ec/0x7ec)
[5.897227] [] (rpm_resume) from [] 
(__pm_runtime_resume+0x4c/0x64)
[5.897236] [] (__pm_runtime_resume) from [] 
(driver_probe_device+0x30/0x70)
[5.897246] [] (driver_probe_device) from [] 
(__driver_attach+0x88/0xac)
[5.897256] [] (__driver_attach) from [] 
(bus_for_each_dev+0x50/0x84)
[5.897267] [] (bus_for_each_dev) from [] 
(bus_add_driver+0xcc/0x1e4)
[5.897276] [] (bus_add_driver) from [] 
(driver_register+0xac/0xf4)
[5.897286] [] (driver_register) from [] 
(do_one_initcall+0x100/0x1b8)
[5.897296] [] (do_one_initcall) from [] 
(do_init_module+0x58/0x1c0)
[5.897304] [] (do_init_module) from [] 
(SyS_finit_module+0x88/0x90)
[5.897313] [] (SyS_finit_module) from [] 
(ret_fast_syscall+0x0/0x1c)
[5.912697] [ cut here ]
[5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 
_raw_spin_unlock+0x28/0x58
[5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count())

Reported-by: H. Nikolaus Schaller 
Tested-by: H. Nikolaus Schaller 
Signed-off-by: Roger Quadros 
Signed-off-by: Lee Jones 
Signed-off-by: Kamal Mostafa 
---
 drivers/mfd/omap-usb-tll.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index b7b3e8e..c30290f 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -269,6 +269,8 @@ static int usbtll_omap_probe(struct platform_device *pdev)
 
if (IS_ERR(tll->ch_clk[i]))
dev_dbg(dev, "can't get clock : %s\n", clkname);
+   else
+   clk_prepare(tll->ch_clk[i]);
}
 
pm_runtime_put_sync(dev);
@@ -301,9 +303,12 @@ static int usbtll_omap_remove(struct platform_device *pdev)
tll_dev = NULL;
spin_unlock(_lock);
 
-   for (i = 0; i < tll->nch; i++)
-   if (!IS_ERR(tll->ch_clk[i]))
+   for (i = 0; i < tll->nch; i++) {
+   if (!IS_ERR(tll->ch_clk[i])) {
+   clk_unprepare(tll->ch_clk[i]);
clk_put(tll->ch_clk[i]);
+   }
+   }
 
pm_runtime_disable(>dev);
return 0;
@@ -420,7 +425,7 @@ int omap_tll_enable(struct 

[PATCH 4.2.y-ckt 075/206] MIPS64: R6: R2 emulation bugfix

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Leonid Yegoshin 

commit 41fa29e4d8cf4150568a0fe9bb4d62229f9caed5 upstream.

Error recovery pointers for fixups was improperly set as ".word"
which is unsuitable for MIPS64.

Replaced by STR(PTR)

[r...@linux-mips.org: Apply changes as requested in the review process.]

Signed-off-by: Leonid Yegoshin 
Reviewed-by: James Hogan 
Reviewed-by: Markos Chandras 
Fixes: b0a668fb2038 ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for 
MIPS R6")
Cc: ma...@linux-mips.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9911/
Signed-off-by: Ralf Baechle 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/kernel/mips-r2-to-r6-emul.c | 105 +-
 1 file changed, 53 insertions(+), 52 deletions(-)

diff --git a/arch/mips/kernel/mips-r2-to-r6-emul.c 
b/arch/mips/kernel/mips-r2-to-r6-emul.c
index f2977f0..e19fa36 100644
--- a/arch/mips/kernel/mips-r2-to-r6-emul.c
+++ b/arch/mips/kernel/mips-r2-to-r6-emul.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1250,10 +1251,10 @@ fpu_emul:
"   j   10b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1325,10 +1326,10 @@ fpu_emul:
"   j   10b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1396,10 +1397,10 @@ fpu_emul:
"   j   9b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1466,10 +1467,10 @@ fpu_emul:
"   j   9b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1581,14 +1582,14 @@ fpu_emul:
"   j   9b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
-   "   .word   5b,8b\n"
-   "   .word   6b,8b\n"
-   "   .word   7b,8b\n"
-   "   .word   0b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
+   STR(PTR) " 

[PATCH 4.2.y-ckt 065/206] ext4: silence UBSAN in ext4_mb_init()

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Nicolai Stange 

commit 935244cd54b86ca46e69bc6604d2adfb1aec2d42 upstream.

Currently, in ext4_mb_init(), there's a loop like the following:

  do {
...
offset += 1 << (sb->s_blocksize_bits - i);
i++;
  } while (i <= sb->s_blocksize_bits + 1);

Note that the updated offset is used in the loop's next iteration only.

However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
and UBSAN reports

  UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
  shift exponent 4294967295 is too large for 32-bit type 'int'
  [...]
  Call Trace:
   [] dump_stack+0xbc/0x117
   [] ? _atomic_dec_and_lock+0x169/0x169
   [] ubsan_epilogue+0xd/0x4e
   [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
   [] ? __ubsan_handle_load_invalid_value+0x158/0x158
   [] ? kmem_cache_alloc+0x101/0x390
   [] ? ext4_mb_init+0x13b/0xfd0
   [] ? create_cache+0x57/0x1f0
   [] ? create_cache+0x11a/0x1f0
   [] ? mutex_lock+0x38/0x60
   [] ? mutex_unlock+0x1b/0x50
   [] ? put_online_mems+0x5b/0xc0
   [] ? kmem_cache_create+0x117/0x2c0
   [] ext4_mb_init+0xc49/0xfd0
   [...]

Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.

Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of offset is never used again.

Silence UBSAN by introducing another variable, offset_incr, holding the
next increment to apply to offset and adjust that one by right shifting it
by one position per loop iteration.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161

Signed-off-by: Nicolai Stange 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Kamal Mostafa 
---
 fs/ext4/mballoc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index d9f9361..5162921 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2571,7 +2571,7 @@ int ext4_mb_init(struct super_block *sb)
 {
struct ext4_sb_info *sbi = EXT4_SB(sb);
unsigned i, j;
-   unsigned offset;
+   unsigned offset, offset_incr;
unsigned max;
int ret;
 
@@ -2600,11 +2600,13 @@ int ext4_mb_init(struct super_block *sb)
 
i = 1;
offset = 0;
+   offset_incr = 1 << (sb->s_blocksize_bits - 1);
max = sb->s_blocksize << 2;
do {
sbi->s_mb_offsets[i] = offset;
sbi->s_mb_maxs[i] = max;
-   offset += 1 << (sb->s_blocksize_bits - i);
+   offset += offset_incr;
+   offset_incr = offset_incr >> 1;
max = max >> 1;
i++;
} while (i <= sb->s_blocksize_bits + 1);
-- 
2.7.4

[PATCH 4.2.y-ckt 080/206] USB: serial: keyspan: fix use-after-free in probe error path

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Johan Hovold 

commit 35be1a71d70775e7bd7e45fa6d2897342ff4c9d2 upstream.

The interface instat and indat URBs were submitted in attach, but never
unlinked in release before deallocating the corresponding transfer
buffers.

In the case of a late probe error (e.g. due to failed minor allocation),
disconnect would not have been called before release, causing the
buffers to be freed while the URBs are still in use. We'd also end up
with active URBs for an unbound interface.

Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect,
release")
Signed-off-by: Johan Hovold 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/keyspan.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index e07b15e..7faa901 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -2376,6 +2376,10 @@ static void keyspan_release(struct usb_serial *serial)
 
s_priv = usb_get_serial_data(serial);
 
+   /* Make sure to unlink the URBs submitted in attach. */
+   usb_kill_urb(s_priv->instat_urb);
+   usb_kill_urb(s_priv->indat_urb);
+
usb_free_urb(s_priv->instat_urb);
usb_free_urb(s_priv->indat_urb);
usb_free_urb(s_priv->glocont_urb);
-- 
2.7.4

[PATCH 4.2.y-ckt 061/206] drm/amdgpu: use drm_mode_vrefresh() rather than mode->vrefresh

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Alex Deucher 

commit 6b8812eb004ee2b24aac8b1a711a0e8e797df3ce upstream.

This is a port of radeon commit:
3d2d98ee1af0cf6eebfbd6bff4c17d3601ac1284
drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh
to amdgpu.

Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
index 7b7f4ab..fe36caf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
@@ -150,7 +150,7 @@ u32 amdgpu_dpm_get_vrefresh(struct amdgpu_device *adev)
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
amdgpu_crtc = to_amdgpu_crtc(crtc);
if (crtc->enabled && amdgpu_crtc->enabled && 
amdgpu_crtc->hw_mode.clock) {
-   vrefresh = amdgpu_crtc->hw_mode.vrefresh;
+   vrefresh = 
drm_mode_vrefresh(_crtc->hw_mode);
break;
}
}
-- 
2.7.4

[PATCH 4.2.y-ckt 079/206] USB: serial: io_edgeport: fix memory leaks in probe error path

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Johan Hovold 

commit c8d62957d450cc1a22ce3242908709fe367ddc8e upstream.

URBs and buffers allocated in attach for Epic devices would never be
deallocated in case of a later probe error (e.g. failure to allocate
minor numbers) as disconnect is then never called.

Fix by moving deallocation to release and making sure that the
URBs are first unlinked.

Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect,
release")
Signed-off-by: Johan Hovold 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/io_edgeport.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
index 1106e7d..1947ea0 100644
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -2966,16 +2966,9 @@ static void edge_disconnect(struct usb_serial *serial)
 {
struct edgeport_serial *edge_serial = usb_get_serial_data(serial);
 
-   /* stop reads and writes on all ports */
-   /* free up our endpoint stuff */
if (edge_serial->is_epic) {
usb_kill_urb(edge_serial->interrupt_read_urb);
-   usb_free_urb(edge_serial->interrupt_read_urb);
-   kfree(edge_serial->interrupt_in_buffer);
-
usb_kill_urb(edge_serial->read_urb);
-   usb_free_urb(edge_serial->read_urb);
-   kfree(edge_serial->bulk_in_buffer);
}
 }
 
@@ -2988,6 +2981,16 @@ static void edge_release(struct usb_serial *serial)
 {
struct edgeport_serial *edge_serial = usb_get_serial_data(serial);
 
+   if (edge_serial->is_epic) {
+   usb_kill_urb(edge_serial->interrupt_read_urb);
+   usb_free_urb(edge_serial->interrupt_read_urb);
+   kfree(edge_serial->interrupt_in_buffer);
+
+   usb_kill_urb(edge_serial->read_urb);
+   usb_free_urb(edge_serial->read_urb);
+   kfree(edge_serial->bulk_in_buffer);
+   }
+
kfree(edge_serial);
 }
 
-- 
2.7.4

[PATCH 4.2.y-ckt 055/206] usb: misc: usbtest: format the data pattern according to max packet size

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Alan Stern 

commit b9a6e8e1001e28fecbd74c073f5503dac2790563 upstream.

With this change, the host and gadget doesn't need to agree with transfer
length for comparing the data, since they doesn't know each other's
transfer size, but know max packet size.

Signed-off-by: Peter Chen 
Acked-by: Michal Nazarewicz 
(Fixed the 'line over 80 characters warning' by Peter Chen)
Tested-by: Peter Chen 
Signed-off-by: Alan Stern 
Signed-off-by: Felipe Balbi 

Signed-off-by: Kamal Mostafa 
---
 drivers/usb/misc/usbtest.c | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 0bbafe7..46bb062 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -303,11 +303,20 @@ static unsigned mod_pattern;
 module_param_named(pattern, mod_pattern, uint, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(mod_pattern, "i/o pattern (0 == zeroes)");
 
-static inline void simple_fill_buf(struct urb *urb)
+static unsigned get_maxpacket(struct usb_device *udev, int pipe)
+{
+   struct usb_host_endpoint*ep;
+
+   ep = usb_pipe_endpoint(udev, pipe);
+   return le16_to_cpup(>desc.wMaxPacketSize);
+}
+
+static void simple_fill_buf(struct urb *urb)
 {
unsignedi;
u8  *buf = urb->transfer_buffer;
unsignedlen = urb->transfer_buffer_length;
+   unsignedmaxpacket;
 
switch (pattern) {
default:
@@ -316,8 +325,9 @@ static inline void simple_fill_buf(struct urb *urb)
memset(buf, 0, len);
break;
case 1: /* mod63 */
+   maxpacket = get_maxpacket(urb->dev, urb->pipe);
for (i = 0; i < len; i++)
-   *buf++ = (u8) (i % 63);
+   *buf++ = (u8) ((i % maxpacket) % 63);
break;
}
 }
@@ -349,6 +359,7 @@ static int simple_check_buf(struct usbtest_dev *tdev, 
struct urb *urb)
u8  expected;
u8  *buf = urb->transfer_buffer;
unsignedlen = urb->actual_length;
+   unsignedmaxpacket = get_maxpacket(urb->dev, urb->pipe);
 
int ret = check_guard_bytes(tdev, urb);
if (ret)
@@ -366,7 +377,7 @@ static int simple_check_buf(struct usbtest_dev *tdev, 
struct urb *urb)
 * with set_interface or set_config.
 */
case 1: /* mod63 */
-   expected = i % 63;
+   expected = (i % maxpacket) % 63;
break;
/* always fail unsupported patterns */
default:
@@ -478,11 +489,13 @@ static void free_sglist(struct scatterlist *sg, int nents)
 }
 
 static struct scatterlist *
-alloc_sglist(int nents, int max, int vary)
+alloc_sglist(int nents, int max, int vary, struct usbtest_dev *dev, int pipe)
 {
struct scatterlist  *sg;
unsignedi;
unsignedsize = max;
+   unsignedmaxpacket =
+   get_maxpacket(interface_to_usbdev(dev->intf), pipe);
 
if (max == 0)
return NULL;
@@ -511,7 +524,7 @@ alloc_sglist(int nents, int max, int vary)
break;
case 1:
for (j = 0; j < size; j++)
-   *buf++ = (u8) (j % 63);
+   *buf++ = (u8) ((j % maxpacket) % 63);
break;
}
 
@@ -2175,7 +2188,8 @@ usbtest_ioctl(struct usb_interface *intf, unsigned int 
code, void *buf)
"TEST 5:  write %d sglists %d entries of %d bytes\n",
param->iterations,
param->sglen, param->length);
-   sg = alloc_sglist(param->sglen, param->length, 0);
+   sg = alloc_sglist(param->sglen, param->length,
+   0, dev, dev->out_pipe);
if (!sg) {
retval = -ENOMEM;
break;
@@ -2193,7 +2207,8 @@ usbtest_ioctl(struct usb_interface *intf, unsigned int 
code, void *buf)
"TEST 6:  read %d sglists %d entries of %d bytes\n",
param->iterations,
param->sglen, param->length);
-   sg = alloc_sglist(param->sglen, param->length, 0);
+   sg = alloc_sglist(param->sglen, param->length,
+   0, dev, dev->in_pipe);
if (!sg) {

[PATCH 4.2.y-ckt 052/206] thunderbolt: Fix double free of drom buffer

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Andreas Noever 

commit 2ffa9a5d76a75abbc1f95c17959fced666095bdd upstream.

If tb_drom_read() fails, sw->drom is freed but not set to NULL.  sw->drom
is then freed again in the error path of tb_switch_alloc().

The bug can be triggered by unplugging a thunderbolt device shortly after
it is detected by the thunderbolt driver.

Clear sw->drom if tb_drom_read() fails.

[bhelgaas: add Fixes:, stable versions of interest]
Fixes: 343fcb8c70d7 ("thunderbolt: Fix nontrivial endpoint devices.")
Signed-off-by: Andreas Noever 
Signed-off-by: Bjorn Helgaas 
CC: Lukas Wunner 
Signed-off-by: Kamal Mostafa 
---
 drivers/thunderbolt/eeprom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
index 0dde34e..545c60c 100644
--- a/drivers/thunderbolt/eeprom.c
+++ b/drivers/thunderbolt/eeprom.c
@@ -444,6 +444,7 @@ int tb_drom_read(struct tb_switch *sw)
return tb_drom_parse_entries(sw);
 err:
kfree(sw->drom);
+   sw->drom = NULL;
return -EIO;
 
 }
-- 
2.7.4

[PATCH 4.2.y-ckt 044/206] Drivers: hv_vmbus: Fix signal to host condition

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Christopher Oo 

commit a5cca686ce0ef4909deaee4ed46dd991e3a9ece4 upstream.

Fixes a bug where previously hv_ringbuffer_read would pass in the old
number of bytes available to read instead of the expected old read index
when calculating when to signal to the host that the ringbuffer is empty.
Since the previous write size is already saved, also changes the
hv_need_to_signal_on_read to use the previously read value rather than
recalculating it.

Signed-off-by: Christopher Oo 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/hv/ring_buffer.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 6361d12..70a1a9a 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -103,10 +103,9 @@ static bool hv_need_to_signal(u32 old_write, struct 
hv_ring_buffer_info *rbi)
  *there is room for the producer to send the pending packet.
  */
 
-static bool hv_need_to_signal_on_read(u32 old_rd,
-struct hv_ring_buffer_info *rbi)
+static bool hv_need_to_signal_on_read(u32 prev_write_sz,
+ struct hv_ring_buffer_info *rbi)
 {
-   u32 prev_write_sz;
u32 cur_write_sz;
u32 r_size;
u32 write_loc = rbi->ring_buffer->write_index;
@@ -123,10 +122,6 @@ static bool hv_need_to_signal_on_read(u32 old_rd,
cur_write_sz = write_loc >= read_loc ? r_size - (write_loc - read_loc) :
read_loc - write_loc;
 
-   prev_write_sz = write_loc >= old_rd ? r_size - (write_loc - old_rd) :
-   old_rd - write_loc;
-
-
if ((prev_write_sz < pending_sz) && (cur_write_sz >= pending_sz))
return true;
 
@@ -517,7 +512,6 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info, void *buffer,
u32 next_read_location = 0;
u64 prev_indices = 0;
unsigned long flags;
-   u32 old_read;
 
if (buflen <= 0)
return -EINVAL;
@@ -528,8 +522,6 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info, void *buffer,
_avail_toread,
_avail_towrite);
 
-   old_read = bytes_avail_toread;
-
/* Make sure there is something to read */
if (bytes_avail_toread < buflen) {
spin_unlock_irqrestore(_info->ring_lock, flags);
@@ -560,7 +552,7 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info, void *buffer,
 
spin_unlock_irqrestore(_info->ring_lock, flags);
 
-   *signal = hv_need_to_signal_on_read(old_read, inring_info);
+   *signal = hv_need_to_signal_on_read(bytes_avail_towrite, inring_info);
 
return 0;
 }
-- 
2.7.4

Re: [PATCH] libnvdimm, nfit: treat volatile virtual CD region as read-only pmem

[Linda Knippers]

On 6/4/2016 7:01 AM, joeyli wrote:
> Hi Dan, 
> 
> Thanks for your review.
> 
> On Fri, Jun 03, 2016 at 12:27:34PM -0700, Dan Williams wrote:
>> On Fri, Jun 3, 2016 at 12:13 AM, Lee, Chun-Yi  
>> wrote:
>>> This patch adds codes to treat a volatile virtual CD region as a
>>> read-only pmem region, then read-only /dev/pmem* device can be mounted
>>> with iso9660.
>>>
>>> It's useful to work with the httpboot in EFI firmware to pull a remote
>>> ISO file to the local memory region for booting and installation.
>>>
>>> Wiki page of UEFI HTTPBoot with OVMF:
>>> https://en.opensuse.org/UEFI_HTTPBoot_with_OVMF
>>>
>>> Signed-off-by: Lee, Chun-Yi 
>>> Cc: Gary Lin 
>>> Cc: Dan Williams 
>>> Cc: Ross Zwisler 
>>> Cc: "Rafael J. Wysocki" 
>>> ---
>>>  drivers/acpi/nfit.c  |  8 +++-
>>>  drivers/nvdimm/region_devs.c | 26 +-
>>>  include/linux/libnvdimm.h|  2 ++
>>>  3 files changed, 34 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
>>> index 2215fc8..b100a17 100644
>>> --- a/drivers/acpi/nfit.c
>>> +++ b/drivers/acpi/nfit.c
>>> @@ -1949,6 +1949,7 @@ static int acpi_nfit_init_mapping(struct 
>>> acpi_nfit_desc *acpi_desc,
>>> switch (nfit_spa_type(spa)) {
>>> case NFIT_SPA_PM:
>>> case NFIT_SPA_VOLATILE:
>>> +   case NFIT_SPA_VCD:
>>> nd_mapping->start = memdev->address;
>>> nd_mapping->size = memdev->region_size;
>>> break;
>>
>> Why do we need to distinguish NFIT_SPA_VOLATILE vs NFIT_SPA_VCD, i.e.
>> what happens if something writes to a VCD device?
> 
> Actually I didn't try to write SPA-VCD device before. Every time I mount it
> that the system responses read-only:
> 
> # mount /dev/pmem0 /mnt/
> mount: /dev/pmem0 is write-protected, mounting read-only
> 
> If it can be written, then I think there have no difference between
> NFIT_SPA_VOLATILE with NFIT_SPA_VCD region.

It's not clear to me what the expectations for this type of device are, or
whether they should be read-only.  The ACPI spec is not helpful here.
The other Disk Region and CD Region types are also unclear.  Anyone
care to define them?

> I implemented this patch to treat VCD region as read-only pmem because the
> pmem region generates /dev/pmem* device that it can be mounted.

I'm a bit worried about this type of device showing up as a "pmem" device.
I realize they're described in the NFIT (not sure why but they are) but do
any of the operations that we support for other pmem devices work on these?
Do root device DSMs make any sense?  Are there other DSMs?  What will happen
if someone uses ndctl to reconfigure the device?

I'm especially concerned on systems that might have one of these devices
and also have NVDIMMs.  Do all the pmem devices get numbered different if
this device comes and goes across reboots?  (I know, we shouldn't rely on
those names but it will still confuse people.)  Can they be some other name
that better represents what they're trying to be?

> Maybe I missed. Does NFIT_SPA_VOLATILE region also generate a device in /dev
> that it can be mounted with filesystem? 

Yes.

-- ljk

> Then I think treat the VCD region as
> a read-only VOLATILE region that's also a solution.
> 
> 
> Thanks a lot!
> Joey Lee
> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
> 

[PATCH 4.2.y-ckt 041/206] aacraid: Fix for KDUMP driver hang

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Raghava Aditya Renukunta 

commit 78cbccd3bd683c295a44af8050797dc4a41376ff upstream.

When KDUMP is triggered the driver first talks to the firmware in INTX
mode, but the adapter firmware is still in MSIX mode. Therefore the first
driver command hangs since the driver is waiting for an INTX response and
firmware gives a MSIX response. If when the OS is installed on a RAID
drive created by the adapter KDUMP will hang since the driver does not
receive a response in sync mode.

Fixed by: Change the firmware to INTX mode if it is in MSIX mode before
sending the first sync command.

Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Kamal Mostafa 
---
 drivers/scsi/aacraid/aacraid.h  |  1 +
 drivers/scsi/aacraid/comminit.c | 24 
 2 files changed, 25 insertions(+)

diff --git a/drivers/scsi/aacraid/aacraid.h b/drivers/scsi/aacraid/aacraid.h
index 18c9c06..3e8e92b 100644
--- a/drivers/scsi/aacraid/aacraid.h
+++ b/drivers/scsi/aacraid/aacraid.h
@@ -29,6 +29,7 @@ enum {
 #define AAC_INT_MODE_MSI   (1<<1)
 #define AAC_INT_MODE_AIF   (1<<2)
 #define AAC_INT_MODE_SYNC  (1<<3)
+#define AAC_INT_MODE_MSIX  (1<<16)
 
 #define AAC_INT_ENABLE_TYPE1_INTX  0xfffb
 #define AAC_INT_ENABLE_TYPE1_MSIX  0xfffa
diff --git a/drivers/scsi/aacraid/comminit.c b/drivers/scsi/aacraid/comminit.c
index 45db84a..e736ecb 100644
--- a/drivers/scsi/aacraid/comminit.c
+++ b/drivers/scsi/aacraid/comminit.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,6 +50,20 @@ struct aac_common aac_config = {
.irq_mod = 1
 };
 
+static inline int aac_is_msix_mode(struct aac_dev *dev)
+{
+   u32 status;
+
+   status = src_readl(dev, MUnit.OMR);
+   return (status & AAC_INT_MODE_MSIX);
+}
+
+static inline void aac_change_to_intx(struct aac_dev *dev)
+{
+   aac_src_access_devreg(dev, AAC_DISABLE_MSIX);
+   aac_src_access_devreg(dev, AAC_ENABLE_INTX);
+}
+
 static int aac_alloc_comm(struct aac_dev *dev, void **commaddr, unsigned long 
commsize, unsigned long commalign)
 {
unsigned char *base;
@@ -358,6 +373,15 @@ struct aac_dev *aac_init_adapter(struct aac_dev *dev)
dev->comm_interface = AAC_COMM_PRODUCER;
dev->raw_io_interface = dev->raw_io_64 = 0;
 
+
+   /*
+* Enable INTX mode, if not done already Enabled
+*/
+   if (aac_is_msix_mode(dev)) {
+   aac_change_to_intx(dev);
+   dev_info(>pdev->dev, "Changed firmware to INTX mode");
+   }
+
if ((!aac_adapter_sync_cmd(dev, GET_ADAPTER_PROPERTIES,
0, 0, 0, 0, 0, 0,
status+0, status+1, status+2, status+3, NULL)) &&
-- 
2.7.4

Re: linux-next: Tree for Jun 9

[Kees Cook]

On Thu, Jun 9, 2016 at 3:06 PM, Sudip Mukherjee
 wrote:
> On Thursday 09 June 2016 07:34 AM, Stephen Rothwell wrote:
>>
>> Hi all,
>>
>> News: there will be no linux-next releases on Friday (tomorrow) or
>> Monday, so the next release will be next-20160614 on Tuesday.
>>
>> Changes since 20160608:
>
>
> While trying to build x86_64 allmodconfig I am getting:
> ++ dirname ../scripts/gcc-plugin.sh
> + srctree=../scripts
> ++ gcc -print-file-name=plugin
> + gccplugins_dir=plugin
> ++ g++ -E -x c++ - -o /dev/null -I../scripts/gcc-plugins -Iplugin/include
> + plugincc='In file included from :1:0:
> ../scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such
> file or directory
>  #include "bversion.h"
>   ^
> compilation terminated.'
> + '[' 1 -ne 0 ']'
> + exit 1
>
> build log is at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/136350824
>
> Looks like 6b90bd4ba40b ("GCC plugin infrastructure") is the problem.

Hi, yes, if you want to be testing the GCC plugins, you'll need the
gcc plugin headers installed. On Debian and Ubuntu, they can be found
like this:

$ apt-cache search gcc | grep plugin-dev
gcc-5-plugin-dev - Files for GNU GCC plugin development.
gcc-4.7-plugin-dev - Files for GNU GCC plugin development.
gcc-4.8-plugin-dev - Files for GNU GCC plugin development.
gcc-4.9-plugin-dev - Files for GNU GCC plugin development.


-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[PATCH 4.2.y-ckt 002/206] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Lyude 

commit 1f7717552ef1306be3b7ed28c66c6eff550e3a23 upstream.

After unplugging a DP MST display from the system, we have to go through
and destroy all of the DRM connectors associated with it since none of
them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
doesn't do a good enough job of ensuring that throughout the destruction
process that no modesettings can be done with the connectors. As it is
right now, intel_dp_destroy_mst_connector() works like this:

* Take all modeset locks
* Clear the configuration of the crtc on the connector, if there is one
* Drop all modeset locks, this is required because of circular
  dependency issues that arise with trying to remove the connector from
  sysfs with modeset locks held
* Unregister the connector
* Take all modeset locks, again
* Do the rest of the required cleaning for destroying the connector
* Finally drop all modeset locks for good

This only works sometimes. During the destruction process, it's very
possible that a userspace application will attempt to do a modesetting
using the connector. When we drop the modeset locks, an ioctl handler
such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
locks from us. When this happens, one thing leads to another and
eventually we end up committing a mode with the non-existent connector:

[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to 
enable link training
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel 
equalization
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi

And in some cases, such as with the T460s using an MST dock, this
results in breaking modesetting and/or panicking the system.

To work around this, we now unregister the connector at the very
beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
locks, and then hold them until we finish the rest of the function.

Signed-off-by: Lyude 
Signed-off-by: Rob Clark 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cp...@redhat.com
[ kamal: backport to 4.2-stable: context ]
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 8c127201..7feec0f 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -470,14 +470,13 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_device *dev = connector->dev;
-   /* need to nuke the connector */
-   mutex_lock(>mode_config.mutex);
-   intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
-   mutex_unlock(>mode_config.mutex);
 
intel_connector->unregister(intel_connector);
 
+   /* need to nuke the connector */
mutex_lock(>mode_config.mutex);
+   intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+
intel_connector_remove_from_fbdev(intel_connector);
drm_connector_cleanup(connector);
mutex_unlock(>mode_config.mutex);
-- 
2.7.4

[PATCH 4.2.y-ckt 013/206] Bluetooth: vhci: fix open_timeout vs. hdev race

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Jiri Slaby 

commit 373a32c848ae3a1c03618517cce85f9211a6facf upstream.

Both vhci_get_user and vhci_release race with open_timeout work. They
both contain cancel_delayed_work_sync, but do not test whether the
work actually created hdev or not. Since the work can be in progress
and _sync will wait for finishing it, we can have data->hdev allocated
when cancel_delayed_work_sync returns. But the call sites do 'if
(data->hdev)' *before* cancel_delayed_work_sync.

As a result:
* vhci_get_user allocates a second hdev and puts it into
  data->hdev. The former is leaked.
* vhci_release does not release data->hdev properly as it thinks there
  is none.

Fix both cases by moving the actual test *after* the call to
cancel_delayed_work_sync.

This can be hit by this program:
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

int main(int argc, char **argv)
{
int fd;

srand(time(NULL));

while (1) {
const int delta = (rand() % 200 - 100) * 100;

fd = open("/dev/vhci", O_RDWR);
if (fd < 0)
err(1, "open");

usleep(100 + delta);

close(fd);
}

return 0;
}

And the result is:
BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr 
88006b0c1228
Read of size 8 by task kworker/u13:1/32068
=
BUG kmalloc-192 (Tainted: GE ): kasan: bad access detected
-

Disabling lock debugging due to kernel taint
INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040
...
kmem_cache_alloc_trace+0x150/0x190
vhci_open+0x50/0x330 [hci_vhci]
misc_open+0x35b/0x4e0
chrdev_open+0x23b/0x510
...
INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040
...
__slab_free+0x204/0x310
vhci_release+0xa4/0xd0 [hci_vhci]
...
INFO: Slab 0xea0001ac3000 objects=16 used=13 fp=0x88006b0c1e00 
flags=0x5f80004080
INFO: Object 0x88006b0c1200 @offset=4608 fp=0x88006b0c0600
Bytes b4 88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00  

Object 88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00  
...k
Object 88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff  
...k...k
Object 88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff  
.F.k.F.k
Object 88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00  

Object 88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff  
@..k@..k
Object 88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de  
P.n.
Object 88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00  
.b..
Object 88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff  
8..k
Object 88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00  .. 
.
Object 88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  

Object 88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff  
...=
Object 88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00  . 
..
Redzone 88006b0c12c0: bb bb bb bb bb bb bb bb  

Padding 88006b0c13f8: 00 00 00 00 00 00 00 00  

CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: GB   E  
4.4.6-0-default #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
Workqueue: hci0 hci_cmd_work [bluetooth]
  81926cfa 88006be37c68 88006bc27180
 88006b0c1200 88006b0c1234 81577993 82489320
 88006bc24240 0046 88006a10 00026e51eb80
Call Trace:
...
 [] ? skb_queue_tail+0x13e/0x150
 [] ? vhci_send_frame+0xac/0x100 [hci_vhci]
 [] ? hci_send_frame+0x188/0x320 [bluetooth]
 [] ? hci_cmd_work+0x115/0x310 [bluetooth]
 [] ? process_one_work+0x815/0x1340
 [] ? worker_thread+0xe5/0x11f0
 [] ? process_one_work+0x1340/0x1340
 [] ? kthread+0x1c8/0x230
...
Memory state around the buggy address:
 88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ^
 88006b0c1280: fb fb fb fb fb 

[PATCH 4.2.y-ckt 011/206] rtlwifi: btcoexist: Implement antenna selection

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Larry Finger 

commit baa1702290953295e421f0f433e2b1ff4815827c upstream.

The previous patch added an option to rtl8723be to manually select the
antenna for those cases when only a single antenna is present, and the
on-board EEPROM is incorrectly programmed. This patch implements the
necessary changes in the Bluetooth coexistence driver.

Signed-off-by: Larry Finger 
Signed-off-by: Kalle Valo 
[ kamal: backport to 4.2-stable: files moved ]
Signed-off-by: Kamal Mostafa 
---
 .../wireless/rtlwifi/btcoexist/halbtc8723b2ant.c   |  9 ++--
 .../net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c  | 27 +-
 .../net/wireless/rtlwifi/btcoexist/halbtcoutsrc.h  |  2 +-
 drivers/net/wireless/rtlwifi/btcoexist/rtl_btc.c   |  5 +++-
 4 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8723b2ant.c
index f2b9d11..e85f165 100644
--- a/drivers/net/wireless/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -1203,7 +1203,6 @@ static void btc8723b2ant_set_ant_path(struct btc_coexist 
*btcoexist,
 
/* Force GNT_BT to low */
btcoexist->btc_write_1byte_bitmask(btcoexist, 0x765, 0x18, 0x0);
-   btcoexist->btc_write_2byte(btcoexist, 0x948, 0x0);
 
if (board_info->btdm_ant_pos == BTC_ANTENNA_AT_MAIN_PORT) {
/* tell firmware "no antenna inverse" */
@@ -1211,19 +1210,25 @@ static void btc8723b2ant_set_ant_path(struct 
btc_coexist *btcoexist,
h2c_parameter[1] = 1;  /* ext switch type */
btcoexist->btc_fill_h2c(btcoexist, 0x65, 2,
h2c_parameter);
+   btcoexist->btc_write_2byte(btcoexist, 0x948, 0x0);
} else {
/* tell firmware "antenna inverse" */
h2c_parameter[0] = 1;
h2c_parameter[1] = 1;  /* ext switch type */
btcoexist->btc_fill_h2c(btcoexist, 0x65, 2,
h2c_parameter);
+   btcoexist->btc_write_2byte(btcoexist, 0x948, 0x280);
}
}
 
/* ext switch setting */
if (use_ext_switch) {
/* fixed internal switch S1->WiFi, S0->BT */
-   btcoexist->btc_write_2byte(btcoexist, 0x948, 0x0);
+   if (board_info->btdm_ant_pos == BTC_ANTENNA_AT_MAIN_PORT)
+   btcoexist->btc_write_2byte(btcoexist, 0x948, 0x0);
+   else
+   btcoexist->btc_write_2byte(btcoexist, 0x948, 0x280);
+
switch (antpos_type) {
case BTC_ANT_WIFI_AT_MAIN:
/* ext switch main at wifi */
diff --git a/drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c
index b2791c8..babd149 100644
--- a/drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -965,13 +965,38 @@ void exhalbtc_set_chip_type(u8 chip_type)
}
 }
 
-void exhalbtc_set_ant_num(u8 type, u8 ant_num)
+void exhalbtc_set_ant_num(struct rtl_priv *rtlpriv, u8 type, u8 ant_num)
 {
if (BT_COEX_ANT_TYPE_PG == type) {
gl_bt_coexist.board_info.pg_ant_num = ant_num;
gl_bt_coexist.board_info.btdm_ant_num = ant_num;
+   /* The antenna position:
+* Main (default) or Aux for pgAntNum=2 && btdmAntNum =1.
+* The antenna position should be determined by
+* auto-detect mechanism.
+* The following is assumed to main,
+* and those must be modified
+* if y auto-detect mechanism is ready
+*/
+   if ((gl_bt_coexist.board_info.pg_ant_num == 2) &&
+   (gl_bt_coexist.board_info.btdm_ant_num == 1))
+   gl_bt_coexist.board_info.btdm_ant_pos =
+  BTC_ANTENNA_AT_MAIN_PORT;
+   else
+   gl_bt_coexist.board_info.btdm_ant_pos =
+  BTC_ANTENNA_AT_MAIN_PORT;
} else if (BT_COEX_ANT_TYPE_ANTDIV == type) {
gl_bt_coexist.board_info.btdm_ant_num = ant_num;
+   gl_bt_coexist.board_info.btdm_ant_pos =
+  BTC_ANTENNA_AT_MAIN_PORT;
+   } else if (type == BT_COEX_ANT_TYPE_DETECTED) {
+   

[PATCH 4.2.y-ckt 004/206] drm/i915: Call intel_dp_mst_resume() before resuming displays

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Lyude 

commit a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422 upstream.

Since we need MST devices ready before we try to resume displays,
calling this after intel_display_resume() can result in some issues with
various laptop docks where the monitor won't turn back on after
suspending the system.

This order was originally changed in

commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")

In order to fix some unclaimed register errors, however the actual cause
of those has since been fixed.

Signed-off-by: Lyude 
[danvet: Resolve conflicts with locking changes.]
Signed-off-by: Daniel Vetter 
[ kamal: backport to 4.2-stable: context ]
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/i915/i915_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9d42aeb..2188b7f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -762,12 +762,12 @@ static int i915_drm_resume(struct drm_device *dev)
dev_priv->display.hpd_irq_setup(dev);
spin_unlock_irq(_priv->irq_lock);
 
+   intel_dp_mst_resume(dev);
+
drm_modeset_lock_all(dev);
intel_modeset_setup_hw_state(dev, true);
drm_modeset_unlock_all(dev);
 
-   intel_dp_mst_resume(dev);
-
/*
 * ... but also need to make sure that hotplug processing
 * doesn't cause havoc. Like in the driver load code we don't
-- 
2.7.4

[PATCH 2/2] Drivers: hv: utils: fix a race on userspace daemons registration

[K. Y. Srinivasan]

From: Vitaly Kuznetsov 

Background: userspace daemons registration protocol for Hyper-V utilities
drivers has two steps:
1) daemon writes its own version to kernel
2) kernel reads it and replies with module version
at this point we consider the handshake procedure being completed and we
do hv_poll_channel() transitioning the utility device to HVUTIL_READY
state. At this point we're ready to handle messages from kernel.

When hvutil_transport is in HVUTIL_TRANSPORT_CHARDEV mode we have a
single buffer for outgoing message. hvutil_transport_send() puts to this
buffer and till the buffer is cleared with hvt_op_read() returns -EFAULT
to all consequent calls. Host<->guest protocol guarantees there is no more
than one request at a time and we will not get new requests till we reply
to the previous one so this single message buffer is enough.

Now to the race. When we finish negotiation procedure and send kernel
module version to userspace with hvutil_transport_send() it goes into the
above mentioned buffer and if the daemon is slow enough to read it from
there we can get a collision when a request from the host comes, we won't
be able to put anything to the buffer so the request will be lost. To
solve the issue we need to know when the negotiation is really done (when
the version message is read by the daemon) and transition to HVUTIL_READY
state after this happens. Implement a callback on read to support this.
Old style netlink communication is not affected by the change, we don't
really know when these messages are delivered but we don't have a single
message buffer there.

Reported-by: Barry Davis 
Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_fcopy.c   |   14 ++
 drivers/hv/hv_kvp.c |   27 ---
 drivers/hv/hv_snapshot.c|   16 +++-
 drivers/hv/hv_utils_transport.c |   15 ++-
 drivers/hv/hv_utils_transport.h |4 +++-
 5 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index 23c7079..8b2ba98 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -83,6 +83,12 @@ static void fcopy_timeout_func(struct work_struct *dummy)
hv_poll_channel(fcopy_transaction.recv_channel, fcopy_poll_wrapper);
 }
 
+static void fcopy_register_done(void)
+{
+   pr_debug("FCP: userspace daemon registered\n");
+   hv_poll_channel(fcopy_transaction.recv_channel, fcopy_poll_wrapper);
+}
+
 static int fcopy_handle_handshake(u32 version)
 {
u32 our_ver = FCOPY_CURRENT_VERSION;
@@ -94,7 +100,8 @@ static int fcopy_handle_handshake(u32 version)
break;
case FCOPY_VERSION_1:
/* Daemon expects us to reply with our own version */
-   if (hvutil_transport_send(hvt, _ver, sizeof(our_ver)))
+   if (hvutil_transport_send(hvt, _ver, sizeof(our_ver),
+   fcopy_register_done))
return -EFAULT;
dm_reg_value = version;
break;
@@ -107,8 +114,7 @@ static int fcopy_handle_handshake(u32 version)
 */
return -EINVAL;
}
-   pr_debug("FCP: userspace daemon ver. %d registered\n", version);
-   hv_poll_channel(fcopy_transaction.recv_channel, fcopy_poll_wrapper);
+   pr_debug("FCP: userspace daemon ver. %d connected\n", version);
return 0;
 }
 
@@ -161,7 +167,7 @@ static void fcopy_send_data(struct work_struct *dummy)
}
 
fcopy_transaction.state = HVUTIL_USERSPACE_REQ;
-   rc = hvutil_transport_send(hvt, out_src, out_len);
+   rc = hvutil_transport_send(hvt, out_src, out_len, NULL);
if (rc) {
pr_debug("FCP: failed to communicate to the daemon: %d\n", rc);
if (cancel_delayed_work_sync(_timeout_work)) {
diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index cb1a916..5e1fdc8 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -102,6 +102,17 @@ static void kvp_poll_wrapper(void *channel)
hv_kvp_onchannelcallback(channel);
 }
 
+static void kvp_register_done(void)
+{
+   /*
+* If we're still negotiating with the host cancel the timeout
+* work to not poll the channel twice.
+*/
+   pr_debug("KVP: userspace daemon registered\n");
+   cancel_delayed_work_sync(_host_handshake_work);
+   hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
+}
+
 static void
 kvp_register(int reg_value)
 {
@@ -116,7 +127,8 @@ kvp_register(int reg_value)
kvp_msg->kvp_hdr.operation = reg_value;
strcpy(version, HV_DRV_VERSION);
 
-   hvutil_transport_send(hvt, kvp_msg, sizeof(*kvp_msg));
+   hvutil_transport_send(hvt, kvp_msg, sizeof(*kvp_msg),
+ kvp_register_done);
 

[PATCH 1/2] Drivers: hv: get rid of timeout in vmbus_open()

[K. Y. Srinivasan]

From: Vitaly Kuznetsov 

vmbus_teardown_gpadl() can result in infinite wait when it is called on 5
second timeout in vmbus_open(). The issue is caused by the fact that gpadl
teardown operation won't ever succeed for an opened channel and the timeout
isn't always enough. As a guest, we can always trust the host to respond to
our request (and there is nothing we can do if it doesn't).

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/channel.c |7 +--
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index a68830c..9a88c63 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -73,7 +73,6 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
void *in, *out;
unsigned long flags;
int ret, err = 0;
-   unsigned long t;
struct page *page;
 
spin_lock_irqsave(>lock, flags);
@@ -183,11 +182,7 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
goto error1;
}
 
-   t = wait_for_completion_timeout(_info->waitevent, 5*HZ);
-   if (t == 0) {
-   err = -ETIMEDOUT;
-   goto error1;
-   }
+   wait_for_completion(_info->waitevent);
 
spin_lock_irqsave(_connection.channelmsg_lock, flags);
list_del(_info->msglistentry);
-- 
1.7.4.1

Re: [PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

[Inki Dae]

Hi Javier,

2016년 06월 09일 09:17에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> Thanks for your feedback.
> 
> On 06/08/2016 07:09 PM, Inki Dae wrote:
>> Hi Javier,
>>
>> 2016년 06월 02일 23:20에 Javier Martinez Canillas 이(가) 쓴 글:
>>> Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
>>> hardware trigger support to the FIMD controller driver. But this broke
>>> the display in at least the Exynos5800 Peach Pi Chromebook.
>>>
>>> So until the issue is fixed, avoid using HW trigger for the Exynos5420
>>> based boards and use SW trigger as it was before the mentioned commit.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>>
>>> ---
>>>
>>> Hello Inki,
>>>
>>> Since commit a6f75aa161c5 landed in v4.7-rc1, I think $SUBJECT should be
>>> picked to make sure that v4.7 is released with the display working for
>>> the Exynos5420 based Chromebooks.
>>>
>>> We can then figure out what's wrong with the HW trigger support and fix
>>> it for v4.8.
>>
>> Agree. And below is a trivial comment.
>>
> 
> I'm glad that you agree.
> 
>>>
>>> Best regards,
>>> Javier
>>>
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
>>>  1 file changed, 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 1c23a8ff5e83..f10030ff00e6 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -170,14 +170,11 @@ static struct fimd_driver_data 
>>> exynos5420_fimd_driver_data = {
>>> .lcdblk_vt_shift = 24,
>>> .lcdblk_bypass_shift = 15,
>>> .lcdblk_mic_bypass_shift = 11,
>>> -   .trg_type = I80_HW_TRG,
>>> .has_shadowcon = 1,
>>> .has_vidoutcon = 1,
>>> .has_vtsel = 1,
>>> .has_mic_bypass = 1,
>>> .has_dp_clk = 1,
>>> -   .has_hw_trigger = 1,
>>> -   .has_trigger_per_te = 1,
>>
>> We don't need to remove above two lines. It would be enough to remove 
>> 'trg_type = I80_HW_TRG', which makes FIMD to be worked with SW trigger in 
>> default.
>>
> 
> I know that removing .trg_type is enough but I also removed those lines
> because the fields are not used if .trg_type != I80_HW_TRG. So there is
> no point to leave a set for unused fields.
> 
> We can latter add those one HW trigger support is fixed for Exynos5420.
> 

As of now, I can merge it but I think it would be not reasonable solution 
because potential problem still exists even we use SW trigger mode in default - 
ie., in case of using HW trigger mode at bootloader, same problem would happen 
as long as we don't support PSR mode support.

Thanks,
Inki Dae

>> Thanks,
>> Inki Dae
>>
>>>  };
>>>  
>>>  struct fimd_context {
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> Best regards,
> 

Re: [PATCH v3 1/7] leds: convert IDE trigger to common disk trigger

[Stephan Linz]

Hi Jacek,

to keep the original ide-disk trigger is good idea to be backward
compatible. I'll submit a new v4 patch set.


br,
Stephan

Am 09.06.2016 um 09:29 schrieb Jacek Anaszewski:
> Hi Stephan,
> 
> Thanks for the patch.
> 
> Generally it looks ok, with one exception: we have to keep
> ide-disk trigger, so as not to break existing users.
> Please just register two triggers in ledtrig_disk_init,
> similarly as it was done for mtd trigger:
> 
> drivers/leds/trigger/ledtrig-mtd.c
> 
> Thanks,
> Jacek Anaszewski
> 
> 
> On 06/09/2016 12:29 AM, Stephan Linz wrote:
>> This patch converts the IDE specific LED trigger to a generic disk
>> activity LED trigger. The libata core is now a trigger source just
>> like before the IDE disk driver. It's merely a replacement of the
>> string ide by disk.
>>
>> The patch is taken from http://dev.gentoo.org/~josejx/ata.patch and is
>> widely used by any ibook/powerbook owners with great satisfaction.
>> Likewise, it is very often used successfully on different ARM platforms.
>>
>> The original patch was split into different parts to clarify platform
>> independent and dependent changes.
>>
>> Cc: Joseph Jezak 
>> Cc: Nico Macrionitis 
>> Cc: Jörg Sommer 
>> Cc: Richard Purdie 
>> Cc: Jacek Anaszewski 
>> Signed-off-by: Stephan Linz 
>> ---
>> Changes in v3:
>>- Port to kernel 4.x
>>- Split into platform independent and dependent parts.
>>
>> v2: https://patchwork.ozlabs.org/patch/117485/
>> v1: http://dev.gentoo.org/~josejx/ata.patch
>> ---
>>   drivers/ata/libata-core.c|  4 
>>   drivers/ide/ide-disk.c   |  2 +-
>>   drivers/leds/leds-hp6xx.c|  2 +-
>>   drivers/leds/trigger/Kconfig |  8 
>>   drivers/leds/trigger/Makefile|  2 +-
>>   .../trigger/{ledtrig-ide-disk.c => ledtrig-disk.c}   | 20
>> ++--
>>   include/linux/leds.h |  6 +++---
>>   7 files changed, 24 insertions(+), 20 deletions(-)
>>   rename drivers/leds/trigger/{ledtrig-ide-disk.c => ledtrig-disk.c}
>> (50%)
>>
>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> index 6be7770..2eca572 100644
>> --- a/drivers/ata/libata-core.c
>> +++ b/drivers/ata/libata-core.c
>> @@ -69,6 +69,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>
>> @@ -5072,6 +5073,9 @@ void ata_qc_complete(struct ata_queued_cmd *qc)
>>   {
>>   struct ata_port *ap = qc->ap;
>>
>> +/* Trigger the LED (if available) */
>> +ledtrig_disk_activity();
>> +
>>   /* XXX: New EH and old EH use different mechanisms to
>>* synchronize EH with regular execution path.
>>*
>> diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
>> index 05dbcce..5ceb176 100644
>> --- a/drivers/ide/ide-disk.c
>> +++ b/drivers/ide/ide-disk.c
>> @@ -186,7 +186,7 @@ static ide_startstop_t ide_do_rw_disk(ide_drive_t
>> *drive, struct request *rq,
>>   BUG_ON(drive->dev_flags & IDE_DFLAG_BLOCKED);
>>   BUG_ON(rq->cmd_type != REQ_TYPE_FS);
>>
>> -ledtrig_ide_activity();
>> +ledtrig_disk_activity();
>>
>>   pr_debug("%s: %sing: block=%llu, sectors=%u\n",
>>drive->name, rq_data_dir(rq) == READ ? "read" : "writ",
>> diff --git a/drivers/leds/leds-hp6xx.c b/drivers/leds/leds-hp6xx.c
>> index a6b8db0..137969f 100644
>> --- a/drivers/leds/leds-hp6xx.c
>> +++ b/drivers/leds/leds-hp6xx.c
>> @@ -50,7 +50,7 @@ static struct led_classdev hp6xx_red_led = {
>>
>>   static struct led_classdev hp6xx_green_led = {
>>   .name= "hp6xx:green",
>> -.default_trigger= "ide-disk",
>> +.default_trigger= "disk-activity",
>>   .brightness_set= hp6xxled_green_set,
>>   .flags= LED_CORE_SUSPENDRESUME,
>>   };
>> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
>> index 9893d91..3f9ddb9 100644
>> --- a/drivers/leds/trigger/Kconfig
>> +++ b/drivers/leds/trigger/Kconfig
>> @@ -33,12 +33,12 @@ config LEDS_TRIGGER_ONESHOT
>>
>> If unsure, say Y.
>>
>> -config LEDS_TRIGGER_IDE_DISK
>> -bool "LED IDE Disk Trigger"
>> -depends on IDE_GD_ATA
>> +config LEDS_TRIGGER_DISK
>> +bool "LED Disk Trigger"
>> +depends on IDE_GD_ATA || ATA
>>   depends on LEDS_TRIGGERS
>>   help
>> -  This allows LEDs to be controlled by IDE disk activity.
>> +  This allows LEDs to be controlled by disk activity.
>> If unsure, say Y.
>>
>>   config LEDS_TRIGGER_MTD
>> diff --git a/drivers/leds/trigger/Makefile
>> b/drivers/leds/trigger/Makefile
>> index 8cc64a4..a72c43c 100644
>> --- a/drivers/leds/trigger/Makefile
>> +++ b/drivers/leds/trigger/Makefile
>> @@ -1,6 +1,6 @@
>>   obj-$(CONFIG_LEDS_TRIGGER_TIMER)+= ledtrig-timer.o
>>   

Re: ipv4: Constrain UFO fragment sizes to multiples of 8 bytes

[Hannes Frederic Sowa]

On 09.06.2016 06:59, Cong Wang wrote:
> (Cc'ing netdev...)
> 
> On Mon, Jun 6, 2016 at 1:24 PM, Steven Caron  wrote:
>> Back in 2011, Bill Sommerfeld submitted an update to prevent ip_append_data 
>> to create malformed packets:
>>  Commit: d9be4f7a6f5a8da3133b832eca41c3591420b1ca
>>
>> Now we're finding that we need to apply the same logic to ip_append_page  to 
>> get nfs to work with udp when UFO is enabled:

Uhh, absolutely for the same reason as described in the referred commit.
 Can you send a patch?

Thanks,
Hannes

[PATCH 3/3] staging: lustre: lnet: optimize memory foot print for lnet_libmd

[James Simmons]

From: Bruno Faccini 

The lnet_libmd struct fields have been re-ordered to optimize its
memory foot-print.

Signed-off-by: Bruno Faccini 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4430
Reviewed-on: http://review.whamcloud.com/18586
Reviewed-by: Andreas Dilger 
Reviewed-by: Doug Oucharek 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 .../staging/lustre/include/linux/lnet/lib-types.h  |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h 
b/drivers/staging/lustre/include/linux/lnet/lib-types.h
index 7967b01..79a4ecf 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-types.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h
@@ -151,9 +151,9 @@ typedef struct lnet_libmd {
int  md_refcount;
unsigned int md_options;
unsigned int md_flags;
+   unsigned int md_niov;   /* # frags at end of struct */
void*md_user_ptr;
lnet_eq_t   *md_eq;
-   unsigned int md_niov;   /* # frags */
union {
struct kvec iov[LNET_MAX_IOV];
lnet_kiov_t kiov[LNET_MAX_IOV];
-- 
1.7.1

[PATCH 0/3] staging: lustre: lnet: bug fixs for 4.7-rc2

[James Simmons]

Here are the latest fixes for LNet. One fix covers a bug
for the infiniband driver that happens when the o2iblnd
intereface is pinged before it is finishing setting up.
The next patch set from Bruno adds kmem_caches for the
LNet layer.

Bruno Faccini (2):
  staging: lustre: lnet: Allocate MEs and small MDs in own kmem_caches
  staging: lustre: lnet: optimize memory foot print for lnet_libmd

Doug Oucharek (1):
  staging: lustre: lnet: Don't access NULL NI on failure path

 .../staging/lustre/include/linux/lnet/lib-lnet.h   |   36 ++--
 .../staging/lustre/include/linux/lnet/lib-types.h  |2 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c |7 ++-
 drivers/staging/lustre/lnet/lnet/api-ni.c  |   45 
 4 files changed, 82 insertions(+), 8 deletions(-)

Re: [RESEND PATCH v2 1/2] device property: Add function to search for named child of device

[Rafael J. Wysocki]

On 6/9/2016 5:13 PM, Adam Thomson wrote:

For device nodes in both DT and ACPI, it possible to have named
child nodes which contain properties (an existing example being
gpio-leds). This adds a function to find a named child node for
a device which can be used by drivers for property retrieval.

For ACPI data node name matching, a helper function is also added
which returns false if CONFIG_ACPI is not set, otherwise it
performs a string comparison on the data node name. This avoids
using the acpi_data_node struct for non CONFIG_ACPI builds,
which would otherwise cause a build failure.

Signed-off-by: Adam Thomson 
Tested-by: Sathyanarayana Nujella 


For some reason that didn't make it into the linux-acpi list, or at 
least I can't see it there.



---

Changes in v2:
  - Rebase to v4.7-rc1

  drivers/base/property.c  | 28 
  include/acpi/acpi_bus.h  |  7 +++
  include/linux/acpi.h |  6 ++
  include/linux/property.h |  3 +++
  4 files changed, 44 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index f38c21d..573b361 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -888,6 +888,34 @@ struct fwnode_handle *device_get_next_child_node(struct 
device *dev,
  EXPORT_SYMBOL_GPL(device_get_next_child_node);

  /**
+ * device_get_named_child_node - Return first matching named child node handle
+ * @dev: Device to find the named child node for.
+ * @childname: String to match child node name against.
+ */
+struct fwnode_handle *device_get_named_child_node(struct device *dev,
+ const char *childname)
+{
+   struct fwnode_handle *child;
+
+   /*
+* Find first matching named child node of this device.
+* For ACPI this will be a data only sub-node.
+*/
+   device_for_each_child_node(dev, child) {
+   if (is_of_node(child)) {
+   if (!strcasecmp(to_of_node(child)->name, childname))


Why do you use strcasecmp() here?


+   return child;
+   } else if (is_acpi_data_node(child)) {
+   if (acpi_data_node_match(child, childname))
+   return child;
+   }
+   }
+
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(device_get_named_child_node);
+
+/**
   * fwnode_handle_put - Drop reference to a device node
   * @fwnode: Pointer to the device node to drop the reference to.
   *
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 788c6c3..993bdd0 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -420,6 +420,13 @@ static inline struct acpi_data_node 
*to_acpi_data_node(struct fwnode_handle *fwn
container_of(fwnode, struct acpi_data_node, fwnode) : NULL;
  }

+static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
+   const char *name)
+{
+   return is_acpi_data_node(fwnode) ?
+   (!strcasecmp(to_acpi_data_node(fwnode)->name, name)) : false;
+}


Is there any particular reason to introduce this function instead of 
doing the test in device_get_named_child_node() directly?



+
  static inline struct fwnode_handle *acpi_fwnode_handle(struct acpi_device 
*adev)
  {
return >fwnode;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 288fac5..03039c4 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -568,6 +568,12 @@ static inline struct acpi_data_node 
*to_acpi_data_node(struct fwnode_handle *fwn
return NULL;
  }

+static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
+   const char *name)
+{
+   return false;
+}
+
  static inline struct fwnode_handle *acpi_fwnode_handle(struct acpi_device 
*adev)
  {
return NULL;
diff --git a/include/linux/property.h b/include/linux/property.h
index ecab11e..3a2f9ae 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -77,6 +77,9 @@ struct fwnode_handle *device_get_next_child_node(struct 
device *dev,
for (child = device_get_next_child_node(dev, NULL); child;  \
 child = device_get_next_child_node(dev, child))

+struct fwnode_handle *device_get_named_child_node(struct device *dev,
+ const char *childname);
+
  void fwnode_handle_put(struct fwnode_handle *fwnode);

  unsigned int device_get_child_node_count(struct device *dev);
--


Mika, Heikki, Andy, any feedback on this one?

[PATCH 4.2.y-ckt 165/206] EDAC: Increment correct counter in edac_inc_ue_error()

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Emmanouil Maroudas 

commit 993f88f1cc7f0879047ff353e824e5cc8f10adfc upstream.

Fix typo in edac_inc_ue_error() to increment ue_noinfo_count instead of
ce_noinfo_count.

Signed-off-by: Emmanouil Maroudas 
Cc: Mauro Carvalho Chehab 
Cc: linux-edac 
Fixes: 4275be635597 ("edac: Change internal representation to work with layers")
Link: 
http://lkml.kernel.org/r/1461425580-5898-1-git-send-email-emmanouil.marou...@gmail.com
Signed-off-by: Borislav Petkov 
Signed-off-by: Kamal Mostafa 
---
 drivers/edac/edac_mc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index e315e5e..aa7f137 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -966,7 +966,7 @@ static void edac_inc_ue_error(struct mem_ctl_info *mci,
mci->ue_mc += count;
 
if (!enable_per_layer_report) {
-   mci->ce_noinfo_count += count;
+   mci->ue_noinfo_count += count;
return;
}
 
-- 
2.7.4

[PATCH 4.2.y-ckt 161/206] cx23885: uninitialized variable in cx23885_av_work_handler()

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Dan Carpenter 

commit 60587bd0680507f48ae3a7360983228fd207de8a upstream.

The "handled" variable could be uninitialized if the
interrupt_service_routine() call back hasn't been implimented or if it
has been implemented but doesn't initialize "handled" to zero at the
start.  For example, adv76xx_isr() only sets "handled" to true.

Fixes: 44b153ca639f ('[media] m5mols: Add ISO sensitivity controls')

Signed-off-by: Dan Carpenter 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 drivers/media/pci/cx23885/cx23885-av.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/cx23885/cx23885-av.c 
b/drivers/media/pci/cx23885/cx23885-av.c
index 877dad8..e7d4406 100644
--- a/drivers/media/pci/cx23885/cx23885-av.c
+++ b/drivers/media/pci/cx23885/cx23885-av.c
@@ -24,7 +24,7 @@ void cx23885_av_work_handler(struct work_struct *work)
 {
struct cx23885_dev *dev =
   container_of(work, struct cx23885_dev, cx25840_work);
-   bool handled;
+   bool handled = false;
 
v4l2_subdev_call(dev->sd_cx25840, core, interrupt_service_routine,
 PCI_MSK_AV_CORE, );
-- 
2.7.4

[PATCH 4.2.y-ckt 164/206] perf test: Ignore kcore files in the "vmlinux matches kallsyms" test

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Arnaldo Carvalho de Melo 

commit 53d0fe68275dbdaf6a532bb4e87f00db5d36c140 upstream.

Before:

  # perf test -v kallsyms

  Maps only in vmlinux:
   81d5e000-81ec3ac8 115e000 [kernel].init.text
   81ec3ac8-a000 12c3ac8 [kernel].exit.text
   a000-a000c000 0 [fjes]
   a000c000-a0017000 0 [video]
   a0017000-a001c000 0 [grace]

   a0a7f000-a0ba5000 0 [xfs]
   a0ba5000- 0 [veth]
  Maps in vmlinux with a different name in kallsyms:
  Maps only in kallsyms:
   8810-88001000b000 8103000 [kernel.kallsyms]
   88001000b000-8801 8001000e000 [kernel.kallsyms]
   8801-c900 8013000 [kernel.kallsyms]

   a000-ff60 7fffa0003000 [kernel.kallsyms]
   ff60- 7f603000 [kernel.kallsyms]
  test child finished with -1
   end 
  vmlinux symtab matches kallsyms: FAILED!
  #

After:

  # perf test -v 1
   1: vmlinux symtab matches kallsyms  :
  --- start ---
  test child forked, pid 7058
  Looking at the vmlinux_path (8 entries long)
  Using /lib/modules/4.6.0-rc1+/build/vmlinux for symbols
  0x81076870: diff end addr for aesni_gcm_dec v: 0x810791f2 k: 
0x81076902
  0x81079200: diff end addr for aesni_gcm_enc v: 0x8107bb03 k: 
0x81079292
  0x8107e8d0: diff end addr for aesni_gcm_enc_avx_gen2 v: 
0x81083e76 k: 0x8107e943
  0x81083e80: diff end addr for aesni_gcm_dec_avx_gen2 v: 
0x81089611 k: 0x81083ef3
  0x81089990: diff end addr for aesni_gcm_enc_avx_gen4 v: 
0x8108e7c4 k: 0x81089a03
  0x8108e7d0: diff end addr for aesni_gcm_dec_avx_gen4 v: 
0x810937ef k: 0x8108e843
  Maps only in vmlinux:
   81d5e000-81ec3ac8 115e000 [kernel].init.text
   81ec3ac8-a000 12c3ac8 [kernel].exit.text
  Maps in vmlinux with a different name in kallsyms:
  Maps only in kallsyms:
  test child finished with -1
   end 
 vmlinux symtab matches kallsyms: FAILED!
  #

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Fixes: 8e0cf965f95e ("perf symbols: Add support for reading from /proc/kcore")
Link: http://lkml.kernel.org/n/tip-n6vrwt9t89w8k769y349g...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Kamal Mostafa 
---
 tools/perf/tests/vmlinux-kallsyms.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/vmlinux-kallsyms.c 
b/tools/perf/tests/vmlinux-kallsyms.c
index b34c5fc..8de34ea 100644
--- a/tools/perf/tests/vmlinux-kallsyms.c
+++ b/tools/perf/tests/vmlinux-kallsyms.c
@@ -54,8 +54,14 @@ int test__vmlinux_matches_kallsyms(void)
 * Step 3:
 *
 * Load and split /proc/kallsyms into multiple maps, one per module.
+* Do not use kcore, as this test was designed before kcore support
+* and has parts that only make sense if using the non-kcore code.
+* XXX: extend it to stress the kcorre code as well, hint: the list
+* of modules extracted from /proc/kcore, in its current form, can't
+* be compacted against the list of modules found in the "vmlinux"
+* code and with the one got from /proc/modules from the "kallsyms" 
code.
 */
-   if (machine__load_kallsyms(, "/proc/kallsyms", type, NULL) <= 
0) {
+   if (__machine__load_kallsyms(, "/proc/kallsyms", type, true, 
NULL) <= 0) {
pr_debug("dso__load_kallsyms ");
goto out;
}
-- 
2.7.4

[PATCH 4.2.y-ckt 174/206] tty: vt, return error when con_startup fails

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Jiri Slaby 

commit 6798df4c5fe0a7e6d2065cf79649a794e5ba7114 upstream.

When csw->con_startup() fails in do_register_con_driver, we return no
error (i.e. 0). This was changed back in 2006 by commit 3e795de763.
Before that we used to return -ENODEV.

So fix the return value to be -ENODEV in that case again.

Fixes: 3e795de763 ("VT binding: Add binding/unbinding support for the VT 
console")
Signed-off-by: Jiri Slaby 
Reported-by: "Dan Carpenter" 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/tty/vt/vt.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 4462d16..cf20282 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3583,9 +3583,10 @@ static int do_register_con_driver(const struct consw 
*csw, int first, int last)
goto err;
 
desc = csw->con_startup();
-
-   if (!desc)
+   if (!desc) {
+   retval = -ENODEV;
goto err;
+   }
 
retval = -EINVAL;
 
-- 
2.7.4

[PATCH 4.2.y-ckt 170/206] taskstats: fix nl parsing in accounting/getdelays.c

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Nicolas Dichtel 

commit 570d8e9398011a63590c281a36cdce311196608e upstream.

The type TASKSTATS_TYPE_NULL should always be ignored.

When jumping to the next attribute, only the length of the current
attribute should be added, not the length of all nested attributes.
This last bug was not visible before commit 80df554275c2, because the
kernel didn't put more than two nested attributes.

Fixes: a3baf649ca9c ("[PATCH] per-task-delay-accounting: documentation")
Fixes: 80df554275c2 ("taskstats: use the libnl API to align nlattr on 64-bit")
Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 Documentation/accounting/getdelays.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/accounting/getdelays.c 
b/Documentation/accounting/getdelays.c
index f405780..9497d20 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -504,6 +504,8 @@ int main(int argc, char *argv[])
if (!loop)
goto done;
break;
+   case TASKSTATS_TYPE_NULL:
+   break;
default:
fprintf(stderr, "Unknown nested"
" nla_type %d\n",
@@ -511,7 +513,8 @@ int main(int argc, char *argv[])
break;
}
len2 += NLA_ALIGN(na->nla_len);
-   na = (struct nlattr *) ((char *) na + 
len2);
+   na = (struct nlattr *)((char *)na +
+  
NLA_ALIGN(na->nla_len));
}
break;
 
-- 
2.7.4

[PATCH 4.2.y-ckt 171/206] char: Drop bogus dependency of DEVPORT on !M68K

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Geert Uytterhoeven 

commit 309124e2648d668a0c23539c5078815660a4a850 upstream.

According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k
update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is
defined.

However, commit 153dcc54df826d2f ("[PATCH] mem driver: fix conditional
on isa i/o support") accidentally changed an "||" into an "&&",
disabling it completely on m68k. This logic was retained when
introducing the DEVPORT symbol in commit 4f911d64e04a44c4 ("Make
/dev/port conditional on config symbol").

Drop the bogus dependency on !M68K to fix this.

Fixes: 153dcc54df826d2f ("[PATCH] mem driver: fix conditional on isa i/o 
support")
Signed-off-by: Geert Uytterhoeven 
Tested-by: Al Stone 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/char/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index a043107..b130d38 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -584,7 +584,6 @@ config TELCLOCK
 
 config DEVPORT
bool
-   depends on !M68K
depends on ISA || PCI
default y
 
-- 
2.7.4

[PATCH 4.2.y-ckt 141/206] dma-debug: avoid spinlock recursion when disabling dma-debug

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= 

commit 3017cd63f26fc655d56875aaf497153ba60e9edf upstream.

With netconsole (at least) the pr_err("...  disablingn") call can
recurse back into the dma-debug code, where it'll try to grab
free_entries_lock again.  Avoid the problem by doing the printk after
dropping the lock.

Link: 
http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 lib/dma-debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index d8b4df8..0c66f76 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -657,9 +657,9 @@ static struct dma_debug_entry *dma_entry_alloc(void)
spin_lock_irqsave(_entries_lock, flags);
 
if (list_empty(_entries)) {
-   pr_err("DMA-API: debugging out of memory - disabling\n");
global_disable = true;
spin_unlock_irqrestore(_entries_lock, flags);
+   pr_err("DMA-API: debugging out of memory - disabling\n");
return NULL;
}
 
-- 
2.7.4

[PATCH 4.2.y-ckt 145/206] MIPS: lib: Mark intrinsics notrace

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Harvey Hunt 

commit aedcfbe06558a9f53002e82d5be64c6c94687726 upstream.

On certain MIPS32 devices, the ftrace tracer "function_graph" uses
__lshrdi3() during the capturing of trace data. ftrace then attempts to
trace __lshrdi3() which leads to infinite recursion and a stack overflow.
Fix this by marking __lshrdi3() as notrace. Mark the other compiler
intrinsics as notrace in case the compiler decides to use them in the
ftrace path.

Signed-off-by: Harvey Hunt 
Cc: 
Cc: 
Patchwork: https://patchwork.linux-mips.org/patch/13354/
Signed-off-by: Ralf Baechle 
[ kamal: backport to 4.2-stable: no bswap[ds]i.c ]
Signed-off-by: Kamal Mostafa 
---
 arch/mips/lib/ashldi3.c | 2 +-
 arch/mips/lib/ashrdi3.c | 2 +-
 arch/mips/lib/cmpdi2.c  | 2 +-
 arch/mips/lib/lshrdi3.c | 2 +-
 arch/mips/lib/ucmpdi2.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/mips/lib/ashldi3.c b/arch/mips/lib/ashldi3.c
index beb80f31..927dc94 100644
--- a/arch/mips/lib/ashldi3.c
+++ b/arch/mips/lib/ashldi3.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-long long __ashldi3(long long u, word_type b)
+long long notrace __ashldi3(long long u, word_type b)
 {
DWunion uu, w;
word_type bm;
diff --git a/arch/mips/lib/ashrdi3.c b/arch/mips/lib/ashrdi3.c
index c884a91..9fdf1a5 100644
--- a/arch/mips/lib/ashrdi3.c
+++ b/arch/mips/lib/ashrdi3.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-long long __ashrdi3(long long u, word_type b)
+long long notrace __ashrdi3(long long u, word_type b)
 {
DWunion uu, w;
word_type bm;
diff --git a/arch/mips/lib/cmpdi2.c b/arch/mips/lib/cmpdi2.c
index 8c13064..06857da 100644
--- a/arch/mips/lib/cmpdi2.c
+++ b/arch/mips/lib/cmpdi2.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-word_type __cmpdi2(long long a, long long b)
+word_type notrace __cmpdi2(long long a, long long b)
 {
const DWunion au = {
.ll = a
diff --git a/arch/mips/lib/lshrdi3.c b/arch/mips/lib/lshrdi3.c
index dcf8d68..3645474 100644
--- a/arch/mips/lib/lshrdi3.c
+++ b/arch/mips/lib/lshrdi3.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-long long __lshrdi3(long long u, word_type b)
+long long notrace __lshrdi3(long long u, word_type b)
 {
DWunion uu, w;
word_type bm;
diff --git a/arch/mips/lib/ucmpdi2.c b/arch/mips/lib/ucmpdi2.c
index bb4cb2f..bd599f5 100644
--- a/arch/mips/lib/ucmpdi2.c
+++ b/arch/mips/lib/ucmpdi2.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-word_type __ucmpdi2(unsigned long long a, unsigned long long b)
+word_type notrace __ucmpdi2(unsigned long long a, unsigned long long b)
 {
const DWunion au = {.ll = a};
const DWunion bu = {.ll = b};
-- 
2.7.4

[PATCH 4.2.y-ckt 146/206] hpfs: fix remount failure when there are no options changed

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Mikulas Patocka 

commit 44d51706b4685f965cd32acde3fe0fcc1e6198e8 upstream.

Commit ce657611baf9 ("hpfs: kstrdup() out of memory handling") checks if
the kstrdup function returns NULL due to out-of-memory condition.

However, if we are remounting a filesystem with no change to
filesystem-specific options, the parameter data is NULL.  In this case,
kstrdup returns NULL (because it was passed NULL parameter), although no
out of memory condition exists.  The mount syscall then fails with
ENOMEM.

This patch fixes the bug.  We fail with ENOMEM only if data is non-NULL.

The patch also changes the call to replace_mount_options - if we didn't
pass any filesystem-specific options, we don't call
replace_mount_options (thus we don't erase existing reported options).

Fixes: ce657611baf9 ("hpfs: kstrdup() out of memory handling")
Signed-off-by: Mikulas Patocka 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 fs/hpfs/super.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/hpfs/super.c b/fs/hpfs/super.c
index 68a9bed..8c2b6e9 100644
--- a/fs/hpfs/super.c
+++ b/fs/hpfs/super.c
@@ -455,7 +455,7 @@ static int hpfs_remount_fs(struct super_block *s, int 
*flags, char *data)
struct hpfs_sb_info *sbi = hpfs_sb(s);
char *new_opts = kstrdup(data, GFP_KERNEL);
 
-   if (!new_opts)
+   if (data && !new_opts)
return -ENOMEM;
 
sync_filesystem(s);
@@ -493,7 +493,8 @@ static int hpfs_remount_fs(struct super_block *s, int 
*flags, char *data)
 
if (!(*flags & MS_RDONLY)) mark_dirty(s, 1);
 
-   replace_mount_options(s, new_opts);
+   if (new_opts)
+   replace_mount_options(s, new_opts);
 
hpfs_unlock(s);
return 0;
-- 
2.7.4

[PATCH 4.2.y-ckt 142/206] dell-rbtn: Ignore ACPI notifications if device is suspended

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Gabriele Mazzotta 

commit ff8651237f39cea60dc89b2d9f25d9ede3fc82c0 upstream.

Some BIOSes unconditionally send an ACPI notification to RBTN when the
system is resuming from suspend. This makes dell-rbtn send an input
event to userspace as if a function key was pressed. Prevent this by
ignoring all the notifications received while the device is suspended.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=106031
Signed-off-by: Gabriele Mazzotta 
Tested-by: Alex Hung 
Reviewed-by: Pali Rohár 
Signed-off-by: Darren Hart 
Signed-off-by: Kamal Mostafa 
---
 drivers/platform/x86/dell-rbtn.c | 56 
 1 file changed, 56 insertions(+)

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index cd410e3..d33e9ad 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -28,6 +28,7 @@ struct rbtn_data {
enum rbtn_type type;
struct rfkill *rfkill;
struct input_dev *input_dev;
+   bool suspended;
 };
 
 
@@ -220,9 +221,55 @@ static const struct acpi_device_id rbtn_ids[] = {
{ "", 0 },
 };
 
+#ifdef CONFIG_PM_SLEEP
+static void ACPI_SYSTEM_XFACE rbtn_clear_suspended_flag(void *context)
+{
+   struct rbtn_data *rbtn_data = context;
+
+   rbtn_data->suspended = false;
+}
+
+static int rbtn_suspend(struct device *dev)
+{
+   struct acpi_device *device = to_acpi_device(dev);
+   struct rbtn_data *rbtn_data = acpi_driver_data(device);
+
+   rbtn_data->suspended = true;
+
+   return 0;
+}
+
+static int rbtn_resume(struct device *dev)
+{
+   struct acpi_device *device = to_acpi_device(dev);
+   struct rbtn_data *rbtn_data = acpi_driver_data(device);
+   acpi_status status;
+
+   /*
+* Upon resume, some BIOSes send an ACPI notification thet triggers
+* an unwanted input event. In order to ignore it, we use a flag
+* that we set at suspend and clear once we have received the extra
+* ACPI notification. Since ACPI notifications are delivered
+* asynchronously to drivers, we clear the flag from the workqueue
+* used to deliver the notifications. This should be enough
+* to have the flag cleared only after we received the extra
+* notification, if any.
+*/
+   status = acpi_os_execute(OSL_NOTIFY_HANDLER,
+rbtn_clear_suspended_flag, rbtn_data);
+   if (ACPI_FAILURE(status))
+   rbtn_clear_suspended_flag(rbtn_data);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(rbtn_pm_ops, rbtn_suspend, rbtn_resume);
+
 static struct acpi_driver rbtn_driver = {
.name = "dell-rbtn",
.ids = rbtn_ids,
+   .drv.pm = _pm_ops,
.ops = {
.add = rbtn_add,
.remove = rbtn_remove,
@@ -384,6 +431,15 @@ static void rbtn_notify(struct acpi_device *device, u32 
event)
 {
struct rbtn_data *rbtn_data = device->driver_data;
 
+   /*
+* Some BIOSes send a notification at resume.
+* Ignore it to prevent unwanted input events.
+*/
+   if (rbtn_data->suspended) {
+   dev_dbg(>dev, "ACPI notification ignored\n");
+   return;
+   }
+
if (event != 0x80) {
dev_info(>dev, "Received unknown event (0x%x)\n",
 event);
-- 
2.7.4

[PATCH 4.2.y-ckt 143/206] Input: xpad - prevent spurious input from wired Xbox 360 controllers

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Cameron Gutman 

commit 1ff5fa3c6732f08e01ae12f12286d4728c9e4d86 upstream.

After initially connecting a wired Xbox 360 controller or sending it
a command to change LEDs, a status/response packet is interpreted as
controller input. This causes the state of buttons represented in
byte 2 of the controller data packet to be incorrect until the next
valid input packet. Wireless Xbox 360 controllers are not affected.

Writing a new value to the LED device while holding the Start button
and running jstest is sufficient to reproduce this bug. An event will
come through with the Start button released.

Xboxdrv also won't attempt to read controller input from a packet
where byte 0 is non-zero. It also checks that byte 1 is 0x14, but
that value differs between wired and wireless controllers and this
code is shared by both. I think just checking byte 0 is enough to
eliminate unwanted packets.

The following are some examples of 3-byte status packets I saw:
01 03 02
02 03 00
03 03 03
08 03 00

Signed-off-by: Cameron Gutman 
Signed-off-by: Pavel Rojtberg 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Kamal Mostafa 
---
 drivers/input/joystick/xpad.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 38fd7b7..8aea29c 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -432,6 +432,10 @@ static void xpad360_process_packet(struct usb_xpad *xpad,
 {
struct input_dev *dev = xpad->dev;
 
+   /* valid pad data */
+   if (data[0] != 0x00)
+   return;
+
/* digital pad */
if (xpad->mapping & MAP_DPAD_TO_BUTTONS) {
/* dpad as buttons (left, right, up, down) */
-- 
2.7.4

[PATCH 4.2.y-ckt 116/206] fs/cifs: correctly to anonymous authentication for the NTLM(v2) authentication

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Stefan Metzmacher 

commit 1a967d6c9b39c226be1b45f13acd4d8a5ab3dc44 upstream.

Only server which map unknown users to guest will allow
access using a non-null NTLMv2_Response.

For Samba it's the "map to guest = bad user" option.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913

Signed-off-by: Stefan Metzmacher 
Signed-off-by: Steve French 
Signed-off-by: Kamal Mostafa 
---
 fs/cifs/sess.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index a58b100..8ffda50 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -895,22 +895,26 @@ sess_auth_ntlmv2(struct sess_data *sess_data)
/* LM2 password would be here if we supported it */
pSMB->req_no_secext.CaseInsensitivePasswordLength = 0;
 
-   /* calculate nlmv2 response and session key */
-   rc = setup_ntlmv2_rsp(ses, sess_data->nls_cp);
-   if (rc) {
-   cifs_dbg(VFS, "Error %d during NTLMv2 authentication\n", rc);
-   goto out;
-   }
+   if (ses->user_name != NULL) {
+   /* calculate nlmv2 response and session key */
+   rc = setup_ntlmv2_rsp(ses, sess_data->nls_cp);
+   if (rc) {
+   cifs_dbg(VFS, "Error %d during NTLMv2 
authentication\n", rc);
+   goto out;
+   }
 
-   memcpy(bcc_ptr, ses->auth_key.response + CIFS_SESS_KEY_SIZE,
-   ses->auth_key.len - CIFS_SESS_KEY_SIZE);
-   bcc_ptr += ses->auth_key.len - CIFS_SESS_KEY_SIZE;
+   memcpy(bcc_ptr, ses->auth_key.response + CIFS_SESS_KEY_SIZE,
+   ses->auth_key.len - CIFS_SESS_KEY_SIZE);
+   bcc_ptr += ses->auth_key.len - CIFS_SESS_KEY_SIZE;
 
-   /* set case sensitive password length after tilen may get
-* assigned, tilen is 0 otherwise.
-*/
-   pSMB->req_no_secext.CaseSensitivePasswordLength =
-   cpu_to_le16(ses->auth_key.len - CIFS_SESS_KEY_SIZE);
+   /* set case sensitive password length after tilen may get
+* assigned, tilen is 0 otherwise.
+*/
+   pSMB->req_no_secext.CaseSensitivePasswordLength =
+   cpu_to_le16(ses->auth_key.len - CIFS_SESS_KEY_SIZE);
+   } else {
+   pSMB->req_no_secext.CaseSensitivePasswordLength = 0;
+   }
 
if (ses->capabilities & CAP_UNICODE) {
if (sess_data->iov[0].iov_len % 2) {
-- 
2.7.4

[PATCH 4.2.y-ckt 121/206] xfs: skip stale inodes in xfs_iflush_cluster

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Dave Chinner 

commit 7d3aa7fe970791f1a674b14572a411accf2f4d4e upstream.

We don't write back stale inodes so we should skip them in
xfs_iflush_cluster, too.

Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dave Chinner 
Signed-off-by: Kamal Mostafa 
---
 fs/xfs/xfs_inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 22b249f..01f3e07 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -3166,6 +3166,7 @@ xfs_iflush_cluster(
 */
spin_lock(>i_flags_lock);
if (!iq->i_ino ||
+   __xfs_iflags_test(iq, XFS_ISTALE) ||
(XFS_INO_TO_AGINO(mp, iq->i_ino) & mask) != first_index) {
spin_unlock(>i_flags_lock);
continue;
-- 
2.7.4

[PATCH 4.2.y-ckt 119/206] xfs: xfs_iflush_cluster fails to abort on error

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Dave Chinner 

commit b1438f477934f5a4d5a44df26f3079a7575d5946 upstream.

When a failure due to an inode buffer occurs, the error handling
fails to abort the inode writeback correctly. This can result in the
inode being reclaimed whilst still in the AIL, leading to
use-after-free situations as well as filesystems that cannot be
unmounted as the inode log items left in the AIL never get removed.

Fix this by ensuring fatal errors from xfs_imap_to_bp() result in
the inode flush being aborted correctly.

Reported-by: Shyam Kaushik 
Diagnosed-by: Shyam Kaushik 
Tested-by: Shyam Kaushik 
Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dave Chinner 
Signed-off-by: Kamal Mostafa 
---
 fs/xfs/xfs_inode.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 3da9f4d..13c58cf 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -3286,7 +3286,7 @@ xfs_iflush(
struct xfs_buf  **bpp)
 {
struct xfs_mount*mp = ip->i_mount;
-   struct xfs_buf  *bp;
+   struct xfs_buf  *bp = NULL;
struct xfs_dinode   *dip;
int error;
 
@@ -3328,14 +3328,22 @@ xfs_iflush(
}
 
/*
-* Get the buffer containing the on-disk inode.
+* Get the buffer containing the on-disk inode. We are doing a try-lock
+* operation here, so we may get  an EAGAIN error. In that case, we
+* simply want to return with the inode still dirty.
+*
+* If we get any other error, we effectively have a corruption situation
+* and we cannot flush the inode, so we treat it the same as failing
+* xfs_iflush_int().
 */
error = xfs_imap_to_bp(mp, NULL, >i_imap, , , XBF_TRYLOCK,
   0);
-   if (error || !bp) {
+   if (error == -EAGAIN) {
xfs_ifunlock(ip);
return error;
}
+   if (error)
+   goto corrupt_out;
 
/*
 * First flush out the inode that xfs_iflush was called with.
@@ -3363,7 +3371,8 @@ xfs_iflush(
return 0;
 
 corrupt_out:
-   xfs_buf_relse(bp);
+   if (bp)
+   xfs_buf_relse(bp);
xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE);
 cluster_corrupt_out:
error = -EFSCORRUPTED;
-- 
2.7.4

[PATCH 4.2.y-ckt 122/206] KVM: MTRR: remove MSR 0x2f8

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Andy Honig 

commit 9842df62004f366b9fed2423e24df10542ee0dc5 upstream.

MSR 0x2f8 accessed the 124th Variable Range MTRR ever since MTRR support
was introduced by 9ba075a664df ("KVM: MTRR support").

0x2f8 became harmful when 910a6aae4e2e ("KVM: MTRR: exactly define the
size of variable MTRRs") shrinked the array of VR MTRRs from 256 to 8,
which made access to index 124 out of bounds.  The surrounding code only
WARNs in this situation, thus the guest gained a limited read/write
access to struct kvm_arch_vcpu.

0x2f8 is not a valid VR MTRR MSR, because KVM has/advertises only 16 VR
MTRR MSRs, 0x200-0x20f.  Every VR MTRR is set up using two MSRs, 0x2f8
was treated as a PHYSBASE and 0x2f9 would be its PHYSMASK, but 0x2f9 was
not implemented in KVM, therefore 0x2f8 could never do anything useful
and getting rid of it is safe.

This fixes CVE-2016-3713.

Fixes: 910a6aae4e2e ("KVM: MTRR: exactly define the size of variable MTRRs")
Reported-by: David Matlack 
Signed-off-by: Andy Honig 
Signed-off-by: Radim Krčmář 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/kvm/mtrr.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 3f8c732..c146f3c 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -44,8 +44,6 @@ static bool msr_mtrr_valid(unsigned msr)
case MSR_MTRRdefType:
case MSR_IA32_CR_PAT:
return true;
-   case 0x2f8:
-   return true;
}
return false;
 }
-- 
2.7.4

[PATCH 4.2.y-ckt 120/206] xfs: fix inode validity check in xfs_iflush_cluster

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Dave Chinner 

commit 51b07f30a71c27405259a0248206ed4e22adbee2 upstream.

Some careless idiot(*) wrote crap code in commit 1a3e8f3 ("xfs:
convert inode cache lookups to use RCU locking") back in late 2010,
and so xfs_iflush_cluster checks the wrong inode for whether it is
still valid under RCU protection. Fix it to lock and check the
correct inode.

(*) Careless-idiot: Dave Chinner 

Discovered-by: Brain Foster 
Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dave Chinner 
Signed-off-by: Kamal Mostafa 
---
 fs/xfs/xfs_inode.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 13c58cf..22b249f 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -3164,13 +3164,13 @@ xfs_iflush_cluster(
 * We need to check under the i_flags_lock for a valid inode
 * here. Skip it if it is not valid or the wrong inode.
 */
-   spin_lock(>i_flags_lock);
-   if (!ip->i_ino ||
+   spin_lock(>i_flags_lock);
+   if (!iq->i_ino ||
(XFS_INO_TO_AGINO(mp, iq->i_ino) & mask) != first_index) {
-   spin_unlock(>i_flags_lock);
+   spin_unlock(>i_flags_lock);
continue;
}
-   spin_unlock(>i_flags_lock);
+   spin_unlock(>i_flags_lock);
 
/*
 * Do an un-protected check to see if the inode is dirty and
-- 
2.7.4

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Tue, May 31, 2016 at 5:27 AM, Srinivas Pandruvada
 wrote:
> Starting from Cherrytrail, multiple generation of Intel processors offers
> on package sensor hub. Several recent tablets, 2-in-1 convertible laptops
> are using ISH instead of external sensor hubs. This resulted in lack of
> support of sensor function like device rotation and auto backlight
> adjustment. In addition, depending on the OEM implementation, support of ISH
> is required to support low power sleep states.
>
> The support of ISH on Linux platforms is not new. Android platforms with
> Intel SoCs had this support for a while submitted by Daniel Drubin.
> This patcheset is reusing most of those changes with  clean up and
> removing Android platform specific changes.

Hi Srinivas,

Thanks for this patch series. I've got an HP Spectre x360 G2
(skylake), and I've built a 4.6.0 kernel with this driver patched in.
It detects the sensors hub, and creates IIO devices under
/sys/bus/iio/devices:

$ ls /sys/bus/iio/devices/
iio:device0  iio:device1  iio:device2  iio:device3  iio:device4
iio:device5  iio:device6  iio:device7  iio:device8  iio:device9
trigger0  trigger1  trigger2  trigger3  trigger4  trigger5  trigger6
trigger7  trigger8  trigger9

However, I haven't figured out how to test it yet. (This is the first
time I'm working with IIO). Do you have any test code or test
procedures to show if it is working?

Thanks,
g.

>
> This series is tested on:
> - Lenovo Yoga 260 with Skylake processor
> - HP Pavilion x2 detachable with Cherrytrail
>
> The user mode ABI is still same as external sensor hubs using Linux
> IIO. So existing user mode software should still work without change.
> This series primarily brings in new HID transport used in ISH.
>
> This series submitted as a RFC to try on several devices. We have
> received request from Linux users who wanted this support. So I hope all
> those users try and give feedback.
>
> Daniel Drubin (3):
>   hid: intel_ish-hid: ISH Transport layer
>   hid: intel-ish-hid: ipc layer
>   hid: intel-ish-hid: ISH HID client driver
>
> Srinivas Pandruvada (1):
>   Documentation: hid: Intel ISH HID document
>
>  Documentation/hid/intel-ish-hid.txt  |  375 +
>  drivers/hid/Kconfig  |2 +
>  drivers/hid/Makefile |2 +
>  drivers/hid/intel-ish-hid/Kconfig|   27 +
>  drivers/hid/intel-ish-hid/Makefile   |   20 +
>  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h  |  220 +
>  drivers/hid/intel-ish-hid/ipc/hw-ish.h   |   71 ++
>  drivers/hid/intel-ish-hid/ipc/ipc.c  |  710 
>  drivers/hid/intel-ish-hid/ipc/pci-ish.c  |  238 ++
>  drivers/hid/intel-ish-hid/ipc/utils.h|   65 ++
>  drivers/hid/intel-ish-hid/ishtp-hid-client.c |  672 +++
>  drivers/hid/intel-ish-hid/ishtp-hid.c|  201 +
>  drivers/hid/intel-ish-hid/ishtp-hid.h|  157 
>  drivers/hid/intel-ish-hid/ishtp/bus.c|  670 +++
>  drivers/hid/intel-ish-hid/ishtp/bus.h|   99 +++
>  drivers/hid/intel-ish-hid/ishtp/client.c | 1131 
> ++
>  drivers/hid/intel-ish-hid/ishtp/client.h |  196 +
>  drivers/hid/intel-ish-hid/ishtp/dma-if.c |  175 
>  drivers/hid/intel-ish-hid/ishtp/hbm.c|  911 +
>  drivers/hid/intel-ish-hid/ishtp/hbm.h|  319 
>  drivers/hid/intel-ish-hid/ishtp/init.c   |   94 +++
>  drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h  |  276 +++
>  include/trace/events/intel_ish.h |   30 +
>  23 files changed, 6661 insertions(+)
>  create mode 100644 Documentation/hid/intel-ish-hid.txt
>  create mode 100644 drivers/hid/intel-ish-hid/Kconfig
>  create mode 100644 drivers/hid/intel-ish-hid/Makefile
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/dma-if.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/init.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
>  create mode 100644 include/trace/events/intel_ish.h
>
> --
> 1.9.1
>

[PATCH 4.2.y-ckt 106/206] ring-buffer: Use long for nr_pages to avoid overflow failures

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: "Steven Rostedt (Red Hat)" 

commit 9b94a8fba501f38368aef6ac1b30e7335252a220 upstream.

The size variable to change the ring buffer in ftrace is a long. The
nr_pages used to update the ring buffer based on the size is int. On 64 bit
machines this can cause an overflow problem.

For example, the following will cause the ring buffer to crash:

 # cd /sys/kernel/debug/tracing
 # echo 10 > buffer_size_kb
 # echo 8556384240 > buffer_size_kb

Then you get the warning of:

 WARNING: CPU: 1 PID: 318 at kernel/trace/ring_buffer.c:1527 
rb_update_pages+0x22f/0x260

Which is:

  RB_WARN_ON(cpu_buffer, nr_removed);

Note each ring buffer page holds 4080 bytes.

This is because:

 1) 10 causes the ring buffer to have 3 pages.
(10kb requires 3 * 4080 pages to hold)

 2) (2^31 / 2^10  + 1) * 4080 = 8556384240
The value written into buffer_size_kb is shifted by 10 and then passed
to ring_buffer_resize(). 8556384240 * 2^10 = 8761737461760

 3) The size passed to ring_buffer_resize() is then divided by BUF_PAGE_SIZE
which is 4080. 8761737461760 / 4080 = 2147484672

 4) nr_pages is subtracted from the current nr_pages (3) and we get:
2147484669. This value is saved in a signed integer nr_pages_to_update

 5) 2147484669 is greater than 2^31 but smaller than 2^32, a signed int
turns into the value of -2147482627

 6) As the value is a negative number, in update_pages_handler() it is
negated and passed to rb_remove_pages() and 2147482627 pages will
be removed, which is much larger than 3 and it causes the warning
because not all the pages asked to be removed were removed.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=118001

Fixes: 7a8e76a3829f1 ("tracing: unified trace buffer")
Reported-by: Hao Qin 
Signed-off-by: Steven Rostedt 
Signed-off-by: Kamal Mostafa 
---
 kernel/trace/ring_buffer.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 40718df..c3f1f34 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -426,7 +426,7 @@ struct ring_buffer_per_cpu {
raw_spinlock_t  reader_lock;/* serialize readers */
arch_spinlock_t lock;
struct lock_class_key   lock_key;
-   unsigned intnr_pages;
+   unsigned long   nr_pages;
unsigned intcurrent_context;
struct list_head*pages;
struct buffer_page  *head_page; /* read from head */
@@ -447,7 +447,7 @@ struct ring_buffer_per_cpu {
u64 write_stamp;
u64 read_stamp;
/* ring buffer pages to update, > 0 to add, < 0 to remove */
-   int nr_pages_to_update;
+   longnr_pages_to_update;
struct list_headnew_pages; /* new pages to add */
struct work_struct  update_pages_work;
struct completion   update_done;
@@ -1126,10 +1126,10 @@ static int rb_check_pages(struct ring_buffer_per_cpu 
*cpu_buffer)
return 0;
 }
 
-static int __rb_allocate_pages(int nr_pages, struct list_head *pages, int cpu)
+static int __rb_allocate_pages(long nr_pages, struct list_head *pages, int cpu)
 {
-   int i;
struct buffer_page *bpage, *tmp;
+   long i;
 
for (i = 0; i < nr_pages; i++) {
struct page *page;
@@ -1166,7 +1166,7 @@ free_pages:
 }
 
 static int rb_allocate_pages(struct ring_buffer_per_cpu *cpu_buffer,
-unsigned nr_pages)
+unsigned long nr_pages)
 {
LIST_HEAD(pages);
 
@@ -1191,7 +1191,7 @@ static int rb_allocate_pages(struct ring_buffer_per_cpu 
*cpu_buffer,
 }
 
 static struct ring_buffer_per_cpu *
-rb_allocate_cpu_buffer(struct ring_buffer *buffer, int nr_pages, int cpu)
+rb_allocate_cpu_buffer(struct ring_buffer *buffer, long nr_pages, int cpu)
 {
struct ring_buffer_per_cpu *cpu_buffer;
struct buffer_page *bpage;
@@ -1291,8 +1291,9 @@ struct ring_buffer *__ring_buffer_alloc(unsigned long 
size, unsigned flags,
struct lock_class_key *key)
 {
struct ring_buffer *buffer;
+   long nr_pages;
int bsize;
-   int cpu, nr_pages;
+   int cpu;
 
/* keep it in its own cache line */
buffer = kzalloc(ALIGN(sizeof(*buffer), cache_line_size()),
@@ -1418,12 +1419,12 @@ static inline unsigned long rb_page_write(struct 
buffer_page *bpage)
 }
 
 static int
-rb_remove_pages(struct ring_buffer_per_cpu *cpu_buffer, unsigned int 

[tip:timers/core] timerfd: Reject ALARM timerfds without CAP_WAKE_ALARM

[tip-bot for Eric Caruso]

Commit-ID:  2895a5e5b3ae78d9923a91fce405d4a2f32c4309
Gitweb: http://git.kernel.org/tip/2895a5e5b3ae78d9923a91fce405d4a2f32c4309
Author: Eric Caruso 
AuthorDate: Wed, 8 Jun 2016 16:08:59 -0700
Committer:  Thomas Gleixner 
CommitDate: Thu, 9 Jun 2016 23:42:38 +0200

timerfd: Reject ALARM timerfds without CAP_WAKE_ALARM

timerfd gives processes a way to set wake alarms, but unlike timers made using
timer_create, timerfds don't check whether the process has CAP_WAKE_ALARM
before setting alarm-time timers. CAP_WAKE_ALARM is supposed to gate this
behavior and so it makes sense that we should deny permission to create such
timerfds if the process doesn't have this capability.

Signed-off-by: Eric Caruso 
Cc: Todd Poynor 
Link: 
http://lkml.kernel.org/r/1465427339-96209-1-git-send-email-ejcar...@chromium.org
Signed-off-by: Thomas Gleixner 

---
 fs/timerfd.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/fs/timerfd.c b/fs/timerfd.c
index 053818d..9ae4abb 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -390,6 +390,11 @@ SYSCALL_DEFINE2(timerfd_create, int, clockid, int, flags)
 clockid != CLOCK_BOOTTIME_ALARM))
return -EINVAL;
 
+   if (!capable(CAP_WAKE_ALARM) &&
+   (clockid == CLOCK_REALTIME_ALARM ||
+clockid == CLOCK_BOOTTIME_ALARM))
+   return -EPERM;
+
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
@@ -433,6 +438,11 @@ static int do_timerfd_settime(int ufd, int flags,
return ret;
ctx = f.file->private_data;
 
+   if (!capable(CAP_WAKE_ALARM) && isalarm(ctx)) {
+   fdput(f);
+   return -EPERM;
+   }
+
timerfd_setup_cancel(ctx, flags);
 
/*

[PATCH 4.2.y-ckt 094/206] powerpc/eeh: Don't report error in eeh_pe_reset_and_recover()

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Gavin Shan 

commit affeb0f2d3a9af419ad7ef4ac782e1540b2f7b28 upstream.

The function eeh_pe_reset_and_recover() is used to recover EEH
error when the passthrough device are transferred to guest and
backwards, meaning the device's driver is vfio-pci or none.
When the driver is vfio-pci that provides error_detected() error
handler only, the handler simply stops the guest and it's not
expected behaviour. On the other hand, no error handlers will
be called if we don't have a bound driver.

This ignores the error handler in eeh_pe_reset_and_recover()
that reports the error to device driver to avoid the exceptional
behaviour.

Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
Signed-off-by: Gavin Shan 
Reviewed-by: Russell Currey 
Signed-off-by: Michael Ellerman 
Signed-off-by: Kamal Mostafa 
---
 arch/powerpc/kernel/eeh_driver.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index afeb2bd..e5f488c 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -502,9 +502,6 @@ int eeh_pe_reset_and_recover(struct eeh_pe *pe)
/* Save states */
eeh_pe_dev_traverse(pe, eeh_dev_save_state, NULL);
 
-   /* Report error */
-   eeh_pe_dev_traverse(pe, eeh_report_error, );
-
/* Issue reset */
ret = eeh_reset_pe(pe);
if (ret) {
-- 
2.7.4

[PATCH 4.2.y-ckt 104/206] MIPS: Disable preemption during prctl(PR_SET_FP_MODE, ...)

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Paul Burton 

commit bd239f1e1429e7781096bf3884bdb1b2b1bb4f28 upstream.

Whilst a PR_SET_FP_MODE prctl is performed there are decisions made
based upon whether the task is executing on the current CPU. This may
change if we're preempted, so disable preemption to avoid such changes
for the lifetime of the mode switch.

Signed-off-by: Paul Burton 
Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Reviewed-by: Maciej W. Rozycki 
Tested-by: Aurelien Jarno 
Cc: Adam Buchbinder 
Cc: James Hogan 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13144/
Signed-off-by: Ralf Baechle 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/kernel/process.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
index 6b3ae73..89847be 100644
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -603,6 +603,9 @@ int mips_set_process_fp_mode(struct task_struct *task, 
unsigned int value)
if (!(value & PR_FP_MODE_FR) && cpu_has_fpu && cpu_has_mips_r6)
return -EOPNOTSUPP;
 
+   /* Proceed with the mode switch */
+   preempt_disable();
+
/* Save FP & vector context, then disable FPU & MSA */
if (task->signal == current->signal)
lose_fpu(1);
@@ -661,6 +664,7 @@ int mips_set_process_fp_mode(struct task_struct *task, 
unsigned int value)
 
/* Allow threads to use FP again */
atomic_set(>mm->context.fp_mode_switching, 0);
+   preempt_enable();
 
return 0;
 }
-- 
2.7.4

[PATCH 4.2.y-ckt 105/206] MIPS: Force CPUs to lose FP context during mode switches

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Paul Burton 

commit 6b8322576e9d325b65c54fbef64e4e8690ad70ce upstream.

Commit 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options
for MIPS") added support for the PR_SET_FP_MODE prctl, which allows a
userland program to modify its FP mode at runtime. This is most notably
required if dynamic linking leads to the FP mode requirement changing at
runtime from that indicated in the initial executable's ELF header. In
order to avoid overhead in the general FP context restore code, it aimed
to have threads in the process become unable to enable the FPU during a
mode switch & have the thread calling the prctl syscall wait for all
other threads in the process to be context switched at least once. Once
that happens we can know that no thread in the process whose mode will
be switched has live FP context, and it's safe to perform the mode
switch. However in the (rare) case of modeswitches occurring in
multithreaded programs this can lead to indeterminate delays for the
thread invoking the prctl syscall, and the code monitoring for those
context switches was woefully inadequate for all but the simplest cases.

Fix this by broadcasting an IPI if other CPUs may have live FP context
for an affected thread, with a handler causing those CPUs to relinquish
their FPU ownership. Threads will then be allowed to continue running
but will stall on the wait_on_atomic_t in enable_restore_fp_context if
they attempt to use FP again whilst the mode switch is still in
progress. The end result is less fragile poking at scheduler context
switch counts & a more expedient completion of the mode switch.

Signed-off-by: Paul Burton 
Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Reviewed-by: Maciej W. Rozycki 
Cc: Adam Buchbinder 
Cc: James Hogan 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13145/
Signed-off-by: Ralf Baechle 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/kernel/process.c | 40 +---
 1 file changed, 17 insertions(+), 23 deletions(-)

diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
index 89847be..ac84ac8 100644
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -582,11 +582,19 @@ int mips_get_process_fp_mode(struct task_struct *task)
return value;
 }
 
+static void prepare_for_fp_mode_switch(void *info)
+{
+   struct mm_struct *mm = info;
+
+   if (current->mm == mm)
+   lose_fpu(1);
+}
+
 int mips_set_process_fp_mode(struct task_struct *task, unsigned int value)
 {
const unsigned int known_bits = PR_FP_MODE_FR | PR_FP_MODE_FRE;
-   unsigned long switch_count;
struct task_struct *t;
+   int max_users;
 
/* Check the value is valid */
if (value & ~known_bits)
@@ -615,31 +623,17 @@ int mips_set_process_fp_mode(struct task_struct *task, 
unsigned int value)
smp_mb__after_atomic();
 
/*
-* If there are multiple online CPUs then wait until all threads whose
-* FP mode is about to change have been context switched. This approach
-* allows us to only worry about whether an FP mode switch is in
-* progress when FP is first used in a tasks time slice. Pretty much all
-* of the mode switch overhead can thus be confined to cases where mode
-* switches are actually occuring. That is, to here. However for the
-* thread performing the mode switch it may take a while...
+* If there are multiple online CPUs then force any which are running
+* threads in this process to lose their FPU context, which they can't
+* regain until fp_mode_switching is cleared later.
 */
if (num_online_cpus() > 1) {
-   spin_lock_irq(>sighand->siglock);
-
-   for_each_thread(task, t) {
-   if (t == current)
-   continue;
-
-   switch_count = t->nvcsw + t->nivcsw;
-
-   do {
-   spin_unlock_irq(>sighand->siglock);
-   cond_resched();
-   spin_lock_irq(>sighand->siglock);
-   } while ((t->nvcsw + t->nivcsw) == switch_count);
-   }
+   /* No need to send an IPI for the local CPU */
+   max_users = (task->mm == current->mm) ? 1 : 0;
 
-   spin_unlock_irq(>sighand->siglock);
+   if (atomic_read(>mm->mm_users) > max_users)
+   smp_call_function(prepare_for_fp_mode_switch,
+ 

[PATCH 4.2.y-ckt 088/206] irqchip/gic-v3: Configure all interrupts as non-secure Group-1

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Marc Zyngier 

commit 7c9b973061b03af62734f613f6abec46c0dd4a88 upstream.

The GICv3 driver wrongly assumes that it runs on the non-secure
side of a secure-enabled system, while it could be on a system
with a single security state, or a GICv3 with GICD_CTLR.DS set.

Either way, it is important to configure this properly, or
interrupts will simply not be delivered on this HW.

Reported-by: Peter Maydell 
Tested-by: Peter Maydell 
Signed-off-by: Marc Zyngier 
Signed-off-by: Kamal Mostafa 
---
 drivers/irqchip/irq-gic-v3.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index f5c518b..0daa31d 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -379,6 +379,15 @@ static void __init gic_dist_init(void)
writel_relaxed(0, base + GICD_CTLR);
gic_dist_wait_for_rwp();
 
+   /*
+* Configure SPIs as non-secure Group-1. This will only matter
+* if the GIC only has a single security state. This will not
+* do the right thing if the kernel is running in secure mode,
+* but that's not the intended use case anyway.
+*/
+   for (i = 32; i < gic_data.irq_nr; i += 32)
+   writel_relaxed(~0, base + GICD_IGROUPR + i / 8);
+
gic_dist_config(base, gic_data.irq_nr, gic_dist_wait_for_rwp);
 
/* Enable distributor with ARE, Group1 */
@@ -482,6 +491,9 @@ static void gic_cpu_init(void)
 
rbase = gic_data_rdist_sgi_base();
 
+   /* Configure SGIs/PPIs as non-secure Group-1 */
+   writel_relaxed(~0, rbase + GICR_IGROUPR0);
+
gic_cpu_config(rbase, gic_redist_wait_for_rwp);
 
/* Give LPIs a spin */
-- 
2.7.4

[PATCH 4.2.y-ckt 081/206] USB: serial: mxuport: fix use-after-free in probe error path

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Johan Hovold 

commit 9e45284984096314994777f27e1446dfbfd2f0d7 upstream.

The interface read and event URBs are submitted in attach, but were
never explicitly unlinked by the driver. Instead the URBs would have
been killed by usb-serial core on disconnect.

In case of a late probe error (e.g. due to failed minor allocation),
disconnect is never called and we could end up with active URBs for an
unbound interface. This in turn could lead to deallocated memory being
dereferenced in the completion callbacks.

Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX
driver")
Signed-off-by: Johan Hovold 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/mxuport.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c
index 460a406..d029b2f 100644
--- a/drivers/usb/serial/mxuport.c
+++ b/drivers/usb/serial/mxuport.c
@@ -1263,6 +1263,15 @@ static int mxuport_attach(struct usb_serial *serial)
return 0;
 }
 
+static void mxuport_release(struct usb_serial *serial)
+{
+   struct usb_serial_port *port0 = serial->port[0];
+   struct usb_serial_port *port1 = serial->port[1];
+
+   usb_serial_generic_close(port1);
+   usb_serial_generic_close(port0);
+}
+
 static int mxuport_open(struct tty_struct *tty, struct usb_serial_port *port)
 {
struct mxuport_port *mxport = usb_get_serial_port_data(port);
@@ -1365,6 +1374,7 @@ static struct usb_serial_driver mxuport_device = {
.probe  = mxuport_probe,
.port_probe = mxuport_port_probe,
.attach = mxuport_attach,
+   .release= mxuport_release,
.calc_num_ports = mxuport_calc_num_ports,
.open   = mxuport_open,
.close  = mxuport_close,
-- 
2.7.4

[PATCH 4.2.y-ckt 078/206] USB: serial: io_edgeport: fix memory leaks in attach error path

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Johan Hovold 

commit c5c0c55598cefc826d6cfb0a417eeaee3631715c upstream.

Private data, URBs and buffers allocated for Epic devices during
attach were never released on errors (e.g. missing endpoints).

Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver")
Signed-off-by: Johan Hovold 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/io_edgeport.c | 39 ---
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
index c086697..1106e7d 100644
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -2856,14 +2856,16 @@ static int edge_startup(struct usb_serial *serial)
/* not set up yet, so do it now */
edge_serial->interrupt_read_urb =
usb_alloc_urb(0, GFP_KERNEL);
-   if (!edge_serial->interrupt_read_urb)
-   return -ENOMEM;
+   if (!edge_serial->interrupt_read_urb) {
+   response = -ENOMEM;
+   break;
+   }
 
edge_serial->interrupt_in_buffer =
kmalloc(buffer_size, GFP_KERNEL);
if (!edge_serial->interrupt_in_buffer) {
-   
usb_free_urb(edge_serial->interrupt_read_urb);
-   return -ENOMEM;
+   response = -ENOMEM;
+   break;
}
edge_serial->interrupt_in_endpoint =
endpoint->bEndpointAddress;
@@ -2891,14 +2893,16 @@ static int edge_startup(struct usb_serial *serial)
/* not set up yet, so do it now */
edge_serial->read_urb =
usb_alloc_urb(0, GFP_KERNEL);
-   if (!edge_serial->read_urb)
-   return -ENOMEM;
+   if (!edge_serial->read_urb) {
+   response = -ENOMEM;
+   break;
+   }
 
edge_serial->bulk_in_buffer =
kmalloc(buffer_size, GFP_KERNEL);
if (!edge_serial->bulk_in_buffer) {
-   usb_free_urb(edge_serial->read_urb);
-   return -ENOMEM;
+   response = -ENOMEM;
+   break;
}
edge_serial->bulk_in_endpoint =
endpoint->bEndpointAddress;
@@ -2924,9 +2928,22 @@ static int edge_startup(struct usb_serial *serial)
}
}
 
-   if (!interrupt_in_found || !bulk_in_found || !bulk_out_found) {
-   dev_err(ddev, "Error - the proper endpoints were not 
found!\n");
-   return -ENODEV;
+   if (response || !interrupt_in_found || !bulk_in_found ||
+   !bulk_out_found) {
+   if (!response) {
+   dev_err(ddev, "expected endpoints not found\n");
+   response = -ENODEV;
+   }
+
+   usb_free_urb(edge_serial->interrupt_read_urb);
+   kfree(edge_serial->interrupt_in_buffer);
+
+   usb_free_urb(edge_serial->read_urb);
+   kfree(edge_serial->bulk_in_buffer);
+
+   kfree(edge_serial);
+
+   return response;
}
 
/* start interrupt read for this edgeport this interrupt will
-- 
2.7.4

[PATCH 4.2.y-ckt 085/206] MIPS: KVM: Fix timer IRQ race when writing CP0_Compare

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: James Hogan 

commit b45bacd2d048f405c7760e5cc9b60dd67708734f upstream.

Writing CP0_Compare clears the timer interrupt pending bit
(CP0_Cause.TI), but this wasn't being done atomically. If a timer
interrupt raced with the write of the guest CP0_Compare, the timer
interrupt could end up being pending even though the new CP0_Compare is
nowhere near CP0_Count.

We were already updating the hrtimer expiry with
kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and
kvm_mips_resume_hrtimer(). Close the race window by expanding out
kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting
CP0_Compare between the freeze and resume. Since the pending timer
interrupt should not be cleared when CP0_Compare is written via the KVM
user API, an ack argument is added to distinguish the source of the
write.

Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
Cc: k...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/include/asm/kvm_host.h |  2 +-
 arch/mips/kvm/emulate.c  | 61 ++--
 arch/mips/kvm/trap_emul.c|  2 +-
 3 files changed, 29 insertions(+), 36 deletions(-)

diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index e8c8d9d..4afe1ec 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -782,7 +782,7 @@ extern enum emulation_result 
kvm_mips_complete_mmio_load(struct kvm_vcpu *vcpu,
 
 uint32_t kvm_mips_read_count(struct kvm_vcpu *vcpu);
 void kvm_mips_write_count(struct kvm_vcpu *vcpu, uint32_t count);
-void kvm_mips_write_compare(struct kvm_vcpu *vcpu, uint32_t compare);
+void kvm_mips_write_compare(struct kvm_vcpu *vcpu, uint32_t compare, bool ack);
 void kvm_mips_init_count(struct kvm_vcpu *vcpu);
 int kvm_mips_set_count_ctl(struct kvm_vcpu *vcpu, s64 count_ctl);
 int kvm_mips_set_count_resume(struct kvm_vcpu *vcpu, s64 count_resume);
diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c
index eaf77b5..dc10c77 100644
--- a/arch/mips/kvm/emulate.c
+++ b/arch/mips/kvm/emulate.c
@@ -438,32 +438,6 @@ static void kvm_mips_resume_hrtimer(struct kvm_vcpu *vcpu,
 }
 
 /**
- * kvm_mips_update_hrtimer() - Update next expiry time of hrtimer.
- * @vcpu:  Virtual CPU.
- *
- * Recalculates and updates the expiry time of the hrtimer. This can be used
- * after timer parameters have been altered which do not depend on the time 
that
- * the change occurs (in those cases kvm_mips_freeze_hrtimer() and
- * kvm_mips_resume_hrtimer() are used directly).
- *
- * It is guaranteed that no timer interrupts will be lost in the process.
- *
- * Assumes !kvm_mips_count_disabled(@vcpu) (guest CP0_Count timer is running).
- */
-static void kvm_mips_update_hrtimer(struct kvm_vcpu *vcpu)
-{
-   ktime_t now;
-   uint32_t count;
-
-   /*
-* freeze_hrtimer takes care of a timer interrupts <= count, and
-* resume_hrtimer the hrtimer takes care of a timer interrupts > count.
-*/
-   now = kvm_mips_freeze_hrtimer(vcpu, );
-   kvm_mips_resume_hrtimer(vcpu, now, count);
-}
-
-/**
  * kvm_mips_write_count() - Modify the count and update timer.
  * @vcpu:  Virtual CPU.
  * @count: Guest CP0_Count value to set.
@@ -558,23 +532,42 @@ int kvm_mips_set_count_hz(struct kvm_vcpu *vcpu, s64 
count_hz)
  * kvm_mips_write_compare() - Modify compare and update timer.
  * @vcpu:  Virtual CPU.
  * @compare:   New CP0_Compare value.
+ * @ack:   Whether to acknowledge timer interrupt.
  *
  * Update CP0_Compare to a new value and update the timeout.
+ * If @ack, atomically acknowledge any pending timer interrupt, otherwise 
ensure
+ * any pending timer interrupt is preserved.
  */
-void kvm_mips_write_compare(struct kvm_vcpu *vcpu, uint32_t compare)
+void kvm_mips_write_compare(struct kvm_vcpu *vcpu, uint32_t compare, bool ack)
 {
struct mips_coproc *cop0 = vcpu->arch.cop0;
+   int dc;
+   u32 old_compare = kvm_read_c0_guest_compare(cop0);
+   ktime_t now;
+   uint32_t count;
 
/* if unchanged, must just be an ack */
-   if (kvm_read_c0_guest_compare(cop0) == compare)
+   if (old_compare == compare) {
+   if (!ack)
+   return;
+   kvm_mips_callbacks->dequeue_timer_int(vcpu);
+   kvm_write_c0_guest_compare(cop0, compare);
return;
+   }
+
+   /* freeze_hrtimer() takes care of timer interrupts <= count */
+   dc = kvm_mips_count_disabled(vcpu);
+   

[PATCH 4.2.y-ckt 076/206] usb: host: xhci-rcar: Avoid long wait in xhci_reset()

[Kamal Mostafa]

4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Yoshihiro Shimoda 

commit f879fc32aa0c96fbac261b3d857a1239d554ad01 upstream.

The firmware of R-Car USB 3.0 host controller will control the reset.
So, if the xhci driver doesn't do firmware downloading (e.g. kernel
configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR
is not set), the reset of USB 3.0 host controller doesn't work
correctly. Then, the host controller will cause long wait in
xhci_reset() because the CMD_RESET bit of op_regs->command is not
cleared for 10 seconds.

So, this patch modifies the Kconfig to enable both CONFIG_USB_XHCI_PLATFORM
and CONFIG_USB_XHCI_RCAR.

Fixes: 4ac8918f3a7 (usb: host: xhci-plat: add support for the R-Car H2 and M2 
xHCI controllers)
Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman 
[ kamal: backport to 4.2-stable: s/ARCH_RENESAS/ARCH_SHMOBILE/ ]
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..a69b405 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -33,6 +33,7 @@ config USB_XHCI_PCI
 
 config USB_XHCI_PLATFORM
tristate
+   select USB_XHCI_RCAR if ARCH_SHMOBILE
 
 config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
@@ -44,7 +45,7 @@ config USB_XHCI_MVEBU
 
 config USB_XHCI_RCAR
tristate "xHCI support for Renesas R-Car SoCs"
-   select USB_XHCI_PLATFORM
+   depends on USB_XHCI_PLATFORM
depends on ARCH_SHMOBILE || COMPILE_TEST
---help---
  Say 'Y' to enable the support for the xHCI host controller
-- 
2.7.4