summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2017-01-02usb: dwc2: fix default value for DMA supportStefan Wahren
The current defaults for DMA results on a non-DMA platform in a unnecessary error message: Invalid value 0 for param gadget-dma So fix this by using dma_capable as default value. Fixes: 9962b62f1be ("usb: dwc2: Deprecate g-use-dma binding") Acked-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2017-01-02usb: dwc2: fix dwc2_get_device_property for u8 and u16Stefan Wahren
According to the Devicetree ePAPR [1] the datatypes u8 and u16 are not defined. So using device_property_read_u16() would result in a partial read of a 32-bit big-endian integer which is not intended. So we better read the complete 32-bit value. This fixes a regression on bcm2835 where the values for g-rx-fifo-size and g-np-tx-fifo-size always read as zero: Invalid value 0 for param g-rx-fifo-size Invalid value 0 for param g-np-tx-fifo-size [1] - http://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf Fixes: 05ee799f202 ("usb: dwc2: Move gadget settings into core_params") Acked-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2017-01-02usb: dwc2: Do not set host parameter in peripheral modeStefan Wahren
Since commit "usb: dwc2: Improve handling of host and device hwparams" the host mode specific hardware parameter aren't initialized in peripheral mode from the register settings anymore. So we better do not set them in this case which avoids the following warnings on bcm2835: 256 invalid for host_nperio_tx_fifo_size. Check HW configuration. 512 invalid for host_perio_tx_fifo_size. Check HW configuration. Fixes: 55e1040e424b ("usb: dwc2: Improve handling of host and device hwparams") Acked-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-12-31PM / domains: Fix 'may be used uninitialized' build warningAugusto Mecking Caringi
This patch fixes the following gcc warning: drivers/base/power/domain.c: In function ‘genpd_runtime_resume’: drivers/base/power/domain.c:642:14: warning: ‘time_start’ may be used uninitialized in this function [-Wmaybe-uninitialized] elapsed_ns = ktime_to_ns(ktime_sub(ktime_get(), time_start) The same problem (in another function in this same file) was fixed in commit d33d5a6c88fc (avoid spurious "may be used uninitialized" warning) Signed-off-by: Augusto Mecking Caringi <augustocaringi@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-31cpufreq: intel_pstate: Always keep all limits settings in syncRafael J. Wysocki
Make intel_pstate update per-logical-CPU limits when the global settings are changed to ensure that they are always in sync and users will not see confusing values in per-logical-CPU sysfs attributes. This also fixes the problem that setting the "no_turbo" global attribute to 1 in the "passive" mode (ie. when intel_pstate acts as a regular cpufreq driver) when scaling_governor is set to "performance" has no effect. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2016-12-31cpufreq: intel_pstate: Use locking in intel_cpufreq_verify_policy()Rafael J. Wysocki
Race conditions are possible if intel_cpufreq_verify_policy() is executed in parallel with global limits updates from sysfs, so the invocation of intel_pstate_update_perf_limits() in it should be carried out under intel_pstate_limits_lock. Make that happen. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2016-12-31cpufreq: intel_pstate: Use locking in intel_pstate_resume()Rafael J. Wysocki
Theoretically, intel_pstate_resume() may be executed in parallel with intel_pstate_set_policy(), if the latter is invoked via cpufreq_update_policy() as a result of a notification, so use intel_pstate_limits_lock in there too to avoid race conditions. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2016-12-31iio: accel: st_accel: fix LIS3LV02 reading and scalingLinus Walleij
The LIS3LV02 has a special bit that need to be set to get the read values left aligned. Before this patch we get gibberish like this: iio_generic_buffer -a -c10 -n lis3lv02dl_accel (...) 0.000000 -0.010042 -0.642688 19155832931907 0.000000 -0.010042 -0.642688 19155858751073 Which is because we read a raw value for 1g as 64 which is the nominal 1024 for 1g shifted 4 bits to the left by being right-aligned rather than left aligned. Since all other sensors are left aligned, add some code to set the special DAS (data alignment setting) bit to 1 so that the right value is now read like this: iio_generic_buffer -a -c10 -n lis3lv02dl_accel (...) 0.000000 -0.147095 -10.120135 24761614364956 -0.029419 -0.176514 -10.120135 24761631624540 The scaling was weird as well: we have a gain of 1000 for 1g and 3000 for 6g. I don't even remember how I came up with the old values but they are wrong. Fixes: 3acddf74f807 ("iio: st-sensors: add support for lis3lv02d accelerometer") Cc: Lorenzo Bianconi <lorenzo.bianconi@st.com> Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-12-31iio: common: st_sensors: fix channel data parsingLorenzo Bianconi
Using realbits as i2c/spi read len, when that value is not byte aligned (e.g 12 bits), lead to skip msb part of out data registers. Fix this taking into account scan_type.shift in addition to scan_type.realbits as read length: read_len = DIV_ROUND_UP(realbits + shift, 8) This fix has been tested on 8, 12, 16, 24 bit sensors Fixes: e7385de5291e ("iio:st_sensors: align on storagebits boundaries") Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-12-30iio: max44000: correct value in illuminance_integration_time_availableAkinobu Mita
According to the datasheet, the shortest available integration time for ALS ADC conversion is 1.5625ms but illuminance_integration_time_available sysfs file shows wrong value. Cc: Crestez Dan Leonard <leonard.crestez@intel.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Fixes: d5d8f49b6 ("max44000: Expose ambient sensor scaling") Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-12-30iio: adc: TI_AM335X_ADC should depend on HAS_DMAGeert Uytterhoeven
If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/iio/adc/ti_am335x_adc.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: f438b9da (" drivers: iio: ti_am335x_adc: add dma support") Cc: <stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-12-30vfio-pci: use 32-bit comparisons for register address for gcc-4.5Arnd Bergmann
Using ancient compilers (gcc-4.5 or older) on ARM, we get a link failure with the vfio-pci driver: ERROR: "__aeabi_lcmp" [drivers/vfio/pci/vfio-pci.ko] undefined! The reason is that the compiler tries to do a comparison of a 64-bit range. This changes it to convert to a 32-bit number explicitly first, as newer compilers do for themselves. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-12-30vfio-mdev: Make mdev_device private and abstract interfacesAlex Williamson
Abstract access to mdev_device so that we can define which interfaces are public rather than relying on comments in the structure. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Jike Song <jike.song@intel.com> Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>
2016-12-30vfio-mdev: Make mdev_parent privateAlex Williamson
Rather than hoping for good behavior by marking some elements internal, enforce it by making the entire structure private and creating an accessor function for the one useful external field. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Jike Song <jike.song@intel.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>
2016-12-30vfio-mdev: de-polute the namespace, rename parent_device & parent_opsAlex Williamson
Add an mdev_ prefix so we're not poluting the namespace so much. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Jike Song <jike.song@intel.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>
2016-12-30vfio-mdev: Fix remove raceAlex Williamson
Using the mtty mdev sample driver we can generate a remove race by starting one shell that continuously creates mtty devices and several other shells all attempting to remove devices, in my case four remove shells. The fault occurs in mdev_remove_sysfs_files() where the passed type arg is NULL, which suggests we've received a struct device in mdev_device_remove() but it's in some sort of teardown state. The solution here is to make use of the accidentally unused list_head on the mdev_device such that the mdev core keeps a list of all the mdev devices. This allows us to validate that we have a valid mdev before we start removal, remove it from the list to prevent others from working on it, and if the vendor driver refuses to remove, we can re-add it to the list. Cc: Kirti Wankhede <kwankhede@nvidia.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-12-30vfio/type1: Restore mapping performance with mdev supportAlex Williamson
As part of the mdev support, type1 now gets a task reference per vfio_dma and uses that to get an mm reference for the task while working on accounting. That's correct, but it's not fast. For some paths, like vfio_pin_pages_remote(), we know we're only called from user context, so we can restore the lighter weight calls. In other cases, we're effectively already testing whether we're in the stored task context elsewhere, extend this vfio_lock_acct() as well. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>
2016-12-30firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI firmwaresMartin Blumenstingl
The pre-1.0 SCPI firmwares are using single __le32 as sensor value, while the SCPI v1.0 protocol uses two __le32 as sensor values(64bit) split into 32bit upper and 32bit lower value. Using an "struct sensor_value" to read the sensor value on a pre-1.0 SCPI firmware gives garbage in the "hi_val" field. This patch fixes the issue by reading only the lower 32-bit value for all pre-1.0 SCPI versions. Suggested-by: Sudeep Holla <Sudeep.Holla@arm.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> [sudeep.holla@arm.com: updated the commit log to reflect the implementation] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2016-12-30pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for Exynos5433Chanwoo Choi
This patch fixes the wrong width of PINCFG_TYPE_DRV bitfields for Exynos5433 because PINCFG_TYPE_DRV of Exynos5433 has 4bit fields in the *_DRV registers. Usually, other Exynos have 2bit field for PINCFG_TYPE_DRV. Fixes: 3c5ecc9ed353 ("pinctrl: exynos: Add support for Exynos5433") Cc: stable@vger.kernel.org Cc: Tomasz Figa <tomasz.figa@gmail.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Kukjin Kim <kgene@kernel.org> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-30iio: bmi160: Fix time needed to sleep after command executionMarcin Niestroj
Datasheet specifies typical and maximum execution times for which CMD register is occupied after previous command execution. We took these values as minimum and maximum time for usleep_range() call before making a new command execution. To be sure, that the CMD register is no longer occupied we need to wait *at least* the maximum time specified by datasheet. Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-12-29sh_eth: fix branch prediction in sh_eth_interrupt()Sergei Shtylyov
IIUC, likely()/unlikely() should apply to the whole *if* statement's expression, not a part of it -- fix such expression in sh_eth_interrupt() accordingly... Fixes: 283e38db65e7 ("sh_eth: Fix serialisation of interrupt disable with interrupt & NAPI handlers") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-29pinctrl: meson: fix gpio request disabling other modesNeil Armstrong
The pinctrl_gpio_request is called with the "full" gpio number, already containing the base, then meson_pmx_request_gpio is then called with the final pin number. Remove the base addition when calling meson_pmx_disable_other_groups. Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs") CC: Beniamino Galvani <b.galvani@gmail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Kevin Hilman <khilman@baylibre.com> Acked-by: Beniamino Galvani <b.galvani@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-29pinctrl/amd: Set the level based on ACPI tablesShyam Sundar S K
In the function amd_gpio_irq_set_type, read the values from the ACPI table to set the level and drop the settings passed by the client. Cc: <stable@vger.kernel.org> # 4.8.x+ Reviewed-by: Pankaj Sen <Pankaj.Sen@amd.com> Reviewed-by: Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@amd.com> Reviewed-by: Shah, Nehal-bakulchandra <Nehal-bakulchandra.Shah@amd.com> Signed-off-by: Shyam-sundar S-k <Shyam-sundar.S-k@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-29net/mlx4_core: Fix raw qp flow steering rules under SRIOVJack Morgenstein
Demoting simple flow steering rule priority (for DPDK) was achieved by wrapping FW commands MLX4_QP_FLOW_STEERING_ATTACH/DETACH for the PF as well, and forcing the priority to MLX4_DOMAIN_NIC in the wrapper function for the PF and all VFs. In function mlx4_ib_create_flow(), this change caused the main rule creation for the PF to be wrapped, while it left the associated tunnel steering rule creation unwrapped for the PF. This mismatch caused rule deletion failures in mlx4_ib_destroy_flow() for the PF when the detach wrapper function did not find the associated tunnel-steering rule (since creation of that rule for the PF did not go through the wrapper function). Fix this by setting MLX4_QP_FLOW_STEERING_ATTACH/DETACH to be "native" (so that the PF invocation does not go through the wrapper), and perform the required priority demotion for the PF in the mlx4_ib_create_flow() code path. Fixes: 48564135cba8 ("net/mlx4_core: Demote simple multicast and broadcast flow steering rules") Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-29net/mlx4_en: Fix type mismatch for 32-bit systemsSlava Shwartsman
is_power_of_2 expects unsigned long and we pass u64 max_val_cycles, this will be truncated on 32 bit systems, and the result is not what we were expecting. div_u64 expects u32 as a second argument and we pass max_val_cycles_rounded which is u64 hence it will always be truncated. Fix was tested on both 64 and 32 bit systems and got same results for max_val_cycles and max_val_cycles_rounded. Fixes: 4850cf458157 ("net/mlx4_en: Resolve dividing by zero in 32-bit system") Signed-off-by: Slava Shwartsman <slavash@mellanox.com> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-29net/mlx4: Remove BUG_ON from ICM allocation routineLeon Romanovsky
This patch removes BUG_ON() macro from mlx4_alloc_icm_coherent() by checking DMA address alignment in advance and performing proper folding in case of error. Fixes: 5b0bf5e25efe ("mlx4_core: Support ICM tables in coherent memory") Reported-by: Ozgur Karatas <okaratas@member.fsf.org> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-29net/mlx4_en: Fix bad WQE issueEugenia Emantayev
Single send WQE in RX buffer should be stamped with software ownership in order to prevent the flow of QP in error in FW once UPDATE_QP is called. Fixes: 9f519f68cfff ('mlx4_en: Not using Shared Receive Queues') Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-29net/mlx4_core: Use-after-free causes a resource leak in flow-steering detachJack Morgenstein
mlx4_QP_FLOW_STEERING_DETACH_wrapper first removes the steering rule (which results in freeing the rule structure), and then references a field in this struct (the qp number) when releasing the busy-status on the rule's qp. Since this memory was freed, it could reallocated and changed. Therefore, the qp number in the struct may be incorrect, so that we are releasing the incorrect qp. This leaves the rule's qp in the busy state (and could possibly release an incorrect qp as well). Fix this by saving the qp number in a local variable, for use after removing the steering rule. Fixes: 2c473ae7e582 ("net/mlx4_core: Disallow releasing VF QPs which have steering rules") Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-29net: stmmac: Fix error path after register_netdev moveFlorian Fainelli
Commit 5701659004d6 ("net: stmmac: Fix race between stmmac_drv_probe and stmmac_open") re-ordered how the MDIO bus registration and the network device are registered, but missed to unwind the MDIO bus registration in case we fail to register the network device. Fixes: 5701659004d6 ("net: stmmac: Fix race between stmmac_drv_probe and stmmac_open") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Kweh, Hock Leong <hock.leong.kweh@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net: wan: slic_ds26522: fix spelling mistake: "configurated" -> "configured"Colin Ian King
trivial fix to spelling mistake in pr_info message Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5e: Disable netdev after closeSaeed Mahameed
Disable netdev should come after it was closed, although no harm of doing it before -hence the MLX5E_STATE_DESTROYING bit- but it is more natural this way. Fixes: 26e59d8077a3 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks") Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Mohamad Haj Yahia <mohamad@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5e: Don't sync netdev state when not registeredSaeed Mahameed
Skip setting netdev vxlan ports and netdev rx_mode on driver load when netdev is not yet registered. Synchronizing with netdev state is needed only on reset flow where the netdev remains registered for the whole reset period. This also fixes an access before initialization of net_device.addr_list_lock - which for some reason initialized on register_netdev - where we queued set_rx_mode work on driver load before netdev registration. Fixes: 26e59d8077a3 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks") Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reported-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by: Mohamad Haj Yahia <mohamad@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5e: Check ets capability before initializing ets settingsHuy Nguyen
During the initial setup, the ets command is sent to firmware without checking if the HCA supports ets. This causes the invalid command error. Add the ets capiblity check before sending firmware command to initialize ets settings. Fixes: e207b7e99176 ("net/mlx5e: ConnectX-4 firmware support for DCBX") Signed-off-by: Huy Nguyen <huyn@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28Revert "net/mlx5e: Expose PCIe statistics to ethtool"Gal Pressman
This reverts commit 9c7262399ba12825f3ca4b00a76d8d5e77c720f5. PCIe counters were introduced in a new firmware version, as a result users with old firmware encountered a syndrome every 200ms due to update stats work. This feature will be re-introduced later with appropriate capabilities infrastructure. Fixes: 9c7262399ba1 ("net/mlx5e: Expose PCIe statistics to ethtool") Signed-off-by: Gal Pressman <galp@mellanox.com> Reported-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5: Prevent setting multicast macs for VFsMohamad Haj Yahia
Need to check that VF mac address entered by the admin user is either zero or unicast mac. Multicast mac addresses are prohibited. Fixes: 77256579c6b4 ('net/mlx5: E-Switch, Introduce Vport administration functions') Signed-off-by: Mohamad Haj Yahia <mohamad@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5: Release FTE lock in error flowMaor Gottlieb
Release the FTE lock when adding rule to the FTE has failed. Fixes: 0fd758d6112f ('net/mlx5: Don't unlock fte while still using it') Signed-off-by: Maor Gottlieb <maorg@mellanox.com> Reviewed-by: Mark Bloch <markb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5: Mask destination mac value in ethtool steering rulesMaor Gottlieb
We need to mask the destination mac value with the destination mac mask when adding steering rule via ethtool. Fixes: 1174fce8d1410 ('net/mlx5e: Support l3/l4 flow type specs in ethtool flow steering') Signed-off-by: Maor Gottlieb <maorg@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5: Avoid shadowing numa_nodeEli Cohen
Avoid using a local variable named numa_node to avoid shadowing a public one. Fixes: db058a186f98 ('net/mlx5_core: Set irq affinity hints') Signed-off-by: Eli Cohen <eli@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5: Cancel recovery work in remove flowDaniel Jurgens
If there is pending delayed work for health recovery it must be canceled if the device is being unloaded. Fixes: 05ac2c0b7438 ("net/mlx5: Fix race between PCI error handlers and health work") Signed-off-by: Daniel Jurgens <danielj@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5: Check FW limitations on log_max_qp before setting itNoa Osherovich
When setting HCA capabilities, set log_max_qp to be the minimum between the selected profile's value and the HCA limitation. Fixes: 938fe83c8dcb ('net/mlx5_core: New device capabilities...') Signed-off-by: Noa Osherovich <noaos@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28net/mlx5: Disable RoCE on the e-switch management port under switchdev modeOr Gerlitz
Under the switchdev/offloads mode, packets that don't match any e-switch steering rule are sent towards the e-switch management port. We use a NIC HW steering rule set per vport (uplink and VFs) to make them be received into the host OS through the respective vport representor netdevice. Currnetly such missed RoCE packets will not get to this NIC steering rule, and hence VF RoCE will not work over the slow path of the offloads mode. This is b/c these packets will be matched by a steering rule added by the firmware that serves RoCE traffic set on the PF NIC vport which is also the e-switch management port under SRIOV. Disabling RoCE on the e-switch management vport when we are in the offloads mode, will signal to the firmware to remove their RoCE rule, and then the missed RoCE packets will be matched by the representor NIC steering rule as any other missed packets. To achieve that, we disable RoCE on the PF vport. We do that by removing (hot-unplugging) the IB device instance associated with the PF. This is also required by our current model where the PF serves as the uplink representor and hence only SW switching (TC, bridge, OVS) applications and slow path vport mlx5e net-device should be running over that vport. Fixes: c930a3ad7453 ('net/mlx5e: Add devlink based SRIOV mode changes') Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-28platform/x86: fujitsu-laptop: use brightness_set_blocking for LED-setting ↵Micha? K?pie?
callbacks All LED-setting functions in fujitsu-laptop are currently assigned to the brightness_set callback, which is incorrect because they can sleep (due to their use of call_fext_func(), which in turn issues ACPI calls) and the documentation (in include/linux/leds.h) clearly states they must not. Assign them to brightness_set_blocking instead and change them to match the expected function prototype. This change makes it possible to use Fujitsu-specific LEDs with "heavy" triggers, like disk-activity or phy0rx. Fixes: 3a407086090b ("fujitsu-laptop: Add BL power, LED control and radio state information") Fixes: 4f62568c1fcf ("fujitsu-laptop: Support radio LED") Fixes: d6b88f64b0d4 ("fujitsu-laptop: Add support for eco LED") Signed-off-by: Michał Kępień <kernel@kempniu.pl> Acked-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-28platform/x86: fix surface3_button build errorsRandy Dunlap
Fix build errors when I2C=m and SURFACE_3_BUTTON=y. The driver uses i2c interfaces so it should depend on I2C. drivers/built-in.o: In function `surface3_driver_init': surface3_button.c:(.init.text+0x75cb0): undefined reference to `i2c_register_driver' drivers/built-in.o: In function `surface3_driver_exit': surface3_button.c:(.exit.text+0x31a8): undefined reference to `i2c_del_driver' Fixes: 1a64b719d3ae (platform/x86: Introduce button support for the Surface 3) Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kbuild test robot <fengguang.wu@intel.com> Cc: Benjamin Tissoires <benjamin.tissoires@gmail.com> Cc: platform-driver-x86@vger.kernel.org Cc: Darren Hart <dvhart@infradead.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-27net: stmmac: Fix race between stmmac_drv_probe and stmmac_openFlorian Fainelli
There is currently a small window during which the network device registered by stmmac can be made visible, yet all resources, including and clock and MDIO bus have not had a chance to be set up, this can lead to the following error to occur: [ 473.919358] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized): stmmac_dvr_probe: warning: cannot get CSR clock [ 473.919382] stmmaceth 0000:01:00.0: no reset control found [ 473.919412] stmmac - user ID: 0x10, Synopsys ID: 0x42 [ 473.919429] stmmaceth 0000:01:00.0: DMA HW capability register supported [ 473.919436] stmmaceth 0000:01:00.0: RX Checksum Offload Engine supported [ 473.919443] stmmaceth 0000:01:00.0: TX Checksum insertion supported [ 473.919451] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer [ 473.921395] libphy: PHY stmmac-1:00 not found [ 473.921417] stmmaceth 0000:01:00.0 eth0: Could not attach to PHY [ 473.921427] stmmaceth 0000:01:00.0 eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 473.959710] libphy: stmmac: probed [ 473.959724] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 0 IRQ POLL (stmmac-1:00) active [ 473.959728] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 1 IRQ POLL (stmmac-1:01) [ 473.959731] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 2 IRQ POLL (stmmac-1:02) [ 473.959734] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 3 IRQ POLL (stmmac-1:03) Fix this by making sure that register_netdev() is the last thing being done, which guarantees that the clock and the MDIO bus are available. Fixes: 4bfcbd7abce2 ("stmmac: Move the mdio_register/_unregister in probe/remove") Reported-by: Kweh, Hock Leong <hock.leong.kweh@intel.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-27Merge branch 'linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "This fixes a hash corruption bug in the marvell driver" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: marvell - Copy IVDIG before launching partial DMA ahash requests
2016-12-27Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds
Pull networking fixes from David Miller: 1) Various ipvlan fixes from Eric Dumazet and Mahesh Bandewar. The most important is to not assume the packet is RX just because the destination address matches that of the device. Such an assumption causes problems when an interface is put into loopback mode. 2) If we retry when creating a new tc entry (because we dropped the RTNL mutex in order to load a module, for example) we end up with -EAGAIN and then loop trying to replay the request. But we didn't reset some state when looping back to the top like this, and if another thread meanwhile inserted the same tc entry we were trying to, we re-link it creating an enless loop in the tc chain. Fix from Daniel Borkmann. 3) There are two different WRITE bits in the MDIO address register for the stmmac chip, depending upon the chip variant. Due to a bug we could set them both, fix from Hock Leong Kweh. 4) Fix mlx4 bug in XDP_TX handling, from Tariq Toukan. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: net: stmmac: fix incorrect bit set in gmac4 mdio addr register r8169: add support for RTL8168 series add-on card. net: xdp: remove unused bfp_warn_invalid_xdp_buffer() openvswitch: upcall: Fix vlan handling. ipv4: Namespaceify tcp_tw_reuse knob net: korina: Fix NAPI versus resources freeing net, sched: fix soft lockup in tc_classify net/mlx4_en: Fix user prio field in XDP forward tipc: don't send FIN message from connectionless socket ipvlan: fix multicast processing ipvlan: fix various issues in ipvlan_process_multicast()
2016-12-27net: stmmac: fix incorrect bit set in gmac4 mdio addr registerKweh, Hock Leong
Fixing the gmac4 mdio write access to use MII_GMAC4_WRITE only instead of OR together with MII_WRITE. Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com> Acked-By: Joao Pinto <jpinto@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-27r8169: add support for RTL8168 series add-on card.Chun-Hao Lin
This chip is the same as RTL8168, but its device id is 0x8161. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-27cpufreq: intel_pstate: Do not expose PID parameters in passive modeRafael J. Wysocki
If intel_pstate works in the passive mode in which it acts as a regular cpufreq driver and collaborates with generic cpufreq governors, the PID parameters are not used, so do not expose them via debugfs in that case. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-26ACPI / watchdog: Print out error number when device creation failsMika Westerberg
If the platform device creation fails for whichever reason the driver prints out something like: [ 0.978837] ACPI: watchdog: Failed to create platform device However, that is quite confusing and does not include any information why it failed. To make it more understandable, reword it like: [ 0.978837] ACPI: watchdog: Device creation failed: -16 Which tells that we failed to create the watchdog device because some of the resources were already reserved (-EBUSY). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit (git 2.34.1) at 2025-09-11 18:09:08 +0000