summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-03-21staging: rtl8723bs: os_dep: Correct long line commentsR Veera Kumar
Correct long line comments to respect 80 character per line limit. Signed-off-by: R Veera Kumar <vkor@vkten.in> Link: https://lore.kernel.org/r/16399fc057c6dd1c78e77ddd3b3224f4b2e37da5.1584764104.git.vkor@vkten.in Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-21staging: rtl8723bs: os_dep: Remove commented out code linesR Veera Kumar
Remove multiple commented out code lines. Remove blank lines next to them. Signed-off-by: R Veera Kumar <vkor@vkten.in> Link: https://lore.kernel.org/r/a62d2fbb77990210b939a5ec99ee27cfa5749a09.1584764104.git.vkor@vkten.in Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-21staging: rtl8723bs: remove unneeded variablesPayal Kshirsagar
Remove unneeded temporary local variables and their declarations. Signed-off-by: Payal Kshirsagar <payalskshirsagar1234@gmail.com> Link: https://lore.kernel.org/r/20200321074757.8321-1-payalskshirsagar1234@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-21staging: mt7621-pci: delete release gpios related codeSergio Paracuellos
Making gpio8 and gpio9 vendor specific and putting them into the specific dts file makes not needed to release gpios anymore because we are not occupying those pins in the first place if it is not necessary. When the device tree is parsed we can also check and return for the error because we rely in the fact that the related device for the board is correct. Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://lore.kernel.org/r/20200321072650.7784-3-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-21staging: mt7621-dts: gpio 8 and 9 are vendor specificSergio Paracuellos
There are three pins that can be used for reset gpios. As mentioned in the application note, there are two possible way of wiring pcie reset: * connect gpio19 to all pcie reset pins * connect gpio19 to pcie0 reset and pick two other gpios for pcie1 and pcie2 gpio7 and gpio8 may not be used as pcie reset and are vendor specific. Hence, maintain common mt7621.dtsi with only gpio19 which is common and make an overlay for gnubee board which uses all gpio's as resets for pcie. After this changes release gpios in driver code is not needed anymore. Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://lore.kernel.org/r/20200321072650.7784-2-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-21staging: mt7621-dma: quoted string split across linesGokce Kuler
quoted string merge to upper line Signed-off-by: Gokce Kuler <gokcekuler@gmail.com> Link: https://lore.kernel.org/r/20200320232607.GA8601@siyah2 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-21staging: mt7621-pci: avoid to poweroff the phy for slot oneSergio Paracuellos
Phy for slot 0 and 1 is shared and handled properly in slot 0. If there is only one port in use,(slot 0) we shall not call the 'phy_power_off' function with an invalid slot because kernel will crash with an unaligned access fault like the following: mt7621-pci 1e140000.pcie: Error applying setting, reverse things back mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1) mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0) mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK) Unhandled kernel unaligned access[#1]: CPU: 3 PID: 111 Comm: kworker/3:2 Not tainted 5.6.0-rc3-00347-g825c6f470c62-dirty #9 Workqueue: events deferred_probe_work_func $ 0 : 00000000 00000001 5f60d043 8fe1ba80 $ 4 : 0000010d 01eb9000 00000000 00000000 $ 8 : 294b4c00 80940000 00000008 000000ce $12 : 2e303030 00000000 00000000 65696370 $16 : ffffffed 0000010d 8e373cd0 8214c1e0 $20 : 00000000 82144c80 82144680 8214c250 $24 : 00000018 803ef8f4 $28 : 8e372000 8e373c60 8214c080 803940e8 Hi : 00000125 Lo : 122f2000 epc : 807b3328 mutex_lock+0x8/0x44 ra : 803940e8 phy_power_off+0x28/0xb0 Status: 1100fc03 KERNEL EXL IE Cause : 00800010 (ExcCode 04) BadVA : 0000010d PrId : 0001992f (MIPS 1004Kc) Modules linked in: Process kworker/3:2 (pid: 111, threadinfo=(ptrval), task=(ptrval), tls=00000000) Stack : 8e373cd0 803fe4f4 8e372000 8e373c90 8214c080 804fde1c 8e373c98 808d62f4 8e373c78 00000000 8214c254 804fe648 1e160000 804f27b8 00000001 808d62f4 00000000 00000001 8214c228 808d62f4 80930000 809a0000 8fd47e10 808d63d4 808d62d4 8fd47e10 808d0000 808d0000 8e373cd0 8e373cd0 809e2a74 809db510 809db510 00000006 00000001 00000000 00000000 00000000 01000000 1e1440ff ... Call Trace: [<807b3328>] mutex_lock+0x8/0x44 [<803940e8>] phy_power_off+0x28/0xb0 [<804fe648>] mt7621_pci_probe+0xc20/0xd18 [<80402ab8>] platform_drv_probe+0x40/0x94 [<80400a74>] really_probe+0x104/0x364 [<803feb74>] bus_for_each_drv+0x84/0xdc [<80400924>] __device_attach+0xdc/0x120 [<803ffb5c>] bus_probe_device+0xa0/0xbc [<80400124>] deferred_probe_work_func+0x7c/0xbc [<800420e8>] process_one_work+0x230/0x450 [<80042638>] worker_thread+0x330/0x5fc [<80048eb0>] kthread+0x12c/0x134 [<80007438>] ret_from_kernel_thread+0x14/0x1c Code: 24050002 27bdfff8 8f830000 <c0850000> 14a00005 00000000 00600825 e0810000 1020fffa Fixes: bf516f413f4e ("staging: mt7621-pci: use only two phys from device tree") Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://lore.kernel.org/r/20200320153837.20415-1-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-21thermal/x86_pkg_temp: Make pkg_temp_lock a raw_spinlock_tClark Williams
The spinlock pkg_temp_lock has the potential of being taken in atomic context because it can be acquired from the thermal IRQ vector. It's static and limited scope so go ahead and make it a raw spinlock. Signed-off-by: Clark Williams <williams@redhat.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20191008110021.2j44ayunal7fkb7i@linutronix.de
2020-03-21ice: add board identifier info to devlink .info_getJacob Keller
Export a unique board identifier using "board.id" for devlink's .info_get command. Obtain this by reading the NVM for the PBA identification string. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-03-21ice: add basic handler for devlink .info_getJacob Keller
The devlink .info_get callback allows the driver to report detailed version information. The following devlink versions are reported with this initial implementation: "fw.mgmt" -> The version of the firmware that controls PHY, link, etc "fw.mgmt.api" -> API version of interface exposed over the AdminQ "fw.mgmt.build" -> Unique build id of the source for the management fw "fw.undi" -> Version of the Option ROM containing the UEFI driver "fw.psid.api" -> Version of the NVM image format. "fw.bundle_id" -> Unique identifier for the combined flash image. "fw.app.name" -> The name of the active DDP package. "fw.app" -> The version of the active DDP package. With this, devlink dev info can report at least as much information as is reported by ETHTOOL_GDRVINFO. Compare the output from ethtool vs from devlink: $ ethtool -i ens785s0 driver: ice version: 0.8.1-k firmware-version: 0.80 0x80002ec0 1.2581.0 expansion-rom-version: bus-info: 0000:3b:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes $ devlink dev info pci/0000:3b:00.0 pci/0000:3b:00.0: driver ice serial number 00-01-ab-ff-ff-ca-05-68 versions: running: fw.mgmt 2.1.7 fw.mgmt.api 1.5 fw.mgmt.build 0x305d955f fw.undi 1.2581.0 fw.psid.api 0.80 fw.bundle_id 0x80002ec0 fw.app.name ICE OS Default Package fw.app 1.3.1.0 More pieces of information can be displayed, each version is kept separate instead of munged together, and each version has an identifier which comes with associated documentation. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-03-21devlink: promote "fw.bundle_id" to a generic info versionJacob Keller
The nfp driver uses ``fw.bundle_id`` to represent a unique identifier of the entire firmware bundle. A future change is going to introduce a similar notion in the ice driver, so promote ``fw.bundle_id`` into a generic version now. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-03-21ice: enable initial devlink supportJacob Keller
Begin implementing support for the devlink interface with the ice driver. The pf structure is currently memory managed through devres, via a devm_alloc. To mimic this behavior, after allocating the devlink pointer, use devm_add_action to add a teardown action for releasing the devlink memory on exit. The ice hardware is a multi-function PCIe device. Thus, each physical function will get its own devlink instance. This means that each function will be treated independently, with its own parameters and configuration. This is done because the ice driver loads a separate instance for each function. Due to this, the implementation does not enable devlink to manage device-wide resources or configuration, as each physical function will be treated independently. This is done for simplicity, as managing a devlink instance across multiple driver instances would significantly increase the complexity for minimal gain. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-03-21ice: implement full NVM read from ETHTOOL_GEEPROMJesse Brandeburg
The current implementation of .get_eeprom only enables reading from the Shadow RAM portion of the NVM contents. Implement support for reading the entire flash contents instead of only the initial portion contained in the Shadow RAM. A complete dump can take several seconds, but the ETHTOOL_GEEPROM ioctl is capable of reading only a limited portion at a time by specifying the offset and length to read. In order to perform the reads directly, several functions are made non static. Additionally, the unused ice_read_sr_buf_aq and ice_read_sr_buf functions are removed. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-03-21ice: discover and store size of available flashJacob Keller
When reading from the NVM using a flat address, it is useful to know the upper bound on the size of the flash contents. This value is not stored within the NVM. We can determine the size by performing a bisection between upper and lower bounds. It is known that the size cannot exceed 16 MB (offset of 0xFFFFFF). Use a while loop to bisect the upper and lower bounds by reading one byte at a time. On a failed read, lower the maximum bound. On a successful read, increase the lower bound. Save this as the flash_size in the ice_nvm_info structure that contains data related to the NVM. The size will be used in a future patch for implementing full NVM read via ethtool's GEEPROM command. The maximum possible size for the flash is bounded by the size limit for the NVM AdminQ commands. Add a new macro, ICE_AQC_NVM_MAX_OFFSET, which can be used to represent this upper bound. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-03-21ice: store NVM version info in extracted formatJacob Keller
The NVM version and Option ROM version information is stored within the struct ice_nvm_ver_info structure. The data for the NVM is stored as a 2byte value with the major and minor versions each using one byte from the field. The Option ROM is stored as a 4byte value that contains a major, build, and patch number. Modify the code to immediately extract the version values and store them in a new struct ice_orom_info. Remove the now unnecessary ice_get_nvm_version function. Update ice_ethtool.c to use the new fields directly from the structured data. This reduces complexity of the code that prints these versions in ice_ethtool.c Update the macro definitions and variable names to use the term "orom" instead of "oem" for the Option ROM version. This helps increase the clarity of the Option ROM version code. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-03-21ice: create function to read a section of the NVM and Shadow RAMJacob Keller
The NVM contents are read via firmware by using the ice_aq_read_nvm function. This function has a couple of limits: 1) The AdminQ commands can only take buffers sized up to 4Kb. Thus, any larger read must be split into multiple reads. 2) when reading from the Shadow RAM, reads must not cross sector boundaries. The sectors are also 4Kb in size. Implement the ice_read_flat_nvm function to read portions of the NVM by flat offset. That is, to read using offsets from the start of the NVM rather than from a specific module. This function will be able to read both from the NVM and from the Shadow RAM. For simplicity NVM reads will always be broken up to not cross 4Kb page boundaries, even though this is not required unless reading from the Shadow RAM. Use this new function as the implementation of ice_read_sr_word_aq. The ice_read_sr_buf_aq function is not modified here. This is because a following change will remove the only caller of that function in favor of directly using ice_read_flat_nvm. Thus, there is little benefit to changing it now only to remove it momentarily. At the same time, the ice_read_sr_aq function will also be removed. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-03-20ice: use __le16 types for explicitly Little Endian valuesJacob Keller
The ice_read_sr_aq function returns words in the Little Endian format. Remove the need for __force and typecasting by using a local variable in the ice_read_sr_word_aq function. Additionally clarify explicitly that the ice_read_sr_aq function takes storage for __le16 values instead of using u16. Being explicit about the endianness of this data helps when using tools like sparse to catch endian-related issues. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-03-20clk: mmp2: Fix bit masks for LCDC I/O and pixel clocksLubomir Rintel
They were reversed because I read the datasheet upside down. Actually there is no datasheet, but I ended up understanding the comments in Open Firmware driver wrong. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-18-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: mmp2: Add clock for fifth SD HCI on MMP3Lubomir Rintel
There's one extra SDHCI on MMP3, used by the internal SD card on OLPC XO-4. Add a clock for it. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-17-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: mmp2: Add clocks for the thermal sensorsLubomir Rintel
The register definitions gotten from OLPC Open Firmware. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-15-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: mmp2: add the GPU clocksLubomir Rintel
MMP2 has a single GC860 core while MMP3 has a GC2000 and a GC300. On both platforms there's an AXI bus interface clock that's common for all GPUs and each GPU core has a separate clock. Meaning of the relevant APMU_GPU bits were gotten from James Cameron's message and [1], the OLPC OS kernel source [2] and Marvell's MMP3 tree. [1] http://lists.laptop.org/pipermail/devel/2019-April/039053.html [2] http://dev.laptop.org/git/olpc-kernel/commit/arch/arm/mach-mmp/mmp2.c?h=arm-3.0-wip&id=8ce9f6122 Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-13-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: mmp2: Add PLLs that are available on MMP3Lubomir Rintel
There are more PLLs on MMP3 and are configured slightly differently. Tested on a MMP3-based Dell Wyse 3020 machine. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-10-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: mmp2: Check for MMP3Lubomir Rintel
The MMP3's are similar enough to MMP2, but there are differencies, such are more clocks available on the newer model. We want to tell which platform are we on. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-8-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: mmp2: Stop pretending PLL outputs are constantLubomir Rintel
The hardcoded values for PLL1 and PLL2 are wrong. PLL1 is slightly off -- it defaults to 797.33 MHz, not 800 MHz. PLL2 is disabled by default, but also configurable. Tested on a MMP2-based OLPC XO-1.75 laptop, with PLL1=797.33 and various values of PLL2 set via set-pll2-520mhz, set-pll2-910mhz and set-pll2-988mhz Open Firmware words. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-6-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: mmp2: Add support for PLL clock sourcesLubomir Rintel
The clk-of-mmp2 driver pretends that the clock outputs from the PLLs are constant, but in fact they are configurable. Add logic for obtaining the actual clock rates on MMP2 as well as MMP3. There is no documentation for either SoC, but the "systemsetting" drivers from Marvell GPL code dump provide some clue as far as MPMU registers on MMP2 [1] and MMP3 [2] go. [1] https://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp3-dell-ariel.git/tree/drivers/char/mmp2_systemsetting.c [2] https://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp3-dell-ariel.git/tree/drivers/char/mmp3_systemsetting.c A separate commit will adjust the clk-of-mmp2 driver. Tested on a MMP3-based Dell Wyse 3020 as well as MMP2-based OLPC XO-1.75 laptop. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-5-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: mmp2: Constify some stringsLubomir Rintel
All the parent clock names for the muxes are constant. Add const. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-3-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: mmp2: Remove a unused prototypeLubomir Rintel
There is no mmp_clk_register_pll2() routine. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Link: https://lkml.kernel.org/r/20200309194254.29009-2-lkundrak@v3.sk Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: at91: add at91rm9200 pmc driverAlexandre Belloni
Add a driver for the PMC clocks of the at91rm9200. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lkml.kernel.org/r/20200214145934.53648-1-alexandre.belloni@bootlin.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20Merge branch 'nvme-5.6-rc6' of git://git.infradead.org/nvme into block-5.6Jens Axboe
Pull NVMe fixes from Keith: "Two late nvme fabrics fixes for 5.6: a double free with the rdma transport, and a regression fix for tcp; please pull." * 'nvme-5.6-rc6' of git://git.infradead.org/nvme: nvmet-tcp: set MSG_MORE only if we actually have more to send nvme-rdma: Avoid double freeing of async event data
2020-03-20clk: versatile: Add device tree probing for IM-PD1 clocksLinus Walleij
As we want to move these clocks over to probe from the device tree we add a device tree probing path. The old platform data path will be deleted once we have the device tree overall code in place. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lkml.kernel.org/r/20200219103326.81120-3-linus.walleij@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: versatile: Export icst_clk_setup()Linus Walleij
Export this clock setup method so we can register the IM-PD1 clocks with common code in the next step. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lkml.kernel.org/r/20200219103326.81120-2-linus.walleij@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: Fix trivia typo in comment exlusive => exclusiveAndy Shevchenko
Fix trivia typo in comment exlusive => exclusive. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lkml.kernel.org/r/20200310135507.87959-1-andriy.shevchenko@linux.intel.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: ingenic/TCU: Fix round_rate returning errorPaul Cercueil
When requesting a rate superior to the parent's rate, it would return -EINVAL instead of simply returning the parent's rate like it should. Fixes: 4f89e4b8f121 ("clk: ingenic: Add driver for the TCU clocks") Cc: stable@vger.kernel.org Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://lkml.kernel.org/r/20200213161952.37460-2-paul@crapouillou.net Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: ingenic/jz4770: Exit with error if CGU init failedPaul Cercueil
Exit jz4770_cgu_init() if the 'cgu' pointer we get is NULL, since the pointer is passed as argument to functions later on. Fixes: 7a01c19007ad ("clk: Add Ingenic jz4770 CGU driver") Cc: stable@vger.kernel.org Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lkml.kernel.org/r/20200213161952.37460-1-paul@crapouillou.net Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: keystone: Add new driver to handle syscon based clocksVignesh Raghavendra
On TI's AM654/J721e SoCs, certain clocks can be gated/ungated by setting a single bit in SoC's System Control Module registers. Sometime more than one clock control can be in the same register. Add a driver to support such clocks using syscon framework. Driver currently supports controlling EHRPWM's TimeBase clock(TBCLK) for AM654 SoC. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lkml.kernel.org/r/20200227053529.16479-3-vigneshr@ti.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: JZ4780: Add function for enable the second core.周琰杰 (Zhou Yanjie)
Add "jz4780_core1_enable()" for enable the second core of JZ4780, prepare for later commits. Tested-by: H. Nikolaus Schaller <hns@goldelico.com> Tested-by: Paul Boddie <paul@boddie.org.uk> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Link: https://lkml.kernel.org/r/1582215889-113034-3-git-send-email-zhouyanjie@wanyeetech.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: Ingenic: Add support for TCU of X1000.周琰杰 (Zhou Yanjie)
X1000 has a different TCU, since X1000 OST has been independent of TCU. This patch is add TCU support of X1000, and prepare for later OST driver. Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Link: https://lkml.kernel.org/r/1584457893-40418-3-git-send-email-zhouyanjie@wanyeetech.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: qcom: gcc: Add USB3 PIPE clock and GDSC for SM8150Wesley Cheng
This adds the USB3 PIPE clock and GDSC structures, so that the USB driver can vote for these resources to be enabled/disabled when required. Both are needed for SS and HS USB paths to operate properly. The GDSC will allow the USB system to be brought out of reset, while the PIPE clock is needed for data transactions between the PHY and controller. Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Link: https://lkml.kernel.org/r/1584478412-7798-2-git-send-email-wcheng@codeaurora.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20ipq806x: gcc: Added the enable regs and mask for PRNGAbhishek Sahu
Kernel got hanged while reading from /dev/hwrng at the time of PRNG clock enable Fixes: 24d8fba44af3 "clk: qcom: Add support for IPQ8064's global clock controller (GCC)" Signed-off-by: Abhishek Sahu <absahu@codeaurora.org> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Link: https://lkml.kernel.org/r/20200318131657.345-1-ansuelsmth@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: qcom: Add modem clock controller driver for SC7180Taniya Das
Add support for the modem clock controller found on SC7180 based devices. This would allow modem drivers to probe and control their clocks. Signed-off-by: Taniya Das <tdas@codeaurora.org> Link: https://lkml.kernel.org/r/1584596131-22741-4-git-send-email-tdas@codeaurora.org Tested-by: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-20clk: qcom: gcc: Add support for modem clocks in GCCTaniya Das
Add the required modem clocks in global clock controller which are required to bring the modem out of reset. Signed-off-by: Taniya Das <tdas@codeaurora.org> Link: https://lkml.kernel.org/r/1584596131-22741-3-git-send-email-tdas@codeaurora.org Tested-by: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-21HID: intel-ish-hid: hbm.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-03-21HID: intel-ish-hid: ishtp-dev.h: Replace zero-length array with ↵Gustavo A. R. Silva
flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-03-20spi: stm32: Fix comments compilation warningsAlain Volmat
Fix all functions and structure descriptions to have the driver warning free when built with W=1. Signed-off-by: Alain Volmat <alain.volmat@st.com> Reviewed-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/1584711857-9162-1-git-send-email-alain.volmat@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-21nvmet-tcp: set MSG_MORE only if we actually have more to sendSagi Grimberg
When we send PDU data, we want to optimize the tcp stack operation if we have more data to send. So when we set MSG_MORE when: - We have more fragments coming in the batch, or - We have a more data to send in this PDU - We don't have a data digest trailer - We optimize with the SUCCESS flag and omit the NVMe completion (used if sq_head pointer update is disabled) This addresses a regression in QD=1 with SUCCESS flag optimization as we unconditionally set MSG_MORE when we didn't actually have more data to send. Fixes: 70583295388a ("nvmet-tcp: implement C2HData SUCCESS optimization") Reported-by: Mark Wunderlich <mark.wunderlich@intel.com> Tested-by: Mark Wunderlich <mark.wunderlich@intel.com> Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org>
2020-03-20irqchip/gic-v4.1: Map the ITS SGIR register pageMarc Zyngier
One of the new features of GICv4.1 is to allow virtual SGIs to be directly signaled to a VPE. For that, the ITS has grown a new 64kB page containing only a single register that is used to signal a SGI to a given VPE. Add a second mapping covering this new 64kB range, and take this opportunity to limit the original mapping to 64kB, which is enough to cover the span of the ITS registers. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20200304203330.4967-8-maz@kernel.org
2020-03-20irqchip/gic-v4.1: Advertise support v4.1 to KVMMarc Zyngier
Tell KVM that we support v4.1. Nothing uses this information so far. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20200304203330.4967-7-maz@kernel.org
2020-03-20irqchip/gic-v4.1: Ensure mutual exclusion betwen invalidations on the same RDMarc Zyngier
The GICv4.1 spec says that it is CONTRAINED UNPREDICTABLE to write to any of the GICR_INV{LPI,ALL}R registers if GICR_SYNCR.Busy == 1. To deal with it, we must ensure that only a single invalidation can happen at a time for a given redistributor. Add a per-RD lock to that effect and take it around the invalidation/syncr-read to deal with this. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20200304203330.4967-6-maz@kernel.org
2020-03-20irqchip/gic-v4.1: Wait for completion of redistributor's INVALL operationZenghui Yu
In GICv4.1, we emulate a guest-issued INVALL command by a direct write to GICR_INVALLR. Before we finish the emulation and go back to guest, let's make sure the physical invalidate operation is actually completed and no stale data will be left in redistributor. Per the specification, this can be achieved by polling the GICR_SYNCR.Busy bit (to zero). Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20200302092145.899-1-yuzenghui@huawei.com Link: https://lore.kernel.org/r/20200304203330.4967-5-maz@kernel.org
2020-03-20drm/etnaviv: fix TS cache flushing on GPUs with BLT engineLucas Stach
As seen in the Vivante kernel driver, most GPUs with the BLT engine have a broken TS cache flush. The workaround is to temporarily set the BLT command to CLEAR_IMAGE, without actually executing the clear. Apparently this state change is enough to trigger the required TS cache flush. As the BLT engine is completely asychronous, we also need a few more stall states to synchronize the flush with the frontend. Root-caused-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
generated by cgit (git 2.34.1) at 2025-09-22 02:18:00 +0000