summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-24mfd: dbx500-prcmu: Drop DSI pll clock functionsLinus Walleij
The DSI PLLs are handled by the generic clock framework since ages, this code is completely unused and misleading. Delete it. Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: dbx500-prcmu: Drop set_display_clocks()Linus Walleij
The display clocks are handled by the generic clock framework since ages, this code is completely unused and misleading. Delete it. Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: max77650: Select REGMAP_IRQ in KconfigBartosz Golaszewski
MAX77650 MFD driver uses regmap_irq API but doesn't select the required REGMAP_IRQ option in Kconfig. This can cause the following build error if regmap irq is not enabled implicitly by someone else: ld: drivers/mfd/max77650.o: in function `max77650_i2c_probe': max77650.c:(.text+0xcb): undefined reference to `devm_regmap_add_irq_chip' ld: max77650.c:(.text+0xdb): undefined reference to `regmap_irq_get_domain' make: *** [Makefile:1079: vmlinux] Error 1 Fix it by adding the missing option. Fixes: d0f60334500b ("mfd: Add new driver for MAX77650 PMIC") Reported-by: Paul Gazzillo <paul@pgazz.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: axp20x: Mark AXP20X_VBUS_IPSOUT_MGMT as volatileSamuel Holland
On AXP288 and newer PMICs, bit 7 of AXP20X_VBUS_IPSOUT_MGMT can be set to prevent using the VBUS input. However, when the VBUS unplugged and plugged back in, the bit automatically resets to zero. We need to set the register as volatile to prevent regmap from caching that bit. Otherwise, regcache will think the bit is already set and not write the register. Fixes: cd53216625a0 ("mfd: axp20x: Fix axp288 volatile ranges") Cc: stable@vger.kernel.org Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: ab8500: Fix ab8500-clk typoLinus Walleij
Commit f4d41ad84433 ("mfd: ab8500: Example using new OF_MFD_CELL MACRO") has a typo error renaming "ab8500-clk" to "abx500-clk" with the result att ALSA SoC audio broke as the clock driver was not probing anymore. Fixed it up. Fixes: f4d41ad84433 ("mfd: ab8500: Example using new OF_MFD_CELL MACRO") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: intel-lpss: Add Intel Jasper Lake PCI IDsAndy Shevchenko
Intel Jasper Lake has the same LPSS than Intel Ice Lake. Add the new IDs to the list of supported devices. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24dt-bindings: mfd: max14577: Add reference to max14040_battery.txt descriptionsMatheus Castello
max77836 MFD has a fuel gauge that has a low SOC alert feature that is described in: Documentation/devicetree/bindings/power/supply/max17040_battery.txt Adding the reference to the documentation here. Signed-off-by: Matheus Castello <matheus@castello.eng.br> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> [Lee: Fix relative path] Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: ab8500-core: Add device tree support for AB8505Stephan Gerhold
AB8505 support was never fully converted to the device tree. Most of the MFD cells for AB8505 lack an "of_compatible", which prevents them from being configured through the device tree. Align the definition of the AB8505 MFD cells with the ones for AB8500, and add device tree compatibles. Except for GPIO and regulators the compatibles are equal to those used for AB8500 because the hardware does not differ much. Finally, change db8500_prcmu_register_ab8500() to check for the AB8505 device tree node additionally, and probe it if it is found. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24dt-bindings: mfd: ab8500: Document AB8505 bindingsStephan Gerhold
AB8505 can now be configured from the device tree. The configuration is almost identical to AB8500, so just add a note for the nodes/compatibles that differ between the two revisions. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24dt-bindings: mfd: Document the Xylon LogiCVC multi-function devicePaul Kocialkowski
The LogiCVC is a display engine which also exposes GPIO functionality. For this reason, it is described as a multi-function device that is expected to provide register access to its children nodes for gpio and display. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24dt-bindings: mfd: da9062: add gpio bindingsMarco Felsch
Add gpio device documentation to make the da9062 gpios available for users. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: da9062: add support for the DA9062 GPIOs in the coreMarco Felsch
Currently the da9062 GPIO's aren't available. The patch adds the support to make these available by adding a gpio device with the corresponding irq resources. Furthermore the patch fixes a minor style issue for the onkey device. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: dln2: More sanity checking for endpointsOliver Neukum
It is not enough to check for the number of endpoints. The types must also be correct. Reported-and-tested-by: syzbot+48a2851be24583b864dc@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum <oneukum@suse.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: sm501: Fix mismatches of request_mem_regionChuhong Yuan
This driver misuses release_resource + kfree to match request_mem_region, which is incorrect. The right way is to use release_mem_region. Replace the mismatched calls with the right ones to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: syscon: Re-use resource_size() to count max_registerAndy Shevchenko
Instead of open coded variant use resource_size() and replace weird '- 3' to more understandable '- 4'. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24Merge branches 'ib-mfd-drm-5.6' and 'ib-mfd-clk-gpio-regulator-rtc-5.6' into ↵Lee Jones
ibs-for-mfd-merged
2020-01-24gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOsMatti Vaittinen
ROHM BD71828 PMIC contains 4 pins which can be configured by OTP to be used for general purposes. First 3 can be used as outputs and 4.th pin can be used as input. Allow them to be controlled via GPIO framework. The driver assumes all of the pins are configured as GPIOs and trusts that the reserved pins in other OTP configurations are excluded from control using "gpio-reserved-ranges" device tree property (or left untouched by GPIO users). Typical use for 4.th pin (input) is to use it as HALL sensor input so that this pin state is toggled when HALL sensor detects LID position change (from close to open or open to close). PMIC HW implements some extra logic which allows PMIC to power-up the system when this pin is toggled. Please see the data sheet for details of GPIO options which can be selected by OTP settings. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24rtc: bd70528: add BD71828 supportMatti Vaittinen
ROHM BD71828 PMIC RTC block is from many parts similar to one on BD70528. Support BD71828 RTC using BD70528 RTC driver and avoid re-inventing the wheel. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: bd70528: Fix hour register maskMatti Vaittinen
When RTC is used in 24H mode (and it is by this driver) the maximum hour value is 24 in BCD. This occupies bits [5:0] - which means correct mask for HOUR register is 0x3f not 0x1f. Fix the mask Fixes: 32a4a4ebf768 ("rtc: bd70528: Initial support for ROHM bd70528 RTC") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24regulator: bd718x7: Split driver to common and bd718x7 specific partsMatti Vaittinen
Few ROHM PMICs allow setting the voltage states for different system states like RUN, IDLE, SUSPEND and LPSR. States are then changed via SoC specific mechanisms. bd718x7 driver implemented device-tree parsing functions for these state specific voltages. The parsing functions can be re-used by other ROHM chip drivers like bd71828. Split the generic functions from bd718x7-regulator.c to rohm-regulator.c and export them for other modules to use. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24clk: bd718x7: Support ROHM BD71828 clk blockMatti Vaittinen
BD71828GW is a single-chip power management IC for battery-powered portable devices. Add support for controlling BD71828 clk using bd718x7 driver. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: bd71828: Add power-key supportMatti Vaittinen
Use gpio_keys to send power input-event to user-space when power button (short) press is detected. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: bd71828: Support ROHM BD71828 PMIC - coreMatti Vaittinen
BD71828GW is a single-chip power management IC for battery-powered portable devices. The IC integrates 7 buck converters, 7 LDOs, and a 1500 mA single-cell linear charger. Also included is a Coulomb counter, a real-time clock (RTC), 3 GPO/regulator control pins, HALL input and a 32.768 kHz clock gate. Add MFD core driver providing interrupt controller facilities and i2c access to sub device drivers. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: bd718x7: Add compatible for BD71850Matti Vaittinen
ROHM BD71850 PMIC is almost identical to BD71847. Main difference is some initial voltage values for regulators. The BD71850 can be handled by BD71847 driver but adding own compatible makes it clearer for one who creates the DT for board containing this PMIC and allows SW to be differentiating PMICs if needed. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24mfd: Rohm PMICs: Use platform_device_id to match MFD sub-devicesMatti Vaittinen
Thanks to Stephen Boyd I today learned we can use platform_device_id to do device and module matching for MFD sub-devices! Do device matching using the platform_device_id instead of using explicit module_aliases to load modules and custom parent-data field to do module loading and sub-device matching. Cc: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24dt-bindings: mfd: Document ROHM BD71828 bindingsMatti Vaittinen
ROHM BD71828 Power management IC integrates 7 buck converters, 7 LDOs, a real-time clock (RTC), 3 GPO/regulator control pins, HALL input and a 32.768 kHz clock gate. Document the dt bindings drivers are using. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24dt-bindings: leds: ROHM BD71282 PMIC LED driverMatti Vaittinen
Document ROHM BD71828 PMIC LED driver device tree bindings. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-01-24net/rose: fix spelling mistake "to" -> "too"Colin Ian King
There is a spelling mistake in a printk message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-24caif_usb: fix spelling mistake "to" -> "too"Colin Ian King
There is a spelling mistake in a pr_warn message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-24ipvs: fix spelling mistake "to" -> "too"Colin Ian King
There is a spelling mistake in a IP_VS_ERR_RL message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-24i40e: fix spelling mistake "to" -> "too"Colin Ian King
There is a spelling mistake in a hw_dbg message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-24dmaengine: Create symlinks between DMA channels and slavesGeert Uytterhoeven
Currently it is not easy to find out which DMA channels are in use, and which slave devices are using which channels. Fix this by creating two symlinks between the DMA channel and the actual slave device when a channel is requested: 1. A "slave" symlink from DMA channel to slave device, 2. A "dma:<name>" symlink slave device to DMA channel. When the channel is released, the symlinks are removed again. The latter requires keeping track of the slave device and the channel name in the dma_chan structure. Note that this is limited to channel request functions for requesting an exclusive slave channel that take a device pointer (dma_request_chan() and dma_request_slave_channel*()). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Link: https://lore.kernel.org/r/20200117153056.31363-1-geert+renesas@glider.be Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24dmaengine: hisilicon: Add Kunpeng DMA engine supportZhou Wang
This patch adds a driver for HiSilicon Kunpeng DMA engine. This DMA engine which is an PCIe iEP offers 30 channels, each channel has a send queue, a complete queue and an interrupt to help to do tasks. This DMA engine can do memory copy between memory blocks or between memory and device buffer. Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Zhenfa Qiu <qiuzhenfa@hisilicon.com> Link: https://lore.kernel.org/r/1579155057-80523-1-git-send-email-wangzhou1@hisilicon.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24dmaengine: idxd: add char driver to expose submission portal to userlandDave Jiang
Create a char device region that will allow acquisition of user portals in order to allow applications to submit DMA operations. A char device will be created per work queue that gets exposed. The workqueue type "user" is used to mark a work queue for user char device. For example if the workqueue 0 of DSA device 0 is marked for char device, then a device node of /dev/dsa/wq0.0 will be created. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/157965026985.73301.976523230037106742.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24dmaengine: idxd: connect idxd to dmaengine subsystemDave Jiang
Add plumbing for dmaengine subsystem connection. The driver register a DMA device per DSA device. The channels are dynamically registered when a workqueue is configured to be "kernel:dmanegine" type. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/157965026376.73301.13867988830650740445.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24dmaengine: idxd: add descriptor manipulation routinesDave Jiang
This commit adds helper functions for DSA descriptor allocation, submission, and free operations. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/157965025757.73301.12692876585357550065.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24dmaengine: idxd: add sysfs ABI for idxd driverJing Lin
Add the sysfs ABI information for idxd driver in Documentation/ABI/stable directory. Signed-off-by: Jing Lin <jing.lin@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/157965025170.73301.13428570530450446901.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24dmaengine: idxd: add configuration component of driverDave Jiang
The device is left unconfigured when the driver is loaded. Various components are configured via the driver sysfs attributes. Once configuration is done, the device can be enabled by writing the device name to the bind attribute of the device driver sysfs. Disabling can be done similarly. Also the individual work queues can also be enabled and disabled through the bind/unbind attributes. A constructed hierarchy is created through the struct device framework in order to provide appropriate configuration points and device state and status. This hierarchy is presented off the virtual DSA bus. i.e. /sys/bus/dsa/... Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/157965024585.73301.6431413676230150589.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24dmaengine: idxd: Init and probe for Intel data acceleratorsDave Jiang
The idxd driver introduces the Intel Data Stream Accelerator [1] that will be available on future Intel Xeon CPUs. One of the kernel access point for the driver is through the dmaengine subsystem. It will initially provide the DMA copy service to the kernel. Some of the main functionality introduced with this accelerator are: shared virtual memory (SVM) support, and descriptor submission using Intel CPU instructions movdir64b and enqcmds. There will be additional accelerator devices that share the same driver with variations to capabilities. This commit introduces the probe and initialization component of the driver. [1]: https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/157965023991.73301.6186843973135311580.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24dmaengine: add support to dynamic register/unregister of channelsDave Jiang
With the channel registration routines broken out, now add support code to allow independent registering and unregistering of channels in a hotplug fashion. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/157965023364.73301.7821862091077299040.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24dmaengine: break out channel registrationDave Jiang
In preparation for dynamic channel registration, the code segment that does the channel registration is broken out to its own function. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/157965022778.73301.8929944324898985438.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-24x86/asm: add iosubmit_cmds512() based on MOVDIR64B CPU instructionDave Jiang
With the introduction of MOVDIR64B instruction, there is now an instruction that can write 64 bytes of data atomically. Quoting from Intel SDM: "There is no atomicity guarantee provided for the 64-byte load operation from source address, and processor implementations may use multiple load operations to read the 64-bytes. The 64-byte direct-store issued by MOVDIR64B guarantees 64-byte write-completion atomicity. This means that the data arrives at the destination in a single undivided 64-byte write transaction." We have identified at least 3 different use cases for this instruction in the format of func(dst, src, count): 1) Clear poison / Initialize MKTME memory @dst is normal memory. @src in normal memory. Does not increment. (Copy same line to all targets) @count (to clear/init multiple lines) 2) Submit command(s) to new devices @dst is a special MMIO region for a device. Does not increment. @src is normal memory. Increments. @count usually is 1, but can be multiple. 3) Copy to iomem in big chunks @dst is iomem and increments @src in normal memory and increments @count is number of chunks to copy Add support for case #2 to support device that will accept commands via this instruction. We provide a @count in order to submit a batch of preprogrammed descriptors in virtually contiguous memory. This allows the caller to submit multiple descriptors to a device with a single submission. The special device requires the entire 64bytes descriptor to be written atomically and will accept MOVDIR64B instruction. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Acked-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/157965022175.73301.10174614665472962675.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-23xfs: remove unused variable 'done'YueHaibing
fs/xfs/xfs_inode.c: In function 'xfs_itruncate_extents_flags': fs/xfs/xfs_inode.c:1523:8: warning: unused variable 'done' [-Wunused-variable] commit 4bbb04abb4ee ("xfs: truncate should remove all blocks, not just to the end of the page cache") left behind this, so remove it. Fixes: 4bbb04abb4ee ("xfs: truncate should remove all blocks, not just to the end of the page cache") Reported-by: Hulk Robot <hulkci@huawei.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2020-01-23xfs: fix uninitialized variable in xfs_attr3_leaf_inactiveDarrick J. Wong
Dan Carpenter pointed out that error is uninitialized. While there never should be an attr leaf block with zero entries, let's not leave that logic bomb there. Fixes: 0bb9d159bd01 ("xfs: streamline xfs_attr3_leaf_inactive") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Allison Collins <allison.henderson@oracle.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com>
2020-01-23Merge tag 'mmc-v5.5-rc2-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: "A couple of MMC host fixes: - sdhci: Fix minimum clock rate for v3 controllers - sdhci-tegra: Fix SDR50 tuning override - sdhci_am654: Fixup tuning issues and support for CQHCI - sdhci_am654: Remove wrong write protect flag" * tag 'mmc-v5.5-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci: fix minimum clock rate for v3 controller mmc: tegra: fix SDR50 tuning override mmc: sdhci_am654: Fix Command Queuing in AM65x mmc: sdhci_am654: Reset Command and Data line after tuning mmc: sdhci_am654: Remove Inverted Write Protect flag
2020-01-24pinctrl: madera: Remove extra blank lineCharles Keepax
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200122111150.11033-1-ckeepax@opensource.cirrus.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-01-24pinctrl: qcom: Don't lock around irq_set_irq_wake()Stephen Boyd
We don't need to hold the local pinctrl lock here to set irq wake on the summary irq line. Doing so only leads to lockdep warnings instead of protecting us from anything. Remove the locking. WARNING: possible circular locking dependency detected 5.4.11 #2 Tainted: G W ------------------------------------------------------ cat/3083 is trying to acquire lock: ffffff81f4fa58c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 but task is already holding lock: ffffff81f4880c18 (&pctrl->lock){-.-.}, at: msm_gpio_irq_set_wake+0x48/0x7c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&pctrl->lock){-.-.}: _raw_spin_lock_irqsave+0x64/0x80 msm_gpio_irq_ack+0x68/0xf4 __irq_do_set_handler+0xe0/0x180 __irq_set_handler+0x60/0x9c irq_domain_set_info+0x90/0xb4 gpiochip_hierarchy_irq_domain_alloc+0x110/0x200 __irq_domain_alloc_irqs+0x130/0x29c irq_create_fwspec_mapping+0x1f0/0x300 irq_create_of_mapping+0x70/0x98 of_irq_get+0xa4/0xd4 spi_drv_probe+0x4c/0xb0 really_probe+0x138/0x3f0 driver_probe_device+0x70/0x140 __device_attach_driver+0x9c/0x110 bus_for_each_drv+0x88/0xd0 __device_attach+0xb0/0x160 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x35c/0x3f0 spi_add_device+0xbc/0x194 of_register_spi_devices+0x2c8/0x408 spi_register_controller+0x57c/0x6fc spi_geni_probe+0x260/0x328 platform_drv_probe+0x90/0xb0 really_probe+0x138/0x3f0 driver_probe_device+0x70/0x140 device_driver_attach+0x4c/0x6c __driver_attach+0xcc/0x154 bus_for_each_dev+0x84/0xcc driver_attach+0x2c/0x38 bus_add_driver+0x108/0x1fc driver_register+0x64/0xf8 __platform_driver_register+0x4c/0x58 spi_geni_driver_init+0x1c/0x24 do_one_initcall+0x1a4/0x3e8 do_initcall_level+0xb4/0xcc do_basic_setup+0x30/0x48 kernel_init_freeable+0x124/0x1a8 kernel_init+0x14/0x100 ret_from_fork+0x10/0x18 -> #0 (&irq_desc_lock_class){-.-.}: __lock_acquire+0xeb4/0x2388 lock_acquire+0x1cc/0x210 _raw_spin_lock_irqsave+0x64/0x80 __irq_get_desc_lock+0x64/0x94 irq_set_irq_wake+0x40/0x144 msm_gpio_irq_set_wake+0x5c/0x7c set_irq_wake_real+0x40/0x5c irq_set_irq_wake+0x70/0x144 cros_ec_rtc_suspend+0x38/0x4c platform_pm_suspend+0x34/0x60 dpm_run_callback+0x64/0xcc __device_suspend+0x310/0x41c dpm_suspend+0xf8/0x298 dpm_suspend_start+0x84/0xb4 suspend_devices_and_enter+0xbc/0x620 pm_suspend+0x210/0x348 state_store+0xb0/0x108 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x15c/0x1fc __vfs_write+0x54/0x18c vfs_write+0xe4/0x1a4 ksys_write+0x7c/0xe4 __arm64_sys_write+0x20/0x2c el0_svc_common+0xa8/0x160 el0_svc_handler+0x7c/0x98 el0_svc+0x8/0xc other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pctrl->lock); lock(&irq_desc_lock_class); lock(&pctrl->lock); lock(&irq_desc_lock_class); *** DEADLOCK *** 7 locks held by cat/3083: #0: ffffff81f06d1420 (sb_writers#7){.+.+}, at: vfs_write+0xd0/0x1a4 #1: ffffff81c8935680 (&of->mutex){+.+.}, at: kernfs_fop_write+0x12c/0x1fc #2: ffffff81f4c322f0 (kn->count#337){.+.+}, at: kernfs_fop_write+0x134/0x1fc #3: ffffffe89a641d60 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x348 #4: ffffff81f190e970 (&dev->mutex){....}, at: __device_suspend+0x168/0x41c #5: ffffff81f183d8c0 (lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 #6: ffffff81f4880c18 (&pctrl->lock){-.-.}, at: msm_gpio_irq_set_wake+0x48/0x7c stack backtrace: CPU: 4 PID: 3083 Comm: cat Tainted: G W 5.4.11 #2 Hardware name: Google Cheza (rev3+) (DT) Call trace: dump_backtrace+0x0/0x174 show_stack+0x20/0x2c dump_stack+0xc8/0x124 print_circular_bug+0x2ac/0x2c4 check_noncircular+0x1a0/0x1a8 __lock_acquire+0xeb4/0x2388 lock_acquire+0x1cc/0x210 _raw_spin_lock_irqsave+0x64/0x80 __irq_get_desc_lock+0x64/0x94 irq_set_irq_wake+0x40/0x144 msm_gpio_irq_set_wake+0x5c/0x7c set_irq_wake_real+0x40/0x5c irq_set_irq_wake+0x70/0x144 cros_ec_rtc_suspend+0x38/0x4c platform_pm_suspend+0x34/0x60 dpm_run_callback+0x64/0xcc __device_suspend+0x310/0x41c dpm_suspend+0xf8/0x298 dpm_suspend_start+0x84/0xb4 suspend_devices_and_enter+0xbc/0x620 pm_suspend+0x210/0x348 state_store+0xb0/0x108 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x15c/0x1fc __vfs_write+0x54/0x18c vfs_write+0xe4/0x1a4 ksys_write+0x7c/0xe4 __arm64_sys_write+0x20/0x2c el0_svc_common+0xa8/0x160 el0_svc_handler+0x7c/0x98 el0_svc+0x8/0xc Fixes: 6aced33f4974 ("pinctrl: msm: drop wake_irqs bitmap") Cc: Douglas Anderson <dianders@chromium.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Lina Iyer <ilina@codeaurora.org> Cc: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200121180950.36959-1-swboyd@chromium.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-01-23hwmon: (k10temp) Display up to eight sets of CCD temperaturesGuenter Roeck
In HWiNFO, we see support for Tccd1, Tccd3, Tccd5, and Tccd7 temperature sensors on Zen2 based Threadripper CPUs. Checking register maps on Threadripper 3970X confirms SMN register addresses and values for those sensors. Register values observed in an idle system: 0x059950: 00000000 00000abc 00000000 00000ad8 0x059960: 00000000 00000ade 00000000 00000ae4 Under load: 0x059950: 00000000 00000c02 00000000 00000c14 0x059960: 00000000 00000c30 00000000 00000c22 More analysis shows that EPYC CPUs support up to 8 CCD temperature sensors. EPYC 7601 supports three CCD temperature sensors. Unlike Zen2 CPUs, the register space in Zen1 CPUs supports a maximum of four sensors, so only search for a maximum of four sensors on Zen1 CPUs. On top of that, in thm_10_0_sh_mask.h in the Linux kernel, we find definitions for THM_DIE{1-3}_TEMP__VALID_MASK, set to 0x00000800, as well as matching SMN addresses. This lets us conclude that bit 11 of the respective registers is a valid bit. With this assumption, the temperature offset is now 49 degrees C. This conveniently matches the documented temperature offset for Tdie, again suggesting that above registers indeed report temperatures sensor values. Assume that bit 11 is indeed a valid bit, and add support for the additional sensors. With this patch applied, output from 3970X (idle) looks as follows: k10temp-pci-00c3 Adapter: PCI adapter Tdie: +55.9°C Tctl: +55.9°C Tccd1: +39.8°C Tccd3: +43.8°C Tccd5: +43.8°C Tccd7: +44.8°C Tested-by: Michael Larabel <michael@phoronix.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24Merge tag 'amd-drm-fixes-5.5-2020-01-23' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.5-2020-01-23: amdgpu: - remove the experimental flag from renoir Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123191424.3849-1-alexander.deucher@amd.com
2020-01-24Merge tag 'drm-intel-fixes-2020-01-23' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Avoid overflow with huge userptr objects - uAPI fix to correctly handle negative values in engine->uabi_class/instance (cc: stable) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135045.GA12584@jlahtine-desk.ger.corp.intel.com