[PATCH 3.16.y-ckt 043/185] ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Tunin 

commit 4fa9dabcffc8e16601307d3d56b58c68d9716ba4 upstream.

Lenovo G30-50 does not have a hardware wireless switch and wireless
is always blocked.

BugLink: https://bugs.launchpad.net/bugs/1397021
Signed-off-by: Dmitry Tunin 
Signed-off-by: Philippe Coval 
[dvh...@linux.intel.com: Reordered dmi id per Phillippe's later version]
Signed-off-by: Darren Hart 
Signed-off-by: Luis Henriques 
---
 drivers/platform/x86/ideapad-laptop.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c
index 7fe7ed830d8d..11712d1dbd17 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -831,6 +831,13 @@ static void ideapad_acpi_notify(acpi_handle handle, u32 
event, void *data)
  */
 static struct dmi_system_id no_hw_rfkill_list[] = {
{
+   .ident = "Lenovo G50-30",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo G50-30"),
+   },
+   },
+   {
.ident = "Lenovo Yoga 2 11 / 13 / Pro",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v1] mips: Use unsigned int when reading CP0 registers

[Ralf Baechle]

On Wed, Jul 15, 2015 at 10:44:30AM +1200, Chris Packham wrote:

> Update __read_32bit_c0_register() and __read_32bit_c0_ctrl_register() to
> use "unsigned int res;" instead of "int res;". There is little reason to
> treat these register values as signed. They are either counters (which
> by definition are unsigned) or are made up of various bit fields to be
> interpreted as per the CPU datasheet.
> 
> Signed-off-by: Chris Packham 
> 
> ---
> This has come up via u-boot[1] which sync's asm/mipsregs.h with the
> kernel. In u-boots case the value read from read_c0_count() is assigned
> to an unsigned long [2] which triggers a sign extension and causes a
> bug.
> 
> U-boot should probably be more explicit about the types used for the
> timer_read_counter() API but that aside is there any reason to treat
> these values as signed integers? A quick grep around the arch/mips makes
> me thing that there may be some bugs lurking when read_c0_count() starts
> to yield a negative value but I haven't really explored any of them.

Known issue but I've always been concerned about math with cycle values
like:

  unsigned int now, timeout = read_c0_counter() + a_bit_of_time;

  waste_some_time();

  if (timeout - read_c0_counter() < 0)
do_timeout_stuff();

Which now with both variables being unsigned would yield a positive value
thus the if would never be taken.  This particular construction GCC would
warn about but there are other, constructs that wouldn't trigger a warning.

I don't even want to think about what C type propagation rules say about
mixing signed and unsigned types.  Whenever such knowledge is required
to figure out what a piece of code is doing it probably should be considered
broken anyway - but the mess resulting from unwanted sign is no better!

Anyway, I've queued your patch for 4.3.  Thanks!

> I also notice that read_32bit_cp1_register has a similar issue. I
> haven't touched it at this stage but it probably makes sense to do so
> for consistency if the CP0 macros are changed. Looking at the users of
> read_32bit_cp1_register() it's probably less of an issue.

I've cooked up a patch for read_32bit_cp1_register and queued it for 4.3.

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

[PATCH 3.16.y-ckt 046/185] ipr: Increase default adapter init stage change timeout

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Brian King 

commit 45c44b5ff9caa743ed9c2bfd44307c536c9caf1e upstream.

Increase the default init stage change timeout from 15 seconds to 30 seconds.
This resolves issues we have seen with some adapters not transitioning
to the first init stage within 15 seconds, which results in adapter
initialization failures.

Signed-off-by: Brian King 
Signed-off-by: James Bottomley 
Signed-off-by: Luis Henriques 
---
 drivers/scsi/ipr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ipr.h b/drivers/scsi/ipr.h
index c24c747595ba..b22b23586f93 100644
--- a/drivers/scsi/ipr.h
+++ b/drivers/scsi/ipr.h
@@ -269,7 +269,7 @@
 #define IPR_RUNTIME_RESET  0x4000
 
 #define IPR_IPL_INIT_MIN_STAGE_TIME5
-#define IPR_IPL_INIT_DEFAULT_STAGE_TIME 15
+#define IPR_IPL_INIT_DEFAULT_STAGE_TIME 30
 #define IPR_IPL_INIT_STAGE_UNKNOWN 0x0
 #define IPR_IPL_INIT_STAGE_TRANSOP 0xB000
 #define IPR_IPL_INIT_STAGE_MASK0xff00
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH 2/2] pinctrl: introduce complex pin description

[Sascha Hauer]

On Wed, Jul 15, 2015 at 10:45:42AM +0200, Ludovic Desroches wrote:
> On Tue, Jul 14, 2015 at 08:13:59AM +0200, Sascha Hauer wrote:
> > On Wed, Jun 10, 2015 at 05:04:57PM +0200, Ludovic Desroches wrote:
> > > Using a string to describe a pin in the device tree can be not enough.
> > > Some controllers may need extra information to fully describe a pin. It
> > > concerns mainly controllers which have a per pin muxing approach which
> > > don't fit well the notions of groups and functions.
> > > Instead of using a pin name, a 32 bit value is used. The 16 least
> > > significant bits are used for the pin number. Other 16 bits can be used to
> > > store extra parameters.
> > 
> > In the Mediatek driver we use 'pinmux' as name for the property
> > containing the combined pin number / mux value defines. 'pinmux' better
> > describes what it is...
> > 
> 
> At the moment, I don't mix pin number and pin mux. I mix pin number and
> ioset. It allows to check that all the pins belong to the same ioset.
> 
> As said previously, I didn't want to mix pin mux and pin conf in the
> same node (but it is something I can do, it's not a problem on my side).
> If I do it I will have to mux three values: pin number, pin mux value
> and pin ioset.
> 
> So assuming I do this change, your advice is to add a 'pinmux' property in
> addition of 'pins' instead of trying to use it?

My advise is to not enslave your code to this ioset concept. The only
effect of introducing this concept is one single warning in the log:

dev_warn(>dev,
"/!\\ pins from group %s are not using the same ioset /!\\\n",
group->name);

There are *no* decisions made in the driver upon the ioset, only the
above warning is printed.

I can easily find examples in which a device needs some functional pins
and some additional GPIOs, be it for card detection or something else,
and this *will* work, regardless of which ioset the pins are in. Why
should a ioset concept limit me in this way that everything works except
I have to suppress or ignore the warning in the log or split the pinmux
node up to two different nodes?

The only thing that won't work (or at least you don't want to guarantee
that it works), is to mix functional pins from the upper left corner of
the SoC with pins from the lower right corner to form a single MMC/SD
controller. Yes, you shouldn't do that. I may or may not work, but that
is nothing this particular SoC introduces, it's like this on many other
SoCs, perhaps even including earlier Atmel SoCs. Still, me as the guy
writing board support have to support the way the hardware is designed,
and if a board designer chooses to use pins from different iosets for a
single device I'll support it that way, no matter if a warning is shown
or not. If the users of this board are annoyed by the above warning
you'll probably receive a patch dropping it soon. Then the ioset concept
has completely vanished, but still the device trees are written like
that.

So, yes, my advice is to drop the ioset concept completely. If you still
insist on it then you can encode the ioset number in the pinmux define.
Only the lower 16bit are defined as the pin number, you can use the
upper 16bit like you want. You can encode the muxing in bits 16-23 and the
ioset in bits 24-31.

> > > + if (pctldesc->complex_pin_desc && pins_prop) {
> > > + of_property_for_each_u32(np, subnode_target_type, prop, cur, 
> > > val) {
> > > + pin_id = val & PINCTRL_PIN_MASK;
> > > + items_name[i++] = pctldesc->pins[pin_id].name;
> > > + }
> > 
> > I don't like that even though pins have numbers here they are converted
> > to strings which the driver later has to search in a list just to
> > convert it back into the number. This is quite inefficient.
> > 
> > I guess this could be optimized later, but it would be nice to have the
> > pin number directly in the driver.
> 
> I know that is something you don't like but, at the moment, I need a string 
> for
> pinctrl_utils_add_map_mux and pinctrl_utils_add_map_configs.

Yeah, I am fine with it. This can be fixed later. I am more concerned
about the device tree bindings than about the actual implementation. The
implementation can far more easy be changed than the bindings.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 014/185] x86/mce: Fix MCE severity messages

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Borislav Petkov 

commit 17fea54bf0ab34fa09a06bbde2f58ed7bbdf9299 upstream.

Derek noticed that a critical MCE gets reported with the wrong
error type description:

  [Hardware Error]: CPU 34: Machine Check Exception: 5 Bank 9: f23f000100b0
  [Hardware Error]: RIP !INEXACT! 10: {intel_idle+0xb1/0x170}
  [Hardware Error]: TSC 49587b8e321cb
  [Hardware Error]: PROCESSOR 0:306e4 TIME 1431561296 SOCKET 1 APIC 29
  [Hardware Error]: Some CPUs didn't answer in synchronization
  [Hardware Error]: Machine check: Invalid
   ^^^

The last line with 'Invalid' should have printed the high level
MCE error type description we get from mce_severity, i.e.
something like:

  [Hardware Error]: Machine check: Action required: data load error in a user 
process

this happens due to the fact that mce_no_way_out() iterates over
all MCA banks and possibly overwrites the @msg argument which is
used in the panic printing later.

Change behavior to take the message of only and the (last)
critical MCE it detects.

Reported-by: Derek 
Signed-off-by: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Link: http://lkml.kernel.org/r/1431936437-25286-3-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
[ kamal: backport to 3.13-stable: context ]
Signed-off-by: Kamal Mostafa 
Signed-off-by: Luis Henriques 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 9a79c8dbd8e8..5648b506f3ae 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -660,6 +660,7 @@ static int mce_no_way_out(struct mce *m, char **msg, 
unsigned long *validp,
  struct pt_regs *regs)
 {
int i, ret = 0;
+   char *tmp;
 
for (i = 0; i < mca_cfg.banks; i++) {
m->status = mce_rdmsrl(MSR_IA32_MCx_STATUS(i));
@@ -668,8 +669,11 @@ static int mce_no_way_out(struct mce *m, char **msg, 
unsigned long *validp,
if (quirk_no_way_out)
quirk_no_way_out(i, m, regs);
}
-   if (mce_severity(m, mca_cfg.tolerant, msg) >= 
MCE_PANIC_SEVERITY)
+
+   if (mce_severity(m, mca_cfg.tolerant, ) >= 
MCE_PANIC_SEVERITY) {
+   *msg = tmp;
ret = 1;
+   }
}
return ret;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails

[Subbaraya Sundeep Bhatta]

Hi John,

> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, July 14, 2015 12:29 AM
> To: John Youn
> Cc: ba...@ti.com; Subbaraya Sundeep Bhatta; gre...@linuxfoundation.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org
> Subject: Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command
> sent to DEPCMD register fails
> 
> Hi,
> 
> On Mon, Jul 13, 2015 at 05:50:49PM +, John Youn wrote:
> > On 7/11/2015 12:29 PM, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Sat, Jul 11, 2015 at 05:17:32PM +, Subbaraya Sundeep Bhatta
> wrote:
> > >> Hi Felipe,
> > >>
> > >> Just an update on this.
> > >>
> > >> I'm trying to get this working with our latest IP with dwc3
> > >> from your testing/next branch. It fails the usbtest with a
> > >> problem unrelated to this patch.
> > >> .
> > >> It passes on 4.1.1.
> > >>
> > >> I'll have to look into the failure but I won't get to it until
> > >> next week as I'm off the rest of this week.
> > >
> > > interesting... If you could post failure signature, I can help
> > > looking at it, but I guess it's too late to ask :-)
> > >
> > > thanks for helping though
> > >
> > 
> > 
> >  Hi Felipe,
> > 
> >  Nevermind about my issue, it ended up being a setup-related
> problem.
> > 
> >  I actually do see the same error as you due to this series of patches.
> >  Except I see it happening before even the first iteration. I get
> >  a completion status of 1 for the Set Endpoint Transfer Resources
> >  command. I'm not sure why this is.
> > 
> >  I don't see any conflict with any previous Transfer Complete.
> > >>
> > >> Same behavior at my end too. Fails before first iteration and I get
> > >> completion status of 1 for Set Endpoint Resource command. Attached
> > >> the logs of testing done with this patch and without this patch.
> > >> Without this patch I often see completion status of 1 for Set
> > >> Endpoint Transfer Resources command for Bulk and Isoc endpoints but
> > >> test proceeds because driver just logs command completion status
> > >> and moves on. We can revert this patch for time being. IP version is
> 2.90a.
> > >
> > > yeah, that's what I mean, it really seems like it's the IP misbehaving.
> > >
> > > John, let's try to figure out what's the root cause of this, we
> > > really want to use command completion status at some point, but for
> > > now we need to revert the patch :-(
> > >
> > > Let me know if you want me to log STARS ticket on your solvnet system.
> > >
> > > cheers
> > >
> >
> > Hi Felipe,
> >
> > We found the issue last week.
> >
> > The start config command isn't getting called during SET_INTERFACE.
> > Thus the transfer resource index isn't getting reset, and with
> > multiple SET_INTERFACE commands it will eventually exhaust the
> > resources.
> >
> > I tried out a fix and it works for me. I'll send it out separately for
> > review.

Thanks John for debugging :). Yes we are not handling SET_INTERFACE similar to
SET_CONFIGURATION in driver. I guess we follow 
"Alternate Initialization on SetInterface Request" sequence as per data book.
Felipe can confirm this.

> 
> Thanks a lot John. Not sure how come we missed that for such a long time
> :-) Let's Cc stable and get it plugged ASAP :-)
> 
> > Also, I noticed that the trace message that shows control transfers
> > doesn't show the SET_INTERFACE properly. Any idea why this is?
> >
> > For example, here is the line in the trace that corresponds to the
> > SET_INTERFACE:
> > irq/33-dwc3-10808 [003] d...  2443.494368: dwc3_ctrl_req:
> bRequestType
> > 01 bRequest 0b wValue 0001 wIndex  wLength 0

Can you please elaborate? What is expected here? Did you mean it shows wrong 
info
(other than the request actually sent by Host) ?

Thanks,
Sundeep.B.S.

> 
> I'll have a look at this when I'm back in the office (Jul 18th).
> 
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 044/185] powerpc/perf: Fix book3s kernel to userspace backtraces

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Anton Blanchard 

commit 72e349f1124a114435e599479c9b8d14bfd1ebcd upstream.

When we take a PMU exception or a software event we call
perf_read_regs(). This overloads regs->result with a boolean that
describes if we should use the sampled instruction address register
(SIAR) or the regs.

If the exception is in kernel, we start with the kernel regs and
backtrace through the kernel stack. At this point we switch to the
userspace regs and backtrace the user stack with perf_callchain_user().

Unfortunately these regs have not got the perf_read_regs() treatment,
so regs->result could be anything. If it is non zero,
perf_instruction_pointer() decides to use the SIAR, and we get issues
like this:

0.11%  qemu-system-ppc  [kernel.kallsyms][k] _raw_spin_lock_irqsave
   |
   ---_raw_spin_lock_irqsave
  |
  |--52.35%-- 0
  |  |
  |  |--46.39%-- __hrtimer_start_range_ns
  |  |  kvmppc_run_core
  |  |  kvmppc_vcpu_run_hv
  |  |  kvmppc_vcpu_run
  |  |  kvm_arch_vcpu_ioctl_run
  |  |  kvm_vcpu_ioctl
  |  |  do_vfs_ioctl
  |  |  sys_ioctl
  |  |  system_call
  |  |  |
  |  |  |--67.08%-- _raw_spin_lock_irqsave <--- hi mum
  |  |  |  |
  |  |  |   --100.00%-- 0x7e714
  |  |  | 0x7e714

Notice the bogus _raw_spin_irqsave when we transition from kernel
(system_call) to userspace (0x7e714). We inserted what was in the SIAR.

Add a check in regs_use_siar() to check that the regs in question
are from a PMU exception. With this fix the backtrace makes sense:

 0.47%  qemu-system-ppc  [kernel.vmlinux] [k] _raw_spin_lock_irqsave
|
---_raw_spin_lock_irqsave
   |
   |--53.83%-- 0
   |  |
   |  |--44.73%-- hrtimer_try_to_cancel
   |  |  kvmppc_start_thread
   |  |  kvmppc_run_core
   |  |  kvmppc_vcpu_run_hv
   |  |  kvmppc_vcpu_run
   |  |  kvm_arch_vcpu_ioctl_run
   |  |  kvm_vcpu_ioctl
   |  |  do_vfs_ioctl
   |  |  sys_ioctl
   |  |  system_call
   |  |  __ioctl
   |  |  0x7e714
   |  |  0x7e714

Signed-off-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
Signed-off-by: Luis Henriques 
---
 arch/powerpc/perf/core-book3s.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index fe52db2eea6a..97579de6853b 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -126,7 +126,16 @@ static void pmao_restore_workaround(bool ebb) { }
 
 static bool regs_use_siar(struct pt_regs *regs)
 {
-   return !!regs->result;
+   /*
+* When we take a performance monitor exception the regs are setup
+* using perf_read_regs() which overloads some fields, in particular
+* regs->result to tell us whether to use SIAR.
+*
+* However if the regs are from another exception, eg. a syscall, then
+* they have not been setup using perf_read_regs() and so regs->result
+* is something random.
+*/
+   return ((TRAP(regs) == 0xf00) && regs->result);
 }
 
 /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 047/185] ieee802154: Fix sockaddr_ieee802154 implicit padding information leak.

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Lennert Buytenhek 

commit 8a70cefa3037d62e7c0b6068a66675def1a330c9 upstream.

The AF_IEEE802154 sockaddr looks like this:

struct sockaddr_ieee802154 {
sa_family_t family; /* AF_IEEE802154 */
struct ieee802154_addr_sa addr;
};

struct ieee802154_addr_sa {
int addr_type;
u16 pan_id;
union {
u8 hwaddr[IEEE802154_ADDR_LEN];
u16 short_addr;
};
};

On most architectures there will be implicit structure padding here,
in two different places:

* In struct sockaddr_ieee802154, two bytes of padding between 'family'
  (unsigned short) and 'addr', so that 'addr' starts on a four byte
  boundary.

* In struct ieee802154_addr_sa, two bytes at the end of the structure,
  to make the structure 16 bytes.

When calling recvmsg(2) on a PF_IEEE802154 SOCK_DGRAM socket, the
ieee802154 stack constructs a struct sockaddr_ieee802154 on the
kernel stack without clearing these padding fields, and, depending
on the addr_type, between four and ten bytes of uncleared kernel
stack will be copied to userspace.

We can't just insert two 'u16 __pad's in the right places and zero
those before copying an address to userspace, as not all architectures
insert this implicit padding -- from a quick test it seems that avr32,
cris and m68k don't insert this padding, while every other architecture
that I have cross compilers for does insert this padding.

The easiest way to plug the leak is to just memset the whole struct
sockaddr_ieee802154 before filling in the fields we want to fill in,
and that's what this patch does.

Signed-off-by: Lennert Buytenhek 
Acked-by: Alexander Aring 
Signed-off-by: Marcel Holtmann 
[ luis: backported to 3.16:
  - file rename: net/ieee802154/socket.c -> net/ieee802154/dgram.c ]
Signed-off-by: Luis Henriques 
---
 net/ieee802154/dgram.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 4f0ed8780194..9c9b27be78e7 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -330,6 +330,12 @@ static int dgram_recvmsg(struct kiocb *iocb, struct sock 
*sk,
sock_recv_ts_and_drops(msg, sk, skb);
 
if (saddr) {
+   /* Clear the implicit padding in struct sockaddr_ieee802154
+* (16 bits between 'family' and 'addr') and in struct
+* ieee802154_addr_sa (16 bits at the end of the structure).
+*/
+   memset(saddr, 0, sizeof(*saddr));
+
saddr->family = AF_IEEE802154;
ieee802154_addr_to_sa(>addr, _cb(skb)->source);
*addr_len = sizeof(*saddr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 053/185] ath3k: add support of 13d3:3474 AR3012 device

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Tunin 

commit 0d0cef6183aec0fb6d0c9f00a09ff51ee086bbe2 upstream.

BugLink: https://bugs.launchpad.net/bugs/1427680

This device requires new firmware files
 AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
/lib/firmware/ar3k/ that are not included in linux-firmware yet.

T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3474 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Dmitry Tunin 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Luis Henriques 
---
 drivers/bluetooth/ath3k.c | 2 ++
 drivers/bluetooth/btusb.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 9fc08bd1495e..ecac55f124e8 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -112,6 +112,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x13d3, 0x3408) },
{ USB_DEVICE(0x13d3, 0x3423) },
{ USB_DEVICE(0x13d3, 0x3432) },
+   { USB_DEVICE(0x13d3, 0x3474) },
 
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -168,6 +169,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x13d3, 0x3474), .driver_info = BTUSB_ATH3012 },
 
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE036), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 6f37775139f1..fbedcf61060f 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -202,6 +202,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x13d3, 0x3474), .driver_info = BTUSB_ATH3012 },
 
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 051/185] selinux: fix setting of security labels on NFS

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "J. Bruce Fields" 

commit 9fc2b4b436cff7d8403034676014f1be9d534942 upstream.

Before calling into the filesystem, vfs_setxattr calls
security_inode_setxattr, which ends up calling selinux_inode_setxattr in
our case.  That returns -EOPNOTSUPP whenever SBLABEL_MNT is not set.
SBLABEL_MNT was supposed to be set by sb_finish_set_opts, which sets it
only if selinux_is_sblabel_mnt returns true.

The selinux_is_sblabel_mnt logic was broken by eadcabc697e9 "SELinux: do
all flags twiddling in one place", which didn't take into the account
the SECURITY_FS_USE_NATIVE behavior that had been introduced for nfs
with eb9ae686507b "SELinux: Add new labeling type native labels".

This caused setxattr's of security labels over NFSv4.2 to fail.

Cc: Eric Paris 
Cc: David Quigley 
Reported-by: Richard Chan 
Signed-off-by: J. Bruce Fields 
Acked-by: Stephen Smalley 
[PM: added the stable dependency]
Signed-off-by: Paul Moore 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques 
---
 security/selinux/hooks.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index a2aa95ecd1d5..9a23a7cccdc4 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -394,7 +394,8 @@ static int selinux_is_sblabel_mnt(struct super_block *sb)
 
if (sbsec->behavior == SECURITY_FS_USE_XATTR ||
sbsec->behavior == SECURITY_FS_USE_TRANS ||
-   sbsec->behavior == SECURITY_FS_USE_TASK)
+   sbsec->behavior == SECURITY_FS_USE_TASK ||
+   sbsec->behavior == SECURITY_FS_USE_NATIVE)
return 1;
 
/* Special handling for sysfs. Is genfs but also has setxattr handler*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/6] locking/pvqspinlock: Opportunistically defer kicking to unlock time

[Peter Zijlstra]

On Tue, Jul 14, 2015 at 10:13:36PM -0400, Waiman Long wrote:
> +static void pv_kick_node(struct qspinlock *lock, struct mcs_spinlock *node)
>  {
>   struct pv_node *pn = (struct pv_node *)node;
>  
> + if (xchg(>state, vcpu_running) == vcpu_running)
> + return;
> +
>   /*
> +  * Kicking the next node at lock time can actually be a bit faster
> +  * than doing it at unlock time because the critical section time
> +  * overlaps with the wakeup latency of the next node. However, if the
> +  * VM is too overcommmitted, it can happen that we need to kick the
> +  * CPU again at unlock time (double-kick). To avoid that and also to
> +  * fully utilize the kick-ahead functionality at unlock time,
> +  * the kicking will be deferred under either one of the following
> +  * 2 conditions:
>*
> +  * 1) The VM guest has too few vCPUs that kick-ahead is not even
> +  *enabled. In this case, the chance of double-kick will be
> +  *higher.
> +  * 2) The node after the next one is also in the halted state.
>*
> +  * In this case, the hashed flag is set to indicate that hashed
> +  * table has been filled and _Q_SLOW_VAL is set.
>*/
> - if (xchg(>state, vcpu_running) == vcpu_halted) {
> - pvstat_inc(pvstat_lock_kick);
> - pv_kick(pn->cpu);
> + if ((!pv_kick_ahead || pv_get_kick_node(pn, 1)) &&
> + (xchg(>hashed, 1) == 0)) {
> + struct __qspinlock *l = (void *)lock;
> +
> + /*
> +  * As this is the same vCPU that will check the _Q_SLOW_VAL
> +  * value and the hash table later on at unlock time, no atomic
> +  * instruction is needed.
> +  */
> + WRITE_ONCE(l->locked, _Q_SLOW_VAL);
> + (void)pv_hash(lock, pn);
> + return;
>   }
> +
> + /*
> +  * Kicking the vCPU even if it is not really halted is safe.
> +  */
> + pvstat_inc(pvstat_lock_kick);
> + pv_kick(pn->cpu);
>  }
>  
>  /*
> @@ -513,6 +545,13 @@ static void pv_wait_head(struct qspinlock *lock, struct 
> mcs_spinlock *node)
>   cpu_relax();
>   }
>  
> + if (!lp && (xchg(>hashed, 1) == 1))
> + /*
> +  * The hashed table & _Q_SLOW_VAL had been filled
> +  * by the lock holder.
> +  */
> + lp = (struct qspinlock **)-1;
> +
>   if (!lp) { /* ONCE */
>   lp = pv_hash(lock, pn);
>   /*

*groan*, so you complained the previous version of this patch was too
complex, but let me say I vastly preferred it to this one :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 050/185] drm/qxl: Do not leak memory if qxl_release_list_add fails

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Frediano Ziglio 

commit 8451cc964c1d193b989c41a44e5e77109cc696f8 upstream.

If the function fails reference counter to the object is not decremented
causing leaks.
This is hard to spot as it happens only on very low memory situations.

Signed-off-by: Frediano Ziglio 
Reviewed-by: Dave Airlie 
Signed-off-by: Dave Airlie 
Signed-off-by: Luis Henriques 
---
 drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index b110883f8253..7354a4cda59d 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -122,8 +122,10 @@ static struct qxl_bo *qxlhw_handle_to_bo(struct qxl_device 
*qdev,
qobj = gem_to_qxl_bo(gobj);
 
ret = qxl_release_list_add(release, qobj);
-   if (ret)
+   if (ret) {
+   drm_gem_object_unreference_unlocked(gobj);
return NULL;
+   }
 
return qobj;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 052/185] ath3k: Add support of 0489:e076 AR3012 device

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Tunin 

commit 692c062e7c282164fd7cda68077f79dafd176eaf upstream.

BugLink: https://bugs.launchpad.net/bugs/1462614

This device requires new firmware files
 AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
/lib/firmware/ar3k/ that are not included in linux-firmware yet.

T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=06 Dev#= 7 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e076 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms

Signed-off-by: Dmitry Tunin 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Luis Henriques 
---
 drivers/bluetooth/ath3k.c | 2 ++
 drivers/bluetooth/btusb.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index b526e7c7b109..9fc08bd1495e 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -80,6 +80,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x0489, 0xe057) },
{ USB_DEVICE(0x0489, 0xe056) },
{ USB_DEVICE(0x0489, 0xe05f) },
+   { USB_DEVICE(0x0489, 0xe076) },
{ USB_DEVICE(0x0489, 0xe078) },
{ USB_DEVICE(0x04c5, 0x1330) },
{ USB_DEVICE(0x04CA, 0x3004) },
@@ -135,6 +136,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe05f), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0489, 0xe076), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe078), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ae854bab7dfa..6f37775139f1 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -170,6 +170,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe05f), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0489, 0xe076), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe078), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 054/185] Bluetooth: btusb: Fix memory leak in Intel setup routine

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Marcel Holtmann 

commit ecffc80478cdce122f0ecb6a4e4f909132dd5c47 upstream.

The SKB returned from the Intel specific version information command is
missing a kfree_skb.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg 
Signed-off-by: Luis Henriques 
---
 drivers/bluetooth/btusb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index fbedcf61060f..41c4a74d589f 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1307,6 +1307,8 @@ static int btusb_setup_intel(struct hci_dev *hdev)
}
fw_ptr = fw->data;
 
+   kfree_skb(skb);
+
/* This Intel specific command enables the manufacturer mode of the
 * controller.
 *
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm64: dts: sprd: adding ETM entries to Spreadtrum SC9836

[Olof Johansson]

On Wed, Jul 15, 2015 at 03:05:48PM +0800, Chunyan Zhang wrote:
> Since ETMv4 driver has been merged, this patch adds ETM nodes for SC9836,
> and four funnel input ports to connect with ETM output ports.
> 
> Signed-off-by: Chunyan Zhang 

Thanks, applied.


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

[PATCH 3.16.y-ckt 057/185] cdc-acm: Add support of ATOL FPrint fiscal printers

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alexey Sokolov 

commit 15bf722e6f6c0b884521a0363204532e849deb7f upstream.

ATOL FPrint fiscal printers require usb_clear_halt to be executed
to work properly. Add quirk to fix the issue.

Signed-off-by: Alexey Sokolov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Luis Henriques 
---
 drivers/usb/class/cdc-acm.c | 9 +
 drivers/usb/class/cdc-acm.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index a8946e88978e..54c79f7fdaf5 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1480,6 +1480,11 @@ skip_countries:
goto alloc_fail8;
}
 
+   if (quirks & CLEAR_HALT_CONDITIONS) {
+   usb_clear_halt(usb_dev, usb_rcvbulkpipe(usb_dev, 
epread->bEndpointAddress));
+   usb_clear_halt(usb_dev, usb_sndbulkpipe(usb_dev, 
epwrite->bEndpointAddress));
+   }
+
return 0;
 alloc_fail8:
if (acm->country_codes) {
@@ -1759,6 +1764,10 @@ static const struct usb_device_id acm_ids[] = {
.driver_info = NO_UNION_NORMAL, /* reports zero length descriptor */
},
 
+   { USB_DEVICE(0x2912, 0x0001), /* ATOL FPrint */
+   .driver_info = CLEAR_HALT_CONDITIONS,
+   },
+
/* Nokia S60 phones expose two ACM channels. The first is
 * a modem and is picked up by the standard AT-command
 * information below. The second is 'vendor-specific' but
diff --git a/drivers/usb/class/cdc-acm.h b/drivers/usb/class/cdc-acm.h
index d3251ebd09e2..9cca2e7280bb 100644
--- a/drivers/usb/class/cdc-acm.h
+++ b/drivers/usb/class/cdc-acm.h
@@ -134,3 +134,4 @@ struct acm {
 #define NO_DATA_INTERFACE  BIT(4)
 #define IGNORE_DEVICE  BIT(5)
 #define QUIRK_CONTROL_LINE_STATE   BIT(6)
+#define CLEAR_HALT_CONDITIONS  BIT(7)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 049/185] drm/qxl: Do not cause spice-server to clean our objects

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Frediano Ziglio 

commit 2fa19535ca6abcbfd1ccc9ef694db52f49f77747 upstream.

If objects are moved back from system memory to VRAM (and spice id
created again) memory is already initialized so we need to set flag
to not clear memory.
If you don't do it after a while using desktop many images turns to
black or transparents.

Signed-off-by: Frediano Ziglio 
Reviewed-by: Dave Airlie 
Signed-off-by: Dave Airlie 
Signed-off-by: Luis Henriques 
---
 drivers/gpu/drm/qxl/qxl_cmd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index eb89653a7a17..c5e96a38f859 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -505,6 +505,7 @@ int qxl_hw_surface_alloc(struct qxl_device *qdev,
 
cmd = (struct qxl_surface_cmd *)qxl_release_map(qdev, release);
cmd->type = QXL_SURFACE_CMD_CREATE;
+   cmd->flags = QXL_SURF_FLAG_KEEP_DATA;
cmd->u.surface_create.format = surf->surf.format;
cmd->u.surface_create.width = surf->surf.width;
cmd->u.surface_create.height = surf->surf.height;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock

[Sylwester nawrocki]

On 07/01/2015 10:10 PM, Bartlomiej Zolnierkiewicz wrote:

From: Thomas Abraham

With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos5250.

Changes by Bartlomiej:
- split Exynos5250 support from the original patch
- moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c

Cc: Tomasz Figa
Cc: Michael Turquette
Cc: Javier Martinez Canillas
Signed-off-by: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz


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

Re: [PATCH v2 6/6] locking/pvqspinlock: Queue node adaptive spinning

[Peter Zijlstra]

On Tue, Jul 14, 2015 at 10:13:37PM -0400, Waiman Long wrote:
> +static void pv_wait_node(struct mcs_spinlock *node, struct mcs_spinlock 
> *prev)
>  {
>   struct pv_node *pn = (struct pv_node *)node;
> + struct pv_node *pp = (struct pv_node *)prev;
> + bool wait_early, can_wait_early;
>   int loop;
>  
>   for (;;) {
> - for (loop = SPIN_THRESHOLD; loop; loop--) {
> + /*
> +  * Spin less if the previous vCPU was in the halted state
> +  * and it is not the queue head.
> +  */
> + can_wait_early = (pn->waithist > PV_WAITHIST_THRESHOLD);
> + wait_early = can_wait_early && !READ_ONCE(prev->locked) &&
> +  (READ_ONCE(pp->state) == vcpu_halted);
> + loop = wait_early ? QNODE_SPIN_THRESHOLD_SHORT
> +   : QNODE_SPIN_THRESHOLD;
> + for (; loop; loop--, cpu_relax()) {
> + bool halted;
> +
>   if (READ_ONCE(node->locked))
>   return;
> - cpu_relax();
> +
> + if (!can_wait_early || (loop & QNODE_SPIN_CHECK_MASK))
> + continue;
> +
> + /*
> +  * Look for state transition at previous node.
> +  *
> +  * running => halted:
> +  *  call pv_wait() now if kick-ahead is enabled
> +  *  or reduce spin threshold to
> +  *  QNODE_SPIN_THRESHOLD_SHORT or less.
> +  * halted => running:
> +  *  reset spin threshold to QNODE_SPIN_THRESHOLD
> +  */
> + halted = (READ_ONCE(pp->state) == vcpu_halted) &&
> +  !READ_ONCE(prev->locked);
> + if (wait_early == halted)
> + continue;
> + wait_early = halted;
> +
> + if (!wait_early)
> + loop = QNODE_SPIN_THRESHOLD;
> + else if (pv_kick_ahead)
> + break;
> + else if (loop > QNODE_SPIN_THRESHOLD_SHORT)
> + loop = QNODE_SPIN_THRESHOLD_SHORT;
>   }
> + if (wait_early)
> + pvstat_inc(pvstat_wait_early);
> +
> + /*
> +  * A pv_wait while !wait_early has higher weight than when
> +  * wait_early is true.
> +  */
> + if (pn->waithist < PV_WAITHIST_MAX)
> + pn->waithist += wait_early ? 1 : PV_WAIT_INC;

So when you looked at this patch, you didn't go like, OMFG!?

So what was wrong with something like:

static inline int pv_spin_threshold(struct pv_node *prev)
{
if (READ_ONCE(prev->locked)) /* it can run, wait for it */
return SPIN_THRESHOLD;

if (READ_ONCE(prev->state) == vcpu_halted) /* its not running, do not 
wait */
return 1;

return SPIN_THRESHOLD;
}

static void pv_wait_head(...)
{
for (;;) {
for (loop = pv_spin_threshold(pp); loop; loop--) {
if (READ_ONCE(node->locked))
return;
cpu_relax();
}

if (!lp) {
...
}
pv_wait(>locked, _Q_SLOW_VAL);
}
}

What part of: "keep it simple" and "gradual complexity" have you still
not grasped?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 055/185] ath9k: fix DMA stop sequence for AR9003+

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Felix Fietkau 

commit 300f77c08ded96d33f492aaa02549103852f0c12 upstream.

AR93xx and newer needs to stop rx before tx to avoid getting the DMA
engine or MAC into a stuck state.
This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam.

Signed-off-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
Signed-off-by: Luis Henriques 
---
 drivers/net/wireless/ath/ath9k/main.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index 62ac95d6bb9d..bf6efbc2c9c0 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -205,11 +205,13 @@ static bool ath_prepare_reset(struct ath_softc *sc)
ath_stop_ani(sc);
ath9k_hw_disable_interrupts(ah);
 
-   if (!ath_drain_all_txq(sc))
-   ret = false;
-
-   if (!ath_stoprecv(sc))
-   ret = false;
+   if (AR_SREV_9300_20_OR_LATER(ah)) {
+   ret &= ath_stoprecv(sc);
+   ret &= ath_drain_all_txq(sc);
+   } else {
+   ret &= ath_drain_all_txq(sc);
+   ret &= ath_stoprecv(sc);
+   }
 
return ret;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 058/185] regulator: core: fix constraints output buffer

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Stefan Wahren 

commit a7068e3932eee8268c4ce4e080a338ee7b8a27bf upstream.

The buffer for condtraints debug isn't big enough to hold the output
in all cases. So fix this issue by increasing the buffer.

Signed-off-by: Stefan Wahren 
Signed-off-by: Mark Brown 
Signed-off-by: Luis Henriques 
---
 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index efeb4b42c5ed..a2e836478549 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -773,7 +773,7 @@ static int suspend_prepare(struct regulator_dev *rdev, 
suspend_state_t state)
 static void print_constraints(struct regulator_dev *rdev)
 {
struct regulation_constraints *constraints = rdev->constraints;
-   char buf[80] = "";
+   char buf[160] = "";
int count = 0;
int ret;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 056/185] b43: fix support for 14e4:4321 PCI dev with BCM4321 chipset

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= 

commit 90f91b129810c3f169e443252be30ed7c0130326 upstream.

It seems Broadcom released two devices with conflicting device id. There
are for sure 14e4:4321 PCI devices with BCM4321 (N-PHY) chipset, they
can be found in routers, e.g. Netgear WNR834Bv2. However, according to
Broadcom public sources 0x4321 is also used for 5 GHz BCM4306 (G-PHY).
It's unsure if they meant PCI device id, or "virtual" id (from SPROM).
To distinguish these devices lets check PHY type (G vs. N).

Signed-off-by: Rafał Miłecki 
Signed-off-by: Kalle Valo 
Signed-off-by: Luis Henriques 
---
 drivers/net/wireless/b43/main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 0d6a0bb1f876..8556325e98a3 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -5130,6 +5130,10 @@ static void b43_supported_bands(struct b43_wldev *dev, 
bool *have_2ghz_phy,
*have_5ghz_phy = true;
return;
case 0x4321: /* BCM4306 */
+   /* There are 14e4:4321 PCI devs with 2.4 GHz BCM4321 (N-PHY) */
+   if (dev->phy.type != B43_PHYTYPE_G)
+   break;
+   /* fall through */
case 0x4313: /* BCM4311 */
case 0x431a: /* BCM4318 */
case 0x432a: /* BCM4321 */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 059/185] ACPI / PM: Add missing pm_generic_complete() invocation

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Rafael J. Wysocki" 

commit 3d56402d3fa8d10749eeb36293dd1992bd5ad0c3 upstream.

Add missing invocation of pm_generic_complete() to
acpi_subsys_complete() to allow ->complete callbacks provided
by the drivers of devices using the ACPI PM domain to be executed
during system resume.

Fixes: f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during 
system suspend)
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Luis Henriques 
---
 drivers/acpi/device_pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index f702dcef4df9..e9f44a210712 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -930,6 +930,7 @@ EXPORT_SYMBOL_GPL(acpi_subsys_prepare);
  */
 void acpi_subsys_complete(struct device *dev)
 {
+   pm_generic_complete(dev);
/*
 * If the device had been runtime-suspended before the system went into
 * the sleep state it is going out of and it has never been resumed till
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 062/185] pinctrl: mvebu: armada-370: fix spi0 pin description

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Thomas Petazzoni 

commit 438881dfddb9107ef0eb30b49368e91e092f0b3e upstream.

Due to a mistake, the CS0 and CS1 SPI0 functions were incorrectly
named "spi0-1" instead of just "spi0". This commit fixes that.

This DT binding change does not affect any of the in-tree users.

Signed-off-by: Thomas Petazzoni 
Fixes: 5f597bb2be57 ("pinctrl: mvebu: add pinctrl driver for Armada 370")
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques 
---
 .../devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt| 4 ++--
 drivers/pinctrl/mvebu/pinctrl-armada-370.c| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
index adda2a8d1d52..e357b020861d 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
@@ -92,5 +92,5 @@ mpp61 61   gpo, dev(wen1), uart1(txd), audio(rclk)
 mpp62 62   gpio, dev(a2), uart1(cts), tdm(drx), pcie(clkreq0),
audio(mclk), uart0(cts)
 mpp63 63   gpo, spi0(sck), tclk
-mpp64 64   gpio, spi0(miso), spi0-1(cs1)
-mpp65 65   gpio, spi0(mosi), spi0-1(cs2)
+mpp64 64   gpio, spi0(miso), spi0(cs1)
+mpp65 65   gpio, spi0(mosi), spi0(cs2)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-370.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
index 670e5b01c678..5e423e0b0cb2 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-370.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
@@ -370,11 +370,11 @@ static struct mvebu_mpp_mode mv88f6710_mpp_modes[] = {
MPP_MODE(64,
   MPP_FUNCTION(0x0, "gpio", NULL),
   MPP_FUNCTION(0x1, "spi0", "miso"),
-  MPP_FUNCTION(0x2, "spi0-1", "cs1")),
+  MPP_FUNCTION(0x2, "spi0", "cs1")),
MPP_MODE(65,
   MPP_FUNCTION(0x0, "gpio", NULL),
   MPP_FUNCTION(0x1, "spi0", "mosi"),
-  MPP_FUNCTION(0x2, "spi0-1", "cs2")),
+  MPP_FUNCTION(0x2, "spi0", "cs2")),
 };
 
 static struct mvebu_pinctrl_soc_info armada_370_pinctrl_info;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 061/185] pinctrl: mvebu: armada-38x: fix PCIe functions

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Thomas Petazzoni 

commit 331642fbf24a1c16b2669ca0a6479b5fcd6dd5b2 upstream.

A new revision of the Marvell Armada 38x hardware datasheet unveiled
that the definition of some of the PCIe functions were not
correct. This commit fixes the pinctrl driver accordingly.

Some PCIe functions simply do not exist, some of the PCIe functions in
fact were corresponding to other functions, and some PCIe functions
have been added.

Note: the seemingly unrelated removal of spi(cs2) on MPP47 is related:
this function is in fact implemented on MPP43, instead of a PCIe
function.

Signed-off-by: Thomas Petazzoni 
Fixes: ca6d9a084b56f ("pinctrl: mvebu: add pin-muxing driver for the Marvell 
Armada 380/385")
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques 
---
 .../pinctrl/marvell,armada-38x-pinctrl.txt | 38 -
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 49 +-
 2 files changed, 39 insertions(+), 48 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt
index b17c96849fc9..4ac138aaaf87 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt
@@ -27,15 +27,15 @@ mpp8  8gpio, ge0(txd1), dev(ad10)
 mpp9  9gpio, ge0(txd2), dev(ad11)
 mpp10 10   gpio, ge0(txd3), dev(ad12)
 mpp11 11   gpio, ge0(txctl), dev(ad13)
-mpp12 12   gpio, ge0(rxd0), pcie0(rstout), pcie1(rstout) [1], 
spi0(cs1), dev(ad14)
-mpp13 13   gpio, ge0(rxd1), pcie0(clkreq), pcie1(clkreq) [1], 
spi0(cs2), dev(ad15)
-mpp14 14   gpio, ge0(rxd2), ptp(clk), m(vtt_ctrl), spi0(cs3), 
dev(wen1)
-mpp15 15   gpio, ge0(rxd3), ge(mdc slave), pcie0(rstout), 
spi0(mosi), pcie1(rstout) [1]
-mpp16 16   gpio, ge0(rxctl), ge(mdio slave), m(decc_err), 
spi0(miso), pcie0(clkreq)
+mpp12 12   gpio, ge0(rxd0), pcie0(rstout), spi0(cs1), dev(ad14), 
pcie3(clkreq)
+mpp13 13   gpio, ge0(rxd1), pcie0(clkreq), pcie1(clkreq) [1], 
spi0(cs2), dev(ad15), pcie2(clkreq)
+mpp14 14   gpio, ge0(rxd2), ptp(clk), m(vtt_ctrl), spi0(cs3), 
dev(wen1), pcie3(clkreq)
+mpp15 15   gpio, ge0(rxd3), ge(mdc slave), pcie0(rstout), 
spi0(mosi)
+mpp16 16   gpio, ge0(rxctl), ge(mdio slave), m(decc_err), 
spi0(miso), pcie0(clkreq), pcie1(clkreq) [1]
 mpp17 17   gpio, ge0(rxclk), ptp(clk), ua1(rxd), spi0(sck), 
sata1(prsnt)
-mpp18 18   gpio, ge0(rxerr), ptp(trig_gen), ua1(txd), spi0(cs0), 
pcie1(rstout) [1]
-mpp19 19   gpio, ge0(col), ptp(event_req), pcie0(clkreq), 
sata1(prsnt), ua0(cts)
-mpp20 20   gpio, ge0(txclk), ptp(clk), pcie1(rstout) [1], 
sata0(prsnt), ua0(rts)
+mpp18 18   gpio, ge0(rxerr), ptp(trig_gen), ua1(txd), spi0(cs0)
+mpp19 19   gpio, ge0(col), ptp(event_req), ge0(txerr), 
sata1(prsnt), ua0(cts)
+mpp20 20   gpio, ge0(txclk), ptp(clk), sata0(prsnt), ua0(rts)
 mpp21 21   gpio, spi0(cs1), ge1(rxd0), sata0(prsnt), sd0(cmd), 
dev(bootcs)
 mpp22 22   gpio, spi0(mosi), dev(ad0)
 mpp23 23   gpio, spi0(sck), dev(ad2)
@@ -58,23 +58,23 @@ mpp39 39   gpio, i2c1(sck), ge1(rxd2), 
ua0(cts), sd0(d1), dev(a2)
 mpp40 40   gpio, i2c1(sda), ge1(rxd3), ua0(rts), sd0(d2), dev(ad6)
 mpp41 41   gpio, ua1(rxd), ge1(rxctl), ua0(cts), spi1(cs3), 
dev(burst/last)
 mpp42 42   gpio, ua1(txd), ua0(rts), dev(ad7)
-mpp43 43   gpio, pcie0(clkreq), m(vtt_ctrl), m(decc_err), 
pcie0(rstout), dev(clkout)
-mpp44 44   gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], 
sata3(prsnt) [3], pcie0(rstout)
-mpp45 45   gpio, ref(clk_out0), pcie0(rstout), pcie1(rstout) [1], 
pcie2(rstout), pcie3(rstout)
-mpp46 46   gpio, ref(clk_out1), pcie0(rstout), pcie1(rstout) [1], 
pcie2(rstout), pcie3(rstout)
-mpp47 47   gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], 
spi1(cs2), sata3(prsnt) [2]
-mpp48 48   gpio, sata0(prsnt), m(vtt_ctrl), tdm2c(pclk), 
audio(mclk), sd0(d4)
-mpp49 49   gpio, sata2(prsnt) [2], sata3(prsnt) [2], tdm2c(fsync), 
audio(lrclk), sd0(d5)
-mpp50 50   gpio, pcie0(rstout), pcie1(rstout) [1], tdm2c(drx), 
audio(extclk), sd0(cmd)
+mpp43 43   gpio, pcie0(clkreq), m(vtt_ctrl), m(decc_err), 
spi1(cs2), dev(clkout)
+mpp44 44   gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], 
sata3(prsnt) [3]
+mpp45 45   gpio, ref(clk_out0), pcie0(rstout)
+mpp46 46   gpio, ref(clk_out1), pcie0(rstout)
+mpp47 47   gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) 

[PATCH 3.16.y-ckt 069/185] i2c: at91: fix a race condition when using the DMA controller

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Cyrille Pitchen 

commit 93563a6a71bb69dd324fc7354c60fb05f84aae6b upstream.

For TX transactions, the TXCOMP bit in the Status Register is cleared
when the first data is written into the Transmit Holding Register.

In the lines from at91_do_twi_transfer():
at91_twi_write_data_dma(dev);
at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP);

the TXCOMP interrupt may be enabled before the DMA controller has
actually started to write into the THR. In such a case, the TXCOMP bit
is still set into the Status Register so the interrupt is triggered
immediately. The driver understands that a transaction completion has
occurred but this transaction hasn't started yet. Hence the TXCOMP
interrupt is no longer enabled by at91_do_twi_transfer() but instead
by at91_twi_write_data_dma_callback().

Also, the TXCOMP bit in the Status Register in not a clear on read flag
but a snapshot of the transmission state at the time the Status
Register is read.
When a NACK error is dectected by the I2C controller, the TXCOMP, NACK
and TXRDY bits are set together to 1 in the SR. If enabled, the TXCOMP
interrupt is triggered at the same time. Also setting the TXRDY to 1
triggers the DMA controller to write the next data into the THR. Such
a write resets the TXCOMP bit to 0 in the SR. So depending on when the
interrupt handler reads the SR, it may fail to detect the NACK error
if it relies on the TXCOMP bit. The NACK bit and its interrupt should
be used instead.

For RX transactions, the TXCOMP bit in the Status Register is cleared
when the START bit is set into the Control Register. However to unify
the management of the TXCOMP bit when the DMA controller is used, the
TXCOMP interrupt is now enabled by the DMA callbacks for both TX and
RX transfers.

Signed-off-by: Cyrille Pitchen 
Acked-by: Ludovic Desroches 
Signed-off-by: Wolfram Sang 
Signed-off-by: Luis Henriques 
---
 drivers/i2c/busses/i2c-at91.c | 70 ---
 1 file changed, 53 insertions(+), 17 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 30c8c1e738e1..c8ec841cf705 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -62,6 +62,9 @@
 #defineAT91_TWI_UNRE   0x0080  /* Underrun Error */
 #defineAT91_TWI_NACK   0x0100  /* Not Acknowledged */
 
+#defineAT91_TWI_INT_MASK \
+   (AT91_TWI_TXCOMP | AT91_TWI_RXRDY | AT91_TWI_TXRDY | AT91_TWI_NACK)
+
 #defineAT91_TWI_IER0x0024  /* Interrupt Enable Register */
 #defineAT91_TWI_IDR0x0028  /* Interrupt Disable Register */
 #defineAT91_TWI_IMR0x002c  /* Interrupt Mask Register */
@@ -117,13 +120,12 @@ static void at91_twi_write(struct at91_twi_dev *dev, 
unsigned reg, unsigned val)
 
 static void at91_disable_twi_interrupts(struct at91_twi_dev *dev)
 {
-   at91_twi_write(dev, AT91_TWI_IDR,
-  AT91_TWI_TXCOMP | AT91_TWI_RXRDY | AT91_TWI_TXRDY);
+   at91_twi_write(dev, AT91_TWI_IDR, AT91_TWI_INT_MASK);
 }
 
 static void at91_twi_irq_save(struct at91_twi_dev *dev)
 {
-   dev->imr = at91_twi_read(dev, AT91_TWI_IMR) & 0x7;
+   dev->imr = at91_twi_read(dev, AT91_TWI_IMR) & AT91_TWI_INT_MASK;
at91_disable_twi_interrupts(dev);
 }
 
@@ -213,6 +215,14 @@ static void at91_twi_write_data_dma_callback(void *data)
dma_unmap_single(dev->dev, sg_dma_address(>dma.sg),
 dev->buf_len, DMA_TO_DEVICE);
 
+   /*
+* When this callback is called, THR/TX FIFO is likely not to be empty
+* yet. So we have to wait for TXCOMP or NACK bits to be set into the
+* Status Register to be sure that the STOP bit has been sent and the
+* transfer is completed. The NACK interrupt has already been enabled,
+* we just have to enable TXCOMP one.
+*/
+   at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_STOP);
 }
 
@@ -307,7 +317,7 @@ static void at91_twi_read_data_dma_callback(void *data)
/* The last two bytes have to be read without using dma */
dev->buf += dev->buf_len - 2;
dev->buf_len = 2;
-   at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_RXRDY);
+   at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_RXRDY | AT91_TWI_TXCOMP);
 }
 
 static void at91_twi_read_data_dma(struct at91_twi_dev *dev)
@@ -368,7 +378,7 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
/* catch error flags */
dev->transfer_status |= status;
 
-   if (irqstatus & AT91_TWI_TXCOMP) {
+   if (irqstatus & (AT91_TWI_TXCOMP | AT91_TWI_NACK)) {
at91_disable_twi_interrupts(dev);
complete(>cmd_complete);
}
@@ -381,6 +391,34 @@ static int at91_do_twi_transfer(struct at91_twi_dev *dev)
int ret;
bool 

Re: [PATCH v2 4/7] clk: samsung: exynos4x12: add cpu clock configuration data and instantiate cpu clock

[Sylwester nawrocki]

On 07/10/2015 12:43 AM, Bartlomiej Zolnierkiewicz wrote:

With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos4x12.

Based on the earlier work by Thomas Abraham.

Cc: Tomasz Figa 
Cc: Michael Turquette 
Cc: Javier Martinez Canillas 
Cc: Thomas Abraham 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
  drivers/clk/samsung/clk-exynos4.c | 50 +++
  1 file changed, 50 insertions(+)


I guess you prefer to have this whole series applied through one,
e.g samsung-soc tree? If so, here is my ack.

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

[PATCH 3.16.y-ckt 063/185] pinctrl: mvebu: armada-375: remove non-existing NAND re/we pins

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Thomas Petazzoni 

commit e5447d26092c72ef3346615ee558c9112ef8063f upstream.

After updating to a more recent version of the Armada 375, we realized
that some of the pins documented as having a NAND-related
functionality in fact did not have such functionality. This commit
updates the pinctrl driver accordingly.

Signed-off-by: Thomas Petazzoni 
Fixes: ce3ed59dcddd ("pinctrl: mvebu: add pin-muxing driver for the Marvell 
Armada 375")
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques 
---
 .../devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt| 4 ++--
 drivers/pinctrl/mvebu/pinctrl-armada-375.c| 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt
index 7de0cda4a379..bedbe42c8c0a 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt
@@ -22,8 +22,8 @@ mpp5  5gpio, dev(ad7), spi0(cs2), spi1(cs2)
 mpp6  6gpio, dev(ad0), led(p1), audio(rclk)
 mpp7  7gpio, dev(ad1), ptp(clk), led(p2), audio(extclk)
 mpp8  8gpio, dev (bootcs), spi0(cs0), spi1(cs0)
-mpp9  9gpio, nf(wen), spi0(sck), spi1(sck)
-mpp1010gpio, nf(ren), dram(vttctrl), led(c1)
+mpp9  9gpio, spi0(sck), spi1(sck), nand(we)
+mpp1010gpio, dram(vttctrl), led(c1), nand(re)
 mpp1111gpio, dev(a0), led(c2), audio(sdo)
 mpp1212gpio, dev(a1), audio(bclk)
 mpp1313gpio, dev(readyn), pcie0(rstoutn), pcie1(rstoutn)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-375.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
index db078fe7ace6..a5089029ba6c 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-375.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
@@ -98,13 +98,11 @@ static struct mvebu_mpp_mode mv88f6720_mpp_modes[] = {
 MPP_FUNCTION(0x5, "nand", "ce")),
MPP_MODE(9,
 MPP_FUNCTION(0x0, "gpio", NULL),
-MPP_FUNCTION(0x1, "nf", "wen"),
 MPP_FUNCTION(0x2, "spi0", "sck"),
 MPP_FUNCTION(0x3, "spi1", "sck"),
 MPP_FUNCTION(0x5, "nand", "we")),
MPP_MODE(10,
 MPP_FUNCTION(0x0, "gpio", NULL),
-MPP_FUNCTION(0x1, "nf", "ren"),
 MPP_FUNCTION(0x2, "dram", "vttctrl"),
 MPP_FUNCTION(0x3, "led", "c1"),
 MPP_FUNCTION(0x5, "nand", "re"),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] dmaengine: fsl-edma: add PM suspend/resume support

[Arnd Bergmann]

On Wednesday 15 July 2015 17:32:58 Yuan Yao wrote:
> +#ifdef CONFIG_PM
> +enum fsl_edma_pm_state {
> +   RUNNING = 0,
> +   SUSPENDED,
> +};
> +#endif
>  
>  struct fsl_edma_hw_tcd {
> 

The #ifdefs here seem unnecessary, at least most of them, better
just do this all unconditionally.

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

Re: MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR]

[Laszlo Ersek]

On 07/15/15 00:37, Jordan Justen wrote:
> On 2015-07-14 14:29:11, Laszlo Ersek wrote:
>> On 07/14/15 23:15, Paolo Bonzini wrote:
 The long delay that Alex reported (for the case when all guest memory
 was set to UC up-front) is due to the fact that the SEC phase of OVMF
 decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
 approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI
 drivers -- and this decompression is extremely memory-intensive.

 (When Jordan implemented that reset vector first, we saw similar
 performance degradation on AMD hosts (albeit not due to MTRR but due to
 page attributes). See
 . I'm only mentioning
 it here because it makes me appreciate the current problem report.)

 Anyway, the reset vector's page table building is implemented in
 "OvmfPkg/ResetVector/Ia32/PageTables64.asm". The decompression in SEC
 can be found in "OvmfPkg/Sec/SecMain.c", function DecompressMemFvs().
>>>
>>> Perhaps the OVMF reset vector should initialize the MTRRs for the BSP?
>>
>> That's an idea, yes, if someone feels sufficiently drawn to writing
>> assembly.
> 
> Maybe we can use MtrrLib in the SEC C code?

If the page table building in the reset vector is not too costly with
UC, then yes, it should suffice if MtrrLib was put to use first just
before the decompression in SEC.

Thanks
Laszlo

> -Jordan
> 
>> Complications:
>> - the reset vector is specific to OvmfPkg only in the OvmfPkgX64.dsc
>>   build
>> - it needs to be determined what memory to cover.
>>
>>> I think SEC doesn't do any MMIO, so it should be enough to enable MTRRs
>>> and set the default type to writeback.
>>
>> Seems safe to me, off the top of my head (and testing could confirm /
>> disprove quickly).
>>
>>> In any case we're going to have to quirk it, because of the broken
>>> guests in the wild.
>>
>> Thanks.
>> Laszlo

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

[PATCH 3.16.y-ckt 066/185] pinctrl: mvebu: armada-xp: fix functions of MPP48

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Thomas Petazzoni 

commit ea78b9511a54d0de026e04b5da86b30515072f31 upstream.

There was a mistake in the definition of the functions for MPP48 on
Marvell Armada XP. The second function is dev(clkout), and not tclk.

Signed-off-by: Thomas Petazzoni 
Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP")
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques 
---
 Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt | 2 +-
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
index b347b85aa22e..96e7744cab84 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
@@ -69,7 +69,7 @@ mpp45 45   gpio, uart2(rts), uart3(txd), 
spi(cs5), sata1(prsnt)
 mpp46 46   gpio, uart3(rts), uart1(rts), spi(cs6), sata0(prsnt)
 mpp47 47   gpio, uart3(cts), uart1(cts), spi(cs7), pcie(clkreq3),
ref(clkout)
-mpp48 48   gpio, tclk, dev(burst/last)
+mpp48 48   gpio, dev(clkout), dev(burst/last)
 
 * Marvell Armada XP (mv78260 and mv78460 only)
 
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 529ad9f4e1a6..cb06fd293fd2 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -286,7 +286,7 @@ static struct mvebu_mpp_mode armada_xp_mpp_modes[] = {
 MPP_VAR_FUNCTION(0x5, "pcie", "clkreq3",   V_MV78230_PLUS)),
MPP_MODE(48,
 MPP_VAR_FUNCTION(0x0, "gpio", NULL,V_MV78230_PLUS),
-MPP_VAR_FUNCTION(0x1, "tclk", NULL,V_MV78230_PLUS),
+MPP_VAR_FUNCTION(0x1, "dev", "clkout", V_MV78230_PLUS),
 MPP_VAR_FUNCTION(0x2, "dev", "burst/last", V_MV78230_PLUS)),
MPP_MODE(49,
 MPP_VAR_FUNCTION(0x0, "gpio", NULL,V_MV78260_PLUS),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 072/185] arm64: Do not attempt to use init_mm in reset_context()

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Catalin Marinas 

commit 565630d503ef24e44c252bed55571b3a0d68455f upstream.

After secondary CPU boot or hotplug, the active_mm of the idle thread is
_mm. The init_mm.pgd (swapper_pg_dir) is only meant for TTBR1_EL1
and must not be set in TTBR0_EL1. Since when active_mm == _mm the
TTBR0_EL1 is already set to the reserved value, there is no need to
perform any context reset.

Signed-off-by: Catalin Marinas 
Signed-off-by: Luis Henriques 
---
 arch/arm64/mm/context.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index baa758d37021..76c1e6cd36fc 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -92,6 +92,14 @@ static void reset_context(void *info)
unsigned int cpu = smp_processor_id();
struct mm_struct *mm = current->active_mm;
 
+   /*
+* current->active_mm could be init_mm for the idle thread immediately
+* after secondary CPU boot or hotplug. TTBR0_EL1 is already set to
+* the reserved value, so no need to reset any context.
+*/
+   if (mm == _mm)
+   return;
+
smp_rmb();
asid = cpu_last_asid + cpu;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 070/185] dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Lior Amsalem 

commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 upstream.

This patch fixes a bug in the XOR driver where the cleanup function can be
called and free descriptors that never been processed by the engine (which
result in data errors).

The cleanup function will free descriptors based on the ownership bit in
the descriptors.

Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine")
Signed-off-by: Lior Amsalem 
Signed-off-by: Maxime Ripard 
Reviewed-by: Ofer Heifetz 
Signed-off-by: Vinod Koul 
[ luis: backported to 3.16:
  - function rename: mv_xor_slot_cleanup() -> __mv_xor_slot_cleanup()
  - adjusted context ]
Signed-off-by: Luis Henriques 
---
 drivers/dma/mv_xor.c | 72 +---
 drivers/dma/mv_xor.h |  1 +
 2 files changed, 47 insertions(+), 26 deletions(-)

diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 394cbc5c93e3..6b2f01d60527 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -316,7 +316,8 @@ static void __mv_xor_slot_cleanup(struct mv_xor_chan 
*mv_chan)
dma_cookie_t cookie = 0;
int busy = mv_chan_is_busy(mv_chan);
u32 current_desc = mv_chan_get_current_desc(mv_chan);
-   int seen_current = 0;
+   int current_cleaned = 0;
+   struct mv_xor_desc *hw_desc;
 
dev_dbg(mv_chan_to_devp(mv_chan), "%s %d\n", __func__, __LINE__);
dev_dbg(mv_chan_to_devp(mv_chan), "current_desc %x\n", current_desc);
@@ -328,38 +329,57 @@ static void __mv_xor_slot_cleanup(struct mv_xor_chan 
*mv_chan)
 
list_for_each_entry_safe(iter, _iter, _chan->chain,
chain_node) {
-   prefetch(_iter);
-   prefetch(&_iter->async_tx);
 
-   /* do not advance past the current descriptor loaded into the
-* hardware channel, subsequent descriptors are either in
-* process or have not been submitted
-*/
-   if (seen_current)
-   break;
+   /* clean finished descriptors */
+   hw_desc = iter->hw_desc;
+   if (hw_desc->status & XOR_DESC_SUCCESS) {
+   cookie = mv_xor_run_tx_complete_actions(iter, mv_chan,
+   cookie);
 
-   /* stop the search if we reach the current descriptor and the
-* channel is busy
-*/
-   if (iter->async_tx.phys == current_desc) {
-   seen_current = 1;
-   if (busy)
+   /* done processing desc, clean slot */
+   mv_xor_clean_slot(iter, mv_chan);
+
+   /* break if we did cleaned the current */
+   if (iter->async_tx.phys == current_desc) {
+   current_cleaned = 1;
+   break;
+   }
+   } else {
+   if (iter->async_tx.phys == current_desc) {
+   current_cleaned = 0;
break;
+   }
}
-
-   cookie = mv_xor_run_tx_complete_actions(iter, mv_chan, cookie);
-
-   if (mv_xor_clean_slot(iter, mv_chan))
-   break;
}
 
if ((busy == 0) && !list_empty(_chan->chain)) {
-   struct mv_xor_desc_slot *chain_head;
-   chain_head = list_entry(mv_chan->chain.next,
-   struct mv_xor_desc_slot,
-   chain_node);
-
-   mv_xor_start_new_chain(mv_chan, chain_head);
+   if (current_cleaned) {
+   /*
+* current descriptor cleaned and removed, run
+* from list head
+*/
+   iter = list_entry(mv_chan->chain.next,
+ struct mv_xor_desc_slot,
+ chain_node);
+   mv_xor_start_new_chain(mv_chan, iter);
+   } else {
+   if (!list_is_last(>chain_node, _chan->chain)) {
+   /*
+* descriptors are still waiting after
+* current, trigger them
+*/
+   iter = list_entry(iter->chain_node.next,
+ struct mv_xor_desc_slot,
+ chain_node);
+   mv_xor_start_new_chain(mv_chan, iter);
+   } else {
+   /*
+   

[PATCH 3.16.y-ckt 077/185] regmap: Fix regmap_bulk_read in BE mode

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Arun Chandran 

commit 15b8d2c41fe5839582029f65c5f7004db451cc2b upstream.

In big endian mode regmap_bulk_read gives incorrect data
for byte reads.

This is because memcpy of a single byte from an address
after full word read gives different results when
endianness differs. ie. we get little-end in LE and big-end in BE.

Signed-off-by: Arun Chandran 
Signed-off-by: Mark Brown 
Signed-off-by: Luis Henriques 
---
 drivers/base/regmap/regmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 457d335f8495..09fe07b6e98b 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2247,7 +2247,7 @@ int regmap_bulk_read(struct regmap *map, unsigned int 
reg, void *val,
  );
if (ret != 0)
return ret;
-   memcpy(val + (i * val_bytes), , val_bytes);
+   map->format.format_val(val + (i * val_bytes), ival, 0);
}
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 068/185] pinctrl: mvebu: armada-38x: fix incorrect total number of GPIOs

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Thomas Petazzoni 

commit 27e7cd016558bf787b128fd882cdd90409ae4036 upstream.

The pinctrl_gpio_range[] array described a first bank of 32 GPIOs and
a second one of 27 GPIOs. However, since there is a total of 60 MPP
pins that can be muxed as GPIOs, the second bank really has 28 GPIOs.

Signed-off-by: Thomas Petazzoni 
Fixes: ca6d9a084b56f ("pinctrl: mvebu: add pin-muxing driver for the Marvell 
Armada 380/385")
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques 
---
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-38x.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
index 1ee8d698eb96..adb6c238f059 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
@@ -400,7 +400,7 @@ static struct mvebu_mpp_ctrl armada_38x_mpp_controls[] = {
 
 static struct pinctrl_gpio_range armada_38x_mpp_gpio_ranges[] = {
MPP_GPIO_RANGE(0,   0,  0, 32),
-   MPP_GPIO_RANGE(1,  32, 32, 27),
+   MPP_GPIO_RANGE(1,  32, 32, 28),
 };
 
 static int armada_38x_pinctrl_probe(struct platform_device *pdev)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 074/185] Disable write buffering on Toshiba ToPIC95

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Ryan Underwood 

commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream.

Disable write buffering on the Toshiba ToPIC95 if it is enabled by
somebody (it is not supposed to be a power-on default according to
the datasheet). On the ToPIC95, practically no 32-bit Cardbus card
will work under heavy load without locking up the whole system if
this is left enabled. I tried about a dozen. It does not affect
16-bit cards. This is similar to the O2 bugs in early controller
revisions it seems.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961
Signed-off-by: Ryan C. Underwood 
Signed-off-by: Dominik Brodowski 
Signed-off-by: Luis Henriques 
---
 drivers/pcmcia/topic.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/pcmcia/topic.h b/drivers/pcmcia/topic.h
index 615a45a8fe86..582688fe7505 100644
--- a/drivers/pcmcia/topic.h
+++ b/drivers/pcmcia/topic.h
@@ -104,6 +104,9 @@
 #define TOPIC_EXCA_IF_CONTROL  0x3e/* 8 bit */
 #define TOPIC_EXCA_IFC_33V_ENA 0x01
 
+#define TOPIC_PCI_CFG_PPBCN0x3e/* 16-bit */
+#define TOPIC_PCI_CFG_PPBCN_WBEN   0x0400
+
 static void topic97_zoom_video(struct pcmcia_socket *sock, int onoff)
 {
struct yenta_socket *socket = container_of(sock, struct yenta_socket, 
socket);
@@ -138,6 +141,7 @@ static int topic97_override(struct yenta_socket *socket)
 static int topic95_override(struct yenta_socket *socket)
 {
u8 fctrl;
+   u16 ppbcn;
 
/* enable 3.3V support for 16bit cards */
fctrl = exca_readb(socket, TOPIC_EXCA_IF_CONTROL);
@@ -146,6 +150,18 @@ static int topic95_override(struct yenta_socket *socket)
/* tell yenta to use exca registers to power 16bit cards */
socket->flags |= YENTA_16BIT_POWER_EXCA | YENTA_16BIT_POWER_DF;
 
+   /* Disable write buffers to prevent lockups under load with numerous
+  Cardbus cards, observed on Tecra 500CDT and reported elsewhere on the
+  net.  This is not a power-on default according to the datasheet
+  but some BIOSes seem to set it. */
+   if (pci_read_config_word(socket->dev, TOPIC_PCI_CFG_PPBCN, ) == 0
+   && socket->dev->revision <= 7
+   && (ppbcn & TOPIC_PCI_CFG_PPBCN_WBEN)) {
+   ppbcn &= ~TOPIC_PCI_CFG_PPBCN_WBEN;
+   pci_write_config_word(socket->dev, TOPIC_PCI_CFG_PPBCN, ppbcn);
+   dev_info(>dev->dev, "Disabled ToPIC95 Cardbus write 
buffers.\n");
+   }
+
return 0;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 076/185] jbd2: use GFP_NOFS in jbd2_cleanup_journal_tail()

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Monakhov 

commit b4f1afcd068f6e533230dfed00782cd8a907f96b upstream.

jbd2_cleanup_journal_tail() can be invoked by jbd2__journal_start()
So allocations should be done with GFP_NOFS

[Full stack trace snipped from 3.10-rh7]
[] dump_stack+0x19/0x1b
[] warn_slowpath_common+0x61/0x80
[] warn_slowpath_null+0x1a/0x20
[] slab_pre_alloc_hook.isra.31.part.32+0x15/0x17
[] kmem_cache_alloc+0x55/0x210
[] ? mempool_alloc_slab+0x15/0x20
[] mempool_alloc_slab+0x15/0x20
[] mempool_alloc+0x69/0x170
[] ? _raw_spin_unlock_irq+0xe/0x20
[] ? finish_task_switch+0x5d/0x150
[] bio_alloc_bioset+0x1be/0x2e0
[] blkdev_issue_flush+0x99/0x120
[] jbd2_cleanup_journal_tail+0x93/0xa0 [jbd2] -->GFP_KERNEL
[] jbd2_log_do_checkpoint+0x221/0x4a0 [jbd2]
[] __jbd2_log_wait_for_space+0xa7/0x1e0 [jbd2]
[] start_this_handle+0x2d8/0x550 [jbd2]
[] ? __memcg_kmem_put_cache+0x29/0x30
[] ? kmem_cache_alloc+0x130/0x210
[] jbd2__journal_start+0xba/0x190 [jbd2]
[] ? lru_cache_add+0xe/0x10
[] ? ext4_da_write_begin+0xf9/0x330 [ext4]
[] __ext4_journal_start_sb+0x77/0x160 [ext4]
[] ext4_da_write_begin+0xf9/0x330 [ext4]
[] generic_file_buffered_write_iter+0x10c/0x270
[] __generic_file_write_iter+0x178/0x390
[] __generic_file_aio_write+0x8b/0xb0
[] generic_file_aio_write+0x5d/0xc0
[] ext4_file_write+0xa9/0x450 [ext4]
[] ? pipe_read+0x379/0x4f0
[] do_sync_write+0x90/0xe0
[] vfs_write+0xbd/0x1e0
[] SyS_write+0x58/0xb0
[] system_call_fastpath+0x16/0x1b

Signed-off-by: Dmitry Monakhov 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Luis Henriques 
---
 fs/jbd2/checkpoint.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
index 7f34f4716165..8d09e756b675 100644
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -463,7 +463,7 @@ int jbd2_cleanup_journal_tail(journal_t *journal)
 * jbd2_cleanup_journal_tail() doesn't get called all that often.
 */
if (journal->j_flags & JBD2_BARRIER)
-   blkdev_issue_flush(journal->j_fs_dev, GFP_KERNEL, NULL);
+   blkdev_issue_flush(journal->j_fs_dev, GFP_NOFS, NULL);
 
__jbd2_update_log_tail(journal, first_tid, blocknr);
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 071/185] ASoC: wm8960: the enum of "DAC Polarity" should be wm8960_enum[1]

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Zidan Wang 

commit a077e81ec61e07a7f86997d045109f06719fbffe upstream.

the enum of "DAC Polarity" should be wm8960_enum[1].

Signed-off-by: Zidan Wang 
Acked-by: Charles Keepax 
Signed-off-by: Mark Brown 
Signed-off-by: Luis Henriques 
---
 sound/soc/codecs/wm8960.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index 1f5a5eebfd67..c2acb2fabf33 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -242,7 +242,7 @@ SOC_SINGLE("PCM Playback -6dB Switch", WM8960_DACCTL1, 7, 
1, 0),
 SOC_ENUM("ADC Polarity", wm8960_enum[0]),
 SOC_SINGLE("ADC High Pass Filter Switch", WM8960_DACCTL1, 0, 1, 0),
 
-SOC_ENUM("DAC Polarity", wm8960_enum[2]),
+SOC_ENUM("DAC Polarity", wm8960_enum[1]),
 SOC_SINGLE_BOOL_EXT("DAC Deemphasis Switch", 0,
wm8960_get_deemph, wm8960_put_deemph),
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 073/185] ext4: fix race between truncate and __ext4_journalled_writepage()

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Theodore Ts'o 

commit bdf96838aea6a265f2ae6cbcfb12a778c84a0b8e upstream.

The commit cf108bca465d: "ext4: Invert the locking order of page_lock
and transaction start" caused __ext4_journalled_writepage() to drop
the page lock before the page was written back, as part of changing
the locking order to jbd2_journal_start -> page_lock.  However, this
introduced a potential race if there was a truncate racing with the
data=journalled writeback mode.

Fix this by grabbing the page lock after starting the journal handle,
and then checking to see if page had gotten truncated out from under
us.

This fixes a number of different warnings or BUG_ON's when running
xfstests generic/086 in data=journalled mode, including:

jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7
c0, 164), jh->b_transaction (  (null), 0), jh->b_next_transaction (  (null), 
0), jlist 0

  - and -

kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200!
...
Call Trace:
 [] ? __ext4_journalled_invalidatepage+0x117/0x117
 [] __ext4_journalled_invalidatepage+0x10f/0x117
 [] ? __ext4_journalled_invalidatepage+0x117/0x117
 [] ? lock_buffer+0x36/0x36
 [] ext4_journalled_invalidatepage+0xd/0x22
 [] do_invalidatepage+0x22/0x26
 [] truncate_inode_page+0x5b/0x85
 [] truncate_inode_pages_range+0x156/0x38c
 [] truncate_inode_pages+0x11/0x15
 [] truncate_pagecache+0x55/0x71
 [] ext4_setattr+0x4a9/0x560
 [] ? current_kernel_time+0x10/0x44
 [] notify_change+0x1c7/0x2be
 [] do_truncate+0x65/0x85
 [] ? file_ra_state_init+0x12/0x29

  - and -

WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396
irty_metadata+0x14a/0x1ae()
...
Call Trace:
 [] ? console_unlock+0x3a1/0x3ce
 [] dump_stack+0x48/0x60
 [] warn_slowpath_common+0x89/0xa0
 [] ? jbd2_journal_dirty_metadata+0x14a/0x1ae
 [] warn_slowpath_null+0x14/0x18
 [] jbd2_journal_dirty_metadata+0x14a/0x1ae
 [] __ext4_handle_dirty_metadata+0xd4/0x19d
 [] write_end_fn+0x40/0x53
 [] ext4_walk_page_buffers+0x4e/0x6a
 [] ext4_writepage+0x354/0x3b8
 [] ? mpage_release_unused_pages+0xd4/0xd4
 [] ? wait_on_buffer+0x2c/0x2c
 [] ? ext4_writepage+0x3b8/0x3b8
 [] __writepage+0x10/0x2e
 [] write_cache_pages+0x22d/0x32c
 [] ? ext4_writepage+0x3b8/0x3b8
 [] ext4_writepages+0x102/0x607
 [] ? sched_clock_local+0x10/0x10e
 [] ? __lock_is_held+0x2e/0x44
 [] ? lock_is_held+0x43/0x51
 [] do_writepages+0x1c/0x29
 [] __writeback_single_inode+0xc3/0x545
 [] writeback_sb_inodes+0x21f/0x36d
...

Signed-off-by: Theodore Ts'o 
Signed-off-by: Luis Henriques 
---
 fs/ext4/inode.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 6a37a1f51e56..fd3c9d5ac932 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1740,19 +1740,32 @@ static int __ext4_journalled_writepage(struct page 
*page,
ext4_walk_page_buffers(handle, page_bufs, 0, len,
   NULL, bget_one);
}
-   /* As soon as we unlock the page, it can go away, but we have
-* references to buffers so we are safe */
+   /*
+* We need to release the page lock before we start the
+* journal, so grab a reference so the page won't disappear
+* out from under us.
+*/
+   get_page(page);
unlock_page(page);
 
handle = ext4_journal_start(inode, EXT4_HT_WRITE_PAGE,
ext4_writepage_trans_blocks(inode));
if (IS_ERR(handle)) {
ret = PTR_ERR(handle);
-   goto out;
+   put_page(page);
+   goto out_no_pagelock;
}
-
BUG_ON(!ext4_handle_valid(handle));
 
+   lock_page(page);
+   put_page(page);
+   if (page->mapping != mapping) {
+   /* The page got truncated from under us */
+   ext4_journal_stop(handle);
+   ret = 0;
+   goto out;
+   }
+
if (inline_data) {
BUFFER_TRACE(inode_bh, "get write access");
ret = ext4_journal_get_write_access(handle, inode_bh);
@@ -1778,6 +1791,8 @@ static int __ext4_journalled_writepage(struct page *page,
   NULL, bput_one);
ext4_set_inode_state(inode, EXT4_STATE_JDATA);
 out:
+   unlock_page(page);
+out_no_pagelock:
brelse(inode_bh);
return ret;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 067/185] pinctrl: mvebu: armada-375: remove incorrect space in pin description

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Thomas Petazzoni 

commit d538990ee12b162f7ce6c0fcef3b643800102676 upstream.

There was an incorrect space in the definition of the function of one
pin in the Armada 375 pinctrl driver, which this commit fixes.

Signed-off-by: Thomas Petazzoni 
Fixes: ce3ed59dcddd ("pinctrl: mvebu: add pin-muxing driver for the Marvell 
Armada 375")
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques 
---
 drivers/pinctrl/mvebu/pinctrl-armada-375.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-375.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
index a5089029ba6c..64cc1184ecc2 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-375.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
@@ -92,7 +92,7 @@ static struct mvebu_mpp_mode mv88f6720_mpp_modes[] = {
 MPP_FUNCTION(0x5, "nand", "io1")),
MPP_MODE(8,
 MPP_FUNCTION(0x0, "gpio", NULL),
-MPP_FUNCTION(0x1, "dev ", "bootcs"),
+MPP_FUNCTION(0x1, "dev", "bootcs"),
 MPP_FUNCTION(0x2, "spi0", "cs0"),
 MPP_FUNCTION(0x3, "spi1", "cs0"),
 MPP_FUNCTION(0x5, "nand", "ce")),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 083/185] nfs: increase size of EXCHANGE_ID name string buffer

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jeff Layton 

commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 upstream.

The current buffer is much too small if you have a relatively long
hostname. Bring it up to the size of the one that SETCLIENTID has.

Reported-by: Michael Skralivetsky 
Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Luis Henriques 
---
 include/linux/nfs_xdr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
index 6f2ca8976069..162a86b2c072 100644
--- a/include/linux/nfs_xdr.h
+++ b/include/linux/nfs_xdr.h
@@ -1139,7 +1139,7 @@ struct nfs41_state_protection {
struct nfs4_op_map allow;
 };
 
-#define NFS4_EXCHANGE_ID_LEN   (48)
+#define NFS4_EXCHANGE_ID_LEN   (127)
 struct nfs41_exchange_id_args {
struct nfs_client   *client;
nfs4_verifier   *verifier;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 065/185] pinctrl: mvebu: armada-xp: remove non-existing VDD cpu_pd functions

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Thomas Petazzoni 

commit 80b3d04feab5e69d51cb2375eb989a7165e43e3b upstream.

The latest version of the Armada XP datasheet no longer documents the
VDD cpu_pd functions, which might indicate they are not working and/or
not supported. This commit ensures the pinctrl driver matches the
datasheet.

Signed-off-by: Thomas Petazzoni 
Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP")
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques 
---
 .../bindings/pinctrl/marvell,armada-xp-pinctrl.txt | 26 +++--
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c  | 33 +++---
 2 files changed, 20 insertions(+), 39 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
index 974168d854ba..b347b85aa22e 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
@@ -44,13 +44,13 @@ mpp22 22   gpio, ge0(rxd6), ge1(rxctl), 
lcd(d22), sata0(prsnt)
 mpp23 23   gpio, ge0(rxd7), ge1(rxclk), lcd(d23), sata1(prsnt)
 mpp24 24   gpio, lcd(hsync), sata1(prsnt), tdm(rst)
 mpp25 25   gpio, lcd(vsync), sata0(prsnt), tdm(pclk)
-mpp26 26   gpio, lcd(clk), tdm(fsync), vdd(cpu1-pd)
+mpp26 26   gpio, lcd(clk), tdm(fsync)
 mpp27 27   gpio, lcd(e), tdm(dtx), ptp(trig)
 mpp28 28   gpio, lcd(pwm), tdm(drx), ptp(evreq)
-mpp29 29   gpio, lcd(ref-clk), tdm(int0), ptp(clk), vdd(cpu0-pd)
+mpp29 29   gpio, lcd(ref-clk), tdm(int0), ptp(clk)
 mpp30 30   gpio, tdm(int1), sd0(clk)
-mpp31 31   gpio, tdm(int2), sd0(cmd), vdd(cpu0-pd)
-mpp32 32   gpio, tdm(int3), sd0(d0), vdd(cpu1-pd)
+mpp31 31   gpio, tdm(int2), sd0(cmd)
+mpp32 32   gpio, tdm(int3), sd0(d0)
 mpp33 33   gpio, tdm(int4), sd0(d1), mem(bat)
 mpp34 34   gpio, tdm(int5), sd0(d2), sata0(prsnt)
 mpp35 35   gpio, tdm(int6), sd0(d3), sata1(prsnt)
@@ -58,14 +58,11 @@ mpp36 36   gpio, spi(mosi)
 mpp37 37   gpio, spi(miso)
 mpp38 38   gpio, spi(sck)
 mpp39 39   gpio, spi(cs0)
-mpp40 40   gpio, spi(cs1), uart2(cts), lcd(vga-hsync), 
vdd(cpu1-pd),
-   pcie(clkreq0)
+mpp40 40   gpio, spi(cs1), uart2(cts), lcd(vga-hsync), 
pcie(clkreq0)
 mpp41 41   gpio, spi(cs2), uart2(rts), lcd(vga-vsync), 
sata1(prsnt),
pcie(clkreq1)
-mpp42 42   gpio, uart2(rxd), uart0(cts), tdm(int7), tdm-1(timer),
-   vdd(cpu0-pd)
-mpp43 43   gpio, uart2(txd), uart0(rts), spi(cs3), pcie(rstout),
-   vdd(cpu2-3-pd){1}
+mpp42 42   gpio, uart2(rxd), uart0(cts), tdm(int7), tdm-1(timer)
+mpp43 43   gpio, uart2(txd), uart0(rts), spi(cs3), pcie(rstout)
 mpp44 44   gpio, uart2(cts), uart3(rxd), spi(cs4), pcie(clkreq2),
mem(bat)
 mpp45 45   gpio, uart2(rts), uart3(txd), spi(cs5), sata1(prsnt)
@@ -84,9 +81,9 @@ mpp51 51   gpio, dev(ad16)
 mpp52 52   gpio, dev(ad17)
 mpp53 53   gpio, dev(ad18)
 mpp54 54   gpio, dev(ad19)
-mpp55 55   gpio, dev(ad20), vdd(cpu0-pd)
-mpp56 56   gpio, dev(ad21), vdd(cpu1-pd)
-mpp57 57   gpio, dev(ad22), vdd(cpu2-3-pd){1}
+mpp55 55   gpio, dev(ad20)
+mpp56 56   gpio, dev(ad21)
+mpp57 57   gpio, dev(ad22)
 mpp58 58   gpio, dev(ad23)
 mpp59 59   gpio, dev(ad24)
 mpp60 60   gpio, dev(ad25)
@@ -96,6 +93,3 @@ mpp63 63   gpio, dev(ad28)
 mpp64 64   gpio, dev(ad29)
 mpp65 65   gpio, dev(ad30)
 mpp66 66   gpio, dev(ad31)
-
-Notes:
-* {1} vdd(cpu2-3-pd) only available on mv78460.
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 26e19faf3dfd..529ad9f4e1a6 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -14,10 +14,7 @@
  * available: mv78230, mv78260 and mv78460. From a pin muxing
  * perspective, the mv78230 has 49 MPP pins. The mv78260 and mv78460
  * both have 67 MPP pins (more GPIOs and address lines for the memory
- * bus mainly). The only difference between the mv78260 and the
- * mv78460 in terms of pin muxing is the addition of two functions on
- * pins 43 and 56 to access the VDD of the CPU2 and 3 (mv78260 has two
- * cores, mv78460 has four cores).
+ * bus mainly).
  */
 
 #include 
@@ -181,8 +178,7 @@ static struct mvebu_mpp_mode armada_xp_mpp_modes[] 

[PATCH 3.16.y-ckt 078/185] jbd2: fix ocfs2 corrupt when updating journal superblock fails

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Joseph Qi 

commit 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a upstream.

If updating journal superblock fails after journal data has been
flushed, the error is omitted and this will mislead the caller as a
normal case.  In ocfs2, the checkpoint will be treated successfully
and the other node can get the lock to update. Since the sb_start is
still pointing to the old log block, it will rewrite the journal data
during journal recovery by the other node. Thus the new updates will
be overwritten and ocfs2 corrupts.  So in above case we have to return
the error, and ocfs2_commit_cache will take care of the error and
prevent the other node to do update first.  And only after recovering
journal it can do the new updates.

The issue discussion mail can be found at:
https://oss.oracle.com/pipermail/ocfs2-devel/2015-June/010856.html
http://comments.gmane.org/gmane.comp.file-systems.ext4/48841

[ Fixed bug in patch which allowed a non-negative error return from
  jbd2_cleanup_journal_tail() to leak out of jbd2_fjournal_flush(); this
  was causing xfstests ext4/306 to fail. -- Ted ]

Reported-by: Yiwen Jiang 
Signed-off-by: Joseph Qi 
Signed-off-by: Theodore Ts'o 
Tested-by: Yiwen Jiang 
Cc: Junxiao Bi 
Signed-off-by: Luis Henriques 
---
 fs/jbd2/checkpoint.c |  5 ++---
 fs/jbd2/journal.c| 38 +++---
 include/linux/jbd2.h |  4 ++--
 3 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
index 8d09e756b675..b892355f1944 100644
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -448,7 +448,7 @@ int jbd2_cleanup_journal_tail(journal_t *journal)
unsigned long   blocknr;
 
if (is_journal_aborted(journal))
-   return 1;
+   return -EIO;
 
if (!jbd2_journal_get_log_tail(journal, _tid, ))
return 1;
@@ -465,8 +465,7 @@ int jbd2_cleanup_journal_tail(journal_t *journal)
if (journal->j_flags & JBD2_BARRIER)
blkdev_issue_flush(journal->j_fs_dev, GFP_NOFS, NULL);
 
-   __jbd2_update_log_tail(journal, first_tid, blocknr);
-   return 0;
+   return __jbd2_update_log_tail(journal, first_tid, blocknr);
 }
 
 
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 19d74d86d99c..72e238b50ad1 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -885,9 +885,10 @@ int jbd2_journal_get_log_tail(journal_t *journal, tid_t 
*tid,
  *
  * Requires j_checkpoint_mutex
  */
-void __jbd2_update_log_tail(journal_t *journal, tid_t tid, unsigned long block)
+int __jbd2_update_log_tail(journal_t *journal, tid_t tid, unsigned long block)
 {
unsigned long freed;
+   int ret;
 
BUG_ON(!mutex_is_locked(>j_checkpoint_mutex));
 
@@ -897,7 +898,10 @@ void __jbd2_update_log_tail(journal_t *journal, tid_t tid, 
unsigned long block)
 * space and if we lose sb update during power failure we'd replay
 * old transaction with possibly newly overwritten data.
 */
-   jbd2_journal_update_sb_log_tail(journal, tid, block, WRITE_FUA);
+   ret = jbd2_journal_update_sb_log_tail(journal, tid, block, WRITE_FUA);
+   if (ret)
+   goto out;
+
write_lock(>j_state_lock);
freed = block - journal->j_tail;
if (block < journal->j_tail)
@@ -913,6 +917,9 @@ void __jbd2_update_log_tail(journal_t *journal, tid_t tid, 
unsigned long block)
journal->j_tail_sequence = tid;
journal->j_tail = block;
write_unlock(>j_state_lock);
+
+out:
+   return ret;
 }
 
 /*
@@ -1331,7 +1338,7 @@ static int journal_reset(journal_t *journal)
return jbd2_journal_start_thread(journal);
 }
 
-static void jbd2_write_superblock(journal_t *journal, int write_op)
+static int jbd2_write_superblock(journal_t *journal, int write_op)
 {
struct buffer_head *bh = journal->j_sb_buffer;
journal_superblock_t *sb = journal->j_superblock;
@@ -1370,7 +1377,10 @@ static void jbd2_write_superblock(journal_t *journal, 
int write_op)
printk(KERN_ERR "JBD2: Error %d detected when updating "
   "journal superblock for %s.\n", ret,
   journal->j_devname);
+   jbd2_journal_abort(journal, ret);
}
+
+   return ret;
 }
 
 /**
@@ -1383,10 +1393,11 @@ static void jbd2_write_superblock(journal_t *journal, 
int write_op)
  * Update a journal's superblock information about log tail and write it to
  * disk, waiting for the IO to complete.
  */
-void jbd2_journal_update_sb_log_tail(journal_t *journal, tid_t tail_tid,
+int jbd2_journal_update_sb_log_tail(journal_t *journal, tid_t tail_tid,
 unsigned long tail_block, int write_op)
 {
journal_superblock_t *sb = journal->j_superblock;
+   int ret;
 
BUG_ON(!mutex_is_locked(>j_checkpoint_mutex));

[PATCH 3.16.y-ckt 075/185] fs/ufs: revert "ufs: fix deadlocks introduced by sb mutex merge"

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Fabian Frederick 

commit 13b987ea275840d74d9df9a44326632fab1894da upstream.

This reverts commit 9ef7db7f38d0 ("ufs: fix deadlocks introduced by sb
mutex merge") That patch tried to solve commit 0244756edc4b98c ("ufs: sb
mutex merge + mutex_destroy") which is itself partially reverted due to
multiple deadlocks.

Signed-off-by: Fabian Frederick 
Suggested-by: Jan Kara 
Cc: Ian Campbell 
Cc: Evgeniy Dushistov 
Cc: Alexey Khoroshilov 
Cc: Roger Pau Monne 
Cc: Ian Jackson 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Luis Henriques 
---
 fs/ufs/inode.c |  5 -
 fs/ufs/namei.c | 14 --
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/fs/ufs/inode.c b/fs/ufs/inode.c
index 42234a871b22..40d6423429cb 100644
--- a/fs/ufs/inode.c
+++ b/fs/ufs/inode.c
@@ -902,6 +902,9 @@ void ufs_evict_inode(struct inode * inode)
invalidate_inode_buffers(inode);
clear_inode(inode);
 
-   if (want_delete)
+   if (want_delete) {
+   lock_ufs(inode->i_sb);
ufs_free_inode(inode);
+   unlock_ufs(inode->i_sb);
+   }
 }
diff --git a/fs/ufs/namei.c b/fs/ufs/namei.c
index 2df62a73f20c..90d74b8f8eba 100644
--- a/fs/ufs/namei.c
+++ b/fs/ufs/namei.c
@@ -126,12 +126,12 @@ static int ufs_symlink (struct inode * dir, struct dentry 
* dentry,
if (l > sb->s_blocksize)
goto out_notlocked;
 
+   lock_ufs(dir->i_sb);
inode = ufs_new_inode(dir, S_IFLNK | S_IRWXUGO);
err = PTR_ERR(inode);
if (IS_ERR(inode))
-   goto out_notlocked;
+   goto out;
 
-   lock_ufs(dir->i_sb);
if (l > UFS_SB(sb)->s_uspi->s_maxsymlinklen) {
/* slow symlink */
inode->i_op = _symlink_inode_operations;
@@ -181,9 +181,13 @@ static int ufs_mkdir(struct inode * dir, struct dentry * 
dentry, umode_t mode)
struct inode * inode;
int err;
 
+   lock_ufs(dir->i_sb);
+   inode_inc_link_count(dir);
+
inode = ufs_new_inode(dir, S_IFDIR|mode);
+   err = PTR_ERR(inode);
if (IS_ERR(inode))
-   return PTR_ERR(inode);
+   goto out_dir;
 
inode->i_op = _dir_inode_operations;
inode->i_fop = _dir_operations;
@@ -191,9 +195,6 @@ static int ufs_mkdir(struct inode * dir, struct dentry * 
dentry, umode_t mode)
 
inode_inc_link_count(inode);
 
-   lock_ufs(dir->i_sb);
-   inode_inc_link_count(dir);
-
err = ufs_make_empty(inode, dir);
if (err)
goto out_fail;
@@ -211,6 +212,7 @@ out_fail:
inode_dec_link_count(inode);
inode_dec_link_count(inode);
iput (inode);
+out_dir:
inode_dec_link_count(dir);
unlock_ufs(dir->i_sb);
goto out;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 064/185] pinctrl: mvebu: armada-xp: remove non-existing NAND pins

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Thomas Petazzoni 

commit bc99357f3690c11817756adfee0ece811a3db2e7 upstream.

After updating to a more recent version of the Armada XP datasheet, we
realized that some of the pins documented as having a NAND-related
functionality in fact did not have such functionality. This commit
updates the pinctrl driver accordingly.

Signed-off-by: Thomas Petazzoni 
Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP")
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques 
---
 .../devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt | 4 ++--
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
index 373dbccd7ab0..974168d854ba 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
@@ -42,8 +42,8 @@ mpp20 20   gpio, ge0(rxd4), ge1(rxd2), lcd(d20), 
ptp(clk)
 mpp21 21   gpio, ge0(rxd5), ge1(rxd3), lcd(d21), mem(bat)
 mpp22 22   gpio, ge0(rxd6), ge1(rxctl), lcd(d22), sata0(prsnt)
 mpp23 23   gpio, ge0(rxd7), ge1(rxclk), lcd(d23), sata1(prsnt)
-mpp24 24   gpio, lcd(hsync), sata1(prsnt), nf(bootcs-re), tdm(rst)
-mpp25 25   gpio, lcd(vsync), sata0(prsnt), nf(bootcs-we), tdm(pclk)
+mpp24 24   gpio, lcd(hsync), sata1(prsnt), tdm(rst)
+mpp25 25   gpio, lcd(vsync), sata0(prsnt), tdm(pclk)
 mpp26 26   gpio, lcd(clk), tdm(fsync), vdd(cpu1-pd)
 mpp27 27   gpio, lcd(e), tdm(dtx), ptp(trig)
 mpp28 28   gpio, lcd(pwm), tdm(drx), ptp(evreq)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index de311129f7a0..26e19faf3dfd 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -171,13 +171,11 @@ static struct mvebu_mpp_mode armada_xp_mpp_modes[] = {
MPP_MODE(24,
 MPP_VAR_FUNCTION(0x0, "gpio", NULL,V_MV78230_PLUS),
 MPP_VAR_FUNCTION(0x1, "sata1", "prsnt",V_MV78230_PLUS),
-MPP_VAR_FUNCTION(0x2, "nf", "bootcs-re",   V_MV78230_PLUS),
 MPP_VAR_FUNCTION(0x3, "tdm", "rst",V_MV78230_PLUS),
 MPP_VAR_FUNCTION(0x4, "lcd", "hsync",  V_MV78230_PLUS)),
MPP_MODE(25,
 MPP_VAR_FUNCTION(0x0, "gpio", NULL,V_MV78230_PLUS),
 MPP_VAR_FUNCTION(0x1, "sata0", "prsnt",V_MV78230_PLUS),
-MPP_VAR_FUNCTION(0x2, "nf", "bootcs-we",   V_MV78230_PLUS),
 MPP_VAR_FUNCTION(0x3, "tdm", "pclk",   V_MV78230_PLUS),
 MPP_VAR_FUNCTION(0x4, "lcd", "vsync",  V_MV78230_PLUS)),
MPP_MODE(26,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 081/185] regmap: Fix possible shift overflow in regmap_field_init()

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Maxime Coquelin 

commit 921cc29473a0d7c109105c1876ddb432f4a4be7d upstream.

The way the mask is generated in regmap_field_init() is wrong.
Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift
overflow while calculating the mask field.

On some 32 bits architectures, such as x86, the generated mask is 0,
instead of the expected 0x.

This patch uses GENMASK() to fix the problem, as this macro is already safe
regarding shift overflow.

Signed-off-by: Maxime Coquelin 
Signed-off-by: Mark Brown 
Signed-off-by: Luis Henriques 
---
 drivers/base/regmap/regmap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 09fe07b6e98b..27487c289ee0 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -887,11 +887,10 @@ EXPORT_SYMBOL_GPL(devm_regmap_init);
 static void regmap_field_init(struct regmap_field *rm_field,
struct regmap *regmap, struct reg_field reg_field)
 {
-   int field_bits = reg_field.msb - reg_field.lsb + 1;
rm_field->regmap = regmap;
rm_field->reg = reg_field.reg;
rm_field->shift = reg_field.lsb;
-   rm_field->mask = ((BIT(field_bits) - 1) << reg_field.lsb);
+   rm_field->mask = GENMASK(reg_field.msb, reg_field.lsb);
rm_field->id_size = reg_field.id_size;
rm_field->id_offset = reg_field.id_offset;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 084/185] vTPM: set virtual device before passing to ibmvtpm_reset_crq

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Hon Ching (Vicky) Lo" 

commit 9d75f08946e8485109458ccf16f714697c207f41 upstream.

tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address.

Signed-off-by: Hon Ching(Vicky) Lo 
Signed-off-by: Joy Latten 
Reviewed-by: Ashley Lai 
Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM 
vTPM")
Signed-off-by: Peter Huewe 
Signed-off-by: Luis Henriques 
---
 drivers/char/tpm/tpm_ibmvtpm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 102463ba745d..643bba7d6f81 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -579,6 +579,9 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
goto cleanup;
}
 
+   ibmvtpm->dev = dev;
+   ibmvtpm->vdev = vio_dev;
+
crq_q = >crq_queue;
crq_q->crq_addr = (struct ibmvtpm_crq *)get_zeroed_page(GFP_KERNEL);
if (!crq_q->crq_addr) {
@@ -623,8 +626,6 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
 
crq_q->index = 0;
 
-   ibmvtpm->dev = dev;
-   ibmvtpm->vdev = vio_dev;
TPM_VPRIV(chip) = (void *)ibmvtpm;
 
spin_lock_init(>rtce_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] KVM: PPC: Book3S HV: Use need_resched() instead of should_resched()

[Konstantin Khlebnikov]

Function should_resched() is equal to (!preempt_count() && need_resched()).
In preemptive kernel preempt_count here is non-zero because of vc->lock.

Signed-off-by: Konstantin Khlebnikov 
---
 arch/powerpc/kvm/book3s_hv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 68d067ad4222..a9f753fb73a8 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -2178,7 +2178,7 @@ static int kvmppc_run_vcpu(struct kvm_run *kvm_run, 
struct kvm_vcpu *vcpu)
vc->runner = vcpu;
if (n_ceded == vc->n_runnable) {
kvmppc_vcore_blocked(vc);
-   } else if (should_resched()) {
+   } else if (need_resched()) {
vc->vcore_state = VCORE_PREEMPT;
/* Let something else run */
cond_resched_lock(>lock);

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

[PATCH v2 3/3] sched/preempt: fix cond_resched_lock() and cond_resched_softirq()

[Konstantin Khlebnikov]

These functions check should_resched() before unlocking spinlock/bh-enable:
preempt_count always non-zero => should_resched() always returns false.
cond_resched_lock() worked iff spin_needbreak is set.

This patch adds argument "preempt_offset" to should_resched().

preempt_count offset constants for that:

PREEMPT_DISABLE_OFFSET  - offset after preempt_disable()
PREEMPT_LOCK_OFFSET - offset after spin_lock()
SOFTIRQ_DISABLE_OFFSET  - offset after local_bh_distable()
SOFTIRQ_LOCK_OFFSET - offset after spin_lock_bh()

Signed-off-by: Konstantin Khlebnikov 
---
 arch/x86/include/asm/preempt.h |4 ++--
 include/asm-generic/preempt.h  |5 +++--
 include/linux/preempt.h|   19 ++-
 include/linux/sched.h  |6 --
 kernel/sched/core.c|6 +++---
 5 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/arch/x86/include/asm/preempt.h b/arch/x86/include/asm/preempt.h
index dca71714f860..b12f81022a6b 100644
--- a/arch/x86/include/asm/preempt.h
+++ b/arch/x86/include/asm/preempt.h
@@ -90,9 +90,9 @@ static __always_inline bool __preempt_count_dec_and_test(void)
 /*
  * Returns true when we need to resched and can (barring IRQ state).
  */
-static __always_inline bool should_resched(void)
+static __always_inline bool should_resched(int preempt_offset)
 {
-   return unlikely(!raw_cpu_read_4(__preempt_count));
+   return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
 }
 
 #ifdef CONFIG_PREEMPT
diff --git a/include/asm-generic/preempt.h b/include/asm-generic/preempt.h
index d0a7a4753db2..0bec580a4885 100644
--- a/include/asm-generic/preempt.h
+++ b/include/asm-generic/preempt.h
@@ -71,9 +71,10 @@ static __always_inline bool 
__preempt_count_dec_and_test(void)
 /*
  * Returns true when we need to resched and can (barring IRQ state).
  */
-static __always_inline bool should_resched(void)
+static __always_inline bool should_resched(int preempt_offset)
 {
-   return unlikely(!preempt_count() && tif_need_resched());
+   return unlikely(preempt_count() == preempt_offset &&
+   tif_need_resched());
 }
 
 #ifdef CONFIG_PREEMPT
diff --git a/include/linux/preempt.h b/include/linux/preempt.h
index 84991f185173..bea8dd8ff5e0 100644
--- a/include/linux/preempt.h
+++ b/include/linux/preempt.h
@@ -84,13 +84,21 @@
  */
 #define in_nmi()   (preempt_count() & NMI_MASK)
 
+/*
+ * The preempt_count offset after preempt_disable();
+ */
 #if defined(CONFIG_PREEMPT_COUNT)
-# define PREEMPT_DISABLE_OFFSET 1
+# define PREEMPT_DISABLE_OFFSETPREEMPT_OFFSET
 #else
-# define PREEMPT_DISABLE_OFFSET 0
+# define PREEMPT_DISABLE_OFFSET0
 #endif
 
 /*
+ * The preempt_count offset after spin_lock()
+ */
+#define PREEMPT_LOCK_OFFSETPREEMPT_DISABLE_OFFSET
+
+/*
  * The preempt_count offset needed for things like:
  *
  *  spin_lock_bh()
@@ -103,7 +111,7 @@
  *
  * Work as expected.
  */
-#define SOFTIRQ_LOCK_OFFSET (SOFTIRQ_DISABLE_OFFSET + PREEMPT_DISABLE_OFFSET)
+#define SOFTIRQ_LOCK_OFFSET (SOFTIRQ_DISABLE_OFFSET + PREEMPT_LOCK_OFFSET)
 
 /*
  * Are we running in atomic context?  WARNING: this macro cannot
@@ -124,7 +132,8 @@
 #if defined(CONFIG_DEBUG_PREEMPT) || defined(CONFIG_PREEMPT_TRACER)
 extern void preempt_count_add(int val);
 extern void preempt_count_sub(int val);
-#define preempt_count_dec_and_test() ({ preempt_count_sub(1); 
should_resched(); })
+#define preempt_count_dec_and_test() \
+   ({ preempt_count_sub(1); should_resched(0); })
 #else
 #define preempt_count_add(val) __preempt_count_add(val)
 #define preempt_count_sub(val) __preempt_count_sub(val)
@@ -184,7 +193,7 @@ do { \
 
 #define preempt_check_resched() \
 do { \
-   if (should_resched()) \
+   if (should_resched(0)) \
__preempt_schedule(); \
 } while (0)
 
diff --git a/include/linux/sched.h b/include/linux/sched.h
index ae21f1591615..a8e9b17acdee 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2885,12 +2885,6 @@ extern int _cond_resched(void);
 
 extern int __cond_resched_lock(spinlock_t *lock);
 
-#ifdef CONFIG_PREEMPT_COUNT
-#define PREEMPT_LOCK_OFFSETPREEMPT_OFFSET
-#else
-#define PREEMPT_LOCK_OFFSET0
-#endif
-
 #define cond_resched_lock(lock) ({ \
___might_sleep(__FILE__, __LINE__, PREEMPT_LOCK_OFFSET);\
__cond_resched_lock(lock);  \
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78b4bad10081..d9a4d93dc879 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4492,7 +4492,7 @@ SYSCALL_DEFINE0(sched_yield)
 
 int __sched _cond_resched(void)
 {
-   if (should_resched()) {
+   if (should_resched(0)) {
preempt_schedule_common();
return 1;
}
@@ -4510,7 +4510,7 @@ EXPORT_SYMBOL(_cond_resched);
  */
 int __cond_resched_lock(spinlock_t *lock)
 {
-   int resched = should_resched();
+   int resched = should_resched(PREEMPT_LOCK_OFFSET);

[PATCH 3.16.y-ckt 085/185] arm: KVM: force execution of HCPTR access on VM exit

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Marc Zyngier 

commit 85e84ba31039595995dae80b277378213602891b upstream.

On VM entry, we disable access to the VFP registers in order to
perform a lazy save/restore of these registers.

On VM exit, we restore access, test if we did enable them before,
and save/restore the guest/host registers if necessary. In this
sequence, the FPEXC register is always accessed, irrespective
of the trapping configuration.

If the guest didn't touch the VFP registers, then the HCPTR access
has now enabled such access, but we're missing a barrier to ensure
architectural execution of the new HCPTR configuration. If the HCPTR
access has been delayed/reordered, the subsequent access to FPEXC
will cause a trap, which we aren't prepared to handle at all.

The same condition exists when trapping to enable VFP for the guest.

The fix is to introduce a barrier after enabling VFP access. In the
vmexit case, it can be relaxed to only takes place if the guest hasn't
accessed its view of the VFP registers, making the access to FPEXC safe.

The set_hcptr macro is modified to deal with both vmenter/vmexit and
vmtrap operations, and now takes an optional label that is branched to
when the guest hasn't touched the VFP registers.

Reported-by: Vikram Sethi 
Signed-off-by: Marc Zyngier 
Signed-off-by: Luis Henriques 
---
 arch/arm/kvm/interrupts.S  | 10 --
 arch/arm/kvm/interrupts_head.S | 20 ++--
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 0d68d4073068..a1467e7689f5 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -159,13 +159,9 @@ __kvm_vcpu_return:
@ Don't trap coprocessor accesses for host kernel
set_hstr vmexit
set_hdcr vmexit
-   set_hcptr vmexit, (HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11))
+   set_hcptr vmexit, (HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11)), 
after_vfp_restore
 
 #ifdef CONFIG_VFPv3
-   @ Save floating point registers we if let guest use them.
-   tst r2, #(HCPTR_TCP(10) | HCPTR_TCP(11))
-   bne after_vfp_restore
-
@ Switch VFP/NEON hardware state to the host's
add r7, vcpu, #VCPU_VFP_GUEST
store_vfp_state r7
@@ -177,6 +173,8 @@ after_vfp_restore:
@ Restore FPEXC_EN which we clobbered on entry
pop {r2}
VFPFMXR FPEXC, r2
+#else
+after_vfp_restore:
 #endif
 
@ Reset Hyp-role
@@ -467,7 +465,7 @@ switch_to_guest_vfp:
push{r3-r7}
 
@ NEON/VFP used.  Turn on VFP access.
-   set_hcptr vmexit, (HCPTR_TCP(10) | HCPTR_TCP(11))
+   set_hcptr vmtrap, (HCPTR_TCP(10) | HCPTR_TCP(11))
 
@ Switch VFP/NEON hardware state to the guest's
add r7, r0, #VCPU_VFP_HOST
diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
index 76af93025574..2973b2d342fa 100644
--- a/arch/arm/kvm/interrupts_head.S
+++ b/arch/arm/kvm/interrupts_head.S
@@ -578,8 +578,13 @@ vcpu   .reqr0  @ vcpu pointer always 
in r0
 .endm
 
 /* Configures the HCPTR (Hyp Coprocessor Trap Register) on entry/return
- * (hardware reset value is 0). Keep previous value in r2. */
-.macro set_hcptr operation, mask
+ * (hardware reset value is 0). Keep previous value in r2.
+ * An ISB is emited on vmexit/vmtrap, but executed on vmexit only if
+ * VFP wasn't already enabled (always executed on vmtrap).
+ * If a label is specified with vmexit, it is branched to if VFP wasn't
+ * enabled.
+ */
+.macro set_hcptr operation, mask, label = none
mrc p15, 4, r2, c1, c1, 2
ldr r3, =\mask
.if \operation == vmentry
@@ -588,6 +593,17 @@ vcpu   .reqr0  @ vcpu pointer always 
in r0
bic r3, r2, r3  @ Don't trap defined coproc-accesses
.endif
mcr p15, 4, r3, c1, c1, 2
+   .if \operation != vmentry
+   .if \operation == vmexit
+   tst r2, #(HCPTR_TCP(10) | HCPTR_TCP(11))
+   beq 1f
+   .endif
+   isb
+   .if \label != none
+   b   \label
+   .endif
+1:
+   .endif
 .endm
 
 /* Configures the HDCR (Hyp Debug Configuration Register) on entry/return
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 1/1] usb:serial:f81534 add F81532/534 driver

[Johan Hovold]

On Wed, Jul 15, 2015 at 04:55:19PM +0800, Peter Hung wrote:
> Hi Paul & Johan
> 
> Paul Bolle 於 2015/7/15 下午 04:36 寫道:
> > Just a few nits, I'm afraid.
> >> +int f81534_gpio_request(struct gpio_chip *chip, unsigned offset)
> >> +{
> >> +  [...]
> >> +}
> >
> > static?
> 
> Thanks Paul for point this out.
> 
> And sorry for Johan. It's seems to make a new patch V5. I'll merge
> some minor fix with newer patch.

No problem, I'll wait for v5.

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

[PATCH 3.16.y-ckt 079/185] ideapad: fix software rfkill setting

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Arnd Bergmann 

commit 4b200b4604bec3388426159f1656109d19fadf6e upstream.

This fixes a several year old regression that I found while trying
to get the Yoga 3 11 to work. The ideapad_rfk_set function is meant
to send a command to the embedded controller through ACPI, but
as of c1f73658ed, it sends the index of the rfkill device instead
of the command, and ignores the opcode field.

This changes it back to the original behavior, which indeed
flips the rfkill state as seen in the debugfs interface.

Signed-off-by: Arnd Bergmann 
Fixes: c1f73658ed ("ideapad: pass ideapad_priv as argument (part 2)")
Signed-off-by: Darren Hart 
Signed-off-by: Luis Henriques 
---
 drivers/platform/x86/ideapad-laptop.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c
index 11712d1dbd17..627d43f3f078 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -464,8 +464,9 @@ const struct ideapad_rfk_data ideapad_rfk_data[] = {
 static int ideapad_rfk_set(void *data, bool blocked)
 {
struct ideapad_rfk_priv *priv = data;
+   int opcode = ideapad_rfk_data[priv->dev].opcode;
 
-   return write_ec_cmd(priv->priv->adev->handle, priv->dev, !blocked);
+   return write_ec_cmd(priv->priv->adev->handle, opcode, !blocked);
 }
 
 static struct rfkill_ops ideapad_rfk_ops = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Add MT8173 MMPLL change rate support

[James Liao]

Hi Stephen,

On Tue, 2015-07-14 at 15:13 -0700, Stephen Boyd wrote:
> On 07/10, James Liao wrote:
> > On Wed, 2015-07-08 at 17:44 -0700, Stephen Boyd wrote:
> > > On 07/08/2015 01:37 AM, James Liao wrote:
> > > > MT8173 MMPLL frequency settings are different from common PLLs.
> > > > It needs different post divider settings for some ranges of frequency.
> > > > This patch add support for MT8173 MMPLL frequency setting, includes:
> > > >
> > > > 1. Add div-rate table for PLLs.
> > > > 2. Increase the max ost divider setting from 3 (/8) to 4 (/16).
> > > > 3. Write postdiv and pcw settings at the same time.
> > > >
> > > > James Liao (2):
> > > >   clk: mediatek: Fix PLL registers setting flow
> > > >   clk: mediatek: Add MT8173 MMPLL change rate support
> > > >
> > > 
> > > Are these fixing regressions in 4.2-rc1? I don't see any "Fixes:" tag so
> > > it's not clear and makes me want to defer these until v4.3. Furthermore,
> > > the subject starts with "Add" so it sounds like a new feature.
> > 
> > This patchset is based on 4.1-rc1 but it had been tested on 4.2-rc1.
> > I'll send a new patch which based on 4.2-rc1.
> > 
> > This patchset contains some general PLL fixes and MMPLL set rate
> > support. We can say the last one is also a fix because changing some
> > specific rate on MMPLL may fail in current implementation.
> > 
> > 
> 
> I'm seriously confused. The files these patches touch were never
> in v4.1, so they can't be based on v4.1-rc1 unless you're saying
> they were on top of clk-next when it was based on 4.1-rc1?
> 

This is an old patch which based on 4.1-rc1 and basic clocks support
[1].

Please refer to the newer patch [2] and ignore this one.


[1] https://lkml.org/lkml/2015/4/23/92
[2] https://lkml.org/lkml/2015/7/10/198


Best regards,

James


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

[PATCH v2 1/3] drivers/xen/preempt: use need_resched() instead of should_resched()

[Konstantin Khlebnikov]

This code is used only when CONFIG_PREEMPT=n and only in non-atomic context:
xen_in_preemptible_hcall is set only in privcmd_ioctl_hypercall().
Thus preempt_count is zero and should_resched() is equal to need_resched().

Signed-off-by: Konstantin Khlebnikov 
---
 drivers/xen/preempt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c
index a1800c150839..08cb419eb4e6 100644
--- a/drivers/xen/preempt.c
+++ b/drivers/xen/preempt.c
@@ -31,7 +31,7 @@ EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall);
 asmlinkage __visible void xen_maybe_preempt_hcall(void)
 {
if (unlikely(__this_cpu_read(xen_in_preemptible_hcall)
-&& should_resched())) {
+&& need_resched())) {
/*
 * Clear flag as we may be rescheduled on a different
 * cpu.

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

[PATCH 3.16.y-ckt 086/185] arm64: mm: Fix freeing of the wrong memmap entries with !SPARSEMEM_VMEMMAP

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dave P Martin 

commit b9bcc919931611498e856eae9bf66337330d04cc upstream.

The memmap freeing code in free_unused_memmap() computes the end of
each memblock by adding the memblock size onto the base.  However,
if SPARSEMEM is enabled then the value (start) used for the base
may already have been rounded downwards to work out which memmap
entries to free after the previous memblock.

This may cause memmap entries that are in use to get freed.

In general, you're not likely to hit this problem unless there
are at least 2 memblocks and one of them is not aligned to a
sparsemem section boundary.  Note that carve-outs can increase
the number of memblocks by splitting the regions listed in the
device tree.

This problem doesn't occur with SPARSEMEM_VMEMMAP, because the
vmemmap code deals with freeing the unused regions of the memmap
instead of requiring the arch code to do it.

This patch gets the memblock base out of the memblock directly when
computing the block end address to ensure the correct value is used.

Signed-off-by: Dave Martin 
Signed-off-by: Catalin Marinas 
Signed-off-by: Luis Henriques 
---
 arch/arm64/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e90c5426fe14..01bfca35b0aa 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -239,7 +239,7 @@ static void __init free_unused_memmap(void)
 * memmap entries are valid from the bank end aligned to
 * MAX_ORDER_NR_PAGES.
 */
-   prev_end = ALIGN(start + __phys_to_pfn(reg->size),
+   prev_end = ALIGN(__phys_to_pfn(reg->base + reg->size),
 MAX_ORDER_NR_PAGES);
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 088/185] dm stats: fix divide by zero if 'number_of_areas' arg is zero

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Mikulas Patocka 

commit dd4c1b7d0c95be1c9245118a3accc41a16f1db67 upstream.

If the number_of_areas argument was zero the kernel would crash on
div-by-zero.  Add better input validation.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Signed-off-by: Luis Henriques 
---
 drivers/md/dm-stats.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/md/dm-stats.c b/drivers/md/dm-stats.c
index 28a90122a5a8..b3b0697a9fd7 100644
--- a/drivers/md/dm-stats.c
+++ b/drivers/md/dm-stats.c
@@ -795,6 +795,8 @@ static int message_stats_create(struct mapped_device *md,
return -EINVAL;
 
if (sscanf(argv[2], "/%u%c", , ) == 1) {
+   if (!divisor)
+   return -EINVAL;
step = end - start;
if (do_div(step, divisor))
step++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 087/185] dm space map metadata: fix occasional leak of a metadata block on resize

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Joe Thornber 

commit 6096d91af0b65a3967139b32d5adbb3647858a26 upstream.

The metadata space map has a simplified 'bootstrap' mode that is
operational when extending the space maps.  Whilst in this mode it's
possible for some refcount decrement operations to become queued (eg, as
a result of shadowing one of the bitmap indexes).  These decrements were
not being applied when switching out of bootstrap mode.

The effect of this bug was the leaking of a 4k metadata block.  This is
detected by the latest version of thin_check as a non fatal error.

Signed-off-by: Joe Thornber 
Signed-off-by: Mike Snitzer 
Signed-off-by: Luis Henriques 
---
 drivers/md/persistent-data/dm-space-map-metadata.c | 50 +++---
 1 file changed, 35 insertions(+), 15 deletions(-)

diff --git a/drivers/md/persistent-data/dm-space-map-metadata.c 
b/drivers/md/persistent-data/dm-space-map-metadata.c
index f4e22bcc7fb8..199c9ccd1f5d 100644
--- a/drivers/md/persistent-data/dm-space-map-metadata.c
+++ b/drivers/md/persistent-data/dm-space-map-metadata.c
@@ -204,6 +204,27 @@ static void in(struct sm_metadata *smm)
smm->recursion_count++;
 }
 
+static int apply_bops(struct sm_metadata *smm)
+{
+   int r = 0;
+
+   while (!brb_empty(>uncommitted)) {
+   struct block_op bop;
+
+   r = brb_pop(>uncommitted, );
+   if (r) {
+   DMERR("bug in bop ring buffer");
+   break;
+   }
+
+   r = commit_bop(smm, );
+   if (r)
+   break;
+   }
+
+   return r;
+}
+
 static int out(struct sm_metadata *smm)
 {
int r = 0;
@@ -216,21 +237,8 @@ static int out(struct sm_metadata *smm)
return -ENOMEM;
}
 
-   if (smm->recursion_count == 1) {
-   while (!brb_empty(>uncommitted)) {
-   struct block_op bop;
-
-   r = brb_pop(>uncommitted, );
-   if (r) {
-   DMERR("bug in bop ring buffer");
-   break;
-   }
-
-   r = commit_bop(smm, );
-   if (r)
-   break;
-   }
-   }
+   if (smm->recursion_count == 1)
+   apply_bops(smm);
 
smm->recursion_count--;
 
@@ -702,6 +710,12 @@ static int sm_metadata_extend(struct dm_space_map *sm, 
dm_block_t extra_blocks)
}
old_len = smm->begin;
 
+   r = apply_bops(smm);
+   if (r) {
+   DMERR("%s: apply_bops failed", __func__);
+   goto out;
+   }
+
r = sm_ll_commit(>ll);
if (r)
goto out;
@@ -771,6 +785,12 @@ int dm_sm_metadata_create(struct dm_space_map *sm,
if (r)
return r;
 
+   r = apply_bops(smm);
+   if (r) {
+   DMERR("%s: apply_bops failed", __func__);
+   return r;
+   }
+
return sm_metadata_commit(sm);
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 089/185] x86/PCI: Use host bridge _CRS info on systems with >32 bit addressing

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Bjorn Helgaas 

commit 3d9fecf6bfb8b12bc2f9a4c7109895a2a2bb9436 upstream.

We enable _CRS on all systems from 2008 and later.  On older systems, we
ignore _CRS and assume the whole physical address space (excluding RAM and
other devices) is available for PCI devices, but on systems that support
physical address spaces larger than 4GB, it's doubtful that the area above
4GB is really available for PCI.

After d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible"), we
try to use that space above 4GB *first*, so we're more likely to put a
device there.

On Juan's Toshiba Satellite Pro U200, BIOS left the graphics, sound, 1394,
and card reader devices unassigned (but only after Windows had been
booted).  Only the sound device had a 64-bit BAR, so it was the only device
placed above 4GB, and hence the only device that didn't work.

Keep _CRS enabled even on pre-2008 systems if they support physical address
space larger than 4GB.

Fixes: d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible")
Reported-and-tested-by: Juan Dayer 
Reported-and-tested-by: Alan Horsfield 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99221
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=907092
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Luis Henriques 
---
 arch/x86/pci/acpi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 46e6538a1a6a..0f8002ca2a5c 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -135,8 +135,10 @@ void __init pci_acpi_crs_quirks(void)
 {
int year;
 
-   if (dmi_get_date(DMI_BIOS_DATE, , NULL, NULL) && year < 2008)
-   pci_use_crs = false;
+   if (dmi_get_date(DMI_BIOS_DATE, , NULL, NULL) && year < 2008) {
+   if (iomem_resource.end <= 0x)
+   pci_use_crs = false;
+   }
 
dmi_check_system(pci_crs_quirks);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 093/185] Bluetooth: ath3k: Add support of 04ca:300d AR3012 device

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Tunin 

commit 7e730c7f3d1f39c25cf5f7cf70c0ff4c28d7bec7 upstream.

BugLink: https://bugs.launchpad.net/bugs/1394368

This device requires new firmware files
 AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
/lib/firmware/ar3k/ that are not included in linux-firmware yet.

T: Bus=02 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=300d Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms

Signed-off-by: Dmitry Tunin 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Luis Henriques 
---
 drivers/bluetooth/ath3k.c | 2 ++
 drivers/bluetooth/btusb.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 84e83b737e50..5b19c4384ec5 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -89,6 +89,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x3007) },
{ USB_DEVICE(0x04CA, 0x3008) },
{ USB_DEVICE(0x04CA, 0x300b) },
+   { USB_DEVICE(0x04CA, 0x300d) },
{ USB_DEVICE(0x04CA, 0x300f) },
{ USB_DEVICE(0x04CA, 0x3010) },
{ USB_DEVICE(0x0930, 0x0219) },
@@ -147,6 +148,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x04ca, 0x300d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 57783a4e3ea9..41abfa124c34 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -179,6 +179,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x04ca, 0x300d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 092/185] Bluetooth: ath3k: add support of 04ca:300f AR3012 device

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Tunin 

commit ec0810d2ac1c932dad48f45da67e3adc5c5449a1 upstream.

BugLink: https://bugs.launchpad.net/bugs/1449730

T:  Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=04ca ProdID=300f Rev=00.01
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Dmitry Tunin 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Luis Henriques 
---
 drivers/bluetooth/ath3k.c | 2 ++
 drivers/bluetooth/btusb.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index ecac55f124e8..84e83b737e50 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -89,6 +89,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x3007) },
{ USB_DEVICE(0x04CA, 0x3008) },
{ USB_DEVICE(0x04CA, 0x300b) },
+   { USB_DEVICE(0x04CA, 0x300f) },
{ USB_DEVICE(0x04CA, 0x3010) },
{ USB_DEVICE(0x0930, 0x0219) },
{ USB_DEVICE(0x0930, 0x0220) },
@@ -146,6 +147,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 41c4a74d589f..57783a4e3ea9 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -179,6 +179,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 095/185] arm64: vdso: work-around broken ELF toolchains in Makefile

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Will Deacon 

commit 6f1a6ae87c0c60d7c462ef8fd071f291aa7a9abb upstream.

When building the kernel with a bare-metal (ELF) toolchain, the -shared
option may not be passed down to collect2, resulting in silent corruption
of the vDSO image (in particular, the DYNAMIC section is omitted).

The effect of this corruption is that the dynamic linker fails to find
the vDSO symbols and libc is instead used for the syscalls that we
intended to optimise (e.g. gettimeofday). Functionally, there is no
issue as the sigreturn trampoline is still intact and located by the
kernel.

This patch fixes the problem by explicitly passing -shared to the linker
when building the vDSO.

Reported-by: Szabolcs Nagy 
Reported-by: James Greenlaigh 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Luis Henriques 
---
 arch/arm64/kernel/vdso/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index a268a9af0c2d..a622dd0be9c4 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -15,6 +15,10 @@ ccflags-y := -shared -fno-common -fno-builtin
 ccflags-y += -nostdlib -Wl,-soname=linux-vdso.so.1 \
$(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
 
+# Workaround for bare-metal (ELF) toolchains that neglect to pass -shared
+# down to collect2, resulting in silent corruption of the vDSO image.
+ccflags-y += -Wl,-shared
+
 obj-y += vdso.o
 extra-y += vdso.lds vdso-offsets.h
 CPPFLAGS_vdso.lds += -P -C -U$(ARCH)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 090/185] pNFS: Fix a memory leak when attempted pnfs fails

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Trond Myklebust 

commit 1ca018d28d96d07788474abf66a5f3e9594841f5 upstream.

pnfs_do_write() expects the call to pnfs_write_through_mds() to free the
pgio header and to release the layout segment before exiting. The problem
is that nfs_pgio_data_destroy() doesn't actually do this; it only frees
the memory allocated by nfs_generic_pgio().

Ditto for pnfs_do_read()...

Fix in both cases is to add a call to hdr->release(hdr).

Signed-off-by: Trond Myklebust 
Signed-off-by: Luis Henriques 
---
 fs/nfs/pnfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
index dea11c2c8c1e..77498f9ba554 100644
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1558,6 +1558,7 @@ pnfs_write_through_mds(struct nfs_pageio_descriptor *desc,
desc->pg_recoalesce = 1;
}
nfs_pgio_data_destroy(hdr);
+   hdr->release(hdr);
 }
 
 static enum pnfs_try_status
@@ -1695,6 +1696,7 @@ pnfs_read_through_mds(struct nfs_pageio_descriptor *desc,
desc->pg_recoalesce = 1;
}
nfs_pgio_data_destroy(hdr);
+   hdr->release(hdr);
 }
 
 /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 102/185] NET: ROSE: Don't dereference NULL neighbour pointer.

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Ralf Baechle 

commit d496f7842aada20c61e6044b3395383fa972872c upstream.

A ROSE socket doesn't necessarily always have a neighbour pointer so check
if the neighbour pointer is valid before dereferencing it.

Signed-off-by: Ralf Baechle 
Tested-by: Bernard Pidoux 
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques 
---
 net/rose/af_rose.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 8451c8cdc9de..60823136dafb 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -192,7 +192,8 @@ static void rose_kill_by_device(struct net_device *dev)
 
if (rose->device == dev) {
rose_disconnect(s, ENETUNREACH, ROSE_OUT_OF_ORDER, 0);
-   rose->neighbour->use--;
+   if (rose->neighbour)
+   rose->neighbour->use--;
rose->device = NULL;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 096/185] iommu/amd: Handle large pages correctly in free_pagetable

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Joerg Roedel 

commit 0b3fff54bc01e8e6064d222a33e6fa7adabd94cd upstream.

Make sure that we are skipping over large PTEs while walking
the page-table tree.

Fixes: 5c34c403b723 ("iommu/amd: Fix memory leak in free_pagetable")
Signed-off-by: Joerg Roedel 
Signed-off-by: Luis Henriques 
---
 drivers/iommu/amd_iommu.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 710ffa1830ae..706cbc5bd5cc 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1922,9 +1922,15 @@ static void free_pt_##LVL (unsigned long __pt)   
\
pt = (u64 *)__pt;   \
\
for (i = 0; i < 512; ++i) { \
+   /* PTE present? */  \
if (!IOMMU_PTE_PRESENT(pt[i]))  \
continue;   \
\
+   /* Large PTE? */\
+   if (PM_PTE_LEVEL(pt[i]) == 0 || \
+   PM_PTE_LEVEL(pt[i]) == 7)   \
+   continue;   \
+   \
p = (unsigned long)IOMMU_PTE_PAGE(pt[i]);   \
FN(p);  \
}   \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 097/185] ext4: call sync_blockdev() before invalidate_bdev() in put_super()

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Theodore Ts'o 

commit 89d96a6f8e6491f24fc8f99fd6ae66820e85c6c1 upstream.

Normally all of the buffers will have been forced out to disk before
we call invalidate_bdev(), but there will be some cases, where a file
system operation was aborted due to an ext4_error(), where there may
still be some dirty buffers in the buffer cache for the device.  So
try to force them out to memory before calling invalidate_bdev().

This fixes a warning triggered by generic/081:

WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56 
__blkdev_put+0xb5/0x16f()

Signed-off-by: Theodore Ts'o 
Signed-off-by: Luis Henriques 
---
 fs/ext4/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 447ccd4af707..cf977e2f8a6f 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -833,6 +833,7 @@ static void ext4_put_super(struct super_block *sb)
dump_orphan_list(sb, sbi);
J_ASSERT(list_empty(>s_orphan));
 
+   sync_blockdev(sb->s_bdev);
invalidate_bdev(sb->s_bdev);
if (sbi->journal_bdev && sbi->journal_bdev != sb->s_bdev) {
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 080/185] fs/ufs: restore s_lock mutex

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Fabian Frederick 

commit cdd9eefdf905e92e7fc6cc393314efe68dc6ff66 upstream.

Commit 0244756edc4b98c ("ufs: sb mutex merge + mutex_destroy") generated
deadlocks in read/write mode on mkdir.

This patch partially reverts it keeping fixes by Andrew Morton and
mutex_destroy()

[AV: fixed a missing bit in ufs_remount()]

Signed-off-by: Fabian Frederick 
Reported-by: Ian Campbell 
Suggested-by: Jan Kara 
Cc: Ian Campbell 
Cc: Evgeniy Dushistov 
Cc: Alexey Khoroshilov 
Cc: Roger Pau Monne 
Cc: Ian Jackson 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques 
---
 fs/ufs/balloc.c | 34 +-
 fs/ufs/ialloc.c | 16 
 fs/ufs/super.c  | 10 ++
 fs/ufs/ufs.h|  1 +
 4 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/fs/ufs/balloc.c b/fs/ufs/balloc.c
index 7bc20809c99e..fe1b53d441e0 100644
--- a/fs/ufs/balloc.c
+++ b/fs/ufs/balloc.c
@@ -51,8 +51,8 @@ void ufs_free_fragments(struct inode *inode, u64 fragment, 
unsigned count)

if (ufs_fragnum(fragment) + count > uspi->s_fpg)
ufs_error (sb, "ufs_free_fragments", "internal error");
-   
-   lock_ufs(sb);
+
+   mutex_lock(_SB(sb)->s_lock);

cgno = ufs_dtog(uspi, fragment);
bit = ufs_dtogd(uspi, fragment);
@@ -115,13 +115,13 @@ void ufs_free_fragments(struct inode *inode, u64 
fragment, unsigned count)
if (sb->s_flags & MS_SYNCHRONOUS)
ubh_sync_block(UCPI_UBH(ucpi));
ufs_mark_sb_dirty(sb);
-   
-   unlock_ufs(sb);
+
+   mutex_unlock(_SB(sb)->s_lock);
UFSD("EXIT\n");
return;
 
 failed:
-   unlock_ufs(sb);
+   mutex_unlock(_SB(sb)->s_lock);
UFSD("EXIT (FAILED)\n");
return;
 }
@@ -151,7 +151,7 @@ void ufs_free_blocks(struct inode *inode, u64 fragment, 
unsigned count)
goto failed;
}
 
-   lock_ufs(sb);
+   mutex_lock(_SB(sb)->s_lock);

 do_more:
overflow = 0;
@@ -211,12 +211,12 @@ do_more:
}
 
ufs_mark_sb_dirty(sb);
-   unlock_ufs(sb);
+   mutex_unlock(_SB(sb)->s_lock);
UFSD("EXIT\n");
return;
 
 failed_unlock:
-   unlock_ufs(sb);
+   mutex_unlock(_SB(sb)->s_lock);
 failed:
UFSD("EXIT (FAILED)\n");
return;
@@ -357,7 +357,7 @@ u64 ufs_new_fragments(struct inode *inode, void *p, u64 
fragment,
usb1 = ubh_get_usb_first(uspi);
*err = -ENOSPC;
 
-   lock_ufs(sb);
+   mutex_lock(_SB(sb)->s_lock);
tmp = ufs_data_ptr_to_cpu(sb, p);
 
if (count + ufs_fragnum(fragment) > uspi->s_fpb) {
@@ -378,19 +378,19 @@ u64 ufs_new_fragments(struct inode *inode, void *p, u64 
fragment,
  "fragment %llu, tmp %llu\n",
  (unsigned long long)fragment,
  (unsigned long long)tmp);
-   unlock_ufs(sb);
+   mutex_unlock(_SB(sb)->s_lock);
return INVBLOCK;
}
if (fragment < UFS_I(inode)->i_lastfrag) {
UFSD("EXIT (ALREADY ALLOCATED)\n");
-   unlock_ufs(sb);
+   mutex_unlock(_SB(sb)->s_lock);
return 0;
}
}
else {
if (tmp) {
UFSD("EXIT (ALREADY ALLOCATED)\n");
-   unlock_ufs(sb);
+   mutex_unlock(_SB(sb)->s_lock);
return 0;
}
}
@@ -399,7 +399,7 @@ u64 ufs_new_fragments(struct inode *inode, void *p, u64 
fragment,
 * There is not enough space for user on the device
 */
if (!capable(CAP_SYS_RESOURCE) && ufs_freespace(uspi, UFS_MINFREE) <= 
0) {
-   unlock_ufs(sb);
+   mutex_unlock(_SB(sb)->s_lock);
UFSD("EXIT (FAILED)\n");
return 0;
}
@@ -424,7 +424,7 @@ u64 ufs_new_fragments(struct inode *inode, void *p, u64 
fragment,
ufs_clear_frags(inode, result + oldcount,
newcount - oldcount, locked_page != 
NULL);
}
-   unlock_ufs(sb);
+   mutex_unlock(_SB(sb)->s_lock);
UFSD("EXIT, result %llu\n", (unsigned long long)result);
return result;
}
@@ -439,7 +439,7 @@ u64 ufs_new_fragments(struct inode *inode, void *p, u64 
fragment,
fragment + count);
ufs_clear_frags(inode, result + oldcount, newcount - oldcount,
locked_page != NULL);
-   unlock_ufs(sb);
+   

[PATCH 3.16.y-ckt 101/185] xfs: don't truncate attribute extents if no extents exist

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Brian Foster 

commit f66bf042693b620133d39af8d2f13615f03eadfc upstream.

The xfs_attr3_root_inactive() call from xfs_attr_inactive() assumes that
attribute blocks exist to invalidate. It is possible to have an
attribute fork without extents, however. Consider the case where the
attribute fork is created towards the beginning of xfs_attr_set() but
some part of the subsequent attribute set fails.

If an inode in such a state hits xfs_attr_inactive(), it eventually
calls xfs_dabuf_map() and possibly xfs_bmapi_read(). The former emits a
filesystem corruption warning, returns an error that bubbles back up to
xfs_attr_inactive(), and leads to destruction of the in-core attribute
fork without an on-disk reset. If the inode happens to make it back
through xfs_inactive() in this state (e.g., via a concurrent bulkstat
that cycles the inode from the reclaim state and releases it), i_afp
might not exist when xfs_bmapi_read() is called and causes a NULL
dereference panic.

A '-p 2' fsstress run to ENOSPC on a relatively small fs (1GB)
reproduces these problems. The behavior is a regression caused by:

6dfe5a0 xfs: xfs_attr_inactive leaves inconsistent attr fork state behind

... which removed logic that avoided the attribute extent truncate when
no extents exist. Restore this logic to ensure the attribute fork is
destroyed and reset correctly if it exists without any allocated
extents.

Signed-off-by: Brian Foster 
Reviewed-by: Dave Chinner 
Signed-off-by: Dave Chinner 
Signed-off-by: Luis Henriques 
---
 fs/xfs/xfs_attr_inactive.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_attr_inactive.c b/fs/xfs/xfs_attr_inactive.c
index ced1dd9dd095..00f68393adf2 100644
--- a/fs/xfs/xfs_attr_inactive.c
+++ b/fs/xfs/xfs_attr_inactive.c
@@ -437,8 +437,14 @@ xfs_attr_inactive(
 */
xfs_trans_ijoin(trans, dp, 0);
 
-   /* invalidate and truncate the attribute fork extents */
-   if (dp->i_d.di_aformat != XFS_DINODE_FMT_LOCAL) {
+   /*
+* Invalidate and truncate the attribute fork extents. Make sure the
+* fork actually has attributes as otherwise the invalidation has no
+* blocks to read and returns an error. In this case, just do the fork
+* removal below.
+*/
+   if (xfs_inode_hasattr(dp) &&
+   dp->i_d.di_aformat != XFS_DINODE_FMT_LOCAL) {
error = xfs_attr3_root_inactive(, dp);
if (error)
goto out_cancel;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 094/185] libata: Do not blacklist Micron M500DC

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Martin K. Petersen" 

commit 243918be6393f643e513a26e7882e6ae06ff7717 upstream.

Queued TRIM got disabled on Micron M500DC drives thanks to the
"Micron_M500*" pattern we had in place to accommodate the previous
generation of this drive family. Tweak the blacklist entry slightly so
we only disable queued TRIM for the non-DC variants of M500 drives.

Signed-off-by: Martin K. Petersen 
Signed-off-by: Tejun Heo 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques 
---
 drivers/ata/libata-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 29358ff3e05e..a554b2e17cd4 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4224,7 +4224,7 @@ static const struct ata_blacklist_entry 
ata_device_blacklist [] = {
{ "PIONEER DVD-RW  DVR-216D",   NULL,   ATA_HORKAGE_NOSETXFER },
 
/* devices that don't properly handle queued TRIM commands */
-   { "Micron_M500*",   NULL,   ATA_HORKAGE_NO_NCQ_TRIM, },
+   { "Micron_M500_*",  NULL,   ATA_HORKAGE_NO_NCQ_TRIM, },
{ "Crucial_CT*M500*",   NULL,   ATA_HORKAGE_NO_NCQ_TRIM, },
{ "Micron_M5[15]0*","MU01", ATA_HORKAGE_NO_NCQ_TRIM, },
{ "Crucial_CT*M550*",   "MU01", ATA_HORKAGE_NO_NCQ_TRIM, },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] gpio: of: remove unnecessary variable in of_get_gpio_hog()

[Linus Walleij]

On Tue, Jul 14, 2015 at 3:01 AM, Masahiro Yamada
 wrote:

> The variable "desc" is only used for storing the return value at the
> end of the function.  It is unneeded.
>
> Signed-off-by: Masahiro Yamada 
> Acked-by: Alexandre Courbot 

Patch applied.

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

[PATCH 3.16.y-ckt 105/185] stmmac: troubleshoot unexpected bits in des0 & des1

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alexey Brodkin 

commit f1590670ce069eefeb93916391a67643e6ad1630 upstream.

Current implementation of descriptor init procedure only takes
care about setting/clearing ownership flag in "des0"/"des1"
fields while it is perfectly possible to get unexpected bits
set because of the following factors:

 [1] On driver probe underlying memory allocated with
 dma_alloc_coherent() might not be zeroed and so
 it will be filled with garbage.

 [2] During driver operation some bits could be set by SD/MMC
 controller (for example error flags etc).

And unexpected and/or randomly set flags in "des0"/"des1"
fields may lead to unpredictable behavior of GMAC DMA block.

This change addresses both items above with:

 [1] Use of dma_zalloc_coherent() instead of simple
 dma_alloc_coherent() to make sure allocated memory is
 zeroed. That shouldn't affect performance because
 this allocation only happens once on driver probe.

 [2] Do explicit zeroing of both "des0" and "des1" fields
 of all buffer descriptors during initialization of
 DMA transfer.

And while at it fixed identation of dma_free_coherent()
counterpart as well.

Signed-off-by: Alexey Brodkin 
Cc: Giuseppe Cavallaro 
Cc: arc-linux-...@synopsys.com
Cc: linux-kernel@vger.kernel.org
Cc: David Miller 
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques 
---
 drivers/net/ethernet/stmicro/stmmac/descs.h   |  2 ++
 drivers/net/ethernet/stmicro/stmmac/enh_desc.c|  3 +-
 drivers/net/ethernet/stmicro/stmmac/norm_desc.c   |  3 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 44 +++
 4 files changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/descs.h 
b/drivers/net/ethernet/stmicro/stmmac/descs.h
index ad3996038018..799c2929c536 100644
--- a/drivers/net/ethernet/stmicro/stmmac/descs.h
+++ b/drivers/net/ethernet/stmicro/stmmac/descs.h
@@ -158,6 +158,8 @@ struct dma_desc {
u32 buffer2_size:13;
u32 reserved4:3;
} etx;  /* -- enhanced -- */
+
+   u64 all_flags;
} des01;
unsigned int des2;
unsigned int des3;
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c 
b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 1e2bcf5f89e1..7d99f5ef 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -240,6 +240,7 @@ static int enh_desc_get_rx_status(void *data, struct 
stmmac_extra_stats *x,
 static void enh_desc_init_rx_desc(struct dma_desc *p, int disable_rx_ic,
  int mode, int end)
 {
+   p->des01.all_flags = 0;
p->des01.erx.own = 1;
p->des01.erx.buffer1_size = BUF_SIZE_8KiB - 1;
 
@@ -254,7 +255,7 @@ static void enh_desc_init_rx_desc(struct dma_desc *p, int 
disable_rx_ic,
 
 static void enh_desc_init_tx_desc(struct dma_desc *p, int mode, int end)
 {
-   p->des01.etx.own = 0;
+   p->des01.all_flags = 0;
if (mode == STMMAC_CHAIN_MODE)
ehn_desc_tx_set_on_chain(p, end);
else
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c 
b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index 35ad4f427ae2..48c3456445b2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -123,6 +123,7 @@ static int ndesc_get_rx_status(void *data, struct 
stmmac_extra_stats *x,
 static void ndesc_init_rx_desc(struct dma_desc *p, int disable_rx_ic, int mode,
   int end)
 {
+   p->des01.all_flags = 0;
p->des01.rx.own = 1;
p->des01.rx.buffer1_size = BUF_SIZE_2KiB - 1;
 
@@ -137,7 +138,7 @@ static void ndesc_init_rx_desc(struct dma_desc *p, int 
disable_rx_ic, int mode,
 
 static void ndesc_init_tx_desc(struct dma_desc *p, int mode, int end)
 {
-   p->des01.tx.own = 0;
+   p->des01.all_flags = 0;
if (mode == STMMAC_CHAIN_MODE)
ndesc_tx_set_on_chain(p, end);
else
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 057a1208e594..641086fc14b5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1142,41 +1142,41 @@ static int alloc_dma_desc_resources(struct stmmac_priv 
*priv)
goto err_tx_skbuff;
 
if (priv->extend_desc) {
-   priv->dma_erx = dma_alloc_coherent(priv->device, rxsize *
-  sizeof(struct
- dma_extended_desc),
-  >dma_rx_phy,
-  GFP_KERNEL);
+   priv->dma_erx = 

Re: [PATCH v2 2/2] ASoC: Drop owner assignment from platform_driver

[Mark Brown]

On Wed, Jul 15, 2015 at 04:23:00PM +0900, Krzysztof Kozlowski wrote:

> > platform_driver does not need to set an owner because
> > platform_driver_register() will set it.

> D'oh! I forgot to include ack from Koro Chen given here:
> https://lkml.org/lkml/2015/7/12/218

That and the fact that it's already applied.


signature.asc
Description: Digital signature

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

[Michal Suchanek]

On 4 June 2015 at 19:15, Richard Cochran  wrote:
> On Thu, Jun 04, 2015 at 10:31:45AM +0200, Michal Suchanek wrote:
>> You might want to try to run the bus at 60MHz or 80MHz and then the
>> values would probably again be different.
>>
>> The first two values are set in DT so the logical place for setting
>> the third is also in DT.
>>
>> Otherwise you would need some in-kernel table of these settings.
>
> Or a formula.
>

This formula probably needs to take into account

 - the unknown reason for the pl330 to fail transfer
 - the device transfer speed and transfer phase as set in DT
 - possibly device-specific latency and board-specific trace design
and assembly tolerances

Seriously, until I have at least a vague idea why the transfer fails I
am not comfortable pulling some formula out of thin air and pretending
I have a working patch.

On the other hand, a parameter you can set in the DT and which comes
with a suggested value which can be tuned depending on the system
seems more viable.

Thanks

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

[PATCH 3.16.y-ckt 098/185] MIPS: Fix KVM guest fixmap address

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: James Hogan 

commit 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 upstream.

KVM guest kernels for trap & emulate run in user mode, with a modified
set of kernel memory segments. However the fixmap address is still in
the normal KSeg3 region at 0xfffe regardless, causing problems when
cache alias handling makes use of them when handling copy on write.

Therefore define FIXADDR_TOP as 0x7ffe in the guest kernel mapped
region when CONFIG_KVM_GUEST is defined.

Signed-off-by: James Hogan 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9887/
Signed-off-by: Ralf Baechle 
Signed-off-by: Luis Henriques 
---
 arch/mips/include/asm/mach-generic/spaces.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/include/asm/mach-generic/spaces.h 
b/arch/mips/include/asm/mach-generic/spaces.h
index 9488fa5f8866..afc96ecb9004 100644
--- a/arch/mips/include/asm/mach-generic/spaces.h
+++ b/arch/mips/include/asm/mach-generic/spaces.h
@@ -94,7 +94,11 @@
 #endif
 
 #ifndef FIXADDR_TOP
+#ifdef CONFIG_KVM_GUEST
+#define FIXADDR_TOP((unsigned long)(long)(int)0x7ffe)
+#else
 #define FIXADDR_TOP((unsigned long)(long)(int)0xfffe)
 #endif
+#endif
 
 #endif /* __ASM_MACH_GENERIC_SPACES_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 106/185] ACPI / resources: free memory on error in add_region_before()

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dan Carpenter 

commit 7bc10388ccdd79b3d20463151a1f8e7a590a775b upstream.

There is a small memory leak on error.

Fixes: 0f1b414d1907 (ACPI / PNP: Avoid conflicting resource reservations)
Signed-off-by: Dan Carpenter 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Luis Henriques 
---
 drivers/acpi/resource.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 28314ba82320..3760e9635aea 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -577,8 +577,10 @@ static int add_region_before(u64 start, u64 end, u8 
space_id,
return -ENOMEM;
 
error = request_range(start, end, space_id, flags, desc);
-   if (error)
+   if (error) {
+   kfree(reg);
return error;
+   }
 
reg->start = start;
reg->end = end;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 108/185] ARC: add compiler barrier to LLSC based cmpxchg

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Vineet Gupta 

commit d57f727264f1425a94689bafc7e99e502cb135b5 upstream.

When auditing cmpxchg call sites, Chuck noted that gcc was optimizing
away some of the desired LDs.

|   do {
|   new = old = *ipi_data_ptr;
|   new |= 1U << msg;
|   } while (cmpxchg(ipi_data_ptr, old, new) != old);

was generating to below

| 8015cef8: ld r2,[r4,0]  <-- First LD
| 8015cefc: bset   r1,r2,r1
|
| 8015cf00: llock  r3,[r4]  <-- atomic op
| 8015cf04: brne   r3,r2,8015cf10
| 8015cf08: scond  r1,[r4]
| 8015cf0c: bnz8015cf00
|
| 8015cf10: brne   r3,r2,8015cf00  <-- Branch doesn't go to orig LD

Although this was fixed by adding a ACCESS_ONCE in this call site, it
seems safer (for now at least) to add compiler barrier to LLSC based
cmpxchg

Reported-by: Chuck Jordan 
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Vineet Gupta 
Signed-off-by: Luis Henriques 
---
 arch/arc/include/asm/cmpxchg.h | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h
index 03cd6894855d..90de5c528da2 100644
--- a/arch/arc/include/asm/cmpxchg.h
+++ b/arch/arc/include/asm/cmpxchg.h
@@ -25,10 +25,11 @@ __cmpxchg(volatile void *ptr, unsigned long expected, 
unsigned long new)
"   scond   %3, [%1]\n"
"   bnz 1b  \n"
"2: \n"
-   : "="(prev)
-   : "r"(ptr), "ir"(expected),
- "r"(new) /* can't be "ir". scond can't take limm for "b" */
-   : "cc");
+   : "="(prev)   /* Early clobber, to prevent reg reuse */
+   : "r"(ptr), /* Not "m": llock only supports reg direct addr mode */
+ "ir"(expected),
+ "r"(new)  /* can't be "ir". scond can't take LIMM for "b" */
+   : "cc", "memory"); /* so that gcc knows memory is being written here */
 
return prev;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] gpio: altera: use of_mm_gpiochip_remove() to fix memory leak

[Linus Walleij]

On Wed, Jun 17, 2015 at 1:59 PM, Masahiro Yamada
 wrote:

> This driver calls of_mm_gpiochip_add() to add a memory mapped gpio
> chip.  So, of_mm_gpiochip_remove() should be used when removing it.
>
> The direct call of gpiochip_remove() misses unmapping the register
> and freeing the label.
>
> Signed-off-by: Masahiro Yamada 

Patch applied with the ACKs.

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

Re: [PATCH 2/2] gpio: mvebu: kill bogus dependency on GPIO_GENERIC

[Linus Walleij]

On Fri, Jun 19, 2015 at 1:31 PM, Masahiro Yamada
 wrote:

> The driver gpio-mvebu.c does not depend on gpio-generic.c at all.
> Drop unneeded "select GPIO_GENERIC".
>
> Signed-off-by: Masahiro Yamada 

Patch applied with Gregory's ACK.

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

[PATCH 3.16.y-ckt 099/185] xfs: fix remote symlinks on V5/CRC filesystems

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Eric Sandeen 

commit 2ac56d3d4bd625450a54d4c3f9292d58f6b88232 upstream.

If we create a CRC filesystem, mount it, and create a symlink with
a path long enough that it can't live in the inode, we get a very
strange result upon remount:

# ls -l mnt
total 4
lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM

XSLM is the V5 symlink block header magic (which happens to be
followed by a NUL, so the string looks terminated).

xfs_readlink_bmap() advanced cur_chunk by the size of the header
for CRC filesystems, but never actually used that pointer; it
kept reading from bp->b_addr, which is the start of the block,
rather than the start of the symlink data after the header.

Looks like this problem goes back to v3.10.

Fixing this gets us reading the proper link target, again.

Signed-off-by: Eric Sandeen 
Reviewed-by: Dave Chinner 
Signed-off-by: Dave Chinner 
Signed-off-by: Luis Henriques 
---
 fs/xfs/xfs_symlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_symlink.c b/fs/xfs/xfs_symlink.c
index d69363c833e1..484583ef8821 100644
--- a/fs/xfs/xfs_symlink.c
+++ b/fs/xfs/xfs_symlink.c
@@ -107,7 +107,7 @@ xfs_readlink_bmap(
cur_chunk += sizeof(struct xfs_dsymlink_hdr);
}
 
-   memcpy(link + offset, bp->b_addr, byte_cnt);
+   memcpy(link + offset, cur_chunk, byte_cnt);
 
pathlen -= byte_cnt;
offset += byte_cnt;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 103/185] netfilter: nf_qeueue: Drop queue entries on nf_unregister_hook

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Eric W. Biederman" 

commit 8405a8fff3f8545c888a872d6e3c0c8eecd4d348 upstream.

Add code to nf_unregister_hook to flush the nf_queue when a hook is
unregistered.  This guarantees that the pointer that the nf_queue code
retains into the nf_hook list will remain valid while a packet is
queued.

I tested what would happen if we do not flush queued packets and was
trivially able to obtain the oops below.  All that was required was
to stop the nf_queue listening process, to delete all of the nf_tables,
and to awaken the nf_queue listening process.

> BUG: unable to handle kernel paging request at 00010001
> IP: [<00010001>] 0x10001
> PGD b9c35067 PUD 0
> Oops: 0010 [#1] SMP
> Modules linked in:
> CPU: 0 PID: 519 Comm: lt-nfqnl_test Not tainted
> task: 8800b9c8c050 ti: 8800ba9d8000 task.ti: 8800ba9d8000
> RIP: 0010:[<00010001>]  [<00010001>] 0x10001
> RSP: 0018:8800ba9dba40  EFLAGS: 00010a16
> RAX: 8800bab48a00 RBX: 8800ba9dba90 RCX: 8800ba9dba90
> RDX: 8800b9c10128 RSI: 8800ba940900 RDI: 8800bab48a00
> RBP: 8800b9c10128 R08: 82976660 R09: 8800ba9dbb28
> R10: dead00100100 R11: dead00200200 R12: 8800ba940900
> R13: 8313fd50 R14: 8800b9c95200 R15: 
> FS:  7fb91fc34700() GS:8800bfa0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 00010001 CR3: babfb000 CR4: 07f0
> Stack:
>  8206ab0f 82982240 8800bab48a00 8800b9c100a8
>  8800b9c10100 0001 8800ba940900 8800b9c10128
>  8206bd65 8800bfb0d5e0 8800bab48a00 00014dc0
> Call Trace:
>  [] ? nf_iterate+0x4f/0xa0
>  [] ? nf_reinject+0x125/0x190
>  [] ? nfqnl_recv_verdict+0x255/0x360
>  [] ? nla_parse+0x80/0xf0
>  [] ? nfnetlink_rcv_msg+0x13c/0x240
>  [] ? __memcg_kmem_get_cache+0x4c/0x150
>  [] ? nfnl_lock+0x20/0x20
>  [] ? netlink_rcv_skb+0xa9/0xc0
>  [] ? netlink_unicast+0x12f/0x1c0
>  [] ? netlink_sendmsg+0x28e/0x650
>  [] ? sock_sendmsg+0x44/0x50
>  [] ? ___sys_sendmsg+0x2ab/0x2c0
>  [] ? __wake_up+0x43/0x70
>  [] ? tty_write+0x1c4/0x2a0
>  [] ? __sys_sendmsg+0x44/0x80
>  [] ? system_call_fastpath+0x12/0x6a
> Code:  Bad RIP value.
> RIP  [<00010001>] 0x10001
>  RSP 
> CR2: 00010001
> ---[ end trace 08eb65d42362793f ]---

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques 
---
 include/net/netfilter/nf_queue.h |  2 ++
 net/netfilter/core.c |  1 +
 net/netfilter/nf_internals.h |  1 +
 net/netfilter/nf_queue.c | 17 +
 net/netfilter/nfnetlink_queue_core.c | 24 +++-
 5 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/include/net/netfilter/nf_queue.h b/include/net/netfilter/nf_queue.h
index 84a53d780306..1a91f979160e 100644
--- a/include/net/netfilter/nf_queue.h
+++ b/include/net/netfilter/nf_queue.h
@@ -28,6 +28,8 @@ struct nf_queue_entry {
 struct nf_queue_handler {
int (*outfn)(struct nf_queue_entry *entry,
 unsigned int queuenum);
+   void(*nf_hook_drop)(struct net *net,
+   struct nf_hook_ops *ops);
 };
 
 void nf_register_queue_handler(const struct nf_queue_handler *qh);
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 1fbab0cdd302..32c5db5a8569 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -95,6 +95,7 @@ void nf_unregister_hook(struct nf_hook_ops *reg)
static_key_slow_dec(_hooks_needed[reg->pf][reg->hooknum]);
 #endif
synchronize_net();
+   nf_queue_nf_hook_drop(reg);
 }
 EXPORT_SYMBOL(nf_unregister_hook);
 
diff --git a/net/netfilter/nf_internals.h b/net/netfilter/nf_internals.h
index 61a3c927e63c..aba1d7dac17c 100644
--- a/net/netfilter/nf_internals.h
+++ b/net/netfilter/nf_internals.h
@@ -24,6 +24,7 @@ int nf_queue(struct sk_buff *skb, struct nf_hook_ops *elem, 
u_int8_t pf,
 unsigned int hook, struct net_device *indev,
 struct net_device *outdev, int (*okfn)(struct sk_buff *),
 unsigned int queuenum);
+void nf_queue_nf_hook_drop(struct nf_hook_ops *ops);
 int __init netfilter_queue_init(void);
 
 /* nf_log.c */
diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
index 5d24b1fdb593..df046ed74f2b 100644
--- a/net/netfilter/nf_queue.c
+++ b/net/netfilter/nf_queue.c
@@ -95,6 +95,23 @@ bool nf_queue_entry_get_refs(struct nf_queue_entry *entry)
 }
 EXPORT_SYMBOL_GPL(nf_queue_entry_get_refs);
 
+void nf_queue_nf_hook_drop(struct nf_hook_ops *ops)
+{
+   const struct nf_queue_handler *qh;
+   struct net *net;
+
+   rtnl_lock();
+ 

[PATCH 3.16.y-ckt 100/185] ext4: don't retry file block mapping on bigalloc fs with non-extent file

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Darrick J. Wong" 

commit 292db1bc6c105d86111e858859456bcb11f90f91 upstream.

ext4 isn't willing to map clusters to a non-extent file.  Don't signal
this with an out of space error, since the FS will retry the
allocation (which didn't fail) forever.  Instead, return EUCLEAN so
that the operation will fail immediately all the way back to userspace.

(The fix is either to run e2fsck -E bmap2extent, or to chattr +e the file.)

Signed-off-by: Darrick J. Wong 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Luis Henriques 
---
 fs/ext4/indirect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/indirect.c b/fs/ext4/indirect.c
index 944c49dd83e3..0c9ed67fe055 100644
--- a/fs/ext4/indirect.c
+++ b/fs/ext4/indirect.c
@@ -576,7 +576,7 @@ int ext4_ind_map_blocks(handle_t *handle, struct inode 
*inode,
   EXT4_FEATURE_RO_COMPAT_BIGALLOC)) {
EXT4_ERROR_INODE(inode, "Can't allocate blocks for "
 "non-extent mapped inodes with bigalloc");
-   return -ENOSPC;
+   return -EUCLEAN;
}
 
goal = ext4_find_goal(inode, map->m_lblk, partial);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 107/185] PM / sleep: Increase default DPM watchdog timeout to 60

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Takashi Iwai 

commit fff3b16d2754a061a3549c4307a186423a0128fd upstream.

Many harddisks (mostly WD ones) have firmware problems and take too
long, more than 10 seconds, to resume from suspend.  And this often
exceeds the default DPM watchdog timeout (12 seconds), resulting in a
kernel panic out of sudden.

Since most distros just take the default as is, we should give a bit
more safer value.  This patch increases the default value from 12
seconds to one minute, which has been confirmed to be long enough for
such problematic disks.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=91921
Fixes: 70fea60d888d (PM / Sleep: Detect device suspend/resume lockup and log 
event)
Signed-off-by: Takashi Iwai 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Luis Henriques 
---
 kernel/power/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 9a83d780facd..ff6150d05e82 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -191,7 +191,7 @@ config DPM_WATCHDOG
 config DPM_WATCHDOG_TIMEOUT
int "Watchdog timeout in seconds"
range 1 120
-   default 12
+   default 60
depends on DPM_WATCHDOG
 
 config PM_TRACE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 113/185] ALSA: hda - Fix Dock Headphone on Thinkpad X250 seen as a Line Out

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: David Henningsson 

commit ec56af67a10a0d82b79027878a81fce08d002d50 upstream.

Thinkpad X250, when attached to a dock, has two headphone outs but
no line out. Make sure we don't try to turn this into one headphone
and one line out (since that disables the headphone amp on the dock).

Alsa-info at 
http://www.alsa-project.org/db/?f=36f8764e1d782397928feec715d0ef90dfddd4c1

Signed-off-by: David Henningsson 
Signed-off-by: Takashi Iwai 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques 
---
 sound/pci/hda/patch_realtek.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 9d2aedb84797..1115e8aed237 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4314,6 +4314,7 @@ enum {
ALC255_FIXUP_HEADSET_MODE_NO_HP_MIC,
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC292_FIXUP_TPT440_DOCK,
+   ALC292_FIXUP_TPT440_DOCK2,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -4738,6 +4739,12 @@ static const struct hda_fixup alc269_fixups[] = {
.chain_id = ALC269_FIXUP_HEADSET_MODE
},
[ALC292_FIXUP_TPT440_DOCK] = {
+   .type = HDA_FIXUP_FUNC,
+   .v.func = alc269_fixup_pincfg_no_hp_to_lineout,
+   .chained = true,
+   .chain_id = ALC292_FIXUP_TPT440_DOCK2
+   },
+   [ALC292_FIXUP_TPT440_DOCK2] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
{ 0x16, 0x21211010 }, /* dock headphone */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 115/185] tracing/filter: Do not allow infix to exceed end of string

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Steven Rostedt (Red Hat)" 

commit 6b88f44e161b9ee2a803e5b2b1fbcf4e20e8b980 upstream.

While debugging a WARN_ON() for filtering, I found that it is possible
for the filter string to be referenced after its end. With the filter:

 # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter

The filter_parse() function can call infix_get_op() which calls
infix_advance() that updates the infix filter pointers for the cnt
and tail without checking if the filter is already at the end, which
will put the cnt to zero and the tail beyond the end. The loop then calls
infix_next() that has

ps->infix.cnt--;
return ps->infix.string[ps->infix.tail++];

The cnt will now be below zero, and the tail that is returned is
already passed the end of the filter string. So far the allocation
of the filter string usually has some buffer that is zeroed out, but
if the filter string is of the exact size of the allocated buffer
there's no guarantee that the charater after the nul terminating
character will be zero.

Luckily, only root can write to the filter.

Signed-off-by: Steven Rostedt 
Signed-off-by: Luis Henriques 
---
 kernel/trace/trace_events_filter.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/trace/trace_events_filter.c 
b/kernel/trace/trace_events_filter.c
index 61959fa704ed..7b244d004d68 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1086,6 +1086,9 @@ static void parse_init(struct filter_parse_state *ps,
 
 static char infix_next(struct filter_parse_state *ps)
 {
+   if (!ps->infix.cnt)
+   return 0;
+
ps->infix.cnt--;
 
return ps->infix.string[ps->infix.tail++];
@@ -1101,6 +1104,9 @@ static char infix_peek(struct filter_parse_state *ps)
 
 static void infix_advance(struct filter_parse_state *ps)
 {
+   if (!ps->infix.cnt)
+   return;
+
ps->infix.cnt--;
ps->infix.tail++;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 104/185] fs: Fix S_NOSEC handling

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jan Kara 

commit 2426f3910069ed47c0cc58559a6d088af7920201 upstream.

file_remove_suid() could mistakenly set S_NOSEC inode bit when root was
modifying the file. As a result following writes to the file by ordinary
user would avoid clearing suid or sgid bits.

Fix the bug by checking actual mode bits before setting S_NOSEC.

Signed-off-by: Jan Kara 
Signed-off-by: Al Viro 
Signed-off-by: Luis Henriques 
---
 fs/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index 6eecb7ff0b9a..f5a842698580 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1630,8 +1630,8 @@ int file_remove_suid(struct file *file)
error = security_inode_killpriv(dentry);
if (!error && killsuid)
error = __remove_suid(dentry, killsuid);
-   if (!error && (inode->i_sb->s_flags & MS_NOSEC))
-   inode->i_flags |= S_NOSEC;
+   if (!error)
+   inode_has_no_xattr(inode);
 
return error;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 114/185] tracing/filter: Do not WARN on operand count going below zero

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Steven Rostedt (Red Hat)" 

commit b4875bbe7e68f139bd3383828ae8e994a0df6d28 upstream.

When testing the fix for the trace filter, I could not come up with
a scenario where the operand count goes below zero, so I added a
WARN_ON_ONCE(cnt < 0) to the logic. But there is legitimate case
that it can happen (although the filter would be wrong).

 # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter

That is, a single operation without any operands will hit the path
where the WARN_ON_ONCE() can trigger. Although this is harmless,
and the filter is reported as a error. But instead of spitting out
a warning to the kernel dmesg, just fail nicely and report it via
the proper channels.

Link: http://lkml.kernel.org/r/558c6082.90...@oracle.com

Reported-by: Vince Weaver 
Reported-by: Sasha Levin 
Signed-off-by: Steven Rostedt 
Signed-off-by: Luis Henriques 
---
 kernel/trace/trace_events_filter.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_events_filter.c 
b/kernel/trace/trace_events_filter.c
index cb347e85f75e..61959fa704ed 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1413,7 +1413,9 @@ static int check_preds(struct filter_parse_state *ps)
continue;
}
n_normal_preds++;
-   WARN_ON_ONCE(cnt < 0);
+   /* all ops should have operands */
+   if (cnt < 0)
+   break;
}
 
if (cnt != 1 || !n_normal_preds || n_logical_preds >= n_normal_preds) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 110/185] ARC: add smp barriers around atomics per Documentation/atomic_ops.txt

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Vineet Gupta 

commit 2576c28e3f623ed401db7e6197241865328620ef upstream.

 - arch_spin_lock/unlock were lacking the ACQUIRE/RELEASE barriers
   Since ARCv2 only provides load/load, store/store and all/all, we need
   the full barrier

 - LLOCK/SCOND based atomics, bitops, cmpxchg, which return modified
   values were lacking the explicit smp barriers.

 - Non LLOCK/SCOND varaints don't need the explicit barriers since that
   is implicity provided by the spin locks used to implement the
   critical section (the spin lock barriers in turn are also fixed in
   this commit as explained above

Cc: Paul E. McKenney 
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Vineet Gupta 
Signed-off-by: Luis Henriques 
---
 arch/arc/include/asm/atomic.h   | 21 +
 arch/arc/include/asm/bitops.h   | 19 +++
 arch/arc/include/asm/cmpxchg.h  | 17 +
 arch/arc/include/asm/spinlock.h | 32 
 4 files changed, 89 insertions(+)

diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index 173f303a868f..223138716c2e 100644
--- a/arch/arc/include/asm/atomic.h
+++ b/arch/arc/include/asm/atomic.h
@@ -45,6 +45,12 @@ static inline int atomic_##op##_return(int i, atomic_t *v)   
\
 {  \
unsigned int temp;  \
\
+   /*  \
+* Explicit full memory barrier needed before/after as  \
+* LLOCK/SCOND thmeselves don't provide any such semantics  \
+*/ \
+   smp_mb();   \
+   \
__asm__ __volatile__(   \
"1: llock   %0, [%1]\n" \
"   " #asm_op " %0, %0, %2  \n" \
@@ -54,6 +60,8 @@ static inline int atomic_##op##_return(int i, atomic_t *v)
\
: "r"(>counter), "ir"(i) \
: "cc");\
\
+   smp_mb();   \
+   \
return temp;\
 }
 
@@ -107,6 +115,9 @@ static inline int atomic_##op##_return(int i, atomic_t *v)  
\
unsigned long flags;\
unsigned long temp; \
\
+   /*  \
+* spin lock/unlock provides the needed smp_mb() before/after   \
+*/ \
atomic_ops_lock(flags); \
temp = v->counter;  \
temp c_op i;\
@@ -144,9 +155,19 @@ ATOMIC_OP(and, &=, and)
 #define __atomic_add_unless(v, a, u)   \
 ({ \
int c, old; \
+   \
+   /*  \
+* Explicit full memory barrier needed before/after as  \
+* LLOCK/SCOND thmeselves don't provide any such semantics  \
+*/ \
+   smp_mb();   \
+   \
c = atomic_read(v); \
while (c != (u) && (old = atomic_cmpxchg((v), c, c + (a))) != c)\
c = old;\
+   \
+   smp_mb();   \
+   \
c;  \
 })
 
diff --git a/arch/arc/include/asm/bitops.h b/arch/arc/include/asm/bitops.h
index ebc0cf3164dc..72e50ec9d00b 100644

[PATCH 3.16.y-ckt 112/185] dell-laptop: Fix allocating & freeing SMI buffer page

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: =?UTF-8?q?Pali=20Roh=C3=A1r?= 

commit b8830a4e71b15d0364ac8e6c55301eea73f211da upstream.

This commit fix kernel crash when probing for rfkill devices in dell-laptop
driver failed. Function free_page() was incorrectly used on struct page *
instead of virtual address of SMI buffer.

This commit also simplify allocating page for SMI buffer by using
__get_free_page() function instead of sequential call of functions
alloc_page() and page_address().

Signed-off-by: Pali Rohár 
Acked-by: Michal Hocko 
Signed-off-by: Darren Hart 
Signed-off-by: Luis Henriques 
---
 drivers/platform/x86/dell-laptop.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index fed4111ac31a..1beb232ef03b 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -272,7 +272,6 @@ static struct dmi_system_id dell_quirks[] = {
 };
 
 static struct calling_interface_buffer *buffer;
-static struct page *bufferpage;
 static DEFINE_MUTEX(buffer_mutex);
 
 static int hwswitch_state;
@@ -825,12 +824,11 @@ static int __init dell_init(void)
 * Allocate buffer below 4GB for SMI data--only 32-bit physical addr
 * is passed to SMI handler.
 */
-   bufferpage = alloc_page(GFP_KERNEL | GFP_DMA32);
-   if (!bufferpage) {
+   buffer = (void *)__get_free_page(GFP_KERNEL | GFP_DMA32);
+   if (!buffer) {
ret = -ENOMEM;
goto fail_buffer;
}
-   buffer = page_address(bufferpage);
 
ret = dell_setup_rfkill();
 
@@ -892,7 +890,7 @@ fail_backlight:
cancel_delayed_work_sync(_rfkill_work);
dell_cleanup_rfkill();
 fail_rfkill:
-   free_page((unsigned long)bufferpage);
+   free_page((unsigned long)buffer);
 fail_buffer:
platform_device_del(platform_device);
 fail_platform_device2:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 126/185] crush: fix a bug in tree bucket decode

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Ilya Dryomov 

commit 82cd003a77173c91b9acad8033fb7931dac8d751 upstream.

struct crush_bucket_tree::num_nodes is u8, so ceph_decode_8_safe()
should be used.  -Wconversion catches this, but I guess it went
unnoticed in all the noise it spews.  The actual problem (at least for
common crushmaps) isn't the u32 -> u8 truncation though - it's the
advancement by 4 bytes instead of 1 in the crushmap buffer.

Fixes: http://tracker.ceph.com/issues/2759

Signed-off-by: Ilya Dryomov 
Reviewed-by: Josh Durgin 
Signed-off-by: Luis Henriques 
---
 net/ceph/osdmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
index c547e46084d3..5740f71b609d 100644
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@ -89,7 +89,7 @@ static int crush_decode_tree_bucket(void **p, void *end,
 {
int j;
dout("crush_decode_tree_bucket %p to %p\n", *p, end);
-   ceph_decode_32_safe(p, end, b->num_nodes, bad);
+   ceph_decode_8_safe(p, end, b->num_nodes, bad);
b->node_weights = kcalloc(b->num_nodes, sizeof(u32), GFP_NOFS);
if (b->node_weights == NULL)
return -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 118/185] ALSA: hda - Fix the dock headphone output on Fujitsu Lifebook E780

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Takashi Iwai 

commit 4df3fd1700abbb53bd874143dfd1f9ac9e7cbf4b upstream.

Fujitsu Lifebook E780 sets the sequence number 0x0f to only only of
the two headphones, thus the driver tries to assign another as the
line-out, and this results in the inconsistent mapping between the
created jack ctl and the actual I/O.  Due to this, PulseAudio doesn't
handle it properly and gets the silent output.

The fix is to ignore the non-HP sequencer checks.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99681
Signed-off-by: Takashi Iwai 
Signed-off-by: Luis Henriques 
---
 sound/pci/hda/patch_realtek.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1aa3bb74fe06..78d333c4a526 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4269,6 +4269,7 @@ enum {
ALC269_FIXUP_LIFEBOOK,
ALC269_FIXUP_LIFEBOOK_EXTMIC,
ALC269_FIXUP_LIFEBOOK_HP_PIN,
+   ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT,
ALC269_FIXUP_AMIC,
ALC269_FIXUP_DMIC,
ALC269VB_FIXUP_AMIC,
@@ -4422,6 +4423,10 @@ static const struct hda_fixup alc269_fixups[] = {
{ }
},
},
+   [ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT] = {
+   .type = HDA_FIXUP_FUNC,
+   .v.func = alc269_fixup_pincfg_no_hp_to_lineout,
+   },
[ALC269_FIXUP_AMIC] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
@@ -4898,6 +4903,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x104d, 0x9099, "Sony VAIO S13", 
ALC275_FIXUP_SONY_DISABLE_AAMIX),
SND_PCI_QUIRK_VENDOR(0x104d, "Sony VAIO", ALC269_FIXUP_SONY_VAIO),
SND_PCI_QUIRK(0x10cf, 0x1475, "Lifebook", ALC269_FIXUP_LIFEBOOK),
+   SND_PCI_QUIRK(0x10cf, 0x159f, "Lifebook E780", 
ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT),
SND_PCI_QUIRK(0x10cf, 0x15dc, "Lifebook T731", 
ALC269_FIXUP_LIFEBOOK_HP_PIN),
SND_PCI_QUIRK(0x10cf, 0x1757, "Lifebook E752", 
ALC269_FIXUP_LIFEBOOK_HP_PIN),
SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", 
ALC269_FIXUP_LIFEBOOK_EXTMIC),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 109/185] locking,arch,arc: Fold atomic_ops

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Peter Zijlstra 

commit f7d11e93ee97a37da1947b7c4e1794705a6f360c upstream.

Many of the atomic op implementations are the same except for one
instruction; fold the lot into a few CPP macros and reduce LoC.

This also prepares for easy addition of new ops.

Signed-off-by: Peter Zijlstra 
Cc: Linus Torvalds 
Cc: Paul E. McKenney 
Cc: Vineet Gupta 
Link: http://lkml.kernel.org/r/20140508135851.886055...@infradead.org
Signed-off-by: Ingo Molnar 
[ luis: 3.16 prereq for:
  2576c28e3f62 "ARC: add smp barriers around atomics per 
Documentation/atomic_ops.txt"
Signed-off-by: Luis Henriques 
---
 arch/arc/include/asm/atomic.h | 184 +++---
 1 file changed, 63 insertions(+), 121 deletions(-)

diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index 83f03ca6caf6..173f303a868f 100644
--- a/arch/arc/include/asm/atomic.h
+++ b/arch/arc/include/asm/atomic.h
@@ -25,79 +25,36 @@
 
 #define atomic_set(v, i) (((v)->counter) = (i))
 
-static inline void atomic_add(int i, atomic_t *v)
-{
-   unsigned int temp;
-
-   __asm__ __volatile__(
-   "1: llock   %0, [%1]\n"
-   "   add %0, %0, %2  \n"
-   "   scond   %0, [%1]\n"
-   "   bnz 1b  \n"
-   : "="(temp)   /* Early clobber, to prevent reg reuse */
-   : "r"(>counter), "ir"(i)
-   : "cc");
-}
-
-static inline void atomic_sub(int i, atomic_t *v)
-{
-   unsigned int temp;
-
-   __asm__ __volatile__(
-   "1: llock   %0, [%1]\n"
-   "   sub %0, %0, %2  \n"
-   "   scond   %0, [%1]\n"
-   "   bnz 1b  \n"
-   : "="(temp)
-   : "r"(>counter), "ir"(i)
-   : "cc");
-}
-
-/* add and also return the new value */
-static inline int atomic_add_return(int i, atomic_t *v)
-{
-   unsigned int temp;
-
-   __asm__ __volatile__(
-   "1: llock   %0, [%1]\n"
-   "   add %0, %0, %2  \n"
-   "   scond   %0, [%1]\n"
-   "   bnz 1b  \n"
-   : "="(temp)
-   : "r"(>counter), "ir"(i)
-   : "cc");
-
-   return temp;
-}
-
-static inline int atomic_sub_return(int i, atomic_t *v)
-{
-   unsigned int temp;
-
-   __asm__ __volatile__(
-   "1: llock   %0, [%1]\n"
-   "   sub %0, %0, %2  \n"
-   "   scond   %0, [%1]\n"
-   "   bnz 1b  \n"
-   : "="(temp)
-   : "r"(>counter), "ir"(i)
-   : "cc");
-
-   return temp;
-}
-
-static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
-{
-   unsigned int temp;
-
-   __asm__ __volatile__(
-   "1: llock   %0, [%1]\n"
-   "   bic %0, %0, %2  \n"
-   "   scond   %0, [%1]\n"
-   "   bnz 1b  \n"
-   : "="(temp)
-   : "r"(addr), "ir"(mask)
-   : "cc");
+#define ATOMIC_OP(op, c_op, asm_op)\
+static inline void atomic_##op(int i, atomic_t *v) \
+{  \
+   unsigned int temp;  \
+   \
+   __asm__ __volatile__(   \
+   "1: llock   %0, [%1]\n" \
+   "   " #asm_op " %0, %0, %2  \n" \
+   "   scond   %0, [%1]\n" \
+   "   bnz 1b  \n" \
+   : "="(temp)   /* Early clobber, to prevent reg reuse */   \
+   : "r"(>counter), "ir"(i) \
+   : "cc");\
+}  \
+
+#define ATOMIC_OP_RETURN(op, c_op, asm_op) \
+static inline int atomic_##op##_return(int i, atomic_t *v) \
+{  \
+   unsigned int temp;  \
+   \
+   __asm__ __volatile__(   \
+   "1: llock   %0, [%1]\n" \
+   "   " #asm_op " %0, %0, %2  \n" \
+   "   scond   %0, [%1]\n" \
+   "   bnz 1b  \n" \
+   : "="(temp)   \
+   : "r"(>counter), "ir"(i)

[PATCH 3.16.y-ckt 122/185] drm/radeon: SDMA fix hibernation (CI GPU family).

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= 

commit 2ba8d1bb8f6b589037f7db1f01144fc80750e8f7 upstream.

In order for hibernation to reliably work we need to properly turn
off the SDMA block, sadly after numerous attemps i haven't not found
proper sequence for clean and full shutdown. So simply reset both
SDMA block, this makes hibernation works reliably on sea island GPU
family (CI)

Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini

Signed-off-by: Jérôme Glisse 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Luis Henriques 
---
 drivers/gpu/drm/radeon/cik_sdma.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 4208ae639407..f3e0d00a2666 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -266,6 +266,17 @@ static void cik_sdma_gfx_stop(struct radeon_device *rdev)
}
rdev->ring[R600_RING_TYPE_DMA_INDEX].ready = false;
rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX].ready = false;
+
+   /* FIXME use something else than big hammer but after few days can not
+* seem to find good combination so reset SDMA blocks as it seems we
+* do not shut them down properly. This fix hibernation and does not
+* affect suspend to ram.
+*/
+   WREG32(SRBM_SOFT_RESET, SOFT_RESET_SDMA | SOFT_RESET_SDMA1);
+   (void)RREG32(SRBM_SOFT_RESET);
+   udelay(50);
+   WREG32(SRBM_SOFT_RESET, 0);
+   (void)RREG32(SRBM_SOFT_RESET);
 }
 
 /**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 123/185] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Simon Guinot 

commit f522a975a8101895a85354b9c143f41b8248e71a upstream.

The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
380 and 385 SoCs. Since at least one more hardware feature is available
for the Armada XP SoCs then a way to identify them is needed.

This patch introduces a new compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot 
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network 
unit")
Acked-by: Gregory CLEMENT 
Acked-by: Thomas Petazzoni 
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques 
---
 Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt 
b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index 750d577e8083..f5a8ca29aff0 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -1,7 +1,7 @@
 * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
 
 Required properties:
-- compatible: should be "marvell,armada-370-neta".
+- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
 - reg: address and length of the register set for the device.
 - interrupts: interrupt for the device
 - phy: See ethernet.txt file in the same directory.
diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 393d49202f23..4456171c885d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3096,6 +3096,7 @@ static int mvneta_remove(struct platform_device *pdev)
 
 static const struct of_device_id mvneta_match[] = {
{ .compatible = "marvell,armada-370-neta" },
+   { .compatible = "marvell,armada-xp-neta" },
{ }
 };
 MODULE_DEVICE_TABLE(of, mvneta_match);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] oom: Do not invoke oom notifiers on sysrq+f

[Michal Hocko]

On Tue 14-07-15 14:58:55, David Rientjes wrote:
> On Fri, 10 Jul 2015, Michal Hocko wrote:
> 
> > Shrinkers are there to reclaim and prevent from OOM. This API is a gray
> > zone. It looks generic method for the notification yet it allows to
> > prevent from oom killer. I can imagine somebody might abuse this
> > interface to implement OOM killer policies.
> > 
> > Anyway, I think it would be preferable to kill it altogether rather than
> > play with its placing. It will always be a questionable API.
> > 
> 
> Agreed.

In such a case it would be still good to fix the bug fixed by this
patch.

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

[PATCH 3.16.y-ckt 117/185] ALSA: hda - Add headset support to Acer Aspire V5

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Takashi Iwai 

commit 7819717b11346b8a5420b223b46600e394049c66 upstream.

Acer Aspire V5 with ALC282 codec needs the similar quirk like Dell
laptops to support the headset mic.  The headset mic pin is 0x19 and
it's not exposed by BIOS, thus we need to fix the pincfg as well.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96201
Signed-off-by: Takashi Iwai 
Signed-off-by: Luis Henriques 
---
 sound/pci/hda/patch_realtek.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1115e8aed237..1aa3bb74fe06 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4287,6 +4287,7 @@ enum {
ALC269_FIXUP_DELL3_MIC_NO_PRESENCE,
ALC269_FIXUP_HEADSET_MODE,
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC,
+   ALC269_FIXUP_ASPIRE_HEADSET_MIC,
ALC269_FIXUP_ASUS_X101_FUNC,
ALC269_FIXUP_ASUS_X101_VERB,
ALC269_FIXUP_ASUS_X101,
@@ -4539,6 +4540,15 @@ static const struct hda_fixup alc269_fixups[] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc_fixup_headset_mode_no_hp_mic,
},
+   [ALC269_FIXUP_ASPIRE_HEADSET_MIC] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   { 0x19, 0x01a1913c }, /* headset mic w/o jack detect */
+   { }
+   },
+   .chained = true,
+   .chain_id = ALC269_FIXUP_HEADSET_MODE,
+   },
[ALC286_FIXUP_SONY_MIC_NO_PRESENCE] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
@@ -4761,6 +4771,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x029b, "Acer 1810TZ", ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x1025, 0x0349, "Acer AOD260", ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x1025, 0x047c, "Acer AC700", ALC269_FIXUP_ACER_AC700),
+   SND_PCI_QUIRK(0x1025, 0x072d, "Acer Aspire V5-571G", 
ALC269_FIXUP_ASPIRE_HEADSET_MIC),
+   SND_PCI_QUIRK(0x1025, 0x080d, "Acer Aspire V5-122P", 
ALC269_FIXUP_ASPIRE_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x0740, "Acer AO725", 
ALC271_FIXUP_HP_GATE_MIC_JACK),
SND_PCI_QUIRK(0x1025, 0x0742, "Acer AO756", 
ALC271_FIXUP_HP_GATE_MIC_JACK),
SND_PCI_QUIRK_VENDOR(0x1025, "Acer Aspire", ALC271_FIXUP_DMIC),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 119/185] agp/intel: Fix typo in needs_ilk_vtd_wa()

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Chris Wilson 

commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 upstream.

In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against
the ids for the mobile GPU and the mobile host bridge. That latter is
impossible and so likely was just a typo for the desktop GPU device id
(which is also buggy).

Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
Author: Chris Wilson 
Date:   Wed Feb 13 09:31:53 2013 +

drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK

Reported-by: Ting-Wei Lan 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127
References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Luis Henriques 
---
 drivers/char/agp/intel-gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 9a024f899dd4..9a99d0a3ff08 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -585,7 +585,7 @@ static inline int needs_ilk_vtd_wa(void)
/* Query intel_iommu to see if we need the workaround. Presumably that
 * was loaded first.
 */
-   if ((gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_HB ||
+   if ((gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_D_IG ||
 gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_IG) &&
 intel_iommu_gfx_mapped)
return 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/6] locking/pvqspinlock: Allow vCPUs kick-ahead

[Peter Zijlstra]

On Tue, Jul 14, 2015 at 10:13:35PM -0400, Waiman Long wrote:
> Frequent CPU halting (vmexit) and CPU kicking (vmenter) lengthens
> critical section and block forward progress.  This patch implements
> a kick-ahead mechanism where the unlocker will kick the queue head
> vCPUs as well as up to four additional vCPUs next to the queue head
> if they were halted.  The kickings are done after exiting the critical
> section to improve parallelism.
> 
> The amount of kick-ahead allowed depends on the number of vCPUs
> in the VM guest.  This patch, by itself, won't do much as most of
> the kickings are currently done at lock time. Coupled with the next
> patch that defers lock time kicking to unlock time, it should improve
> overall system performance in a busy overcommitted guest.
> 
> Linux kernel builds were run in KVM guest on an 8-socket, 4
> cores/socket Westmere-EX system and a 4-socket, 8 cores/socket
> Haswell-EX system. Both systems are configured to have 32 physical
> CPUs. The kernel build times before and after the patch were:
> 
>   WestmereHaswell
>   Patch   32 vCPUs48 vCPUs32 vCPUs48 vCPUs
>   -   
>   Before patch 3m25.0s10m34.1s 2m02.0s15m35.9s
>   After patch3m27.4s10m32.0s   2m00.8s14m52.5s
> 
> There wasn't too much difference before and after the patch.

That means either the patch isn't worth it, or as you seem to imply its
in the wrong place in this series.

> @@ -224,7 +233,16 @@ static unsigned int pv_lock_hash_bits __read_mostly;
>   */
>  void __init __pv_init_lock_hash(void)
>  {
> - int pv_hash_size = ALIGN(4 * num_possible_cpus(), PV_HE_PER_LINE);
> + int ncpus = num_possible_cpus();
> + int pv_hash_size = ALIGN(4 * ncpus, PV_HE_PER_LINE);
> + int i;
> +
> + /*
> +  * The minimum number of vCPUs required in each kick-ahead level
> +  */
> + static const u8 kick_ahead_threshold[PV_KICK_AHEAD_MAX] = {
> + 4, 8, 16, 32
> + };

You are aware we have ilog2(), right?

> + /*
> +  * Enable the unlock kick ahead mode according to the number of
> +  * vCPUs available.
> +  */
> + for (i = PV_KICK_AHEAD_MAX; i > 0; i--)
> + if (ncpus >= kick_ahead_threshold[i - 1]) {
> + pv_kick_ahead = i;
> + break;
> + }

That's missing { }.

> + if (pv_kick_ahead)
> + pr_info("PV unlock kick ahead level %d enabled\n",
> + pv_kick_ahead);

Idem.

That said, I still really dislike this patch, it again seems a random
bunch of hacks.

You also do not offer any support for any of the magic numbers..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 116/185] clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Damian Eppel 

commit 56a94f13919c0db5958611b388e1581b4852f3c9 upstream.

Whilst testing cpu hotplug events on kernel configured with
DEBUG_PREEMPT and DEBUG_ATOMIC_SLEEP we get following BUG message,
caused by calling request_irq() and free_irq() in the context of
hotplug notification (which is in this case atomic context).

[   40.785859] CPU1: Software reset
[   40.786660] BUG: sleeping function called from invalid context at 
mm/slub.c:1241
[   40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[   40.786678] Preemption disabled at:[<  (null)>]   (null)
[   40.786681]
[   40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
3.19.0-rc4-00024-g7dca860 #36
[   40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   40.786728] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   40.786747] [] (show_stack) from [] 
(dump_stack+0x70/0xbc)
[   40.786767] [] (dump_stack) from [] 
(kmem_cache_alloc+0xd8/0x170)
[   40.786785] [] (kmem_cache_alloc) from [] 
(request_threaded_irq+0x64/0x128)
[   40.786804] [] (request_threaded_irq) from [] 
(exynos4_local_timer_setup+0xc0/0x13c)
[   40.786820] [] (exynos4_local_timer_setup) from [] 
(exynos4_mct_cpu_notify+0x30/0xa8)
[   40.786838] [] (exynos4_mct_cpu_notify) from [] 
(notifier_call_chain+0x44/0x84)
[   40.786857] [] (notifier_call_chain) from [] 
(__cpu_notify+0x28/0x44)
[   40.786873] [] (__cpu_notify) from [] 
(secondary_start_kernel+0xec/0x150)
[   40.786886] [] (secondary_start_kernel) from [<40008764>] 
(0x40008764)

Interrupts cannot be requested/freed in the CPU_STARTING/CPU_DYING
notifications which run on the hotplugged cpu with interrupts and
preemption disabled.

To avoid the issue, request the interrupts for all possible cpus in
the boot code. The interrupts are marked NO_AUTOENABLE to avoid a racy
request_irq/disable_irq() sequence. The flag prevents the
request_irq() code from enabling the interrupt immediately.

The interrupt is then enabled in the CPU_STARTING notifier of the
hotplugged cpu and again disabled with disable_irq_nosync() in the
CPU_DYING notifier.

[ tglx: Massaged changelog to match the patch ]

Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for 
local timer registration")
Reported-by: Krzysztof Kozlowski 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Krzysztof Kozlowski 
Tested-by: Marcin Jabrzyk 
Signed-off-by: Damian Eppel 
Cc: m.szyprow...@samsung.com
Cc: kyungmin.p...@samsung.com
Cc: daniel.lezc...@linaro.org
Cc: kg...@kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1435324984-7328-1-git-send-email-d.ep...@samsung.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Luis Henriques 
---
 drivers/clocksource/exynos_mct.c | 43 
 1 file changed, 30 insertions(+), 13 deletions(-)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 336a60fbabf9..5d1b7f64947c 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -441,15 +441,12 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
exynos4_mct_write(TICK_BASE_CNT, mevt->base + MCT_L_TCNTB_OFFSET);
 
if (mct_int_type == MCT_INT_SPI) {
-   evt->irq = mct_irqs[MCT_L0_IRQ + cpu];
-   if (request_irq(evt->irq, exynos4_mct_tick_isr,
-   IRQF_TIMER | IRQF_NOBALANCING,
-   evt->name, mevt)) {
-   pr_err("exynos-mct: cannot register IRQ %d\n",
-   evt->irq);
+
+   if (evt->irq == -1)
return -EIO;
-   }
-   irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+
+   irq_force_affinity(evt->irq, cpumask_of(cpu));
+   enable_irq(evt->irq);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
@@ -462,10 +459,12 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
 static void exynos4_local_timer_stop(struct clock_event_device *evt)
 {
evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
-   if (mct_int_type == MCT_INT_SPI)
-   free_irq(evt->irq, this_cpu_ptr(_mct_tick));
-   else
+   if (mct_int_type == MCT_INT_SPI) {
+   if (evt->irq != -1)
+   disable_irq_nosync(evt->irq);
+   } else {
disable_percpu_irq(mct_irqs[MCT_L0_IRQ]);
+   }
 }
 
 static int exynos4_mct_cpu_notify(struct notifier_block *self,
@@ -497,7 +496,7 @@ static struct notifier_block exynos4_mct_cpu_nb = {
 
 static void __init exynos4_timer_resources(struct device_node *np, void 
__iomem *base)
 {
-   int err;
+   int err, cpu;
struct mct_clock_event_device *mevt = this_cpu_ptr(_mct_tick);
struct clk 

[PATCH 3.16.y-ckt 111/185] mm: kmemleak: allow safe memory scanning during kmemleak disabling

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Catalin Marinas 

commit c5f3b1a51a591c18c8b33983908e7fdda6ae417e upstream.

The kmemleak scanning thread can run for minutes.  Callbacks like
kmemleak_free() are allowed during this time, the race being taken care
of by the object->lock spinlock.  Such lock also prevents a memory block
from being freed or unmapped while it is being scanned by blocking the
kmemleak_free() -> ...  -> __delete_object() function until the lock is
released in scan_object().

When a kmemleak error occurs (e.g.  it fails to allocate its metadata),
kmemleak_enabled is set and __delete_object() is no longer called on
freed objects.  If kmemleak_scan is running at the same time,
kmemleak_free() no longer waits for the object scanning to complete,
allowing the corresponding memory block to be freed or unmapped (in the
case of vfree()).  This leads to kmemleak_scan potentially triggering a
page fault.

This patch separates the kmemleak_free() enabling/disabling from the
overall kmemleak_enabled nob so that we can defer the disabling of the
object freeing tracking until the scanning thread completed.  The
kmemleak_free_part() is deliberately ignored by this patch since this is
only called during boot before the scanning thread started.

Signed-off-by: Catalin Marinas 
Reported-by: Vignesh Radhakrishnan 
Tested-by: Vignesh Radhakrishnan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Luis Henriques 
---
 mm/kmemleak.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 3cda50c1e394..6691476a66fc 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -193,6 +193,8 @@ static struct kmem_cache *scan_area_cache;
 
 /* set if tracing memory operations is enabled */
 static int kmemleak_enabled;
+/* same as above but only for the kmemleak_free() callback */
+static int kmemleak_free_enabled;
 /* set in the late_initcall if there were no errors */
 static int kmemleak_initialized;
 /* enables or disables early logging of the memory operations */
@@ -940,7 +942,7 @@ void __ref kmemleak_free(const void *ptr)
 {
pr_debug("%s(0x%p)\n", __func__, ptr);
 
-   if (kmemleak_enabled && ptr && !IS_ERR(ptr))
+   if (kmemleak_free_enabled && ptr && !IS_ERR(ptr))
delete_object_full((unsigned long)ptr);
else if (kmemleak_early_log)
log_early(KMEMLEAK_FREE, ptr, 0, 0);
@@ -980,7 +982,7 @@ void __ref kmemleak_free_percpu(const void __percpu *ptr)
 
pr_debug("%s(0x%p)\n", __func__, ptr);
 
-   if (kmemleak_enabled && ptr && !IS_ERR(ptr))
+   if (kmemleak_free_enabled && ptr && !IS_ERR(ptr))
for_each_possible_cpu(cpu)
delete_object_full((unsigned long)per_cpu_ptr(ptr,
  cpu));
@@ -1743,6 +1745,13 @@ static void kmemleak_do_cleanup(struct work_struct *work)
mutex_lock(_mutex);
stop_scan_thread();
 
+   /*
+* Once the scan thread has stopped, it is safe to no longer track
+* object freeing. Ordering of the scan thread stopping and the memory
+* accesses below is guaranteed by the kthread_stop() function.
+*/
+   kmemleak_free_enabled = 0;
+
if (!kmemleak_found_leaks)
__kmemleak_do_cleanup();
else
@@ -1769,6 +1778,8 @@ static void kmemleak_disable(void)
/* check whether it is too early for a kernel thread */
if (kmemleak_initialized)
schedule_work(_work);
+   else
+   kmemleak_free_enabled = 0;
 
pr_info("Kernel memory leak detector disabled\n");
 }
@@ -1833,8 +1844,10 @@ void __init kmemleak_init(void)
if (kmemleak_error) {
local_irq_restore(flags);
return;
-   } else
+   } else {
kmemleak_enabled = 1;
+   kmemleak_free_enabled = 1;
+   }
local_irq_restore(flags);
 
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 121/185] drm/radeon: compute ring fix hibernation (CI GPU family) v2.

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= 

commit 161569deaa03cf3c00ed63352006193f250b0648 upstream.

In order for hibernation to reliably work we need to cleanup more
thoroughly the compute ring. Hibernation is different from suspend
resume as when we resume from hibernation the hardware is first
fully initialize by regular kernel then freeze callback happens
(which correspond to a suspend inside the radeon kernel driver)
and turn off each of the block. It turns out we were not cleanly
shutting down the compute ring. This patch fix that.

Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini

Changed since v1:
  - Factor the ring stop logic into a function taking ring as arg.

Signed-off-by: Jérôme Glisse 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Luis Henriques 
---
 drivers/gpu/drm/radeon/cik.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 0cf54a4b83bd..6bdaa9500f78 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4245,6 +4245,31 @@ void cik_compute_set_wptr(struct radeon_device *rdev,
WDOORBELL32(ring->doorbell_index, ring->wptr);
 }
 
+static void cik_compute_stop(struct radeon_device *rdev,
+struct radeon_ring *ring)
+{
+   u32 j, tmp;
+
+   cik_srbm_select(rdev, ring->me, ring->pipe, ring->queue, 0);
+   /* Disable wptr polling. */
+   tmp = RREG32(CP_PQ_WPTR_POLL_CNTL);
+   tmp &= ~WPTR_POLL_EN;
+   WREG32(CP_PQ_WPTR_POLL_CNTL, tmp);
+   /* Disable HQD. */
+   if (RREG32(CP_HQD_ACTIVE) & 1) {
+   WREG32(CP_HQD_DEQUEUE_REQUEST, 1);
+   for (j = 0; j < rdev->usec_timeout; j++) {
+   if (!(RREG32(CP_HQD_ACTIVE) & 1))
+   break;
+   udelay(1);
+   }
+   WREG32(CP_HQD_DEQUEUE_REQUEST, 0);
+   WREG32(CP_HQD_PQ_RPTR, 0);
+   WREG32(CP_HQD_PQ_WPTR, 0);
+   }
+   cik_srbm_select(rdev, 0, 0, 0, 0);
+}
+
 /**
  * cik_cp_compute_enable - enable/disable the compute CP MEs
  *
@@ -4258,6 +4283,15 @@ static void cik_cp_compute_enable(struct radeon_device 
*rdev, bool enable)
if (enable)
WREG32(CP_MEC_CNTL, 0);
else {
+   /*
+* To make hibernation reliable we need to clear compute ring
+* configuration before halting the compute ring.
+*/
+   mutex_lock(>srbm_mutex);
+   cik_compute_stop(rdev,>ring[CAYMAN_RING_TYPE_CP1_INDEX]);
+   cik_compute_stop(rdev,>ring[CAYMAN_RING_TYPE_CP2_INDEX]);
+   mutex_unlock(>srbm_mutex);
+
WREG32(CP_MEC_CNTL, (MEC_ME1_HALT | MEC_ME2_HALT));
rdev->ring[CAYMAN_RING_TYPE_CP1_INDEX].ready = false;
rdev->ring[CAYMAN_RING_TYPE_CP2_INDEX].ready = false;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.16.y-ckt 120/185] drm/i915: fix backlight after resume on 855gm

[Luis Henriques]

3.16.7-ckt15 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jani Nikula 

commit 2059ac3b1304cb6a82f9d90762dea9f556831627 upstream.

Some 855gm models (at least ThinkPad X40) regressed because of

commit b0cd324faed23d10d66ba6ade66579c681feef6f
Author: Jani Nikula 
Date:   Wed Nov 12 16:25:43 2014 +0200

drm/i915: don't save/restore backlight hist ctl registers

which tried to make our driver more robust by not blindly saving and
restoring registers, but it failed to take into account

commit 0eb96d6ed38430b72897adde58f5477a6b71757a
Author: Jesse Barnes 
Date:   Wed Oct 14 12:33:41 2009 -0700

drm/i915: save/restore BLC histogram control reg across suspend/resume

Fix the regression by enabling hist ctl on gen2.

v2: Improved the comment.

v3: Improved the comment, again.

Reported-and-tested-by: Philipp Gesang 
References: http://mid.gmane.org/20150623222648.GD12335@acheron
Fixes: b0cd324faed2 ("drm/i915: don't save/restore backlight hist ctl 
registers")
Cc: Ville Syrjälä 
Acked-by: Chris Wilson 
Signed-off-by: Jani Nikula 
Signed-off-by: Luis Henriques 
---
 drivers/gpu/drm/i915/i915_reg.h| 1 +
 drivers/gpu/drm/i915/intel_panel.c | 8 
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dda970cb01c1..fa0ec5aed9ed 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2898,6 +2898,7 @@ enum punit_power_well {
 #define   BLM_POLARITY_PNV (1 << 0) /* pnv only */
 
 #define BLC_HIST_CTL   (dev_priv->info.display_mmio_offset + 0x61260)
+#define  BLM_HISTOGRAM_ENABLE  (1 << 31)
 
 /* New registers for PCH-split platforms. Safe where new bits show up, the
  * register layout machtes with gen4 BLC_PWM_CTL[12]. */
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 59b294c5fe41..a25816cb3df1 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -774,6 +774,14 @@ static void i9xx_enable_backlight(struct intel_connector 
*connector)
 
/* XXX: combine this into above write? */
intel_panel_actually_set_backlight(connector, panel->backlight.level);
+
+   /*
+* Needed to enable backlight on some 855gm models. BLC_HIST_CTL is
+* 855gm only, but checking for gen2 is safe, as 855gm is the only gen2
+* that has backlight.
+*/
+   if (IS_GEN2(dev))
+   I915_WRITE(BLC_HIST_CTL, BLM_HISTOGRAM_ENABLE);
 }
 
 static void i965_enable_backlight(struct intel_connector *connector)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/