* [PATCH 2/2] ASoC: uniphier: aio-dma: Use guard() for spin locks
From: phucduc.bui @ 2026-04-29 9:16 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Jaroslav Kysela, Takashi Iwai, Kunihiko Hayashi, Masami Hiramatsu,
Kuninori Morimoto, Joris Verhaegen, Miller Liang, linux-sound,
linux-arm-kernel, linux-kernel, bui duc phuc
In-Reply-To: <20260429091614.96667-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/uniphier/aio-dma.c | 52 ++++++++++++++++--------------------
1 file changed, 23 insertions(+), 29 deletions(-)
diff --git a/sound/soc/uniphier/aio-dma.c b/sound/soc/uniphier/aio-dma.c
index c1ca55997103..c01eae55d4fc 100644
--- a/sound/soc/uniphier/aio-dma.c
+++ b/sound/soc/uniphier/aio-dma.c
@@ -32,15 +32,15 @@ static void aiodma_pcm_irq(struct uniphier_aio_sub *sub)
runtime->channels * samples_to_bytes(runtime, 1);
int ret;
- spin_lock(&sub->lock);
- ret = aiodma_rb_set_threshold(sub, runtime->dma_bytes,
- sub->threshold + bytes);
- if (!ret)
- sub->threshold += bytes;
-
- aiodma_rb_sync(sub, runtime->dma_addr, runtime->dma_bytes, bytes);
- aiodma_rb_clear_irq(sub);
- spin_unlock(&sub->lock);
+ scoped_guard(spinlock, &sub->lock) {
+ ret = aiodma_rb_set_threshold(sub, runtime->dma_bytes,
+ sub->threshold + bytes);
+ if (!ret)
+ sub->threshold += bytes;
+
+ aiodma_rb_sync(sub, runtime->dma_addr, runtime->dma_bytes, bytes);
+ aiodma_rb_clear_irq(sub);
+ }
snd_pcm_period_elapsed(sub->substream);
}
@@ -51,15 +51,15 @@ static void aiodma_compr_irq(struct uniphier_aio_sub *sub)
int bytes = runtime->fragment_size;
int ret;
- spin_lock(&sub->lock);
- ret = aiodma_rb_set_threshold(sub, sub->compr_bytes,
- sub->threshold + bytes);
- if (!ret)
- sub->threshold += bytes;
+ scoped_guard(spinlock, &sub->lock) {
+ ret = aiodma_rb_set_threshold(sub, sub->compr_bytes,
+ sub->threshold + bytes);
+ if (!ret)
+ sub->threshold += bytes;
- aiodma_rb_sync(sub, sub->compr_addr, sub->compr_bytes, bytes);
- aiodma_rb_clear_irq(sub);
- spin_unlock(&sub->lock);
+ aiodma_rb_sync(sub, sub->compr_addr, sub->compr_bytes, bytes);
+ aiodma_rb_clear_irq(sub);
+ }
snd_compr_fragment_elapsed(sub->cstream);
}
@@ -113,18 +113,16 @@ static int uniphier_aiodma_prepare(struct snd_soc_component *component,
struct uniphier_aio_sub *sub = &aio->sub[substream->stream];
int bytes = runtime->period_size *
runtime->channels * samples_to_bytes(runtime, 1);
- unsigned long flags;
int ret;
ret = aiodma_ch_set_param(sub);
if (ret)
return ret;
- spin_lock_irqsave(&sub->lock, flags);
- ret = aiodma_rb_set_buffer(sub, runtime->dma_addr,
- runtime->dma_addr + runtime->dma_bytes,
- bytes);
- spin_unlock_irqrestore(&sub->lock, flags);
+ scoped_guard(spinlock_irqsave, &sub->lock)
+ ret = aiodma_rb_set_buffer(sub, runtime->dma_addr,
+ runtime->dma_addr + runtime->dma_bytes,
+ bytes);
if (ret)
return ret;
@@ -141,9 +139,8 @@ static int uniphier_aiodma_trigger(struct snd_soc_component *component,
struct device *dev = &aio->chip->pdev->dev;
int bytes = runtime->period_size *
runtime->channels * samples_to_bytes(runtime, 1);
- unsigned long flags;
- spin_lock_irqsave(&sub->lock, flags);
+ guard(spinlock_irqsave)(&sub->lock);
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
aiodma_rb_sync(sub, runtime->dma_addr, runtime->dma_bytes,
@@ -161,7 +158,6 @@ static int uniphier_aiodma_trigger(struct snd_soc_component *component,
dev_warn(dev, "Unknown trigger(%d) ignored\n", cmd);
break;
}
- spin_unlock_irqrestore(&sub->lock, flags);
return 0;
}
@@ -176,17 +172,15 @@ static snd_pcm_uframes_t uniphier_aiodma_pointer(
struct uniphier_aio_sub *sub = &aio->sub[substream->stream];
int bytes = runtime->period_size *
runtime->channels * samples_to_bytes(runtime, 1);
- unsigned long flags;
snd_pcm_uframes_t pos;
- spin_lock_irqsave(&sub->lock, flags);
+ guard(spinlock_irqsave)(&sub->lock);
aiodma_rb_sync(sub, runtime->dma_addr, runtime->dma_bytes, bytes);
if (sub->swm->dir == PORT_DIR_OUTPUT)
pos = bytes_to_frames(runtime, sub->rd_offs);
else
pos = bytes_to_frames(runtime, sub->wr_offs);
- spin_unlock_irqrestore(&sub->lock, flags);
return pos;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] ASoC: uniphier: aio-compress: Use guard() for spin locks
From: phucduc.bui @ 2026-04-29 9:16 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Jaroslav Kysela, Takashi Iwai, Kunihiko Hayashi, Masami Hiramatsu,
Kuninori Morimoto, Joris Verhaegen, Miller Liang, linux-sound,
linux-arm-kernel, linux-kernel, bui duc phuc
In-Reply-To: <20260429091614.96667-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/uniphier/aio-compress.c | 24 +++++++-----------------
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/sound/soc/uniphier/aio-compress.c b/sound/soc/uniphier/aio-compress.c
index b18af98a552b..57247a03b5c9 100644
--- a/sound/soc/uniphier/aio-compress.c
+++ b/sound/soc/uniphier/aio-compress.c
@@ -183,18 +183,16 @@ static int uniphier_aio_compr_prepare(struct snd_soc_component *component,
struct uniphier_aio *aio = uniphier_priv(snd_soc_rtd_to_cpu(rtd, 0));
struct uniphier_aio_sub *sub = &aio->sub[cstream->direction];
int bytes = runtime->fragment_size;
- unsigned long flags;
int ret;
ret = aiodma_ch_set_param(sub);
if (ret)
return ret;
- spin_lock_irqsave(&sub->lock, flags);
- ret = aiodma_rb_set_buffer(sub, sub->compr_addr,
- sub->compr_addr + sub->compr_bytes,
- bytes);
- spin_unlock_irqrestore(&sub->lock, flags);
+ scoped_guard(spinlock_irqsave, &sub->lock)
+ ret = aiodma_rb_set_buffer(sub, sub->compr_addr,
+ sub->compr_addr + sub->compr_bytes,
+ bytes);
if (ret)
return ret;
@@ -223,9 +221,8 @@ static int uniphier_aio_compr_trigger(struct snd_soc_component *component,
struct uniphier_aio_sub *sub = &aio->sub[cstream->direction];
struct device *dev = &aio->chip->pdev->dev;
int bytes = runtime->fragment_size, ret = 0;
- unsigned long flags;
- spin_lock_irqsave(&sub->lock, flags);
+ guard(spinlock_irqsave)(&sub->lock);
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
aiodma_rb_sync(sub, sub->compr_addr, sub->compr_bytes, bytes);
@@ -242,7 +239,6 @@ static int uniphier_aio_compr_trigger(struct snd_soc_component *component,
dev_warn(dev, "Unknown trigger(%d)\n", cmd);
ret = -EINVAL;
}
- spin_unlock_irqrestore(&sub->lock, flags);
return ret;
}
@@ -256,10 +252,9 @@ static int uniphier_aio_compr_pointer(struct snd_soc_component *component,
struct uniphier_aio *aio = uniphier_priv(snd_soc_rtd_to_cpu(rtd, 0));
struct uniphier_aio_sub *sub = &aio->sub[cstream->direction];
int bytes = runtime->fragment_size;
- unsigned long flags;
u32 pos;
- spin_lock_irqsave(&sub->lock, flags);
+ guard(spinlock_irqsave)(&sub->lock);
aiodma_rb_sync(sub, sub->compr_addr, sub->compr_bytes, bytes);
@@ -273,8 +268,6 @@ static int uniphier_aio_compr_pointer(struct snd_soc_component *component,
}
tstamp->byte_offset = pos;
- spin_unlock_irqrestore(&sub->lock, flags);
-
return 0;
}
@@ -332,7 +325,6 @@ static int uniphier_aio_compr_copy(struct snd_soc_component *component,
struct uniphier_aio_sub *sub = &aio->sub[cstream->direction];
size_t cnt = min_t(size_t, count, aio_rb_space_to_end(sub) / 2);
int bytes = runtime->fragment_size;
- unsigned long flags;
size_t s;
int ret;
@@ -360,7 +352,7 @@ static int uniphier_aio_compr_copy(struct snd_soc_component *component,
if (ret)
return -EFAULT;
- spin_lock_irqsave(&sub->lock, flags);
+ guard(spinlock_irqsave)(&sub->lock);
sub->threshold = 2 * bytes;
aiodma_rb_set_threshold(sub, sub->compr_bytes, 2 * bytes);
@@ -376,8 +368,6 @@ static int uniphier_aio_compr_copy(struct snd_soc_component *component,
}
aiodma_rb_sync(sub, sub->compr_addr, sub->compr_bytes, bytes);
- spin_unlock_irqrestore(&sub->lock, flags);
-
return cnt;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] ASoC: uniphier: Use guard() for spin locks
From: phucduc.bui @ 2026-04-29 9:16 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Jaroslav Kysela, Takashi Iwai, Kunihiko Hayashi, Masami Hiramatsu,
Kuninori Morimoto, Joris Verhaegen, Miller Liang, linux-sound,
linux-arm-kernel, linux-kernel, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Hi all,
This series converts spin lock handling in UniPhier AIO drivers
to use guard() helpers.
The changes are purely code cleanups with no functional impact.
Best regards,
Phuc
bui duc phuc (2):
ASoC: uniphier: aio-compress: Use guard() for spin locks
ASoC: uniphier: aio-dma: Use guard() for spin locks
sound/soc/uniphier/aio-compress.c | 24 +++++---------
sound/soc/uniphier/aio-dma.c | 52 ++++++++++++++-----------------
2 files changed, 30 insertions(+), 46 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 2/4] soc: qcom: Restrict drivers per ARM/ARM64
From: Krzysztof Kozlowski @ 2026-04-29 9:10 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, linux-arm-kernel
In-Reply-To: <527a434e-5ac6-4a79-91e7-bf8bac4adb84@oss.qualcomm.com>
On 29/04/2026 11:03, Konrad Dybcio wrote:
> On 4/29/26 10:56 AM, Krzysztof Kozlowski wrote:
>> There is no point to allow selecting core SoC drivers for Qualcomm ARMv7
>> SoCs when building ARM64 kernel, and vice versa.
>>
>> This makes kernel configuration more difficult as many do not remember
>> the Qualcomm SoCs model names/numbers and their properties like
>> architecture. No features should be lost because:
>> 1. There won't be a single image for ARMv7 and ARMv8/9 SoCs.
>> 2. Newer ARMv8/9 SoCs won't be running in arm32 emulation mode.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> ---
>
> [...]
>
>> drivers/soc/qcom/Kconfig | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 62ce1c67d684..9a050ba1dbcb 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -19,6 +19,7 @@ config QCOM_AOSS_QMP
>> tristate "Qualcomm AOSS Driver"
>> depends on MAILBOX
>> depends on COMMON_CLK && PM
>> + depends on ARM64 || COMPILE_TEST
>
> SDX65
Ack, although not in upstream DTS.
>
>> select PM_GENERIC_DOMAINS
>> help
>> This driver provides the means of communicating with and controlling
>> @@ -37,6 +38,7 @@ config QCOM_COMMAND_DB
>>
>> config QCOM_GENI_SE
>> tristate "QCOM GENI Serial Engine Driver"
>> + depends on ARM64 || COMPILE_TEST
>
> OK
>
>> help
>> This driver is used to manage Generic Interface (GENI) firmware based
>> Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This
>> @@ -45,6 +47,7 @@ config QCOM_GENI_SE
>>
>> config QCOM_GSBI
>> tristate "QCOM General Serial Bus Interface"
>> + depends on ARM || COMPILE_TEST
>
> OK
>
>> select MFD_SYSCON
>> help
>> Say y here to enable GSBI support. The GSBI provides control
>> @@ -53,6 +56,7 @@ config QCOM_GSBI
>>
>> config QCOM_LLCC
>> tristate "Qualcomm Technologies, Inc. LLCC driver"
>> + depends on ARM64 || COMPILE_TEST
>
> SDX65
Ack
>
>> select REGMAP_MMIO
>> help
>> Qualcomm Technologies, Inc. platform specific
>> @@ -108,6 +112,7 @@ config QCOM_PMIC_GLINK
>> depends on DRM
>> depends on NET
>> depends on OF
>> + depends on ARM64 || COMPILE_TEST
>
> Probably OK?
>
>> select AUXILIARY_BUS
>> select QCOM_PDR_HELPERS
>> select DRM_AUX_HPD_BRIDGE
>> @@ -242,6 +247,7 @@ config QCOM_APR
>> tristate "Qualcomm APR/GPR Bus (Asynchronous/Generic Packet Router)"
>> depends on RPMSG
>> depends on NET
>> + depends on ARM64 || COMPILE_TEST
>
> This I think goes back to <2012 SoCs
It could, but there is no upstream DTS in arm32. It is however in few
old like 8916 which might be running in arm32 mode, so I guess better to
drop it.
>
>> select QCOM_PDR_HELPERS
>> help
>> Enable APR IPC protocol support between
>> @@ -251,6 +257,7 @@ config QCOM_APR
>>
>> config QCOM_ICC_BWMON
>> tristate "QCOM Interconnect Bandwidth Monitor driver"
>> + depends on ARM64 || COMPILE_TEST
>
> This is OK currently, some arm32 targets have an older (unsupported today)
> BWMON, I don't know if they would be using the same driver or not
They would get their own compatible, thus driver would be changed. The
depends here is for current driver.
>
>> select PM_OPP
>> select REGMAP_MMIO
>> help
>> @@ -265,6 +272,7 @@ config QCOM_ICC_BWMON
>>
>> config QCOM_PBS
>> tristate "PBS trigger support for Qualcomm Technologies, Inc. PMICS"
>> + depends on ARM64 || COMPILE_TEST
>
> MSM8909+PM660 exists and makes use of that
Well, not in upstream, but I get your point.
>
> Konrad
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] mailbox: exynos: Add support for Exynos850 mailbox
From: Tudor Ambarus @ 2026-04-29 9:07 UTC (permalink / raw)
To: Alexey Klimov
Cc: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Sam Protsenko, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Jassi Brar, Krzysztof Kozlowski,
Peter Griffin, linux-samsung-soc, linux-arm-kernel, linux-clk,
devicetree, linux-kernel
In-Reply-To: <DI52JP9JH6AH.3I5OKWOZ56MIU@linaro.org>
On 4/28/26 11:26 PM, Alexey Klimov wrote:
> On Wed Apr 8, 2026 at 2:08 PM BST, Alexey Klimov wrote:
>
> [...]
>
>> On Thu Apr 2, 2026 at 9:42 AM BST, Tudor Ambarus wrote:
>>>> static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>>>> @@ -57,7 +104,8 @@ static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>>>> return -EINVAL;
>>>> }
>>>>
>>>> - writel(BIT(msg->chan_id), exynos_mbox->regs + EXYNOS_MBOX_INTGR1);
>>>> + writel(BIT(msg->chan_id) << exynos_mbox->data->irq_doorbell_shift,
>>>> + exynos_mbox->regs + exynos_mbox->data->irq_doorbell_offset);
>>>
>>> Use FIELD_PREP from <linux/bitfield.h> please. You will use a mask instead of
>>> a shift.
>>>
>>> I would rename irq_doorbell_offset to intgr. It aligns with the register name
>>> from the datasheet. You won't need to prepend _offset to the name, we already
>>> see it's an offset when doing the writel().
>>
>> Sure. Thanks. Let's use FIELD_PREP.
>
> + /* Ring the doorbell */
> + writel(BIT(msg->chan_id) << exynos_mbox->data->intgr_shift,
> + exynos_mbox->regs + exynos_mbox->data->intgr);
>
> FIELD_PREP() wants a mask as a compile-time constant. Unless you want me to
Indeed, I forgot, sorry.
> add switch/case for different SoCs or I misunderstood something I don't see
> how this is gonna fly.
other option is to have a .ring_doorbell callback defined in the SoC data,
and then you can use FIELD_PREP. But it increases boilerplate code just to
ring a doorbell. I wouldn't go via switch/case. I think we'll have to live
with the mask and shift.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH 3/4] soc: qcom: Make important drivers default
From: Konrad Dybcio @ 2026-04-29 9:06 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, linux-arm-kernel
In-Reply-To: <20260429-qcom-soc-kconfig-v1-3-69ba540b3fe9@oss.qualcomm.com>
On 4/29/26 10:56 AM, Krzysztof Kozlowski wrote:
> The drivers for Qualcomm SoC components are covering a basic or
> fundamental SoC blocks. Usually they are required for booting or to
> achieve basic expected functionality when running Linux. These drivers
> do not represent any sort of buses visible to the board
> designers/configurators, thus they should be always enabled, regardless
> how SoC is used in the final board.
>
> Kernel configuration should not ask users choice of drivers when that
> choice is obvious and known to the developers that answer should be
> 'yes' or 'module'.
>
> Switch most of the Qualcomm SoC drivers to a default 'yes' or
> 'module' for ARCH_QCOM, to match existing defconfig usage.
>
> This has no impact on arm64 defconfig, arm qcom_defconfig and arm
> multi_v7_defconfig.
>
> The change will however enable by default all drivers for arm or arm64
> COMPILE_TEST builds, whenever ARCH_QCOM is selected, which feels
> logical: if one selects ARCH_QCOM then probably by default wants to
> build test it entirely. Kernels with COMPILE_TEST are not supposed to
> be used for booting.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Please also add:
QCOM_RMTFS_MEM (required for modem)
QCOM_SPM (cpufreq-adjacent on some platforms)
Konrad
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: paris: Directly modify registers to set GPIO direction
From: Chen-Yu Tsai @ 2026-04-29 9:03 UTC (permalink / raw)
To: Linus Walleij
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
linux-mediatek, linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <CAD++jLnP9HvWPQg8WqoFkgRoFCWjkOUsRAgtnks4mEhHwYRt+g@mail.gmail.com>
On Tue, Apr 28, 2026 at 7:44 PM Linus Walleij <linusw@kernel.org> wrote:
>
> On Mon, Apr 27, 2026 at 4:10 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> > pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take
> > the pinctrl mutex. This causes a gpiochip operations to need to sleep.
> > Worse yet, the .can_sleep field in the gpiochip is not set. This causes
> > the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check
> > whether it can use a spinlock or needs a mutex. In this case, it ends
> > up taking a spinlock, then calls pinctrl_gpio_direction_output(), which
> > takes a mutex. This causes a huge warning.
> >
> > While this class of Mediatek hardware does not have separate clear/set
> > registers, the pinctrl context has a spinlock that is taken whenever
> > a register read-modify-write is done.
> >
> > Switch to directly setting the GPIO direction register bits to avoid
> > the mutex.
> >
> > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
>
> You are essentially decoupling the pin control back-end from
> the GPIO front-end, can you try to do this a more friendly way
> that doesn't wrangle registers out of the pin controller like this?
This is essentially following
commit 8df89a7cbc63 ("pinctrl-sunxi: don't call pinctrl_gpio_direction()")
And in MediaTek's hardware, the GPIO direction is even further removed
from pinctrl. GPIO is a function that gets muxed, but after that the
direction and data bits are in separate registers that are grouped
separately from the pinmux registers. The pin controller doesn't have
to be involved.
> If you insist on doing this, you also need to DELETE the pin
> control back-end function
> mtk_pinmux_gpio_set_direction(), which is what gets called.
You mean delete the .gpio_set_direction field from pinmux_ops?
Sure I can do that.
Thanks
ChenYu
^ permalink raw reply
* Re: [PATCH v4 3/3] coco: guest: arm64: Query host IPA-change alignment via RHI
From: Aneesh Kumar K.V @ 2026-04-29 9:03 UTC (permalink / raw)
To: Will Deacon
Cc: linux-kernel, iommu, linux-coco, linux-arm-kernel, kvmarm,
Catalin Marinas, Jason Gunthorpe, Marc Zyngier, Marek Szyprowski,
Robin Murphy, Steven Price, Suzuki K Poulose, Thomas Gleixner,
sebastianene
In-Reply-To: <afC8hZTJY6Cx8Liz@willie-the-truck>
Will Deacon <will@kernel.org> writes:
> [+Seb for the ITS]
>
> On Mon, Apr 27, 2026 at 12:01:08PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> Add the Realm Host Interface support needed to query host configuration
>> from a Realm guest. Define the RHI hostconf SMCs, add rsi_host_call(), and
>> use them during Realm initialization to retrieve the host IPA-change
>> alignment size.
>>
>> Expose that alignment through realm_get_hyp_pagesize() and
>> mem_decrypt_granule_size() so shared-buffer allocation and
>> encryption/decryption paths can honor the ipa change page-size requirement.
>>
>> If the host reports an invalid alignment (when alginment value is not
>> multiple of 4K), do not enable Realm support.
>>
>> This provides the host alignment information required by the shared buffer
>> alignment changes.
>>
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> ---
>> arch/arm64/include/asm/mem_encrypt.h | 3 ++
>> arch/arm64/include/asm/rhi.h | 24 +++++++++++++
>> arch/arm64/include/asm/rsi.h | 2 ++
>> arch/arm64/include/asm/rsi_cmds.h | 10 ++++++
>> arch/arm64/include/asm/rsi_smc.h | 7 ++++
>> arch/arm64/kernel/Makefile | 2 +-
>> arch/arm64/kernel/rhi.c | 54 ++++++++++++++++++++++++++++
>> arch/arm64/kernel/rsi.c | 13 +++++++
>> arch/arm64/mm/mem_encrypt.c | 8 +++++
>> 9 files changed, 122 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm64/include/asm/rhi.h
>> create mode 100644 arch/arm64/kernel/rhi.c
>
> [...]
>
>> diff --git a/arch/arm64/mm/mem_encrypt.c b/arch/arm64/mm/mem_encrypt.c
>> index 38c62c9e4e74..f5d64bc29c20 100644
>> --- a/arch/arm64/mm/mem_encrypt.c
>> +++ b/arch/arm64/mm/mem_encrypt.c
>> @@ -59,3 +59,11 @@ int set_memory_decrypted(unsigned long addr, int numpages)
>> return crypt_ops->decrypt(addr, numpages);
>> }
>> EXPORT_SYMBOL_GPL(set_memory_decrypted);
>> +
>> +size_t mem_decrypt_granule_size(void)
>> +{
>> + if (is_realm_world())
>> + return max(PAGE_SIZE, realm_get_hyp_pagesize());
>> + return PAGE_SIZE;
>
> No, this should be indirected via 'struct arm64_mem_crypt_ops' because
> there's nothing particularly unique to realms here. For pKVM protected
> guests using a smaller page-size than the host, we'd presumably need
> something similar for the ITS (where restricted-dma isn't used).
>
Sure, I will rework this to use struct arm64_mem_crypt_ops in the next revision.
-aneesh
^ permalink raw reply
* Re: [PATCH 2/4] soc: qcom: Restrict drivers per ARM/ARM64
From: Konrad Dybcio @ 2026-04-29 9:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, linux-arm-kernel
In-Reply-To: <20260429-qcom-soc-kconfig-v1-2-69ba540b3fe9@oss.qualcomm.com>
On 4/29/26 10:56 AM, Krzysztof Kozlowski wrote:
> There is no point to allow selecting core SoC drivers for Qualcomm ARMv7
> SoCs when building ARM64 kernel, and vice versa.
>
> This makes kernel configuration more difficult as many do not remember
> the Qualcomm SoCs model names/numbers and their properties like
> architecture. No features should be lost because:
> 1. There won't be a single image for ARMv7 and ARMv8/9 SoCs.
> 2. Newer ARMv8/9 SoCs won't be running in arm32 emulation mode.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
[...]
> drivers/soc/qcom/Kconfig | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 62ce1c67d684..9a050ba1dbcb 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -19,6 +19,7 @@ config QCOM_AOSS_QMP
> tristate "Qualcomm AOSS Driver"
> depends on MAILBOX
> depends on COMMON_CLK && PM
> + depends on ARM64 || COMPILE_TEST
SDX65
> select PM_GENERIC_DOMAINS
> help
> This driver provides the means of communicating with and controlling
> @@ -37,6 +38,7 @@ config QCOM_COMMAND_DB
>
> config QCOM_GENI_SE
> tristate "QCOM GENI Serial Engine Driver"
> + depends on ARM64 || COMPILE_TEST
OK
> help
> This driver is used to manage Generic Interface (GENI) firmware based
> Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This
> @@ -45,6 +47,7 @@ config QCOM_GENI_SE
>
> config QCOM_GSBI
> tristate "QCOM General Serial Bus Interface"
> + depends on ARM || COMPILE_TEST
OK
> select MFD_SYSCON
> help
> Say y here to enable GSBI support. The GSBI provides control
> @@ -53,6 +56,7 @@ config QCOM_GSBI
>
> config QCOM_LLCC
> tristate "Qualcomm Technologies, Inc. LLCC driver"
> + depends on ARM64 || COMPILE_TEST
SDX65
> select REGMAP_MMIO
> help
> Qualcomm Technologies, Inc. platform specific
> @@ -108,6 +112,7 @@ config QCOM_PMIC_GLINK
> depends on DRM
> depends on NET
> depends on OF
> + depends on ARM64 || COMPILE_TEST
Probably OK?
> select AUXILIARY_BUS
> select QCOM_PDR_HELPERS
> select DRM_AUX_HPD_BRIDGE
> @@ -242,6 +247,7 @@ config QCOM_APR
> tristate "Qualcomm APR/GPR Bus (Asynchronous/Generic Packet Router)"
> depends on RPMSG
> depends on NET
> + depends on ARM64 || COMPILE_TEST
This I think goes back to <2012 SoCs
> select QCOM_PDR_HELPERS
> help
> Enable APR IPC protocol support between
> @@ -251,6 +257,7 @@ config QCOM_APR
>
> config QCOM_ICC_BWMON
> tristate "QCOM Interconnect Bandwidth Monitor driver"
> + depends on ARM64 || COMPILE_TEST
This is OK currently, some arm32 targets have an older (unsupported today)
BWMON, I don't know if they would be using the same driver or not
> select PM_OPP
> select REGMAP_MMIO
> help
> @@ -265,6 +272,7 @@ config QCOM_ICC_BWMON
>
> config QCOM_PBS
> tristate "PBS trigger support for Qualcomm Technologies, Inc. PMICS"
> + depends on ARM64 || COMPILE_TEST
MSM8909+PM660 exists and makes use of that
Konrad
^ permalink raw reply
* Re: [PATCH v4 3/3] coco: guest: arm64: Query host IPA-change alignment via RHI
From: Aneesh Kumar K.V @ 2026-04-29 9:01 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-kernel, iommu, linux-coco, linux-arm-kernel, kvmarm,
Catalin Marinas, Jason Gunthorpe, Marek Szyprowski, Robin Murphy,
Steven Price, Suzuki K Poulose, Thomas Gleixner, Will Deacon
In-Reply-To: <86tssvyz2v.wl-maz@kernel.org>
Marc Zyngier <maz@kernel.org> writes:
> On Tue, 28 Apr 2026 13:49:46 +0100,
> Aneesh Kumar K.V <aneesh.kumar@kernel.org> wrote:
>>
>> Marc Zyngier <maz@kernel.org> writes:
>>
>> > On Mon, 27 Apr 2026 07:31:08 +0100,
>> > "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:
>> >>
>> >> Add the Realm Host Interface support needed to query host configuration
>> >> from a Realm guest. Define the RHI hostconf SMCs, add rsi_host_call(), and
>> >> use them during Realm initialization to retrieve the host IPA-change
>> >> alignment size.
>> >
>> > I don't understand what "IPA-change" means. What you are after is the
>> > host's sharing granule size.
>> >
>>
>> This is part of the RHI specification, and the call is named
>> RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT. The intent is to determine the
>> alignment requirements for changing IPA attributes (protected vs.
>> unprotected IPA
>
> This really is a terrible name. Why the 'change' part? It doesn't
> change, it is a constant.
>
> Oh well...
>
> [...]
>
>> >> +static inline unsigned long rsi_host_call(struct rsi_host_call *rhi_call)
>> >> +{
>> >> + phys_addr_t addr = virt_to_phys(rhi_call);
>> >> + struct arm_smccc_res res;
>> >> +
>> >> + arm_smccc_1_1_invoke(SMC_RSI_HOST_CALL, addr, &res);
>> >
>> > Errr... What guarantees that *rhi_call is *IPA contiguous*? This is
>> > incredibly fragile. You should at the very least check that this isn't
>> > vmalloc'd.
>> >
>>
>>
>> I didn’t quite follow that. We have other RSI calls (even RMI calls)
>> that do similar things, and the caller understands that the address
>> should be IPA-contiguous.
>
> Does it? Where is it documented? All you get is a pointer, so all
> bets are off.
>
>> Are you suggesting that all RSI calls should
>> add checks for this?. or are you suggesting to update the API to
>>
>> unsigned long rsi_host_call(unsigned long rhi_call_phys) ?
>
> I'm suggesting that this API is subtly broken because it makes random
> assumption about the physical contiguity of the VA space. It does so
> without any check, without any documentation.
>
> Simply changing the parameter to phys_addr_t could at the very least
> capture some of the requirements, but I'd like something in big bold
> letters.
>
>>
>> >> +
>> >> + return res.a0;
>> >> +}
>> >> +
>> >> #endif /* __ASM_RSI_CMDS_H */
>> >> diff --git a/arch/arm64/include/asm/rsi_smc.h b/arch/arm64/include/asm/rsi_smc.h
>> >> index e19253f96c94..9ee8b5c7612e 100644
>> >> --- a/arch/arm64/include/asm/rsi_smc.h
>> >> +++ b/arch/arm64/include/asm/rsi_smc.h
>> >> @@ -182,6 +182,13 @@ struct realm_config {
>> >> */
>> >> #define SMC_RSI_IPA_STATE_GET SMC_RSI_FID(0x198)
>> >>
>> >> +struct rsi_host_call {
>> >> + union {
>> >> + u16 imm;
>> >> + u64 padding0;
>> >> + };
>> >> + u64 gprs[31];
>> >> +} __aligned(0x100);
>> >> /*
>> >> * Make a Host call.
>> >> *
>> >> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> >> index fe627100d199..3e72dd9584ed 100644
>> >> --- a/arch/arm64/kernel/Makefile
>> >> +++ b/arch/arm64/kernel/Makefile
>> >> @@ -34,7 +34,7 @@ obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
>> >> cpufeature.o alternative.o cacheinfo.o \
>> >> smp.o smp_spin_table.o topology.o smccc-call.o \
>> >> syscall.o proton-pack.o idle.o patching.o pi/ \
>> >> - rsi.o jump_label.o
>> >> + rsi.o jump_label.o rhi.o
>> >>
>> >> obj-$(CONFIG_COMPAT) += sys32.o signal32.o \
>> >> sys_compat.o
>> >> diff --git a/arch/arm64/kernel/rhi.c b/arch/arm64/kernel/rhi.c
>> >> new file mode 100644
>> >> index 000000000000..7cd6c5102464
>> >> --- /dev/null
>> >> +++ b/arch/arm64/kernel/rhi.c
>> >> @@ -0,0 +1,54 @@
>> >> +// SPDX-License-Identifier: GPL-2.0-only
>> >> +/*
>> >> + * Copyright (C) 2026 ARM Ltd.
>> >> + */
>> >> +
>> >> +#include <linux/mm.h>
>> >> +#include <asm/rsi.h>
>> >> +#include <asm/rhi.h>
>> >> +
>> >> +/* we need an aligned rhicall for rsi_host_call. slab is not yet ready */
>> >> +static struct rsi_host_call hyp_pagesize_rhicall;
>> >
>> > Why the "hyp_" prefix? This has absolutely nothing to with the
>> > hypervisor.
>> >
>>
>> Sure will update "hyp_" reference to host.
>>
>>
>> >> +unsigned long rhi_get_ipa_change_alignment(void)
>> >> +{
>> >> + long ret;
>> >> + unsigned long ipa_change_align;
>> >> +
>> >> + hyp_pagesize_rhicall.imm = 0;
>> >> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_VERSION;
>> >> + ret = rsi_host_call(lm_alias(&hyp_pagesize_rhicall));
>> >> + if (ret != RSI_SUCCESS)
>> >> + goto err_out;
>> >> +
>> >> + if (hyp_pagesize_rhicall.gprs[0] != RHI_HOSTCONF_VER_1_0)
>> >> + goto err_out;
>> >> +
>> >> + hyp_pagesize_rhicall.imm = 0;
>> >> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_FEATURES;
>> >> + ret = rsi_host_call(lm_alias(&hyp_pagesize_rhicall));
>> >> + if (ret != RSI_SUCCESS)
>> >> + goto err_out;
>> >> +
>> >> + if (!(hyp_pagesize_rhicall.gprs[0] & __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT))
>> >> + goto err_out;
>> >> +
>> >> + hyp_pagesize_rhicall.imm = 0;
>> >> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT;
>> >> + ret = rsi_host_call(lm_alias(&hyp_pagesize_rhicall));
>> >> + if (ret != RSI_SUCCESS)
>> >> + goto err_out;
>> >> +
>> >> + ipa_change_align = hyp_pagesize_rhicall.gprs[0];
>> >> + /* This error needs special handling in the caller */
>> >> + if (ipa_change_align & (SZ_4K - 1))
>> >> + return 0;
>> >> +
>> >> + return ipa_change_align;
>> >> +
>> >> +err_out:
>> >> + /*
>> >> + * For failure condition assume host is built with 4K page size
>> >> + * and hence ipa change alignment can be guest PAGE_SIZE.
>> >> + */
>> >> + return PAGE_SIZE;
>> >> +}
>> >
>> > Why can't this be part of rsi.c? This is an RSI call, and it should be
>> > part of the RSI initialisation.
>> >
>>
>> This is an RHI call as per the specification, hence it has been added to
>> rhi.c.
>
> News flash: this is the Linux kernel, not an ARM spec. We organise
> things based on the logical use, not on the TLA associated with it.
>
> And RHI is implemented in terms of RSI. In rsi.c it goes. We don't
> need this pointless proliferation of helper files that only result in
> equally pointless global symbols.
>
>>
>> >> diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
>> >> index 9e846ce4ef9c..ff735c04e236 100644
>> >> --- a/arch/arm64/kernel/rsi.c
>> >> +++ b/arch/arm64/kernel/rsi.c
>> >> @@ -14,8 +14,10 @@
>> >> #include <asm/mem_encrypt.h>
>> >> #include <asm/pgtable.h>
>> >> #include <asm/rsi.h>
>> >> +#include <asm/rhi.h>
>> >>
>> >> static struct realm_config config;
>> >> +static unsigned long ipa_change_alignment = PAGE_SIZE;
>> >>
>> >> unsigned long prot_ns_shared;
>> >> EXPORT_SYMBOL(prot_ns_shared);
>> >> @@ -139,6 +141,11 @@ static int realm_ioremap_hook(phys_addr_t phys, size_t size, pgprot_t *prot)
>> >> return 0;
>> >> }
>> >>
>> >> +unsigned long realm_get_hyp_pagesize(void)
>> >> +{
>> >> + return ipa_change_alignment;
>> >> +}
>> >
>> > Again, this has nothing to do with the hypervisor, but the host. And
>> > ipa_change_alignment is still a wording I can't wrap my small head
>> > around.
>> >
>> >> +
>> >> void __init arm64_rsi_init(void)
>> >> {
>> >> if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
>> >> @@ -147,6 +154,12 @@ void __init arm64_rsi_init(void)
>> >> return;
>> >> if (WARN_ON(rsi_get_realm_config(&config)))
>> >> return;
>> >> +
>> >> + ipa_change_alignment = rhi_get_ipa_change_alignment();
>> >> + /* If we don't get a correct alignment response, don't enable realm */
>> >> + if (!ipa_change_alignment)
>> >> + return;
>> >
>> > But at the same time, you override a global value with an error, and
>> > then paper over it in mem_decrypt_granule_size()...
>> >
>>
>>
>> I believe I received similar feedback on my previous version as well,
>> which I didn’t quite follow.
>
> And you didn't think of asking? Sometimes I wonder what these patch
> reviews are for... Just to waste some more electrons, I guess :-/.
>
>>
>> rhi_get_ipa_change_alignment() only returns an error when the host
>> returns a size that is not 4K-aligned. Otherwise, it returns the
>> host-determined size, or defaults to guest PAGE_SIZE if the RHI call
>> itself is not supported.
>
> You encode the error as 0. You override ipa_change_alignment with 0.
>
> Then...
>
>> >> +size_t mem_decrypt_granule_size(void)
>> >> +{
>> >> + if (is_realm_world())
>> >> + return max(PAGE_SIZE, realm_get_hyp_pagesize());
>> >
>> > If you didn't mess with ipa_change_alignment above, you shouldn't need
>> > this max().
>> >
>>
>> size_t mem_decrypt_granule_size(void)
>> {
>> if (is_realm_world())
>> return max(PAGE_SIZE, realm_get_hyp_pagesize());
>> return PAGE_SIZE;
>> }
>>
>> That needs to use max(), because we should align to the guest PAGE_SIZE
>> if it is larger than the host-specified alignment value.
>
> ... you need to correct that back to PAGE_SIZE because you have stored
> something smaller than PAGE_SIZE.
>
> Isn't the problem really obvious? ipa_change_alignment can *NEVER* go
> down. It should never be allowed to reduce, because that's exactly
> the property you are trying to enforce.
>
Sure, I will update rhi_get_ipa_change_alignment() to always return the
max value.
-aneesh
^ permalink raw reply
* [PATCH 3/4] soc: qcom: Make important drivers default
From: Krzysztof Kozlowski @ 2026-04-29 8:56 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260429-qcom-soc-kconfig-v1-0-69ba540b3fe9@oss.qualcomm.com>
The drivers for Qualcomm SoC components are covering a basic or
fundamental SoC blocks. Usually they are required for booting or to
achieve basic expected functionality when running Linux. These drivers
do not represent any sort of buses visible to the board
designers/configurators, thus they should be always enabled, regardless
how SoC is used in the final board.
Kernel configuration should not ask users choice of drivers when that
choice is obvious and known to the developers that answer should be
'yes' or 'module'.
Switch most of the Qualcomm SoC drivers to a default 'yes' or
'module' for ARCH_QCOM, to match existing defconfig usage.
This has no impact on arm64 defconfig, arm qcom_defconfig and arm
multi_v7_defconfig.
The change will however enable by default all drivers for arm or arm64
COMPILE_TEST builds, whenever ARCH_QCOM is selected, which feels
logical: if one selects ARCH_QCOM then probably by default wants to
build test it entirely. Kernels with COMPILE_TEST are not supposed to
be used for booting.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/soc/qcom/Kconfig | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 9a050ba1dbcb..108fbd0610a3 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -21,6 +21,7 @@ config QCOM_AOSS_QMP
depends on COMMON_CLK && PM
depends on ARM64 || COMPILE_TEST
select PM_GENERIC_DOMAINS
+ default ARCH_QCOM
help
This driver provides the means of communicating with and controlling
the low-power state for resources related to the remoteproc
@@ -30,6 +31,7 @@ config QCOM_AOSS_QMP
config QCOM_COMMAND_DB
tristate "Qualcomm Command DB"
depends on OF_RESERVED_MEM
+ default ARCH_QCOM
help
Command DB queries shared memory by key string for shared system
resources. Platform drivers that require to set state of a shared
@@ -39,6 +41,7 @@ config QCOM_COMMAND_DB
config QCOM_GENI_SE
tristate "QCOM GENI Serial Engine Driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This driver is used to manage Generic Interface (GENI) firmware based
Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This
@@ -48,6 +51,7 @@ config QCOM_GENI_SE
config QCOM_GSBI
tristate "QCOM General Serial Bus Interface"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
select MFD_SYSCON
help
Say y here to enable GSBI support. The GSBI provides control
@@ -58,6 +62,7 @@ config QCOM_LLCC
tristate "Qualcomm Technologies, Inc. LLCC driver"
depends on ARM64 || COMPILE_TEST
select REGMAP_MMIO
+ default m if ARCH_QCOM
help
Qualcomm Technologies, Inc. platform specific
Last Level Cache Controller(LLCC) driver for platforms such as,
@@ -71,6 +76,7 @@ config QCOM_KRYO_L2_ACCESSORS
config QCOM_OCMEM
tristate "Qualcomm On Chip Memory (OCMEM) driver"
select QCOM_SCM
+ default m if ARCH_QCOM
help
The On Chip Memory (OCMEM) allocator allows various clients to
allocate memory from OCMEM based on performance, latency and power
@@ -116,6 +122,7 @@ config QCOM_PMIC_GLINK
select AUXILIARY_BUS
select QCOM_PDR_HELPERS
select DRM_AUX_HPD_BRIDGE
+ default m if ARCH_QCOM
help
The Qualcomm PMIC GLINK driver provides access, over GLINK, to the
USB and battery firmware running on one of the coprocessors in
@@ -135,6 +142,7 @@ config QCOM_RAMP_CTRL
config QCOM_RMTFS_MEM
tristate "Qualcomm Remote Filesystem memory driver"
select QCOM_SCM
+ default m if ARCH_QCOM
help
The Qualcomm remote filesystem memory driver is used for allocating
and exposing regions of shared memory with remote processors for the
@@ -156,6 +164,7 @@ config QCOM_RPM_MASTER_STATS
config QCOM_RPMH
tristate "Qualcomm RPM-Hardened (RPMH) Communication"
depends on (QCOM_COMMAND_DB || !QCOM_COMMAND_DB)
+ default ARCH_QCOM
help
Support for communication with the hardened-RPM blocks in
Qualcomm Technologies Inc (QTI) SoCs. RPMH communication uses an
@@ -166,6 +175,7 @@ config QCOM_RPMH
config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on HWSPINLOCK
+ default ARCH_QCOM
help
Say y here to enable support for the Qualcomm Shared Memory Manager.
The driver provides an interface to items in a heap shared among all
@@ -175,6 +185,7 @@ config QCOM_SMD_RPM
tristate "Qualcomm Resource Power Manager (RPM) over SMD"
depends on RPMSG
depends on RPMSG_QCOM_SMD || RPMSG_QCOM_SMD=n
+ default ARCH_QCOM
help
If you say yes to this option, support will be included for the
Resource Power Manager system found in the Qualcomm 8974 based
@@ -195,6 +206,7 @@ config QCOM_SMP2P
depends on QCOM_SMEM
select QCOM_SMEM_STATE
select IRQ_DOMAIN
+ default ARCH_QCOM
help
Say yes here to support the Qualcomm Shared Memory Point to Point
protocol.
@@ -205,6 +217,7 @@ config QCOM_SMSM
depends on QCOM_SMEM
select QCOM_SMEM_STATE
select IRQ_DOMAIN
+ default ARCH_QCOM
help
Say yes here to support the Qualcomm Shared Memory State Machine.
The state machine is represented by bits in shared memory.
@@ -213,6 +226,7 @@ config QCOM_SOCINFO
tristate "Qualcomm socinfo driver"
depends on QCOM_SMEM
select SOC_BUS
+ default m if ARCH_QCOM
help
Say yes here to support the Qualcomm socinfo driver, providing
information about the SoC to user space.
@@ -230,6 +244,7 @@ config QCOM_STATS
depends on DEBUG_FS || COMPILE_TEST
depends on QCOM_SMEM
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
+ default m if ARCH_QCOM
help
Qualcomm Technologies, Inc. (QTI) Sleep stats driver to read
the shared memory exported by the remote processor related to
@@ -239,6 +254,7 @@ config QCOM_STATS
config QCOM_WCNSS_CTRL
tristate "Qualcomm WCNSS control driver"
depends on RPMSG
+ default m if ARCH_QCOM
help
Client driver for the WCNSS_CTRL SMD channel, used to download nv
firmware to a newly booted WCNSS chip.
@@ -249,6 +265,7 @@ config QCOM_APR
depends on NET
depends on ARM64 || COMPILE_TEST
select QCOM_PDR_HELPERS
+ default m if ARCH_QCOM
help
Enable APR IPC protocol support between
application processor and QDSP6. APR is
@@ -260,6 +277,7 @@ config QCOM_ICC_BWMON
depends on ARM64 || COMPILE_TEST
select PM_OPP
select REGMAP_MMIO
+ default m if ARCH_QCOM
help
Sets up driver monitoring bandwidth on various interconnects and
based on that voting for interconnect bandwidth, adjusting their
@@ -274,6 +292,7 @@ config QCOM_PBS
tristate "PBS trigger support for Qualcomm Technologies, Inc. PMICS"
depends on ARM64 || COMPILE_TEST
depends on SPMI
+ default m if ARCH_QCOM
help
This driver supports configuring software programmable boot sequencer (PBS)
trigger event through PBS RAM on Qualcomm Technologies, Inc. PMICs.
--
2.51.0
^ permalink raw reply related
* [PATCH 4/4] ARM: defconfig: qcom: Drop Qualcomm SoC drivers with defaults
From: Krzysztof Kozlowski @ 2026-04-29 8:56 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260429-qcom-soc-kconfig-v1-0-69ba540b3fe9@oss.qualcomm.com>
Several Qualcomm SoC drivers have defaults, so their defconfig entries
are redundant. Keep the few options which choose specific choice
different than the default.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm/configs/multi_v7_defconfig | 11 -----------
arch/arm/configs/qcom_defconfig | 7 -------
arch/arm64/configs/defconfig | 18 ------------------
3 files changed, 36 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index bcc9aabc1202..09abe406d2a5 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1152,17 +1152,6 @@ CONFIG_ASPEED_LPC_CTRL=m
CONFIG_ASPEED_LPC_SNOOP=m
CONFIG_ASPEED_P2A_CTRL=m
CONFIG_QCOM_COMMAND_DB=m
-CONFIG_QCOM_GSBI=y
-CONFIG_QCOM_OCMEM=m
-CONFIG_QCOM_RMTFS_MEM=m
-CONFIG_QCOM_RPMH=y
-CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD_RPM=y
-CONFIG_QCOM_SMP2P=y
-CONFIG_QCOM_SMSM=y
-CONFIG_QCOM_SOCINFO=m
-CONFIG_QCOM_STATS=m
-CONFIG_QCOM_WCNSS_CTRL=m
CONFIG_ROCKCHIP_IODOMAIN=y
CONFIG_SOC_TI=y
CONFIG_KEYSTONE_NAVIGATOR_QMSS=y
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 29a1dea500f0..b738e7f8a5e9 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -249,16 +249,9 @@ CONFIG_RPMSG_CHAR=y
CONFIG_RPMSG_CTRL=y
CONFIG_RPMSG_QCOM_GLINK_SMEM=y
CONFIG_RPMSG_QCOM_SMD=y
-CONFIG_QCOM_COMMAND_DB=y
-CONFIG_QCOM_GSBI=y
CONFIG_QCOM_OCMEM=y
CONFIG_QCOM_PM=y
CONFIG_QCOM_RMTFS_MEM=y
-CONFIG_QCOM_RPMH=y
-CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD_RPM=y
-CONFIG_QCOM_SMP2P=y
-CONFIG_QCOM_SMSM=y
CONFIG_QCOM_SOCINFO=y
CONFIG_QCOM_STATS=y
CONFIG_QCOM_WCNSS_CTRL=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index dd1ac01ee29b..116d0b17e404 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1656,25 +1656,7 @@ CONFIG_MTK_CMDQ=m
CONFIG_MTK_DEVAPC=m
CONFIG_MTK_PMIC_WRAP=y
CONFIG_MTK_SVS=m
-CONFIG_QCOM_AOSS_QMP=y
-CONFIG_QCOM_COMMAND_DB=y
-CONFIG_QCOM_GENI_SE=y
-CONFIG_QCOM_LLCC=m
-CONFIG_QCOM_OCMEM=m
-CONFIG_QCOM_PMIC_GLINK=m
-CONFIG_QCOM_RMTFS_MEM=m
-CONFIG_QCOM_RPMH=y
-CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD_RPM=y
-CONFIG_QCOM_SMP2P=y
-CONFIG_QCOM_SMSM=y
-CONFIG_QCOM_SOCINFO=m
CONFIG_QCOM_SPM=m
-CONFIG_QCOM_STATS=m
-CONFIG_QCOM_WCNSS_CTRL=m
-CONFIG_QCOM_APR=m
-CONFIG_QCOM_ICC_BWMON=m
-CONFIG_QCOM_PBS=m
CONFIG_ROCKCHIP_IODOMAIN=y
CONFIG_TI_PRUSS=m
CONFIG_OWL_PM_DOMAINS=y
--
2.51.0
^ permalink raw reply related
* [PATCH 1/4] soc: qcom: Hide all drivers behind selectable menu
From: Krzysztof Kozlowski @ 2026-04-29 8:56 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260429-qcom-soc-kconfig-v1-0-69ba540b3fe9@oss.qualcomm.com>
Switch from a simple menu to menuconfig, so all Qualcomm SoC drivers
will be under one selectable option, allowing to disable them all which
should make kernel configuration easier when preparing a non-Qualcomm
kernel.
This has few benefits (functional impact of this commit):
1. Allow compile testing of QCOM_OCMEM, which previously required
ARCH_QCOM.
2. Hide behind ARCH_QCOM or COMPILE_TEST drivers specific to Qualcomm
which should not be available to other kernel builds:
QCOM_PMIC_PDCHARGER_ULOG, QCOM_PMIC_GLINK, QCOM_SPM and QCOM_PBS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/soc/qcom/Kconfig | 76 +++++++++++++++++++++++-------------------------
1 file changed, 37 insertions(+), 39 deletions(-)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 2caadbbcf830..62ce1c67d684 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -2,11 +2,21 @@
#
# QCOM Soc drivers
#
-menu "Qualcomm SoC drivers"
+menuconfig QCOM_SOC
+ bool "Qualcomm SoC drivers"
+ depends on ARCH_QCOM || COMPILE_TEST
+ default ARCH_QCOM
+ help
+ This collection of drivers is specific to Qualcomm System-on-Chips
+ and most of them are necessary for a fully functional boot of the
+ Linux kernel (plus a few debugging drivers).
+ Drivers can be skipped when building Linux kernel not intended to run
+ said processors.
+
+if QCOM_SOC
config QCOM_AOSS_QMP
tristate "Qualcomm AOSS Driver"
- depends on ARCH_QCOM || COMPILE_TEST
depends on MAILBOX
depends on COMMON_CLK && PM
select PM_GENERIC_DOMAINS
@@ -18,7 +28,6 @@ config QCOM_AOSS_QMP
config QCOM_COMMAND_DB
tristate "Qualcomm Command DB"
- depends on ARCH_QCOM || COMPILE_TEST
depends on OF_RESERVED_MEM
help
Command DB queries shared memory by key string for shared system
@@ -28,7 +37,6 @@ config QCOM_COMMAND_DB
config QCOM_GENI_SE
tristate "QCOM GENI Serial Engine Driver"
- depends on ARCH_QCOM || COMPILE_TEST
help
This driver is used to manage Generic Interface (GENI) firmware based
Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This
@@ -37,7 +45,6 @@ config QCOM_GENI_SE
config QCOM_GSBI
tristate "QCOM General Serial Bus Interface"
- depends on ARCH_QCOM || COMPILE_TEST
select MFD_SYSCON
help
Say y here to enable GSBI support. The GSBI provides control
@@ -46,7 +53,6 @@ config QCOM_GSBI
config QCOM_LLCC
tristate "Qualcomm Technologies, Inc. LLCC driver"
- depends on ARCH_QCOM || COMPILE_TEST
select REGMAP_MMIO
help
Qualcomm Technologies, Inc. platform specific
@@ -56,15 +62,10 @@ config QCOM_LLCC
config QCOM_KRYO_L2_ACCESSORS
bool
- depends on (ARCH_QCOM || COMPILE_TEST) && ARM64
-
-config QCOM_MDT_LOADER
- tristate
- select QCOM_SCM
+ depends on ARM64
config QCOM_OCMEM
tristate "Qualcomm On Chip Memory (OCMEM) driver"
- depends on ARCH_QCOM
select QCOM_SCM
help
The On Chip Memory (OCMEM) allocator allows various clients to
@@ -77,7 +78,7 @@ config QCOM_PD_MAPPER
select QCOM_QMI_HELPERS
select QCOM_PDR_MSG
select AUXILIARY_BUS
- depends on NET && QRTR && (ARCH_QCOM || COMPILE_TEST)
+ depends on NET && QRTR
default QCOM_RPROC_COMMON
help
The Protection Domain Mapper maps registered services to the domains
@@ -85,12 +86,6 @@ config QCOM_PD_MAPPER
implementation of the service. It is a simpler alternative to the
userspace daemon.
-config QCOM_PDR_HELPERS
- tristate
- select QCOM_QMI_HELPERS
- select QCOM_PDR_MSG
- depends on NET
-
config QCOM_PDR_MSG
tristate
@@ -124,13 +119,8 @@ config QCOM_PMIC_GLINK
Say yes here to support USB-C and battery status on modern Qualcomm
platforms.
-config QCOM_QMI_HELPERS
- tristate
- depends on NET
-
config QCOM_RAMP_CTRL
tristate "Qualcomm Ramp Controller driver"
- depends on ARCH_QCOM || COMPILE_TEST
help
The Ramp Controller is used to program the sequence ID for pulse
swallowing, enable sequence and link sequence IDs for the CPU
@@ -139,7 +129,6 @@ config QCOM_RAMP_CTRL
config QCOM_RMTFS_MEM
tristate "Qualcomm Remote Filesystem memory driver"
- depends on ARCH_QCOM || COMPILE_TEST
select QCOM_SCM
help
The Qualcomm remote filesystem memory driver is used for allocating
@@ -151,7 +140,6 @@ config QCOM_RMTFS_MEM
config QCOM_RPM_MASTER_STATS
tristate "Qualcomm RPM Master stats"
- depends on ARCH_QCOM || COMPILE_TEST
help
The RPM Master sleep stats driver provides detailed per-subsystem
sleep/wake data, read from the RPM message RAM. It can be used to
@@ -162,7 +150,6 @@ config QCOM_RPM_MASTER_STATS
config QCOM_RPMH
tristate "Qualcomm RPM-Hardened (RPMH) Communication"
- depends on ARCH_QCOM || COMPILE_TEST
depends on (QCOM_COMMAND_DB || !QCOM_COMMAND_DB)
help
Support for communication with the hardened-RPM blocks in
@@ -173,7 +160,6 @@ config QCOM_RPMH
config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
- depends on ARCH_QCOM || COMPILE_TEST
depends on HWSPINLOCK
help
Say y here to enable support for the Qualcomm Shared Memory Manager.
@@ -182,7 +168,6 @@ config QCOM_SMEM
config QCOM_SMD_RPM
tristate "Qualcomm Resource Power Manager (RPM) over SMD"
- depends on ARCH_QCOM || COMPILE_TEST
depends on RPMSG
depends on RPMSG_QCOM_SMD || RPMSG_QCOM_SMD=n
help
@@ -229,7 +214,6 @@ config QCOM_SOCINFO
config QCOM_SPM
tristate "Qualcomm Subsystem Power Manager (SPM)"
- depends on ARCH_QCOM || COMPILE_TEST
select QCOM_SCM
help
Enable the support for the Qualcomm Subsystem Power Manager, used
@@ -238,7 +222,7 @@ config QCOM_SPM
config QCOM_STATS
tristate "Qualcomm Technologies, Inc. (QTI) Sleep stats driver"
- depends on (ARCH_QCOM && DEBUG_FS) || COMPILE_TEST
+ depends on DEBUG_FS || COMPILE_TEST
depends on QCOM_SMEM
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
help
@@ -249,7 +233,6 @@ config QCOM_STATS
config QCOM_WCNSS_CTRL
tristate "Qualcomm WCNSS control driver"
- depends on ARCH_QCOM || COMPILE_TEST
depends on RPMSG
help
Client driver for the WCNSS_CTRL SMD channel, used to download nv
@@ -257,7 +240,6 @@ config QCOM_WCNSS_CTRL
config QCOM_APR
tristate "Qualcomm APR/GPR Bus (Asynchronous/Generic Packet Router)"
- depends on ARCH_QCOM || COMPILE_TEST
depends on RPMSG
depends on NET
select QCOM_PDR_HELPERS
@@ -269,7 +251,6 @@ config QCOM_APR
config QCOM_ICC_BWMON
tristate "QCOM Interconnect Bandwidth Monitor driver"
- depends on ARCH_QCOM || COMPILE_TEST
select PM_OPP
select REGMAP_MMIO
help
@@ -282,10 +263,6 @@ config QCOM_ICC_BWMON
the fixed bandwidth votes from cpufreq (CPU nodes) thus achieve high
memory throughput even with lower CPU frequencies.
-config QCOM_INLINE_CRYPTO_ENGINE
- tristate
- select QCOM_SCM
-
config QCOM_PBS
tristate "PBS trigger support for Qualcomm Technologies, Inc. PMICS"
depends on SPMI
@@ -295,7 +272,28 @@ config QCOM_PBS
This module provides the APIs to the client drivers that wants to send the
PBS trigger event to the PBS RAM.
-endmenu
+endif
+
+# Options selected by other drivers from different subsystems must be outside
+# of the menuconfig if-block:
+
+config QCOM_INLINE_CRYPTO_ENGINE
+ tristate
+ select QCOM_SCM
+
+config QCOM_MDT_LOADER
+ tristate
+ select QCOM_SCM
+
+config QCOM_PDR_HELPERS
+ tristate
+ select QCOM_QMI_HELPERS
+ select QCOM_PDR_MSG
+ depends on NET
+
+config QCOM_QMI_HELPERS
+ tristate
+ depends on NET
config QCOM_UBWC_CONFIG
tristate
--
2.51.0
^ permalink raw reply related
* [PATCH 2/4] soc: qcom: Restrict drivers per ARM/ARM64
From: Krzysztof Kozlowski @ 2026-04-29 8:56 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260429-qcom-soc-kconfig-v1-0-69ba540b3fe9@oss.qualcomm.com>
There is no point to allow selecting core SoC drivers for Qualcomm ARMv7
SoCs when building ARM64 kernel, and vice versa.
This makes kernel configuration more difficult as many do not remember
the Qualcomm SoCs model names/numbers and their properties like
architecture. No features should be lost because:
1. There won't be a single image for ARMv7 and ARMv8/9 SoCs.
2. Newer ARMv8/9 SoCs won't be running in arm32 emulation mode.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/soc/qcom/Kconfig | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 62ce1c67d684..9a050ba1dbcb 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -19,6 +19,7 @@ config QCOM_AOSS_QMP
tristate "Qualcomm AOSS Driver"
depends on MAILBOX
depends on COMMON_CLK && PM
+ depends on ARM64 || COMPILE_TEST
select PM_GENERIC_DOMAINS
help
This driver provides the means of communicating with and controlling
@@ -37,6 +38,7 @@ config QCOM_COMMAND_DB
config QCOM_GENI_SE
tristate "QCOM GENI Serial Engine Driver"
+ depends on ARM64 || COMPILE_TEST
help
This driver is used to manage Generic Interface (GENI) firmware based
Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This
@@ -45,6 +47,7 @@ config QCOM_GENI_SE
config QCOM_GSBI
tristate "QCOM General Serial Bus Interface"
+ depends on ARM || COMPILE_TEST
select MFD_SYSCON
help
Say y here to enable GSBI support. The GSBI provides control
@@ -53,6 +56,7 @@ config QCOM_GSBI
config QCOM_LLCC
tristate "Qualcomm Technologies, Inc. LLCC driver"
+ depends on ARM64 || COMPILE_TEST
select REGMAP_MMIO
help
Qualcomm Technologies, Inc. platform specific
@@ -108,6 +112,7 @@ config QCOM_PMIC_GLINK
depends on DRM
depends on NET
depends on OF
+ depends on ARM64 || COMPILE_TEST
select AUXILIARY_BUS
select QCOM_PDR_HELPERS
select DRM_AUX_HPD_BRIDGE
@@ -242,6 +247,7 @@ config QCOM_APR
tristate "Qualcomm APR/GPR Bus (Asynchronous/Generic Packet Router)"
depends on RPMSG
depends on NET
+ depends on ARM64 || COMPILE_TEST
select QCOM_PDR_HELPERS
help
Enable APR IPC protocol support between
@@ -251,6 +257,7 @@ config QCOM_APR
config QCOM_ICC_BWMON
tristate "QCOM Interconnect Bandwidth Monitor driver"
+ depends on ARM64 || COMPILE_TEST
select PM_OPP
select REGMAP_MMIO
help
@@ -265,6 +272,7 @@ config QCOM_ICC_BWMON
config QCOM_PBS
tristate "PBS trigger support for Qualcomm Technologies, Inc. PMICS"
+ depends on ARM64 || COMPILE_TEST
depends on SPMI
help
This driver supports configuring software programmable boot sequencer (PBS)
--
2.51.0
^ permalink raw reply related
* [PATCH 0/4] soc: qcom: Kconfig improvements
From: Krzysztof Kozlowski @ 2026-04-29 8:56 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
Make important drivers default, so people will not have to choose
obvious things and few other re-organizations.
This matches my other work for Qualcomm drivers (clock, interconnect,
pinctrl).
Best regards,
Krzysztof
---
Krzysztof Kozlowski (4):
soc: qcom: Hide all drivers behind selectable menu
soc: qcom: Restrict drivers per ARM/ARM64
soc: qcom: Make important drivers default
ARM: defconfig: qcom: Drop Qualcomm SoC drivers with defaults
arch/arm/configs/multi_v7_defconfig | 11 ----
arch/arm/configs/qcom_defconfig | 7 ---
arch/arm64/configs/defconfig | 18 -------
drivers/soc/qcom/Kconfig | 103 ++++++++++++++++++++++--------------
4 files changed, 64 insertions(+), 75 deletions(-)
---
base-commit: 9974969c14031a097d6b45bcb7a06bb4aa525c40
change-id: 20260429-qcom-soc-kconfig-1b9b31d9702a
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 3/3] p54spi: convert to devicetree
From: Johannes Berg @ 2026-04-29 8:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Kevin Hilman, Krzysztof Kozlowski, Linus Walleij, Paolo Abeni,
Rob Herring, Roger Quadros, Tony Lindgren, linux-wireless, netdev,
devicetree, linux-kernel, linux-arm-kernel, linux-gpio,
linux-omap, Christian Lamparter
In-Reply-To: <20260427142355.2532714-4-arnd@kernel.org>
Since you got comments anyway...
> }
>
> - irq_set_irq_type(gpio_to_irq(p54spi_gpio_irq), IRQ_TYPE_EDGE_RISING);
>
> INIT_WORK(&priv->work, p54spi_work);
This leaves two adjacent blank lines.
johannes
^ permalink raw reply
* Re: [PATCH v3 3/3] p54spi: convert to devicetree
From: Krzysztof Kozlowski @ 2026-04-29 8:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, Krzysztof Kozlowski, Linus Walleij,
Paolo Abeni, Rob Herring, Roger Quadros, Tony Lindgren,
linux-wireless, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-gpio, linux-omap, Christian Lamparter
In-Reply-To: <20260427142355.2532714-4-arnd@kernel.org>
On 27/04/2026 16:23, Arnd Bergmann wrote:
>
> - ret = gpio_request(p54spi_gpio_power, "p54spi power");
> - if (ret < 0) {
> - dev_err(&priv->spi->dev, "power GPIO request failed: %d", ret);
> + priv->gpio_powerdown = gpiod_get(&spi->dev, "powerdown", GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->gpio_powerdown)) {
> + ret = PTR_ERR(priv->gpio_powerdown);
> + dev_err(&priv->spi->dev, "powerdown GPIO request failed: %d", ret);
Binding said it is optional, so this cannot be a failure.
Also, please use ret = dev_err_probe syntax.
> goto err_free;
> }
>
> - ret = gpio_request(p54spi_gpio_irq, "p54spi irq");
> - if (ret < 0) {
> - dev_err(&priv->spi->dev, "irq GPIO request failed: %d", ret);
> - goto err_free_gpio_power;
> - }
> -
> - gpio_direction_output(p54spi_gpio_power, 0);
> - gpio_direction_input(p54spi_gpio_irq);
> -
> - ret = request_irq(gpio_to_irq(p54spi_gpio_irq),
> - p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi",
> - priv->spi);
> + ret = request_irq(spi->irq, p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi", priv->spi);
> if (ret < 0) {
> dev_err(&priv->spi->dev, "request_irq() failed");
> - goto err_free_gpio_irq;
> + goto err_free_gpio_power;
> }
>
> - irq_set_irq_type(gpio_to_irq(p54spi_gpio_irq), IRQ_TYPE_EDGE_RISING);
>
> INIT_WORK(&priv->work, p54spi_work);
> init_completion(&priv->fw_comp);
> @@ -659,11 +636,9 @@ static int p54spi_probe(struct spi_device *spi)
>
> err_free_common:
> release_firmware(priv->firmware);
> - free_irq(gpio_to_irq(p54spi_gpio_irq), spi);
> -err_free_gpio_irq:
> - gpio_free(p54spi_gpio_irq);
> + free_irq(priv->irq, spi);
> err_free_gpio_power:
> - gpio_free(p54spi_gpio_power);
> + gpiod_put(priv->gpio_powerdown);
> err_free:
> p54_free_common(priv->hw);
> return ret;
> @@ -675,10 +650,8 @@ static void p54spi_remove(struct spi_device *spi)
>
> p54_unregister_common(priv->hw);
>
> - free_irq(gpio_to_irq(p54spi_gpio_irq), spi);
> -
> - gpio_free(p54spi_gpio_power);
> - gpio_free(p54spi_gpio_irq);
> + free_irq(priv->irq, spi);
> + gpiod_put(priv->gpio_powerdown);
> release_firmware(priv->firmware);
>
> mutex_destroy(&priv->mutex);
> @@ -686,10 +659,19 @@ static void p54spi_remove(struct spi_device *spi)
> p54_free_common(priv->hw);
> }
>
> +struct of_device_id p54spi_of_ids[] = {
static const
> + { .compatible = "cnxt,3110x", },
> + { .compatible = "isil,p54spi", },
> + { .compatible = "st,stlc4550", },
> + { .compatible = "st,stlc4560", },
At least last two devices are then compatible, so this should be
expressed in the binding with fallback and drop stlc4560 here. Maybe all
of them are compatible.
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, p54spi_of_ids);
>
> static struct spi_driver p54spi_driver = {
> .driver = {
> .name = "p54spi",
> + .of_match_table = p54spi_of_ids,
> },
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 04/28] arm64: Provide arm64 UAPI for other host architectures
From: Steffen Eiden @ 2026-04-29 8:04 UTC (permalink / raw)
To: Steffen Eiden
Cc: kvm, kvmarm, linux-arm-kernel, linux-kernel, linux-s390,
Andreas Grapentin, Arnd Bergmann, Catalin Marinas,
Christian Borntraeger, Claudio Imbrenda, David Hildenbrand,
Gautam Gala, Hendrik Brueckner, Janosch Frank, Joey Gouly,
Marc Zyngier, Nina Schoetterl-Glausch, Oliver Upton,
Paolo Bonzini, Suzuki K Poulose, Ulrich Weigand, Will Deacon,
Zenghui Yu
In-Reply-To: <20260428155622.1361364-5-seiden@linux.ibm.com>
On Tue, Apr 28, 2026 at 05:55:56PM +0200, Steffen Eiden wrote:
> Enable the ARM64 userspace API to be used on non-arm64 host
> architectures, with initial support for s390.
>
> The arm64 KVM UAPI headers are relocated to include/uapi/arch/arm64/,
> allowing non‑arm64 hosts (such as s390) to use the arm64 KVM userspace API.
>
> To achieve architecture independence, some type aliases are introduced,
> which conditionally resolve to native arm64 types when building on arm64
> or to fallback to ABI compatible inline struct definitions on other
> architectures.
>
> The build system is updated to install the moved UAPI headers to their
> original location but in and conditionally export arm64 architecture
> headers for s390. This infrastructure enables s390 systems to host arm64
> virtual machines while maintaining full compatibility with the existing
> arm64 KVM-UAPI, requiring only minimal, compatible changes to the arm64
> UAPI-headers itself.
@Will @Marc
I think doing it the other way around for the UPAI here might be the better
approach with less churn (esp for arm)
1) keep arch/arm64/include/uapi/asm/{kvm.h, sve_context.h} where they are
2) mark them as shared in the include guard similar as in the symlink variant
3) for s390 (and any other arch that wants them) install the headers to
include/uapi/arch/arm64/asm
The only thing I fear with this (and also the symlink) approach is that it is
easy for you to include a header that we do not have on s390. This was the
reason I moved all the headers that are shared to a different location - to
stress that those are shared between multiple arches. Marking them as shared
in the include guard may also do the job well enough.
What do you think about this variant?
Steffen
<snip>
^ permalink raw reply
* Re: [PATCH] arch: arm64: fix KERNEL_SEGMENT_COUNT error
From: Zhaoyang Huang @ 2026-04-29 8:03 UTC (permalink / raw)
To: zhaoyang.huang
Cc: Catalin Marinas, Will Deacon, Ard Biesheuvel, linux-arm-kernel,
linux-kernel, steve.kang, shuo.tian, haiyan.liu, hao_hao.wang
In-Reply-To: <20260429061752.2880923-1-zhaoyang.huang@unisoc.com>
On Wed, Apr 29, 2026 at 2:19 PM zhaoyang.huang
<zhaoyang.huang@unisoc.com> wrote:
>
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> During debug of a kernel panic, we find that the pte_t of the final
> part of [data, end] segment got overflow to the next page of
> init_pg_end[1] which is the gap page before early_init_stack[2].
> This should be introduced by the KERNEL_SEGMENT_COUNT's value is 5
> which should be 6 as map_segment are called 6 times for the segments
> of (text, stext, rodata, inittext, initdata, data+bss)
>
> [1]
> crash_arm64_v9.0.1> vtop ffffffed00601000
> VIRTUAL PHYSICAL
> ffffffed00601000 83401000
>
> PAGE DIRECTORY: ffffffecffd62000
> PGD: ffffffecffd62da0 => 10000000833fb003
> PMD: ffffff80033fb018 => 10000000833fe003
> PTE: ffffff80033fe008 => 68000083401f03
> PAGE: 83401000
>
> PTE PHYSICAL FLAGS
> 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> fffffffec00d0040 83401000 0 0 1 4000 reserved
>
> [2]
> ffffffed002c8000 (r) __pi__data
> ffffffed0054e000 (d) __pi___bss_start
> ffffffed005f5000 (b) __pi_init_pg_dir
> ffffffed005fe000 (b) __pi_init_pg_end
> ffffffed005ff000 (B) early_init_stack
> ffffffed00608000 (b) __pi__end
>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> ---
> arch/arm64/include/asm/kernel-pgtable.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
> index 74a4f738c5f5..14dd1c52552a 100644
> --- a/arch/arm64/include/asm/kernel-pgtable.h
> +++ b/arch/arm64/include/asm/kernel-pgtable.h
> @@ -64,8 +64,8 @@
> #define INIT_IDMAP_FDT_PAGES (EARLY_PAGES(INIT_IDMAP_PGTABLE_LEVELS, 0UL, UL(MAX_FDT_SIZE), 1) - 1)
> #define INIT_IDMAP_FDT_SIZE ((INIT_IDMAP_FDT_PAGES + EARLY_IDMAP_EXTRA_FDT_PAGES) * PAGE_SIZE)
>
> -/* The number of segments in the kernel image (text, rodata, inittext, initdata, data+bss) */
> -#define KERNEL_SEGMENT_COUNT 5
> +/* The number of segments in the kernel image (text, stext, rodata, inittext, initdata, data+bss) */
> +#define KERNEL_SEGMENT_COUNT 6
>
> #if SWAPPER_BLOCK_SIZE > SEGMENT_ALIGN
> #define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 1)
I just noticed that the page just behind init_pg_end which I called as
guard page is designed as early_init_stack in vmlinux.lds.s. That
could explain why I find the strings of aliases within
idreg-override.c present in this page.
ffffffed005fe000 (b) __pi_init_pg_end
...
ffffffed005fec50: 77735f34366d7261 726c3d656876682e arm64_sw.hvhe=lr
ffffffed005fec60: 00003d633d723d3d 0000000000000000 ==r=c=..........
...
ffffffed005ff000 (B) early_init_stack
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: remoteproc: add imx-rproc-psci binding
From: Krzysztof Kozlowski @ 2026-04-29 8:04 UTC (permalink / raw)
To: Jiafei Pan
Cc: andersson, mathieu.poirier, peng.fan, Frank.Li, s.hauer, kernel,
festevam, imx, linux-arm-kernel, linux-kernel, Zhiqiang.Hou,
mingkai.hu, linux-remoteproc, devicetree
In-Reply-To: <20260429031047.30893-2-Jiafei.Pan@nxp.com>
On Wed, Apr 29, 2026 at 11:10:43AM +0800, Jiafei Pan wrote:
> Add compatible string "fsl,imx-rproc-psci" for i.MX Cortex-A Core's
> remoteproc support.
So here is v2 and almost all comments apply.
Including one that it fails obviously testing.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/3] ARM: at91: remove unnecessary of_platform_default_populate calls
From: Alexander Dahl @ 2026-04-29 8:02 UTC (permalink / raw)
To: Miquel Raynal
Cc: Rob Herring (Arm), Richard Weinberger, Vignesh Raghavendra,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Russell King,
linux-mtd, linux-arm-kernel, linux-kernel
In-Reply-To: <87tsswfnmy.fsf@bootlin.com>
Hello Miquel,
thanks for your kind reply, I think with your help I have new
information now.
First of all: I could reproduce on an off-the-shelve sam9x60-curiosity
board, which has mainline dts, so others should be able to reproduce,
too. Tested with v7.0 release and today's master
(v7.1-rc1-58-gdca922e019dd7). See below for details:
Am Mon, Apr 27, 2026 at 05:07:01PM +0200 schrieb Miquel Raynal:
> Hi Alexander,
>
> On 24/04/2026 at 12:56:27 +02, Alexander Dahl <ada@thorsis.com> wrote:
>
> > Hei hei,
> >
> > after few hints in IRC yesterday, I tried to understand why neither
> > the ebi driver nor the nand driver are probed, but I failed. See
> > below.
>
> Just to be clear, I would not expect the NAND driver to probe "alone",
> it is described as a child node of the EBI controller which has its own
> compatible. As a result, only the of_platform_populate() at the end of
> the probe of the EBI can lead to the NAND controller to probe. The EBI
> node being a child node of a "simple-bus", this is the one we should
> focus on, because it should be probed.
Right, this is how I understood it, too.
> One reason (trying to be creative) could the that Rob's patch is
> dropping an explicit populate that maybe kind of bypasses checks that
> the "official" populate does. So maybe there is one resource that is
> missing and which is not ignored as it used to be by the core device
> driver (likely, dd.c).
>
> Can you enable CONFIG_DEBUG_DRIVER and see in the logs if anything pops
> up? Maybe trying to trace (manually) in the core why we do not attempt
> to probe the EBI controller by looking for possible conditions to bail
> out early. Pinctrl is one of them, so maybe just removing all pinctrl
> references in the DT may help troubleshooting this (obviously probe will
> fail if pinctrl is incorrect, but if it is attempted we will have a
> culprit).
Was not aware of that option before, produces a lot of output, but I
think helpful output for this kind of problem, not quoting the whole
kernel log, but what I think is relevant here:
[ 0.177130] device: '10000000.ebi': device_add
[ 0.177222] bus: 'platform': add device 10000000.ebi
[ 0.177343] PM: Adding info for platform:10000000.ebi
[ 0.177531] platform 10000000.ebi: Not linking /ahb/apb/clock-controller@fffffc00 - might never become dev
[ 0.177584] /ahb/ebi@10000000 Dropping the fwnode link to /ahb/apb/clock-controller@fffffc00
…
[ 0.217944] device: 'platform:fffffa00.gpio--platform:10000000.ebi': device_add
[ 0.218200] platform 10000000.ebi: Linked as a sync state only consumer to fffffa00.gpio
…
[ 0.958298] bus: 'platform': add driver atmel-ebi
[ 0.958451] platform 10000000.ebi: bus: 'platform': __driver_probe_device: matched device with driver atmel-ebi
[ 0.958566] platform 10000000.ebi: error -EPROBE_DEFER: wait for supplier /ahb/apb/pinctrl@fffff400/ebi/ebi-data-lsb
[ 0.958649] platform 10000000.ebi: Added to deferred list
[ 0.959429] bus: 'platform': remove driver atmel-ebi
[ 0.959540] driver: 'atmel-ebi': driver_release
…
[ 1.170809] pinctrl-at91 ahb:apb:pinctrl@fffff400: driver: 'pinctrl-at91': driver_bound: bound to device
[ 1.170871] /ahb/apb/adc@f804c000 Linked as a fwnode consumer to /ahb/apb/pinctrl@fffff400
[ 1.170947] /ahb/apb/adc@f804c000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/adc/adc-default
[ 1.171031] /ahb/apb/adc@f804c000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/adc/adtrg-default
[ 1.171122] /ahb/apb/can@f8004000 Linked as a fwnode consumer to /ahb/apb/pinctrl@fffff400
[ 1.171184] /ahb/apb/can@f8004000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/can1/can1-rx-tx
[ 1.171267] /ahb/apb/serial@fffff200 Linked as a fwnode consumer to /ahb/apb/pinctrl@fffff400
[ 1.171327] /ahb/apb/serial@fffff200 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/dbgu/dbgu-0
[ 1.171409] /ahb/ebi@10000000 Linked as a fwnode consumer to /ahb/apb/pinctrl@fffff400
[ 1.171464] /ahb/ebi@10000000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/ebi/ebi-data-lsb
[ 1.171536] /ahb/ebi@10000000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/ebi/ebi-addr-nand
…
[ 1.176057] platform 10000000.ebi: Linked as a sync state only consumer to ahb:apb:pinctrl@fffff400
[ 1.176127] device: 'platform:ahb:apb:pinctrl@fffff400--platform:f802c000.ethernet': device_add
…
[ 1.178167] devices_kset: Moving 10000000.ebi to end of list
[ 1.178191] PM: Moving platform:10000000.ebi to end of list
[ 1.178222] platform 10000000.ebi: Linked as a consumer to ahb:apb:pinctrl@fffff400
[ 1.178248] /ahb/ebi@10000000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400
…
[ 3.431138] devices_kset: Moving 10000000.ebi to end of list
[ 3.431206] PM: Moving platform:10000000.ebi to end of list
[ 3.431256] platform 10000000.ebi: Retrying from deferred list
…
[ 3.437765] UBI error: cannot open mtd rootfs, error -2
So the ebi driver is probed but returns with -EPROBE_DEFER, to my
interpretation because the pinctrl driver is not ready? Later the
pinctrl driver drops the relation? On retry from the deferred list
the driver does not probe again? This feels strange, because other
drivers probe as usual after that "Retrying from deferred list"
message. But other deferred drivers do not have that "remove driver"
and "driver release" messages.
The pinctrl itself seems to work, gpiodetect and gpioinfo show
reasonable output, gpio connected LED works as expected.
No time to dig into this further right now,
but sharing what I have so far anyways.
Greets
Alex
^ permalink raw reply
* Re: [PATCH v4 01/15] arm64: mm: Map the linear alias of text/rodata as tagged
From: Ard Biesheuvel @ 2026-04-29 7:58 UTC (permalink / raw)
To: Kevin Brodsky, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
linux-mm, linux-hardening
In-Reply-To: <1ba0b6ce-3e71-45f7-a3c8-cdc5aadcaf27@arm.com>
On Wed, 29 Apr 2026, at 09:57, Kevin Brodsky wrote:
> On 28/04/2026 18:23, Ard Biesheuvel wrote:
>> Hi Kevin,
>>
>> On Tue, 28 Apr 2026, at 16:16, Kevin Brodsky wrote:
>>> On 27/04/2026 17:34, Ard Biesheuvel wrote:
>>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>>
>>>> Before moving the empty_zero_page into the __ro_after_init section, make
>>>> sure it has the memory-tagged type. This is needed to ensure that
>>>> cpu_enable_mte() will be able to initialize the tags correctly.
>>> mark_linear_text_alias_ro() is called after all features have been
>>> detected and enabled, so do we actually need this?
>>>
>>> AFAICT the lines that matter for cpu_enable_mte() are those, in map_mem():
>>>
>>> __map_memblock(pgdp, kernel_start, kernel_end,
>>> PAGE_KERNEL, NO_CONT_MAPPINGS);
>>>
>>> It is probably this call that needs to be changed to use
>>> pgprot_tagged(PAGE_KERNEL).
>>>
>> I see. I guess we should probably update both, no?
>
> We could, but would we ever access the tags in data mapped read-only?
> cpu_enable_mte() needs tag access to zero them, but AFAIU it's really a
> special case that is only relevant to the situation where the data is RW.
>
Right, that makes sense.
^ permalink raw reply
* Re: [PATCH v4 01/15] arm64: mm: Map the linear alias of text/rodata as tagged
From: Kevin Brodsky @ 2026-04-29 7:57 UTC (permalink / raw)
To: Ard Biesheuvel, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
linux-mm, linux-hardening
In-Reply-To: <6f514d91-c8ce-473f-8383-f3b9a4cc2f7a@app.fastmail.com>
On 28/04/2026 18:23, Ard Biesheuvel wrote:
> Hi Kevin,
>
> On Tue, 28 Apr 2026, at 16:16, Kevin Brodsky wrote:
>> On 27/04/2026 17:34, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>
>>> Before moving the empty_zero_page into the __ro_after_init section, make
>>> sure it has the memory-tagged type. This is needed to ensure that
>>> cpu_enable_mte() will be able to initialize the tags correctly.
>> mark_linear_text_alias_ro() is called after all features have been
>> detected and enabled, so do we actually need this?
>>
>> AFAICT the lines that matter for cpu_enable_mte() are those, in map_mem():
>>
>> __map_memblock(pgdp, kernel_start, kernel_end,
>> PAGE_KERNEL, NO_CONT_MAPPINGS);
>>
>> It is probably this call that needs to be changed to use
>> pgprot_tagged(PAGE_KERNEL).
>>
> I see. I guess we should probably update both, no?
We could, but would we ever access the tags in data mapped read-only?
cpu_enable_mte() needs tag access to zero them, but AFAIU it's really a
special case that is only relevant to the situation where the data is RW.
- Kevin
^ permalink raw reply
* [PATCH v2 5/6] regulator: mt6359: Add regulator supply names
From: Chen-Yu Tsai @ 2026-04-29 7:41 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260429074113.3720271-1-wenst@chromium.org>
The MT6359 regulator DT binding defines the supply names for the PMIC.
Add support for them by adding .supply_name field settings for each
regulator. The buck regulators each have their own supply. The name
of the supply is related to the name of the buck regulator. The LDOs
have shared supplies.
Add the supply name to the declaration of each regulator. At the moment
they are declared explicitly, but the buck regulator macro can be made
to derive both the match string and supply name from the base name once
the *_sshub regulators are figured out and removed. For context, the
*_sshub regulators are not separate regulators, but separate settings
for the same name regulators without the "_sshub" suffix.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- Handle vbbck's supply internally
---
drivers/regulator/mt6359-regulator.c | 220 +++++++++++++++------------
1 file changed, 125 insertions(+), 95 deletions(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index bcf9a476a34e..fa97c3189df5 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -38,7 +38,7 @@ struct mt6359_regulator_info {
u32 lp_mode_mask;
};
-#define MT6359_BUCK(match, _name, min, max, step, \
+#define MT6359_BUCK(match, _name, supply, min, max, step, \
_enable_reg, _status_reg, \
_vsel_reg, _vsel_mask, \
_lp_mode_reg, _lp_mode_shift, \
@@ -46,6 +46,7 @@ struct mt6359_regulator_info {
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &mt6359_volt_linear_ops, \
@@ -69,11 +70,12 @@ struct mt6359_regulator_info {
.modeset_mask = BIT(_modeset_shift), \
}
-#define MT6359_LDO_LINEAR(match, _name, min, max, step, \
+#define MT6359_LDO_LINEAR(match, _name, supply, min, max, step, \
_enable_reg, _status_reg, _vsel_reg, _vsel_mask) \
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &mt6359_volt_linear_ops, \
@@ -92,12 +94,13 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
-#define MT6359_LDO(match, _name, _volt_table, \
+#define MT6359_LDO(match, _name, supply, _volt_table, \
_enable_reg, _enable_mask, _status_reg, \
_vsel_reg, _vsel_mask, _en_delay) \
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &mt6359_volt_table_ops, \
@@ -116,11 +119,13 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
-#define MT6359_REG_FIXED(match, _name, _enable_reg, \
- _status_reg, _fixed_volt) \
+#define MT6359_REG_FIXED(match, _name, supply, \
+ _enable_reg, _status_reg, \
+ _fixed_volt) \
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &mt6359_volt_fixed_ops, \
@@ -136,12 +141,14 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
-#define MT6359P_LDO1(match, _name, _ops, _volt_table, \
- _enable_reg, _enable_mask, _status_reg, \
- _vsel_reg, _vsel_mask) \
+#define MT6359P_LDO1(match, _name, supply, _ops, \
+ _volt_table, _enable_reg, \
+ _enable_mask, _status_reg, \
+ _vsel_reg, _vsel_mask) \
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &_ops, \
@@ -470,14 +477,14 @@ static const struct regulator_ops mt6359p_vemc_ops = {
/* The array is indexed by id(MT6359_ID_XXX) */
static const struct mt6359_regulator_info mt6359_regulators[] = {
- MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
+ MT6359_BUCK("buck_vs1", VS1, "vsys-vs1", 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
MT6359_RG_BUCK_VS1_VOSEL_MASK <<
MT6359_RG_BUCK_VS1_VOSEL_SHIFT,
MT6359_RG_BUCK_VS1_LP_ADDR, MT6359_RG_BUCK_VS1_LP_SHIFT,
MT6359_RG_VS1_FPWM_ADDR, MT6359_RG_VS1_FPWM_SHIFT),
- MT6359_BUCK("buck_vgpu11", VGPU11, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vgpu11", VGPU11, "vsys-vgpu11", 400000, 1193750, 6250,
MT6359_RG_BUCK_VGPU11_EN_ADDR,
MT6359_DA_VGPU11_EN_ADDR, MT6359_RG_BUCK_VGPU11_VOSEL_ADDR,
MT6359_RG_BUCK_VGPU11_VOSEL_MASK <<
@@ -485,7 +492,7 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VGPU11_LP_ADDR,
MT6359_RG_BUCK_VGPU11_LP_SHIFT,
MT6359_RG_VGPU11_FCCM_ADDR, MT6359_RG_VGPU11_FCCM_SHIFT),
- MT6359_BUCK("buck_vmodem", VMODEM, 400000, 1100000, 6250,
+ MT6359_BUCK("buck_vmodem", VMODEM, "vsys-vmodem", 400000, 1100000, 6250,
MT6359_RG_BUCK_VMODEM_EN_ADDR,
MT6359_DA_VMODEM_EN_ADDR, MT6359_RG_BUCK_VMODEM_VOSEL_ADDR,
MT6359_RG_BUCK_VMODEM_VOSEL_MASK <<
@@ -493,35 +500,35 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VMODEM_LP_ADDR,
MT6359_RG_BUCK_VMODEM_LP_SHIFT,
MT6359_RG_VMODEM_FCCM_ADDR, MT6359_RG_VMODEM_FCCM_SHIFT),
- MT6359_BUCK("buck_vpu", VPU, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vpu", VPU, "vsys-vpu", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPU_EN_ADDR,
MT6359_DA_VPU_EN_ADDR, MT6359_RG_BUCK_VPU_VOSEL_ADDR,
MT6359_RG_BUCK_VPU_VOSEL_MASK <<
MT6359_RG_BUCK_VPU_VOSEL_SHIFT,
MT6359_RG_BUCK_VPU_LP_ADDR, MT6359_RG_BUCK_VPU_LP_SHIFT,
MT6359_RG_VPU_FCCM_ADDR, MT6359_RG_VPU_FCCM_SHIFT),
- MT6359_BUCK("buck_vcore", VCORE, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vcore", VCORE, "vsys-vcore", 400000, 1193750, 6250,
MT6359_RG_BUCK_VCORE_EN_ADDR,
MT6359_DA_VCORE_EN_ADDR, MT6359_RG_BUCK_VCORE_VOSEL_ADDR,
MT6359_RG_BUCK_VCORE_VOSEL_MASK <<
MT6359_RG_BUCK_VCORE_VOSEL_SHIFT,
MT6359_RG_BUCK_VCORE_LP_ADDR, MT6359_RG_BUCK_VCORE_LP_SHIFT,
MT6359_RG_VCORE_FCCM_ADDR, MT6359_RG_VCORE_FCCM_SHIFT),
- MT6359_BUCK("buck_vs2", VS2, 800000, 1600000, 12500,
+ MT6359_BUCK("buck_vs2", VS2, "vsys-vs2", 800000, 1600000, 12500,
MT6359_RG_BUCK_VS2_EN_ADDR,
MT6359_DA_VS2_EN_ADDR, MT6359_RG_BUCK_VS2_VOSEL_ADDR,
MT6359_RG_BUCK_VS2_VOSEL_MASK <<
MT6359_RG_BUCK_VS2_VOSEL_SHIFT,
MT6359_RG_BUCK_VS2_LP_ADDR, MT6359_RG_BUCK_VS2_LP_SHIFT,
MT6359_RG_VS2_FPWM_ADDR, MT6359_RG_VS2_FPWM_SHIFT),
- MT6359_BUCK("buck_vpa", VPA, 500000, 3650000, 50000,
+ MT6359_BUCK("buck_vpa", VPA, "vsys-vpa", 500000, 3650000, 50000,
MT6359_RG_BUCK_VPA_EN_ADDR,
MT6359_DA_VPA_EN_ADDR, MT6359_RG_BUCK_VPA_VOSEL_ADDR,
MT6359_RG_BUCK_VPA_VOSEL_MASK <<
MT6359_RG_BUCK_VPA_VOSEL_SHIFT,
MT6359_RG_BUCK_VPA_LP_ADDR, MT6359_RG_BUCK_VPA_LP_SHIFT,
MT6359_RG_VPA_MODESET_ADDR, MT6359_RG_VPA_MODESET_SHIFT),
- MT6359_BUCK("buck_vproc2", VPROC2, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vproc2", VPROC2, "vsys-vproc2", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPROC2_EN_ADDR,
MT6359_DA_VPROC2_EN_ADDR, MT6359_RG_BUCK_VPROC2_VOSEL_ADDR,
MT6359_RG_BUCK_VPROC2_VOSEL_MASK <<
@@ -529,7 +536,7 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VPROC2_LP_ADDR,
MT6359_RG_BUCK_VPROC2_LP_SHIFT,
MT6359_RG_VPROC2_FCCM_ADDR, MT6359_RG_VPROC2_FCCM_SHIFT),
- MT6359_BUCK("buck_vproc1", VPROC1, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vproc1", VPROC1, "vsys-vproc1", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPROC1_EN_ADDR,
MT6359_DA_VPROC1_EN_ADDR, MT6359_RG_BUCK_VPROC1_VOSEL_ADDR,
MT6359_RG_BUCK_VPROC1_VOSEL_MASK <<
@@ -537,7 +544,7 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VPROC1_LP_ADDR,
MT6359_RG_BUCK_VPROC1_LP_SHIFT,
MT6359_RG_VPROC1_FCCM_ADDR, MT6359_RG_VPROC1_FCCM_SHIFT),
- MT6359_BUCK("buck_vcore_sshub", VCORE_SSHUB, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vcore_sshub", VCORE_SSHUB, "vsys-vcore", 400000, 1193750, 6250,
MT6359_RG_BUCK_VCORE_SSHUB_EN_ADDR,
MT6359_DA_VCORE_EN_ADDR,
MT6359_RG_BUCK_VCORE_SSHUB_VOSEL_ADDR,
@@ -545,158 +552,159 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VCORE_SSHUB_VOSEL_SHIFT,
MT6359_RG_BUCK_VCORE_LP_ADDR, MT6359_RG_BUCK_VCORE_LP_SHIFT,
MT6359_RG_VCORE_FCCM_ADDR, MT6359_RG_VCORE_FCCM_SHIFT),
- MT6359_REG_FIXED("ldo_vaud18", VAUD18, MT6359_RG_LDO_VAUD18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vaud18", VAUD18, "vs1-ldo1", MT6359_RG_LDO_VAUD18_EN_ADDR,
MT6359_DA_VAUD18_B_EN_ADDR, 1800000),
- MT6359_LDO("ldo_vsim1", VSIM1, vsim1_voltages,
+ MT6359_LDO("ldo_vsim1", VSIM1, "vsys-ldo2", vsim1_voltages,
MT6359_RG_LDO_VSIM1_EN_ADDR, MT6359_RG_LDO_VSIM1_EN_SHIFT,
MT6359_DA_VSIM1_B_EN_ADDR, MT6359_RG_VSIM1_VOSEL_ADDR,
MT6359_RG_VSIM1_VOSEL_MASK << MT6359_RG_VSIM1_VOSEL_SHIFT,
480),
- MT6359_LDO("ldo_vibr", VIBR, vibr_voltages,
+ MT6359_LDO("ldo_vibr", VIBR, "vsys-ldo1", vibr_voltages,
MT6359_RG_LDO_VIBR_EN_ADDR, MT6359_RG_LDO_VIBR_EN_SHIFT,
MT6359_DA_VIBR_B_EN_ADDR, MT6359_RG_VIBR_VOSEL_ADDR,
MT6359_RG_VIBR_VOSEL_MASK << MT6359_RG_VIBR_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vrf12", VRF12, vrf12_voltages,
+ MT6359_LDO("ldo_vrf12", VRF12, "vs2-ldo2", vrf12_voltages,
MT6359_RG_LDO_VRF12_EN_ADDR, MT6359_RG_LDO_VRF12_EN_SHIFT,
MT6359_DA_VRF12_B_EN_ADDR, MT6359_RG_VRF12_VOSEL_ADDR,
MT6359_RG_VRF12_VOSEL_MASK << MT6359_RG_VRF12_VOSEL_SHIFT,
120),
- MT6359_REG_FIXED("ldo_vusb", VUSB, MT6359_RG_LDO_VUSB_EN_0_ADDR,
+ MT6359_REG_FIXED("ldo_vusb", VUSB, "vsys-ldo2", MT6359_RG_LDO_VUSB_EN_0_ADDR,
MT6359_DA_VUSB_B_EN_ADDR, 3000000),
- MT6359_LDO_LINEAR("ldo_vsram_proc2", VSRAM_PROC2, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_proc2", VSRAM_PROC2, "vs2-ldo1", 500000, 1293750, 6250,
MT6359_RG_LDO_VSRAM_PROC2_EN_ADDR,
MT6359_DA_VSRAM_PROC2_B_EN_ADDR,
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_SHIFT),
- MT6359_LDO("ldo_vio18", VIO18, volt18_voltages,
+ MT6359_LDO("ldo_vio18", VIO18, "vs1-ldo2", volt18_voltages,
MT6359_RG_LDO_VIO18_EN_ADDR, MT6359_RG_LDO_VIO18_EN_SHIFT,
MT6359_DA_VIO18_B_EN_ADDR, MT6359_RG_VIO18_VOSEL_ADDR,
MT6359_RG_VIO18_VOSEL_MASK << MT6359_RG_VIO18_VOSEL_SHIFT,
960),
- MT6359_LDO("ldo_vcamio", VCAMIO, volt18_voltages,
+ MT6359_LDO("ldo_vcamio", VCAMIO, "vs1-ldo1", volt18_voltages,
MT6359_RG_LDO_VCAMIO_EN_ADDR, MT6359_RG_LDO_VCAMIO_EN_SHIFT,
MT6359_DA_VCAMIO_B_EN_ADDR, MT6359_RG_VCAMIO_VOSEL_ADDR,
MT6359_RG_VCAMIO_VOSEL_MASK << MT6359_RG_VCAMIO_VOSEL_SHIFT,
1290),
- MT6359_REG_FIXED("ldo_vcn18", VCN18, MT6359_RG_LDO_VCN18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vcn18", VCN18, "vs1-ldo2", MT6359_RG_LDO_VCN18_EN_ADDR,
MT6359_DA_VCN18_B_EN_ADDR, 1800000),
- MT6359_REG_FIXED("ldo_vfe28", VFE28, MT6359_RG_LDO_VFE28_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vfe28", VFE28, "vsys-ldo1", MT6359_RG_LDO_VFE28_EN_ADDR,
MT6359_DA_VFE28_B_EN_ADDR, 2800000),
- MT6359_LDO("ldo_vcn13", VCN13, vcn13_voltages,
+ MT6359_LDO("ldo_vcn13", VCN13, "vs2-ldo2", vcn13_voltages,
MT6359_RG_LDO_VCN13_EN_ADDR, MT6359_RG_LDO_VCN13_EN_SHIFT,
MT6359_DA_VCN13_B_EN_ADDR, MT6359_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
MT6359_RG_LDO_VCN33_1_EN_1_SHIFT,
MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_REG_FIXED("ldo_vaux18", VAUX18, MT6359_RG_LDO_VAUX18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359_RG_LDO_VAUX18_EN_ADDR,
MT6359_DA_VAUX18_B_EN_ADDR, 1800000),
- MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, 500000, 1293750,
+ MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
6250,
MT6359_RG_LDO_VSRAM_OTHERS_EN_ADDR,
MT6359_DA_VSRAM_OTHERS_B_EN_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_SHIFT),
- MT6359_LDO("ldo_vefuse", VEFUSE, vefuse_voltages,
+ MT6359_LDO("ldo_vefuse", VEFUSE, "vs1-ldo2", vefuse_voltages,
MT6359_RG_LDO_VEFUSE_EN_ADDR, MT6359_RG_LDO_VEFUSE_EN_SHIFT,
MT6359_DA_VEFUSE_B_EN_ADDR, MT6359_RG_VEFUSE_VOSEL_ADDR,
MT6359_RG_VEFUSE_VOSEL_MASK << MT6359_RG_VEFUSE_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vxo22", VXO22, vxo22_voltages,
+ MT6359_LDO("ldo_vxo22", VXO22, "vsys-ldo2", vxo22_voltages,
MT6359_RG_LDO_VXO22_EN_ADDR, MT6359_RG_LDO_VXO22_EN_SHIFT,
MT6359_DA_VXO22_B_EN_ADDR, MT6359_RG_VXO22_VOSEL_ADDR,
MT6359_RG_VXO22_VOSEL_MASK << MT6359_RG_VXO22_VOSEL_SHIFT,
120),
- MT6359_LDO("ldo_vrfck", VRFCK, vrfck_voltages,
+ MT6359_LDO("ldo_vrfck", VRFCK, "vsys-ldo2", vrfck_voltages,
MT6359_RG_LDO_VRFCK_EN_ADDR, MT6359_RG_LDO_VRFCK_EN_SHIFT,
MT6359_DA_VRFCK_B_EN_ADDR, MT6359_RG_VRFCK_VOSEL_ADDR,
MT6359_RG_VRFCK_VOSEL_MASK << MT6359_RG_VRFCK_VOSEL_SHIFT,
480),
- MT6359_REG_FIXED("ldo_vbif28", VBIF28, MT6359_RG_LDO_VBIF28_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vbif28", VBIF28, "vsys-ldo2", MT6359_RG_LDO_VBIF28_EN_ADDR,
MT6359_DA_VBIF28_B_EN_ADDR, 2800000),
- MT6359_LDO("ldo_vio28", VIO28, vio28_voltages,
+ MT6359_LDO("ldo_vio28", VIO28, "vsys-ldo2", vio28_voltages,
MT6359_RG_LDO_VIO28_EN_ADDR, MT6359_RG_LDO_VIO28_EN_SHIFT,
MT6359_DA_VIO28_B_EN_ADDR, MT6359_RG_VIO28_VOSEL_ADDR,
MT6359_RG_VIO28_VOSEL_MASK << MT6359_RG_VIO28_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vemc", VEMC, vemc_voltages,
+ MT6359_LDO("ldo_vemc", VEMC, "vsys-ldo2", vemc_voltages,
MT6359_RG_LDO_VEMC_EN_ADDR, MT6359_RG_LDO_VEMC_EN_SHIFT,
MT6359_DA_VEMC_B_EN_ADDR, MT6359_RG_VEMC_VOSEL_ADDR,
MT6359_RG_VEMC_VOSEL_MASK << MT6359_RG_VEMC_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_va12", VA12, va12_voltages,
+ MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359_RG_LDO_VA12_EN_ADDR, MT6359_RG_LDO_VA12_EN_SHIFT,
MT6359_DA_VA12_B_EN_ADDR, MT6359_RG_VA12_VOSEL_ADDR,
MT6359_RG_VA12_VOSEL_MASK << MT6359_RG_VA12_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_va09", VA09, va09_voltages,
+ MT6359_LDO("ldo_va09", VA09, "vs2-ldo2", va09_voltages,
MT6359_RG_LDO_VA09_EN_ADDR, MT6359_RG_LDO_VA09_EN_SHIFT,
MT6359_DA_VA09_B_EN_ADDR, MT6359_RG_VA09_VOSEL_ADDR,
MT6359_RG_VA09_VOSEL_MASK << MT6359_RG_VA09_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vrf18", VRF18, vrf18_voltages,
+ MT6359_LDO("ldo_vrf18", VRF18, "vs1-ldo2", vrf18_voltages,
MT6359_RG_LDO_VRF18_EN_ADDR, MT6359_RG_LDO_VRF18_EN_SHIFT,
MT6359_DA_VRF18_B_EN_ADDR, MT6359_RG_VRF18_VOSEL_ADDR,
MT6359_RG_VRF18_VOSEL_MASK << MT6359_RG_VRF18_VOSEL_SHIFT,
120),
- MT6359_LDO_LINEAR("ldo_vsram_md", VSRAM_MD, 500000, 1100000, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_md", VSRAM_MD, "vs2-ldo1", 500000, 1100000, 6250,
MT6359_RG_LDO_VSRAM_MD_EN_ADDR,
MT6359_DA_VSRAM_MD_B_EN_ADDR,
MT6359_RG_LDO_VSRAM_MD_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_MD_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_MD_VOSEL_SHIFT),
- MT6359_LDO("ldo_vufs", VUFS, volt18_voltages,
+ MT6359_LDO("ldo_vufs", VUFS, "vs1-ldo1", volt18_voltages,
MT6359_RG_LDO_VUFS_EN_ADDR, MT6359_RG_LDO_VUFS_EN_SHIFT,
MT6359_DA_VUFS_B_EN_ADDR, MT6359_RG_VUFS_VOSEL_ADDR,
MT6359_RG_VUFS_VOSEL_MASK << MT6359_RG_VUFS_VOSEL_SHIFT,
1920),
- MT6359_LDO("ldo_vm18", VM18, volt18_voltages,
+ MT6359_LDO("ldo_vm18", VM18, "vs1-ldo1", volt18_voltages,
MT6359_RG_LDO_VM18_EN_ADDR, MT6359_RG_LDO_VM18_EN_SHIFT,
MT6359_DA_VM18_B_EN_ADDR, MT6359_RG_VM18_VOSEL_ADDR,
MT6359_RG_VM18_VOSEL_MASK << MT6359_RG_VM18_VOSEL_SHIFT,
1920),
- MT6359_LDO("ldo_vbbck", VBBCK, vbbck_voltages,
+ /* vbbck is fed from vio18 internally. */
+ MT6359_LDO("ldo_vbbck", VBBCK, "LDO_VIO18", vbbck_voltages,
MT6359_RG_LDO_VBBCK_EN_ADDR, MT6359_RG_LDO_VBBCK_EN_SHIFT,
MT6359_DA_VBBCK_B_EN_ADDR, MT6359_RG_VBBCK_VOSEL_ADDR,
MT6359_RG_VBBCK_VOSEL_MASK << MT6359_RG_VBBCK_VOSEL_SHIFT,
240),
- MT6359_LDO_LINEAR("ldo_vsram_proc1", VSRAM_PROC1, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_proc1", VSRAM_PROC1, "vs2-ldo1", 500000, 1293750, 6250,
MT6359_RG_LDO_VSRAM_PROC1_EN_ADDR,
MT6359_DA_VSRAM_PROC1_B_EN_ADDR,
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_SHIFT),
- MT6359_LDO("ldo_vsim2", VSIM2, vsim2_voltages,
+ MT6359_LDO("ldo_vsim2", VSIM2, "vsys-ldo2", vsim2_voltages,
MT6359_RG_LDO_VSIM2_EN_ADDR, MT6359_RG_LDO_VSIM2_EN_SHIFT,
MT6359_DA_VSIM2_B_EN_ADDR, MT6359_RG_VSIM2_VOSEL_ADDR,
MT6359_RG_VSIM2_VOSEL_MASK << MT6359_RG_VSIM2_VOSEL_SHIFT,
480),
- MT6359_LDO_LINEAR("ldo_vsram_others_sshub", VSRAM_OTHERS_SSHUB,
+ MT6359_LDO_LINEAR("ldo_vsram_others_sshub", VSRAM_OTHERS_SSHUB, "vs2-ldo1",
500000, 1293750, 6250,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_EN_ADDR,
MT6359_DA_VSRAM_OTHERS_B_EN_ADDR,
@@ -706,14 +714,14 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
};
static const struct mt6359_regulator_info mt6359p_regulators[] = {
- MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
+ MT6359_BUCK("buck_vs1", VS1, "vsys-vs1", 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
MT6359_RG_BUCK_VS1_VOSEL_MASK <<
MT6359_RG_BUCK_VS1_VOSEL_SHIFT,
MT6359_RG_BUCK_VS1_LP_ADDR, MT6359_RG_BUCK_VS1_LP_SHIFT,
MT6359_RG_VS1_FPWM_ADDR, MT6359_RG_VS1_FPWM_SHIFT),
- MT6359_BUCK("buck_vgpu11", VGPU11, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vgpu11", VGPU11, "vsys-vgpu11", 400000, 1193750, 6250,
MT6359_RG_BUCK_VGPU11_EN_ADDR,
MT6359_DA_VGPU11_EN_ADDR, MT6359P_RG_BUCK_VGPU11_VOSEL_ADDR,
MT6359_RG_BUCK_VGPU11_VOSEL_MASK <<
@@ -721,7 +729,7 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VGPU11_LP_ADDR,
MT6359_RG_BUCK_VGPU11_LP_SHIFT,
MT6359_RG_VGPU11_FCCM_ADDR, MT6359_RG_VGPU11_FCCM_SHIFT),
- MT6359_BUCK("buck_vmodem", VMODEM, 400000, 1100000, 6250,
+ MT6359_BUCK("buck_vmodem", VMODEM, "vsys-vmodem", 400000, 1100000, 6250,
MT6359_RG_BUCK_VMODEM_EN_ADDR,
MT6359_DA_VMODEM_EN_ADDR, MT6359_RG_BUCK_VMODEM_VOSEL_ADDR,
MT6359_RG_BUCK_VMODEM_VOSEL_MASK <<
@@ -729,35 +737,35 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VMODEM_LP_ADDR,
MT6359_RG_BUCK_VMODEM_LP_SHIFT,
MT6359_RG_VMODEM_FCCM_ADDR, MT6359_RG_VMODEM_FCCM_SHIFT),
- MT6359_BUCK("buck_vpu", VPU, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vpu", VPU, "vsys-vpu", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPU_EN_ADDR,
MT6359_DA_VPU_EN_ADDR, MT6359_RG_BUCK_VPU_VOSEL_ADDR,
MT6359_RG_BUCK_VPU_VOSEL_MASK <<
MT6359_RG_BUCK_VPU_VOSEL_SHIFT,
MT6359_RG_BUCK_VPU_LP_ADDR, MT6359_RG_BUCK_VPU_LP_SHIFT,
MT6359_RG_VPU_FCCM_ADDR, MT6359_RG_VPU_FCCM_SHIFT),
- MT6359_BUCK("buck_vcore", VCORE, 506250, 1300000, 6250,
+ MT6359_BUCK("buck_vcore", VCORE, "vsys-vcore", 506250, 1300000, 6250,
MT6359_RG_BUCK_VCORE_EN_ADDR,
MT6359_DA_VCORE_EN_ADDR, MT6359P_RG_BUCK_VCORE_VOSEL_ADDR,
MT6359_RG_BUCK_VCORE_VOSEL_MASK <<
MT6359_RG_BUCK_VCORE_VOSEL_SHIFT,
MT6359_RG_BUCK_VCORE_LP_ADDR, MT6359_RG_BUCK_VCORE_LP_SHIFT,
MT6359_RG_VCORE_FCCM_ADDR, MT6359_RG_VCORE_FCCM_SHIFT),
- MT6359_BUCK("buck_vs2", VS2, 800000, 1600000, 12500,
+ MT6359_BUCK("buck_vs2", VS2, "vsys-vs2", 800000, 1600000, 12500,
MT6359_RG_BUCK_VS2_EN_ADDR,
MT6359_DA_VS2_EN_ADDR, MT6359_RG_BUCK_VS2_VOSEL_ADDR,
MT6359_RG_BUCK_VS2_VOSEL_MASK <<
MT6359_RG_BUCK_VS2_VOSEL_SHIFT,
MT6359_RG_BUCK_VS2_LP_ADDR, MT6359_RG_BUCK_VS2_LP_SHIFT,
MT6359_RG_VS2_FPWM_ADDR, MT6359_RG_VS2_FPWM_SHIFT),
- MT6359_BUCK("buck_vpa", VPA, 500000, 3650000, 50000,
+ MT6359_BUCK("buck_vpa", VPA, "vsys-vpa", 500000, 3650000, 50000,
MT6359_RG_BUCK_VPA_EN_ADDR,
MT6359_DA_VPA_EN_ADDR, MT6359_RG_BUCK_VPA_VOSEL_ADDR,
MT6359_RG_BUCK_VPA_VOSEL_MASK <<
MT6359_RG_BUCK_VPA_VOSEL_SHIFT,
MT6359_RG_BUCK_VPA_LP_ADDR, MT6359_RG_BUCK_VPA_LP_SHIFT,
MT6359_RG_VPA_MODESET_ADDR, MT6359_RG_VPA_MODESET_SHIFT),
- MT6359_BUCK("buck_vproc2", VPROC2, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vproc2", VPROC2, "vsys-vproc2", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPROC2_EN_ADDR,
MT6359_DA_VPROC2_EN_ADDR, MT6359_RG_BUCK_VPROC2_VOSEL_ADDR,
MT6359_RG_BUCK_VPROC2_VOSEL_MASK <<
@@ -765,7 +773,7 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VPROC2_LP_ADDR,
MT6359_RG_BUCK_VPROC2_LP_SHIFT,
MT6359_RG_VPROC2_FCCM_ADDR, MT6359_RG_VPROC2_FCCM_SHIFT),
- MT6359_BUCK("buck_vproc1", VPROC1, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vproc1", VPROC1, "vsys-vproc1", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPROC1_EN_ADDR,
MT6359_DA_VPROC1_EN_ADDR, MT6359_RG_BUCK_VPROC1_VOSEL_ADDR,
MT6359_RG_BUCK_VPROC1_VOSEL_MASK <<
@@ -773,7 +781,7 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VPROC1_LP_ADDR,
MT6359_RG_BUCK_VPROC1_LP_SHIFT,
MT6359_RG_VPROC1_FCCM_ADDR, MT6359_RG_VPROC1_FCCM_SHIFT),
- MT6359_BUCK("buck_vgpu11_sshub", VGPU11_SSHUB, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vgpu11_sshub", VGPU11_SSHUB, "vsys-vgpu11", 400000, 1193750, 6250,
MT6359P_RG_BUCK_VGPU11_SSHUB_EN_ADDR,
MT6359_DA_VGPU11_EN_ADDR,
MT6359P_RG_BUCK_VGPU11_SSHUB_VOSEL_ADDR,
@@ -782,161 +790,161 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VGPU11_LP_ADDR,
MT6359_RG_BUCK_VGPU11_LP_SHIFT,
MT6359_RG_VGPU11_FCCM_ADDR, MT6359_RG_VGPU11_FCCM_SHIFT),
- MT6359_REG_FIXED("ldo_vaud18", VAUD18, MT6359P_RG_LDO_VAUD18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vaud18", VAUD18, "vs1-ldo1", MT6359P_RG_LDO_VAUD18_EN_ADDR,
MT6359P_DA_VAUD18_B_EN_ADDR, 1800000),
- MT6359_LDO("ldo_vsim1", VSIM1, vsim1_voltages,
+ MT6359_LDO("ldo_vsim1", VSIM1, "vsys-ldo2", vsim1_voltages,
MT6359P_RG_LDO_VSIM1_EN_ADDR, MT6359P_RG_LDO_VSIM1_EN_SHIFT,
MT6359P_DA_VSIM1_B_EN_ADDR, MT6359P_RG_VSIM1_VOSEL_ADDR,
MT6359_RG_VSIM1_VOSEL_MASK << MT6359_RG_VSIM1_VOSEL_SHIFT,
480),
- MT6359_LDO("ldo_vibr", VIBR, vibr_voltages,
+ MT6359_LDO("ldo_vibr", VIBR, "vsys-ldo1", vibr_voltages,
MT6359P_RG_LDO_VIBR_EN_ADDR, MT6359P_RG_LDO_VIBR_EN_SHIFT,
MT6359P_DA_VIBR_B_EN_ADDR, MT6359P_RG_VIBR_VOSEL_ADDR,
MT6359_RG_VIBR_VOSEL_MASK << MT6359_RG_VIBR_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vrf12", VRF12, vrf12_voltages,
+ MT6359_LDO("ldo_vrf12", VRF12, "vs2-ldo2", vrf12_voltages,
MT6359P_RG_LDO_VRF12_EN_ADDR, MT6359P_RG_LDO_VRF12_EN_SHIFT,
MT6359P_DA_VRF12_B_EN_ADDR, MT6359P_RG_VRF12_VOSEL_ADDR,
MT6359_RG_VRF12_VOSEL_MASK << MT6359_RG_VRF12_VOSEL_SHIFT,
480),
- MT6359_REG_FIXED("ldo_vusb", VUSB, MT6359P_RG_LDO_VUSB_EN_0_ADDR,
+ MT6359_REG_FIXED("ldo_vusb", VUSB, "vsys-ldo2", MT6359P_RG_LDO_VUSB_EN_0_ADDR,
MT6359P_DA_VUSB_B_EN_ADDR, 3000000),
- MT6359_LDO_LINEAR("ldo_vsram_proc2", VSRAM_PROC2, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_proc2", VSRAM_PROC2, "vs2-ldo1", 500000, 1293750, 6250,
MT6359P_RG_LDO_VSRAM_PROC2_EN_ADDR,
MT6359P_DA_VSRAM_PROC2_B_EN_ADDR,
MT6359P_RG_LDO_VSRAM_PROC2_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_SHIFT),
- MT6359_LDO("ldo_vio18", VIO18, volt18_voltages,
+ MT6359_LDO("ldo_vio18", VIO18, "vs1-ldo2", volt18_voltages,
MT6359P_RG_LDO_VIO18_EN_ADDR, MT6359P_RG_LDO_VIO18_EN_SHIFT,
MT6359P_DA_VIO18_B_EN_ADDR, MT6359P_RG_VIO18_VOSEL_ADDR,
MT6359_RG_VIO18_VOSEL_MASK << MT6359_RG_VIO18_VOSEL_SHIFT,
960),
- MT6359_LDO("ldo_vcamio", VCAMIO, volt18_voltages,
+ MT6359_LDO("ldo_vcamio", VCAMIO, "vs1-ldo1", volt18_voltages,
MT6359P_RG_LDO_VCAMIO_EN_ADDR,
MT6359P_RG_LDO_VCAMIO_EN_SHIFT,
MT6359P_DA_VCAMIO_B_EN_ADDR, MT6359P_RG_VCAMIO_VOSEL_ADDR,
MT6359_RG_VCAMIO_VOSEL_MASK << MT6359_RG_VCAMIO_VOSEL_SHIFT,
1290),
- MT6359_REG_FIXED("ldo_vcn18", VCN18, MT6359P_RG_LDO_VCN18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vcn18", VCN18, "vs1-ldo2", MT6359P_RG_LDO_VCN18_EN_ADDR,
MT6359P_DA_VCN18_B_EN_ADDR, 1800000),
- MT6359_REG_FIXED("ldo_vfe28", VFE28, MT6359P_RG_LDO_VFE28_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vfe28", VFE28, "vsys-ldo1", MT6359P_RG_LDO_VFE28_EN_ADDR,
MT6359P_DA_VFE28_B_EN_ADDR, 2800000),
- MT6359_LDO("ldo_vcn13", VCN13, vcn13_voltages,
+ MT6359_LDO("ldo_vcn13", VCN13, "vs2-ldo2", vcn13_voltages,
MT6359P_RG_LDO_VCN13_EN_ADDR, MT6359P_RG_LDO_VCN13_EN_SHIFT,
MT6359P_DA_VCN13_B_EN_ADDR, MT6359P_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT,
MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_REG_FIXED("ldo_vaux18", VAUX18, MT6359P_RG_LDO_VAUX18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359P_RG_LDO_VAUX18_EN_ADDR,
MT6359P_DA_VAUX18_B_EN_ADDR, 1800000),
- MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, 500000, 1293750,
+ MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
6250,
MT6359P_RG_LDO_VSRAM_OTHERS_EN_ADDR,
MT6359P_DA_VSRAM_OTHERS_B_EN_ADDR,
MT6359P_RG_LDO_VSRAM_OTHERS_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_SHIFT),
- MT6359_LDO("ldo_vefuse", VEFUSE, vefuse_voltages,
+ MT6359_LDO("ldo_vefuse", VEFUSE, "vs1-ldo2", vefuse_voltages,
MT6359P_RG_LDO_VEFUSE_EN_ADDR,
MT6359P_RG_LDO_VEFUSE_EN_SHIFT,
MT6359P_DA_VEFUSE_B_EN_ADDR, MT6359P_RG_VEFUSE_VOSEL_ADDR,
MT6359_RG_VEFUSE_VOSEL_MASK << MT6359_RG_VEFUSE_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vxo22", VXO22, vxo22_voltages,
+ MT6359_LDO("ldo_vxo22", VXO22, "vsys-ldo2", vxo22_voltages,
MT6359P_RG_LDO_VXO22_EN_ADDR, MT6359P_RG_LDO_VXO22_EN_SHIFT,
MT6359P_DA_VXO22_B_EN_ADDR, MT6359P_RG_VXO22_VOSEL_ADDR,
MT6359_RG_VXO22_VOSEL_MASK << MT6359_RG_VXO22_VOSEL_SHIFT,
480),
- MT6359_LDO("ldo_vrfck_1", VRFCK, vrfck_voltages_1,
+ MT6359_LDO("ldo_vrfck_1", VRFCK, "vsys-ldo2", vrfck_voltages_1,
MT6359P_RG_LDO_VRFCK_EN_ADDR, MT6359P_RG_LDO_VRFCK_EN_SHIFT,
MT6359P_DA_VRFCK_B_EN_ADDR, MT6359P_RG_VRFCK_VOSEL_ADDR,
MT6359_RG_VRFCK_VOSEL_MASK << MT6359_RG_VRFCK_VOSEL_SHIFT,
480),
- MT6359_REG_FIXED("ldo_vbif28", VBIF28, MT6359P_RG_LDO_VBIF28_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vbif28", VBIF28, "vsys-ldo2", MT6359P_RG_LDO_VBIF28_EN_ADDR,
MT6359P_DA_VBIF28_B_EN_ADDR, 2800000),
- MT6359_LDO("ldo_vio28", VIO28, vio28_voltages,
+ MT6359_LDO("ldo_vio28", VIO28, "vsys-ldo2", vio28_voltages,
MT6359P_RG_LDO_VIO28_EN_ADDR, MT6359P_RG_LDO_VIO28_EN_SHIFT,
MT6359P_DA_VIO28_B_EN_ADDR, MT6359P_RG_VIO28_VOSEL_ADDR,
MT6359_RG_VIO28_VOSEL_MASK << MT6359_RG_VIO28_VOSEL_SHIFT,
1920),
- MT6359P_LDO1("ldo_vemc_1", VEMC, mt6359p_vemc_ops, vemc_voltages_1,
+ MT6359P_LDO1("ldo_vemc_1", VEMC, "vsys-ldo2", mt6359p_vemc_ops, vemc_voltages_1,
MT6359P_RG_LDO_VEMC_EN_ADDR, MT6359P_RG_LDO_VEMC_EN_SHIFT,
MT6359P_DA_VEMC_B_EN_ADDR,
MT6359P_RG_LDO_VEMC_VOSEL_0_ADDR,
MT6359P_RG_LDO_VEMC_VOSEL_0_MASK <<
MT6359P_RG_LDO_VEMC_VOSEL_0_SHIFT),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_va12", VA12, va12_voltages,
+ MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359P_RG_LDO_VA12_EN_ADDR, MT6359P_RG_LDO_VA12_EN_SHIFT,
MT6359P_DA_VA12_B_EN_ADDR, MT6359P_RG_VA12_VOSEL_ADDR,
MT6359_RG_VA12_VOSEL_MASK << MT6359_RG_VA12_VOSEL_SHIFT,
960),
- MT6359_LDO("ldo_va09", VA09, va09_voltages,
+ MT6359_LDO("ldo_va09", VA09, "vs2-ldo2", va09_voltages,
MT6359P_RG_LDO_VA09_EN_ADDR, MT6359P_RG_LDO_VA09_EN_SHIFT,
MT6359P_DA_VA09_B_EN_ADDR, MT6359P_RG_VA09_VOSEL_ADDR,
MT6359_RG_VA09_VOSEL_MASK << MT6359_RG_VA09_VOSEL_SHIFT,
960),
- MT6359_LDO("ldo_vrf18", VRF18, vrf18_voltages,
+ MT6359_LDO("ldo_vrf18", VRF18, "vs1-ldo2", vrf18_voltages,
MT6359P_RG_LDO_VRF18_EN_ADDR, MT6359P_RG_LDO_VRF18_EN_SHIFT,
MT6359P_DA_VRF18_B_EN_ADDR, MT6359P_RG_VRF18_VOSEL_ADDR,
MT6359_RG_VRF18_VOSEL_MASK << MT6359_RG_VRF18_VOSEL_SHIFT,
240),
- MT6359_LDO_LINEAR("ldo_vsram_md", VSRAM_MD, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_md", VSRAM_MD, "vs2-ldo1", 500000, 1293750, 6250,
MT6359P_RG_LDO_VSRAM_MD_EN_ADDR,
MT6359P_DA_VSRAM_MD_B_EN_ADDR,
MT6359P_RG_LDO_VSRAM_MD_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_MD_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_MD_VOSEL_SHIFT),
- MT6359_LDO("ldo_vufs", VUFS, volt18_voltages,
+ MT6359_LDO("ldo_vufs", VUFS, "vs1-ldo1", volt18_voltages,
MT6359P_RG_LDO_VUFS_EN_ADDR, MT6359P_RG_LDO_VUFS_EN_SHIFT,
MT6359P_DA_VUFS_B_EN_ADDR, MT6359P_RG_VUFS_VOSEL_ADDR,
MT6359_RG_VUFS_VOSEL_MASK << MT6359_RG_VUFS_VOSEL_SHIFT,
1920),
- MT6359_LDO("ldo_vm18", VM18, volt18_voltages,
+ MT6359_LDO("ldo_vm18", VM18, "vs1-ldo1", volt18_voltages,
MT6359P_RG_LDO_VM18_EN_ADDR, MT6359P_RG_LDO_VM18_EN_SHIFT,
MT6359P_DA_VM18_B_EN_ADDR, MT6359P_RG_VM18_VOSEL_ADDR,
MT6359_RG_VM18_VOSEL_MASK << MT6359_RG_VM18_VOSEL_SHIFT,
1920),
- MT6359_LDO("ldo_vbbck", VBBCK, vbbck_voltages,
+ MT6359_LDO("ldo_vbbck", VBBCK, "LDO_VIO18", vbbck_voltages,
MT6359P_RG_LDO_VBBCK_EN_ADDR, MT6359P_RG_LDO_VBBCK_EN_SHIFT,
MT6359P_DA_VBBCK_B_EN_ADDR, MT6359P_RG_VBBCK_VOSEL_ADDR,
MT6359P_RG_VBBCK_VOSEL_MASK << MT6359P_RG_VBBCK_VOSEL_SHIFT,
480),
- MT6359_LDO_LINEAR("ldo_vsram_proc1", VSRAM_PROC1, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_proc1", VSRAM_PROC1, "vs2-ldo1", 500000, 1293750, 6250,
MT6359P_RG_LDO_VSRAM_PROC1_EN_ADDR,
MT6359P_DA_VSRAM_PROC1_B_EN_ADDR,
MT6359P_RG_LDO_VSRAM_PROC1_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_SHIFT),
- MT6359_LDO("ldo_vsim2", VSIM2, vsim2_voltages,
+ MT6359_LDO("ldo_vsim2", VSIM2, "vsys-ldo2", vsim2_voltages,
MT6359P_RG_LDO_VSIM2_EN_ADDR, MT6359P_RG_LDO_VSIM2_EN_SHIFT,
MT6359P_DA_VSIM2_B_EN_ADDR, MT6359P_RG_VSIM2_VOSEL_ADDR,
MT6359_RG_VSIM2_VOSEL_MASK << MT6359_RG_VSIM2_VOSEL_SHIFT,
480),
- MT6359_LDO_LINEAR("ldo_vsram_others_sshub", VSRAM_OTHERS_SSHUB,
+ MT6359_LDO_LINEAR("ldo_vsram_others_sshub", VSRAM_OTHERS_SSHUB, "vs2-ldo1",
500000, 1293750, 6250,
MT6359P_RG_LDO_VSRAM_OTHERS_SSHUB_EN_ADDR,
MT6359P_DA_VSRAM_OTHERS_B_EN_ADDR,
@@ -951,6 +959,7 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
struct regulator_config config = {};
struct regulator_dev *rdev;
const struct mt6359_regulator_info *mt6359_info;
+ const char *vio18_name;
int i, hw_ver, ret;
ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
@@ -962,16 +971,37 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
else
mt6359_info = mt6359_regulators;
+ vio18_name = mt6359_info[MT6359_ID_VIO18].desc.name;
+
config.dev = mt6397->dev;
config.regmap = mt6397->regmap;
for (i = 0; i < MT6359_MAX_REGULATOR; i++, mt6359_info++) {
+ const struct regulator_desc *desc = &mt6359_info->desc;
+ struct regulator_desc *_desc;
+
/* drop const here, but all uses in the driver are const */
config.driver_data = (void *)mt6359_info;
- rdev = devm_regulator_register(&pdev->dev, &mt6359_info->desc, &config);
+
+ /* Use vio18's actual name as supply_name for vbbck */
+ if (i == MT6359_ID_VBBCK && strcmp(desc->supply_name, vio18_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vio18_name;
+ desc = _desc;
+ }
+
+ rdev = devm_regulator_register(&pdev->dev, desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "failed to register %s\n", mt6359_info->desc.name);
return PTR_ERR(rdev);
}
+
+ /* Save vio18 name for vbbck */
+ if (i == MT6359_ID_VIO18)
+ vio18_name = rdev_get_name(rdev);
}
return 0;
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v2 6/6] regulator: mt6359: Add proper ldo_vcn33_[12] regulators
From: Chen-Yu Tsai @ 2026-04-29 7:41 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260429074113.3720271-1-wenst@chromium.org>
The ldo_vcn33_[12]_wifi and ldo_vcn33_[12]_bt are just two regulator
outputs instead of four. The wifi and bt parts refer to separate enable
bits that are OR-ed together to affect the actual regulator output. The
separate bits allow the wifi and bt stacks to enable their power without
coordination between them. These have been deprecated in favor of proper
nodes matching the output.
Add proper ldo_vcn33_[12] regulators to replace the existing ones. The
enable status is synced to just one of the two enable bits, and the
other is forced off. This makes the handling in other bits simpler.
The existing *_(bt|wifi) regulators are converted to no-op regulators
that are fed from their new respective ldo_vcn33_[12] regulator. This
allows existing device trees to continue to work.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- Instead of dropping one regulator from each output, add a new one for
each output; the existing *_(bt|wifi) ones are then supplied from the
new one
---
drivers/regulator/mt6359-regulator.c | 179 +++++++++++++++++----
include/linux/regulator/mt6359-regulator.h | 10 +-
2 files changed, 154 insertions(+), 35 deletions(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index fa97c3189df5..cd489adf9a2a 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -166,6 +166,20 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
+#define MT6359_LDO_NOOP(match, _name, supply) \
+[MT6359_ID_##_name] = { \
+ .desc = { \
+ .name = #_name, \
+ .supply_name = supply, \
+ .of_match = of_match_ptr(match), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .ops = &mt6359_noop_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6359_ID_##_name, \
+ .owner = THIS_MODULE, \
+ }, \
+}
+
static const unsigned int vsim1_voltages[] = {
0, 0, 0, 1700000, 1800000, 0, 0, 0, 2700000, 0, 0, 3000000, 3100000,
};
@@ -475,6 +489,9 @@ static const struct regulator_ops mt6359p_vemc_ops = {
.get_status = mt6359_get_status,
};
+/* Used for backward-compatible placeholder regulators */
+static const struct regulator_ops mt6359_noop_ops = {};
+
/* The array is indexed by id(MT6359_ID_XXX) */
static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, "vsys-vs1", 800000, 2200000, 12500,
@@ -596,18 +613,12 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_DA_VCN13_B_EN_ADDR, MT6359_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1", VCN33_1, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_1_EN_1_SHIFT,
- MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
- MT6359_RG_VCN33_1_VOSEL_MASK <<
- MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359_RG_LDO_VAUX18_EN_ADDR,
MT6359_DA_VAUX18_B_EN_ADDR, 1800000),
MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
@@ -644,18 +655,12 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_DA_VEMC_B_EN_ADDR, MT6359_RG_VEMC_VOSEL_ADDR,
MT6359_RG_VEMC_VOSEL_MASK << MT6359_RG_VEMC_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2", VCN33_2, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
- MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
- MT6359_RG_VCN33_2_VOSEL_MASK <<
- MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359_RG_LDO_VA12_EN_ADDR, MT6359_RG_LDO_VA12_EN_SHIFT,
MT6359_DA_VA12_B_EN_ADDR, MT6359_RG_VA12_VOSEL_ADDR,
@@ -711,6 +716,11 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
+ /* Placeholders for DT backward compatibility */
+ MT6359_LDO_NOOP("ldo_vcn33_1_bt", VCN33_1_BT, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_1_wifi", VCN33_1_WIFI, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_bt", VCN33_2_BT, "LDO_VCN33_2"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_wifi", VCN33_2_WIFI, "LDO_VCN33_2"),
};
static const struct mt6359_regulator_info mt6359p_regulators[] = {
@@ -835,18 +845,12 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_DA_VCN13_B_EN_ADDR, MT6359P_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1", VCN33_1, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
- MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT,
- MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
- MT6359_RG_VCN33_1_VOSEL_MASK <<
- MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359P_RG_LDO_VAUX18_EN_ADDR,
MT6359P_DA_VAUX18_B_EN_ADDR, 1800000),
MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
@@ -885,18 +889,12 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_RG_LDO_VEMC_VOSEL_0_ADDR,
MT6359P_RG_LDO_VEMC_VOSEL_0_MASK <<
MT6359P_RG_LDO_VEMC_VOSEL_0_SHIFT),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2", VCN33_2, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
- MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
- MT6359_RG_VCN33_2_VOSEL_MASK <<
- MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359P_RG_LDO_VA12_EN_ADDR, MT6359P_RG_LDO_VA12_EN_SHIFT,
MT6359P_DA_VA12_B_EN_ADDR, MT6359P_RG_VA12_VOSEL_ADDR,
@@ -951,27 +949,114 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
+ /* Placeholders for DT backward compatibility */
+ MT6359_LDO_NOOP("ldo_vcn33_1_bt", VCN33_1_BT, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_1_wifi", VCN33_1_WIFI, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_bt", VCN33_2_BT, "LDO_VCN33_2"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_wifi", VCN33_2_WIFI, "LDO_VCN33_2"),
+};
+
+struct mt6359_vcn33_regs {
+ u32 wifi_en_reg;
+ u32 wifi_en_mask;
+ u32 bt_en_reg;
+ u32 bt_en_mask;
+};
+
+static const struct mt6359_vcn33_regs vcn33_regs[][2] = {
+ { /* MT6359 */
+ {
+ .wifi_en_reg = MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_1_SHIFT),
+ .bt_en_reg = MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_0_SHIFT),
+ }, {
+ .wifi_en_reg = MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_1_SHIFT),
+ .bt_en_reg = MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_0_SHIFT),
+ }
+ }, { /* MT6359P */
+ {
+ .wifi_en_reg = MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT),
+ .bt_en_reg = MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_0_SHIFT),
+ }, {
+ .wifi_en_reg = MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_1_SHIFT),
+ .bt_en_reg = MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT),
+ }
+ }
};
+static int mt6359_sync_vcn33_setting(struct device *dev, unsigned int idx)
+{
+ struct mt6397_chip *mt6397 = dev_get_drvdata(dev->parent);
+ unsigned int val;
+ int ret;
+
+ /*
+ * VCN33_[12]_WIFI and VCN33_[12]_BT are two separate enable bits for
+ * the same regulator. They share the same voltage setting and output
+ * pin. Instead of having two potentially conflicting regulators, just
+ * have one regulator. Sync the two enable bits and only use one in
+ * the regulator device.
+ */
+ for (unsigned int i = 0; i < ARRAY_SIZE(vcn33_regs[0]); i++) {
+ u32 bt_en_mask = vcn33_regs[idx][i].bt_en_mask;
+ u32 wifi_en_mask = vcn33_regs[idx][i].wifi_en_mask;
+
+ ret = regmap_read(mt6397->regmap, vcn33_regs[idx][i].wifi_en_reg, &val);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to read VCN33_%u_WIFI setting\n", i);
+
+ if (!(val & wifi_en_mask))
+ continue;
+
+ /* Sync VCN33_[12]_WIFI enable status to VCN33_[12]_BT */
+ ret = regmap_update_bits(mt6397->regmap, vcn33_regs[idx][i].bt_en_reg,
+ bt_en_mask, bt_en_mask);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to sync VCN33_%u_WIFI setting to VCN33_%u_BT\n",
+ i, i);
+
+ /* Disable VCN33_[12]_WIFI */
+ ret = regmap_update_bits(mt6397->regmap, vcn33_regs[idx][i].wifi_en_reg,
+ wifi_en_mask, 0);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to disable VCN33_%u_WIFI\n", i);
+ }
+
+ return 0;
+}
+
static int mt6359_regulator_probe(struct platform_device *pdev)
{
struct mt6397_chip *mt6397 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = {};
struct regulator_dev *rdev;
const struct mt6359_regulator_info *mt6359_info;
- const char *vio18_name;
+ const char *vio18_name, *vcn33_1_name, *vcn33_2_name;
int i, hw_ver, ret;
ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
if (ret)
return ret;
- if (hw_ver >= MT6359P_CHIP_VER)
+ if (hw_ver >= MT6359P_CHIP_VER) {
mt6359_info = mt6359p_regulators;
- else
+ mt6359_sync_vcn33_setting(&pdev->dev, 1);
+ } else {
mt6359_info = mt6359_regulators;
+ mt6359_sync_vcn33_setting(&pdev->dev, 0);
+ }
vio18_name = mt6359_info[MT6359_ID_VIO18].desc.name;
+ vcn33_1_name = mt6359_info[MT6359_ID_VCN33_1].desc.name;
+ vcn33_2_name = mt6359_info[MT6359_ID_VCN33_2].desc.name;
config.dev = mt6397->dev;
config.regmap = mt6397->regmap;
@@ -993,6 +1078,30 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
desc = _desc;
}
+ /* Use vcn33_1's actual name as supply_name for vcn33_1_(bt|wifi) */
+ if ((i == MT6359_ID_VCN33_1_BT || i == MT6359_ID_VCN33_1_WIFI) &&
+ strcmp(desc->supply_name, vcn33_1_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vcn33_1_name;
+ desc = _desc;
+ }
+
+ /* Use vcn33_2's actual name as supply_name for vcn33_2_(bt|wifi) */
+ if ((i == MT6359_ID_VCN33_2_BT || i == MT6359_ID_VCN33_2_WIFI) &&
+ strcmp(desc->supply_name, vcn33_2_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vcn33_2_name;
+ desc = _desc;
+ }
+
rdev = devm_regulator_register(&pdev->dev, desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "failed to register %s\n", mt6359_info->desc.name);
@@ -1002,6 +1111,14 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
/* Save vio18 name for vbbck */
if (i == MT6359_ID_VIO18)
vio18_name = rdev_get_name(rdev);
+
+ /* Save vcn33_1 name for vbbck */
+ if (i == MT6359_ID_VCN33_1)
+ vcn33_1_name = rdev_get_name(rdev);
+
+ /* Save vcn33_2 name for vbbck */
+ if (i == MT6359_ID_VCN33_2)
+ vcn33_2_name = rdev_get_name(rdev);
}
return 0;
diff --git a/include/linux/regulator/mt6359-regulator.h b/include/linux/regulator/mt6359-regulator.h
index 6d6e5a58f482..ce2cd0fc9d95 100644
--- a/include/linux/regulator/mt6359-regulator.h
+++ b/include/linux/regulator/mt6359-regulator.h
@@ -29,8 +29,7 @@ enum {
MT6359_ID_VCN18,
MT6359_ID_VFE28,
MT6359_ID_VCN13,
- MT6359_ID_VCN33_1_BT,
- MT6359_ID_VCN33_1_WIFI,
+ MT6359_ID_VCN33_1,
MT6359_ID_VAUX18,
MT6359_ID_VSRAM_OTHERS,
MT6359_ID_VEFUSE,
@@ -39,8 +38,7 @@ enum {
MT6359_ID_VBIF28,
MT6359_ID_VIO28,
MT6359_ID_VEMC,
- MT6359_ID_VCN33_2_BT,
- MT6359_ID_VCN33_2_WIFI,
+ MT6359_ID_VCN33_2,
MT6359_ID_VA12,
MT6359_ID_VA09,
MT6359_ID_VRF18,
@@ -51,6 +49,10 @@ enum {
MT6359_ID_VSRAM_PROC1,
MT6359_ID_VSIM2,
MT6359_ID_VSRAM_OTHERS_SSHUB,
+ MT6359_ID_VCN33_1_BT,
+ MT6359_ID_VCN33_1_WIFI,
+ MT6359_ID_VCN33_2_BT,
+ MT6359_ID_VCN33_2_WIFI,
MT6359_ID_RG_MAX,
};
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox