summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* dt-bindings: pci: add PHY properties to Armada 7K/8K controller bindingsMiquel Raynal2019-08-271-0/+8
| | | | | | | | | Armada CP110 PCIe controller can have from one to four PHYs for configuring SERDES lanes (PCIe x1, PCIe x2 or PCIe x4). Describe the phys and phy-names properties in the bindings. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* dt-bindings: phy: Add Marvell COMPHY clocksMiquel Raynal2019-08-271-0/+10
| | | | | | | | | Marvell CP110 COMPHY block is fed by 3 clocks. Describe each of them in the bindings. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Update comment about powering off all lanes at bootMiquel Raynal2019-08-271-2/+4
| | | | | | | | | | | | Now that all COMPHY modes are supported by the driver, update the comment stating that mvebu_comphy_power_off() should be called for each lane. This is still wrong because for compatibility reasons, it might break users running an old firmware (the driver only uses SMC calls for SATA, USB and PCIe configuration, there is no code in Linux to fallback on in these cases. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Add PCIe supportGrzegorz Jaszczyk2019-08-271-5/+32
| | | | | | | | | | | | | | Add PCIe support by filling the COMPHY modes table. Also add a new macro to generate the right value for the firmware depending on the width (PCI x1, x2, x4, etc). The width will be passed by the core as the "submode" argument of the ->set_mode() callback. If this argument is zero, default to x1 mode. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> [miquel.raynal@bootlin.com: adapt the content to the mainline driver] Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Cosmetic change in a helperMiquel Raynal2019-08-271-6/+8
| | | | | | | | | Before adding more logic, simplify a bit the writing of the mvebu_comphy_get_mode() helper by using a pointer instead of referencing a configuration with the entire table name. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Add SATA supportGrzegorz Jaszczyk2019-08-271-0/+10
| | | | | | | | | | | Add the corresponding entries in the COMPHY modes table. SATA support does not need any additional care. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> [miquel.raynal@bootlin.com: adapt the content to the mainline driver] Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Add USB3 host/device supportGrzegorz Jaszczyk2019-08-271-0/+23
| | | | | | | | | | | | Add USB3 host/device support by adding the right entries in the COMPHY modes table. A new macro is created to instantiate a "generic" mode ie. not an Ethernet one. This macro will be re-used when adding SATA support. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> [miquel.raynal@bootlin.com: adapt the content to the mainline driver] Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Allow non-Ethernet modes to be configuredMiquel Raynal2019-08-271-3/+0
| | | | | | | | | The COMPHY can configure the SERDES lanes in several non-Ethernet modes: SATA, USB3, PCIe. Drop the condition limiting the driver to Ethernet modes only before adding support for more. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Rename the macro handling only Ethernet modesMiquel Raynal2019-08-271-22/+22
| | | | | | | | | Before adding support for other PHY modes (not Ethernet ones), let's rename the MVEBU_COMPHY_CONF macro to a more specific (and shorter) appellation. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Add RXAUI supportGrzegorz Jaszczyk2019-08-271-0/+10
| | | | | | | | | | | | Add support for RXAUI mode by adding an entry in the COMPHY modes list. There is no user for this mode yet so we can enforce an up-to-date firmware and return an error otherwise without breaking anywone. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> [miquel.raynal@bootlin.com: adapt the content to the mainline driver] Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: List already supported Ethernet modesMiquel Raynal2019-08-271-0/+2
| | | | | | | | | Currently, the driver supports setting lanes to 1000BASEX, 2500BASEX, 10GKR. Complete the COMPHY modes list by adding two (already supported) cases for lane 4. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Add SMC call supportGrzegorz Jaszczyk2019-08-272-22/+177
| | | | | | | | | | | | | Keep the exact same list of supported configurations but first try to use the firmware's implementation. If it fails, try the legacy method: Linux implementation. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> [miquel.raynal@bootlin.com: adapt the content to the mainline driver] Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Grzegorz Jaszczyk <jaz@semihalf.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Explicitly initialize the lane submodeMiquel Raynal2019-08-271-0/+1
| | | | | | | Explicitly set the lane submode (enum) to a known invalid value. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-cp110-comphy: Add clocks supportMiquel Raynal2019-08-271-3/+85
| | | | | | | | | | | | | | | | | There is no public clock tree that implies such dependencies between the MG/MG-core/AXI clocks and the COMPHY IP but accessing the COMPHY registers while one of the three clocks are disabled stalls the CPU. This happens if, for instance, the COMPHY driver probe is deferred (eg. the USB Vbus regulator driver is not yet visible). The MVPP2 driver which also needs these clocks (among others) will prepare/enable the clocks, then be deferred, and disable/unprepare them. Next COMPHY lane to be configured would produce an infinite stall. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Grzegorz Jaszczyk <jaz@semihalf.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy-rockchip-inno-hdmi: Fix RK3328_TERM_RESISTOR_CALIB_SPEED_7_0's third valueNathan Chancellor2019-08-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit "linux/bits.h: Add compile time sanity check of GENMASK inputs" [1], arm64 defconfig builds started failing: In file included from ../include/linux/bits.h:22, from ../include/linux/bitops.h:5, from ../include/linux/kernel.h:12, from ../include/linux/clk.h:13, from ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:9: ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c: In function 'inno_hdmi_phy_rk3328_power_on': ../include/linux/build_bug.h:16:45: error: negative width in bit-field '<anonymous>' 16 | #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); })) | ^ ../include/linux/bits.h:24:18: note: in expansion of macro 'BUILD_BUG_ON_ZERO' 24 | ((unsigned long)BUILD_BUG_ON_ZERO(__builtin_choose_expr( \ | ^~~~~~~~~~~~~~~~~ ../include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK' 39 | (GENMASK_INPUT_CHECK(high, low) + __GENMASK(high, low)) | ^~~~~~~~~~~~~~~~~~~ ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:24:42: note: in expansion of macro 'GENMASK' 24 | #define UPDATE(x, h, l) (((x) << (l)) & GENMASK((h), (l))) | ^~~~~~~ ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:201:50: note: in expansion of macro 'UPDATE' 201 | #define RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(x) UPDATE(x, 7, 9) | ^~~~~~ ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:1046:26: note: in expansion of macro 'RK3328_TERM_RESISTOR_CALIB_SPEED_7_0' 1046 | inno_write(inno, 0xc6, RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(v)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As pointed out by Robin and Guenter, inno_write's val argument is an 8-bit value so having a mask larger than that doesn't make sense. This also matches the rest of the *_7_0 macros in this driver. [1]: https://lore.kernel.org/lkml/20190801230358.4193-2-rikard.falkeborn@gmail.com/ Reported-by: Andrzej Hajda <a.hajda@samsung.com> Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: kernelci.org bot <bot@kernelci.org> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Suggested-by: Guenter Roeck <linux@roeck-us.net> Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de>
* phy: qcom-qmp: Correct ready status, againBjorn Andersson2019-08-261-17/+16
| | | | | | | | | | | | | | | | | | | | | | | Despite extensive testing of commit 885bd765963b ("phy: qcom-qmp: Correct READY_STATUS poll break condition") I failed to conclude that the PHYSTATUS bit of the PCS_STATUS register used in PCIe and USB3 falls as the PHY gets ready. Similar to the prior bug with UFS the code will generally get past the check before the transition and thereby "succeed". Correct the name of the register used PCIe and USB3 PHYs, replace mask_pcs_ready with a constant expression depending on the type of the PHY and check for the appropriate ready state. Cc: stable@vger.kernel.org Cc: Vivek Gautam <vivek.gautam@codeaurora.org> Cc: Evan Green <evgreen@chromium.org> Cc: Niklas Cassel <niklas.cassel@linaro.org> Reported-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Fixes: 885bd765963b ("phy: qcom-qmp: Correct READY_STATUS poll break condition") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: qualcomm: phy-qcom-qmp: Add of_node_put() before returnNishka Dasgupta2019-08-261-4/+7
| | | | | | | | | | | | | | | Each iteration of for_each_available_child_of_node() puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence create a new label, err_node_put, that puts the previous node (child) before returning the required value. Also include the statement pm_runtime_disable() under this label in order to avoid repetition among mid-loop return conditions. Edit the mid-loop return statements to instead go to this new label err_node_put. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-currentYoshihiro Shimoda2019-08-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | The hardware manual should be revised, but the initial value of VBCTRL.OCCLREN is set to 1 actually. If the bit is set, the hardware clears VBCTRL.VBOUT and ADPCTRL.DRVVBUS registers automatically when the hardware detects over-current signal from a USB power switch. However, since the hardware doesn't have any registers which indicates over-current, the driver cannot handle it at all. So, if "is_otg_channel" hardware detects over-current, since ADPCTRL.DRVVBUS register is cleared automatically, the channel cannot be used after that. To resolve this behavior, this patch sets the VBCTRL.OCCLREN to 0 to keep ADPCTRL.DRVVBUS even if the "is_otg_channel" hardware detects over-current. (We assume a USB power switch itself protects over-current and turns the VBUS off.) This patch is inspired by a BSP patch from Kazuya Mizuguchi. Fixes: 1114e2d31731 ("phy: rcar-gen3-usb2: change the mode to OTG on the combined channel") Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: ti: am654-serdes: fix an use-after-free in serdes_am654_clk_register()Wen Yang2019-08-261-11/+22
| | | | | | | | | | | | The regmap_node variable is still being used in the syscon_node_to_regmap() call after the of_node_put() call, which may result in use-after-free. Fixes: 71e2f5c5c224 ("phy: ti: Add a new SERDES driver for TI's AM654x SoC") Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Roger Quadros <rogerq@ti.com> Reviewed-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: mvebu-a3700-comphy: Inform users if their firmware is too oldMiquel Raynal2019-08-231-1/+8
| | | | | | | | | | | | | | | | | PHY configuration has been implemented in the firmware and accessed through SMC calls. In the past, it worked magically if the bootloader was correctly doing the initializations. With up-to-date bindings, the kernel will need a recent firmware in order to do the initializations himself (we assume people must update their firmware along with their kernel). People might not understand why IPs that were working correctly before stopped to be probed suddendly. In this case, let's advise the users to update their firmware with a visual warning. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: samsung: disable bind/unbind platform driver featureMarek Szyprowski2019-08-236-0/+6
| | | | | | | | | | | | Samsung PHY drivers control the power to the SoC core components needed by their client devices (USB HCDs, SATA, camera ISP bridge, DP encoder) to properly operate. Disabling PHYs in runtime usually causes the client device to crash with external abort exception or similar issue due to lack of API to notify clients about PHY removal. This patch removes the possiblity to unbind Samsung Exynos PHY drivers in runtime. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: core: document phy_calibrate()Marek Szyprowski2019-08-231-0/+10
| | | | | | | | | | | Commit 36914111e682 ("drivers: phy: add calibrate method") added support for generic phy_calibrate() method, but it didn't explain in detail when such method is supposed to be called. Add some more documentation directly to the phy.h to make it clean that it is intended to be called after every host controller reset. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: marvell: phy-mvebu-a3700-comphy: Add of_node_put() before returnNishka Dasgupta2019-08-231-2/+6
| | | | | | | | | | | Each iteration of for_each_available_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return in two places. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: marvell: phy-mvebu-cp110-comphy: Add of_node_put() before returnNishka Dasgupta2019-08-231-2/+6
| | | | | | | | | | | Each iteration of for_each_available_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return in two places. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: marvell: phy-armada38x-comphy: Add of_node_put() before returnNishka Dasgupta2019-08-231-1/+3
| | | | | | | | | | | Each iteration of for_each_available_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: enable compile-testing for the Lantiq PHY driversMartin Blumenstingl2019-08-231-1/+1
| | | | | | | | | | | Unconditionally include the lantiq subdirectory in the phy Makefile. All drivers in there have their dependencies maintained. One of these (optional) dependencies is COMPILE_TEST, however this can only be evaluated when Kconfig scans the lantiq subdirectory. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* phy: lantiq: vrx200-pcie: add a driver for the Lantiq VRX200 PCIe PHYMartin Blumenstingl2019-08-233-0/+506
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The Lantiq VRX200 SoCs embed a PCIe PHY in the "sram" bus. Unlike most other IP blocks on this SoC the register values are only 16-bit wide. Like other IP blocks on this SoC the register values are in big endian. The PHY embeds a PLL which can be configured in various modes. Only the 36MHz mode is supported for now, the other modes can be implemented when there's a board which actually needs them. OpenWrt uses the out-of-tree vendor driver and all supported boards there only need the 36MHz mode. There are two input clocks: - the "pdi" clock enables the register access - the "phy" clock is the clock input and enables the internal PLL There are two reset lines: - "phy" resets the PHY itself - the "pcie" reset line is shared between the PHY and the PCIe controller While the VRX200 SoC has only one PCIe controller and PHY the ARX300 uses two identical PCIe controllers and PHYs which are compatible with the PCIe controller and PHY on VRX200. Add a driver for this PHY so PCIe support can be enabled on these SoCs. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* dt-bindings: phy: add binding for the Lantiq VRX200 and ARX300 PCIe PHYsMartin Blumenstingl2019-08-232-0/+106
| | | | | | | | | | Add the bindings for the PCIe PHY on Lantiq VRX200 and ARX300 SoCs. The IP block contains settings for the PHY and a PLL. The PLL mode is configurable through a dedicated #phy-cell in .dts. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* Linux 5.3-rc2v5.3-rc2Linus Torvalds2019-07-281-1/+1
|
* Merge tag 'meminit-v5.3-rc2' of ↵Linus Torvalds2019-07-281-0/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull structleak fix from Kees Cook: "Disable gcc-based stack variable auto-init under KASAN (Arnd Bergmann). This fixes a bunch of build warnings under KASAN and the gcc-plugin-based stack auto-initialization features (which are arguably redundant, so better to let KASAN control this)" * tag 'meminit-v5.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: structleak: disable STRUCTLEAK_BYREF in combination with KASAN_STACK
| * structleak: disable STRUCTLEAK_BYREF in combination with KASAN_STACKArnd Bergmann2019-07-261-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The combination of KASAN_STACK and GCC_PLUGIN_STRUCTLEAK_BYREF leads to much larger kernel stack usage, as seen from the warnings about functions that now exceed the 2048 byte limit: drivers/media/i2c/tvp5150.c:253:1: error: the frame size of 3936 bytes is larger than 2048 bytes drivers/media/tuners/r820t.c:1327:1: error: the frame size of 2816 bytes is larger than 2048 bytes drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16552:1: error: the frame size of 3144 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] fs/ocfs2/aops.c:1892:1: error: the frame size of 2088 bytes is larger than 2048 bytes fs/ocfs2/dlm/dlmrecovery.c:737:1: error: the frame size of 2088 bytes is larger than 2048 bytes fs/ocfs2/namei.c:1677:1: error: the frame size of 2584 bytes is larger than 2048 bytes fs/ocfs2/super.c:1186:1: error: the frame size of 2640 bytes is larger than 2048 bytes fs/ocfs2/xattr.c:3678:1: error: the frame size of 2176 bytes is larger than 2048 bytes net/bluetooth/l2cap_core.c:7056:1: error: the frame size of 2144 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] net/bluetooth/l2cap_core.c: In function 'l2cap_recv_frame': net/bridge/br_netlink.c:1505:1: error: the frame size of 2448 bytes is larger than 2048 bytes net/ieee802154/nl802154.c:548:1: error: the frame size of 2232 bytes is larger than 2048 bytes net/wireless/nl80211.c:1726:1: error: the frame size of 2224 bytes is larger than 2048 bytes net/wireless/nl80211.c:2357:1: error: the frame size of 4584 bytes is larger than 2048 bytes net/wireless/nl80211.c:5108:1: error: the frame size of 2760 bytes is larger than 2048 bytes net/wireless/nl80211.c:6472:1: error: the frame size of 2112 bytes is larger than 2048 bytes The structleak plugin was previously disabled for CONFIG_COMPILE_TEST, but meant we missed some bugs, so this time we should address them. The frame size warnings are distracting, and risking a kernel stack overflow is generally not beneficial to performance, so it may be best to disallow that particular combination. This can be done by turning off either one. I picked the dependency in GCC_PLUGIN_STRUCTLEAK_BYREF and GCC_PLUGIN_STRUCTLEAK_BYREF_ALL, as this option is designed to make uninitialized stack usage less harmful when enabled on its own, but it also prevents KASAN from detecting those cases in which it was in fact needed. KASAN_STACK is currently implied by KASAN on gcc, but could be made a user selectable option if we want to allow combining (non-stack) KASAN with GCC_PLUGIN_STRUCTLEAK_BYREF. Note that it would be possible to specifically address the files that print the warning, but presumably the overall stack usage is still significantly higher than in other configurations, so this would not address the full problem. I could not test this with CONFIG_INIT_STACK_ALL, which may or may not suffer from a similar problem. Fixes: 81a56f6dcd20 ("gcc-plugins: structleak: Generalize to all variable types") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190722114134.3123901-1-arnd@arndb.de Signed-off-by: Kees Cook <keescook@chromium.org>
* | Merge tag 'kbuild-fixes-v5.3' of ↵Linus Torvalds2019-07-284-7/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - add compile_commands.json to .gitignore - fix false-positive warning from gen_compile_commands.py after allnoconfig build - remove unused code * tag 'kbuild-fixes-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: remove unused single-used-m gen_compile_commands: lower the entry count threshold .gitignore: Add compilation database file kbuild: remove unused objectify macro
| * | kbuild: remove unused single-used-mMasahiro Yamada2019-07-271-2/+0
| | | | | | | | | | | | | | | | | | | | | This is unused since commit 9f69a496f100 ("kbuild: split out *.mod out of {single,multi}-used-m rules"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
| * | gen_compile_commands: lower the entry count thresholdMasahiro Yamada2019-07-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running gen_compile_commands.py after building the kernel with allnoconfig gave this: $ ./scripts/gen_compile_commands.py WARNING: Found 449 entries. Have you compiled the kernel? Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
| * | .gitignore: Add compilation database fileToru Komatsu2019-07-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file is used by clangd to use language server protocol. It can be generated at each compile using scripts/gen_compile_commands.py. Therefore it is different depending on the environment and should be ignored. Signed-off-by: Toru Komatsu <k0ma@utam0k.jp> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
| * | kbuild: remove unused objectify macroMasahiro Yamada2019-07-271-3/+0
| | | | | | | | | | | | | | | | | | | | | Commit 415008af3219 ("docs-rst: convert lsm from DocBook to ReST") removed the last users of this macro. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* | | Merge tag 'char-misc-5.3-rc2' of ↵Linus Torvalds2019-07-2810-11/+23
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are some small char and misc driver fixes for 5.3-rc2 to resolve some reported issues. Nothing major at all, some binder bugfixes for issues found, some new mei device ids, firmware building warning fixes, habanalabs fixes, a few other build fixes, and a MAINTAINERS update. All of these have been in linux-next with no reported issues" * tag 'char-misc-5.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: test_firmware: fix a memory leak bug hpet: Fix division by zero in hpet_time_div() eeprom: make older eeprom drivers select NVMEM_SYSFS vmw_balloon: Remove Julien from the maintainers list fpga-manager: altera-ps-spi: Fix build error mei: me: add mule creek canyon (EHL) device ids binder: prevent transactions to context manager from its own process. binder: Set end of SG buffer area properly. firmware: Fix missing inline firmware: fix build errors in paged buffer handling code habanalabs: don't reset device when getting VRHOT habanalabs: use %pad for printing a dma_addr_t
| * | | test_firmware: fix a memory leak bugWenwen Wang2019-07-251-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In test_firmware_init(), the buffer pointed to by the global pointer 'test_fw_config' is allocated through kzalloc(). Then, the buffer is initialized in __test_firmware_config_init(). In the case that the initialization fails, the following execution in test_firmware_init() needs to be terminated with an error code returned to indicate this failure. However, the allocated buffer is not freed on this execution path, leading to a memory leak bug. To fix the above issue, free the allocated buffer before returning from test_firmware_init(). Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu> Link: https://lore.kernel.org/r/1563084696-6865-1-git-send-email-wang6495@umn.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | hpet: Fix division by zero in hpet_time_div()Kefeng Wang2019-07-251-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The base value in do_div() called by hpet_time_div() is truncated from unsigned long to uint32_t, resulting in a divide-by-zero exception. UBSAN: Undefined behaviour in ../drivers/char/hpet.c:572:2 division by zero CPU: 1 PID: 23682 Comm: syz-executor.3 Not tainted 4.4.184.x86_64+ #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 b573382df1853d00 ffff8800a3287b98 ffffffff81ad7561 ffff8800a3287c00 ffffffff838b35b0 ffffffff838b3860 ffff8800a3287c20 0000000000000000 ffff8800a3287bb0 ffffffff81b8f25e ffffffff838b35a0 Call Trace: [<ffffffff81ad7561>] __dump_stack lib/dump_stack.c:15 [inline] [<ffffffff81ad7561>] dump_stack+0xc1/0x120 lib/dump_stack.c:51 [<ffffffff81b8f25e>] ubsan_epilogue+0x12/0x8d lib/ubsan.c:166 [<ffffffff81b900cb>] __ubsan_handle_divrem_overflow+0x282/0x2c8 lib/ubsan.c:262 [<ffffffff823560dd>] hpet_time_div drivers/char/hpet.c:572 [inline] [<ffffffff823560dd>] hpet_ioctl_common drivers/char/hpet.c:663 [inline] [<ffffffff823560dd>] hpet_ioctl_common.cold+0xa8/0xad drivers/char/hpet.c:577 [<ffffffff81e63d56>] hpet_ioctl+0xc6/0x180 drivers/char/hpet.c:676 [<ffffffff81711590>] vfs_ioctl fs/ioctl.c:43 [inline] [<ffffffff81711590>] file_ioctl fs/ioctl.c:470 [inline] [<ffffffff81711590>] do_vfs_ioctl+0x6e0/0xf70 fs/ioctl.c:605 [<ffffffff81711eb4>] SYSC_ioctl fs/ioctl.c:622 [inline] [<ffffffff81711eb4>] SyS_ioctl+0x94/0xc0 fs/ioctl.c:613 [<ffffffff82846003>] tracesys_phase2+0x90/0x95 The main C reproducer autogenerated by syzkaller, syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0); memcpy((void*)0x20000100, "/dev/hpet\000", 10); syscall(__NR_openat, 0xffffffffffffff9c, 0x20000100, 0, 0); syscall(__NR_ioctl, r[0], 0x40086806, 0x40000000000000); Fix it by using div64_ul(). Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Zhang HongJun <zhanghongjun2@huawei.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190711132757.130092-1-wangkefeng.wang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | eeprom: make older eeprom drivers select NVMEM_SYSFSArseny Solokha2019-07-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | misc/eeprom/{at24,at25,eeprom_93xx46} drivers all register their corresponding devices in the nvmem framework in compat mode which requires nvmem sysfs interface to be present. The latter, however, has been split out from nvmem under a separate Kconfig in commit ae0c2d725512 ("nvmem: core: add NVMEM_SYSFS Kconfig"). As a result, probing certain I2C-attached EEPROMs now fails with at24: probe of 0-0050 failed with error -38 because of a stub implementation of nvmem_sysfs_setup_compat() in drivers/nvmem/nvmem.h. Update the nvmem dependency for these drivers so they could load again: at24 0-0050: 32768 byte 24c256 EEPROM, writable, 64 bytes/write Cc: Adrian Bunk <bunk@kernel.org> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru> Link: https://lore.kernel.org/r/20190716111236.27803-1-asolokha@kb.kras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | vmw_balloon: Remove Julien from the maintainers listNadav Amit2019-07-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Julien will not be a maintainer anymore. Signed-off-by: Nadav Amit <namit@vmware.com> Link: https://lore.kernel.org/r/20190702100519.7464-1-namit@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | fpga-manager: altera-ps-spi: Fix build errorYueHaibing2019-07-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If BITREVERSE is m and FPGA_MGR_ALTERA_PS_SPI is y, build fails: drivers/fpga/altera-ps-spi.o: In function `altera_ps_write': altera-ps-spi.c:(.text+0x4ec): undefined reference to `byte_rev_table' Select BITREVERSE to fix this. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: fcfe18f885f6 ("fpga-manager: altera-ps-spi: use bitrev8x4") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Cc: stable <stable@vger.kernel.org> Acked-by: Moritz Fischer <mdf@kernel.org> Link: https://lore.kernel.org/r/20190708071356.50928-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | mei: me: add mule creek canyon (EHL) device idsAlexander Usyskin2019-07-242-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add Mule Creek Canyon (PCH) MEI device ids for Elkhart Lake (EHL) Platform. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20190712095814.20746-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | binder: prevent transactions to context manager from its own process.Hridya Valsaraju2019-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, a transaction to context manager from its own process is prevented by checking if its binder_proc struct is the same as that of the sender. However, this would not catch cases where the process opens the binder device again and uses the new fd to send a transaction to the context manager. Reported-by: syzbot+8b3c354d33c4ac78bfad@syzkaller.appspotmail.com Signed-off-by: Hridya Valsaraju <hridya@google.com> Acked-by: Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20190715191804.112933-1-hridya@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | binder: Set end of SG buffer area properly.Martijn Coenen2019-07-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case the target node requests a security context, the extra_buffers_size is increased with the size of the security context. But, that size is not available for use by regular scatter-gather buffers; make sure the ending of that buffer is marked correctly. Acked-by: Todd Kjos <tkjos@google.com> Fixes: ec74136ded79 ("binder: create node flag to request sender's security context") Signed-off-by: Martijn Coenen <maco@android.com> Cc: stable@vger.kernel.org # 5.1+ Link: https://lore.kernel.org/r/20190709110923.220736-1-maco@android.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | firmware: Fix missing inlineTakashi Iwai2019-07-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I mistakenly dropped the inline while resolving the patch conflicts in the previous fix patch. Without inline, we get compiler warnings wrt unused functions. Note that Mauro's original patch contained the correct changes; it's all my fault to submit a patch before a morning coffee. Fixes: c8917b8ff09e ("firmware: fix build errors in paged buffer handling code") Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20190723081159.22624-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | Merge tag 'misc-habanalabs-fixes-2019-07-22' of ↵Greg Kroah-Hartman2019-07-221-3/+3
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~gabbayo/linux into char-misc-linux Oded writes: This tag contains the following fixes: - Fix to VRHOT event handling from the ASIC. No need to reset the ASIC, just notify it in dmesg. - Fix printk specifier for printing dma address * tag 'misc-habanalabs-fixes-2019-07-22' of git://people.freedesktop.org/~gabbayo/linux: habanalabs: don't reset device when getting VRHOT habanalabs: use %pad for printing a dma_addr_t
| | * | | habanalabs: don't reset device when getting VRHOTOded Gabbay2019-06-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VRHOT event from the F/W indicates the device has reached a temperature of 100 Celsius degrees. In this case, the driver should only print this information to the kernel log. The device will shutdown itself automatically when reaching 125 degrees. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
| | * | | habanalabs: use %pad for printing a dma_addr_tArnd Bergmann2019-07-081-2/+2
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dma_addr_t might be different sizes depending on the configuration, so we cannot print it as %llx: drivers/misc/habanalabs/goya/goya.c: In function 'goya_sw_init': drivers/misc/habanalabs/goya/goya.c:698:21: error: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'dma_addr_t' {aka 'unsigned int'} [-Werror=format=] Use the special %pad format string. This requires passing the argument by reference. Fixes: 2a51558c8c7f ("habanalabs: remove DMA mask hack for Goya") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
| * / / firmware: fix build errors in paged buffer handling codeMauro Rossi2019-07-221-2/+2
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fw_{grow,map}_paged_buf() need to be defined as static inline when CONFIG_FW_LOADER_PAGED_BUF is not enabled, infact fw_free_paged_buf() is also defined as static inline when CONFIG_FW_LOADER_PAGED_BUF is not enabled. Fixes the following mutiple definition building errors for Android kernel: drivers/base/firmware_loader/fallback_efi.o: In function `fw_grow_paged_buf': fallback_efi.c:(.text+0x0): multiple definition of `fw_grow_paged_buf' drivers/base/firmware_loader/main.o:(.text+0x73b): first defined here drivers/base/firmware_loader/fallback_efi.o: In function `fw_map_paged_buf': fallback_efi.c:(.text+0xf): multiple definition of `fw_map_paged_buf' drivers/base/firmware_loader/main.o:(.text+0x74a): first defined here [ slightly corrected the patch description -- tiwai ] Fixes: 5342e7093ff2 ("firmware: Factor out the paged buffer handling code") Fixes: 82fd7a8142a1 ("firmware: Add support for loading compressed files") Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20190722055536.15342-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-23 02:16:05 +0100