summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2014-03-26net: phy: bcm7xxx: fix spurious MDIO failures during workaroundFlorian Fainelli
Writing first to the AFE registers, and then the VCO, RCAL, RC_CAL registers turned out to unveil some spurious MDIO read/write failures which would make the workaround partially applied. The fix is to write first to the VCO, RCAL, RC_CAL registers, and then write to the AFE registers. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26net: phy: bcm7xxx: define constants for our registersFlorian Fainelli
Define constants for the various registers used in bcm7xxx_28nm_afe_config_init() to help clarify what this workaround is about. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26tg3: Do not include vlan acceleration features in vlan_featuresVlad Yasevich
Including hardware acceleration features in vlan_features breaks stacked vlans (Q-in-Q) by marking the bottom vlan interface as capable of acceleration. This causes one of the tags to be lost and the packets are sent with a sing vlan header. CC: Nithin Nayak Sujir <nsujir@broadcom.com> CC: Michael Chan <mchan@broadcom.com> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26qlcnic: Remove casts of pointer to same typeJoe Perches
Casting a pointer to a pointer of the same type is pointless, so remove these unnecessary casts. Done via coccinelle script: $ cat typecast_2.cocci @@ type T; T *foo; @@ - (T *)foo + foo Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Shahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26alx: Remove casts of pointer to same typeJoe Perches
Casting a pointer to a pointer of the same type is pointless, so remove these unnecessary casts. Done via coccinelle script: $ cat typecast_2.cocci @@ type T; T *foo; @@ - (T *)foo + foo Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26altera: Remove casts of pointer to same typeJoe Perches
Casting a pointer to a pointer of the same type is pointless, so remove these unnecessary casts. Done via coccinelle script: $ cat typecast_2.cocci @@ type T; T *foo; @@ - (T *)foo + foo Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Vince Bridgers <vbridgers2013@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26chelsio: Remove addressof casts to same typeJoe Perches
Using addressof then casting to the original type is pointless, so remove these unnecessary casts. Done via coccinelle script: $ cat typecast.cocci @@ type T; T foo; @@ - (T *)&foo + &foo Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26smsc911x: No need to print driver versionFabio Estevam
Having the kernel to print: "smsc911x: Driver version 2008-10-21" on every boot is not very useful, so remove the print of the driver version. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26smsc911x: Do not use netdev_dbg() when device is not registeredFabio Estevam
With debug enabled we get the following message: smsc911x smsc911x (unregistered net_device): couldn't get clock -2 As the device has not been registered at this point, it is better to use dev_dbg() instead of netdev_dbg(). CC: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Suggested-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26x86, efi: Abstract x86 efi_early callsMatt Fleming
The ARM EFI boot stub doesn't need to care about the efi_early infrastructure that x86 requires in order to do mixed mode thunking. So wrap everything up in an efi_call_early() macro. This allows x86 to do the necessary indirection jumps to call whatever firmware interface is necessary (native or mixed mode), but also allows the ARM folks to mask the fact that they don't support relocation in the boot stub and need to pass 'sys_table_arg' to every function. [ hpa: there are no object code changes from this patch ] Signed-off-by: Matt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/r/20140326091011.GB2958@console-pimps.org Cc: Roy Franz <roy.franz@linaro.org> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2014-03-26Merge remote-tracking branches 'regulator/topic/tps65218', ↵Mark Brown
'regulator/topic/tps6524x', 'regulator/topic/tps6586x', 'regulator/topic/tps65910', 'regulator/topic/tps80031', 'regulator/topic/wm831x', 'regulator/topic/wm8350' and 'regulator/topic/wm8994' into regulator-next
2014-03-26Merge remote-tracking branches 'regulator/topic/s5m8767', ↵Mark Brown
'regulator/topic/st-pwm', 'regulator/topic/ti-abb', 'regulator/topic/tps51632', 'regulator/topic/tps62360', 'regulator/topic/tps6507x', 'regulator/topic/tps65090' and 'regulator/topic/tps65217' into regulator-next
2014-03-26Merge remote-tracking branches 'regulator/topic/max8973', ↵Mark Brown
'regulator/topic/max8997', 'regulator/topic/max8998', 'regulator/topic/mc13xxx', 'regulator/topic/pfuze100', 'regulator/topic/rc5t583' and 'regulator/topic/s2mps11' into regulator-next
2014-03-26Merge remote-tracking branches 'regulator/topic/max1586', ↵Mark Brown
'regulator/topic/max77686', 'regulator/topic/max77693', 'regulator/topic/max8649', 'regulator/topic/max8660', 'regulator/topic/max8907', 'regulator/topic/max8925' and 'regulator/topic/max8952' into regulator-next
2014-03-26Merge remote-tracking branches 'regulator/topic/doc', ↵Mark Brown
'regulator/topic/enable', 'regulator/topic/fan53555', 'regulator/topic/fixed', 'regulator/topic/gpio', 'regulator/topic/lp3971', 'regulator/topic/lp872x' and 'regulator/topic/max14577' into regulator-next
2014-03-26Merge remote-tracking branches 'regulator/topic/bcm590xx', ↵Mark Brown
'regulator/topic/da9052', 'regulator/topic/da9055', 'regulator/topic/da9063', 'regulator/topic/da9210', 'regulator/topic/db8500' and 'regulator/topic/dbx500' into regulator-next
2014-03-26Merge remote-tracking branches 'regulator/topic/88pm800', ↵Mark Brown
'regulator/topic/88pm8607', 'regulator/topic/aat2870', 'regulator/topic/act8865', 'regulator/topic/anatop', 'regulator/topic/arizona', 'regulator/topic/as3711' and 'regulator/topic/as3722' into regulator-next
2014-03-26Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2014-03-26regulator: aat2870: Use regulator_map_voltage_ascendAxel Lin
The voltages in aat2870_ldo_voltages table are in ascendant order, so use regulator_map_voltage_ascend. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-03-26ata: fix ARASAN CompactFlash PATA driver dependenciesBartlomiej Zolnierkiewicz
Make pata_arasan_cf host driver depend on ARCH_SPEAR13XX config option as ARASAN CompactFlash PATA support is specific to ST SPEAr13xx SoCs and the driver to work requires suitable device tree node (or platform device) to be defined. Additionally allow the driver build if COMPILE_TEST config option is set. Cc: Viresh Kumar <viresh.linux@gmail.com> Cc: Shiraz Hashim <shiraz.hashim@st.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-03-26spi: omap-uwire: Remove full duplex checkAxel Lin
This driver sets the SPI_MASTER_HALF_DUPLEX flag, so the spi core will check transfers to ensure they are not full duplex. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-03-26ata: remove superfluous castsJoe Perches
Unreferenced casts of void * types are unnecessary so remove them. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-03-26ata: sata_highbank: remove superfluous castBartlomiej Zolnierkiewicz
hpriv->plat_data is 'void *' so there is no need to cast it to 'struct ecx_plat_data *'. Cc: Mark Langsdorf <mark.langsdorf@calxeda.com> Cc: Rob Herring <robh@kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-03-26cpufreq: Make cpufreq_notify_transition & cpufreq_notify_post_transition staticViresh Kumar
cpufreq_notify_transition() and cpufreq_notify_post_transition() shouldn't be called directly by cpufreq drivers anymore and so these should be marked static. Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}Viresh Kumar
CPUFreq core has new infrastructure that would guarantee serialized calls to target() or target_index() callbacks. These are called cpufreq_freq_transition_begin() and cpufreq_freq_transition_end(). This patch converts existing drivers to use these new set of routines. Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26cpufreq: Make sure frequency transitions are serializedSrivatsa S. Bhat
Whenever we change the frequency of a CPU, we call the PRECHANGE and POSTCHANGE notifiers. They must be serialized, i.e. PRECHANGE and POSTCHANGE notifiers should strictly alternate, thereby preventing two different sets of PRECHANGE or POSTCHANGE notifiers from interleaving arbitrarily. The following examples illustrate why this is important: Scenario 1: ----------- A thread reading the value of cpuinfo_cur_freq, will call __cpufreq_cpu_get()->cpufreq_out_of_sync()->cpufreq_notify_transition() The ondemand governor can decide to change the frequency of the CPU at the same time and hence it can end up sending the notifications via ->target(). If the notifiers are not serialized, the following sequence can occur: - PRECHANGE Notification for freq A (from cpuinfo_cur_freq) - PRECHANGE Notification for freq B (from target()) - Freq changed by target() to B - POSTCHANGE Notification for freq B - POSTCHANGE Notification for freq A We can see from the above that the last POSTCHANGE Notification happens for freq A but the hardware is set to run at freq B. Where would we break then?: adjust_jiffies() in cpufreq.c & cpufreq_callback() in arch/arm/kernel/smp.c (which also adjusts the jiffies). All the loops_per_jiffy calculations will get messed up. Scenario 2: ----------- The governor calls __cpufreq_driver_target() to change the frequency. At the same time, if we change scaling_{min|max}_freq from sysfs, it will end up calling the governor's CPUFREQ_GOV_LIMITS notification, which will also call __cpufreq_driver_target(). And hence we end up issuing concurrent calls to ->target(). Typically, platforms have the following logic in their ->target() routines: (Eg: cpufreq-cpu0, omap, exynos, etc) A. If new freq is more than old: Increase voltage B. Change freq C. If new freq is less than old: decrease voltage Now, if the two concurrent calls to ->target() are X and Y, where X is trying to increase the freq and Y is trying to decrease it, we get the following race condition: X.A: voltage gets increased for larger freq Y.A: nothing happens Y.B: freq gets decreased Y.C: voltage gets decreased X.B: freq gets increased X.C: nothing happens Thus we can end up setting a freq which is not supported by the voltage we have set. That will probably make the clock to the CPU unstable and the system might not work properly anymore. This patch introduces a set of synchronization primitives to serialize frequency transitions, which are to be used as shown below: cpufreq_freq_transition_begin(); //Perform the frequency change cpufreq_freq_transition_end(); The _begin() call sends the PRECHANGE notification whereas the _end() call sends the POSTCHANGE notification. Also, all the necessary synchronization is handled within these calls. In particular, even drivers which set the ASYNC_NOTIFICATION flag can also use these APIs for performing frequency transitions (ie., you can call _begin() from one task, and call the corresponding _end() from a different task). The actual synchronization underneath is not that complicated: The key challenge is to allow drivers to begin the transition from one thread and end it in a completely different thread (this is to enable drivers that do asynchronous POSTCHANGE notification from bottom-halves, to also use the same interface). To achieve this, a 'transition_ongoing' flag, a 'transition_lock' spinlock and a wait-queue are added per-policy. The flag and the wait-queue are used in conjunction to create an "uninterrupted flow" from _begin() to _end(). The spinlock is used to ensure that only one such "flow" is in flight at any given time. Put together, this provides us all the necessary synchronization. Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26ata: fix Calxeda Highbank SATA driver dependenciesBartlomiej Zolnierkiewicz
Make sata_highbank host driver depend on ARCH_HIGHBANK config option as Calxeda Highbank SATA support is specific to Calxeda Highbank SoCs and the driver to work requires suitable device tree node to be defined. Additionally allow the driver build if COMPILE_TEST config option is set. Cc: Mark Langsdorf <mark.langsdorf@calxeda.com> Cc: Rob Herring <robh@kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-03-26intel_pstate: Use del_timer_sync in intel_pstate_cpu_stopDirk Brandewie
Ensure that no timer callback is running since we are about to free the timer structure. We cannot guarantee that the call back is called on the CPU where the timer is running. Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26cpufreq: resume drivers before enabling governorsViresh Kumar
During suspend, we first stop governors and then suspend cpufreq drivers and resume must be exactly opposite of that. i.e. resume drivers first and then start governors. But the current code in resume enables governors first and then resume drivers. Fix it be changing code sequence there. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26PM / Runtime: Spelling s/competing/completing/Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26Revert "ACPI / processor: Make it possible to get APIC ID via GIC"Hanjun Guo
Revert commit df86f5df79d8 (ACPI / processor: Make it possible to get APIC ID via GIC). APIC ID refers the hardware ID of the CPU, which means MPIDR on ARM/ARM64, but in ACPI 5.0, GIC ID feild in GIC structure have no explicit definition and may not refer to the MPIDR. Commit df86f5df79d8 assumed that gic->gic_id as MPIDR which may not be the case, so revert it until the explicit definition of GIC structure is ready. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26ACPICA: Enable auto-serialization as a default kernel behavior.Lv Zheng
The previous commit "ACPICA: Add auto-serialization support for ill-behaved control methods" introduced the auto-serialization facility as a workaround that can be enabled by "acpi_auto_serialize": This feature marks control methods that create named objects as "serialized" to avoid unwanted AE_ALREADY_EXISTS control method evaluation failures. Enable method auto-serialization as the default kernel behavior. The new kernel parameter is also changed from "acpi_auto_serialize" to "acpi_no_auto_serialize" to reflect the default behavior. References: https://bugzilla.kernel.org/show_bug.cgi?id=52191 References: http://www.spinics.net/lists/linux-acpi/msg49496.html Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26ACPICA: Ignore sync_level for methods that have been auto-serialized.Bob Moore
Cannot use a sync_level for methods that have been serialized at load-time or runtime because this may interfere with any existing use of sync_levels within the ASL code. So, we simply ignore the sync_level for these methods, thus preserving any existing sync_level priorities. Note, the use of sync_levels is actually rather rare within BIOS ASL code. References: http://www.spinics.net/lists/linux-acpi/msg49496.html Reported-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Reported-by: Sabrina Dubroka <sd@queasysnail.net> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26ACPICA: Add additional named objects for the auto-serialize method scan.Lv Zheng
This change adds some additional opcodes that are detected and will cause a method to be auto-serialized. These opcodes are the various CreateXField and the FieldUnit opcodes. Lv Zheng. References: https://bugzilla.kernel.org/show_bug.cgi?id=52191 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26ACPICA: Add auto-serialization support for ill-behaved control methods.Bob Moore
This change adds support to automatically mark a control method as "serialized" if the method creates any named objects. This will positively prevent the method from being entered by more than one thread and thus preventing a possible abort when an attempt is made to create an object twice. Implemented by parsing all non-serialize control methods at table load time. This feature is disabled by default and this patch also adds a new Linux kernel parameter "acpi_auto_serialize" to allow this feature to be turned on for a specific boot. References: https://bugzilla.kernel.org/show_bug.cgi?id=52191 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26ACPICA: Remove global option to serialize all control methods.Lv Zheng
According to the reports, the "acpi_serialize" mechanism is broken as: A. The parallel method calls can still happen when the interpreter lock is released under the following conditions: 1. External callbacks are invoked, for example, by the region handlers, the exception handlers, etc.; 2. Module level execution is performed when Load/LoadTable opcodes are executed, and 3. The _REG control methods are invoked to complete the region registrations. B. For the following situations, the interpreter lock need to be released even for a serialized method while currently, the lock-releasing operation is marked as a no-op by acpi_ex_relinquish/reacquire_interpreter() when this mechanism is enabled: 1. Wait opcode is executed, 2. Acquire opcode is executed, and 3. Sleep opcode is executed. This patch removes this mechanism and the internal acpi_ex_relinquish/reacquire_interpreter() APIs. Lv Zheng. References: https://bugzilla.kernel.org/show_bug.cgi?id=52191 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26ata: fix R-Car SATA driver dependenciesBartlomiej Zolnierkiewicz
Make sata_rcar host driver depend on ARCH_SHMOBILE config option as Renesas R-Car SATA support is specific to Renesas SoCs and the driver to work requires suitable device tree node (or platform device) to be defined. Additionally allow the driver build if COMPILE_TEST config option is set. Cc: Simon Horman <horms@verge.net.au> Cc: Magnus Damm <magnus.damm@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-03-26s390/con3270: optionally disable auto updateMartin Schwidefsky
This patch adds a parameter 'auto_update' to the con3270 driver, causing the 'auto_update' feature to be disabled if unset. The 'auto_update' feature will cause the con3270 driver to switch to the console view whenever new system messages are displayed, which makes working on the 3270 terminal awkward. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-03-25Revert "sysfs, driver-core: remove unused ↵Greg Kroah-Hartman
{sysfs|device}_schedule_callback_owner()" This reverts commit d1ba277e79889085a2faec3b68b91ce89c63f888. As reported by Stephen, this patch breaks linux-next as a ppc patch suddenly (after 2 years) started using this old api call. So revert it for now, it will go away in 3.15-rc2 when we can change the PPC call to the new api. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Tejun Heo <tj@kernel.org> Cc: Stewart Smith <stewart@linux.vnet.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-25bnx2x: Don't allow VFs to become promiscuousYuval Mintz
Currently, if a VF's Rx Mode will be configured to support promiscuous mode the PF will comply, causing the VF to actually become promiscuous. This will enable the VF to see all unicast traffic which might be intended for other VMs, which we believe should not be possible. This patch will cause the hypervisor to ignore the VF's request for changes in its Rx mode (other than disabling it), preventing it from becoming promiscuous. Reported-by: Yoann Juet <yoann.juet@univ-nantes.fr> Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-25bnx2x: Don't show port statistics for VFsYuval Mintz
VFs are currently showing port statistics, although they can't really access those - thus all such statistics will always show a value of 0. This patch removes said statistics from the VF's view as to not confuse the user. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-25bnx2x: Remove the sriov VFOP mechanismYuval Mintz
Since we now posses a workqueue dedicated for sriov, the paradigm that sriov- related tasks cannot sleep is no longer correct. The VFOP mechanism was the one previously supporting said paradigm - the sriov related tasks were broken into segments which did not require sleep, and the mechanism re-scheduled the next segment whenever possible. This patch remvoes the VFOP mechanism altogether - the resulting code is a much easier to follow code; The segments are gathered into straight-forward functions which sleep whenever neccessary. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-25bnx2x: Create workqueue for IOV related tasksYuval Mintz
The bnx2x sriov mechanisms were done in the bnx2x slowpath workitem which runs on the bnx2x's workqueue; This workitem is also responsible for the bottom half of interrupt handling in the driver, and specifically it also receives FW notifications of ramrod completions, allowing other flows to progress. The original design of the sriov reltaed-flows was based on the notion such flows must not sleep, since their context is the slowpath workitem. Otherwise, we might reach timeouts - those flows may wait for ramrod completion that will never arrive as the workitem wlll not be re-scheduled until that same flow will be over. In more recent time bnx2x started supporting features in which the VF interface can be configured by the tools accessing the PF on the hypervisor. This support created possible races on the VF-PF lock (which is taken either when the PF is handling a VF message or when the PF is doing some slowpath work on behalf of the VF) which may cause timeouts on the VF side and lags on the PF side. This patch changes the scheme - it creates a new workqueue for sriov related tasks and moves all handling currently done in the slowpath task into the the new workqueue. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-25bnx2x: Support mng. request for driver versionYuval Mintz
This adds support in a new management feature which needs the driver versions (bnx2x, bnx2fc and bnx2i) loaded for each interface. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-25atm: idt77105: Use del_timer_sync() in exit pathThomas Gleixner
The module is about to go away. Make sure everything is stopped safely before we pull the plug. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Chas Williams <chas@cmf.nrl.navy.mil> Cc: atm <linux-atm-general@lists.sourceforge.net> Cc: netdev <netdev@vger.kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-25atm: firestream: Use del_timer_sync() in teardown pathThomas Gleixner
The device is about to vanish. So we need to make sure that the timer is completely stopped and the callback is not running on another CPU. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Chas Williams <chas@cmf.nrl.navy.mil> Cc: atm <linux-atm-general@lists.sourceforge.net> Cc: netdev <netdev@vger.kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-25mlx4: Use actual number of PCI functions (PF + VFs) for alias GUID logicMatan Barak
The code which is dealing with SRIOV alias GUIDs in the mlx4 IB driver has some logic which operated according to the maximal possible active functions (PF + VFs). After the single port VFs code integration this resulted in a flow of false-positive warnings going to the kernel log after the PF driver started the alias GUID work. Fix it by referring to the actual number of functions. Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Conflicts: Documentation/devicetree/bindings/net/micrel-ks8851.txt net/core/netpoll.c The net/core/netpoll.c conflict is a bug fix in 'net' happening to code which is completely removed in 'net-next'. In micrel-ks8851.txt we simply have overlapping changes. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controllerCarlo Caione
Allwinner A20/A31 SoCs have special registers to control / (un)mask / acknowledge NMI. This NMI controller is separated and independent from GIC. This patch adds a new irqchip to manage NMI. Signed-off-by: Carlo Caione <carlo@caione.org> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-sunxi@googlegroups.com Cc: mark.rutland@arm.com Cc: hdegoede@redhat.com Link: http://lkml.kernel.org/r/1395256879-8475-2-git-send-email-carlo@caione.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-03-25Merge branch 'for-davem' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next John W. Linville says: ==================== Please pull this batch of wireless updates intended for 3.15! For the mac80211 bits, Johannes says: "This has a whole bunch of bugfixes for things that went into -next previously as well as some other bugfixes I didn't want to rush into 3.14 at this point. The rest of it is some cleanups and a few small features, the biggest of which is probably Janusz's regulatory DFS CAC time code." For the Bluetooth bits, Gustavo says: "One more pull request to 3.15. This is mostly and bug fix pull request, it contains several fixes and clean up all over the tree, plus some small new features." For the NFC bits, Samuel says: "This is the NFC pull request for 3.15. With this one we have: - Support for ISO 15693 a.k.a. NFC vicinity a.k.a. Type 5 tags. ISO 15693 are long range (1 - 2 meters) vicinity tags/cards. The kernel now supports those through the NFC netlink and digital APIs. - Support for TI's trf7970a chipset. This chipset relies on the NFC digital layer and the driver currently supports type 2, 4A and 5 tags. - Support for NXP's pn544 secure firmare download. The pn544 C3 chipsets relies on a different firmware download protocal than the C2 one. We now support both and use the right one depending on the version we detect at runtime. - Support for 4A tags from the NFC digital layer. - A bunch of cleanups and minor fixes from Axel Lin and Thierry Escande." For the iwlwifi bits, Emmanuel says: "We were sending a host command while the mutex wasn't held. This led to hard-to-catch races." And... "I have a fix for a "merge damage" which is not really a merge damage: it enables scheduled scan which has been disabled in wireless.git. Since you merged wireless.git into wireless-next.git, this can now be fixed in wireless-next.git. Besides this, Alex made a workaround for a hardware bug. This fix allows us to consume less power in S3. Arik and Eliad continue to work on D0i3 which is a run-time power saving feature. Eliad also contributes a few bits to the rate scaling logic to which Eyal adds his own contribution. Avri dives deep in the power code - newer firmware will allow to enable power save in newer scenarios. Johannes made a few clean-ups. I have the regular amount of BT Coex boring stuff. I disable uAPSD since we identified firmware bugs that cause packet loss. One thing that do stand out is the udev event that we now send when the FW asserts. I hope it will allow us to debug the FW more easily." Also included is one last iwlwifi pull for a build breakage fix... For the Atheros bits, Kalle says: "Michal now did some optimisations and was able to improve throughput by 100 Mbps on our MIPS based AP135 platform. Chun-Yeow added some workarounds to be able to better use ad-hoc mode. Ben improved log messages and added support for MSDU chaining. And, as usual, also some smaller fixes." Beyond that... Andrea Merello continues his rtl8180 refactoring, in preparation for a long-awaited rtl8187 driver. We get a new driver (rsi) for the RS9113 chip, from Fariya Fatima. And, of course, we get the usual round of updates for ath9k, brcmfmac, mwifiex, wil6210, etc. as well. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>