user/sven/linux.git/drivers/reset, branch v5.4.68

reset: uniphier: Add SCSSI reset control for each channel

2020-02-24T07:36:41Z

[ Upstream commit f4aec227e985e31d2fdc5608daf48e3de19157b7 ] SCSSI has reset controls for each channel in the SoCs newer than Pro4, so this adds missing reset controls for channel 1, 2 and 3. And more, this moves MCSSI reset ID after SCSSI. Fixes: 6b39fd590aeb ("reset: uniphier: add reset control support for SPI") Signed-off-by: Kunihiko Hayashi Acked-by: Masahiro Yamada Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin

reset: Fix {of,devm}_reset_control_array_get kerneldoc return types

2020-01-23T07:22:43Z

commit 723c0011c7f6992f57e2c629fa9c89141acc115f upstream. of_reset_control_array_get() and devm_reset_control_array_get() return struct reset_control pointers, not internal struct reset_control_array pointers, just like all other reset control API calls. Correct the kerneldoc to match the code. Fixes: 17c82e206d2a3cd8 ("reset: Add APIs to manage array of resets") Signed-off-by: Geert Uytterhoeven Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman

reset: brcmstb: Remove resource checks

2020-01-17T18:48:29Z

commit ce89d8d3a70fa530e16f0b0f8994385a214cd0c0 upstream. The use of IS_ALIGNED() is incorrect, the typical resource we pass looks like this: start: 0x8404318, size: 0x30. When using IS_ALIGNED() we will get the following 0x8404318 & (0x18 - 1) = 0x10 which is definitively not equal to 0, same goes with the size. These two checks would make the driver fail probing. Remove the resource checks, since there should be no constraint on the base addresse or size. Fixes: 77750bc089e4 ("reset: Add Broadcom STB SW_INIT reset controller driver") Signed-off-by: Florian Fainelli Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman

reset: Do not register resource data for missing resets

2020-01-12T11:21:21Z

[ Upstream commit db23808615e29d9a04f96806cac56f78b0fee0ef ] When an optional reset is not present, __devm_reset_control_get() and devm_reset_control_array_get() still register resource data to release the non-existing reset on cleanup, which is futile. Fix this by skipping NULL reset control pointers. Signed-off-by: Geert Uytterhoeven Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin

reset: fix of_reset_control_get_count kerneldoc comment

2019-10-24T08:26:33Z

Add a newline and remove a superfluous kerneldoc marker before the of_reset_control_get_count kerneldoc comment, to fix documentation build warnings: ./drivers/reset/core.c:832: warning: Incorrect use of kernel-doc format: * of_reset_control_get_count - Count number of resets available with a device ./drivers/reset/core.c:840: warning: Function parameter or member 'node' not described in 'of_reset_control_get_count' Fixes: 17c82e206d2a ("reset: Add APIs to manage array of resets") Signed-off-by: Philipp Zabel

reset: fix of_reset_simple_xlate kerneldoc comment

2019-10-24T08:26:33Z

The flags parameter never made it into the API, but was erroneously included in the kerneldoc comment. Remove it to fix a documentation build warning: ./drivers/reset/core.c:86: warning: Excess function parameter 'flags' description in 'of_reset_simple_xlate' Fixes: 61fc41317666 ("reset: Add reset controller API") Signed-off-by: Philipp Zabel

reset: Fix memory leak in reset_control_array_put()

2019-10-22T08:56:41Z

Memory allocated for 'struct reset_control_array' in of_reset_control_array_get() is never freed in reset_control_array_put() resulting in kmemleak showing the following backtrace. backtrace: [<00000000c5f17595>] __kmalloc+0x1b0/0x2b0 [<00000000bd499e13>] of_reset_control_array_get+0xa4/0x180 [<000000004cc02754>] 0xffff800008c669e4 [<0000000050a83b24>] platform_drv_probe+0x50/0xa0 [<00000000d3a0b0bc>] really_probe+0x108/0x348 [<000000005aa458ac>] driver_probe_device+0x58/0x100 [<000000008853626c>] device_driver_attach+0x6c/0x90 [<0000000085308d19>] __driver_attach+0x84/0xc8 [<00000000080d35f2>] bus_for_each_dev+0x74/0xc8 [<00000000dd7f015b>] driver_attach+0x20/0x28 [<00000000923ba6e6>] bus_add_driver+0x148/0x1f0 [<0000000061473b66>] driver_register+0x60/0x110 [<00000000c5bec167>] __platform_driver_register+0x40/0x48 [<000000007c764b4f>] 0xffff800008c6c020 [<0000000047ec2e8c>] do_one_initcall+0x5c/0x1b0 [<0000000093d4b50d>] do_init_module+0x54/0x1d0 Fixes: 17c82e206d2a ("reset: Add APIs to manage array of resets") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Philipp Zabel

Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2019-09-30T17:04:28Z

Pull ARM SoC fixes from Olof Johansson: "A few fixes that have trickled in through the merge window: - Video fixes for OMAP due to panel-dpi driver removal - Clock fixes for OMAP that broke no-idle quirks + nfsroot on DRA7 - Fixing arch version on ASpeed ast2500 - Two fixes for reset handling on ARM SCMI" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: aspeed: ast2500 is ARMv6K reset: reset-scmi: add missing handle initialisation firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_reset bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle() ARM: dts: logicpd-som-lv: Fix i2c2 and i2c3 Pin mux ARM: dts: am3517-evm: Fix missing video ARM: dts: logicpd-torpedo-baseboard: Fix missing video ARM: omap2plus_defconfig: Fix missing video bus: ti-sysc: Fix handling of invalid clocks bus: ti-sysc: Fix clock handling for no-idle quirks

reset: reset-scmi: add missing handle initialisation

2019-09-18T12:42:44Z

scmi_reset_data->handle needs to be initialised at probe, so that it can be later used to access scmi reset protocol APIs using the same. Since it was tested with a module that obtained handle elsewhere, it was missed easily. Add the missing scmi_reset_data->handle initialisation to fix the issue. Fixes: c8ae9c2da1cc ("reset: Add support for resets provided by SCMI") Acked-by: Philipp Zabel Reported-by: Etienne Carriere Signed-off-by: Sudeep Holla

Merge tag 'scmi-updates-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/drivers

2019-08-14T18:46:38Z

ARM SCMI updates/fixes for v5.4 Handful of fixes/updates including: 1. SCMI v2.0(recently released) support for: - Performance protocol fast channels - Reset Management Protocol 2. SCMI infrastructure/core support for recieve(Rx) channels, asynchronous commands and delayed response 3. Usage of asynchronous commands for clock rate setting and sensor reading based on the attributes read from the firmware 4. Miscellaneous cleanups(typos, naming alignment with specification, and SPDX License identifier) 5. Couple of fixes: removal of extra check for invalid length and additional check to ensure platform/firmware has released shared memory before using it in OSPM * tag 'scmi-updates-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (22 commits) reset: Add support for resets provided by SCMI firmware: arm_scmi: Add RESET protocol in SCMI v2.0 dt-bindings: arm: Extend SCMI to support new reset protocol firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possible firmware: arm_scmi: Drop config flag in clk_ops->rate_set firmware: arm_scmi: Add asynchronous sensor read if it supports firmware: arm_scmi: Drop async flag in sensor_ops->reading_get firmware: arm_scmi: Add support for asynchronous commands and delayed response firmware: arm_scmi: Add mechanism to unpack message headers firmware: arm_scmi: Separate out tx buffer handling and prepare to add rx firmware: arm_scmi: Add receive channel support for notifications firmware: arm_scmi: Segregate tx channel handling and prepare to add rx firmware: arm_scmi: Reorder some functions to avoid forward declarations firmware: arm_scmi: Check if platform has released shmem before using firmware: arm_scmi: Use the term 'message' instead of 'command' firmware: arm_scmi: Fix few trivial typos in comments firmware: arm_scmi: Remove extra check for invalid length message responses ... Link: https://lore.kernel.org/r/20190814172454.26191-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann