- 20 Nov, 2019 40 commits
-
-
Nicolas Adell authored
[ Upstream commit 1dedbdf2 ] When initializing the USB subsystem before starting the kernel, OTG overcurrent detection is disabled. In case the OTG polarity of overcurrent is low active, the overcurrent detection is never enabled again and events cannot be reported as expected. Because imx usb overcurrent polarity is low active by default, only detection needs to be enable in usbmisc init function. Signed-off-by:
Nicolas Adell <nicolas.adell@actia.fr> Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jakub Kicinski authored
[ Upstream commit 23d9f553 ] NFP supports fairly enormous ring sizes (up to 256k descriptors). In commit 46627170 ("nfp: use kvcalloc() to allocate SW buffer descriptor arrays") we have started using kvcalloc() functions to make sure the allocation of software state arrays doesn't hit the MAX_ORDER limit. Unfortunately, we can't use virtual mappings for the DMA region holding HW descriptors. In case this allocation fails instead of the generic (and fairly scary) warning/splat in the logs print a helpful message explaining what happened and suggesting how to fix it. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jian Shen authored
[ Upstream commit 32c7fbc8 ] So far all the places calling hclge_tm_q_to_qs_map_cfg() are assigning an u16 type value to "q_id", and in the processing of hclge_tm_q_to_qs_map_cfg(), it also converts the "q_id" to le16. The max tqp number for pf can be more than 256, we should use "u16" to store the queue id, instead of "u8", which may cause data lost. Fixes: 84844054 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
-
Jian Shen authored
[ Upstream commit d9f28fc2 ] When roce is loaded before nic, the roce client will not be initialized until nic client is initialized, but roce init flag is set before it. Furthermore, in this case of nic initialized success and roce failed, the nic init flag is not set, and roce init flag is not cleared. This patch fixes it by set init flag only after the client is initialized successfully. Fixes: e2cb1dec ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by:
-
Jian Shen authored
[ Upstream commit 49dd8054 ] If initialize client failed or finish uninitializing client, we should clear the client pointer. It may cause unexpected result when use uninitialized client. Meanwhile, we also should check whether client exist when uninitialize it. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by:
-
Jian Shen authored
[ Upstream commit 37dc9cdb ] According to hardware's description, the head pointer register should be written before the tail pointer register while initializing the vf command queue. Otherwise, it may trigger an interrupt even though there is no command received. Fixes: fedd0c15 ("net: hns3: Add HNS3 VF IMP(Integrated Management Proc) cmd interface") Signed-off-by:
-
Fuyun Liang authored
[ Upstream commit fd813314 ] The function of genphy_read_status is that reading phy information from HW and using these information to update SW variable. If user is using ethtool to setting the speed of phy and service task is calling by hclge_get_mac_phy_link, the result of speed setting is uncertain. Because ethtool cmd will modified phydev and hclge_get_mac_phy_link also will modified phydev. Because phy state machine will update phy link periodically, we can just use phydev->link to check the link status. This patch removes function call of genphy_read_status. To ensure accuracy, this patch adds a phy state check. If phy state is not PHY_RUNNING, we consider link is down. Because in some scenarios, phydev->link may be link up, but phy state is not PHY_RUNNING. This is just an intermediate state. In fact, the link is not ready yet. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by:
Fuyun Liang <liangfuyun1@huawei.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 0e0cc31f ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, but the implementation in this driver returns an 'int'. Found by coccinelle. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit fe72352e ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit 0c13b8d1 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit 81255af8 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit bacade82 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit f03508ce ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
Antoine Tenart authored
[ Upstream commit 70afb58e ] The Marvell PPv2.2 engine only has 8 Rx queues per CPU, while PPv2.1 has 16 of them. This patch updates the code so that the Rx queues mask width is selected given the version of the network controller used. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Andreas Kemnade authored
[ Upstream commit 079cdff3 ] This avoids getting woken up from suspend after power interruptions when the bci wrongly thinks the battery is full just because of input current going low because of low input power Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Andreas Kemnade authored
[ Upstream commit 8314c212 ] the charging current uses unsigned int variables, if we step back if the current is still low, we would run into negative which means setting the target to a huge value. Better add checks here. Signed-off-by:
-
Rob Herring authored
[ Upstream commit 53dd9dce ] The next update of libfdt has a new dependency on INT_MAX. Update the instances of libfdt_env.h in the kernel to either include the necessary header with the definition or define it locally. Cc: Russell King <linux@armlinux.org.uk> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linux-arm-kernel@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 62287dce ] dtc has new checks for I2C buses. Fix the warnings in unit-addresses in the unittests. drivers/of/unittest-data/testcases.dtb: Warning (i2c_bus_reg): /testcase-data/overlay-node/test-bus/i2c-test-bus/test-unittest14/i2c@0/test-mux-dev: I2C bus unit address format error, expected "20" drivers/of/unittest-data/overlay_15.dtb: Warning (i2c_bus_reg): /fragment@0/__overlay__/test-unittest15/i2c@0/test-mux-dev: I2C bus unit address format error, expected "20" Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by:
-
Viresh Kumar authored
[ Upstream commit 3d255699 ] The dev_list needs to be protected with a lock, else we may have simultaneous access (addition/removal) to it and that would be racy. Extend scope of the opp_table lock to protect dev_list as well. Tested-by:
Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Rob Herring authored
[ Upstream commit c890ecdb ] dtc has new checks for I2C and SPI buses. Fix the warnings in node names and unit-addresses. arch/arm/boot/dts/at91-dvk_som60.dtb: Warning (i2c_bus_reg): /ahb/apb/i2c@f0018000/eeprom@87: I2C bus unit address format error, expected "57" arch/arm/boot/dts/at91-dvk_som60.dtb: Warning (i2c_bus_reg): /ahb/apb/i2c@f0018000/ft5426@56: I2C bus unit address format error, expected "38" arch/arm/boot/dts/at91-vinco.dtb: Warning (i2c_bus_reg): /ahb/apb/i2c@f8024000/rtc@64: I2C bus unit address format error, expected "32" arch/arm/boot/dts/at91sam9260ek.dtb: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1" arch/arm/boot/dts/at91sam9g20ek_2mmc.dtb: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1" arch/arm/boot/dts/at91sam9g20ek.dtb: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1" arch/arm/boot/dts/at91sam9261ek.dtb: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/tsc2046@0: SPI bus unit address format error, expected "2" Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Håkon Bugge authored
[ Upstream commit 802fa45c ] Commit f27b4746 ("i40iw: add connection management code") uses an incorrect rcu iterator, whilst holding the rtnl_lock. Since the critical region invokes i40iw_manage_qhash(), which is a sleeping function, the rcu locking and traversal cannot be used. Signed-off-by:
Håkon Bugge <haakon.bugge@oracle.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Anton Blanchard authored
[ Upstream commit e00d93ac ] This re-applies commit b91c1e3e ("powerpc: Fix duplicate const clang warning in user access code") (Jun 2015) which was undone in commits: f2ca8090 ("powerpc/sparse: Constify the address pointer in __get_user_nosleep()") (Feb 2017) d466f6c5 ("powerpc/sparse: Constify the address pointer in __get_user_nocheck()") (Feb 2017) f84ed59a ("powerpc/sparse: Constify the address pointer in __get_user_check()") (Feb 2017) We see a large number of duplicate const errors in the user access code when building with llvm/clang: include/linux/pagemap.h:576:8: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier] ret = __get_user(c, uaddr); The problem is we are doing const __typeof__(*(ptr)), which will hit the warning if ptr is marked const. Removing const does not seem to have any effect on GCC code generation. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Nathan Fontenot authored
[ Upstream commit 85a88cab ] When performing partition migrations all present CPUs must be online as all present CPUs must make the H_JOIN call as part of the migration process. Once all present CPUs make the H_JOIN call, one CPU is returned to make the rtas call to perform the migration to the destination system. During testing of migration and changing the SMT state we have found instances where CPUs are offlined, as part of the SMT state change, before they make the H_JOIN call. This results in a hung system where every CPU is either in H_JOIN or offline. To prevent this this patch disables CPU hotplug during the migration process. Signed-off-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> Reviewed-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
-
Nathan Fontenot authored
[ Upstream commit 063b8b12 ] The updates to powerpc numa and memory hotplug code now use the in-kernel LMB array instead of the device tree. This change allows the pseries memory DLPAR code to only update the device tree once after successfully handling a DLPAR request. Prior to the in-kernel LMB array, the numa code looked up the affinity for memory being added in the device tree, the code now looks this up in the LMB array. This change means the memory hotplug code can just update the affinity for an LMB in the LMB array instead of updating the device tree. This also provides a savings in kernel memory. When updating the device tree old properties are never free'ed since there is no usecount on properties. This behavior leads to a new copy of the property being allocated every time a LMB is added or removed (i.e. a request to add 100 LMBs creates 100 new copies of the property). With this update only a single new property is created when a DLPAR request completes successfully. Signed-off-by:
-
Nicholas Piggin authored
[ Upstream commit 09b4438d ] This causes SLB alloation to start 1 beyond the start of the SLB. There is no real problem because after it wraps it stats behaving properly, it's just surprisig to see when looking at SLB traces. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
-
Breno Leitao authored
[ Upstream commit 44d947ef ] There are cases where the test is not expecting to have the transaction aborted, but, the test process might have been rescheduled, either in the OS level or by KVM (if it is running on a KVM guest machine). The process reschedule will cause a treclaim/recheckpoint which will cause the transaction to doom, aborting the transaction as soon as the process is rescheduled back to the CPU. This might cause the test to fail, but this is not a failure in essence. If that is the case, TEXASR[FC] is indicated with either TM_CAUSE_RESCHEDULE or TM_CAUSE_KVM_RESCHEDULE for KVM interruptions. In this scenario, ignore these two failures and avoid the whole test to return failure. Signed-off-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
Gustavo Romero <gromero@linux.ibm.com> Signed-off-by:
-
Breno Leitao authored
[ Upstream commit 984ecdd6 ] The tbl pointer is being derefenced by IOMMU_PAGE_SIZE prior the check if it is not NULL. Just moving the dereference code to after the check, where there will be guarantee that 'tbl' will not be NULL. Signed-off-by:
-
YueHaibing authored
[ Upstream commit 94b2bb28 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit ac1172de ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit c9c39411 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, also the implementation in this driver has returns 'netdev_tx_t' value, so just change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit 060e8fb5 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/char/ipmi/ipmi_msghandler.c: In function 'ipmi_set_my_LUN': drivers/char/ipmi/ipmi_msghandler.c:1335:13: warning: variable 'rv' set but not used [-Wunused-but-set-variable] int index, rv = 0; 'rv' should be the correct return value. Fixes: 048f7c3e ("ipmi: Properly release srcu locks on error conditions") Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Corey Minyard authored
[ Upstream commit 1574608f ] Looking at logs from systems all over the place, it looks like tons of broken systems exist that set the base address to zero. I can only guess that is some sort of non-standard idea to mark the interface as not being present. It can't be zero, anyway, so just complain and ignore it. Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 97a103e6 ] Shifting unsigned char b by an int type can lead to sign-extension overflow. For example, if b is 0xff and the shift is 24, then top bit is sign-extended so the final value passed to writeq has all the upper 32 bits set. Fix this by casting b to a 64 bit unsigned before the shift. Detected by CoverityScan, CID#1465246 ("Unintended sign extension") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Meelis Roos authored
[ Upstream commit 01508d9e ] I noticed that 4.17.0 logs the follwing during ipmi_si setup: ipmi_si 0000:01:04.6: probing via PCI (NULL device *): Could not setup I/O space ipmi_si 0000:01:04.6: [mem 0xf5ef0000-0xf5ef00ff] regsize 1 spacing 1 irq 21 Fix the "NULL device *) by moving io.dev assignment before its potential use by ipmi_pci_probe_regspacing(). Result: ipmi_si 0000:01:04.6: probing via PCI ipmi_si 0000:01:04.6: Could not setup I/O space ipmi_si 0000:01:04.6: [mem 0xf5ef0000-0xf5ef00ff] regsize 1 spacing 1 irq 21 Signed-off-by:
Meelis Roos <mroos@linux.ee> Signed-off-by:
-
Shuming Fan authored
[ Upstream commit 28b20dde ] This patch fixed the boost volume at the begining of playback while DAC volume set to lower level. Signed-off-by:
Shuming Fan <shumingf@realtek.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Peter Shih authored
[ Upstream commit 00bca73b ] Mediatek SPI driver modifies some fields (tx_buf, rx_buf, len, tx_dma, rx_dma) of the spi_transfer* passed in when doing transfer_one and in interrupt handler. This is somewhat unexpected, and there are some caller (e.g. Cr50 spi driver) that reuse the spi_transfer for multiple messages. Add a field to record how many bytes have been transferred, and calculate the right len / buffer based on it instead. Signed-off-by:
Pi-Hsun Shih <pihsun@chromium.org> Change-Id: I23e218cd964f16c0b2b26127d4a5ca6529867673 Signed-off-by:
-
Jonas Gorski authored
[ Upstream commit 0fd85869 ] If the pll clock needs to be enabled to get its rate, it will also need to be enabled to provide it. So ensure it is kept enabled through the lifetime of the device. Fixes: 0d7412ed ("spi/bcm63xx-hspi: Enable the clock before calling clk_get_rate().") Signed-off-by:
Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by:
-
Yonghong Song authored
[ Upstream commit 534e0e52 ] samples/bpf build failed with the following errors: $ make samples/bpf/ ... HOSTCC samples/bpf/sockex3_user.o /data/users/yhs/work/net-next/samples/bpf/sockex3_user.c:16:8: error: redefinition of ‘struct bpf_flow_keys’ struct bpf_flow_keys { ^ In file included from /data/users/yhs/work/net-next/samples/bpf/sockex3_user.c:4:0: ./usr/include/linux/bpf.h:2338:9: note: originally defined here struct bpf_flow_keys *flow_keys; ^ make[3]: *** [samples/bpf/sockex3_user.o] Error 1 Commit d58e468b ("flow_dissector: implements flow dissector BPF hook") introduced struct bpf_flow_keys in include/uapi/linux/bpf.h and hence caused the naming conflict with samples/bpf/sockex3_user.c. The fix is to rename struct bpf_flow_keys in samples/bpf/sockex3_user.c to flow_keys to avoid the conflict. Signed-off-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Kishon Vijay Abraham I authored
[ Upstream commit 3bc15720 ] AM65 has two PCIe controllers and each PCIe controller has '2' address spaces one within the 4GB address space of the SoC and the other above the 4GB address space of the SoC (cbass_main) in addition to the register space. The size of the address space above the 4GB SoC address space is 4GB. These address ranges will be used by CPU/DMA to access the PCIe address space. In order to represent the address space above the 4GB SoC address space and to represent the size of this address space as 4GB, change address-cells and size-cells of interconnect to 2. Since OSPI has similar need in MCU Domain Memory Map, change address-cells and size-cells of cbass_mcu interconnect also to 2. Fixes: ea47eed3 ("arm64: dts: ti: Add Support for AM654 SoC") Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Acked-by:
Vignesh R <vigneshr@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Douglas Anderson authored
[ Upstream commit c362272b ] If you've got the "console" serial port setup to use just as a UART (AKA there is no "console=ttyMSMX" on the kernel command line) then certain initialization is skipped. When userspace later tries to do something with the port then things go boom (specifically, on my system, some sort of exception hit that caused the system to reboot itself w/ no error messages). Let's cleanup / refactor the init so that we always run the same init code regardless of whether we're using the console. To make this work, we make rely on qcom_geni_serial_pm doing its job to turn resources on. For the record, here is a trace of the order of things (after this patch) when console= is specified on the command line and we have an agetty on the port: qcom_geni_serial_pm: 4 (undefined) => 0 (on) qcom_geni_console_setup qcom_geni_serial_port_setup qcom_geni_serial_console_write qcom_geni_serial_startup qcom_geni_serial_start_tx ...and here is the order of things (after this patch) when console= is _NOT_ specified on the command line and we have an agetty port: qcom_geni_serial_pm: 4 => 0 qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_port_setup qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_start_tx Fixes: c4f52879 ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
