Add support for a new multi-function mode based on the Unified Fabric Port
system specifications.
Support includes configuration of:
1. Outer vlan tags.
2. Bandwidth settings.
3. Virtual link enable/disable.
Rearrange macros to query for storage-only modes in different MF environment.
Improves the readibility and maintainability of the code. E.g.:
- if (IS_MF_STORAGE_SD(bp) || IS_MF_FCOE_AFEX(bp))
+ if (IS_MF_STORAGE_ONLY(bp))
In addition, this removes the need for bnx2x_is_valid_ether_addr().
Neil Horman [Wed, 17 Sep 2014 13:04:45 +0000 (09:04 -0400)]
3c59x: Fix bad offset spec in skb_frag_dma_map
Recently aded the use of skb_frag_dma_map to 3c59x, but didn't realize it
automatically included the frag_offset internally, as well as provided an option
to specify an extra offset in the parameter list. We need to specify an offset
of 0 in the parameter list to avoid skb corruption that results in lost
connections.
Neil Horman [Wed, 17 Sep 2014 13:04:44 +0000 (09:04 -0400)]
3c59x: Add dma error checking and recovery
Noted that 3c59x has no checks on transmit for failed DMA mappings, and no
ability to unmap fragments when a single map fails in the middle of a transmit.
This patch provides error checking to ensure that dma mappings work properly,
and unrolls an skb mapping if a fragmented skb transmission has a mapping
failure to prevent leaks.
This patch sets the change to of_phy_connect() that you have seen before,
this time with the full context of why it is useful and applicable here.
Due to some design decision, the internal PHY on Broadcom BCM7xxx chips
is not entirely self contained and does not report its internal revision
through MII_PHYSID2, that is left to external PHY designs.
This forces us to get the PHY revision from the GENET and SF2 switch drivers
because those two peripherals integrate such a PHY and do contain the PHY
revision in their registers.
The approach taken here is hopefully easy to extend to similar needs for
other chips/ as well.
====================
net: phy: bcm7xxx: utilize PHY revision in config_init
Now that the GENET and SF2 drivers have been updated to communicate us
what is the revision of the BCM7xxx integrated PHY, utilize that
information in the config_init() callback to call into the appropriate
workaround function based on our revision.
While at it, we also print the revision and patch level to help debug
new chips.
net: dsa: bcm_sf2: communicate integrated PHY revision to PHY driver
The integrated BCM7xxx PHY contains no useful revision information
in its MII_PHYSID2 bits 3:0, that information is instead contained in
the SWITCH_REG_PHY_REVISION register.
Read this register, store its value, and return it by implementing the
dsa_switch::get_phy_flags() callback accordingly. The register layout is
already matching what the BCM7xxx PHY driver is expecting to find.
net: dsa: allow switch drivers to specify phy_device::dev_flags
Some switch drivers (e.g: bcm_sf2) may have to communicate specific
workarounds or flags towards the PHY device driver. Allow switches
driver to be delegated that task by introducing a get_phy_flags()
callback which will do just that.
net: bcmgenet: communicate integrated PHY revision to PHY driver
The integrated BCM7xxx PHY contains no useful revision information in
its MII_PHYSID2 bits 3:0, that information is instead contained in the
GENET hardware block.
We already read the GENET 32-bit revision register, so store the
integrated PHY revision in the driver private structure, and then
communicate this revision value to the PHY driver by overriding the
phy_flags value.
Now that we have removed the need for the PHY_BRCM_100MBPS_WAR flag, we
can remove it from the GENET driver and the broadcom shared header file.
The PHY driver checks the PHY supported bitmask instead.
net: phy: bcm7xxx: do not use PHY_BRCM_100MBPS_WAR
There is no need for the PHY driver to check PHY_BRCM_100MBPS_WAR since
that is redundant with checking the PHY device supported features. Get
rid of that workaround flag.
net: phy: broadcom: add helper for PHY revision and patch level
The Broadcom BCM7xxx internal PHYs do not contain any useful revision
information in the low 4-bits of their MII_PHYSID2 (MII register 3)
which could allow us to properly identify them.
As a result, we need the actual hardware block integrating these PHYs:
GENET or the SF2 switch to tell us what revision they are built with. To
assist with that, add two helper macros for fetching the the PHY
revision and patch level from the struct phy_device::dev_flags.
Commit f9a8f83b04e0 ("net: phy: remove flags argument from phy_{attach,
connect, connect_direct}") removed the flags argument to the PHY library
calls to: phy_{attach,connect,connect_direct}.
Most Device Tree aware drivers call of_phy_connect() with the flag
argument set to 0, but some of them might want to set a different value
there in order for the PHY driver to key a specific behavior based on
the phy_device::phy_flags value.
Allow such drivers to set custom phy_flags as part of the
of_phy_connect() call since of_phy_connect() does start the PHY state
machine, it will call into the PHY driver config_init() callback which
is usually where a specific phy_flags value is important.
Fixes: f9a8f83b04e0 ("net: phy: remove flags argument from phy_{attach, connect, connect_direct}") Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
Pull btrfs fixes from Chris Mason:
"I've got a revert to fix a regression with btrfs device registration,
and Filipe has part two of his fsync fix from last week"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Revert "Btrfs: device_list_add() should not update list when mounted"
Btrfs: set inode's logged_trans/last_log_commit after ranged fsync
Merge tag 'nfs-for-3.17-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client fixes from Trond Myklebust:
"Highligts:
- fix an Oops in nfs4_open_and_get_state
- fix an Oops in the nfs4_state_manager
- fix another bug in the close/open_downgrade code"
* tag 'nfs-for-3.17-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
NFSv4: Fix another bug in the close/open_downgrade code
NFSv4: nfs4_state_manager() vs. nfs_server_remove_lists()
NFS: remove BUG possibility in nfs4_open_and_get_state
sparc: bpf_jit: fix support for ldx/stx mem and SKF_AD_VLAN_TAG
fix several issues in sparc BPF JIT compiler.
ldx/stx related:
. classic BPF instructions that access mem[] slots were not setting
SEEN_MEM flag, so stack wasn't allocated. Fix that by advertising
correct flags
. LDX/STX instructions were missing SEEN_XREG, so register value
could have leaked to user space. Fix it.
. since stack for mem[] slots is allocated with 'sub %sp' instead
of 'save %sp', use %sp as base register instead of %fp.
. ldx mem[0] means first slot in classic BPF which should have
-4 offset instead of 0.
. sparc64 needs 2047 stack bias as per ABI to access stack
. emit_stmem() was using LD32I macro instead of ST32I
SKF_AD_VLAN_TAG* related:
. SKF_AD_VLAN_TAG_PRESENT must return 1 or 0 instead of '> 0' or 0
as per classic BPF de facto standard
. SKF_AD_VLAN_TAG needs to mask the field correctly
Fixes: 2809a2087cc4 ("net: filter: Just In Time compiler for sparc") Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
David S. Miller [Fri, 19 Sep 2014 19:57:46 +0000 (15:57 -0400)]
Merge branch 'udp-tunnel-common'
Andy Zhou says:
====================
Refactor vxlan and l2tp to use new common UDP tunnel APIs
This patch series add a few more UDP tunnel APIs and refactoring current
UDP tunnel based protocols, vxlan and l2tp to make use of the new APIs.
The added APIs are setup_udp_tunnel_sock(), udp_tunnel_xmit_skb() and
udp_tunnel_sock_release(). Those implementation logics already exist in
current vxlan and l2tp implementation. Move them to common APIs to reduce
code duplications.
Also split udp_tunnel.c into net/ipv4/udp_tunnel.c and
net/ipv6/ip6_udp_tunnel.c to maintain proper IP protocol separation.
====================
Change from v2 to v3
- add error check in fec_enet_set_coalesce
- fix a run time warning to get clock rate in interrupt
- fix commit message use TKT number
Change from v1 to v2
- fix indention
- use errata number instead of TKT
====================
net: fec: Workaround for imx6sx enet tx hang when enable three queues
When enable three queues on imx6sx enet, and then do tx performance
test with iperf tool, after some time running, tx hang.
Found that:
If uDMA is running, software set TDAR may cause tx hang.
If uDMA is in idle, software set TDAR don't cause tx hang.
There is a TDAR race condition for mutliQ when the software sets TDAR
and the UDMA clears TDAR simultaneously or in a small window (2-4 cycles).
This will cause the udma_tx and udma_tx_arbiter state machines to hang.
The issue exist at i.MX6SX enet IP.
So, the Workaround is checking TDAR status four time, if TDAR cleared by
hardware and then write TDAR, otherwise don't set TDAR.
The patch is only one Workaround for the issue ERR007885.
net: fec: add interrupt coalescence feature support
i.MX6 SX support interrupt coalescence feature
By default, init the interrupt coalescing frame count threshold and
timer threshold.
Supply the ethtool interfaces as below for user tuning to improve
enet performance:
rx_max_coalesced_frames
rx_coalesce_usecs
tx_max_coalesced_frames
tx_coalesce_usecs
Merge tag 'pci-v3.17-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fixes from Bjorn Helgaas:
"These fix:
- Boot video device detection on dual-GPU Apple systems
- Hotplug fiascos on VGA switcheroo with radeon & nouveau drivers
- Boot hang on Freescale i.MX6 systems
- Excessive "no hotplug settings from platform" warnings
In particular:
Enumeration
- Don't default exclusively to first video device (Bruno Prémont)
PCI device hotplug
- Remove "no hotplug settings from platform" warning (Bjorn Helgaas)
- Add pci_ignore_hotplug() for VGA switcheroo (Bjorn Helgaas)
Freescale i.MX6
- Put LTSSM in "Detect" state before disabling (Lucas Stach)"
* tag 'pci-v3.17-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
vgaarb: Drop obsolete #ifndef
vgaarb: Don't default exclusively to first video device with mem+io
ACPIPHP / radeon / nouveau: Remove acpi_bus_no_hotplug()
PCI: Remove "no hotplug settings from platform" warning
PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device
PCI: imx6: Put LTSSM in "Detect" state before disabling it
MAINTAINERS: Add Lucas Stach as co-maintainer for i.MX6 PCI driver
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is a set of three fixes.
One represents a nasty shared tag map regression (another inverted
condition) caused by recent SCSI MQ patches, one is a longstanding
potential buffer overrun in the iscsi data buffer and the final one is
a use after free for the rare bidirectional commands"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
[SCSI] fix for bidi use after free
[SCSI] fix regression that accidentally disabled block-based tcq
[SCSI] libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu
Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
"Two kernel side fixes: a kprobes fix and a perf_remove_from_context()
fix (which does not yet fix the migration bug which is WIP)"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Fix a race condition in perf_remove_from_context()
kprobes/x86: Free 'optinsn' cache when range check fails
Mike Marciniszyn [Fri, 19 Sep 2014 12:32:19 +0000 (08:32 -0400)]
IB/qib: Correct reference counting in debugfs qp_stats
This particular reference count is not needed with the rcu protection,
and the current code leaks a reference count, causing a hang in
qib_qp_destroy().
Revert "PCI: Make sure bus number resources stay within their parents bounds"
This reverts commit 1820ffdccb9b ("PCI: Make sure bus number resources stay
within their parents bounds") because it breaks some systems with LSI Logic
FC949ES Fibre Channel Adapters, apparently by exposing a defect in those
adapters.
Dirk tested a Tyan VX50 (B4985) with this device that worked like this
prior to 1820ffdccb9b:
bus: [bus 00-7f] on node 0 link 1
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-07])
pci 0000:00:0e.0: PCI bridge to [bus 0a]
pci_bus 0000:0a: busn_res: can not insert [bus 0a] under [bus 00-07] (conflicts with (null) [bus 00-07])
pci 0000:0a:00.0: [1000:0646] type 00 class 0x0c0400 (FC adapter)
Note that the root bridge [bus 00-07] aperture is wrong; this is a BIOS
defect in the PCI0 _CRS method. But prior to 1820ffdccb9b, we didn't
enforce that aperture, and the FC adapter worked fine at 0a:00.0.
After 1820ffdccb9b, we notice that 00:0e.0's aperture is not contained in
the root bridge's aperture, so we reconfigure it so it *is* contained:
This effectively moves the FC device from 0a:00.0 to 07:00.0, which should
be legal. But when we enumerate bus 06, the FC device doesn't respond, so
we don't find anything. This is probably a defect in the FC device.
Possible fixes (due to Yinghai):
1) Add a quirk to fix the _CRS information based on what amd_bus.c read
from the hardware
2) Reset the FC device after we change its bus number
Fix 1 would be relatively easy, but it does sweep the LSI FC issue under
the rug. We might want to reconfigure bus numbers in the future for some
other reason, e.g., hotplug, and then we could trip over this again.
For that reason, I like fix 2, but we don't know whether it actually works,
and we don't have a patch for it yet.
This revert is fix 3, which also sweeps the LSI FC issue under the rug.
According to <http://marc.info/?t=138347640900004&r=1&w=2>, revision
A0 of Connect-X does not correctly assemble TSO packets. Disable that
feature on that hardware revision.
Mike Marciniszyn [Mon, 15 Sep 2014 15:42:53 +0000 (11:42 -0400)]
IB/qib: Change get_user_pages() usage to always NULL vmas
The static helper routine, __qib_get_user_pages(), accepts a vma arg,
but current use always passes NULL.
This has caused some confusion associated with the correct use of this
argument, but since the current use case doesn't require the
flexiblity, the best thing to do is to simplfy the code to always pass
NULL to get_user_pages().
Mike Marciniszyn [Mon, 15 Sep 2014 15:43:06 +0000 (11:43 -0400)]
IB/ipath: Change get_user_pages() usage to always NULL vmas
The static helper routine, __ipath_get_user_pages(), accepts a vma
arg, but current use always passes NULL.
This has caused some confusion associated with the correct use of this
argument, but since the current use case doesn't require the
flexiblity, the best thing to do is to simplfy the code to always pass
NULL to get_user_pages().
Revert "PCI: Don't scan random busses in pci_scan_bridge()"
This reverts commit fc1b253141b3 ("PCI: Don't scan random busses in
pci_scan_bridge()") because it breaks CardBus on some machines.
David tested a Dell Latitude D505 that worked like this prior to fc1b253141b3:
pci 0000:00:1e.0: PCI bridge to [bus 01]
pci 0000:01:01.0: CardBus bridge to [bus 02-05]
Note that the 01:01.0 CardBus bridge has a bus number aperture of
[bus 02-05], but those buses are all outside the 00:1e.0 PCI bridge bus
number aperture, so accesses to buses 02-05 never reach CardBus. This is
later patched up by yenta_fixup_parent_bridge(), which changes the
subordinate bus number of the 00:1e.0 PCI bridge:
pci_bus 0000:01: Raising subordinate bus# of parent bus (#01) from #01 to #05
With fc1b253141b3, pci_scan_bridge() fails immediately when it notices that
we can't allocate a valid secondary bus number for the CardBus bridge, and
CardBus doesn't work at all:
pci 0000:01:01.0: can't allocate child bus 01 from [bus 01]
I'd prefer to fix this by integrating the yenta_fixup_parent_bridge() logic
into pci_scan_bridge() so we fix the bus number apertures up front. But
I don't think we can do that before v3.17, so I'm going to revert this to
avoid the problem while we're working on the long-term fix.
IB: ib_umem_release() should decrement mm->pinned_vm from ib_umem_get
In debugging an application that receives -ENOMEM from ib_reg_mr(), I
found that ib_umem_get() can fail because the pinned_vm count has
wrapped causing it to always be larger than the lock limit even with
RLIMIT_MEMLOCK set to RLIM_INFINITY.
The wrapping of pinned_vm occurs because the process that calls
ib_reg_mr() will have its mm->pinned_vm count incremented. Later a
different process with a different mm_struct than the one that
allocated the ib_umem struct ends up releasing it which results in
decrementing the new processes mm->pinned_vm count past zero and
wrapping.
I'm not entirely sure what circumstances cause a different process to
release the ib_umem than the one that allocated it but the kernel
stack trace of the freeing process from my situation looks like the
following:
The following patch fixes the issue by storing the pid struct of the
process that calls ib_umem_get() so that ib_umem_release and/or
ib_umem_account() can properly decrement the pinned_vm count of the
correct mm_struct.
Devesh Sharma [Mon, 9 Jun 2014 05:22:38 +0000 (10:52 +0530)]
RDMA/ocrdma: Do not skip setting deferred_arm
When ib_request_notify_cq() is called for the first time, ocrdma tries
to skip setting deffered_arm flag. This may lead CQ to an un-armed
state thus never generating a CQ event and leaving consumer hung.
This patch removes the part of code that skips setting deferred_arm.
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
"Misc fixes:
EFI fixes, a build fix, a page table dumping (debug) fix and a clang
build fix"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi/arm64: Fix fdt-related memory reservation
x86/mm: Apply the section attribute to the variable, not its type
x86/efi: Fixup GOT in all boot code paths
x86/efi: Only load initrd above 4g on second try
x86-64, ptdump: Mark espfix area only if existent
x86, irq: Fix build error caused by 9eabc99a635a77cbf09
Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus
Pull MIPS fixes from Ralf Baechle:
"A fair number of build fixes for various configurations.
Fixes to BPF, and the BCM47xx platform code, a preemption fix for the
Loongson core, a syscall auditing fix, wire up the new getrandom and
memfd_create. Several patches for EVA"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: (30 commits)
MIPS: SmartMIPS: Disable assembler warnings
MIPS: Move CPU topology macros to topology.h
MIPS: Wire up new syscalls getrandom and memfd_create.
MIPS: Fix a warning for virt_to_page
arch/mips/net/bpf_jit.c: fix failure check
MIPS: COP2: CPP macro safety fixes.
MIPS: Kconfig: Select SMP symbols for CMP
MIPS: ZBOOT: add missing <linux/string.h> include
MIPS: IP28: Fix/clean spaces.h
MIPS: IP28: Select correct L1_CACHE_SHIFT
MIPS: BCM63xx: delete double assignment
MIPS: Spelling s/confugrations/configurations/
MIPS: OCTEON: make get_system_type() thread-safe
MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores
MIPS: Malta: EVA: Rename 'eva_entry' to 'platform_eva_init'
MIPS: EVA: Add new EVA header
MIPS: scall64-o32: Fix indirect syscall detection
MIPS: syscall: Fix AUDIT value for O32 processes on MIPS64
MIPS: Loongson: Fix COP2 usage for preemptible kernel
MIPS: NL: Fix nlm_xlp_defconfig build error
...
When ending a bi-directionional SCSI request, blk_finish_request()
cleans up and frees the request, but scsi_release_bidi_buffers() tries
to indirect through the request to find it's data buffers. This causes
a panic due to a null pointer dereference.
Move the call to scsi_release_bidi_buffers() before the call to
blk_finish_request().
[SCSI] fix regression that accidentally disabled block-based tcq
The scsi blk-mq support accidentally flipped a conditional, which lead to
never enabling block based tcq when using the legacy request path.
Fixes: d285203cf647d7c9 scsi: add support for a blk-mq based I/O path. Reported-by: Hans de Goede <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: James Bottomley <[email protected]>
Mike Christie [Wed, 3 Sep 2014 05:00:39 +0000 (00:00 -0500)]
[SCSI] libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu
This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu.
This function is used by iscsi drivers and userspace to send iscsi PDUs/
commands. For login commands, we have a set buffer size. For all other
commands we do not support data buffers.
This was reported by Dan Carpenter here:
http://www.spinics.net/lists/linux-scsi/msg66838.html
netfilter: nf_tables: export rule-set generation ID
This patch exposes the ruleset generation ID in three ways:
1) The new command NFT_MSG_GETGEN that exposes the 32-bits ruleset
generation ID. This ID is incremented in every commit and it
should be large enough to avoid wraparound problems.
2) The less significant 16-bits of the generation ID are exposed through
the nfgenmsg->res_id header field. This allows us to quickly catch
if the ruleset has change between two consecutive list dumps from
different object lists (in this specific case I think the risk of
wraparound is unlikely).
3) Userspace subscribers may receive notifications of new rule-set
generation after every commit. This also provides an alternative
way to monitor the generation ID. If the events are lost, the
userspace process hits a overrun error, so it knows that it is
working with a stale ruleset anyway.
Patrick spotted that rule-set transformations in userspace may take
quite some time. In that case, it annotates the 32-bits generation ID
before fetching the rule-set, then:
1) it compares it to what we obtain after the transformation to
make sure it is not working with a stale rule-set and no wraparound
has ocurred.
2) it subscribes to ruleset notifications, so it can watch for new
generation ID.
This is complementary to the NLM_F_DUMP_INTR approach, which allows
us to detect an interference in the middle one single list dumping.
There is no way to explicitly check that an interference has occurred
between two list dumps from the kernel, since it doesn't know how
many lists the userspace client is actually going to dump.
Dave Airlie [Fri, 19 Sep 2014 00:34:34 +0000 (10:34 +1000)]
Merge tag 'drm-intel-fixes-2014-09-18' of git://anongit.freedesktop.org/drm-intel into drm-fixes
couple of display fixes.
* tag 'drm-intel-fixes-2014-09-18' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Add limited color range readout for HDMI/DP ports on g4x/vlv/chv
drm/i915: Fix SRC_COPY width on 830/845g
Dave Airlie [Fri, 19 Sep 2014 00:34:06 +0000 (10:34 +1000)]
Merge branch 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
- fix a resume hang on mullins
- fix an oops on module unload with vgaswitcheroo (radeon and nouveau)
- fix possible hangs DMA engine hangs due to hw bugs
* 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux:
drm/nouveau/runpm: fix module unload
drm/radeon/px: fix module unload
vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops
drm/radeon: don't reset dma on r6xx-evergreen init
drm/radeon: don't reset sdma on CIK init
drm/radeon: don't reset dma on NI/SI init
drm/radeon/dpm: fix resume on mullins
drm/radeon: Disable HDP flush before every CS again for < r600
drm/radeon: delete unused PTE_* defines
./arch/arm64/include/asm/pgtable.h:27:0: note: this is the location of the previous definition
#define PTE_VALID (_AT(pteval_t, 1) << 0)
^
In file included from drivers/gpu/drm/radeon/r600_cs.c:31:0:
drivers/gpu/drm/radeon/r600d.h:48:0: warning: "PTE_VALID" redefined [enabled by default]
#define PTE_VALID (1 << 0)
^
In file included from ./arch/arm64/include/asm/io.h:29:0,
from include/linux/clocksource.h:19,
from include/clocksource/arm_arch_timer.h:19,
from ./arch/arm64/include/asm/arch_timer.h:27,
from ./arch/arm64/include/asm/timex.h:19,
from include/linux/timex.h:65,
<snip>
from include/drm/drmP.h:51,
from drivers/gpu/drm/radeon/r600_cs.c:29:
./arch/arm64/include/asm/pgtable.h:27:0: note: this is the location of the previous definition
#define PTE_VALID (_AT(pteval_t, 1) << 0)
^
Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs/smb3 fixes from Steve French:
"Fixes for problems found during testing and debugging at the SMB3
storage test event (plugfest) this week"
* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
Fix mfsymlinks file size check
Update version number displayed by modinfo for cifs.ko
cifs: remove dead code
Revert "cifs: No need to send SIGKILL to demux_thread during umount"
[SMB3] Fix oops when creating symlinks on smb3
[CIFS] Fix setting time before epoch (negative time values)
Merge tag 'sound-3.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"All small fixes in random various drivers, mostly for ASoC at this
time, which look reasonable for a high rc number"
* tag 'sound-3.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: rockchip-i2s: dt: swap tx and rx channed request number in example
ASoC: rockchip-i2s: fix registers' property of rockchip i2s controller
ASoC: rockchip-i2s: fix master mode set bit error
ASoC: cs4265: Fix register address to set the proper data type.
ALSA: hda - Fix invalid pin powermap without jack detection
ASoC: soc-pcm: fix dpcm_path_get error handling
ASoC: samsung-i2s: Check secondary DAI exists before referencing
ASoC: Update email id of the author
ASoC: dwc: Update email id of the author
ASoC: davinci-mcasp: Correct rx format unit configuration
ASoC: tlv320aic31xx: Fix 24bit samples with I2S format and 12MHz mclk
Krzysztof Hałasa [Thu, 18 Sep 2014 13:12:02 +0000 (15:12 +0200)]
Fix unbalanced mutex in dma_pool_create().
dma_pool_create() needs to unlock the mutex in error case. The bug was
introduced in the 3.16 by commit cc6b664aa26d ("mm/dmapool.c: remove
redundant NULL check for dev in dma_pool_create()")/
Merge tag 'regulator-v3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"Fix some leaked OF node references in regulator drivers that have been
left over following a fix on a fix to the reference counting"
* tag 'regulator-v3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: remove unnecessary of_node_get() to parent
Merge tag 'spi-v3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A few driver specific fixes for v3.17:
- Fix davinci so that GPIO chip selects work with deferred probe of
GPIOs (which could happen in production depending on kernel config)
plus one incremental stylistic fix to that.
- Several fixes for the newly introduced rockchip driver that came up
in wider testing of the device.
- A couple of small things in the sirf driver, one bug that would
stop DMA transfers working and another update to follow the
documented procedure in the datasheet.
- Fix some memory leaks with devm_kzalloc() being used outside of the
device bind path"
* tag 'spi-v3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: davinci: remove empty function davinci_spi_cleanup
spi: davinci: request cs_gpio's from probe
spi/pl022: Fix error message
spi/rockchip: Mark DMA as optional
spi/rockchip: Don't warn if SPI is busy but disabled
spi/rockchip: Fix the wait_for_idle() timeout
spi: sirf: add fifo reset/start for cmd transfer
spi: sirf: enable RX_IO_DMA_INT interrupt
spi: dw: Don't use devm_kzalloc in master->setup callback
spi: fsl: Don't use devm_kzalloc in master->setup callback
NFSv4: Fix another bug in the close/open_downgrade code
James Drew reports another bug whereby the NFS client is now sending
an OPEN_DOWNGRADE in a situation where it should really have sent a
CLOSE: the client is opening the file for O_RDWR, but then trying to
do a downgrade to O_RDONLY, which is not allowed by the NFSv4 spec.
Steve Dickson [Thu, 18 Sep 2014 13:13:17 +0000 (09:13 -0400)]
NFSv4: nfs4_state_manager() vs. nfs_server_remove_lists()
There is a race between nfs4_state_manager() and
nfs_server_remove_lists() that happens during a nfsv3 mount.
The v3 mount notices there is already a supper block so
nfs_server_remove_lists() called which uses the nfs_client_lock
spin lock to synchronize access to the client list.
At the same time nfs4_state_manager() is running through
the client list looking for work to do, using the same
lock. When nfs4_state_manager() wins the race to the
list, a v3 client pointer is found and not ignored
properly which causes the panic.
Moving some protocol checks before the state checking
avoids the panic.
Zefan Li [Thu, 18 Sep 2014 09:28:46 +0000 (17:28 +0800)]
cgroup: fix unbalanced locking
cgroup_pidlist_start() holds cgrp->pidlist_mutex and then calls
pidlist_array_load(), and cgroup_pidlist_stop() releases the mutex.
It is wrong that we release the mutex in the failure path in
pidlist_array_load(), because cgroup_pidlist_stop() will be called
no matter if cgroup_pidlist_start() returns errno or not.
This commit is triggering failures to mount by subvolume id in some
configurations. The main problem is how many different ways this
scanning function is used, both for scanning while mounted and
unmounted. A proper cleanup is too big for late rcs.
For now, just revert the commit and we'll put a better fix into a later
merge window.
Ville Syrjälä [Fri, 12 Sep 2014 12:46:29 +0000 (15:46 +0300)]
drm/i915: Add limited color range readout for HDMI/DP ports on g4x/vlv/chv
The limited color range knob is in the port registers on
g4x and vlv/chv for HDMI, and on g4x for DP. Add the relevant code
to read out the hardware state into pipe config. On vlv/chv the
DP port limited color range knob is in PIPECONF for which we
already have readout code.
Jacob Keller [Wed, 3 Sep 2014 08:12:59 +0000 (08:12 +0000)]
ixgbe: use e_dev_warn instead of netif_printk
Again, we should not be directly using netif_printk, as we have our own
error print routines that we generate. In addition, instead of using an
early return we can just use the else block of this one line if
statement.
Jacob Keller [Wed, 3 Sep 2014 08:12:58 +0000 (08:12 +0000)]
ixgbe: use e_dev_warn instead of e_err for displaying warning
In this case, disabling DCB is not an error. We can still function, but
we just have to let the user know. In addition, since we call this
during probe before allocating our netdevice structure, we should use
e_dev_warn instead of e_warn.
Our calculated v_budget doesn't matter except if we allocate MSI-X
vectors. We shouldn't need to calculate this outside of the function, so
don't. Instead, only calculate it once we attempt to acquire MSI-X
vectors. This helps collocate all of the MSI-X vector code together.
Jacob Keller [Wed, 3 Sep 2014 08:12:56 +0000 (08:12 +0000)]
ixgbe: move msix_entries allocation into ixgbe_acquire_msix_vectors
We already have to kfree this value if we fail, and this is only part of
MSI-X mode, so we should simply allocate the value where we need it.
This is cleaner, and makes it a lot more obvious why we are freeing it
inside of ixgbe_acquire_msix_vectors.
Jacob Keller [Wed, 3 Sep 2014 08:12:55 +0000 (08:12 +0000)]
ixgbe: return integer from ixgbe_acquire_msix_vectors
Similar to how ixgbevf handles acquiring MSI-X vectors, we can return an
error code instead of relying on the flag being set. This makes it more
clear that we have failed to setup MSI-X mode, and also will make it
easier to consolidate MSI-X related code all into the single function.
Jacob Keller [Wed, 3 Sep 2014 08:12:54 +0000 (08:12 +0000)]
ixgbe: use e_dev_warn instead of netif_printk
The netif_printk relies on our netdevice structure to be registered
already. We may call ixgbe_acquire_msix_vectors prior to registering our
netdevice, so we should not use the netdevice specific printk.
Mark Rustad [Sat, 9 Aug 2014 07:02:09 +0000 (07:02 +0000)]
ixgbe: Do not schedule an uninitialized workqueue entry
If a hardware Tx timestamp is requested, an uninitialized
workqueue entry may be scheduled, especially on an 82598 adapter.
Add a check for a PTP clock to avoid that. Also only apply the
unlikely to the first term of the conditional. That will make the
rest of the checks be in the cold path.
ixgbe: remove useless bd_number from adapter struct
Because bd_number is not useful anymore, so remove it from adapter struct, or
if keep it, we have to fix the boards driven counter bug in ixgbe_remove() and
ixgbe_probe() only for trivial debug purpose -- other output is enough.
David Dueck [Wed, 17 Sep 2014 12:26:48 +0000 (14:26 +0200)]
can: at91_can: add missing prepare and unprepare of the clock
In order to make the driver work with the common clock framework, this patch
converts the clk_enable()/clk_disable() to
clk_prepare_enable()/clk_disable_unprepare(). While there, add the missing
error handling.
can: flexcan: put TX mailbox into TX_INACTIVE mode after tx-complete
After sending a RTR frame the TX mailbox becomes a RX_EMPTY mailbox. To avoid
side effects when the RX-FIFO is full, this patch puts the TX mailbox into
TX_INACTIVE mode in the transmission complete interrupt handler. This, of
course, leaves a race window between the actual completion of the transmission
and the handling of tx-complete interrupt. However this is the best we can do
without busy polling the tx complete interrupt.
David Jander [Wed, 3 Sep 2014 14:47:22 +0000 (16:47 +0200)]
can: flexcan: implement workaround for errata ERR005829
This patch implements the workaround mentioned in ERR005829:
ERR005829: FlexCAN: FlexCAN does not transmit a message that is enabled to
be transmitted in a specific moment during the arbitration process.
Workaround: The workaround consists of two extra steps after setting up a
message for transmission:
Step 8: Reserve the first valid mailbox as an inactive mailbox (CODE=0b1000).
If RX FIFO is disabled, this mailbox must be message buffer 0. Otherwise, the
first valid mailbox can be found using the "RX FIFO filters" table in the
FlexCAN chapter of the chip reference manual.
Step 9: Write twice INACTIVE code (0b1000) into the first valid mailbox.
David Jander [Wed, 27 Aug 2014 09:58:05 +0000 (11:58 +0200)]
can: flexcan: correctly initialize mailboxes
Apparently mailboxes may contain random data at startup, causing some of them
being prepared for message reception. This causes overruns being missed or even
confusing the IRQ check for trasmitted messages, increasing the transmit
counter instead of the error counter.
This patch initializes all mailboxes after the FIFO as RX_INACTIVE.
Oliver Hartkopp [Tue, 16 Sep 2014 08:05:41 +0000 (10:05 +0200)]
can: peak_pci: add PCI ID definition pcie card variant
Add PCI ID definition for the single channel PCAN ExpressCard 34 adapter. Due
to the subsystem id evaluation the correct number of channels (here 1) is
created at initialization time. Tested including the LED functionality.
====================
This pull requests makes the following changes:
* Add simple weighted fail-over scheduler.
- Unlike other IPVS schedulers this offers fail-over rather than load
balancing. Connections are directed to the appropriate server based
solely on highest weight value and server availability.
- Thanks to Kenny Mathis
* Support IPv6 real servers in IPv4 virtual-services and vice versa
- This feature is supported in conjunction with the tunnel (IPIP)
forwarding mechanism. That is, IPv4 may be forwarded in IPv6 and
vice versa.
- The motivation for this is to allow more flexibility in the
choice of IP version offered by both virtual-servers and
real-servers as they no longer need to match: An IPv4 connection from an
end-user may be forwarded to a real-server using IPv6 and vice versa.
- Further work need to be done to support this feature in conjunction
with connection synchronisation. For now such configurations are
not allowed.
- This change includes update to netlink protocol, adding a new
destination address family attribute. And the necessary changes
to plumb this information throughout IPVS.
- Thanks to Alex Gartrell and Julian Anastasov
====================
Herbert Xu [Thu, 18 Sep 2014 08:38:18 +0000 (16:38 +0800)]
ipsec: Remove obsolete MAX_AH_AUTH_LEN
While tracking down the MAX_AH_AUTH_LEN crash in an old kernel
I thought that this limit was rather arbitrary and we should
just get rid of it.
In fact it seems that we've already done all the work needed
to remove it apart from actually removing it. This limit was
there in order to limit stack usage. Since we've already
switched over to allocating scratch space using kmalloc, there
is no longer any need to limit the authentication length.
This patch kills all references to it, including the BUG_ONs
that led me here.
David Howells [Wed, 17 Sep 2014 22:28:38 +0000 (23:28 +0100)]
CacheFiles: Handle rename2
Not all filesystems now provide the rename i_op - ext4 for one - but rather
provide the rename2 i_op. CacheFiles checks that the filesystem has rename
and so will reject ext4 now with EPERM:
CacheFiles: Failed to register: -1
Fix this by checking for rename2 as an alternative. The call to vfs_rename()
actually handles selection of the appropriate function, so we needn't worry
about that.
projects / linux.git / log