Commit Graph

495584 Commits

Author SHA1 Message Date
Yinghai Lu 2e5e804a83 parisc/PCI: Clip bridge windows to fit in upstream windows
Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: "James E.J. Bottomley" <jejb@parisc-linux.org>
CC: Helge Deller <deller@gmx.de>
CC: linux-parisc@vger.kernel.org
2015-01-16 10:04:43 -06:00
Yinghai Lu 4e348ba2dd mn10300/PCI: Clip bridge windows to fit in upstream windows
Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: David Howells <dhowells@redhat.com>
CC: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
CC: linux-am33-list@redhat.com
2015-01-16 10:04:43 -06:00
Yinghai Lu 576e4385ff microblaze/PCI: Clip bridge windows to fit in upstream windows
Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Michal Simek <monstr@monstr.eu>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Sebastian Ott <sebott@linux.vnet.ibm.com>
2015-01-16 10:04:43 -06:00
Yinghai Lu ce821ef033 ia64/PCI: Clip bridge windows to fit in upstream windows
Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Tony Luck <tony.luck@intel.com>
CC: Fenghua Yu <fenghua.yu@intel.com>
CC: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
CC: linux-ia64@vger.kernel.org
2015-01-16 10:04:42 -06:00
Yinghai Lu b0c568de32 frv/PCI: Clip bridge windows to fit in upstream windows
Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: David Howells <dhowells@redhat.com>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
2015-01-16 10:04:42 -06:00
Yinghai Lu b3e118224c alpha/PCI: Clip bridge windows to fit in upstream windows
Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Richard Henderson <rth@twiddle.net>
CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
CC: Matt Turner <mattst88@gmail.com>
CC: linux-alpha@vger.kernel.org
2015-01-16 10:04:42 -06:00
Yinghai Lu 851b093692 x86/PCI: Clip bridge windows to fit in upstream windows
Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Tested-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@redhat.com>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: x86@kernel.org
CC: stable@vger.kernel.org	# v3.16+
2015-01-16 10:04:42 -06:00
Yinghai Lu 8505e729a2 PCI: Add pci_claim_bridge_resource() to clip window if necessary
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window.  This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.

This is for scenarios like this:

  pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
  pci 0000:00:01.0:   bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
  pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]

The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible.  We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].

Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch.  That is a problem because Linux doesn't
always assign things optimally.  For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.

Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration.  Of
course, it's possible that devices below 00:01.0 will no longer fit.  If
that's the case, we'll have to reassign things.  But that's a separate
problem.

[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.16+
2015-01-16 10:04:42 -06:00
Yinghai Lu 0f7e7aee2f PCI: Add pci_bus_clip_resource() to clip to fit upstream window
Add pci_bus_clip_resource().  If a PCI-PCI bridge window overlaps an
upstream bridge window but is not completely contained by it, this clips
the downstream window so it fits inside the upstream one.

No functional change (this adds the function but no callers).

[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.16+
2015-01-16 10:04:42 -06:00
Yinghai Lu 3f2f4dc456 PCI: Pass bridge device, not bus, when updating bridge windows
pci_setup_bridge_io(), pci_setup_bridge_mmio(), and
pci_setup_bridge_mmio_pref() program the windows of PCI-PCI bridges.
Previously they accepted a pointer to the pci_bus of the secondary bus,
then looked up the bridge leading to that bus.  Pass the bridge directly,
which will make it more convenient for future callers.

No functional change.

[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.16+
2015-01-16 10:04:42 -06:00
Alex Williamson c3e59ee4e7 PCI: Mark Atheros AR93xx to avoid bus reset
Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets.  I've also been able to
confirm this behavior on multiple systems.  The device never returns from
reset and attempts to access config space of the device after reset result
in hangs.  Blacklist bus reset for the device to avoid this issue.

[bhelgaas: This regression appeared in v3.14.  Andreas bisected it to
425c1b223d ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.]

[bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Reported-by: Andreas Hartmann <andihartmann@freenet.de>
Tested-by: Andreas Hartmann <andihartmann@freenet.de>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.14+
2015-01-16 10:04:38 -06:00
Alex Williamson f331a859e0 PCI: Add flag for devices where we can't use bus reset
Enable a mechanism for devices to quirk that they do not behave when
doing a PCI bus reset.  We require a modest level of spec compliant
behavior in order to do a reset, for instance the device should come
out of reset without throwing errors and PCI config space should be
accessible after reset.  This is too much to ask for some devices.

Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.14+
2015-01-16 10:04:38 -06:00
Catalin Marinas 0145058c3d arm64: partially revert "ARM: 8167/1: extend the reserved memory for initrd to be page aligned"
This patch partially reverts commit 421520ba98
(only the arm64 part). There is no guarantee that the boot-loader places other
images like dtb in a different page than initrd start/end, especially when the
kernel is built with 64KB pages. When this happens, such pages must not be
freed. The free_reserved_area() already takes care of rounding up "start" and
rounding down "end" to avoid freeing partially used pages.

Cc: <stable@vger.kernel.org> # 3.17+
Reported-by: Peter Maydell <Peter.Maydell@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-01-16 13:57:33 +00:00
Kan Liang 33636732dc perf/x86/intel: Fix bug for "cycles:p" and "cycles:pp" on SLM
cycles:p and cycles:pp do not work on SLM since commit:

   86a04461a9 ("perf/x86: Revamp PEBS event selection")

UOPS_RETIRED.ALL is not a PEBS capable event, so it should not be used
to count cycle number.

Actually SLM calls intel_pebs_aliases_core2() which uses INST_RETIRED.ANY_P
to count the number of cycles. It's a PEBS capable event. But inv and
cmask must be set to count cycles.

Considering SLM allows all events as PEBS with no flags, only
INST_RETIRED.ANY_P, inv=1, cmask=16 needs to handled specially.

Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1421084541-31639-1-git-send-email-kan.liang@intel.com
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-01-16 09:06:59 +01:00
Stephane Eranian 433678bdc6 perf/rapl: Fix sysfs_show() initialization for RAPL PMU
This patch fixes a problem with the initialization of the
sysfs_show() routine for the RAPL PMU.

The current code was wrongly relying on the EVENT_ATTR_STR()
macro which uses the events_sysfs_show() function in the x86
PMU code. That function itself was relying on the x86_pmu data
structure. Yet RAPL and the core PMU (x86_pmu) have nothing to
do with each other. They should therefore not interact with
each other.

The x86_pmu structure is initialized at boot time based on
the host CPU model. When the host CPU is not supported, the
x86_pmu remains uninitialized and some of the callbacks it
contains are NULL.

The false dependency with x86_pmu could potentially cause crashes
in case the x86_pmu is not initialized while the RAPL PMU is. This
may, for instance, be the case in virtualized environments.

This patch fixes the problem by using a private sysfs_show()
routine for exporting the RAPL PMU events.

Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20150113225953.GA21525@thinkpad
Cc: vincent.weaver@maine.edu
Cc: jolsa@redhat.com
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-01-16 09:06:58 +01:00
Eric Dumazet ac64da0b83 net: rps: fix cpu unplug
softnet_data.input_pkt_queue is protected by a spinlock that
we must hold when transferring packets from victim queue to an active
one. This is because other cpus could still be trying to enqueue packets
into victim queue.

A second problem is that when we transfert the NAPI poll_list from
victim to current cpu, we absolutely need to special case the percpu
backlog, because we do not want to add complex locking to protect
process_queue : Only owner cpu is allowed to manipulate it, unless cpu
is offline.

Based on initial patch from Prasad Sodagudi & Subash Abhinov
Kasiviswanathan.

This version is better because we do not slow down packet processing,
only make migration safer.

Reported-by: Prasad Sodagudi <psodagud@codeaurora.org>
Reported-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16 01:02:42 -05:00
David S. Miller 57d737c5e2 Merge branch 'davinci_emac'
Tony Lindgren says:

====================
Fixes for davinci_emac

Here's a repost of the fixes for davinci_emac with patches
updated for comments and acks collected.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16 01:00:17 -05:00
Tony Lindgren de3900833e net: davinci_emac: Add support for emac on dm816x
On dm816x we have two emac controllers with separate memory
areas.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16 01:00:03 -05:00
Tony Lindgren a1594321a9 net: davinci_emac: Fix ioremap for devices with MDIO within the EMAC address space
Some devices like dm816x have the MDIO registers within the first EMAC
instance address space. Let's fix the issue by allowing to pass an
optional second IO range for the EMAC control register area.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16 01:00:03 -05:00
Tony Lindgren 1d82ffa6ba net: davinci_emac: Fix incomplete code for getting the phy from device tree
Looks like the phy_id is never set up beyond getting the phandle.
Note that we can remove the ifdef for phy_node as there is a stub
for of_phy_connec() if CONFIG_OF is not set.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16 01:00:03 -05:00
Tony Lindgren 0f5372731d net: davinci_emac: Free clock after checking the frequency
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16 01:00:03 -05:00
Tony Lindgren b5133e7a98 net: davinci_emac: Fix runtime pm calls for davinci_emac
Commit 3ba9738134 ("net: ethernet: davinci_emac: add pm_runtime support")
added support for runtime PM, but it causes issues on omap3 related devices
that actually gate the clocks:

Unhandled fault: external abort on non-linefetch (0x1008)
...
[<c04160f0>] (emac_dev_getnetstats) from [<c04d6a3c>] (dev_get_stats+0x78/0xc8)
[<c04d6a3c>] (dev_get_stats) from [<c04e9ccc>] (rtnl_fill_ifinfo+0x3b8/0x938)
[<c04e9ccc>] (rtnl_fill_ifinfo) from [<c04eade4>] (rtmsg_ifinfo+0x68/0xd8)
[<c04eade4>] (rtmsg_ifinfo) from [<c04dd35c>] (register_netdevice+0x3a0/0x4ec)
[<c04dd35c>] (register_netdevice) from [<c04dd4bc>] (register_netdev+0x14/0x24)
[<c04dd4bc>] (register_netdev) from [<c041755c>] (davinci_emac_probe+0x408/0x5c8)
[<c041755c>] (davinci_emac_probe) from [<c0396d78>] (platform_drv_probe+0x48/0xa4)

Let's fix it by moving the pm_runtime_get() call earlier, and also add it to
the emac_dev_getnetstats(). Also note that we want to use pm_runtime_get_sync()
as we don't want to have deferred_resume happen. And let's also check the
return value for pm_runtime_get_sync() as noted by Felipe Balbi <balbi@ti.com>.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Acked-by: Mark A. Greer <mgreer@animalcreek.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16 01:00:03 -05:00
Tony Lindgren cd2d6d33e2 net: davinci_emac: Fix hangs with interrupts
On davinci_emac, we have pulse interrupts. This means that we need to
clear the EOI bits when disabling interrupts as otherwise the interrupts
keep happening. And we also need to not clear the EOI bits again when
enabling the interrupts as otherwise we will get tons of:

unexpected IRQ trap at vector 00

These errors almost certainly mean that the omap-intc.c is signaling
a spurious interrupt with the reserved irq 127 as we've seen earlier
on omap3.

Let's fix the issue by clearing the EOI bits when disabling the
interrupts. Let's also keep the comment for "Rx Threshold and Misc
interrupts are not enabled" for both enable and disable so people
are aware of this when potentially adding more support.

Note that eventually we should handle the RX and TX interrupts
separately like cpsw is now doing. However, so far I have not seen
any issues with this based on my testing, so it seems to behave a
little different compared to the cpsw that had a similar issue.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16 01:00:03 -05:00
Linus Torvalds cb59670870 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse
Pull fuse fixes from Miklos Szeredi:
 "This fixes a regression in the latest fuse update plus a fix for a
  rather theoretical memory ordering issue"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
  fuse: add memory barrier to INIT
  fuse: fix LOOKUP vs INIT compat handling
2015-01-16 14:58:16 +13:00
Linus Torvalds 0b6212e0a4 fbdev fixes for 3.19
* broadsheetfb: fix memory leak
 * simplefb: fix build failure on sparc
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJUt6JeAAoJEPo9qoy8lh71u2sQAI5/erMGJ4U3sxQ09B/ewQra
 dVgNmPVv417GViUIaJgEGx6g9gqqZcx0iu+tmGrKgSPYf5s/ldHgIWx29drUm7pO
 NnUzxK1uj7+XrjCXVESNytHAH/yNgGQv8N3V9KtM+APzm0yUS5FCvCi72JAQ2Mwh
 dqroNbv22rGqrrdgBaAgDb8+AvkgliONKHZi0EZ6xOxfGVkwLBaolOfPWdknGpW6
 BIk6q0Fl6V0Wt4s7w2IgM3G6s2FIi/o5nuNaUtjzttJO6sBh+muILJUWJ1AtIEaN
 rTfFZeRbtl2jr81Ne7rCTL+wc+GPkEWiSA1jmmZrL74SIrZNowVktEIvvegDBk97
 t+CnF7bvkfbbJWzgNavzGbWvv4hF6pbqRvJhKW2ASIKPxYKUP55roXVHfdbV83e1
 MfM8aHOAaHdZyR/xdhhAFkhCaAfjt9yh500SQUkrRPXqWHFWAj4fMme4Oijnl+XC
 QA473/ApBVlH4TxA8GXRJLz6h+qZRY6vDIC4jHg0uu5XrS5VVv+zBw09fPf4TnVV
 uEajRcXD9AwwV64IFYInG8iATyZalwDHjvHm8e8OkTGgJLbZ6hGi5bGX7JBnLg8Q
 My5GC5vaX+xemwGxVYJoLtt/fvsESgd71ZaB3Q2henGZm17kyHuACR6m9/mTwQ1D
 84JW6EAk5MuDKa+Sqfjv
 =cau9
 -----END PGP SIGNATURE-----

Merge tag 'fbdev-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux

Pull fbdev fixes from Tomi Valkeinen:
 - broadsheetfb: fix memory leak
 - simplefb: fix build failure on sparc

* tag 'fbdev-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
  fbdev/broadsheetfb: fix memory leak
  simplefb: Fix build failure on Sparc
2015-01-16 14:55:47 +13:00
Linus Torvalds 7b552bc12f MMC host:
- sdhci: Fix regulator regression for Qualcomm and Nvidia boards
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJUt36dAAoJEP4mhCVzWIwpaEkQALkX7G/WM9pGfs5iYpCW35KM
 A+2y9S1XZpsP1gGfVdiYXQ4el/7zuttyZmIodpDahgSx/VFYjNaXkz3UwL/o0hwT
 LlQCbVCzXTKvjrP6QNmZ6eCg3Ijqnat3qqeHarLdcUWfGw3j708KhaoB8iEBYUOW
 JVbKZc2yHQMcaKxHViQLOjNKTWutQdJTfSCiQFXoVK8R74ON4VrgapcuzbgTBxLU
 nYEu6JCVLUfneRGdXl7bqBfj8+f32lo3KJ1tizMw9eZFa4tMn3wcxtMOSJ55pVYo
 3E7EpIHwP9QztqN99I4w1acN8LuXxxJ3Y2IDd01HwrGMl2cCnR/eQnkASZwBksTq
 Gpem8F9Wl/2GObTZ7GqP+y4+4h1FZnVHz1haeuLqij8XJOF4yCLxgUBBWq2dtSRr
 CR2vB3JJ3TpZEBWQgpfHWdTJ6q7qnNGwtnOiqhlKLdHxYfIWx1+/tZRNqH9zizA9
 6mn+WpHn9woNljti0xWc89GKVC/Y8qei4B+ca+6/cb7UizdT1DQRJo84VgXihtTk
 tgbB4wshyRLGe5oPU4NVT6IsU9UzCdCU7vMtIWQjjyqM+g7YHyIh9Xm0YeZR1oo7
 43L5waQK1r3812JBDHe4nTrq7czbdavdpKVn8fvSmialH1yVGHCSm0J86QoYku36
 VIYJPUrjbmt8UkiG2wq0
 =yFv9
 -----END PGP SIGNATURE-----

Merge tag 'mmc-v3.19-4' of git://git.linaro.org/people/ulf.hansson/mmc

Pull MMC bugfix from Ulf Hansson:
 "Fix sdhci regulator regression for Qualcomm and Nvidia boards"

* tag 'mmc-v3.19-4' of git://git.linaro.org/people/ulf.hansson/mmc:
  mmc: sdhci: Set SDHCI_POWER_ON with external vmmc
2015-01-16 14:53:07 +13:00
Linus Torvalds f8cb3954a2 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k
Pull m68k fixlet from Geert Uytterhoeven.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
  m68k: Wire up execveat
2015-01-16 14:29:21 +13:00
Linus Torvalds 3fa116e8bd A few powerpc fixes.
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJUt10CAAoJEFHr6jzI4aWA4tEP/jTOd19YAdbDwVobp2KbjOGF
 fJSMBBP7w6AWYBaq+3dHR9hOtdeJie/1enqIgw2hdds6tPXtdXKBMlrluR3WwIT7
 WSEJxHITTbct3U4jPy0IsIULZH+6PNLQECGmOQ7Hn9ihqt0c6L4wPtmQpOOLqs22
 w+3zkomWiXfkNM/Y16QkXG5qc7lXDbKpeQkiTTSGevGOf2iOIbKXKsCvQk3qd+G4
 Lo/UmXUIWj7WWi/juBRgjISxGdwL0kggCs2kavytVb4+E4f7ET96xc0rxMLarS41
 MLMfkWMSZzsLC7Hw+habG1IiqKOD/yB1xBP1emXkh/pQP8R/ypamtYZ56UAhqD/u
 V44ho5jVNGV8LFlnNqUhO38tFNKavZ8iEO6VaVvgERZK+RyimayAWaf6ZZdxdU+V
 2vRazINnNGRFFMBS38hnFaorB9ytaRSCFcmaVkNflGQsulsHcstrWf5LhgireLmf
 U/B8oGUWwrJ+PAeM1SUHsUv7XcCApsmq+0DQU9/kiihwhX2V7jVj/dZq6mdKuiZs
 L9xYV8Xk/RlxuR112CWbZ+IUymfGWujcw9IRpV4uLLjYVHI9WVvJ1H8eBUGaS34w
 whh4yD+g5AVhrsOmAMpmLLJONzLMoCcKfuGN+A0WMW5V38WSpZpmFxR25sWZq2bK
 gjnVXo6gIwO6CuHwMDeQ
 =9ZIN
 -----END PGP SIGNATURE-----

Merge tag 'powerpc-3.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux

Pull powerpc fixes from Michael Ellerman:
 "A few powerpc fixes"

* tag 'powerpc-3.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux:
  powerpc: Work around gcc bug in current_thread_info()
  cxl: Fix issues when unmapping contexts
  powernv: Fix OPAL tracepoint code
2015-01-16 14:28:01 +13:00
Willem de Bruijn f812116b17 ip: zero sockaddr returned on error queue
The sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That
structure is defined and allocated on the stack as

    struct {
            struct sock_extended_err ee;
            struct sockaddr_in(6)    offender;
    } errhdr;

The second part is only initialized for certain SO_EE_ORIGIN values.
Always initialize it completely.

An MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that
would return uninitialized bytes.

Signed-off-by: Willem de Bruijn <willemb@google.com>

----

Also verified that there is no padding between errhdr.ee and
errhdr.offender that could leak additional kernel data.
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15 19:41:16 -05:00
David S. Miller 4315ef8d8b linux-can-fixes-for-3.19-20150115
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABCAAGBQJUt+OgAAoJECte4hHFiupUcckP/jVRKceArdqteY9YSL4XI7Xl
 CuL3zNDRtl9xhtGy8ZXONOvuQ4aRrTO4RTWtnCveDE1Gft573biG8RFiHLQClVAY
 z3u0cEi47Tx4vUW5ghVkVPxDp+5FKUQ+iOr3ab59aaMZdMds0vhAkR8sdLuQ8gZy
 nRLdH/FTDkbwAGJl+gdDElitZ/XdNcU0sfRMGIbi0l5xgjaDmFepi9H8EWHpnlbe
 z938d1bpsjRWJs3O8qm3ZoBDo1pRywVMDYDA0wtVPHViiCDclhaAhmR8Q6qt22Tx
 0WNUKQhULPxSwtdDHYZEoTOJlFxqst7umUbl46fDWaq/+7GSKvplkwP3j2pyzRU9
 8F8LeVCZqfIKYvfbD+PhGXjD8azg0/XXU64wUxCuED3BrCm2nDQqqycnWlyG5Iax
 /qkQgjj3o3xOYPmjOf2RkfwLSRIG00h9gT7B0KkQLjSmywzMF16WSiqR8xt8RtzA
 9kcsoEFxz8I+qyY0ovo2Bj8IBLhrM0NRbrRCUJuxtt6kKhTZdZOk3/pPUA2Tuh9a
 kHdhKQeqFGKCqCM4UOrKKpyNd1quYOoQ9CtzuMMDvY8cZEabcCZnOoT4SFouoPip
 TrOPgLtrT7jRsgN1/WiNr0Tc/oS3MYzLw4r2ja6yJ+KFaXG1N+p2n9cwYOTQugku
 ZJEACpRWrRQ+J0qBNCid
 =9sbv
 -----END PGP SIGNATURE-----

Merge tag 'linux-can-fixes-for-3.19-20150115' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can

Marc Kleine-Budde says:

====================
pull-request: can 2015-01-15

this is a pull request of 8 patches.

Ahmed S. Darwish contributes 4 fixes for the kvaser_usb driver. The two patches
by Oliver Hartkopp mark the m_can driver as non-ISO, as the CANFD standard was
updated. Roger Quadros's patch for the c_can driver fixes the register access
during RAMINIT. And one patch by my, which updates the MAINTAINERS file, as we
moved the git repos to the kernel.org infrastructure.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15 19:38:49 -05:00
Or Gerlitz 5eff6dadb9 net/mlx4: Don't disable vxlan offloads under DMFS-A0 optimized steering
Except for VXLAN steering rules, all offloads should work as they were
under plain DMFS mode. Fix that by enabling all the offloads under
DMFS-A0 mode, except for VXLAN steering rules.

Fixes: d57febe1a4 "net/mlx4: Add A0 hybrid steering"
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15 19:35:30 -05:00
David S. Miller aaef66b837 Just two fixes - one for an uninialized variable and
one for a deadlock in regulatory processing.
 -----BEGIN PGP SIGNATURE-----
 
 iQIcBAABCAAGBQJUt7Z6AAoJEDBSmw7B7bqrgxoQALEEWcIJ1wmu+M7ijdiXLiUM
 vRNuxGENwIgfdmoTs6R7pgKhEYFzePWccjHOzt9cQB5efdRzDjrxj2fDrPf4o5JB
 7of2uHGoaD2RI2H+pJS1URT8igmxDJii+bOEzHn/WL730Hgr2J2iuJizxZ2lzsVM
 VKkiwOykV3kfN5MGsj7yvJQXR32DlGfmiT86+3bjNhE8hgU38NgE0TeUUnyF0AS9
 jLV5mpJfkLmZyZmnvszV5tiqQQmQAdHImI+vbHuhzNUUAn6RLswxbWBzUrLXpXqu
 5KBR2P/6TU4X89NcYGm+JhTI9PghsMbh1zDuqDQ9gq8j0mrV7Kzh1K6LdYoVpfXf
 s42gHe32+Mh0l6LRTlsjftMxJbFla7I6madPcVTqJCV2y1LocD1BseJ+qX5bngU1
 lBSSbzE9MlAl5gyHVDh1CAV+8FM0CP8Ff3WtAyr8XtDxfAUwmo3xBqmL8pvLq6nh
 49kDqDVOzC5KzASYIjqBwmRMcqW2AnaNQG64iIOzM3ure/l5trncPHHPsMkxgwu+
 dDgEXwjWhJNaxWt7fcTSZndATLCRvkeb6ZeRoqmY6A2GJgzpUIhm6HETXc9BNGbg
 3J56176xx04LYg6U5+vMiU5A+gFjlrUknQ3MGXF0KPgw0MvtSyempobV68Lpul4r
 6DviuT9NiRqxloaBimyx
 =bMKg
 -----END PGP SIGNATURE-----

Merge tag 'mac80211-for-davem-2015-01-15' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211

Just two fixes - one for an uninialized variable and
one for a deadlock in regulatory processing.

Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15 19:28:36 -05:00
Byungho An f7d855566f net: sxgbe: Fix waring for double kfree()
This patch fixes double kfree() calls at init_rx_ring() because
it causes static checker warning.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Byungho An <bh74.an@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15 19:01:10 -05:00
Girish K.S 1c1832c7cd net: sxgbe: Fix NULL dereferece when using DT
When the MAC address is provided in the device tree file, the
condition is true and kernel crashes due to NULL dereference.

Signed-off-by: Girish K.S <ks.giri@samsung.com>
Signed-off-by: Byungho An <bh74.an@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15 19:01:10 -05:00
Jens Axboe 6222d1721d NVMe: cq_vector should be signed
This was inadvertently dropped from an earlier commit, otherwise
the check against cq_vector == -1 to prevent double free doesn't
make any sense.

Fixes: 2b25d98179
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-01-15 15:19:10 -07:00
Geert Uytterhoeven 01fbd3f55c sh_eth: Fix addition of .trscer_err_mask to wrong SoC data
commit b284fbe3b3 ("sh_eth: Fix access to TRSCER register") wanted
to add a .trscer_err_mask value to the R-Car Gen2 family-specific data
structure (r8a779x_data), but it was accidentally added to the
SH7724-specific data structure (sh7724_data).

Presumably this happened due to a patch conflict with commit
d407bc0203 ("sh-eth: Set fdr_value of R-Car SoCs"), which added
another field at the same position.

Move the field setting to fix this.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: b284fbe3b3 ("sh_eth: Fix access to TRSCER register")
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15 14:09:37 -05:00
Mugunthan V N 9f6bd8fa58 drivers: net: cpsw: fix cpsw hung with add vlan using vconfig
while adding vlan in dual EMAC mode, only specific ports should be
subscribed for the vlan, else it will lead to switching mode and
if both ports connected to same switch cpsw will hung as it creates
a network loop. Fixing this by adding only specific ports in case
of dual EMAC.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15 13:57:07 -05:00
Felipe Balbi 8c6067355f arm: boot: dts: dra7: enable dwc3 suspend PHY quirk
Whenever Suspend PHY bit is set on DRA7x devices,
USB will not work due to Set EP Configuration command
always failing.

This was only found after a recent commit 2164a47 (usb:
dwc3: set SUSPHY bit for all cores, which will be merged
for v3.19) added a missing *required* step to dwc3
initialization. Synopsys Databook requires that we enable
Suspend PHY bit after initialization but that, unfortunately,
breaks DRA7x.

Note that the same regression was already patched for AM437x.

Reported-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-01-15 10:34:17 -08:00
Hans Holmberg 7b8792bbdf gpiolib: of: Correct error handling in of_get_named_gpiod_flags
of_get_named_gpiod_flags fails with -EPROBE_DEFER in cases
where the gpio chip is available and the GPIO translation fails.

This causes drivers to be re-probed erroneusly, and hides the
real problem(i.e. the GPIO number being out of range).

Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Hans Holmberg <hans.holmberg@intel.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-15 18:31:47 +01:00
Johan Hovold ebbeba120a gpio: sysfs: fix gpio attribute-creation race
Fix attribute-creation race with userspace by using the default group
to create also the contingent gpio device attributes.

Fixes: d8f388d8dc ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-15 17:20:56 +01:00
Johan Hovold 0915e6feb3 gpio: sysfs: fix gpio device-attribute leak
The gpio device attributes were never destroyed when the gpio was
unexported (or on export failures).

Use device_create_with_groups() to create the default device attributes
of the gpio class device. Note that this also fixes the
attribute-creation race with userspace for these attributes.

Remove contingent attributes in export error path and on unexport.

Fixes: d8f388d8dc ("gpio: sysfs interface")
Cc: stable <stable@vger.kernel.org>	# v2.6.27+
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-15 17:20:15 +01:00
Johan Hovold 121b6a7995 gpio: sysfs: fix gpio-chip device-attribute leak
The gpio-chip device attributes were never destroyed when the device was
removed.

Fix by using device_create_with_groups() to create the device attributes
of the chip class device.

Note that this also fixes the attribute-creation race with userspace.

Fixes: d8f388d8dc ("gpio: sysfs interface")
Cc: stable <stable@vger.kernel.org>	# v2.6.27+
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-15 17:19:45 +01:00
Alex Deucher d8a74e1869 drm/radeon: use rv515_ring_start on r5xx
This was accidently lost in 76a0df859d.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2015-01-15 11:11:02 -05:00
Ahmed S. Darwish a58518ccf3 can: kvaser_usb: Don't dereference skb after a netif_rx()
We should not touch the packet after a netif_rx: it might
get freed behind our back.

Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-15 16:58:02 +01:00
Ahmed S. Darwish 5e7e6e0c9b can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels
Recent Leaf firmware versions (>= 3.1.557) do not allow to send
commands for non-existing channels.  If a command is sent for a
non-existing channel, the firmware crashes.

Reported-by: Christopher Storah <Christopher.Storah@invetech.com.au>
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-15 16:58:01 +01:00
Ahmed S. Darwish 889b77f7fd can: kvaser_usb: Reset all URB tx contexts upon channel close
Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in very high frequency (*), closing the CAN channel while
all the transmissions are on (#), opening the device again (@),
then sending a small number of packets would make the driver
enter an almost infinite loop of:

[....]
[15959.853988] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853990] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853991] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853993] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853994] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853995] kvaser_usb 4-3:1.0 can0: cannot find free context
[....]

_dragging the whole system down_ in the process due to the
excessive logging output.

Initially, this has caused random panics in the kernel due to a
buggy error recovery path.  That got fixed in an earlier commit.(%)
This patch aims at solving the root cause. -->

16 tx URBs and contexts are allocated per CAN channel per USB
device. Such URBs are protected by:

a) A simple atomic counter, up to a value of MAX_TX_URBS (16)
b) A flag in each URB context, stating if it's free
c) The fact that ndo_start_xmit calls are themselves protected
   by the networking layers higher above

After grabbing one of the tx URBs, if the driver noticed that all
of them are now taken, it stops the netif transmission queue.
Such queue is worken up again only if an acknowedgment was received
from the firmware on one of our earlier-sent frames.

Meanwhile, upon channel close (#), the driver sends a CMD_STOP_CHIP
to the firmware, effectively closing all further communication.  In
the high traffic case, the atomic counter remains at MAX_TX_URBS,
and all the URB contexts remain marked as active.  While opening
the channel again (@), it cannot send any further frames since no
more free tx URB contexts are available.

Reset all tx URB contexts upon CAN channel close.

(*) 50 parallel instances of `cangen0 -g 0 -ix`
(#) `ifconfig can0 down`
(@) `ifconfig can0 up`
(%) "can: kvaser_usb: Don't free packets when tight on URBs"

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-15 16:58:01 +01:00
Ahmed S. Darwish b442723fce can: kvaser_usb: Don't free packets when tight on URBs
Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in high frequency caused seemingly-random panics in the
kernel.

On further inspection, it seems the driver erroneously freed the
to-be-transmitted packet upon getting tight on URBs and returning
NETDEV_TX_BUSY, leading to invalid memory writes and double frees
at a later point in time.

Note:

Finding no more URBs/transmit-contexts and returning NETDEV_TX_BUSY
is a driver bug in and out of itself: it means that our start/stop
queue flow control is broken.

This patch only fixes the (buggy) error handling code; the root
cause shall be fixed in a later commit.

Acked-by: Olivier Sobrie <olivier@sobrie.be>
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-15 16:58:00 +01:00
Roger Quadros 47e3485af0 can: c_can: use regmap_update_bits() to modify RAMINIT register
use of regmap_read() and regmap_write() in c_can_hw_raminit_syscon()
is not safe as the RAMINIT register can be shared between different drivers
at least for TI SoCs.

To make the modification atomic we switch to using regmap_update_bits().

regmap_update_bits() skips writing to the register if it's read content is the
same as what is going to be written. This causes an issue for us when we
need to clear the DONE bit with the initial condition START:0, DONE:1 as
DONE bit must be written with 1 to clear it.

So we defer the clearing of DONE bit to later when we set the START bit.
There we are sure that START bit is changed from 0 to 1 so the write of
1 to already set DONE bit will happen.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-15 16:58:00 +01:00
Oliver Hartkopp 6cfda7fbeb can: m_can: tag current CAN FD controllers as non-ISO
During the CAN FD standardization process within the ISO it turned out that
the failure detection capability has to be improved.

The CAN in Automation organization (CiA) defined the already implemented CAN
FD controllers as 'non-ISO' and the upcoming improved CAN FD controllers as
'ISO' compliant. See at http://www.can-cia.com/index.php?id=1937

Finally there will be three types of CAN FD controllers in the future:

1. ISO compliant (fixed)
2. non-ISO compliant (fixed, like the M_CAN IP v3.0.1 in m_can.c)
3. ISO/non-ISO CAN FD controllers (switchable, like the PEAK USB FD)

So the current M_CAN driver for the M_CAN IP v3.0.1 has to expose its non-ISO
implementation by setting the CAN_CTRLMODE_FD_NON_ISO ctrlmode at startup.
As this bit cannot be switched at configuration time CAN_CTRLMODE_FD_NON_ISO
must not be set in ctrlmode_supported of the current M_CAN driver.

Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-15 16:57:59 +01:00
Oliver Hartkopp 9b1087aa5e can: dev: fix crtlmode_supported check
When changing flags in the CAN drivers ctrlmode the provided new content has to
be checked whether the bits are allowed to be changed. The bits that are to be
changed are given as a bitfield in cm->mask. Therefore checking against
cm->flags is wrong as the content can hold any kind of values.

The iproute2 tool sets the bits in cm->mask and cm->flags depending on the
detected command line options. To be robust against bogus user space
applications additionally sanitize the provided flags with the provided mask.

Cc: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-15 16:57:59 +01:00