summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-06-17hw_random: ixp4xx: enable compile-testingArnd Bergmann
The driver is almost portable already, it just needs to include the new header for the cpu definition. Cc: Deepak Saxena <dsaxena@plexity.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-06-17pata: ixp4xx: split platform data to its own headerArnd Bergmann
Portable drivers cannot use mach/platform.h, so move the structure into its own header. With this, compile testing can be enabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-06-17soc: ixp4xx: move cpu detection to linux/soc/ixp4xx/cpu.hArnd Bergmann
Generic drivers are unable to use the feature macros from mach/cpu.h or the feature bits from mach/hardware.h, so move these into a global header file along with some dummy helpers that list these features as disabled elsewhere. Cc: David S. Miller <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Cc: Zoltan HERPAI <wigyori@uid0.hu> Cc: Raylynn Knight <rayknight@me.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-06-17usb: host: xhci-tegra: Use devm_platform_get_and_ioremap_resource()Yang Yingliang
Use devm_platform_get_and_ioremap_resource() to simplify code. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210616044519.2183826-3-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17usb: host: xhci-tegra: Add missing of_node_put() in tegra_xusb_probe()Yang Yingliang
This node pointer is returned by of_parse_phandle() with refcount incremented in this function. of_node_put() on it before exitting this function. Fixes: 971ee247060d ("usb: xhci: tegra: Enable ELPG for runtime/system PM") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210616044519.2183826-2-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17usb: host: xhci-tegra: add missing put_device() in tegra_xusb_probe()Yang Yingliang
Goto put_padctl to put refcount of device on error in tegra_xusb_probe() Fixes: 971ee247060d ("usb: xhci: tegra: Enable ELPG for runtime/system PM") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210616044519.2183826-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17usb: renesas-xhci: Fix handling of unknown ROM stateMoritz Fischer
The ROM load sometimes seems to return an unknown status (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. If the ROM load indeed failed this leads to failures when trying to communicate with the controller later on. Attempt to load firmware using RAM load in those cases. Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") Cc: stable@vger.kernel.org Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Vinod Koul <vkoul@kernel.org> Tested-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Moritz Fischer <mdf@kernel.org> Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17Merge tag 'irqchip-fixes-5.13-2' of ↵Thomas Gleixner
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes from Marc Zyngier: - Fix GICv3 NMI handling where an IRQ could be mistakenly handled as a NMI, with disatrous effects Link: https://lore.kernel.org/r/20210610171127.2404752-1-maz@kernel.org
2021-06-17firmware: turris-mox-rwtm: add marvell,armada-3700-rwtm-firmware compatible ↵Pali Rohár
string Add more generic compatible string 'marvell,armada-3700-rwtm-firmware' for this driver, since it can also be used on other Armada 3720 devices. Current compatible string 'cznic,turris-mox-rwtm' is kept for backward compatibility. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2021-06-17firmware: turris-mox-rwtm: show message about HWRNG registrationPali Rohár
Currently it is hard to determinate if on Armada 3720 device is HWRNG by running kernel accessible or not. So print information message into dmesg when HWRNG is available and registration was successful. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2021-06-17firmware: turris-mox-rwtm: fail probing when firmware does not support hwrngPali Rohár
When Marvell's rWTM firmware, which does not support the GET_RANDOM command, is used, kernel prints an error message hwrng: no data available every 10 seconds. Fail probing of this driver if the rWTM firmware does not support the GET_RANDOM command. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2021-06-17firmware: turris-mox-rwtm: report failures betterMarek Behún
Report a notice level message if a command is not supported by the rWTM firmware. This should not be an error, merely a notice, because the firmware can be used on boards that do not have manufacturing information burned. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2021-06-17firmware: turris-mox-rwtm: fix reply status decoding functionMarek Behún
The status decoding function mox_get_status() currently contains an incorrect check: if the error status is not MBOX_STS_SUCCESS, it always returns -EIO, so the comparison to MBOX_STS_FAIL is never executed and we don't get the actual error code sent by the firmware. Fix this. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2021-06-17ACPI: PRM: make symbol 'prm_module_list' staticWei Yongjun
The sparse tool complains as follows: drivers/acpi/prmt.c:53:1: warning: symbol 'prm_module_list' was not declared. Should it be static? This symbol is not used outside of prmt.c, so marks it static. Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-17ACPI: NVS: fix doc warnings in nvs.cBaokun Li
Fixes the following W=1 kernel build warning(s): drivers/acpi/nvs.c:94: warning: Function parameter or member 'start' not described in 'suspend_nvs_register' drivers/acpi/nvs.c:94: warning: Function parameter or member 'size' not described in 'suspend_nvs_register' Signed-off-by: Baokun Li <libaokun1@huawei.com> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-17ACPI: sysfs: fix doc warnings in device_sysfs.cBaokun Li
Fixes the following W=1 kernel build warning(s): drivers/acpi/device_sysfs.c:278: warning: Function parameter or member 'dev' not described in 'acpi_device_uevent_modalias' drivers/acpi/device_sysfs.c:278: warning: Function parameter or member 'env' not described in 'acpi_device_uevent_modalias' drivers/acpi/device_sysfs.c:323: warning: Function parameter or member 'dev' not described in 'acpi_device_modalias' drivers/acpi/device_sysfs.c:323: warning: Function parameter or member 'buf' not described in 'acpi_device_modalias' drivers/acpi/device_sysfs.c:323: warning: Function parameter or member 'size' not described in 'acpi_device_modalias' Signed-off-by: Baokun Li <libaokun1@huawei.com> [ rjw: Fix spelling: acpi -> ACPI ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-17cpuidle: teo: remove unneeded semicolon in teo_select()Wan Jiabing
Fix following coccicheck warning: drivers/cpuidle/governors/teo.c:315:10-11: Unneeded semicolon Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-17thermal/cpufreq_cooling: Update offline CPUs per-cpu thermal_pressureLukasz Luba
The thermal pressure signal gives information to the scheduler about reduced CPU capacity due to thermal. It is based on a value stored in a per-cpu 'thermal_pressure' variable. The online CPUs will get the new value there, while the offline won't. Unfortunately, when the CPU is back online, the value read from per-cpu variable might be wrong (stale data). This might affect the scheduler decisions, since it sees the CPU capacity differently than what is actually available. Fix it by making sure that all online+offline CPUs would get the proper value in their per-cpu variable when thermal framework sets capping. Fixes: f12e4f66ab6a3 ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping") Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20210614191030.22241-1-lukasz.luba@arm.com
2021-06-17ACPI: APEI: fix synchronous external aborts in user-modeXiaofei Tan
Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work"), do_sea() would unconditionally signal the affected task from the arch code. Since that change, the GHES driver sends the signals. This exposes a problem as errors the GHES driver doesn't understand or doesn't handle effectively are silently ignored. It will cause the errors get taken again, and circulate endlessly. User-space task get stuck in this loop. Existing firmware on Kunpeng9xx systems reports cache errors with the 'ARM Processor Error' CPER records. Do memory failure handling for ARM Processor Error Section just like for Memory Error Section. Fixes: 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work") Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-17bus: fsl-mc: mc-io: Correct misdocumentation of 'dpmcp_dev' paramLee Jones
Fixes the following W=1 kernel build warning(s): drivers/bus/fsl-mc/mc-io.c:70: warning: Function parameter or member 'dpmcp_dev' not described in 'fsl_create_mc_io' Cc: Stuart Yoder <stuyoder@gmail.com> Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210617110500.15907-8-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17bus: fsl-mc-msi: Fix a little doc-rot pertaining to 'np' to 'fwnode' conversionLee Jones
Fixes the following W=1 kernel build warning(s): drivers/bus/fsl-mc/fsl-mc-msi.c:164: warning: Function parameter or member 'fwnode' not described in 'fsl_mc_msi_create_irq_domain' drivers/bus/fsl-mc/fsl-mc-msi.c:164: warning: Excess function parameter 'np' description in 'fsl_mc_msi_create_irq_domain' Cc: Stuart Yoder <stuyoder@gmail.com> Cc: German Rivera <German.Rivera@freescale.com> Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210617110500.15907-7-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17bus: fsl-mc: fsl-mc-allocator: Fix misspelling of 'new_mc_adev' and demote ↵Lee Jones
non-kernel-doc headers Fixes the following W=1 kernel build warning(s): drivers/bus/fsl-mc/fsl-mc-allocator.c:271: warning: Function parameter or member 'new_mc_adev' not described in 'fsl_mc_object_allocate' drivers/bus/fsl-mc/fsl-mc-allocator.c:271: warning: Excess function parameter 'new_mc_dev' description in 'fsl_mc_object_allocate' drivers/bus/fsl-mc/fsl-mc-allocator.c:417: warning: Function parameter or member 'mc_bus_dev' not described in 'fsl_mc_cleanup_irq_pool' drivers/bus/fsl-mc/fsl-mc-allocator.c:417: warning: expecting prototype for Teardown the interrupt pool associated with an fsl(). Prototype was for fsl_mc_cleanup_irq_pool() instead drivers/bus/fsl-mc/fsl-mc-allocator.c:443: warning: Function parameter or member 'mc_dev' not described in 'fsl_mc_allocate_irqs' drivers/bus/fsl-mc/fsl-mc-allocator.c:443: warning: expecting prototype for Allocate the IRQs required by a given fsl(). Prototype was for fsl_mc_allocate_irqs() instead drivers/bus/fsl-mc/fsl-mc-allocator.c:586: warning: Function parameter or member 'mc_dev' not described in 'fsl_mc_allocator_probe' drivers/bus/fsl-mc/fsl-mc-allocator.c:618: warning: Function parameter or member 'mc_dev' not described in 'fsl_mc_allocator_remove' Cc: Stuart Yoder <stuyoder@gmail.com> Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210617110500.15907-6-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17bus: fsl-mc: dprc-driver: Fix some missing/incorrect function parameter ↵Lee Jones
descriptions Fixes the following W=1 kernel build warning(s): drivers/bus/fsl-mc/dprc-driver.c:360: warning: Function parameter or member 'alloc_interrupts' not described in 'dprc_scan_container' drivers/bus/fsl-mc/dprc-driver.c:383: warning: Function parameter or member 'irq_num' not described in 'dprc_irq0_handler' drivers/bus/fsl-mc/dprc-driver.c:383: warning: Excess function parameter 'irq' description in 'dprc_irq0_handler' drivers/bus/fsl-mc/dprc-driver.c:394: warning: Function parameter or member 'irq_num' not described in 'dprc_irq0_handler_thread' drivers/bus/fsl-mc/dprc-driver.c:394: warning: Excess function parameter 'irq' description in 'dprc_irq0_handler_thread' Cc: Stuart Yoder <stuyoder@gmail.com> Cc: German Rivera <German.Rivera@freescale.com> Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210617110500.15907-5-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17bus: fsl-mc: dprc: Fix a couple of misspelling and formatting issuesLee Jones
Fixes the following W=1 kernel build warning(s): drivers/bus/fsl-mc/dprc.c:345: warning: Function parameter or member 'attr' not described in 'dprc_get_attributes' drivers/bus/fsl-mc/dprc.c:521: warning: Function parameter or member 'obj_type' not described in 'dprc_get_obj_region' Cc: Stuart Yoder <stuyoder@gmail.com> Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210617110500.15907-4-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17bus: fsl-mc: fsl-mc-bus: Demote a bunch of non-conformant kernel-doc headers ↵Lee Jones
and help others Fixes the following W=1 kernel build warning(s): drivers/bus/fsl-mc/fsl-mc-bus.c:30: warning: expecting prototype for Default DMA mask for devices on a fsl(). Prototype was for FSL_MC_DEFAULT_DMA_MASK() instead drivers/bus/fsl-mc/fsl-mc-bus.c:45: warning: Function parameter or member 'fsl_mc_regs' not described in 'fsl_mc' drivers/bus/fsl-mc/fsl-mc-bus.c:124: warning: Function parameter or member 'dev' not described in 'fsl_mc_bus_uevent' drivers/bus/fsl-mc/fsl-mc-bus.c:124: warning: Function parameter or member 'env' not described in 'fsl_mc_bus_uevent' drivers/bus/fsl-mc/fsl-mc-bus.c:480: warning: Function parameter or member 'mc_driver' not described in '__fsl_mc_driver_register' drivers/bus/fsl-mc/fsl-mc-bus.c:480: warning: Function parameter or member 'owner' not described in '__fsl_mc_driver_register' drivers/bus/fsl-mc/fsl-mc-bus.c:511: warning: Function parameter or member 'mc_driver' not described in 'fsl_mc_driver_unregister' drivers/bus/fsl-mc/fsl-mc-bus.c:571: warning: Function parameter or member 'dev' not described in 'fsl_mc_get_root_dprc' drivers/bus/fsl-mc/fsl-mc-bus.c:571: warning: Function parameter or member 'root_dprc_dev' not described in 'fsl_mc_get_root_dprc' drivers/bus/fsl-mc/fsl-mc-bus.c:739: warning: Function parameter or member 'dev' not described in 'fsl_mc_is_root_dprc' drivers/bus/fsl-mc/fsl-mc-bus.c:767: warning: Function parameter or member 'obj_desc' not described in 'fsl_mc_device_add' drivers/bus/fsl-mc/fsl-mc-bus.c:767: warning: Function parameter or member 'mc_io' not described in 'fsl_mc_device_add' drivers/bus/fsl-mc/fsl-mc-bus.c:767: warning: Function parameter or member 'parent_dev' not described in 'fsl_mc_device_add' drivers/bus/fsl-mc/fsl-mc-bus.c:767: warning: Function parameter or member 'new_mc_dev' not described in 'fsl_mc_device_add' drivers/bus/fsl-mc/fsl-mc-bus.c:767: warning: expecting prototype for Add a newly discovered fsl(). Prototype was for fsl_mc_device_add() instead drivers/bus/fsl-mc/fsl-mc-bus.c:1066: warning: Function parameter or member 'pdev' not described in 'fsl_mc_bus_probe' drivers/bus/fsl-mc/fsl-mc-bus.c:1190: warning: Function parameter or member 'pdev' not described in 'fsl_mc_bus_remove' Cc: Stuart Yoder <stuyoder@gmail.com> Cc: German Rivera <German.Rivera@freescale.com> Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210617110500.15907-3-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17bus: fsl-mc: mc-sys: Supply missing function names in kernel-doc headersLee Jones
Fixes the following W=1 kernel build warning(s): drivers/bus/fsl-mc/mc-sys.c:20: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/bus/fsl-mc/mc-sys.c:151: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/bus/fsl-mc/mc-sys.c:197: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/bus/fsl-mc/mc-sys.c:237: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Stuart Yoder <stuyoder@gmail.com> Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210617110500.15907-2-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17bus: fsl-mc: mc-io: Supply function names for 'fsl_create_mc_io()' and ↵Lee Jones
'fsl_destroy_mc_io()' Fixes the following W=1 kernel build warning(s): drivers/bus/fsl-mc/mc-io.c:53: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/bus/fsl-mc/mc-io.c:126: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Stuart Yoder <stuyoder@gmail.com> Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210617110500.15907-1-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17extcon: extcon-max8997: Simplify driver using devmMatti Vaittinen
Simplify driver by switching to use the resource managed IRQ requesting and resource managed work-queue initialization. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/r/61190cc280a63baeb05ec570282bb3677bee8e7b.1623146580.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-06-17extcon: extcon-max8997: Fix IRQ freeing at error pathMatti Vaittinen
If reading MAX8997_MUIC_REG_STATUS1 fails at probe the driver exits without freeing the requested IRQs. Free the IRQs prior returning if reading the status fails. Fixes: 3e34c8198960 ("extcon: max8997: Avoid forcing UART path on drive probe") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/r/27ee4a48ee775c3f8c9d90459c18b6f2b15edc76.1623146580.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-06-17extcon: extcon-max77693.c: Fix potential work-queue cancellation raceMatti Vaittinen
The extcon IRQ schedules a work item. IRQ is requested using devm while WQ is cancelld at remove(). This mixing of devm and manual unwinding has potential case where the WQ has been emptied (.remove() was ran) but devm unwinding of IRQ was not yet done. It may be possible the IRQ is triggered at this point scheduling new work item to the already flushed queue. According to the input documentation the input device allocated by devm_input_allocate_device() does not need to be explicitly unregistered. Use the new devm_work_autocancel() and remove the remove() to simplify the code. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/r/cbe8205eed8276f6e6db5003cfe51b8b0d4ac966.1623146580.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-06-17hwmon: (ntc_thermistor) Drop unused headers.Jonathan Cameron
The IIO usage in this driver is purely consumer so it should only be including linux/iio/consumer.h Whilst here drop pm_runtime.h as there is no runtime power management in the driver. Found using include-what-you-use and manual inspection of the suggestions. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210611142257.103094-1-jic23@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (pmbus) Add driver for Delta DPS-920AB PSURobert Marko
This adds support for the Delta DPS-920AB PSU. Only missing feature is fan control which the PSU supports. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://lore.kernel.org/r/20210607103431.2039073-1-robert.marko@sartura.hr [groeck: Add MODULE_IMPORT_NS(PMBUS);] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (pmbus/pim4328) Add PMBus driver for PIM4006, PIM4328 and PIM4820Erik Rosen
Add hardware monitoring support for Flex power interface modules PIM4006, PIM4328 and PIM4820. Signed-off-by: Erik Rosen <erik.rosen@metormote.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (pmbus) Allow phase function even if it's not on pageErik Rosen
Allow the use of a phase function even if it does not exist on the associated page. Signed-off-by: Erik Rosen <erik.rosen@metormote.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (pmbus) Add support for reading direct mode coefficientsErik Rosen
Add support for reading and decoding direct format coefficients to the PMBus core driver. If the new flag PMBUS_USE_COEFFICIENTS_CMD is set, the driver will use the COEFFICIENTS register together with the information in the pmbus_sensor_attr structs to initialize relevant coefficients for the direct mode format. Signed-off-by: Erik Rosen <erik.rosen@metormote.com> [groeck: Initialize ret with -EINVAL in pmbus_init_coefficients()] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (pmbus) Add new pmbus flag NO_WRITE_PROTECTErik Rosen
Some PMBus chips respond with invalid data when reading the WRITE_PROTECT register. For such chips, this flag should be set so that the PMBus core driver doesn't use the WRITE_PROTECT command to determine its behavior. Signed-off-by: Erik Rosen <erik.rosen@metormote.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (pmbus_core) Check adapter PEC supportMadhava Reddy Siddareddygari
Currently, for Packet Error Checking (PEC) only the controller is checked for support. This causes problems on the cisco-8000 platform where a SMBUS transaction errors are observed. This is because PEC has to be enabled only if both controller and adapter support it. Added code to check PEC capability for adapter and enable it only if both controller and adapter supports PEC. Signed-off-by: Madhava Reddy Siddareddygari <msiddare@cisco.com> [Upstream from SONiC https://github.com/Azure/sonic-linux-kernel/pull/215] Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/r/20210605052700.541455-1-pmenzel@molgen.mpg.de [groeck: Dropped unnecessary continuation line] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (ina3221) use CVRF only for single-shot conversionNinad Malwade
As per current logic the wait time per conversion is arouns 430ms for 512 samples and around 860ms for 1024 samples for 3 channels considering 140us as the bus voltage and shunt voltage sampling conversion time. This waiting time is a lot for the continuous mode and even for the single shot mode. For continuous mode when moving average is considered the waiting for CVRF bit is not required and the data from the previous conversion is sufficuent. As mentioned in the datasheet the conversion ready bit is provided to help coordinate single-shot conversions, we can restrict the use to single-shot mode only. Also, the conversion time is for the averaged samples, the wait time for the polling can omit the number of samples consideration. Signed-off-by: Ninad Malwade <nmalwade@nvidia.com> Link: https://lore.kernel.org/r/1622789683-30931-1-git-send-email-nmalwade@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (max31790) Detect and report zero fan speedGuenter Roeck
If a fan is not running or not connected, of if fan monitoring is disabled, the fan count register returns a fixed value of 0xffe0. So far this is then translated to a RPM value larger than 0. Since this is misleading and does not really make much sense, report a fan RPM of 0 in this situation. Cc: Jan Kundrát <jan.kundrat@cesnet.cz> Cc: Václav Kubernát <kubernat@cesnet.cz> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Václav Kubernát <kubernat@cesnet.cz> Link: https://lore.kernel.org/r/20210526154022.3223012-7-linux@roeck-us.net
2021-06-17hwmon: (max31790) Clear fan fault after reporting itGuenter Roeck
Fault bits in MAX31790 are sticky and have to be cleared explicitly. A write operation into either the 'Target Duty Cycle' register or the 'Target Count' register is necessary to clear a fault. At the same time, we can never clear cached fault status values before reading them because the companion fault status for any given fan is cleared as well when clearing a fault. Cc: Jan Kundrát <jan.kundrat@cesnet.cz> Cc: Václav Kubernát <kubernat@cesnet.cz> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Václav Kubernát <kubernat@cesnet.cz> Link: https://lore.kernel.org/r/20210526154022.3223012-6-linux@roeck-us.net
2021-06-17hwmon: (max31790) Fix pwmX_enable attributesGuenter Roeck
pwmX_enable supports three possible values: 0: Fan control disabled. Duty cycle is fixed to 0% 1: Fan control enabled, pwm mode. Duty cycle is determined by values written into Target Duty Cycle registers. 2: Fan control enabled, rpm mode Duty cycle is adjusted such that fan speed matches the values in Target Count registers The current code does not do this; instead, it mixes pwm control configuration with fan speed monitoring configuration. Worse, it reports that pwm control would be disabled (pwmX_enable==0) when it is in fact enabled in pwm mode. Part of the problem may be that the chip sets the "TACH input enable" bit on its own whenever the mode bit is set to RPM mode, but that doesn't mean that "TACH input enable" accurately reflects the pwm mode. Fix it up and only handle pwm control with the pwmX_enable attributes. In the documentation, clarify that disabling pwm control (pwmX_enable=0) sets the pwm duty cycle to 0%. In the code, explain why TACH_INPUT_EN is set together with RPM_MODE. While at it, only update the configuration register if the configuration has changed, and only update the cached configuration if updating the chip configuration was successful. Cc: Jan Kundrát <jan.kundrat@cesnet.cz> Cc: Václav Kubernát <kubernat@cesnet.cz> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Václav Kubernát <kubernat@cesnet.cz> Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/r/20210526154022.3223012-4-linux@roeck-us.net
2021-06-17hwmon: (max31790) Report correct current pwm duty cyclesGuenter Roeck
The MAX31790 has two sets of registers for pwm duty cycles, one to request a duty cycle and one to read the actual current duty cycle. Both do not have to be the same. When reporting the pwm duty cycle to the user, the actual pwm duty cycle from pwm duty cycle registers needs to be reported. When setting it, the pwm target duty cycle needs to be written. Since we don't know the actual pwm duty cycle after a target pwm duty cycle has been written, set the valid flag to false to indicate that actual pwm duty cycle should be read from the chip instead of using cached values. Cc: Jan Kundrát <jan.kundrat@cesnet.cz> Cc: Václav Kubernát <kubernat@cesnet.cz> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Václav Kubernát <kubernat@ceesnet.cz> Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/r/20210526154022.3223012-3-linux@roeck-us.net
2021-06-17hwmon: (max31790) Fix fan speed reporting for fan7..12Guenter Roeck
Fans 7..12 do not have their own set of configuration registers. So far the code ignored that and read beyond the end of the configuration register range to get the tachometer period. This resulted in more or less random fan speed values for those fans. The datasheet is quite vague when it comes to defining the tachometer period for fans 7..12. Experiments confirm that the period is the same for both fans associated with a given set of configuration registers. Fixes: 54187ff9d766 ("hwmon: (max31790) Convert to use new hwmon registration API") Fixes: 195a4b4298a7 ("hwmon: Driver for Maxim MAX31790") Cc: Jan Kundrát <jan.kundrat@cesnet.cz> Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Cc: Václav Kubernát <kubernat@cesnet.cz> Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210526154022.3223012-2-linux@roeck-us.net
2021-06-17hwmon: (sht4x) Fix sht4x_read_values return valueJoe Perches
Kernel doc for sht4x_read_values() shows 0 on success, 1 on failure but the return value on success is actually always positive as it is set to SHT4X_RESPONSE_LENGTH by a successful call to i2c_master_recv(). Miscellanea: o Update the kernel doc for sht4x_read_values to 0 for success or -ERRNO o Remove incorrectly used kernel doc /** header for other _read functions o Typo fix succesfull->successful o Reverse a test to unindent a block and use goto unlock o Declare cmd[SHT4X_CMD_LEN] rather than cmd[] At least for gcc 10.2, object size is reduced a tiny bit. $ size drivers/hwmon/sht4x.o* text data bss dec hex filename 1752 404 256 2412 96c drivers/hwmon/sht4x.o.new 1825 404 256 2485 9b5 drivers/hwmon/sht4x.o.old Signed-off-by: Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/60eedce497137eb34448c0c77e01ec9d9c972ad7.camel@perches.com Reviewed by: Navin Sankar Velliangiri <navin@linumiz.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: Add sht4x Temperature and Humidity Sensor DriverNavin Sankar Velliangiri
This patch adds a hwmon driver for the SHT4x Temperature and Humidity sensor. Signed-off-by: Navin Sankar Velliangiri <navin@linumiz.com> [groeck: dropped unnecessary empty line and continuation lines] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (adm1275) enable adm1272 temperature reportingChu Lin
adm1272 supports temperature reporting but it is disabled by default. Tested: ls temp1_* temp1_crit temp1_highest temp1_max temp1_crit_alarm temp1_input temp1_max_alarm cat temp1_input 26642 Signed-off-by: Chu Lin <linchuyuan@google.com> Link: https://lore.kernel.org/r/20210512171043.2433694-1-linchuyuan@google.com [groeck: Updated subject to reflect correct driver] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (pmbus) Add support for MPS Multi-phase mp2888 controllerVadim Pasternak
Add support for mp2888 device from Monolithic Power Systems, Inc. (MPS) vendor. This is a digital, multi-phase, pulse-width modulation controller. This device supports: - One power rail. - Programmable Multi-Phase up to 10 Phases. - PWM-VID Interface - One pages 0 for telemetry. - Programmable pins for PMBus Address. - Built-In EEPROM to Store Custom Configurations. - Can configured VOUT readout in direct or VID format and allows setting of different formats on rails 1 and 2. For VID the following protocols are available: VR13 mode with 5-mV DAC; VR13 mode with 10-mV DAC, IMVP9 mode with 5-mV DAC. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20210511055619.118104-3-vadimp@nvidia.com [groeck: Add MODULE_IMPORT_NS] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (pmbus) Increase maximum number of phases per pageVadim Pasternak
Increase maximum number of phases from 8 to 10 to support multi-phase devices allowing up to 10 phases. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20210511055619.118104-2-vadimp@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (bt1-pvt) Remove redundant error printing in pvt_request_regs()Zhen Lei
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210511091843.4561-1-thunder.leizhen@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-17hwmon: (pmbus) Add support for additional Flex BMR converters to pmbusErik Rosen
Add support for Flex BMR310, BMR456, BMR457, BMR458, BMR480, BMR490, BMR491 and BMR492 to the pmbus driver Signed-off-by: Erik Rosen <erik.rosen@metormote.com> Link: https://lore.kernel.org/r/20210507194023.61138-4-erik.rosen@metormote.com [groeck: Fixed minor whitespace error] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
generated by cgit (git 2.34.1) at 2025-09-24 12:24:44 +0000