* Re: [PATCH 1/1] arm64: dts: rockchip: disable analog audio for rock-5b
From: Pratham Patel @ 2024-03-24 11:43 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh, krzysztof.kozlowski+dt, conor+dt, heiko, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <TbQeSy-AWAKVHo2Alb8hXUvplVNvohDJ2ztRM1x3Fo5PMmGLMsJxtHR-OIms9FlUshfUD9x45EghBCB9gVtcUPlxeMRUJQ_C95DVhu3AJrk=@thefossguy.com>
On Sunday, March 24th, 2024 at 16:51, Pratham Patel <prathampatel@thefossguy.com> wrote:
> On Sunday, March 24th, 2024 at 16:15, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
>
> > > + /*
> > > + *analog-sound {
> > > + * compatible = "audio-graph-card";
> > > + * label = "rk3588-es8316";
> >
> > Do not comment out code. Instead disable the nodes and provide
> > appropriate comment describing reason.
>
> I tried changing the status from okay to disabled. That didn't work. The SBC
> still locked up during boot.
I think setting the status to fail should do the trick, instead of setting it to disabled.
Will try that and be back with a v2.
-- Pratham Patel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: Fix the i2c address of es8316 on Cool Pi CM5
From: Andy Yan @ 2024-03-24 11:28 UTC (permalink / raw)
To: heiko
Cc: krzysztof.kozlowski+dt, devicetree, dsimic, conor+dt,
linux-arm-kernel, linux-kernel, linux-rockchip, Andy Yan
According to the hardware design, the i2c address of audio codec es8316
on Cool Pi CM5 is 0x10.
This fix the read/write error like bellow:
es8316 7-0011: ASoC: error at soc_component_write_no_lock on es8316.7-0011 for register: [0x0000000c] -6
es8316 7-0011: ASoC: error at soc_component_write_no_lock on es8316.7-0011 for register: [0x00000003] -6
es8316 7-0011: ASoC: error at soc_component_read_no_lock on es8316.7-0011 for register: [0x00000016] -6
es8316 7-0011: ASoC: error at soc_component_read_no_lock on es8316.7-0011 for register: [0x00000016] -6
Fixes: 791c154c3982 ("arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5 EVB")
Signed-off-by: Andy Yan <andyshrk@163.com>
---
arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi
index cce1c8e83587..ea8de76b9214 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi
@@ -218,7 +218,7 @@ &i2c7 {
es8316: audio-codec@11 {
compatible = "everest,es8316";
- reg = <0x11>;
+ reg = <0x10>;
assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
assigned-clock-rates = <12288000>;
clocks = <&cru I2S0_8CH_MCLKOUT>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v1] staging: media: remove duplicates
From: Philipp Hortmann @ 2024-03-24 12:06 UTC (permalink / raw)
To: coolrrsh, slongerbeam, p.zabel, mchehab, gregkh, shawnguo,
s.hauer, kernel, festevam, linux-imx, linux-media, linux-staging,
linux-arm-kernel, linux-kernel
Cc: linux-kernel-mentees
In-Reply-To: <20240324092917.19177-1-coolrrsh@gmail.com>
On 3/24/24 10:29, coolrrsh@gmail.com wrote:
Hi Rajeshwar,
Please make your "Subject" line more unique. Consider that we may end up
with having dozen of commits like yours, all of them referring to
different removals and all without the necessary information to tell
what they differ in (except the driver/subsystem). So it would help if
you add the changed file to make it more unique.
Typically we omit the v1 on the first patch in the subject
> From: Rajeshwar R Shinde <coolrrsh@gmail.com>
This line does not belong here. Please remove it.
>
> In Kconfig, the kernel configuration VIDEO_DEV is defined twice.
> To prevent doing repeated checks, the redundant code was replaced.
replaced?
If you send in a second version of this patch please use a change
history. Description from Dan under:
https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/
Thanks for your support.
Bye Philipp
> Signed-off-by: Rajeshwar R Shinde <coolrrsh@gmail.com>
>
> ---
> drivers/staging/media/imx/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig
> index 21fd79515042..772f49b1fe52 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -4,7 +4,6 @@ config VIDEO_IMX_MEDIA
> depends on ARCH_MXC || COMPILE_TEST
> depends on HAS_DMA
> depends on VIDEO_DEV
> - depends on VIDEO_DEV
> select MEDIA_CONTROLLER
> select V4L2_FWNODE
> select V4L2_MEM2MEM_DEV
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: rockchip: disable analog audio for rock-5b
From: Linux regression tracking (Thorsten Leemhuis) @ 2024-03-24 12:14 UTC (permalink / raw)
To: Pratham Patel, Krzysztof Kozlowski
Cc: robh, krzysztof.kozlowski+dt, conor+dt, heiko, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <XJ_dGL-0X07dJ8GOKvrXbRD2FAHN1A7keAtohcSaU41DEF0FbeWwswLEqkrYiwwulyXDwJ6SZHfWukhHO3t3tOWX7ZGM7ya9lwXfn8Xh1nU=@thefossguy.com>
On 24.03.24 12:43, Pratham Patel wrote:
> On Sunday, March 24th, 2024 at 16:51, Pratham Patel <prathampatel@thefossguy.com> wrote:
>
>> On Sunday, March 24th, 2024 at 16:15, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
>>
>>>> + /*
>>>> + *analog-sound {
>>>> + * compatible = "audio-graph-card";
>>>> + * label = "rk3588-es8316";
>>>
>>> Do not comment out code. Instead disable the nodes and provide
>>> appropriate comment describing reason.
>>
>> I tried changing the status from okay to disabled. That didn't work. The SBC
>> still locked up during boot.
>
> I think setting the status to fail should do the trick, instead of setting it to disabled.
> Will try that and be back with a v2.
Please CC the author of the change that broke things when submitting v2,
which you afaics failed to do in this thread.
Ciao, Thorsten
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v5 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Peng Fan @ 2024-03-24 12:15 UTC (permalink / raw)
To: Dan Carpenter, Peng Fan (OSS)
Cc: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Oleksii Moisieiev, Linus Walleij, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
dl-linux-imx, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, AKASHI Takahiro
In-Reply-To: <b06ab1e3-c00a-444c-908f-0ac8ad4d95fc@moroto.mountain>
Hi Dan,
> Subject: Re: [PATCH v5 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol
> protocol basic support
>
> On Thu, Mar 21, 2024 at 05:46:53PM +0300, Dan Carpenter wrote:
> > On Thu, Mar 14, 2024 at 09:35:20PM +0800, Peng Fan (OSS) wrote:
> > > +enum scmi_pinctrl_protocol_cmd {
> > > + PINCTRL_ATTRIBUTES = 0x3,
> > > + PINCTRL_LIST_ASSOCIATIONS = 0x4,
> > > + PINCTRL_CONFIG_GET = 0x5,
> > > + PINCTRL_CONFIG_SET = 0x6,
> > > + PINCTRL_FUNCTION_SELECT = 0x7,
> >
> > PINCTRL_FUNCTION_SELECT was removed from the spec so the other cmds
> > were renumbered. I'm still going through and reviewing this file.
> > I'll hopefully be done tomorrow.
> >
>
> I think the rest is okay. It's just updating to the new version of the spec.
> CONFIG_GET/SET need to be updated and FUNCTION_SELECT gets deleted.
V6 has this updated. Thanks for helping reviewing this patchset.
Thanks,
Peng.
>
> regards,
> dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: rockchip: disable analog audio for rock-5b
From: Pratham Patel @ 2024-03-24 12:19 UTC (permalink / raw)
To: Linux regressions mailing list
Cc: Krzysztof Kozlowski, robh, krzysztof.kozlowski+dt, conor+dt,
heiko, devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <db6ae45b-ff34-433f-8a31-1547423768ce@leemhuis.info>
On Sunday, March 24th, 2024 at 17:44, Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info> wrote:
>
>
> On 24.03.24 12:43, Pratham Patel wrote:
>
> > On Sunday, March 24th, 2024 at 16:51, Pratham Patel prathampatel@thefossguy.com wrote:
> >
> > > On Sunday, March 24th, 2024 at 16:15, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
> > >
> > > > > + /*
> > > > > + *analog-sound {
> > > > > + * compatible = "audio-graph-card";
> > > > > + * label = "rk3588-es8316";
> > > >
> > > > Do not comment out code. Instead disable the nodes and provide
> > > > appropriate comment describing reason.
> > >
> > > I tried changing the status from okay to disabled. That didn't work. The SBC
> > > still locked up during boot.
> >
> > I think setting the status to fail should do the trick, instead of setting it to disabled.
> > Will try that and be back with a v2.
>
>
> Please CC the author of the change that broke things when submitting v2,
> which you afaics failed to do in this thread.
>
> Ciao, Thorsten
Ack, will do.
-- Pratham Patel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] iommu/smmu-v3: support suspend/resume
From: Peng Fan (OSS) @ 2024-03-24 12:28 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Thomas Gleixner,
Marc Zyngier
Cc: Bixuan Cui, linux-arm-kernel, iommu, linux-kernel, Peng Fan
This patchset takes [1] for reference.
Patchset was tested on NXP i.MX95, but since i.MX95 not has SMMU MSI,
so not able to test MSI part. If anyone could help test, that would be
great.
[1]:
https://lore.kernel.org/lkml/20210721013350.17664-1-cuibixuan@huawei.com/T/#m06bf92e2306ba52c106f2d4d24765921d4e9781e
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
iommu/arm-smmu-v3: save bypass in smmu device structure
genirq/msi: cache the last msi msg
iommu/arm-smmu-v3: support suspend/resume
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 76 +++++++++++++++++++++++++----
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
kernel/irq/msi.c | 3 ++
3 files changed, 70 insertions(+), 10 deletions(-)
---
base-commit: 13ee4a7161b6fd938aef6688ff43b163f6d83e37
change-id: 20240324-smmu-v3-7fd1a43ed735
Best regards,
--
Peng Fan <peng.fan@nxp.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] iommu/arm-smmu-v3: save bypass in smmu device structure
From: Peng Fan (OSS) @ 2024-03-24 12:28 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Thomas Gleixner,
Marc Zyngier
Cc: Bixuan Cui, linux-arm-kernel, iommu, linux-kernel, Peng Fan
In-Reply-To: <20240324-smmu-v3-v1-0-11bc96e156a5@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
'bypass' will be used in smmu resume function, so need to save
its value for future usage.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 9 ++++-----
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 5ed036225e69..a8a569573c2f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -3494,7 +3494,7 @@ static int arm_smmu_device_disable(struct arm_smmu_device *smmu)
return ret;
}
-static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)
+static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
{
int ret;
u32 reg, enables;
@@ -3612,7 +3612,7 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)
enables &= ~(CR0_EVTQEN | CR0_PRIQEN);
/* Enable the SMMU interface, or ensure bypass */
- if (!bypass || disable_bypass) {
+ if (!smmu->bypass || disable_bypass) {
enables |= CR0_SMMUEN;
} else {
ret = arm_smmu_update_gbpa(smmu, 0, GBPA_ABORT);
@@ -4007,7 +4007,6 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
resource_size_t ioaddr;
struct arm_smmu_device *smmu;
struct device *dev = &pdev->dev;
- bool bypass;
smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
if (!smmu)
@@ -4023,7 +4022,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
}
/* Set bypass mode according to firmware probing result */
- bypass = !!ret;
+ smmu->bypass = !!ret;
/* Base address */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -4087,7 +4086,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
arm_smmu_rmr_install_bypass_ste(smmu);
/* Reset the device */
- ret = arm_smmu_device_reset(smmu, bypass);
+ ret = arm_smmu_device_reset(smmu);
if (ret)
return ret;
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 23baf117e7e4..97064a6aa87c 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -683,6 +683,7 @@ struct arm_smmu_device {
struct rb_root streams;
struct mutex streams_mutex;
+ bool bypass;
};
struct arm_smmu_stream {
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] genirq/msi: cache the last msi msg
From: Peng Fan (OSS) @ 2024-03-24 12:28 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Thomas Gleixner,
Marc Zyngier
Cc: Bixuan Cui, linux-arm-kernel, iommu, linux-kernel, Peng Fan
In-Reply-To: <20240324-smmu-v3-v1-0-11bc96e156a5@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Cache the last msi msg which will be used for ARM SMMU V3 resume
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
kernel/irq/msi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index f90952ebc494..9d7e0a675089 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -617,6 +617,9 @@ static unsigned int msi_domain_get_hwsize(struct device *dev, unsigned int domid
static inline void irq_chip_write_msi_msg(struct irq_data *data,
struct msi_msg *msg)
{
+ struct msi_desc *desc = irq_data_get_msi_desc(data);
+
+ desc->msg = *msg;
data->chip->irq_write_msi_msg(data, msg);
}
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] iommu/arm-smmu-v3: support suspend/resume
From: Peng Fan (OSS) @ 2024-03-24 12:29 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Thomas Gleixner,
Marc Zyngier
Cc: Bixuan Cui, linux-arm-kernel, iommu, linux-kernel, Peng Fan
In-Reply-To: <20240324-smmu-v3-v1-0-11bc96e156a5@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
smmu maybe power-gated, and the registers are cleared. So
need to restore its registers with arm_smmu_device_reset and
resume the msi interrupt settings in resume callback.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 71 ++++++++++++++++++++++++++---
1 file changed, 64 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index a8a569573c2f..2bfe4b3d0ba1 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -3396,6 +3396,36 @@ static void arm_smmu_setup_msis(struct arm_smmu_device *smmu)
devm_add_action(dev, arm_smmu_free_msis, dev);
}
+static void arm_smmu_resume_unique_irqs(struct arm_smmu_device *smmu)
+{
+ struct device *dev = smmu->dev;
+ struct msi_desc *desc;
+ struct msi_msg msg;
+
+ if (!dev->msi.domain)
+ return;
+
+ desc = irq_get_msi_desc(smmu->evtq.q.irq);
+ if (desc) {
+ get_cached_msi_msg(smmu->evtq.q.irq, &msg);
+ arm_smmu_write_msi_msg(desc, &msg);
+ }
+
+ desc = irq_get_msi_desc(smmu->gerr_irq);
+ if (desc) {
+ get_cached_msi_msg(smmu->gerr_irq, &msg);
+ arm_smmu_write_msi_msg(desc, &msg);
+ }
+
+ if (smmu->features & ARM_SMMU_FEAT_PRI) {
+ desc = irq_get_msi_desc(smmu->priq.q.irq);
+ if (desc) {
+ get_cached_msi_msg(smmu->priq.q.irq, &msg);
+ arm_smmu_write_msi_msg(desc, &msg);
+ }
+ }
+}
+
static void arm_smmu_setup_unique_irqs(struct arm_smmu_device *smmu)
{
int irq, ret;
@@ -3442,7 +3472,7 @@ static void arm_smmu_setup_unique_irqs(struct arm_smmu_device *smmu)
}
}
-static int arm_smmu_setup_irqs(struct arm_smmu_device *smmu)
+static int arm_smmu_setup_irqs(struct arm_smmu_device *smmu, bool resume)
{
int ret, irq;
u32 irqen_flags = IRQ_CTRL_EVTQ_IRQEN | IRQ_CTRL_GERROR_IRQEN;
@@ -3456,7 +3486,7 @@ static int arm_smmu_setup_irqs(struct arm_smmu_device *smmu)
}
irq = smmu->combined_irq;
- if (irq) {
+ if (irq && !resume) {
/*
* Cavium ThunderX2 implementation doesn't support unique irq
* lines. Use a single irq line for all the SMMUv3 interrupts.
@@ -3468,8 +3498,12 @@ static int arm_smmu_setup_irqs(struct arm_smmu_device *smmu)
"arm-smmu-v3-combined-irq", smmu);
if (ret < 0)
dev_warn(smmu->dev, "failed to enable combined irq\n");
- } else
- arm_smmu_setup_unique_irqs(smmu);
+ } else {
+ if (resume)
+ arm_smmu_resume_unique_irqs(smmu);
+ else
+ arm_smmu_setup_unique_irqs(smmu);
+ }
if (smmu->features & ARM_SMMU_FEAT_PRI)
irqen_flags |= IRQ_CTRL_PRIQ_IRQEN;
@@ -3494,7 +3528,7 @@ static int arm_smmu_device_disable(struct arm_smmu_device *smmu)
return ret;
}
-static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
+static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool resume)
{
int ret;
u32 reg, enables;
@@ -3602,7 +3636,7 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
}
}
- ret = arm_smmu_setup_irqs(smmu);
+ ret = arm_smmu_setup_irqs(smmu, resume);
if (ret) {
dev_err(smmu->dev, "failed to setup irqs\n");
return ret;
@@ -4086,7 +4120,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
arm_smmu_rmr_install_bypass_ste(smmu);
/* Reset the device */
- ret = arm_smmu_device_reset(smmu);
+ ret = arm_smmu_device_reset(smmu, false);
if (ret)
return ret;
@@ -4124,12 +4158,34 @@ static void arm_smmu_device_shutdown(struct platform_device *pdev)
arm_smmu_device_disable(smmu);
}
+static int __maybe_unused arm_smmu_suspend(struct device *dev)
+{
+ struct arm_smmu_device *smmu = dev_get_drvdata(dev);
+
+ arm_smmu_device_disable(smmu);
+
+ return 0;
+}
+
+static int __maybe_unused arm_smmu_resume(struct device *dev)
+{
+ struct arm_smmu_device *smmu = dev_get_drvdata(dev);
+
+ arm_smmu_device_reset(smmu, true);
+
+ return 0;
+}
+
static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v3", },
{ },
};
MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
+static const struct dev_pm_ops arm_smmu_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(arm_smmu_suspend, arm_smmu_resume)
+};
+
static void arm_smmu_driver_unregister(struct platform_driver *drv)
{
arm_smmu_sva_notifier_synchronize();
@@ -4141,6 +4197,7 @@ static struct platform_driver arm_smmu_driver = {
.name = "arm-smmu-v3",
.of_match_table = arm_smmu_of_match,
.suppress_bind_attrs = true,
+ .pm = &arm_smmu_pm_ops,
},
.probe = arm_smmu_device_probe,
.remove_new = arm_smmu_device_remove,
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] dt-bindings: iio: adc: nxp,imx93-adc.yaml: Add calibration properties
From: Jonathan Cameron @ 2024-03-24 13:54 UTC (permalink / raw)
To: Andrej Picej
Cc: Krzysztof Kozlowski, haibo.chen, linux-iio, devicetree, lars,
shawnguo, s.hauer, kernel, festevam, imx, linux-arm-kernel,
linux-kernel, robh, krzysztof.kozlowski+dt, conor+dt, upstream
In-Reply-To: <1bbd4fdf-59c5-42b2-8698-95f402645c67@norik.com>
On Fri, 22 Mar 2024 10:58:54 +0100
Andrej Picej <andrej.picej@norik.com> wrote:
> On 22. 03. 24 09:14, Krzysztof Kozlowski wrote:
> > On 22/03/2024 08:39, Andrej Picej wrote:
> >> On 20. 03. 24 13:15, Krzysztof Kozlowski wrote:
> >>> On 20/03/2024 13:05, Andrej Picej wrote:
> >>>> Hi Krzysztof,
> >>>>
> >>>> On 20. 03. 24 11:26, Krzysztof Kozlowski wrote:
> >>>>> On 20/03/2024 11:04, Andrej Picej wrote:
> >>>>>> Document calibration properties and how to set them.
> >>>>>
> >>>>> Bindings are before users.
> >>>>
> >>>> will change patch order when I send a v2.
> >>>>
> >>>>>
> >>>>> Please use subject prefixes matching the subsystem. You can get them for
> >>>>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> >>>>> your patch is touching.
> >>>>> There is no file extension in prefixes.
> >>>>
> >>>> So: dt-bindings: iio/adc: nxp,imx93-adc: Add calibration properties?
> >>>
> >>> Did you run the command I proposed? I don't see much of "/", but except
> >>> that looks good.
> >>
> >> Ok noted.
> >>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
> >>>>>> ---
> >>>>>> .../bindings/iio/adc/nxp,imx93-adc.yaml | 15 +++++++++++++++
> >>>>>> 1 file changed, 15 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
> >>>>>> index dacc526dc695..64958be62a6a 100644
> >>>>>> --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
> >>>>>> @@ -46,6 +46,21 @@ properties:
> >>>>>> "#io-channel-cells":
> >>>>>> const: 1
> >>>>>>
> >>>>>> + nxp,calib-avg-en:
> >>>>>> + description:
> >>>>>> + Enable or disable averaging of calibration time.
> >>>>>> + enum: [ 0, 1 ]
> >>>>>> +
> >>>>>> + nxp,calib-nr-samples:
> >>>>>> + description:
> >>>>>> + Selects the number of averaging samples to be used during calibration.
> >>>>>> + enum: [ 16, 32, 128, 512 ]
> >>>>>> +
> >>>>>> + nxp,calib-t-samples:
> >>>>>> + description:
> >>>>>> + Specifies the sample time of calibration conversions.
> >>>>>> + enum: [ 8, 16, 22, 32 ]
> >>>>>
> >>>>> No, use existing, generic properties. Open other bindings for this.
> >>>>
> >>>> You mean I should use generic properties for the ADC calibration
> >>>> settings? Is there already something in place? Because as I understand
> >>>> it, these calib-* values only effect the calibration process of the ADC.
> >>>
> >>> Please take a look at other devices and dtschema. We already have some
> >>> properties for this... but maybe they cannot be used?
> >>>
> >>
> >> I did look into other ADC devices, grep across iio/adc, adc bindings
> >> folders and couldn't find anything closely related to what we are
> >> looking for. Could you please point me to the properties that you think
> >> should be used for this?
> >
> > Indeed, there are few device specific like qcom,avg-samples. We have
> > though oversampling-ratio, settling-time-us and min-sample-time (which
> > is not that good because does not use unit suffix).
>
> Ok, these are examples but I think I should not use them, since these
> are i.MX93 ADC specific settings, which are used for configuration of
> calibration process, and are not related to the standard conversion
> process during runtime. Calibration process is the first step that
> should be done after every power-on reset.
>
> >
> > Then follow up questions:
> > - nxp,calib-avg-en: Why is it a board-level decision? I would assume
> > this depends on user choice and what kind of input you have (which could
> > be board dependent or could be runtime decision).
>
> Not really sure I get your question, so please elaborate if I missed the
> point.
> This is a user choice, to enable or disable the averaging function in
> calibration, but this is a board-level decision, probably relates on
> external ADC regulators and input connections. The same options are used
> for every ADC channel and this can not be a runtime decision, since
> calibration is done before the ADC is even registered.
I'll raise this question in reply to the cover letter or patch 1 where
it is perhaps more appropriate, but I'd really like to know more about why
these are useful at all.
>
> > - nxp,calib-t-samples: what does it mean? Time is expressed in time
> > units, but there is nothing about units in the property name.
> >
>
> You are right, basically this is "time" in cycles of AD_CLK. I should at
> least add that to the property description.
>
> Best regards,
> Andrej Picej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] i.MX93 ADC calibration settings
From: Jonathan Cameron @ 2024-03-24 13:55 UTC (permalink / raw)
To: Andrej Picej
Cc: haibo.chen, linux-iio, devicetree, lars, shawnguo, s.hauer,
kernel, festevam, imx, linux-arm-kernel, linux-kernel, robh,
krzysztof.kozlowski+dt, conor+dt, upstream
In-Reply-To: <20240320100407.1639082-1-andrej.picej@norik.com>
On Wed, 20 Mar 2024 11:04:04 +0100
Andrej Picej <andrej.picej@norik.com> wrote:
> Hi all,
>
> we had some problems with failing ADC calibration on the i.MX93 boards.
> Changing default calibration settings fixed this. The board where this
> patches are useful is not yet upstream but will be soon (hopefully).
Tell us more. My initial instinct is that this shouldn't be board specific.
What's the trade off we are making here? Time vs precision of calibration or
something else? If these are set to a level by default that doesn't work
for our board, maybe we should just change them for all devices?
Jonathan
>
> Since we had these patches laying around we thought they might also be
> useful for someone else.
>
> Best regards,
> Andrej
>
> Andrej Picej (2):
> iio: adc: imx93: Make calibration properties configurable
> dt-bindings: iio: adc: nxp,imx93-adc.yaml: Add calibration properties
>
> .../bindings/iio/adc/nxp,imx93-adc.yaml | 15 +++++
> drivers/iio/adc/imx93_adc.c | 66 +++++++++++++++++--
> 2 files changed, 76 insertions(+), 5 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] iio: adc: imx93: Make calibration properties configurable
From: Jonathan Cameron @ 2024-03-24 14:02 UTC (permalink / raw)
To: Andrej Picej
Cc: haibo.chen, linux-iio, devicetree, lars, shawnguo, s.hauer,
kernel, festevam, imx, linux-arm-kernel, linux-kernel, robh,
krzysztof.kozlowski+dt, conor+dt, upstream
In-Reply-To: <20240320100407.1639082-2-andrej.picej@norik.com>
On Wed, 20 Mar 2024 11:04:05 +0100
Andrej Picej <andrej.picej@norik.com> wrote:
> Make calibration properties:
> - AVGEN: allow averaging of calibration time,
Confused. How do you average time? Or is this enabling averaging of
ADC readings at calibration time?
> - NRSMPL: select the number of averaging samples during calibration and
Assuming I read AVGEN right, just have a value of 1 in here mean AVGEN is
disabled.
> - TSAMP: specifies the sample time of calibration conversions
Not sure what this means. Is it acquisition time? Is it time after a mux
changes? Anyhow, more info needed.
This is the only one I can see being possibly board related. But if it
is and is needed for calibration, why not for normal read out?
>
> configurable with device tree properties:
> - nxp,calib-avg-en,
> - nxp,calib-nr-samples and
> - nxp,calib-t-samples.
>
> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
> ---
> drivers/iio/adc/imx93_adc.c | 66 ++++++++++++++++++++++++++++++++++---
> 1 file changed, 61 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/adc/imx93_adc.c b/drivers/iio/adc/imx93_adc.c
> index 4ccf4819f1f1..ad24105761ab 100644
> --- a/drivers/iio/adc/imx93_adc.c
> +++ b/drivers/iio/adc/imx93_adc.c
> @@ -18,6 +18,7 @@
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/property.h>
>
> #define IMX93_ADC_DRIVER_NAME "imx93-adc"
>
> @@ -43,6 +44,9 @@
> #define IMX93_ADC_MCR_MODE_MASK BIT(29)
> #define IMX93_ADC_MCR_NSTART_MASK BIT(24)
> #define IMX93_ADC_MCR_CALSTART_MASK BIT(14)
> +#define IMX93_ADC_MCR_AVGEN_MASK BIT(13)
> +#define IMX93_ADC_MCR_NRSMPL_MASK GENMASK(12, 11)
> +#define IMX93_ADC_MCR_TSAMP_MASK GENMASK(10, 9)
> #define IMX93_ADC_MCR_ADCLKSE_MASK BIT(8)
> #define IMX93_ADC_MCR_PWDN_MASK BIT(0)
> #define IMX93_ADC_MSR_CALFAIL_MASK BIT(30)
> @@ -145,7 +149,7 @@ static void imx93_adc_config_ad_clk(struct imx93_adc *adc)
>
> static int imx93_adc_calibration(struct imx93_adc *adc)
> {
> - u32 mcr, msr;
> + u32 mcr, msr, value;
> int ret;
>
> /* make sure ADC in power down mode */
> @@ -156,12 +160,64 @@ static int imx93_adc_calibration(struct imx93_adc *adc)
> mcr &= ~FIELD_PREP(IMX93_ADC_MCR_ADCLKSE_MASK, 1);
> writel(mcr, adc->regs + IMX93_ADC_MCR);
>
> - imx93_adc_power_up(adc);
> -
> /*
> - * TODO: we use the default TSAMP/NRSMPL/AVGEN in MCR,
> - * can add the setting of these bit if need in future.
> + * Set calibration settings:
> + * - AVGEN: allow averaging of calibration time,
> + * - NRSMPL: select the number of averaging samples during calibration,
> + * - TSAMP: specifies the sample time of calibration conversions.
> */
> + if (!device_property_read_u32(adc->dev, "nxp,calib-avg-en", &value)) {
> + mcr &= ~IMX93_ADC_MCR_AVGEN_MASK;
> + mcr |= FIELD_PREP(IMX93_ADC_MCR_AVGEN_MASK, value);
> + }
> +
> + if (!device_property_read_u32(adc->dev, "nxp,calib-nr-samples", &value)) {
Handle error for not present different from a failure to read or similar.
Not present isn't an error, just a fall back to defaults.
For other error codes we should fail the probe.
> + switch (value) {
> + case 16:
> + value = 0x0;
Don't do this in place, meaning of value before this point different to what
you have in it going forwards. Use a different variable name to make that clear.
reg_val vs nr_samples perhaps?
> + break;
> + case 32:
> + value = 0x1;
> + break;
> + case 128:
> + value = 0x2;
> + break;
> + case 512:
> + value = 0x3;
> + break;
> + default:
> + dev_warn(adc->dev, "NRSMPL: wrong value, using default: 512\n");
Fail the probe rather than papering over a wrong value. I'd rather we got the DT fixed
quickly and if someone wanted another value, they really did want it.
We probably do want a default though for the property not being present (given it is new).
so take setting of this variable outside the if(!device_property_read_u32);
> + value = 0x3;
> + }
> + mcr &= ~IMX93_ADC_MCR_NRSMPL_MASK;
> + mcr |= FIELD_PREP(IMX93_ADC_MCR_NRSMPL_MASK, value);
> + }
> +
> + if (!device_property_read_u32(adc->dev, "nxp,calib-t-samples", &value)) {
> + switch (value) {
> + case 8:
> + value = 0x1;
> + break;
> + case 16:
> + value = 0x2;
> + break;
> + case 22:
> + value = 0x0;
> + break;
> + case 32:
> + value = 0x3;
> + break;
> + default:
> + dev_warn(adc->dev, "TSAMP: wrong value, using default: 22\n");
> + value = 0x0;
> + }
> + mcr &= ~IMX93_ADC_MCR_TSAMP_MASK;
> + mcr |= FIELD_PREP(IMX93_ADC_MCR_TSAMP_MASK, value);
> + }
> +
> + writel(mcr, adc->regs + IMX93_ADC_MCR);
> +
> + imx93_adc_power_up(adc);
>
> /* run calibration */
> mcr = readl(adc->regs + IMX93_ADC_MCR);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: qcom: Add Motorola Moto G (2013)
From: Stanislav Jakubek @ 2024-03-24 14:03 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-arm-kernel, phone-devel,
linux-kernel
Document the Motorola Moto G (2013), which is a smartphone based
on the Qualcomm MSM8226 SoC.
Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 66beaac60e1d..d2910982ae86 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -137,6 +137,7 @@ properties:
- microsoft,dempsey
- microsoft,makepeace
- microsoft,moneypenny
+ - motorola,falcon
- samsung,s3ve3g
- const: qcom,msm8226
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: qcom: Add support for Motorola Moto G (2013)
From: Stanislav Jakubek @ 2024-03-24 14:04 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-arm-kernel, phone-devel,
linux-kernel
In-Reply-To: <f5d4d71cd59f25b80889ef88fa044aa3a4268d46.1711288736.git.stano.jakubek@gmail.com>
Add a device tree for the Motorola Moto G (2013) smartphone based
on the Qualcomm MSM8226 SoC.
Initially supported features:
- Buttons (Volume Down/Up, Power)
- eMMC
- Hall Effect Sensor
- SimpleFB display
- TMP108 temperature sensor
- Vibrator
Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
---
arch/arm/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/msm8226-motorola-falcon.dts | 355 ++++++++++++++++++
2 files changed, 356 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts
diff --git a/arch/arm/boot/dts/qcom/Makefile b/arch/arm/boot/dts/qcom/Makefile
index 6478a39b3be5..3eacbf5c0785 100644
--- a/arch/arm/boot/dts/qcom/Makefile
+++ b/arch/arm/boot/dts/qcom/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_QCOM) += \
+ msm8226-motorola-falcon.dtb \
qcom-apq8016-sbc.dtb \
qcom-apq8026-asus-sparrow.dtb \
qcom-apq8026-huawei-sturgeon.dtb \
diff --git a/arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts b/arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts
new file mode 100644
index 000000000000..acf0e3fee481
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts
@@ -0,0 +1,355 @@
+// SPDX-License-Identifier: BSD-3-Clause
+
+/dts-v1/;
+
+#include "qcom-msm8226.dtsi"
+#include "pm8226.dtsi"
+
+/delete-node/ &smem_region;
+
+/ {
+ model = "Motorola Moto G (2013)";
+ compatible = "motorola,falcon", "qcom,msm8226";
+ chassis-type = "handset";
+
+ aliases {
+ mmc0 = &sdhc_1;
+ };
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@3200000 {
+ compatible = "simple-framebuffer";
+ reg = <0x03200000 0x800000>;
+ width = <720>;
+ height = <1280>;
+ stride = <(720 * 3)>;
+ format = "r8g8b8";
+ vsp-supply = <®_lcd_pos>;
+ vsn-supply = <®_lcd_neg>;
+ vddio-supply = <&vddio_disp_vreg>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ event-hall-sensor {
+ label = "Hall Effect Sensor";
+ gpios = <&tlmm 51 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_LID>;
+ linux,can-disable;
+ };
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = <&tlmm 106 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ debounce-interval = <15>;
+ };
+ };
+
+ vddio_disp_vreg: regulator-vddio-disp {
+ compatible = "regulator-fixed";
+ regulator-name = "vddio_disp";
+ gpio = <&tlmm 34 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&pm8226_l8>;
+ startup-delay-us = <300>;
+ enable-active-high;
+ regulator-boot-on;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@3200000 {
+ reg = <0x03200000 0x800000>;
+ no-map;
+ };
+
+ hob-ram@f500000 {
+ reg = <0x0f500000 0x40000>,
+ <0x0f540000 0x2000>;
+ no-map;
+ };
+
+ smem_region: smem@fa00000 {
+ reg = <0x0fa00000 0x100000>;
+ no-map;
+ };
+
+ /* Actually <0x0fa00000 0x500000>, but first 100000 is smem */
+ reserved@fb00000 {
+ reg = <0x0fb00000 0x400000>;
+ no-map;
+ };
+ };
+};
+
+&blsp1_i2c3 {
+ status = "okay";
+
+ regulator@3e {
+ compatible = "ti,tps65132";
+ reg = <0x3e>;
+ pinctrl-0 = <®_lcd_default>;
+ pinctrl-names = "default";
+
+ reg_lcd_pos: outp {
+ regulator-name = "outp";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <6000000>;
+ regulator-active-discharge = <1>;
+ regulator-boot-on;
+ enable-gpios = <&tlmm 31 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_lcd_neg: outn {
+ regulator-name = "outn";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <6000000>;
+ regulator-active-discharge = <1>;
+ regulator-boot-on;
+ enable-gpios = <&tlmm 33 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp108";
+ reg = <0x48>;
+ interrupts-extended = <&tlmm 13 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&temp_alert_default>;
+ pinctrl-names = "default";
+ #thermal-sensor-cells = <0>;
+ };
+};
+
+&pm8226_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+ status = "okay";
+};
+
+&pm8226_vib {
+ status = "okay";
+};
+
+&rpm_requests {
+ regulators {
+ compatible = "qcom,rpm-pm8226-regulators";
+
+ pm8226_s3: s3 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1300000>;
+ };
+
+ pm8226_s4: s4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2200000>;
+ };
+
+ pm8226_s5: s5 {
+ regulator-min-microvolt = <1150000>;
+ regulator-max-microvolt = <1150000>;
+ };
+
+ pm8226_l1: l1 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ };
+
+ pm8226_l2: l2 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8226_l3: l3 {
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1337500>;
+ };
+
+ pm8226_l4: l4 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8226_l5: l5 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8226_l6: l6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allow-set-load;
+ };
+
+ pm8226_l7: l7 {
+ regulator-min-microvolt = <1850000>;
+ regulator-max-microvolt = <1850000>;
+ };
+
+ pm8226_l8: l8 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm8226_l9: l9 {
+ regulator-min-microvolt = <2050000>;
+ regulator-max-microvolt = <2050000>;
+ };
+
+ pm8226_l10: l10 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm8226_l12: l12 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm8226_l14: l14 {
+ regulator-min-microvolt = <2750000>;
+ regulator-max-microvolt = <2750000>;
+ };
+
+ pm8226_l15: l15 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ pm8226_l16: l16 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3350000>;
+ };
+
+ pm8226_l17: l17 {
+ regulator-min-microvolt = <2950000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l18: l18 {
+ regulator-min-microvolt = <2950000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l19: l19 {
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ };
+
+ pm8226_l20: l20 {
+ regulator-min-microvolt = <3075000>;
+ regulator-max-microvolt = <3075000>;
+ };
+
+ pm8226_l21: l21 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ regulator-allow-set-load;
+ };
+
+ pm8226_l22: l22 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l23: l23 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l24: l24 {
+ regulator-min-microvolt = <1300000>;
+ regulator-max-microvolt = <1350000>;
+ };
+
+ pm8226_l25: l25 {
+ regulator-min-microvolt = <1775000>;
+ regulator-max-microvolt = <2125000>;
+ };
+
+ pm8226_l26: l26 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ };
+
+ pm8226_l27: l27 {
+ regulator-min-microvolt = <2050000>;
+ regulator-max-microvolt = <2050000>;
+ };
+
+ pm8226_l28: l28 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ };
+
+ pm8226_lvs1: lvs1 {
+ regulator-always-on;
+ };
+ };
+};
+
+&sdhc_1 {
+ vmmc-supply = <&pm8226_l17>;
+ vqmmc-supply = <&pm8226_l6>;
+
+ bus-width = <8>;
+ non-removable;
+
+ status = "okay";
+};
+
+&smbb {
+ qcom,fast-charge-safe-current = <2000000>;
+ qcom,fast-charge-current-limit = <1900000>;
+ qcom,fast-charge-safe-voltage = <4400000>;
+ qcom,minimum-input-voltage = <4300000>;
+
+ status = "okay";
+};
+
+&tlmm {
+ reg_lcd_default: reg-lcd-default-state {
+ pins = "gpio31", "gpio33";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ reg_vddio_disp_default: reg-vddio-disp-default-state {
+ pins = "gpio34";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ temp_alert_default: temp-alert-default-state {
+ pins = "gpio13";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-disable;
+ };
+};
+
+&usb {
+ extcon = <&smbb>;
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usb_hs_phy {
+ extcon = <&smbb>;
+ v1p8-supply = <&pm8226_l10>;
+ v3p3-supply = <&pm8226_l20>;
+};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v1 0/3] iio: adc: meson: a few improvements
From: Jonathan Cameron @ 2024-03-24 14:04 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-amlogic, linux-arm-kernel, linux-kernel, gnstark,
neil.armstrong, lars
In-Reply-To: <20240323231309.415425-1-martin.blumenstingl@googlemail.com>
On Sun, 24 Mar 2024 00:13:06 +0100
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> This series contains three improvements to the meson SAR ADC driver.
> None of them are meant to change the existing behavior. The goal is
> to make the driver code easier to read and understand.
>
>
> Martin Blumenstingl (3):
> iio: adc: meson: fix voltage reference selection field name typo
> iio: adc: meson: consistently use bool/enum in struct
> meson_sar_adc_param
> iio: adc: meson: simplify MESON_SAR_ADC_REG11 register access
>
> drivers/iio/adc/meson_saradc.c | 78 ++++++++++++++++------------------
> 1 file changed, 36 insertions(+), 42 deletions(-)
>
Hi Martin,
Please resend +CC linux-iio@vger.kernel.org
I'll take a quick look but I won't pick up anything that hasn't been on that
list (as I use patchwork to track status etc).
Jonathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/3] iio: adc: meson: consistently use bool/enum in struct meson_sar_adc_param
From: Jonathan Cameron @ 2024-03-24 14:07 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-amlogic, linux-arm-kernel, linux-kernel, gnstark,
neil.armstrong, lars
In-Reply-To: <20240323231309.415425-3-martin.blumenstingl@googlemail.com>
On Sun, 24 Mar 2024 00:13:08 +0100
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> Consistently use bool for any register bit that enables/disables
> functionality and enum for register values where there's a choice
> between different settings. The aim is to make the code easier to read
> and understand by being more consistent. No functional changes intended.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> drivers/iio/adc/meson_saradc.c | 47 +++++++++++++++++++---------------
> 1 file changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 2615d74534df..6b2af0c2bbc7 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -156,9 +156,9 @@
> #define MESON_SAR_ADC_REG11 0x2c
> #define MESON_SAR_ADC_REG11_BANDGAP_EN BIT(13)
> #define MESON_SAR_ADC_REG11_CMV_SEL BIT(6)
> - #define MESON_SAR_ADC_REG11_VREF_VOLTAGE BIT(5)
> - #define MESON_SAR_ADC_REG11_EOC BIT(1)
> - #define MESON_SAR_ADC_REG11_VREF_SEL BIT(0)
> + #define MESON_SAR_ADC_REG11_VREF_VOLTAGE BIT(5)
> + #define MESON_SAR_ADC_REG11_EOC BIT(1)
> + #define MESON_SAR_ADC_REG11_VREF_SEL BIT(0)
Looks like a spaces to tab conversion. Not related to rest of patch so
put them back as spaces. If you really want to tidy that up with tabs
later, separate patch please.
Otherwise LGTM
>
> #define MESON_SAR_ADC_REG13 0x34
> #define MESON_SAR_ADC_REG13_12BIT_CALIBRATION_MASK GENMASK(13, 8)
> @@ -224,6 +224,11 @@ enum meson_sar_adc_vref_sel {
> VREF_VDDA = 1,
> };
>
> +enum meson_sar_adc_vref_voltage {
> + VREF_VOLTAGE_0V9 = 0,
> + VREF_VOLTAGE_1V8 = 1,
> +};
> +
> enum meson_sar_adc_avg_mode {
> NO_AVERAGING = 0x0,
> MEAN_AVERAGING = 0x1,
> @@ -321,13 +326,13 @@ struct meson_sar_adc_param {
> u8 temperature_trimming_bits;
> unsigned int temperature_multiplier;
> unsigned int temperature_divider;
> - u8 disable_ring_counter;
> + bool disable_ring_counter;
> bool has_reg11;
> bool has_vref_select;
> - u8 vref_select;
> - u8 cmv_select;
> - u8 adc_eoc;
> - enum meson_sar_adc_vref_sel vref_voltage;
> + bool cmv_select;
> + bool adc_eoc;
> + enum meson_sar_adc_vref_sel vref_select;
> + enum meson_sar_adc_vref_voltage vref_voltage;
> };
>
> struct meson_sar_adc_data {
> @@ -982,14 +987,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> MESON_SAR_ADC_DELTA_10_TS_REVE0, 0);
> }
>
> - regval = FIELD_PREP(MESON_SAR_ADC_REG3_CTRL_CONT_RING_COUNTER_EN,
> - priv->param->disable_ring_counter);
> + if (priv->param->disable_ring_counter)
> + regval = MESON_SAR_ADC_REG3_CTRL_CONT_RING_COUNTER_EN;
> + else
> + regval = 0;
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
> MESON_SAR_ADC_REG3_CTRL_CONT_RING_COUNTER_EN,
> regval);
>
> if (priv->param->has_reg11) {
> - regval = FIELD_PREP(MESON_SAR_ADC_REG11_EOC, priv->param->adc_eoc);
> + regval = priv->param->adc_eoc ? MESON_SAR_ADC_REG11_EOC : 0;
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
> MESON_SAR_ADC_REG11_EOC, regval);
>
> @@ -1005,8 +1012,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
> MESON_SAR_ADC_REG11_VREF_VOLTAGE, regval);
>
> - regval = FIELD_PREP(MESON_SAR_ADC_REG11_CMV_SEL,
> - priv->param->cmv_select);
> + regval = priv->param->cmv_select ? MESON_SAR_ADC_REG11_CMV_SEL : 0;
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
> MESON_SAR_ADC_REG11_CMV_SEL, regval);
> }
> @@ -1225,8 +1231,8 @@ static const struct meson_sar_adc_param meson_sar_adc_gxbb_param = {
> .regmap_config = &meson_sar_adc_regmap_config_gxbb,
> .resolution = 10,
> .has_reg11 = true,
> - .vref_voltage = 1,
> - .cmv_select = 1,
> + .vref_voltage = VREF_VOLTAGE_1V8,
> + .cmv_select = true,
> };
>
> static const struct meson_sar_adc_param meson_sar_adc_gxl_param = {
> @@ -1237,8 +1243,8 @@ static const struct meson_sar_adc_param meson_sar_adc_gxl_param = {
> .resolution = 12,
> .disable_ring_counter = 1,
> .has_reg11 = true,
> - .vref_voltage = 1,
> - .cmv_select = 1,
> + .vref_voltage = VREF_VOLTAGE_1V8,
> + .cmv_select = true,
> };
>
> static const struct meson_sar_adc_param meson_sar_adc_axg_param = {
> @@ -1249,10 +1255,10 @@ static const struct meson_sar_adc_param meson_sar_adc_axg_param = {
> .resolution = 12,
> .disable_ring_counter = 1,
> .has_reg11 = true,
> - .vref_voltage = 1,
> + .vref_voltage = VREF_VOLTAGE_1V8,
> .has_vref_select = true,
> .vref_select = VREF_VDDA,
> - .cmv_select = 1,
> + .cmv_select = true,
> };
>
> static const struct meson_sar_adc_param meson_sar_adc_g12a_param = {
> @@ -1263,7 +1269,8 @@ static const struct meson_sar_adc_param meson_sar_adc_g12a_param = {
> .resolution = 12,
> .disable_ring_counter = 1,
> .has_reg11 = true,
> - .adc_eoc = 1,
> + .vref_voltage = VREF_VOLTAGE_0V9,
> + .adc_eoc = true,
> .has_vref_select = true,
> .vref_select = VREF_VDDA,
> };
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Alan Stern @ 2024-03-24 15:22 UTC (permalink / raw)
To: comex
Cc: Linus Torvalds, Kent Overstreet, Boqun Feng, rust-for-linux,
linux-kernel, linux-arch, llvm, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Andrea Parri,
Will Deacon, Peter Zijlstra, Nicholas Piggin, David Howells,
Jade Alglave, Luc Maranget, Paul E. McKenney, Akira Yokosawa,
Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman, elver,
Mark Rutland, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Catalin Marinas,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <C85BE4F4-5847-45B4-A973-76B184B35EDE@gmail.com>
On Sat, Mar 23, 2024 at 05:40:23PM -0400, comex wrote:
> That may be true, but the LLVM issue you cited isn’t a good example.
> In that issue, the function being miscompiled doesn’t actually use any
> barriers or atomics itself; only the scaffolding around it does. The
> same issue would happen even if the scaffolding used LKMM atomics.
>
> For anyone curious: The problematic optimization involves an
> allocation (‘p’) that is initially private to the function, but is
> returned at the end of the function. LLVM moves a non-atomic store to
> that allocation across an external function call (to ‘foo’). This
> reordering would be blatantly invalid if any other code could observe
> the contents of the allocation, but is valid if the allocation is
> private to the function. LLVM assumes the latter: after all, the
> pointer to it hasn’t escaped. Yet. Except that in a weak memory
> model, the escape can ‘time travel’...
It's hard to understand exactly what you mean, but consider the
following example:
int *globalptr;
int x;
int *f() {
int *p = kzalloc(sizeof(int));
L1: *p = 1;
L2: foo();
return p;
}
void foo() {
smp_store_release(&x, 2);
}
void thread0() {
WRITE_ONCE(globalptr, f());
}
void thread1() {
int m, n;
int *q;
m = smp_load_acquire(&x);
q = READ_ONCE(globalptr);
if (m && q)
n = *q;
}
(If you like, pretend each of these function definitions lives in a
different source file -- it doesn't matter.)
With no optimization, whenever thread1() reads *q it will always obtain
1, thanks to the store-release in foo() and the load-acquire() in
thread1(). But if the compiler swaps L1 and L2 in f() then this is not
guaranteed. On a weakly ordered architecture, thread1() could then get
0 from *q.
I don't know if this is what you meant by "in a weak memory model, the
escape can ‘time travel'". Regardless, it seems very clear that any
compiler which swaps L1 and L2 in f() has a genuine bug.
Alan Stern
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: comex @ 2024-03-24 17:37 UTC (permalink / raw)
To: Alan Stern
Cc: Linus Torvalds, Kent Overstreet, Boqun Feng, rust-for-linux,
linux-kernel, linux-arch, llvm, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Andrea Parri,
Will Deacon, Peter Zijlstra, Nicholas Piggin, David Howells,
Jade Alglave, Luc Maranget, Paul E. McKenney, Akira Yokosawa,
Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman,
Marco Elver, Mark Rutland, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Catalin Marinas, linux-arm-kernel, linux-fsdevel
In-Reply-To: <174272a1-e21f-4d85-94ab-f0457bd1c93b@rowland.harvard.edu>
> On Mar 24, 2024, at 11:22 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> I don't know if this is what you meant by "in a weak memory model, the
> escape can ‘time travel'". Regardless, it seems very clear that any
> compiler which swaps L1 and L2 in f() has a genuine bug.
Yes, that’s what I meant. Clang thinks it’s valid to swap L1 and L2. Though, for it to actually happen, they would have to be in a loop, since the problematic optimization is “loop-invariant code motion". Here’s a modified version of your f() that shows the optimization in action:
https://godbolt.org/z/bdaTjjvMs
Anyway, my point is just that using LKMM doesn’t save you from the bug.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 06/25] ASoC: meson: g12a-toacodec: fix "Lane Select" width
From: Jan Dakinevich @ 2024-03-24 17:51 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Kevin Hilman, Martin Blumenstingl, Liam Girdwood, Mark Brown,
Linus Walleij, Jaroslav Kysela, Takashi Iwai, linux-amlogic,
linux-clk, devicetree, linux-kernel, linux-arm-kernel, alsa-devel,
linux-sound, linux-gpio
Cc: kernel
In-Reply-To: <20240314232201.2102178-7-jan.dakinevich@salutedevices.com>
Sorry, I screwed up. Original code is correct. I mixed up the maximum
value and bit offset.
On 3/15/24 02:21, Jan Dakinevich wrote:
> For both G12A and SM1 the width of "Lane Select" should be 2, not 3.
> Otherwise, it overlaps with "Source".
>
> Signed-off-by: Jan Dakinevich <jan.dakinevich@salutedevices.com>
> ---
> sound/soc/meson/g12a-toacodec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/meson/g12a-toacodec.c b/sound/soc/meson/g12a-toacodec.c
> index 531bb8707a3e..b92de2235627 100644
> --- a/sound/soc/meson/g12a-toacodec.c
> +++ b/sound/soc/meson/g12a-toacodec.c
> @@ -229,11 +229,11 @@ static const struct snd_soc_dapm_route g12a_toacodec_routes[] = {
> };
>
> static const struct snd_kcontrol_new g12a_toacodec_controls[] = {
> - SOC_SINGLE("Lane Select", TOACODEC_CTRL0, CTRL0_LANE_SEL, 3, 0),
> + SOC_SINGLE("Lane Select", TOACODEC_CTRL0, CTRL0_LANE_SEL, 2, 0),
> };
>
> static const struct snd_kcontrol_new sm1_toacodec_controls[] = {
> - SOC_SINGLE("Lane Select", TOACODEC_CTRL0, CTRL0_LANE_SEL_SM1, 3, 0),
> + SOC_SINGLE("Lane Select", TOACODEC_CTRL0, CTRL0_LANE_SEL_SM1, 2, 0),
> };
>
> static const struct snd_soc_component_driver g12a_toacodec_component_drv = {
--
Best regards
Jan Dakinevich
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH bpf-next v2 0/1] Support kCFI + BPF on arm64
From: Puranjay Mohan @ 2024-03-24 21:15 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Zi Shen Lim, Mark Rutland, Suzuki K Poulose,
Mark Brown, linux-arm-kernel, open list,
open list:BPF [GENERAL] (Safe Dynamic Programs and Tools),
Josh Poimboeuf
Cc: puranjay12
Changes in V2:
V1: https://lore.kernel.org/bpf/20240227151115.4623-1-puranjay12@gmail.com/
- Rebased on latest bpf-next/master
On ARM64 with CONFIG_CFI_CLANG, CFI warnings can be triggered by running
the bpf selftests. This is because the JIT doesn't emit proper CFI prologues
for BPF programs, callbacks, and struct_ops trampolines.
Example Warning:
CFI failure at bpf_rbtree_add_impl+0x120/0x1d4 (target: bpf_prog_fb8b097ab47d164a_less+0x0/0x98; expected type: 0x9e4709a9)
WARNING: CPU: 0 PID: 1488 at bpf_rbtree_add_impl+0x120/0x1d4
Modules linked in: bpf_testmod(OE) virtio_net net_failover failover aes_ce_blk aes_ce_cipher ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_mmio uio_pdrv_genirq uio dm_mod dax configfs [last unloaded: bpf_testmod(OE)]
CPU: 0 PID: 1488 Comm: new_name Tainted: P OE 6.8.0-rc1+ #1
Hardware name: linux,dummy-virt (DT)
pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : bpf_rbtree_add_impl+0x120/0x1d4
lr : bpf_prog_234260f1d6227155_rbtree_first_and_remove+0x218/0x438
sp : ffff80008444bb10
x29: ffff80008444bb10 x28: ffff80008444bbf0 x27: ffff80008444bb60
x26: 0000000000000000 x25: 0000000000000010 x24: 0000000000000008
x23: 0000000000000001 x22: ffff00000ab71658 x21: ffff8000843dd5fc
x20: ffff00000ab459f0 x19: ffff00000ab71358 x18: 0000000000000000
x17: 000000009e4709a9 x16: 00000000d4202000 x15: 0000aaaadf15e420
x14: 0000000000004007 x13: ffff800084448000 x12: 0000000000000000
x11: dead00000000eb9f x10: ffff00000ab71370 x9 : 0000000000000000
x8 : ffff00000ab71658 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : ffff00000ab71658 x0 : ffff00000ab71358
Call trace:
bpf_rbtree_add_impl+0x120/0x1d4
bpf_prog_234260f1d6227155_rbtree_first_and_remove+0x218/0x438
bpf_test_run+0x190/0x358
bpf_prog_test_run_skb+0x354/0x460
bpf_prog_test_run+0x128/0x164
__sys_bpf+0x364/0x428
__arm64_sys_bpf+0x30/0x44
invoke_syscall+0x64/0x128
el0_svc_common+0xb4/0xe8
do_el0_svc+0x28/0x34
el0_svc+0x58/0x108
el0t_64_sync_handler+0x90/0xfc
el0t_64_sync+0x1a8/0x1ac
irq event stamp: 35493817
hardirqs last enabled at (35493816): [<ffff8000802e4268>] unit_alloc+0x110/0x1b0
hardirqs last disabled at (35493817): [<ffff8000802ad35c>] bpf_spin_lock+0x2c/0xec
softirqs last enabled at (35493688): [<ffff800080275934>] bpf_ksym_add+0x164/0x184
softirqs last disabled at (35493810): [<ffff800080cd9ac8>] local_bh_disable+0x4/0x30
---[ end trace 0000000000000000 ]---
This patch fixes the prologue and trampoline generation code to emit the
KCFI hash before the expected branch targets. The KCFI hashes are generated
at compile time and are unique to function prototypes. To allow the JIT to
find these hashes at runtime, the following behaviour of the compiler is used:
Two function prototypes are declared, one for BPF programs and another for callbacks:
extern unsigned int __bpf_prog_runX(const void *ctx, const struct bpf_insn *insn);
extern u64 __bpf_callback_fn(u64, u64, u64, u64, u64);
We force a reference to these external symbols:
__ADDRESSABLE(__bpf_prog_runX);
__ADDRESSABLE(__bpf_callback_fn);
This makes the compiler add the following two symbols with the hashes in
the symbol table:
00000000d9421881 0 NOTYPE WEAK DEFAULT ABS __kcfi_typeid___bpf_prog_runX
000000009e4709a9 0 NOTYPE WEAK DEFAULT ABS __kcfi_typeid___bpf_callback_fn
The JIT can now use the above symbols to emit the hashes in the prologues of
the programs and callbacks.
For struct_ops trampoline, the bpf_struct_ops_prepare_trampoline() function
receives a stub function that would have the hash at (function - 4). The
bpf_struct_ops_prepare_trampoline() sets `flags = BPF_TRAMP_F_INDIRECT;`
which tells prepare_trampoline() to find the hash before the stub function
and emit it in the struct_ops trampoline.
Running the selftests causes no CFI warnings:
---------------------------------------------
test_progs: Summary: 454/3613 PASSED, 62 SKIPPED, 74 FAILED
test_tag: OK (40945 tests)
test_verifier: Summary: 789 PASSED, 0 SKIPPED, 0 FAILED
ARM64 Doesn't support DYNAMIC_FTRACE_WITH_CALL_OPS when CFI_CLANG is
enabled. This causes all tests that attach fentry to kernel functions to fail.
While running the selftests, I saw some CFI warnings which were related to
static calls. Josh Poimboeuf had sent a patch series[1] last year that includes
a patch to fix this issue. Applying this patch and [1] fixes all kCFI issues.
[1] https://lore.kernel.org/all/cover.1679456900.git.jpoimboe@kernel.org/
Puranjay Mohan (1):
arm64/cfi,bpf: Support kCFI + BPF on arm64
arch/arm64/include/asm/cfi.h | 23 ++++++++++++++
arch/arm64/kernel/alternative.c | 54 +++++++++++++++++++++++++++++++++
arch/arm64/net/bpf_jit_comp.c | 28 +++++++++++++----
3 files changed, 99 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/include/asm/cfi.h
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH bpf-next v2 1/1] arm64/cfi,bpf: Support kCFI + BPF on arm64
From: Puranjay Mohan @ 2024-03-24 21:15 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Zi Shen Lim, Mark Rutland, Suzuki K Poulose,
Mark Brown, linux-arm-kernel, open list,
open list:BPF [GENERAL] (Safe Dynamic Programs and Tools),
Josh Poimboeuf
Cc: puranjay12
In-Reply-To: <20240324211518.93892-1-puranjay12@gmail.com>
Currently, bpf_dispatcher_*_func() is marked with `__nocfi` therefore
calling BPF programs from this interface doesn't cause CFI warnings.
When BPF programs are called directly from C: from BPF helpers or
struct_ops, CFI warnings are generated.
Implement proper CFI prologues for the BPF programs and callbacks and
drop __nocfi for arm64. Fix the trampoline generation code to emit kCFI
prologue when a struct_ops trampoline is being prepared.
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
---
arch/arm64/include/asm/cfi.h | 23 ++++++++++++++
arch/arm64/kernel/alternative.c | 54 +++++++++++++++++++++++++++++++++
arch/arm64/net/bpf_jit_comp.c | 28 +++++++++++++----
3 files changed, 99 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/include/asm/cfi.h
diff --git a/arch/arm64/include/asm/cfi.h b/arch/arm64/include/asm/cfi.h
new file mode 100644
index 000000000000..670e191f8628
--- /dev/null
+++ b/arch/arm64/include/asm/cfi.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM64_CFI_H
+#define _ASM_ARM64_CFI_H
+
+#ifdef CONFIG_CFI_CLANG
+#define __bpfcall
+static inline int cfi_get_offset(void)
+{
+ return 4;
+}
+#define cfi_get_offset cfi_get_offset
+extern u32 cfi_bpf_hash;
+extern u32 cfi_bpf_subprog_hash;
+extern u32 cfi_get_func_hash(void *func);
+#else
+#define cfi_bpf_hash 0U
+#define cfi_bpf_subprog_hash 0U
+static inline u32 cfi_get_func_hash(void *func)
+{
+ return 0;
+}
+#endif /* CONFIG_CFI_CLANG */
+#endif /* _ASM_ARM64_CFI_H */
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 8ff6610af496..1715da7df137 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -13,6 +13,7 @@
#include <linux/elf.h>
#include <asm/cacheflush.h>
#include <asm/alternative.h>
+#include <asm/cfi.h>
#include <asm/cpufeature.h>
#include <asm/insn.h>
#include <asm/module.h>
@@ -298,3 +299,56 @@ noinstr void alt_cb_patch_nops(struct alt_instr *alt, __le32 *origptr,
updptr[i] = cpu_to_le32(aarch64_insn_gen_nop());
}
EXPORT_SYMBOL(alt_cb_patch_nops);
+
+#ifdef CONFIG_CFI_CLANG
+struct bpf_insn;
+
+/* Must match bpf_func_t / DEFINE_BPF_PROG_RUN() */
+extern unsigned int __bpf_prog_runX(const void *ctx,
+ const struct bpf_insn *insn);
+
+/*
+ * Force a reference to the external symbol so the compiler generates
+ * __kcfi_typid.
+ */
+__ADDRESSABLE(__bpf_prog_runX);
+
+/* u32 __ro_after_init cfi_bpf_hash = __kcfi_typeid___bpf_prog_runX; */
+asm (
+" .pushsection .data..ro_after_init,\"aw\",@progbits \n"
+" .type cfi_bpf_hash,@object \n"
+" .globl cfi_bpf_hash \n"
+" .p2align 2, 0x0 \n"
+"cfi_bpf_hash: \n"
+" .word __kcfi_typeid___bpf_prog_runX \n"
+" .size cfi_bpf_hash, 4 \n"
+" .popsection \n"
+);
+
+/* Must match bpf_callback_t */
+extern u64 __bpf_callback_fn(u64, u64, u64, u64, u64);
+
+__ADDRESSABLE(__bpf_callback_fn);
+
+/* u32 __ro_after_init cfi_bpf_subprog_hash = __kcfi_typeid___bpf_callback_fn; */
+asm (
+" .pushsection .data..ro_after_init,\"aw\",@progbits \n"
+" .type cfi_bpf_subprog_hash,@object \n"
+" .globl cfi_bpf_subprog_hash \n"
+" .p2align 2, 0x0 \n"
+"cfi_bpf_subprog_hash: \n"
+" .word __kcfi_typeid___bpf_callback_fn \n"
+" .size cfi_bpf_subprog_hash, 4 \n"
+" .popsection \n"
+);
+
+u32 cfi_get_func_hash(void *func)
+{
+ u32 hash;
+
+ if (get_kernel_nofault(hash, func - cfi_get_offset()))
+ return 0;
+
+ return hash;
+}
+#endif
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index bc16eb694657..2372812bb47c 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -17,6 +17,7 @@
#include <asm/asm-extable.h>
#include <asm/byteorder.h>
#include <asm/cacheflush.h>
+#include <asm/cfi.h>
#include <asm/debug-monitors.h>
#include <asm/insn.h>
#include <asm/patching.h>
@@ -158,6 +159,12 @@ static inline void emit_bti(u32 insn, struct jit_ctx *ctx)
emit(insn, ctx);
}
+static inline void emit_kcfi(u32 hash, struct jit_ctx *ctx)
+{
+ if (IS_ENABLED(CONFIG_CFI_CLANG))
+ emit(hash, ctx);
+}
+
/*
* Kernel addresses in the vmalloc space use at most 48 bits, and the
* remaining bits are guaranteed to be 0x1. So we can compose the address
@@ -295,7 +302,7 @@ static bool is_lsi_offset(int offset, int scale)
#define PROLOGUE_OFFSET (BTI_INSNS + 2 + PAC_INSNS + 8)
static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf,
- bool is_exception_cb)
+ bool is_exception_cb, bool is_subprog)
{
const struct bpf_prog *prog = ctx->prog;
const bool is_main_prog = !bpf_is_subprog(prog);
@@ -306,7 +313,6 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf,
const u8 fp = bpf2a64[BPF_REG_FP];
const u8 tcc = bpf2a64[TCALL_CNT];
const u8 fpb = bpf2a64[FP_BOTTOM];
- const int idx0 = ctx->idx;
int cur_offset;
/*
@@ -332,6 +338,8 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf,
*
*/
+ emit_kcfi(is_subprog ? cfi_bpf_subprog_hash : cfi_bpf_hash, ctx);
+ const int idx0 = ctx->idx;
/* bpf function may be invoked by 3 instruction types:
* 1. bl, attached via freplace to bpf prog via short jump
* 2. br, attached via freplace to bpf prog via long jump
@@ -1648,7 +1656,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
* BPF line info needs ctx->offset[i] to be the offset of
* instruction[i] in jited image, so build prologue first.
*/
- if (build_prologue(&ctx, was_classic, prog->aux->exception_cb)) {
+ if (build_prologue(&ctx, was_classic, prog->aux->exception_cb,
+ bpf_is_subprog(prog))) {
prog = orig_prog;
goto out_off;
}
@@ -1696,7 +1705,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
ctx.idx = 0;
ctx.exentry_idx = 0;
- build_prologue(&ctx, was_classic, prog->aux->exception_cb);
+ build_prologue(&ctx, was_classic, prog->aux->exception_cb,
+ bpf_is_subprog(prog));
if (build_body(&ctx, extra_pass)) {
prog = orig_prog;
@@ -1745,9 +1755,9 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
jit_data->ro_header = ro_header;
}
- prog->bpf_func = (void *)ctx.ro_image;
+ prog->bpf_func = (void *)ctx.ro_image + cfi_get_offset();
prog->jited = 1;
- prog->jited_len = prog_size;
+ prog->jited_len = prog_size - cfi_get_offset();
if (!prog->is_func || extra_pass) {
int i;
@@ -2011,6 +2021,12 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im,
/* return address locates above FP */
retaddr_off = stack_size + 8;
+ if (flags & BPF_TRAMP_F_INDIRECT) {
+ /*
+ * Indirect call for bpf_struct_ops
+ */
+ emit_kcfi(cfi_get_func_hash(func_addr), ctx);
+ }
/* bpf trampoline may be invoked by 3 instruction types:
* 1. bl, attached to bpf prog or kernel function via short jump
* 2. br, attached to bpf prog or kernel function via long jump
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 0/4] NXP S32G3 SoC initial bring-up
From: Wadim Mueller @ 2024-03-24 21:43 UTC (permalink / raw)
Cc: Wadim Mueller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Alexander Stein, Marek Vasut,
Gregor Herburger, Hugo Villeneuve, Joao Paulo Goncalves,
Markus Niebel, Marco Felsch, Matthias Schiffer, Stefan Wahren,
Bjorn Helgaas, Philippe Schenker, Josua Mayer, Li Yang,
devicetree, linux-kernel, linux-mmc, linux-arm-kernel,
linux-serial
This series brings up initial support for the NXP S32G3 SoC,
used on the S32G-VNP-RDB3 board [1].
The following features are supported in this initial port:
* Devicetree for the S32G-VNP-RDB3
* UART (fsl-linflexuart) with earlycon support
* SDHC: fsl-imx-esdhc (SD/eMMC)
== Changes since v3 ==:
* changed dts license to dual license model (GPL-2.0+ OR BSD-3-Clause)
* fixed wrong s32g3 schema binding for fsl-imx-esdhc
* merged s32-linflexuart schema binding for s32g2 and s32g3 into one enum
* sorted s32g3 dts nodes alpha-numerically by the node name
* sorted s32g3 soc nodes by unit address
[1] https://www.nxp.com/design/design-center/designs/s32g3-vehicle-networking-reference-design:S32G-VNP-RDB3
Wadim Mueller (4):
dt-bindings: arm: fsl: add NXP S32G3 board
dt-bindings: serial: fsl-linflexuart: add compatible for S32G3
dt-bindings: mmc: fsl-imx-esdhc: add NXP S32G3 support
arm64: dts: S32G3: Introduce device tree for S32G-VNP-RDB3
.../devicetree/bindings/arm/fsl.yaml | 6 +
.../bindings/mmc/fsl-imx-esdhc.yaml | 3 +
.../bindings/serial/fsl,s32-linflexuart.yaml | 4 +-
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/s32g3.dtsi | 233 ++++++++++++++++++
.../boot/dts/freescale/s32g399a-rdb3.dts | 45 ++++
6 files changed, 291 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/freescale/s32g3.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/s32g399a-rdb3.dts
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/4] dt-bindings: arm: fsl: add NXP S32G3 board
From: Wadim Mueller @ 2024-03-24 21:43 UTC (permalink / raw)
Cc: Wadim Mueller, Krzysztof Kozlowski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby, Chester Lin,
Andreas Färber, Matthias Brugger, NXP S32 Linux Team,
Tim Harvey, Alexander Stein, Marek Vasut, Gregor Herburger,
Hugo Villeneuve, Joao Paulo Goncalves, Markus Niebel,
Marco Felsch, Matthias Schiffer, Stefan Wahren, Bjorn Helgaas,
Josua Mayer, Li Yang, devicetree, linux-kernel, linux-mmc,
linux-arm-kernel, linux-serial
In-Reply-To: <20240324214329.29988-1-wafgo01@gmail.com>
Add bindings for NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) [1]
[1]
https://www.nxp.com/design/design-center/designs/s32g3-vehicle-networking-reference-design:S32G-VNP-RDB3
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 228dcc5c7d6f..23bf1d7f95b1 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1503,6 +1503,12 @@ properties:
- nxp,s32g274a-rdb2
- const: nxp,s32g2
+ - description: S32G3 based Boards
+ items:
+ - enum:
+ - nxp,s32g399a-rdb3
+ - const: nxp,s32g3
+
- description: S32V234 based Boards
items:
- enum:
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 2/4] dt-bindings: serial: fsl-linflexuart: add compatible for S32G3
From: Wadim Mueller @ 2024-03-24 21:43 UTC (permalink / raw)
Cc: Wadim Mueller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Marco Felsch, Gregor Herburger,
Marek Vasut, Joao Paulo Goncalves, Markus Niebel,
Matthias Schiffer, Stefan Wahren, Bjorn Helgaas,
Philippe Schenker, Yannic Moog, Li Yang, devicetree, linux-kernel,
linux-mmc, linux-arm-kernel, linux-serial
In-Reply-To: <20240324214329.29988-1-wafgo01@gmail.com>
Add a compatible string for the uart binding of NXP S32G3 platforms. Here
we use "s32v234-linflexuart" as fallback since the current linflexuart
driver can still work on S32G3.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
---
.../devicetree/bindings/serial/fsl,s32-linflexuart.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
index 7a105551fa6a..4171f524a928 100644
--- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
@@ -23,7 +23,9 @@ properties:
oneOf:
- const: fsl,s32v234-linflexuart
- items:
- - const: nxp,s32g2-linflexuart
+ - enum:
+ - nxp,s32g2-linflexuart
+ - nxp,s32g3-linflexuart
- const: fsl,s32v234-linflexuart
reg:
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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