- 14 May, 2020 40 commits
-
-
David Rivshin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ae092b5b upstream. The phy-mode emac property was only being processed in the phy_id or fixed-link cases. However if phy-handle was specified instead, an error message would complain about the lack of phy_id or fixed-link, and then jump past the of_get_phy_mode(). This would result in the PHY mode defaulting to MII, regardless of what the devicetree specified. Fixes: 9e42f715 ("drivers: net: cpsw: add phy-handle parsing") Signed-off-by:
David Rivshin <drivshin@allworx.com> Tested-by:
Nicolas Chauvet <kwizart@gmail.com> Tested-by:
Andrew Goodbody <andrew.goodbody@cambrionix.com> Reviewed-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0d8f3c67 upstream. Make sure to drop the reference taken by of_parse_phandle() before returning from dsa_slave_phy_setup(). Note that this also modifies the PHY priority so that any fixed-link node is only parsed when no phy-handle is given, which is in accordance with the common scheme for this. Fixes: 0d8bcdd3 ("net: dsa: allow for more complex PHY setups") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Roosen Henri authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b4c19f71 upstream. Commit 651df218 ("phy: micrel: Fix finding PHY properties in MAC node.") only fixes finding PHY properties in MAC node for KSZ9021. This commit applies the same fix for KSZ9031. Fixes: 8b63ec18 ("phylib: Make PHYs children of their MDIO bus, not the bus' parent.") Acked-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Henri Roosen <henri.roosen@ginzinger.com> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 48c1699d upstream. Make sure to drop the of_node reference also on failure to parse the speed property in of_phy_register_fixed_link(). Fixes: 3be2a49e ("of: provide a binding for fixed link PHYs") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 50d89980 upstream. The clear and set masks in the call to phy_set_clr_bits() called from bcm7xxx_config_init() are inverted. We need to fix this by swapping the two arguments, that is, set 0 bits, but clear the shade mode 2 enable bit. Fixes: b560a58c ("net: phy: add Broadcom BCM7xxx internal PHY driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit deccd16f upstream. Commit 5ea94e76 ("phy: add phy_mac_interrupt()") to use with PHY_IGNORE_INTERRUPT added a cancel_work_sync() into phy_mac_interrupt() which is allowed to sleep, whereas phy_mac_interrupt() is expected to be callable from interrupt context. Now that we have fixed how the PHY state machine treats PHY_IGNORE_INTERRUPT with respect to state changes, we can just set the new link state, and queue the PHY state machine for execution so it is going to read the new link state. For that to work properly, we need to update phy_change() not to try to invoke any interrupt callbacks if we have configured the PHY device for PHY_IGNORE_INTERRUPT, because that PHY device and its driver are not required to implement those. Fixes: 5ea94e76 ("phy: add phy_mac_interrupt() to use with PHY_IGNORE_INTERRUPT") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit d5c3d846 upstream. Commit 2c7b4921 ("phy: fix the use of PHY_IGNORE_INTERRUPT") changed a hunk in phy_state_machine() in the PHY_RUNNING case which was not needed. The change essentially makes the PHY library treat PHY devices with PHY_IGNORE_INTERRUPT to keep polling for the PHY device, even though the intent is not to do it. Fix this by reverting that specific hunk, which makes the PHY state machine wait for state changes, and stay in the PHY_RUNNING state for as long as needed. Fixes: 2c7b4921 ("phy: fix the use of PHY_IGNORE_INTERRUPT") Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c6dc65d8 upstream. I've moved the check for "number_destination_params" forward a few lines to avoid leaking "cmd". Fixes: caa575a8 ('NFC: nci: fix possible crash in nci_core_conn_create') Acked-by:
Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Chuck Lever authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 4b9c7f9d upstream. Commit 176e21ee ("SUNRPC: Support for RPC over AF_LOCAL transports") added a 5-character netid, but did not bump RPCBIND_MAXNETIDLEN from 4 to 5. Fixes: 176e21ee ("SUNRPC: Support for RPC over AF_LOCAL ...") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Xin Long authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 39d2adeb upstream. prior to this patch, at the beginning if we have two paths in one assoc, they may have the same params other than the last_time_heard, it will try the paths like this: 1st cycle try trans1 fail. then trans2 is selected.(cause it's last_time_heard is after trans1). 2nd cycle: try trans2 fail then trans2 is selected.(cause it's last_time_heard is after trans1). 3rd cycle: try trans2 fail then trans2 is selected.(cause it's last_time_heard is after trans1). .... trans1 will never have change to be selected, which is not what we expect. we should keeping round robin all the paths if they are just added at the beginning. So at first every tranport's last_time_heard should be initialized 0, so that we ensure they have the same value at the beginning, only by this, all the transports could get equal chance to be selected. Then for sctp_trans_elect_best, it should return the trans_next one when *trans == *trans_next, so that we can try next if it fails, but now it always return trans. so we can fix it by exchanging these two params when we calls sctp_trans_elect_tie(). Fixes: 4c47af4d ('net: sctp: rework multihoming retransmission path selection to rfc4960') Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
Mahesh Salgaonkar authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c74dd88e upstream. When machine check occurs with MSR(RI=0), it means MC interrupt is unrecoverable and kernel goes down to panic path. But the console message still shows it as recovered. This patch fixes the MCE console messages. Fixes: 36df96f8 ("powerpc/book3s: Decode and save machine check event.") Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Naveen N. Rao authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f4782207 upstream. On some architectures (powerpc in particular), the number of registers exceeds what can be represented in an integer bitmask. Ensure we generate the proper bitmask on such platforms. Fixes: 71ad0f5e ("perf tools: Support for DWARF CFI unwinding on post processing") Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Acked-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Adrian Hunter authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 1dceb041 upstream. Several commits relating to setting power have been introducing problems by putting driver-specific rules into generic SDHCI code. Krzysztof Kozlowski reported that after commit 918f4cbd ("mmc: sdhci: restore behavior when setting VDD via external regulator") on Trats2 board there are warnings for invalid VDD value (2.8V): [ 3.119656] ------------[ cut here ]------------ [ 3.119666] WARNING: CPU: 3 PID: 90 at ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0 [ 3.119669] mmc0: Invalid vdd 0x10 [ 3.119673] Modules linked in: [ 3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G W 4.5.0-next-20160324 #23 [ 3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 3.119690] Workqueue: events_freezable mmc_rescan [ 3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>] (show_stack+0x10/0x14) [ 3.119719] [<c010ae10>] (show_stack) from [<c0323260>] (dump_stack+0x88/0x9c) [ 3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100) [ 3.119734] [<c011b754>] (__warn) from [<c011b7a4>] (warn_slowpath_fmt+0x38/0x48) [ 3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>] (sdhci_do_set_ios+0x4cc/0x5e0) [ 3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>] (sdhci_runtime_resume_host+0x60/0x114) [ 3.119758] [<c0528018>] (sdhci_runtime_resume_host) from [<c0402570>] (__rpm_callback+0x2c/0x60) [ 3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>] (rpm_callback+0x20/0x80) [ 3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>] (rpm_resume+0x36c/0x558) [ 3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>] (__pm_runtime_resume+0x4c/0x64) [ 3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>] (__mmc_claim_host+0x170/0x1b0) [ 3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>] (mmc_rescan+0x54/0x348) [ 3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>] (process_one_work+0x120/0x3f4) [ 3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>] (worker_thread+0x38/0x554) [ 3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>] (kthread+0xdc/0xf4) [ 3.119831] [<c01365a4>] (kthread) from [<c0107878>] (ret_from_fork+0x14/0x3c) [ 3.119834] ---[ end trace a22d652aa3276886 ]--- Fix by adding a 'set_power' callback and restoring the default behaviour prior to commit 918f4cbd ("mmc: sdhci: restore behavior when setting VDD via external regulator"). The desired behaviour of that commit is gotten by having sdhci-pxav3 provide its own set_power callback. Reported-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com Fixes: 918f4cbd ("mmc: sdhci: restore behavior when setting VDD...) Tested-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.5+ Reviewed-by:
Jisheng Zhang <jszhang@marvell.com> Tested-by:
Jaehoon Chung <jh80.chung@samsung.com> Tested-by:
Anand Moon <linux.amoon@gmail.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Nicholas Mc Guire authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 41f469ca upstream. wait_for_completion_timeout_interruptible returns long not unsigned long so dma_time, which is used exclusively here, is changed to long. Fixes: 1b66e94e ("mmc: moxart: Add MOXA ART SD/MMC driver") Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by:
-
Douglas Anderson authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit d4aa908c upstream. Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance where the power on default is wrong or where the firmware didn't configure this properly then we'll get a mysterious failure. In commit 7a03fe6f ("clk: rockchip: reset init state before mmc card initialization") we actually started setting this explicitly in the kernel, but that commit wasn't quite right and also wasn't quite enough. See <https://patchwork.kernel.org/patch/9085311/> for some details. Let's explicitly set this phase in dw_mmc. The comments inside this patch try to explain the situation quite throughly, but the high level overview of this is: Before this patch on rk3288 devices tested (after revert of the clock patch described above): * eMMC: 180 degrees * SDMMC/SDIO0/SDIO1: 90 degrees After this patch: * Use 90 degree phase offset usually. * Use 180 degree phase offset for MMC_DDR52, SDR104, HS200. That means we are _changing_ behavior for those devices in this way: * If we have HS200 eMMC or DDR52 eMMC, we'll run ID mode at 90 degrees (vs 180) but otherwise have no change. * For any non-HS200 / non-DDR52 eMMC devices we'll now _always_ run at 90 degrees (vs 180). It seems fairly unlikely that building modern hardware is using an eMMC that isn't using DDR52 or HS200, of course. * For SDR104 cards we'll now run with 180 degree phase offset (vs 90). It's expected that 90 degree phase offset would have worked OK, but this gives us extra margin. I have tested this by inserting my collection of uSD cards (mostly UHS, though a few not) into a veyron_minnie and confirmed that they still seem to enumerate properly. For a subset of them I tried putting a filesystem on them and also tried running mmc_test. Fixes: 7a03fe6f ("clk: rockchip: reset init state before mmc card initialization") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Shawn Lin <shawn.lin@rock-chips.com> Tested-by:
Heiko Stuebner <heiko@sntech.de> Tested-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
Douglas Anderson authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 4715f81a upstream. This reverts commit 7a03fe6f ("clk: rockchip: reset init state before mmc card initialization"). Though not totally obvious from the commit message nor from the source code, that commit appears to be trying to reset the "_drv" MMC clocks to 90 degrees (note that the "_sample" MMC clocks have a shift of 0 so are not touched). The major problem here is that it doesn't properly reset things. The phase is a two bit field and the commit only touches one of the two bits. Thus the commit had the following affect: - phase 0 => phase 90 - phase 90 => phase 90 - phase 180 => phase 270 - phase 270 => phase 270 Things get even weirder if you happen to have a bootloader that was actually using delay elements (should be no reason to, but you never know), since those are additional bits that weren't touched by the original patch. This is unlikely to be what we actually want. Checking on rk3288-veyron devices, I can see that the bootloader leaves these clocks as: - emmc: phase 180 - sdmmc: phase 90 - sdio0: phase 90 Thus on rk3288-veyron devices the commit we're reverting had the effect of changing the eMMC clock to phase 270. This probably explains the scattered reports I've heard of eMMC devices not working on some veyron devices when using the upstream kernel. The original commit was presumably made because previously the kernel didn't touch the "_drv" phase at all and relied on whatever value was there when the kernel started. If someone was using a bootloader that touched the "_drv" phase then, indeed, we should have code in the kernel to fix that. ...and also, to get ideal timings, we should also have the kernel change the phase depending on the speed mode. In fact, that's the subject of a recent patch I posted at <https://patchwork.kernel.org/patch/9075141/>. Ideally, we should take both the patch posted to dw_mmc and this revert. Since those will likely go through different trees, here I describe behavior with the combos: 1. Just this revert: likely will fix rk3288-veyron eMMC on some devices + other cases; might break someone with a strange bootloader that sets the phase to 0 or one that uses delay elements (pretty unpredicable what would happen in that case). 2. Just dw_mmc patch: fixes everyone. Effectly the dw_mmc patch will totally override the broken patch and fix everything. 3. Both patches: fixes everyone. Once dw_mmc is initting properly then any defaults from the clock code doesn't mattery. Fixes: 7a03fe6f ("clk: rockchip: reset init state before mmc card initialization") Signed-off-by:
-
Olof Johansson authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f00ab14c upstream. This used to return -EFAULT, but the function above returns -EINVAL on the same condition so let's stick to that. The removal of error return on this path was introduced with b093410c ('mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD'). Fixes: b093410c ('mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD'). Signed-off-by:
Olof Johansson <olof@lixom.net> Cc: Grant Grundler <grundler@google.com> Signed-off-by:
-
Chuanxiao Dong authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0036e746 upstream. Correct the wrong voltage value shown in debugfs for mmc/sd/sdio. Signed-off-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by:
Pawel Wodkowski <pawelx.wodkowski@intel.com> Fixes: 42cd95a0 ("mmc: core: debugfs: Add signal_voltage to ios dump") Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit d9812780 upstream. The SD card specification allows cards to error out a SWITCH command where the requested function in a group is not supported. The spec provides for a set of capabilities which indicate which functions are supported. In the case of the power limit, requesting an unsupported power level via the SWITCH command fails, resulting in the power level remaining at the power-on default of 0.72W, even though the host and card may support higher powers levels. This has been seen with SanDisk 8GB cards, which support the default 0.72W and 1.44W (200mA and 400mA) in combination with an iMX6 host, supporting up to 2.88W (800mA). This currently causes us to try to set a power limit function value of '3' (2.88W) which the card errors out on, and thereby causes the power level to remain at 0.72W rather than the desired 1.44W. Arrange to limit the selected current limit by the capabilities reported by the card to avoid the SWITCH command failing. Select the highest current limit that the host and card combination support. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Fixes: a39ca6ae ("mmc: core: Simplify and fix for SD switch processing") Signed-off-by:
-
Jisheng Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 918f4cbd upstream. After commit 52221610 ("mmc: sdhci: Improve external VDD regulator support"), for the VDD is supplied via external regulators, we ignore the code to convert a VDD voltage request into one of the standard SDHCI voltage levels, then program it in the SDHCI_POWER_CONTROL. This brings two issues: 1. SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON quirk isn't handled properly any more. 2. What's more, once SDHCI_POWER_ON bit is set, some controllers such as the sdhci-pxav3 used in marvell berlin SoCs require the voltage levels programming in the SDHCI_POWER_CONTROL register, even the VDD is supplied by external regulator. So the host in marvell berlin SoCs still works fine after the commit. However, commit 3cbc6123 ("mmc: sdhci: Set SDHCI_POWER_ON with external vmmc") sets the SDHCI_POWER_ON bit, this would make the host in marvell berlin SoCs won't work any more with external vmmc. This patch restores the behavior when setting VDD through external regulator by moving the call of mmc_regulator_set_ocr() to the end of sdhci_set_power() function. After this patch, the sdcard on Marvell Berlin SoC boards work again. Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b5f88dd1 upstream. The specific power domain can't be used in a way provided by the commit 01ac170b, i.e. pointer to platform device is a subject to change during unbound / bind cycle. This reverts commit 01ac170b. Fixes: 3df2da96 (Revert "ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Maciej S. Szmigiero authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 3f1c241f upstream. SACNT register should be marked volatile since its WR and RD bits are cleared by SSI after completing the relevant operation. This unbreaks AC'97 register access. Fixes: 05cf2379 ("ASoC: fsl_ssi: Add driver suspend and resume to support MEGA Fast") Signed-off-by:
Maciej S. Szmigiero <mail@maciej.szmigiero.name> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Sudip Mukherjee authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 319c3259 upstream. We have been returning success even if snd_soc_card_jack_new() fails. Lets check the return value and return error if it fails. Fixes: 12cc6d1d ("ASoC: tegra_alc5632: Register jacks at the card level") Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit d16a2b9f upstream. "data" is always NULL in this function. I think we should be passing "&data" to sst_prepare_and_post_msg() instead of "data". Fixes: 3d9ff346 ('ASoC: Intel: sst: add stream operations') Signed-off-by:
Dinesh Mirche <dinesh.mirche@intel.com> Acked-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Boris Brezillon authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 320092a0 upstream. Unregister the NAND device from the NAND subsystem when removing a denali NAND controller, otherwise the MTD attached to the NAND device is still exposed by the MTD layer, and accesses to this device will likely crash the system. Fixes: 2a0a288e ("mtd: denali: split the generic driver and PCI layer") Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by:
Dinh Nguyen <dinguyen@opensource.altera.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit adb03115 upstream. Jiri Pirko reported an UBSAN warning happening in ip_idents_reserve() [] UBSAN: Undefined behaviour in ./arch/x86/include/asm/atomic.h:156:11 [] signed integer overflow: [] -2117905507 + -695755206 cannot be represented in type 'int' Since we do not have uatomic_add_return() yet, use atomic_cmpxchg() so that the arithmetics can be done using unsigned int. Fixes: 04ca6973 ("ip: make IP identifiers less predictable") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Chuck Lever authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 11476e9d upstream. At Connectathon 2016, we found that recent upstream Linux clients would occasionally send a LOCK operation with a zero stateid. This appeared to happen in close proximity to another thread returning a delegation before unlinking the same file while it remained open. Earlier, the client received a write delegation on this file and returned the open stateid. Now, as it is getting ready to unlink the file, it returns the write delegation. But there is still an open file descriptor on that file, so the client must OPEN the file again before it returns the delegation. Since commit 24311f88 ('NFSv4: Recovery of recalled read delegations is broken'), nfs_open_delegation_recall() clears the NFS_DELEGATED_STATE flag _before_ it sends the OPEN. This allows a racing LOCK on the same inode to be put on the wire before the OPEN operation has returned a valid open stateid. To eliminate this race, serialize delegation return with the acquisition of a file lock on the same file. Adopt the same approach as is used in the unlock path. This patch also eliminates a similar race seen when sending a LOCK operation at the same time as returning a delegation on the same file. Fixes: 24311f88 ('NFSv4: Recovery of recalled read ... ') Signed-off-by:
-
Ilan Peer authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 4b559ec0 upstream. It is possible that the station is connected to an AP with bandwidth of 80+80MHz or 160MHz. In such cases there is no need to perform an upgrade as the maximal supported bandwidth is 80MHz. In addition, when upgrading and setting center_freq1 and bandwidth to 80MHz also set center_freq2 to 0. Fixes: 0fabfaaf ("mac80211: upgrade BW of TDLS peers when possible" Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Arik Nemtsov authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 59021c67 upstream. The previous approach simply ignored chandef restrictions when calculating the appropriate peer BW for a WIDER_BW peer. This could result in a regulatory violation if both peers indicated 80MHz support, but the regdomain forbade it. Change the approach to setting a WIDER_BW peer's BW. Don't exempt it from the chandef width at first. If during TDLS negotiation the chandef width is upgraded, update the peer's BW to match. Fixes: 0fabfaaf ("mac80211: upgrade BW of TDLS peers when possible") Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
-
Arik Nemtsov authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit db8d9977 upstream. Even if the current chandef width is equal to the station's max-BW, it doesn't mean it's a valid width for TDLS. Make sure to always check regulatory constraints in these cases. Fixes: 0fabfaaf ("mac80211: upgrade BW of TDLS peers when possible") Signed-off-by:
-
Johannes Berg authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit e673a659 upstream. If a mgmt-tx operation is aborted before it runs, the wrong cookie is reported back to userspace, and the ack_skb gets leaked since the frame is freed directly instead of freeing it using ieee80211_free_txskb(). Fix that. Fixes: 3b79af97 ("mac80211: stop using pointers as userspace cookies") Signed-off-by:
-
Ilan Tayari authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b5884793 upstream. commit 1a6509d9 ("[IPSEC]: Add support for combined mode algorithms") introduced aead. The function attach_aead kmemdup()s the algorithm name during xfrm_state_construct(). However this memory is never freed. Implementation has since been slightly modified in commit ee5c2317 ("xfrm: Clone states properly on migration") without resolving this leak. This patch adds a kfree() call for the aead algorithm name. Fixes: 1a6509d9 ("[IPSEC]: Add support for combined mode algorithms") Signed-off-by:
Ilan Tayari <ilant@mellanox.com> Acked-by:
Rami Rosen <roszenrami@gmail.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Mathias Krause authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 2f30ea50 upstream. When we fail to attach the security context in xfrm_state_construct() we'll return 0 as error value which, in turn, will wrongly claim success to userland when, in fact, we won't be adding / updating the XFRM state. This is a regression introduced by commit fd21150a ("[XFRM] netlink: Inline attach_encap_tmpl(), attach_sec_ctx(), and attach_one_addr()"). Fix it by propagating the error returned by security_xfrm_state_alloc() in this case. Fixes: fd21150a ("[XFRM] netlink: Inline attach_encap_tmpl()...") Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Alexey Kodanev authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 1625f452 upstream. Running LTP 'icmp-uni-basic.sh -6 -p ipcomp -m tunnel' test over openvswitch + veth can trigger kernel panic: BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0 IP: [<ffffffff8169d1d2>] xfrm_input+0x82/0x750 ... [<ffffffff816d472e>] xfrm6_rcv_spi+0x1e/0x20 [<ffffffffa082c3c2>] xfrm6_tunnel_rcv+0x42/0x50 [xfrm6_tunnel] [<ffffffffa082727e>] tunnel6_rcv+0x3e/0x8c [tunnel6] [<ffffffff8169f365>] ip6_input_finish+0xd5/0x430 [<ffffffff8169fc53>] ip6_input+0x33/0x90 [<ffffffff8169f1d5>] ip6_rcv_finish+0xa5/0xb0 ... It seems that tunnel.ip6 can have garbage values and also dereferenced without a proper check, only tunnel.ip4 is being verified. Fix it by adding one more if block for AF_INET6 and initialize tunnel.ip6 with NULL inside xfrm6_rcv_spi() (which is similar to xfrm4_rcv_spi()). Fixes: 049f8e2e ("xfrm: Override skb->mark with tunnel->parm.i_key in xfrm_input") Signed-off-by:
Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by:
-
Philipp Zabel authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit dc262dfa upstream. A recent patch broke parsing the gain, offset, and threshold parameters from device tree. Instead of setting the cached values and writing them to the correct registers during probe, it would write the values from DT into the register address variables and never write them to the chip during normal operation. Fixes: 2e23b7a9 ("Input: edt-ft5x06 - use generic properties API") Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 8679ee42 upstream. Commit 4ea14a53 ("Input: gpio-keys - report error when disabling unsupported key") tried let user know that they attempted to disable an unsupported key, unfortunately the check is wrong as it believes that all codes are invalid. Fix it by ensuring that keys that we try to disable are subset of keys (or switches) that device reports. Fixes: 4ea14a53 ("Input: gpio-keys - report error when disabling unsupported key") Reported-by:
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Tested-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0dc924c5 upstream. If we return 1 here, then the caller treats it as an error and returns -EINVAL. It causes a static checker warning to treat positive returns as an error. Fixes: 1aba86d6 ('Btrfs: fix easily get into ENOSPC in mixed case') Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
William Breathitt Gray authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 32a5a0c0 upstream. The isa_bus_init function must be called before drivers which utilize the ISA bus driver are registered. A race condition for initilization exists if device_initcall is used (the isa_bus_init callback is placed in the same initcall level as dependent drivers which use module_init). This patch ensures that isa_bus_init is called first by utilizing postcore_initcall in favor of device_initcall. Fixes: a5117ba7 ("[PATCH] Driver model: add ISA bus") Cc: Rene Herman <rene.herman@keyaccess.nl> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
-
Krzysztof Kozlowski authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 926b7b51 upstream. On non-DeviceTree platforms, the index of serial device is a static variable incremented on each probe. It is incremented even if deferred probe happens when getting the clock in s3c24xx_serial_init_port(). This index is used for referencing elements of statically allocated s3c24xx_serial_ports array. In case of re-probe, the index will point outside of this array leading to memory corruption. Increment the index only on successful probe. Reported-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Fixes: b497549a ("[ARM] S3C24XX: Split serial driver into core and per-cpu drivers") Signed-off-by:
-
Stephen Boyd authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 98952bf5 upstream. The msm_find_best_baud() function is written with the assumption that the port->uartclk rate is fixed to a particular rate at boot time, but now this driver changes that clk rate at runtime when the baud is changed. The way the hardware works is that an input clk rate comes from the clk controller into the uart hw block. That rate is typically 1843200 or 3686400 Hz. That rate can then be divided by an internal divider in the hw block to achieve a particular baud on the serial wire. msm_find_best_baud() is looking for that divider value. A few things are wrong with the way the code is written. First, it assumes that the maximum baud that the uart can support if the clk rate is fixed at boot is 460800, which would correspond to an input clk rate of 230400 * 16 == 3686400 Hz. Except some devices have a boot rate of 1843200 Hz or max baud of 115200, so achieving 230400 on those devices doesn't work at all because we don't increase the clk rate unless max baud is 460800. Second, we can't achieve bauds higher than 460800 that require anything besides a divisor of 1, because we always call msm_find_best_baud() with a fixed port->uartclk rate that will eventually be changed after we calculate the divisor. So if we need to get a baud of 500000, we'll just multiply that by 16 and hope that the clk can give us 500000 * 16 == 8000000 Hz, which it typically can't do. To really achieve 500000 baud, we need to get an input clk rate of 24000000 Hz and then divide that by 3 inside the uart hardware. Finally, we return success for bauds even when we can't actually achieve them. This means that when the user asks for 500000 baud, we actually get 921600 right now, but the user doesn't know that. Fix all of this by searching through the divisor and clk rate space with a combination of clk_round_rate() and baud calculations, keeping track of the best clk rate and divisor we find if we can't get an exact match. Typically we can get an exact match with a divisor of 1, but sometimes we need to keep track and try more frequencies. On my msm8916 device, this results in all standard bauds in baud_table being supported except for 1800, 576000, 1152000, and 4000000. Fixes: 850b37a7 ("tty: serial: msm: Remove 115.2 Kbps maximum baud rate limitation") Cc: "Ivan T. Ivanov" <iivanov.xz@gmail.com> Cc: Matthew McClintock <mmcclint@codeaurora.org> Signed-off-by:
Stephen Boyd <stephen.boyd@linaro.org> Tested-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by:
Andy Gross <andy.gross@linaro.org> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by:
Cristian Prundeanu <cprundea@codeaurora.org> Signed-off-by:
-
