* Re: [PATCH net-next 1/2] dt-bindings: net: mediatek: add WED RX binding for MT7981 eth driver
From: AngeloGioacchino Del Regno @ 2023-04-20 7:40 UTC (permalink / raw)
To: Daniel Golle, devicetree, netdev, linux-mediatek,
linux-arm-kernel, linux-kernel, Rob Herring, Krzysztof Kozlowski,
Felix Fietkau, John Crispin, Sean Wang, Mark Lee,
Lorenzo Bianconi, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Matthias Brugger
In-Reply-To: <e970078a937c39067d5733ddafb64d0eb56ac474.1681930898.git.daniel@makrotopia.org>
Il 19/04/23 21:04, Daniel Golle ha scritto:
> Add compatible string for mediatek,mt7981-wed as MT7981 also supports
> RX WED just like MT7986, but needs a different firmware file.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> .../devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml
> index 5c223cb063d48..2c5e04c9adcc8 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml
> @@ -21,6 +21,7 @@ properties:
> - enum:
> - mediatek,mt7622-wed
> - mediatek,mt7986-wed
> + - mediatek,mt7981-wed
Please, keep entries ordered. 7891 goes before 7986.
Cheers,
Angelo
_______________________________________________
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 2/2] pwm: mediatek: Add support for MT7981
From: AngeloGioacchino Del Regno @ 2023-04-20 7:47 UTC (permalink / raw)
To: Daniel Golle, linux-pwm, linux-mediatek, linux-arm-kernel,
linux-kernel, Thierry Reding, Uwe Kleine-König,
Matthias Brugger, John Crispin
In-Reply-To: <e22d8e66558f094b544aa208c722a7f88fd0bde1.1681932165.git.daniel@makrotopia.org>
Il 19/04/23 21:25, Daniel Golle ha scritto:
> The PWM unit on MT7981 uses different register offsets than previous
> MediaTek PWM units. Add support for these new offsets and add support
> for PWM on MT7981 which has 3 PWM channels, one of them is typically
> used for a temperature controlled fan.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> drivers/pwm/pwm-mediatek.c | 54 ++++++++++++++++++++++++++++++++------
> 1 file changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> index 5b5eeaff35da6..2bfb5bedf570b 100644
> --- a/drivers/pwm/pwm-mediatek.c
> +++ b/drivers/pwm/pwm-mediatek.c
> @@ -34,10 +34,14 @@
>
> #define PWM_CLK_DIV_MAX 7
>
> +#define REG_V1 1
> +#define REG_V2 2
> +
> struct pwm_mediatek_of_data {
> unsigned int num_pwms;
> bool pwm45_fixup;
> bool has_ck_26m_sel;
> + u8 reg_ver;
You're overcomplicating this one... checking for a register version and then
deciding at every pwm_mediatek_writel() call what to use...
It's way simpler than that!
Pass a pointer to the register array in pwm_mediatek_of_data and then...
> };
>
> /**
> @@ -59,10 +63,14 @@ struct pwm_mediatek_chip {
> const struct pwm_mediatek_of_data *soc;
> };
>
> -static const unsigned int pwm_mediatek_reg_offset[] = {
> +static const unsigned int mtk_pwm_reg_offset_v1[] = {
> 0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
> };
>
> +static const unsigned int mtk_pwm_reg_offset_v2[] = {
> + 0x0080, 0x00c0, 0x0100, 0x0140, 0x0180, 0x1c0, 0x200, 0x0240
> +};
> +
> static inline struct pwm_mediatek_chip *
> to_pwm_mediatek_chip(struct pwm_chip *chip)
> {
> @@ -111,7 +119,19 @@ static inline void pwm_mediatek_writel(struct pwm_mediatek_chip *chip,
> unsigned int num, unsigned int offset,
> u32 value)
> {
> - writel(value, chip->regs + pwm_mediatek_reg_offset[num] + offset);
...this simply becomes:
writel(value, chip->regs + chip->reg_offset[num] + offset);
> + u32 pwm_offset;
> +
> + switch (chip->soc->reg_ver) {
> + case REG_V2:
> + pwm_offset = mtk_pwm_reg_offset_v2[num];
> + break;
> +
> + case REG_V1:
> + default:
> + pwm_offset = mtk_pwm_reg_offset_v1[num];
> + }
> +
> + writel(value, chip->regs + pwm_offset + offset);
> }
>
> static int pwm_mediatek_config(struct pwm_chip *chip, struct pwm_device *pwm,
> @@ -285,60 +305,77 @@ static const struct pwm_mediatek_of_data mt2712_pwm_data = {
> .num_pwms = 8,
> .pwm45_fixup = false,
> .has_ck_26m_sel = false,
> + .reg_ver = REG_V1,
...so instead of assigning that, you'd be assigning
.reg_offset = mtk_pwm_reg_offset_v1;
Better, right? :-)
Cheers,
Angelo
_______________________________________________
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] dt-bindings: pwm: mediatek: Add mediatek,mt7981 compatible
From: AngeloGioacchino Del Regno @ 2023-04-20 7:48 UTC (permalink / raw)
To: Daniel Golle, devicetree, linux-pwm, linux-mediatek,
linux-arm-kernel, linux-kernel, Rob Herring, Krzysztof Kozlowski,
Thierry Reding, Uwe Kleine-König, Matthias Brugger,
John Crispin
In-Reply-To: <4877689269af862ea9ddd199d8aa96b2d7fcf6fe.1681932165.git.daniel@makrotopia.org>
Il 19/04/23 21:24, Daniel Golle ha scritto:
> Add compatible string for the PWM unit found of the MediaTek MT7981 SoC.
> This is in preparation to adding support in the pwm-mediatek.c driver.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
_______________________________________________
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 2/2] input: imx_sc_key: add wakeup support
From: Peng Fan @ 2023-04-20 7:54 UTC (permalink / raw)
To: Ulf Hansson, Peng Fan
Cc: Dmitry Torokhov, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
Aisheng Dong, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx
In-Reply-To: <CAPDyKFruZOP65k0SEEmCGtopp8ywJA92ChGZs2ZR=nVxqUC0OQ@mail.gmail.com>
Dmitry,Ulf
On 4/18/2023 4:32 PM, Ulf Hansson wrote:
> On Wed, 12 Apr 2023 at 17:58, Peng Fan <peng.fan@nxp.com> wrote:
>>
>> +Ulf
>>
>>> Subject: RE: [PATCH 2/2] input: imx_sc_key: add wakeup support
>>>
>>>> Subject: Re: [PATCH 2/2] input: imx_sc_key: add wakeup support
>>>>
>>>> On Thu, Mar 23, 2023 at 05:31:41PM +0800, Peng Fan (OSS) wrote:
>>>>> From: Peng Fan <peng.fan@nxp.com>
>>>>>
>>>>> Add support for waking up from system wide suspend.
>>>>>
>>>>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>>>> ---
>>>>> drivers/input/keyboard/imx_sc_key.c | 2 ++
>>>>> 1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/drivers/input/keyboard/imx_sc_key.c
>>>> b/drivers/input/keyboard/imx_sc_key.c
>>>>> index d18839f1f4f6..234f23cf9990 100644
>>>>> --- a/drivers/input/keyboard/imx_sc_key.c
>>>>> +++ b/drivers/input/keyboard/imx_sc_key.c
>>>>> @@ -151,6 +151,8 @@ static int imx_sc_key_probe(struct
>>>> platform_device *pdev)
>>>>> priv->input = input;
>>>>> platform_set_drvdata(pdev, priv);
>>>>>
>>>>> + device_init_wakeup(&pdev->dev,
>>>> device_property_read_bool(&pdev->dev, "wakeup-source"));
>>>>> +
>>>>
>>>> I wonder - could we move this to the device core?
>>>
>>> I see lots device drivers parse wakeup-source, so I also follow That. Not sure
>>> whether could move this feature to device core, but anyway I could give a
>>> try.
>>
>> Do you think it is feasible to move device_init_wakeup into device core
>> part?
>
> Not sure it would really improve things that much. Subsystems/drivers
> need to make additional configurations based upon whether this DT
> property is set anyway.
>
> Perhaps an option is to make this a part of the common input subsystem
> helper functions instead? Other subsystems do this, but I am not sure
> how feasible that would be in the input case.
How do you think of below patch?
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 37e876d45eb9..a98a9f37e1f5 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -2402,6 +2402,10 @@ int input_register_device(struct input_dev *dev)
__func__, dev_name(&dev->dev));
devres_add(dev->dev.parent, devres);
}
+
+ if (device_property_read_bool(input->dev.parent, "wakeup-source"))
+ device_init_wakeup(&pdev->dev, true);
+
return 0;
err_device_del:
Thanks,
Peng.
>
> Kind regards
> Uffe
_______________________________________________
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 v3 1/2] dt-bindings: usb: mtk-xhci: add an optional frame count clock
From: Greg Kroah-Hartman @ 2023-04-20 8:07 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Rob Herring, Krzysztof Kozlowski, Matthias Brugger,
AngeloGioacchino Del Regno, Mathias Nyman, linux-usb,
linux-arm-kernel, linux-mediatek, devicetree, linux-kernel,
Tianping Fang, Krzysztof Kozlowski
In-Reply-To: <20230417024213.17973-1-chunfeng.yun@mediatek.com>
On Mon, Apr 17, 2023 at 10:42:12AM +0800, Chunfeng Yun wrote:
> Add optional clock 'frmcnt_ck' used on 4nm or advanced process SoC
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v3: add acked-by and Reviewed-by tags
There's never a need to do this as our tools pick them up automatically.
This resend did nothing but move it later in the queue to review :(
thanks,
greg k-h
_______________________________________________
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 0/2] KVM: arm64: Fix bugs related to mp_state updates
From: Marc Zyngier @ 2023-04-20 8:08 UTC (permalink / raw)
To: kvmarm, Reiji Watanabe, Oliver Upton
Cc: Suzuki K Poulose, Raghavendra Rao Anata, James Morse,
Paolo Bonzini, linux-arm-kernel, Zenghui Yu, Will Deacon,
Ricardo Koller, Alexandru Elisei, Jing Zhang, kvm
In-Reply-To: <20230419021852.2981107-1-reijiw@google.com>
On Tue, 18 Apr 2023 19:18:50 -0700, Reiji Watanabe wrote:
> This series adds fixes that were missing in the patch [1].
>
> The patch [1] added the mp_state_lock to serialize writes to
> kvm_vcpu_arch::{mp_state, reset_state}, and promoted all
> accessors of mp_state to {READ,WRITE}_ONCE() as readers do not
> acquire the mp_state_lock.
>
> [...]
Applied to next, thanks!
[1/2] KVM: arm64: Acquire mp_state_lock in kvm_arch_vcpu_ioctl_vcpu_init()
commit: 4ff910be01c0ca28c2ea8b354dd47a3a17524489
[2/2] KVM: arm64: Have kvm_psci_vcpu_on() use WRITE_ONCE() to update mp_state
commit: a189884bdc9238aeba941c50f02e25eb584fafed
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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 V7 10/10] ARM64: dts: imx7ulp: update usb compatible
From: Greg KH @ 2023-04-20 8:10 UTC (permalink / raw)
To: Shawn Guo
Cc: Peng Fan, Peng Fan (OSS), robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, s.hauer@pengutronix.de,
Xu Yang, kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jun Li
In-Reply-To: <20230406014013.GJ11367@dragon>
On Thu, Apr 06, 2023 at 09:40:13AM +0800, Shawn Guo wrote:
> On Thu, Apr 06, 2023 at 01:18:43AM +0000, Peng Fan wrote:
> > Hi Shawn,
> >
> > > Subject: Re: [PATCH V7 10/10] ARM64: dts: imx7ulp: update usb compatible
> > >
> > > On Wed, Mar 22, 2023 at 01:25:04PM +0800, Peng Fan (OSS) wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >
> > > > Per binding doc, update the compatible
> > > >
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > >
> > > ARM: dts: imx7ulp: ...
> > >
> > > Fixed it up and applied all DTS patches.
> > [Peng Fan]
> >
> > Thanks for the fix. But I think Greg already applied the patchset.
>
> Okay, I will drop them from my tree, but ...
>
> Greg,
>
> May I suggest a couple of things on the future process?
>
> - Could you leave i.MX DTS patches to me, so that we can avoid potential
> merge conflicts?
How am I supposed to know this? Our tools take the whole patch series,
not individual ones. If someone wants patches to go through different
trees, then they need to submit them as different patch series,
otherwise it makes no sense.
> - Would you update your patch robot to reply the applying message to all
> recipients, so that everyone knows the status?
Can't really do that, it only responds to those that are on the patch
signed-off-by list itself, as the other cc: metadata is gone after the
patch is applied.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] optee: fix uninited async notif value
From: Etienne Carriere @ 2023-04-20 7:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, Jens Wiklander, Sumit Garg, Ard Biesheuvel,
op-tee, Etienne Carriere, kernel test robot, Dan Carpenter
Fixes an uninitialized variable in irq_handler() that could lead to
unpredictable behavior in case OP-TEE fails to handle SMC function ID
OPTEE_SMC_GET_ASYNC_NOTIF_VALUE. This change ensures that in that case
get_async_notif_value() properly reports there are no notification
event.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/202304200755.OoiuclDZ-lkp@intel.com/
Reported-by: Dan Carpenter <error27@gmail.com>
Link: https://lore.kernel.org/all/d9b7f69b-c737-4cb3-8e74-79fe00c934f9@kili.mountain/
Fixes: 6749e69c4dad ("optee: add asynchronous notifications")
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
drivers/tee/optee/smc_abi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
index de7ac9a46354..6d3705770755 100644
--- a/drivers/tee/optee/smc_abi.c
+++ b/drivers/tee/optee/smc_abi.c
@@ -1001,8 +1001,10 @@ static u32 get_async_notif_value(optee_invoke_fn *invoke_fn, bool *value_valid,
invoke_fn(OPTEE_SMC_GET_ASYNC_NOTIF_VALUE, 0, 0, 0, 0, 0, 0, 0, &res);
- if (res.a0)
+ if (res.a0) {
+ *value_valid = false;
return 0;
+ }
*value_valid = (res.a2 & OPTEE_SMC_ASYNC_NOTIF_VALUE_VALID);
*value_pending = (res.a2 & OPTEE_SMC_ASYNC_NOTIF_VALUE_PENDING);
return res.a1;
--
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
* Re: [PATCH v1 1/2] KVM: arm64: Acquire mp_state_lock in kvm_arch_vcpu_ioctl_vcpu_init()
From: Marc Zyngier @ 2023-04-20 8:16 UTC (permalink / raw)
To: Reiji Watanabe
Cc: Oliver Upton, kvmarm, kvm, linux-arm-kernel, James Morse,
Alexandru Elisei, Zenghui Yu, Suzuki K Poulose, Paolo Bonzini,
Ricardo Koller, Jing Zhang, Raghavendra Rao Anata, Will Deacon
In-Reply-To: <20230420021302.iyl3pqo3lg6lpabv@google.com>
On Thu, 20 Apr 2023 03:13:02 +0100,
Reiji Watanabe <reijiw@google.com> wrote:
>
> Hi Marc,
>
> On Wed, Apr 19, 2023 at 08:12:45AM +0100, Marc Zyngier wrote:
> > On Wed, 19 Apr 2023 03:18:51 +0100,
> > Reiji Watanabe <reijiw@google.com> wrote:
> > > kvm_arch_vcpu_ioctl_vcpu_init() doesn't acquire mp_state_lock
> > > when setting the mp_state to KVM_MP_STATE_RUNNABLE. Fix the
> > > code to acquire the lock.
> > >
> > > Signed-off-by: Reiji Watanabe <reijiw@google.com>
> > > ---
> > > arch/arm64/kvm/arm.c | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index fbafcbbcc463..388aa4f18f21 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -1244,8 +1244,11 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
> > > */
> > > if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
> > > kvm_arm_vcpu_power_off(vcpu);
> > > - else
> > > + else {
> > > + spin_lock(&vcpu->arch.mp_state_lock);
> > > WRITE_ONCE(vcpu->arch.mp_state.mp_state, KVM_MP_STATE_RUNNABLE);
> > > + spin_unlock(&vcpu->arch.mp_state_lock);
> > > + }
> > >
> > > return 0;
> > > }
> >
> > I'm not entirely convinced that this fixes anything. What does the
> > lock hazard against given that the write is atomic? But maybe a
>
> It appears that kvm_psci_vcpu_on() expects the vCPU's mp_state
> to not be changed by holding the lock. Although I don't think this
> code practically causes any real issues now, I am a little concerned
> about leaving one instance that updates mpstate without acquiring the
> lock, in terms of future maintenance, as holding the lock won't prevent
> mp_state from being updated.
>
> What do you think ?
Right, fair enough. It is probably better to take the lock and not
have to think of this sort of things... I'm becoming more lazy by the
minute!
>
> > slightly more readable of this would be to expand the critical section
> > this way:
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index 4ec888fdd4f7..bb21d0c25de7 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -1246,11 +1246,15 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
> > /*
> > * Handle the "start in power-off" case.
> > */
> > + spin_lock(&vcpu->arch.mp_state_lock);
> > +
> > if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
> > - kvm_arm_vcpu_power_off(vcpu);
> > + __kvm_arm_vcpu_power_off(vcpu);
> > else
> > WRITE_ONCE(vcpu->arch.mp_state.mp_state, KVM_MP_STATE_RUNNABLE);
> >
> > + spin_unlock(&vcpu->arch.mp_state_lock);
> > +
> > return 0;
> > }
> >
> > Thoughts?
>
> Yes, it looks better!
Cool. I've applied this change to your patch, applied the series to
the lock inversion branch, and remerged the branch in -next.
We're getting there! ;-)
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* W sprawie samochodu
From: Krystian Wieczorek @ 2023-04-20 8:11 UTC (permalink / raw)
To: linux-arm-kernel
Dzień dobry,
chcielibyśmy zapewnić Państwu kompleksowe rozwiązania, jeśli chodzi o system monitoringu GPS.
Precyzyjne monitorowanie pojazdów na mapach cyfrowych, śledzenie ich parametrów eksploatacyjnych w czasie rzeczywistym oraz kontrola paliwa to kluczowe funkcjonalności naszego systemu.
Organizowanie pracy pracowników jest dzięki temu prostsze i bardziej efektywne, a oszczędności i optymalizacja w zakresie ponoszonych kosztów, mają dla każdego przedsiębiorcy ogromne znaczenie.
Dopasujemy naszą ofertę do Państwa oczekiwań i potrzeb organizacji. Czy moglibyśmy porozmawiać o naszej propozycji?
Pozdrawiam
Krystian Wieczorek
_______________________________________________
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 v2 1/1] arm: dts: sunxi: Add ICnova A20 ADB4006 board support
From: Ludwig Kormann @ 2023-04-20 8:23 UTC (permalink / raw)
To: samuel, jernej.skrabec, wens, robh+dt, krzysztof.kozlowski+dt,
andre.przywara
Cc: linux-arm-kernel, devicetree, linux-sunxi, linux-kernel
In-Reply-To: <b84537c0-cb58-621a-2b6d-3bbaac5091de@linaro.org>
Hi,
thanks for your review.
Am 19.04.23 um 15:05 schrieb Krzysztof Kozlowski:
> On 19/04/2023 14:12, Ludwig Kormann wrote:
>> Add board support for ICnova A20 SomPi compute module on
>> ICnova ADB4006 development board.
>>
>> Specification:
>> SoM
>> - Processor: Allwinner A20 Cortex-A7 Dual Core at 1GHz
>> - 512MB DDR3 RAM
>> - Fast Ethernet (Phy: Realtek RTL8201CP)
>> ADB4006
>> - I2C
>> - 2x USB 2.0
>> - 1x Fast Ethernet port
>> - 1x SATA
>> - 2x buttons (PWRON, Boot)
>> - 2x LEDS
>> - serial console
>> - HDMI
>> - µSD-Card slot
>> - Audio Line-In / Line-Out
>> - GPIO pinheaders
>>
>> https://wiki.in-circuit.de/index.php5?title=ICnova_ADB4006
>> https://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
>>
>> ---
>>
>> changes in v2:
>> - use short licensing header
>> - remove deprecated elements from led nodes
>> - disable csi power supply
>> - add missing pins in usbphy node
>> - split dts into SoM dtsi and carrier board dts
>>
>> v1 of this patch was sent to the uboot mailing list [1].
>>
>> [1] https://lists.denx.de/pipermail/u-boot/2023-April/514605.html
>>
>> Signed-off-by: Ludwig Kormann <ludwig.kormann@in-circuit.de>
>> ---
>> .../devicetree/bindings/arm/sunxi.yaml | 6 +
> Bindings are always separate patches. checkpatch did not complain?
>
I just ran checkpatch.pl, you're right, it does complain. I will move
the bindings to a seperate patch.
>> arch/arm/boot/dts/Makefile | 1 +
>> .../boot/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 ++++++++++++++++++
>> arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi | 63 ++++++++
>> 4 files changed, 207 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
>>
>> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
>> b/Documentation/devicetree/bindings/arm/sunxi.yaml
>> index 013821f4a7b8..12f0c236f17b 100644
>> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
>> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
>> @@ -305,6 +305,12 @@ properties:
>> - const: allwinner,i12-tvbox
>> - const: allwinner,sun7i-a20
>> + - description: ICNova A20 ADB4006
>> + items:
>> + - const: incircuit,icnova-a20-adb4006
>> + - const: incircuit,icnova-a20
>> + - const: allwinner,sun7i-a20
>> +
>> - description: ICNova A20 SWAC
>> items:
>> - const: incircuit,icnova-a20-swac
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 3cc32722c394..b6b408417261 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -1321,6 +1321,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>> sun7i-a20-hummingbird.dtb \
>> sun7i-a20-itead-ibox.dtb \
>> sun7i-a20-i12-tvbox.dtb \
>> + sun7i-a20-icnova-a20-adb4006.dtb \
>> sun7i-a20-icnova-swac.dtb \
>> sun7i-a20-lamobo-r1.dtb \
>> sun7i-a20-linutronix-testbox-v2.dtb \
>> diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> new file mode 100644
>> index 000000000000..c1606c085e4e
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> @@ -0,0 +1,137 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> Unusual license. Are you sure you are ok with GPLv5.0?
Thanks for the hint. I will remove the '+' and update the licensing to
"GPL-2.0 OR MIT".
>
> Also, at the end of your files - drop stray blank lines.
I will remove them.
I will implement the changes and provide patch series v3.
kind regards,
Ludwig
>
> Best regards,
> Krzysztof
>
_______________________________________________
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 00/37] cpu/hotplug, x86: Reworked parallel CPU bringup
From: Thomas Gleixner @ 2023-04-20 8:32 UTC (permalink / raw)
To: Andrew Cooper, Paul Menzel
Cc: linux-kernel, x86, David Woodhouse, Brian Gerst,
Arjan van de Veen, Paolo Bonzini, Paul McKenney, Tom Lendacky,
Sean Christopherson, Oleksandr Natalenko, Guilherme G. Piccoli,
Piotr Gorski, David Woodhouse, Usama Arif, Jürgen Groß,
Boris Ostrovsky, xen-devel, Russell King, Arnd Bergmann,
linux-arm-kernel, Catalin Marinas, Will Deacon, Guo Ren,
linux-csky, Thomas Bogendoerfer, linux-mips,
James E. J. Bottomley, Helge Deller, linux-parisc, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Mark Rutland, Sabin Rapan
In-Reply-To: <c2aaa4fb-a5ba-d5bf-634a-dcf4fd8ad246@citrix.com>
On Wed, Apr 19 2023 at 17:21, Andrew Cooper wrote:
> On 19/04/2023 2:50 pm, Andrew Cooper wrote:
>> What I'm confused by is why this system boots in the first place. I can
>> only think that's is a system which only has 4-bit APIC IDs, and happens
>> to function when bit 4 gets truncated off the top of the SIPI destination...
>
> https://www.amd.com/system/files/TechDocs/42300_15h_Mod_10h-1Fh_BKDG.pdf
>
> This system does still require the IO-APICs to be at 0, and the LAPICs
> to start at some offset, which is clearly 16 in this case. Also, this
> system has configurable 4-bit or 8-bit wide APIC IDs, and I can't tell
> which mode is active just from the manual.
That document contradicts itself:
"The ApicId of core j must be enumerated/assigned as:
ApicId[core=j] = (OFFSET_IDX) * MNC + j
Where OFFSET_IDX is an integer offset (0 to N) used to shift up the
core ApicId values to allow room for IOAPIC devices.
It is recommended that BIOS use the following APIC ID assignments for
the broadest operating system sup- port. Given N = MNC and M =
Number_Of_IOAPICs:
• Assign the core ApicId’s first from 0 to N-1, and the IOAPIC IDs
from N to N+(M-1)."
Oh well. If the rest of these docs is of the same quality then it's not
a surprise that BIOSes are trainwrecks.
> But, it does mean that the BIOS has genuinely modified the APIC IDs of
> the logic processors. This does highlight an error in reasoning with
> the parallel bringup code.
Yes.
> For xAPIC, the APIC_ID register is writeable (at least, model
> specifically), and CPUID is only the value it would have had at reset.
> So the AP bringup logic can't actually use CPUID reliably.
>
> This was changed in x2APIC, which made the x2APIC_ID immutable.
>
> I don't see an option other than the AP bringup code query for xAPIC vs
> x2APIC mode, and either looking at the real APIC_ID register, or falling
> back to CPUID.
I'm pondering to simply deny parallel mode if x2APIC is not there.
Thanks,
tglx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [linux-next:master] BUILD REGRESSION 3cdbc01c40e34c57697f8934f2727a88551696be
From: kernel test robot @ 2023-04-20 8:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Mark Brown, op-tee, linux-xfs, linux-mediatek, linux-arm-kernel,
linux-acpi, intel-gfx, amd-gfx, Linux Memory Management List
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 3cdbc01c40e34c57697f8934f2727a88551696be Add linux-next specific files for 20230419
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202304102354.Q4VOXGTE-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202304200812.6UqNDVZy-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202304201027.2upm4i0C-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202304201216.YgbKeHUJ-lkp@intel.com
Error/Warning: (recently discovered and may have been fixed)
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:184:19: warning: variable 'dmub' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.c:138:15: warning: variable 'feature_support' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:124:14: warning: no previous prototype for function 'dmub_abm_get_current_backlight' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:135:14: warning: no previous prototype for function 'dmub_abm_get_target_backlight' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:146:6: warning: no previous prototype for function 'dmub_abm_set_level' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:167:6: warning: no previous prototype for function 'dmub_abm_set_ambient_level' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:189:6: warning: no previous prototype for function 'dmub_abm_init_config' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:221:6: warning: no previous prototype for function 'dmub_abm_set_pause' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:241:6: warning: no previous prototype for function 'dmub_abm_set_pipe' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:263:6: warning: no previous prototype for function 'dmub_abm_set_backlight_level' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:83:6: warning: no previous prototype for function 'dmub_abm_init' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:351:13: warning: variable 'bw_needed' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:352:25: warning: variable 'link' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:451:16: warning: variable 'j' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1049:6: warning: no previous prototype for 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1049:6: warning: no previous prototype for function 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1072:6: warning: no previous prototype for 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:48:38: warning: unused variable 'golden_settings_gc_9_4_3' [-Wunused-const-variable]
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line:
drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for i915_vma_offset(). Prototype was for i915_vma_size() instead
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is uninitialized when used here [-Wuninitialized]
ld.lld: error: .btf.vmlinux.bin.o: unknown file type
phy-mtk-hdmi-mt8195.c:(.text+0x2e2): undefined reference to `__floatundidf'
phy-mtk-hdmi-mt8195.c:(.text+0x2f4): undefined reference to `__ltdf2'
phy-mtk-hdmi-mt8195.c:(.text+0x344): undefined reference to `__gedf2'
riscv64-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x312): undefined reference to `__gedf2'
riscv64-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x32c): undefined reference to `__ltdf2'
Unverified Error/Warning (likely false positive, please contact us if interested):
drivers/acpi/property.c:985 acpi_data_prop_read_single() error: potentially dereferencing uninitialized 'obj'.
drivers/firmware/smccc/smccc.c:20:21: sparse: sparse: symbol 'smccc_soc_id_version' was not declared. Should it be static?
drivers/firmware/smccc/smccc.c:21:21: sparse: sparse: symbol 'smccc_soc_id_revision' was not declared. Should it be static?
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:240 mtk_hdmi_pll_calc() warn: impossible condition '(tmds_clk < 1.483500e+02 * 1000000) => (0.000000e+00-1.844674e+19 < -1.786711e-113)'
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:242 mtk_hdmi_pll_calc() warn: always true condition '(tmds_clk >= 1.483500e+02 * 1000000) => (0-u64max >= -1.786711e-113)'
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:242 mtk_hdmi_pll_calc() warn: impossible condition '(tmds_clk < 2.967000e+02 * 1000000) => (0.000000e+00-1.844674e+19 < -4.419080e+60)'
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:244 mtk_hdmi_pll_calc() warn: always true condition '(tmds_clk >= 2.967000e+02 * 1000000) => (0-u64max >= -4.419080e+60)'
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298 mtk_hdmi_pll_calc() error: uninitialized symbol 'ret'.
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:331 mtk_hdmi_pll_drv_setting() warn: always true condition '(pixel_clk >= 7.417500e+01 * 1000000) => (0-u32max >= -7.223985e-287)'
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:336 mtk_hdmi_pll_drv_setting() warn: impossible condition '(pixel_clk < 7.417500e+01 * 1000000) => (0.000000e+00-4.294967e+09 < -7.223985e-287)'
drivers/tee/optee/smc_abi.c:1021 irq_handler() error: uninitialized symbol 'value_valid'.
drivers/tee/optee/smc_abi.c:1028 irq_handler() error: uninitialized symbol 'value_pending'.
fs/xfs/scrub/refcount.c: xfs_mount.h is included more than once.
fs/xfs/scrub/refcount.c: xfs_trans_resv.h is included more than once.
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- alpha-randconfig-r001-20230420
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- alpha-randconfig-r023-20230420
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arc-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arc-buildonly-randconfig-r004-20230419
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- arc-randconfig-r043-20230420
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm64-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm64-randconfig-m041-20230419
| |-- drivers-tee-optee-smc_abi.c-irq_handler()-error:uninitialized-symbol-value_pending-.
| `-- drivers-tee-optee-smc_abi.c-irq_handler()-error:uninitialized-symbol-value_valid-.
|-- arm64-randconfig-r003-20230417
| `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- arm64-randconfig-s031-20230416
| |-- drivers-firmware-smccc-smccc.c:sparse:sparse:symbol-smccc_soc_id_revision-was-not-declared.-Should-it-be-static
| `-- drivers-firmware-smccc-smccc.c:sparse:sparse:symbol-smccc_soc_id_version-was-not-declared.-Should-it-be-static
|-- csky-randconfig-m041-20230419
| |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-error:uninitialized-symbol-ret-.
| |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:always-true-condition-(tmds_clk-.483500e-)-(-u64max-.786711e-)
| |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:always-true-condition-(tmds_clk-.967000e-)-(-u64max-.419080e-)
| |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:impossible-condition-(tmds_clk-.483500e-)-(.000000e-.844674e-.786711e-)
| |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:impossible-condition-(tmds_clk-.967000e-)-(.000000e-.844674e-.419080e-)
| |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_drv_setting()-warn:always-true-condition-(pixel_clk-.417500e-)-(-u32max-.223985e-)
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_drv_setting()-warn:impossible-condition-(pixel_clk-.417500e-)-(.000000e-.294967e-.223985e-)
|-- csky-randconfig-r024-20230417
| `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- i386-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- i386-randconfig-m021-20230417
| `-- drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-.
|-- ia64-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- ia64-randconfig-r034-20230416
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- ia64-randconfig-s043-20230416
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- loongarch-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- loongarch-defconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- microblaze-randconfig-m041-20230416
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- microblaze-randconfig-r004-20230420
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- mips-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- mips-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- mips-randconfig-c003-20230420
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- mips-randconfig-s041-20230416
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:sparse:sparse:cast-truncates-bits-from-constant-value-(ffff-becomes-ff)
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- openrisc-randconfig-c003-20230416
| `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- parisc-buildonly-randconfig-r003-20230419
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- powerpc-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- riscv-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- riscv-randconfig-r016-20230416
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- riscv-randconfig-s052-20230416
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
| |-- phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__floatundidf
| |-- phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__gedf2
| |-- phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__ltdf2
| |-- riscv64-linux-ld:phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__gedf2
| `-- riscv64-linux-ld:phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__ltdf2
|-- s390-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- sparc-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- sparc64-randconfig-s053-20230416
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- x86_64-allnoconfig
| |-- fs-xfs-scrub-refcount.c:xfs_mount.h-is-included-more-than-once.
| `-- fs-xfs-scrub-refcount.c:xfs_trans_resv.h-is-included-more-than-once.
|-- x86_64-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
`-- x86_64-randconfig-m001-20230417
`-- drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-.
clang_recent_errors
|-- arm64-buildonly-randconfig-r005-20230416
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- arm64-randconfig-r015-20230417
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- arm64-randconfig-r036-20230416
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dc_dmub_srv.c:warning:variable-dmub-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm.c:warning:variable-feature_support-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_get_current_backlight
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_get_target_backlight
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_init
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_init_config
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_ambient_level
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_backlight_level
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_level
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_pause
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_pipe
| |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-function-gfx_v9_4_3_disable_gpa_mode
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:unused-variable-golden_settings_gc_9_4_3
|-- hexagon-randconfig-r023-20230417
| `-- ld.lld:error:.btf.vmlinux.bin.o:unknown-file-type
|-- hexagon-randconfig-r045-20230420
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- mips-randconfig-r021-20230420
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- riscv-buildonly-randconfig-r006-20230419
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- riscv-randconfig-r032-20230416
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
`-- x86_64-randconfig-a011-20230417
|-- drivers-gpu-drm-i915-gt-uc-guc_capture_fwif.h:warning:wrong-kernel-doc-identifier-on-line:
|-- drivers-gpu-drm-i915-i915_pmu.h:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
|-- drivers-gpu-drm-i915-i915_request.h:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
`-- drivers-gpu-drm-i915-i915_vma.h:warning:expecting-prototype-for-i915_vma_offset().-Prototype-was-for-i915_vma_size()-instead
elapsed time: 734m
configs tested: 190
configs skipped: 20
tested configs:
alpha allyesconfig gcc
alpha buildonly-randconfig-r005-20230417 gcc
alpha defconfig gcc
alpha randconfig-r001-20230416 gcc
alpha randconfig-r001-20230420 gcc
alpha randconfig-r003-20230416 gcc
alpha randconfig-r013-20230416 gcc
alpha randconfig-r023-20230420 gcc
arc allyesconfig gcc
arc buildonly-randconfig-r002-20230418 gcc
arc buildonly-randconfig-r004-20230417 gcc
arc buildonly-randconfig-r004-20230419 gcc
arc buildonly-randconfig-r006-20230416 gcc
arc defconfig gcc
arc randconfig-r043-20230416 gcc
arc randconfig-r043-20230417 gcc
arc randconfig-r043-20230419 gcc
arc randconfig-r043-20230420 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm at91_dt_defconfig gcc
arm defconfig gcc
arm ep93xx_defconfig clang
arm hisi_defconfig gcc
arm keystone_defconfig gcc
arm omap1_defconfig clang
arm randconfig-r006-20230416 gcc
arm randconfig-r046-20230416 clang
arm randconfig-r046-20230417 gcc
arm randconfig-r046-20230419 gcc
arm randconfig-r046-20230420 clang
arm tegra_defconfig gcc
arm64 allyesconfig gcc
arm64 buildonly-randconfig-r004-20230418 clang
arm64 buildonly-randconfig-r005-20230416 clang
arm64 buildonly-randconfig-r005-20230419 gcc
arm64 defconfig gcc
arm64 randconfig-r003-20230417 gcc
arm64 randconfig-r015-20230417 clang
arm64 randconfig-r036-20230416 clang
csky buildonly-randconfig-r004-20230416 gcc
csky buildonly-randconfig-r006-20230418 gcc
csky defconfig gcc
csky randconfig-r024-20230417 gcc
csky randconfig-r025-20230416 gcc
csky randconfig-r026-20230420 gcc
hexagon randconfig-r005-20230417 clang
hexagon randconfig-r012-20230417 clang
hexagon randconfig-r016-20230417 clang
hexagon randconfig-r023-20230417 clang
hexagon randconfig-r031-20230418 clang
hexagon randconfig-r035-20230416 clang
hexagon randconfig-r041-20230416 clang
hexagon randconfig-r041-20230417 clang
hexagon randconfig-r041-20230419 clang
hexagon randconfig-r041-20230420 clang
hexagon randconfig-r045-20230416 clang
hexagon randconfig-r045-20230417 clang
hexagon randconfig-r045-20230419 clang
hexagon randconfig-r045-20230420 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230417 gcc
i386 randconfig-a002-20230417 gcc
i386 randconfig-a003-20230417 gcc
i386 randconfig-a004-20230417 gcc
i386 randconfig-a005-20230417 gcc
i386 randconfig-a006-20230417 gcc
i386 randconfig-a011-20230417 clang
i386 randconfig-a012-20230417 clang
i386 randconfig-a013-20230417 clang
i386 randconfig-a014-20230417 clang
i386 randconfig-a015-20230417 clang
i386 randconfig-a016-20230417 clang
i386 randconfig-r006-20230417 gcc
ia64 allmodconfig gcc
ia64 defconfig gcc
ia64 randconfig-r022-20230416 gcc
ia64 randconfig-r022-20230417 gcc
ia64 randconfig-r026-20230416 gcc
ia64 randconfig-r034-20230416 gcc
ia64 randconfig-r036-20230418 gcc
ia64 zx1_defconfig gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
m68k allmodconfig gcc
m68k atari_defconfig gcc
m68k defconfig gcc
m68k m5272c3_defconfig gcc
microblaze buildonly-randconfig-r003-20230418 gcc
microblaze randconfig-r004-20230420 gcc
microblaze randconfig-r021-20230417 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips cobalt_defconfig gcc
mips decstation_64_defconfig gcc
mips malta_qemu_32r6_defconfig clang
mips omega2p_defconfig clang
mips randconfig-r012-20230416 clang
mips randconfig-r014-20230417 gcc
mips randconfig-r021-20230420 clang
mips randconfig-r034-20230418 gcc
nios2 buildonly-randconfig-r006-20230417 gcc
nios2 defconfig gcc
nios2 randconfig-r002-20230417 gcc
nios2 randconfig-r025-20230417 gcc
openrisc buildonly-randconfig-r001-20230418 gcc
openrisc buildonly-randconfig-r002-20230416 gcc
openrisc randconfig-r011-20230417 gcc
parisc buildonly-randconfig-r002-20230417 gcc
parisc buildonly-randconfig-r003-20230419 gcc
parisc defconfig gcc
parisc randconfig-r021-20230416 gcc
parisc randconfig-r023-20230416 gcc
parisc randconfig-r024-20230416 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc cm5200_defconfig gcc
powerpc gamecube_defconfig clang
powerpc klondike_defconfig gcc
powerpc makalu_defconfig gcc
powerpc mpc7448_hpc2_defconfig gcc
powerpc rainier_defconfig gcc
powerpc redwood_defconfig gcc
powerpc skiroot_defconfig clang
powerpc taishan_defconfig gcc
powerpc wii_defconfig gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r003-20230416 gcc
riscv buildonly-randconfig-r003-20230417 clang
riscv buildonly-randconfig-r006-20230419 clang
riscv defconfig gcc
riscv randconfig-r005-20230416 clang
riscv randconfig-r016-20230416 gcc
riscv randconfig-r032-20230416 clang
riscv randconfig-r032-20230418 clang
riscv randconfig-r042-20230416 gcc
riscv randconfig-r042-20230417 clang
riscv randconfig-r042-20230419 clang
riscv randconfig-r042-20230420 gcc
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r002-20230420 clang
s390 randconfig-r003-20230420 clang
s390 randconfig-r044-20230416 gcc
s390 randconfig-r044-20230417 clang
s390 randconfig-r044-20230419 clang
s390 randconfig-r044-20230420 gcc
sh allmodconfig gcc
sh buildonly-randconfig-r001-20230416 gcc
sh ecovec24_defconfig gcc
sh r7785rp_defconfig gcc
sh randconfig-r004-20230417 gcc
sh randconfig-r011-20230416 gcc
sh rsk7264_defconfig gcc
sparc defconfig gcc
sparc sparc32_defconfig gcc
sparc64 buildonly-randconfig-r002-20230419 gcc
sparc64 randconfig-r026-20230417 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230417 gcc
x86_64 randconfig-a002-20230417 gcc
x86_64 randconfig-a003-20230417 gcc
x86_64 randconfig-a004-20230417 gcc
x86_64 randconfig-a005-20230417 gcc
x86_64 randconfig-a006-20230417 gcc
x86_64 randconfig-a011-20230417 clang
x86_64 randconfig-a012-20230417 clang
x86_64 randconfig-a013-20230417 clang
x86_64 randconfig-a014-20230417 clang
x86_64 randconfig-a015-20230417 clang
x86_64 randconfig-a016-20230417 clang
x86_64 rhel-8.3-bpf gcc
x86_64 rhel-8.3-kunit gcc
x86_64 rhel-8.3-kvm gcc
x86_64 rhel-8.3-syz gcc
x86_64 rhel-8.3 gcc
xtensa randconfig-r015-20230416 gcc
xtensa smp_lx200_defconfig gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
_______________________________________________
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 v2 09/19] KVM: arm64: Save/restore PIE registers
From: Marc Zyngier @ 2023-04-20 8:36 UTC (permalink / raw)
To: Joey Gouly
Cc: linux-arm-kernel, nd, broonie, catalin.marinas, james.morse,
mark.rutland, oliver.upton, suzuki.poulose, will, yuzenghui
In-Reply-To: <20230413110513.243326-10-joey.gouly@arm.com>
On Thu, 13 Apr 2023 12:05:03 +0100,
Joey Gouly <joey.gouly@arm.com> wrote:
>
> Define the new system registers that PIE introduces and context switch them.
> The PIE feature is still hidden from the ID register, and not exposed to a VM.
>
> Signed-off-by: Joey Gouly <joey.gouly@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oliver.upton@linux.dev>
> Cc: James Morse <james.morse@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Zenghui Yu <yuzenghui@huawei.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 4 ++++
> arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 8 ++++++++
> arch/arm64/kvm/sys_regs.c | 2 ++
> 3 files changed, 14 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index e1137832a01f..381bd0763abf 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -367,6 +367,10 @@ enum vcpu_sysreg {
> CNTHCTL_EL2, /* Counter-timer Hypervisor Control register */
> SP_EL2, /* EL2 Stack Pointer */
>
> + /* Permission Indirection Extension registers */
> + PIR_EL1, /* Permission Indirection Register 1 (EL1) */
> + PIRE0_EL1, /* Permission Indirection Register 0 (EL1) */
> +
nit: please move these EL1 register outside of the EL2 range, as it
becomes significant with NV. Next to the MTE register is as good a
place as any.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 1/2] arm64: amlogic: add new ARCH_AMLIPC for IPC SoC
From: Kelvin Zhang @ 2023-04-20 8:43 UTC (permalink / raw)
To: Dmitry Rokosov, Neil Armstrong
Cc: =Xianwei Zhao, linux-arm-kernel, linux-kernel, linux-amlogic,
devicetree, Catalin Marinas, Will Deacon, Kevin Hilman,
Rob Herring, Krzysztof Kozlowski
In-Reply-To: <20230419170043.auzfa32weevmrt4e@CAB-WSD-L081021>
On 2023/4/20 01:00, Dmitry Rokosov wrote:
> [ EXTERNAL EMAIL ]
>
> On Wed, Apr 19, 2023 at 06:25:07PM +0200, Neil Armstrong wrote:
>> On 19/04/2023 18:04, Dmitry Rokosov wrote:
>>> On Wed, Apr 19, 2023 at 03:43:12PM +0200, Neil Armstrong wrote:
>>>> On 19/04/2023 15:14, Dmitry Rokosov wrote:
>>>>> On Wed, Apr 19, 2023 at 03:38:33PM +0800, =Xianwei Zhao wrote:
>>>>>> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>>>>>>
>>>>>> The C series SoCs are designed for smart IP camera
>>>>>> applications, which does not belong to Meson series.
>>>>>> So, Add ARCH_AMLIPC for the new series.
>>>>>>
>>>>>> There are now multiple amlogic SoC seies supported, so group them under
>>>>>> their own menu. we can easily add new platforms there in the future.
>>>>>> Introduce ARCH_AMLOGIC to cover all Amlogic SoC series.
>>>>>>
>>>>>> No functional changes introduced.
>>>>>>
>>>>>> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
>>>>>> ---
>>>>>> arch/arm64/Kconfig.platforms | 12 ++++++++++++
>>>>>> arch/arm64/configs/defconfig | 2 ++
>>>>>> 2 files changed, 14 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>>> index 89a0b13b058d..bfbc817eef8f 100644
>>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>>> @@ -162,12 +162,24 @@ config ARCH_MEDIATEK
>>>>>> This enables support for MediaTek MT27xx, MT65xx, MT76xx
>>>>>> & MT81xx ARMv8 SoCs
>>>>>> +menuconfig ARCH_AMLOGIC
>>>>>> + bool "NXP SoC support"
>>>>> NXP? Did you mean "Amlogic"?
>>>>>
>>>>>> +
>>>>>> +if ARCH_AMLOGIC
>>>>>> +
>>>>>> config ARCH_MESON
>>>>>> bool "Amlogic Platforms"
>>>>>> help
>>>>>> This enables support for the arm64 based Amlogic SoCs
>>>>>> such as the s905, S905X/D, S912, A113X/D or S905X/D2
>>>>>> +config ARCH_AMLIPC
>>>>> Do we really need a different ARCH for Amlogic IPC?
>>>>> I can imagine that it's not the Meson architecture at all.
>>>>> But maybe a better solution is just to rename ARCH_MESON to ARCH_AMLOGIC?
>>>> It should be changed treewide, and is it worth it ?
>>> As far as I understand, the A1 and S4 families are not fully compatible
>>> with the Meson architecture, and we haven't provided additional ARCH_*
>>> for them.
>> The GXBB, GXL/GXM, G12A, G12B & SM1 are also not fully compatible,
>> but they lie under the "MESON" umbrella which covers SoC since the
>> Meson6 architecture. It's a facility to include/exclude Amlogic
>> drivers/DT, nothing else.
GXBB, GXL/GXM, G12A, G12B , SM1 and S4 belong to media box.
So, "MESON" represents the media box series.
Up to now, "MESON" works well for all existing chips except A1 and AXG.
>> If you compare it to BCM or NXP, it's different situation, the
>> different ARCH_* actually targets totally different SoCs from
>> completely different Business Units or from companies acquisitions.
Firstly, the new C series is totally different from previous MESON series.
From the perspective of application, the new C series is designed for
smart IP camera applications,
while MESON series is designed for hybrid OTT/ IP Set Top Box and
high-end media box applications.
From the perspective of architecture, the new C series integrates the
sensor interface, image signal processing unit, Dewarp, video encoder,
neural networking processing unit,
which MESON series does not and will never have.
Secondly, there are C1 and C2 besides C3.
Moreover, more other series are on the way, such as T series.
If we always stick to "MESON", people will get more and more confused.
Therefore, I think it is the right time to add ARCH_AMLIPC.
>> We should have named it ARCH_AMLOGIC since the beginning, but we
>> can't change history.
Shouldn't we deserve a chance to make it right?
>>> In my opinion, it's a good time to split the Meson architecture into
>>> proper subsets, or rename it treewide (maybe only config option
>>> ARCH_MESON => ARCH_AMLOGIC).
>> MESON is only a codename to differentiate from other SoC vendors
>> because Amlogic used it as a codename for a long time.
>> Compare this to Allwinner's "sunxi" or Qualcomm's "msm".
>>
>> This config has no functional mean, it's only a config namespace.
>>
>> Renaming it would need renaming it in all subsystems Kconfig/Makefiles
>> and will certainly break builds with custom kernel configs
>> in various publicly used builds like Armbian, meta-meson, LibreELEC,
>> Debian, Suse, ...
Let's get back to ARCH_AMLIPC.
We just need to add ARCH_AMLIPC in the necessary subsystems
Kconfig/Makefile.
This change will keep the existing MESON related code, and will neither
involve renaming nor break any builds.
>> So it's pointless to change, and even add a different one since
>> it's not a family differentiator since the Kernel is modular
>> and works around DT to determine which drivers to probe.
Proper names play an important role in understanding the code, right?
>> Neil
>>
> Thank you for the detailed explanation; it makes sense!
> Actually, I disagree with creating a separate ARCH without first reworking
> all of its subsets - that's why I started this discussion.
> Now, I see that you share my perspective and believe that C3
> should be added to the ARCH_MESON subset, so I have no objections.
>
> [...]
>
> --
> Thank you,
> Dmitry
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
_______________________________________________
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 2/2] arm64: defconfig: enable TI K3 R5 and DSP remote proc drivers
From: Hari Nagalla @ 2023-04-20 8:47 UTC (permalink / raw)
To: Krzysztof Kozlowski, linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, quic_bjorande, arnd, treding,
dmitry.baryshkov, nfraprado, broonie, rafal
In-Reply-To: <9a2ed4b6-13b7-9e65-263c-d2b08e11da00@linaro.org>
On 4/19/23 07:46, Krzysztof Kozlowski wrote:
> Yeah, but why? This is simple defconfig change, just enabling drivers
> for same platform. With such arguments are we going to enable all
> drivers everywhere one-by-one?
Ok. will coalesce both patches and resubmit.
Thanks
_______________________________________________
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 v2 1/1] arm: dts: sunxi: Add ICnova A20 ADB4006 board support
From: Andre Przywara @ 2023-04-20 8:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ludwig Kormann, samuel, jernej.skrabec, wens, robh+dt,
krzysztof.kozlowski+dt, linux-arm-kernel, devicetree, linux-sunxi,
linux-kernel
In-Reply-To: <b84537c0-cb58-621a-2b6d-3bbaac5091de@linaro.org>
On Wed, 19 Apr 2023 15:05:17 +0200
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> On 19/04/2023 14:12, Ludwig Kormann wrote:
> > Add board support for ICnova A20 SomPi compute module on
> > ICnova ADB4006 development board.
> >
> > Specification:
> > SoM
> > - Processor: Allwinner A20 Cortex-A7 Dual Core at 1GHz
> > - 512MB DDR3 RAM
> > - Fast Ethernet (Phy: Realtek RTL8201CP)
> > ADB4006
> > - I2C
> > - 2x USB 2.0
> > - 1x Fast Ethernet port
> > - 1x SATA
> > - 2x buttons (PWRON, Boot)
> > - 2x LEDS
> > - serial console
> > - HDMI
> > - µSD-Card slot
> > - Audio Line-In / Line-Out
> > - GPIO pinheaders
> >
> > https://wiki.in-circuit.de/index.php5?title=ICnova_ADB4006
> > https://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
> >
> > ---
> >
> > changes in v2:
> > - use short licensing header
> > - remove deprecated elements from led nodes
> > - disable csi power supply
> > - add missing pins in usbphy node
> > - split dts into SoM dtsi and carrier board dts
> >
> > v1 of this patch was sent to the uboot mailing list [1].
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2023-April/514605.html
> >
> > Signed-off-by: Ludwig Kormann <ludwig.kormann@in-circuit.de>
> > ---
> > .../devicetree/bindings/arm/sunxi.yaml | 6 +
>
> Bindings are always separate patches. checkpatch did not complain?
>
> > arch/arm/boot/dts/Makefile | 1 +
> > .../boot/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 ++++++++++++++++++
> > arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi | 63 ++++++++
> > 4 files changed, 207 insertions(+)
> > create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
> > create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
> >
> > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > index 013821f4a7b8..12f0c236f17b 100644
> > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > @@ -305,6 +305,12 @@ properties:
> > - const: allwinner,i12-tvbox
> > - const: allwinner,sun7i-a20
> >
> > + - description: ICNova A20 ADB4006
> > + items:
> > + - const: incircuit,icnova-a20-adb4006
> > + - const: incircuit,icnova-a20
> > + - const: allwinner,sun7i-a20
> > +
> > - description: ICNova A20 SWAC
> > items:
> > - const: incircuit,icnova-a20-swac
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 3cc32722c394..b6b408417261 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -1321,6 +1321,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> > sun7i-a20-hummingbird.dtb \
> > sun7i-a20-itead-ibox.dtb \
> > sun7i-a20-i12-tvbox.dtb \
> > + sun7i-a20-icnova-a20-adb4006.dtb \
> > sun7i-a20-icnova-swac.dtb \
> > sun7i-a20-lamobo-r1.dtb \
> > sun7i-a20-linutronix-testbox-v2.dtb \
> > diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
> > new file mode 100644
> > index 000000000000..c1606c085e4e
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
> > @@ -0,0 +1,137 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> Unusual license. Are you sure you are ok with GPLv5.0?
Is it really unusual? This is literally the most commonly used dual license
for DTs, grep counts 252 users in arm and 573 users in arm64.
Or is it that it's deprecated and we recommend (GPL-2.0 OR MIT) for new
files?
Cheers,
Andre
>
> Also, at the end of your files - drop stray blank lines.
>
> Best regards,
> Krzysztof
>
_______________________________________________
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 v2 1/1] arm: dts: sunxi: Add ICnova A20 ADB4006 board support
From: Andre Przywara @ 2023-04-20 8:57 UTC (permalink / raw)
To: Ludwig Kormann
Cc: samuel, jernej.skrabec, wens, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, devicetree, linux-sunxi, linux-kernel
In-Reply-To: <20230419121229.1384024-1-ludwig.kormann@in-circuit.de>
On Wed, 19 Apr 2023 14:12:29 +0200
Ludwig Kormann <ludwig.kormann@in-circuit.de> wrote:
Hi Ludwig,
thanks for posting this!
> Add board support for ICnova A20 SomPi compute module on
> ICnova ADB4006 development board.
>
> Specification:
> SoM
> - Processor: Allwinner A20 Cortex-A7 Dual Core at 1GHz
> - 512MB DDR3 RAM
> - Fast Ethernet (Phy: Realtek RTL8201CP)
> ADB4006
> - I2C
> - 2x USB 2.0
> - 1x Fast Ethernet port
> - 1x SATA
> - 2x buttons (PWRON, Boot)
> - 2x LEDS
> - serial console
> - HDMI
> - µSD-Card slot
> - Audio Line-In / Line-Out
> - GPIO pinheaders
>
> https://wiki.in-circuit.de/index.php5?title=ICnova_ADB4006
> https://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
>
> ---
>
> changes in v2:
> - use short licensing header
> - remove deprecated elements from led nodes
> - disable csi power supply
> - add missing pins in usbphy node
> - split dts into SoM dtsi and carrier board dts
>
> v1 of this patch was sent to the uboot mailing list [1].
>
> [1] https://lists.denx.de/pipermail/u-boot/2023-April/514605.html
>
> Signed-off-by: Ludwig Kormann <ludwig.kormann@in-circuit.de>
So apart from what Krzysztof already mentioned (separate binding patch and
stray line), this looks good to me, and passed dt-validate. Also you
addressed all the comments I had on the U-Boot post (thanks for that), so
with those nits above fixed:
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre
> ---
> .../devicetree/bindings/arm/sunxi.yaml | 6 +
> arch/arm/boot/dts/Makefile | 1 +
> .../boot/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 ++++++++++++++++++
> arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi | 63 ++++++++
> 4 files changed, 207 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
> create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index 013821f4a7b8..12f0c236f17b 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -305,6 +305,12 @@ properties:
> - const: allwinner,i12-tvbox
> - const: allwinner,sun7i-a20
>
> + - description: ICNova A20 ADB4006
> + items:
> + - const: incircuit,icnova-a20-adb4006
> + - const: incircuit,icnova-a20
> + - const: allwinner,sun7i-a20
> +
> - description: ICNova A20 SWAC
> items:
> - const: incircuit,icnova-a20-swac
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 3cc32722c394..b6b408417261 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1321,6 +1321,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> sun7i-a20-hummingbird.dtb \
> sun7i-a20-itead-ibox.dtb \
> sun7i-a20-i12-tvbox.dtb \
> + sun7i-a20-icnova-a20-adb4006.dtb \
> sun7i-a20-icnova-swac.dtb \
> sun7i-a20-lamobo-r1.dtb \
> sun7i-a20-linutronix-testbox-v2.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
> new file mode 100644
> index 000000000000..c1606c085e4e
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2023 In-Circuit GmbH
> +
> +/dts-v1/;
> +
> +#include "sun7i-a20-icnova-a20.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> + model = "In-Circuit ICnova A20 ADB4006";
> + compatible = "incircuit,icnova-a20-adb4006", "incircuit,icnova-a20",
> + "allwinner,sun7i-a20";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + function = LED_FUNCTION_POWER;
> + color = <LED_COLOR_ID_YELLOW>;
> + gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; /* PH21 */
> + default-state = "on";
> + };
> +
> + led-1 {
> + function = LED_FUNCTION_HEARTBEAT;
> + color = <LED_COLOR_ID_RED>;
> + gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> +
> +&ahci {
> + target-supply = <®_ahci_5v>;
> + status = "okay";
> +};
> +
> +&codec {
> + status = "okay";
> +};
> +
> +&de {
> + status = "okay";
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&hdmi {
> + status = "okay";
> +};
> +
> +&hdmi_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
> + status = "okay";
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&otg_sram {
> + status = "okay";
> +};
> +
> +®_ahci_5v {
> + status = "okay";
> +};
> +
> +&ac_power_supply {
> + status = "okay";
> +};
> +
> +®_usb1_vbus {
> + status = "okay";
> +};
> +
> +®_usb2_vbus {
> + status = "okay";
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pb_pins>;
> + status = "okay";
> +};
> +
> +&usb_otg {
> + dr_mode = "otg";
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> + usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
> + usb1_vbus-supply = <®_usb1_vbus>;
> + usb2_vbus-supply = <®_usb2_vbus>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi b/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
> new file mode 100644
> index 000000000000..f1142bda5cd7
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
> @@ -0,0 +1,63 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2023 In-Circuit GmbH
> +
> +#include "sun7i-a20.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +&cpu0 {
> + cpu-supply = <®_dcdc2>;
> +};
> +
> +&gmac {
> + pinctrl-names = "default";
> + pinctrl-0 = <&gmac_mii_pins>;
> + phy-handle = <&phy1>;
> + phy-mode = "mii";
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> +
> + axp209: pmic@34 {
> + reg = <0x34>;
> + interrupt-parent = <&nmi_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + };
> +};
> +
> +&gmac_mdio {
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
> +};
> +
> +#include "axp209.dtsi"
> +
> +®_dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-name = "vdd-cpu";
> +};
> +
> +®_dcdc3 {
> + regulator-always-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-name = "vdd-int-dll";
> +};
> +
> +®_ldo1 {
> + regulator-name = "vdd-rtc";
> +};
> +
> +®_ldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-name = "avcc";
> +};
> +
_______________________________________________
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] mediatek/clk-mt8173-apmixedsys: convert to devm_platform_ioremap_resource
From: Hao Ge @ 2023-04-20 8:53 UTC (permalink / raw)
To: Stephen Boyd, matthias.bgg, mturquette
Cc: linux-clk, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <f09425fde83f4b21ee301ef8810c4c29.sboyd@kernel.org>
On 4/14/23 02:40, Stephen Boyd wrote:
> Quoting Hao Ge (2023-04-13 02:01:28)
>> diff --git a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
>> index a56c5845d07a..fe386bf8225d 100644
>> --- a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
>> +++ b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
>> @@ -90,7 +90,7 @@ static int clk_mt8173_apmixed_probe(struct platform_device *pdev)
>> struct clk_hw *hw;
>> int r;
>>
>> - base = of_iomap(node, 0);
>> + base = devm_platform_ioremap_resource(pdev, 0);
>> if (!base)
>
> This needs to be updated.
>
>> return PTR_ERR(base);
>
> And PTR_ERR(NULL) is 0, which is wrong.
Thank you for pointing out this point and Sorry for the late reply.
I will update the v2 for it.
Best regards.
Hao
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] arm64: defconfig: enable TI OMAP2 mailbox and K3 remote proc drivers
From: Hari Nagalla @ 2023-04-20 9:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, quic_bjorande, arnd, krzysztof.kozlowski,
treding, dmitry.baryshkov, nfraprado, broonie, rafal
Enable TI OMAP2 mailbox driver. This driver is used in TI K3 platforms
as well for communications with remote processors. Also enable Cortex R5
and TI DSP (C66x,C71x) remote proc drivers as modules for K3 platforms.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
---
Changes in v2:
- Coalesced the mailbox and remote proc enable defconfig patches
into one.
link: https://lore.kernel.org/all/f4514baa-d92d-c421-b13a-b30c7023108e@ti.com/#r
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 7790ee42c68a..d8e0ae85485f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1161,6 +1161,7 @@ CONFIG_TEGRA186_TIMER=y
CONFIG_RENESAS_OSTM=y
CONFIG_ARM_MHU=y
CONFIG_IMX_MBOX=y
+CONFIG_OMAP2PLUS_MBOX=m
CONFIG_PLATFORM_MHU=y
CONFIG_BCM2835_MBOX=y
CONFIG_QCOM_APCS_IPC=y
@@ -1172,6 +1173,8 @@ CONFIG_ARM_SMMU_V3=y
CONFIG_MTK_IOMMU=y
CONFIG_QCOM_IOMMU=y
CONFIG_REMOTEPROC=y
+CONFIG_TI_K3_R5_REMOTEPROC=m
+CONFIG_TI_K3_DSP_REMOTEPROC=m
CONFIG_MTK_SCP=m
CONFIG_QCOM_Q6V5_ADSP=m
CONFIG_QCOM_Q6V5_MSS=m
--
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] optee: fix uninited async notif value
From: Sumit Garg @ 2023-04-20 9:02 UTC (permalink / raw)
To: Etienne Carriere
Cc: linux-kernel, linux-arm-kernel, Jens Wiklander, Ard Biesheuvel,
op-tee, kernel test robot, Dan Carpenter
In-Reply-To: <20230420074923.2281303-1-etienne.carriere@linaro.org>
On Thu, 20 Apr 2023 at 13:43, Etienne Carriere
<etienne.carriere@linaro.org> wrote:
>
> Fixes an uninitialized variable in irq_handler() that could lead to
> unpredictable behavior in case OP-TEE fails to handle SMC function ID
> OPTEE_SMC_GET_ASYNC_NOTIF_VALUE. This change ensures that in that case
> get_async_notif_value() properly reports there are no notification
> event.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Link: https://lore.kernel.org/r/202304200755.OoiuclDZ-lkp@intel.com/
> Reported-by: Dan Carpenter <error27@gmail.com>
> Link: https://lore.kernel.org/all/d9b7f69b-c737-4cb3-8e74-79fe00c934f9@kili.mountain/
> Fixes: 6749e69c4dad ("optee: add asynchronous notifications")
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> ---
> drivers/tee/optee/smc_abi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
-Sumit
> diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
> index de7ac9a46354..6d3705770755 100644
> --- a/drivers/tee/optee/smc_abi.c
> +++ b/drivers/tee/optee/smc_abi.c
> @@ -1001,8 +1001,10 @@ static u32 get_async_notif_value(optee_invoke_fn *invoke_fn, bool *value_valid,
>
> invoke_fn(OPTEE_SMC_GET_ASYNC_NOTIF_VALUE, 0, 0, 0, 0, 0, 0, 0, &res);
>
> - if (res.a0)
> + if (res.a0) {
> + *value_valid = false;
> return 0;
> + }
> *value_valid = (res.a2 & OPTEE_SMC_ASYNC_NOTIF_VALUE_VALID);
> *value_pending = (res.a2 & OPTEE_SMC_ASYNC_NOTIF_VALUE_PENDING);
> return res.a1;
> --
> 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
* RE: [PATCH V7 1/7] spi: Add stacked and parallel memories support in SPI core
From: Mahapatra, Amit Kumar @ 2023-04-20 9:04 UTC (permalink / raw)
To: Stefan Binding, broonie@kernel.org, tudor.ambarus@linaro.org,
pratyush@kernel.org, michael@walle.cc, miquel.raynal@bootlin.com,
richard@nod.at, vigneshr@ti.com
Cc: git (AMD-Xilinx), alexandre.belloni@bootlin.com,
vitalyr@opensource.cirrus.com, patches@opensource.cirrus.com,
amitrkcian2002@gmail.com, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org,
Simek, Michal, claudiu.beznea@microchip.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <e3704956-e72c-421c-fd65-b8f17b7e2a5a@opensource.cirrus.com>
Hello Stefan,
> -----Original Message-----
> From: Stefan Binding <sbinding@opensource.cirrus.com>
> Sent: Wednesday, April 12, 2023 8:33 PM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra@amd.com>;
> broonie@kernel.org; tudor.ambarus@linaro.org; pratyush@kernel.org;
> michael@walle.cc; miquel.raynal@bootlin.com; richard@nod.at;
> vigneshr@ti.com
> Cc: git (AMD-Xilinx) <git@amd.com>; linux-spi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-mtd@lists.infradead.org;
> nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com;
> claudiu.beznea@microchip.com; Simek, Michal <michal.simek@amd.com>;
> linux-arm-kernel@lists.infradead.org; amitrkcian2002@gmail.com;
> patches@opensource.cirrus.com; vitalyr@opensource.cirrus.com
> Subject: Re: [PATCH V7 1/7] spi: Add stacked and parallel memories support
> in SPI core
>
> Hi,
>
> On 11/04/2023 10:07, Mahapatra, Amit Kumar wrote:
> > Hello Stefan,
> >
> >> -----Original Message-----
> >> From: Stefan Binding <sbinding@opensource.cirrus.com>
> >> Sent: Thursday, April 6, 2023 7:14 PM
> >> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra@amd.com>;
> >> broonie@kernel.org; tudor.ambarus@linaro.org; pratyush@kernel.org;
> >> michael@walle.cc; miquel.raynal@bootlin.com; richard@nod.at;
> >> vigneshr@ti.com
> >> Cc: git (AMD-Xilinx) <git@amd.com>; linux-spi@vger.kernel.org; linux-
> >> kernel@vger.kernel.org; linux-mtd@lists.infradead.org;
> >> nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com;
> >> claudiu.beznea@microchip.com; Simek, Michal
> <michal.simek@amd.com>;
> >> linux-arm-kernel@lists.infradead.org; amitrkcian2002@gmail.com;
> >> patches@opensource.cirrus.com; vitalyr@opensource.cirrus.com
> >> Subject: RE: [PATCH V7 1/7] spi: Add stacked and parallel memories
> >> support in SPI core
> >>
> >> Hi,
> >>
> >>> -----Original Message-----
> >>> From: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
> >>> Sent: Thursday, April 6, 2023 7:54 AM
> >>> To: broonie@kernel.org; tudor.ambarus@linaro.org;
> >>> pratyush@kernel.org; michael@walle.cc; miquel.raynal@bootlin.com;
> >>> richard@nod.at; vigneshr@ti.com
> >>> Cc: git@amd.com; sbinding@opensource.cirrus.com; linux-
> >>> spi@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> >>> mtd@lists.infradead.org; nicolas.ferre@microchip.com;
> >>> alexandre.belloni@bootlin.com; claudiu.beznea@microchip.com;
> >>> michal.simek@amd.com; linux-arm-kernel@lists.infradead.org;
> >>> amitrkcian2002@gmail.com; Amit Kumar Mahapatra <amit.kumar-
> >>> mahapatra@amd.com>
> >>> Subject: [PATCH V7 1/7] spi: Add stacked and parallel memories
> >> support
> >>> in SPI core
> >>>
> >>> For supporting multiple CS the SPI device need to be aware of all
> >> the CS
> >>> values. So, the "chip_select" member in the spi_device structure is
> >> now
> >>> an
> >>> array that holds all the CS values.
> >>>
> >>> spi_device structure now has a "cs_index_mask" member. This acts as
> >> an
> >>> index to the chip_select array. If nth bit of spi->cs_index_mask is
> >> set
> >>> then the driver would assert spi->chip_select[n].
> >>>
> >>> In parallel mode all the chip selects are asserted/de-asserted
> >>> simultaneously and each byte of data is stored in both devices, the
> >> even
> >>> bits in one, the odd bits in the other. The split is automatically
> >> handled
> >>> by the GQSPI controller. The GQSPI controller supports a maximum of
> >>> two flashes connected in parallel mode. A SPI_CONTROLLER_MULTI_CS
> >>> flag bit is added in the spi controntroller flags, through
> >>> ctlr->flags the spi
> >> core
> >>> will make sure that the controller is capable of handling multiple
> >> chip
> >>> selects at once.
> >>>
> >>> For supporting multiple CS via GPIO the cs_gpiod member of the
> >>> spi_device structure is now an array that holds the gpio descriptor
> >>> for each chipselect.
> >>>
> >>> Multi CS support using GPIO is not tested due to unavailability of
> >>> necessary hardware setup.
> >>>
> >>> Multi CS configuration with one native CS and one GPIO CS is not
> >>> supported as this configuration could not be tested due to
> >>> unavailability of necessary hardware setup.
> >> I've tested this chain on a released laptop (HP EliteBook 840 G9)
> >> which uses SPI to interface to 2 amps, one amp uses a native CS and
> >> the other uses a GPIO CS, and I noticed that when using this chain,
> >> the second amp no longer works.
> > Thank you for testing this patch series on GPIO CS setup. As I don't
> > have a GPIO CS setup, is it possible for you debug the failure and
> > share more details/logs where the problem is?
> >
> > Regards,
> > Amit
>
> We are willing and able to debug this failure and share the failure logs.
> The first issue that I see is a kernel crash when trying to set the GPIO CS:
>
> [ 2.951658] general protection fault, probably for non-canonical address
> 0xdead000000000122: 0000 [#1] PREEMPT SMP NOPTI [ 2.951771] CPU: 9
> PID: 379 Comm: systemd-udevd Tainted: G A 6.3.0-rc3+ #30
> [ 2.951826] Hardware name: HP /896D, BIOS U70 Ver. 89.33.02 10/29/2021
> [ 2.951882] RIP: 0010:gpiod_set_value_cansleep+0x21/0xa0
> [ 2.951941] Code: 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 ff
> 74 3e 55 48 89 e5 41 55 41 89 f5 41 54 49 89 fc 48 81 ff 00 f0 ff ff 77 2c <48>
> 8b 3f 48 85 ff 74 53 48 83 bf 68 03 00 00 00 74 34 44 89 ee 4c [ 2.952043]
> RSP: 0018:ffffc008c0deb928 EFLAGS: 00010287 [ 2.952080] RAX:
> 0000000000000001 RBX: ffffa0a489534c00 RCX:
> 0000000000000000
> [ 2.952124] RDX: dead000000000122 RSI: 0000000000000001 RDI:
> dead000000000122
> [ 2.952167] RBP: ffffc008c0deb938 R08: 0000000000000000 R09:
> ffffc008c0deb868
> [ 2.952211] R10: ffffffffffffffff R11: 00000000000000b0 R12:
> dead000000000122
> [ 2.952256] R13: 0000000000000001 R14: 0000000000000000 R15:
> 0000000000000000
> [ 2.952299] FS: 00007f7fa5b5b880(0000) GS:ffffa0a81f840000(0000)
> knlGS:0000000000000000
> [ 2.952369] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 2.952407] CR2: 000055d648427100 CR3: 000000010e960003 CR4:
> 0000000000770ee0
> [ 2.952451] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 2.952492] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:
> 0000000000000400
> [ 2.952533] PKRU: 55555554
> [ 2.952561] Call Trace:
> [ 2.952579] <TASK>
> [ 2.952598] spi_set_cs+0x257/0x4a0
> [ 2.952630] spi_setup+0x1a2/0x500
> [ 2.952667] __spi_add_device+0x88/0x160
> [ 2.952710] spi_add_device+0x60/0x90
> [ 2.952738] smi_spi_probe+0x178/0x370 [serial_multi_instantiate]
> [ 2.952792] smi_probe+0xcf/0x110 [serial_multi_instantiate]
> [ 2.952854] platform_probe+0x42/0xb0
> [ 2.952885] really_probe+0x1b2/0x420
> [ 2.952914] __driver_probe_device+0x7e/0x180
> [ 2.952947] driver_probe_device+0x23/0xa0
> [ 2.952993] __driver_attach+0xe4/0x1e0 [ 2.953021] ?
> __pfx___driver_attach+0x10/0x10
> [ 2.953061] bus_for_each_dev+0x7a/0xd0
> [ 2.953088] driver_attach+0x1e/0x30
> [ 2.953123] bus_add_driver+0x11c/0x220
> [ 2.953150] driver_register+0x64/0x130 [ 2.953174] ?
> __pfx_init_module+0x10/0x10 [serial_multi_instantiate]
> [ 2.953221] __platform_driver_register+0x1e/0x30
> [ 2.953251] smi_driver_init+0x1c/0xff0 [serial_multi_instantiate]
> [ 2.953310] do_one_initcall+0x46/0x220 [ 2.953339] ?
> kmalloc_trace+0x2a/0xa0 [ 2.953375] do_init_module+0x52/0x220
> [ 2.953411] load_module+0x223c/0x2460
> [ 2.953450] __do_sys_finit_module+0xc8/0x140 [ 2.953479] ?
> __do_sys_finit_module+0xc8/0x140
> [ 2.953510] __x64_sys_finit_module+0x18/0x20
> [ 2.953538] do_syscall_64+0x38/0x90
> [ 2.953574] entry_SYSCALL_64_after_hwframe+0x72/0xdc
> [ 2.953606] RIP: 0033:0x7f7fa5d7476d
> [ 2.953639] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa
> 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f
> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f3 36 0d 00 f7 d8 64 89 01 48
> [ 2.953739] RSP: 002b:00007fff1f8dd3b8 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000139
> [ 2.956833] RAX: ffffffffffffffda RBX: 000055d648654ab0 RCX:
> 00007f7fa5d7476d
> [ 2.959202] RDX: 0000000000000000 RSI: 00007f7fa5c54ded RDI:
> 0000000000000006
> [ 2.961542] RBP: 0000000000020000 R08: 0000000000000000 R09:
> 0000000000000000
> [ 2.964312] R10: 0000000000000006 R11: 0000000000000246 R12:
> 00007f7fa5c54ded
> [ 2.966694] R13: 0000000000000000 R14: 000055d6483f41a0 R15:
> 000055d648654ab0
> [ 2.967668] resource: resource sanity check: requesting [mem
> 0x00000000fedc0000-0x00000000fedcffff], which spans more than pnp 00:04
> [mem 0xfedc0000-0xfedc7fff] [ 2.968998] </TASK> [ 2.971615] caller
> igen6_probe+0x178/0x8e0 [igen6_edac] mapping multiple BARs [ 2.975014]
> Modules linked in: igen6_edac(+) fjes(-)
> serial_multi_instantiate(+) int3403_thermal sch_fq_codel
> int340x_thermal_zone int3400_thermal intel_hid acpi_thermal_rel acpi_tad
> sparse_keymap acpi_pad mac_hid msr parport_pc ppdev lp parport drm
> ramoops reed_solomon efi_pstore ip_tables x_tables autofs4
> spi_pxa2xx_platform dw_dmac dw_dmac_core nvme intel_lpss_pci
> intel_lpss crc32_pclmul thunderbolt i2c_i801 xhci_pci idma64 nvme_core
> i2c_smbus virt_dma xhci_pci_renesas video wmi pinctrl_tigerlake
> [ 2.987901] ---[ end trace 0000000000000000 ]--- [ 3.157030] RIP:
> 0010:gpiod_set_value_cansleep+0x21/0xa0
> [ 3.159077] Code: 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 ff
> 74 3e 55 48 89 e5 41 55 41 89 f5 41 54 49 89 fc 48 81 ff 00 f0 ff ff 77 2c <48>
> 8b 3f 48 85 ff 74 53 48 83 bf 68 03 00 00 00 74 34 44 89 ee 4c [ 3.161461]
> RSP: 0018:ffffc008c0deb928 EFLAGS: 00010287 [ 3.164005] RAX:
> 0000000000000001 RBX: ffffa0a489534c00 RCX:
> 0000000000000000
> [ 3.166354] RDX: dead000000000122 RSI: 0000000000000001 RDI:
> dead000000000122
> [ 3.168499] RBP: ffffc008c0deb938 R08: 0000000000000000 R09:
> ffffc008c0deb868
> [ 3.170609] R10: ffffffffffffffff R11: 00000000000000b0 R12:
> dead000000000122
> [ 3.172893] R13: 0000000000000001 R14: 0000000000000000 R15:
> 0000000000000000
> [ 3.175335] FS: 00007f7fa5b5b880(0000) GS:ffffa0a81f840000(0000)
> knlGS:0000000000000000
> [ 3.180434] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 3.183356] CR2: 000055d648427100 CR3: 000000010e960003 CR4:
> 0000000000770ee0
> [ 3.185107] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 3.186840] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:
> 0000000000000400
> [ 3.188647] PKRU: 55555554
Thank you for sharing the logs.
As per our analysis the spi->cs_gpiod[0] is getting messed up while
setting it in __spi_add_device( ).
Is it possible for you to do the following changes on top of this patch
series & re-run your test.
After applying this patch series, in drivers/spi/spi.c file replace the
following code snippet in __spi_add_device( ) function defination.
if (ctlr->cs_gpiods) {
for (idx = 0; idx < SPI_CS_CNT_MAX; idx++)
spi_set_csgpiod(spi, idx, ctlr->cs_gpiods[spi_get_chipselect(spi, idx)]);
}
with the below code snippet
if (ctlr->cs_gpiods) {
for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) {
if (!(idx != 0 && !spi_get_chipselect(spi, idx)))
spi_set_csgpiod(spi, idx, ctlr->cs_gpiods[spi_get_chipselect(spi, idx)]);
}
}
then re-run your test.
Regards,
Amit
>
> Thanks,
>
> Stefan
>
> >
> >> Thanks,
> >> Stefan Binding
> >>
> >>> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
> >> mahapatra@amd.com>
> >>> ---
> >>> drivers/spi/spi.c | 226
> >> ++++++++++++++++++++++++++++------------
> >>> include/linux/spi/spi.h | 32 ++++--
> >>> 2 files changed, 183 insertions(+), 75 deletions(-)
> >>>
> >>> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index
> >>> 9036d7a50674..04d7322170c4 100644
> >>> --- a/drivers/spi/spi.c
> >>> +++ b/drivers/spi/spi.c
> >>> @@ -612,10 +612,24 @@ static int spi_dev_check(struct device *dev,
> >>> void *data) {
> >>> struct spi_device *spi = to_spi_device(dev);
> >>> struct spi_device *new_spi = data;
> >>> + int idx, nw_idx;
> >>>
> >>> - if (spi->controller == new_spi->controller &&
> >>> - spi_get_chipselect(spi, 0) == spi_get_chipselect(new_spi,
> >> 0))
> >>> - return -EBUSY;
> >>> + if (spi->controller == new_spi->controller) {
> >>> + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) {
> >>> + for (nw_idx = 0; nw_idx < SPI_CS_CNT_MAX;
> >>> nw_idx++) {
> >>> + if ((idx != 0 &&
> >> !spi_get_chipselect(spi,
> >>> idx)) ||
> >>> + (nw_idx != 0 &&
> >>> !spi_get_chipselect(spi, nw_idx))) {
> >>> + continue;
> >>> + } else if (spi_get_chipselect(spi,
> >> idx) ==
> >>> + spi_get_chipselect(new_spi,
> >> nw_idx))
> >>> {
> >>> + dev_err(dev,
> >>> + "chipselect %d already
> >>> in use\n",
> >>> +
> >>> spi_get_chipselect(new_spi, nw_idx));
> >>> + return -EBUSY;
> >>> + }
> >>> + }
> >>> + }
> >>> + }
> >>> return 0;
> >>> }
> >>>
> >>> @@ -629,7 +643,7 @@ static int __spi_add_device(struct spi_device
> >>> *spi)
> >>> {
> >>> struct spi_controller *ctlr = spi->controller;
> >>> struct device *dev = ctlr->dev.parent;
> >>> - int status;
> >>> + int status, idx;
> >>>
> >>> /*
> >>> * We need to make sure there's no other device with this @@
> >>> -638,8
> >>> +652,6 @@ static int __spi_add_device(struct spi_device
> >>> *spi)
> >>> */
> >>> status = bus_for_each_dev(&spi_bus_type, NULL, spi,
> >> spi_dev_check);
> >>> if (status) {
> >>> - dev_err(dev, "chipselect %d already in use\n",
> >>> - spi_get_chipselect(spi, 0));
> >>> return status;
> >>> }
> >>>
> >>> @@ -649,8 +661,10 @@ static int __spi_add_device(struct spi_device
> >>> *spi)
> >>> return -ENODEV;
> >>> }
> >>>
> >>> - if (ctlr->cs_gpiods)
> >>> - spi_set_csgpiod(spi, 0, ctlr-
> >>>> cs_gpiods[spi_get_chipselect(spi, 0)]);
> >>> + if (ctlr->cs_gpiods) {
> >>> + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++)
> >>> + spi_set_csgpiod(spi, idx, ctlr-
> >>>> cs_gpiods[spi_get_chipselect(spi, idx)]);
> >>> + }
> >>>
> >>> /*
> >>> * Drivers may modify this initial i/o setup, but will @@ -690,13
> >>> +704,15 @@ int spi_add_device(struct spi_device *spi) {
> >>> struct spi_controller *ctlr = spi->controller;
> >>> struct device *dev = ctlr->dev.parent;
> >>> - int status;
> >>> + int status, idx;
> >>>
> >>> - /* Chipselects are numbered 0..max; validate. */
> >>> - if (spi_get_chipselect(spi, 0) >= ctlr->num_chipselect) {
> >>> - dev_err(dev, "cs%d >= max %d\n",
> >>> spi_get_chipselect(spi, 0),
> >>> - ctlr->num_chipselect);
> >>> - return -EINVAL;
> >>> + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) {
> >>> + /* Chipselects are numbered 0..max; validate. */
> >>> + if (spi_get_chipselect(spi, idx) >=
> >> ctlr->num_chipselect) {
> >>> + dev_err(dev, "cs%d >= max %d\n",
> >>> spi_get_chipselect(spi, idx),
> >>> + ctlr->num_chipselect);
> >>> + return -EINVAL;
> >>> + }
> >>> }
> >>>
> >>> /* Set the bus ID string */
> >>> @@ -713,12 +729,15 @@ static int spi_add_device_locked(struct
> >>> spi_device *spi) {
> >>> struct spi_controller *ctlr = spi->controller;
> >>> struct device *dev = ctlr->dev.parent;
> >>> + int idx;
> >>>
> >>> - /* Chipselects are numbered 0..max; validate. */
> >>> - if (spi_get_chipselect(spi, 0) >= ctlr->num_chipselect) {
> >>> - dev_err(dev, "cs%d >= max %d\n",
> >>> spi_get_chipselect(spi, 0),
> >>> - ctlr->num_chipselect);
> >>> - return -EINVAL;
> >>> + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) {
> >>> + /* Chipselects are numbered 0..max; validate. */
> >>> + if (spi_get_chipselect(spi, idx) >=
> >> ctlr->num_chipselect) {
> >>> + dev_err(dev, "cs%d >= max %d\n",
> >>> spi_get_chipselect(spi, idx),
> >>> + ctlr->num_chipselect);
> >>> + return -EINVAL;
> >>> + }
> >>> }
> >>>
> >>> /* Set the bus ID string */
> >>> @@ -966,58 +985,118 @@ static void spi_res_release(struct
> >>> spi_controller *ctlr, struct spi_message *mes static void
> >>> spi_set_cs(struct spi_device *spi, bool enable, bool
> >> force)
> >>> {
> >>> bool activate = enable;
> >>> + u32 cs_num = __ffs(spi->cs_index_mask);
> >>> + int idx;
> >>>
> >>> /*
> >>> - * Avoid calling into the driver (or doing delays) if the chip
> >> select
> >>> - * isn't actually changing from the last time this was called.
> >>> + * In parallel mode all the chip selects are
> >> asserted/de-asserted
> >>> + * at once
> >>> */
> >>> - if (!force && ((enable && spi->controller->last_cs ==
> >>> spi_get_chipselect(spi, 0)) ||
> >>> - (!enable && spi->controller->last_cs !=
> >>> spi_get_chipselect(spi, 0))) &&
> >>> - (spi->controller->last_cs_mode_high == (spi->mode &
> >>> SPI_CS_HIGH)))
> >>> - return;
> >>> -
> >>> - trace_spi_set_cs(spi, activate);
> >>> -
> >>> - spi->controller->last_cs = enable ? spi_get_chipselect(spi, 0)
> >> : -1;
> >>> - spi->controller->last_cs_mode_high = spi->mode &
> >>> SPI_CS_HIGH;
> >>> -
> >>> - if ((spi_get_csgpiod(spi, 0) ||
> >> !spi->controller->set_cs_timing)
> >>> && !activate)
> >>> - spi_delay_exec(&spi->cs_hold, NULL);
> >>> -
> >>> - if (spi->mode & SPI_CS_HIGH)
> >>> - enable = !enable;
> >>> + if ((spi->cs_index_mask & SPI_PARALLEL_CS_MASK) ==
> >>> SPI_PARALLEL_CS_MASK) {
> >>> + spi->controller->last_cs_mode_high = spi->mode &
> >>> SPI_CS_HIGH;
> >>> +
> >>> + if ((spi_get_csgpiod(spi, 0) || !spi->controller-
> >>>> set_cs_timing) && !activate)
> >>> + spi_delay_exec(&spi->cs_hold, NULL);
> >>> +
> >>> + if (spi->mode & SPI_CS_HIGH)
> >>> + enable = !enable;
> >>> +
> >>> + if (spi_get_csgpiod(spi, 0) && spi_get_csgpiod(spi,
> >> 1)) {
> >>> + if (!(spi->mode & SPI_NO_CS)) {
> >>> + /*
> >>> + * Historically ACPI has no means of
> >> the
> >>> GPIO polarity and
> >>> + * thus the SPISerialBus() resource
> >>> defines it on the per-chip
> >>> + * basis. In order to avoid a chain of
> >>> negations, the GPIO
> >>> + * polarity is considered being Active
> >>> High. Even for the cases
> >>> + * when _DSD() is involved (in the
> >>> updated versions of ACPI)
> >>> + * the GPIO CS polarity must be
> >> defined
> >>> Active High to avoid
> >>> + * ambiguity. That's why we use
> >> enable,
> >>> that takes SPI_CS_HIGH
> >>> + * into account.
> >>> + */
> >>> + if (has_acpi_companion(&spi->dev)) {
> >>> + for (idx = 0; idx <
> >>> SPI_CS_CNT_MAX; idx++)
> >>> +
> >>> gpiod_set_value_cansleep(spi_get_csgpiod(spi, idx),
> >>> +
> >>> !enable);
> >>> + } else {
> >>> + for (idx = 0; idx <
> >>> SPI_CS_CNT_MAX; idx++)
> >>> + /* Polarity handled by
> >>> GPIO library */
> >>> +
> >>> gpiod_set_value_cansleep(spi_get_csgpiod(spi, idx),
> >>> +
> >>> activate);
> >>> + }
> >>> + }
> >>> + /* Some SPI masters need both GPIO CS &
> >>> slave_select */
> >>> + if ((spi->controller->flags &
> >>> SPI_MASTER_GPIO_SS) &&
> >>> + spi->controller->set_cs)
> >>> + spi->controller->set_cs(spi, !enable);
> >>> + } else if (spi->controller->set_cs) {
> >>> + spi->controller->set_cs(spi, !enable);
> >>> + }
> >>>
> >>> - if (spi_get_csgpiod(spi, 0)) {
> >>> - if (!(spi->mode & SPI_NO_CS)) {
> >>> - /*
> >>> - * Historically ACPI has no means of the GPIO
> >>> polarity and
> >>> - * thus the SPISerialBus() resource defines it
> >> on
> >>> the per-chip
> >>> - * basis. In order to avoid a chain of
> >> negations,
> >>> the GPIO
> >>> - * polarity is considered being Active High.
> >> Even
> >>> for the cases
> >>> - * when _DSD() is involved (in the updated
> >>> versions of ACPI)
> >>> - * the GPIO CS polarity must be defined Active
> >>> High to avoid
> >>> - * ambiguity. That's why we use enable, that
> >>> takes SPI_CS_HIGH
> >>> - * into account.
> >>> - */
> >>> - if (has_acpi_companion(&spi->dev))
> >>> -
> >>> gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), !enable);
> >>> + if (spi_get_csgpiod(spi, 0) || spi_get_csgpiod(spi, 1)
> >> ||
> >>> + !spi->controller->set_cs_timing) {
> >>> + if (activate)
> >>> + spi_delay_exec(&spi->cs_setup, NULL);
> >>> else
> >>> - /* Polarity handled by GPIO library */
> >>> -
> >>> gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), activate);
> >>> + spi_delay_exec(&spi->cs_inactive,
> >>> NULL);
> >>> }
> >>> - /* Some SPI masters need both GPIO CS & slave_select
> >>> */
> >>> - if ((spi->controller->flags & SPI_MASTER_GPIO_SS) &&
> >>> - spi->controller->set_cs)
> >>> + } else {
> >>> + /*
> >>> + * Avoid calling into the driver (or doing delays) if
> >> the
> >>> chip select
> >>> + * isn't actually changing from the last time this was
> >>> called.
> >>> + */
> >>> + if (!force && ((enable && spi->controller->last_cs ==
> >>> + spi_get_chipselect(spi, cs_num)) ||
> >>> + (!enable && spi->controller->last_cs
> >> !=
> >>> + spi_get_chipselect(spi, cs_num))) &&
> >>> + (spi->controller->last_cs_mode_high ==
> >>> + (spi->mode & SPI_CS_HIGH)))
> >>> + return;
> >>> +
> >>> + trace_spi_set_cs(spi, activate);
> >>> +
> >>> + spi->controller->last_cs = enable ?
> >>> spi_get_chipselect(spi, cs_num) : -1;
> >>> + spi->controller->last_cs_mode_high = spi->mode &
> >>> SPI_CS_HIGH;
> >>> +
> >>> + if ((spi_get_csgpiod(spi, cs_num) || !spi->controller-
> >>>> set_cs_timing) && !activate)
> >>> + spi_delay_exec(&spi->cs_hold, NULL);
> >>> +
> >>> + if (spi->mode & SPI_CS_HIGH)
> >>> + enable = !enable;
> >>> +
> >>> + if (spi_get_csgpiod(spi, cs_num)) {
> >>> + if (!(spi->mode & SPI_NO_CS)) {
> >>> + /*
> >>> + * Historically ACPI has no means of
> >> the
> >>> GPIO polarity and
> >>> + * thus the SPISerialBus() resource
> >>> defines it on the per-chip
> >>> + * basis. In order to avoid a chain of
> >>> negations, the GPIO
> >>> + * polarity is considered being Active
> >>> High. Even for the cases
> >>> + * when _DSD() is involved (in the
> >>> updated versions of ACPI)
> >>> + * the GPIO CS polarity must be
> >> defined
> >>> Active High to avoid
> >>> + * ambiguity. That's why we use
> >> enable,
> >>> that takes SPI_CS_HIGH
> >>> + * into account.
> >>> + */
> >>> + if (has_acpi_companion(&spi->dev))
> >>> +
> >>> gpiod_set_value_cansleep(spi_get_csgpiod(spi, cs_num),
> >>> +
> >>> !enable);
> >>> + else
> >>> + /* Polarity handled by GPIO
> >>> library */
> >>> +
> >>> gpiod_set_value_cansleep(spi_get_csgpiod(spi, cs_num),
> >>> +
> >>> activate);
> >>> + }
> >>> + /* Some SPI masters need both GPIO CS &
> >>> slave_select */
> >>> + if ((spi->controller->flags &
> >>> SPI_MASTER_GPIO_SS) &&
> >>> + spi->controller->set_cs)
> >>> + spi->controller->set_cs(spi, !enable);
> >>> + } else if (spi->controller->set_cs) {
> >>> spi->controller->set_cs(spi, !enable);
> >>> - } else if (spi->controller->set_cs) {
> >>> - spi->controller->set_cs(spi, !enable);
> >>> - }
> >>> + }
> >>>
> >>> - if (spi_get_csgpiod(spi, 0) ||
> >> !spi->controller->set_cs_timing) {
> >>> - if (activate)
> >>> - spi_delay_exec(&spi->cs_setup, NULL);
> >>> - else
> >>> - spi_delay_exec(&spi->cs_inactive, NULL);
> >>> + if (spi_get_csgpiod(spi, cs_num) || !spi->controller-
> >>>> set_cs_timing) {
> >>> + if (activate)
> >>> + spi_delay_exec(&spi->cs_setup, NULL);
> >>> + else
> >>> + spi_delay_exec(&spi->cs_inactive,
> >>> NULL);
> >>> + }
> >>> }
> >>> }
> >>>
> >>> @@ -2246,8 +2325,8 @@ static void of_spi_parse_dt_cs_delay(struct
> >>> device_node *nc, static int of_spi_parse_dt(struct spi_controller
> >>> *ctlr, struct
> >> spi_device
> >>> *spi,
> >>> struct device_node *nc)
> >>> {
> >>> - u32 value;
> >>> - int rc;
> >>> + u32 value, cs[SPI_CS_CNT_MAX] = {0};
> >>> + int rc, idx;
> >>>
> >>> /* Mode (clock phase/polarity/etc.) */
> >>> if (of_property_read_bool(nc, "spi-cpha")) @@ -2320,13 +2399,21
> >> @@
> >>> static int of_spi_parse_dt(struct spi_controller *ctlr, struct
> >>> spi_device *spi,
> >>> }
> >>>
> >>> /* Device address */
> >>> - rc = of_property_read_u32(nc, "reg", &value);
> >>> - if (rc) {
> >>> + rc = of_property_read_variable_u32_array(nc, "reg", &cs[0], 1,
> >>> + SPI_CS_CNT_MAX);
> >>> + if (rc < 0 || rc > ctlr->num_chipselect) {
> >>> dev_err(&ctlr->dev, "%pOF has no valid 'reg' property
> >> (%d)\n",
> >>> nc, rc);
> >>> return rc;
> >>> + } else if ((of_property_read_bool(nc, "parallel-memories")) &&
> >>> + (!(ctlr->flags & SPI_CONTROLLER_MULTI_CS))) {
> >>> + dev_err(&ctlr->dev, "SPI controller doesn't support
> >> multi
> >>> CS\n");
> >>> + return -EINVAL;
> >>> }
> >>> - spi_set_chipselect(spi, 0, value);
> >>> + for (idx = 0; idx < rc; idx++)
> >>> + spi_set_chipselect(spi, idx, cs[idx]);
> >>> + /* By default set the spi->cs_index_mask as 1 */
> >>> + spi->cs_index_mask = 0x01;
> >>>
> >>> /* Device speed */
> >>> if (!of_property_read_u32(nc, "spi-max-frequency", &value)) @@
> >>> -3907,7 +3994,8 @@ static int __spi_validate(struct spi_device *spi,
> >>> struct spi_message *message)
> >>> * cs_change is set for each transfer.
> >>> */
> >>> if ((spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits &
> >>> SPI_CS_WORD) ||
> >>> - spi_get_csgpiod(spi, 0))) {
> >>> + spi_get_csgpiod(spi, 0) ||
> >>> + spi_get_csgpiod(spi, 1))) {
> >>> size_t maxsize;
> >>> int ret;
> >>>
> >>> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index
> >>> 873ced6ae4ca..6453b246e0af 100644
> >>> --- a/include/linux/spi/spi.h
> >>> +++ b/include/linux/spi/spi.h
> >>> @@ -19,6 +19,11 @@
> >>> #include <linux/acpi.h>
> >>> #include <linux/u64_stats_sync.h>
> >>>
> >>> +/* Max no. of CS supported per spi device */ #define SPI_CS_CNT_MAX
> >>> +2
> >>> +
> >>> +/* chip select mask */
> >>> +#define SPI_PARALLEL_CS_MASK (BIT(0) | BIT(1))
> >>> struct dma_chan;
> >>> struct software_node;
> >>> struct ptp_system_timestamp;
> >>> @@ -166,6 +171,7 @@ extern void
> >>> spi_transfer_cs_change_delay_exec(struct spi_message *msg,
> >>> * deasserted. If @cs_change_delay is used from @spi_transfer,
> >>> then the
> >>> * two delays will be added up.
> >>> * @pcpu_statistics: statistics for the spi_device
> >>> + * @cs_index_mask: Bit mask of the active chipselect(s) in the
> >>> chipselect array
> >>> *
> >>> * A @spi_device is used to interchange data between an SPI slave
> >>> * (usually a discrete chip) and CPU memory.
> >>> @@ -181,7 +187,7 @@ struct spi_device {
> >>> struct spi_controller *controller;
> >>> struct spi_controller *master; /* Compatibility layer
> >> */
> >>> u32 max_speed_hz;
> >>> - u8 chip_select;
> >>> + u8 chip_select[SPI_CS_CNT_MAX];
> >>> u8 bits_per_word;
> >>> bool rt;
> >>> #define SPI_NO_TX BIT(31) /* No transmit wire */
> >>> @@ -202,7 +208,7 @@ struct spi_device {
> >>> void *controller_data;
> >>> char modalias[SPI_NAME_SIZE];
> >>> const char *driver_override;
> >>> - struct gpio_desc *cs_gpiod; /* Chip select gpio
> >> desc
> >>> */
> >>> + struct gpio_desc *cs_gpiod[SPI_CS_CNT_MAX]; /*
> >> Chip
> >>> select gpio desc */
> >>> struct spi_delay word_delay; /* Inter-word delay */
> >>> /* CS delays */
> >>> struct spi_delay cs_setup;
> >>> @@ -212,6 +218,13 @@ struct spi_device {
> >>> /* The statistics */
> >>> struct spi_statistics __percpu *pcpu_statistics;
> >>>
> >>> + /* Bit mask of the chipselect(s) that the driver need to use
> >> from
> >>> + * the chipselect array.When the controller is capable to
> >> handle
> >>> + * multiple chip selects & memories are connected in parallel
> >>> + * then more than one bit need to be set in cs_index_mask.
> >>> + */
> >>> + u32 cs_index_mask : SPI_CS_CNT_MAX;
> >>> +
> >>> /*
> >>> * likely need more hooks for more protocol options affecting how
> >>> * the controller talks to each chip, like:
> >>> @@ -268,22 +281,22 @@ static inline void *spi_get_drvdata(const
> >>> struct spi_device *spi)
> >>>
> >>> static inline u8 spi_get_chipselect(const struct spi_device *spi,
> >> u8 idx)
> >>> {
> >>> - return spi->chip_select;
> >>> + return spi->chip_select[idx];
> >>> }
> >>>
> >>> static inline void spi_set_chipselect(struct spi_device *spi, u8
> >> idx, u8
> >>> chipselect)
> >>> {
> >>> - spi->chip_select = chipselect;
> >>> + spi->chip_select[idx] = chipselect;
> >>> }
> >>>
> >>> static inline struct gpio_desc *spi_get_csgpiod(const struct
> >> spi_device
> >>> *spi, u8 idx)
> >>> {
> >>> - return spi->cs_gpiod;
> >>> + return spi->cs_gpiod[idx];
> >>> }
> >>>
> >>> static inline void spi_set_csgpiod(struct spi_device *spi, u8 idx,
> >> struct
> >>> gpio_desc *csgpiod)
> >>> {
> >>> - spi->cs_gpiod = csgpiod;
> >>> + spi->cs_gpiod[idx] = csgpiod;
> >>> }
> >>>
> >>> /**
> >>> @@ -388,6 +401,8 @@ extern struct spi_device
> >>> *spi_new_ancillary_device(struct spi_device *spi, u8 ch
> >>> * @bus_lock_spinlock: spinlock for SPI bus locking
> >>> * @bus_lock_mutex: mutex for exclusion of multiple callers
> >>> * @bus_lock_flag: indicates that the SPI bus is locked for
> >> exclusive use
> >>> + * @multi_cs_cap: indicates that the SPI Controller can
> >> assert/de-assert
> >>> + * more than one chip select at once.
> >>> * @setup: updates the device mode and clocking records used by a
> >>> * device's SPI controller; protocol code may call this. This
> >>> * must fail if an unrecognized or unsupported mode is requested.
> >>> @@ -554,6 +569,11 @@ struct spi_controller {
> >>> #define SPI_CONTROLLER_MUST_TX BIT(4) /* Requires tx
> >>> */
> >>>
> >>> #define SPI_MASTER_GPIO_SS BIT(5) /* GPIO CS must
> >> select
> >>> slave */
> >>> + /*
> >>> + * The spi-controller has multi chip select capability and can
> >>> + * assert/de-assert more than one chip select at once.
> >>> + */
> >>> +#define SPI_CONTROLLER_MULTI_CS BIT(6)
> >>>
> >>> /* Flag indicating if the allocation of this struct is devres-
> >>> managed */
> >>> bool devm_allocated;
> >>> --
> >>> 2.17.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 V2] mediatek/clk-mt8173-apmixedsys: convert to devm_platform_ioremap_resource
From: Hao Ge @ 2023-04-20 9:11 UTC (permalink / raw)
To: sboyd, mturquette, matthias.bgg
Cc: gehao, linux-arm-kernel, linux-clk, linux-kernel, linux-mediatek,
gehao618
In-Reply-To: <7b162010-4fa3-4572-c834-7264eb937e4a@kylinos.cn>
Use devm_platform_ioremap_resource to take the place of of_iomap for
avoid that we don't called iounmap when return some error or remove
device.
Signed-off-by: Hao Ge <gehao@kylinos.cn>
Suggested-by: Stephen Boyd <sboyd@kernel.org>
---
v2: fix error handle condition for devm_platform_ioremap_resource
---
drivers/clk/mediatek/clk-mt8173-apmixedsys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
index a56c5845d07a..73c29d1dccc6 100644
--- a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
@@ -90,8 +90,8 @@ static int clk_mt8173_apmixed_probe(struct platform_device *pdev)
struct clk_hw *hw;
int r;
- base = of_iomap(node, 0);
- if (!base)
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
return PTR_ERR(base);
clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
--
2.25.1
No virus found
Checked by Hillstone Network AntiVirus
_______________________________________________
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 v2 08/19] KVM: arm64: Save/restore TCR2_EL1
From: Marc Zyngier @ 2023-04-20 9:13 UTC (permalink / raw)
To: Joey Gouly
Cc: linux-arm-kernel, nd, broonie, catalin.marinas, james.morse,
mark.rutland, oliver.upton, suzuki.poulose, will, yuzenghui
In-Reply-To: <20230413110513.243326-9-joey.gouly@arm.com>
On Thu, 13 Apr 2023 12:05:02 +0100,
Joey Gouly <joey.gouly@arm.com> wrote:
>
> Define the new system register TCR2_EL1 and context switch it.
>
> Signed-off-by: Joey Gouly <joey.gouly@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oliver.upton@linux.dev>
> Cc: James Morse <james.morse@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Zenghui Yu <yuzenghui@huawei.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 1 +
> arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 4 ++++
> arch/arm64/kvm/sys_regs.c | 1 +
> 3 files changed, 6 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index bcd774d74f34..e1137832a01f 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -269,6 +269,7 @@ enum vcpu_sysreg {
> TTBR0_EL1, /* Translation Table Base Register 0 */
> TTBR1_EL1, /* Translation Table Base Register 1 */
> TCR_EL1, /* Translation Control Register */
> + TCR2_EL1, /* Extended Translation Control Register */
> ESR_EL1, /* Exception Syndrome Register */
> AFSR0_EL1, /* Auxiliary Fault Status Register 0 */
> AFSR1_EL1, /* Auxiliary Fault Status Register 1 */
> diff --git a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
> index 699ea1f8d409..16199a107a47 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
> @@ -44,6 +44,8 @@ static inline void __sysreg_save_el1_state(struct kvm_cpu_context *ctxt)
> ctxt_sys_reg(ctxt, TTBR0_EL1) = read_sysreg_el1(SYS_TTBR0);
> ctxt_sys_reg(ctxt, TTBR1_EL1) = read_sysreg_el1(SYS_TTBR1);
> ctxt_sys_reg(ctxt, TCR_EL1) = read_sysreg_el1(SYS_TCR);
> + if (cpus_have_final_cap(ARM64_HAS_TCR2))
> + ctxt_sys_reg(ctxt, TCR2_EL1) = read_sysreg_el1(SYS_TCR2);
> ctxt_sys_reg(ctxt, ESR_EL1) = read_sysreg_el1(SYS_ESR);
> ctxt_sys_reg(ctxt, AFSR0_EL1) = read_sysreg_el1(SYS_AFSR0);
> ctxt_sys_reg(ctxt, AFSR1_EL1) = read_sysreg_el1(SYS_AFSR1);
> @@ -114,6 +116,8 @@ static inline void __sysreg_restore_el1_state(struct kvm_cpu_context *ctxt)
> write_sysreg_el1(ctxt_sys_reg(ctxt, CPACR_EL1), SYS_CPACR);
> write_sysreg_el1(ctxt_sys_reg(ctxt, TTBR0_EL1), SYS_TTBR0);
> write_sysreg_el1(ctxt_sys_reg(ctxt, TTBR1_EL1), SYS_TTBR1);
> + if (cpus_have_final_cap(ARM64_HAS_TCR2))
> + write_sysreg_el1(ctxt_sys_reg(ctxt, TCR2_EL1), SYS_TCR2);
> write_sysreg_el1(ctxt_sys_reg(ctxt, ESR_EL1), SYS_ESR);
> write_sysreg_el1(ctxt_sys_reg(ctxt, AFSR0_EL1), SYS_AFSR0);
> write_sysreg_el1(ctxt_sys_reg(ctxt, AFSR1_EL1), SYS_AFSR1);
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 53749d3a0996..5e7e4a433035 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1871,6 +1871,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { SYS_DESC(SYS_TTBR0_EL1), access_vm_reg, reset_unknown, TTBR0_EL1 },
> { SYS_DESC(SYS_TTBR1_EL1), access_vm_reg, reset_unknown, TTBR1_EL1 },
> { SYS_DESC(SYS_TCR_EL1), access_vm_reg, reset_val, TCR_EL1, 0 },
> + { SYS_DESC(SYS_TCR2_EL1), NULL, reset_unknown, TCR2_EL1 },
I'm not convinced reset_unknown is the right thing, at least for the
bits that are defined as "If EL2 and EL3 is not implemented, this bit
resets to 0b0 on a reset."
Given that an EL1 guest isn't in control of EL2, I'm a bit wary that
we start execution of the guest in a context that isn't well defined.
My strong preference would be to reset TCR2 just like TCR, unless you
can provide a explanation of why UNKNOWN is actually more correct.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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 v2 1/1] arm: dts: sunxi: Add ICnova A20 ADB4006 board support
From: Ludwig Kormann @ 2023-04-20 9:22 UTC (permalink / raw)
To: Andre Przywara
Cc: samuel, jernej.skrabec, wens, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, devicetree, linux-sunxi, linux-kernel
In-Reply-To: <20230420095735.00cbf365@donnerap.cambridge.arm.com>
Hi Andre,
Am 20.04.23 um 10:57 schrieb Andre Przywara:
> On Wed, 19 Apr 2023 14:12:29 +0200
> Ludwig Kormann <ludwig.kormann@in-circuit.de> wrote:
>
> Hi Ludwig,
>
> thanks for posting this!
>
>> Add board support for ICnova A20 SomPi compute module on
>> ICnova ADB4006 development board.
>>
>> Specification:
>> SoM
>> - Processor: Allwinner A20 Cortex-A7 Dual Core at 1GHz
>> - 512MB DDR3 RAM
>> - Fast Ethernet (Phy: Realtek RTL8201CP)
>> ADB4006
>> - I2C
>> - 2x USB 2.0
>> - 1x Fast Ethernet port
>> - 1x SATA
>> - 2x buttons (PWRON, Boot)
>> - 2x LEDS
>> - serial console
>> - HDMI
>> - µSD-Card slot
>> - Audio Line-In / Line-Out
>> - GPIO pinheaders
>>
>> https://wiki.in-circuit.de/index.php5?title=ICnova_ADB4006
>> https://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
>>
>> ---
>>
>> changes in v2:
>> - use short licensing header
>> - remove deprecated elements from led nodes
>> - disable csi power supply
>> - add missing pins in usbphy node
>> - split dts into SoM dtsi and carrier board dts
>>
>> v1 of this patch was sent to the uboot mailing list [1].
>>
>> [1] https://lists.denx.de/pipermail/u-boot/2023-April/514605.html
>>
>> Signed-off-by: Ludwig Kormann <ludwig.kormann@in-circuit.de>
> So apart from what Krzysztof already mentioned (separate binding patch and
> stray line), this looks good to me, and passed dt-validate. Also you
> addressed all the comments I had on the U-Boot post (thanks for that), so
> with those nits above fixed:
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Thanks for your review! I will provide v3 in a few minutes.
kind regards,
Ludwig
> Cheers,
> Andre
>
>> ---
>> .../devicetree/bindings/arm/sunxi.yaml | 6 +
>> arch/arm/boot/dts/Makefile | 1 +
>> .../boot/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 ++++++++++++++++++
>> arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi | 63 ++++++++
>> 4 files changed, 207 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
>>
>> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
>> index 013821f4a7b8..12f0c236f17b 100644
>> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
>> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
>> @@ -305,6 +305,12 @@ properties:
>> - const: allwinner,i12-tvbox
>> - const: allwinner,sun7i-a20
>>
>> + - description: ICNova A20 ADB4006
>> + items:
>> + - const: incircuit,icnova-a20-adb4006
>> + - const: incircuit,icnova-a20
>> + - const: allwinner,sun7i-a20
>> +
>> - description: ICNova A20 SWAC
>> items:
>> - const: incircuit,icnova-a20-swac
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 3cc32722c394..b6b408417261 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -1321,6 +1321,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>> sun7i-a20-hummingbird.dtb \
>> sun7i-a20-itead-ibox.dtb \
>> sun7i-a20-i12-tvbox.dtb \
>> + sun7i-a20-icnova-a20-adb4006.dtb \
>> sun7i-a20-icnova-swac.dtb \
>> sun7i-a20-lamobo-r1.dtb \
>> sun7i-a20-linutronix-testbox-v2.dtb \
>> diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> new file mode 100644
>> index 000000000000..c1606c085e4e
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> @@ -0,0 +1,137 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +// Copyright (C) 2023 In-Circuit GmbH
>> +
>> +/dts-v1/;
>> +
>> +#include "sun7i-a20-icnova-a20.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/leds/common.h>
>> +
>> +/ {
>> + model = "In-Circuit ICnova A20 ADB4006";
>> + compatible = "incircuit,icnova-a20-adb4006", "incircuit,icnova-a20",
>> + "allwinner,sun7i-a20";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + hdmi-connector {
>> + compatible = "hdmi-connector";
>> + type = "a";
>> +
>> + port {
>> + hdmi_con_in: endpoint {
>> + remote-endpoint = <&hdmi_out_con>;
>> + };
>> + };
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + led-0 {
>> + function = LED_FUNCTION_POWER;
>> + color = <LED_COLOR_ID_YELLOW>;
>> + gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; /* PH21 */
>> + default-state = "on";
>> + };
>> +
>> + led-1 {
>> + function = LED_FUNCTION_HEARTBEAT;
>> + color = <LED_COLOR_ID_RED>;
>> + gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */
>> + linux,default-trigger = "heartbeat";
>> + };
>> + };
>> +};
>> +
>> +&ahci {
>> + target-supply = <®_ahci_5v>;
>> + status = "okay";
>> +};
>> +
>> +&codec {
>> + status = "okay";
>> +};
>> +
>> +&de {
>> + status = "okay";
>> +};
>> +
>> +&ehci0 {
>> + status = "okay";
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&hdmi {
>> + status = "okay";
>> +};
>> +
>> +&hdmi_out {
>> + hdmi_out_con: endpoint {
>> + remote-endpoint = <&hdmi_con_in>;
>> + };
>> +};
>> +
>> +&mmc0 {
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
>> + status = "okay";
>> +};
>> +
>> +&ohci0 {
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&otg_sram {
>> + status = "okay";
>> +};
>> +
>> +®_ahci_5v {
>> + status = "okay";
>> +};
>> +
>> +&ac_power_supply {
>> + status = "okay";
>> +};
>> +
>> +®_usb1_vbus {
>> + status = "okay";
>> +};
>> +
>> +®_usb2_vbus {
>> + status = "okay";
>> +};
>> +
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_pb_pins>;
>> + status = "okay";
>> +};
>> +
>> +&usb_otg {
>> + dr_mode = "otg";
>> + status = "okay";
>> +};
>> +
>> +&usbphy {
>> + usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
>> + usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
>> + usb1_vbus-supply = <®_usb1_vbus>;
>> + usb2_vbus-supply = <®_usb2_vbus>;
>> + status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi b/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
>> new file mode 100644
>> index 000000000000..f1142bda5cd7
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
>> @@ -0,0 +1,63 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +// Copyright (C) 2023 In-Circuit GmbH
>> +
>> +#include "sun7i-a20.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +
>> +&cpu0 {
>> + cpu-supply = <®_dcdc2>;
>> +};
>> +
>> +&gmac {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&gmac_mii_pins>;
>> + phy-handle = <&phy1>;
>> + phy-mode = "mii";
>> + status = "okay";
>> +};
>> +
>> +&i2c0 {
>> + status = "okay";
>> +
>> + axp209: pmic@34 {
>> + reg = <0x34>;
>> + interrupt-parent = <&nmi_intc>;
>> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> + };
>> +};
>> +
>> +&gmac_mdio {
>> + phy1: ethernet-phy@1 {
>> + reg = <1>;
>> + };
>> +};
>> +
>> +#include "axp209.dtsi"
>> +
>> +®_dcdc2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <1400000>;
>> + regulator-name = "vdd-cpu";
>> +};
>> +
>> +®_dcdc3 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <1400000>;
>> + regulator-name = "vdd-int-dll";
>> +};
>> +
>> +®_ldo1 {
>> + regulator-name = "vdd-rtc";
>> +};
>> +
>> +®_ldo2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3000000>;
>> + regulator-name = "avcc";
>> +};
>> +
>
--
Dipl.-Ing. Ludwig Kormann
In-Circuit GmbH
Boltenhagener Straße 124
01109 Dresden
Germany
Phone: +49 351 42 66 850
Fax: +49 351 42 66 849
Email: ludwig.kormann@in-circuit.de
https://www.in-circuit.de/
Name der Gesellschaft: In-Circuit GmbH
Sitz der Gesellschaft: Dresden
Handelsregister : HRB 23099
Geschäftsführer : Jörg Träger
UST-ID Nr. : DE237550066
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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