Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4 |
|
#
c71d4b65 |
| 13-Sep-2023 |
Chen-Yu Tsai <wenst@chromium.org> |
regulator: mt6358: Fail probe on unknown chip ID
[ Upstream commit 7442edec72bc657e6ce38ae01de9f10e55decfaa ]
The MT6358 and MT6366 PMICs, and likely many others from MediaTek, have a chip ID regis
regulator: mt6358: Fail probe on unknown chip ID
[ Upstream commit 7442edec72bc657e6ce38ae01de9f10e55decfaa ]
The MT6358 and MT6366 PMICs, and likely many others from MediaTek, have a chip ID register, making the chip semi-discoverable.
The driver currently supports two PMICs and expects to be probed on one or the other. It does not account for incorrect mfd driver entries or device trees. While these should not happen, if they do, it could be catastrophic for the device. The driver should be sure the hardware is what it expects.
Make the driver fail to probe if the chip ID presented is not a known one.
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Fixes: f0e3c6261af1 ("regulator: mt6366: Add support for MT6366 regulator") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230913082919.1631287-2-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
7e37c851 |
| 20-Sep-2023 |
Chen-Yu Tsai <wenst@chromium.org> |
regulator: mt6358: split ops for buck and linear range LDO regulators
The buck and linear range LDO (VSRAM_*) regulators share one set of ops. This set includes support for get/set mode. However thi
regulator: mt6358: split ops for buck and linear range LDO regulators
The buck and linear range LDO (VSRAM_*) regulators share one set of ops. This set includes support for get/set mode. However this only makes sense for buck regulators, not LDOs. The callbacks were not checking whether the register offset and/or mask for mode setting was valid or not. This ends up making the kernel report "normal" mode operation for the LDOs.
Create a new set of ops without the get/set mode callbacks for the linear range LDO regulators.
Fixes: f67ff1bd58f0 ("regulator: mt6358: Add support for MT6358 regulator") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230920085336.136238-1-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40 |
|
#
67cb6088 |
| 21-Jul-2023 |
Chen-Yu Tsai <wenst@chromium.org> |
regulator: mt6358: Fix incorrect VCN33 sync error message
After syncing the enable status of VCN33_WIFI to VCN33_BT, the driver will disable VCN33_WIFI. If it fails it will error out with a message.
regulator: mt6358: Fix incorrect VCN33 sync error message
After syncing the enable status of VCN33_WIFI to VCN33_BT, the driver will disable VCN33_WIFI. If it fails it will error out with a message. However the error message incorrectly refers to VCN33_BT.
Fix the error message so that it correctly refers to VCN33_WIFI.
Suggested-by: Fei Shao <fshao@chromium.org> Fixes: 65bae54e08c1 ("regulator: mt6358: Merge VCN33_* regulators") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230721082903.2038975-4-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
649fee5a |
| 21-Jul-2023 |
Chen-Yu Tsai <wenst@chromium.org> |
regulator: mt6358: Sync VCN33_* enable status after checking ID
Syncing VCN33_* enable status should be done after checking the PMIC's ID, to avoid setting random bits on other PMICs.
Suggested-by:
regulator: mt6358: Sync VCN33_* enable status after checking ID
Syncing VCN33_* enable status should be done after checking the PMIC's ID, to avoid setting random bits on other PMICs.
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Fixes: 65bae54e08c1 ("regulator: mt6358: Merge VCN33_* regulators") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230721082903.2038975-3-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33 |
|
#
ea861df7 |
| 09-Jun-2023 |
Chen-Yu Tsai <wenst@chromium.org> |
regulator: mt6358: Use linear voltage helpers for single range regulators
Some of the regulators on the MT6358/MT6366 PMICs have just one linear voltage range. These are the bulk regulators and VSRA
regulator: mt6358: Use linear voltage helpers for single range regulators
Some of the regulators on the MT6358/MT6366 PMICs have just one linear voltage range. These are the bulk regulators and VSRAM_* LDOs. Currently they are modeled with one linear range, but also have their minimum, maximum, and step voltage described.
Convert them to the linear voltage helpers. These helpers are a bit simpler, and we can also drop the linear range definitions. Also reflow the touched lines now that they are shorter.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230609083009.2822259-7-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
1ff35e66 |
| 09-Jun-2023 |
Chen-Yu Tsai <wenst@chromium.org> |
regulator: mt6358: Const-ify mt6358_regulator_info data structures
In the MT6358 regulator driver, each regulator is described by a |struct regulator_desc| wrapped by a |struct mt6358_regulator_info
regulator: mt6358: Const-ify mt6358_regulator_info data structures
In the MT6358 regulator driver, each regulator is described by a |struct regulator_desc| wrapped by a |struct mt6358_regulator_info|. The latter was tied to the regulator device using the config's driver_data field, which meant that the variables could not be constant.
Since each regulator device has a pointer to its regulator_desc, and mt6358_regulator_info wraps that, the driver could use container_of() to retrieve it instead.
Switch to using container_of(), drop tha driver_data setting, and const-ify all the regulator descriptions.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230609083009.2822259-6-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
04ba6652 |
| 09-Jun-2023 |
Chen-Yu Tsai <wenst@chromium.org> |
regulator: mt6358: Drop *_SSHUB regulators
The *_SSHUB regulators are actually alternate configuration interfaces for their non *_SSHUB counterparts. They are not separate regulator outputs. These r
regulator: mt6358: Drop *_SSHUB regulators
The *_SSHUB regulators are actually alternate configuration interfaces for their non *_SSHUB counterparts. They are not separate regulator outputs. These registers are intended for the companion processor to use to configure the power rails while the main processor is sleeping. They are not intended for the main operating system to use.
Since they are not real outputs they shouldn't be modeled separately. Remove them. Luckily no device tree actually uses them.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20230609083009.2822259-5-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
65bae54e |
| 09-Jun-2023 |
Chen-Yu Tsai <wenst@chromium.org> |
regulator: mt6358: Merge VCN33_* regulators
The VCN33_BT and VCN33_WIFI regulators are actually the same regulator, having the same voltage setting and output pin. There are simply two enable bits t
regulator: mt6358: Merge VCN33_* regulators
The VCN33_BT and VCN33_WIFI regulators are actually the same regulator, having the same voltage setting and output pin. There are simply two enable bits that are ORed together to enable the regulator.
Having two regulators representing the same output pin is misleading from a design matching standpoint, and also error-prone in driver implementations. If consumers try to set different voltages on either regulator, the one set later would override the one set before. There are ways around this, such as chaining them together and having the downstream one act as a switch. But given there's only one output pin, such a workaround doesn't match reality.
Remove the VCN33_WIFI regulator. During the probe phase, have the driver sync the enable status of VCN33_WIFI to VCN33_BT. Also drop the suffix so that the regulator name matches the pin name in the datasheet.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230609083009.2822259-4-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20 |
|
#
d3b81d97 |
| 16-Mar-2023 |
Douglas Anderson <dianders@chromium.org> |
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.19 and 5.4
This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") but changes regulat
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.19 and 5.4
This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") but changes regulators didn't exist in Linux 4.19 but did exist in Linux 5.4.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.3.I45bf925ca9537da5f647e2acb0ad207c0c98af81@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
f0e3c626 |
| 01-Apr-2022 |
Johnson Wang <johnson.wang@mediatek.com> |
regulator: mt6366: Add support for MT6366 regulator
The MT6366 is a regulator found on boards based on MediaTek MT8186 and probably other SoCs. It is a so called pmic and connects as a slave to SoC
regulator: mt6366: Add support for MT6366 regulator
The MT6366 is a regulator found on boards based on MediaTek MT8186 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Johnson Wang <johnson.wang@mediatek.com> Link: https://lore.kernel.org/r/20220401080212.27383-2-johnson.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30 |
|
#
d077002c |
| 16-Mar-2022 |
Johnson Wang <johnson.wang@mediatek.com> |
regulator: mt6366: Add support for MT6366 regulator
The MT6366 is a regulator found on boards based on MediaTek MT8186 and probably other SoCs. It is a so called pmic and connects as a slave to SoC
regulator: mt6366: Add support for MT6366 regulator
The MT6366 is a regulator found on boards based on MediaTek MT8186 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper.
Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Johnson Wang <johnson.wang@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220317030402.24894-2-johnson.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49 |
|
#
b99b7b79 |
| 29-Jun-2021 |
Axel Lin <axel.lin@ingics.com> |
regulator: mt6358: Remove shift fields from struct mt6358_regulator_info
The shift setting can be calculated via the corresponding mask field, so remove these shift fields.
The usage of da_vsel_mas
regulator: mt6358: Remove shift fields from struct mt6358_regulator_info
The shift setting can be calculated via the corresponding mask field, so remove these shift fields.
The usage of da_vsel_mask is different from other mask defines because current code does shift regval before mask with the da_vsel_mask. Do proper shit to da_vsel_mask setting so we can calculate the shift.
Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210629130503.2183574-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.13, v5.10.46 |
|
#
50c9462e |
| 22-Jun-2021 |
Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> |
regulator: mt6358: Fix vdram2 .vsel_mask
The valid vsel value are 0 and 12, so the .vsel_mask should be 0xf.
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Reviewed-by: Axel Lin <a
regulator: mt6358: Fix vdram2 .vsel_mask
The valid vsel value are 0 and 12, so the .vsel_mask should be 0xf.
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/1624424169-510-1-git-send-email-hsin-hsiung.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.10.43 |
|
#
431ea63b |
| 06-Jun-2021 |
Axel Lin <axel.lin@ingics.com> |
regulator: mt6358: Use unsigned int for volt_tables
The regulator_desc expects "const unsigned int *volt_table", thus use unsigned int instead of u32.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
regulator: mt6358: Use unsigned int for volt_tables
The regulator_desc expects "const unsigned int *volt_table", thus use unsigned int instead of u32.
Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210606065052.1417111-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
5d9e3279 |
| 22-Jun-2021 |
Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> |
regulator: mt6358: Fix vdram2 .vsel_mask
[ Upstream commit 50c9462edcbf900f3d5097ca3ad60171346124de ]
The valid vsel value are 0 and 12, so the .vsel_mask should be 0xf.
Signed-off-by: Hsin-Hsiung
regulator: mt6358: Fix vdram2 .vsel_mask
[ Upstream commit 50c9462edcbf900f3d5097ca3ad60171346124de ]
The valid vsel value are 0 and 12, so the .vsel_mask should be 0xf.
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/1624424169-510-1-git-send-email-hsin-hsiung.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40 |
|
#
60ab7f41 |
| 08-May-2020 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
regulator: use linear_ranges helper
Change the regulator helpers to use common linear_ranges code.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Mark Brown <brooni
regulator: use linear_ranges helper
Change the regulator helpers to use common linear_ranges code.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/64f01d5e381b8631a271616b7790f9d5640974fb.1588944082.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
f67ff1bd |
| 22-Aug-2019 |
Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> |
regulator: mt6358: Add support for MT6358 regulator
The MT6358 is a regulator found on boards based on MediaTek MT8183 and probably other SoCs. It is a so called pmic and connects as a slave to SoC
regulator: mt6358: Add support for MT6358 regulator
The MT6358 is a regulator found on boards based on MediaTek MT8183 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper.
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Link: https://lore.kernel.org/r/1566531931-9772-8-git-send-email-hsin-hsiung.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
5d9e3279 |
| 22-Jun-2021 |
Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> |
regulator: mt6358: Fix vdram2 .vsel_mask [ Upstream commit 50c9462edcbf900f3d5097ca3ad60171346124de ] The valid vsel value are 0 and 12, so the .vsel_mask should be 0xf. Si
regulator: mt6358: Fix vdram2 .vsel_mask [ Upstream commit 50c9462edcbf900f3d5097ca3ad60171346124de ] The valid vsel value are 0 and 12, so the .vsel_mask should be 0xf. Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/1624424169-510-1-git-send-email-hsin-hsiung.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40 |
|
#
60ab7f41 |
| 08-May-2020 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
regulator: use linear_ranges helper Change the regulator helpers to use common linear_ranges code. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by
regulator: use linear_ranges helper Change the regulator helpers to use common linear_ranges code. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/64f01d5e381b8631a271616b7790f9d5640974fb.1588944082.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
f67ff1bd |
| 22-Aug-2019 |
Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> |
regulator: mt6358: Add support for MT6358 regulator The MT6358 is a regulator found on boards based on MediaTek MT8183 and probably other SoCs. It is a so called pmic and connects as a s
regulator: mt6358: Add support for MT6358 regulator The MT6358 is a regulator found on boards based on MediaTek MT8183 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper. Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Link: https://lore.kernel.org/r/1566531931-9772-8-git-send-email-hsin-hsiung.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|